[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080415.003153.30044057.davem@davemloft.net>
Date: Tue, 15 Apr 2008 00:31:53 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: msb@...gle.com
Cc: netdev@...r.kernel.org, jeff@...zik.org, joe@...ches.com,
nil@...gle.com, thockin@...gle.com, matthew@....cx
Subject: Re: [PATCH] [ETHTOOL]: Add support for large eeproms
From: Mandeep Singh Baines <msb@...gle.com>
Date: Mon, 14 Apr 2008 11:03:38 -0700
> Currently, it is not possible to read/write to an eeprom larger than
> 128k in size because the buffer used for temporarily storing the
> eeprom contents is allocated using kmalloc. kmalloc can only allocate
> a maximum of 128k depending on architecture.
>
> Modified ethtool_get/set_eeprom to only allocate a page of memory and
> then copy the eeprom a page at a time.
>
> Updated original patch as per suggestions from Joe Perches.
>
> Signed-off-by: Mandeep Singh Baines <msb@...gle.com>
This looks fine on the surface.
But I wonder what we can do if we have some EEPROM implementation
that can only write the whole time at once, and thus will fail
if you try to do it in pieces? Do we have such a case?
If so this new code could cause regressions.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists