All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Poeschel <poeschel-Xtl8qvBWbHwb1SvskN2V4Q@public.gmane.org>
To: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC] misc/at24: distinguish between eeprom and fram chips
Date: Fri, 7 Dec 2012 11:14:28 +0100	[thread overview]
Message-ID: <201212071114.29034.poeschel@lemonage.de> (raw)
In-Reply-To: <20121205164153.GA5011-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

> > > > I wanted to use a fm24c04 i2c fram chip with linux. I grepped the
> > > > source and found nothing. I later found that my chip can be handled
> > > > by at24 eeprom driver. It creates a sysfs file called eeprom to
> > > > read from and write to the chip. Userspace has no chance to
> > > > distinguish if it is writing an eeprom or a fram chip.
> > > 
> > > Why should it?
> > 
> > Because writes are much faster and it doesn't have to take care on erase
> > cycles. It could use other write strategies on such devices and update
> > informations that have to survive power downs more often.
> 
> I agree. I think that a seperate attribute named e.g. 'page_size' would
> be more helpful than renaming the binary file to fram?

Yes, this is a much better solution! Adding a seperate sysfs file page_size 
and a file for the type of device which would read eeprom, fram, etc then.
If you also think this is the way to go, I would spent one of my next free 
timeslots to this.

> > > The method of accessing EEPROMs is used by way more chips than FRAMs.
> > > So, I'd prefer to have the text updated more generic like "EEPROMs and
> > > similar devices like RAMs, ROMs, etc...". Describing setting .flags in
> > > Kconfig is overkill.
> > 
> > A patch updating Kconfig is below.
> 
> Looks good from a glimpse, will apply it later.

Thank you!

Lars

WARNING: multiple messages have this Message-ID (diff)
From: Lars Poeschel <poeschel@lemonage.de>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org
Subject: Re: [PATCH RFC] misc/at24: distinguish between eeprom and fram chips
Date: Fri, 7 Dec 2012 11:14:28 +0100	[thread overview]
Message-ID: <201212071114.29034.poeschel@lemonage.de> (raw)
In-Reply-To: <20121205164153.GA5011@pengutronix.de>

> > > > I wanted to use a fm24c04 i2c fram chip with linux. I grepped the
> > > > source and found nothing. I later found that my chip can be handled
> > > > by at24 eeprom driver. It creates a sysfs file called eeprom to
> > > > read from and write to the chip. Userspace has no chance to
> > > > distinguish if it is writing an eeprom or a fram chip.
> > > 
> > > Why should it?
> > 
> > Because writes are much faster and it doesn't have to take care on erase
> > cycles. It could use other write strategies on such devices and update
> > informations that have to survive power downs more often.
> 
> I agree. I think that a seperate attribute named e.g. 'page_size' would
> be more helpful than renaming the binary file to fram?

Yes, this is a much better solution! Adding a seperate sysfs file page_size 
and a file for the type of device which would read eeprom, fram, etc then.
If you also think this is the way to go, I would spent one of my next free 
timeslots to this.

> > > The method of accessing EEPROMs is used by way more chips than FRAMs.
> > > So, I'd prefer to have the text updated more generic like "EEPROMs and
> > > similar devices like RAMs, ROMs, etc...". Describing setting .flags in
> > > Kconfig is overkill.
> > 
> > A patch updating Kconfig is below.
> 
> Looks good from a glimpse, will apply it later.

Thank you!

Lars

  parent reply	other threads:[~2012-12-07 10:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-04 16:58 [PATCH RFC] misc/at24: distinguish between eeprom and fram chips Lars Poeschel
2012-12-04 18:32 ` Wolfram Sang
     [not found]   ` <20121204183238.GA15067-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-12-05  9:43     ` Lars Poeschel
2012-12-05  9:43       ` Lars Poeschel
     [not found]       ` <201212051043.07460.poeschel-Xtl8qvBWbHwb1SvskN2V4Q@public.gmane.org>
2012-12-05 16:41         ` Wolfram Sang
2012-12-05 16:41           ` Wolfram Sang
     [not found]           ` <20121205164153.GA5011-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-12-07 10:14             ` Lars Poeschel [this message]
2012-12-07 10:14               ` Lars Poeschel
2013-01-24  7:27               ` Wolfram Sang
2013-01-28 10:40                 ` Lars Poeschel
2013-02-06 18:19             ` Lars Poeschel
2013-02-06 18:19               ` Lars Poeschel
     [not found]               ` <201302061919.18501.poeschel-Xtl8qvBWbHwb1SvskN2V4Q@public.gmane.org>
2013-02-10 16:30                 ` Wolfram Sang
2013-02-10 16:30                   ` Wolfram Sang
2013-02-11  8:51                   ` Lars Poeschel

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=201212071114.29034.poeschel@lemonage.de \
    --to=poeschel-xtl8qvbwbhwb1svskn2v4q@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@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 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.