From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9849C433EF for ; Mon, 21 Feb 2022 17:07:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351099AbiBURH2 (ORCPT ); Mon, 21 Feb 2022 12:07:28 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:55058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240037AbiBURHW (ORCPT ); Mon, 21 Feb 2022 12:07:22 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 564381D32F; Mon, 21 Feb 2022 09:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645463218; x=1676999218; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=RZDvFcjNGzHfz6QJapWn9VmEfw3si9l1wOlygRoWuG8=; b=dTldcRvdL3TB43GX5oDmRRR/PGPqswjY6qzz358+VfG7PXy/sIAQBN+z IXcQxTqPugT/eK4Wq1k86h5a+npMe1JhsrB2tOV+qaQlV+FeOJ3myApo1 u/TqhPLAMvm1Tav2wJaboMtYvaYcz36tr5QXCSpbHIhSdVD07t80hkORk Xzyhej/xJMeXrp8/sxvZOTudXf1g3dIkcr5PcovtxG0vgc49Hy0C2hObf n4W2j5UqoiJEms+WZzQV8xuPak7oy3EuP/XdGj6/V4ZyvXM1KzN7Iqcif kHENspKkPin3hFWciYa/acff6MvN57KpA5AoxhMsku7tUifAoS0vMuI5a w==; X-IronPort-AV: E=McAfee;i="6200,9189,10265"; a="232164088" X-IronPort-AV: E=Sophos;i="5.88,386,1635231600"; d="scan'208";a="232164088" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2022 09:06:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,386,1635231600"; d="scan'208";a="636723005" Received: from linux.intel.com ([10.54.29.200]) by fmsmga002.fm.intel.com with ESMTP; 21 Feb 2022 09:06:57 -0800 Received: from bazacche-MOBL.amr.corp.intel.com (unknown [10.209.98.194]) by linux.intel.com (Postfix) with ESMTP id B2092580C7E; Mon, 21 Feb 2022 09:06:57 -0800 (PST) Message-ID: <8cb2722299ecf8b4c6d24ff28a0a19024dcb41f0.camel@linux.intel.com> Subject: Re: [PATCH 1/3] platform/x86/intel: pmt: Remove bin_attribute mmap support to runtime pm From: "David E. Box" Reply-To: david.e.box@linux.intel.com To: Hans de Goede , mgross@linux.intel.com, rjw@rjwysocki.net, srinivas.pandruvada@intel.com Cc: linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org Date: Mon, 21 Feb 2022 09:06:57 -0800 In-Reply-To: <5ba6e52c-d7e9-39fc-cb84-963a403385ca@redhat.com> References: <20220214213258.1929462-1-david.e.box@linux.intel.com> <20220214213258.1929462-2-david.e.box@linux.intel.com> <5ba6e52c-d7e9-39fc-cb84-963a403385ca@redhat.com> Organization: David E. Box Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2022-02-21 at 10:05 +0100, Hans de Goede wrote: > Hi, > > On 2/14/22 22:32, David E. Box wrote: > > PMT devices need to support runtime D3. However, binary attributes > > don't > > provide access to open/release methods that could be used to > > control > > runtime pm. Therefore, remove the mmap operation. The data may > > still be > > accessed with read() calls. > > > > Signed-off-by: David E. Box > > --- > > V0 comments: > > > > I expect that this is an undesirable solution because of the ABI > > change. > > I don't know if anyone is using this ABI outside of our Intel tools > > which > > are willing to make this change. I'd rather find a solution to keep > > the > > mmap support. I initially wrote a patch to simply add the missing > > open and > > release callbacks to binary attributes but this was thought to be > > too heavy > > handed in our internal review. I'm open to suggestions. Thanks. > > We really cannot go and break userspace API like this. Even if you > are > dropping mmap support from the Intel tools; and we assume that the > Intel > tools are the only consumer, then we still cannot drop mmap support > because users may install a new kernel without updating the tools. > > The never break userspace rule applies here and that is a very clear > and hard rule. > > So please respin the series using the approach with open and release > callbacks. Thanks Hans. I'll send out that series for comment. David