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 3/4] drivers/otp: convert bfin otp to generic OTP
Date: Sat, 26 Mar 2011 00:11:43 +0000	[thread overview]
Message-ID: <20110326001143.GX3130@pulham.picochip.com> (raw)
In-Reply-To: <AANLkTin+Uvw8=CN+2oawAUHGot8gdM5u98S4zC8QoB=u@mail.gmail.com>

On Fri, Mar 25, 2011 at 06:56:03PM -0400, Mike Frysinger wrote:
> On Fri, Mar 25, 2011 at 13:14, Jamie Iles wrote:
> > +       /*
> > +        * Skip the control pages then if we would run into the ECC area skip
> > +        * past to the next data region.
> > +        */
> > +       raw_addr = region_addr + control_words;
> > +       if (raw_addr > 0x80 * BFIN_OTP_WORDS_PER_PAGE)
> > +               raw_addr += 0x20 * BFIN_OTP_WORDS_PER_PAGE;
> 
> mmm, no, we dont want to do that.  the Blackfin documentation is very
> exact when it maps out pages, and we want the driver to match the
> documentation.
> 
> but i guess in the other discussion we had, this would be removed anyways.

OK, so in that case could we initially have:

	- region for control bits
	- region for the first data bits
	- region for the ecc for the first data
	- region for the second data bits
	- region for the ecc for the second data

or shall I just leave it as one big region for now?

> 
> > +static int bfin_region_write_word(struct otp_region *region, unsigned long addr,
> > +                                 u64 content)
> > +{
> > +       return -EACCES;
> > +}
> 
> i think we'd just stub this out as NULL and let the common layer take
> care of rejecting it ?

Yes, that's probably best.  At least we're always building the whole 
driver then.

> 
> > +static const struct otp_device_ops bfin_otp_ops = {
> > +       .name           = "BFIN",
> 
> guess this should be "bfin-otp"

Good spot.

> 
> > +static const struct otp_region_ops bfin_region_ops = {
> > +       .read_word      = bfin_region_read_word,
> > +       .write_word     = bfin_region_write_word,
> > +       .get_size       = bfin_region_get_size,
> > +       .get_fmt        = bfin_region_get_fmt,
> > +       .ioctl          = bfin_region_ioctl,
> > +};
> 
> hmm, i just realized this stuff is per-region.  wouldnt the
> read/write/ioctl make more sense as per-device ?

No, I don't think so.  The file_operations are all based on the regions 
rather than the device so I think it makes sense to have these as region 
based operations.  We could make them per device and pass the region as 
a parameter but I'm not sure that it gains us anything.

Jamie

  reply	other threads:[~2011-03-26  0:11 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
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 [this message]
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=20110326001143.GX3130@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.