netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: grygorii.strashko@ti.com
Cc: netdev@vger.kernel.org, mugunthanvnm@ti.com, nsekhar@ti.com,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	ivan.khoronzhuk@linaro.org
Subject: Re: [PATCH 1/7] net: ethernet: ti: cpdma: am437x: allow descs to be plased in ddr
Date: Sat, 03 Dec 2016 15:34:19 -0500 (EST)	[thread overview]
Message-ID: <20161203.153419.482900037601991931.davem@davemloft.net> (raw)
In-Reply-To: <20161201233432.6182-2-grygorii.strashko@ti.com>

From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Thu, 1 Dec 2016 17:34:26 -0600

> @@ -167,10 +167,10 @@ static struct cpdma_control_info controls[] = {
>  
>  /* various accessors */
>  #define dma_reg_read(ctlr, ofs)		__raw_readl((ctlr)->dmaregs + (ofs))
> -#define chan_read(chan, fld)		__raw_readl((chan)->fld)
> +#define chan_read(chan, fld)		readl((chan)->fld)
>  #define desc_read(desc, fld)		__raw_readl(&(desc)->fld)
>  #define dma_reg_write(ctlr, ofs, v)	__raw_writel(v, (ctlr)->dmaregs + (ofs))
> -#define chan_write(chan, fld, v)	__raw_writel(v, (chan)->fld)
> +#define chan_write(chan, fld, v)	writel(v, (chan)->fld)
>  #define desc_write(desc, fld, v)	__raw_writel((u32)(v), &(desc)->fld)

Unless you want to keep running into subtle errors all over the
place wrt. register vs. memory write ordering, I strong suggest
you use strongly ordered readl/writel for all register accesses.

I see no tangible, worthwhile, advantage to using these relaxed
ordering primitives.  The only result is potential bugs.

People who use the relaxed ordering primitives properly are only
doing so in extremely carefully coded sequences where a series
of writes has no dependency on main memory operations and is
explicitly completed with a barrier operation such as a read
back of a register in the same device.

That's not at all what is going on here, instead the driver is wildly
using relaxed ordered register accesses for basically everything.
This is extremely unwise and it's why you ran into this bug in the
first place.

Therefore, I absolutely require that you fix this by eliminating
any and all usese of relaxed ordering I/O accessors in this driver.

Thank you.

  reply	other threads:[~2016-12-03 20:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01 23:34 [PATCH 0/7] net: ethernet: ti: cpsw: support placing CPDMA descriptors into DDR Grygorii Strashko
2016-12-01 23:34 ` [PATCH 1/7] net: ethernet: ti: cpdma: am437x: allow descs to be plased in ddr Grygorii Strashko
2016-12-03 20:34   ` David Miller [this message]
2016-12-05 17:57     ` Grygorii Strashko
2016-12-01 23:34 ` [PATCH 2/7] net: ethernet: ti: cpdma: fix desc re-queuing Grygorii Strashko
2016-12-02 11:03   ` Ivan Khoronzhuk
2016-12-02 16:45     ` Grygorii Strashko
2016-12-02 23:28       ` Ivan Khoronzhuk
2016-12-05 18:22         ` Grygorii Strashko
2016-12-01 23:34 ` [PATCH 3/7] net: ethernet: ti: cpdma: minimize number of parameters in cpdma_desc_pool_create/destroy() Grygorii Strashko
2016-12-01 23:34 ` [PATCH 4/7] net: ethernet: ti: cpdma: use devm_ioremap Grygorii Strashko
2016-12-01 23:34 ` [PATCH 5/7] Documentation: DT: net: cpsw: allow to specify descriptors pool size Grygorii Strashko
2016-12-02 11:28   ` Ivan Khoronzhuk
2016-12-02 17:21     ` Grygorii Strashko
2016-12-07 19:41       ` Grygorii Strashko
2016-12-02 17:22     ` Grygorii Strashko
2016-12-03  0:37       ` Ivan Khoronzhuk
2016-12-01 23:34 ` [PATCH 6/7] net: ethernet: ti: cpsw: add support for descs_pool_size dt property Grygorii Strashko
2016-12-01 23:34 ` [PATCH 7/7] Documentation: DT: net: cpsw: remove no_bd_ram property Grygorii Strashko

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=20161203.153419.482900037601991931.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=grygorii.strashko@ti.com \
    --cc=ivan.khoronzhuk@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mugunthanvnm@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=nsekhar@ti.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 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).