linux-kernel - RE: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager (IOM) driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM6PR11MB3963228D43B50604AE4D0F3AF6520@DM6PR11MB3963.namprd11.prod.outlook.com>
Date:   Fri, 28 Aug 2020 15:20:22 +0000
From:   "Mani, Rajmohan" <rajmohan.mani@...el.com>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Ayman Bagabas <ayman.bagabas@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        "Joseph, Jithu" <jithu.joseph@...el.com>,
        Blaž Hrastnik <blaz@...n.io>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "pmalani@...omium.org" <pmalani@...omium.org>,
        "bleung@...omium.org" <bleung@...omium.org>
Subject: RE: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager (IOM)
 driver

Hi Greg,

> Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager
> (IOM) driver
> 
> Hi Greg,
> 
> 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.
> 
> That would mean that we start maintaining something like DMI quirk table in
> those drivers. Unfortunately the IOM device is not available on every platform.
> Also, even on platforms that do have it, there is no guarantee that the device is
> always going to be mapped to the same address.
> 
> 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 what
> they are planning to use it for).
> 
> 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 care 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 valid
> reason for existing.
> 

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.

> 
> thanks,
> 
> --
> heikki