From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: consequences of setting net_device_ops ndo_change_carrier()? Date: Sat, 4 Aug 2018 13:47:20 +0200 Message-ID: <20180804114720.GC2015@nanopsycho> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linux kernel ntedev mailing list To: "Robert P. J. Day" Return-path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:37100 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726588AbeHDNuk (ORCPT ); Sat, 4 Aug 2018 09:50:40 -0400 Received: by mail-wm0-f67.google.com with SMTP id n11-v6so9155837wmc.2 for ; Sat, 04 Aug 2018 04:50:11 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Sat, Aug 04, 2018 at 01:06:58PM CEST, rpjday@crashcourse.ca 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). >doing this with a "regular" port on my linux laptop certainly >confirmed that the carrier file would switch between 0 and 1, and >operstate would switch between up and down, so i know what behaviour i >was *expecting* if things were ostensibly working properly. > > long story short, i pawed through the driver code only to stumble What driver? Has to be out of tree as I don't see any in the existing kernel using .ndo_change_carrier (aside of team and dummy) >over this in the ethernet driver for the device: > > static const struct net_device_ops netdev_netdev_ops = { > ... snip ... > .ndo_change_carrier = netdev_change_carrier, > ... snip ... > }; > >and > > static int > netdev_change_carrier(struct net_device *dev, bool new_carrier) > { > if (new_carrier) > netif_carrier_on(dev); > else > netif_carrier_off(dev); > return 0; > } > >as i mentioned before, i am really new to kernel networking code, so i >did a quick search and found this in netdevice.h: > >* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier); > * Called to change device carrier. Soft-devices (like dummy, team, etc) > * which do not represent real hardware may define this to allow their > * userspace components to manage their virtual carrier state. 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. > * > >although i still don't fully understand the purpose of that field, it >makes me *very* nervous to read that that routine is for "soft" >devices, and ***not*** for devices that attempt to determine carrier >state from physical hardware properties. i searched the kernel code >base for other drivers that set that field, and found only what is >mentioned in that comment -- dummy.c, of_dummy_mac.c and team.c. > > the testers for this unit are complaining that they are somehow not >being notified when they plug and unplug devices from the ports -- is >this why? what would be the purpose of assigning a routine to that >field? as i read it (and i could be wrong), my impression is that you >can have the driver *either* determine the carrier state from physical >properties, *or* allow userspace control, but not both, is that >correct? Correct. Your device is physical device, it knows how to get the state of the carrier itself. > > i'm about to ask the original authors why they did the above, but I guess that the reason is that they had no clue what they are doing :) >i'd like to feel that it's not a stupid question if there's something >really clever going on here. is this just a development debugging >feature that would normally be removed at production? or what? > >rday > >-- > >======================================================================== >Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca/dokuwiki > >Twitter: http://twitter.com/rpjday >LinkedIn: http://ca.linkedin.com/in/rpjday >========================================================================