netdev - Re: [PATCH RESEND net-next v3 0/3] net: enetc: remove bootloader dependency

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: <CA+h21hoD0HTtpeGtEFyALg-5b7Gs0qJycukgzhQOGy+xHra23A@mail.gmail.com>
Date:   Thu, 2 Jul 2020 12:41:39 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Michael Walle <michael@...le.cc>, netdev <netdev@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Alex Marginean <alexandru.marginean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Heiko Thiery <heiko.thiery@...il.com>
Subject: Re: [PATCH RESEND net-next v3 0/3] net: enetc: remove bootloader dependency

On Thu, 2 Jul 2020 at 11:41, Russell King - ARM Linux admin
<linux@...linux.org.uk> wrote:
>
> On Thu, Jul 02, 2020 at 01:04:02AM +0300, Vladimir Oltean wrote:
> > On Thu, 2 Jul 2020 at 00:53, Russell King - ARM Linux admin
> > <linux@...linux.org.uk> wrote:
> > >
> > > fixing up almost every driver the best I can with the exception of two -
> > > felix DSA and Mediatek.
> > >
> > > I'm not going to wait for Felix or Mediatek.  As I say, I've given
> > > plenty of warning, and it's only a _suspicion_ of breakage on my
> > > side.
> > >
> >
> > What do you mean "I'm not going to wait for Felix"?
> > https://patchwork.ozlabs.org/project/netdev/patch/20200625152331.3784018-5-olteanv@gmail.com/
> > We left it at:
> >
> > > I'm not going to review patch 7
> > > tonight because of this fiasco.  To pissed off to do a decent job, so
> > > you're just going to have to wait.
> >
> > So, I was actively waiting for you to review it ever since, just like
> > you said, so I could send a v2. Were you waiting for anything?
>
> I stopped being interested in your series with the patch 5 commit
> description issue; what happened there is really demotivating.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Yes, but I mean, the fact that reviewing felix is "demotivating" can
only have 2 courses of action as far as I can see:
- I do resubmit the series with feedback that you've given so far, but
it's likely going to take a few more iterations because you haven't
reviewed the current series in its entirety, and you haven't in fact
reviewed the part which you consider as a dependency for your work yet
(the mac_link_up conversion). But this goes against your argument that
the lynx pcs will land quickly, so Michael should just wait a little
bit more.
- As per your "I'm not going to wait for Felix or Mediatek" phrase,
you might decide you just don't deal with DSA any longer, and you
proceed with the PCS patches by essentially breaking the dependency.
In this case, I'm not sure why Michael would need to wait either,
since _you_ are deciding to not wait for DSA, neither is he.

I'm fine either way, but one thing is not going to change, and that's
the ordering of my patches in the "PHYLINK integration improvements
for Felix DSA driver" series. As you know, most NXP users are not
using David's net-next directly (and that is at their! request), but a
"vendor" kernel which we try to keep as close to David's tree as
humanly possible, and which goes through a lot of testing. But if
there are going to be treewide changes in the phylink API (and there
_are_ already, that mac_link_up thing, which we haven't backported),
then there needs to be a strict ordering relationship between the
cleanup commits, which we can cherry-pick, and the adaptation to an
API which we haven't (nor we intend to) backport to 5.4, because it's
too much for little practical benefit. You seem to be hung up on that,
and we won't be making much progress if that continues, I'm afraid.

There are a lot of things to be done that depend on the lynx-pcs
thing, and there are multiple groups of people who are all waiting.
The new seville DSA driver, which _almost_ got into the previous
release cycle but missed the train due to a dependency with Mark
Brown's tree, also has a Lynx PCS integrated in it. I would like to
reuse the lynx-pcs module, but from what I can see, the bottleneck for
everybody seems to be reviewing the mac_link_up conversion of felix.

Thank you,
-Vladimir