Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp856629rwd; Sat, 20 May 2023 07:56:10 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6CDBD4rN5he3tH77nXE3mj2cDYZ5UyG645G023EZLOnVrOx3z5uh2x9bXOpAwMfZ2pIyCU X-Received: by 2002:a05:6a20:7d85:b0:104:950f:fe15 with SMTP id v5-20020a056a207d8500b00104950ffe15mr6573190pzj.55.1684594569953; Sat, 20 May 2023 07:56:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684594569; cv=none; d=google.com; s=arc-20160816; b=R5EBiSvegB1bs0wBFp+hqPDpCvSLiCy5evAezg9vhUa7qbOg6fhXL6Eqauw3GjmwS1 pDwdjXLO5QXO0ZDcuTnfcv6HGxhkRrpMccjxeZGz+3COVtgs8JzCOn5jpcXjGVZeD8N4 ifBQvr/O9pO3VKUrEddJmzvMEMhqAouZCEw8sXjbCAEfVrID5FKLePdCg0UAIQWLK/8C LJATUU8g1fW+0yC/ysVo3+xLGAGuSqBQi9Yi8x5ujSj4pa9e/Fr93mzHtWirJsLqGmio LxJD1rs9fuK7abXJrg7ejLQfzPBce2L/o5VKH73Chm7o23BYyRU6gw2S7aB/kRR8AS3l mdLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=Xqo//Z3YSCxLxplwihirUOSAKhHl2vinR9Z+B1dgNog=; b=ne+WVPs6vhdDIclGKWhA8YqQNxQPrG8oT64JN4VQTReYEWtR1PxbSzRuBSVZH10QlP o/yKls1EiIzv05iE9nH590RlDxctte3ZnP1mX6wkAM4nfBfHR9koKelxwM7cMeNslLlY SLRNuan80TcFJEqiTo8ueHx1lvbn1+yK/C2pMqPQcug7nAXj2VuY7mfOmJKK91FH8/qn DihoRirvIICS9bloKm4K0zALBGic+gsRijjGaDmDOm+thkw9UZMiAsf18cJ57ZYgrHDa DPqPCP2OZi67A30zXJRNhp9+Jf3ealvFJqQsFGtZuFcr/LLDMqNlogGvhwnfdzXAfuWT yfbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i2-20020a633c42000000b00535a71508f3si1617331pgn.77.2023.05.20.07.55.52; Sat, 20 May 2023 07:56:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231281AbjETOpx (ORCPT + 99 others); Sat, 20 May 2023 10:45:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229464AbjETOpv (ORCPT ); Sat, 20 May 2023 10:45:51 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2B221109; Sat, 20 May 2023 07:45:49 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 2991992009D; Sat, 20 May 2023 16:45:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 1CA6092009B; Sat, 20 May 2023 15:45:47 +0100 (BST) Date: Sat, 20 May 2023 15:45:47 +0100 (BST) From: "Maciej W. Rozycki" To: Arnd Bergmann cc: Jiaxun Yang , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Bogendoerfer , Linux-Arch , Baoquan He , Huacai Chen Subject: Re: [PATCH v4] mips: add including In-Reply-To: Message-ID: References: <20230519195135.79600-1-jiaxun.yang@flygoat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 May 2023, Arnd Bergmann wrote: > On most other architectures, we also don't define __raw_readq() > and __raw_writeq() on 32-bit because they lose the atomicity that > might be required for FIFO accesses, but the existing MIPS version > has them, so changing those should be a separate patch after it > can be shown to not break anything. With MIPS we have: if (sizeof(type) != sizeof(u64) || sizeof(u64) == sizeof(long)) \ *__mem = __val; \ else if (cpu_has_64bits) { \ unsigned long __flags; \ type __tmp; \ \ if (irq) \ local_irq_save(__flags); \ __asm__ __volatile__( \ ".set push" "\t\t# __writeq""\n\t" \ ".set arch=r4000" "\n\t" \ "dsll32 %L0, %L0, 0" "\n\t" \ "dsrl32 %L0, %L0, 0" "\n\t" \ "dsll32 %M0, %M0, 0" "\n\t" \ "or %L0, %L0, %M0" "\n\t" \ "sd %L0, %2" "\n\t" \ ".set pop" "\n" \ : "=r" (__tmp) \ : "0" (__val), "m" (*__mem)); \ if (irq) \ local_irq_restore(__flags); \ } else \ BUG(); \ etc. so we don't actually lose atomicity, because we always use 64-bit operations (SD above, store-doubleword) and we BUG if they are not there (i.e. with 32-bit hardware; not a build-time check as in principle the same 32-bit kernel image ought to run just fine both on 32-bit and 64-bit hardware). A few MIPS platforms do use them, e.g. SB1250, which requires 64-bit unswapped accesses to SoC registers. Maciej