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 9BE21CCA47F for ; Fri, 1 Jul 2022 10:15:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235241AbiGAKPl (ORCPT ); Fri, 1 Jul 2022 06:15:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231942AbiGAKPj (ORCPT ); Fri, 1 Jul 2022 06:15:39 -0400 Received: from alexa-out.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CA0C76942; Fri, 1 Jul 2022 03:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1656670538; x=1688206538; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tjB+YWtXrkSRn425vyGQBHRy7XsCGQmbQOkFimaKvD8=; b=mGlH6Ehl4+p81Okw+KAPIJ8ISKWWOor6jcsuLgWeklkjkPq/S4mFaAR7 zW7HxKB5YTd2mklPt2aAyW01+GOomRDxHWRnR4att7T+0rqTCKiKFdkye kVFOylkjldrDHyuhz+A0ya4u0RQMaipMPq/cfv8811uBEo4P+PKztL7fK 8=; Received: from ironmsg-lv-alpha.qualcomm.com ([10.47.202.13]) by alexa-out.qualcomm.com with ESMTP; 01 Jul 2022 03:15:37 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg-lv-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2022 03:15:36 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Fri, 1 Jul 2022 03:15:36 -0700 Received: from hu-pkondeti-hyd.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Fri, 1 Jul 2022 03:15:30 -0700 Date: Fri, 1 Jul 2022 15:45:26 +0530 From: Pavan Kondeti To: Matthias Kaehlcke CC: Krishna Kurapati PSSNV , Stephen Boyd , Pavan Kondeti , "Bjorn Andersson" , Felipe Balbi , Krzysztof Kozlowski , Rob Herring , Andy Gross , Greg Kroah-Hartman , Doug Anderson , "Mathias Nyman" , , , , , , , Subject: Re: [PATCH v20 2/5] usb: dwc3: core: Host wake up support from system suspend Message-ID: <20220701101526.GA30468@hu-pkondeti-hyd.qualcomm.com> References: <20220616091110.GA24114@hu-pkondeti-hyd.qualcomm.com> <20220620085415.GA13744@hu-pkondeti-hyd.qualcomm.com> <20220628053148.GA21797@hu-pkondeti-hyd.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Thu, Jun 30, 2022 at 06:10:50PM -0700, Matthias Kaehlcke wrote: > > > dwc3-qcom should wait for dwc3 core to call component_add() and then do > > > whatever needs to be done once the dwc3 core is registered in the > > > dwc3-qcom bind callback. Honestly this may all be a little overkill if > > > there's only two drivers here, dwc3-qcom and dwc3 core. It could > > > probably just be some callback from dwc3 core at the end of probe that > > > calls some function in dwc3-qcom. > > Since the issue we are facing is that the ssphy device links are not ready > > causing the dwc3 probe not being invoked, can we add an API as Pavan > > suggested > > to check if deferred_probe listfor dwc3 device is empty or not andbased on > > that we can choose to defer our qcomprobe ? In this case, we don't need to > > touch the dwc3 core driver and would be making changesonly in qcom glue > > driver. > > As mentioned above, it shouldn't be necessary to add component support to > all the glue drivers. An API to check for deferred probing is an option, > however there is a possible race condition: When the dwc3-qcom driver checks > for a deferred probe the core could still be probing, in that situation the > glue would proceed before the core driver is ready. That could be avoided > with the component based approach. The race can happen only if asynchronous probe is enabled, otherwise the child's probe happens synchronously in of_platform_populate() OTOH, would the below condition suffice for our needs here? if our device is not bounded to a driver, we check the state of initcalls and return either error or -EPROBE_DEFER diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 7b6eff5..519a503 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev) dev_err(dev, "failed to get dwc3 platform device\n"); } + if (!qcom->dwc3->dev.driver) + return driver_deferred_probe_check_state(&qcom->dwc3->dev); + node_put: of_node_put(dwc3_np); Thanks, Pavan