next/master bisection: baseline.bootrr.intel-igb-probed on kontron-pitx-imx8m

Mark Brown broonie at kernel.org
Wed Aug 17 05:58:09 PDT 2022


On Wed, Aug 17, 2022 at 08:44:09AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 16, 2022 at 10:48:04AM -0700, Saravana Kannan wrote:

> > 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?

The various files in /sys/class/regulator.

> > (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.

Sure, but the less things correspond to the concrete concept of a thing
the more chance there is that things will be redefined later, and in
this case I'm struggling to see this matching even the abstract idea of
a bus.

> 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.

My understanding is that people are using the current class interface
for monitoring of what the framework is doing, there's regular attempts
to add a write interface too though that isn't happening.  It kind of
corresponds to the write side of hwmon in some ways.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220817/19bb6883/attachment.sig>


More information about the linux-arm-kernel mailing list