[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mark Cave-Ayland
Subject: Re: [PATCH 1/4] dp8393x: don't force 32-bit register access
Date: Thu, 8 Jul 2021 09:50:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]