Message-Id: <4831B269-DFC1-40E0-96B7-67981AC72562@nexthop.ai>
Date: Mon, 19 Jan 2026 12:30:43 -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:56 AM, Mark Brown <broonie@...nel.org> wrote:
> 
> On Mon, Jan 19, 2026 at 08:17:46PM +0100, Michal Simek wrote:
>> On 1/19/26 20:01, Mark Brown wrote:
>>> On Mon, Jan 19, 2026 at 07:52:35PM +0100, Michal Simek wrote:
> 
> 
>> If you know it I think you have multiple options how to wire existing drivers.
> 
>> 1. ACPI - which is what this series is trying to do
> 
> Is it?  It just looks like random cleanups.  We've got a change to make
> interrupts optional and this change to device properties - the cover
> letter just says it's a transition to device property but there's no
> indiciation why it's being done.  The cover letter for the series just
> says it's switching to device properties with no further explanation.
> It looks like a "that's the newer API" thing than something that's been
> thought through.
> 
> None of this looks like something intended to add ACPI bindings,
> it's not clear to me how we'd even get the device instantiated on a
> normal ACPI system.  There's no ACPI IDs defined (and there aren't any
> existing ones), just a conversion of the property parsing code.
> 

These "random" cleanups make the spi-xilinx.c driver work on non-DT platforms.
Which is what the cover letter says.

We are trying NOT to introduce new ACPI IDS, or fork the existing drivers.
But rather, to re-use the existing drivers as much as possible by relying on the
special DT namespace link "PRP0001":

"The special DT namespace link device ID, PRP0001, provides a means to use the existing DT-compatible device identification in ACPI."

Also from the same document:

"
Platform bus support

Since we are using platform devices to represent devices that are not connected to any physical bus we only need to implement a platform driver for the device and add supported ACPI IDs. If this same IP-block is used on some other non-ACPI platform, the driver might work out of the box or needs some minor changes.
"


>> 2. DT - on x86 not sure if feasible
> 
> No, x86 decided not to use DT and shoehorn everything into APCI (and the
> x86 SoCs put their platform devices behind fake PCI that looks like PCI
> to the OS).
> 
>> 3. platform drivers - as described above by Greg not an option on PCIe
>> 4. aux bus - for example keba drivers
>> 5. dfl - drivers/fpga/dfl* - used for accelerators.
> 
> These are orthogonal to the above, they're Linux internal things not a
> concept the firmware has.  You have firmware descriptions of things that
> can be mapped onto platform devices but that's a separate thing.
> 
>> Pretty much all current Xilinx drivers for soft IPs (spi, i2c, uarts,
>> watchdogs, etc) are platform drivers (more OF drivers because platform data
>> are mostly not used).
> 
>> It means I think would be good to get any recommendation which way to go.
> 
> You should use whatever firmware interface is sensible for the platform,
> if that's x86 that's always ACPI.  For other architectures there's a
> split with servers using ACPI and more embedded platforms using DT.

Which is exactly what we are doing - using ACPI on x86 to describe the hardware.

> 
>>> 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.
> 
>> I think all these cases are very similar. You have x86 with pcie root port
>> which is connected directly (or via pcie slot) to fpga. In fpga you have
>> pcie endpoint HW which connects other IPs sitting on AXI.
> 
> What are "all these cases"?  For something connected via PCI I would
> expect a PCI driver that knows via some mechanism what's connected to it
> and then instantiates the IPs, probably as aux devices.  I would not
> expect to see the contents of the PCI device described in firmware at
> all, that's a big goal with using PCI.  If something is not connected
> via PCI that's obviously not going to fly but it sounds like you're only
> interested in PCI cases here.

Yes, we have a somewhat “generic” PCI driver that actually doesn’t need to know
what’s actually “behind” it. It only implements irq_chip and gpios.
It’s the firmware (ACPI) that describes the devices as nested device nodes under the
FPGA device node. These HW ACPI tables are SKU specific, so the generic FPGA PCI driver
can be kept generic. And all the device enumeration just works. It goes with the kernel
philosophy of keeping the policy out of the kernel as much as possible.

All we need is these little “random” cleanups to tie it all together and make it working.

Regards,
Abdurrahman

Powered by blists - more mailing lists