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 E04A3C433EF for ; Wed, 8 Jun 2022 23:16:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231421AbiFHXP7 (ORCPT ); Wed, 8 Jun 2022 19:15:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231176AbiFHXPq (ORCPT ); Wed, 8 Jun 2022 19:15:46 -0400 Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82D5D62A2C for ; Wed, 8 Jun 2022 16:15:43 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2ef5380669cso224682297b3.9 for ; Wed, 08 Jun 2022 16:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5dm3ORkewVvScpNnTHAWD0lWUpKHv8ZP9Eg12POa/hY=; b=s8ajev8ylc24lWL+uVn0aQqBmKLBXSt4qhwBZySWYs06ap1dTsQm6yNKQo5ZZk1Ttw CogFfnoV9WalwlDwJZQwIzhS53XYG0TnpLr6RaCiWz52oS8Ya2rxty3/51rSjmJayx7c EWdKZF1ai138Psl2FvsA3fb81ZOFaNvnMqn373Non4bghec4LDcPh888h9mpuh/1unnN f9dX3yfRPbSr2zW6HLeQ/tEvTedV0nhIrv0QdBSD7AwR10AtUBj/yefZJX+LJ+vEpqtI mz7ygzZjwLzaYvbU7IBn1tdY8nY9jEOw6ZGRU2lMtt4y+nfEmnlgAfeCbdWY91a6rwLO KGNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5dm3ORkewVvScpNnTHAWD0lWUpKHv8ZP9Eg12POa/hY=; b=jHnL9LVV9Ezn5ZX/KScCHjyJmnbQBfmaKkU/U8U5HLBVKNa53O8CPVpVwtEyuBxGqt 4kIRFSwTAPEJyUql6Ze1oROB1M6DNLn98nbyRmXidau2yV9BaamJuqUrRNPwvNy7bepk FFdAAeSej6TVWuEBIZi+8juz82rJdOvPVKnqiXJUY1+7axucbuNsfsDDZoTrMjXucKKY qhbOTs4f4lHptgE8WxdpBLdaMuFCMrz6qc4zcsLpGf6mq2AcFNdqdLn6YUHGfQZweL1S raxKtXXM0/Ho+xSybAa0tBecmc8Q40MW0p2EsN+9RkOEdXLlSvwByYEQ5dLyteSZYn3Q sXrA== X-Gm-Message-State: AOAM532M0LmF6thiLWKp9n3CwVHTlXWWsSHHREiCHiacc+4nZXhZ26Z9 Kk7JBNFtjdcGNYH93UkuzrD+S7rsk8z8U75NSA7SFw== X-Google-Smtp-Source: ABdhPJydbDnoddm1zrWGAsHzuwqdddTQzuodu0O1Gb1JEUm33YqJ1CQ0JnoMmfFGzaJs2LsBc2KxBacSkdprXywkGyo= X-Received: by 2002:a81:1a4c:0:b0:30c:8363:e170 with SMTP id a73-20020a811a4c000000b0030c8363e170mr38925926ywa.455.1654730143827; Wed, 08 Jun 2022 16:15:43 -0700 (PDT) MIME-Version: 1.0 References: <20220601070707.3946847-1-saravanak@google.com> <20220608154908.4ddb9795@kernel.org> In-Reply-To: <20220608154908.4ddb9795@kernel.org> From: Saravana Kannan Date: Wed, 8 Jun 2022 16:15:07 -0700 Message-ID: Subject: Re: [PATCH v2 0/9] deferred_probe_timeout logic clean up To: Jakub Kicinski Cc: Geert Uytterhoeven , Greg Kroah-Hartman , "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , Len Brown , Pavel Machek , Joerg Roedel , Will Deacon , Andrew Lunn , Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Paolo Abeni , Linus Walleij , David Ahern , Android Kernel Team , Linux Kernel Mailing List , Linux PM list , Linux IOMMU , netdev , "open list:GPIO SUBSYSTEM" , Linux-Renesas , =?UTF-8?Q?Niklas_S=C3=B6derlund?= , Laurent Pinchart , Rob Herring , Vladimir Oltean , Florian Fainelli , Thomas Bogendoerfer Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 8, 2022 at 3:49 PM Jakub Kicinski wrote: > > On Wed, 8 Jun 2022 14:07:44 -0700 Saravana Kannan wrote: > > David/Jakub, > > > > Do the IP4 autoconfig changes look reasonable to you? > > I'm no expert in this area, I'd trust the opinion of the embedded folks > (adding Florian as well) more than myself. Thanks. > It's unclear to me why we'd > wait_for_init_devices_probe() after the first failed iteration, wait_for_init_devices_probe() relaxes ordering rules for all devices and it's not something we want to do unless we really need it. That's why we are doing that only if we can't find any network device in the first iteration. > sleep, > and then allow 11 more iterations with wait_for_device_probe(). > Let me also add Thomas since he wrote e2ffe3ff6f5e ("net: ipconfig: > Wait for deferred device probes"). Even without this change, I'm not sure the wait_for_device_probe() needs to be within the loop. It's probably sufficient to just do it once in the beginning, but it's already there and I'm not sure if I'm missing some scenarios, so I left that part as is. -Saravana