lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 28 May 2020 11:22:47 +0200
From:   Petr Machata <>
To:     Oleksij Rempel <>
Cc:     Amit Cohen <>,
        "andrew\" <>, mlxsw <>,
        "netdev\" <>
Subject: Re: Link down reasons

Oleksij Rempel <> 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

Powered by blists - more mailing lists