Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by
 default""
To:     Saravana Kannan <saravanak@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Al Cooper <alcooperx@gmail.com>,
        Jim Quinlan <james.quinlan@broadcom.com>,
        Sudeep Holla <sudeep.holla@arm.com>,
        Cristian Marussi <cristian.marussi@arm.com>
Cc:     Michael Walle <michael@walle.cc>,
        Jon Hunter <jonathanh@nvidia.com>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Guenter Roeck <linux@roeck-us.net>, kernel-team@android.com,
        linux-kernel@vger.kernel.org
References: <20210302211133.2244281-1-saravanak@google.com>
 <20210302211133.2244281-4-saravanak@google.com>
From:   Florian Fainelli <f.fainelli@gmail.com>
Message-ID: <60989b90-7f8a-5306-e7d7-c5461bc9ac68@gmail.com>
Date:   Mon, 26 Apr 2021 13:51:06 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <20210302211133.2244281-4-saravanak@google.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

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?

Thank you!
-- 
Florian