[PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub

David Gibson david at gibson.dropbear.id.au
Fri Sep 7 11:15:53 EST 2007

On Wed, Sep 05, 2007 at 08:21:06AM -0500, Scott Wood wrote:
> On Wed, Sep 05, 2007 at 03:40:23PM +0400, Anton Vorontsov wrote:
> > On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> > > The kernel is of course welcome to do so -- and this may be a valid
> > > reason to attach pin information to specific device nodes, if it actually
> > > saves a non-negligible amount of power -- but it's not a reason to force
> > > the kernel to have to care by not setting things up in the firmware.
> > 
> > Well, I might agree here. But to me it seems unnatural that I have to
> > upgrade bootloader to use SPI -- I can already boot the kernel.
> Sure -- the firmware should have been done right the first time.
> Unfortunately, it very often doesn't, and thus fixups in the kernel's
> platform code are warranted, but the firmware is still the preferred
> place to do it.

Appealing though it is, I think the whole "firmware is the preferred
place to do it" approach is a lost cause (for nearly every value of

Firmwares are, more often than not, crap, and that's unlikely to
change.  For a lot of things, having the kernel or bootwrapper cope as
a special case with a handful of crap firmwares which don't set things
up properly isn't actually any easier than having it set them up
itself, always.

Which is why I err strongly in favour of having the kernel set things
up rather than rely on firmware setup, unless there's a very strong
reason why we *have* to respect the firmware's setup.

(Incidentally, this reasoning is why although the approach is very
neat-looking, I'm actually quite uncomfortable with firmwares directly
supplying flattened device trees to the kernel, rather than having the
tree in the bootwrapper.)

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!

More information about the Linuxppc-dev mailing list