From: Krzysztof Kozlowski <krzk@kernel.org>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Kathiravan Thirumoorthy
<kathiravan.thirumoorthy@oss.qualcomm.com>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/10] soc: qcom: aoss: Use __cleanup() for device_node pointers
Date: Tue, 18 Nov 2025 14:25:45 +0100 [thread overview]
Message-ID: <9fff160b-e8ef-4a28-8445-e53cc5ffc407@kernel.org> (raw)
In-Reply-To: <c89a2cae-ae96-46ee-a990-0c0ef13fe4de@oss.qualcomm.com>
On 18/11/2025 14:16, Konrad Dybcio wrote:
> 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@oss.qualcomm.com>
>>>>>>> ---
>>>>>>
>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.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
True
> patches seem to introduce any bugs related to it
True
>
>>> 2. It makes simple get+put code complicated, not simpler.
>
> Here I tend to disagree..
of_get and immediate of_put is really obvious and easy to read. It is
really a common pattern.
OTOH code like:
struct device_node *np = of_parse_whatever_which_is_get()
...
bunch of code here where np is actually used.
...
... more code
return;
is not simple. The lifecycle of this variable becomes very long and
where it is acquired - at beginning - causes question - why do you need
to acquire it there?
That's why cleanup.h has VERY specific syntax different than rest of kernel.
If contributor does not know this syntax, don't send the patches. They
are wrong.
>
>>> 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
It is not cosmetic. It is anti-pattern.
Anti-patterns, even without introducing bugs, make the code WORSE to
maintain. Worse code is not cosmetic.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-11-18 13:25 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 4:51 [PATCH 00/10] soc: qcom: Use __cleanup() for device_node pointers Kathiravan Thirumoorthy
2025-11-17 4:51 ` [PATCH 01/10] soc: qcom: aoss: " Kathiravan Thirumoorthy
2025-11-17 11:35 ` Konrad Dybcio
2025-11-18 11:39 ` Krzysztof Kozlowski
2025-11-18 12:25 ` Dmitry Baryshkov
2025-11-18 12:32 ` Krzysztof Kozlowski
2025-11-18 12:52 ` Dmitry Baryshkov
2025-11-18 13:16 ` Konrad Dybcio
2025-11-18 13:25 ` Krzysztof Kozlowski [this message]
2025-11-18 15:18 ` Kathiravan Thirumoorthy
2025-11-18 11:38 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 02/10] soc: qcom: gsbi: " Kathiravan Thirumoorthy
2025-11-17 11:35 ` Konrad Dybcio
2025-11-18 11:38 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 03/10] soc: qcom: pd-mapper: " Kathiravan Thirumoorthy
2025-11-17 11:36 ` Konrad Dybcio
2025-11-18 11:43 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 04/10] soc: qcom: rpm-proc: " Kathiravan Thirumoorthy
2025-11-17 11:36 ` Konrad Dybcio
2025-11-18 11:40 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 05/10] soc: qcom: rpm_master_stats: " Kathiravan Thirumoorthy
2025-11-17 11:37 ` Konrad Dybcio
2025-11-18 11:40 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 06/10] soc: qcom: smem: " Kathiravan Thirumoorthy
2025-11-17 11:37 ` Konrad Dybcio
2025-11-18 11:42 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 07/10] soc: qcom: smp2p: " Kathiravan Thirumoorthy
2025-11-17 11:37 ` Konrad Dybcio
2025-11-18 11:41 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 08/10] soc: qcom: smsm: " Kathiravan Thirumoorthy
2025-11-17 11:38 ` Konrad Dybcio
2025-11-18 11:42 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 09/10] soc: qcom: spm: " Kathiravan Thirumoorthy
2025-11-17 11:38 ` Konrad Dybcio
2025-11-18 11:42 ` Krzysztof Kozlowski
2025-11-17 4:51 ` [PATCH 10/10] soc: qcom: ubwc: " Kathiravan Thirumoorthy
2025-11-17 11:39 ` Konrad Dybcio
2025-11-18 11:43 ` Krzysztof Kozlowski
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=9fff160b-e8ef-4a28-8445-e53cc5ffc407@kernel.org \
--to=krzk@kernel.org \
--cc=andersson@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=kathiravan.thirumoorthy@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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