On Sun, Jan 31, 2021 at 8:38 AM Martin Kaiser <mar...@kaiser.cx> wrote: > > Dear all, > > Thus wrote Saravana Kannan (sarava...@google.com): > > > Sending again because I messed up the To/Cc for the coverletter. > > > This series combines two patches [1] [2] that'd conflict. > > > Greg, > > > Can you please pull this into driver-core-next? > > > -Saravana > > > [1] - > > https://lore.kernel.org/lkml/20210115210159.3090203-1-sarava...@google.com/ > > [2] - > > https://lore.kernel.org/lkml/20201218210750.3455872-1-sarava...@google.com/ > > I'm running linux-next on my hardware which is based on the imx258 > chipset by Freescale/NXP. > > When those two patches appeared in linux-next, my system would not boot > any more. It was stuck right after > > Uncompressing Linux... done, booting the kernel. > > Reverting the irq-patch made the system boot again. Still, a number of > devices like usb or nand flash controller are not found any more. > If I revert the gpio patch as well, all devices are available again. > > My system's device tree is based on arch/arm/boot/dts/imx25.dtsi with > very few adaptations for my board. > > I tried to play around with the new parse_interrupts() function to > figure out which device causes the boot failure. If I skip the following > device, I can boot again: > > - return of_irq_find_parent(np); > + np_ret = of_irq_find_parent(np); > + if (!strcmp(np->full_name, "serial@50008000")) { > + printk(KERN_ERR "skip serial@50008000\n"); > + return NULL; > + } > + return np_ret; > > This is uart4 of the imx258 chip, which I use as my serial console. The > imx25.dtsi device tree seems ok, we find an interrupt parent. The > problem must be in the code that processes the result of > parse_interrupts(). > > I tried to boot the unmodified code with qemu, simulating the imx25-pdk > device. This wouldn't boot either. > > Does this ring any bells with anyone?
This series [1] has a high chance of fixing it for you if CONFIG_MODULES is disabled in your set up. Can you give it a shot? The real problem is that arch/arm/mach-imx/avic.c doesn't set the OF_POPULATED flag for the "fsl,avic" node. fw_devlink uses this information to know that this device node will never have a struct device created for it. The proper way to do this for root IRQCHIP nodes is to use IRQCHIP_DECLARE(). I Cc'ed you on a clean up patch for IMX [2], can you please give [2] a shot *without* [1] and with CONFIG_MODULES enabled? Things should boot properly with this combination too. Btw, for future reference, you can try enabling the logs in device_links_check_suppliers() to see what devices are being blocked on what supplier nodes. [1] - https://lore.kernel.org/lkml/20210130040344.2807439-1-sarava...@google.com/ [2] - https://lore.kernel.org/lkml/20210131205654.3379661-1-sarava...@google.com/T/#u Thanks, Saravana
