netdev - Re: Reporting SFP presence status

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6d7cc782-ee35-838b-d4f8-990e374ed6b0@silicom.dk>
Date:   Mon, 4 Jan 2021 12:52:16 +0100
From:   Martin Hundebøll <mhu@...icom.dk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: Reporting SFP presence status

Hi Andrew,

On 22/12/2020 15.22, Andrew Lunn wrote:
>> You're right; a notification isn't what I need. But a way to query the
>> current state of the module would be nice, i.e. using ethtool.
> What do you mean by state? ethtool -m gives you some state
> information. ENODEV gives you an idea that there is no module
> inserted. Lots of data suggests there is a module. You can decode the
> data to get a lot of information.

Using ENODEV would be enough, thanks.

> There was also a patchset from Russell King a few weeks ago exposing
> some information in debugfs. But since it is debugfs, you cannot rely
> on it.
> 
> Back to, what is you real use cases here?

Similar to the NO-CARRIER / LOWER_UP flags from network interfaces, a 
NO_SFP flag can aid when maintaining remote systems. So it's definitely 
nice-to-have.

// Martin