> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> Sent: Tuesday, July 19, 2022 3:49 PM
> To: Shenwei Wang <shenwei.wang@xxxxxxx>; Rob Herring
> >>>>>>> +<dt-bindings/firmware/imx/rsrc.h>
> >>>>>>> +#include <dt-bindings/gpio/gpio.h> #include
> >>>>>>> +<dt-bindings/interrupt-controller/arm-gic.h>
> >>>>>>> +#include <dt-bindings/input/input.h> #include
> >>>>>>> +<dt-bindings/pinctrl/pads-imx8dxl.h>
> >>>>>>> +#include <dt-bindings/thermal/thermal.h>
> >>>>>>> +
> >>>>>>> +/ {
> >>>>>>> + interrupt-parent = <&gic>;
> >>>>>>> + #address-cells = <2>;
> >>>>>>> + #size-cells = <2>;
> >>>>>>> +
> >>>>>>> + aliases {
> >>>>>>> + ethernet0 = &fec1;
> >>>>>>> + ethernet1 = &eqos;
> >>>>>>> + gpio0 = &lsio_gpio0;
> >>>>>>> + gpio1 = &lsio_gpio1;
> >>>>>>> + gpio2 = &lsio_gpio2;
> >>>>>>> + gpio3 = &lsio_gpio3;
> >>>>>>> + gpio4 = &lsio_gpio4;
> >>>>>>> + gpio5 = &lsio_gpio5;
> >>>>>>> + gpio6 = &lsio_gpio6;
> >>>>>>> + gpio7 = &lsio_gpio7;> + i2c2 = &i2c2;
> >>>>>>> + i2c3 = &i2c3;
> >>>>>>
> >>>>>> Board aliases, not SoC.
> >>>>>
> >>>>> We take these as the SoC aliases because we want to have the same
> >>>>> alias for
> >>>> the specific IP instance independent of the board design. All the
> >>>> i.mx SoCs use the same rule.
> >>>>
> >>>> UART, most likely also I2C and SPI are board design dependent. Just
> >>>> because error was made in several other files, it is not a reason
> >>>> to make it again, so the last argument is irrelevant.
> >>>>
> >>>
> >>> The SoC alias here can give a specific IP module a uniform device
> >>> file name
> >> independent of board design.
> >>
> >> It can, yet the specific alias depends on the usage of interfaces on
> >> the board, thus is board dependent.
> >
> > No matter how you use the interface on the board, you can still use the SoC
> alias by default. If a user doesn't like some of the default SoC alias, he can re-
> define those in his board alias. As I know, so far most of our customers just use
> the SoC alias with no changes.
>
> This is the argument of - let's put all possible stuff and many not existing devices
> like 10 different LCD panels to DTSI because customers can always enable what
> they want. Nope.
You are giving an improper example here. We are talking about the IP modules inside the SoC, but you involved the LCD panels which are outside the SoC. For LCD panels, you should define them in the board level for sure.
...
>
> >
> >>
> >>
> > There is nothing wrong to have a SoC alias by default if those default aliases
> are most commonly accepted in the real products. And this choice doesn't
> prevent a user to have a customized board alias if he wants. This is a more
> flexible solution so far if you couldn't point out a concrete disadvantage.
>
> Same misleading argument - putting not existing stuff to DTSI is not advantage
> and does not give flexibility. DTSI should reflect what SoC provides and aliases
> should represent what is available to the user, e.g. via board connectors. Adding
> 10 aliases out of which 9 are for
> *disabled* elements contradicts it.
We give a default SoC alias because most of the users will take the alias as is. This would make the future support more clearer and much easier. When we talk about the "/dev/ttyLP1", it is always LPUART1, the "/dev/i2c-2" is always i2c2 in SoC.
>
> Again, the same as clock-frequency, NXP is not special to receive some type of
> exceptions. It seems you want your DTS to be treated differently, but this is not
> how upstream process looks like.
I don't want to be treated differently. What I did for the clock part is just following the upstreaming ones like i.mx8qxp, i.mx8mm, etc. I am actually looking for a consistent rule for this part.
Thanks,
Shenwei
>
> Best regards,
> Krzysztof
