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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
