From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Hui Pu <Hui.Pu@gehealthcare.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Dmitry Baryshkov <lumag@kernel.org>
Subject: Re: [PATCH 2/2] drm/bridge: ti-sn65dsi83: protect device resources on unplug
Date: Thu, 11 Sep 2025 15:09:33 +0200 [thread overview]
Message-ID: <20250911150933.52a0416d@booty> (raw)
In-Reply-To: <20250911-adept-vengeful-jacamar-15f2a0@houat>
Hi Maxime,
On Thu, 11 Sep 2025 08:44:34 +0200
Maxime Ripard <mripard@kernel.org> wrote:
> > > > Option 2: have a function to unconditionally do the cleanups:
> > > >
> > > > sn65dsi83_cleanups()
> > > > {
> > > > /* the same cleanups (no if) */
> > > > }
> > > >
> > > > And then:
> > > > * in atomic_pre_enable, instead of setting the flag
> > > > add a devres action to call sn65dsi83_cleanups()
> > > > * in atomic_disable, instead of clearing the flag
> > > > remove the devres action
> > > >
> > > > Even this option looks like more complicated and less readable code
> > > > to do the same thing.
> > > >
> > > > Do you have in mind a better option that I haven't figured out?
> > >
> > > Would using devm_add_action in atomic_pre_enable, and
> > > devm_release_action in atomic_post_disable work?
> > >
> > > That way, if you have a typical enable / disable cycle, the action will
> > > get registered and executed properly, and if you only have an enable but
> > > no matching disable, it will be collected after remove.
> >
> > So you're OK with option 2. I just implemented it, works well and the
> > resulting code is a bit cleaner. Queued for v2.
>
> Kind of, but you shouldn't remove but release it, and it doesn't have to
> be a single action / function.
Released instead of removed: yes.
Doesn't have to be a single function: I currently implemented a single
function with the 3 actions that are currently done in atomic_disable.
I think you propose to add 3 different devres actions, one for each,
but it would be more code and a little more resources used and I don't
see the advantage.
I think it makes sense that I send my current version and we can
continue discussion based on the code. I'm waiting a bit before
sending it, in case you have feedback about the other branch of this
discussion (placement of drm_bridge_unplug()).
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2025-09-11 13:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 13:24 [PATCH 0/2] drm/bridge: handle gracefully atomic updates during bridge removal Luca Ceresoli
2025-08-08 13:24 ` [PATCH 1/2] drm/bridge: add drm_bridge_unplug() and drm_bridge_enter/exit() Luca Ceresoli
2025-08-08 13:24 ` [PATCH 2/2] drm/bridge: ti-sn65dsi83: protect device resources on unplug Luca Ceresoli
2025-08-19 12:29 ` Maxime Ripard
2025-08-20 11:13 ` Luca Ceresoli
2025-08-27 7:46 ` Maxime Ripard
2025-09-08 13:49 ` Luca Ceresoli
2025-09-10 10:59 ` Maxime Ripard
2025-09-10 16:47 ` Luca Ceresoli
2025-09-15 12:03 ` Maxime Ripard
2025-09-15 14:51 ` Luca Ceresoli
2025-09-26 16:37 ` Luca Ceresoli
2025-10-07 15:09 ` Maxime Ripard
2025-10-09 14:48 ` Luca Ceresoli
2025-09-08 13:49 ` Luca Ceresoli
2025-09-10 7:52 ` Maxime Ripard
2025-09-10 16:34 ` Luca Ceresoli
2025-09-11 6:44 ` Maxime Ripard
2025-09-11 13:09 ` Luca Ceresoli [this message]
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=20250911150933.52a0416d@booty \
--to=luca.ceresoli@bootlin.com \
--cc=Hui.Pu@gehealthcare.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=thomas.petazzoni@bootlin.com \
--cc=tzimmermann@suse.de \
/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