Message ID | 20230417151738.19426-1-ansuelsmth@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | net: Add basic LED support for switch/phy | expand |
On Mon, 17 Apr 2023 17:17:22 +0200 Christian Marangi wrote: > This is a continue of [1]. It was decided to take a more gradual > approach to implement LEDs support for switch and phy starting with > basic support and then implementing the hw control part when we have all > the prereq done. > > This series implements only the brightness_set() and blink_set() ops. > An example of switch implementation is done with qca8k. > > For PHY a more generic approach is used with implementing the LED > support in PHY core and with the user (in this case marvell) adding all > the required functions. > > Currently we set the default-state as "keep" to not change the default > configuration of the declared LEDs since almost every switch have a > default configuration. IIRC we were supposed to take these via netdev with acks from Pavel/Lee. So we need acks on patches 4/5/16 ? If there is a repost, could you take out the arch/arm patches? They should not go via netdev, we'll try to filter them out when applying but mistakes happen.
Hello: This series was applied to netdev/net-next.git (main) by David S. Miller <davem@davemloft.net>: On Mon, 17 Apr 2023 17:17:22 +0200 you wrote: > This is a continue of [1]. It was decided to take a more gradual > approach to implement LEDs support for switch and phy starting with > basic support and then implementing the hw control part when we have all > the prereq done. > > This series implements only the brightness_set() and blink_set() ops. > An example of switch implementation is done with qca8k. > > [...] Here is the summary with links: - [net-next,v7,01/16] net: dsa: qca8k: move qca8k_port_to_phy() to header https://git.kernel.org/netdev/net-next/c/3e8b4d6277fd - [net-next,v7,02/16] net: dsa: qca8k: add LEDs basic support https://git.kernel.org/netdev/net-next/c/1e264f9d2918 - [net-next,v7,03/16] net: dsa: qca8k: add LEDs blink_set() support https://git.kernel.org/netdev/net-next/c/91acadcc6e59 - [net-next,v7,04/16] leds: Provide stubs for when CLASS_LED & NEW_LEDS are disabled https://git.kernel.org/netdev/net-next/c/e5029edd5393 - [net-next,v7,05/16] net: phy: Add a binding for PHY LEDs https://git.kernel.org/netdev/net-next/c/01e5b728e9e4 - [net-next,v7,06/16] net: phy: phy_device: Call into the PHY driver to set LED brightness https://git.kernel.org/netdev/net-next/c/684818189b04 - [net-next,v7,07/16] net: phy: marvell: Add software control of the LEDs https://git.kernel.org/netdev/net-next/c/2d3960e58ef7 - [net-next,v7,08/16] net: phy: phy_device: Call into the PHY driver to set LED blinking https://git.kernel.org/netdev/net-next/c/4e901018432e - [net-next,v7,09/16] net: phy: marvell: Implement led_blink_set() https://git.kernel.org/netdev/net-next/c/ea9e86485dec - [net-next,v7,10/16] dt-bindings: net: ethernet-controller: Document support for LEDs node https://git.kernel.org/netdev/net-next/c/57b6c752c5c0 - [net-next,v7,11/16] dt-bindings: net: dsa: qca8k: add LEDs definition example https://git.kernel.org/netdev/net-next/c/ed617bc022f4 - [net-next,v7,12/16] ARM: dts: qcom: ipq8064-rb3011: Drop unevaluated properties in switch nodes https://git.kernel.org/netdev/net-next/c/939595c79d12 - [net-next,v7,13/16] ARM: dts: qcom: ipq8064-rb3011: Add Switch LED for each port https://git.kernel.org/netdev/net-next/c/09930f1fb875 - [net-next,v7,14/16] dt-bindings: net: phy: Document support for LEDs node https://git.kernel.org/netdev/net-next/c/18a24b694a2b - [net-next,v7,15/16] arm: mvebu: dt: Add PHY LED support for 370-rd WAN port https://git.kernel.org/netdev/net-next/c/380a8fe1b2f4 - [net-next,v7,16/16] Documentation: LEDs: Describe good names for network LEDs https://git.kernel.org/netdev/net-next/c/c693ea2fd6e3 You are awesome, thank you!
> IIRC we were supposed to take these via netdev with acks from Pavel/Lee. > So we need acks on patches 4/5/16 ? If there is a repost, could you > take out the arch/arm patches? They should not go via netdev, we'll try > to filter them out when applying but mistakes happen. The 370rd patch could in theory go via netdev. I maintain it, both at the board and mvebu SoC level, so can give my Acked-by:, in addition to my Signed-off-by:. It is very unlikely there will be any sort of merge conflict. Andrew
> IIRC we were supposed to take these via netdev with acks from Pavel/Lee. > So we need acks on patches 4/5/16 ? If there is a repost, could you > take out the arch/arm patches? They should not go via netdev, we'll try > to filter them out when applying but mistakes happen. Ah, mute point now, the whole patchset has been merged. Andrew