[RFC] ethtool: Display reg dump length via get driver info.

Submitted by Ajit Khaparde on March 18, 2011, 9:06 p.m.

Details

Message ID ae232d9a-90c7-47ae-856d-bc5a2b3a8037@exht1.ad.emulex.com
State Not Applicable
Delegated to: David Miller
Headers show

Commit Message

Ajit Khaparde March 18, 2011, 9:06 p.m.
Devices like BE store Reg Dump Data in the hardware.
This change will allow to just peek into the hardware
to see if any data is available for a dump and analysis,
without actually dumping the register data.

Patch:
----

Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
 ethtool.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

Comments

Ben Hutchings March 18, 2011, 9:32 p.m.
On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
> Devices like BE store Reg Dump Data in the hardware.

Where else would it be?

> This change will allow to just peek into the hardware
> to see if any data is available for a dump and analysis,
> without actually dumping the register data.
[...]

This is wrong.  ethtool_ops::get_regs_len really should return a
constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
the right size.  If the size of a dump really does vary then make it
return the maximum possible size for the device.

Ben.
Ajit Khaparde March 18, 2011, 9:52 p.m.

Ben Hutchings March 18, 2011, 10 p.m.
On Fri, 2011-03-18 at 14:52 -0700, Ajit.Khaparde@Emulex.Com wrote:
> ______________________________________
> From: Ben Hutchings [bhutchings@solarflare.com]
> Sent: Friday, March 18, 2011 4:32 PM
> To: Khaparde, Ajit
> Cc: netdev@vger.kernel.org
> Subject: Re: [RFC] ethtool: Display reg dump length via get driver info.
> 
> On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
> >> Devices like BE store Reg Dump Data in the hardware.
> 
> > Where else would it be?
> 
> Well yes. That's true.
> 
> >> This change will allow to just peek into the hardware
> >> to see if any data is available for a dump and analysis,
> >> without actually dumping the register data.
> > [...]
> 
> > This is wrong.  ethtool_ops::get_regs_len really should return a
> > constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
> > the right size.  If the size of a dump really does vary then make it
> > return the maximum possible size for the device.
> 
> Yes, it is a constant size. And will always be the max size possible.
> I just want to see if I can get the length, without really making the ethtoool -d call.
> Because that will trigger the dump too.
> At that moment, I may not be interested in the data itself.

OK, so what you're really interested in is 'does this version of the
driver support register dump'?

Ben.
Ajit Khaparde March 18, 2011, 10:07 p.m.

Patch hide | download patch | download mbox

diff --git a/ethtool.c b/ethtool.c
index e9cb2c9..a0c7c99 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1423,11 +1423,13 @@  static int dump_drvinfo(struct ethtool_drvinfo *info)
 		"driver: %s\n"
 		"version: %s\n"
 		"firmware-version: %s\n"
-		"bus-info: %s\n",
+		"bus-info: %s\n"
+		"regdump-len: %d\n",
 		info->driver,
 		info->version,
 		info->fw_version,
-		info->bus_info);
+		info->bus_info,
+		info->regdump_len);
 
 	return 0;
 }