From: Christian Marangi <ansuelsmth@gmail.com> To: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, Gregory Clement <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, John Crispin <john@phrozen.org>, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lee Jones <lee@kernel.org>, linux-leds@vger.kernel.org Subject: Re: [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support Date: Tue, 7 Mar 2023 20:41:55 +0100 [thread overview] Message-ID: <6407dd94.df0a0220.b4618.52e4@mx.google.com> (raw) In-Reply-To: <d1226e21-8150-4959-95b0-e9df2c460b81@lunn.ch> On Wed, Mar 08, 2023 at 01:49:55AM +0100, Andrew Lunn wrote: > On Tue, Mar 07, 2023 at 06:57:10PM +0100, Christian Marangi wrote: > > On Wed, Mar 08, 2023 at 12:16:13AM +0100, Andrew Lunn wrote: > > > > +qca8k_setup_led_ctrl(struct qca8k_priv *priv) > > > > +{ > > > > + struct fwnode_handle *ports, *port; > > > > + int port_num; > > > > + int ret; > > > > + > > > > + ports = device_get_named_child_node(priv->dev, "ports"); > > > > + if (!ports) { > > > > + dev_info(priv->dev, "No ports node specified in device tree!\n"); > > > > + return 0; > > > > + } > > > > + > > > > + fwnode_for_each_child_node(ports, port) { > > > > + struct fwnode_handle *phy_node, *reg_port_node = port; > > > > + > > > > + phy_node = fwnode_find_reference(port, "phy-handle", 0); > > > > + if (!IS_ERR(phy_node)) > > > > + reg_port_node = phy_node; > > > > > > I don't understand this bit. Why are you looking at the phy-handle? > > > > > > > + > > > > + if (fwnode_property_read_u32(reg_port_node, "reg", &port_num)) > > > > + continue; > > > > > > I would of expect port, not reg_port_node. I'm missing something > > > here.... > > > > > > > It's really not to implement ugly things like "reg - 1" > > > > On qca8k the port index goes from 0 to 6. > > 0 is cpu port 1 > > 1 is port0 at mdio reg 0 > > 2 is port1 at mdio reg 1 > > ... > > 6 is cpu port 2 > > > > Each port have a phy-handle that refer to a phy node with the correct > > reg and that reflect the correct port index. > > > > Tell me if this looks wrong, for qca8k we have qca8k_port_to_phy() and > > at times we introduced the mdio thing to describe the port - 1 directly > > in DT. If needed I can drop the additional fwnode and use this function > > but I would love to use what is defined in DT thatn a simple - 1. > > This comes back to the off list discussion earlier today. What you > actually have here are MAC LEDs, not PHY LEDs. They are implemented in > the MAC, not the PHY. To the end user, it should not matter, they > blink when you would expect. > > So your addressing should be based around the MAC port number, not the > PHY. Ok will drop this. > > Also, at the moment, all we are adding are a bunch of LEDs. There is > no link to a netdev at this point. At least, i don't see one. Be once > we start using ledtrig-netdev we will need that link to a netdev. Take > a look in my git tree at the last four patch. They add an additional > call to get the device an LED is attached to. > No currently we have no link for netdev, hence we are setting keep and not setting a default trigger in DT. Just checked them, interesting concept, guess we can think of something also for the interval setting. That would effectively make all the setting of the trigger set. Just my concern is that they may be too much specific to netdev trigger and may be problematic for other kind of hw control. (one main argument that was made for this feature was that some stuff were too much specific and actually not that generic) -- Ansuel
WARNING: multiple messages have this Message-ID (diff)
From: Christian Marangi <ansuelsmth@gmail.com> To: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, Gregory Clement <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, John Crispin <john@phrozen.org>, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lee Jones <lee@kernel.org>, linux-leds@vger.kernel.org Subject: Re: [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support Date: Tue, 7 Mar 2023 20:41:55 +0100 [thread overview] Message-ID: <6407dd94.df0a0220.b4618.52e4@mx.google.com> (raw) In-Reply-To: <d1226e21-8150-4959-95b0-e9df2c460b81@lunn.ch> On Wed, Mar 08, 2023 at 01:49:55AM +0100, Andrew Lunn wrote: > On Tue, Mar 07, 2023 at 06:57:10PM +0100, Christian Marangi wrote: > > On Wed, Mar 08, 2023 at 12:16:13AM +0100, Andrew Lunn wrote: > > > > +qca8k_setup_led_ctrl(struct qca8k_priv *priv) > > > > +{ > > > > + struct fwnode_handle *ports, *port; > > > > + int port_num; > > > > + int ret; > > > > + > > > > + ports = device_get_named_child_node(priv->dev, "ports"); > > > > + if (!ports) { > > > > + dev_info(priv->dev, "No ports node specified in device tree!\n"); > > > > + return 0; > > > > + } > > > > + > > > > + fwnode_for_each_child_node(ports, port) { > > > > + struct fwnode_handle *phy_node, *reg_port_node = port; > > > > + > > > > + phy_node = fwnode_find_reference(port, "phy-handle", 0); > > > > + if (!IS_ERR(phy_node)) > > > > + reg_port_node = phy_node; > > > > > > I don't understand this bit. Why are you looking at the phy-handle? > > > > > > > + > > > > + if (fwnode_property_read_u32(reg_port_node, "reg", &port_num)) > > > > + continue; > > > > > > I would of expect port, not reg_port_node. I'm missing something > > > here.... > > > > > > > It's really not to implement ugly things like "reg - 1" > > > > On qca8k the port index goes from 0 to 6. > > 0 is cpu port 1 > > 1 is port0 at mdio reg 0 > > 2 is port1 at mdio reg 1 > > ... > > 6 is cpu port 2 > > > > Each port have a phy-handle that refer to a phy node with the correct > > reg and that reflect the correct port index. > > > > Tell me if this looks wrong, for qca8k we have qca8k_port_to_phy() and > > at times we introduced the mdio thing to describe the port - 1 directly > > in DT. If needed I can drop the additional fwnode and use this function > > but I would love to use what is defined in DT thatn a simple - 1. > > This comes back to the off list discussion earlier today. What you > actually have here are MAC LEDs, not PHY LEDs. They are implemented in > the MAC, not the PHY. To the end user, it should not matter, they > blink when you would expect. > > So your addressing should be based around the MAC port number, not the > PHY. Ok will drop this. > > Also, at the moment, all we are adding are a bunch of LEDs. There is > no link to a netdev at this point. At least, i don't see one. Be once > we start using ledtrig-netdev we will need that link to a netdev. Take > a look in my git tree at the last four patch. They add an additional > call to get the device an LED is attached to. > No currently we have no link for netdev, hence we are setting keep and not setting a default trigger in DT. Just checked them, interesting concept, guess we can think of something also for the interval setting. That would effectively make all the setting of the trigger set. Just my concern is that they may be too much specific to netdev trigger and may be problematic for other kind of hw control. (one main argument that was made for this feature was that some stuff were too much specific and actually not that generic) -- Ansuel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-08 0:58 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-07 17:00 [net-next PATCH 00/11] net: Add basic LED support for switch/phy Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 17:00 ` [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 23:16 ` Andrew Lunn 2023-03-07 23:16 ` Andrew Lunn 2023-03-07 17:57 ` Christian Marangi 2023-03-07 17:57 ` Christian Marangi 2023-03-08 0:49 ` Andrew Lunn 2023-03-08 0:49 ` Andrew Lunn 2023-03-07 19:41 ` Christian Marangi [this message] 2023-03-07 19:41 ` Christian Marangi 2023-03-08 1:07 ` Andrew Lunn 2023-03-08 1:07 ` Andrew Lunn 2023-03-16 22:07 ` kernel test robot 2023-03-16 22:07 ` kernel test robot 2023-03-07 17:00 ` [net-next PATCH 02/11] net: dsa: qca8k: add LEDs blink_set() support Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 23:16 ` Andrew Lunn 2023-03-07 23:16 ` Andrew Lunn 2023-03-07 17:00 ` [net-next PATCH 03/11] net: phy: Add a binding for PHY LEDs Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 23:17 ` Andrew Lunn 2023-03-07 23:17 ` Andrew Lunn 2023-03-07 18:00 ` Christian Marangi 2023-03-07 18:00 ` Christian Marangi 2023-03-08 0:54 ` Andrew Lunn 2023-03-08 0:54 ` Andrew Lunn 2023-03-07 17:00 ` [net-next PATCH 04/11] net: phy: phy_device: Call into the PHY driver to set LED brightness Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 17:00 ` [net-next PATCH 05/11] net: phy: marvell: Add software control of the LEDs Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 17:00 ` [net-next PATCH 06/11] net: phy: phy_device: Call into the PHY driver to set LED blinking Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 17:00 ` [net-next PATCH 07/11] net: phy: marvell: Implement led_blink_set() Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 17:00 ` [net-next PATCH 08/11] dt-bindings: net: dsa: dsa-port: Document support for LEDs node Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-08 1:00 ` Andrew Lunn 2023-03-08 1:00 ` Andrew Lunn 2023-03-08 18:58 ` Krzysztof Kozlowski 2023-03-08 18:58 ` Krzysztof Kozlowski 2023-03-07 17:00 ` [net-next PATCH 09/11] dt-bindings: net: dsa: qca8k: add LEDs definition example Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-08 10:58 ` Krzysztof Kozlowski 2023-03-08 10:58 ` Krzysztof Kozlowski 2023-03-08 13:57 ` Andrew Lunn 2023-03-08 13:57 ` Andrew Lunn 2023-03-08 18:49 ` Krzysztof Kozlowski 2023-03-08 18:49 ` Krzysztof Kozlowski 2023-03-08 19:02 ` Christian Marangi 2023-03-08 19:02 ` Christian Marangi 2023-03-08 19:09 ` Krzysztof Kozlowski 2023-03-08 19:09 ` Krzysztof Kozlowski 2023-03-08 19:23 ` Christian Marangi 2023-03-08 19:23 ` Christian Marangi 2023-03-08 19:42 ` Andrew Lunn 2023-03-08 19:42 ` Andrew Lunn 2023-03-07 17:00 ` [net-next PATCH 10/11] dt-bindings: net: phy: Document support for LEDs node Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-08 1:01 ` Andrew Lunn 2023-03-08 1:01 ` Andrew Lunn 2023-03-08 11:00 ` Krzysztof Kozlowski 2023-03-08 11:00 ` Krzysztof Kozlowski 2023-03-08 18:56 ` Krzysztof Kozlowski 2023-03-08 18:56 ` Krzysztof Kozlowski 2023-03-08 18:56 ` Krzysztof Kozlowski 2023-03-08 18:56 ` Krzysztof Kozlowski 2023-03-08 19:03 ` Christian Marangi 2023-03-08 19:03 ` Christian Marangi 2023-03-07 17:00 ` [net-next PATCH 11/11] arm: mvebu: dt: Add PHY LED support for 370-rd WAN port Christian Marangi 2023-03-07 17:00 ` Christian Marangi 2023-03-07 23:20 ` Andrew Lunn 2023-03-07 23:20 ` Andrew Lunn 2023-03-07 18:03 ` Christian Marangi 2023-03-07 18:03 ` Christian Marangi 2023-03-08 1:20 ` [net-next PATCH 00/11] net: Add basic LED support for switch/phy Andrew Lunn 2023-03-08 1:20 ` Andrew Lunn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=6407dd94.df0a0220.b4618.52e4@mx.google.com \ --to=ansuelsmth@gmail.com \ --cc=andrew@lunn.ch \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=edumazet@google.com \ --cc=f.fainelli@gmail.com \ --cc=gregory.clement@bootlin.com \ --cc=hkallweit1@gmail.com \ --cc=john@phrozen.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=kuba@kernel.org \ --cc=lee@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-leds@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=netdev@vger.kernel.org \ --cc=olteanv@gmail.com \ --cc=pabeni@redhat.com \ --cc=robh+dt@kernel.org \ --cc=sebastian.hesselbarth@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.