[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