On Tue, Jul 13, 2021 at 9:19 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > 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(+) Ah, okay, you are talking with regard to the current patch. I talked in generic terms. > > 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. No-one is objecting to this. I agree that integration of regulators and ACPI should be done in a specific way if needed at all. > 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. Of course, no objections to this. > 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. In some (I suppose rear) cases it may be used by DT-enabled platforms as well. I can imagine the case when you have a system in ROM and only what you can do to change DTB there is either use DT overlays (which seems to be not working, plenty of gaps there according to a Wiki I saw once) or do something in the board files. So, if you replace "ACPI" with the "firmware resource provider" in the above paragraph, I will agree 100% with you. -- With Best Regards, Andy Shevchenko
