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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A3F14C6FD18 for ; Tue, 28 Mar 2023 15:01:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+405XRifbDXbUDCOnpUT7jVtXYUqLKoSg8uknPepGTE=; b=xJu0pwiWP9f4VC +ePdaZ7dJ/xCT0Irm68YYLhAbnVhGBQNJexFKhMx1vspgZ1Sw0IpP1GIca+mHOtIqLFqzEGz1x5/D sMhiOJ246qDjU1yp5OInXPJHxEwCpRh771hb6UG2IAqLdLIOFXefL+ejx4jKgJoMG3dqDzKBP0hHz S8rVf+rhUxNP5rjsLwBnJJGB8AjyFds0wrjxwgSQjXFNxHpWhNmtbqNj/rP2GZEgwuSOs5B8oMY0w BUw0AmfPXAodzuOfZJ5QLHbtA7IceBGnZ82PZBxwN5El8NAkI4z8G6ZQK9TyquZYyy1eROufjA+6C EIYcEz/PQgk/3h/L9fNQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1phAoa-00ErYh-1q; Tue, 28 Mar 2023 15:00:48 +0000 Received: from fudo.makrotopia.org ([2a07:2ec0:3002::71]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1phAoW-00ErWr-1d; Tue, 28 Mar 2023 15:00:46 +0000 Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.96) (envelope-from ) id 1phAoM-0008Nx-1D; Tue, 28 Mar 2023 17:00:34 +0200 Date: Tue, 28 Mar 2023 16:00:30 +0100 From: Daniel Golle To: Vladimir Oltean Cc: Andrew Lunn , netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Florian Fainelli , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , Sean Wang , Landen Chao , DENG Qingfang , Philipp Zabel , Sam Shih , Lorenzo Bianconi , John Crispin , Felix Fietkau Subject: Re: [RFC PATCH net-next 2/2] net: dsa: mt7530: introduce MMIO driver for MT7988 SoC Message-ID: References: <20230328141628.ahteqtqniey45wb6@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230328141628.ahteqtqniey45wb6@skbuf> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230328_080044_567535_B3806126 X-CRM114-Status: GOOD ( 18.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Mar 28, 2023 at 05:16:28PM +0300, Vladimir Oltean wrote: > On Tue, Mar 28, 2023 at 02:08:18PM +0100, Daniel Golle wrote: > > I agree that using regmap would be better and I have evaluated that > > approach as well. As regmap doesn't allow lock-skipping and mt7530.c is > > much more complex than xrs700x in the way indirect access to its MDIO bus > > and interrupts work, using regmap accessors for everything would not be > > trivial. > > > > So here we can of course use regmap_read_poll_timeout and a bunch of > > readmap_write operations. However, each of them will individually acquire > > and release the mdio bus mutex while the current code acquires the lock > > at the top of the function and then uses unlocked operations. > > regmap currently doesn't offer any way to skip the locking and/or perform > > locking manually. regmap_read, regmap_write, regmap_update_bits, ... always > > acquire and release the lock on each operation. > > What does struct regmap_config :: disable_locking do? I thought I can't use that on a per-operation base because the instance of struct regmap_config itself isn't protected by any lock and hence setting disable_locking=false before calling one of the accessor functions may affect also other congruent calls to the accessors which will then ignore locking and screw things up. Please correct me if I'm wrong there. Yet another way I thought about now could also be to have two regmap instances, one for locked and one for unlocked accessed to the same regmap_bus. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel