On Fri, 2014-11-28 at 09:39 +0100, Greg Kurz wrote: > On Fri, 28 Nov 2014 12:49:08 +1100 > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > > In a second pass, we parse that stream, one 16-bytes at a time, and > > we could do so with a simple loop of be16_to_cpup(foo++). I wouldn't > > bother with the cast to 32-bit etc... if you encounter a 32-bit case, > > you just fetch another 16-bit and do value = (old << 16) | new > > > > I think that should lead to something more readable, no ? > > Of course ! This is THE way to go. Thanks Ben ! :) > > An while we're here, I have a question about VPHN_ASSOC_BUFSIZE. The > H_HOME_NODE_ASSOCIATIVITY spec says that the stream: > - is at most 64 * 6 = 384 bits long
That's from "Each of the registers R4-R9 ..." > - may contain 16-bit numbers "... is divided into 4 fields each 2 bytes long." > - is padded with "all ones" > > The stream could theoretically contain up to 384 / 16 = 24 domain numbers. Yes I think that's right, based on: "The high order bit of each 2 byte field is a length specifier: 1: The associativity domain number is contained in the low order 15 bits of the field," But then there's also: "0: The associativity domain number is contained in the low order 15 bits of the current field concatenated with the 16 bits of the next sequential field)" > The current code expects no more than 12 domain numbers... and strangely > seems to correlate the size of the output array to the size of the input > one as noted in the comment: > > "6 64-bit registers unpacked into 12 32-bit associativity values" > > My understanding is that the resulting array is be32 only because it is > supposed to look like the ibm,associativity property from the DT... and > I could find no clue that this property is limited to 12 values. Have I > missed something ? I don't know for sure, but I strongly suspect it's just confused about the two options above. Probably when it was tested they only ever saw 12 32-bit values, and so that assumption was allowed to stay in the code. I'd be quite happy if you wanted to pull the parsing logic out into a separate file, so we could write some userspace tests of it. cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev