[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=Vynttaz00yqbihgK0HxyrPt9b0i0-8Ft6-4NEPc_NkeQ@mail.gmail.com>
Date: Fri, 4 Dec 2020 08:42:46 -0800
From: Doug Anderson <dianders@...omium.org>
To: Andreas Kemnade <andreas@...nade.info>
Cc: Tony Lindgren <tony@...mide.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
linux-omap <linux-omap@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
Discussions about the Letux Kernel
<letux-kernel@...nphoenux.org>
Subject: Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
Hi,
On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade <andreas@...nade.info> wrote:
>
> > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> >
> > From the description it sounds like this problem has always existed
> > but the async probe just tickled it reliably. Seems like it'd make
> > sense to tag the "Fixes" as some earlier commit so you make sure your
> > fix gets picked to kernels even if they don't have the async probe
> > patch?
> >
>
> Hmm, maybe
> Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> pm_runtime after probe defer")
>
> But on the other hand to stable branches only such patches are applied
> which solve pratical problems not only theoretical problems. But maybe
> it solves several random issues where nobody took care to debug them.
>
> That would be since v4.11.
I guess maybe best is to include both. Then if someone is debugging
why their async probe is failing they will notice this commit, but
they also might decide to pick it earlier just to be safe...
-Doug
Powered by blists - more mailing lists