[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: |
Finn Thain |
Subject: |
Re: [PATCH 1/4] dp8393x: don't force 32-bit register access |
Date: |
Thu, 8 Jul 2021 10:52:22 +1000 (AEST) |
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.
[PATCH 2/4] dp8393x: Replace address_space_rw(is_write=1) by address_space_write(), Mark Cave-Ayland, 2021/07/05
[PATCH 3/4] dp8393x: Store CAM registers as 16-bit, Mark Cave-Ayland, 2021/07/05
[PATCH 4/4] dp8393x: Rewrite dp8393x_get() / dp8393x_put(), Mark Cave-Ayland, 2021/07/05