All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Anton Hvornum <anton@hvornum.se>
Cc: netdev@vger.kernel.org, Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: Request for feature: force carrier up/on flag
Date: Wed, 10 Feb 2021 07:57:46 +0100	[thread overview]
Message-ID: <4fb584a3-5d4d-b6da-0e6a-766273e2a3e7@gmail.com> (raw)
In-Reply-To: <20210209163242.7ce62140@hermes.local>

On 10.02.2021 01:32, Stephen Hemminger wrote:
> On Tue, 9 Feb 2021 18:35:54 +0100
> Anton Hvornum <anton@hvornum.se> wrote:
> 
>> Hi.
>>
>> I am a bit new to ethtool, kernel drivers and all the surrounding aspects.
>> I also recognize that my use case is of low priority and a bit niche,
>> but any response would be greatly appreciated.
>>
>> I'm modifying an existing Intel driver, and I'm looking for a way to
>> integrate/add another ethtool hook to force call `netif_carrier_on`.
>> There's plenty of hooks/listeners (not clear as to what you call
>> these) between the Intel driver and ethtool via C API's today that
>> allows for ethtool to control the driver. Many of which are for speed,
>> autonegotiation etc. But I don't see any flags/functions to force a
>> carrier state to up.
>>
>> This would be very useful for many reasons, primarily on fiber optic
>> setups where you are developing hardware such as switches, routers and
>> even developing network cards. Or if you've got a passive device such
>> as IDS or something similar that passively monitors network traffic
>> and can't/shouldn't send out link requests.
>> There are commercial products with modified drivers that support this,
>> but since the Intel hardware in this case seems to support it - just
>> that there's no way controlling it with the tools that exist today. I
>> would therefore request a feature for consideration to ethtool that
>> can force carrier states up/down.
>>
>> A intuitive option I think would be:
>> ethtool --change carrier on
>>
>> Assuming that drivers follow suit and allow this. But a first step
>> would be for the tools to support it in the API so drivers have
>> something to call/listen for. In the meantime, I can probably
>> integrate a private flag and go that route, but that feels hacky and
>> won't foster driver developers to follow suit. My goal is to empower
>> more open source alternatives to otherwise expensive commercials
>> solutions.
>>
>> Best wishes,
>> Anton Hvornum
> 
> Normally, carrier just reflects the state of what the hardware is
> reporting. Why not set admin down which tells the NIC to take
> the device offline, and that drops the fiber link.
> 
> Or maybe what you want is already there.
> Try writing to /sys/class/net/ethX/carrier which forces a carrier change?
> 

This attribute uses callback ndo_change_carrier in struct net_device_ops.
The kerneldoc provides further details.

      reply	other threads:[~2021-02-10  6:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 17:35 Request for feature: force carrier up/on flag Anton Hvornum
2021-02-10  0:32 ` Stephen Hemminger
2021-02-10  6:57   ` Heiner Kallweit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4fb584a3-5d4d-b6da-0e6a-766273e2a3e7@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=anton@hvornum.se \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.