From: David Brownell <[email protected]>
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 <[email protected]>
---
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;
On Thu, 2009-03-26 at 00:42 -0700, David Brownell wrote:
> From: David Brownell <[email protected]>
>
> 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 (Битюцкий Артём)
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
> Could this be done for all NANDs in nand_base.c instead?
Why would it be reasonable?
Thanks,
Vitaly
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 <[email protected]>
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
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 <[email protected]>
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
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 <[email protected]>
>
> 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 (Битюцкий Артём)