These three platforms didn't properly fill nr_chips in gen_nand registration and
therefore depended on gen_nand bug fixed by the following patch:
"mtd: gen_nand: fix support for multiple chips"
Signed-off-by: Marek Vasut <[email protected]>
---
v2: Added other broken boards outside arch-arm (mips and bfin)
v1: Initial patch
arch/arm/mach-ixp4xx/ixdp425-setup.c | 1 +
arch/arm/mach-mx3/mach-qong.c | 1 +
arch/arm/mach-orion5x/ts78xx-setup.c | 1 +
arch/blackfin/mach-bf537/boards/stamp.c | 1 +
arch/blackfin/mach-bf561/boards/acvilon.c | 1 +
arch/mips/nxp/pnx833x/common/platform.c | 1 +
6 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index 827cbc4..ea9ee4e 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -100,6 +100,7 @@ ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
static struct platform_nand_data ixdp425_flash_nand_data = {
.chip = {
+ .nr_chips = 1,
.chip_delay = 30,
.options = NAND_NO_AUTOINCR,
#ifdef CONFIG_MTD_PARTITIONS
diff --git a/arch/arm/mach-mx3/mach-qong.c b/arch/arm/mach-mx3/mach-qong.c
index e5b5b83..1f9363f 100644
--- a/arch/arm/mach-mx3/mach-qong.c
+++ b/arch/arm/mach-mx3/mach-qong.c
@@ -169,6 +169,7 @@ static void qong_nand_select_chip(struct mtd_info *mtd, int chip)
static struct platform_nand_data qong_nand_data = {
.chip = {
+ .nr_chips = 1,
.chip_delay = 20,
.options = 0,
},
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
index 5041d1b..696b1a9 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -216,6 +216,7 @@ static struct mtd_partition ts78xx_ts_nand_parts[] = {
static struct platform_nand_data ts78xx_ts_nand_data = {
.chip = {
+ .nr_chips = 1,
.part_probe_types = ts_nand_part_probes,
.partitions = ts78xx_ts_nand_parts,
.nr_partitions = ARRAY_SIZE(ts78xx_ts_nand_parts),
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c b/arch/blackfin/mach-bf537/boards/stamp.c
index 9eaf5b0..68a27bc 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -400,6 +400,7 @@ static int bfin_plat_nand_dev_ready(struct mtd_info *mtd)
static struct platform_nand_data bfin_plat_nand_data = {
.chip = {
+ .nr_chips = 1,
.chip_delay = 30,
#ifdef CONFIG_MTD_PARTITIONS
.part_probe_types = part_probes,
diff --git a/arch/blackfin/mach-bf561/boards/acvilon.c b/arch/blackfin/mach-bf561/boards/acvilon.c
index bfcfa86..35b6d12 100644
--- a/arch/blackfin/mach-bf561/boards/acvilon.c
+++ b/arch/blackfin/mach-bf561/boards/acvilon.c
@@ -284,6 +284,7 @@ static int bfin_plat_nand_dev_ready(struct mtd_info *mtd)
static struct platform_nand_data bfin_plat_nand_data = {
.chip = {
+ .nr_chips = 1,
.chip_delay = 30,
#ifdef CONFIG_MTD_PARTITIONS
.part_probe_types = part_probes,
diff --git a/arch/mips/nxp/pnx833x/common/platform.c b/arch/mips/nxp/pnx833x/common/platform.c
index 01f8345..ce45df1 100644
--- a/arch/mips/nxp/pnx833x/common/platform.c
+++ b/arch/mips/nxp/pnx833x/common/platform.c
@@ -266,6 +266,7 @@ pnx833x_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
static struct platform_nand_data pnx833x_flash_nand_data = {
.chip = {
+ .nr_chips = 1,
.chip_delay = 25,
.part_probe_types = part_probes,
},
--
1.7.1
Signed-off-by: Marek Vasut <[email protected]>
---
drivers/mtd/nand/plat_nand.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/plat_nand.c b/drivers/mtd/nand/plat_nand.c
index 90e143e..317aff4 100644
--- a/drivers/mtd/nand/plat_nand.c
+++ b/drivers/mtd/nand/plat_nand.c
@@ -37,6 +37,11 @@ static int __devinit plat_nand_probe(struct platform_device *pdev)
struct resource *res;
int err = 0;
+ if (pdata->chip.nr_chips < 1) {
+ dev_err(&pdev->dev, "invalid number of chips specified\n");
+ return -EINVAL;
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
--
1.7.1
Dne Čt 12. srpna 2010 04:53:54 Marek Vasut napsal(a):
> These three platforms didn't properly fill nr_chips in gen_nand
> registration and therefore depended on gen_nand bug fixed by the following
> patch:
>
NOTE for bfin guys: I'm slightly concerned about overall code quality on the
BFIN architecture. Maybe someone should run it through checkpatch or something.
> "mtd: gen_nand: fix support for multiple chips"
>
> Signed-off-by: Marek Vasut <[email protected]>
> ---
> v2: Added other broken boards outside arch-arm (mips and bfin)
> v1: Initial patch
>
> arch/arm/mach-ixp4xx/ixdp425-setup.c | 1 +
> arch/arm/mach-mx3/mach-qong.c | 1 +
> arch/arm/mach-orion5x/ts78xx-setup.c | 1 +
> arch/blackfin/mach-bf537/boards/stamp.c | 1 +
> arch/blackfin/mach-bf561/boards/acvilon.c | 1 +
> arch/mips/nxp/pnx833x/common/platform.c | 1 +
> 6 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> b/arch/arm/mach-ixp4xx/ixdp425-setup.c index 827cbc4..ea9ee4e 100644
> --- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> +++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> @@ -100,6 +100,7 @@ ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int
> cmd, unsigned int ctrl)
>
> static struct platform_nand_data ixdp425_flash_nand_data = {
> .chip = {
> + .nr_chips = 1,
> .chip_delay = 30,
> .options = NAND_NO_AUTOINCR,
> #ifdef CONFIG_MTD_PARTITIONS
> diff --git a/arch/arm/mach-mx3/mach-qong.c b/arch/arm/mach-mx3/mach-qong.c
> index e5b5b83..1f9363f 100644
> --- a/arch/arm/mach-mx3/mach-qong.c
> +++ b/arch/arm/mach-mx3/mach-qong.c
> @@ -169,6 +169,7 @@ static void qong_nand_select_chip(struct mtd_info *mtd,
> int chip)
>
> static struct platform_nand_data qong_nand_data = {
> .chip = {
> + .nr_chips = 1,
> .chip_delay = 20,
> .options = 0,
> },
> diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c
> b/arch/arm/mach-orion5x/ts78xx-setup.c index 5041d1b..696b1a9 100644
> --- a/arch/arm/mach-orion5x/ts78xx-setup.c
> +++ b/arch/arm/mach-orion5x/ts78xx-setup.c
> @@ -216,6 +216,7 @@ static struct mtd_partition ts78xx_ts_nand_parts[] = {
>
> static struct platform_nand_data ts78xx_ts_nand_data = {
> .chip = {
> + .nr_chips = 1,
> .part_probe_types = ts_nand_part_probes,
> .partitions = ts78xx_ts_nand_parts,
> .nr_partitions = ARRAY_SIZE(ts78xx_ts_nand_parts),
> diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
> b/arch/blackfin/mach-bf537/boards/stamp.c index 9eaf5b0..68a27bc 100644
> --- a/arch/blackfin/mach-bf537/boards/stamp.c
> +++ b/arch/blackfin/mach-bf537/boards/stamp.c
> @@ -400,6 +400,7 @@ static int bfin_plat_nand_dev_ready(struct mtd_info
> *mtd)
>
> static struct platform_nand_data bfin_plat_nand_data = {
> .chip = {
> + .nr_chips = 1,
> .chip_delay = 30,
> #ifdef CONFIG_MTD_PARTITIONS
> .part_probe_types = part_probes,
> diff --git a/arch/blackfin/mach-bf561/boards/acvilon.c
> b/arch/blackfin/mach-bf561/boards/acvilon.c index bfcfa86..35b6d12 100644
> --- a/arch/blackfin/mach-bf561/boards/acvilon.c
> +++ b/arch/blackfin/mach-bf561/boards/acvilon.c
> @@ -284,6 +284,7 @@ static int bfin_plat_nand_dev_ready(struct mtd_info
> *mtd)
>
> static struct platform_nand_data bfin_plat_nand_data = {
> .chip = {
> + .nr_chips = 1,
> .chip_delay = 30,
> #ifdef CONFIG_MTD_PARTITIONS
> .part_probe_types = part_probes,
> diff --git a/arch/mips/nxp/pnx833x/common/platform.c
> b/arch/mips/nxp/pnx833x/common/platform.c index 01f8345..ce45df1 100644
> --- a/arch/mips/nxp/pnx833x/common/platform.c
> +++ b/arch/mips/nxp/pnx833x/common/platform.c
> @@ -266,6 +266,7 @@ pnx833x_flash_nand_cmd_ctrl(struct mtd_info *mtd, int
> cmd, unsigned int ctrl)
>
> static struct platform_nand_data pnx833x_flash_nand_data = {
> .chip = {
> + .nr_chips = 1,
> .chip_delay = 25,
> .part_probe_types = part_probes,
> },
On Wed, Aug 11, 2010 at 22:53, Marek Vasut wrote:
> These three platforms didn't properly fill nr_chips in gen_nand registration and
> therefore depended on gen_nand bug fixed by the following patch:
the Blackfin arch has a mailing list ... no need to pick out people
> "mtd: gen_nand: fix support for multiple chips"
>
> arch/blackfin/mach-bf537/boards/stamp.c | 1 +
> arch/blackfin/mach-bf561/boards/acvilon.c | 1 +
looks sane enough to me
Acked-by: Mike Frysinger <[email protected]>
-mike
On Wed, Aug 11, 2010 at 22:57, Marek Vasut wrote:
> NOTE for bfin guys: I'm slightly concerned about overall code quality on the
> BFIN architecture.
that makes one of us
-mike
Dne Čt 12. srpna 2010 05:36:31 Mike Frysinger napsal(a):
> On Wed, Aug 11, 2010 at 22:53, Marek Vasut wrote:
> > These three platforms didn't properly fill nr_chips in gen_nand
> > registration and
>
> > therefore depended on gen_nand bug fixed by the following patch:
> the Blackfin arch has a mailing list ... no need to pick out people
Hi, that's true, but there's that "scripts/get_maintainer.pl" thing which gave
me this list.
Cheers
>
> > "mtd: gen_nand: fix support for multiple chips"
> >
> > arch/blackfin/mach-bf537/boards/stamp.c | 1 +
> > arch/blackfin/mach-bf561/boards/acvilon.c | 1 +
>
> looks sane enough to me
> Acked-by: Mike Frysinger <[email protected]>
> -mike
On Thu, Aug 12, 2010 at 07:04, Marek Vasut wrote:
> Dne Čt 12. srpna 2010 05:36:31 Mike Frysinger napsal(a):
>> On Wed, Aug 11, 2010 at 22:53, Marek Vasut wrote:
>> > These three platforms didn't properly fill nr_chips in gen_nand
>> > registration and
>>
>> > therefore depended on gen_nand bug fixed by the following patch:
>> the Blackfin arch has a mailing list ... no need to pick out people
>
> Hi, that's true, but there's that "scripts/get_maintainer.pl" thing which gave
> me this list.
yes, but typically that's a shotgun approach that grabs way more
people and can easily fall out of date (people no longer
exist/etc...). personally, i use it as a fallback when MAINTAINERS
doesnt cover it.
-mike
Dne Čt 12. srpna 2010 14:47:06 Mike Frysinger napsal(a):
> On Thu, Aug 12, 2010 at 07:04, Marek Vasut wrote:
> > Dne Čt 12. srpna 2010 05:36:31 Mike Frysinger napsal(a):
> >> On Wed, Aug 11, 2010 at 22:53, Marek Vasut wrote:
> >> > These three platforms didn't properly fill nr_chips in gen_nand
> >> > registration and
> >>
> >> > therefore depended on gen_nand bug fixed by the following patch:
> >> the Blackfin arch has a mailing list ... no need to pick out people
> >
> > Hi, that's true, but there's that "scripts/get_maintainer.pl" thing which
> > gave me this list.
>
> yes, but typically that's a shotgun approach that grabs way more
> people and can easily fall out of date (people no longer
> exist/etc...). personally, i use it as a fallback when MAINTAINERS
> doesnt cover it.
> -mike
The more eyes on the code, the better :)
Cheers