LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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