> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> Sent: Tuesday, July 19, 2022 1:34 AM
> To: Shenwei Wang <shenwei.wang@xxxxxxx>; Rob Herring
> <robh+dt@xxxxxxxxxx>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@xxxxxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>;
> Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Pengutronix Kernel Team
> <kernel@xxxxxxxxxxxxxx>; Peng Fan <peng.fan@xxxxxxx>
> Cc: dl-linux-imx <linux-imx@xxxxxxx>; devicetree@xxxxxxxxxxxxxxx
> Subject: Re: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support
>
> Caution: EXT Email
>
> On 18/07/2022 21:08, Shenwei Wang wrote:
> >
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> >> Sent: Monday, July 18, 2022 7:48 AM
> >> To: Shenwei Wang <shenwei.wang@xxxxxxx>; Rob Herring
> >> <robh+dt@xxxxxxxxxx>; Krzysztof Kozlowski
> >> <krzysztof.kozlowski+dt@xxxxxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>;
> >> Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Pengutronix Kernel Team
> >> <kernel@xxxxxxxxxxxxxx>; Peng Fan <peng.fan@xxxxxxx>
> >> Cc: dl-linux-imx <linux-imx@xxxxxxx>
> >> Subject: Re: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl
> >> support
> >>
> >> Caution: EXT Email
> >>
> >> On 15/07/2022 20:04, Shenwei Wang wrote:
> >>> Hi Krzysztorf
> >>>
> >>>> -----Original Message-----
> >>>> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> >>>> Sent: Thursday, July 14, 2022 6:44 AM
> >>>> To: Shenwei Wang <shenwei.wang@xxxxxxx>; Rob Herring
> >>>> <robh+dt@xxxxxxxxxx>; Krzysztof Kozlowski
> >>>> <krzysztof.kozlowski+dt@xxxxxxxxxx>; Shawn Guo
> >>>> <shawnguo@xxxxxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>;
> >>>> Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx>; Peng Fan
> >>>> <peng.fan@xxxxxxx>
> >>>> Cc: dl-linux-imx <linux-imx@xxxxxxx>
> >>>> Subject: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support
> >>>>
> >>>> Caution: EXT Email
> >>>>
> >>>>> +<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.
>
>
> > Can you please let me know what problems are discovered with the SoC alias
> taking the UART as an example?
>
> Arnd explained it nicely:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kern
> el.org%2Flinux-rockchip%2FCAK8P3a25iYksubCnQb1-
> e5yj%3DcrEsK37RB9Hn4ZGZMwcVVrG7g%40mail.gmail.com%2F&data=05
> %7C01%7Cshenwei.wang%40nxp.com%7C2b0eb5df69464b445b5d08da6950a8
> 83%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6379380923851874
> 99%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v45G22t
> TdVszPMb3ok4EAyLgFnzz%2Fj0U4QZMTFjpZ%2FI%3D&reserved=0
>
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.
>
> Best regards,
> Krzysztof
