Re: [PATCH 2/5] leds: make sure leds_class is initialized before triggers are registered

[Greg Kroah-Hartman]

On Sun, Sep 08, 2019 at 09:41:09PM +0900, Akinobu Mita wrote:
> If the led-class and usb-common modules are built into the kernel, the
> usb-common module could be initialized earlier than the led-class module.
> 
> So when the ledtrig_usb_gadget and ledtrig_usb_host LED triggers are
> registered by usb-common module, the leds_class could not be initialized
> yet.
> 
> We are going to populate sub-directories, each representing an LED
> trigger in /sys/class/triggers/, so leds_class needs to be initialized
> before any LED triggers is registered.
> 
> This makes led-class initialize earlier then usb-common by changing
> initcall group.
> 
> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> Cc: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
> Cc: Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>
> Cc: Pavel Machek <pavel@xxxxxx>
> Cc: Dan Murphy <dmurphy@xxxxxx>
> Signed-off-by: Akinobu Mita <akinobu.mita@xxxxxxxxx>
> ---
>  drivers/leds/led-class.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 8b5a1d1..7d85181 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -424,7 +424,7 @@ static void __exit leds_exit(void)
>  	class_destroy(leds_class);
>  }
>  
> -subsys_initcall(leds_init);
> +postcore_initcall(leds_init);

This is a case of "whack a mole".

Why not just initialize everything the first time the function is
called?  That way you don't have to mess with any of the link order
stuff and everything will always continue to work if things ever change
in the future?

thanks,

greg k-h