[regression] next-20170307: led trigger deferral breaks sdhci

[regression] next-20170307: led trigger deferral breaks sdhci

[Jon Hunter]

Hello!

I noticed that sdhci is broken for me on yesterday's and today's -next
and the bisect is pointing to commit 3f1318e01bb4 ('leds: core: use
deferred probing if default trigger isn't available yet').

At first I thought that ok, the problem is that sdhci driver is first
registering the led and then the trigger. However, then I looked at the
led_trigger_register() function and it appears to allow you to register
the led first and the trigger sometime later and populate the default
trigger later on. So then I am not sure why the above commit is needed?

It is not clear to me from the commit message for the above commit what
actual problem was caused by not registering the trigger first.

Cheers
Jon

-- 
nvpublic

Re: [regression] next-20170307: led trigger deferral breaks sdhci

[Ludovic Desroches]

Hi,

On 03/08/2017 10:17 PM, Jon Hunter wrote:
> Hello!
>
> I noticed that sdhci is broken for me on yesterday's and today's -next
> and the bisect is pointing to commit 3f1318e01bb4 ('leds: core: use
> deferred probing if default trigger isn't available yet').

I have noticed it yesterday, I was going to perform a bisect but thanks 
to you I won't have to do it.

Ludovic

>
> At first I thought that ok, the problem is that sdhci driver is first
> registering the led and then the trigger. However, then I looked at the
> led_trigger_register() function and it appears to allow you to register
> the led first and the trigger sometime later and populate the default
> trigger later on. So then I am not sure why the above commit is needed?
>
> It is not clear to me from the commit message for the above commit what
> actual problem was caused by not registering the trigger first.
>
> Cheers
> Jon
>

Re: [regression] next-20170307: led trigger deferral breaks sdhci

[Jacek Anaszewski]

Hi Joe,

On 03/08/2017 10:17 PM, Jon Hunter wrote:
> Hello!
> 
> I noticed that sdhci is broken for me on yesterday's and today's -next
> and the bisect is pointing to commit 3f1318e01bb4 ('leds: core: use
> deferred probing if default trigger isn't available yet').
> 
> At first I thought that ok, the problem is that sdhci driver is first
> registering the led and then the trigger. However, then I looked at the
> led_trigger_register() function and it appears to allow you to register
> the led first and the trigger sometime later and populate the default
> trigger later on. So then I am not sure why the above commit is needed?
> 
> It is not clear to me from the commit message for the above commit what
> actual problem was caused by not registering the trigger first.

The problem was the case when the trigger that has been defined as
"default-trigger" in DT is not registered at the moment of LED class
driver probing. It is silently ignored by LED core.

It turned out that we accepted the commit too hastily, and in fact
that case seems not to be critical to the extent justifying preventing
LED class device registration.

Probably dev_warn() should be enough in this case. I've already dropped
the commit. Sorry for making confusion.

-- 
Best regards,
Jacek Anaszewski