linux-kernel - Re: [PATCH v2 05/20] drm/tilcdc: Convert legacy panel binding via DT overlay at boot time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DFGTS953Y2YJ.1SUIIDRMKUGQJ@bootlin.com>
Date: Mon, 05 Jan 2026 18:18:32 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.com>
To: "Kory Maincent" <kory.maincent@...tlin.com>
Cc: "Jyri Sarha" <jyri.sarha@....fi>, "Tomi Valkeinen"
 <tomi.valkeinen@...asonboard.com>, "Maarten Lankhorst"
 <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard" <mripard@...nel.org>,
 "Thomas Zimmermann" <tzimmermann@...e.de>, "David Airlie"
 <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>, "Rob Herring"
 <robh@...nel.org>, "Krzysztof Kozlowski" <krzk+dt@...nel.org>, "Conor
 Dooley" <conor+dt@...nel.org>, "Russell King" <linux@...linux.org.uk>,
 "Bartosz Golaszewski" <brgl@...ev.pl>, "Tony Lindgren" <tony@...mide.com>,
 "Andrzej Hajda" <andrzej.hajda@...el.com>, "Neil Armstrong"
 <neil.armstrong@...aro.org>, "Robert Foss" <rfoss@...nel.org>, "Laurent
 Pinchart" <Laurent.pinchart@...asonboard.com>, "Jonas Karlman"
 <jonas@...boo.se>, "Jernej Skrabec" <jernej.skrabec@...il.com>, "Markus
 Schneider-Pargmann" <msp@...libre.com>, "Bajjuri Praneeth"
 <praneeth@...com>, "Louis Chauvet" <louis.chauvet@...tlin.com>, "Thomas
 Petazzoni" <thomas.petazzoni@...tlin.com>, "Miguel Gazquez"
 <miguel.gazquez@...tlin.com>, <dri-devel@...ts.freedesktop.org>,
 <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <linux-arm-kernel@...ts.infradead.org>, <linux-omap@...r.kernel.org>
Subject: Re: [PATCH v2 05/20] drm/tilcdc: Convert legacy panel binding via
 DT overlay at boot time

Hi Köry,

On Mon Jan 5, 2026 at 3:29 PM CET, Kory Maincent wrote:
>> > +static int __init tilcdc_panel_copy_props(struct device_node *old_panel,
>> > +					  struct device_node *new_panel)
>> > +{
>> > +	struct device_node *child, *old_timing, *new_timing, *panel_info;
>> > +	u32 invert_pxl_clk = 0, sync_edge = 0;
>> > +	struct property *prop;
>> > +
>> > +	/* Copy all panel properties to the new panel node */
>> > +	for_each_property_of_node(old_panel, prop) {
>> > +		if (!strncmp(prop->name, "compatible",
>> > sizeof("compatible")))
>> > +			continue;
>> > +
>> > +		tilcdc_panel_update_prop(new_panel, prop->name,
>> > +					 prop->value, prop->length);
>> > +	}
>> > +
>> > +	child = of_get_child_by_name(old_panel, "display-timings");
>>
>> There's some housekeeping code in this function to ensure you put all the
>> device_node refs. It would be simpler and less error prone to use a cleanup
>> action. E.g.:
>>
>> -	struct device_node *child, *old_timing, *new_timing, *panel_info;
>>
>> -	child = of_get_child_by_name(old_panel, "display-timings");
>> +	struct device_node *child __free(device_node) =
>> of_get_child_by_name(old_panel, "display-timings");
>
> I am not used to this __free() macro and even some subsystem (net) are avoiding
> it but ok I will move to it. I don't know what are the pros and cons.

I don't see drawbacks from a technical point of view. Only potentially a
matter of taste.

The pro is that with a cleanup action the compiler will put the cleanup
code at scope exit, whichever exit point is taken. Example:

int myfunc()
{
    struct device_node *node1, *node2, *node3;

    struct device_node *node1 = of_get_child_by_name();
    ...
    if (foo) {
        of_node_put(node1);
        return -E...;
    }

    struct device_node *node2 = of_get_child_by_name();
    ...
    if (bar) {
        of_node_put(node2);
        of_node_put(node1);
        return -E...;
    }

    struct device_node *node3 = of_get_child_by_name();
    ...
    if (foo) {
        of_node_put(node3);
        of_node_put(node2);
        of_node_put(node1);
        return -E...;
    }
}

Here the of_node_put() list grows at every return point. Of course you can
use gotos to do all the of_node_put()s in a single place, but still with
some code to maintain, potential bugs, and take care of corner cases in
case of a complex code path.

Same example with a cleanup action:

int myfunc()
{
    struct device_node *node1 __free(of_node_put) = of_get_child_by_name();
    ...
    if (foo)
        return -E...;

    struct device_node *node2 __free(of_node_put) = of_get_child_by_name();
    ...
    if (bar)
        return -E...;

    struct device_node *node3 __free(of_node_put) = of_get_child_by_name();
    ...
    if (foo)
        return -E...;
}

The compiler will insert the of_node_put() calls at scope exit (the scope
is the entire function in the above example), so they are called whichever
'return' statement happens. Pros: less code to write and maintain, code is
cleaner, less potential mistakes.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com