Re: [PATCH 5/7] dt-bindings: trivial-devices: Add IOT2050 Arduino SPI connector

[Jan Kiszka <jan.kiszka@siemens.com>]

On 30.10.23 17:43, Rob Herring wrote:
> On Fri, Oct 27, 2023 at 03:34:36PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> On the Siemens IOT2050 devices, the SPI controller wired to the Arduino
>> connector is normally driven by userspace. Introduce a binding for use
>> by spidev.
> 
> What's spidev? Not a h/w device...
> 
> 
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
>> index 430a814f64a5..01b9f36afcd5 100644
>> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
>> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
>> @@ -349,6 +349,8 @@ properties:
>>            - silabs,si3210
>>              # Relative Humidity and Temperature Sensors
>>            - silabs,si7020
>> +            # Siemens IOT2050: SPI interface on Arduino connector
>> +          - siemens,iot2050-arduino-spi
> 
> How is this specific to your board? Presumably, an 'Arduino connector' 
> is a somewhat standard interface, right? If every board with an Arduino 
> connector adds a compatible, this doesn't scale.
> 
> A connector is what you should be describing, but I imagine it is not 
> just SPI. Here's some past discussions[1][2] on the need for connector 
> bindings.

Right, we are not alone with this modelling problem on our board. The
code talking to the SPI devices is inside applications, the kernel just
needs to pave the way to the interface. However, you can't define that
path without bending of the DT. This is specific to at least SPI, maybe
some other buses without probing as well.

If this were a PCI device, no problem: tell vfio-pci or uio_pci_generic
to be responsible as well (add IDs on the fly), bind bind any of them
and then let userspace handle things. Same why to go back to an
in-kernel driver. No bothering of the DT regarding how the final device
is driven.

Jan

-- 
Siemens AG, Technology
Linux Expert Center