public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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


  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