Messages in this thread | | | From | Saravana Kannan <> | Date | Mon, 26 Apr 2021 14:33:18 -0700 | Subject | Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by default"" |
| |
On Mon, Apr 26, 2021 at 1:51 PM Florian Fainelli <f.fainelli@gmail.com> 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 <saravanak@google.com> > > 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). 2. Point out the UART device node and the SCMI device node that you suspect is causing the issue. 3. Boot logs with dev_dbg changed to dev_info in device_link_add() and device_links_check_suppliers()
Thanks, Saravana
| |