Message-ID: <CO2PR11MB0088C6D5B98C6C8E2D173A99975B0@CO2PR11MB0088.namprd11.prod.outlook.com>
Date:	Sun, 5 Jun 2016 17:44:31 +0000
From:	Yuval Mintz <Yuval.Mintz@...gic.com>
To:	Ben Hutchings <ben@...adent.org.uk>,
	David Miller <davem@...emloft.net>
CC:	netdev <netdev@...r.kernel.org>,
	Sudarsana Kalluru <Sudarsana.Kalluru@...gic.com>
Subject: RE: [RFC net-next 1/1] ethtool: Add support for set eeprom metadata.

> > > > > Currently ethtool implementation does not have a way to pass the
> > > > > metadata for eeprom related operations. Some adapters have a
> > > > > complicated non-volatile memory implementation that requires
> > > > > additional information – there are drivers [bnx2x and bnxt] that
> > > > > use the ‘magic’ field in the {G,S}EEPROM  for that purpose,
> > > > > although that’s not
> > > its intended usage.
> > > > >
> > > > > This patch adds a provision to pass the eeprom metadata for
> > > > > %ETHTOOL_SEEPROM/%ETHTOOL_GEEPROM implementations. User
> > > provided
> > > > > metadata will be cached by the driver and assigns a magic value
> > > > > which the application need to use for the subsequent {G,S}EEPROM
> > > command.
> > > >
> > > > Hi Dave,
> > > >
> > > > This got no comments at all.
> > > > What do you want us to with it next? Should we re-send it as a patch?
> > >
> > > Here's a comment: I really dislike this.
> > :-)
> >
> > > - It doesn't specify any semantics for the 'metadata'.  The comment
> > > hints that they are driver-specific identifiers for different NVRAM partitions.
> > Not exactly, but close [in our use case there are 2 'methods' of
> > accessing the flash - either according to addresses or logical 'files'].
> >
> > > - It doesn't provide a way for userland to enumerate the valid metadata
> values.
> > I agree; I can't think of any good way of enumerating device-specific values.
> >
> > > - It's not clear whether the driver is supposed to maintain just one
> > > metadata:magic mapping, or more than that.
> > Theoretically, I guess it could maintain multiple, but that wasn't the intention.
> > One should do.
> >
> > > Is the ethtool API really the right interface for access to flash?
> > > The sfc driver exposes a large number of flash partitions using MTD
> > > instead.  These can be enumerated (through /proc/mtd or sysfs) and
> > > they can be read and written through block devices.
> >
> > I think the better question then is 'what's the purpose of this ethtool API at
> all'?
> 
> I think it's a bit of an accident - MTD was designed for flash in embedded
> systems, and it used to have a static limit on the number of partitions.  The
> ethtool API was then rather better suited to plug-in cards that would have a
> single small EEPROM.
> 
> > I agree we can go and do everything via MTD; The reason we've tried
> > using this API was mainly... because it was there. And thus we thought
> > this is the RIGHT method for providing users the way of reading their flash.
> [...]
> 
> I think that MTD makes more sense for flash partitions, especially when there
> are several of them.  I already did the work of removing the static limit on the
> number of partitions, and convincing distributions to enable the MTD core
> drivers.  (That said, you will still find some users who need to change their
> custom kernel
> configurations.)

Notice we don't really have multiple partitions. We have a single partition
pseudo file-system, but problem is device has no direct access to the controller;
Every access has to go via the management firmware. 
And in order to work with it we need some additional metadata.
I think MTD would eventually look just as 'magical'.

Powered by blists - more mailing lists