Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190614063341.1672-1-fancer.lancer@gmail.com>
 <20190620174002.tgayzon7dc5d57fh@pburton-laptop> <alpine.LFD.2.21.1906201851580.21654@eddie.linux-mips.org>
In-Reply-To: <alpine.LFD.2.21.1906201851580.21654@eddie.linux-mips.org>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Fri, 21 Jun 2019 11:25:47 +0200
Message-ID: <CAK8P3a28Dp3UygNyomDPDxDmCmey37VS7TJkmDogaKUGZMF2mw@mail.gmail.com>
Subject: Re: [PATCH] mips: Remove q-accessors from non-64bit platforms
To:     "Maciej W. Rozycki" <macro@linux-mips.org>
Cc:     Paul Burton <paul.burton@mips.com>,
        Serge Semin <fancer.lancer@gmail.com>,
        Ralf Baechle <ralf@linux-mips.org>,
        James Hogan <jhogan@kernel.org>,
        Serge Semin <Sergey.Semin@t-platforms.ru>,
        "Vadim V . Vlasov" <vadim.vlasov@t-platforms.ru>,
        "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jun 20, 2019 at 8:19 PM Maciej W. Rozycki <macro@linux-mips.org> wrote:
>
> On Thu, 20 Jun 2019, Paul Burton wrote:
>
> > So this seems pretty reasonable. Build testing all our defconfigs only
> > showed up one issue for decstation_defconfig & decstation_r4k_defconfig:
> >
> >   drivers/net/fddi/defza.c: In function 'fza_reads':
> >   drivers/net/fddi/defza.c:88:17: error: implicit declaration of
> >     function 'readq_relaxed'; did you mean 'readw_relaxed'?
> >     [-Werror=implicit-function-declaration]
> >    #define readq_u readq_relaxed
> >                    ^~~~~~~~~~~~~
> >   drivers/net/fddi/defza.c:126:13: note: in expansion of macro 'readq_u'
> >       *dst++ = readq_u(src++);
> >                ^~~~~~~
> >   drivers/net/fddi/defza.c: In function 'fza_writes':
> >   drivers/net/fddi/defza.c:92:18: error: implicit declaration of
> >     function 'writeq_relaxed'; did you mean 'writel_relaxed'?
> >     [-Werror=implicit-function-declaration]
> >    #define writeq_u writeq_relaxed
> >                     ^~~~~~~~~~~~~~
> >   drivers/net/fddi/defza.c:151:4: note: in expansion of macro 'writeq_u'
> >       writeq_u(*src++, dst++);
> >       ^~~~~~~~
> >     CC      net/core/scm.o
> >   cc1: some warnings being treated as errors
> >   make[4]: *** [scripts/Makefile.build:279: drivers/net/fddi/defza.o] Error 1
> >
> > These uses of readq_relaxed & writeq_relaxed are both conditional upon
> > sizeof(unsigned long) == 8, ie. upon CONFIG_64BIT=y so they're not going
> > to present a runtime issue but we need to provide some implementation of
> > the *q accessors to keep the compiler happy.
> >
> > I see a few options:
> >
> > 1) We could just have defza.c include <io-64-nonatomic-lo-hi.h> to get
> >    the appropriate declarations, which should then get optimized away by
> >    the compiler anyway & never actually be used.
>
>  This, definitely.

The compiler should generally not be allowed to combine two adjacent
readl_relaxed() back into a 64-bit load. Only __raw_readl() can be
combined or split up. If the mips version of the *_relaxed() accessors
allows the compiler to do this, I would consider that a bug.

> > 2) We could have defza.h #define its readq_u & writeq_u macros
> >    differently for CONFIG_32BIT=y kernels, perhaps using
> >    __compiletime_error to catch any bogus use of them.
> >
> > 3) We could do the same in a generic header, though if nobody else has
> >    needed it so far & this is the only place we need it then maybe it's
> >    not worth it.
> >
> > So I'm thinking option 2 might be best, as below. Having said that I
> > don't mind option 1 either - it's simple. Maciej do you have any
> > preference?
>
>  The use of 64-bit operations to access option's packet memory, which is
> true SRAM, i.e. no side effects, is to improve throughput only and there's
> no need for atomicity here nor also any kind of barriers, except at the
> conclusion.  Splitting 64-bit accesses into 32-bit halves in software
> would not be a functional error here.

The other property of packet memory and similar things is that you
basically want memcpy()-behavior with no byteswaps. This is one
of the few cases in which __raw_readq() is actually the right accessor
in (mostly) portable code.

       Arnd