linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* mpic_alloc: Differences between of_address_to_resource() and of_get_property()+of_translate_address()
@ 2011-02-24 17:43 Moffett, Kyle D
  2011-02-24 20:43 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 2+ messages in thread
From: Moffett, Kyle D @ 2011-02-24 17:43 UTC (permalink / raw)
  To: linuxppc-dev

Hello everyone,

I'm currently cleaning up a new P2020 (mpc85xx) board port for submission a=
nd I was noticing a lot of commonalities between the various ports.

In particular, at least 80% of the mpic_alloc() callers seem to do somethin=
g like this (with more error-checking):

struct resource r;
of_address_to_resource(np, 0, &r);
mpic_alloc(np, r.start, [...]);

But mpic_alloc() itself seems to have some logic for digging the base addre=
ss out of OpenFirmware already:

if (paddr =3D=3D 0 && !(mpic->flags & MPIC_USES_DCR)) {
      const u32 *reg =3D of_get_property(node, "reg", NULL);
      BUG_ON(reg =3D=3D NULL);
      paddr =3D of_translate_address(node, reg);
      BUG_ON(paddr =3D=3D OF_BAD_ADDR);
}

As far as I can tell, the code in mpic_alloc() is a very limited form of of=
_address_to_resource() without a lot of the special cases, but I can't tell=
 what the effect of those special cases would be on the boards relying on m=
pic_alloc(np, 0, [...]);

I'd like to just convert mpic_alloc() to do the of_address_to_resource() in=
ternally (instead of the existing logic), but I'd be afraid of breaking oth=
er systems.

Any comments/advice?

Cheers,
Kyle Moffett

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: mpic_alloc: Differences between of_address_to_resource() and of_get_property()+of_translate_address()
  2011-02-24 17:43 mpic_alloc: Differences between of_address_to_resource() and of_get_property()+of_translate_address() Moffett, Kyle D
@ 2011-02-24 20:43 ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 2+ messages in thread
From: Benjamin Herrenschmidt @ 2011-02-24 20:43 UTC (permalink / raw)
  To: Moffett, Kyle D; +Cc: linuxppc-dev

On Thu, 2011-02-24 at 11:43 -0600, Moffett, Kyle D wrote:
> Hello everyone,
> 
> I'm currently cleaning up a new P2020 (mpc85xx) board port for submission and I was noticing a lot of commonalities between the various ports.
> 
> In particular, at least 80% of the mpic_alloc() callers seem to do something like this (with more error-checking):
> 
> struct resource r;
> of_address_to_resource(np, 0, &r);
> mpic_alloc(np, r.start, [...]);
> 
> But mpic_alloc() itself seems to have some logic for digging the base address out of OpenFirmware already:
> 
> if (paddr == 0 && !(mpic->flags & MPIC_USES_DCR)) {
>       const u32 *reg = of_get_property(node, "reg", NULL);
>       BUG_ON(reg == NULL);
>       paddr = of_translate_address(node, reg);
>       BUG_ON(paddr == OF_BAD_ADDR);
> }
> 
> As far as I can tell, the code in mpic_alloc() is a very limited form of of_address_to_resource() without a
> lot of the special cases, but I can't tell what the effect of those special cases would be on the boards
> relying on mpic_alloc(np, 0, [...]);

Probably none, ie, it's probably historical and could probably be
converted.

> I'd like to just convert mpic_alloc() to do the of_address_to_resource() internally (instead of the existing logic),
> but I'd be afraid of breaking other systems.
> 
> Any comments/advice?

I think it can be tried :-) The risk should be reasonably low.

Cheers,
Ben.

> Cheers,
> Kyle Moffett
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-02-24 20:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-24 17:43 mpic_alloc: Differences between of_address_to_resource() and of_get_property()+of_translate_address() Moffett, Kyle D
2011-02-24 20:43 ` Benjamin Herrenschmidt

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).