[RFC,v2,00/13] hwspinlock: move device alloc into core and refactor includes

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).

Happy hacking,

   Wolfram


Wolfram Sang (13):
  hwspinlock: add helpers to retrieve core data
  hwspinlock: add callback to fill private data of a hwspinlock
  hwspinlock: omap: use new callback to initialize hwspinlock priv
  hwspinlock: qcom: use new callback to initialize hwspinlock priv
  hwspinlock: sprd: use new callback to initialize hwspinlock priv
  hwspinlock: stm32: use new callback to initialize hwspinlock priv
  hwspinlock: sun6i: use new callback to initialize hwspinlock priv
  hwspinlock: handle hwspinlock device allocation in the core
  hwspinlock: move entries from internal to public header
  hwspinlock: remove internal header
  hwspinlock: sort include and update copyright
  hwspinlock: refactor provider.h from public header
  hwspinlock: refactor consumer.h from public header

 Documentation/locking/hwspinlock.rst          |   2 +-
 MAINTAINERS                                   |   2 +-
 drivers/base/regmap/regmap.c                  |   2 +-
 drivers/hwspinlock/hwspinlock_core.c          | 129 +++++++++++++-----
 drivers/hwspinlock/hwspinlock_internal.h      |  72 ----------
 drivers/hwspinlock/omap_hwspinlock.c          |  29 ++--
 drivers/hwspinlock/qcom_hwspinlock.c          |  69 +++++-----
 drivers/hwspinlock/sprd_hwspinlock.c          |  41 +++---
 drivers/hwspinlock/stm32_hwspinlock.c         |  28 ++--
 drivers/hwspinlock/sun6i_hwspinlock.c         |  38 ++----
 drivers/iio/adc/sc27xx_adc.c                  |   2 +-
 drivers/irqchip/irq-stm32mp-exti.c            |   2 +-
 drivers/mfd/syscon.c                          |   2 +-
 drivers/nvmem/sc27xx-efuse.c                  |   2 +-
 drivers/nvmem/sprd-efuse.c                    |   2 +-
 drivers/pinctrl/stm32/pinctrl-stm32.c         |   2 +-
 drivers/soc/qcom/smem.c                       |   2 +-
 drivers/spi/spi-sprd-adi.c                    |   2 +-
 .../{hwspinlock.h => hwspinlock/consumer.h}   |  29 +---
 include/linux/hwspinlock/provider.h           |  60 ++++++++
 20 files changed, 268 insertions(+), 249 deletions(-)
 delete mode 100644 drivers/hwspinlock/hwspinlock_internal.h
 rename include/linux/{hwspinlock.h => hwspinlock/consumer.h} (93%)
 create mode 100644 include/linux/hwspinlock/provider.h
  

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.
  

> > 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.

Ah, thanks! True, documenting it slipped through the cracks. Sorry about
that. The reason is, of course, we have MAINTAINERS for this kind of
information. Plus, Ohad Ben-Cohen hasn't been commiting upstream to 10+
years according to git history.