qemu-devel
[Top][All Lists]
Advanced

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

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


From: Mark Cave-Ayland
Subject: Re: [PATCH 2/6] dp8393x: don't force 32-bit register access
Date: Sun, 4 Jul 2021 16:34:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 03/07/2021 17:29, Philippe Mathieu-Daudé wrote:

On 7/3/21 4:39 PM, Mark Cave-Ayland wrote:
On 03/07/2021 15:19, Philippe Mathieu-Daudé wrote:

From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that
all accesses
to the registers were 32-bit but this is actually not the case. The
access size is
determined by the CPU instruction used and not the number of physical
address lines.

The big_endian workaround applied to the register read/writes was
actually caused
by forcing the access size to 32-bit when the guest OS was using a
16-bit access.
Since the registers are 16-bit then we can simply set .impl.min_access
to 2 and
then the memory API will automatically do the right thing for both
16-bit accesses
used by Linux and 32-bit accesses used by the MacOS toolbox ROM.

The change should work, but the commit message above needs a slight
tweak - maybe something like this?

Since the registers are 16-bit then we can simply set both
.impl.min_access and .impl.max_access to 2 and then the memory API will
automatically do the right thing for both 16-bit accesses used by Linux
and 32-bit accesses used by the MacOS toolbox ROM.

Do you mind sending v3 of this patch reworded (and including the .valid
fields)?

I've sent a v3 with the rewording but dropping the .valid fields since that breaks MacOS and removed Finn's T-b tag as it may be there is an issue here with mips64el - whilst it works for me on all of my test images, I'm struggling to keep up with all the patches flying around everywhere :/

Now that your MIPS PR has been applied, perhaps it is worth sending a rebased v2 of your RFC "dp8393x: Housekeeping" patchset to ensure that everyone is up to date with the latest fixes? I won't be able to have a look at the CRC patchset for a few days though.


ATB,

Mark.



reply via email to

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