From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C71251EDA2B for ; Mon, 16 Feb 2026 09:29:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771234162; cv=none; b=UdIzkHvn/WuNDtWrW7Yv0Sdad7DqkASO/KW0Pm3baiSXlOl0r1kI0zvTYdsSmlF5cjzYjhuMxuuQQhuCtEiXe7Hzp6/gNubX5/3sPlDwZuUPKm1reS6tvP2ghweou1LH8WqX6hw/J/7hNR9YPmYD9U8Ds6qqlthNWcJLKlhV6BA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771234162; c=relaxed/simple; bh=w+XEoEDh9P6pvfwimOIKt86v4LQn9xAIGzRD/YzWpXE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IoLQIknq8HjYqobqDQP5nPWvPHBlhwB6ITv9eS9+CbT97eybYfYlXmNzLKHZ9oOTkSixO5bt0jes4Isqjlcd/6HSj4pccLDZPuNS+VZRc40Qz3WF00egL4rklOQuobsKYySeheToSJC46HP53bRb6Wrr+GtSULgKbm6h9z7Zwbk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XNA9XTUc; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XNA9XTUc" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4837991d1e1so1898535e9.0 for ; Mon, 16 Feb 2026 01:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771234159; x=1771838959; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ogvJ3kqaNl4WpBdAZZzPnlDtG3SqRNUddgrdVVu6K+8=; b=XNA9XTUc4pPlbAk1mNsas+pKUjSEQlVEORYJHizZR5CDezYMZeEe3xpt2uDWu++cjc Oq4k/0DOL9OqS3N/Dlzb2pjim7QylscnsVDmI5b9JrnIUVxNUYIYADSF0zV+iBx1/I3o +vbGoWw6aH5D9+ogxuZJFff+SDlyS9dw2kMvIGOZ2MwF5gw4gYMulKbAuXJoNm9yJc5R bhzxq3XLnTzDHV2rM+TlUhXHlRDLdBZv8LuVcWE3gBWU4QSGVQ8zi1ptSVc2l98PNREy 8SZVp2oXX091m0IQZb6WGk+G15PWRiyF8RWNgYPKompeaYzHgc1NGctQdHyRbNewbKup m5UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771234159; x=1771838959; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ogvJ3kqaNl4WpBdAZZzPnlDtG3SqRNUddgrdVVu6K+8=; b=JdVy8MGGjyTfgieZsMVyU4ubliJgiHYKM+my/7Y9Yaiupj19LApsxfT4s++aFOAHAQ KtTya1g6qUc6cLqgpFePQH8EOjUWgRce3cu8XWZtgCrqQu4TLNAo2s2M+vqKbRpqNbLP HWSSfr+LXcZrThgeCBtSnKb+D3zj99HIL2AKozEdAWrxdzsUp8wxDlasWrH5tzaU5YuU u3XZ7FpNgsD36T/jKIFP4C0WX/G7d42CXxix7dlDT8B9xtHMbaAHCF5cZZggGDb623G2 5LIhVe2k+yujxgvsufD9uOlbufzmZ9k+2fiSui7LBZXITowSYZUQ22QtoAXst/cEIrI4 soRg== X-Forwarded-Encrypted: i=1; AJvYcCVylQchMwE2E7dpV28cCmklhSBwWm3Y5JPYPRvfTKfobThx5Ndi8lpYyOlKwyCaUXUakwofgiQFwZdtvic=@vger.kernel.org X-Gm-Message-State: AOJu0YxOZ7EhnJrgz+uz5PbbKKy8l8UXD1RKPD0KroTbFEjvaKY9VmiQ 5iWL+wc5HPF64Gm6OvBZjgEkH0nzS0xobcDMEDwctkZP+r7+LwaUgKqR X-Gm-Gg: AZuq6aI/LHTEmwgUgyZaLC34Q/TDDOYlFwAUWx9nCyrVMGqhC8oj6//YF/AZe1jz7XC 17OBZVaY5QcxL8w66QXe9nR/5/RPeQGfvqYveTyhhYwPoSdLMyguyCFnQ+B+Gi5+HWiayzca+1j y3NAcRftMJs8qQLwIv04FGSN5OszfHgyh1OTfVMyaUtNGNNLkic3DN6uA2FsHR09QWvF0AF1Fje CeJvWiJ4RQl9EkgqRKm/o40t4B5tYXcLYoHhBKtOLUCqrxNKLBWPJOYn0ktKHmhrgTMUIlH7xKr fQG1hxv8wBCoMS28p6Nlhzt6vfAYqWsosRFhsR4gLx5KO2DPW5Zmc3Q+p+F72vgMskClWdSbSQ0 dX5OcIag/rd57dHu895xzOGvr/G2e8eHuCDS8zLzx2xRTX4MH6cI3VAW4hbO+In3S93/6ECga7g p6tmawuArYxgAJpA== X-Received: by 2002:a05:600c:3b98:b0:47d:3ffa:9838 with SMTP id 5b1f17b1804b1-48370e18ff1mr144504325e9.1.1771234159012; Mon, 16 Feb 2026 01:29:19 -0800 (PST) Received: from skbuf ([2a02:2f04:d501:d900:68e2:cc27:74c:c083]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48371a3c03asm76821035e9.24.2026.02.16.01.29.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 01:29:18 -0800 (PST) Date: Mon, 16 Feb 2026 11:29:14 +0200 From: Vladimir Oltean To: Josua Mayer Cc: Geert Uytterhoeven , Marc Kleine-Budde , Vincent Mailhol , Vinod Koul , Neil Armstrong , Peter Rosin , Aaro Koskinen , Andreas Kemnade , Kevin Hilman , Roger Quadros , Tony Lindgren , Janusz Krzysztofik , Vignesh R , Andi Shyti , Ulf Hansson , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Geert Uytterhoeven , Magnus Damm , Wolfram Sang , Yazan Shhady , Jon Nettleton , Mikhail Anikin , "linux-can@vger.kernel.org" , "linux-phy@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-omap@vger.kernel.org" , "linux-i2c@vger.kernel.org" , "linux-mmc@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" Subject: Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict Message-ID: <20260216092914.kmvl7aep7dantcsd@skbuf> References: <20260208-rz-sdio-mux-v9-0-9a3be13c1280@solid-run.com> <20260208-rz-sdio-mux-v9-1-9a3be13c1280@solid-run.com> <20260212164823.mbeycqwzsy2dfq6e@skbuf> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Josua, On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote: > >> In the future, when you have a series with cross-tree dependencies, > >> please try to think of it as individual mini-series for each tree's > >> 'next' branch, and specify clearly that you need stable tags (to be > >> pulled into other trees). > > I don't really understand how I could split my series up to avoid this > issue. > > Due to the fact that one (and now two) drivers implemented local > mux helpers, to undo that an atomic change must be made tree-wide. > > Meanwhile it must be avoided that while the mux core helpers are being > tested / reviewed, that any tree adds another driver-local mux helper > like appears to have happened here. > > Note that my patch-set did go to linux-phy@lists.infradead.org list, too. > > The second challenge for this series was that mux framework is being > enabled only by drivers Kconfig "select" - and not possible by menuconfig. > This is e.g. responsible for being unable to test =m build with arm64 > defconfig - and lead to it only being detected through kernel robot > x86_64 allmodconfig. To avoid this, a combination of developer due diligence + maintainer due diligence is probably required. >From linux-phy perspective, there will be some automated build testing (which did not exist at the time of your submission). This would have caught the 'hidden' devm_mux_state_get_optional() call present only in linux-phy/next, when testing patch 2/7. But, to work, the build automation needs to be able to apply the entire patch set on linux-phy/next. So expect some pushback if it doesn't (hence the recommendation to send a mini-series to linux-phy first, and request a stable tag). These are the tools we have, we need to find a way to make them work somehow. Then there is the fact that local definitions of devm_mux_state_get_optional() keep popping up, possibly in unrelated trees (not the case here). This seems to be a bad practice which should be discouraged during review if caught. Otherwise, some 'retries' will be required from the developer until all occurrences are removed. Note that the upcoming linux-phy automated build testing does have an x86_64 allmodconfig test too.