linux-kernel - Re: [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Mar 2023 01:49:55 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Christian Marangi <ansuelsmth@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        John Crispin <john@...ozen.org>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, Lee Jones <lee@...nel.org>,
        linux-leds@...r.kernel.org
Subject: Re: [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support

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.

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.

     Andrew