[Skiboot] [PATCH 08/12] xive: make endian-clean

[Nicholas Piggin]

Oliver O'Halloran's on October 1, 2019 3:44 pm:
> On Tue, Oct 1, 2019 at 3:41 PM Cédric Le Goater <clg at kaod.org> wrote:
>>
>> On 01/10/2019 07:24, Oliver O'Halloran wrote:
>> > On Sun, 2019-09-29 at 17:46 +1000, Nicholas Piggin wrote:
>> >> Convert xive opal calls, dt construction, and in-memory hardware tables
>> >> to use explicit endian conversions.
>> >
>> > Cedric, ack/nak?
>>
>> Sorry. I was not in CC:
>>
>> Let's be honest. This is very valid but the result is dreadful.
>>
>> > I'm a bit iffy about the __prefixes since the in-memory tables are
>> > homogenously BE. If we're going to be more concerned about endian
>> > safety going forward I'd prefer we use the __beXX annotations and some
>> > kind of automated checking rather than ad-hoc conventions.
>>
>> I don't mind the __be types but I don't understand the __ prefix in
>> the word structures. is that a requirement ?
>>
>> > We might also want to do something similar to what we did with the
>> > radix tables in Linux where constants we use change based on endianness
>> > rather than having the code do cpu_to_beXX all over the place.
>>
>> I introduced helpers in QEMU to deal with endianness, as we have
>> the same problem on the pseries and PowerNV machines. It does
>> not cover all cases but it cleans up the code a lot.
>>
>> https://git.qemu.org/?p=qemu.git;a=blob;f=include/hw/ppc/xive_regs.h;h=08c8bf7172e22ec964603c2192fd462a1ae918a2;hb=HEAD#l162
>>
>> Are we in a hurry ? This is also completely ruining my patchset ...
>>
>> Nick, do you want me to take over ? I will complain less :)
> 
> I was planning on merging this after you do your v3, so no rush. I'll
> let you and nick fight it out over who gets to do the rebase ;)
> 

As discussed offline, I'm fine for Cedric's patches to go in first
and he can take over the endian fixes of xive from there.

Thanks,
Nick