[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3ad5248-fe47-4622-a53b-386e556a0add@kernel.org>
Date: Thu, 5 Sep 2024 15:46:18 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>, quic_dikshita@...cinc.com,
Vikash Garodia <quic_vgarodia@...cinc.com>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>
Cc: linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 10/29] media: iris: implement power management
On 05/09/2024 15:23, Bryan O'Donoghue wrote:
> On 27/08/2024 11:05, Dikshita Agarwal via B4 Relay wrote:
>> From: Dikshita Agarwal <quic_dikshita@...cinc.com>
>>
>> Implement runtime power management for iris including
>> platform specific power on/off sequence.
>>
>> Signed-off-by: Dikshita Agarwal <quic_dikshita@...cinc.com>
>
>> +int iris_hfi_pm_suspend(struct iris_core *core)
>> +{
>> + int ret;
>> +
>> + if (!mutex_is_locked(&core->lock))
>> + return -EINVAL;
>> +
>> + if (core->state != IRIS_CORE_INIT)
>> + return -EINVAL;
>
> Reiterating a previous point
>
> Are these checks realistic or defensive coding ?
Well, this one:
if (!mutex_is_locked(&core->lock))
is clear bug or someone is reinventing lockdep.
>> +
>> + if (!core->power_enabled) {
>> + dev_err(core->dev, "power not enabled\n");
>> + return 0;
>> + }
>
> Similarly is this a real check an error that can happen and if so how ?
And here re-inventing runtime PM.
Best regards,
Krzysztof
Powered by blists - more mailing lists