From: Michael Ellerman <mpe@ellerman•id.au>
To: Greg Kurz <gkurz@linux•vnet.ibm.com>
Cc: linuxppc-dev@lists•ozlabs.org, Paul Mackerras <paulus@samba•org>
Subject: Re: [PATCH REPOST 3/3] powerpc/vphn: move endianness fixing to vphn_unpack_associativity()
Date: Mon, 01 Dec 2014 20:17:30 +1100 [thread overview]
Message-ID: <1417425450.25107.3.camel@concordia> (raw)
In-Reply-To: <20141128093919.700f1874@bahia.local>
On Fri, 2014-11-28 at 09:39 +0100, Greg Kurz wrote:
> On Fri, 28 Nov 2014 12:49:08 +1100
> Benjamin Herrenschmidt <benh@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
prev parent reply other threads:[~2014-12-01 9:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 17:42 [PATCH REPOST 0/3] VPHN parsing fixes Greg Kurz
2014-11-17 17:42 ` [PATCH REPOST 1/3] powerpc/vphn: clarify the H_HOME_NODE_ASSOCIATIVITY API Greg Kurz
2014-11-17 17:42 ` [PATCH REPOST 2/3] powerpc/vphn: simplify the parsing code Greg Kurz
2014-11-17 17:42 ` [PATCH REPOST 3/3] powerpc/vphn: move endianness fixing to vphn_unpack_associativity() Greg Kurz
2014-11-26 23:39 ` Benjamin Herrenschmidt
2014-11-27 9:28 ` Greg Kurz
2014-11-28 1:49 ` Benjamin Herrenschmidt
2014-11-28 8:39 ` Greg Kurz
2014-12-01 9:17 ` Michael Ellerman [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=1417425450.25107.3.camel@concordia \
--to=mpe@ellerman$(echo .)id.au \
--cc=gkurz@linux$(echo .)vnet.ibm.com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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