Thread (7 messages) 7 messages, 4 authors, 2023-03-10

Re: [PATCH] arm64: PCI: Add quirk for platforms running Windows

From: Bjorn Helgaas <helgaas@kernel.org>
Date: 2023-03-09 17:38:55
Also in: linux-acpi, linux-arm-msm, linux-pci, lkml

On Thu, Mar 09, 2023 at 10:52:13AM +0800, Shawn Guo wrote:
+ linux-arm-msm and MSM maintainer Bjorn

On Wed, Mar 08, 2023 at 12:53:10PM -0600, Bjorn Helgaas wrote:
quoted
On Mon, Feb 27, 2023 at 10:12:21AM +0800, Shawn Guo wrote:
quoted
Commit 8fd4391ee717 ("arm64: PCI: Exclude ACPI "consumer" resources from
host bridge windows") introduced a check to remove host bridge register
resources for all arm64 platforms, with the assumption that the PNP0A03
_CRS resources would always be host bridge registers and never as windows
on arm64.

The assumption stands true until Qualcomm Snapdragon Windows laptops
emerge.  These laptops describe host bridge windows in PNP0A03 _CRS
resources instead.  For example, the Microsoft Surface Pro X has host
bridges defined as

    Name (_HID, EisaId ("PNP0A08") /* PCI Express Bus */)  // _HID: Hardware ID
    Name (_CID, EisaId ("PNP0A03") /* PCI Bus */)  // _CID: Compatible ID

    Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
    {
        Name (RBUF, ResourceTemplate ()
        {
            Memory32Fixed (ReadWrite,
                0x60200000,         // Address Base
                0x01DF0000,         // Address Length
                )
            WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
                0x0000,             // Granularity
                0x0000,             // Range Minimum
                0x0001,             // Range Maximum
                0x0000,             // Translation Offset
                0x0002,             // Length
                ,, )
        })
        Return (RBUF) /* \_SB_.PCI0._CRS.RBUF */
    }

The Memory32Fixed holds a host bridge window, but it's not properly
defined as a "producer" resource.  Consequently the resource gets
removed by kernel, and the BAR allocation fails later on:

    [ 0.150731] pci 0002:00:00.0: BAR 14: no space for [mem size 0x00100000]
    [ 0.150744] pci 0002:00:00.0: BAR 14: failed to assign [mem size 0x00100000]
    [ 0.150758] pci 0002:01:00.0: BAR 0: no space for [mem size 0x00004000 64bit]
    [ 0.150769] pci 0002:01:00.0: BAR 0: failed to assign [mem size 0x00004000 64bit]

This eventually prevents the PCIe NVME drive from being accessible.

Add a quirk for these platforms to avoid the resource being removed.

Signed-off-by: Shawn Guo <redacted>
---
We are running into the issue on more devices than just Surface Pro X
now, so trying to sort it out with a quirk as suggested by Lorenzo [1].
One thing I don't like about this application of quirks is that the
list of affected platforms is likely to grow, which is an ongoing
burden for users and developers.
It's a very reasonable concern.  I really hope that Qualcomm will start
thinking about Linux support on these machines in the future not too far
away, so that the list will not grow too long.
quoted
Can we have a conversation with Qualcomm about how they *intend* this
to work?  Linux is probably doing something wrong (interpreting
something differently than Windows does), and if we could fix that, we
have a better chance of future platforms working without quirks.
Today Qualcomm only ships and cares about Windows on these machines, but
I believe it will change sooner or later.
I don't maintain arch/arm64/kernel/pci.c, but my opinion is that we
should not pursue quirks like this until we've tried really hard to
figure out a generic approach.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help