From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert P. J. Day" Subject: Re: consequences of setting net_device_ops ndo_change_carrier()? Date: Sun, 5 Aug 2018 06:43:11 -0400 (EDT) Message-ID: References: <20180805011121.GA19202@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: Linux kernel ntedev mailing list To: Andrew Lunn Return-path: Received: from cpanel4.indieserve.net ([199.212.143.9]:41534 "EHLO cpanel4.indieserve.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726117AbeHEMsr (ORCPT ); Sun, 5 Aug 2018 08:48:47 -0400 In-Reply-To: <20180805011121.GA19202@lunn.ch> Sender: netdev-owner@vger.kernel.org List-ID: On Sun, 5 Aug 2018, Andrew Lunn wrote: > 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//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. i think i see that now ... based on the really adamant comment in netdevice.h: "Devices that determine carrier state from physical hardware properties (eg network cables) or protocol-dependent mechanisms (eg USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function." the impression i got was that implementing that routine for a physical device would actually cause problems, but it seems only that it would be a strange thing to do, but wouldn't necessarily cause problems if you chose not to take advantage of it. which brings me back to one of my original questions -- why *would* someone implement it? as some sort of debugging feature? in any event, i'm convinced that that's not where the problem lies. > 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? in my case, it's properly in drivers/net/phy, so at least that part is normal. back to investigating ... rday