From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.andi.de1.cc (mail.andi.de1.cc [178.238.236.174]) (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 76B8C3164C2; Mon, 16 Feb 2026 15:25:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.238.236.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771255535; cv=none; b=syI6h/6BOV8LB6E265Q8DahJFXr3pjQNPTCc00/EH73b/RqmIlMjvclCzHZMGQGphj8ljwEHwAkjopQeeOKuhwuCwWMaf0ddyNGIRQuhW2EFLqh8xXgMdvjcILSnZHyaUm82dICj2fk1MD9UKY1r93cURSUe9PeWeyW/f0mOm9k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771255535; c=relaxed/simple; bh=K3lRTqVkgTbsUZEdt0AotXacxdi5Nb+Ix685DjTsOz0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=X96MBk9WCXgvTsD2MB8t2KtocbGROaLSVBuv+5gF1vsNSzKTSZ/1UY+S/4w4oLAe4Lyhh+BC9a/abXjP/rFcSTPipcBkQvONXaCROWoFjxKu2bFwS6IQJs6e80ooT54szqGNmFI9GJNZUh9HgkXgM+g8fKw9AW1CKzRf5NUkzc4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kemnade.info; spf=pass smtp.mailfrom=kemnade.info; dkim=pass (2048-bit key) header.d=kemnade.info header.i=@kemnade.info header.b=3I3ct1mS; arc=none smtp.client-ip=178.238.236.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kemnade.info Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kemnade.info Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kemnade.info header.i=@kemnade.info header.b="3I3ct1mS" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kemnade.info; s=20220719; h=References:In-Reply-To:Cc:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=+NuGee1f3YReNLAkZ92SuV7HlsXpngRlfWnVEVSkgmQ=; b=3I3ct1mSQotzkI0CFg0yUeDyPU uszNV5kuZ5BoqCMC6ea1ywRQ9F8zCXOL/daxPnD8zkNgUHA+mmizXUBINHJxHNlw7hMr4s0IHioh9 5rlaft8K+ZH5XDqp0Yd3XdFnTcTPA0XAPgtXdL/jwazhLlNkinKzlgXymtdDixCgO7CocgnDF5suu iCBCt9pqxSEP8lbjwY7jbss/nmXL51hQ0fv4jm+WRPHHO549392zOcsxYzRk4jTZQeTcsDoqFc90M +tiUVHW2jQH47ycjEgqCjs3dAESLSss5wECck4GJNgxvFwo7SB0sPhR8g79fm5Jur8p5mkQOASMuj 68a4dnlQ==; Date: Mon, 16 Feb 2026 16:24:06 +0100 From: Andreas Kemnade To: Vladimir Oltean Cc: Josua Mayer , Geert Uytterhoeven , Marc Kleine-Budde , Vincent Mailhol , Vinod Koul , Neil Armstrong , Peter Rosin , Aaro Koskinen , 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: <20260216162406.0121dd91@kemnade.info> In-Reply-To: <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> <20260216092914.kmvl7aep7dantcsd@skbuf> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.49; aarch64-unknown-linux-gnu) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 16 Feb 2026 11:29:14 +0200 Vladimir Oltean wrote: > 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). > I do not think that is at all the duty of the patch submitter. I think as long as every dependencies and side effects are documented, it is IMHO up to the maintainers to decide how it can be merged best. They know best whether there is any danger of conflicts in their working tree because that is an area where people are working on. Especially this patchset is around for months. In MFD where it is more common practice to have cross-subsystem patchsets, once acks from everyone are there, MFD Maintainer creates an immutable branch with a tag. The maintainers of the affected subsystems pull it in. Regards, Andreas