From: Mandeep Singh Baines <msb@google.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, jeff@garzik.org, joe@perches.com,
nil@google.com, thockin@google.com, matthew@wil.cx
Subject: Re: [PATCH] [ETHTOOL]: Add support for large eeproms
Date: Tue, 15 Apr 2008 10:39:31 -0700 [thread overview]
Message-ID: <20080415173931.GA1000@google.com> (raw)
In-Reply-To: <20080415.003153.30044057.davem@davemloft.net>
David Miller (davem@davemloft.net) wrote:
> From: Mandeep Singh Baines <msb@google.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@google.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?
>
I suspect such a case does not exist but can't say for certain. Currently,
the only user-space application I'm aware of which makes use of the set_eeprom
ioctl interface is ethtool. It currently only supports single byte writes.
Hence, any device which supports set_eeprom will likely also support
single byte writing.
To test my changes, I had to modify the ethtool application to support writing
an arbitrary number of bytes to eeprom. This makes it possible to update an
eeprom from a binary file. To do so, I use ethtool as follows:
# ethtool -E eth1 < eeprom.bin
I plan on sending my ethtool changes to the maintainers once this patch
is accepted.
> If so this new code could cause regressions.
An alternative would be to vmalloc the entire size to avoid the potential
regression.
next prev parent reply other threads:[~2008-04-15 17:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1207195123.23161.291.camel@localhost>
2008-04-03 18:00 ` [PATCH] [ETHTOOL]: Add support for large eeproms Mandeep Singh Baines
2008-04-04 0:03 ` Joe Perches
2008-04-04 1:41 ` Mandeep Singh Baines
2008-04-12 9:10 ` Jeff Garzik
2008-04-14 18:03 ` Mandeep Singh Baines
2008-04-15 7:31 ` David Miller
2008-04-15 17:07 ` Tim Hockin
2008-04-16 2:23 ` David Miller
2008-04-24 18:17 ` Breno Leitao
2008-04-24 19:01 ` Mandeep Singh Baines
2008-04-24 20:21 ` Breno Leitao
2008-04-25 1:15 ` Mandeep Singh Baines
2008-04-15 17:39 ` Mandeep Singh Baines [this message]
2008-04-16 2:24 ` David Miller
2008-04-03 2:12 Mandeep Singh Baines
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080415173931.GA1000@google.com \
--to=msb@google.com \
--cc=davem@davemloft.net \
--cc=jeff@garzik.org \
--cc=joe@perches.com \
--cc=matthew@wil.cx \
--cc=netdev@vger.kernel.org \
--cc=nil@google.com \
--cc=thockin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.