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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a3fcef3a-d1e9-4b46-b114-3a82575e052e@amd.com>
Date: Mon, 19 Jan 2026 20:17:46 +0100
From: Michal Simek <michal.simek@....com>
To: Mark Brown <broonie@...nel.org>
Cc: Abdurrahman Hussain <abdurrahman@...thop.ai>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-spi@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

On 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