| Message ID | 20201209140501.17415-1-i.mikhaylov@yadro.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add LED mode behavior/select properties and handle | expand |
On Wed, Dec 09, 2020 at 05:04:59PM +0300, Ivan Mikhaylov wrote: > In KSZ9131 PHY it is possible to control LEDs blink behavior via > LED mode behavior and select registers. Add DTS properties plus handles > of them inside micrel PHY driver. > > I've some concerns about passing raw register values into LED mode > select and behavior. There was been some work done allowing PHY LEDs to be controlled just like other LEDs in Linux. That is how this should be done. Please go look back in the netdev and LED mailing list archives, and join that work. Andrew
Hi! > In KSZ9131 PHY it is possible to control LEDs blink behavior via > LED mode behavior and select registers. Add DTS properties plus handles > of them inside micrel PHY driver. > > I've some concerns about passing raw register values into LED mode > select and behavior. It can be passed via array like in microchip > driver(Documentation/devicetree/bindings/net/microchip,lan78xx.txt). > There is the problem in this particular driver - there is a lot of other PHYs > and led mode behavior/select states may intersect, that's the reason why > I did it this way. Is there any good ways to make it look more > properly? Lets... not do this? We have a LED subsystem which should probably control the LEDs... so user can specify behaviours at run-time, instead of them being hard-coded in the device tree. Plus, LED subsystem will use same interface for networks LEDs as for ... other LEDs. Best regards, Pavel
Am Wed, Dec 16, 2020 at 11:41:19PM +0100 schrieb Pavel Machek: > Hi! > > > In KSZ9131 PHY it is possible to control LEDs blink behavior via > > LED mode behavior and select registers. Add DTS properties plus handles > > of them inside micrel PHY driver. > > > > I've some concerns about passing raw register values into LED mode > > select and behavior. It can be passed via array like in microchip > > driver(Documentation/devicetree/bindings/net/microchip,lan78xx.txt). > > There is the problem in this particular driver - there is a lot of other PHYs > > and led mode behavior/select states may intersect, that's the reason why > > I did it this way. Is there any good ways to make it look more > > properly? > > Lets... not do this? > > We have a LED subsystem which should probably control the LEDs... so > user can specify behaviours at run-time, instead of them being > hard-coded in the device tree. > > Plus, LED subsystem will use same interface for networks LEDs as for > ... other LEDs. Hi Pavel, I would also like to control the LEDs via subsystem interface, but how I can configure those to be visible in 'sys/class/leds'? My LEDs are connected directly to KSZ9131RNX phy device and not to any of GPIO available on the CPU. Am I missing some DTS entries therefore? Best regards Alexander Wilhelm > > Best regards, > Pavel > -- > http://www.livejournal.com/~pavelmachek
On Tue, Nov 12, 2024 at 09:19:59AM +0100, Alexander Wilhelm wrote: > Am Wed, Dec 16, 2020 at 11:41:19PM +0100 schrieb Pavel Machek: > > Hi! > > > > > In KSZ9131 PHY it is possible to control LEDs blink behavior via > > > LED mode behavior and select registers. Add DTS properties plus handles > > > of them inside micrel PHY driver. > > > > > > I've some concerns about passing raw register values into LED mode > > > select and behavior. It can be passed via array like in microchip > > > driver(Documentation/devicetree/bindings/net/microchip,lan78xx.txt). > > > There is the problem in this particular driver - there is a lot of other PHYs > > > and led mode behavior/select states may intersect, that's the reason why > > > I did it this way. Is there any good ways to make it look more > > > properly? > > > > Lets... not do this? > > > > We have a LED subsystem which should probably control the LEDs... so > > user can specify behaviours at run-time, instead of them being > > hard-coded in the device tree. > > > > Plus, LED subsystem will use same interface for networks LEDs as for > > ... other LEDs. > > Hi Pavel, > > I would also like to control the LEDs via subsystem interface, but how I can > configure those to be visible in 'sys/class/leds'? My LEDs are connected > directly to KSZ9131RNX phy device and not to any of GPIO available on the CPU. > Am I missing some DTS entries therefore? The KSZ9131RNX driver needs to implement some LED methods, like .led_brightness_set(), .led_blink_set(), .led_hw_is_supported(), .led_hw_control_set(), .led_hw_control_get(). Look for example at marvell.c driver, or broadcom.c. Regarding DTS, look at linux/arch/arm/boot/dts/marvell/armada-370-rd.dts. The ethernet-phy@0 node has leds subnode, describing the LEDs. Marek
Am Tue, Nov 12, 2024 at 09:49:03AM +0100 schrieb Marek Behún: > On Tue, Nov 12, 2024 at 09:19:59AM +0100, Alexander Wilhelm wrote: > > Am Wed, Dec 16, 2020 at 11:41:19PM +0100 schrieb Pavel Machek: > > > Hi! > > > > > > > In KSZ9131 PHY it is possible to control LEDs blink behavior via > > > > LED mode behavior and select registers. Add DTS properties plus handles > > > > of them inside micrel PHY driver. > > > > > > > > I've some concerns about passing raw register values into LED mode > > > > select and behavior. It can be passed via array like in microchip > > > > driver(Documentation/devicetree/bindings/net/microchip,lan78xx.txt). > > > > There is the problem in this particular driver - there is a lot of other PHYs > > > > and led mode behavior/select states may intersect, that's the reason why > > > > I did it this way. Is there any good ways to make it look more > > > > properly? > > > > > > Lets... not do this? > > > > > > We have a LED subsystem which should probably control the LEDs... so > > > user can specify behaviours at run-time, instead of them being > > > hard-coded in the device tree. > > > > > > Plus, LED subsystem will use same interface for networks LEDs as for > > > ... other LEDs. > > > > Hi Pavel, > > > > I would also like to control the LEDs via subsystem interface, but how I can > > configure those to be visible in 'sys/class/leds'? My LEDs are connected > > directly to KSZ9131RNX phy device and not to any of GPIO available on the CPU. > > Am I missing some DTS entries therefore? > > The KSZ9131RNX driver needs to implement some LED methods, like > .led_brightness_set(), .led_blink_set(), .led_hw_is_supported(), > .led_hw_control_set(), .led_hw_control_get(). > > Look for example at marvell.c driver, or broadcom.c. > > Regarding DTS, look at linux/arch/arm/boot/dts/marvell/armada-370-rd.dts. > The ethernet-phy@0 node has leds subnode, describing the LEDs. > > Marek Hi Marek, thank you a lot. I think I got the main idea how the LED interface intended to work. The current linux master does not implement those callbacks for the micrel phy. I will look into implementing these functions if I am given enough time to do so. Best regards Alexander Wilhelm
In KSZ9131 PHY it is possible to control LEDs blink behavior via LED mode behavior and select registers. Add DTS properties plus handles of them inside micrel PHY driver. I've some concerns about passing raw register values into LED mode select and behavior. It can be passed via array like in microchip driver(Documentation/devicetree/bindings/net/microchip,lan78xx.txt). There is the problem in this particular driver - there is a lot of other PHYs and led mode behavior/select states may intersect, that's the reason why I did it this way. Is there any good ways to make it look more properly? Ivan Mikhaylov (2): net: phy: micrel: add LED control on KSZ9131 dt-bindings: net: phy: micrel: add LED mode behavior and select properties .../devicetree/bindings/net/micrel.txt | 7 ++ drivers/net/phy/micrel.c | 69 ++++++++++++++++++- 2 files changed, 75 insertions(+), 1 deletion(-)