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
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
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?
> 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.
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?
> 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
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?
> 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
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.
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
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.
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
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.
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
+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
> 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
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.
> 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?
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.
> 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.
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.
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
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
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
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
> 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
> 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
> 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" }
}
})
}
}
© 2016 - 2026 Red Hat, Inc.