Hi Vladimir,

Am 2020-07-01 15:37, schrieb Vladimir Oltean:
[..]

quoted

quoted

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/ (local)

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