All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jose Abreu <Jose.Abreu@synopsys.com>
To: David Miller <davem@redhat.com>,
	Jakub Jelinek <jj@ultra.linux.cz>,
	"Jeff Garzik" <jgarzik@pobox.com>, Tim Hockin <thockin@sun.com>,
	Eli Kupermann <eli.kupermann@intel.com>,
	Chris Leech <christopher.leech@intel.com>,
	"Scott Feldman" <scott.feldman@intel.com>,
	Ben Hutchings <ben@decadent.org.uk>
Cc: <netdev@vger.kernel.org>, Joao Pinto <Joao.Pinto@synopsys.com>
Subject: [RFC] ethtool: Support for driver private ioctl's
Date: Thu, 5 Apr 2018 11:47:28 +0100	[thread overview]
Message-ID: <cbd05f37-509b-118b-e681-0ccd0ebebd73@synopsys.com> (raw)

Hi All,

I would like to know your opinion regarding adding support for
driver private ioctl's in ethtool.

Background: Synopsys Ethernet IP's have a certain number of
features which can be reconfigured at runtime. Giving you two
examples: One of the most recent one is the safety features,
which can be enabled/disabled and forced at runtime. Another one
is a Flexible RX Parser which can route specific packets to
specific RX DMA channels. Given that these are features specific
to our IP's it would not be useful to add an uniform API for this
because the users would only be one or two drivers ...

This new feature would change the help usage for ethtool so that
each driver private option would be shown, and then each driver
specific file would have a structure with all the available
options. Finally, each driver would have to handle the private
IOCTL's.

We already have this working locally and now I would like to know
your opinion about upstreaming this ... Do you think this can be
useful for anyone else? Or should we change direction to use, for
example, debugfs/configfs?

Thanks and Best Regards,
Jose Miguel Abreu

             reply	other threads:[~2018-04-05 10:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 10:47 Jose Abreu [this message]
2018-04-05 15:50 ` [RFC] ethtool: Support for driver private ioctl's Florian Fainelli
2018-04-06  9:07   ` Michal Kubecek
2018-04-06 13:57     ` Jose Abreu
2018-04-06 13:51   ` Jose Abreu
2018-04-06 14:47     ` Andrew Lunn
2018-04-06 14:51       ` Jose Abreu
2018-04-07 19:58     ` Florian Fainelli
2018-04-24  9:37       ` Jose Abreu

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=cbd05f37-509b-118b-e681-0ccd0ebebd73@synopsys.com \
    --to=jose.abreu@synopsys.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=ben@decadent.org.uk \
    --cc=christopher.leech@intel.com \
    --cc=davem@redhat.com \
    --cc=eli.kupermann@intel.com \
    --cc=jgarzik@pobox.com \
    --cc=jj@ultra.linux.cz \
    --cc=netdev@vger.kernel.org \
    --cc=scott.feldman@intel.com \
    --cc=thockin@sun.com \
    /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.