All of lore.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:55:23 +0000	[thread overview]
Message-ID: <20110325225523.GW3130@pulham.picochip.com> (raw)
In-Reply-To: <AANLkTi=XGNdLq4=cp3iv++rg=yXUVsp4mjcW7CVuQZUV@mail.gmail.com>

On Fri, Mar 25, 2011 at 06:50:36PM -0400, Mike Frysinger wrote:
> On Fri, Mar 25, 2011 at 18:47, Jamie Iles wrote:
> > On Fri, Mar 25, 2011 at 05:58:05PM -0400, Mike Frysinger wrote:
> >> On Fri, Mar 25, 2011 at 13:14, Jamie Iles wrote:
> >> > +/* 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.
> 
> yeah that's true.  guess i'll leave it be then ;).

OK, but it still might be worth pruning it down to a single major number 
or is that something worth doing later on if it becomes needed?

> whatever naming is picked in /dev/ should match the stuff in /sys/ btw ...

I think that's working ok.  On my system I have:

	/sys/bus/otp/devices/otpa/otpa1/
	/sys/bus/otp/devices/otpa/otpa2/

and

	/dev/otpa1
	/dev/otpa2

Jamie

  reply	other threads:[~2011-03-25 22:55 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
2011-03-25 22:50       ` Mike Frysinger
2011-03-25 22:55         ` Jamie Iles [this message]
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=20110325225523.GW3130@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 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.