On Thu, Aug 20, 2020 at 7:53 AM Marc Zyngier <m...@kernel.org> wrote: > > On 2020-08-20 09:07, Saravana Kannan wrote: > > On Thu, Aug 20, 2020 at 12:56 AM Marc Zyngier <m...@kernel.org> wrote: > >> > >> On 2020-08-19 19:51, Saravana Kannan wrote: > >> > On Wed, Aug 19, 2020 at 9:52 AM Frank Wunderlich <wich...@fw-web.de> > >> > wrote: > >> >> > >> >> hi, > >> >> > >> >> does the fix you've linked to my revert [1] not work in your case? > >> >> > >> >> [1] https://patchwork.kernel.org/patch/11718481/ > >> > > >> > Thanks for pointing it out Frank. Also, might want to avoid top > >> > posting in the future. > >> > > >> > Enric, Can you please try that other fix and see if that solves your > >> > issue? > >> > >> I think Enric was clear that the driver does probe correctly > >> (meaning that he has the fix in his tree). It is everything else > >> that breaks, because none of the drivers on the platform are > >> equipped to defer their own probing. > >> > >> I think we need to change this works right now, meaning that we can't > >> blindly change the behaviour of *built-in* drivers. I'll see if I can > >> come up with something quickly, but I'll otherwise take Enric patch. > > > > Sounds fair Marc. > > > > Btw, Enric, out of curiosity, can you try adding "fw_devlink=on" to > > your kernel command line to see if it helps? It basically ensures > > proper probe ordering without depending on the drivers. There are some > > corner cases where it still can't work properly (too much to explain > > for a late night email), but if the platforms don't have those corner > > cases it'll work perfectly. > > > > I'm fine with the revert if Marc isn't able to find a quick fix to the > > drivers, but this might also fix your problem right away. > > I'm afraid there is no quick fix if we want to preserve the current > behavior with built-in drivers,
> and not having "fw_devlink=on" by > default makes it irrelevant for most people. Agreed. > fw_devlink also prevents my test platforms from booting (my rk3399 > doesn't find its PCI devices with it), while the same kernel boots > just fine without it. It could well be that the corner case is > likely to be more prevalent than you seem to expect. Yeah, I know it has a few corner cases I need to deal with. > I will probably end-up end-up queuing reverts for both mtk-sysirq, > mtk-cirq, and qcom-pdc (the first two can't be built as module with > mainline anyway, and I seem to remember that the latter caused some > controversy as well). > > As an experiment, I have pushed out a branch[1] that implements > a "hybrid" probe, retaining the previous early probe mechanism when > the driver is built-in, and letting things rip when built as a > module (if you do that, you hopefully know what you are doing). > I'd welcome some testing on affected platforms (I don't have > anything I can run mainline on that'd be affected). I like [1] and the code looks good. Hopefully, we can stick with that. -Saravana