[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160611.192648.91885921700006865.davem@davemloft.net>
Date: Sat, 11 Jun 2016 19:26:48 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: vidya@...ulusnetworks.com
Cc: bwh@...nel.org, netdev@...r.kernel.org, roopa@...ulusnetworks.com
Subject: Re: [PATCH net-next] ethtool: Macro definition for SFF-8436/8636
Memory map max sizes
From: Vidya Sagar Ravipati <vidya@...ulusnetworks.com>
Date: Sat, 11 Jun 2016 16:22:38 -0700
> As part of ethtool application, application is requesting the drivers
> to provide the supported eeprom size to allocate memory buffer for
> getting complete dump.
And the right way to do that is the driver requests the eeprom info
with a buffer size of zero, then the driver fills in the size field
for what the size actually is.
Then the application can allocate the proper buffer size and rerun
the eeprom request.
Putting endless values for each and every eeprom type a device has is
just rediculous.
I'm not going to continue promoting this broken and unscalable scheme,
we have to fix this.
Powered by blists - more mailing lists