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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]