From: Alexandre Mergnat <amergnat@baylibre.com>
To: "AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Nícolas F. R. A. Prado" <nfraprado@collabora.com>
Cc: kernel@collabora.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Fabien Parent <fparent@baylibre.com>,
Conor Dooley <conor+dt@kernel.org>
Subject: Re: [PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles
Date: Tue, 6 May 2025 11:30:08 +0200 [thread overview]
Message-ID: <99febf26-2ada-4fed-b4b3-596ac4abf581@baylibre.com> (raw)
In-Reply-To: <174652097090.119919.16240846809714782858.b4-ty@collabora.com>
Hello Nícolas and Angelo,
On 06/05/2025 10:42, AngeloGioacchino Del Regno wrote:
> On Fri, 02 May 2025 11:32:10 -0400, Nícolas F. R. A. Prado wrote:
>> Some of the regulators in the MT6357 PMIC dtsi have compatible set to
>> regulator-fixed, even though they don't serve any purpose: all those
>> regulators are handled as a whole by the mt6357-regulator driver. In
>> fact this is the only dtsi in this family of chips where this is the
>> case: mt6359 and mt6358 don't have any such compatibles.
>>
>> A side-effect caused by this is that the DT kselftest, which is supposed
>> to identify nodes with compatibles that can be probed, but haven't,
>> shows these nodes as failures.
>>
>> [...]
>
> Applied to v6.15-next/dts64, thanks!
>
> [1/1] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles
> commit: d77e89b7b03fb945b4353f2dcc4a70b34baa7bcb
I'm surprised that patch is applied after the Rob's bot reply.
Also, I've some concern:
On 02/05/2025 17:32, Nícolas F. R. A. Prado wrote:
> Some of the regulators in the MT6357 PMIC dtsi have compatible set to
> regulator-fixed, even though they don't serve any purpose: all those
> regulators are handled as a whole by the mt6357-regulator driver. In
> fact this is the only dtsi in this family of chips where this is the
> case: mt6359 and mt6358 don't have any such compatibles.
This is the only dtsi in this family to do this, yes. But according to
all other vendor DTSI, which use regulator-fixed when a regulator can't
support a range of voltage, IMHO, it make sense to use it, isn't it ?
If other DTSI from the family of chips doesn't, why don't fix them to be
aligned with the other families?
>
> A side-effect caused by this is that the DT kselftest, which is supposed
> to identify nodes with compatibles that can be probed, but haven't,
> shows these nodes as failures.
>
I lack of data about kselftest, but according to what is reported here, it
appear to me this is something which could be fixed in the test itself. It make
sense for a DTS, but not for a DTSI because it expose HW capability of a
device, not the board, so it isn't mandatory to probe all DTSI node.
Again, I'm not an expert, the test shouldn't show the DTSI node as failure,
but maybe more a warning.
> Remove the useless compatibles to move the dtsi in line with the others
> in its family and fix the DT kselftest failures.
If you remove compatible from these regulators, I think mediatek,mt6357-regulator.yaml
documentation file should be modified to be consistent and avoid dt-check error.
>
> Cheers,
> Angelo
>
>
--
Regards,
Alexandre
next prev parent reply other threads:[~2025-05-06 11:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 15:32 [PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles Nícolas F. R. A. Prado
2025-05-05 14:44 ` Rob Herring (Arm)
2025-05-06 8:42 ` AngeloGioacchino Del Regno
2025-05-06 9:30 ` Alexandre Mergnat [this message]
2025-05-06 21:20 ` Nícolas F. R. A. Prado
2025-05-07 7:48 ` Alexandre Mergnat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99febf26-2ada-4fed-b4b3-596ac4abf581@baylibre.com \
--to=amergnat@baylibre.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fparent@baylibre.com \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=nfraprado@collabora.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox