All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Iles <jamie@jamieiles.com>
To: linux-kernel@vger.kernel.org
Cc: Greg KH <gregkh@suse.de>
Subject: Re: [RFC PATCH 1/2] picoxcell-otp: add support for picoxcell OTP devices
Date: Thu, 24 Mar 2011 09:30:36 +0000	[thread overview]
Message-ID: <20110324093035.GA3130@pulham.picochip.com> (raw)
In-Reply-To: <20110323151242.GC2795@pulham.picochip.com>

Replying to myself...

On Wed, Mar 23, 2011 at 03:12:42PM +0000, Jamie Iles wrote:
> On Wed, Mar 23, 2011 at 07:42:30AM -0700, Greg KH wrote:
> > On Wed, Mar 23, 2011 at 12:16:58PM +0000, Jamie Iles wrote:
> > > +What:           /sys/bus/picoxcell-otp/devices/.../size
> > > +Date:           March 2011
> > > +KernelVersion:  2.6.40+
> > > +Contact:        Jamie Iles <jamie@jamieiles.com>
> > > +Description:
> > > +                The effective storage size of the region. This is the amount
> > > +		of data that a user can store in the region taking into
> > > +		account the number of regions and the redundancy format of the
> > > +		region itself.
> > > diff --git a/Documentation/ABI/testing/sysfs-platform-picoxcell-otp b/Documentation/ABI/testing/sysfs-platform-picoxcell-otp
> > > new file mode 100644
> > > index 0000000..e5ee711
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-platform-picoxcell-otp
> > > @@ -0,0 +1,39 @@
> > > +What:		/sys/devices/platform/picoxcell-otp*/write_enable
> > 
> > Why are these in a platform subdirectory?  Shouldn't they be the devices
> > listed above in the previous file?
> 
> So the way I have it is that there is the real OTP device which can be 
> split into a number of regions.  These attributes affect the physical 
> device by programming the number of regions and write enable.
> 
> Each region is a virtual device to provide the character device and the 
> redundancy/size attributes but you can't split these regions down again.

[...]

> > > +/*
> > > + * Add all of the device entries to sysfs. This also includes creating the
> > > + * region device nodes and sysfs entries.
> > > + */
> > > +static int otp_sysfs_add(struct device *dev)
> > > +{
> > > +	int err;
> > > +
> > > +	err = device_create_file(dev, &dev_attr_write_enable);
> > > +	if (err)
> > > +		goto out;
> > > +
> > > +	err = device_create_file(dev, &dev_attr_num_regions);
> > > +	if (err)
> > > +		goto num_regions_fail;
> > > +
> > > +	err = device_create_file(dev, &dev_attr_bad_words);
> > > +	if (err)
> > > +		goto bad_words_fail;
> > > +
> > > +	err = device_create_file(dev, &dev_attr_strict_programming);
> > > +	if (err)
> > > +		goto strict_programming_fail;
> > > +
> > 
> > Shouldn't all of these be in an attribute group like the other sysfs
> > files are in this driver?  That way you add/remove them all at once.
> 
> I did look at doing this but I couldn't see a way to add an attribute 
> group to an existing device in a single step, or is this just the 
> wrong approach all together?

So the crucial thing I was missing was the device_type part of the 
driver model.  I'm now creating a virtual "otpa" device that is in the 
"otp" bus and has the regions has virtual child devices.   Both of these 
virtual devices have different device_types that have different 
attributes so that fits in very nicely.

Jamie

  reply	other threads:[~2011-03-24  9:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-23 12:16 [RFC PATCH 0/2] Support for picoxcell OTP memory Jamie Iles
2011-03-23 12:16 ` [RFC PATCH 1/2] picoxcell-otp: add support for picoxcell OTP devices Jamie Iles
2011-03-23 14:42   ` Greg KH
2011-03-23 15:12     ` Jamie Iles
2011-03-24  9:30       ` Jamie Iles [this message]
2011-04-02 22:15     ` Thomas Gleixner
2011-03-23 12:16 ` [RFC PATCH 2/2] picoxcellotp: add support for PC3X3 " Jamie Iles

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=20110324093035.GA3130@pulham.picochip.com \
    --to=jamie@jamieiles.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.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.