netdev - 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]

Message-ID: <6407dd94.df0a0220.b4618.52e4@mx.google.com>
Date:   Tue, 7 Mar 2023 20:41:55 +0100
From:   Christian Marangi <ansuelsmth@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
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 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