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 42C0554652 for ; Fri, 19 Jun 2026 17:23:40 +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=1781889821; cv=none; b=bdy1/xpyMLBjDILT26vTU8HECaSCTa9OXukH2e2ugjZxLfJK7C4fsNslmD5F4YeiQQJAS17Cp8LYc7PD/LLW32ZrhDXxCqhjC3cO713HsEDfkhKugpm3kthjIfZ4XZ2XTHFntbCsc59tZ7uF4PCK/YACULVr9/2SxAzvS0O6N9g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781889821; c=relaxed/simple; bh=Bkdqvi3Fi/Cp6BwSGO76FBXc58Z16/vknKLt5aKdWqY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eal+Tnwb+XnMhXSwhi0AXa5QmCqjIpsyXBKtMX/q9HQK+Hjx9En9s40+Cd8THOYuZInKN9wcI9Bc+IdSHe/86CHveF+mHaBbqmWlkIT63jHchmliw5QvVqgenWR10AtaayDSpWni3H+kr4qGrrmsPxndhUz1Ug+gSEp6QzdkmLs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lgaY8omD; 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="lgaY8omD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A287C1F000E9; Fri, 19 Jun 2026 17:23:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781889819; bh=sB1AHEiq7+4SoJwqCR6IM6vvoDUns6b1OwbViX7QO6o=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=lgaY8omDEmU59uoU3UB+TJCE3AB+esRSPdW33G3eEZVJ5Nu6e0lZe+yBqNNh0pgUy HVoKx3NNFWeE4DM3Vu1njTDop5pVfSfMUbfaSHNrjXc+yf0G3ad1CNbDF6jY40pOQS fZ+2kQAhHSbtGZe+S4TSzoTnpy4s7sMuj2bn0oz4CQk5LaCeqJUN9chxlkw2bLnstY b11QLeoIcyP/fIwj9K+jj6WishcmdER2bq/aX1qCKBbZLM/IK9BBlug39/BP+YF6Vr C/g9MtJ2KvdgQ0WUkBzSvo7XcZ47VgY4vXwik3jmLCEEZoXw736eMHBjy2uKMMhEdD UsIU0UPdwUICA== Message-ID: <87032e28-9527-4513-a5ef-38afe0006480@kernel.org> Date: Fri, 19 Jun 2026 18:23:37 +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 , linusw@kernel.org Cc: johan+linaro@kernel.org, krzk@kernel.org, linux-kernel@vger.kernel.org, peda@axentia.se, srini@kernel.org References: <20260506123350.310564-1-andrea.tomassetti@sipearl.com> Content-Language: en-US From: Srinivas Kandagatla In-Reply-To: <20260506123350.310564-1-andrea.tomassetti@sipearl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit "mux: gpio-mux: add support for multiple mux controls" would be more reflective of what is done in the patch. On 5/6/26 1:33 PM, Andrea Tomassetti wrote: > Some gpio multiplexers, like TMUX1209, offer differential 4:1 > or dual 4:1 single-ended channels. No binding changes are needed > because the DT binding already supports #mux-control-cells > with values 0 and 1. So, similarly to what was already done by the > adg792a driver, the gpio-mux driver has to take into account I guess adg792a does not have same issue(described below) as gpio mux > the #mux-control-cells property and allocate as many controllers as > advised by it.> drivers/mux/gpio.c | 24 +++++++++++++++++++----- > 1 file changed, 19 insertions(+), 5 deletions(-) > > diff --git a/drivers/mux/gpio.c b/drivers/mux/gpio.c > index 4cc3202c58f3..ab3ed5247d2c 100644 > --- a/drivers/mux/gpio.c > +++ b/drivers/mux/gpio.c > @@ -52,12 +52,23 @@ static int mux_gpio_probe(struct platform_device *pdev) > int pins; > s32 idle_state; > int ret; > + u32 cells; > + int i; > > pins = gpiod_count(dev, "mux"); > if (pins < 0) > return pins; > > - mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio)); > + ret = device_property_read_u32(dev, "#mux-control-cells", &cells); > + if (ret < 0) > + cells = 0; > + > + if (cells >= 2) { This code snippet is duplicated once again, may its time for this to go to as helper function, either in core or somewhere common. > + dev_err(dev, "invalid control-cells %u, must be 0 or 1\n", cells); mux-control-cells would give useful message to user rather than just control-cells. > + return -EINVAL; > + } > + > + 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. > if (IS_ERR(mux_chip)) > return PTR_ERR(mux_chip); > > @@ -69,7 +80,9 @@ static int mux_gpio_probe(struct platform_device *pdev) > return dev_err_probe(dev, PTR_ERR(mux_gpio->gpios), > "failed to get gpios\n"); > WARN_ON(pins != mux_gpio->gpios->ndescs); > - mux_chip->mux->states = BIT(pins); > + > + for (i = 0; i < mux_chip->controllers; ++i) > + mux_chip->mux[i].states = BIT(pins); > > ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state); > if (ret >= 0 && idle_state != MUX_IDLE_AS_IS) { > @@ -78,7 +91,8 @@ static int mux_gpio_probe(struct platform_device *pdev) > return -EINVAL; > } > > - mux_chip->mux->idle_state = idle_state; > + for (i = 0; i < mux_chip->controllers; ++i) > + mux_chip->mux[i].idle_state = idle_state; > } >.