Re: Link down reasons

[Petr Machata <petrm@mellanox.com>]

Oleksij Rempel <o.rempel@pengutronix.de> writes:

> I would add some more reasons:
> - master slave resolution issues: both link partners are master or
>   slave.

I guess we should send the RFC, so that we can talk particulars. We
currently don't have anything like master/slave mismatch in the API, but
that's just because our FW does not report this. The idea is that if MAC
and/or PHY driver can't express some fail using the existing codes, it
creates a new one.

> - signal quality drop. In this case driver should be extended to notify
>   the system if SQI is under some configurable limit.

As SQI goes down, will the PHY driver eventually shut down the port?

Because if yes, that's exactly the situation when it would later report,
yeah, the link is down because SQI was rubbish. In the proposed API, we
would model this as "signal integrity issue", with a possible subreason
of "low SQI", or something along those lines.

E.g., mlxsw can report module temperatures. But whether the port goes
down is a separate mechanism. So when a port is down, the driver can
tell you, yeah, it is down, because it was overheated. And separate from
that you can check the module temperatures. SQI might be a similar
issue.