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: <20180427134400.GA4813@piout.net>
Date:   Fri, 27 Apr 2018 15:44:00 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Allan Nielsen <Allan.Nielsen@...rosemi.com>,
        razvan.stefanescu@....com, po.liu@....com,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mips@...ux-mips.org
Subject: Re: [PATCH net-next v2 4/7] net: mscc: Add initial Ocelot switch
 support

On 26/04/2018 23:09:15+0200, Andrew Lunn wrote:
> > +/* Checks if the net_device instance given to us originate from our driver. */
> > +static bool ocelot_netdevice_dev_check(const struct net_device *dev)
> > +{
> > +	return dev->netdev_ops == &ocelot_port_netdev_ops;
> > +}
> 
> This is probably O.K. now, but when you add support for controlling
> the switch over PCIe, i think it breaks. A board could have two
> switches...
> 
> It might be possible to do something with dev->parent. All ports of a
> switch should have the same parent.
> 

Actually, that is fine because it simply ensures netdev_priv(dev); is a
struct ocelot_port.

Later on, we get ocelot_port->ocelot and do the right thing.

The only thing that would not be working when having multiple of those
switches on the same platform would be having interfaces from different
switches in the same bridge. Anyway, this is definitively not something
we want because of the limited bandwidth of the CPU port.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ