[PATCH v3 0/3] spi: xilinx: switch to device properties and make IRQs optional

[PATCH v3 0/3] spi: xilinx: switch to device properties and make IRQs optional

[Abdurrahman Hussain via B4 Relay]

Transition the driver to use the generic device property API.

Additionally, make interrupts optional to allow the driver to fall back
to its existing polling mode on systems where interrupts are either missing
or broken.

Abdurrahman Hussain (3):
  spi: xilinx: use device property accessors.
  spi: xilinx: make irq optional
  spi: dt-bindings: xilinx: make interrupts optional

 .../devicetree/bindings/spi/spi-xilinx.yaml          |  1 -
 drivers/spi/spi-xilinx.c                             | 12 ++++++------
 2 files changed, 6 insertions(+), 7 deletions(-)

--
2.52.0

base-commit: 944aacb68baf7624ab8d277d0ebf07f025ca137c
---
Abdurrahman Hussain (3):
      spi: dt-bindings: xilinx: make interrupts optional
      spi: xilinx: make irq optional
      spi: xilinx: use device property accessors.

 Documentation/devicetree/bindings/spi/spi-xilinx.yaml |  1 -
 drivers/spi/spi-xilinx.c                              | 12 ++++++------
 2 files changed, 6 insertions(+), 7 deletions(-)
---
base-commit: 944aacb68baf7624ab8d277d0ebf07f025ca137c
change-id: 20260118-spi-xilinx-1b884d5b6519

Best regards,
-- 
Abdurrahman Hussain <abdurrahman@nexthop.ai>

[PATCH v3 1/3] spi: dt-bindings: xilinx: make interrupts optional

[Abdurrahman Hussain via B4 Relay]

From: Abdurrahman Hussain <abdurrahman@nexthop.ai>

Both the hardware and driver already support polling mode. By removing
the mandatory IRQ requirement during probe, the driver can now fall
back to polling when an interrupt is unavailable, ensuring
compatibility with a wider range of systems.

Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
---
 Documentation/devicetree/bindings/spi/spi-xilinx.yaml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
index 4beb3af0416d..24e62530d432 100644
--- a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
@@ -38,7 +38,6 @@ properties:
 required:
   - compatible
   - reg
-  - interrupts
 
 unevaluatedProperties: false
 

-- 
2.52.0

[PATCH v3 2/3] spi: xilinx: make irq optional

[Abdurrahman Hussain via B4 Relay]

From: Abdurrahman Hussain <abdurrahman@nexthop.ai>

Both the hardware and driver already support polling mode. By removing
the mandatory IRQ requirement during probe, the driver can now fall
back to polling when an interrupt is unavailable, ensuring
compatibility with a wider range of systems.

Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
---
 drivers/spi/spi-xilinx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
index c86dc56f38b4..4aa67fc61cb6 100644
--- a/drivers/spi/spi-xilinx.c
+++ b/drivers/spi/spi-xilinx.c
@@ -471,7 +471,7 @@ static int xilinx_spi_probe(struct platform_device *pdev)
 	xspi->bytes_per_word = bits_per_word / 8;
 	xspi->buffer_size = xilinx_spi_find_buffer_size(xspi);
 
-	xspi->irq = platform_get_irq(pdev, 0);
+	xspi->irq = platform_get_irq_optional(pdev, 0);
 	if (xspi->irq < 0 && xspi->irq != -ENXIO) {
 		return xspi->irq;
 	} else if (xspi->irq >= 0) {

-- 
2.52.0

[PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain via B4 Relay]

From: Abdurrahman Hussain <abdurrahman@nexthop.ai>

Make the driver work on non-OF platforms.

Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
---
 drivers/spi/spi-xilinx.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
index 4aa67fc61cb6..9fb1da2fcce4 100644
--- a/drivers/spi/spi-xilinx.c
+++ b/drivers/spi/spi-xilinx.c
@@ -405,11 +405,11 @@ static int xilinx_spi_probe(struct platform_device *pdev)
 		bits_per_word = pdata->bits_per_word;
 		force_irq = pdata->force_irq;
 	} else {
-		of_property_read_u32(pdev->dev.of_node, "xlnx,num-ss-bits",
-					  &num_cs);
-		ret = of_property_read_u32(pdev->dev.of_node,
-					   "xlnx,num-transfer-bits",
-					   &bits_per_word);
+		device_property_read_u32(&pdev->dev, "xlnx,num-ss-bits",
+					 &num_cs);
+		ret = device_property_read_u32(&pdev->dev,
+					       "xlnx,num-transfer-bits",
+					       &bits_per_word);
 		if (ret)
 			bits_per_word = 8;
 	}

-- 
2.52.0

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Mon, Jan 19, 2026 at 07:06:24AM +0000, Abdurrahman Hussain via B4 Relay wrote:

> -		of_property_read_u32(pdev->dev.of_node, "xlnx,num-ss-bits",
> -					  &num_cs);
> -		ret = of_property_read_u32(pdev->dev.of_node,
> -					   "xlnx,num-transfer-bits",
> -					   &bits_per_word);
> +		device_property_read_u32(&pdev->dev, "xlnx,num-ss-bits",
> +					 &num_cs);
> +		ret = device_property_read_u32(&pdev->dev,
> +					       "xlnx,num-transfer-bits",
> +					       &bits_per_word);

Are these bindings appropraite for ACPI systems?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain]

> On Jan 19, 2026, at 8:32 AM, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Jan 19, 2026 at 07:06:24AM +0000, Abdurrahman Hussain via B4 Relay wrote:
> 
>> -		of_property_read_u32(pdev->dev.of_node, "xlnx,num-ss-bits",
>> -					  &num_cs);
>> -		ret = of_property_read_u32(pdev->dev.of_node,
>> -					   "xlnx,num-transfer-bits",
>> -					   &bits_per_word);
>> +		device_property_read_u32(&pdev->dev, "xlnx,num-ss-bits",
>> +					 &num_cs);
>> +		ret = device_property_read_u32(&pdev->dev,
>> +					       "xlnx,num-transfer-bits",
>> +					       &bits_per_word);
> 
> Are these bindings appropraite for ACPI systems?

Yes, the Xilinx IP blocks are memory mapped and work exactly the same on ACPI as they do on DT.

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On Mon, Jan 19, 2026 at 08:47:17AM -0800, Abdurrahman Hussain wrote:
> > On Jan 19, 2026, at 8:32 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Jan 19, 2026 at 07:06:24AM +0000, Abdurrahman Hussain via B4 Relay wrote:

> >> -		of_property_read_u32(pdev->dev.of_node, "xlnx,num-ss-bits",
> >> -					  &num_cs);
> >> -		ret = of_property_read_u32(pdev->dev.of_node,
> >> -					   "xlnx,num-transfer-bits",
> >> -					   &bits_per_word);
> >> +		device_property_read_u32(&pdev->dev, "xlnx,num-ss-bits",
> >> +					 &num_cs);
> >> +		ret = device_property_read_u32(&pdev->dev,
> >> +					       "xlnx,num-transfer-bits",
> >> +					       &bits_per_word);

> > Are these bindings appropraite for ACPI systems?

> Yes, the Xilinx IP blocks are memory mapped and work exactly the same on ACPI as they do on DT.

That does not answer the question at all.  Is it appropriate to
configure an ACPI system in this way?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain]

> On Jan 19, 2026, at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Jan 19, 2026 at 08:47:17AM -0800, Abdurrahman Hussain wrote:
>>> On Jan 19, 2026, at 8:32 AM, Mark Brown <broonie@kernel.org> wrote:
>>> On Mon, Jan 19, 2026 at 07:06:24AM +0000, Abdurrahman Hussain via B4 Relay wrote:
> 
>>>> - of_property_read_u32(pdev->dev.of_node, "xlnx,num-ss-bits",
>>>> -  &num_cs);
>>>> - ret = of_property_read_u32(pdev->dev.of_node,
>>>> -   "xlnx,num-transfer-bits",
>>>> -   &bits_per_word);
>>>> + device_property_read_u32(&pdev->dev, "xlnx,num-ss-bits",
>>>> + &num_cs);
>>>> + ret = device_property_read_u32(&pdev->dev,
>>>> +       "xlnx,num-transfer-bits",
>>>> +       &bits_per_word);
> 
>>> Are these bindings appropraite for ACPI systems?
> 
>> Yes, the Xilinx IP blocks are memory mapped and work exactly the same on ACPI as they do on DT.
> 
> That does not answer the question at all.  Is it appropriate to
> configure an ACPI system in this way?

I am not sure I understood your question. What do you mean by “appropriate”?
This is following the same guidelines as outlined in 
https://www.kernel.org/doc/html/v6.7/firmware-guide/acpi/enumeration.html

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Mon, Jan 19, 2026 at 09:15:40AM -0800, Abdurrahman Hussain wrote:
> > On Jan 19, 2026, at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Jan 19, 2026 at 08:47:17AM -0800, Abdurrahman Hussain wrote:

> >>> Are these bindings appropraite for ACPI systems?

> >> Yes, the Xilinx IP blocks are memory mapped and work exactly the same on ACPI as they do on DT.

> > That does not answer the question at all.  Is it appropriate to
> > configure an ACPI system in this way?

> I am not sure I understood your question. What do you mean by “appropriate”?
> This is following the same guidelines as outlined in 
> https://www.kernel.org/doc/html/v6.7/firmware-guide/acpi/enumeration.html

You are just bindly making the DT properties available as _DSD
properties on ACPI systems, ACPI is a completely different firmware
interface with it's own idioms.  Does this interface make any sense on
ACPI?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain]

> On Jan 19, 2026, at 9:32 AM, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Jan 19, 2026 at 09:15:40AM -0800, Abdurrahman Hussain wrote:
>>> On Jan 19, 2026, at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
>>> On Mon, Jan 19, 2026 at 08:47:17AM -0800, Abdurrahman Hussain wrote:
> 
>>>>> Are these bindings appropraite for ACPI systems?
> 
>>>> Yes, the Xilinx IP blocks are memory mapped and work exactly the same on ACPI as they do on DT.
> 
>>> That does not answer the question at all.  Is it appropriate to
>>> configure an ACPI system in this way?
> 
>> I am not sure I understood your question. What do you mean by “appropriate”?
>> This is following the same guidelines as outlined in 
>> https://www.kernel.org/doc/html/v6.7/firmware-guide/acpi/enumeration.html
> 
> You are just bindly making the DT properties available as _DSD
> properties on ACPI systems, ACPI is a completely different firmware
> interface with it's own idioms.  Does this interface make any sense on
> ACPI?


From the above link:

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

The following is an excerpt from 
https://www.kernel.org/doc/html/v6.7/firmware-guide/acpi/DSD-properties-rules.html

The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1, allows any type of device configuration data to be provided via the ACPI namespace. In principle, the format of the data may be arbitrary, but it has to be identified by a UUID which must be recognized by the driver processing the _DSD output. However, there are generic UUIDs defined for _DSD recognized by the ACPI subsystem in the Linux kernel which automatically processes the data packages associated with them and makes those data available to device drivers as "device properties”.

The two settings are just configuration data for the spi-xilinx driver. By switching to generic device_property_ APIs we can re-use the same driver on ACPI based systems where the properties are passed as _DSD.

Is this not appropriate?

Regards,
Abdurrahman

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

On Mon, Jan 19, 2026 at 09:47:11AM -0800, Abdurrahman Hussain wrote:
> > On Jan 19, 2026, at 9:32 AM, Mark Brown <broonie@kernel.org> wrote:

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.

> > You are just bindly making the DT properties available as _DSD
> > properties on ACPI systems, ACPI is a completely different firmware
> > interface with it's own idioms.  Does this interface make any sense on
> > ACPI?

> From the above link:

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

...

> Is this not appropriate?

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Michal Simek]

On 1/19/26 19:38, Mark Brown wrote:
> On Mon, Jan 19, 2026 at 09:47:11AM -0800, Abdurrahman Hussain wrote:
>>> On Jan 19, 2026, at 9:32 AM, Mark Brown <broonie@kernel.org> wrote:
> 
> 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.
> 
>>> You are just bindly making the DT properties available as _DSD
>>> properties on ACPI systems, ACPI is a completely different firmware
>>> interface with it's own idioms.  Does this interface make any sense on
>>> ACPI?
> 
>>  From the above link:
> 
>> "The special DT namespace link device ID, PRP0001, provides a means to
>> use the existing DT-compatible device identification in ACPI…"
> 
> ...
> 
>> Is this not appropriate?
> 
> 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/

Thanks,
Michal

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Michal Simek]

On 1/19/26 20:01, Mark Brown 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 don't thing it is actually eeprom because in fpga you can place at certain 
location just memory (or RO memory) to describe what it is inside.
There is also pcie config space which could be used.

Another approach would be to just put record uuid and via firmware interface 
asks for firmware blob which describes different configurations.

Above part is how to find out what is where.

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
2. DT - on x86 not sure if feasible
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.

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.


> 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.

Thanks,
Michal

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3890 bytes --]

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:

> > > 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 don't thing it is actually eeprom because in fpga you can place at certain
> location just memory (or RO memory) to describe what it is inside.

The table of per module I2C EEPROM devices (there's a whole pile flagged
as optional) sure does look like it, and it's a very standard way to
implement hardware enumeration of non-enumerable systems.

> 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.

> 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.

> > 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain]

> On Jan 19, 2026, at 11:56 AM, Mark Brown <broonie@kernel.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

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]

On Mon, Jan 19, 2026 at 12:30:43PM -0800, Abdurrahman Hussain wrote:

To repeat what I previously said:

| 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 11:56 AM, Mark Brown <broonie@kernel.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:

> > 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.

The cover letter just says:

| Transition the driver to use the generic device property API.

| Additionally, make interrupts optional to allow the driver to fall back
| to its existing polling mode on systems where interrupts are either missing
| or broken.

which doesn't mention any motivation for this, it's just a statement of
what the patches do.  It's very unclear why this is a series TBH, the
interrupts changes have no visible relationship to the device properties
conversion and should have been submitted separately.

> 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":

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.

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 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.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain]

> On Jan 19, 2026, at 3:20 PM, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Jan 19, 2026 at 12:30:43PM -0800, Abdurrahman Hussain wrote:
> 
> To repeat what I previously said:
> 
> | 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 11:56 AM, Mark Brown <broonie@kernel.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:
> 
>>> 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.
> 
> The cover letter just says:
> 
> | Transition the driver to use the generic device property API.
> 
> | Additionally, make interrupts optional to allow the driver to fall back
> | to its existing polling mode on systems where interrupts are either missing
> | or broken.
> 
> which doesn't mention any motivation for this, it's just a statement of
> what the patches do.  It's very unclear why this is a series TBH, the
> interrupts changes have no visible relationship to the device properties
> conversion and should have been submitted separately.

V1 was a single patch. And the commit body there was:

"This makes the driver work on non-OF platforms.”

See https://lkml.org/lkml/2026/1/15/66

It was suggested to reword the body in imperative mood. Maybe that’s where it got lost.
I can re-add the mentioning of non-OF platforms to the cover letter to make it clear.

Andrew Lunn also suggested to split it into 3.

> 
>> 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":
> 
> 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.


> 
> 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?

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?

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?
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.

> 
>>> 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.
> 
> 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):

    Scope (_SB.PCI0.GPP5)
    {
        Device (FPGA)
        {
            Name (_ADR, 0x00000000)
…
            Device (I2C0) {
            ...
            }

            Device (I2C1) {
            ...
            }

            Device (SPI0) {
            ...
            }

            Device (SPI0) {
            ...
            }

        }
     }

I have provided ASL fragments for I2C and SPI earlier.

Which part of it is not idiomatic?

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4268 bytes --]

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@kernel.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).

> 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.

> > 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain]

> On Jan 20, 2026, at 10:45 AM, Mark Brown <broonie@kernel.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@kernel.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.

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Andrew Lunn]

> 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?

I suspect your wording is wrong here. You probably have a license for
the Xilinx IP blocks, you are using in your synthesising for use in
your FPGA.

That i think you are trying to say is that you don't own the software
driver for the Xilinx IP blocks? But that should not matter. The Linux
community Maintains these drivers, and can make modifications to them.
You as part of this community can propose a patch which adds the
needed IDs to the driver.

The "escape hatch" is generally used when there is a mature DT
binding, but nothing for ACPI. Linux has a mature and complex set of
DT bindings around network device sub-components, where Linux drivers
all the sub-components. ACPI has nothing in this area, because network
devices used in the ACPI world tend to use firmware, not Linux to
drive the hardware. In such a case, using the escape hatch makes
sense. However, I2C, SPI, etc all have well established ACPI bindings
and are part of the basic ACPI standard. It makes no sense to use the
"escape hatch" hatch for such devices. Please follow the ACPI
standard.

       Andrew

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Andrew Lunn]

> 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.

I would actually say, that is the core of your problem.

Look around at the networking world. Nobody uses x86 for core
networking. Nobody uses ACPI. Everything is MIPS, ARM, or Risc-V and
using DT.  Linux has mature and complex DT bindings for networking,
ACPI has nothing.

You might want to consider using DT with x86. It is possible. Take a
look at drivers/misc/lan966x_pci.dtso, which is used for networking,
and can be used on x86.

    Andrew

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

On Tue, Jan 20, 2026 at 11:11:44AM -0800, Abdurrahman Hussain wrote:
> > On Jan 20, 2026, at 10:45 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Jan 19, 2026 at 04:20:06PM -0800, Abdurrahman Hussain wrote:

Let me once more renew my plea:

> > 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.

> > 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.

Sure, AFAICT it's mostly a PCI card with a bunch of stuff on it from a
software point of view.

> >> 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?

No, it's more there for the cases where embedded ACPI systems need to
import non-trivial DT bindings so they can avoid having to respecify
things that ACPI really doesn't cope with or for local hacks.  See
Andy's reply earlier in the thread:

   https://lore.kernel.org/r/aW9JihlsjnJ-uBul@black.igk.intel.com

AFAICT for ACPI the HID assigment is a bit of a free for all in practice
- board vendors generally seem perfectly happy to just pick something if
the silicon vendor didn't do something.  Just look at all the parts with
INTxxxx IDs!  That said Michal is on the thread so hopefully that's not
an issue and we can get something from Xilinx fairly easily.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Andy Shevchenko]

On Tue, Jan 20, 2026 at 09:04:58PM +0000, Mark Brown wrote:
> On Tue, Jan 20, 2026 at 11:11:44AM -0800, Abdurrahman Hussain wrote:
> > > On Jan 20, 2026, at 10:45 AM, Mark Brown <broonie@kernel.org> wrote:
> > > On Mon, Jan 19, 2026 at 04:20:06PM -0800, Abdurrahman Hussain wrote:
> 
> Let me once more renew my plea:
> 
> > > 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.
> 
> > > 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.
> 
> Sure, AFAICT it's mostly a PCI card with a bunch of stuff on it from a
> software point of view.
> 
> > >> 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?
> 
> No, it's more there for the cases where embedded ACPI systems need to
> import non-trivial DT bindings so they can avoid having to respecify
> things that ACPI really doesn't cope with or for local hacks.  See
> Andy's reply earlier in the thread:
> 
>    https://lore.kernel.org/r/aW9JihlsjnJ-uBul@black.igk.intel.com
> 
> AFAICT for ACPI the HID assigment is a bit of a free for all in practice
> - board vendors generally seem perfectly happy to just pick something if
> the silicon vendor didn't do something.  Just look at all the parts with
> INTxxxx IDs!  That said Michal is on the thread so hopefully that's not

INTxxxx was a (historical) mistake, but look at the correct one INTCxxxx
which has listed several components Intel doesn't own. Because ACPI HID
it's not only about the component in use, it's also about integration of
that component in the platform environment. Hence it might require (platform)
specific quirks.

> an issue and we can get something from Xilinx fairly easily.

Exactly! Either from them, or AMD can do, or even NextHop.AI.
If you have not yet registered vendor ID, it's pretty much
straightforward process.

Here is the pointer for your convenience:
https://uefi.org/PNP_ACPI_Registry

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Andy Shevchenko]

On Tue, Jan 20, 2026 at 11:28:50PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 20, 2026 at 09:04:58PM +0000, Mark Brown wrote:
> > On Tue, Jan 20, 2026 at 11:11:44AM -0800, Abdurrahman Hussain wrote:
> > > > On Jan 20, 2026, at 10:45 AM, Mark Brown <broonie@kernel.org> wrote:
> > > > On Mon, Jan 19, 2026 at 04:20:06PM -0800, Abdurrahman Hussain wrote:
> > 
> > Let me once more renew my plea:
> > 
> > > > 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.
> > 
> > > > 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.
> > 
> > Sure, AFAICT it's mostly a PCI card with a bunch of stuff on it from a
> > software point of view.
> > 
> > > >> 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?
> > 
> > No, it's more there for the cases where embedded ACPI systems need to
> > import non-trivial DT bindings so they can avoid having to respecify
> > things that ACPI really doesn't cope with or for local hacks.  See
> > Andy's reply earlier in the thread:
> > 
> >    https://lore.kernel.org/r/aW9JihlsjnJ-uBul@black.igk.intel.com
> > 
> > AFAICT for ACPI the HID assigment is a bit of a free for all in practice
> > - board vendors generally seem perfectly happy to just pick something if
> > the silicon vendor didn't do something.  Just look at all the parts with
> > INTxxxx IDs!  That said Michal is on the thread so hopefully that's not
> 
> INTxxxx was a (historical) mistake, but look at the correct one INTCxxxx
> which has listed several components Intel doesn't own. Because ACPI HID
> it's not only about the component in use, it's also about integration of
> that component in the platform environment. Hence it might require (platform)
> specific quirks.

Btw, you can look at the MIPI I3C HCI case. MIPI as an owner allocated generic
ID (which is usually represented as _CID in ACPI), AMD allocated their own one
_HID (compatible with _CID) exactly for the purpose of having platform quirks.

TL;DR: if you are 100% sure you have no HW integration issues, requirements, etc
and everything works as is, you can use Xilinx allocated id (assuming it will come)
for the given IP and use it directly as _HID, otherwise use that as _CID and
allocate your own for _HID.

> > an issue and we can get something from Xilinx fairly easily.
> 
> Exactly! Either from them, or AMD can do, or even NextHop.AI.
> If you have not yet registered vendor ID, it's pretty much
> straightforward process.
> 
> Here is the pointer for your convenience:
> https://uefi.org/PNP_ACPI_Registry

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Michal Simek]

On 1/20/26 22:38, Andy Shevchenko wrote:
> On Tue, Jan 20, 2026 at 11:28:50PM +0200, Andy Shevchenko wrote:
>> On Tue, Jan 20, 2026 at 09:04:58PM +0000, Mark Brown wrote:
>>> On Tue, Jan 20, 2026 at 11:11:44AM -0800, Abdurrahman Hussain wrote:
>>>>> On Jan 20, 2026, at 10:45 AM, Mark Brown <broonie@kernel.org> wrote:
>>>>> On Mon, Jan 19, 2026 at 04:20:06PM -0800, Abdurrahman Hussain wrote:
>>>
>>> Let me once more renew my plea:
>>>
>>>>> 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.
>>>
>>>>> 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.
>>>
>>> Sure, AFAICT it's mostly a PCI card with a bunch of stuff on it from a
>>> software point of view.
>>>
>>>>>> 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?
>>>
>>> No, it's more there for the cases where embedded ACPI systems need to
>>> import non-trivial DT bindings so they can avoid having to respecify
>>> things that ACPI really doesn't cope with or for local hacks.  See
>>> Andy's reply earlier in the thread:
>>>
>>>     https://lore.kernel.org/r/aW9JihlsjnJ-uBul@black.igk.intel.com
>>>
>>> AFAICT for ACPI the HID assigment is a bit of a free for all in practice
>>> - board vendors generally seem perfectly happy to just pick something if
>>> the silicon vendor didn't do something.  Just look at all the parts with
>>> INTxxxx IDs!  That said Michal is on the thread so hopefully that's not
>>
>> INTxxxx was a (historical) mistake, but look at the correct one INTCxxxx
>> which has listed several components Intel doesn't own. Because ACPI HID
>> it's not only about the component in use, it's also about integration of
>> that component in the platform environment. Hence it might require (platform)
>> specific quirks.
> 
> Btw, you can look at the MIPI I3C HCI case. MIPI as an owner allocated generic
> ID (which is usually represented as _CID in ACPI), AMD allocated their own one
> _HID (compatible with _CID) exactly for the purpose of having platform quirks.
> 
> TL;DR: if you are 100% sure you have no HW integration issues, requirements, etc
> and everything works as is, you can use Xilinx allocated id (assuming it will come)
> for the given IP and use it directly as _HID, otherwise use that as _CID and
> allocate your own for _HID.

I got in touch with respective AMD team about ACPI ID allocation. I also don't 
think it is going to be a problem to get unique one. And I expect device 
properties should pretty much match DT property names to be able to use the same 
device_property_read* helper function to read them. Andy: Correct?

I am still trying to wrap my head around all these possible solutions for this 
problem or if we can solve it in a more generic way.

I can't see any problem with patches which are switching from of_property_read* 
to device_property_read. If driver also works without IRQ I think it is fine to 
make irq optional (which is 2/3 patch in this series).
The patch 1/3 is the same as mine I sent in past
https://lore.kernel.org/all/a527f5adffc6efe4c1ad2ccc40e1e095d73efe74.1749027112.git.michal.simek@amd.com/
and it was rejected by Rob.


Andrew: thanks for sharing link to pcie driver with DT which is one solution 
which requires writing one PCIe driver and that's pretty much it.
Obviously enable DT on x86 but that's not a problem for product based on 
embedded x86. But it can be a problem for standard distributions.

Then this ACPI way where it is not clear to me yet how to get information about 
clocks. The i2c Abdurrahman's patch is making clk optional
https://lore.kernel.org/r/20260115002846.25389-1-abdurrahman@nexthop.ai
But input_clk is used in reinit code that's why maybe it is working for the 
first time but in case of error not sure if driver really works properly.
On PCIe clock for spi/i2c is likely only one and ACPI device property can be 
created to pass that information and call devm_clk_get_enabled() only in DT case.

And then you have DFL (drivers/fpga/dfl*) and aux bus 
(drivers/misc/keba/cp500.c) which pretty much targets similar setup.

Thanks,
Michal

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 09:11:04AM +0100, Michal Simek wrote:
> On 1/20/26 22:38, Andy Shevchenko wrote:
> > On Tue, Jan 20, 2026 at 11:28:50PM +0200, Andy Shevchenko wrote:
> > > On Tue, Jan 20, 2026 at 09:04:58PM +0000, Mark Brown wrote:
> > > > On Tue, Jan 20, 2026 at 11:11:44AM -0800, Abdurrahman Hussain wrote:
> > > > > > On Jan 20, 2026, at 10:45 AM, Mark Brown <broonie@kernel.org> wrote:
> > > > > > On Mon, Jan 19, 2026 at 04:20:06PM -0800, Abdurrahman Hussain wrote:
> > > > 
> > > > Let me once more renew my plea:
> > > > 
> > > > > > 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.
> > > > 
> > > > > > 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.
> > > > 
> > > > Sure, AFAICT it's mostly a PCI card with a bunch of stuff on it from a
> > > > software point of view.
> > > > 
> > > > > > > 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?
> > > > 
> > > > No, it's more there for the cases where embedded ACPI systems need to
> > > > import non-trivial DT bindings so they can avoid having to respecify
> > > > things that ACPI really doesn't cope with or for local hacks.  See
> > > > Andy's reply earlier in the thread:
> > > > 
> > > >     https://lore.kernel.org/r/aW9JihlsjnJ-uBul@black.igk.intel.com
> > > > 
> > > > AFAICT for ACPI the HID assigment is a bit of a free for all in practice
> > > > - board vendors generally seem perfectly happy to just pick something if
> > > > the silicon vendor didn't do something.  Just look at all the parts with
> > > > INTxxxx IDs!  That said Michal is on the thread so hopefully that's not
> > > 
> > > INTxxxx was a (historical) mistake, but look at the correct one INTCxxxx
> > > which has listed several components Intel doesn't own. Because ACPI HID
> > > it's not only about the component in use, it's also about integration of
> > > that component in the platform environment. Hence it might require (platform)
> > > specific quirks.
> > 
> > Btw, you can look at the MIPI I3C HCI case. MIPI as an owner allocated generic
> > ID (which is usually represented as _CID in ACPI), AMD allocated their own one
> > _HID (compatible with _CID) exactly for the purpose of having platform quirks.
> > 
> > TL;DR: if you are 100% sure you have no HW integration issues, requirements, etc
> > and everything works as is, you can use Xilinx allocated id (assuming it will come)
> > for the given IP and use it directly as _HID, otherwise use that as _CID and
> > allocate your own for _HID.
> 
> I got in touch with respective AMD team about ACPI ID allocation. I also
> don't think it is going to be a problem to get unique one. And I expect
> device properties should pretty much match DT property names to be able to
> use the same device_property_read* helper function to read them. Andy:
> Correct?

Yes, the main issue I see is the enumeration by PRP0001 instead of by ACPI
_HID. Also note, whatever ACPI has supported in _CRS (resources) should be
used that way (memory, interrupts, DMA channels, etc).

> I am still trying to wrap my head around all these possible solutions for
> this problem or if we can solve it in a more generic way.
> 
> I can't see any problem with patches which are switching from
> of_property_read* to device_property_read.

Technically there is no issue with that, indeed.

> If driver also works without IRQ
> I think it is fine to make irq optional (which is 2/3 patch in this series).
> The patch 1/3 is the same as mine I sent in past
> https://lore.kernel.org/all/a527f5adffc6efe4c1ad2ccc40e1e095d73efe74.1749027112.git.michal.simek@amd.com/
> and it was rejected by Rob.

I think Rob is correct. But what's the problem to describe IRQ natively in _CRS
in ACPI via Interrupt() or GpioInt() resource? You mean there is no actual wire
connection to it?

> Andrew: thanks for sharing link to pcie driver with DT which is one solution
> which requires writing one PCIe driver and that's pretty much it.
> Obviously enable DT on x86 but that's not a problem for product based on
> embedded x86. But it can be a problem for standard distributions.
> 
> Then this ACPI way where it is not clear to me yet how to get information
> about clocks. The i2c Abdurrahman's patch is making clk optional
> https://lore.kernel.org/r/20260115002846.25389-1-abdurrahman@nexthop.ai
> But input_clk is used in reinit code that's why maybe it is working for the
> first time but in case of error not sure if driver really works properly.
> On PCIe clock for spi/i2c is likely only one and ACPI device property can be
> created to pass that information and call devm_clk_get_enabled() only in DT
> case.

On ACPI the clock are usually managed by firmware, but in new specification
we also have ClockInput() resource. I dunno if there is still a gap between
ACPICA and CCF to integrate that.

> And then you have DFL (drivers/fpga/dfl*) and aux bus
> (drivers/misc/keba/cp500.c) which pretty much targets similar setup.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 07:56:57PM +0000, Mark Brown 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:

> > > > 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 don't thing it is actually eeprom because in fpga you can place at certain
> > location just memory (or RO memory) to describe what it is inside.
> 
> The table of per module I2C EEPROM devices (there's a whole pile flagged
> as optional) sure does look like it, and it's a very standard way to
> implement hardware enumeration of non-enumerable systems.
> 
> > 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.

For the matter of this change, the only thing that can be preferred in ACPI is
to have the real ID, id est ACPI _HID (allocated by the vendor, namely Xilix).
So, ideally at the end it should be enumerated by ACPI ID table with properly
allocated HID and not with the compatible line.

The compatible line is for prototyping and DIY (discrete components, like
small temperature sensors, when allocating proper ACPI ID is a big deal
for a vendor).

The set of _DSD properties is okay to be shared even in that case.

TL;DR: We prefer ACPI HID to be properly allocated and used, or explained
why it can't be feasible (which I don't believe the case for Xilinx).

> > 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).

There are three platforms in the past that used DT on x86.
Latest one was dated ca. 2017 (SpreadTrum SoC with x86 core in it).

DT on x86 is a real thing, but very niche.

> > 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.
> 
> > > 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.



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Andy Shevchenko]

+Cc: Rafael

On Tue, Jan 20, 2026 at 10:23:22AM +0100, Andy Shevchenko wrote:
> On Mon, Jan 19, 2026 at 07:56:57PM +0000, Mark Brown 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:
> 
> > > > > 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 don't thing it is actually eeprom because in fpga you can place at certain
> > > location just memory (or RO memory) to describe what it is inside.
> > 
> > The table of per module I2C EEPROM devices (there's a whole pile flagged
> > as optional) sure does look like it, and it's a very standard way to
> > implement hardware enumeration of non-enumerable systems.
> > 
> > > 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.
> 
> For the matter of this change, the only thing that can be preferred in ACPI is
> to have the real ID, id est ACPI _HID (allocated by the vendor, namely Xilix).
> So, ideally at the end it should be enumerated by ACPI ID table with properly
> allocated HID and not with the compatible line.
> 
> The compatible line is for prototyping and DIY (discrete components, like
> small temperature sensors, when allocating proper ACPI ID is a big deal
> for a vendor).
> 
> The set of _DSD properties is okay to be shared even in that case.
> 
> TL;DR: We prefer ACPI HID to be properly allocated and used, or explained
> why it can't be feasible (which I don't believe the case for Xilinx).
> 
> > > 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).
> 
> There are three platforms in the past that used DT on x86.
> Latest one was dated ca. 2017 (SpreadTrum SoC with x86 core in it).
> 
> DT on x86 is a real thing, but very niche.
> 
> > > 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.
> > 
> > > > 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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Abdurrahman Hussain]

> On Jan 19, 2026, at 11:01 AM, Mark Brown <broonie@kernel.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" }
                        }
                    })
                }
            }

Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

[Michal Simek]

On 1/19/26 08:06, Abdurrahman Hussain via B4 Relay wrote:
> From: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> 
> Make the driver work on non-OF platforms.
> 
> Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> ---
>   drivers/spi/spi-xilinx.c | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
> index 4aa67fc61cb6..9fb1da2fcce4 100644
> --- a/drivers/spi/spi-xilinx.c
> +++ b/drivers/spi/spi-xilinx.c
> @@ -405,11 +405,11 @@ static int xilinx_spi_probe(struct platform_device *pdev)
>   		bits_per_word = pdata->bits_per_word;
>   		force_irq = pdata->force_irq;
>   	} else {
> -		of_property_read_u32(pdev->dev.of_node, "xlnx,num-ss-bits",
> -					  &num_cs);
> -		ret = of_property_read_u32(pdev->dev.of_node,
> -					   "xlnx,num-transfer-bits",
> -					   &bits_per_word);
> +		device_property_read_u32(&pdev->dev, "xlnx,num-ss-bits",
> +					 &num_cs);
> +		ret = device_property_read_u32(&pdev->dev,
> +					       "xlnx,num-transfer-bits",
> +					       &bits_per_word);
>   		if (ret)
>   			bits_per_word = 8;
>   	}
> 

Let's get back to this patch itself. I think you should send v4 version of this 
patch with updating commit message and saying that you are using generic device 
helper functions.

Thanks,
Michal

Re: (subset) [PATCH v3 0/3] spi: xilinx: switch to device properties and make IRQs optional

[Mark Brown]

On Mon, 19 Jan 2026 07:06:21 +0000, Abdurrahman Hussain wrote:
> Transition the driver to use the generic device property API.
> 
> Additionally, make interrupts optional to allow the driver to fall back
> to its existing polling mode on systems where interrupts are either missing
> or broken.
> 
> Abdurrahman Hussain (3):
>   spi: xilinx: use device property accessors.
>   spi: xilinx: make irq optional
>   spi: dt-bindings: xilinx: make interrupts optional
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/3] spi: dt-bindings: xilinx: make interrupts optional
      commit: b603500de20fbe15ee54580481c1df4212a4ec44
[2/3] spi: xilinx: make irq optional
      commit: c3608162a95a259c669cf9fdccf900782fa8d902

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: (subset) [PATCH v3 0/3] spi: xilinx: switch to device properties and make IRQs optional

[Michal Simek]

Hi Mark

On 1/20/26 20:23, Mark Brown wrote:
> On Mon, 19 Jan 2026 07:06:21 +0000, Abdurrahman Hussain wrote:
>> Transition the driver to use the generic device property API.
>>
>> Additionally, make interrupts optional to allow the driver to fall back
>> to its existing polling mode on systems where interrupts are either missing
>> or broken.
>>
>> Abdurrahman Hussain (3):
>>    spi: xilinx: use device property accessors.
>>    spi: xilinx: make irq optional
>>    spi: dt-bindings: xilinx: make interrupts optional
>>
>> [...]
> 
> Applied to
> 
>     https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
> 
> Thanks!
> 
> [1/3] spi: dt-bindings: xilinx: make interrupts optional
>        commit: b603500de20fbe15ee54580481c1df4212a4ec44

Are you sure about this one based on my discussion with Rob in past?
https://lore.kernel.org/all/20250605130331.GA2370690-robh@kernel.org/

I don't really mind but would be good to do it in a consistent way.

Thanks,
Michal

Re: (subset) [PATCH v3 0/3] spi: xilinx: switch to device properties and make IRQs optional

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Wed, Jan 21, 2026 at 09:15:02AM +0100, Michal Simek wrote:
> On 1/20/26 20:23, Mark Brown wrote:

> > [1/3] spi: dt-bindings: xilinx: make interrupts optional
> >        commit: b603500de20fbe15ee54580481c1df4212a4ec44

> Are you sure about this one based on my discussion with Rob in past?
> https://lore.kernel.org/all/20250605130331.GA2370690-robh@kernel.org/

> I don't really mind but would be good to do it in a consistent way.

My understanding was that the hardware doesn't require physically wiring
up the interrupt signal and can work in a polling only mode.  That's not
unknown for SPI controllers.  If the interrupt is actually a strong
requirement for the hardware (and especially if it is actually wired up
on this system) then we should drop these patches.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: (subset) [PATCH v3 0/3] spi: xilinx: switch to device properties and make IRQs optional

[Michal Simek]

On 1/21/26 12:39, Mark Brown wrote:
> On Wed, Jan 21, 2026 at 09:15:02AM +0100, Michal Simek wrote:
>> On 1/20/26 20:23, Mark Brown wrote:
> 
>>> [1/3] spi: dt-bindings: xilinx: make interrupts optional
>>>         commit: b603500de20fbe15ee54580481c1df4212a4ec44
> 
>> Are you sure about this one based on my discussion with Rob in past?
>> https://lore.kernel.org/all/20250605130331.GA2370690-robh@kernel.org/
> 
>> I don't really mind but would be good to do it in a consistent way.
> 
> My understanding was that the hardware doesn't require physically wiring
> up the interrupt signal and can work in a polling only mode.  That's not
> unknown for SPI controllers.  If the interrupt is actually a strong
> requirement for the hardware (and especially if it is actually wired up
> on this system) then we should drop these patches.

Keep in mind one thing. This is soft IP in fpga. If you connect in design IRQ 
you will have it. If you don't connect it, you don't have it.
 From HW perspective both of them are valid options.

It is up to everybody to decide if make sense to have IRQ logic or not.

This is the same for all soft IP cores which Xilinx is having.

 From SW perspective one OS can decide to use IRQ, another one not.

Then the question is if DT binding in Linux are targeting HW capability and 
configurations or describing Linux driver. I was said multiple times that it 
should describe HW not actually what Linux driver implements.

Thanks,
Michal

Re: (subset) [PATCH v3 0/3] spi: xilinx: switch to device properties and make IRQs optional

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Wed, Jan 21, 2026 at 01:26:04PM +0100, Michal Simek wrote:
> On 1/21/26 12:39, Mark Brown wrote:

> > My understanding was that the hardware doesn't require physically wiring
> > up the interrupt signal and can work in a polling only mode.  That's not
> > unknown for SPI controllers.  If the interrupt is actually a strong
> > requirement for the hardware (and especially if it is actually wired up
> > on this system) then we should drop these patches.

> Keep in mind one thing. This is soft IP in fpga. If you connect in design
> IRQ you will have it. If you don't connect it, you don't have it.
> From HW perspective both of them are valid options.

Yes, that's what I thought was happening - this means that it's valid to
not describe an interrupt for the device.  It's not like a primary clock
where the device simply won't function without it being wired up.

> Then the question is if DT binding in Linux are targeting HW capability and
> configurations or describing Linux driver. I was said multiple times that it
> should describe HW not actually what Linux driver implements.

Right, so if the hardware has an optional interrupt then the binding
should too.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]