On Thu, Feb 24, 2022 at 05:42:05PM +0100, Clément Léger wrote: > Hans de Goede <hdegoede@xxxxxxxxxx> a écrit : > > As Mark already mentioned the regulator subsystem has shown to > > be a bit problematic here, but you don't seem to need that? > Indeed, I don't need this subsystem. However, I'm still not clear why > this subsystem in particular is problematic. Just so that I can > recognize the other subsystems with the same pattern, could you explain > me why it is problematic ? ACPI has a strong concept of how power supply (and general critical resources) for devices should be described by firmware which is very different to that which DT as it is used in Linux has, confusing that model would make it much harder for generic OSs to work with generic ACPI systems, and makes it much easier to create unfortunate interactions between bits of software expecting ACPI models and bits of software expecting DT models for dealing with a device. Potentially we could even run into issues with new versions of Linux if there's timing or other changes. If Linux starts parsing the core DT bindings for regulators on ACPI systems then that makes it more likely that system integrators who are primarily interested in Linux will produce firmwares that run into these issues, perhaps unintentionally through a "this just happens to work" process. As a result of this we very much do not want to have the regulator code parsing DT bindings using the fwnode APIs since that makes it much easier for us to end up with a situation where we are interpreting _DSD versions of regulator bindings and ending up with people making systems that rely on that. Instead the regulator API is intentional about which platform description interfaces it is using. We could potentially have something that is specific to swnode and won't work with general fwnode but it's hard to see any advantages for this over the board file based mechanism we have already, swnode offers less error detection (typoing field names is harder to spot) and the data marshalling takes more code. fwnode is great for things like properties for leaf devices since those are basically a free for all on ACPI systems, it allows us to quickly and simply apply the work done defining bindings for DT to ACPI systems in a way that's compatible with how APCI wants to work. It's also good for cross device bindings that are considered out of scope for ACPI, though a bit of caution is needed determining when that's the case.
Attachment:
signature.asc
Description: PGP signature
