The PHYSMAP_COMPAT code had been ignoring the return value of
platform_device_register() in the physmap_init() function.

Signed-off-by: Zev Weiss <zevweiss@gmail.com>
---
  drivers/mtd/maps/physmap.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/maps/physmap.c b/drivers/mtd/maps/physmap.c
index 42d844f..6fba0d4 100644
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -312,7 +312,7 @@ static int __init physmap_init(void)
  	err = platform_driver_register(&physmap_flash_driver);
  #ifdef PHYSMAP_COMPAT
  	if (err == 0)
-		platform_device_register(&physmap_flash);
+		err = platform_device_register(&physmap_flash);
  #endif

  	return err;
-- 
1.5.4.1


--

[ message continues ]

I don't think you want the registration of the physmap driver to fail
if the compat platform device fails to register.

One reason that the compat platform device can fail to register can be
that there is already a non-compat platform device for the compat flash
chip, and in that case I don't think you want to fail the driver init
(while leaving the physmap_flash_driver registered, too!).
--

[ message continues ]

Chalk another one up to ignorance on my part...sounds like a nak all 'round.
--

[ message continues ]

On Fri, 12 Sep 2008 23:32:58 -0700

Your email client is performing space-stuffing, thus making the patches
unapplyable.

Presumably we should run platform_driver_unregister() if the
platform_device_register() failed.

--

[ message continues ]

Hello.



    Why is that? There could be "normal" platform devices out there...

WBR, Sergei
--

[ message continues ]

With that said, the patch is pointless (as already noted by Lennert).

WBR, Sergei
--

[ message continues ]