public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamie Iles <jamie@jamieiles.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: Jamie Iles <jamie@jamieiles.com>,
	linux-kernel@vger.kernel.org, gregkh@suse.de
Subject: Re: [RFC PATCHv3 1/4] drivers/otp: add initial support for OTP memory
Date: Fri, 25 Mar 2011 22:47:26 +0000	[thread overview]
Message-ID: <20110325224726.GU3130@pulham.picochip.com> (raw)
In-Reply-To: <AANLkTinLBbKaw=DwVFgORtQ=uA+zkF8QUUKj6uiqLaMw@mail.gmail.com>

Hi Mike,

On Fri, Mar 25, 2011 at 05:58:05PM -0400, Mike Frysinger wrote:
> On Fri, Mar 25, 2011 at 13:14, Jamie Iles wrote:
> > --- /dev/null
> > +++ b/drivers/otp/Kconfig
> > +         may have different characterstics.  This provides a character device
> 
> characterstics -> characteristics

Doh!

> > +if OTP
> > +
> > +config WRITE_ENABLE
> > +       bool "Enable writing support of OTP pages"
> > +       default n
> > +       help
> 
> does this show correctly in the kconfig by putting this under "if otp"
> instead of "depends otp" ?  it should show the write option indented
> rather than at the same level.

I think it's OK because it's a menuconfig thing so the toplevel OTP 
thing is at the same level as misc devices and staging drivers etc.

> > +/* We'll allow OTP devices to be named otpa-otpz. */
> > +#define MAX_OTP_DEVICES                26
> 
> mmm is that still true ?

I think so - the actual devices should be otpa-otpz, but when you 
register regions they could be otpa1, otpa2, otpb1, otpb2 etc.

> 
> > +static unsigned long registered_otp_map[BITS_TO_LONGS(MAX_OTP_DEVICES)];
> > +static DEFINE_MUTEX(otp_register_mutex);
> 
> do we really need this ?  if we let the minor number dictate
> availability, then we can increment until that errors/wraps, and we
> dont need to do any tracking ...

OK, so it would be nice to get rid of this but afaict we still need to 
do some accounting of available minor numbers in the range that we've 
allocated.  We could do a simple increment % 255 for the minor number 
but if OTP devices are removed at runtime then that may get fragmented 
and we would need to do retries of device_register() which feels a bit 
too easy to mess up.

Certainly allocating one major number for OTP devices then allocating 
the minors one by one would be much better than what I have now.

We probably also want it so that if you remove the OTP device that has 
had regions called otpaN then reinsert it they doesn't suddenly become 
otpbN.

> 
> > +       if (fmt == OTP_REDUNDANCY_FMT_SINGLE_ENDED)
> > +               fmt_string = "single-ended";
> > +       else if (fmt == OTP_REDUNDANCY_FMT_REDUNDANT)
> > +               fmt_string = "redundant";
> > +       else if (fmt == OTP_REDUNDANCY_FMT_DIFFERENTIAL)
> > +               fmt_string = "differential";
> > +       else if (fmt == OTP_REDUNDANCY_FMT_DIFFERENTIAL_REDUNDANT)
> > +               fmt_string = "differential-redundant";
> > +       else if (fmt == OTP_REDUNDANCY_FMT_ECC)
> > +               fmt_string = "ecc";
> > +       else
> > +               return -EINVAL;
> 
> i wonder if the code would be simpler if we had a local static array.
> then the show/store funcs would simply walk that tree, and when you
> add a new format in the future, you only have to update one place.
> 
> static const char * const otp_redundancy_str[] = {
> 	[OTP_REDUNDANCY_FMT_SINGLE_ENDED] = "single-ended",
> 	[OTP_REDUNDANCY_FMT_REDUNDANT] = "redundant",
> 	........
> };

Yes, that would be a lot cleaner.

> > +static ssize_t otp_num_regions_show(struct device *dev,
> > +                                   struct device_attribute *attr, char *buf)
> > +{
> > +       int nr_regions;
> > +
> > +       nr_regions = otp_dev->ops->get_nr_regions(otp_dev);
> > +
> > +       if (nr_regions < 0)
> > +               return (ssize_t)nr_regions;
> 
> we could make get_nr_regions() return a ssize_t ...

OK, will do.

> 
> > +       err = alloc_chrdev_region(&otp_dev->devno, 0, max_regions, "otp");
> 
> hmm, i was thinking that we'd have 1 major for otp devices.  isnt this
> how MTD does it ?
> 
> > --- /dev/null
> > +++ b/include/linux/otp.h
> > +/**
> > + * enum otp_device_flags - Flags to indicate capabilities for the OTP device.
> > + *
> > + * @OTP_DEVICE_FNO_SUBWORD_WRITE:      only full word sized writes may be
> > + *                                     performed.  Don't use
> > + *                                     read-modify-write cycles for
> > + *                                     performing unaligned writes.
> > + */
> > +enum otp_device_flags {
> > +       OTP_DEVICE_FNO_SUBWORD_WRITE    = (1 << 0),
> > +};
> 
> use OTP_CAPS_xxx instead ?

Sounds like a plan!  Thanks again for the review!

Jamie

  reply	other threads:[~2011-03-25 22:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-25 17:14 [RFC PATCHv3 0/4] Support for OTP memory Jamie Iles
2011-03-25 17:14 ` [RFC PATCHv3 1/4] drivers/otp: add initial support " Jamie Iles
2011-03-25 21:58   ` Mike Frysinger
2011-03-25 22:47     ` Jamie Iles [this message]
2011-03-25 22:50       ` Mike Frysinger
2011-03-25 22:55         ` Jamie Iles
2011-03-25 22:58           ` Mike Frysinger
2011-03-25 17:14 ` [RFC PATCHv3 2/4] drivers/otp: add support for Picoxcell PC3X3 OTP Jamie Iles
2011-03-25 17:14 ` [RFC PATCHv3 3/4] drivers/otp: convert bfin otp to generic OTP Jamie Iles
2011-03-25 22:56   ` Mike Frysinger
2011-03-26  0:11     ` Jamie Iles
2011-03-26  2:11       ` Mike Frysinger
2011-03-26  2:32         ` Jamie Iles
2011-03-26  2:55           ` Mike Frysinger
2011-03-25 17:14 ` [RFC PATCHv3 4/4] Blackfin: add the OTP device as a platform device Jamie Iles
2011-03-25 21:37   ` Mike Frysinger

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=20110325224726.GU3130@pulham.picochip.com \
    --to=jamie@jamieiles.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vapier@gentoo.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