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 9614636EAB1 for ; Fri, 3 Jul 2026 07:47:06 +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=1783064827; cv=none; b=jakvm34+AkaE3rh8UCkUt0fhQVsl+egyOMB0B5MZk6HcBszqeddgc3whgYaKCb/BzaK6YT+VaH5vIcMcdsOpxgTRk+KCs1twRq0xcOQcDiRgNE4AuGjltu2QbnXCoQ+Y4gywm/uWxRWoCara6dMti1bJUrejbVUb65vIQxSMamA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783064827; c=relaxed/simple; bh=xAapxc1juzKwgiOHVioabLi4xU0ElT58xolvrC/Z8gE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jP5PZQP8ZH5NIZ5IPLgTMEgqPHbXtZv6CEz1hRyecnnIbKGXGOJVKO/lpryWcNpQSzI6C3yyIqe9trYVg87Awy0YXsSqar/LqyTpktOfLzWq8UIciAIEzrNDiKY8sVPV+7rh6o7sMiFg/Pv13WARWCSuFkpPpD8ETKuxZ8hcHV8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XDQnTspI; 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="XDQnTspI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1F631F000E9; Fri, 3 Jul 2026 07:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783064826; bh=VYkuNdTognQIs2j+ybtTEz5f3IFZB3kjG5rBVAxVSaM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XDQnTspIWcNXp/iZYRnAdTmyF2+BZNOIsb2B0d6w5ZGv6rTiLrS06GVstEJsx2H+z Gh1WrKQnTkmAaLbBhn90LC+oQvA8JigS9iZYvP33VMNde1iU7EaEtVXwNLol/UTtPt +ltMHM3ngQKV9+5hT5hsQNDTtkF8cYOpEB0mpiMlMTloJCM6PFXxMTQEzTtQakqrGP /ZUEWYaHzzeVIkGuOqt8rF5dB1QjLVIGmK7KTDvxkltjk3HlzWg2CDtwyY5hFA7g53 Fu+TFtzYMUhDrf7FtRWTl6EGc0aqGTTRz80jpUo8QGM9zbI8bCkX00JDUwU7N4QMK7 9ocyd5BaU9jUg== Date: Fri, 3 Jul 2026 08:47:01 +0100 From: Lee Jones To: Pengpeng Hou Cc: Fabrice Gasnier , Maxime Coquelin , Alexandre Torgue , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mfd: stm32-timers: depopulate child devices on populate failure Message-ID: <20260703074701.GE2108533@google.com> References: <20260615063042.36397-1-pengpeng@iscas.ac.cn> <20260701214250.GD2108533@google.com> <20260703065016.97181-1-pengpeng@iscas.ac.cn> 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: <20260703065016.97181-1-pengpeng@iscas.ac.cn> On Fri, 03 Jul 2026, Pengpeng Hou wrote: > Hi Lee, > > Thanks for taking a look. > > I checked devm_of_platform_populate(), but I don't think it covers this > particular failure path on its own. > > devm_of_platform_populate() only installs the devres cleanup after > of_platform_populate() has returned success. If of_platform_populate() > returns an error after creating some earlier children, the helper just > frees its devres record and those partial children are not depopulated. > > For stm32-timers, I think we still need the explicit ordering used by > remove: depopulate children before stm32_timers_dma_remove(). The child > drivers get the parent drvdata, and the PWM child can call the parent > stm32_timers_dma_burst_read() helper, so releasing the parent DMA > channels while partially-created children remain would keep the same > ordering problem the remove path avoids. > > I agree the inline unwind is not the clearest form. I can send a v2 > using a normal goto unwind label and a short comment explaining the > partial-populate case, unless you prefer a different shape. I'm not concerned about where in the file the call sits. Calls like this that fail usually do so cleanly. I think this deserves a wider piece of work that ensures that of_platform_populate() doesn't leave dangling resources when it fails. Also, why doesn't every call to of_platform_populate() have this? -- Lee Jones