From: Andrew Lunn <andrew@lunn.ch>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Linux kernel ntedev mailing list <netdev@vger.kernel.org>
Subject: Re: consequences of setting net_device_ops ndo_change_carrier()?
Date: Sun, 5 Aug 2018 03:11:21 +0200 [thread overview]
Message-ID: <20180805011121.GA19202@lunn.ch> (raw)
In-Reply-To: <alpine.LFD.2.21.1808040646290.25800@localhost.localdomain>
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
next prev parent reply other threads:[~2018-08-05 3:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-04 11:06 consequences of setting net_device_ops ndo_change_carrier()? Robert P. J. Day
2018-08-04 11:47 ` Jiri Pirko
2018-08-04 11:57 ` Robert P. J. Day
2018-08-04 17:26 ` Stephen Hemminger
2018-08-04 17:32 ` Robert P. J. Day
2018-08-05 1:11 ` Andrew Lunn [this message]
2018-08-05 10:43 ` Robert P. J. Day
2018-08-05 14:58 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180805011121.GA19202@lunn.ch \
--to=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=rpjday@crashcourse.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.