diff mbox

[v3,1/5] io: define several IO & PIO barrier types for the asm-generic version

Message ID 1522886301-25955-1-git-send-email-okaya@codeaurora.org (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Sinan Kaya April 4, 2018, 11:58 p.m. UTC
Getting ready to harden readX()/writeX() and inX()/outX() semantics for the
generic implementation.

Defining two set of macros as __io_br() and __io_ar() to indicate actions
to be taken before and after MMIO read.

Defining two set of macros as __io_bw() and __io_aw() to indicate actions
to be taken before and after MMIO write.

Defining two set of macros as __io_pbw() and __io_paw() to indicate actions
to be taken before and after Port IO write.

Defining two set of macros as __io_pbr() and __io_par() to indicate actions
to be taken before and after Port IO read.

If rmb() is available for the architecture, prefer rmb() as the default
implementation of __io_ar()/__io_par().

If wmb() is available for the architecture, prefer wmb() as the default
implementation of __io_bw()/__io_pbw().

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 include/asm-generic/io.h | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

Comments

Arnd Bergmann April 5, 2018, 7 a.m. UTC | #1
On Thu, Apr 5, 2018 at 1:58 AM, Sinan Kaya <okaya@codeaurora.org> wrote:

Looks good, but I'd change the comments to ones that document exactly
what those barriers are for:

> +#ifndef __io_ar
> +#ifdef rmb
> +/* prefer rmb() as the default implementation of __io_ar() if supported */
> +#define __io_ar()      rmb()

/*
 * prevent prefetching of coherent DMA data ahead of a dma-complete */

> +#ifndef __io_bw
> +#ifdef wmb
> +/* prefer wmb() as the default implementation of __io_bw() if supported */
> +#define __io_bw()      wmb()
> +#else

/* flush writes to coherent DMA data before possibly triggering a DMA read */

> +#ifndef __io_aw
> +#define __io_aw()      barrier()
> +#endif

/* serialize device access against a spin_unlock, usually handled there */

The other four patches look perfect already.  What's the timing we need for
these patches? Are they 4.18 material, or do we need them in 4.17 and
stable kernels to work around known bugs?

      Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sinan Kaya April 5, 2018, 11:48 a.m. UTC | #2
On 2018-04-05 03:00, Arnd Bergmann wrote:
> On Thu, Apr 5, 2018 at 1:58 AM, Sinan Kaya <okaya@codeaurora.org> 
> wrote:
> 
> Looks good, but I'd change the comments to ones that document exactly
> what those barriers are for:
> 
>> +#ifndef __io_ar
>> +#ifdef rmb
>> +/* prefer rmb() as the default implementation of __io_ar() if 
>> supported */
>> +#define __io_ar()      rmb()
> 
> /*
>  * prevent prefetching of coherent DMA data ahead of a dma-complete */
> 
>> +#ifndef __io_bw
>> +#ifdef wmb
>> +/* prefer wmb() as the default implementation of __io_bw() if 
>> supported */
>> +#define __io_bw()      wmb()
>> +#else
> 
> /* flush writes to coherent DMA data before possibly triggering a DMA 
> read */
> 
>> +#ifndef __io_aw
>> +#define __io_aw()      barrier()
>> +#endif
> 
> /* serialize device access against a spin_unlock, usually handled there 
> */
> 

I will add these and post the next version.

> The other four patches look perfect already.  What's the timing we need 
> for
> these patches? Are they 4.18 material, or do we need them in 4.17 and
> stable kernels to work around known bugs?

I was hoping to get all arch stuff in for 4.17.

Driver developers started removing redundant wmb().

> 
>       Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann April 5, 2018, 11:58 a.m. UTC | #3
On Thu, Apr 5, 2018 at 1:48 PM,  <okaya@codeaurora.org> wrote:
> On 2018-04-05 03:00, Arnd Bergmann wrote:

>> The other four patches look perfect already.  What's the timing we need
>> for
>> these patches? Are they 4.18 material, or do we need them in 4.17 and
>> stable kernels to work around known bugs?
>
>
> I was hoping to get all arch stuff in for 4.17.
>
> Driver developers started removing redundant wmb().

Ok, so 4.17 but no stable backports then.

     Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index b4531e3..a3d349e 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -25,6 +25,49 @@ 
 #define mmiowb() do {} while (0)
 #endif
 
+#ifndef __io_br
+#define __io_br()      barrier()
+#endif
+
+#ifndef __io_ar
+#ifdef rmb
+/* prefer rmb() as the default implementation of __io_ar() if supported */
+#define __io_ar()      rmb()
+#else
+#define __io_ar()      barrier()
+#endif
+#endif
+
+#ifndef __io_bw
+#ifdef wmb
+/* prefer wmb() as the default implementation of __io_bw() if supported */
+#define __io_bw()      wmb()
+#else
+#define __io_bw()      barrier()
+#endif
+#endif
+
+#ifndef __io_aw
+#define __io_aw()      barrier()
+#endif
+
+#ifndef __io_pbw
+#define __io_pbw()     __io_bw()
+#endif
+
+#ifndef __io_paw
+#define __io_paw()     __io_aw()
+#endif
+
+#ifndef __io_pbr
+#define __io_pbr()     __io_br()
+#endif
+
+#ifndef __io_par
+#define __io_par()     __io_ar()
+#endif
+
+
 /*
  * __raw_{read,write}{b,w,l,q}() access memory in native endianness.
  *