On Mon, 2011-11-28 at 15:48 -0500, Kyle Moffett wrote:
> On Sun, Nov 27, 2011 at 18:51, Benjamin Herrenschmidt
> <b...@kernel.crashing.org> wrote:
> > Overall I really look your series. It doesn't quite apply cleanly
> > anymore so I'll as you for a new shoot after you address the comments
> > below, at which point, if you're fast enough, I'll stick it in -next :-)
>
> Awesome! Thanks!
>
> As I mentioned before, I have precious little of the hardware to test
> this all on, so I hope I don't break anything. At minimum I need to
> do a final build-and-run test on my e500 boards before I send it out.
> :-D
That's ok, I was planning on letting it simmer in -test for a week or
so, giving myself time to test on a range of powermacs etc...
> > Just a couple of comments on some of the patches:
> >
> > - 5/10: search for open-pic device-tree node if NULL
> >
> > The idea is fine, however most callers ignore the device-type and only
> > compare on compatible, while you replace that with a match entry that
> > seems to require matching on both. This is likely to break stuff. The
> > "type" part of te march entry should be NULL I believe.
>
> If you re-read that, the match table used if no of_node is passed in
> has *two* separate entries, one of them with a "type" and the other
> with a "compatible", as opposed to a single entry which matches both
> "type" and "compatible".
Oh, my bad. Ok.
> There are a lot of callers which do:
> dnp = of_find_node_by_type(NULL, "open-pic");
>
> So I doubt I can remove the "type" entry all together, unfortunately.
>
>
> > - 9/10: cache the node
> >
> > of_node_get() is your friend.
>
> Yes, I actually messed this one up in the prior patch too, thanks for
> noticing. It should all be fixed now.
>
>
> > - 10/10: Makes me a bit nervous. It 'looks' right but I wouldn't bet on
> > Apple device-trees being sane vs. chaining. I would like a test that
> > doesn't do the cascade if the mpic is a primary to at least limit the
> > risk of messup.
>
> Oh, you mean to wrap that block like this?
>
> if (mpic->flags & MPIC_SECONDARY) {
> virq = irq_of_parse_and_map(mpic->node, 0);
> ...
> }
Yes.
> Sure, makes sense to me. I've made that change.
>
> Thanks for the review!
Thanks. Re-post the whole series and I'll merge it.
Cheers,
Ben.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
