Re: [PATCH v2 02/13] dp8393x: Clean up endianness hacks

[Finn Thain]

On Fri, 20 Dec 2019, Finn Thain wrote:

> The in_use field is no different to the other words handled using
> dp8393x_put() and dp8393x_get(). Use the same technique for in_use
> that is used everywhere else.
> 
> Signed-off-by: Finn Thain <address@hidden>
> ---
> Changed since v1:
>  - Use existing 'address' variable rather than declare a new one.
> 
> Laurent tells me that this clean-up has been tried before. He referred
> me to commit c744cf7879 ("dp8393x: fix dp8393x_receive()") and
> commit 409b52bfe1 ("net/dp8393x: correctly reset in_use field").
> 
> Both of those patches look wrong to me because they both pass the wrong
> byte count to address_space_rw(). It's possible that those patches were
> needed to work around some kind of bug elsewhere, for example, an
> off-by-one result from dp8393x_crda(). The preceding patch in this series
> might help there.

Unfortunately this patch really does break NetBSD/arc 5.1, just as
Laurent said it would, just as commit c744cf7879 did.

Yet these patches are correct. What gives?

I found that one more change can make guests work (for both m68k q800 and 
mips64el magnum machines) --

--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -246,8 +246,10 @@ static void dp8393x_put(dp8393xState *s, int width, 
int offset,
                         uint16_t val)
 {
     if (s->big_endian) {
+        s->data[offset * width] = 0;
         s->data[offset * width + width - 1] = cpu_to_be16(val);
     } else {
+        s->data[offset * width + width - 1] = 0;
         s->data[offset * width] = cpu_to_le16(val);
     }
 }

For a wide bus interface, this forces the Most Significant Word (MSW) to 
zero. Yet another endianness hack, but it makes NetBSD 5.1 'sn' driver 
happy.

There is a similar issue with the Linux jazzsonic driver. This driver uses 
long-word-sized loads with word-sized MMIO registers --

#define SONIC_READ(reg) (*((volatile unsigned int *)dev->base_addr+reg))

This driver also expects the MSW to be zero. But the MSW actually equals 
the LSW, and the driver fails to probe:

SONIC ethernet controller not found (0x40004)

This seems to indicate that qemu-system-mips64el -M magnum is doing word 
smearing on the processor bus. Does anyone know how to prevent that?

> ---
>  hw/net/dp8393x.c | 17 ++++++-----------
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
> index 1957bd391e..b2cc768d9b 100644
> --- a/hw/net/dp8393x.c
> +++ b/hw/net/dp8393x.c
> @@ -765,8 +765,6 @@ static ssize_t dp8393x_receive(NetClientState *nc, const 
> uint8_t * buf,
>          return -1;
>      }
>  
> -    /* XXX: Check byte ordering */
> -
>      /* Check for EOL */
>      if (s->regs[SONIC_LLFA] & SONIC_DESC_EOL) {
>          /* Are we still in resource exhaustion? */
> @@ -836,15 +834,12 @@ static ssize_t dp8393x_receive(NetClientState *nc, 
> const uint8_t * buf,
>          /* EOL detected */
>          s->regs[SONIC_ISR] |= SONIC_ISR_RDE;
>      } else {
> -        /* Clear in_use, but it is always 16bit wide */
> -        int offset = dp8393x_crda(s) + sizeof(uint16_t) * 6 * width;
> -        if (s->big_endian && width == 2) {
> -            /* we need to adjust the offset of the 16bit field */
> -            offset += sizeof(uint16_t);
> -        }
> -        s->data[0] = 0;
> -        address_space_rw(&s->as, offset, MEMTXATTRS_UNSPECIFIED,
> -                         (uint8_t *)s->data, sizeof(uint16_t), 1);
> +        /* Clear in_use */
> +        address = dp8393x_crda(s) + sizeof(uint16_t) * 6 * width;
> +        size = sizeof(uint16_t) * width;
> +        dp8393x_put(s, width, 0, 0);
> +        address_space_rw(&s->as, address, MEMTXATTRS_UNSPECIFIED,
> +                         (uint8_t *)s->data, size, 1);
>          s->regs[SONIC_CRDA] = s->regs[SONIC_LLFA];
>          s->regs[SONIC_ISR] |= SONIC_ISR_PKTRX;
>          s->regs[SONIC_RSC] = (s->regs[SONIC_RSC] & 0xff00) | 
> (((s->regs[SONIC_RSC] & 0x00ff) + 1) & 0x00ff);
>