Hi Köry,
On Tue, 11 Feb 2025 14:32:09 +0100
Kory Maincent <kory.maincent@xxxxxxxxxxx> wrote:
> On Fri, 7 Feb 2025 23:36:22 +0100
> Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx> wrote:
>
> > Ethernet provides a wide variety of layer 1 protocols and standards for
> > data transmission. The front-facing ports of an interface have their own
> > complexity and configurability.
> >
> > Introduce a representation of these front-facing ports. The current code
> > is minimalistic and only support ports controlled by PHY devices, but
> > the plan is to extend that to SFP as well as raw Ethernet MACs that
> > don't use PHY devices.
> >
> > This minimal port representation allows describing the media and number
> > of lanes of a port. From that information, we can derive the linkmodes
> > usable on the port, which can be used to limit the capabilities of an
> > interface.
> >
> > For now, the port lanes and medium is derived from devicetree, defined
> > by the PHY driver, or populated with default values (as we assume that
> > all PHYs expose at least one port).
> >
> > The typical example is 100M ethernet. 100BaseT can work using only 2
> > lanes on a Cat 5 cables. However, in the situation where a 10/100/1000
> > capable PHY is wired to its RJ45 port through 2 lanes only, we have no
> > way of detecting that. The "max-speed" DT property can be used, but a
> > more accurate representation can be used :
> >
> > mdi {
> > port@0 {
> > media = "BaseT";
> > lanes = <2>;
> > };
> > };
> >
> > From that information, we can derive the max speed reachable on the
> > port.
> >
> > Another benefit of having that is to avoid vendor-specific DT properties
> > (micrel,fiber-mode or ti,fiber-mode).
> >
> > This basic representation is meant to be expanded, by the introduction
> > of port ops, userspace listing of ports, and support for multi-port
> > devices.
>
> This patch is tackling the support of ports only for the PHY API. Keeping in
> mind that this port abstraction support will also be of interest to the NICs.
> Isn't it preferable to handle port in a standalone API?
The way I see it, nothing prevents from using the port definition in
ethernet-port.yml in DSA/raw nics.
> With net drivers having PHY managed by the firmware or DSA, there is no linux
> description of their PHYs. On that case, if we want to use port abstraction,
> what is the best? Register a virtual phy_device to use the abstraction port or
> use the port abstraction API directly which meant that it is not related to any
> PHY?
I think the next steps will be to have net_device have a list of ports
(maintained in the phy_link_topology) that aggregates ports from all
its PHYs/SFPs/raw interfaces. in that case net_device will be the
direct parent. I haven't worked on the bindings for that though,
especially for DSA :'(
I don't think the virtual phydev is going to be helpful. I'm hitting
the 15 patches limit, but a possible extension is to make so that
phylink also creates a port when it finds an SFP (hence, when upstream
is a MAC).
This is why phy_port has these fields :
enum phy_port_parent {
PHY_PORT_PHY,
};
struct phy_port {
...
enum phy_port_parent parent_type;
union {
struct phy_device *phy;
};
};
The parent type may (will) be extended with PORT_PHY_MAC, and that's
also why the parent pointer is in a union :)
I'm trying hard to make so that phy_port doesn't depend on phylib
(altough, phylib depends on phy_port). There's a dependency on some
core stuff (converting from medium => linkmodes) and phylink
(converting the interfaces list to linkmodes), but we can extract these
fairly easily.
You're correct in that for now, the integration is with phylib only
though, but let's make sure this will also work for phy-less devices.
Thanks a lot for your input,
Maxime
