[PATCH] ARM: dts: microchip: Rename node, sub-node, and clean up spacing

claudiu beznea claudiu.beznea at tuxon.dev
Thu Aug 8 23:29:19 PDT 2024


Hi, Andrei,

On 08.08.2024 17:25, Andrei.Simion at microchip.com wrote:
>>> diff --git a/arch/arm/boot/dts/microchip/at91sam9g25-gardena-smart-gateway.dts b/arch/arm/boot/dts/microchip/at91sam9g25-gardena-smart-gateway.dts
>>> index af70eb8a3a02..60560e4c1696 100644
>>> --- a/arch/arm/boot/dts/microchip/at91sam9g25-gardena-smart-gateway.dts
>>> +++ b/arch/arm/boot/dts/microchip/at91sam9g25-gardena-smart-gateway.dts
>>> @@ -37,71 +37,71 @@ button {
>>>       leds {
>>>               compatible = "gpio-leds";
>>>
>>> -             power_blue {
>>> +             led-0 {
>>>                       label = "smartgw:power:blue";
>>>                       gpios = <&pioC 21 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             power_green {
>>> +             led-1 {
>>>                       label = "smartgw:power:green";
>>>                       gpios = <&pioC 20 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "on";
>>>               };
>>>
>>> -             power_red {
>>> +             led-2 {
>>>                       label = "smartgw:power:red";
>>>                       gpios = <&pioC 19 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             radio_blue {
>>> +             led-3 {
>>>                       label = "smartgw:radio:blue";
>>>                       gpios = <&pioC 18 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             radio_green {
>>> +             led-4 {
>>>                       label = "smartgw:radio:green";
>>>                       gpios = <&pioC 17 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             radio_red {
>>> +             led-5 {
>>>                       label = "smartgw:radio:red";
>>>                       gpios = <&pioC 16 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             internet_blue {
>>> +             led-6 {
>>>                       label = "smartgw:internet:blue";
>>>                       gpios = <&pioC 15 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             internet_green {
>>> +             led-7 {
>>>                       label = "smartgw:internet:green";
>>>                       gpios = <&pioC 14 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             internet_red {
>>> +             led-8 {
>>>                       label = "smartgw:internet:red";
>>>                       gpios = <&pioC 13 GPIO_ACTIVE_HIGH>;
>>>                       default-state = "off";
>>>               };
>>>
>>> -             heartbeat {
>>> +             led-9 {
>>>                       label = "smartgw:heartbeat";
>>>                       gpios = <&pioB 8 GPIO_ACTIVE_HIGH>;
>>>                       linux,default-trigger = "heartbeat";
>>>               };
>>>
>>> -             pb18 {
>>> +             led-pb18 {
>>>                       status = "disabled";
>>>               };
>>>
>>> -             pd21 {
>>> +             led-pd21 {
>> Why used led-<old-label> for some leds and led-<integer> for other? Valid
>> for other files.
>>
> I could have done either rule led-<old-label> or led-<integer> 
> but we ended up with the old label being quite long.
> So, I use led-<integer> when <old-label> is too long.
> I don't think it was the best rule to rename.
> In your opinion, how would it be correct to rename these subnodes?

Keeping old label is OK. FYI, these particular changes were already
integrated with old labels being kept. See
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git/commit/?id=b39c457205d0a3513fed1c3863e7cf9b6d72bf86

Thank you,
Claudiu Beznea


> 
> 
> PS: It is a problem on our side with the mail server. The e-mails may not arrive on the linux-arm-kernel mailing list.
> 
> BR,
> Andrei Simion



More information about the linux-arm-kernel mailing list