From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=193.142.43.55 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792481560; b=rdjJt8Ci14R3talByDuvWoMt0s6J3L2S2bRU71ix31SXIbJSZIqJXPbhTKWIGWzlVvDY nuxyGh5Kcf0knBE0TpGxvIOSjudYQxdjs32DQadXhm4isGtUD6u3S1G4SqOS2Mi0wYVMS De5QJQzdtSo6Ad0Ujj0CUTvROUsEn88fLL17B3Tw2dQQocSv7B4dKeF92msketysfor2h 18YKgnrkaEMl9cAITa0iEZkocfoZk2NCaJV83az4zLuKAm3e9Vyu2KbyxAXaW6/qdPqSQ ixZAlHcWmiSDKQvkBexu2a/wKgQOfIooNmqFnnqQ5WvJ75+k7LVeC/swbx0khvzQ/Bw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792481560; h=DMARC-Filter:Date:DKIM-Signature:DKIM-Signature:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To; bh=AbbG2Q6j4Hecrtu/PulD9TnwIM8oYREi3XENRG9e+T0=; b=ZosLiAXXyDYkzo9wiJdcfTE0//cvQNbAG7bzY8DXDto4sgBaei8r4KX41V2lZiyrGIww 1U2U1Xi0VZDfXbEehK63pEGp95Qd4PLXDFrSWhuZkq9KNeOKgNR3r0lXXSISLkr+G45ST gnudPoGAan6P7RN7Jc6+IdPYW473EqQPJuTGZTlUO1B9WQuBRKPD0sYsF7IEwBmcz8nrv 5G1AYG/7qlvmtc7ttUUqpTe5RQdFmJhXFisy6mZpkMjPyrl76gFqY/iMcbGSCxADMtOe3 WGoNJzHA7eI/sFZ/k58Ha7MyNdU/6pdLDh53J+jki1KXiyGZ5yBtrAvRyVpD+Bw8iJg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=K477aKgm; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=CY4xOlG9; arc=none smtp.remote-ip=193.142.43.55 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB092606A31D; Tue, 20 Oct 2026 07:32:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org DB092606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=K477aKgm; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=CY4xOlG9 Date: Tue, 20 Oct 2026 09:32:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1792481557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AbbG2Q6j4Hecrtu/PulD9TnwIM8oYREi3XENRG9e+T0=; b=K477aKgmkz+L+RRd+uucEpbLJ0f0xKJRbJMfRt+6Ovxjrea0w0kLPKBE5pAcVCIEDbo1l5 mT0KYpEsopt8ZkoUShMmn45KL4YIHT3PvAwNfUPHN73uzIG1rdp4RQlRpVNduOaSunwJ1I fFI6AZFYjFCqqDkshKZ1oSh6lyYxhQjWWrNKyyZv5s6IxcBDyREqjG6ss/H7Ouja4XWYig 3nGe9jgw5DNxc0PaBrFMUPvEEG8JbQXAUsnIQXEW40UkFvqcvoS7nhV+9dO4VdiACU7tLX 9FrRFppKhgnJvIikvN2imkbISyzdfwGDbZvSYQUBa0dC2Ff13nHAYlrzkWZ4hA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1792481557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AbbG2Q6j4Hecrtu/PulD9TnwIM8oYREi3XENRG9e+T0=; b=CY4xOlG9QFW8DCbV7CCf/a69uJonoMF1BH+tVAs9yDlMABxmZbFtFiTlS0+2B5nu9/U1+T INrARMRaDy1GEgBA== From: Sebastian Andrzej Siewior To: Ryan Brue Cc: Chen-Yu Tsai , Mark Brown , Lee Jones , Arnd Bergmann , Sean Wang , Linus Walleij , Matthias Brugger , AngeloGioacchino Del Regno , Bartosz Golaszewski , Clark Williams , Steven Rostedt , Yingjoe Chen , Chaotian Jing , Hongzhou Yang , linux-mediatek@lists.infradead.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rt-devel@lists.linux.dev, mfd@lists.linux.dev Subject: Re: [PATCH] pinctrl: mediatek: common-v1: Use a raw spinlock for the pinctrl regmap Message-ID: <20261020073236.dDVmd3BW@linutronix.de> References: <20260929-rbrue-suez-upstreaming-mtk-pinctrl-raw-regmap-v1-1-db92943f42cb@gmail.com> <20260930080609.dnK1-Uta@linutronix.de> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: On 2026-10-06 19:57:01 [-0500], Ryan Brue wrote: > Hi Chen-Yu and Sebastian, >=20 > Thanks for looking at this. >=20 > On 9/30/26 3:17 AM, Chen-Yu Tsai wrote: > > The syscon node is the provider of the regmap. You need to fix it there, > > not duplicate it in the consumer. >=20 > Unless I'm misunderstanding, no driver binds to that node, so its regmap > comes from the generic syscon code, and changing it there would affect ev= ery > syscon. Lee, Arnd, Mark, would that be acceptable? >=20 > These are the options I see. Please let me know if there's a better one: >=20 > - Do what Sebastian suggested and make syscon use a raw spinlock, except > when the node has a clock, since regmap-mmio calls clk_enable() under the > lock. Off PREEMPT_RT, nothing changes. On RT the lock would no longer be > preemptible for most syscons, including across bulk writes. Most syscon > users that do bulk writes only write a few registers, but enabling the > Amlogic G12A PCIe PLL writes a sequence with 40 us of udelay() under the > lock. bulk writes could be a concern. The 40us delay is within the lock acquired? If so, could this be done without the lock? I assume this is part of the init sequence so nothing should use the HW so the writes should not be interrupted by other writes to the device. > - Have the pinctrl ioremap() the node a second time alongside syscon's > mapping and read the input register (DIN) with readl(). That read is the > only access the EINT code makes in raw context. This would go around the > syscon, and it requires that DIN never be written in a multi-step sequenc= e, > which is currently the case. So it would be safe for now=E2=80=A6 > I'd like to know the best approach before sending out a v2. >=20 > Best regards, > Ryan Brue Sebastian