[PATCH 3/3] arm64: enable 128-bit memory read/write support

[Yury Norov]

On Wed, Jan 24, 2018 at 02:00:42PM +0100, Geert Uytterhoeven wrote:
> Hi Yury,
> 
> On Wed, Jan 24, 2018 at 10:05 AM, Yury Norov <ynorov at caviumnetworks.com> wrote:
> > Introduce __raw_writeo(), __raw_reado() and other arch-specific
> > RW functions for 128-bit memory access, and enable it for arm64.
> >
> > 128-bit I/O is required for example by Octeon TX2 device to access
> > some registers. According to Hardware Reference Manual:
> >
> > A 128-bit write to the OP_FREE0/1 registers frees a pointer into a
> > given [...] pool. All other accesses to these registers (e.g. reads
> > and 64-bit writes) are RAZ/WI.
> >
> > Starting from ARMv8.4, stp and ldp instructions become atomic, and
> > API for 128-bit access would be helpful for core code.
> >
> > Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
> 
> Thanks for your patch!
> 
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -116,6 +116,13 @@ config UPROBES
> >             managed by the kernel and kept transparent to the probed
> >             application. )
> >
> > +config HAVE_128BIT_ACCESS
> > +       def_bool ARM64
> 
> I think it's better to select this symbol from arch/arm64/Kconfig instead.
> Else this file has to be modified each and every time an architecture
> adds support for 128-bit, causing conflicts.

Shure, thanks.

Yury
 
> > +       help
> > +         Architectures having 128-bit access require corresponding APIs,
> > +         like reado() and writeo(), which stands for reading and writing
> > +         the octet of bytes at once.
> > +
> >  config HAVE_64BIT_ALIGNED_ACCESS
> >         def_bool 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
> >         help
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds