qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Jason Wang <jasowang@redhat.com>, qemu-devel@nongnu.org
Cc: Aleksandar Rikalo <aleksandar.rikalo@rt-rk.com>,
	Herve Poussineau <hpoussin@reactos.org>,
	Laurent Vivier <laurent@vivier.eu>,
	qemu-stable@nongnu.org
Subject: [PATCH 02/10] dp8393x: Clean up endianness hacks
Date: Sat, 14 Dec 2019 12:25:57 +1100	[thread overview]
Message-ID: <397259001f92f93620a618e83599463b1faa54ee.1576286757.git.fthain@telegraphics.com.au> (raw)
In-Reply-To: <cover.1576286757.git.fthain@telegraphics.com.au>

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 <fthain@telegraphics.com.au>
---
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.

This needs testing with the little endian MIPS Jazz emulation.
---
 hw/net/dp8393x.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 164311c055..3fd59bc1d4 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -760,8 +760,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] & 0x1) {
         /* Are we still in resource exhaustion? */
@@ -831,15 +829,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 */
+        /* Clear in_use */
         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;
+        size = sizeof(uint16_t) * width;
+        dp8393x_put(s, width, 0, 0);
         address_space_rw(&s->as, offset, MEMTXATTRS_UNSPECIFIED,
-                         (uint8_t *)s->data, sizeof(uint16_t), 1);
+                         (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);
-- 
2.23.0



  parent reply	other threads:[~2019-12-14  1:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-14  1:25 [PATCH 00/10] Fixes for DP8393X SONIC device emulation Finn Thain
2019-12-14  1:25 ` [PATCH 08/10] dp8393x: Implement packet size limit and RBAE interrupt Finn Thain
2019-12-14  1:25 ` [PATCH 09/10] dp8393x: Don't stop reception upon RBE interrupt assertion Finn Thain
2019-12-14  1:25 ` [PATCH 06/10] dp8393x: Clear RRRA command register bit only when appropriate Finn Thain
2019-12-14 13:31   ` Philippe Mathieu-Daudé
2019-12-14  1:25 ` Finn Thain [this message]
2019-12-14  1:25 ` [PATCH 05/10] dp8393x: Update LLFA register Finn Thain
2019-12-14  1:25 ` [PATCH 10/10] dp8393x: Don't clobber packet checksum Finn Thain
2019-12-14 13:21   ` Philippe Mathieu-Daudé
2019-12-14  1:25 ` [PATCH 07/10] dp8393x: Implement TBWC0 and TBWC1 registers to restore buffer state Finn Thain
2019-12-14  1:25 ` [PATCH 01/10] dp8393x: Mask EOL bit from descriptor addresses Finn Thain
2019-12-14 13:35   ` Philippe Mathieu-Daudé
2019-12-14 23:21     ` Finn Thain
2019-12-14  1:25 ` [PATCH 04/10] dp8393x: Don't advance RX descriptor twice Finn Thain
2019-12-14  1:25 ` [PATCH 03/10] dp8393x: Have dp8393x_receive() return the packet size Finn Thain
2019-12-14 13:26   ` Philippe Mathieu-Daudé
2019-12-14  1:43 ` [PATCH 00/10] Fixes for DP8393X SONIC device emulation no-reply
2019-12-14  2:52   ` Finn Thain
2019-12-14 13:38     ` Philippe Mathieu-Daudé
2019-12-14 13:45       ` Eric Blake
2019-12-14 17:17 ` Aleksandar Markovic
2019-12-14 23:16   ` Finn Thain
2019-12-14 23:32     ` Aleksandar Markovic
2019-12-14 23:35       ` Aleksandar Markovic
2019-12-20  4:24         ` Finn Thain
2019-12-23 17:17           ` Philippe Mathieu-Daudé
2019-12-24  0:12             ` NetBSD/arc on MIPS Magnum, was " Finn Thain
2019-12-24  4:33               ` Finn Thain
2019-12-24  6:53                 ` Hervé Poussineau
2020-01-06 22:15                   ` Finn Thain
2019-12-16  0:36     ` Finn Thain
2019-12-20  4:21       ` Finn Thain
2019-12-20 11:38 ` Aleksandar Markovic
2019-12-20 12:03   ` Aleksandar Markovic
2019-12-20 12:54   ` Laurent Vivier
2019-12-20 23:22     ` Finn Thain
2019-12-21 12:03       ` Aleksandar Markovic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=397259001f92f93620a618e83599463b1faa54ee.1576286757.git.fthain@telegraphics.com.au \
    --to=fthain@telegraphics.com.au \
    --cc=aleksandar.rikalo@rt-rk.com \
    --cc=hpoussin@reactos.org \
    --cc=jasowang@redhat.com \
    --cc=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).