From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: should __LINK_STATE_* enums really be restricted to generic queueing layer? Date: Fri, 24 Aug 2018 15:49:17 +0200 Message-ID: <20180824134917.GB1999@lunn.ch> References: <20180824071738.Horde.kWZLgt1409E2fICBH1FiM5U@crashcourse.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: rpjday@crashcourse.ca Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:42255 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726883AbeHXRYE (ORCPT ); Fri, 24 Aug 2018 13:24:04 -0400 Content-Disposition: inline In-Reply-To: <20180824071738.Horde.kWZLgt1409E2fICBH1FiM5U@crashcourse.ca> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Aug 24, 2018 at 07:17:38AM -0400, rpjday@crashcourse.ca wrote: > more curious pedantry ... in netdevice.h, one reads: > > /* These flag bits are private to the generic network queueing > * layer; they may not be explicitly referenced by any other > * code. > */ > > enum netdev_state_t { > __LINK_STATE_START, > __LINK_STATE_PRESENT, > __LINK_STATE_NOCARRIER, > __LINK_STATE_LINKWATCH_PENDING, > __LINK_STATE_DORMANT, > }; > > ok, but there are definitely a few examples of what look like > non-generic network queueing code referencing those enums. > > one example, drivers/net/ethernet/amd/sun3lance.c, which openly > (and amusingly) admits that it shouldn't be doing this: > > dev->netdev_ops = &lance_netdev_ops; > // KLUDGE -- REMOVE ME > set_bit(__LINK_STATE_PRESENT, &dev->state); > return 1; > } > > there are a few more places (admittedly, not many) -- is this > acceptable behaviour? Not in a new driver. The sun3lance is a very old driver. I have misty memories of a Sun 3/60. There is nothing in this code about a driving a PHY. Maybe using netif_carrier_on() would work, but without having access to the hardware to test, i would just leave it alone. Andrew