[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 02/13] dp8393x: Clean up endianness hacks
From: |
Finn Thain |
Subject: |
Re: [PATCH v2 02/13] dp8393x: Clean up endianness hacks |
Date: |
Tue, 7 Jan 2020 09:19:13 +1100 (AEDT) |
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);
>
- Re: [PATCH v2 02/13] dp8393x: Clean up endianness hacks,
Finn Thain <=