Re: [PATCH 1/4] dp8393x: don't force 32-bit register access

[Mark Cave-Ayland]

On 08/07/2021 01:52, Finn Thain wrote:

> On Wed, 7 Jul 2021, Mark Cave-Ayland wrote:
>
> > However this conflicts with what you mention above that the SONIC is
> > hard-coded into little-endian mode, in which case we would still need to
> > keep it.
>
> If you want to fully implement BMODE in QEMU then you'll need to abandon
> native endiannes for the device implementation. I was not proposing this
> as it implies more byte swapping.
>
> In a real Magnum the SONIC chip is connected to a bus that's not modelled
> by QEMU. It follows that BMODE serves different purposes than big_endian.
>
> I pointed out several semantic differences between BMODE and big_endian,
> but I think the most significant of those was that endianness is already a
> property of the memory device being accessed for DMA. Yet big_endian is a
> property of the dp8393x device.
>
> > Certainly we can look to improve things in the future, but without
> > anyone having a working big-endian MIPS image to test against, I don't
> > think it's worth guessing what changes are required as we can easily
> > double the length of this thread and still have no idea if any changes
> > we've made are correct.
>
> That argument can be applied to other patches in this series also.
>
> Anyway, if we agree that the aim is ultimately to remove the big_endian
> flag then patch 4/4 should probably be re-evaluated in light of that.

Other than fixing up the MMIO accesses to use the memory API, the patches in this 
series are just tidy-ups and refactorings i.e. no change in functionality related to 
the big_endian property. This is exactly the case for patch 4. If there were any 
changes to the big_endian logic required, then those would be handled by a separate 
patch (or patches) outside of this refactoring work.

As I said before I'm not opposed to this, but we're coming up to freeze in less than 
a week and no-one has been able to provide working MIPS big endian and little endian 
test images in a thread lasting 3 weeks. Therefore my recommendation would be to 
merge the series in its current form for 6.1 and then when someone has found time to 
generate working images and do the required analysis around the big_endian logic, we 
can consider further changes later.


ATB,

Mark.