netdev - Re: [PATCH net-next 10/12] net: dsa: vitesse: move vsc73xx driver to a separate folder

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, 13 Nov 2019 08:38:22 +0100
From:   "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To:     Vladimir Oltean <olteanv@...il.com>
CC:     Andrew Lunn <andrew@...n.ch>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        netdev <netdev@...r.kernel.org>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next 10/12] net: dsa: vitesse: move vsc73xx driver to
 a separate folder

> > > The way I see an Ocelot DSA driver, it would be done a la mv88e6xxx,
> > > aka a single struct dsa_switch_ops registered for the entire family,
> > > and function pointers where the implementation differs. You're not
> > > proposing that here, but rather that each switch driver works in
> > > parallel with each other, and they all call into the Ocelot core. That
> > > would produce a lot more boilerplate, I think.
> > > And if the DSA driver for Ocelot ends up supporting more than 1
> > > device, its name should better not contain "vsc9959" since that's
> > > rather specific.
> > A vsc7511/12 will not share code with felix/vsc9959. I do not expect any other
> > IP/chip will be register compatible with vsc9959.
> I don't exactly understand this comment. Register-incompatible in a
> logical sense, or in a layout sense? Judging from the attachment in
> chapter 6 of the VSC7511 datasheet [1], at least the basic
> functionality appears to be almost the same. And for the rest, there's
> regmap magic.
My point is that vsc7511 has more in commen with vsc7514 than it has with
felix/vsc9959.

vsc7511 will use the same regmaps as those in vsc7514 (with different helper
functions as it will be accessing the reguster via SPI).

As far as I recall, felix/vsc9959 has slightly different (in-compatible) PTP
functionallity than vsc7511-14, which needs to be handled in the felix/vsc9959
driver. The same apply if you want to add support for TAS/taprio as this
featurte are not to be found in vsc7511-14.

> > A vsc7511/12 will use the ocelot DSA tagger, but other from that it will call into the
> > ocelot driver (I think).
> >
> > But to be honest, I do not think we should spend too much energy on vsc7511/12
> > now. When/if it comes, we will see how it fit best.
> 
> Ok. So the driver will still be called "felix", it will instantiate a
> struct felix_info_vsc9959 instead of the current felix_info_ls1028a,
> but will live in the root drivers/net/dsa folder. Then, when/if you
> add support for vsc7511, you'll move both into an "ocelot" folder and
> figure out how much of the driver minus the tagger is worth reusing
> (aka instantiate a struct felix_info_vsc7511). Agree?
Agree.

/Allan