netdev - Re: [RFC PATCH net-next 10/12] net: lan966x: add port module 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20210923080236.mqnb7shs2x6rzmh2@soft-dev3-1.localhost>
Date:   Thu, 23 Sep 2021 10:02:36 +0200
From:   Horatiu Vultur <horatiu.vultur@...rochip.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
CC:     <davem@...emloft.net>, <kuba@...nel.org>, <robh+dt@...nel.org>,
        <andrew@...n.ch>, <f.fainelli@...il.com>,
        <alexandre.belloni@...tlin.com>, <vladimir.oltean@....com>,
        <UNGLinuxDriver@...rochip.com>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-phy@...ts.infradead.org>, <linux-pm@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 10/12] net: lan966x: add port module support

The 09/20/2021 14:54, Russell King (Oracle) wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi Russell,

> 
> On Mon, Sep 20, 2021 at 11:52:16AM +0200, Horatiu Vultur wrote:
> > +static void lan966x_cleanup_ports(struct lan966x *lan966x)
> > +{
> > +     struct lan966x_port *port;
> > +     int portno;
> > +
> > +     for (portno = 0; portno < lan966x->num_phys_ports; portno++) {
> > +             port = lan966x->ports[portno];
> > +             if (!port)
> > +                     continue;
> > +
> > +             if (port->phylink) {
> > +                     rtnl_lock();
> > +                     lan966x_port_stop(port->dev);
> > +                     rtnl_unlock();
> > +                     port->phylink = NULL;
> 
> This leaks the phylink structure. You need to call phylink_destroy().
> 
> >  static int lan966x_probe_port(struct lan966x *lan966x, u8 port,
> >                             phy_interface_t phy_mode)
> >  {
> >       struct lan966x_port *lan966x_port;
> > +     struct phylink *phylink;
> > +     struct net_device *dev;
> > +     int err;
> >
> >       if (port >= lan966x->num_phys_ports)
> >               return -EINVAL;
> >
> > -     lan966x_port = devm_kzalloc(lan966x->dev, sizeof(*lan966x_port),
> > -                                 GFP_KERNEL);
> > +     dev = devm_alloc_etherdev_mqs(lan966x->dev,
> > +                                   sizeof(struct lan966x_port), 8, 1);
> > +     if (!dev)
> > +             return -ENOMEM;
> >
> > +     SET_NETDEV_DEV(dev, lan966x->dev);
> > +     lan966x_port = netdev_priv(dev);
> > +     lan966x_port->dev = dev;
> >       lan966x_port->lan966x = lan966x;
> >       lan966x_port->chip_port = port;
> >       lan966x_port->pvid = PORT_PVID;
> >       lan966x->ports[port] = lan966x_port;
> >
> > +     dev->max_mtu = ETH_MAX_MTU;
> > +
> > +     dev->netdev_ops = &lan966x_port_netdev_ops;
> > +     dev->needed_headroom = IFH_LEN * sizeof(u32);
> > +
> > +     err = register_netdev(dev);
> > +     if (err) {
> > +             dev_err(lan966x->dev, "register_netdev failed\n");
> > +             goto err_register_netdev;
> > +     }
> 
> register_netdev() publishes the network device.
> 
> > +
> > +     lan966x_port->phylink_config.dev = &lan966x_port->dev->dev;
> > +     lan966x_port->phylink_config.type = PHYLINK_NETDEV;
> > +     lan966x_port->phylink_config.pcs_poll = true;
> > +
> > +     phylink = phylink_create(&lan966x_port->phylink_config,
> > +                              lan966x_port->fwnode,
> > +                              phy_mode,
> > +                              &lan966x_phylink_mac_ops);
> 
> phylink_create() should always be called _prior_ to the network device
> being published. In any case...
> 
> > +     if (IS_ERR(phylink))
> > +             return PTR_ERR(phylink);
> 
> If this fails, this function returns an error, but leaves the network
> device published - which is a bug in itself.

If this fails it should eventually call lan966x_cleaup_ports where the
net_device will be unregister. But first I will need to make
phylink_create() be called prior the network device.

> 
> > +static void lan966x_phylink_mac_link_down(struct phylink_config *config,
> > +                                       unsigned int mode,
> > +                                       phy_interface_t interface)
> > +{
> 
> Hmm? Shouldn't this do something?

I don't think I need to do anything here. The current setup is that
there is a PHY in front of the MAC.
So when the link partner goes down, the PHY will go down and the MAC
will still be up. Is this a problem?
When we force the port to be set down, then in the function
lan966x_port_stop we actually shutdown the port.

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

-- 
/Horatiu