Message-ID: <30944fda-6d18-4fc1-8c73-bcda4814a417@freemail.hu>
Date: Sun, 2 Jun 2024 17:31:10 +0200
From: Szőke Benjamin <egyszeregy@...email.hu>
To: Mark Brown <broonie@...nel.org>
Cc: linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] spidev: Introduce "linux,spidev-name" property for
 device tree of spidev.

2024. 05. 20. 22:14 keltezéssel, Mark Brown írta:
> On Mon, May 20, 2024 at 07:20:12PM +0200, Szőke Benjamin wrote:
> 
>> So, in Yocto project build system point of view the best, if any Machine
>> specific settings is stored in the device tree files of the target machine
>> in driver levels/config, because it will be deterministic in 100% sure and
>> it will be nicely separated from the SW meta layers which may not contains
>> any machine specific hacking with udev and so on.
> 
> Given that with Yocto you're building a full system image it's not
> super obvious to me that it is particularly harder to ship udev rules in
> the image as opposed to modifying the DT.  It's a little more annoying
> but not drastically so and it's not creating a burden on the ABI for
> something that's mainly used within a vertically integrated software
> stack.
> 

In Yocto and Buildroot it is harder and more ugly to provide MACHINE specific 
settings in a rootfs config files than define it in the machine specific .dts 
and .dtsi files because they are separated in meta-layers for SW recipes and HW 
related machine recipes.

As i know udev is much older than device-tree in Linux kernel history. For 
embedded Linux image maintaining/developing for ARM, RISC-V etc. to solve this 
kind of features/issues is more elegant to do in device-tree than with udev, 
moreover for an embedded Linux developer it is more familiar to do in 
device-tree then udev.

I spent 3-4 days to understand udev rules files and i tried to do it via udev, 
but i gave up it due to it complexity and incomplete documentation about it.

axi_quad_spi_0: axi_quad_spi@...a0000 {
     bits-per-word = <8>;
     clock-names = "ext_spi_clk", "s_axi_aclk";
     clocks = <&zynqmp_clk 71>, <&zynqmp_clk 71>;
     compatible = "xlnx,axi-quad-spi-3.2", "xlnx,xps-spi-2.00.a";
     fifo-size = <16>;
     interrupt-names = "ip2intc_irpt";
     interrupt-parent = <&gic>;
     interrupts = <0 106 1>;
     num-cs = <0x1>;
     reg = <0x0 0xa00a0000 0x0 0x10000>;
     xlnx,num-ss-bits = <0x1>;
     xlnx,spi-mode = <0>;

     #address-cells = <1>;
     #size-cells = <0>;

     spidev@0 {
         reg = <0>;
         compatible = "rohm,dh2228fv";
         spi-max-frequency = <1000000>;

         // via my kernel patch -> /dev/spidev-mysensor
         // linux,spidev-name = "mysensor";
     };
};

As i understand "axi_quad_spi@...a0000" can be mapped via udev to a custom 
symlink name but in a new adaptive SoC HWs like AMD ZynqMP, Intel Stratix, 
Microchip PolarFire Soc etc. it is not possible and not good solution because 
this axi reg address can be different and become to non-deterministic in day to 
next when there is a new PL FW update for their FPGA part in the silicon.

What udev rules have to use for it if you say it can be perfectly done via udev 
and "axi_quad_spi@...a0000" cannot be used for making this rule?

>> DT binding would need to be documented later in a separated patch as a
>> guideline mentioned it in Linux repo.
> 
> No, that needs to happen along with the code change.

The official documentation says totally different:
"The Documentation/ and include/dt-bindings/ portion of the patch should be a 
separate patch. ..."

https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/submitting-patches.rst

By the way where can i find .yml or .txt dt-bindings documentation of spidev driver?

Powered by blists - more mailing lists