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:   Fri, 29 May 2020 19:20:41 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>,
        radu-andrei.bulie@....com, fido_max@...ox.ru
Subject: Re: [PATCH net-next 11/11] net: dsa: ocelot: introduce driver for
 Seville VSC9953 switch

On 29/05/2020 18:42:47+0300, Vladimir Oltean wrote:
> On Fri, 29 May 2020 at 12:03, Alexandre Belloni
> <alexandre.belloni@...tlin.com> wrote:
> >
> > On 29/05/2020 11:30:43+0300, Vladimir Oltean wrote:
> > > > As ocelot can be used in a DSA configuration (even if it is not
> > > > implemented yet), I don't think this would be correct. From my point of
> > > > view, felix and seville are part of the ocelot family.
> > > >
> > >
> > > In this case, there would be a third driver in
> > > drivers/net/dsa/ocelot/ocelot_vsc7511.c which uses the intermediate
> > > felix_switch_ops from felix.c to access the ocelot core
> > > implementation. Unless you have better naming suggestions?
> > >
> >
> > I don't. Maybe felix.c should have been ocelot.c from the beginning but
> > honestly, it doesn't matter that much.
> >
> 
> Technically Seville is not part of the Ocelot family but part of
> Serval, but then again, it's just a marketing name, so it doesn't
> really mean anything..

When I submitted ocelot, I was thinking we would have different drivers
for jaguar, luton, ocelot, serval and serval-t. IIRC, ocelot is a subset
of serval or at least, it is similar enough to share the same driver.

> I am a bit reluctant to rename the DSA driver ops to "ocelot", since
> it would be even more confusing for everyone to have a function
> ocelot_dsa_set_ageing_time that calls ocelot_set_ageing_time. At least
> this way, there's going to be some learning curve figuring out that
> felix is an umbrella term for DSA ops, but there will be more naming
> predictability. (at least that's how I see it)
> 

I'm fine with the current naming, I was certainly not suggesting to
change it.

> > BTW, maybe we should merge the VITESSE FELIX ETHERNET SWITCH DRIVER and
> > MICROSEMI ETHERNET SWITCH DRIVER entries in MAINTAINERS. You do much
> > more work in drivers/net/ethernet/mscc/ than I currently do.
> >
> 
> How would you see the merged MAINTAINERS entry? Something like this?
> 
> MICROSEMI ETHERNET SWITCH DRIVER
> M:    Alexandre Belloni <alexandre.belloni@...tlin.com>
> M:    Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
> M:    Vladimir Oltean <vladimir.oltean@....com>

You should probably be in the top position.

> M:    Claudiu Manoil <claudiu.manoil@....com>
> L:    netdev@...r.kernel.org
> S:    Maintained

I guess this could stay Supported unless you are not paid to work on
that.

> F:    include/soc/mscc/ocelot*
> F:    drivers/net/ethernet/mscc/
> F:    drivers/net/dsa/ocelot/*
> F:    net/dsa/tag_ocelot.c
> 
> Any takers from Microchip, or is the internal mailing list enough?

It seems ok for now, we can always add/replace people later on.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ