Re: [PATCH 2/4] arm64: dts: mediatek: mt8365: use a specific SCPSYS compatible

[Alexandre Mergnat]

On 21/05/2024 10:22, Krzysztof Kozlowski wrote:
> On 20/05/2024 17:23, Alexandre Mergnat wrote:
> > Hello Krzysztof,
> >
> > On 20/05/2024 12:12, AngeloGioacchino Del Regno wrote:
> > > Il 20/05/24 12:03, Krzysztof Kozlowski ha scritto:
> > > > On 20/05/2024 11:55, AngeloGioacchino Del Regno wrote:
> > > > > Il 18/05/24 23:11, Krzysztof Kozlowski ha scritto:
> > > > > > SoCs should use dedicated compatibles for each of their syscon nodes to
> > > > > > precisely describe the block.  Using an incorrect compatible does not
> > > > > > allow to properly match/validate children of the syscon device.  Replace
> > > > > > SYSCFG compatible, which does not have children, with a new dedicated
> > > > > > one for SCPSYS block.
> > > > > >
> > > > > > Signed-off-by: Krzysztof Kozlowski<krzysztof.kozlowski@xxxxxxxxxx>
> > > > > Technically, that's not a SCPSYS block, but called SYSCFG in MT8365, but the
> > > > > meaning and the functioning is the same, so it's fine for me.
> > > > So there are two syscfg blocks? With exactly the same set of registers
> > > > or different?
> > > I'm not sure about that, I don't have the MT8365 datasheet...
> > >
> > > Adding Alexandre to the loop - I think he can clarify as he should have the
> > > required documentation.
> > Unfortunately, The SCPSYS (@10006000) isn't documented, but according to the functionnal
> > specification, it seems to have only one block.
> >
> > I don't have the history why SYSCFG instead of SCPSYS.
> >
> > I've tested your serie and have a regression at the kernel boot time:
> > [    7.738117] mtk-power-controller 10006000.syscon:power-controller: Failed to create device link
> > (0x180) with 14000000.syscon
> >
> > It's related to your patch 3/4.
> I don't see how this could be related. The error is mentioning entirely
> different node - mmsys. No driver binds to 10006000.syscon, except the
> MFD syscon of course, so my change should have zero effect on drivers.
>
> The mtk-pm-domains (so child of patch affected in 3/4) only takes regmap
> from the parent, so the cells again are not related.
>
> Just to be sure: you are testing mainline or next, without any other
> patches on top except mine?

I've tested on next

* a018995ac19c (HEAD -> temp, me/temp) arm64: dts: mediatek: mt8173-elm: correct PMIC's syscon reg entry
* 0f118436c61c arm64: dts: mediatek: mt8365: drop incorrect power-domain-cells
* d40e424fe6dc arm64: dts: mediatek: mt8365: use a specific SCPSYS compatible
* d7caa08a4a9b dt-bindings: mfd: mediatek,mt8195-scpsys: add mediatek,mt8365-scpsys
* 82d92a9a1b9e (tag: next-20240515, linux-next/master) Add linux-next specific files for 20240515
*   77ba09d6e7cb Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git
|\
| * dedcf3a8e704 tools/power turbostat: version 2024.05.10
| * baac2f4c7f3b tools/power turbostat: Ignore pkg_cstate_limit when it is not available
| * a0525800e2dc tools/power turbostat: Fix order of strings in pkg_cstate_limit_strings
| * ffc2e3d90e6f tools/power turbostat: Read Package-cstates via perf


I did the test with and without "0f118436c61c arm64: dts: mediatek: mt8365: drop incorrect 
power-domain-cells"

Without this specific patch, no regression.


--
Regards,
Alexandre