Message-Id: <80A8F67E-7A01-4F9F-9D84-29722678A2CE@nexthop.ai>
Date: Tue, 20 Jan 2026 11:11:44 -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>,
 Andrew Lunn <andrew@...n.ch>,
 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 20, 2026, at 10:45 AM, Mark Brown <broonie@...nel.org> wrote:
> 
> On Mon, Jan 19, 2026 at 04:20:06PM -0800, Abdurrahman Hussain wrote:
> 
> To repeat once again:
> 
> | Please fix your mail client to word wrap within paragraphs at something
> | substantially less than 80 columns.  Doing this makes your messages much
> | easier to read and reply to.
> 
>>> On Jan 19, 2026, at 3:20 PM, Mark Brown <broonie@...nel.org> wrote:
> 
>>>> But rather, to re-use the existing drivers as much as possible by relying on the
>>>> special DT namespace link "PRP0001":
> 
>>> What is the goal in avoiding using native ACPI bindings?  PRP0001 is a
>>> workaround for cases where you have things that ACPI has never dreamed
>>> of and can't abstract well but which have already been handled by DT,
>>> it is not something we're aiming.  The hardware you have described
>>> seems like fairly normal server style hardware and like it should fit
>>> well with normal ACPI.  Adding ACPI IDs to existing drivers is pretty
>>> common and standard, I'd class that as reuse.
> 
>> I did not intentionally avoid introducing new ACPI _HIDs, but at the same time
>> don’t understand the need to, especially when PRP0001 workaround works and
>> it works well. We don’t own the spi-xilinx driver and neither do we own the i2c-xiic.
>> These are standard Xilinx IP platform drivers that could be made usable on ACPI platforms
>> by just switching to device_property APIs. Which is what these series is trying to do.
> 
> It's just not idiomatic ACPI, indeed some other OSs actively reject the
> idea of binding to PRP0001 described devices.  In general we don't want
> to encourage people needlessly creating unusual hardware descriptions,
> that provides better future proofing so we're less likely to have to
> work around our own past decisions and avoids causing hassle for other
> OS vendors with having to deal with Linux special firmware descriptions.
> 
>>> As far as I can see from the example you posted the devices are all
>>> fairly standard and just need IDs assigning to work naturally with ACPI.
>>> There's possibly an argument for using PRP0001 for the flash given that
>>> it's not especially idiomatic to have OS visible flash on ACPI systems,
>>> usually flash would only be visible to UEFI, but equally the description
>>> would trivial and systems wouldn't have to use it.
> 
>> You mention “idiomatic” a lot. Are you implying the SPI NOR-flash devices should
>> not be exposed to user-space? Then why does the spi-nor driver even exist?
> 
> Flashes are widely used on non-ACPI systems where exposing them to the
> OS is a perfectly normal and standard thing to do.  Usually on a system
> with ACPI NOR flashes would be purely for the firmware to store itself
> and it's data, storage exposed to the OS would be at least eMMC or
> something.  ACPI has a very strong idea of what the systems it is used
> with should look like.
> 
>> We have a SPI device that needs to be accessible from users-space in order to
>> “flash" various FPGAs. How do you suggest we do that?
> 
> You should probably register the device, it's just a question of if it's
> weird enough that it does actually fit with PRP0001 or if it's something
> with general enough application in ACPI systems that a HID should be
> allocated.
> 
>> Also, there are hundreds of drivers in the DT namespace that are missing the ACPI IDs today.
>> Do you suggest adding ACPI IDs to every driver just so it’s more “idiomatic” to use?
> 
> To drivers that are used on ACPI systems, yes.  Many devices wouldn't be
> used on ACPI systems, or would be expected to be exposed differently
> (for example, hidden behind AML).

This is not for a normal off the shelf server. In our case we are building an embedded
switch with an AMD CPU and Xilinx FPGAs that happens to use EDK2 based BIOS and ACPI.

We, as a vendor, have full control of the BIOS/ACPI and would like to use it describe
hardware and make as much use of the standard Linux drivers as possible. We have dozens of
I2C devices like temp sensors, voltage regulators, DCDC converters, EEPROMS, SPI-NOR flash
devices behind the Xilinx IP blocks. Most of the devices we use don’t have proper ACPI _HIDs.

> 
>> I am just trying to get this 2-line small change merged so we can start using the standard spi-xilinx driver today. I am not trying to boil the ocean.
> 
> I mean, adding a HID wouldn't take substantially more code.

We could, but we don’t own the Xilinx IP blocks. Are we not justified in using PRP0001
hack until the driver owner adds the HIDs? Wasn’t PRP0001 created as an escape hatch for
these kind of scenarios?


> 
>>> There is the bit where there's a PCI bus in the way and you don't use
>>> ACPI particularly idiomatically...  I can see the dodging out on the PCI
>>> bus description, but the way the devices behind the PCI bus are
>>> described seems confusing.
> 
>> What exactly about this usage is not idiomatic? Our PCI device description in ACPI looks like
>> this (GPP5 is the PCIe bridge under which the FPGA is located):
> 
> The use of PRP0001.

Understood.

Powered by blists - more mailing lists