[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c89a2cae-ae96-46ee-a990-0c0ef13fe4de@oss.qualcomm.com>
Date: Tue, 18 Nov 2025 14:16:41 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Krzysztof Kozlowski <krzk@...nel.org>
Cc: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/10] soc: qcom: aoss: Use __cleanup() for device_node
pointers
On 11/18/25 1:52 PM, Dmitry Baryshkov wrote:
> On Tue, Nov 18, 2025 at 01:32:51PM +0100, Krzysztof Kozlowski wrote:
>> On 18/11/2025 13:25, Dmitry Baryshkov wrote:
>>> On Tue, Nov 18, 2025 at 12:39:51PM +0100, Krzysztof Kozlowski wrote:
>>>> On 17/11/2025 12:35, Konrad Dybcio wrote:
>>>>> On 11/17/25 5:51 AM, Kathiravan Thirumoorthy wrote:
>>>>>> Make use of the __cleanup() attribute for device_node pointers to simplify
>>>>>> resource management and remove explicit of_node_put() calls.
>>>>>>
>>>>>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@....qualcomm.com>
>>>>>> ---
>>>>>
>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
>>>>
>>>> This is obviously wrong and not helpful patch.
>>>
>>> Describing why it is wrong would be helpful (or having a pointer to an
>>> explanation). Bear in mind people who read email archives and find this
>>> very brief note.
>>
>> I gave some rationale in other patches, but summarizing:
>> 1. It is against cleanup.h - author did not bother to read it - which
>> clearly asks for constructor with declaration. This was discussed many
>> times in the list, including many bugs and explicit checkpatch warning
>> (on LKML) because people don't bother to read cleanup.h.
Looks like I didn't read it either.. now that I did, I see that
_free(x) = NULL is somewhat of an anti-pattern, but none of these
patches seem to introduce any bugs related to it
>> 2. It makes simple get+put code complicated, not simpler.
Here I tend to disagree..
>> 3. It grows the scope of OF reference without benefits.
This makes sense
Ultimately as you've noticed, this is mostly a cosmetic change and
I don't mind it going either way
Konrad
>> 4. This driver was already reviewed and simplified so author should go
>> back and think why this was left alone (would save a lot of trouble).
>
> Thanks!
>
Powered by blists - more mailing lists