Re: [PATCH RESEND 0/8] Resend LED patches

Re: [PATCH RESEND 0/8] Resend LED patches

[Arnd Bergmann]

On Mon, Dec 26, 2022, at 13:36, Pali Rohár wrote:
> Linus Walleij suggested me to send these patches to SoC tree [1]
> instead. So I'm doing it.
>
> This patch series contains LED patches which are on the linux-leds
> mailing list for a long time without any future movement. Could you
> please handle them here via SoC tree? Thanks.
>
> [1] - 
> https://lore.kernel.org/linux-leds/CACRpkdad6WDo7rGfa4MW8zz0mLXmcPHo+SEC-yLQnRz_kdrryA@mail.gmail.com/

I'm going through the backlog of patches sent to soc@kernel.org
and came across this series. While I don't mind taking these
patches through the soc tree in principle, it is important
that this is only done as an exception, and with all the
relevant parties on Cc.

In particular, the original series that you got no
feedback for did not include the arch/powerpc/ changes,
and I would assume those should go through the powerpc
tree anyway. We have recently decided to take
risc-v and loongarch dts changes through the soc
tree, and I don't mind doing it for powerpc as well
if the powerpc maintainers prefer that, but this is
not something we have even discussed so far.

I've added everyone to Cc on this mail, but please
resend the series once more so everyone has the patches,
and then we can decide who will pick up what.

    Arnd

>
> Marek Behún (3):
>   leds: turris-omnia: support HW controlled mode via private trigger
>   leds: turris-omnia: initialize multi-intensity to full
>   leds: turris-omnia: change max brightness from 255 to 1
>
> Pali Rohár (5):
>   dt-bindings: leds: register-bit-led: Add active-low property
>   leds: syscon: Implement support for active-low property
>   powerpc/85xx: DTS: Add CPLD definitions for P1021RDB Combo Board CPL
>     Design
>   dt-bindings: leds: Add cznic,turris1x-leds.yaml binding
>   leds: Add support for Turris 1.x LEDs
>
>  .../testing/sysfs-class-led-driver-turris1x   |  31 ++
>  .../bindings/leds/cznic,turris1x-leds.yaml    | 118 +++++
>  .../bindings/leds/register-bit-led.yaml       |   5 +
>  arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi    |  92 ++++
>  arch/powerpc/boot/dts/fsl/p1020mbg-pc_32b.dts |   6 +-
>  arch/powerpc/boot/dts/fsl/p1020mbg-pc_36b.dts |   6 +-
>  arch/powerpc/boot/dts/fsl/p1020rdb-pd.dts     |  44 +-
>  arch/powerpc/boot/dts/fsl/p1020utm-pc.dtsi    |  37 ++
>  arch/powerpc/boot/dts/fsl/p1020utm-pc_32b.dts |   4 +-
>  arch/powerpc/boot/dts/fsl/p1020utm-pc_36b.dts |   4 +-
>  arch/powerpc/boot/dts/fsl/p1021rdb-pc.dtsi    |  37 ++
>  arch/powerpc/boot/dts/fsl/p1021rdb-pc_32b.dts |   5 +-
>  arch/powerpc/boot/dts/fsl/p1021rdb-pc_36b.dts |   5 +-
>  arch/powerpc/boot/dts/fsl/p2020rdb-pc.dtsi    |  33 +-
>  drivers/leds/Kconfig                          |  10 +
>  drivers/leds/Makefile                         |   1 +
>  drivers/leds/leds-syscon.c                    |  14 +-
>  drivers/leds/leds-turris-1x.c                 | 474 ++++++++++++++++++
>  drivers/leds/leds-turris-omnia.c              |  46 +-
>  19 files changed, 945 insertions(+), 27 deletions(-)
>  create mode 100644 
> Documentation/ABI/testing/sysfs-class-led-driver-turris1x
>  create mode 100644 
> Documentation/devicetree/bindings/leds/cznic,turris1x-leds.yaml
>  create mode 100644 drivers/leds/leds-turris-1x.c
>
> -- 
> 2.20.1

Re: [PATCH RESEND 0/8] Resend LED patches

[Arnd Bergmann]

On Fri, Jan 20, 2023, at 18:15, Lee Jones wrote:
> On Fri, 20 Jan 2023, Arnd Bergmann wrote:

>> > Marek Behún (3):
>> >   leds: turris-omnia: support HW controlled mode via private trigger
>> >   leds: turris-omnia: initialize multi-intensity to full
>> >   leds: turris-omnia: change max brightness from 255 to 1
>> >
>> > Pali Rohár (5):
>> >   dt-bindings: leds: register-bit-led: Add active-low property
>> >   leds: syscon: Implement support for active-low property
>> >   powerpc/85xx: DTS: Add CPLD definitions for P1021RDB Combo Board CPL
>> >     Design
>> >   dt-bindings: leds: Add cznic,turris1x-leds.yaml binding
>> >   leds: Add support for Turris 1.x LEDs
>> >
>> >  .../testing/sysfs-class-led-driver-turris1x   |  31 ++
>> >  .../bindings/leds/cznic,turris1x-leds.yaml    | 118 +++++
>> >  .../bindings/leds/register-bit-led.yaml       |   5 +
>> >  arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi    |  92 ++++
>> >  arch/powerpc/boot/dts/fsl/p1020mbg-pc_32b.dts |   6 +-
>> >  arch/powerpc/boot/dts/fsl/p1020mbg-pc_36b.dts |   6 +-
>> >  arch/powerpc/boot/dts/fsl/p1020rdb-pd.dts     |  44 +-
>> >  arch/powerpc/boot/dts/fsl/p1020utm-pc.dtsi    |  37 ++
>> >  arch/powerpc/boot/dts/fsl/p1020utm-pc_32b.dts |   4 +-
>> >  arch/powerpc/boot/dts/fsl/p1020utm-pc_36b.dts |   4 +-
>> >  arch/powerpc/boot/dts/fsl/p1021rdb-pc.dtsi    |  37 ++
>> >  arch/powerpc/boot/dts/fsl/p1021rdb-pc_32b.dts |   5 +-
>> >  arch/powerpc/boot/dts/fsl/p1021rdb-pc_36b.dts |   5 +-
>> >  arch/powerpc/boot/dts/fsl/p2020rdb-pc.dtsi    |  33 +-
>
>> >  drivers/leds/Kconfig                          |  10 +
>> >  drivers/leds/Makefile                         |   1 +
>> >  drivers/leds/leds-syscon.c                    |  14 +-
>> >  drivers/leds/leds-turris-1x.c                 | 474 ++++++++++++++++++
>> >  drivers/leds/leds-turris-omnia.c              |  46 +-
>
> If everyone is convinced that applying these drivers is the correct
> thing to do, I'd be happy to (rather) take them via LEDs.

Ok, thanks. I had not actually looked at the patches until today.
They were in the soc tree backlog but appeared to be misplaced
there until I read the  0/10 message text.

Looking at it now, I see:

- patches 1 and 2 seem obvious and have been reviewed by
  others already

- patch 3 is for arch/powerpc and should get merged through
  there if there are no objections to the binding in patch 4.

- patch 5 is the big driver patch, with a Reviewed-by tag
  from Marek Behún, who is the author of the last three patches.
  An earlier version of this patch was sent in June and got
  a few Acks and detailed feedback from Andy [1], but he's also
  not on Cc, and I don't know if his comments are all resolved
  in this version.

- Patches 6, 7 and 8 all seem simple LED subsystem patches,
  they just need review from you in order to get applied.
  These are also missing a Signed-off-by from the submitter
  in addition to the author in order to be applied.
  
      Arnd

[1] https://lore.kernel.org/all/CAHp75Vcr6o2rm+T6Tr8sS4VXCLVHtmLPWy-njOKAvO4AcZoW=A@mail.gmail.com/

Re: [PATCH RESEND 0/8] Resend LED patches

[Linus Walleij]

On Fri, Jan 20, 2023 at 6:15 PM Lee Jones <lee@kernel.org> wrote:

> If everyone is convinced that applying these drivers is the correct
> thing to do, I'd be happy to (rather) take them via LEDs.

Oh you are co-maintainer of the LED subsystem since a month!

Sadly this series stalled way before that, so that's why we didn't notice.

By all means, pick it up!

Yours,
Linus Walleij

Re: [PATCH RESEND 1/8] dt-bindings: leds: register-bit-led: Add active-low property

[Linus Walleij]

On Thu, Feb 23, 2023 at 5:48 PM Pali Rohár <pali@kernel.org> wrote:
> On Thursday 23 February 2023 14:22:52 Lee Jones wrote:
> > On Fri, 27 Jan 2023, Lee Jones wrote:
> >
> > > On Mon, 26 Dec 2022, Pali Rohár wrote:
> > >
> > > > Allow to define inverted logic (0 - enable LED, 1 - disable LED) via
> > > > active-low property.
> > > >
> > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > > > ---
> > > >  Documentation/devicetree/bindings/leds/register-bit-led.yaml | 5 +++++
> > > >  1 file changed, 5 insertions(+)
> > >
> > > Needs a DT Ack (now Cc:ed)
> >
> > I can't do anything with this set until we have a DT Ack.
> >
> > If you don't receive one soon, I'd suggest resending the set again with
> > all of the DT people on Cc that it should have been sent to in the first
> > place.
>
> (Re)Sending one email multiple times is against email etiquette,
> moreover it is spam technique and reason for marking sender on the
> blacklist.

No problem on the kernel mailing lists actually, we love to mail
bomb each other here. Yeah maybe we are a bit weird :/

> Moreover I have already sent it more than one time. DT people are known
> to not respond to patches and pull requests and I have no motivation to
> send reminder emails for them for more than half of year.
>
> So I would suggest to not send emails to people who just do not want to
> receive or read emails. It is logical reaction.
>
> This patch is here for more than 6 months, so I do not see reason why to
> wait for Godot. Rather move forward than stepping at the same position.

I understand that it is annoying.

In my experience Krzysztof and Rob (now added on To) are usually
quite responsive and helpful, so something must have made them
miss it I think.

As subsystem maintainer, if the DT reviewers haven't said anything
in ~2 weeks I tend to sanity check the binding as best I can and then
merge it. The bigger and more complex it is the more hesitant I get to
do this...

Yours,
Linus Walleij

Re: [PATCH RESEND 1/8] dt-bindings: leds: register-bit-led: Add active-low property

[Krzysztof Kozlowski]

On 23/02/2023 21:59, Linus Walleij wrote:
> On Thu, Feb 23, 2023 at 5:48 PM Pali Rohár <pali@kernel.org> wrote:
>> On Thursday 23 February 2023 14:22:52 Lee Jones wrote:
>>> On Fri, 27 Jan 2023, Lee Jones wrote:
>>>
>>>> On Mon, 26 Dec 2022, Pali Rohár wrote:
>>>>
>>>>> Allow to define inverted logic (0 - enable LED, 1 - disable LED) via
>>>>> active-low property.
>>>>>
>>>>> Signed-off-by: Pali Rohár <pali@kernel.org>
>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/leds/register-bit-led.yaml | 5 +++++
>>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> Needs a DT Ack (now Cc:ed)
>>>
>>> I can't do anything with this set until we have a DT Ack.
>>>
>>> If you don't receive one soon, I'd suggest resending the set again with
>>> all of the DT people on Cc that it should have been sent to in the first
>>> place.
>>
>> (Re)Sending one email multiple times is against email etiquette,
>> moreover it is spam technique and reason for marking sender on the
>> blacklist.
> 
> No problem on the kernel mailing lists actually, we love to mail
> bomb each other here. Yeah maybe we are a bit weird :/
> 
>> Moreover I have already sent it more than one time. DT people are known
>> to not respond to patches and pull requests and I have no motivation to
>> send reminder emails for them for more than half of year.

Is this a joke? You got here response within one day!

Sent: 18th of August
Reviewed-by: 19th of August

https://lore.kernel.org/all/f635d5a7-6817-cd62-e395-63e346775716@linaro.org/

You ignored the tag and then ignored the process and not Cc'ed us. Yet
you complain that someone did not respond to your emails. Really?


>>
>> So I would suggest to not send emails to people who just do not want to
>> receive or read emails. It is logical reaction.
>>
>> This patch is here for more than 6 months, so I do not see reason why to
>> wait for Godot. Rather move forward than stepping at the same position.
> 
> I understand that it is annoying.
> 
> In my experience Krzysztof and Rob (now added on To) are usually
> quite responsive and helpful, so something must have made them
> miss it I think.
> 
> As subsystem maintainer, if the DT reviewers haven't said anything
> in ~2 weeks I tend to sanity check the binding as best I can and then
> merge it. The bigger and more complex it is the more hesitant I get to
> do this...

Yeah... this patch was never sent to us, thus regardless how hard we
work, it would be quite difficult to answer emails which we never received.

Best regards,
Krzysztof