Message-ID: <20140127131823.GX11727@sirena.org.uk>
Date:	Mon, 27 Jan 2014 13:18:23 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	Guenter Roeck <linux@...ck-us.net>,
	LM Sensors <lm-sensors@...sensors.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>, Wei Ni <wni@...dia.com>
Subject: Re: lm90 driver no longer working on PCs in 3.13

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@...nel.org> 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.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists