netdev - Re: [PATCH net-next v3 0/9] net: phy: add Lynx PCS MDIO module

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]

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