| Message ID | 20221118001548.635752-1-tharvey@gateworks.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add dt configuration for dp83867 led modes | expand |
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