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@xxxxxxxxxx> 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
