[PATCH] Power5,Power6 BSR driver

Benjamin Herrenschmidt benh at kernel.crashing.org
Tue Jul 8 08:26:57 EST 2008


On Mon, 2008-07-07 at 16:17 -0500, Sonny Rao wrote:
> On Mon, Jul 07, 2008 at 02:59:35PM +1000, Benjamin Herrenschmidt wrote:
> > 
> > > +		cur->bsr_addr   = reg[i * 2];
> > > +		cur->bsr_len    = reg[i * 2 + 1];
> > 
> > That's fishy... hand-reading of "reg" property without taking
> > into account the parent's #size-cells/#address-cells... can't you
> > use of_address_to_resource or something similar and carry a struct
> > resource around instead ?
> 
> So, with this suggestion I looked at the resource API... not very well
> documented, and I get the feeling like it's more for carving up a PCI
> memory address range.  In the case of the BSR, everything is already
> partitioned (by hardware) so I don't see the point of using this API
> here.  Or am I missing something about it?

It's about properly parsing a "reg" property in OF. The format of the
reg property depends on the parent #address-cells and #size-cells, and
the addresses in there may need remapping (or not) depending on parent
"ranges" properties. The special cases in prom_parse.c for PCI and ISA
are purely to deal with the additional address space flags those add to
addresses, but you shouldn't hit that with BSR.

> > In fact, same goes with the way you do num_bsr_devs = reg_len / 16.
> > 
> > You should rather use -another- property of well known lenght, or
> > get the #address/#size-cells of the parent and use those appropriately.
> 
> Well, I check to make sure the lengths are consistent with each other
> right above there so we shouldn't walk off the end of anything, but I
> will take a look at using #size-cells / #address-cells instead.

The code in prom_parse.c will do it for you :-)

Cheers,
Ben.





More information about the Linuxppc-dev mailing list