From: David Miller <davem@davemloft.net>
To: anssi.hannula@bitwise.fi
Cc: michal.simek@xilinx.com, soren.brinkmann@xilinx.com,
netdev@vger.kernel.org
Subject: Re: [PATCH 2/2] net: xilinx_emaclite: fix freezes due to unordered I/O
Date: Wed, 15 Feb 2017 12:19:41 -0500 (EST) [thread overview]
Message-ID: <20170215.121941.1615540242375929154.davem@davemloft.net> (raw)
In-Reply-To: <20170214171145.26953-2-anssi.hannula@bitwise.fi>
From: Anssi Hannula <anssi.hannula@bitwise.fi>
Date: Tue, 14 Feb 2017 19:11:45 +0200
> The xilinx_emaclite uses __raw_writel and __raw_readl for register
> accesses. Those functions do not imply any kind of memory barriers and
> they may be reordered.
>
> The driver does not seem to take that into account, though, and the
> driver does not satisfy the ordering requirements of the hardware.
> For clear examples, see xemaclite_mdio_write() and xemaclite_mdio_read()
> which try to set MDIO address before initiating the transaction.
>
> I'm seeing system freezes with the driver with GCC 5.4 and current
> Linux kernels on Zynq-7000 SoC immediately when trying to use the
> interface.
>
> In commit 123c1407af87 ("net: emaclite: Do not use microblaze and ppc
> IO functions") the driver was switched from non-generic
> in_be32/out_be32 (memory barriers, big endian) to
> __raw_readl/__raw_writel (no memory barriers, native endian), so
> apparently the device follows system endianness and the driver was
> originally written with the assumption of memory barriers.
>
> Rather than try to hunt for each case of missing barrier, just switch
> the driver to use iowrite32/ioread32/iowrite32be/ioread32be depending
> on endianness instead.
>
> Tested on little-endian Zynq-7000 ARM SoC FPGA.
>
> Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
> Fixes: 123c1407af87 ("net: emaclite: Do not use microblaze and ppc IO
> functions")
Applied.
next prev parent reply other threads:[~2017-02-15 17:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 17:11 [PATCH 1/2] net: xilinx_emaclite: fix receive buffer overflow Anssi Hannula
2017-02-14 17:11 ` [PATCH 2/2] net: xilinx_emaclite: fix freezes due to unordered I/O Anssi Hannula
2017-02-15 17:19 ` David Miller [this message]
2017-02-14 20:12 ` [PATCH 1/2] net: xilinx_emaclite: fix receive buffer overflow David Miller
2017-02-15 8:28 ` Anssi Hannula
2017-02-15 15:31 ` David Laight
2017-02-15 17:19 ` David Miller
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=20170215.121941.1615540242375929154.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=anssi.hannula@bitwise.fi \
--cc=michal.simek@xilinx.com \
--cc=netdev@vger.kernel.org \
--cc=soren.brinkmann@xilinx.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.