Hi Mark, On Thu, Feb 24, 2022 at 03:33:12PM +0000, Mark Brown wrote: > On Thu, Feb 24, 2022 at 03:58:04PM +0100, Hans de Goede wrote: > > > As Mark already mentioned the regulator subsystem has shown to > > be a bit problematic here, but you don't seem to need that? > > I believe clocks are also potentially problematic for similar reasons > (ACPI wants to handle those as part of the device level power management > and/or should have native abstractions for them, and I think we also > have board file provisions that work well for them and are less error > prone than translating into an abstract data structure). Per ACPI spec, what corresponds to clocks and regulators in DT is handled through power resources. This is generally how things work in ACPI based systems but there are cases out there where regulators and/or clocks are exposed to software directly. This concerns e.g. camera sensors and lens voice coils on some systems while rest of the devices in the system are powered on and off the usual ACPI way. So controlling regulators or clocks directly on an ACPI based system wouldn't be exactly something new. All you need to do in that case is to ensure that there's exactly one way regulators and clocks are controlled for a given device. For software nodes this is a non-issue. This does have the limitation that a clock or a regulator is either controlled through power resources or relevant drivers, but that tends to be the case in practice. But I presume it wouldn't be different with board files. -- Sakari Ailus
