On 1/6/20 11:19 PM, Finn Thain wrote:
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 <fth...@telegraphics.com.au> --- 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.
Can you write a list of real word addresses/values/result expected for each endianess, so we can add a qtest for this?
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?
I remember a similar issue with another MIPS board because QEMU doesn't model the bus controller, which might do such magic.
--- 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);
