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 >
