Message-Id: <31207BE9-C83F-4B4D-9A3F-7F25DF574E89@nexthop.ai>
Date: Mon, 19 Jan 2026 11:18:12 -0800
From: Abdurrahman Hussain <abdurrahman@...thop.ai>
To: Mark Brown <broonie@...nel.org>
Cc: Michal Simek <michal.simek@....com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 linux-spi@...r.kernel.org,
 devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.



> On Jan 19, 2026, at 11:01 AM, Mark Brown <broonie@...nel.org> wrote:
> 
> On Mon, Jan 19, 2026 at 07:52:35PM +0100, Michal Simek wrote:
>> On 1/19/26 19:38, Mark Brown wrote:
> 
>>> This was specifically targetted at some embedded x86 systems where there
>>> was a goal to reuse device tree bindings for things that just can't be
>>> expressed well in ACPI.  _DSD is generally considered tasteless for more
>>> server style systems, AIUI the general approach preferred by ACPI
>>> forward OSs is to use some combination of DMI quirking and registering
>>> with a per-device ID (like the per generation fake PCI IDs that Intel
>>> uses for all IPs on their SoCs).  Just blindly accepting _DSD can end up
>>> with something that's not used because it's not what the ecosystem
>>> wants.
> 
>> Is it a better way to use auxiliary bus as was recommended by Greg in past
>> on drivers/misc/keba/cp500.c review?
>> https://lore.kernel.org/linux-i2c/2024060203-impeding-curing-e6cd@gregkh/
> 
> The driver there appears to be doing runtime enumeration based on some
> EEPROMs on the system and creating platform devices based on what it
> finds there so it's a bit of a different thing, the aux bus suggestion
> is about what the code that does with the data it got from the EEPROM.
> This patch is for something described directly by firmware so there's no
> way we'd create an aux device, that's purely in kernel.
> 
> I have no idea what the hardware this series targets is (other than that
> it's using a FPGA) or if there's even a motivation for the change other
> than code inspection.

We are using this on an AMD Ryzen Embedded V3C48 based system. This is a data-center switch using Broadcom TH5 ASIC with 64 port OSFP cage and a whole lot of hwmon/pmbus and temp sensors. We have an AMD Artix 7 based FPGA that sits on PCIe bus and exposes about 80 different IP blocks (I2C and SPI). Behind each IP block are various devices. Each of the 64 OSFPs is handled by its own IP block (i2c-xiic.c driver) and is wired to one of 3 MSI interrupts.

We have implemented a custom irq_chip/gpi driver to manage the interrupts.

All of this gets automatically enumerated by kernel and works today, so there’s strong motivation to get this merged. It’s not just for code inspection. We are currently using 6.12 kernel.


Here’s an example of what a SPI controller/device would look like in ACPI ASL:

            Device (SPI0) {
                Name (_HID, "PRP0001")
                Name (_CRS, ResourceTemplate () {
                    Memory32Fixed (ReadWrite, 0x80950000, 0x00000200)
                })
                Name (_DSD, Package () {
                    ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                    Package () {
                        Package () { "compatible", "xlnx,axi-quad-spi-1.00.a" },
                        Package () { "xlnx,num-ss-bits", 5 },
                        Package () { "xlnx,num-transfer-bits", 8 },
                    }
                })

                Device (NOR0) {
                    Name (_HID, "PRP0001")
                    Name (_STR, Unicode ("TH5 Boot Flash"))
                    Name (_CRS, ResourceTemplate () {
                        SPISerialBus(0, PolarityLow, FourWireMode, 8, ControllerInitiated,
                            120000000, ClockPolarityHigh, ClockPhaseSecond,
                            "\\_SB.PCI0.GPP6.FPGA.SPI0")
                    })
                    Name (_DSD, Package () {
                        ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                        Package () {
                            Package () { "compatible", "jedec,spi-nor" }
                        }
                    })
                }
            }

And here’s an example of I2C controller with a TMP sensor:

            Device (I2C6) {
                Name (_HID, "PRP0001")
                Name (_CRS, ResourceTemplate () {
                    Memory32Fixed (ReadWrite, 0x80a40c00, 0x00000200)
                    ClockInput(25, 1, Mhz, Fixed,,)
                    GpioInt (Level, ActiveHigh, Exclusive, PullNone, 0,
                        "\\_SB.PCI0.GPP5.FPGA") { 14 }
                })
                Name (_DSD, Package () {
                    ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                    Package () {
                       Package () { "compatible", "xlnx,axi-iic-2.1" },
                       Package () { "single-master", 1 },
                       Package () { "clock-frequency", 100000 },
                    }
                })

                Device (TMP0) {
                    Name (_HID, "PRP0001")
                    Name (_CRS, ResourceTemplate () {
                        I2cSerialBusV2 (0x48, ControllerInitiated, 100000,
                            AddressingMode7Bit, "\\_SB.PCI0.GPP5.FPGA.I2C6",
                            0, ResourceConsumer,,)
                    })
                    Name (_DSD, Package () {
                        ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                        Package () {
                            Package () { "compatible", "ti,tmp464" }
                        }
                    })
                }
            }

Powered by blists - more mailing lists