All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alessandro Rubini <rubini@gnudd.com>,
	linux-kernel@vger.kernel.org, giancarlo.asnaghi@st.com,
	alan@linux.intel.com, tglx@linutronix.de, mingo@redhat.com,
	sameo@linux.intel.com, x86@kernel.org,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH] x86/platform: sta2x11: add platform code
Date: Mon, 04 Jun 2012 20:16:12 +1000	[thread overview]
Message-ID: <1338804972.7150.77.camel@pasglop> (raw)
In-Reply-To: <4FC47D49.50204@zytor.com>

On Tue, 2012-05-29 at 00:39 -0700, H. Peter Anvin wrote:
> > So, it seems I must go device-tree for the chipset-like mounting.
> And
> > what about plug in boards? I may arrange a firmware-loader mechanism
> > as an alternative, so the vendor of each board can provide the the
> > platform data for all the sub devices. Actually, if firmware loader
> is
> > acceptable, I'd try it first, to avoid changing the boot procedure;
> > maybe I can save myself from the device tree.
> > 
> 
> If you're going to use a binary blob for the loader, use either ACPI 5
> SSDT or device tree format.  This is *not* something where
> (re)invention is encouraged.

Right, a device-tree blob could easily be passed an x86 has the
infrastructure to use it already afaik.

It then becomes a matter of the bootloader to carry it over to the
kernel a way or another. If the "vendor" boards don't do the right
thing, you can always do like powerpc for those cases and "package" the
device-tree blob in the zImage wrapper.

That way, distribution install tools etc.... can stick the right
device-tree before doing whatever "flashing" of the image is needed for
booting etc... and the main kernel image remains agnostic.

That or the ACPI way but I know nothing about it and thus naturally
assume it's harder :-)

Cheers,
Ben.


  parent reply	other threads:[~2012-06-04 10:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-27 20:50 [PATCH] x86/platform: sta2x11: add platform code Alessandro Rubini
2012-05-28 23:38 ` H. Peter Anvin
2012-05-29  6:37   ` Alessandro Rubini
2012-05-29  6:43     ` H. Peter Anvin
2012-05-29  7:05       ` Alessandro Rubini
2012-05-29  7:15         ` H. Peter Anvin
2012-05-29  7:34           ` Alessandro Rubini
2012-05-29  7:39             ` H. Peter Anvin
2012-05-29  7:44               ` Alessandro Rubini
2012-06-04 10:16               ` Benjamin Herrenschmidt [this message]
2012-06-04 10:21                 ` Alessandro Rubini
2012-06-04 10:17         ` Benjamin Herrenschmidt

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=1338804972.7150.77.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=alan@linux.intel.com \
    --cc=giancarlo.asnaghi@st.com \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rubini@gnudd.com \
    --cc=sameo@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.