On Mon, Oct 31, 2022 at 08:45:34AM PDT, Mark Brown wrote:
On Fri, Oct 28, 2022 at 12:44:50PM -0700, Zev Weiss wrote:
On Fri, Oct 28, 2022 at 08:51:54AM PDT, Mark Brown wrote:
> We don't turn things off on reboot? We don't do anything in particular
> on reboot...
Okay, perhaps not on reboot specifically, but the userspace-consumer driver
has a regulator_bulk_disable() in its .remove function, so it would be
triggered at least by a module unload (which is sort of why I ended up with
the "when software relinquishes control" wording in the patch). If we're
going to continue with the plan of using that driver for this functionality
(which seems overall quite reasonable to me), we need a way to express that
that must not happen on this hardware.
Ah, that would be the test driver not intended to be used in production
then... That shouldn't be a blocker for the DT binding, and if there's
a different compatible string for this application then we can either
make the userspace consumer do something different based on that
compatible string or have a new driver which does something more
sensible and perhaps has a better userspace ABI. Either way so long as
we can tell the thing being described is a BMC output from the DT
binding I think we can leave it up to the OS to do something constructive
with that rather than trying to control the specific behaviour in the
binding.
Ah, alright -- that seems like a nice (obvious in retrospect, of course)
solution that should work well I think. I'll post a v2 with that
approach soon.
Thanks,
Zev
