From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 BE2E930B51D; Mon, 3 Nov 2025 13:35:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762176914; cv=none; b=rs7ceUWsR7pTQ34ZqvZ4x0OioT7EQ3JYSOD6TpPcaD1GPODQs5mq48SmFKkMuHlPlGM/M/GTDkq24tbDW6SBp6NB5mxzgGzAnC2MkHeTo5U6bmkoKC9eIC6jdhzus8UiD0+AsubTroPSmTrsag4PWOoMME6NGX0coFRQ6QF4zwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762176914; c=relaxed/simple; bh=HUhCBMZvZipHgUmjcVZ0eOSnMcg+HbQiCeJ/7jxn+Gg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=P6p/dLO60d+vtjssYhbMGrfTt+v/z6HcloMASoeQsnvO97hK4x3hSMMuGUEuDVKjpijL/da5jfWHB91CVgzDfuZ/IJD1mqn42ZCUxrl3dn7x4B+0HYI8+H1dN+Bwcy2EubRCnHKz2vys0hke6Kbdxm8WyQfcq+ja+rA21zxZXTU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=iSuStlNC; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="iSuStlNC" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id F1DAC1A1840; Mon, 3 Nov 2025 13:35:09 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id C0BB160709; Mon, 3 Nov 2025 13:35:09 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id F194010B500FE; Mon, 3 Nov 2025 14:34:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1762176907; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=koLz65BvAsRdOTOjAYYzE2T1rPDi7AByKsxkPawhxGI=; b=iSuStlNC/qPWehMW5QtSxmK7/Ek+OmtM952H+Xk5cz64yvAI1dRLRJl2LFnH1Saj3uIcSn Tfo0dDHHxzLe5rPhwCbyehjx3KhF+kWXpLRNtBcibrsD5eWlEhe06L8+GQDP7gihuHb7M4 aMb4hr5u64HA2jT9649n28R3LSuMyiMLHcAn1aj1T2djrGGH2TKUKnNVTaabRGpAWKTAUy xDNG39m9CDfMAnKBAqtJttRhZlsDSxkcO7NokNzenCtkiwC6nxpHFV3TZc+Gz2qOhJ3anH P5/UUwG3W53ojB0Z3tCqPkFB8BoZl0mckys6ra3FPqO4z9ocBaUZIcIEe7GxPQ== Date: Mon, 3 Nov 2025 14:34:52 +0100 From: Herve Codina To: Andi Shyti Cc: Andrew Lunn , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Michael Turquette , Stephen Boyd , Wolfram Sang , Peter Rosin , Arnd Bergmann , Saravana Kannan , Bjorn Helgaas , Charles Keepax , Richard Fitzgerald , David Rhodes , Linus Walleij , Ulf Hansson , Mark Brown , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Len Brown , Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , Geert Uytterhoeven , Wolfram Sang , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-i2c@vger.kernel.org, linux-pci@vger.kernel.org, linux-sound@vger.kernel.org, patches@opensource.cirrus.com, linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org, linux-spi@vger.kernel.org, linux-acpi@vger.kernel.org, linux-cxl@vger.kernel.org, Allan Nielsen , Horatiu Vultur , Steen Hegelund , Luca Ceresoli , Thomas Petazzoni Subject: Re: [PATCH v4 18/29] i2c: mux: Create missing devlink between mux and adapter physical device Message-ID: <20251103143452.080c3503@bootlin.com> In-Reply-To: <6tgbavtf2dqc44ebfighrs5chzx4j4zdmjk77fmulwqbhrex2b@lou7ekbsjekr> References: <20251015071420.1173068-1-herve.codina@bootlin.com> <20251015071420.1173068-19-herve.codina@bootlin.com> <6tgbavtf2dqc44ebfighrs5chzx4j4zdmjk77fmulwqbhrex2b@lou7ekbsjekr> Organization: Bootlin X-Mailer: Claws Mail 4.3.1 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-spi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 Hi Andi, On Thu, 30 Oct 2025 16:23:24 +0100 Andi Shyti wrote: > Hi Herve, > > ... > > > When an i2c mux is involved in an i2c path, the struct dev topology is > > the following: > > supernitpick: I'd leave blank line here. Will be added. > > > +----------------+ +-------------------+ > > | i2c controller | | i2c mux | > > | device | | device | > > | ^ | | | > > | | | | | > > | dev's parent | | | > > | | | | | > > | i2c adapter | | i2c adapter chanX | > > | device <---- dev's parent ------ device | > > | (no driver) | | (no driver) | > > +----------------+ +-------------------+ > > > > ... > > > No relationship exists between the i2c mux device itself and the i2c > > controller device (physical device) in order to have the i2c mux device > > calling i2c_del_adapter() to remove its downtream adapters and so, > > /downtream/downstream/ Will be fixed > > > release references taken to the upstream adapter. > > ... > > > + /* > > + * There is no relationship set between the mux device and the physical > > + * device handling the parent adapter. Create this missing relationship > > + * in order to remove the i2c mux device (consumer) and so the dowstream > > + * channel adapters before removing the physical device (supplier) which > > + * handles the i2c mux upstream adapter. > > + */ > > + parent_physdev = i2c_get_adapter_physdev(parent); > > + if (!parent_physdev) { > > + dev_err(muxc->dev, "failed to get the parent physical device\n"); > > + ret = -EINVAL; > > -ENODEV? Yes, -ENODEV makes sense here. Will be changed in the next iteration. > > > + goto err_free_priv; > > + } > > + dl = device_link_add(muxc->dev, parent_physdev, DL_FLAG_AUTOREMOVE_CONSUMER); > > Not to call twice put_device, I would add it once here and then > check for !dl. As Andy already mentioned, we cannot do that. Indeed, dev_name(parent_physdev) is called in the error path and so the device reference has to be kept. > > > + if (!dl) { > > + dev_err(muxc->dev, "failed to create device link to %s\n", > > + dev_name(parent_physdev)); > > + put_device(parent_physdev); > > + ret = -EINVAL; > > same here, should this be -ENODEV? For this one, I am not so sure. The failure is related to the device link creation and probably due to some devlink invalid internal flags or state instead of a missing device. That's said, if you really want the -ENODEV here, let me know. Best regards, Hervé