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.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Fixes: 3fe9a838ec ("dp8393x: Always use 32-bit accesses")
Tested-by: Finn Thain <fthain@linux-m68k.org>
Message-Id: <20210625065401.30170-9-mark.cave-ayland@ilande.co.uk>
[PMD: dp8393x_ops.impl.max_access_size 4 -> 2]
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/net/dp8393x.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 11810c9b600..d16ade2b198 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -602,15 +602,14 @@ static uint64_t dp8393x_read(void *opaque, hwaddr addr, unsigned int size)
 
     trace_dp8393x_read(reg, reg_names[reg], val, size);
 
-    return s->big_endian ? val << 16 : val;
+    return val;
 }
 
-static void dp8393x_write(void *opaque, hwaddr addr, uint64_t data,
+static void dp8393x_write(void *opaque, hwaddr addr, uint64_t val,
                           unsigned int size)
 {
     dp8393xState *s = opaque;
     int reg = addr >> s->it_shift;
-    uint32_t val = s->big_endian ? data >> 16 : data;
 
     trace_dp8393x_write(reg, reg_names[reg], val, size);
 
@@ -694,8 +693,8 @@ static void dp8393x_write(void *opaque, hwaddr addr, uint64_t data,
 static const MemoryRegionOps dp8393x_ops = {
     .read = dp8393x_read,
     .write = dp8393x_write,
-    .impl.min_access_size = 4,
-    .impl.max_access_size = 4,
+    .impl.min_access_size = 2,
+    .impl.max_access_size = 2,
     .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-- 
2.31.1

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.

> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> Fixes: 3fe9a838ec ("dp8393x: Always use 32-bit accesses")
> Tested-by: Finn Thain <fthain@linux-m68k.org>
> Message-Id: <20210625065401.30170-9-mark.cave-ayland@ilande.co.uk>
> [PMD: dp8393x_ops.impl.max_access_size 4 -> 2]
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>   hw/net/dp8393x.c | 9 ++++-----
>   1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
> index 11810c9b600..d16ade2b198 100644
> --- a/hw/net/dp8393x.c
> +++ b/hw/net/dp8393x.c
> @@ -602,15 +602,14 @@ static uint64_t dp8393x_read(void *opaque, hwaddr addr, unsigned int size)
>   
>       trace_dp8393x_read(reg, reg_names[reg], val, size);
>   
> -    return s->big_endian ? val << 16 : val;
> +    return val;
>   }
>   
> -static void dp8393x_write(void *opaque, hwaddr addr, uint64_t data,
> +static void dp8393x_write(void *opaque, hwaddr addr, uint64_t val,
>                             unsigned int size)
>   {
>       dp8393xState *s = opaque;
>       int reg = addr >> s->it_shift;
> -    uint32_t val = s->big_endian ? data >> 16 : data;
>   
>       trace_dp8393x_write(reg, reg_names[reg], val, size);
>   
> @@ -694,8 +693,8 @@ static void dp8393x_write(void *opaque, hwaddr addr, uint64_t data,
>   static const MemoryRegionOps dp8393x_ops = {
>       .read = dp8393x_read,
>       .write = dp8393x_write,
> -    .impl.min_access_size = 4,
> -    .impl.max_access_size = 4,
> +    .impl.min_access_size = 2,
> +    .impl.max_access_size = 2,
>       .endianness = DEVICE_NATIVE_ENDIAN,
>   };


ATB,

Mark.

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)?

>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>> Fixes: 3fe9a838ec ("dp8393x: Always use 32-bit accesses")
>> Tested-by: Finn Thain <fthain@linux-m68k.org>
>> Message-Id: <20210625065401.30170-9-mark.cave-ayland@ilande.co.uk>
>> [PMD: dp8393x_ops.impl.max_access_size 4 -> 2]
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>>   hw/net/dp8393x.c | 9 ++++-----
>>   1 file changed, 4 insertions(+), 5 deletions(-)

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.

On Sat, 3 Jul 2021, 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.
> 
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> Fixes: 3fe9a838ec ("dp8393x: Always use 32-bit accesses")
> Tested-by: Finn Thain <fthain@linux-m68k.org>

I have to retract that tested-by tag for this new version. It breaks my 
Linux/mipsel guest. The jazzsonic driver now says,

SONIC ethernet controller not found (0x40004)

> Message-Id: <20210625065401.30170-9-mark.cave-ayland@ilande.co.uk>
> [PMD: dp8393x_ops.impl.max_access_size 4 -> 2]
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>