From: Brian Masney <bmasney@redhat.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>, Ulf Hansson <ulfh@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Neil Armstrong <neil.armstrong@linaro.org>,
Xuyang Dong <dongxuyang@eswincomputing.com>,
Jens Glathe <jens.glathe@oldschoolsolutions.biz>,
Hans de Goede <johannes.goede@oss.qualcomm.com>,
Maxime Ripard <mripard@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Abel Vesa <abelvesa@kernel.org>,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-clk@vger.kernel.org
Subject: Re: [PATCH 1/4] driver: core: introduce dev_add_sync_state()
Date: Mon, 29 Jun 2026 11:31:14 -0400 [thread overview]
Message-ID: <akKPwt8PN_UtawAg@redhat.com> (raw)
In-Reply-To: <fea9665f-d134-4b11-a936-e1f265858ce1@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 12:11:18PM +0200, Konrad Dybcio wrote:
> On 6/26/26 6:32 PM, Brian Masney wrote:
> > We have cases where a device node represents a provider for multiple
> > types of resources, like clocks, power-domains, resets, etc. We
> > currently have dev_set_drv_sync_state() where a framework or driver
> > can set the sync_state callback for a device node, however it currently
> > only supports a single sync_state callback.
> >
> > The pmdomain subsystem currently sets up a sync_state callback in the
> > core framework, and the clk subsystem will setup it's own separate
> > sync_state callback in the core framework. These can collide with each
> > other on some types of devices that have multiple types of resources.
> > Additionally, some clk drivers already have their own separate
> > sync_state callback already defined.
> >
> > Let's introduce support for allowing drivers and frameworks to add their
> > own sync_state callback via a new function dev_add_sync_state() so that
> > multiple sync_state callbacks can coexist.
> >
> > Link: https://lore.kernel.org/linux-clk/CAPx+jO9JiV16ePLk59hTQzEMnA96Va6Ns4jqJbwyZ6oTT0AjXA@mail.gmail.com/
> > Signed-off-by: Brian Masney <bmasney@redhat.com>
> > Assisted-by: Claude:claude-opus-4-6
> > ---
>
> [...]
>
> > +int dev_add_sync_state(struct device *dev,
> > + void (*fn)(struct device *dev))
> > +{
> > + struct sync_state_entry *entry;
> > +
> > + if (!dev || !dev->driver)
> > + return 0;
> > +
> > + list_for_each_entry(entry, &dev->sync_state_list, node)
> > + if (entry->fn == fn)
> > + return 0;
>
> Do we expect this to be a valid call, i.e. should we WARN_ON here?
That's a good point about adding a WARN_ON() here. I kept this logic
from when I converted from dev_set_drv_sync_state().
Brian
next prev parent reply other threads:[~2026-06-29 15:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 16:32 [PATCH 0/4] clk: implement sync_state support Brian Masney
2026-06-26 16:32 ` [PATCH 1/4] driver: core: introduce dev_add_sync_state() Brian Masney
2026-06-29 10:11 ` Konrad Dybcio
2026-06-29 15:31 ` Brian Masney [this message]
2026-06-26 16:32 ` [PATCH 2/4] pmdomain: core: migrate to dev_add_sync_state() Brian Masney
2026-06-29 12:29 ` Konrad Dybcio
2026-06-26 16:32 ` [PATCH 3/4] driver: core: remove dev_set_drv_sync_state() Brian Masney
2026-06-26 16:32 ` [PATCH 4/4] clk: implement sync_state support Brian Masney
2026-06-29 13:44 ` Konrad Dybcio
2026-06-29 15:48 ` Brian Masney
2026-06-29 10:06 ` [PATCH 0/4] " Konrad Dybcio
2026-06-29 15:34 ` Brian Masney
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=akKPwt8PN_UtawAg@redhat.com \
--to=bmasney@redhat.com \
--cc=abelvesa@kernel.org \
--cc=andersson@kernel.org \
--cc=dakr@kernel.org \
--cc=dongxuyang@eswincomputing.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=jens.glathe@oldschoolsolutions.biz \
--cc=johannes.goede@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mripard@kernel.org \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=rafael@kernel.org \
--cc=saravanak@kernel.org \
--cc=sboyd@kernel.org \
--cc=ulfh@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