[RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

TLDR: I want to create a hwspinlock provider outside of the hwspinlock
directory. So, I refactored the headers into a provider/consumer pair.
Which seems to me like a reasonable seperation anyhow. No functional
changes. My build tests went fine and buildbots are happy, too.

Longer explanation:

There is a device (MFIS) in newer Renesas SoCs which combines various
things like hwspinlocks, mailboxes and other stuff. Sadly, these are not
strictly separated. Registers are kind of mixed and its register
unprotection scheme will need one of its own locks. I tried various
paths to handle this device (MFD, auxiliary bus) but I concluded that
the sub-device dependencies give enough reasons for a single driver in
drivers/soc/. So, this series will allow me to instantiate a hwspinlock
provider from the other directory.

Patches 1+2 do the actual refactoring with a fallback being in place. I
used '-B' with git-format-patch in this RFC, so the actual changes are
more visible when the headers are moved.

Patch 3 converts all the users. There are not many. We could try to get
all the acks for this single patch. Or I can break it into single
patches and send them to subsystems. I don't mind.

Patch 4 simply removes the fallback.

Looking forward to comments on this approach. If the hwspinlock
maintainers like it as is, I would kindly propose to apply patches 1+2
after 7.0-rc1 comes out. This might sound a bit hasty, but a) I want to
avoid chasing a moving target and b) this would remove one dependency of
the hwspinlock driver I originally intend to upstream, of course.

I would take care of patches 3+4 as needed.

A branch can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/hwspinlock/refactor-includes

Patches are based on linux-next as of 2026-01-21.

Opinions?

Thanks and happy hacking,

   Wolfram


Wolfram Sang (4):
  hwspinlock: refactor existing headers into provider.h
  hwspinlock: refactor existing headers into consumer.h
  treewide: convert hwspinlock users to the new consumer header file
  hwspinlock: remove old header file

 Documentation/locking/hwspinlock.rst          |  2 +-
 MAINTAINERS                                   |  2 +-
 drivers/base/regmap/regmap.c                  |  2 +-
 drivers/hwspinlock/hwspinlock_core.c          |  5 +--
 drivers/hwspinlock/omap_hwspinlock.c          |  4 +-
 drivers/hwspinlock/qcom_hwspinlock.c          |  4 +-
 drivers/hwspinlock/sprd_hwspinlock.c          |  4 +-
 drivers/hwspinlock/stm32_hwspinlock.c         |  4 +-
 drivers/hwspinlock/sun6i_hwspinlock.c         |  4 +-
 drivers/hwspinlock/u8500_hsem.c               |  5 +--
 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}   | 22 ++--------
 .../linux/hwspinlock/provider.h               | 40 ++++++++++++-------
 20 files changed, 49 insertions(+), 65 deletions(-)
 rename include/linux/{hwspinlock.h => hwspinlock/consumer.h} (94%)
 rename drivers/hwspinlock/hwspinlock_internal.h => include/linux/hwspinlock/provider.h (78%)

-- 
2.47.3

[RFC PATCH 3/4] treewide: convert hwspinlock users to the new consumer header file

[Wolfram Sang]

Point the drivers to the new header file. No functional changes.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/base/regmap/regmap.c          | 2 +-
 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 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index ae2215d4e61c..ec2348e199c1 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -16,7 +16,7 @@
 #include <linux/sched.h>
 #include <linux/delay.h>
 #include <linux/log2.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/unaligned.h>
 
 #define CREATE_TRACE_POINTS
diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
index 6209499c5c37..8a881d63b7dd 100644
--- a/drivers/iio/adc/sc27xx_adc.c
+++ b/drivers/iio/adc/sc27xx_adc.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (C) 2018 Spreadtrum Communications Inc.
 
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/iio/iio.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
diff --git a/drivers/irqchip/irq-stm32mp-exti.c b/drivers/irqchip/irq-stm32mp-exti.c
index a24f4f1a4f8f..25d5aa67728a 100644
--- a/drivers/irqchip/irq-stm32mp-exti.c
+++ b/drivers/irqchip/irq-stm32mp-exti.c
@@ -6,7 +6,7 @@
  */
 
 #include <linux/bitops.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/irq.h>
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index e5d5def594f6..49473669e84e 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -11,7 +11,7 @@
 #include <linux/cleanup.h>
 #include <linux/clk.h>
 #include <linux/err.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/list.h>
 #include <linux/mutex.h>
 #include <linux/of.h>
diff --git a/drivers/nvmem/sc27xx-efuse.c b/drivers/nvmem/sc27xx-efuse.c
index 4e2ffefac96c..309090cd4ff0 100644
--- a/drivers/nvmem/sc27xx-efuse.c
+++ b/drivers/nvmem/sc27xx-efuse.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (C) 2018 Spreadtrum Communications Inc.
 
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
diff --git a/drivers/nvmem/sprd-efuse.c b/drivers/nvmem/sprd-efuse.c
index 1a7e4e5d8b86..92e3092719ba 100644
--- a/drivers/nvmem/sprd-efuse.c
+++ b/drivers/nvmem/sprd-efuse.c
@@ -3,7 +3,7 @@
 
 #include <linux/clk.h>
 #include <linux/delay.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/nvmem-provider.h>
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 6a99708a5a23..17b2072d609e 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -10,7 +10,7 @@
 #include <linux/clk.h>
 #include <linux/export.h>
 #include <linux/gpio/driver.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/mfd/syscon.h>
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 088b2bbee9e6..4cc65b6a7f24 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -4,7 +4,7 @@
  * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
  */
 
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/of.h>
diff --git a/drivers/spi/spi-sprd-adi.c b/drivers/spi/spi-sprd-adi.c
index e7d83c16b46c..04313e4a63dd 100644
--- a/drivers/spi/spi-sprd-adi.c
+++ b/drivers/spi/spi-sprd-adi.c
@@ -5,7 +5,7 @@
  */
 
 #include <linux/delay.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
-- 
2.47.3

Re: [RFC PATCH 3/4] treewide: convert hwspinlock users to the new consumer header file

[Andy Shevchenko]

On Sun, Jan 25, 2026 at 07:46:54PM +0100, Wolfram Sang wrote:
> Point the drivers to the new header file. No functional changes.

...

> +++ b/drivers/base/regmap/regmap.c

>  #include <linux/sched.h>
>  #include <linux/delay.h>
>  #include <linux/log2.h>
> -#include <linux/hwspinlock.h>
> +#include <linux/hwspinlock/consumer.h>
>  #include <linux/unaligned.h>

Can it be also moved to be a bit more ordered? (With given context like to put
it before log2.h).

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH 3/4] treewide: convert hwspinlock users to the new consumer header file

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

On Sun, Jan 25, 2026 at 07:46:54PM +0100, Wolfram Sang wrote:
> Point the drivers to the new header file. No functional changes.

Acked-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Andy Shevchenko]

On Sun, Jan 25, 2026 at 07:46:51PM +0100, Wolfram Sang wrote:
> TLDR: I want to create a hwspinlock provider outside of the hwspinlock
> directory. So, I refactored the headers into a provider/consumer pair.
> Which seems to me like a reasonable seperation anyhow. No functional
> changes. My build tests went fine and buildbots are happy, too.
> 
> Longer explanation:
> 
> There is a device (MFIS) in newer Renesas SoCs which combines various
> things like hwspinlocks, mailboxes and other stuff. Sadly, these are not
> strictly separated. Registers are kind of mixed and its register
> unprotection scheme will need one of its own locks. I tried various
> paths to handle this device (MFD, auxiliary bus) but I concluded that
> the sub-device dependencies give enough reasons for a single driver in
> drivers/soc/. So, this series will allow me to instantiate a hwspinlock
> provider from the other directory.
> 
> Patches 1+2 do the actual refactoring with a fallback being in place. I
> used '-B' with git-format-patch in this RFC, so the actual changes are
> more visible when the headers are moved.
> 
> Patch 3 converts all the users. There are not many. We could try to get
> all the acks for this single patch. Or I can break it into single
> patches and send them to subsystems. I don't mind.
> 
> Patch 4 simply removes the fallback.
> 
> Looking forward to comments on this approach. If the hwspinlock
> maintainers like it as is, I would kindly propose to apply patches 1+2
> after 7.0-rc1 comes out. This might sound a bit hasty, but a) I want to
> avoid chasing a moving target and b) this would remove one dependency of
> the hwspinlock driver I originally intend to upstream, of course.
> 
> I would take care of patches 3+4 as needed.
> 
> A branch can be found here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/hwspinlock/refactor-includes
> 
> Patches are based on linux-next as of 2026-01-21.
> 
> Opinions?

I don't like the idea of sharing internal stuff. Why would we need to have
a struct hwspinlock to be visible?

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

> I don't like the idea of sharing internal stuff. Why would we need to have
> a struct hwspinlock to be visible?

Providers need it, especially the 'priv' member. Consumers won't see it.

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Andy Shevchenko]

On Mon, Jan 26, 2026 at 11:13:59AM +0100, Wolfram Sang wrote:
> 
> > I don't like the idea of sharing internal stuff. Why would we need to have
> > a struct hwspinlock to be visible?
> 
> Providers need it, especially the 'priv' member. Consumers won't see it.

But can't we make it opaque?

We may have getters and setters for the priv member...

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

> > Providers need it, especially the 'priv' member. Consumers won't see it.
> 
> But can't we make it opaque?
> 
> We may have getters and setters for the priv member...

I think we could do that.

Two drivers use the bank member, but only for the device
(lock->bank->dev). That can probably be refactored away, I'd guess.

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

Hi all,

> > > Providers need it, especially the 'priv' member. Consumers won't see it.
> > 
> > But can't we make it opaque?
> > 
> > We may have getters and setters for the priv member...
> 
> I think we could do that.
> 
> Two drivers use the bank member, but only for the device
> (lock->bank->dev). That can probably be refactored away, I'd guess.

I am willing to develop this series in the above direction. Before
though, I'd like to know from hwspinlock maintainers if they agree to
this refactoring in general.

Thanks and happy hacking,

   Wolfram

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

Hi Bjorn, Baolin Wang,

> > > > Providers need it, especially the 'priv' member. Consumers won't see it.
> > > 
> > > But can't we make it opaque?
> > > 
> > > We may have getters and setters for the priv member...
> > 
> > I think we could do that.
> > 
> > Two drivers use the bank member, but only for the device
> > (lock->bank->dev). That can probably be refactored away, I'd guess.
> 
> I am willing to develop this series in the above direction. Before
> though, I'd like to know from hwspinlock maintainers if they agree to
> this refactoring in general.

Moving maintainers from CC to To ;) Do you, in general, approve this
change to the headers? I think it is more modern and e.g. the mailbox
subsystem has a similar structure, a header for the client and a header
for the controller. And do you also prefer an opaque 'priv' member?

Happy hacking,

   Wolfram

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 12:14:52PM +0100, Wolfram Sang wrote:

> > > > > Providers need it, especially the 'priv' member. Consumers won't see it.
> > > > 
> > > > But can't we make it opaque?
> > > > 
> > > > We may have getters and setters for the priv member...
> > > 
> > > I think we could do that.
> > > 
> > > Two drivers use the bank member, but only for the device
> > > (lock->bank->dev). That can probably be refactored away, I'd guess.
> > 
> > I am willing to develop this series in the above direction. Before
> > though, I'd like to know from hwspinlock maintainers if they agree to
> > this refactoring in general.
> 
> Moving maintainers from CC to To ;) Do you, in general, approve this
> change to the headers? I think it is more modern and e.g. the mailbox
> subsystem has a similar structure, a header for the client and a header
> for the controller. And do you also prefer an opaque 'priv' member?

I'm in To and I am fine with this change (but not sure if I'm anyhow
a maintainer in the matter of the series).

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Bjorn Andersson]

On Mon, Feb 09, 2026 at 12:14:52PM +0100, Wolfram Sang wrote:
> Hi Bjorn, Baolin Wang,
> 
> > > > > Providers need it, especially the 'priv' member. Consumers won't see it.
> > > > 
> > > > But can't we make it opaque?
> > > > 
> > > > We may have getters and setters for the priv member...
> > > 
> > > I think we could do that.
> > > 
> > > Two drivers use the bank member, but only for the device
> > > (lock->bank->dev). That can probably be refactored away, I'd guess.
> > 
> > I am willing to develop this series in the above direction. Before
> > though, I'd like to know from hwspinlock maintainers if they agree to
> > this refactoring in general.
> 
> Moving maintainers from CC to To ;) Do you, in general, approve this
> change to the headers?

Certainly, I don't think we should force unnatural slicing of drivers
across the source tree.

> I think it is more modern and e.g. the mailbox subsystem has a similar
> structure, a header for the client and a header for the controller.

gpio, regulators, resets to name a few more.

> And do you also prefer an opaque 'priv' member?
> 

'priv' is already opaque, so I presume you're asking if we can make
struct hwspinlock internal to hwspinlock_core.c?

I can see the allure of making hwspinlock::lock internal to the core,
but (luckily) I don't see it to be a matter of just slapping some OOP it
and call it solved. It would have to come with a new model for how we
create the hwspinlock in the first place - as this is currently
allocated as a whole by the provider driver.

I've always found the current model unergonomic, resolving this part
might very well have the side effect that Andy is looking for (and I'd
welcome that).

Regards,
Bjorn

> Happy hacking,
> 
>    Wolfram
> 

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

Hi Bjorn,

thanks for the reply!

> > Moving maintainers from CC to To ;) Do you, in general, approve this
> > change to the headers?
> 
> Certainly, I don't think we should force unnatural slicing of drivers
> across the source tree.

Cool, glad you like it.

> I've always found the current model unergonomic, resolving this part
> might very well have the side effect that Andy is looking for (and I'd
> welcome that).

Yeah probably, but frankly the task of redesigning hwlock-allocation is
a bit exceeding my bandwidth for this project. Can we make this a second
step on top of this series? And if so, would be this series acceptable
as-is then (modulo the better include-sorting mentioned by Andy)?

Hope you are well,

   Wolfram

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Bjorn Andersson]

On Mon, Feb 09, 2026 at 08:51:46PM +0100, Wolfram Sang wrote:
> Hi Bjorn,
> 
> thanks for the reply!
> 
> > > Moving maintainers from CC to To ;) Do you, in general, approve this
> > > change to the headers?
> > 
> > Certainly, I don't think we should force unnatural slicing of drivers
> > across the source tree.
> 
> Cool, glad you like it.
> 
> > I've always found the current model unergonomic, resolving this part
> > might very well have the side effect that Andy is looking for (and I'd
> > welcome that).
> 
> Yeah probably, but frankly the task of redesigning hwlock-allocation is
> a bit exceeding my bandwidth for this project. Can we make this a second
> step on top of this series?

I'm okay with that. It's winter and the yak might need its fur.

> And if so, would be this series acceptable
> as-is then (modulo the better include-sorting mentioned by Andy)?
> 

Sounds good, I'll pick up your v2 once we get out of the merge window
and share a immutable branch for the other subsystems.

> Hope you are well,
> 

Likewise,
Bjorn

>    Wolfram
> 

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 08:51:46PM +0100, Wolfram Sang wrote:

> > > Moving maintainers from CC to To ;) Do you, in general, approve this
> > > change to the headers?
> > 
> > Certainly, I don't think we should force unnatural slicing of drivers
> > across the source tree.
> 
> Cool, glad you like it.
> 
> > I've always found the current model unergonomic, resolving this part
> > might very well have the side effect that Andy is looking for (and I'd
> > welcome that).
> 
> Yeah probably, but frankly the task of redesigning hwlock-allocation is
> a bit exceeding my bandwidth for this project. Can we make this a second
> step on top of this series?

How do you see it's done if others will (*) start (ab)using that struct
directly?

> And if so, would be this series acceptable
> as-is then (modulo the better include-sorting mentioned by Andy)?

*From my experience it's not the Q "will they or not?", the Q is "when?"
 they start abusing it. I really prefer to hide as much as possible from
 day 1. Maybe the structure can be split to two? Currently IIO has a
 (painful and long) conversion from open to opaque. Taking this into account
 I really don't won't to repeat this design mistake. But it's all up to
 the maintainers, of course. Just my deep worries about this... while
 the idea, as I said, I fully support.

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

Hi Andy,

> > And if so, would be this series acceptable
> > as-is then (modulo the better include-sorting mentioned by Andy)?
> 
> *From my experience it's not the Q "will they or not?", the Q is "when?"
>  they start abusing it. I really prefer to hide as much as possible from

I totally agree with you on that.

>  day 1. Maybe the structure can be split to two? Currently IIO has a

I also thought that keeping some internal header might provide that
safety. When looking into it, I didn't see an obvious and somewhat
elegant way. Even more, I got a better picture of why Bjorn named the
current approach "unergonomic". I got some ideas which look doable in my
time frame. I will try going the full route, after all.

I'll start with some cleanup in some minutes.

Happy hacking,

   Wolfram

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Andy Shevchenko]

On Tue, Feb 10, 2026 at 11:44:25AM +0100, Wolfram Sang wrote:

> > > And if so, would be this series acceptable
> > > as-is then (modulo the better include-sorting mentioned by Andy)?
> > 
> > *From my experience it's not the Q "will they or not?", the Q is "when?"
> >  they start abusing it. I really prefer to hide as much as possible from
> 
> I totally agree with you on that.
> 
> >  day 1. Maybe the structure can be split to two? Currently IIO has a
> 
> I also thought that keeping some internal header might provide that
> safety. When looking into it, I didn't see an obvious and somewhat
> elegant way. Even more, I got a better picture of why Bjorn named the
> current approach "unergonomic". I got some ideas which look doable in my
> time frame. I will try going the full route, after all.

Thanks!
Looking forward for the rest, the cleanup is quite good, no added lines.

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wilken Gottwalt]

On Mon, 26 Jan 2026 11:59:43 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Sun, Jan 25, 2026 at 07:46:51PM +0100, Wolfram Sang wrote:
> > TLDR: I want to create a hwspinlock provider outside of the hwspinlock
> > directory. So, I refactored the headers into a provider/consumer pair.
> > Which seems to me like a reasonable seperation anyhow. No functional
> > changes. My build tests went fine and buildbots are happy, too.
> > 
> > Longer explanation:
> > 
> > There is a device (MFIS) in newer Renesas SoCs which combines various
> > things like hwspinlocks, mailboxes and other stuff. Sadly, these are not
> > strictly separated. Registers are kind of mixed and its register
> > unprotection scheme will need one of its own locks. I tried various
> > paths to handle this device (MFD, auxiliary bus) but I concluded that
> > the sub-device dependencies give enough reasons for a single driver in
> > drivers/soc/. So, this series will allow me to instantiate a hwspinlock
> > provider from the other directory.
> > 
> > Patches 1+2 do the actual refactoring with a fallback being in place. I
> > used '-B' with git-format-patch in this RFC, so the actual changes are
> > more visible when the headers are moved.
> > 
> > Patch 3 converts all the users. There are not many. We could try to get
> > all the acks for this single patch. Or I can break it into single
> > patches and send them to subsystems. I don't mind.
> > 
> > Patch 4 simply removes the fallback.
> > 
> > Looking forward to comments on this approach. If the hwspinlock
> > maintainers like it as is, I would kindly propose to apply patches 1+2
> > after 7.0-rc1 comes out. This might sound a bit hasty, but a) I want to
> > avoid chasing a moving target and b) this would remove one dependency of
> > the hwspinlock driver I originally intend to upstream, of course.
> > 
> > I would take care of patches 3+4 as needed.
> > 
> > A branch can be found here:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/hwspinlock/refactor-includes
> > 
> > Patches are based on linux-next as of 2026-01-21.
> > 
> > Opinions?
> 
> I don't like the idea of sharing internal stuff. Why would we need to have
> a struct hwspinlock to be visible?
> 

I see what Wolfram wants to achieve. It is the same issue I encounterd while I
wrote the sun6i hwspinlock driver. Currently it is impossible to write external
(out-of-kernel-tree) drivers because of internal structures. And it was a pain
in the ass for testing purposes. I prefer to be able to write external hwspinlock
drivers.

greetings

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Wolfram Sang]

> wrote the sun6i hwspinlock driver. Currently it is impossible to write external
> (out-of-kernel-tree) drivers because of internal structures. And it was a pain

Although my use case is more "out-of-directory" than "out-of-tree" ;)

Re: [RFC PATCH 0/4] hwspinlock: refactor headers into public provider/consumer pair

[Andy Shevchenko]

On Mon, Jan 26, 2026 at 10:14:46AM +0000, Wilken Gottwalt wrote:
> On Mon, 26 Jan 2026 11:59:43 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
> > On Sun, Jan 25, 2026 at 07:46:51PM +0100, Wolfram Sang wrote:
> > > TLDR: I want to create a hwspinlock provider outside of the hwspinlock
> > > directory. So, I refactored the headers into a provider/consumer pair.
> > > Which seems to me like a reasonable seperation anyhow. No functional
> > > changes. My build tests went fine and buildbots are happy, too.
> > > 
> > > Longer explanation:
> > > 
> > > There is a device (MFIS) in newer Renesas SoCs which combines various
> > > things like hwspinlocks, mailboxes and other stuff. Sadly, these are not
> > > strictly separated. Registers are kind of mixed and its register
> > > unprotection scheme will need one of its own locks. I tried various
> > > paths to handle this device (MFD, auxiliary bus) but I concluded that
> > > the sub-device dependencies give enough reasons for a single driver in
> > > drivers/soc/. So, this series will allow me to instantiate a hwspinlock
> > > provider from the other directory.
> > > 
> > > Patches 1+2 do the actual refactoring with a fallback being in place. I
> > > used '-B' with git-format-patch in this RFC, so the actual changes are
> > > more visible when the headers are moved.
> > > 
> > > Patch 3 converts all the users. There are not many. We could try to get
> > > all the acks for this single patch. Or I can break it into single
> > > patches and send them to subsystems. I don't mind.
> > > 
> > > Patch 4 simply removes the fallback.
> > > 
> > > Looking forward to comments on this approach. If the hwspinlock
> > > maintainers like it as is, I would kindly propose to apply patches 1+2
> > > after 7.0-rc1 comes out. This might sound a bit hasty, but a) I want to
> > > avoid chasing a moving target and b) this would remove one dependency of
> > > the hwspinlock driver I originally intend to upstream, of course.
> > > 
> > > I would take care of patches 3+4 as needed.
> > > 
> > > A branch can be found here:
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/hwspinlock/refactor-includes
> > > 
> > > Patches are based on linux-next as of 2026-01-21.
> > > 
> > > Opinions?
> > 
> > I don't like the idea of sharing internal stuff. Why would we need to have
> > a struct hwspinlock to be visible?
> > 
> 
> I see what Wolfram wants to achieve. It is the same issue I encounterd while I
> wrote the sun6i hwspinlock driver. Currently it is impossible to write external
> (out-of-kernel-tree) drivers because of internal structures. And it was a pain
> in the ass for testing purposes. I prefer to be able to write external hwspinlock
> drivers.

I am not against _that_. I'm against the implementation. At least I can't see
the impediment in making that struct opaque. Maybe I missed something. That's
why I'm asking why we need it to be visible to the entire world.

-- 
With Best Regards,
Andy Shevchenko