RE: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support

RE: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support

[Shenwei Wang]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Monday, July 18, 2022 7:48 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
> <robh+dt@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> 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@linaro.org>
> >> Sent: Thursday, July 14, 2022 6:44 AM
> >> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
> >> <robh+dt@kernel.org>; Krzysztof Kozlowski
> >> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
> >> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> >> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
> >> Cc: dl-linux-imx <linux-imx@nxp.com>
> >> 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.  Can you please let me know what problems are discovered with the SoC alias taking the UART as an example?

Thanks
Shenwei


> 
> Best regards,
> Krzysztof

Re: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support

[Krzysztof Kozlowski]

On 18/07/2022 21:08, Shenwei Wang wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> Sent: Monday, July 18, 2022 7:48 AM
>> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
>> <robh+dt@kernel.org>; Krzysztof Kozlowski
>> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
>> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
>> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
>> Cc: dl-linux-imx <linux-imx@nxp.com>
>> 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@linaro.org>
>>>> Sent: Thursday, July 14, 2022 6:44 AM
>>>> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
>>>> <robh+dt@kernel.org>; Krzysztof Kozlowski
>>>> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
>>>> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
>>>> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
>>>> 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.


>  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://lore.kernel.org/linux-rockchip/CAK8P3a25iYksubCnQb1-e5yj=crEsK37RB9Hn4ZGZMwcVVrG7g@mail.gmail.com/


Best regards,
Krzysztof

RE: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support

[Shenwei Wang]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Tuesday, July 19, 2022 1:34 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
> <robh+dt@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; devicetree@vger.kernel.org
> 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@linaro.org>
> >> Sent: Monday, July 18, 2022 7:48 AM
> >> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
> >> <robh+dt@kernel.org>; Krzysztof Kozlowski
> >> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
> >> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> >> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
> >> Cc: dl-linux-imx <linux-imx@nxp.com>
> >> 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@linaro.org>
> >>>> Sent: Thursday, July 14, 2022 6:44 AM
> >>>> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
> >>>> <robh+dt@kernel.org>; Krzysztof Kozlowski
> >>>> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo
> >>>> <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
> >>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Peng Fan
> >>>> <peng.fan@nxp.com>
> >>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> >>>> 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&amp;data=05
> %7C01%7Cshenwei.wang%40nxp.com%7C2b0eb5df69464b445b5d08da6950a8
> 83%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6379380923851874
> 99%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=v45G22t
> TdVszPMb3ok4EAyLgFnzz%2Fj0U4QZMTFjpZ%2FI%3D&amp;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

Re: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support

[Krzysztof Kozlowski]

On 19/07/2022 21:13, Shenwei Wang wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> Sent: Tuesday, July 19, 2022 1:34 AM
>> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
>> <robh+dt@kernel.org>; Krzysztof Kozlowski
>> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
>> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
>> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
>> Cc: dl-linux-imx <linux-imx@nxp.com>; devicetree@vger.kernel.org
>> 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@linaro.org>
>>>> Sent: Monday, July 18, 2022 7:48 AM
>>>> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
>>>> <robh+dt@kernel.org>; Krzysztof Kozlowski
>>>> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
>>>> Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
>>>> <kernel@pengutronix.de>; Peng Fan <peng.fan@nxp.com>
>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
>>>> 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@linaro.org>
>>>>>> Sent: Thursday, July 14, 2022 6:44 AM
>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>; Rob Herring
>>>>>> <robh+dt@kernel.org>; Krzysztof Kozlowski
>>>>>> <krzysztof.kozlowski+dt@linaro.org>; Shawn Guo
>>>>>> <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Peng Fan
>>>>>> <peng.fan@nxp.com>
>>>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
>>>>>> 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.

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.

> 
>>
>>
>>>  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&amp;data=05
>> %7C01%7Cshenwei.wang%40nxp.com%7C2b0eb5df69464b445b5d08da6950a8
>> 83%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6379380923851874
>> 99%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=v45G22t
>> TdVszPMb3ok4EAyLgFnzz%2Fj0U4QZMTFjpZ%2FI%3D&amp;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.

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.

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.

Best regards,
Krzysztof

RE: [EXT] Re: [PATCH 1/3] arm64: dts: imx: add imx8dxl support

[Shenwei Wang]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Tuesday, July 19, 2022 3:49 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>; 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