[PATCH v1 1/3] dt-bindings: mmc: rockchip-dw-mshc: add rockchip,disable-runtime-pm
Krzysztof Kozlowski
krzk at kernel.org
Fri Jan 16 02:20:30 PST 2026
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 at 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
More information about the linux-arm-kernel
mailing list