Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp710901ybz; Wed, 15 Apr 2020 17:15:20 -0700 (PDT) X-Google-Smtp-Source: APiQypJWtJ2lS70g9j0p2+Z51JRrr6Si2sWbmAmcieQ0KnRMcGoggxEPzl4T0zA76Ke8xaV5V+xe X-Received: by 2002:aa7:dcc3:: with SMTP id w3mr12344485edu.231.1586996119877; Wed, 15 Apr 2020 17:15:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586996119; cv=none; d=google.com; s=arc-20160816; b=YId0JKS2G26q+8Ksy+Ynfb2YyHHm5QxiongN0LYGfvc5enjJutGgDtETQnTwFsYBcZ FQzkFu9li3lwq1F8AKU1WsnEe3wnLa3dEUqUQ/oZIVVGpGsHkRidaslFgnRv/r2za4T+ 3LJyO4DOQ1Y8fXOp+rUOkHyE1eY6xErc25CV+/FzDXrdYTaqhYnjcgLxHeJF3/mjdrtB toyTT2wQOtrO5YM51mox+TGRxi1Ey4KQfy4yTwGcpSjGXauIA+1FyEfPOZt4I9CPAUS6 oX9B75vNFtYZn96CnMRTbOxrX5RmX66drZ62fNBJX0Bz7bdhDpStrMwUwqJIgg1+qsZQ 6sfg== 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=Wv6LKdZQYCgQDBDRQioFP30rJAaB0zrmL7jOFhIQ7ZY=; b=HdqiClXhzBTqKbpYYkeJw0LpBWq0vCdoQVL1i+uRr8Ye1RaFCtRhYsZ3QcdIo04vDD u3hq2ll4FUGVGiAKmAVhYo5AII0kUetl0FcrdIrLdIf2URhWB0rQhxp86DQPxbATLjJw fqFtvagEomChPPmdhL0G0gNxa3/P0904ObFxJJZyCGHKbgh2k7Ih5AuDzjzyVZDKAedX IqJaiMuTIsFe/34MKHIY/pAKJU7uARJlM9VBD11FgvBmtQP93YHpwVQNV7Gf+nWl6VwL aMrQtQGNfCZhMRUOtZJNXk2DcsolF0O5KpLRAvGr7SOIlbxnL37n5gIU6TcdPzLus9FK Fkag== 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 d8si12531031edj.16.2020.04.15.17.14.56; Wed, 15 Apr 2020 17:15:19 -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 S1414760AbgDOPg3 (ORCPT + 99 others); Wed, 15 Apr 2020 11:36:29 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:46889 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1414755AbgDOPg1 (ORCPT ); Wed, 15 Apr 2020 11:36:27 -0400 Received: from mail-qt1-f171.google.com ([209.85.160.171]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1N1Oo7-1jHTtb3PEx-012mIa for ; Wed, 15 Apr 2020 17:36:25 +0200 Received: by mail-qt1-f171.google.com with SMTP id x2so13577351qtr.0 for ; Wed, 15 Apr 2020 08:36:24 -0700 (PDT) X-Gm-Message-State: AGi0PubUrgJH+B8roOSSeQunEy5YpBii1s+9myXJUP7BXtnedS6CoUGY 0Avzwjg3fjxhCNsI9jQcFEAEWZzS7G9nwwBZExA= X-Received: by 2002:aed:20e3:: with SMTP id 90mr21209126qtb.142.1586964983698; Wed, 15 Apr 2020 08:36:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Wed, 15 Apr 2020 17:36:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 3/3] soc: sprd: Add Spreadtrum special bits updating support To: Baolin Wang Cc: Lee Jones , Mark Brown , Orson Zhai , Lyra Zhang , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:MQnvqLOoWwqTuhAeHc2QB61aLz/NzXqAPWq5pVuRAUy5+fSKJ5S MsMTXCs9DWVAOXPA5xj4V2z9QP33FytL6zYK271HtnLtnH1bNnya0vvKcLtQqUen9olsIYU iRLi2MyvRkPDt5Dcd96anlK4/wOZtkUmeB0ui00TuP5EazC1Pn/Llb1PF10PNYj5fixl5id pg/X+n594Il2zKK9gwNVw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:fbRXHR7l6S4=:4cKBIH25KCcvxXWvp7z+xD hYFi2KNrLLdqRiELpGfhaF9qQyK8G524b1MasvKsYpSUf0GLEMdzVjj6AOSF0FLJ9ZPQZYqr7 LkN5xr4TcB9szTQE3AweCXIypobUvYPE/GVgTaCV40LUUmhwfZaq/go3wqPDkiehE3R+VaoSY /HESg9O7k05nP0ifcTLjVwj5EoFjI8BiCEuzf+BeBuoUo2EvUbpP1bWtbksxSlPNa/9tswqa/ Ia3nRPyGm7bzt+BBj+9P9VEqfk4VKYwvNhEWYx60BicIRGKVHPhPHc5GrwvZC5UgiiRMI8wdB XlsoqKK1r2o9lYH9GeopBv0UKg6u4ib9HBKosDgEVXp/Mp9M9U1q0VmB+8GJfgC2di/cPxcEf pO8RL1TgElmr+J775t0i5SZwb128oZqKDSQkt0LvSMP23YaUK1g0z3aYlF1YfM56ZHqLi41Ld QRoqfLnhDsoONpTNFvH0PeL8rh+qFt5nuFM4PkJtINBoUHfqHGwIVVM5KJPhLcoOKomZwwhXY 9ZODzLNeUWfYzr/dUKsL57uKooaXWLEyiSoWBD7ZiLOhjTPrmGUBW8WtmZK+mHK1dv6ak6fe2 fjT8y7B4I6UT/Mx7yD1CXvnxtU01257KjyEJguzhkLflH7tIyJAa6HNNZp6AdrXncZuuB7nsI 7Ygbza32FAVZVhsycPpF/O/bo8o0bZR0FR2EMxfC5yrdhfC8b7sLGzBfi/Jz6FqNIWq43UK07 egJ3si3gpE2kS8eJ9n6jJHygPyYFKSkkOAQiFC9DEbhFrooaTIX3xWjxyC47rLeexY2CWboc9 9O/YVWE1RgziX9xkLpBD/M/Gqdvlm0OCeiKKd2P8bCqMTZ13CE= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 13, 2020 at 8:14 AM Baolin Wang wrote: > > The spreadtrum platform uses a special set/clear method to update > registers' bits, which can remove the race of updating the global > registers between the multiple subsystems. Thus we can register > a physical regmap bus into syscon core to support this. > > Signed-off-by: Baolin Wang I'd hope to avoid complicating the syscon driver further for this. Have you tried to use something other than syscon here to provide the regmap? > +#define SPRD_REG_SET_OFFSET 0x1000 > +#define SPRD_REG_CLR_OFFSET 0x2000 > + > +/* > + * The Spreadtrum platform defines a special set/clear method to update > + * registers' bits, which means it can write values to the register's SET > + * address (offset is 0x1000) to set bits, and write values to the register's > + * CLEAR address (offset is 0x2000) to clear bits. > + * > + * This set/clear method can help to remove the race of accessing the global > + * registers between the multiple subsystems instead of using hardware > + * spinlocks. > + */ > +static int sprd_syscon_update_bits(void *context, unsigned int reg, > + unsigned int mask, unsigned int val) > +{ > + void __iomem *base = context; > + unsigned int set, clr; > + > + set = val & mask; > + clr = ~set & mask; > + > + if (set) > + writel(set, base + reg + SPRD_REG_SET_OFFSET); > + > + if (clr) > + writel(clr, base + reg + SPRD_REG_CLR_OFFSET); > + > + return 0; > +} Regarding the implementation: Doesn't this introduce a new race between setting and clearing bits if you do both at the same time? This may not be a problem if you never do. > +static int sprd_syscon_init(void) > +{ > + syscon_register_phys_regmap_bus(&sprd_syscon_regmap); > + > + return 0; > +} > +core_initcall_sync(sprd_syscon_init); I don't think this part can be done at all: If you load the module on a generic kernel running on a random other platform, it will break as there is no check at all to ensure the platform is compatible. The same thing happens on a platform that may have multiple syscon nodes, when not all of them use the same register layout. The only sane way that I can see would be to do it based on properties of the syscon node itself. Arnd