From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 789DB367B6F for ; Fri, 3 Jul 2026 08:10:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783066257; cv=none; b=dIiPsDNPgGoLU+BXLI+BOsemrUVajNU894JRnkHpDIwSvI32IRKOLOW7SfMeq7Vdt5Fo5PfMN0Exr5Btnt7DyaUO+nPr207NZYMBxpp1d1Xg3ErlXsyzU0mOBaEBcuSpcBwDbDklxMLmRp58++F/e0HnQXSH6s9YTwSBr1eeHOA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783066257; c=relaxed/simple; bh=KniKkmYLQfq0uFP9EAIyouGeNxE7Ujr/B6TkphT/MyY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NiOn5valcBIUaguN4IHC9sqmdl0irjeGCEq8dz4qD1fYy7ntoH5FocNXQ7iBEcEdRJHWAgJs9se58n+dDQWjeELF6GacA7NDxATU82OhpU/4BjSZbG5r3lOGuP9XiM/0w25RcJGcCOyx1VwbPFqZqQHJH68a+OBHneTPht7Pmkc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kYmIIAuO; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kYmIIAuO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1EFCE1F00A3D; Fri, 3 Jul 2026 08:10:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783066256; bh=E9FluBv696RCg5RYI47LuvfTbzNOTJxeeYZ7D8eOx40=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=kYmIIAuOP6pR8+4jAwU5W8JX3198z3x0mPcVS6geLPVk7J8uDMQ0ZkeL1SrCQGN5w h0rR8u+ibvipIxg7BJvLpSEti0lm75gu1qDGj7slAGCTh3S9Zr6j1MH8veyCrV7ZKI H2fb2yAm4rTM8ybx6mwoRz2NbwMinTHKn+AH5r5fKqlTh+FdECS+Tg3A9p9PwcFFfD LwFWg4YVEwgXzSzrICHDurxjepYA2hzXGfXEe0hnvmVZjNkOXZxsrw7Fy+n7g3wowA 0rH6w++LD3NxJM4k3tIKNarQBnScqrjCBWpx8Pk8afUzLW5cSt04hjxlyb92ajYZcW 7OORYCB2Ntgcw== Message-ID: Date: Fri, 3 Jul 2026 09:10:53 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux To: Andrea Tomassetti , Srinivas Kandagatla , "linusw@kernel.org" Cc: "johan+linaro@kernel.org" , "krzk@kernel.org" , "linux-kernel@vger.kernel.org" , "peda@axentia.se" References: <20260506123350.310564-1-andrea.tomassetti@sipearl.com> <87032e28-9527-4513-a5ef-38afe0006480@kernel.org> <57cd1b9d-2ee4-48b7-873a-c8baa162c3ab@sipearl.com> Content-Language: en-US From: Srinivas Kandagatla In-Reply-To: <57cd1b9d-2ee4-48b7-873a-c8baa162c3ab@sipearl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/30/26 4:08 PM, Andrea Tomassetti wrote: >>> + >>> + mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio)); >> We are now allocating n mux_controls, however mux_gpio_set is not >> protected against multiple controllers accessing the same gpio resource. >> >> > This is a great point. I see two different type of "race conditions" here: > 1. serialize accesses in mux_gpio_set serializing is not the major issue. The end result is. > 2. "logical race condition" due to how the upper locking mechanism is > handled by mux/core.c > > The first issue can be easily solved by adding a mutex inside struct mux_gpio > and use it to serialize accesses in mux_gpio_set. > > OTOH, the second issue is more nasty and depends on how the upper locking > mechanism is handled by mux/core.c. Please, correct me if I'm wrong, but to me > it looks like that the core's locking model assumes each mux_control is an > independently lockable resource. While this is generally true, it doesn't apply > in the case when there's only one controller that jointly controls two or more > gpio-muxes. Like in this case. Yes, we have locking per mux control for a reason, Mux resources are protected in that control context to make sure the mux is always held in requested state. Now with this patch we are using shared resource for multiple mux, that means an underlying resource can be updated by another mux control without of each other knowing about it. Two questions. 1. Why a single resource is split into different mux controls? (sorry In case I missed previous discussions) 2. Does the hardware allow you to set two different values for the same resource, respecting both values at any given time. If its gpio, then am not sure it does. --srini > > So, adding a mutex at gpio-mux level would fix the race condition of two > consumers changing the state at the same time (issue 1). But, to my > understanding, it won't fix issue 2: mutual exclusion on the write makes each > write atomic, but consumer A's selection can still be immediately hijacked by > consumer B's, leaving A believing it is reading what it just set when it's > actually reading whatever B last selected. This happens because the lock used in > mux/core.c is allocated _per controller_ and not _per chip_. Do you agree with > my analysis? > > If you agree, I can fix issue 1 but I'd lean towards treating issue 2 as out of > scope for this patch. Let me know if you see it differently. > > Br,