From: Kumar Gala <galak@kernel.crashing.org>
To: Nate Case <ncase@xes-inc.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH -next] powerpc/85xx: Add support for X-ES MPC85xx boards
Date: Wed, 10 Jun 2009 18:16:56 -0500 [thread overview]
Message-ID: <ED53CEC4-BB2B-4878-BA2E-44C43DB54D7E@kernel.crashing.org> (raw)
In-Reply-To: <1244670419.29684.1600.camel@localhost.localdomain>
On Jun 10, 2009, at 4:46 PM, Nate Case wrote:
> Hi Kumar,
>
> Thanks for the feedback. Response below:
>
>>> +
>>> + root = of_find_node_by_path("/");
>>> + if (root == NULL)
>>> + return;
>>> +
>>> + model = of_get_property(root, "model", NULL);
>>> + if (strncasecmp(model, "xes,", strlen("xes,")) != 0)
>>> + return;
>>
>> What is this check for?
>
> Historical accident. A while back we somehow ended up with a case of
> probe() succeeding when it shouldn't have, and this was the
> workaround.
> I'll remove it since it's useless now.
>
>>> +
>>> + printk(KERN_INFO "X-ES MPC85xx-based single-board computer: %s\n",
>>> + model + strlen("xes,"));
>>
>> Why not print the name from machine_id.name
>
> Because machine_id->name will give us "X-ES MPC8572" from the machine
> description rather than the actual board name (e.g., xpedite5370).
>
> In our situation, we have several boards that share largely the same
> hardware design. I decided to just put 1 machine definition per
> processor rather than having a machine definition for every board
> (which
> would get pretty crazy for our case). For example, we have at least 6
> MPC8572-based boards with more on the way, but all of their changes
> can
> be described in the device tree (e.g., changes in number of ethernet
> ports or PCI express controllers), so there's no need for a machine
> definition for all of them.
>
>>> +machine_device_initcall(xes_mpc8572, xes_mpc85xx_publish_devices);
>>> +machine_device_initcall(xes_mpc8548, xes_mpc85xx_publish_devices);
>>
>> Do you not need this for xes_mpc8540?
>
> Yes, thanks. I'll fix this and the other things you mentioned and
> re-submit. Will this be able to make it into your next tree destined
> for 2.6.31?
If it get submitted pretty soon I'd be willing to take it for .31.
Also can you split the patch into 3 pieces (defconfig, .dts, and
actual platform code)
- k
prev parent reply other threads:[~2009-06-10 23:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 22:13 [PATCH -next] powerpc/85xx: Add support for X-ES MPC85xx boards Nate Case
2009-06-08 22:52 ` Kumar Gala
2009-06-09 18:53 ` Nate Case
2009-06-09 19:43 ` Kumar Gala
2009-06-08 22:59 ` Kumar Gala
2009-06-10 21:46 ` Nate Case
2009-06-10 23:16 ` Kumar Gala [this message]
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=ED53CEC4-BB2B-4878-BA2E-44C43DB54D7E@kernel.crashing.org \
--to=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=ncase@xes-inc.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