From: "Grant Likely" <grant.likely@secretlab.ca>
To: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org, olaf@aepfle.de, sven@genesi-usa.com
Subject: Platform matching style (was:: [RFC] add phy-handle property for fec_mpc52xx)
Date: Thu, 10 Jan 2008 08:31:18 -0700 [thread overview]
Message-ID: <fa686aa40801100731k62b004ecq4f6058aea5df9da0@mail.gmail.com> (raw)
On 1/9/08, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> As much as I despise having to work around firmware bugs, it looks
> indeed like this one has been broken for way too long to the point where
> users are being hurt, distros are being hurt, and telling people to
> whack things in nvramrc is just plain gross, so let's merge it.
Tangent question:
The Efika has device_type = "chrp" in the root node, but in Linux
Efika support does not use CHRP, it uses
arch/powerpc/platforms/52xx/efika.c. However, if CHRP support is
compiled in then it will see the chrp device_type and bind to it
before efika.c has a chance to probe. I see three reasonable
solutions to this:
1. Apply a device tree fixup to change device_type from "chrp" to
"efika" (the current solution)
2. Modify chrp_probe() to check specifically for the Efika when probing
3. Modify the link order so that Efika is probed before CHRP.
All three of these solutions will work, but I'd like to get opinions
on which is stylistically the best approach (or if there is another
approach I'm missing).
In general, I'm trying to reduce the Efika fixups down to only what is
absolutely necessary and as much as possible work with the provided
device tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next reply other threads:[~2008-01-10 15:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 15:31 Grant Likely [this message]
2008-01-10 15:52 ` Platform matching style (was:: [RFC] add phy-handle property for fec_mpc52xx) Olof Johansson
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=fa686aa40801100731k62b004ecq4f6058aea5df9da0@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=olaf@aepfle.de \
--cc=sven@genesi-usa.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).