linux-kernel - Re: [RFC PATCHv3 3/4] drivers/otp: convert bfin otp to generic OTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 Mar 2011 00:11:43 +0000
From:	Jamie Iles <jamie@...ieiles.com>
To:	Mike Frysinger <vapier@...too.org>
Cc:	Jamie Iles <jamie@...ieiles.com>, linux-kernel@...r.kernel.org,
	gregkh@...e.de
Subject: Re: [RFC PATCHv3 3/4] drivers/otp: convert bfin otp to generic OTP

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/