Use of 'SIOCDEVPRIVATE' in ethernet drivers.

Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[Giri Reddy]

I'm implementing a new interface for upgrading the firmware for our next
generation of Qlogic drivers. We need to transfer control information
between userspace and driver, in addition to the firmware payload. I'm
considering using 'SIOCDEVPRIVATE' ioctl interface to pass control
information between userland and driver.

I also see comments in the source (include/linux/sockios.h) that
'SIOCDEVPRIVATE' will be deprecated 2.5.x. What is the current status of
deprecation in the latest versions of the kernel?

Are we still allowed to use 'SIOCDEVPRIVATE' in drivers if there the
deprecation efforts are on hold.

Any input will be appreciated.

Thanks.
Giri
Qlogic

________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[David Miller]

From: Giri Reddy <giri.reddy@qlogic.com>
Date: Tue, 7 Jan 2014 18:21:17 +0000

> Are we still allowed to use 'SIOCDEVPRIVATE' in drivers if there the
> deprecation efforts are on hold.

To say that use of SIOCDEVPRIVATE is discouraged would be an
understatement.

Please create a generic ethtool based facility that other drivers in
similar situations can use as well.

Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[Giri Reddy]

On 1/7/14 11:05 AM, David Miller wrote:
> From: Giri Reddy <giri.reddy@qlogic.com>
> Date: Tue, 7 Jan 2014 18:21:17 +0000
>
>> Are we still allowed to use 'SIOCDEVPRIVATE' in drivers if there the
>> deprecation efforts are on hold.
> To say that use of SIOCDEVPRIVATE is discouraged would be an
> understatement.
>
> Please create a generic ethtool based facility that other drivers in
> similar situations can use as well.

Thanks for the input. I will explore the 'ethtool' option. We will have
multiple control frames exchanged between user space and kernel for
every flash update operation, most of this will be proprietary stuff
that will get exchanged - I will explore how to provide a generic
interface for that.

Giri

>


________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[Stephen Hemminger]

On Tue, 7 Jan 2014 22:22:45 +0000
Giri Reddy <giri.reddy@qlogic.com> wrote:

> On 1/7/14 11:05 AM, David Miller wrote:
> > From: Giri Reddy <giri.reddy@qlogic.com>
> > Date: Tue, 7 Jan 2014 18:21:17 +0000
> >
> >> Are we still allowed to use 'SIOCDEVPRIVATE' in drivers if there the
> >> deprecation efforts are on hold.
> > To say that use of SIOCDEVPRIVATE is discouraged would be an
> > understatement.
> >
> > Please create a generic ethtool based facility that other drivers in
> > similar situations can use as well.
> 
> Thanks for the input. I will explore the 'ethtool' option. We will have
> multiple control frames exchanged between user space and kernel for
> every flash update operation, most of this will be proprietary stuff
> that will get exchanged - I will explore how to provide a generic
> interface for that.
> 
> Giri

Maybe a debugfs or sysfs filesystem would work better than adding ioctl';s

Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[Giri Reddy]

Thanks for the input. I will explore the 'ethtool' option. We will have
multiple control frames exchanged between user space and kernel for
every flash update operation, most of this will be proprietary stuff
that will get exchanged - I will explore how to provide a generic
interface for that.

Giri

> Maybe a debugfs or sysfs filesystem would work better than adding ioctl';s

IOCTL option is off the table based on feedback from DaveM. I'm
considering 'sysfs' as an option along with 'ethtool', making this
generic without too much proprietary taint will be the problem that
needs to be solved.

Giri

>


________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[Ben Hutchings]

On Tue, 2014-01-07 at 18:21 +0000, Giri Reddy wrote:
> I'm implementing a new interface for upgrading the firmware for our next
> generation of Qlogic drivers. We need to transfer control information
> between userspace and driver, in addition to the firmware payload. I'm
> considering using 'SIOCDEVPRIVATE' ioctl interface to pass control
> information between userland and driver.
> 
> I also see comments in the source (include/linux/sockios.h) that
> 'SIOCDEVPRIVATE' will be deprecated 2.5.x. What is the current status of
> deprecation in the latest versions of the kernel?

It is still supported and unlikely to be removed, but no in-tree driver
will be allowed to expose new operations this way.

> Are we still allowed to use 'SIOCDEVPRIVATE' in drivers if there the
> deprecation efforts are on hold.
> 
> Any input will be appreciated.

The existing interfaces used for firmware update are:

1. ethtool ETHTOOL_FLASHDEV command.  Userland program installs a
firmware blob under /lib/firmware and then issues this command using
ioctl().  It can specify which flash partition is to be written.  Driver
loads and writes the entire blob and (presumably) resets the chip if
necessary.  There is no way to read the old firmware.

Example drivers: bna, cxgb4, be2net, vxge

2. MTD driver plus ethtool ETHTOOL_RESET command.  The flash
partition(s) containing firmware are exposed as separate devices with
names that indicate what they all are.  Userland can read and write the
firmware through /dev/mtd* or /dev/mtdblock*.  It can reset the chip
after writing firmware, using ioctl().  This is flexible but relatively
complicated for userland to use.

Example driver: sfc

3. ethtool ETHTOOL_{G,S}EEPROM commands.  Userland program sends these
commands using ioctl().  There is no clean way to expose more than one
flash partition, e.g. for controller, PHY, and net-boot firmware.

Example driver: bnx2

Please choose one of the above and don't invent another one.  (There are
already several other interfaces in use that are too horrible to mention
here.)

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[Ben Hutchings]

On Wed, 2014-01-08 at 16:02 +0000, Giri Reddy wrote:
> Thanks for the input. I will explore the 'ethtool' option. We will have
> multiple control frames exchanged between user space and kernel for
> every flash update operation, most of this will be proprietary stuff
> that will get exchanged - I will explore how to provide a generic
> interface for that.
[...]

What you need to do beyond read, write, erase and reset?

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.

[Giri Reddy]

On 1/9/14 1:09 PM, Ben Hutchings wrote:
> On Wed, 2014-01-08 at 16:02 +0000, Giri Reddy wrote:
>> Thanks for the input. I will explore the 'ethtool' option. We will have
>> multiple control frames exchanged between user space and kernel for
>> every flash update operation, most of this will be proprietary stuff
>> that will get exchanged - I will explore how to provide a generic
>> interface for that.
> [...]
>
> What you need to do beyond read, write, erase and reset?

Thanks for detailed note about various options for firmware update in
the other email. Aside form the payload we also want control frames
(proprietary) to be exchanged between our firmware and management
application.

Giri

>
> Ben.
>


________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.