On Mon, Jan 26, 2026 at 10:14:46AM +0000, Wilken Gottwalt wrote: > On Mon, 26 Jan 2026 11:59:43 +0200 > Andy Shevchenko <[email protected]> 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
