netdev - Re: consequences of setting net_device_ops ndo_change

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180805011121.GA19202@lunn.ch>
Date:   Sun, 5 Aug 2018 03:11:21 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Robert P. J. Day" <rpjday@...shcourse.ca>
Cc:     Linux kernel ntedev mailing list <netdev@...r.kernel.org>
Subject: Re: consequences of setting net_device_ops ndo_change_carrier()?

On Sat, Aug 04, 2018 at 07:06:58AM -0400, Robert P. J. Day wrote:
> 
>   i'll try to keep this (relatively) short as there may be a simple
> answer to this, or it could just be a stupid question -- sort of
> related to previous question (thank you, florian).
> 
>   currently messing with networking device involving FPGA and some
> quad-port transceivers, and noticed that, when one unplugs or plugs a
> device into one of the ports, there is no change in the contents of
> the corresponding sysfs files /sys/class/net/<ifname>/carrier (or
> operstate, for that matter, which might be related to this as well).

Hi Robert

As other have pointed out, ndo_change_carrier is not what you want
here.

You should have a PHY device of some sort. Either a traditional copper
PHY, or an SFP module. There should be a driver for this PHY. This
could be one of those in drivers/net/phy. Or it could be firmware
running, running on a little microcontroller inside your FPGA?

Assuming you are using a Linux phy driver, it will keep an eye on the
state of the Link. If the cable is unplugged, the other end downs its
interface, etc. it will notice the change in state. The core phy code,
aka. phylib, will then call netif_carrier_off() and it will call the
MAC callback which was registers when the MAC driver called one of the
phy_connect() variants. The same happens when the link goes up. If you
are using an SFP module, it is a little but more complex, and you
should look at phylink.

If you have firmware managing the PHY, (not recommended, goes against
the principals of open source, nobody can help you debug it, or fix
it, costs you more in the long run, blah, blah, blah), the MAC driver
should be informed, probably by an interrupt and a status
register. The MAC driver should then call netif_carrier_off|on as
needed.

	Andrew