linux-kernel - Re: [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111220180610.GB24444@atomide.com>
Date:	Tue, 20 Dec 2011 10:06:11 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Janusz Krzysztofik <jkrzyszt@....icnet.pl>
Cc:	alsa-devel@...a-project.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jarkko Nikula <jarkko.nikula@...mer.com>,
	Liam Girdwood <lrg@...com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-input@...r.kernel.org
Subject: Re: [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch
 dependent devices later

* Janusz Krzysztofik <jkrzyszt@....icnet.pl> [111219 14:57]:
> Resending because of a typo in the Cc: list, sorry.
> 
> 8<--------------------------
> 
> In preparation to converting Amstrad Delta on-board latches to
> basic_mmio_gpio devices, registration of platform devices which depend
> on latches and will require initialization of their GPIO pins first,
> should be moved out of .machine_init down to late_initcall level, as the
> gpio-generic driver is not available until device_initcall time.  The
> latch reset operation, which will be replaced with GPIO initialization,
> must also be moved to late_initcall for the same reason.
> 
> Since there was already another, separate arch_initcall function for
> setting up one of those latch dependent devices, the on-board modem
> device, reuse that function, i.e., rename it to a name that matches the
> new purpose, extend with other device setup relocated from
> .machine_init, and move down to the late_initcall level.
> 
> While being at it, add missing gpio_free() in case the modem platform
> device registration fails.
> 
> In addition, defer registration of the Amstrad Delta ASoC and serio
> devices, done from their device driver files, until late_initcall time,
> as those drivers will depend on their GPIO pins already requested from
> the board late_init() function until updated to register their GPIO pins
> themselves.
> 
> Thanks to Tony Lindgren <tony@...mide.com> who suggested this approach
> instead of shifting up the gpio-generic driver initialization.
...
 
> --- a/drivers/input/serio/ams_delta_serio.c
> +++ b/drivers/input/serio/ams_delta_serio.c
> @@ -165,6 +165,9 @@ serio:
>  	kfree(ams_delta_serio);
>  	return err;
>  }
> +#ifndef MODULE
> +late_initcall(ams_delta_serio_init);
> +#else
>  module_init(ams_delta_serio_init);
>  
>  static void __exit ams_delta_serio_exit(void)
> @@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void)
>  	gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
>  }
>  module_exit(ams_delta_serio_exit);
> +#endif
> diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
> index ccb8a6a..1764a3b 100644
> --- a/sound/soc/omap/ams-delta.c
> +++ b/sound/soc/omap/ams-delta.c
> @@ -636,6 +636,9 @@ err:
>  	platform_device_put(ams_delta_audio_platform_device);
>  	return ret;
>  }
> +#ifndef MODULE
> +late_initcall(ams_delta_module_init);
> +#else
>  module_init(ams_delta_module_init);
>  
>  static void __exit ams_delta_module_exit(void)
> @@ -657,6 +660,7 @@ static void __exit ams_delta_module_exit(void)
>  	platform_device_unregister(ams_delta_audio_platform_device);
>  }
>  module_exit(ams_delta_module_exit);
> +#endif
>  
>  MODULE_AUTHOR("Janusz Krzysztofik <jkrzyszt@....icnet.pl>");
>  MODULE_DESCRIPTION("ALSA SoC driver for Amstrad E3 (Delta) videophone");

This looks a bit odd.. I think these drivers should be converted to
a proper platform_driver so you can get rid of the machine_is_ams_delta
check in the init. Then you can rely on the probe to match the
device. To deal with the init order issues, you can pass a set_power
function pointer in platform_data that the driver can use. Or
set up a fixed regulator for it.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/