On Mon, Jan 27, 2014 at 11:10:41AM +0100, Geert Uytterhoeven wrote: > On Mon, Jan 27, 2014 at 12:15 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > 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). > This is not just a randomly generated config where you disable critical > options. Just enabling a subsystem like the regulator subsystem shouldn't > give you an unbootable kernel. It's even needed, think multi-platform > kernels. > Typically, I'd expect allmodconfig/allyesconfig kernels to actually boot > (ignoring RAM size issues etc.). So, not booting is probably not what's going to happen for most systems. You will in general at least get console output and mostly the realistic issues for boot failures are netboot in embedded systems. I'm more than aware of the idea of multiplatform systems, this is one of the reasons why things like checking for DT being compiled in don't do the right thing. Don't get me wrong, I would prefer it if we had a way to transparently make this stuff just work and we are getting there - that's what's driving the recent changes with optional regulators for example - but just ignoring errors causes other problems. For DT and (assuming the patch I sent last night gets applied) ACPI systems I think we're now pretty much there which should cover the majority of users. I also think many architectures (especially older ones that don't see much active hardware development) could probably do the same thing. The issues that remain are around platforms which may use regulators but need to have them come from board data in Linux. Unfortunately the mechanism we have for that currently only registers the supply mappings when the regulator is registered which means it's difficult to tell if the mappings are going to appear later so the core is never terribly sure if it knows when everything is set up unless the platform tells it. Knowing that is the key bit of information that allows us to be more helpful now we've got regulator_get_optional(). Fortunately outside of the ACPI/DT cases the platforms that are affected are generally embedded ones where the problems are going to be developer only and so it should be relatively easy to deal with them (for the most part just adding a regulator_has_full_constraints() call on the affected system if disabing the regulator API isn't desirable). Realistically it is unlikely to be useful to enable on affected systems though. The next step is to transition all the platforms in this class to a way of setting up mappings that could be done purely in machine init (which means they're in a similar position to DT and ACPI) but that's more work than could sensibly be done in a bugfix context which is what people are looking for here.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
