netdev - Re: [net-next PATCH 0/8] configuration support for switch headers & phy

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: <YFyOW5X0Nrjz8w/v@lunn.ch>
Date:   Thu, 25 Mar 2021 14:21:31 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc:     Hariprasad Kelam <hkelam@...vell.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        Linu Cherian <lcherian@...vell.com>,
        Geethasowjanya Akula <gakula@...vell.com>,
        Jerin Jacob Kollanukkaran <jerinj@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>
Subject: Re: [net-next PATCH 0/8] configuration support for switch headers &
 phy

On Thu, Mar 25, 2021 at 06:32:12PM +0530, Sunil Kovvuri wrote:
> On Thu, Mar 25, 2021 at 6:20 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > > So you completely skipped how this works with mv88e6xxx or
> > > > prestera. If you need this private flag for some out of mainline
> > > > Marvell SDK, it is very unlikely to be accepted.
> > > >
> > > >         Andrew
> > >
> > > What we are trying to do here has no dependency on DSA drivers and
> > > neither impacts that functionality.
> >
> > So this is an indirect way of saying: Yes, this is for some out of
> > mainline Marvell SDK.
> >
> > > Here we are just notifying the HW to parse the packets properly.
> >
> > But the correct way for this to happen is probably some kernel
> > internal API between the MAC and the DSA driver. Mainline probably has
> > no need for this private flag.
> >
> >    Andrew
> 
> Didn't get why you say so.
> HW expects some info from SW to do the packet parsing properly and
> this is specific to this hardware.

Anything which needs out of mainline code is going to be rejected,
unless you can show there is an in mainline use case as well. Which is
why i keep pointing you to mv88e6xxx and prestira. That provides the
necessary {E}DSA tags. You have an mv88e6xxx and prestira switch being
controlled by Linux with DSA tagged frames flowing out of it into your
MAC driver. What is the big picture use case that requires this
private flag to enable DSA parsing? Why don't the MAC driver and the
DSA driver just talk to each other, and setup the parsing?

	Andrew