[0/3] add dt configuration for dp83867 led modes

  This series adds a dt-prop ti,led-modes to configure dp83867 PHY led
modes, adds the code to implement it, and updates some board dt files
to use the new property.

Tim Harvey (3):
  dt-bindings: net: phy: dp83867: add LED mode property
  net: phy: dp83867: add LED mode configuration via dt
  arm64: dts: imx8m*-venice: add dp83867 PHY LED mode configuration

 .../devicetree/bindings/net/ti,dp83867.yaml   |  6 ++++
 .../dts/freescale/imx8mm-venice-gw700x.dtsi   |  6 ++++
 .../dts/freescale/imx8mm-venice-gw7902.dts    |  6 ++++
 .../dts/freescale/imx8mn-venice-gw7902.dts    |  6 ++++
 drivers/net/phy/dp83867.c                     | 32 +++++++++++++++++--
 include/dt-bindings/net/ti-dp83867.h          | 16 ++++++++++
 6 files changed, 70 insertions(+), 2 deletions(-)
  

On Thu, Nov 17, 2022 at 04:15:45PM -0800, Tim Harvey wrote:
> This series adds a dt-prop ti,led-modes to configure dp83867 PHY led
> modes, adds the code to implement it, and updates some board dt files
> to use the new property.

Sorry, but NACK.

We need PHY leds to be controlled via /sys/class/leds. Everybody keeps
trying to add there own way to configure these things, rather than
have just one uniform way which all PHYs share.

     Andrew
  

On Thu, Nov 17, 2022 at 4:27 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Nov 17, 2022 at 04:15:45PM -0800, Tim Harvey wrote:
> > This series adds a dt-prop ti,led-modes to configure dp83867 PHY led
> > modes, adds the code to implement it, and updates some board dt files
> > to use the new property.
>
> Sorry, but NACK.
>
> We need PHY leds to be controlled via /sys/class/leds. Everybody keeps
> trying to add there own way to configure these things, rather than
> have just one uniform way which all PHYs share.
>
>      Andrew

Andrew,

I completely agree with you but I haven't seen how that can be done
yet. What support exists for a PHY driver to expose their LED
configuration to be used that way? Can you point me to an example?

Best Regards,

Tim
  

> Andrew,
> 
> I completely agree with you but I haven't seen how that can be done
> yet. What support exists for a PHY driver to expose their LED
> configuration to be used that way? Can you point me to an example?

Nobody has actually worked on this long enough to get code merged. e.g.
https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
https://lists.archive.carbon60.com/linux/kernel/3396223

This is probably the last attempt, which was not too far away from getting merged:
https://patches.linaro.org/project/linux-leds/cover/20220503151633.18760-1-ansuelsmth@gmail.com/

I seem to NACK a patch like yours every couple of months. If all that
wasted time was actually spent on a common framework, this would of
been solved years ago.

How important is it to you to control these LEDs? Enough to finish
this code and get it merged?

     Andrew
  

On Fri, Nov 18, 2022 at 5:11 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > Andrew,
> >
> > I completely agree with you but I haven't seen how that can be done
> > yet. What support exists for a PHY driver to expose their LED
> > configuration to be used that way? Can you point me to an example?
>
> Nobody has actually worked on this long enough to get code merged. e.g.
> https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
> https://lists.archive.carbon60.com/linux/kernel/3396223
>
> This is probably the last attempt, which was not too far away from getting merged:
> https://patches.linaro.org/project/linux-leds/cover/20220503151633.18760-1-ansuelsmth@gmail.com/
>
> I seem to NACK a patch like yours every couple of months. If all that
> wasted time was actually spent on a common framework, this would of
> been solved years ago.
>
> How important is it to you to control these LEDs? Enough to finish
> this code and get it merged?
>

Andrew,

Thanks for the links - the most recent attempt does look promising.
For whatever reason I don't have that series in my mail history so
it's not clear how I can respond to it.

Ansuel, are you planning on posting a v7 of 'Adds support for PHY LEDs
with offload triggers' [1]?

I'm not all that familiar with netdev led triggers. Is there a way to
configure the default offload blink mode via dt with your series? I
didn't quite follow how the offload function/blink-mode gets set.

Best Regards,

Tim
[1] https://patches.linaro.org/project/linux-leds/list/?submitter=10040
  

On Fri, Nov 18, 2022 at 11:57:00AM -0800, Tim Harvey wrote:
> On Fri, Nov 18, 2022 at 5:11 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > Andrew,
> > >
> > > I completely agree with you but I haven't seen how that can be done
> > > yet. What support exists for a PHY driver to expose their LED
> > > configuration to be used that way? Can you point me to an example?
> >
> > Nobody has actually worked on this long enough to get code merged. e.g.
> > https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
> > https://lists.archive.carbon60.com/linux/kernel/3396223
> >
> > This is probably the last attempt, which was not too far away from getting merged:
> > https://patches.linaro.org/project/linux-leds/cover/20220503151633.18760-1-ansuelsmth@gmail.com/
> >
> > I seem to NACK a patch like yours every couple of months. If all that
> > wasted time was actually spent on a common framework, this would of
> > been solved years ago.
> >
> > How important is it to you to control these LEDs? Enough to finish
> > this code and get it merged?
> >
> 
> Andrew,
> 
> Thanks for the links - the most recent attempt does look promising.
> For whatever reason I don't have that series in my mail history so
> it's not clear how I can respond to it.

apt-get install b4

> Ansuel, are you planning on posting a v7 of 'Adds support for PHY LEDs
> with offload triggers' [1]?
> 
> I'm not all that familiar with netdev led triggers. Is there a way to
> configure the default offload blink mode via dt with your series? I
> didn't quite follow how the offload function/blink-mode gets set.

The idea is that the PHY LEDs are just LEDs in the Linux LED
framework. So read Documentation/devicetree/bindings/leds/common.yaml.
The PHY should make use of these standard DT properties, including
linux,default-trigger.

	Andrew
  

On Sun, Nov 20, 2022 at 3:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Fri, Nov 18, 2022 at 11:57:00AM -0800, Tim Harvey wrote:
> > On Fri, Nov 18, 2022 at 5:11 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > > Andrew,
> > > >
> > > > I completely agree with you but I haven't seen how that can be done
> > > > yet. What support exists for a PHY driver to expose their LED
> > > > configuration to be used that way? Can you point me to an example?
> > >
> > > Nobody has actually worked on this long enough to get code merged. e.g.
> > > https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
> > > https://lists.archive.carbon60.com/linux/kernel/3396223
> > >
> > > This is probably the last attempt, which was not too far away from getting merged:
> > > https://patches.linaro.org/project/linux-leds/cover/20220503151633.18760-1-ansuelsmth@gmail.com/
> > >
> > > I seem to NACK a patch like yours every couple of months. If all that
> > > wasted time was actually spent on a common framework, this would of
> > > been solved years ago.
> > >
> > > How important is it to you to control these LEDs? Enough to finish
> > > this code and get it merged?
> > >
> >
> > Andrew,
> >
> > Thanks for the links - the most recent attempt does look promising.
> > For whatever reason I don't have that series in my mail history so
> > it's not clear how I can respond to it.
>
> apt-get install b4
>
> > Ansuel, are you planning on posting a v7 of 'Adds support for PHY LEDs
> > with offload triggers' [1]?
> >
> > I'm not all that familiar with netdev led triggers. Is there a way to
> > configure the default offload blink mode via dt with your series? I
> > didn't quite follow how the offload function/blink-mode gets set.
>
> The idea is that the PHY LEDs are just LEDs in the Linux LED
> framework. So read Documentation/devicetree/bindings/leds/common.yaml.
> The PHY should make use of these standard DT properties, including
> linux,default-trigger.
>
>         Andrew

Ansuel,

Are you planning on posting a v7 of 'Adds support for PHY LEDs with
offload triggers' [1]?

Best Regards,

Tim
[1] https://patches.linaro.org/project/linux-leds/list/?series=174704
  

On Thu, Dec 01, 2022 at 10:26:09AM -0800, Tim Harvey wrote:
> On Sun, Nov 20, 2022 at 3:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Fri, Nov 18, 2022 at 11:57:00AM -0800, Tim Harvey wrote:
> > > On Fri, Nov 18, 2022 at 5:11 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > > >
> > > > > Andrew,
> > > > >
> > > > > I completely agree with you but I haven't seen how that can be done
> > > > > yet. What support exists for a PHY driver to expose their LED
> > > > > configuration to be used that way? Can you point me to an example?
> > > >
> > > > Nobody has actually worked on this long enough to get code merged. e.g.
> > > > https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
> > > > https://lists.archive.carbon60.com/linux/kernel/3396223
> > > >
> > > > This is probably the last attempt, which was not too far away from getting merged:
> > > > https://patches.linaro.org/project/linux-leds/cover/20220503151633.18760-1-ansuelsmth@gmail.com/
> > > >
> > > > I seem to NACK a patch like yours every couple of months. If all that
> > > > wasted time was actually spent on a common framework, this would of
> > > > been solved years ago.
> > > >
> > > > How important is it to you to control these LEDs? Enough to finish
> > > > this code and get it merged?
> > > >
> > >
> > > Andrew,
> > >
> > > Thanks for the links - the most recent attempt does look promising.
> > > For whatever reason I don't have that series in my mail history so
> > > it's not clear how I can respond to it.
> >
> > apt-get install b4
> >
> > > Ansuel, are you planning on posting a v7 of 'Adds support for PHY LEDs
> > > with offload triggers' [1]?
> > >
> > > I'm not all that familiar with netdev led triggers. Is there a way to
> > > configure the default offload blink mode via dt with your series? I
> > > didn't quite follow how the offload function/blink-mode gets set.
> >
> > The idea is that the PHY LEDs are just LEDs in the Linux LED
> > framework. So read Documentation/devicetree/bindings/leds/common.yaml.
> > The PHY should make use of these standard DT properties, including
> > linux,default-trigger.
> >
> >         Andrew
> 
> Ansuel,
> 
> Are you planning on posting a v7 of 'Adds support for PHY LEDs with
> offload triggers' [1]?
> 
> Best Regards,
> 
> Tim
> [1] https://patches.linaro.org/project/linux-leds/list/?series=174704

I can consider that only if there is a real interest for it and would
love some help by the netdev team to actually have a review from the
leds team...

I tried multiple time to propose it but I never got a review... only a
review from an external guy that wanted to follow his idea in every way
possible with the only intention of applying his code (sorry to be rude
about that but i'm more than happy to recover the work and search for a
common solution)

So yes this is still in my TODO list but it would help if others can
tell me that they want to actually review it. That would put that
project on priority and I would recover and push a v7.
  

On Thu, Dec 1, 2022 at 10:31 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> On Thu, Dec 01, 2022 at 10:26:09AM -0800, Tim Harvey wrote:
> > On Sun, Nov 20, 2022 at 3:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > On Fri, Nov 18, 2022 at 11:57:00AM -0800, Tim Harvey wrote:
> > > > On Fri, Nov 18, 2022 at 5:11 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > > > >
> > > > > > Andrew,
> > > > > >
> > > > > > I completely agree with you but I haven't seen how that can be done
> > > > > > yet. What support exists for a PHY driver to expose their LED
> > > > > > configuration to be used that way? Can you point me to an example?
> > > > >
> > > > > Nobody has actually worked on this long enough to get code merged. e.g.
> > > > > https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
> > > > > https://lists.archive.carbon60.com/linux/kernel/3396223
> > > > >
> > > > > This is probably the last attempt, which was not too far away from getting merged:
> > > > > https://patches.linaro.org/project/linux-leds/cover/20220503151633.18760-1-ansuelsmth@gmail.com/
> > > > >
> > > > > I seem to NACK a patch like yours every couple of months. If all that
> > > > > wasted time was actually spent on a common framework, this would of
> > > > > been solved years ago.
> > > > >
> > > > > How important is it to you to control these LEDs? Enough to finish
> > > > > this code and get it merged?
> > > > >
> > > >
> > > > Andrew,
> > > >
> > > > Thanks for the links - the most recent attempt does look promising.
> > > > For whatever reason I don't have that series in my mail history so
> > > > it's not clear how I can respond to it.
> > >
> > > apt-get install b4
> > >
> > > > Ansuel, are you planning on posting a v7 of 'Adds support for PHY LEDs
> > > > with offload triggers' [1]?
> > > >
> > > > I'm not all that familiar with netdev led triggers. Is there a way to
> > > > configure the default offload blink mode via dt with your series? I
> > > > didn't quite follow how the offload function/blink-mode gets set.
> > >
> > > The idea is that the PHY LEDs are just LEDs in the Linux LED
> > > framework. So read Documentation/devicetree/bindings/leds/common.yaml.
> > > The PHY should make use of these standard DT properties, including
> > > linux,default-trigger.
> > >
> > >         Andrew
> >
> > Ansuel,
> >
> > Are you planning on posting a v7 of 'Adds support for PHY LEDs with
> > offload triggers' [1]?
> >
> > Best Regards,
> >
> > Tim
> > [1] https://patches.linaro.org/project/linux-leds/list/?series=174704
>
> I can consider that only if there is a real interest for it and would
> love some help by the netdev team to actually have a review from the
> leds team...
>
> I tried multiple time to propose it but I never got a review... only a
> review from an external guy that wanted to follow his idea in every way
> possible with the only intention of applying his code (sorry to be rude
> about that but i'm more than happy to recover the work and search for a
> common solution)
>
> So yes this is still in my TODO list but it would help if others can
> tell me that they want to actually review it. That would put that
> project on priority and I would recover and push a v7.
>
> --
>         Ansuel

Ansuel,

Considering Andrew is nak'ing any phy code to configure LED's until a
solution using via /sys/class/leds is provided I would say there is
real interest.

It seems to me that you got very positive feedback for this last
series. I would think if you submitted without RFC it would catch more
eyes as well.

Best Regards,

Tim
  

On Thu, Dec 01, 2022 at 10:35:46AM -0800, Tim Harvey wrote:
> On Thu, Dec 1, 2022 at 10:31 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > On Thu, Dec 01, 2022 at 10:26:09AM -0800, Tim Harvey wrote:
> > > On Sun, Nov 20, 2022 at 3:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > > >
> > > > On Fri, Nov 18, 2022 at 11:57:00AM -0800, Tim Harvey wrote:
> > > > > On Fri, Nov 18, 2022 at 5:11 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > > > > >
> > > > > > > Andrew,
> > > > > > >
> > > > > > > I completely agree with you but I haven't seen how that can be done
> > > > > > > yet. What support exists for a PHY driver to expose their LED
> > > > > > > configuration to be used that way? Can you point me to an example?
> > > > > >
> > > > > > Nobody has actually worked on this long enough to get code merged. e.g.
> > > > > > https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
> > > > > > https://lists.archive.carbon60.com/linux/kernel/3396223
> > > > > >
> > > > > > This is probably the last attempt, which was not too far away from getting merged:
> > > > > > https://patches.linaro.org/project/linux-leds/cover/20220503151633.18760-1-ansuelsmth@gmail.com/
> > > > > >
> > > > > > I seem to NACK a patch like yours every couple of months. If all that
> > > > > > wasted time was actually spent on a common framework, this would of
> > > > > > been solved years ago.
> > > > > >
> > > > > > How important is it to you to control these LEDs? Enough to finish
> > > > > > this code and get it merged?
> > > > > >
> > > > >
> > > > > Andrew,
> > > > >
> > > > > Thanks for the links - the most recent attempt does look promising.
> > > > > For whatever reason I don't have that series in my mail history so
> > > > > it's not clear how I can respond to it.
> > > >
> > > > apt-get install b4
> > > >
> > > > > Ansuel, are you planning on posting a v7 of 'Adds support for PHY LEDs
> > > > > with offload triggers' [1]?
> > > > >
> > > > > I'm not all that familiar with netdev led triggers. Is there a way to
> > > > > configure the default offload blink mode via dt with your series? I
> > > > > didn't quite follow how the offload function/blink-mode gets set.
> > > >
> > > > The idea is that the PHY LEDs are just LEDs in the Linux LED
> > > > framework. So read Documentation/devicetree/bindings/leds/common.yaml.
> > > > The PHY should make use of these standard DT properties, including
> > > > linux,default-trigger.
> > > >
> > > >         Andrew
> > >
> > > Ansuel,
> > >
> > > Are you planning on posting a v7 of 'Adds support for PHY LEDs with
> > > offload triggers' [1]?
> > >
> > > Best Regards,
> > >
> > > Tim
> > > [1] https://patches.linaro.org/project/linux-leds/list/?series=174704
> >
> > I can consider that only if there is a real interest for it and would
> > love some help by the netdev team to actually have a review from the
> > leds team...
> >
> > I tried multiple time to propose it but I never got a review... only a
> > review from an external guy that wanted to follow his idea in every way
> > possible with the only intention of applying his code (sorry to be rude
> > about that but i'm more than happy to recover the work and search for a
> > common solution)
> >
> > So yes this is still in my TODO list but it would help if others can
> > tell me that they want to actually review it. That would put that
> > project on priority and I would recover and push a v7.
> >
> > --
> >         Ansuel
> 
> Ansuel,
> 
> Considering Andrew is nak'ing any phy code to configure LED's until a
> solution using via /sys/class/leds is provided I would say there is
> real interest.
> 
> It seems to me that you got very positive feedback for this last
> series. I would think if you submitted without RFC it would catch more
> eyes as well.
> 

Well yes that's the fun part. netdev really liked the concept and how it
was implemented (and actually also liked the use of a dedicated trigger
instead of bloating the netdev trigger)

But I never got a review from LED team and that result in having the
patch stalled and never merged... But ok I will recover the work and
recheck/retest everything from the start hoping to get more traction
now...
  

> But I never got a review from LED team and that result in having the
> patch stalled and never merged... But ok I will recover the work and
> recheck/retest everything from the start hoping to get more traction
> now...

There are a few emails suggesting the LED team has disappeared, and
there are a lot of patches waiting to be merged. I think they were
asking GregKH if he could do something about this.

https://lore.kernel.org/netdev/Y3zQ5ZtAU4NL3hG4@smile.fi.intel.com/

I don't know if anything has changed since then.

Until this is solved, i don't think you will get much from the LED
people. Best you can get is more netdev reviews.

	Andrew
  

Hello Ansuel,

Am Donnerstag, 1. Dezember 2022, 19:38:36 CET schrieb Christian Marangi:
> On Thu, Dec 01, 2022 at 10:35:46AM -0800, Tim Harvey wrote:
> > On Thu, Dec 1, 2022 at 10:31 AM Christian Marangi <ansuelsmth@gmail.com> 
wrote:
> > > On Thu, Dec 01, 2022 at 10:26:09AM -0800, Tim Harvey wrote:
> > > > On Sun, Nov 20, 2022 at 3:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > > > > On Fri, Nov 18, 2022 at 11:57:00AM -0800, Tim Harvey wrote:
> > > > > > On Fri, Nov 18, 2022 at 5:11 AM Andrew Lunn <andrew@lunn.ch> 
wrote:
> > > > > > > > Andrew,
> > > > > > > > 
> > > > > > > > I completely agree with you but I haven't seen how that can be
> > > > > > > > done
> > > > > > > > yet. What support exists for a PHY driver to expose their LED
> > > > > > > > configuration to be used that way? Can you point me to an
> > > > > > > > example?
> > > > > > > 
> > > > > > > Nobody has actually worked on this long enough to get code
> > > > > > > merged. e.g.
> > > > > > > https://lore.kernel.org/netdev/20201004095852.GB1104@bug/T/
> > > > > > > https://lists.archive.carbon60.com/linux/kernel/3396223
> > > > > > > 
> > > > > > > This is probably the last attempt, which was not too far away
> > > > > > > from getting merged:
> > > > > > > https://patches.linaro.org/project/linux-leds/cover/20220503151
> > > > > > > 633.18760-1-ansuelsmth@gmail.com/
> > > > > > > 
> > > > > > > I seem to NACK a patch like yours every couple of months. If all
> > > > > > > that
> > > > > > > wasted time was actually spent on a common framework, this would
> > > > > > > of
> > > > > > > been solved years ago.
> > > > > > > 
> > > > > > > How important is it to you to control these LEDs? Enough to
> > > > > > > finish
> > > > > > > this code and get it merged?
> > > > > > 
> > > > > > Andrew,
> > > > > > 
> > > > > > Thanks for the links - the most recent attempt does look
> > > > > > promising.
> > > > > > For whatever reason I don't have that series in my mail history so
> > > > > > it's not clear how I can respond to it.
> > > > > 
> > > > > apt-get install b4
> > > > > 
> > > > > > Ansuel, are you planning on posting a v7 of 'Adds support for PHY
> > > > > > LEDs
> > > > > > with offload triggers' [1]?
> > > > > > 
> > > > > > I'm not all that familiar with netdev led triggers. Is there a way
> > > > > > to
> > > > > > configure the default offload blink mode via dt with your series?
> > > > > > I
> > > > > > didn't quite follow how the offload function/blink-mode gets set.
> > > > > 
> > > > > The idea is that the PHY LEDs are just LEDs in the Linux LED
> > > > > framework. So read
> > > > > Documentation/devicetree/bindings/leds/common.yaml.
> > > > > The PHY should make use of these standard DT properties, including
> > > > > linux,default-trigger.
> > > > > 
> > > > >         Andrew
> > > > 
> > > > Ansuel,
> > > > 
> > > > Are you planning on posting a v7 of 'Adds support for PHY LEDs with
> > > > offload triggers' [1]?
> > > > 
> > > > Best Regards,
> > > > 
> > > > Tim
> > > > [1] https://patches.linaro.org/project/linux-leds/list/?series=174704
> > > 
> > > I can consider that only if there is a real interest for it and would
> > > love some help by the netdev team to actually have a review from the
> > > leds team...
> > > 
> > > I tried multiple time to propose it but I never got a review... only a
> > > review from an external guy that wanted to follow his idea in every way
> > > possible with the only intention of applying his code (sorry to be rude
> > > about that but i'm more than happy to recover the work and search for a
> > > common solution)
> > > 
> > > So yes this is still in my TODO list but it would help if others can
> > > tell me that they want to actually review it. That would put that
> > > project on priority and I would recover and push a v7.
> > > 
> > > --
> > > 
> > >         Ansuel
> > 
> > Ansuel,
> > 
> > Considering Andrew is nak'ing any phy code to configure LED's until a
> > solution using via /sys/class/leds is provided I would say there is
> > real interest.
> > 
> > It seems to me that you got very positive feedback for this last
> > series. I would think if you submitted without RFC it would catch more
> > eyes as well.
> 
> Well yes that's the fun part. netdev really liked the concept and how it
> was implemented (and actually also liked the use of a dedicated trigger
> instead of bloating the netdev trigger)
> 
> But I never got a review from LED team and that result in having the
> patch stalled and never merged... But ok I will recover the work and
> recheck/retest everything from the start hoping to get more traction
> now...

I was just trying to use your RFC patchset from May 2022 for dp83867 as well, 
with some success at least.
I have some comments, fixes and uncertainties. How do you want to progress? 
Resend so I can rebase on that? Anyway, put me on CC.

Best regards,
Alexander
  

On 07/12/2022 11.40, Alexander Stein wrote:
> Hello Ansuel,
> 
> Am Donnerstag, 1. Dezember 2022, 19:38:36 CET schrieb Christian Marangi:

>>> Considering Andrew is nak'ing any phy code to configure LED's until a
>>> solution using via /sys/class/leds is provided I would say there is
>>> real interest.
>>>
>>> It seems to me that you got very positive feedback for this last
>>> series. I would think if you submitted without RFC it would catch more
>>> eyes as well.
>>
>> Well yes that's the fun part. netdev really liked the concept and how it
>> was implemented (and actually also liked the use of a dedicated trigger
>> instead of bloating the netdev trigger)
>>
>> But I never got a review from LED team and that result in having the
>> patch stalled and never merged... But ok I will recover the work and
>> recheck/retest everything from the start hoping to get more traction
>> now...
> 
> I was just trying to use your RFC patchset from May 2022 for dp83867 as well, 
> with some success at least.
> I have some comments, fixes and uncertainties. How do you want to progress? 
> Resend so I can rebase on that? Anyway, put me on CC.

Yes, I'm also very interested in getting mainline support for hardware
LED triggers, and incidentally one of my peripherals also happens to be
a dp83867. So please also include me on cc if and when you find time to
post a v+1, and I'll help with testing and reviewing.

Rasmus