On Tue, Jul 13, 2021 at 06:55:59PM +0300, Andy Shevchenko wrote: > On Tue, Jul 13, 2021 at 6:25 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > The driver code is trivial boilerplate, assuming someone doesn't go and > > implement a helper to register stuff separately like I suggested. The > > proposed swnode stuff would involve duplicating the DT parsing code. > > This seems like a whole lot of effort for something that provides a > > worse result than either of the existing things. > I'm not sure I follow. Where did you see the duplication when I saw > the other way around? The current patch consists entirely of additions, it does not remove any existing code at all, the diffstat is: 5 files changed, 174 insertions(+) > Converting code from OF to fwnode APIs in most cases is smooth and > doesn't add any overhead to the codebase, We explicitly do not want to attempt to parse regulator properties out of ACPI platform descriptions because using the regulator binding on ACPI platforms conflicts with the ACPI model for power management and we really don't want to encourage platforms to attempt to mix and match here, it's not going to lead to anything robust. System integrators that need this sort of OS visible low level power management really should be working with the UEFI forum to get an ACPI specification for it, or if they don't really need it fixing up their AML to DTRT. If you were to say that we could bodge around that by somehow forcing this binding to exist only for swnodes when running on ACPI systems then we'd still have the problems with creating something with worse tooling than what's there already. Like I said in the other mail fwnode is a nice hack for systems that are using ACPI but have hardware that's doing something totally outside the ACPI model to allow them to reuse work that's been done for DT, it's not a universal solution to the lack of appropriate support for describing modern systems in ACPI.
Attachment:
signature.asc
Description: PGP signature
