diff mbox

[2/2] misc: atmel_pwm: set initcall level to subsys

Message ID 1382459560-26596-3-git-send-email-jhovold@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Johan Hovold Oct. 22, 2013, 4:32 p.m. UTC
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@gmail.com>
---
 drivers/misc/atmel_pwm.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

Comments

Greg KH Oct. 29, 2013, 11:22 p.m. UTC | #1
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@gmail.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
Johan Hovold Oct. 30, 2013, 11:07 a.m. UTC | #2
On Tue, Oct 29, 2013 at 04:22:49PM -0700, Greg KH wrote:
> 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@gmail.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.

Yes, it's crude, but it's currently the only way to express a preferred
probe order.

> 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...

Deferred probing (the first patch) fixes the dependency problem, but may
introduce delays. I can live with that.

> Sorry, I can't take this.

Fair enough.

Thanks,
Johan
Arnd Bergmann Oct. 30, 2013, 8:46 p.m. UTC | #3
On Wednesday 30 October 2013, Johan Hovold wrote:
> > 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.
> 
> Yes, it's crude, but it's currently the only way to express a preferred
> probe order.

Does the same problem occur with the generic PWM subsystem?

The atmel_pwm driver apparently is the last PWM driver that has
not been converted to the generic subsystem yet. Doing that would
also let us drop the atmel-pwm-bl driver in favor of the generic
backlight.

	Arnd
Bo Shen Oct. 31, 2013, 1:19 a.m. UTC | #4
Hi Arnd,

On 10/31/2013 04:46, Arnd Bergmann wrote:
> On Wednesday 30 October 2013, Johan Hovold wrote:
>>> 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.
>>
>> Yes, it's crude, but it's currently the only way to express a preferred
>> probe order.
>
> Does the same problem occur with the generic PWM subsystem?
>
> The atmel_pwm driver apparently is the last PWM driver that has
> not been converted to the generic subsystem yet. Doing that would
> also let us drop the atmel-pwm-bl driver in favor of the generic
> backlight.

The atmel pwm driver is on the way to generic subsystem. more 
information at:
--->8---
PWM: atmel-pwm: add PWM controller driver:
    https://patchwork.kernel.org/patch/2963081/
---<8---

Best Regards,
Bo Shen
Jean-Christophe PLAGNIOL-VILLARD Oct. 31, 2013, 5:30 a.m. UTC | #5
On 09:19 Thu 31 Oct     , Bo Shen wrote:
> Hi Arnd,
> 
> On 10/31/2013 04:46, Arnd Bergmann wrote:
> >On Wednesday 30 October 2013, Johan Hovold wrote:
> >>>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.
> >>
> >>Yes, it's crude, but it's currently the only way to express a preferred
> >>probe order.
> >
> >Does the same problem occur with the generic PWM subsystem?
> >
> >The atmel_pwm driver apparently is the last PWM driver that has
> >not been converted to the generic subsystem yet. Doing that would
> >also let us drop the atmel-pwm-bl driver in favor of the generic
> >backlight.
> 
> The atmel pwm driver is on the way to generic subsystem. more
> information at:
> --->8---
> PWM: atmel-pwm: add PWM controller driver:
>    https://patchwork.kernel.org/patch/2963081/

so the fix can be drop in favor of the conversion

Best Regards,
J.
> ---<8---
> 
> Best Regards,
> Bo Shen
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Johan Hovold Oct. 31, 2013, 2:01 p.m. UTC | #6
On Wed, Oct 30, 2013 at 09:46:17PM +0100, Arnd Bergmann wrote:
> On Wednesday 30 October 2013, Johan Hovold wrote:
> > > 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.
> > 
> > Yes, it's crude, but it's currently the only way to express a preferred
> > probe order.
> 
> Does the same problem occur with the generic PWM subsystem?

It does not suffer from the problem with failed probe as it supports
deferred probing, but there could be added delays depending on probe
order.

> The atmel_pwm driver apparently is the last PWM driver that has
> not been converted to the generic subsystem yet. Doing that would
> also let us drop the atmel-pwm-bl driver in favor of the generic
> backlight.

As Bo mentioned, it's work in progress that hasn't been merged yet.

Johan
Johan Hovold Oct. 31, 2013, 2:07 p.m. UTC | #7
On Thu, Oct 31, 2013 at 06:30:37AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:19 Thu 31 Oct     , Bo Shen wrote:
> > Hi Arnd,
> > 
> > On 10/31/2013 04:46, Arnd Bergmann wrote:
> > >On Wednesday 30 October 2013, Johan Hovold wrote:
> > >>>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.
> > >>
> > >>Yes, it's crude, but it's currently the only way to express a preferred
> > >>probe order.
> > >
> > >Does the same problem occur with the generic PWM subsystem?
> > >
> > >The atmel_pwm driver apparently is the last PWM driver that has
> > >not been converted to the generic subsystem yet. Doing that would
> > >also let us drop the atmel-pwm-bl driver in favor of the generic
> > >backlight.
> > 
> > The atmel pwm driver is on the way to generic subsystem. more
> > information at:
> > --->8---
> > PWM: atmel-pwm: add PWM controller driver:
> >    https://patchwork.kernel.org/patch/2963081/
> 
> so the fix can be drop in favor of the conversion

This patch (2/2) has been dropped, but the dependency issue still has to
be addressed (by adding deferred-probing support). The atmel-pwm-bl
driver has not been removed yet and the fix is also needed in stable.

Johan
diff mbox

Patch

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);
+
+static void __exit pwm_exit(void)
+{
+	platform_driver_unregister(&atmel_pwm_driver);
+}
+module_exit(pwm_exit);
 
 MODULE_DESCRIPTION("Driver for AT32/AT91 PWM module");
 MODULE_LICENSE("GPL");