Re: Link down reasons

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Thu, May 28, 2020 at 11:22:47AM +0200, Petr Machata wrote:
> 
> 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.

ok

> > - 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?

Not in current implementation. But it is possible at least with
nxp_tja11xx PHY.

> 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.

nxp_tja11xx can go down or can't go up on under vlotage or over temerature
error. So, I assume this are two more possible link-down reasons.


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |