All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Andy Fleming <afleming@freescale.com>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] Fix the LPC47M192 SuperIO on the MPC8641 HPCN
Date: Fri, 8 Jun 2007 10:22:38 +0200	[thread overview]
Message-ID: <ddd8efa1565a98b4ac50666b91c3e325@kernel.crashing.org> (raw)
In-Reply-To: <FF15186D-1D92-422E-AC6C-3127F6116C79@freescale.com>

>>> I suppose I could create a device node for the Super I/O config
>>> registers and use those instead of hardcoding it here.
>>
>> I'd just hide it all, do this setup in the firmware,
>> where it belongs, and don't expose the superio config
>> in the device tree.
>
> No more.  No more firmware-only initializations.

This setup is very board specific, and the board cannot
reasonably work without that setup being done right.  You
really want to push _that_ into Linux?  Alternatively,
you could put it into the device tree, but that doesn't
help anything either.

> It sounds great, in principle, until you actually have to figure out 
> why someone's setup isn't working.  I'm tired of having to see if the 
> dts, u-boot, and Linux are in sync.  If Linux wants to use a device, I 
> think it's not unreasonable to have it setup the device itself.  That 
> way, Linux can do whatever it wants with the device, and not have to 
> rely on U-Boot (or some other firmware) setting up the appropriate 
> bits.

There is one and only one way to set up the superio for
a certain board (assuming the legacy I/O and IRQ values
are considered fixed values).

> Please...no.  What happens next is that we find a small bug that 
> requires we modify U-Boot to do the initialization slightly 
> differently, and then requires Linux to act slightly differently.

This is equivalent to needing a board-level fix really.


Segher

  reply	other threads:[~2007-06-08  8:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 16:30 [PATCH] Fix the LPC47M192 SuperIO on the MPC8641 HPCN Wade Farnsworth
2007-06-06 22:39 ` Arnd Bergmann
2007-06-07 13:03   ` Segher Boessenkool
2007-06-07 16:04   ` Wade Farnsworth
2007-06-07 16:35     ` Segher Boessenkool
2007-06-07 16:51       ` Wade Farnsworth
2007-06-07 17:05         ` Segher Boessenkool
2007-06-07 20:01       ` Andy Fleming
2007-06-08  8:22         ` Segher Boessenkool [this message]
2007-06-07 13:01 ` Segher Boessenkool
2007-06-07 16:42   ` Wade Farnsworth
2007-06-07 17:04     ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ddd8efa1565a98b4ac50666b91c3e325@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=afleming@freescale.com \
    --cc=arnd@arndb.de \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.