linux-kernel - Re: [PATCH 2/2] misc: atmel_pwm: set initcall level to subsys

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: <20131029232249.GA20476@kroah.com>
Date:	Tue, 29 Oct 2013 16:22:49 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Johan Hovold <jhovold@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] misc: atmel_pwm: set initcall level to subsys

On Tue, Oct 22, 2013 at 06:32:40PM +0200, Johan Hovold wrote:
> Even with the atmel_pwm driver and the atmel-pwm-bl backlight driver
> supporting deferred probing, we still want to make sure that any
> pwm-device is available when the backlight devices are probed to avoid
> any unnecessary delays before enabling the backlight.
> 
> Signed-off-by: Johan Hovold <jhovold@...il.com>
> ---
>  drivers/misc/atmel_pwm.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/atmel_pwm.c b/drivers/misc/atmel_pwm.c
> index a6dc56e..0d0f599 100644
> --- a/drivers/misc/atmel_pwm.c
> +++ b/drivers/misc/atmel_pwm.c
> @@ -395,7 +395,17 @@ static struct platform_driver atmel_pwm_driver = {
>  	 */
>  };
>  
> -module_platform_driver_probe(atmel_pwm_driver, pwm_probe);
> +static int __init pwm_init(void)
> +{
> +	return platform_driver_probe(&atmel_pwm_driver, pwm_probe);
> +}
> +subsys_initcall(pwm_init);

I really hate this type of patch, as it's papering over the real
problem.  What happens when someone else moves their driver to this
level?  Then you are back to the original problem.

This is what deferred probing was supposed to fix.  If it doesn't, then
something else needs to be done, or fix the deferred probing mess...

Sorry, I can't take this.

greg k-h
--
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/