On Thu, 14 Dec 2023 at 09:16, Johan Hovold <johan@xxxxxxxxxx> wrote: > > On Wed, Dec 13, 2023 at 01:06:43PM -0800, Rob Clark wrote: > > From: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > We need to bail out before adding/removing devices, if we are going > > to -EPROBE_DEFER. Otherwise boot will get stuck forever at > > deferred_probe_initcall(). > > Can please you expand on why this is a problem here in the commit > message? > > The aux devices appear to be tore down correctly in the probe error > paths so how exactly does that lead to deferred_probe_initcall() being > stuck? This sounds like we may have a problem elsewhere which this patch > is papering over. This is a known problem. Successful probes during the probe deferral loop causes the whole loop to be reiterated. Creating child devices usually results in a successful probe. Aso I thought that just creating new device also causes a reprobe, but I can not find any evidence now. > > Also where does the probe deferral come from in your case? > pdr_handle_alloc()? > > If this is a correct fix, I'd also expect there to be a Fixes and > CC-stable tag. > > Johan > -- With best wishes Dmitry
