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@a00a0000 {
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@a00a0000" 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@a00a0000" 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?
