Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: zbeJLlo4MyeFQ23eRZYuN5HtuYzrcxbTX8rqoB2Y+tfIz3F+SW650RYCWvFp4SKfh5RAKuvBni
 oNqL8yl0MYQQ==
IronPort-SDR: 5AzL6bCfU8sqBhH9dnNGMXsnXJwa19INQzEFBtECdoF9s/PVGcNFwYXHmmwgNiQPgANLWAz5ps
 RnbbbhMmxDYQ==
From:   "Mani, Rajmohan" <rajmohan.mani@intel.com>
To:     Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC:     Darren Hart <dvhart@infradead.org>,
        Andy Shevchenko <andy@infradead.org>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Lee Jones <lee.jones@linaro.org>,
        Ayman Bagabas <ayman.bagabas@gmail.com>,
        Masahiro Yamada <masahiroy@kernel.org>,
        "Joseph, Jithu" <jithu.joseph@intel.com>,
        =?iso-8859-2?Q?Bla=BE_Hrastnik?= <blaz@mxxn.io>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "pmalani@chromium.org" <pmalani@chromium.org>,
        "bleung@chromium.org" <bleung@chromium.org>
Subject: RE: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager (IOM)
 driver
Thread-Topic: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager
 (IOM) driver
Thread-Index: AQHWeD6ZmieVJ7ILtEmVT73DLNf2fqlNLX2AgAAXoACAAGapYA==
Date:   Fri, 28 Aug 2020 15:20:22 +0000
Message-ID: <DM6PR11MB3963228D43B50604AE4D0F3AF6520@DM6PR11MB3963.namprd11.prod.outlook.com>
References: <20200822040508.23510-1-rajmohan.mani@intel.com>
 <20200822040508.23510-2-rajmohan.mani@intel.com>
 <20200828074359.GC942935@kroah.com>
 <20200828090832.GB174928@kuha.fi.intel.com>
In-Reply-To: <20200828090832.GB174928@kuha.fi.intel.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.5.1.3
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c5a30c3-7cf5-4903-075f-08d84b65e1cd
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 15:20:22.3416
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FBWU2IK7Ep/zkL/dpdkxilABbN9RfNhTEY00KPbBrACsc76fktAN/P93Oalp0dwb13tv6XzN7otqsdn93gXZsA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4754
X-OriginatorOrg: intel.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Greg,

> Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager
> (IOM) driver
>=20
> Hi Greg,
>=20
> On Fri, Aug 28, 2020 at 09:43:59AM +0200, Greg Kroah-Hartman wrote:
> > I still find this crazy that a whole separate driver is created just
> > to read a single 32bit value.
> >
> > Why not put this logic in the driver that wants to read that value?
> > That would be much simpler, smaller, and more obvious.
>=20
> That would mean that we start maintaining something like DMI quirk table =
in
> those drivers. Unfortunately the IOM device is not available on every pla=
tform.
> Also, even on platforms that do have it, there is no guarantee that the d=
evice is
> always going to be mapped to the same address.
>=20
> Nevertheless, I was originally hoping that we could hide the handling of =
IOM
> somehow in ACPI without the need for an actual device object, but it now
> turns out that the other features of the IOM chip have created interest. =
At
> least our i915 guys probable have some use for it (I don't know exactly w=
hat
> they are planning to use it for).
>=20
> So the fact that we may later need the device for something else, on top =
of the
> clumsiness and most importantly risks involved with using ACPI to take ca=
re of
> extra tasks (ASL tends to have bugs - bugs that may never ever get fixed)=
, I
> think the IOM device object, and the driver that binds to it, do have a v=
alid
> reason for existing.
>=20

Intel PMC USB mux device is part of the PCH, while IOM is part of the SoC.
This was another reason we had to have a separate ACPI device.

>=20
> thanks,
>=20
> --
> heikki