| Message ID | 20230314101516.20427-10-ansuelsmth@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [net-next,v3,01/14] net: dsa: qca8k: move qca8k_port_to_phy() to header | expand |
On Tue, Mar 14, 2023 at 11:15:11AM +0100, Christian Marangi wrote: > Document support for LEDs node in dsa port. > Switch may support different LEDs that can be configured for different > operation like blinking on traffic event or port link. > > Also add some Documentation to describe the difference of these nodes > compared to PHY LEDs, since dsa-port LEDs are controllable by the switch > regs and the possible intergated PHY doesn't have control on them. > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > .../devicetree/bindings/net/dsa/dsa-port.yaml | 21 +++++++++++++++++++ > 1 file changed, 21 insertions(+) Of all schemas, why did you choose dsa-port.yaml? Why not either something hardware specific (qca8k.yaml) or more generic (ethernet-controller.yaml)?
On Wed, Mar 15, 2023 at 02:58:23AM +0100, Andrew Lunn wrote: > On Wed, Mar 15, 2023 at 02:50:00AM +0200, Vladimir Oltean wrote: > > On Tue, Mar 14, 2023 at 11:15:11AM +0100, Christian Marangi wrote: > > > Document support for LEDs node in dsa port. > > > Switch may support different LEDs that can be configured for different > > > operation like blinking on traffic event or port link. > > > > > > Also add some Documentation to describe the difference of these nodes > > > compared to PHY LEDs, since dsa-port LEDs are controllable by the switch > > > regs and the possible intergated PHY doesn't have control on them. > > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > > --- > > > .../devicetree/bindings/net/dsa/dsa-port.yaml | 21 +++++++++++++++++++ > > > 1 file changed, 21 insertions(+) > > > > Of all schemas, why did you choose dsa-port.yaml? Why not either something > > hardware specific (qca8k.yaml) or more generic (ethernet-controller.yaml)? > > The binding should be generic. So qca8k.yaml is way to specific. The > Marvell switch should re-use it at some point. > > Looking at the hierarchy, ethernet-controller.yaml would work since > dsa-port includes ethernet-switch-port, which includes > ethernet-controller. > > These are MAC LEDs, and there is no reason why a standalone MAC in a > NIC could not implement such LEDs. So yes, > ethernet-controller.yaml. > > Is there actually anything above ethernet-controller.yaml? This is > about a netdev really, so a wifi MAC, or even a CAN MAC could also use > the binding.... > Yes ideally when we manage to do all the things, ath10k would benefits from this since it does have leds that blink on tx/rx traffic and are specially controlled... Don't think there is something above ethernet-controller tho...
On Wed, Mar 15, 2023 at 02:58:23AM +0100, Andrew Lunn wrote: > On Wed, Mar 15, 2023 at 02:50:00AM +0200, Vladimir Oltean wrote: > > On Tue, Mar 14, 2023 at 11:15:11AM +0100, Christian Marangi wrote: > > > Document support for LEDs node in dsa port. > > > Switch may support different LEDs that can be configured for different > > > operation like blinking on traffic event or port link. > > > > > > Also add some Documentation to describe the difference of these nodes > > > compared to PHY LEDs, since dsa-port LEDs are controllable by the switch > > > regs and the possible intergated PHY doesn't have control on them. > > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > > --- > > > .../devicetree/bindings/net/dsa/dsa-port.yaml | 21 +++++++++++++++++++ > > > 1 file changed, 21 insertions(+) > > > > Of all schemas, why did you choose dsa-port.yaml? Why not either something > > hardware specific (qca8k.yaml) or more generic (ethernet-controller.yaml)? > > The binding should be generic. So qca8k.yaml is way to specific. The > Marvell switch should re-use it at some point. > > Looking at the hierarchy, ethernet-controller.yaml would work since > dsa-port includes ethernet-switch-port, which includes > ethernet-controller. > > These are MAC LEDs, and there is no reason why a standalone MAC in a > NIC could not implement such LEDs. So yes, > ethernet-controller.yaml. > > Is there actually anything above ethernet-controller.yaml? Yes, the one under review[1]. Rob [1] https://lore.kernel.org/all/20230203-dt-bindings-network-class-v2-0-499686795073@jannau.net/
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml index 480120469953..1bf4151e5155 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml @@ -59,6 +59,27 @@ properties: - rtl8_4t - seville + leds: + type: object + description: + Describes the LEDs associated by the Switch Port and controllable + in its MACs. These LEDs are not integrated in the PHY and PHY + doesn't have any control on them. Switch regs are used to control + these Switch Port LEDs. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + '^led(@[a-f0-9]+)?$': + $ref: /schemas/leds/common.yaml# + + additionalProperties: false + # CPU and DSA ports must have phylink-compatible link descriptions if: oneOf:
Document support for LEDs node in dsa port. Switch may support different LEDs that can be configured for different operation like blinking on traffic event or port link. Also add some Documentation to describe the difference of these nodes compared to PHY LEDs, since dsa-port LEDs are controllable by the switch regs and the possible intergated PHY doesn't have control on them. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> --- .../devicetree/bindings/net/dsa/dsa-port.yaml | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+)