Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp360789ybg; Wed, 10 Jun 2020 02:46:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcw8oQPCxjKF2zXwy4IoxNOxinKxiiuYtkLuiiC4cwbStQAu01sagJh8I8YQYhKNtx3VNE X-Received: by 2002:aa7:d985:: with SMTP id u5mr1821856eds.160.1591782383632; Wed, 10 Jun 2020 02:46:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591782383; cv=none; d=google.com; s=arc-20160816; b=LO7qnh/czW7SpVNLJ+dzgw/c3koFyCMl/8uFj+t+d0tuHETXifgz0R2+a6YiMCyNiQ A9iGclKHYqegf7hTN8jxgUPviMSNjlmxAqGjrODC8kQzqHwbCkFBB8KE45kd4gYXi0km lXLo3wXPuYIwRnbOzL3OALzXg466BQqd4IohucVc2AyTB7Nix1HGJuQkbliaAZ7nmhSw R6OY7RqidWhXeCrFbX2w6UpjlSspO9qbToiXnYpQfpWp54gntf0fZv/y1MdgaTvlUmFY VKeXSQ2WOZif8c4c57TrjG36gFm3p3ljU1SQKmYGk9ltoaDptqHvOGbyBxW59CZFkgjE QQCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=EWXYJnhDYgQRWjI3arCWKDlNqmb6U4nqSInYksfLlh0=; b=vyqvFY/3HXk/CkFlPGr920I7VByASks9z+Q5eUnRx1rTdyU9P4QISJEQ73lQFLmKIi dOy8FDpFTjiY/BORSuX++sjpqDCzDlhAyrkebZk0K1B3AeXJJ0jNTfGu6kR0hG4LRgBR 6Bn2tcKMW5PZoisfnI7QRPZCR7q2BEKif3UB638WxpeAK6Z6Q45EvkbWozNm3QKUWGY6 mRcjOjkN/bsPYmznNOJul0yJlDLoKG4BCOhh9bhaxhqsM4XYyZP3j/xkSnU+QvcXqe2Q BcSW/21cQhbTdAzb5d3cPGl32lvTwFTIhPTZuYO1r5hhJDKt6vN98f2T+DKXHQ/K3OXe 8ZoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dt2si16164280ejc.596.2020.06.10.02.46.01; Wed, 10 Jun 2020 02:46:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727893AbgFJJoL (ORCPT + 99 others); Wed, 10 Jun 2020 05:44:11 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:58273 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727007AbgFJJoK (ORCPT ); Wed, 10 Jun 2020 05:44:10 -0400 Received: from mail-qk1-f179.google.com ([209.85.222.179]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1N9MlI-1iomFg13Wm-015KAf; Wed, 10 Jun 2020 11:44:08 +0200 Received: by mail-qk1-f179.google.com with SMTP id 205so1397453qkg.3; Wed, 10 Jun 2020 02:44:07 -0700 (PDT) X-Gm-Message-State: AOAM533JwTxCxmVxd+bGyZZ8LWwnIEX2fjF6cxPyHnlMYfZ7DJmTQ3DR xnEMPtcuSkGXp8LYWrvmMMD07CvIN6KnPLv+2p4= X-Received: by 2002:a37:9401:: with SMTP id w1mr2110620qkd.286.1591782246851; Wed, 10 Jun 2020 02:44:06 -0700 (PDT) MIME-Version: 1.0 References: <20191014061617.10296-2-daniel@0x0f.com> <20200610090421.3428945-3-daniel@0x0f.com> In-Reply-To: <20200610090421.3428945-3-daniel@0x0f.com> From: Arnd Bergmann Date: Wed, 10 Jun 2020 11:43:50 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/5] ARM: mstar: Add machine for MStar/Sigmastar infinity/mercury family ARMv7 SoCs To: Daniel Palmer Cc: k@japko.eu, "Bird, Timothy" , DTML , Daniel Palmer , Rob Herring , Russell King , Sam Ravnborg , Linus Walleij , Heiko Stuebner , Maxime Ripard , Lubomir Rintel , Stephan Gerhold , Mark Brown , allen , Mauro Carvalho Chehab , "David S. Miller" , Jonathan Corbet , Greg Kroah-Hartman , Mike Rapoport , Andrew Morton , Doug Anderson , Benjamin Gaignard , Gregory Fong , Bartosz Golaszewski , Masahiro Yamada , Nathan Chancellor , Nick Desaulniers , Christian Lamparter , Nathan Huckleberry , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Ard Biesheuvel , Marc Zyngier , Linux ARM , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:lU2b0x8yqs9dY8JdqQi624zU2A3u64WZZdXSPs5TO9KumojjZXv Hwug4fi66Y2UDqmvotkCzdDba5/EgMr0wnhdT4++Tnch5W1yI+7AwapjHEPBnFYcjtn0+1c OaD10KUhUWJl3mqItC2yGx5j9Lnh5y6RG1p113v4632WPa3PNcQpVJrr/3Av9VCBvhEV8Z4 AnGsrnwLNADH2arIwVGzg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:W/XwwlzMmJQ=:EU5wKH9C1dYiHYsWryDZQN weK1a0hsWNDmko5Rc//g1iCuwhgmPCZHLkiQZ7WzU19tEB6l6SMYPYcs1Emr6CCCriMqj0EuR waXcV6JsMRn8cTatuiN2/QWjGCzAHEZOjx8rnU1F54R4ZkdL78EUHymkVUdbL+7SyQtWCPe4G xwrlPIGE6MlJVDSuaDw97pfJ4IT9g8+OkULxhsq6VIRNl10bWo+zeogx+ELs4Nmv0c/GRYnRR geU3XvLuY7HPsx/TYccRg8nkim5p9IfH/MUToB3eNCBHkxPaG7ECEumh9LWLCIJEmLPASkXZH bwywkUlO+NfduFmMDoMuR7lgrHu9qijJICisvQGUQxvad/z0J6xTukh3oFcIVQvXLxnQ0WQYy KTWk3uTAZ6QzXffQS5gKidM4u8RGQkX8XrE5ej5cjkj1FvV17ZgSIWhiZAMePZmtW2XsqyzV9 Pupd0+TEHZqFUasRhzWYZ8+JQamaTjGqfvfzTTuQRmFQr5Et2gLFkI3e4iPmAXeUziPJOPllo JyRh0VumjCY9rlvGWsfpTNhBn7PW2SAei1iB+rv46ncxHiH+YC6S4Z/YwWxpQo7AJLXzhMewS ClVcH5g/OSKxZZL2OPisBkPLTuVasifNNDkLS2z/hYVJp/xw1G+RF9HcNi2BGZ31zT4IUy4T0 W95oqFsDBMYKsiBS8Ngctzz8BwG2Uh8jOob/VkQitSOnHzDeBgJnqILsSGgoF/IMEgPVKwA1h SBN11hStpdDhZr0qaFqBaO8u8OYvrWLvdJuMTItSLFzk/JJHKB/b5+38Kjc6cA3rFJhVakBRU /MjpiG3Bto4LCNA10NSLDFzyTYjfjsUir8qALva+1HM2CZVVaw= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 10, 2020 at 11:08 AM Daniel Palmer wrote: > +/* > + * This may need locking to deal with situations where an interrupt > + * happens while we are in here and mb() gets called by the interrupt handler. > + */ I would suspect that you don't need locking here, and locking would likely make it worse. From what I can tell, an interrupt happening anywhere inside of mstarv7_mb() would still result in the function completing (as miu_status still has the MSTARV7_L3BRIDGE_STATUS_DONE bit set) and nothing that could happen inside the irq would make the barrier weaker, only stronger. > +static void mstarv7_mb(void) > +{ > + /* toggle the flush miu pipe fire bit */ > + writel_relaxed(0, miu_flush); > + writel_relaxed(MSTARV7_L3BRIDGE_FLUSH_TRIGGER, miu_flush); > + while (!(readl_relaxed(miu_status) & MSTARV7_L3BRIDGE_STATUS_DONE)) { > + /* wait for flush to complete */ > + } > +} This is a heavy memory barrier indeed. The use of _relaxed() accessors is normally a bad idea and should be avoided, but this is one of the places where it is necessary because the normal writel()/readl() would recurse into arm_heavy_barrier(). Can you add a comment explaining this for the next reviewer? > +static void __init mstarv7_barriers_init(void) > +{ > + miu_flush = ioremap(MSTARV7_L3BRIDGE_FLUSH, sizeof(*miu_flush)); > + miu_status = ioremap(MSTARV7_L3BRIDGE_STATUS, sizeof(*miu_status)); > + soc_mb = mstarv7_mb; > +} Hardcoding physical addresses is generally considered bad style, even if you know the address in advance. Can you change this to get the address of the L3BRIDGE from DT instead and just hardcode the offsets? Note that they are in the same physical page, so you only need a single of_iomap(). > +static void __init mstarv7_init(void) > +{ > + mstarv7_barriers_init(); > +} I think you can fold this into a single function. Arnd