[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMi1Hd2H2aA6EYp5-46dWe0eu0_hAWUumoQbnk7WR0q9bhppog@mail.gmail.com>
Date: Fri, 16 Jun 2023 22:39:47 +0530
From: Amit Pundir <amit.pundir@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Linux regressions mailing list <regressions@...ts.linux.dev>,
Mark Brown <broonie@...nel.org>,
Doug Anderson <dianders@...omium.org>,
Bjorn Andersson <andersson@...nel.org>,
Andy Gross <agross@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Caleb Connolly <caleb.connolly@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
dt <devicetree@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: sdm845-db845c: Move LVS regulator nodes up
Hi,
On Fri, 16 Jun 2023 at 13:57, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
>
> So you have interconnect as module - this is not a supported setup. It
> might work with if all the modules are loaded very early or might not.
> Pinctrl is another driver which should be built-in.
>
> With your defconfig I see regular issue - console and system dies
> because of lack of interconnects, most likely. I don't see your WARNs -
> I just see usual hang.
>
> See:
> https://lore.kernel.org/all/20221021032702.1340963-1-krzysztof.kozlowski@linaro.org/
>
> If you want them to really be modules, then you need to fix all the
> dependencies (SOFTDEP?), probe ordering glitches. It's not a problem of
> DTS. Just because something can be built as module, does not mean it
> will work. We don't test it, we don't work with them as modules.
I do somewhat agree with most of your arguments but not this one. If a
driver doesn't work as a module then it shouldn't be allowed to build
as a module. I took a quick look at the history of the interconnect
driver and it is tristate from the beginning. And not converted to a
modular build later-on like some of the other drivers to support GKI.
>
> It's kind of the same as here:
> https://lore.kernel.org/all/ac328b6a-a8e2-873d-4015-814cb4f5588e@canonical.com/
>
> I understand that we might have here regression, if these were working
> as modules, but I don't think we ever really committed to it. We can as
> well make it non-module to solve the regression.
Sure. But since v6.4 is around the corner, can we merge this
workaround for now, while a proper fix is being worked upon.
Regards,
Amit Pundir
Powered by blists - more mailing lists