From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Petri Gynther <pgynther-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Greg Kroah-Hartman <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] eeprom: add non-cached sysfs read access to EEPROM data
Date: Wed, 2 Sep 2009 22:16:51 +0200 [thread overview]
Message-ID: <20090902221651.10b13a5b@hyperion.delvare> (raw)
In-Reply-To: <fc21faff0909021245k44e27206t65a268470065431a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2 Sep 2009 12:45:21 -0700, Petri Gynther wrote:
> In 2.6.25, I used this patch successfully for read-only access to some
> SFP EEPROMs:
> - 0x50 - vendor/part info (caching OK)
> - 0x51 - real-time diagnostics data (caching not OK)
>
> I only care about read-only access to these EEPROMs. And, actually, I
> don't want to provide write access at all.
>
> In 2.6.31, I'd like to continue using this same legacy driver for SFP
> EEPROM access, with the option of bypassing the cache.
This is not going to happen, sorry. "eeprom" is a legacy driver and we
certainly don't want to enhance it in any way. The "at24" driver is
much easier to extend as it was designed that way from the ground up.
You can add a SFP EEPROM type to it (whatever it is) and have the
driver automatically set the access to read-only and the caching
strategy for each part of the EEPROM.
I'm curious, why do you insist on using the eeprom driver?
--
Jean Delvare
next prev parent reply other threads:[~2009-09-02 20:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 23:15 [PATCH] eeprom: add non-cached sysfs read access to EEPROM data Petri Gynther
2009-09-01 23:39 ` Greg KH
[not found] ` <20090901233948.GA3828-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2009-09-02 19:28 ` Petri Gynther
2009-09-02 8:30 ` Jean Delvare
[not found] ` <20090902103034.15f13e4d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-09-02 19:45 ` Petri Gynther
[not found] ` <fc21faff0909021245k44e27206t65a268470065431a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-09-02 20:16 ` Jean Delvare [this message]
[not found] ` <20090902221651.10b13a5b-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-09-03 18:42 ` Petri Gynther
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=20090902221651.10b13a5b@hyperion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pgynther-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).