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 9243FC43334 for ; Fri, 1 Jul 2022 15:52:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229559AbiGAPwy (ORCPT ); Fri, 1 Jul 2022 11:52:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229491AbiGAPwy (ORCPT ); Fri, 1 Jul 2022 11:52:54 -0400 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 870EA12D31 for ; Fri, 1 Jul 2022 08:52:52 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id v126so2733027pgv.11 for ; Fri, 01 Jul 2022 08:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GwCJQx8sgFjKqx/lCA3RxH+lFCAU49v9gAkFazVr4kI=; b=JGyKim5cmpBfr8P3eul8H76XrfNlBpwWXjFJV6xVwpsD8Wx+/M1K7OOCy9WXfWxjjd lJzA67y66zVfCRfRcnAC9DhfnLsXQjccJc3KhK4qyFU33+g0xaWzX5KGnRiVKwn6nvJn IRswZzOBwkqI61T41Z6RekZBAHdeIEba6xJFw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GwCJQx8sgFjKqx/lCA3RxH+lFCAU49v9gAkFazVr4kI=; b=i/bU+miMD0hk8CT3XU9ktwDtqoTX/laxQa2BNlWx7O2+0YNu3w+i9hQzxsL1IZ8QOW /JOFmVg5OhllT3akUA3Rk6Eod0T9vnlGOlPGbrehCk/Dqq6AsYWJx8C728xlSKXYhnNP Tohhh/HeNFafvBpndHD1iX3WbGRWCw3r2NDgmWO3hAlGk8ZWH7W8VokAn8ccH60NXkPn DkMfTTnbcMnq3iC507RBv+W7J78ti8oLHa1PlC/STc2GEr6Vk8iZRn4+LiAngcMrrlxP kN2hGhXVdxL5G9QmMIlEcNEYz5PHjq+ldgTsa9c1jND1CuC2Y42vYYx3mYAndmtxgaid +yTQ== X-Gm-Message-State: AJIora+1uFjCEhewbtOxlGnC1xb2HVPCYNNuohnEK3ygD5YkCLsdSiah N3ZeoZ0rxkgjzGm/NYd87YVlsA== X-Google-Smtp-Source: AGRyM1unAQ7Hy3XTb21SIviGN36FXP7laFKOa5oKp755UdNTtbj9rY+F/HVa5luU0xbBFupWbBWmmw== X-Received: by 2002:a63:334d:0:b0:40c:3c28:1ec4 with SMTP id z74-20020a63334d000000b0040c3c281ec4mr13002795pgz.623.1656690772093; Fri, 01 Jul 2022 08:52:52 -0700 (PDT) Received: from localhost ([2620:15c:11a:202:faad:e53e:b60a:f694]) by smtp.gmail.com with UTF8SMTPSA id mj17-20020a17090b369100b001e2bd411079sm4327044pjb.20.2022.07.01.08.52.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jul 2022 08:52:51 -0700 (PDT) Date: Fri, 1 Jul 2022 08:52:49 -0700 From: Matthias Kaehlcke To: Pavan Kondeti Cc: Krishna Kurapati PSSNV , Stephen Boyd , Bjorn Andersson , Felipe Balbi , Krzysztof Kozlowski , Rob Herring , Andy Gross , Greg Kroah-Hartman , Doug Anderson , Mathias Nyman , devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, quic_ppratap@quicinc.com, quic_vpulyala@quicinc.com Subject: Re: [PATCH v20 2/5] usb: dwc3: core: Host wake up support from system suspend Message-ID: References: <20220616091110.GA24114@hu-pkondeti-hyd.qualcomm.com> <20220620085415.GA13744@hu-pkondeti-hyd.qualcomm.com> <20220628053148.GA21797@hu-pkondeti-hyd.qualcomm.com> <20220701101526.GA30468@hu-pkondeti-hyd.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220701101526.GA30468@hu-pkondeti-hyd.qualcomm.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Jul 01, 2022 at 03:45:26PM +0530, Pavan Kondeti wrote: > 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() I was thinking about the case where the dwc3-qcom probe is initially deferred, then the deferred probe starts shortly after (asynchronously) and now the dwc3-qcom driver does its check. Probably it's not very likely to happen ... > 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); I like the simplicity of it, no need for new APIs. The components based approach would be slightly safer, but in practice I think this should be good enough.