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

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

[David Brownell]

From: David Brownell <dbrownell@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.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 drivers/mtd/devices/m25p80.c        |    2 ++
 drivers/mtd/devices/mtd_dataflash.c |    2 ++
 drivers/mtd/maps/omap_nor.c         |    2 ++
 drivers/mtd/maps/physmap.c          |    1 +
 drivers/mtd/maps/plat-ram.c         |    1 +
 drivers/mtd/nand/davinci_nand.c     |    2 ++
 drivers/mtd/nand/mxc_nand.c         |    1 +
 drivers/mtd/onenand/omap2.c         |    2 ++
 8 files changed, 13 insertions(+)

--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -678,6 +678,8 @@ static int __devinit m25p_probe(struct s
 		flash->mtd.erasesize = info->sector_size;
 	}
 
+	flash->mtd.dev.parent = &spi->dev;
+
 	dev_info(&spi->dev, "%s (%lld Kbytes)\n", info->name,
 			(long long)flash->mtd.size >> 10);
 
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -670,6 +670,8 @@ add_dataflash_otp(struct spi_device *spi
 	device->write = dataflash_write;
 	device->priv = priv;
 
+	device->dev.parent = &spi->dev;
+
 	if (revision >= 'c')
 		otp_tag = otp_setup(device, revision);
 
--- a/drivers/mtd/maps/omap_nor.c
+++ b/drivers/mtd/maps/omap_nor.c
@@ -115,6 +115,8 @@ static int __init omapflash_probe(struct
 	}
 	info->mtd->owner = THIS_MODULE;
 
+	info->mtd->dev.parent = &pdev->dev;
+
 #ifdef CONFIG_MTD_PARTITIONS
 	err = parse_mtd_partitions(info->mtd, part_probes, &info->parts, 0);
 	if (err > 0)
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -147,6 +147,7 @@ static int physmap_flash_probe(struct pl
 			devices_found++;
 		}
 		info->mtd[i]->owner = THIS_MODULE;
+		info->mtd[i]->dev.parent = &dev->dev;
 	}
 
 	if (devices_found == 1) {
--- a/drivers/mtd/maps/plat-ram.c
+++ b/drivers/mtd/maps/plat-ram.c
@@ -224,6 +224,7 @@ static int platram_probe(struct platform
 	}
 
 	info->mtd->owner = THIS_MODULE;
+	info->mtd->dev.parent = &pdev->dev;
 
 	platram_setrw(info, PLATRAM_RW);
 
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -358,6 +358,8 @@ static int __init nand_davinci_probe(str
 	info->mtd.name		= dev_name(&pdev->dev);
 	info->mtd.owner		= THIS_MODULE;
 
+	info->mtd.dev.parent	= &pdev->dev;
+
 	info->chip.IO_ADDR_R	= vaddr;
 	info->chip.IO_ADDR_W	= vaddr;
 	info->chip.chip_delay	= 0;
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -866,6 +866,7 @@ static int __init mxcnd_probe(struct pla
 	mtd = &host->mtd;
 	mtd->priv = this;
 	mtd->owner = THIS_MODULE;
+	mtd->dev.parent = &pdev->dev;
 
 	/* 50 us command delay time */
 	this->chip_delay = 5;
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -672,6 +672,8 @@ static int __devinit omap2_onenand_probe
 	c->mtd.priv = &c->onenand;
 	c->mtd.owner = THIS_MODULE;
 
+	c->mtd.dev.parent = &pdev->dev;
+
 	if (c->dma_channel >= 0) {
 		struct onenand_chip *this = &c->onenand;
 

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

[Artem Bityutskiy]

On Thu, 2009-03-26 at 00:42 -0700, David Brownell wrote:
> From: David Brownell <dbrownell@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
> @@ -866,6 +866,7 @@ 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 (Битюцкий Артём)

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

[Artem Bityutskiy]

On Thu, 2009-03-26 at 00:42 -0700, David Brownell wrote:
> From: David Brownell <dbrownell@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
> @@ -866,6 +866,7 @@ 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 (Битюцкий Артём)

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

[David Brownell]

On Tuesday 31 March 2009, Artem Bityutskiy wrote:
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> > @@ -866,6 +866,7 @@ 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

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

[David Brownell]

On Tuesday 31 March 2009, Artem Bityutskiy wrote:
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> > @@ -866,6 +866,7 @@ 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

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

[Vitaly Wool]

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

Why would it be reasonable?

Thanks,
   Vitaly

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

[Artem Bityutskiy]

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
> > > @@ -866,6 +866,7 @@ 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@infradead.org>

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

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

[Artem Bityutskiy]

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
> > > @@ -866,6 +866,7 @@ 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@infradead.org>

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

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

[David Brownell]

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@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

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

[David Brownell]

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@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

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

[Artem Bityutskiy]

On Tue, 2009-03-31 at 23:42 -0700, David Brownell wrote:
> 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@infradead.org>
> 
> Thanks.  I'll expect someone to handle getting these
> merged through the MTD tree, then.

David Woodhouse maintains the MTD tree. He saw your patches,
not sure when he takes them.

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

If he merges them during this merge window, then this might
not be the case :-)

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

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

[Artem Bityutskiy]

On Tue, 2009-03-31 at 23:42 -0700, David Brownell wrote:
> 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@infradead.org>
> 
> Thanks.  I'll expect someone to handle getting these
> merged through the MTD tree, then.

David Woodhouse maintains the MTD tree. He saw your patches,
not sure when he takes them.

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

If he merges them during this merge window, then this might
not be the case :-)

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