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: Sat, 4 Aug 2018 13:32:40 -0400 (EDT) Message-ID: References: <20180804114720.GC2015@nanopsycho> <20180804102627.09259ca6@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: Jiri Pirko , Linux kernel ntedev mailing list To: Stephen Hemminger Return-path: Received: from cpanel4.indieserve.net ([199.212.143.9]:57416 "EHLO cpanel4.indieserve.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727953AbeHDTf3 (ORCPT ); Sat, 4 Aug 2018 15:35:29 -0400 In-Reply-To: <20180804102627.09259ca6@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: On Sat, 4 Aug 2018, Stephen Hemminger wrote: ... big snip ... > ndo_change_carrier is not the droid your looking for. > > The purpose of ndo_change_carrier was for testing network devices > (ie dummy), and also for cases like network tunnels where the > sofrware carrier state may be controlled by a userspace daemon. > > Real network devices call netif_carrier_on and netif_carrier_off > when they notice change in carrier state in hardware. Typically, > this is when an interrupt happens. i had actually come to just that conclusion, as i was digging through the code, and couldn't immediately see why setting ndo_change_carrier() would cause a problem. in fact, to help my admittedly painful newbie-level debugging, i started a wiki page to track this (i document *everything* on wiki pages): http://crashcourse.ca/dokuwiki/doku.php?id=ndo_change_carrier so i am reduced to concluding that the drivers in question are simply not calling correctly the very routines you mention. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================