From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D926C4332F for ; Thu, 14 Dec 2023 14:09:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1573423AbjLNOJf (ORCPT ); Thu, 14 Dec 2023 09:09:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1573115AbjLNOJd (ORCPT ); Thu, 14 Dec 2023 09:09:33 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CA17A7 for ; Thu, 14 Dec 2023 06:09:40 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE3E9C433C8; Thu, 14 Dec 2023 14:09:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702562979; bh=F3Budhbk+oO4EaTBoG3jnHcriilK7yvDChjm2zriBQo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fonDCcbmN11dfo8tFhAC9T0TGc8c1GNGBfvFzoWua/DlBDFRbYa56Lbj8ZKCdvVol LlZEPSN6l96Pzz9AsWP6PWvZMRvYLxLDtof/FQS6TKJNWs0o8F/dWYGRi1tCHq6wbK n1LWvn+lq9Q+x4suypErvJ5VUTFax2vilb4NQbt53YeO5ePBxQqxEu5zUjYaOlAM4X fP2TF/Sjugrm3SelgTZaLM6Pzv8aIw1HMdKr5ktJGSVPq1bca2bZr9rCBf3DueLnOF vTTUD8fIx8kyYwhuX06tNHH8ELTaEdwMm/H7p8jYgubuqusFNl0l+q0YtLjLWJQIex SeS9Y38XCKRGQ== Received: from johan by xi.lan with local (Exim 4.96.2) (envelope-from ) id 1rDmPA-0007zy-14; Thu, 14 Dec 2023 15:09:36 +0100 Date: Thu, 14 Dec 2023 15:09:36 +0100 From: Johan Hovold To: Dmitry Baryshkov Cc: Rob Clark , linux-arm-msm@vger.kernel.org, Rob Clark , Andy Gross , Bjorn Andersson , Konrad Dybcio , open list Subject: Re: [PATCH] soc: qcom: pmic_glink: Fix boot when QRTR=m Message-ID: References: <20231213210644.8702-1-robdclark@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 14, 2023 at 04:04:49PM +0200, Dmitry Baryshkov wrote: > On Thu, 14 Dec 2023 at 16:01, Johan Hovold wrote: > > On Thu, Dec 14, 2023 at 01:04:43PM +0200, Dmitry Baryshkov wrote: > > > On Thu, 14 Dec 2023 at 09:16, Johan Hovold wrote: > > > > On Wed, Dec 13, 2023 at 01:06:43PM -0800, Rob Clark wrote: > > > > > From: Rob Clark > > > > > > > > > > We need to bail out before adding/removing devices, if we are going > > > > > to -EPROBE_DEFER. Otherwise boot will get stuck forever at > > > > > deferred_probe_initcall(). > > > > > > > > Can please you expand on why this is a problem here in the commit > > > > message? > > > > > > > > The aux devices appear to be tore down correctly in the probe error > > > > paths so how exactly does that lead to deferred_probe_initcall() being > > > > stuck? This sounds like we may have a problem elsewhere which this patch > > > > is papering over. > > > > > > This is a known problem. Successful probes during the probe deferral > > > loop causes the whole loop to be reiterated. Creating child devices > > > usually results in a successful probe. Aso I thought that just > > > creating new device also causes a reprobe, but I can not find any > > > evidence now. > > > > This still needs to be described in the commit message. > > > > Only a successful probe should trigger a reprobe, and when the child > > devices are registered the parent is not yet on the deferred probe list. > > So something is not right or missing here. > > Child devices can be successfully probed, then the parent gets > -EPROBE_DEFER, removes children and then it goes on and on. So what? As I described above, the successful probe of the children should have nothing to do with whether the parent is reprobed. If that isn't the case, then explain how. Johan