Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp1682956ioo; Mon, 23 May 2022 00:09:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWBYTwCAdgMxj0cdEN80Apa+CrGApICPx/B098/Zvpk/vcz/cNWVbDiQT4nemMuAKaQCCh X-Received: by 2002:a63:48b:0:b0:3f6:4ded:378c with SMTP id 133-20020a63048b000000b003f64ded378cmr16122648pge.163.1653289768246; Mon, 23 May 2022 00:09:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653289768; cv=none; d=google.com; s=arc-20160816; b=gxq0tF/Qh1TYZiZCGrl1W1IrkuZvUI12xLUAevQoPSi3jR9AYLz7kLdoOSIzPpbohy PiOmlfMoybFqGWMrQCpwyCCIr6tMkZuFJgccjA3RUwpgQQ/I7Z309YM8NNoP/szQa9ON AkdsU5vk9rxDdjEIQfLplTpiEXA+Jgn3IsWlB0m/X15Jy0g6Br0sQ7M4H958FTIOZAzX E5F+x6LbxoWGtyRWXvnVQy9pAFh4RlVHYiL8tcfTFCpUj7rIIsYjlhfMFK63+ivTpVY+ 9CDvTSCvCjNDXVR4krCVuqo5sPLodwQ8pscKVP9XYQ2Ayb6CtKdhTZ4vem0CYgI1sAoc magQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=4EbTUlhTEpoUgQqWiI/dseKqBh8sQfu3BdkMvRGGeSQ=; b=edm3BlnsgAOsKz+VzJojZKR7dbLouSji+u5KKIANIoDi3KZBEMyzCYFQgf8gOrNJup eYbS3/Xf1wwq/heP1wpRbkMzGmoLLlQ1Y0vOvLkNBfrSXe4etdgBDcLOu1Qu2ZdYSjXC g3qlMFByZWcn5rnLFEMAY6DE2ETVBa8s+4Fg2etuO237LHgO1/fEUvdGealIHW/EUzPb 9Xce2+gjTznzBWgMpyI/pm9RHB/+wcZLNnkjiT9bfA01JFPdxR6sx3ioybkuCyWyj1G+ QKFsChVMlRSdOnBZ0CrdwhcXdTSNwfDObsXdHz35FKU+xIntodqphQU2Y0YwmakfM2OM v0Zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=gMxtn02B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id l3-20020a63ea43000000b003c14249f5d4si9213090pgk.135.2022.05.23.00.09.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 00:09:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=gMxtn02B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EF8792BB27; Sun, 22 May 2022 23:29:22 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350037AbiEURiI (ORCPT + 99 others); Sat, 21 May 2022 13:38:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236589AbiEURiF (ORCPT ); Sat, 21 May 2022 13:38:05 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF32A5D181; Sat, 21 May 2022 10:38:01 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id a38so7402021pgl.9; Sat, 21 May 2022 10:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4EbTUlhTEpoUgQqWiI/dseKqBh8sQfu3BdkMvRGGeSQ=; b=gMxtn02BzmVK2fLgjDLTx3m0VlYVJFnXZwArUzwsiQLnp+C34BAbgoyxSI2ytRUJYF 1q2RfsV++yqeO4bLRenKF5eQXVrlhCcWh8aORpbzTKEYcOeD+1UbIlt11k7k4im7QGHJ 25SOwzcv9Po8qVkUrne1iVHdfKS9RJQUQgxjORkQft9TRAk4YSVevGSvxN0BZSw0df9P CJ71Z+/m4cZR5oG93tcmJjkfy6wvjEuUtYPXM2DQnMsrbCG9IZZ0oX/q4cznO+V9tOjN COZxKZvv+9+NUGPoxq8FBo/39XICXa86QQUszB+vofYbQEYgjum4bgzAUFE0DOi+aTIL vrYg== 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=4EbTUlhTEpoUgQqWiI/dseKqBh8sQfu3BdkMvRGGeSQ=; b=oGxyPOjYbopf3grRwaAP4TVpWIN7gMcBap/x5meZ+33/I6/UslRg7dhJ8XnDwrR2fJ 90czuPCzg2To1t0wHcxKrFK8PBH0pQN7/k+vKkHcaelbjgaPvGDyJqk+srq0hedaJmJ0 dzUPD0+AMLQsBqDMHDaED+wL1oPtrFy0W53q88ksRGQIhDYpE+99SXaGdgmgkuQCJunZ 8JuGLblUH9mC6l2IFgDuQd448cCi4qEN1CnKKdXAWmd5XRlnjQDJX2Y8jT0c6+VkTFrr uaEBRGMi7SP/78jGrdR7f8kFjlGI8nKKA0/HqaMm1XrT0L2dQ75ALB+6qSZMuGoe4hFW bitA== X-Gm-Message-State: AOAM532+oN6smvDi8woPp1jQSwLhMZko81uxzlQshq2JdS3Ne2H2Jq6c DGUsmZx5gQm4NxyRIAiBNPhPR0YCb9arL34n71LnUBjAEQU= X-Received: by 2002:a05:6a00:1501:b0:510:7ab8:71c8 with SMTP id q1-20020a056a00150100b005107ab871c8mr15648138pfu.63.1653154681477; Sat, 21 May 2022 10:38:01 -0700 (PDT) MIME-Version: 1.0 References: <20220516165740.6256af51.alex.williamson@redhat.com> <20220518115432.76183-1-windy.bi.enflame@gmail.com> <20220520064148.GA20418@wunner.de> <20220521124910.GA13556@wunner.de> In-Reply-To: <20220521124910.GA13556@wunner.de> From: Sheng Bi Date: Sun, 22 May 2022 01:37:50 +0800 Message-ID: Subject: Re: [PATCH v2] PCI: Fix no-op wait after secondary bus reset To: Lukas Wunner Cc: Bjorn Helgaas , Alex Williamson , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 21, 2022 at 8:49 PM Lukas Wunner wrote: > > On Sat, May 21, 2022 at 04:36:10PM +0800, Sheng Bi wrote: > > If so, I also want to align the polling things mentioned in the > > question from Alex, since pci_dev_wait() is also used for reset > > functions other than SBR. To Bjorn, Alex, Lucas, how do you think if > > we need to change the polling in pci_dev_wait() to 20ms intervals, or > > keep binary exponential back-off with probable unexpected extra > > timeout delay. > > The exponential backoff should probably be capped at some point > to avoid excessive wait delays. I guess the rationale for > exponential backoff is to not poll too frequently. > Capping at 20 msec or 100 msec may be reasonable, i.e.: > > - delay *= 2; > + delay = min(delay * 2, 100); > > Thanks, > > Lukas Capping at 20 or 100 msec seems reasonable to me. Btw, since 20 msec is not a long time in these scenarios, how about changing to a fixed 20 msec interval? Thanks, windy