On Tue, Aug 16, 2022 at 10:48:04AM -0700, Saravana Kannan wrote: > On Tue, Aug 16, 2022 at 10:26 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > On Fri, Aug 12, 2022 at 04:54:25PM -0700, Saravana Kannan wrote: > > > > > While you are here, I'm working towards patches on top of [1] where > > > fw_devlink will tie the sync_state() callback to each regulator. Also, > > > i realized that if you can convert the regulator_class to a > > > regulator_bus, we could remove a lot of the "find the supply for this > > > regulator when it's registered" code and let device links handle it. > > > Let me know if that's something you'd be okay with. It would change > > > the sysfs path for /sys/class/regulator and moves it to > > > /sys/bus/regulator, but not sure if that's considered an ABI breakage > > > (sysfs paths change all the time). > > > > That *does* sound like it'd be an ABI issue TBH. I thought there was > > support for keeping class around even when converting to a bus > > Ah, this is news to me. I'll poke around to see if the path can be > maintained even after converting a class to a bus. Which specific path are you worried about? > (though > > TBH given how entirely virtual this stuff us it seems odd that we'd be > > going for a bus). > > I'm going for a bus because class doesn't have a distinction between > "device has been added" and "device is ready if these things happen". > There's nothing to say that a "bus" has to be a real hardware bus. busses are not always real hardware busses, look at the virtual bus code for examples of that. Classes are "representations of a type of device that userspace interacts with" like input, sound, tty, and so on, that are independant of the type of hardware bus or device it is. Do all regulators need to interact with userspace in a common way? If so, it's a class, if not, maybe a bus would work, but that takes more code than a class so it should only be done if you really need it for some odd reason. thanks, greg k-h
