On Tue, Feb 2, 2021 at 9:41 AM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > On Tue, Feb 2, 2021 at 10:52 AM <Tudor.Ambarus@xxxxxxxxxxxxx> wrote: > > > > Hi, Saravana, > > > > On 2/2/21 6:33 AM, Saravana Kannan wrote: > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > > > This patch series solves two general issues with fw_devlink=on > > > > > > Patch 1/3 and 3/3 addresses the issue of firmware nodes that look like > > > they'll have struct devices created for them, but will never actually > > > have struct devices added for them. For example, DT nodes with a > > > compatible property that don't have devices added for them. > > > > > > Patch 2/2 address (for static kernels) the issue of optional suppliers > > > that'll never have a driver registered for them. So, if the device could > > > have probed with fw_devlink=permissive with a static kernel, this patch > > > should allow those devices to probe with a fw_devlink=on. This doesn't > > > solve it for the case where modules are enabled because there's no way > > > to tell if a driver will never be registered or it's just about to be > > > registered. I have some other ideas for that, but it'll have to come > > > later thinking about it a bit. > > > > > > Marek, Geert, > > > > > > I don't expect v2 to do any better for your cases. > > > > > > This series not making any difference for Marek is still a mystery to > > > me. I guess one of the consumers doesn't take too well to its probe (and > > > it's consumers' probe) being delayed till late_initcall(). I'll continue > > > looking into it. > > > > > > Marc, > > > > > > This v2 should do better than v1 with gpiolib stub driver reverted. I > > > forgot to take care of the case where more suppliers could link after I > > > went and deleted some of the links. v2 handles that now. > > > > > > Tudor, > > > > > > You should still make the clock driver fix (because it's a bug), but I > > > think this series will fix your issue too (even without the clock driver > > > fix). Can you please give this a shot? > > > > > > > Did the following tests (using sama5_defconfig and at91-sama5d2_xplained.dts): > > 1/ modular kernel with your v2 on top of next-20210202, and without the clock > > driver fix: the problem persists. > > > > 2/ static kernel with your v2 on top of next-20210202, and without the clock > > driver fix: the problem persists. Comparing to the previous test, I see that > > the links to pmc are dropped. I can see the following only with early printk > > enabled: > > platform fc008000.serial: Dropping the link to f0014000.pmc > > But later on, the serial still gets deferred waiting for the dma controller > > this time: > > platform f8020000.serial: probe deferral - supplier f0010000.dma-controller not ready > > I'll check what happens in the dma-controller. > > Not sure if it's the case here, but some serial drivers use DMA only > when available and decide that on open() rather than probe. How is > devlinks going to deal with that? That's kinda what I'm trying to work out here :) but in a more generic fashion. -Saravana
