From: Krzysztof Kozlowski <krzk@kernel.org>
To: "Heiko Stübner" <heiko@sntech.de>,
"Marco Schirrmeister" <mschirrmeister@gmail.com>
Cc: ulf.hansson@linaro.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, linux-rockchip@lists.infradead.org,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 1/3] dt-bindings: mmc: rockchip-dw-mshc: add rockchip,disable-runtime-pm
Date: Fri, 16 Jan 2026 11:20:30 +0100 [thread overview]
Message-ID: <8ba68d9c-5cd1-4616-998e-2ff5d3440984@kernel.org> (raw)
In-Reply-To: <1791168.izSxrag8PF@diego>
On 16/01/2026 10:43, Heiko Stübner wrote:
> Hi Marco,
>
> Am Montag, 12. Januar 2026, 00:51:24 Mitteleuropäische Normalzeit schrieb Marco Schirrmeister:
>> On Sun, Jan 11, 2026 at 10:41 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>> + rockchip,disable-runtime-pm:
>>>> + type: boolean
>>>> + description:
>>>> + Inhibit runtime power management. This is required for boards
>>>
>>> What is runtime power management? Like Linux PM? If anything phrased
>>> like that is it is a clear no go. Bindings describe hardware.
>>
>> You are right. This refers to the Linux PM subsystem and describes
>> software behavior.
>>
>>>> + where the bus timing becomes unstable if the controller is
>>>> + runtime-suspended.
>>>
>>> You described the desired Linux feature or behavior, not the actual
>>> hardware. The bindings are about the latter, so instead you need to
>>> rephrase the property and its description to match actual hardware
>>> capabilities/features/configuration etc.
>>
>> On this board, the bus timing becomes unstable when waking up from
>> a low-power state. This causes a constant retraining loop.
>
> As you describe it here, it does sound like a real hardware quirk (which
> would be a dt-thing) ... it's just that the previous wording describes it
> in a non-hardware way - as Krzysztof pointed out in his reply.
I can also imagine that you miss some register programming, clocks or
regulator voltage, so "unstable" has to be actually analyzed.
You should not really disable a Linux driver feature just because your
hardware has issues. And even then it's more likely some MMC core part,
not entire runtime PM, is problematic here.
>
>
>> I will move this logic into the driver and handle it as a board specific
>> quirk using of_machine_is_compatible("friendlyarm,nanopi-r76s")
>> instead. I will send a v2.
>
> This won't fly I think. We can't really have a (possibly long) list of
>
> If (boardA) foo();
> if (boardB) bar();
> if (boardC) bas();
>
> That really is not sustainable and most likely won't get accepted.
Yep
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-01-16 10:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-10 1:07 [PATCH v1 0/3] mmc: dw_mmc-rockchip: Add stability quirk for NanoPi R76S Marco Schirrmeister
2026-01-10 1:07 ` [PATCH v1 1/3] dt-bindings: mmc: rockchip-dw-mshc: add rockchip,disable-runtime-pm Marco Schirrmeister
2026-01-10 2:25 ` Rob Herring (Arm)
2026-01-11 9:41 ` Krzysztof Kozlowski
2026-01-11 23:51 ` Marco Schirrmeister
2026-01-16 9:43 ` Heiko Stübner
2026-01-16 10:20 ` Krzysztof Kozlowski [this message]
2026-01-10 1:07 ` [PATCH v1 2/3] mmc: host: dw_mmc-rockchip: add rockchip,disable-runtime-pm quirk Marco Schirrmeister
2026-01-10 1:07 ` [PATCH v1 3/3] arm64: dts: rockchip: add stability quirk to NanoPi R76S Marco Schirrmeister
2026-01-11 9:42 ` Krzysztof Kozlowski
2026-01-12 1:32 ` [PATCH v1 0/3] mmc: dw_mmc-rockchip: Add stability quirk for " Shawn Lin
2026-01-12 3:56 ` Shawn Lin
2026-01-12 8:29 ` Chaoyi Chen
2026-01-12 8:58 ` Shawn Lin
2026-01-12 19:09 ` Marco Schirrmeister
2026-01-14 8:08 ` Shawn Lin
2026-01-14 19:51 ` Marco Schirrmeister
2026-01-15 0:25 ` Shawn Lin
2026-01-15 19:39 ` Marco Schirrmeister
2026-01-16 0:31 ` Shawn Lin
2026-01-12 19:04 ` Marco Schirrmeister
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=8ba68d9c-5cd1-4616-998e-2ff5d3440984@kernel.org \
--to=krzk@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mschirrmeister@gmail.com \
--cc=robh@kernel.org \
--cc=ulf.hansson@linaro.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