On Sun, Jan 26, 2014 at 10:44:25PM +0100, Jean Delvare wrote: > On Sun, 26 Jan 2014 21:22:56 +0000, Mark Brown wrote: > > They only worked with a debug option turned on and generated warnings > > every time they were used... that kernel config would've been actively > > broken for devices that wanted to do anything at all interesting with > > the regulators and would've been prone to issues with init ordering and > > races in any cases where there are actually regulators. > No, you don't get what I'm saying. For PC users, the lm90 did not I understand perfectly well thank you very much. > request a regulator and things worked because the kernel isn't supposed > to take care about things like that on PC machines. Now that the lm90 > driver does request a regulator, it fails on PC machines because no > regulator is declared. If and only if the user has enabled the regulator API on a platform that hasn't fully configured it; if the user has not enabled the regulator API it'll stub itself out and they'll never see it. > Don't tell me that it is expected that things will fail if > CONFIG_REGULATOR is enabled on a system which doesn't need it. It > doesn't make any sense. If kernels would fail as soon as any enabled > option wasn't actually needed, no system would boot out there. It's very easy to generate unbootable kernels by changing the kernel config, I'd not immediately expect a randomly generated config to do anything useful and things like FW_LOADER_USER_HELPER can be rather miserable if you turn them on (that one produces enormous delays during init which look awfully like hangs when you're watching your board boot). > If regulator is enabled but not needed, that's something the regulator > subsystem should figure out at run-time so that it can stub everything > out and things keep working. To repeat this is something the platform needs to tell the API; the only safe thing that API is able to do by itself is hope that something is going to turn up later on and supply some data. Supplying stubs and then trying to substitute the real thing in later isn't going to be terribly clever, worst case we end up in the situation where a driver talks to a device that has no power or partial power because we've hit an init ordering race. Requiring platforms to flag in code when they use regulators isn't something that seems like it's going to be deployed smoothly and quickly, I'd be concerned that'd cause as much trouble as it avoids - up until now the kernel config has been sufficient. I think the 90% fix here (aside from Ubuntu disabling regulators in the kernel config which would be sane too) is that ACPI based systems ought to be flagging that they have full constraints as soon as they boot and decide they have ACPI in the same way that DT ones do, we can be pretty confident that a system using ACPI will have all supplies taken care of transparently by the platform. This would deal with the PC situation at any rate which is probably most of the users who care and aren't already using DT. The regulator API is in general conservative about what it does since incorrect operation of regulators can cause lasting physical damage to the system, in general doing nothing and generating errors will be safer and we'd much rather deal with people running into that than with damaged boards. The general approach is that it only does operations it was specifically told by some outside source were OK. What it's doing here is essentially saying that it doesn't know what's going on so it's punting and hoping something tells it later on.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
