linux-kernel - Re: [PATCH] pci/quirks: Add quirk for Bayhub O2 SD controller

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20211215202703.GA708007@bhelgaas>
Date:   Wed, 15 Dec 2021 14:27:03 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Rajat Jain <rajatxjain@...il.com>
Cc:     Rajat Jain <rajatja@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>, linux-mmc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        Jesse Barnes <jsbarnes@...gle.com>, gwendal@...gle.com
Subject: Re: [PATCH] pci/quirks: Add quirk for Bayhub O2 SD controller

On Wed, Dec 15, 2021 at 10:15:02AM -0800, Rajat Jain wrote:
> On Wed, Dec 15, 2021 at 10:04 AM Bjorn Helgaas <helgaas@...nel.org> wrote:
> > On Tue, Dec 07, 2021 at 04:09:48PM -0800, Rajat Jain wrote:
> > > This particular SD controller from O2 / Bayhub only allows dword
> > > accesses to its LTR max latency registers:
> > > https://github.com/rajatxjain/public_shared/blob/main/OZ711LV2_appnote.pdf
> >
> > What happens if we use a non-dword access?  Unsupported Request?
> > Invalid data returned?  Writes ignored?
> 
> Invalid data values are read / written.
> 
> > I guess word accesses must not cause PCIe errors, since we still do
> > them in pci_save_ltr_state() and pci_restore_ltr_state() even with
> > this patch.
> 
> Yes, that is correct.
> 
> > The app note says 0x234 (Max Latency registers), 0x248 (L1 PM
> > Substates Control 1), and 0x24c (L1 PM Substates Control 2) are all
> > broken, but the patch only mentions 0x234.
> >
> > I guess for 0x248 and 0x24c (the L1 PM Substates Control registers),
> > we're just lucky because those are dword registers, and all current
> > users already do dword accesses.
> 
> Yes, that is right.
> 
> > What if we instead changed pci_save_ltr_state() and
> > pci_restore_ltr_state() to do a single dword access instead of two
> > word accesses?  That kind of sweeps it under the rug, but we're
> > already doing that for 0x248 and 0x24c.
> 
> Yes, that is what I had in mind originally, and actually I'd prefer
> that too. I was afraid you might disagree :-). It sounds like we're on
> the same page though, so should I send a patch with that approach?

I think so.  I don't *like* papering over it, but the quirk only
compensates for one situation (pci_save_ltr_state() and
pci_restore_ltr_state()).  Any other places where we might read/write
the LTR values will still fail.  We don't have any other places yet,
but if/when we get ASPM L1.2 figured out, I think we will.

If we had a quirk mechanism for filtering config accesses to certain
devices, that would be ideal, but I don't think we have that.  If you
squint hard enough, aer_inject.c has something like that, but it's not
general purpose.

> > If we did that, we shouldn't need a quirk at all, but the hardware bug
> > is still lurking, and we should add a comment about it somewhere.
> 
> I can add a comment in pci_save_ltr_state() / pci_restore_ltr_state().

Maybe also in pcie_aspm_cap_init() for the L1 PM part.  Just a
one-liner should be enough.  All the details will be in the commit log
and the app note.

Bjorn