linux-kernel - Re: [PATCH] i2c: piix4: Replace piix4_smbus driver's cd6h/cd7h port io accesses with mmio accesses

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]

Date:   Tue, 11 Jan 2022 16:54:35 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Terry Bowman <Terry.Bowman@....com>
Cc:     Wolfram Sang <wsa@...nel.org>, Guenter Roeck <linux@...ck-us.net>,
        Jean Delvare <jdelvare@...e.de>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        linux-watchdog@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Robert Richter <rrichter@....com>
Subject: Re: [PATCH] i2c: piix4: Replace piix4_smbus driver's cd6h/cd7h port
 io accesses with mmio accesses

On Tue, Jan 11, 2022 at 4:53 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Tue, Jan 11, 2022 at 4:13 PM Terry Bowman <Terry.Bowman@....com> wrote:
> > The cd6h/cd7h port I/O can be disabled on recent AMD processors and these
> > changes replace the cd6h/cd7h port I/O accesses with with MMIO accesses.
> > I can provide more details or answer questions.
>
> AFAIU the issue the list of questions looks like this (correct me, if
> I'm wrong):
> - some chips switched from I/O to MMIO
> - the bus driver has shared resources with another (TCO) driver
>
> Now, technically what you are trying is to find a way to keep the
> original functionality on old machines and support new ones without
> much trouble.
>
> From what I see, the silver bullet may be the switch to regmap as we
> have done in I2C DesignWare driver implementation.
>
> Yes, it's a much more invasive solution, but at the same time it's
> much cleaner from my p.o.v. And you may easily split it to logical
> parts (prepare drivers, switch to regmap, add a new functionality).
>
> I might be missing something and above not gonna work, please tell me
> what I miss in that case.

On top of that I'm wondering why slow I/O is used? Do we have anything
that really needs that or is it simply a cargo-cult?

> > On 1/11/22 6:39 AM, Wolfram Sang wrote:
> > >
> > >> I have briefly read the discussion by the link you provided above in
> > >> this thread. I'm not sure I understand the issue and if Intel hardware
> > >> is affected. Is there any summary of the problem?
> > >
> > > I guess the original patch description should explain it. You can find
> > > it here:
> > >
> > > http://patchwork.ozlabs.org/project/linux-i2c/patch/20210715221828.244536-1-Terry.Bowman@amd.com/
> > >
> > > If this is not sufficient, hopefully Terry can provide more information?

-- 
With Best Regards,
Andy Shevchenko