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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08DA1C83000 for ; Tue, 28 Apr 2020 20:39:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ADB6F2085B for ; Tue, 28 Apr 2020 20:39:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ax7SeX9z"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Ig9oGDt/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ADB6F2085B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HEp0sqwe+/qUz2uEgL+BZ/HQoXXTJKt18YWNqQfsGPU=; b=Ax7SeX9zOwEBsZ qE3Ncc6g68+qCxdqYQdCi57gxWrU/qbPYri7thi3GxpsfZlVWDZA06ahPTGxAu+c61NSqiaqkWxvj oZNW70BMKXk4Xh2krSVf5SaRsmHmmC54JZo4+UnIf+2uLe0XsZ8nfeOY3fVcUTGAXVqCdE/XxMrj+ ZLyfO9qYlgGaIAksYXdIndQ2HavZP3ryp3QPTcgDkm433p+RmY9xXeWaT6CWBXwiPVOMVB2DxotUA qwOsuL9Z4tix0KaQPODEw7Q9K0qmDz6frk+poYmnEcRSi9SqFUqXwdAGmYQjt5w86HtMuX6FNKBZ8 CA+1h5CSr/ucHUFNnfOg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTX1G-0004H0-1P; Tue, 28 Apr 2020 20:39:54 +0000 Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTX1C-0004GA-9m for linux-arm-kernel@lists.infradead.org; Tue, 28 Apr 2020 20:39:52 +0000 Received: by mail-lj1-x244.google.com with SMTP id a21so137832ljb.9 for ; Tue, 28 Apr 2020 13:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V3OlUrk1ZjE1ta2A4BFHChh1Q15DDJC2bVKnSZqjkIw=; b=Ig9oGDt/jncXxEexaKBGPNWFHql3a4RonXLv+oSsQq40ap0vqIGMNbYniuDe/2sIyM weZEz1xbFa+4xdkrUwn6uAlQhHiYgYAen9aSTPRiipuzS1gP/6ISmR8UIUWgvSvtS3KJ SgwHyYQjJiXQiiGsxurH7pi4Re+fyiWcZUZXiTx1MFQ22gSnrshUKsayirwoDX2/FIFy f02nZIl1ahnj62FItb1r8+gArYLUD/cXv4v3zxux1AnthwnXD0mH+uBkbyoqKCtf4uQU jLlozDRdVHZlrv+72QZolw/h3LDfYkZA7zWQfwqB1+uMFzCkqE+JFTqakXEBJkyLJSn4 MZVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V3OlUrk1ZjE1ta2A4BFHChh1Q15DDJC2bVKnSZqjkIw=; b=HNZ7kbdv548ODY2xKf2exm9nUTw3tz8LmnswuQdafAZ4gvN21FZhhcK2Y8oNxqUalN lfz81hEx3KIMNyqdmzKyIX9nG/sVoUvMEh8AMgK1MGcRaSl0YQXoMEZVpFOM3ZC49HgR hcWkBdSdZR3vktK9C/PkKyANCbEyeGz31hH/89zLVVvXQg7kuexhKTFEAJmyRoYOeOpo hmQij+l3t7VB+EkUH0XZmpQGBlpo5EhbF3LlLj3l69+8BZsayv/wxUUso9+N14jUCKsg Dc4wsp3OkVcwkuHj8CgMZT2Mpf55u1IFEHxkn5otQtbQxqYsxIfERBSKI8ZsuqLgPArl uafg== X-Gm-Message-State: AGi0PuYW7Tt8kdvlNPbdRg2F+g2UjhyVrcGJJPx2o2XGjWH1TQNnjAKg W1CrbfuvRUAvyjRmqofAOZsNF+inuo10XJPiEQmMgw== X-Google-Smtp-Source: APiQypIH9BsRfXXG0y8j3kGmDLc7ZK9EIQjOI8GIl+BT62qRMzbZcjmCkZJ5VobjAhrDkABqdmdFC+/IuCmXpXyJ10A= X-Received: by 2002:a2e:8805:: with SMTP id x5mr19535284ljh.223.1588106388089; Tue, 28 Apr 2020 13:39:48 -0700 (PDT) MIME-Version: 1.0 References: <20200427212514.11219-1-robh@kernel.org> In-Reply-To: <20200427212514.11219-1-robh@kernel.org> From: Linus Walleij Date: Tue, 28 Apr 2020 22:39:36 +0200 Message-ID: Subject: Re: [PATCH] amba: Retry adding deferred devices at late_initcall To: Rob Herring , Marek Szyprowski X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200428_133950_507817_81CA3608 X-CRM114-Status: GOOD ( 15.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Saravana Kannan , Geert Uytterhoeven , Russell King , John Stultz , Linux ARM , Sudeep Holla , Nicolas Saenz Julienne Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Apr 27, 2020 at 11:25 PM Rob Herring wrote: > If amba bus devices defer when adding, the amba bus code simply retries > adding the devices every 5 seconds. This doesn't work well as it > completely unsynchronized with starting the init process which can > happen in less than 5 secs. Add a retry during late_initcall. If the > amba devices are added, then deferred probe takes over. If the > dependencies have not probed at this point, then there's no improvement > over previous behavior. To completely solve this, we'd need to retry > after every successful probe as deferred probe does. > > The list_empty() check now happens outside the mutex, but the mutex > wasn't necessary in the first place. > > This needed to use deferred probe instead of fragile initcall ordering > on 32-bit VExpress systems where the apb_pclk has a number of probe > dependencies (vexpress-sysregs, vexpress-config). > > Cc: John Stultz > Cc: Saravana Kannan > Cc: Linus Walleij > Cc: Sudeep Holla > Cc: Nicolas Saenz Julienne > Cc: Geert Uytterhoeven > Cc: Russell King > Signed-off-by: Rob Herring Makes sense to me, and the same approach is found in the generic code in drivers/base/dd.c so Reviewed-by: Linus Walleij The timer-based re-probe was added by Marek Szyprowski in commit a41980f2a3eb33ed7a2636e83498b47e95ceb05b do deal with power domains. I guess it mimics dd.c deferred probe at this point? There are a bit of other differences that have piled up, should we take a quick look at dd.c so there is not something else we're missing? I see some PM code for example. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel