[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 1/4] hwspinlock: refactor existing headers into provider.h

[Wolfram Sang]

The ultimate goal is to allow hwspinlock drivers outside of the
hwspinlock directory. So, the public and the internal header get
refactored into a more modern public provider/consumer pair. This patch
creates the provider header. It is a plain move without functional
changes. Only a now obsolete comment gets removed which explained why
some functions do not have fallbacks if hwspinlock is not seleceted. All
acutal providers are converted as well.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 MAINTAINERS                                   |  1 +
 drivers/hwspinlock/hwspinlock_core.c          |  3 +-
 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               |  3 +-
 include/linux/hwspinlock.h                    | 14 -------
 .../linux/hwspinlock/provider.h               | 40 ++++++++++++-------
 10 files changed, 33 insertions(+), 48 deletions(-)
 rename drivers/hwspinlock/hwspinlock_internal.h => include/linux/hwspinlock/provider.h (78%)

diff --git a/MAINTAINERS b/MAINTAINERS
index a56f8f00aebb..18f4991044ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11187,6 +11187,7 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git hw
 F:	Documentation/devicetree/bindings/hwlock/
 F:	Documentation/locking/hwspinlock.rst
 F:	drivers/hwspinlock/
+F:	include/linux/hwspinlock/
 F:	include/linux/hwspinlock.h
 
 HARDWARE TRACING FACILITIES
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index cc8e952a6772..3ee4f4357e01 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -18,12 +18,11 @@
 #include <linux/jiffies.h>
 #include <linux/radix-tree.h>
 #include <linux/hwspinlock.h>
+#include <linux/hwspinlock/provider.h>
 #include <linux/pm_runtime.h>
 #include <linux/mutex.h>
 #include <linux/of.h>
 
-#include "hwspinlock_internal.h"
-
 /* retry delay used in atomic context */
 #define HWSPINLOCK_RETRY_DELAY_US	100
 
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 1832e0c3af6b..e2a8fe4ad96a 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -19,12 +19,10 @@
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/provider.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 
-#include "hwspinlock_internal.h"
-
 /* Spinlock register offsets */
 #define SYSSTATUS_OFFSET		0x0014
 #define LOCK_BASE_OFFSET		0x0800
diff --git a/drivers/hwspinlock/qcom_hwspinlock.c b/drivers/hwspinlock/qcom_hwspinlock.c
index 0390979fd765..1b5a0c2fadee 100644
--- a/drivers/hwspinlock/qcom_hwspinlock.c
+++ b/drivers/hwspinlock/qcom_hwspinlock.c
@@ -4,7 +4,7 @@
  * Copyright (c) 2015, Sony Mobile Communications AB
  */
 
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/provider.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/mfd/syscon.h>
@@ -14,8 +14,6 @@
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 
-#include "hwspinlock_internal.h"
-
 #define QCOM_MUTEX_APPS_PROC_ID	1
 #define QCOM_MUTEX_NUM_LOCKS	32
 
diff --git a/drivers/hwspinlock/sprd_hwspinlock.c b/drivers/hwspinlock/sprd_hwspinlock.c
index 22e2ffb91743..62de2a551cee 100644
--- a/drivers/hwspinlock/sprd_hwspinlock.c
+++ b/drivers/hwspinlock/sprd_hwspinlock.c
@@ -7,7 +7,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/device.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/provider.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -15,8 +15,6 @@
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 
-#include "hwspinlock_internal.h"
-
 /* hwspinlock registers definition */
 #define HWSPINLOCK_RECCTRL		0x4
 #define HWSPINLOCK_MASTERID(_X_)	(0x80 + 0x4 * (_X_))
diff --git a/drivers/hwspinlock/stm32_hwspinlock.c b/drivers/hwspinlock/stm32_hwspinlock.c
index bb5c7e5f7a80..7af8e4cc564c 100644
--- a/drivers/hwspinlock/stm32_hwspinlock.c
+++ b/drivers/hwspinlock/stm32_hwspinlock.c
@@ -6,7 +6,7 @@
 
 #include <linux/clk.h>
 #include <linux/delay.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/provider.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -14,8 +14,6 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 
-#include "hwspinlock_internal.h"
-
 #define STM32_MUTEX_COREID	BIT(8)
 #define STM32_MUTEX_LOCK_BIT	BIT(31)
 #define STM32_MUTEX_NUM_LOCKS	32
diff --git a/drivers/hwspinlock/sun6i_hwspinlock.c b/drivers/hwspinlock/sun6i_hwspinlock.c
index c2d314588046..3c8c067e6312 100644
--- a/drivers/hwspinlock/sun6i_hwspinlock.c
+++ b/drivers/hwspinlock/sun6i_hwspinlock.c
@@ -7,7 +7,7 @@
 #include <linux/clk.h>
 #include <linux/debugfs.h>
 #include <linux/errno.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/provider.h>
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -17,8 +17,6 @@
 #include <linux/spinlock.h>
 #include <linux/types.h>
 
-#include "hwspinlock_internal.h"
-
 #define DRIVER_NAME		"sun6i_hwspinlock"
 
 #define SPINLOCK_BASE_ID	0 /* there is only one hwspinlock device per SoC */
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 5a2d8c3e0d80..ff0730613929 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -19,10 +19,9 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/hwspinlock.h>
+#include <linux/hwspinlock/provider.h>
 #include <linux/platform_device.h>
 
-#include "hwspinlock_internal.h"
-
 /*
  * Implementation of STE's HSem protocol 1 without interrutps.
  * The only masterID we allow is '0x01' to force people to use
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index f35b42e8c5de..7f38960c7162 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -55,9 +55,6 @@ struct hwspinlock_pdata {
 
 #ifdef CONFIG_HWSPINLOCK
 
-int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-		const struct hwspinlock_ops *ops, int base_id, int num_locks);
-int hwspin_lock_unregister(struct hwspinlock_device *bank);
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
 int hwspin_lock_free(struct hwspinlock *hwlock);
 int of_hwspin_lock_get_id(struct device_node *np, int index);
@@ -70,13 +67,6 @@ int hwspin_lock_bust(struct hwspinlock *hwlock, unsigned int id);
 int devm_hwspin_lock_free(struct device *dev, struct hwspinlock *hwlock);
 struct hwspinlock *devm_hwspin_lock_request_specific(struct device *dev,
 						     unsigned int id);
-int devm_hwspin_lock_unregister(struct device *dev,
-				struct hwspinlock_device *bank);
-int devm_hwspin_lock_register(struct device *dev,
-			      struct hwspinlock_device *bank,
-			      const struct hwspinlock_ops *ops,
-			      int base_id, int num_locks);
-
 #else /* !CONFIG_HWSPINLOCK */
 
 /*
@@ -85,10 +75,6 @@ int devm_hwspin_lock_register(struct device *dev,
  * code path get compiled away. This way, if CONFIG_HWSPINLOCK is not
  * required on a given setup, users will still work.
  *
- * The only exception is hwspin_lock_register/hwspin_lock_unregister, with which
- * we _do_ want users to fail (no point in registering hwspinlock instances if
- * the framework is not available).
- *
  * Note: ERR_PTR(-ENODEV) will still be considered a success for NULL-checking
  * users. Others, which care, can still check this with IS_ERR.
  */
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/include/linux/hwspinlock/provider.h
similarity index 78%
rename from drivers/hwspinlock/hwspinlock_internal.h
rename to include/linux/hwspinlock/provider.h
index f298fc0ee5ad..d53bbacec744 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/include/linux/hwspinlock/provider.h
@@ -7,14 +7,26 @@
  * Contact: Ohad Ben-Cohen <ohad@wizery.com>
  */
 
-#ifndef __HWSPINLOCK_HWSPINLOCK_H
-#define __HWSPINLOCK_HWSPINLOCK_H
+#ifndef __LINUX_HWSPINLOCK_PROVIDER_H
+#define __LINUX_HWSPINLOCK_PROVIDER_H
 
 #include <linux/spinlock.h>
 #include <linux/device.h>
 
 struct hwspinlock_device;
 
+/**
+ * struct hwspinlock - this struct represents a single hwspinlock instance
+ * @bank: the hwspinlock_device structure which owns this lock
+ * @lock: initialized and used by hwspinlock core
+ * @priv: private data, owned by the underlying platform-specific hwspinlock drv
+ */
+struct hwspinlock {
+	struct hwspinlock_device *bank;
+	spinlock_t lock;
+	void *priv;
+};
+
 /**
  * struct hwspinlock_ops - platform-specific hwspinlock handlers
  *
@@ -34,18 +46,6 @@ struct hwspinlock_ops {
 	void (*relax)(struct hwspinlock *lock);
 };
 
-/**
- * struct hwspinlock - this struct represents a single hwspinlock instance
- * @bank: the hwspinlock_device structure which owns this lock
- * @lock: initialized and used by hwspinlock core
- * @priv: private data, owned by the underlying platform-specific hwspinlock drv
- */
-struct hwspinlock {
-	struct hwspinlock_device *bank;
-	spinlock_t lock;
-	void *priv;
-};
-
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
  * @dev: underlying device, will be used to invoke runtime PM api
@@ -69,4 +69,14 @@ static inline int hwlock_to_id(struct hwspinlock *hwlock)
 	return hwlock->bank->base_id + local_id;
 }
 
-#endif /* __HWSPINLOCK_HWSPINLOCK_H */
+int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
+		const struct hwspinlock_ops *ops, int base_id, int num_locks);
+int hwspin_lock_unregister(struct hwspinlock_device *bank);
+int devm_hwspin_lock_register(struct device *dev,
+			      struct hwspinlock_device *bank,
+			      const struct hwspinlock_ops *ops,
+			      int base_id, int num_locks);
+int devm_hwspin_lock_unregister(struct device *dev,
+				struct hwspinlock_device *bank);
+
+#endif /* __LINUX_HWSPINLOCK_PROVIDER_H */
-- 
2.47.3

[RFC PATCH 2/4] hwspinlock: refactor existing headers into consumer.h

[Wolfram Sang]

The ultimate goal is to allow hwspinlock drivers outside of the
hwspinlock directory. So, the public and the internal header get
refactored into a more modern public provider/consumer pair. This patch
creates the consumer header. It is a plain move without functional
changes. Only the hwspinlock internal users are converted. The old
headerfile still exists as a plain link to the new one until all users
are converted. Documentation gets updated, too.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 Documentation/locking/hwspinlock.rst          |   2 +-
 drivers/hwspinlock/hwspinlock_core.c          |   2 +-
 drivers/hwspinlock/u8500_hsem.c               |   2 +-
 include/linux/hwspinlock.h                    | 438 +-----------------
 .../{hwspinlock.h => hwspinlock/consumer.h}   |   8 +-
 5 files changed, 11 insertions(+), 441 deletions(-)
 rewrite include/linux/hwspinlock.h (99%)
 copy include/linux/{hwspinlock.h => hwspinlock/consumer.h} (98%)

diff --git a/Documentation/locking/hwspinlock.rst b/Documentation/locking/hwspinlock.rst
index a737c702a7d1..001bcab86690 100644
--- a/Documentation/locking/hwspinlock.rst
+++ b/Documentation/locking/hwspinlock.rst
@@ -306,7 +306,7 @@ Typical usage
 
 ::
 
-	#include <linux/hwspinlock.h>
+	#include <linux/hwspinlock/consumer.h>
 	#include <linux/err.h>
 
 	int hwspinlock_example(void)
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 3ee4f4357e01..cafe204728f5 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -17,7 +17,7 @@
 #include <linux/err.h>
 #include <linux/jiffies.h>
 #include <linux/radix-tree.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/hwspinlock/provider.h>
 #include <linux/pm_runtime.h>
 #include <linux/mutex.h>
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index ff0730613929..de456b859ac7 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -18,7 +18,7 @@
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
-#include <linux/hwspinlock.h>
+#include <linux/hwspinlock/consumer.h>
 #include <linux/hwspinlock/provider.h>
 #include <linux/platform_device.h>
 
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
dissimilarity index 99%
index 7f38960c7162..7220f7f2368b 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -1,434 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Hardware spinlock public header
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Ohad Ben-Cohen <ohad@wizery.com>
- */
-
-#ifndef __LINUX_HWSPINLOCK_H
-#define __LINUX_HWSPINLOCK_H
-
-#include <linux/err.h>
-#include <linux/sched.h>
-
-/* hwspinlock mode argument */
-#define HWLOCK_IRQSTATE		0x01 /* Disable interrupts, save state */
-#define HWLOCK_IRQ		0x02 /* Disable interrupts, don't save state */
-#define HWLOCK_RAW		0x03
-#define HWLOCK_IN_ATOMIC	0x04 /* Called while in atomic context */
-
-struct device;
-struct device_node;
-struct hwspinlock;
-struct hwspinlock_device;
-struct hwspinlock_ops;
-
-/**
- * struct hwspinlock_pdata - platform data for hwspinlock drivers
- * @base_id: base id for this hwspinlock device
- *
- * hwspinlock devices provide system-wide hardware locks that are used
- * by remote processors that have no other way to achieve synchronization.
- *
- * To achieve that, each physical lock must have a system-wide id number
- * that is agreed upon, otherwise remote processors can't possibly assume
- * they're using the same hardware lock.
- *
- * Usually boards have a single hwspinlock device, which provides several
- * hwspinlocks, and in this case, they can be trivially numbered 0 to
- * (num-of-locks - 1).
- *
- * In case boards have several hwspinlocks devices, a different base id
- * should be used for each hwspinlock device (they can't all use 0 as
- * a starting id!).
- *
- * This platform data structure should be used to provide the base id
- * for each device (which is trivially 0 when only a single hwspinlock
- * device exists). It can be shared between different platforms, hence
- * its location.
- */
-struct hwspinlock_pdata {
-	int base_id;
-};
-
-#ifdef CONFIG_HWSPINLOCK
-
-struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-int hwspin_lock_free(struct hwspinlock *hwlock);
-int of_hwspin_lock_get_id(struct device_node *np, int index);
-int __hwspin_lock_timeout(struct hwspinlock *, unsigned int, int,
-							unsigned long *);
-int __hwspin_trylock(struct hwspinlock *, int, unsigned long *);
-void __hwspin_unlock(struct hwspinlock *, int, unsigned long *);
-int of_hwspin_lock_get_id_byname(struct device_node *np, const char *name);
-int hwspin_lock_bust(struct hwspinlock *hwlock, unsigned int id);
-int devm_hwspin_lock_free(struct device *dev, struct hwspinlock *hwlock);
-struct hwspinlock *devm_hwspin_lock_request_specific(struct device *dev,
-						     unsigned int id);
-#else /* !CONFIG_HWSPINLOCK */
-
-/*
- * We don't want these functions to fail if CONFIG_HWSPINLOCK is not
- * enabled. We prefer to silently succeed in this case, and let the
- * code path get compiled away. This way, if CONFIG_HWSPINLOCK is not
- * required on a given setup, users will still work.
- *
- * Note: ERR_PTR(-ENODEV) will still be considered a success for NULL-checking
- * users. Others, which care, can still check this with IS_ERR.
- */
-static inline struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
-{
-	return ERR_PTR(-ENODEV);
-}
-
-static inline int hwspin_lock_free(struct hwspinlock *hwlock)
-{
-	return 0;
-}
-
-static inline
-int __hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned int to,
-					int mode, unsigned long *flags)
-{
-	return 0;
-}
-
-static inline
-int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
-{
-	return 0;
-}
-
-static inline
-void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
-{
-}
-
-static inline int hwspin_lock_bust(struct hwspinlock *hwlock, unsigned int id)
-{
-	return 0;
-}
-
-static inline int of_hwspin_lock_get_id(struct device_node *np, int index)
-{
-	return 0;
-}
-
-static inline
-int of_hwspin_lock_get_id_byname(struct device_node *np, const char *name)
-{
-	return 0;
-}
-
-static inline
-int devm_hwspin_lock_free(struct device *dev, struct hwspinlock *hwlock)
-{
-	return 0;
-}
-
-static inline
-struct hwspinlock *devm_hwspin_lock_request_specific(struct device *dev,
-						     unsigned int id)
-{
-	return ERR_PTR(-ENODEV);
-}
-
-#endif /* !CONFIG_HWSPINLOCK */
-
-/**
- * hwspin_trylock_irqsave() - try to lock an hwspinlock, disable interrupts
- * @hwlock: an hwspinlock which we want to trylock
- * @flags: a pointer to where the caller's interrupt state will be saved at
- *
- * This function attempts to lock the underlying hwspinlock, and will
- * immediately fail if the hwspinlock is already locked.
- *
- * Upon a successful return from this function, preemption and local
- * interrupts are disabled (previous interrupts state is saved at @flags),
- * so the caller must not sleep, and is advised to release the hwspinlock
- * as soon as possible.
- *
- * Returns 0 if we successfully locked the hwspinlock, -EBUSY if
- * the hwspinlock was already taken, and -EINVAL if @hwlock is invalid.
- */
-static inline
-int hwspin_trylock_irqsave(struct hwspinlock *hwlock, unsigned long *flags)
-{
-	return __hwspin_trylock(hwlock, HWLOCK_IRQSTATE, flags);
-}
-
-/**
- * hwspin_trylock_irq() - try to lock an hwspinlock, disable interrupts
- * @hwlock: an hwspinlock which we want to trylock
- *
- * This function attempts to lock the underlying hwspinlock, and will
- * immediately fail if the hwspinlock is already locked.
- *
- * Upon a successful return from this function, preemption and local
- * interrupts are disabled, so the caller must not sleep, and is advised
- * to release the hwspinlock as soon as possible.
- *
- * Returns 0 if we successfully locked the hwspinlock, -EBUSY if
- * the hwspinlock was already taken, and -EINVAL if @hwlock is invalid.
- */
-static inline int hwspin_trylock_irq(struct hwspinlock *hwlock)
-{
-	return __hwspin_trylock(hwlock, HWLOCK_IRQ, NULL);
-}
-
-/**
- * hwspin_trylock_raw() - attempt to lock a specific hwspinlock
- * @hwlock: an hwspinlock which we want to trylock
- *
- * This function attempts to lock an hwspinlock, and will immediately fail
- * if the hwspinlock is already taken.
- *
- * Caution: User must protect the routine of getting hardware lock with mutex
- * or spinlock to avoid dead-lock, that will let user can do some time-consuming
- * or sleepable operations under the hardware lock.
- *
- * Returns 0 if we successfully locked the hwspinlock, -EBUSY if
- * the hwspinlock was already taken, and -EINVAL if @hwlock is invalid.
- */
-static inline int hwspin_trylock_raw(struct hwspinlock *hwlock)
-{
-	return __hwspin_trylock(hwlock, HWLOCK_RAW, NULL);
-}
-
-/**
- * hwspin_trylock_in_atomic() - attempt to lock a specific hwspinlock
- * @hwlock: an hwspinlock which we want to trylock
- *
- * This function attempts to lock an hwspinlock, and will immediately fail
- * if the hwspinlock is already taken.
- *
- * This function shall be called only from an atomic context.
- *
- * Returns 0 if we successfully locked the hwspinlock, -EBUSY if
- * the hwspinlock was already taken, and -EINVAL if @hwlock is invalid.
- */
-static inline int hwspin_trylock_in_atomic(struct hwspinlock *hwlock)
-{
-	return __hwspin_trylock(hwlock, HWLOCK_IN_ATOMIC, NULL);
-}
-
-/**
- * hwspin_trylock() - attempt to lock a specific hwspinlock
- * @hwlock: an hwspinlock which we want to trylock
- *
- * This function attempts to lock an hwspinlock, and will immediately fail
- * if the hwspinlock is already taken.
- *
- * Upon a successful return from this function, preemption is disabled,
- * so the caller must not sleep, and is advised to release the hwspinlock
- * as soon as possible. This is required in order to minimize remote cores
- * polling on the hardware interconnect.
- *
- * Returns 0 if we successfully locked the hwspinlock, -EBUSY if
- * the hwspinlock was already taken, and -EINVAL if @hwlock is invalid.
- */
-static inline int hwspin_trylock(struct hwspinlock *hwlock)
-{
-	return __hwspin_trylock(hwlock, 0, NULL);
-}
-
-/**
- * hwspin_lock_timeout_irqsave() - lock hwspinlock, with timeout, disable irqs
- * @hwlock: the hwspinlock to be locked
- * @to: timeout value in msecs
- * @flags: a pointer to where the caller's interrupt state will be saved at
- *
- * This function locks the underlying @hwlock. If the @hwlock
- * is already taken, the function will busy loop waiting for it to
- * be released, but give up when @timeout msecs have elapsed.
- *
- * Upon a successful return from this function, preemption and local interrupts
- * are disabled (plus previous interrupt state is saved), so the caller must
- * not sleep, and is advised to release the hwspinlock as soon as possible.
- *
- * Returns 0 when the @hwlock was successfully taken, and an appropriate
- * error code otherwise (most notably an -ETIMEDOUT if the @hwlock is still
- * busy after @timeout msecs). The function will never sleep.
- */
-static inline int hwspin_lock_timeout_irqsave(struct hwspinlock *hwlock,
-				unsigned int to, unsigned long *flags)
-{
-	return __hwspin_lock_timeout(hwlock, to, HWLOCK_IRQSTATE, flags);
-}
-
-/**
- * hwspin_lock_timeout_irq() - lock hwspinlock, with timeout, disable irqs
- * @hwlock: the hwspinlock to be locked
- * @to: timeout value in msecs
- *
- * This function locks the underlying @hwlock. If the @hwlock
- * is already taken, the function will busy loop waiting for it to
- * be released, but give up when @timeout msecs have elapsed.
- *
- * Upon a successful return from this function, preemption and local interrupts
- * are disabled so the caller must not sleep, and is advised to release the
- * hwspinlock as soon as possible.
- *
- * Returns 0 when the @hwlock was successfully taken, and an appropriate
- * error code otherwise (most notably an -ETIMEDOUT if the @hwlock is still
- * busy after @timeout msecs). The function will never sleep.
- */
-static inline
-int hwspin_lock_timeout_irq(struct hwspinlock *hwlock, unsigned int to)
-{
-	return __hwspin_lock_timeout(hwlock, to, HWLOCK_IRQ, NULL);
-}
-
-/**
- * hwspin_lock_timeout_raw() - lock an hwspinlock with timeout limit
- * @hwlock: the hwspinlock to be locked
- * @to: timeout value in msecs
- *
- * This function locks the underlying @hwlock. If the @hwlock
- * is already taken, the function will busy loop waiting for it to
- * be released, but give up when @timeout msecs have elapsed.
- *
- * Caution: User must protect the routine of getting hardware lock with mutex
- * or spinlock to avoid dead-lock, that will let user can do some time-consuming
- * or sleepable operations under the hardware lock.
- *
- * Returns 0 when the @hwlock was successfully taken, and an appropriate
- * error code otherwise (most notably an -ETIMEDOUT if the @hwlock is still
- * busy after @timeout msecs). The function will never sleep.
- */
-static inline
-int hwspin_lock_timeout_raw(struct hwspinlock *hwlock, unsigned int to)
-{
-	return __hwspin_lock_timeout(hwlock, to, HWLOCK_RAW, NULL);
-}
-
-/**
- * hwspin_lock_timeout_in_atomic() - lock an hwspinlock with timeout limit
- * @hwlock: the hwspinlock to be locked
- * @to: timeout value in msecs
- *
- * This function locks the underlying @hwlock. If the @hwlock
- * is already taken, the function will busy loop waiting for it to
- * be released, but give up when @timeout msecs have elapsed.
- *
- * This function shall be called only from an atomic context and the timeout
- * value shall not exceed a few msecs.
- *
- * Returns 0 when the @hwlock was successfully taken, and an appropriate
- * error code otherwise (most notably an -ETIMEDOUT if the @hwlock is still
- * busy after @timeout msecs). The function will never sleep.
- */
-static inline
-int hwspin_lock_timeout_in_atomic(struct hwspinlock *hwlock, unsigned int to)
-{
-	return __hwspin_lock_timeout(hwlock, to, HWLOCK_IN_ATOMIC, NULL);
-}
-
-/**
- * hwspin_lock_timeout() - lock an hwspinlock with timeout limit
- * @hwlock: the hwspinlock to be locked
- * @to: timeout value in msecs
- *
- * This function locks the underlying @hwlock. If the @hwlock
- * is already taken, the function will busy loop waiting for it to
- * be released, but give up when @timeout msecs have elapsed.
- *
- * Upon a successful return from this function, preemption is disabled
- * so the caller must not sleep, and is advised to release the hwspinlock
- * as soon as possible.
- * This is required in order to minimize remote cores polling on the
- * hardware interconnect.
- *
- * Returns 0 when the @hwlock was successfully taken, and an appropriate
- * error code otherwise (most notably an -ETIMEDOUT if the @hwlock is still
- * busy after @timeout msecs). The function will never sleep.
- */
-static inline
-int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned int to)
-{
-	return __hwspin_lock_timeout(hwlock, to, 0, NULL);
-}
-
-/**
- * hwspin_unlock_irqrestore() - unlock hwspinlock, restore irq state
- * @hwlock: a previously-acquired hwspinlock which we want to unlock
- * @flags: previous caller's interrupt state to restore
- *
- * This function will unlock a specific hwspinlock, enable preemption and
- * restore the previous state of the local interrupts. It should be used
- * to undo, e.g., hwspin_trylock_irqsave().
- *
- * @hwlock must be already locked before calling this function: it is a bug
- * to call unlock on a @hwlock that is already unlocked.
- */
-static inline void hwspin_unlock_irqrestore(struct hwspinlock *hwlock,
-							unsigned long *flags)
-{
-	__hwspin_unlock(hwlock, HWLOCK_IRQSTATE, flags);
-}
-
-/**
- * hwspin_unlock_irq() - unlock hwspinlock, enable interrupts
- * @hwlock: a previously-acquired hwspinlock which we want to unlock
- *
- * This function will unlock a specific hwspinlock, enable preemption and
- * enable local interrupts. Should be used to undo hwspin_lock_irq().
- *
- * @hwlock must be already locked (e.g. by hwspin_trylock_irq()) before
- * calling this function: it is a bug to call unlock on a @hwlock that is
- * already unlocked.
- */
-static inline void hwspin_unlock_irq(struct hwspinlock *hwlock)
-{
-	__hwspin_unlock(hwlock, HWLOCK_IRQ, NULL);
-}
-
-/**
- * hwspin_unlock_raw() - unlock hwspinlock
- * @hwlock: a previously-acquired hwspinlock which we want to unlock
- *
- * This function will unlock a specific hwspinlock.
- *
- * @hwlock must be already locked (e.g. by hwspin_trylock()) before calling
- * this function: it is a bug to call unlock on a @hwlock that is already
- * unlocked.
- */
-static inline void hwspin_unlock_raw(struct hwspinlock *hwlock)
-{
-	__hwspin_unlock(hwlock, HWLOCK_RAW, NULL);
-}
-
-/**
- * hwspin_unlock_in_atomic() - unlock hwspinlock
- * @hwlock: a previously-acquired hwspinlock which we want to unlock
- *
- * This function will unlock a specific hwspinlock.
- *
- * @hwlock must be already locked (e.g. by hwspin_trylock()) before calling
- * this function: it is a bug to call unlock on a @hwlock that is already
- * unlocked.
- */
-static inline void hwspin_unlock_in_atomic(struct hwspinlock *hwlock)
-{
-	__hwspin_unlock(hwlock, HWLOCK_IN_ATOMIC, NULL);
-}
-
-/**
- * hwspin_unlock() - unlock hwspinlock
- * @hwlock: a previously-acquired hwspinlock which we want to unlock
- *
- * This function will unlock a specific hwspinlock and enable preemption
- * back.
- *
- * @hwlock must be already locked (e.g. by hwspin_trylock()) before calling
- * this function: it is a bug to call unlock on a @hwlock that is already
- * unlocked.
- */
-static inline void hwspin_unlock(struct hwspinlock *hwlock)
-{
-	__hwspin_unlock(hwlock, 0, NULL);
-}
-
-#endif /* __LINUX_HWSPINLOCK_H */
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Temporary. Until all users are converted. */
+
+#include <hwspinlock/consumer.h>
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock/consumer.h
similarity index 98%
copy from include/linux/hwspinlock.h
copy to include/linux/hwspinlock/consumer.h
index 7f38960c7162..89a95e3d35c6 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock/consumer.h
@@ -1,14 +1,14 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Hardware spinlock public header
+ * Hardware spinlock public header for consumers
  *
  * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
  *
  * Contact: Ohad Ben-Cohen <ohad@wizery.com>
  */
 
-#ifndef __LINUX_HWSPINLOCK_H
-#define __LINUX_HWSPINLOCK_H
+#ifndef __LINUX_HWSPINLOCK_CONSUMER_H
+#define __LINUX_HWSPINLOCK_CONSUMER_H
 
 #include <linux/err.h>
 #include <linux/sched.h>
@@ -431,4 +431,4 @@ static inline void hwspin_unlock(struct hwspinlock *hwlock)
 	__hwspin_unlock(hwlock, 0, NULL);
 }
 
-#endif /* __LINUX_HWSPINLOCK_H */
+#endif /* __LINUX_HWSPINLOCK_CONSUMER_H */
-- 
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 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

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

[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

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

[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