> The best you came with is that phylink gives you flexibility and
> options, and sure it does, when you add a lot of stuff to it to make it
> do that. But I don't want to know why phylink is an option, I want to
> know why phylib isn't. Phylink is your creation, which as far as I'm
> concerned stems out of the need to support more setups than phylib did,
> and you took the route of working around phylib rather than extending
> it. So, I would have expected an answer from you why phylib is not a
> valid place for this.
phylib assumes it is the last thing. There is nothing after it, just
the copper media. And it assumes the world is copper, and not
hot-pluggable. For a long time, this was sufficient. The MAC was
directly connected to the PHY via MII, or GMII, RGMII and everything
is static. It does this job well.
But other the last few years, things have changed. We have
intermediary blocks. An SFP is such an intermediary block, when you
have a copper module. We have SERDES blocks which can need
configuration. We potentially have a backplane, with an SFP at the
other end, with copper PHY plugged into it. And all thus can
dynamically change.
The phylib architecture is not flexiable enough to handle this
chain. phylib is good for copper PHYs, but not much more. phylink is
there to help link together a number of blocks into a complete chain,
and declare the link is up when all blocks in the chain are up. If the
end block happens to be an copper PHY, phylink will use phylib to
control the PHY, because that is what phylib is for. I would not say
phylink works around phylib, it incorporates phylib.
If you have a simple setup of a MAC directly connected to a copper PHY
in a simple static setup, feel free to use phylib. It is not going
away. But don't push the boundary, or we are likely to reject it.
Andrew
