On 4/26/21 2:33 PM, Saravana Kannan wrote: > On Mon, Apr 26, 2021 at 1:51 PM Florian Fainelli wrote: >> >> Hi Saravana, >> >> Adding Sudeep and Christian, Al and Jim. >> >> On 3/2/21 1:11 PM, Saravana Kannan wrote: >>> This reverts commit 3e4c982f1ce75faf5314477b8da296d2d00919df. >>> >>> Since all reported issues due to fw_devlink=on should be addressed by >>> this series, revert the revert. fw_devlink=on Take II. >>> >>> Signed-off-by: Saravana Kannan >> >> This change breaks booting on SCMI-based platforms such as ARCH_BRCMSTB. >> If I revert this change or boot with fw_devlink=permissive, then our >> systems boot again. From a quick look, the SCMI clock provider was never >> probed which means that our UART driver never got a chance to get its >> clock and we have no console -> timeout. > > We explicitly landed changes to handle this condition. So we'll see if > this is what is happening. > >> Al, AFAICT you had started to analyze this before in the context of >> SCMI, do you mind sharing what you had found? >> >> Saravana, is there any debugging output that we can help provide? > > Thanks for the report. Couple of things that can help: > 1. Example DTS file (the final board file so that I can get the full DT view). Attached BCX972160DV.dts which is one such system. > 2. Point out the UART device node and the SCMI device node that you > suspect is causing the issue. The SCMI provider node is brcm_scmi@0 and its sub-node protocol@14 is the clock provider. The UART node is /rdb/serial@840c000. > 3. Boot logs with dev_dbg changed to dev_info in device_link_add() and > device_links_check_suppliers() OK, I did not want to modify the kernel so I just enabled dynamic debug prints from the command line, if this is too verbose let me know. Thank you for your prompt response. -- Florian