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

[Wilken Gottwalt <wilken.gottwalt@posteo.net>]

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