Skip to contentSkip to conversation

gpio: generic: Revert to old error handling in bgpio_map

PATCH In review Guenter Roeck 3 participants 3 messages Oct 21, 2015 – Oct 27, 2015 GPIO

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 gpio: generic: Revert to old error handling in bgpio_map

Returning an error instead of NULL in bgpio_map if platform_get_resource_byname does not find a resource was introduced with commit cf3f2a2c8bae ("gpio: generic: improve error handling in bgpio_map"). This results in several qemu runtime failures with default and non-default configurations, if attempts are made to boot from mmcblk0. Examples for failures with multi_v7_defconfig are

Machine: vexpress-a9 dtb: vexpress-v2p-ca9
Machine: vexpress-a15 dtb: vexpress-v2p-ca15-tc1

Crash:

VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Looking into the code, always returning an error if bgpio_map fails does not appear to make much sense, since the code in bgpio_setup_io specifically supports some of the resources to be NULL.

Fixes cf3f2a2c8bae ("gpio: generic: improve error handling in bgpio_map")
Cc Heiner Kallweit <[email protected]>
---
 drivers/gpio/gpio-generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-generic.c +1 -1
index d8b1700b9519..bd5193c67a9c 100644
@@ -586,7 +586,7 @@ static void __iomem *bgpio_map(struct platform_device *pdev,
 
 	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
 	if (!r)
-		return IOMEM_ERR_PTR(-EINVAL);
+		return NULL;
 
 	sz = resource_size(r);
 	if (sz != sane_sz)
Signature · 1 line
2.1.4
#1 lore raw
Quoted 12 lines · Guenter Roeck

Returning an error instead of NULL in bgpio_map if platform_get_resource_byname does not find a resource was introduced with commit cf3f2a2c8bae ("gpio: generic: improve error handling in bgpio_map"). This results in several qemu runtime failures with default and non-default configurations, if attempts are made to boot from mmcblk0. Examples for failures with multi_v7_defconfig are

Machine: vexpress-a9 dtb: vexpress-v2p-ca9
Machine: vexpress-a15 dtb: vexpress-v2p-ca15-tc1

Crash:

Quoted 8 lines

VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Looking into the code, always returning an error if bgpio_map fails does not appear to make much sense, since the code in bgpio_setup_io specifically supports some of the resources to be NULL.

Indeed. Seems like "dat" is the only mandatory resource. Previously there was a double check that "dat" is set:
in bgpio_dev_probe and in bgpio_setup_io

With your proposed patch the check in bgpio_dev_probe is removed. Due to the (previously redundant) check in bgpio_setup_io it's ok however.

One could only discuss whether "dat" should be checked as early as possible (in bgpio_dev_probe instead of bgpio_setup_io).
But that's something I'd consider to be more or less cosmetic.

Quoted 23 lines
Fixes cf3f2a2c8bae ("gpio: generic: improve error handling in bgpio_map")
Cc Heiner Kallweit <[email protected]>
---
 drivers/gpio/gpio-generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-generic.c +1 -2
index d8b1700b9519..bd5193c67a9c 100644
@@ -586,7 +586,7 @@ static void __iomem *bgpio_map(struct platform_device *pdev,
 
        r = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
        if (!r)
-               return IOMEM_ERR_PTR(-EINVAL);
+               return NULL;
 
        sz = resource_size(r);
        if (sz != sane_sz)
--

2.1.4

#2 lore raw
In reply to Guenter Roeck
Quoted 16 lines · Guenter Roeck

Returning an error instead of NULL in bgpio_map if platform_get_resource_byname does not find a resource was introduced with commit cf3f2a2c8bae ("gpio: generic: improve error handling in bgpio_map"). This results in several qemu runtime failures with default and non-default configurations, if attempts are made to boot from mmcblk0. Examples for failures with multi_v7_defconfig are

Machine: vexpress-a9 dtb: vexpress-v2p-ca9
Machine: vexpress-a15 dtb: vexpress-v2p-ca15-tc1

Crash:

VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Quoted 7 lines

Looking into the code, always returning an error if bgpio_map fails does not appear to make much sense, since the code in bgpio_setup_io specifically supports some of the resources to be NULL.

Fixes cf3f2a2c8bae ("gpio: generic: improve error handling in bgpio_map")
Cc Heiner Kallweit <[email protected]>

Patch/revert applied. Thanks for digging in and fixing this Günther!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html