* [patch/rfc 2.6.29 2/2] MTD: support driver model updates [not found] <200903260039.34013.david-b@pacbell.net> @ 2009-03-26 7:42 ` David Brownell 2009-04-01 5:46 ` Artem Bityutskiy 0 siblings, 1 reply; 12+ messages in thread From: David Brownell @ 2009-03-26 7:42 UTC (permalink / raw) To: Linux MTD, LKML; +Cc: Kay Sievers 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; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates 2009-03-26 7:42 ` [patch/rfc 2.6.29 2/2] MTD: support driver model updates David Brownell @ 2009-04-01 5:46 ` Artem Bityutskiy 0 siblings, 0 replies; 12+ messages in thread From: Artem Bityutskiy @ 2009-04-01 5:46 UTC (permalink / raw) To: David Brownell; +Cc: Kay Sievers, Linux MTD, LKML 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 (Битюцкий Артём) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates @ 2009-04-01 5:46 ` Artem Bityutskiy 0 siblings, 0 replies; 12+ messages in thread From: Artem Bityutskiy @ 2009-04-01 5:46 UTC (permalink / raw) To: David Brownell; +Cc: Linux MTD, LKML, Kay Sievers 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 (Битюцкий Артём) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates 2009-04-01 5:46 ` Artem Bityutskiy @ 2009-04-01 5:57 ` David Brownell -1 siblings, 0 replies; 12+ messages in thread From: David Brownell @ 2009-04-01 5:57 UTC (permalink / raw) To: dedekind; +Cc: Kay Sievers, Linux MTD, LKML 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates @ 2009-04-01 5:57 ` David Brownell 0 siblings, 0 replies; 12+ messages in thread From: David Brownell @ 2009-04-01 5:57 UTC (permalink / raw) To: dedekind; +Cc: Linux MTD, LKML, Kay Sievers 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates 2009-04-01 5:57 ` David Brownell @ 2009-04-01 6:10 ` Artem Bityutskiy -1 siblings, 0 replies; 12+ messages in thread From: Artem Bityutskiy @ 2009-04-01 6:10 UTC (permalink / raw) To: David Brownell; +Cc: Kay Sievers, Linux MTD, LKML 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 (Битюцкий Артём) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates @ 2009-04-01 6:10 ` Artem Bityutskiy 0 siblings, 0 replies; 12+ messages in thread From: Artem Bityutskiy @ 2009-04-01 6:10 UTC (permalink / raw) To: David Brownell; +Cc: Linux MTD, LKML, Kay Sievers 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 (Битюцкий Артём) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates 2009-04-01 6:10 ` Artem Bityutskiy @ 2009-04-01 6:42 ` David Brownell -1 siblings, 0 replies; 12+ messages in thread From: David Brownell @ 2009-04-01 6:42 UTC (permalink / raw) To: dedekind; +Cc: Kay Sievers, Linux MTD, LKML 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates @ 2009-04-01 6:42 ` David Brownell 0 siblings, 0 replies; 12+ messages in thread From: David Brownell @ 2009-04-01 6:42 UTC (permalink / raw) To: dedekind; +Cc: Linux MTD, LKML, Kay Sievers 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates 2009-04-01 6:42 ` David Brownell @ 2009-04-01 6:48 ` Artem Bityutskiy -1 siblings, 0 replies; 12+ messages in thread From: Artem Bityutskiy @ 2009-04-01 6:48 UTC (permalink / raw) To: David Brownell; +Cc: Kay Sievers, Linux MTD, LKML 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 (Битюцкий Артём) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates @ 2009-04-01 6:48 ` Artem Bityutskiy 0 siblings, 0 replies; 12+ messages in thread From: Artem Bityutskiy @ 2009-04-01 6:48 UTC (permalink / raw) To: David Brownell; +Cc: Linux MTD, LKML, Kay Sievers 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 (Битюцкий Артём) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch/rfc 2.6.29 2/2] MTD: support driver model updates 2009-04-01 5:46 ` Artem Bityutskiy (?) (?) @ 2009-04-01 6:08 ` Vitaly Wool -1 siblings, 0 replies; 12+ messages in thread From: Vitaly Wool @ 2009-04-01 6:08 UTC (permalink / raw) To: dedekind; +Cc: David Brownell, Kay Sievers, Linux MTD, LKML > Could this be done for all NANDs in nand_base.c instead? Why would it be reasonable? Thanks, Vitaly ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-04-01 6:49 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200903260039.34013.david-b@pacbell.net>
2009-03-26 7:42 ` [patch/rfc 2.6.29 2/2] MTD: support driver model updates David Brownell
2009-04-01 5:46 ` Artem Bityutskiy
2009-04-01 5:46 ` Artem Bityutskiy
2009-04-01 5:57 ` David Brownell
2009-04-01 5:57 ` David Brownell
2009-04-01 6:10 ` Artem Bityutskiy
2009-04-01 6:10 ` Artem Bityutskiy
2009-04-01 6:42 ` David Brownell
2009-04-01 6:42 ` David Brownell
2009-04-01 6:48 ` Artem Bityutskiy
2009-04-01 6:48 ` Artem Bityutskiy
2009-04-01 6:08 ` Vitaly Wool
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.