From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74EC0C43613 for ; Fri, 21 Jun 2019 10:09:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55324208CA for ; Fri, 21 Jun 2019 10:09:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726622AbfFUKJG (ORCPT ); Fri, 21 Jun 2019 06:09:06 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:56132 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726759AbfFUKJG (ORCPT ); Fri, 21 Jun 2019 06:09:06 -0400 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23994550AbfFUKJDD0AoN (ORCPT + 1 other); Fri, 21 Jun 2019 12:09:03 +0200 Date: Fri, 21 Jun 2019 11:09:03 +0100 (BST) From: "Maciej W. Rozycki" To: Arnd Bergmann cc: Paul Burton , Serge Semin , Ralf Baechle , James Hogan , Serge Semin , "Vadim V . Vlasov" , "linux-mips@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mips: Remove q-accessors from non-64bit platforms In-Reply-To: Message-ID: References: <20190614063341.1672-1-fancer.lancer@gmail.com> <20190620174002.tgayzon7dc5d57fh@pburton-laptop> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Fri, 21 Jun 2019, Arnd Bergmann wrote: > > 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. Correct, but we're missing an `__raw_readq_relaxed', etc. interface and having additional barriers applied on every access would hit performance very badly; in fact even the barriers `*_relaxed' accessors imply would best be removed in this use (which is why defza.c uses `readw_o' vs `readw_u', etc. internally), but after all the struggles over the years for weakly ordered internal APIs x86 people are so averse to I'm not sure if I want to start another one. We can get away with `readq_relaxed' in this use though as all the systems this device can be used with are little-endian as is TURBOchannel, so no byte-swapping will ever actually occur. Maciej