On Thu, Jan 6, 2022 at 11:27 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Tue, 28 Dec 2021 at 03:34, Troy Lee <leet...@gmail.com> wrote: > > > > Hi Klaus, > > > > On Thu, Dec 23, 2021 at 11:57 PM Klaus Heinrich Kiwi > > <kl...@klauskiwi.com> wrote: > > > > > > Em qui., 23 de dez. de 2021 às 09:54, Cédric Le Goater <c...@kaod.org> > > > escreveu: > > > > > > > > [ Adding Klaus ] > > > > > > Thanks Cedric. It's been a while since I've looked at this but I'll do my > > > best.. > > > > > > > > > > > On 12/22/21 03:22, Troy Lee wrote: > > > > > > > + /* > > > > > + * Read the message length in bit from last 64/128 > > > > > bits > > > > > + * and tear the padding bits from iov > > > > > + */ > > > > > + uint64_t stream_len; > > > > > + > > > > > + memcpy(&stream_len, iov[i].iov_base + iov[i].iov_len > > > > > - 8, 8); > > > > > + stream_len = __bswap_64(stream_len) / 8; > > > > > + > > > > > > I no longer have access to the aspeed workbook I guess, but what is > > > the actual specification here? is the message length 64 or 128 bits? > > > and bswap seems arch-dependent - you probably want to be explicit if > > > this is big or little-endian and use the appropriate conversion > > > function. > > The message length is described in RFC4634: > > - SHA224 or SHA256 should be 64-bit. > > - SHA384 or SHA512 should be 128-bit. > > And it should be in big-endian. > > You can read a 64-bit BE value with > uint64_t val = ldq_be_p(iov[i].iov_base + iov[i].iov_len - 8); > or similar. (We don't have a similar function for 128 bits because > there's no fully-portable native C data type for that.) > > -- PMM
Thanks for the suggestion! Troy Lee