headers
Kay Sievers | 1 Apr 2009 01:51

Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

On Tue, Mar 31, 2009 at 23:18, David Brownell <david-b <at> pacbell.net> wrote:
> On Thursday 26 March 2009, David Brownell wrote:
>> From: David Brownell <dbrownell <at> users.sourceforge.net>
>>
>> Update driver model support in the MTD framework, so it fits
>> better into the current udev-based hotplug framework:
>
> Hmm, no comments?  I had understood there was interest over on
> the MTD side of things in exposing more information through
> sysfs, to help avoid the need to add Even More Ioctls as part
> of support for things like NAND chips with 4KB pages, or which
> handle more than 4GBytes ...

Please have a look at this. We got asked repeatedly to provide better
hotplug/udev integration, and the patches, and having the parent
device properly assigned, would solve some of the problems people run
into currently.

Thanks,
Kay
Permalink | Reply | 2 comments |
headers
Kevin Cernekee | 1 Apr 2009 03:17
Picon

Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

On Tue, Mar 31, 2009 at 2:18 PM, David Brownell <david-b <at> pacbell.net> wrote:
> Hmm, no comments?  I had understood there was interest over on
> the MTD side of things in exposing more information through
> sysfs, to help avoid the need to add Even More Ioctls as part
> of support for things like NAND chips with 4KB pages, or which
> handle more than 4GBytes ...

Based on this post:
http://lists.infradead.org/pipermail/linux-mtd/2009-March/025060.html

I am inferring that the following attributes are wanted in the MTD
sysfs interface:

1) mtd_info_user fields - type, flags, size, erasesize, writesize,
oobsize.  So far we have "type," but it should be easy to add the
rest.

2) region_info_user fields?  Not really sure how this would work.
Maybe a separate subdirectory for each region?
Permalink | Reply | 6 comments |
headers
David Brownell | 1 Apr 2009 05:21

Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

On Tuesday 31 March 2009, Kevin Cernekee wrote:
> On Tue, Mar 31, 2009 at 2:18 PM, David Brownell <david-b <at> pacbell.net> wrote:
> > Hmm, no comments?  I had understood there was interest over on
> > the MTD side of things in exposing more information through
> > sysfs, to help avoid the need to add Even More Ioctls as part
> > of support for things like NAND chips with 4KB pages, or which
> > handle more than 4GBytes ...
> 
> Based on this post:
> http://lists.infradead.org/pipermail/linux-mtd/2009-March/025060.html
> 
> I am inferring that the following attributes are wanted in the MTD
> sysfs interface:
> 
> 1) mtd_info_user fields - type, flags, size, erasesize, writesize,
> oobsize.  So far we have "type," but it should be easy to add the
> rest.

Yes, easy to add those.  As noted in the $SUBJECT patch, the set
consisting of just "type" is a "starter set".  :)

For procfs elimination, a name/label would be needed too; that can
be an input to, or output from, cmdlinepart.

My question about the $SUBJECT patch is whether there's any reason
not to use that as the start of such driver model enhancements.
I'm thinking the answer to that seems to be "no", and that someone
more involved in *using* those sysfs attributes would be a better
choice for growing that set of attributes.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kevin Cernekee | 1 Apr 2009 06:49
Picon

Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

On 3/31/09, David Brownell <david-b <at> pacbell.net> wrote:
>> 2) region_info_user fields?  Not really sure how this would work.
>> Maybe a separate subdirectory for each region?
>
> I'm not sure I've ever had reason to care about a "region" (whatever
> that is!) with MTD hardware.

Erase Block Regions.  From the CFI spec:

"x specifies the number of regions within the device containing one or
more contiguous Erase Blocks of the same size.  For example, a 128KB
device (1Mb) having blocking of 16KB, 8KB, four 2KB, two 16KB, and one
64KB is considered to have 5 Erase Block Regions."

This is fairly common on parallel NOR devices.  Probably less so on
huge NAND devices.

> I suspect that a lot of interesting questions could come up in
> the context of enhancing mtd-utils to work with sysfs and bigger
> NAND chips.  Some might relate to "regions".

Right, this sysfs requirement raises a number of issues that need to
be fully thought out in order to make sure the new interface is a
suitable replacement for the "INFO" ioctls.  For instance:

1) If each region is a subdirectory, are user programs supposed to use
readdir() to count them?  Is ioctl(MEMGETREGIONCOUNT) still the
preferred method?  Or do we make a new "regioncount" sysfs attribute?

(A somewhat related question is whether MEMGETREGIONCOUNT only exists
(Continue reading)

Permalink | Reply | 2 comments |
headers
Artem Bityutskiy | 1 Apr 2009 07:46
Favicon

Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates

On Thu, 2009-03-26 at 00:42 -0700, David Brownell wrote:
> From: David Brownell <dbrownell <at> users.sourceforge.net>
> 
> Follow-on patch to the previous driver model patch for the MTD
> framework.  This one makes various MTD drivers connect to the
> driver model tree, so /sys/devices/virtual/mtd/* nodes are no
> longer present ... mostly drivers used on boards I have handy.
> 
> Based on a patch from Kay Sievers.

...

> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
>  <at>  <at>  -866,6 +866,7  <at>  <at>  static int __init mxcnd_probe(struct pla
>  	mtd = &host->mtd;
>  	mtd->priv = this;
>  	mtd->owner = THIS_MODULE;
> +	mtd->dev.parent = &pdev->dev;

Could this be done for all NANDs in nand_base.c instead?

--

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)
Permalink | Reply | 10 comments |
headers
David Brownell | 1 Apr 2009 07:57

Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates

On Tuesday 31 March 2009, Artem Bityutskiy wrote:
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> >  <at>  <at>  -866,6 +866,7  <at>  <at>  static int __init mxcnd_probe(struct pla
> >       mtd = &host->mtd;
> >       mtd->priv = this;
> >       mtd->owner = THIS_MODULE;
> > +     mtd->dev.parent = &pdev->dev;
> 
> Could this be done for all NANDs in nand_base.c instead?

By adding the device as a parameter to nand_scan(),
and presumably nand_scan_ident() ... which is a more
invasive API change, and would require a "flag day"
to convert all drivers.

My default assumption for API changes is to avoid
flag days.  They can be done, yes, but I don't see
a compelling reason to choose one here.

- Dave
Permalink | Reply | 6 comments |
headers
Vitaly Wool | 1 Apr 2009 08:08
Picon

Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates

> Could this be done for all NANDs in nand_base.c instead?

Why would it be reasonable?

Thanks,
   Vitaly
Permalink | Reply | 0 comments |
headers
Artem Bityutskiy | 1 Apr 2009 08:10
Favicon

Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates

On Tue, 2009-03-31 at 22:57 -0700, David Brownell wrote:
> On Tuesday 31 March 2009, Artem Bityutskiy wrote:
> > > --- a/drivers/mtd/nand/mxc_nand.c
> > > +++ b/drivers/mtd/nand/mxc_nand.c
> > >  <at>  <at>  -866,6 +866,7  <at>  <at>  static int __init mxcnd_probe(struct pla
> > >       mtd = &host->mtd;
> > >       mtd->priv = this;
> > >       mtd->owner = THIS_MODULE;
> > > +     mtd->dev.parent = &pdev->dev;
> > 
> > Could this be done for all NANDs in nand_base.c instead?
> 
> By adding the device as a parameter to nand_scan(),
> and presumably nand_scan_ident() ... which is a more
> invasive API change, and would require a "flag day"
> to convert all drivers.
> 
> My default assumption for API changes is to avoid
> flag days.  They can be done, yes, but I don't see
> a compelling reason to choose one here.

OK. MTD long needs sysfs, and I'm very happy with this
patches, even though they are not 100% complete. Good
start anyway.

Acked-by: Artem Bityutskiy <dedekind <at> infradead.org>

--

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Brownell | 1 Apr 2009 08:36

Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

On Tuesday 31 March 2009, Kevin Cernekee wrote:
> On 3/31/09, David Brownell <david-b <at> pacbell.net> wrote:
> >> 2) region_info_user fields?  Not really sure how this would work.
> >> Maybe a separate subdirectory for each region?
> >
> > I'm not sure I've ever had reason to care about a "region" (whatever
> > that is!) with MTD hardware.
> 
> Erase Block Regions.  From the CFI spec:
> 
> ...
> 
> This is fairly common on parallel NOR devices.  Probably less so on
> huge NAND devices.

Oh, that.  Right.  Few new boards I've seen in the past few
years have NOR; it's mostly NAND nowadays.  That gets mixed
up with bootblocks too ... as in, store u-boot parameters in
a 4K erase block (surrounded by u-boot code) instead of some
dedicated 128K block that's almost entirely unused.

> > I suspect that a lot of interesting questions could come up in
> > the context of enhancing mtd-utils to work with sysfs and bigger
> > NAND chips.  Some might relate to "regions".
> 
> Right, this sysfs requirement raises a number of issues that need to
> be fully thought out in order to make sure the new interface is a
> suitable replacement for the "INFO" ioctls.

Hmm, it's the same as the *current* sysfs model for chardevs, except
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brownell | 1 Apr 2009 08:42

Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates

On Tuesday 31 March 2009, Artem Bityutskiy wrote:
> OK. MTD long needs sysfs, and I'm very happy with this
> patches, even though they are not 100% complete. Good
> start anyway.
> 
> Acked-by: Artem Bityutskiy <dedekind <at> infradead.org>

Thanks.  I'll expect someone to handle getting these
merged through the MTD tree, then.

And I'll be rather surprised if no more attributes
appear by the time this gets to mainline!  :)

- Dave
Permalink | Reply | 2 comments |

Gmane