netdev - Re: [PATCH RFC net-next 6/7] net: dsa: mv88e6xxx: provide software node for default settings

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: <ZBtjl9+bhtpKPmjr@shell.armlinux.org.uk>
Date:   Wed, 22 Mar 2023 20:22:47 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Daniel Scally <djrscally@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Jakub Kicinski <kuba@...nel.org>, linux-acpi@...r.kernel.org,
        netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH RFC net-next 6/7] net: dsa: mv88e6xxx: provide software
 node for default settings

On Wed, Mar 22, 2023 at 09:17:02PM +0100, Andrew Lunn wrote:
> On Wed, Mar 22, 2023 at 08:13:51PM +0000, Russell King (Oracle) wrote:
> > On Wed, Mar 22, 2023 at 07:57:19PM +0100, Andrew Lunn wrote:
> > > > +static struct fwnode_handle *mv88e6xxx_port_get_fwnode(struct dsa_switch *ds,
> > > > +						       int port,
> > > > +						       struct fwnode_handle *h)
> > > > +{
> > > > +	struct mv88e6xxx_chip *chip = ds->priv;
> > > > +	struct device_node *np, *phy_node;
> > > > +	int speed, duplex, err;
> > > > +	phy_interface_t mode;
> > > > +	struct dsa_port *dp;
> > > > +	unsigned long caps;
> > > > +
> > > > +	dp = dsa_to_port(ds, port);
> > > > +	if (dsa_port_is_user(dp))
> > > > +		return h;
> > > > +
> > > > +	/* No DT? Eh? */
> > > > +	np = to_of_node(h);
> > > > +	if (!np)
> > > > +		return h;
> > > 
> > > I've not looked at the big picture yet, but you can have a simple
> > > switch setup without DT. I have a couple of amd64 boards which use
> > > platform data. The user ports all have internal PHYs, and the CPU port
> > > defaults to 1G, it might even be strapped that way.
> > 
> > Are you suggesting that we should generate some swnode description of
> > the max interface mode and speed if we are missing a DT node?
> > 
> > I'm not seeing any port specific data in the mv88e6xxx platform data.
> 
> No, i'm just pointing out that not have DT is not an error, and can
> happen. I just wanted to make sure you are not assuming there is
> always DT.

What I'm trying to find out is what you think the behaviour should be
in this case. Are you suggesting we should fall back to what we do now
which is let the driver do it internally without phylink.

The problem is that if we don't go down the phylink route for everything
then we /can't/ convert mv88e6xxx to phylink_pcs, because the "serdes"
stuff will be gone, and the absence of phylink will mean those won't be
called e.g. to power up the serdes.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!