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 3D07FC43334 for ; Mon, 27 Jun 2022 20:02:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240786AbiF0UCy (ORCPT ); Mon, 27 Jun 2022 16:02:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240768AbiF0UCx (ORCPT ); Mon, 27 Jun 2022 16:02:53 -0400 Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8D801C926 for ; Mon, 27 Jun 2022 13:02:50 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id m24-20020a0568301e7800b00616b5c114d4so6344483otr.11 for ; Mon, 27 Jun 2022 13:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=32+pYyBzsUADZK/USZZWRdjG4+AC0lABRMoHRP/yr1M=; b=nxV1pazrE3xVmh1LX/HlRMYNTdOjbKwW0RRCRVu9T6jkSNo72sz01NuioSXN637++Z b2AmAuDtTrrhStoYWSiOXtpgTrLKdZeEkbwlHG4tCtrt1pXbnIQ8Sc3i5QhU0GyPpZW2 zh5xzrpaq2r4OY2ESHBGrWRJGNUk8oZYa/f3M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=32+pYyBzsUADZK/USZZWRdjG4+AC0lABRMoHRP/yr1M=; b=OWFRDW3U15yh5CM+rG6v3Ct0s0yu741rvmkWVaWrqwucodUaQnJdGtlVx8Fca5qcn5 3ZQhnnZ9CdxrOBswc02yWi6HGWJzPuC9NHaDfcxoRx6ABc62AXS27rqk/Ya42h2J0ae2 jFXjHNiyAXt1lILNKmI7H85lQPMxCSArB6DBuCdHUiIqtdbnJ2xSBaxqxV6FqbXvv715 91ty4JWBeJ5/sG4ADU0KHu19ksvEjhf/PA3W9RPo9dw54bYNceQwDPg+rlmoE6hW9OHe DrMokl/1ZMJhBWwo2xMhEsrrxp2taapgTQytDaNwK5lzIMKGBw9YYpWV67jWlZZ4Eqzp 63wA== X-Gm-Message-State: AJIora+6DVW7gHNZRqIc6Qf3lsKjdDPAOvCzdlk2FvXzk2Y86HJZ3Y9X P7s0kqtERrmRQSq5hhttMFUmoqN0aV1GLi2l9vnigg== X-Google-Smtp-Source: AGRyM1sUw3aUn8cs+jsZnRLI9HEdw7aGdjxn3slIwtFmzZUccOZBZrgs+CFrxV/GByzKlfqxHxRNuOwt68VgnVijZA8= X-Received: by 2002:a9d:6484:0:b0:60b:eb0b:4054 with SMTP id g4-20020a9d6484000000b0060beb0b4054mr6754340otl.159.1656360170138; Mon, 27 Jun 2022 13:02:50 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 27 Jun 2022 13:02:49 -0700 MIME-Version: 1.0 In-Reply-To: <20220620085415.GA13744@hu-pkondeti-hyd.qualcomm.com> References: <1654158277-12921-1-git-send-email-quic_kriskura@quicinc.com> <1654158277-12921-3-git-send-email-quic_kriskura@quicinc.com> <20220616091110.GA24114@hu-pkondeti-hyd.qualcomm.com> <20220620085415.GA13744@hu-pkondeti-hyd.qualcomm.com> From: Stephen Boyd User-Agent: alot/0.10 Date: Mon, 27 Jun 2022 13:02:49 -0700 Message-ID: Subject: Re: [PATCH v20 2/5] usb: dwc3: core: Host wake up support from system suspend To: Bjorn Andersson , Felipe Balbi , Matthias Kaehlcke , Pavan Kondeti Cc: Krishna Kurapati , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Quoting Pavan Kondeti (2022-06-20 01:54:15) > +Felipe, Bjorn > > On Thu, Jun 16, 2022 at 10:15:49AM -0700, Matthias Kaehlcke wrote: > > On Thu, Jun 16, 2022 at 02:41:10PM +0530, Pavan Kondeti wrote: > > > > Good point! It doesn't really ensure that the child is probed (actually it > > won't be probed and DL_FLAG_AUTOPROBE_CONSUMER doesn't make sense here), it > > could happen that dwc3_qcom_probe() is deferred multiple times, but eventually > > the PHYs should be ready and dwc3_probe() be invoked through > > of_platform_populate(). > > This is a generic problem i.e if a parent can only proceed after the child > devices are bounded (i.e probed successfully), how to ensure this behavior > from the parent's probe? Since we can't block the parent probe (async probe is > not the default behavior), we have to identify the condition that the children > are deferring probe, so that parent also can do that. > > Can we add a API in drivers core to tell if a device probe is deferred or > not? This can be done by testing list_empty(&dev->p->deferred_probe) under > deferred_probe_mutex mutex. The parent can return EPROBE_DEFER based on this > API return value. > > Another alternative would be explicitly checking if the child device suppliers > are ready or not before adding child device. That would require decoupling > of_platform_populate() to creating devices and adding devices. > > Note that this problem is not just limited to suppliers not ready. if the > dwc3-qcom is made asynchronous probe, then its child also probed > asynchronously and there is no guarantee that child would be probed by the > time of_platform_populate() is returned. The bus notifier might come handy > in this case. The parent can register for this notifier and waiting for > the children device's BUS_NOTIFY_BOUND_DRIVER/BUS_NOTIFY_DRIVER_NOT_BOUND > notifications. This would also work in our case, if we move to > of_platform_populate() outside the probe(). > > Would like to hear other people thoughts on this. > I'm not following very closely but it sounds like a problem that may be solved by using the component driver code (see include/linux/component.h). That would let you move anything that needs to be done once the child devices probe to the aggregate driver 'bind' function (see struct component_master_ops::bind).