On 19/07/2022 21:13, Shenwei Wang wrote:
>
>
>> -----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.
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&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.
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
