Re: consequences of setting net_device_ops ndo_change_carrier()?

[Jiri Pirko <jiri@resnulli.us>]

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/<ifname>/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
>========================================================================