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] [day] [month] [year] [list]
Message-ID: <1f258d5db214f9f1e644ea4b4fdb18e5@walle.cc>
Date:   Wed, 01 Jul 2020 15:49:28 +0200
From:   Michael Walle <michael@...le.cc>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Ioana Ciornei <ioana.ciornei@....com>,
        netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH net-next v3 0/9] net: phy: add Lynx PCS MDIO module

Hi Vladimir,

Am 2020-07-01 15:37, schrieb Vladimir Oltean:
[..]
>> > felix does not have support code for 1000base-x, so I think it's
>> > natural to not clutter this series with things like that.
>> > Things like USXGMII up to 10G, 10GBase-R, are also missing, for much
>> > of the same reason - we wanted to make no functional change to the
>> > existing code, precisely because we wanted it to go in quickly. There
>> > are multiple things that are waiting for it:
>> > - Michael Walle's enetc patches are going to use pcs-lynx
>> 
>> How likely is it that this will be sorted out before the 5.9 merge
>> window will be closed? The thing is, we have boards out in the
>> wild which have a non-working ethernet with their stock bootloader
>> and which depend on the following patch series to get that fixed:
>> 
>> https://lore.kernel.org/netdev/20200528063847.27704-1-michael@walle.cc/
>> 
>> Thus, if this is going to take longer, I'd do a respin of that
>> series. We already missed the 5.8 release and I don't know if
>> a "Fixes:" tag (or a CC stable) is appropriate here because it
>> is kind of a new functionality.
>> 
>> -michael
> 
> From my side I think it is reasonable that you resubmit your enetc
> patches using the existing framework. Looks like we're in for some
> pretty significant API changes for phylink, not sure if you need to
> depend on those if you just need the PCS to work.

Ok, I'll resubmit them.

> But, I don't know if marketing your patches as "fixes" is going to go
> that well. In fact, you are also moving some definitions around, from
> felix to enetc. I think if you want to break dependencies from felix
> here, you should leave the definitions where they are and just
> duplicate them.

Nice idea, but I didn't intend to add the Fixes tag anyways. I'm fine
with saying, please use the newest kernel.

-michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ