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