From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Antonio Borneo" <antonio.borneo@foss.st.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Bjorn Andersson" <andersson@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Chen-Yu Tsai" <wens@kernel.org>,
"Chunyan Zhang" <zhang.lyra@gmail.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
driver-core@lists.linux.dev,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Konrad Dybcio" <konradybcio@kernel.org>,
"Lee Jones" <lee@kernel.org>, "Linus Walleij" <linusw@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-iio@vger.kernel.org,
linux-omap@vger.kernel.org, linux-remoteproc@vger.kernel.org,
linux-spi@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-sunxi@lists.linux.dev, "Mark Brown" <broonie@kernel.org>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Orson Zhai" <orsonzhai@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Samuel Holland" <samuel@sholland.org>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Srinivas Kandagatla" <srini@kernel.org>,
"Thomas Gleixner" <tglx@kernel.org>,
"Waiman Long" <longman@redhat.com>,
"Wilken Gottwalt" <wilken.gottwalt@posteo.net>,
"Will Deacon" <will@kernel.org>
Subject: Re: [RFC v2 PATCH 00/13] hwspinlock: move device alloc into core and refactor includes
Date: Mon, 16 Feb 2026 09:40:33 +0200 [thread overview]
Message-ID: <aZLJ8Z4XOTEUJfmh@smile.fi.intel.com> (raw)
In-Reply-To: <20260215225501.6365-1-wsa+renesas@sang-engineering.com>
On Sun, Feb 15, 2026 at 11:54:40PM +0100, Wolfram Sang wrote:
> My ultimate goal is to allow hwspinlock provider drivers outside of the
> subsystem directory. It turned out that a simple split of the headers
> files into a public provider and a public consumer header file is not
> enough because core internal structure need to stay hidden. Even more,
> their opaqueness could and should even be increased. That would also
> allow the core to handle the de-/allocation of the hwspinlock device
> itself.
>
> This series does all that. Patches 1-7 abstract access to internal
> structures away using helpers. Patch 8 then move hwspinlock device
> handling to the core, simplifying drivers. The remaining patches
> refactor the headers until the internal one is gone and the public ones
> are divided into provider and consumer parts. More details are given in
> the patch descriptions.
>
> One note about using a callback to initialize hwspinlock priv: I also
> experimented with a dedicated 'set_priv' helper function. It felt a bit
> clumsy to me. Drivers would need to save the 'bank' pointer again and
> iterate over it. Because most drivers will only have a simple callback
> anyhow, it looked leaner to me.
>
> This series is based on the cleanup series "hwspinlock: remove
> platform_data from subsystem" and has been tested on a Renesas
> SparrowHawk board (R-Car V4H) with a yet-to-be-upstreamed hwspinlock
> driver for the MFIS IP core. A branch can be found here (the MFIS driver
> is still WIP):
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/hwspinlock/refactor-alloc-buildtest
>
> Buildbots seem to be happy, too.
>
> Looking forward to comments. I especially wonder if the last patch
> should stay as-is or if it should be broken out, so individual
> subsystems can pick up their part (with a fallback in place, of course,
> until the last user is converted).
Coincidentally I have briefly reviewed it in the Git tree before you have sent
this to ML. I like the whole series, but what I have missed is the explanation
of the removal of Contact: comment in some of the files.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-02-16 7:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-15 22:54 [RFC v2 PATCH 00/13] hwspinlock: move device alloc into core and refactor includes Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 01/13] hwspinlock: add helpers to retrieve core data Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 02/13] hwspinlock: add callback to fill private data of a hwspinlock Wolfram Sang
2026-02-16 8:05 ` Sergey Shtylyov
2026-02-16 8:29 ` Wolfram Sang
2026-02-16 10:12 ` Geert Uytterhoeven
2026-02-16 10:53 ` Wolfram Sang
2026-02-16 16:12 ` Sergey Shtylyov
2026-02-16 16:54 ` Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 03/13] hwspinlock: omap: use new callback to initialize hwspinlock priv Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 04/13] hwspinlock: qcom: " Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 05/13] hwspinlock: sprd: " Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 06/13] hwspinlock: stm32: " Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 07/13] hwspinlock: sun6i: " Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 08/13] hwspinlock: handle hwspinlock device allocation in the core Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 09/13] hwspinlock: move entries from internal to public header Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 10/13] hwspinlock: remove internal header Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 11/13] hwspinlock: sort include and update copyright Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 12/13] hwspinlock: refactor provider.h from public header Wolfram Sang
2026-02-15 22:54 ` [RFC PATCH v2 13/13] hwspinlock: refactor consumer.h " Wolfram Sang
2026-02-16 7:37 ` Andy Shevchenko
2026-02-16 16:07 ` Mark Brown
2026-02-18 19:56 ` Jonathan Cameron
2026-02-16 7:40 ` Andy Shevchenko [this message]
2026-02-16 8:34 ` [RFC v2 PATCH 00/13] hwspinlock: move device alloc into core and refactor includes Wolfram Sang
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=aZLJ8Z4XOTEUJfmh@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andersson@kernel.org \
--cc=andy@kernel.org \
--cc=antonio.borneo@foss.st.com \
--cc=arnd@arndb.de \
--cc=baolin.wang@linux.alibaba.com \
--cc=boqun@kernel.org \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dlechner@baylibre.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=jernej.skrabec@gmail.com \
--cc=jic23@kernel.org \
--cc=konradybcio@kernel.org \
--cc=lee@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=longman@redhat.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mingo@redhat.com \
--cc=nuno.sa@analog.com \
--cc=orsonzhai@gmail.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=samuel@sholland.org \
--cc=skhan@linuxfoundation.org \
--cc=srini@kernel.org \
--cc=tglx@kernel.org \
--cc=wens@kernel.org \
--cc=wilken.gottwalt@posteo.net \
--cc=will@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
--cc=zhang.lyra@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.