public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Richard Purdie <rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org>,
	Jacek Anaszewski
	<jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>,
	Adrian Hunter
	<adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Heiner Kallweit
	<hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: [regression] next-20170307: led trigger deferral breaks sdhci
Date: Wed, 8 Mar 2017 21:17:33 +0000	[thread overview]
Message-ID: <20246b21-4c00-e22e-232d-49596f5f275e@nvidia.com> (raw)

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

             reply	other threads:[~2017-03-08 21:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-08 21:17 Jon Hunter [this message]
     [not found] ` <20246b21-4c00-e22e-232d-49596f5f275e-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-03-09  6:50   ` [regression] next-20170307: led trigger deferral breaks sdhci Ludovic Desroches
2017-03-09 20:30 ` Jacek Anaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20246b21-4c00-e22e-232d-49596f5f275e@nvidia.com \
    --to=jonathanh-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pavel-+ZI9xUNit7I@public.gmane.org \
    --cc=rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox