Message ID | 20221231074041.264738-1-sergio.paracuellos@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp3243059wrt; Fri, 30 Dec 2022 23:58:03 -0800 (PST) X-Google-Smtp-Source: AMrXdXsxZJD78FKBp/yo32nkLmLEj5oru6Gq8RQx9lLra135q+RE1kLUUPKxYRI2DpzBFKzkAaAw X-Received: by 2002:a62:5245:0:b0:581:2c4f:e969 with SMTP id g66-20020a625245000000b005812c4fe969mr19579205pfb.5.1672473483208; Fri, 30 Dec 2022 23:58:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672473483; cv=none; d=google.com; s=arc-20160816; b=v6UsTOICgrJdkweDnWnOax4XoWIX7/I8ENJtfsLjAlS1RB7UUrWc0q96OkRXVLMxx+ hNlbeB8tGqpgcSfE0V12JU37uCsDpo9NleKeVm7TuIOWkclpotLP1HJGEfTmPDBZr+hW BFYcm2AwCnNEIPpbmpWpAa4uo/9D2/WLGNyLBSYsbzuUNNrUoTWP2p2Pg5pBpeYgkYcX suoWnfFooh0gFxuQZEflWiZ5zcldrVg4xKVGAH2RUdOlpvEqaN5kkHlsd1NcfzPOAhkC WjZDtFymrVqWtRI/F+mouEz3WtP1j1GMyZr1a5rp1rPgJFCgPPV3pbwXPdsx1Vj1Q5om 8j/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=BRto61P8hgbUD9Adp/jPx7dLuXOhVXQgxTy/8DMBdG8=; b=Bdcmvp0ibqyKvjJHK4fvC7Zl5WZYolWVTzOYL4Gad/xsQOSjnfUx6fPw8nDHTg5e6K Zebk3Ew7sf8WeWFCzuZUR1yuiOeoMgKbk+Js5EfKphmEIyl+W2rdFqB372EZyuve6e1H x99uNk4ug0EZqbaYFaYY3Bod61/KBV9SveALsb9XB4tfUzmC+xtLZf1mlIO8e+Sgm8IZ 8GlWZcXGOej2wkkStoVcKRMtMtN0ywjDEip5I649wRPs1I8xIEn4oHezBImyqHjveQn0 ch4Jza1yDdT0D0zqMrczIci83+ahVES0NLqHiZfryjuDh9VBH+QkiKLwahCHNKp9mF2h CTNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=hWggnJs4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q19-20020a056a00151300b005809ad59dddsi22931502pfu.9.2022.12.30.23.57.40; Fri, 30 Dec 2022 23:58:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=hWggnJs4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231600AbiLaHku (ORCPT <rfc822;cscallsign@gmail.com> + 99 others); Sat, 31 Dec 2022 02:40:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231573AbiLaHks (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 31 Dec 2022 02:40:48 -0500 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F29091099; Fri, 30 Dec 2022 23:40:45 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id bn26so2453281wrb.0; Fri, 30 Dec 2022 23:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=BRto61P8hgbUD9Adp/jPx7dLuXOhVXQgxTy/8DMBdG8=; b=hWggnJs4RDX4JorexSlF3c14+vA2UoPxtxFB0RJIPz9SA1NiL9MrdaAngRiE3LDjLZ qkguJw6zfWXDU8GLghPpp7mr0ZQtnQIlRffkaU2oajBYOWE1Ttfy3eKtXz/sZUZySXCw f3/rjUOjGHfaD2R6O8QnKYf/Gvh7B8wfpwfSTzvmDP8Ya5SMfNwNwdO35zQDU59Hleiw Finqu5bU4Yokky+rZLeXWBFxforL8pZ9hK+7UBqcgD+3dCr9AUShp81FKx6G25q0EW0I TSiVM/NsliJxpxrhCZR7zTMx00X+ABuKyUnpYBHQh9k4TlZ0OJPn/sNXLL5Ipz7Pias/ yiwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BRto61P8hgbUD9Adp/jPx7dLuXOhVXQgxTy/8DMBdG8=; b=PDImDCAhGEr6lXR2Ggqoo8zpIgnvr3Je0E3o2dValvNQO/GflrzX/eNqCqYY43bkvB dsKo+fatCJxXfCZXFWmcXkq+EghDN+NJUP31+A9vFGTj8hjhJi4TyBMzEn+g25T7mZUP slnhfhYq0SKgaX7BAVLEYAOo2PiOvMhTGv+6fOcvengyn16h9O4JtLxaQ8xXEpcoLUsj AVtD0VhBJhu4R+Nh/5e8YK859/UDHyYRugcjysNaaXchtRlLptgWqklt+F4Ww6MUoPwN AyikApp9/yqPytZwb417l6hKmYKISkktNf7jgMx2b3ptWaOASWqL2RX5ksWuD/orjlKt /F8Q== X-Gm-Message-State: AFqh2kptuuC7DkvFzUctnhb4zoM1AqQsn9LzQdgLVjI87vM2ep1Yzpxf Bg7ZzVKEdhazNrzKQhvDjgMj8mjToq4= X-Received: by 2002:a05:6000:1c05:b0:261:d8be:3046 with SMTP id ba5-20020a0560001c0500b00261d8be3046mr22534292wrb.0.1672472444106; Fri, 30 Dec 2022 23:40:44 -0800 (PST) Received: from localhost.localdomain (188.red-88-10-59.dynamicip.rima-tde.net. [88.10.59.188]) by smtp.gmail.com with ESMTPSA id x2-20020adfec02000000b0025e86026866sm27194005wrn.0.2022.12.30.23.40.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Dec 2022 23:40:43 -0800 (PST) From: Sergio Paracuellos <sergio.paracuellos@gmail.com> To: linux-pci@vger.kernel.org Cc: bhelgaas@google.com, lpieralisi@kernel.org, robh@kernel.org, kw@linux.com, matthias.bgg@gmail.com, linux-kernel@vger.kernel.org Subject: [PATCH v2] PCI: mt7621: Sleep a bit after power on the PCIs phy ports Date: Sat, 31 Dec 2022 08:40:41 +0100 Message-Id: <20221231074041.264738-1-sergio.paracuellos@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753715554673070974?= X-GMAIL-MSGID: =?utf-8?q?1753715554673070974?= |
Series |
[v2] PCI: mt7621: Sleep a bit after power on the PCIs phy ports
|
|
Commit Message
Sergio Paracuellos
Dec. 31, 2022, 7:40 a.m. UTC
Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to sleep a bit after call to mt7621_pcie_init_port() driver function to get
into reliable boots for both warm and hard resets. The needed time for these
devices to always detect the ports seems to be from 75 to 100 milliseconds.
There is no datasheet or something similar to really understand why this
extra time is needed in these devices but not in most of the boards which
use mt7621 SoC. This issue has been reported by openWRT community and the
complete discussion is in [0]. The selected time of 100 milliseconds has
been also tested in these devices ending up in an always working platform.
Hence, properly add the extra 100 milliseconds msleep() function call to make
also these devices work.
[0]: https://github.com/openwrt/openwrt/pull/11220
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
---
Hi Bjorn / Lorenzo,
As per Lorenzo comments in v1[0] here it is the patch with changes in commit
message and introducing a new definition for this needed extra delay time.
I wish you the best new year for you both.
Changes in v2:
- Add a new define 'INIT_PORTS_DELAY_MS' avoiding to reuse 'PERST_DELAY_MS'.
- Rewrite commit message and add a link to openWRT discussion.
Previous patch lore link:
[0]: https://lore.kernel.org/lkml/20221209071703.2891714-1-sergio.paracuellos@gmail.com/T/
Thanks,
Sergio Paracuellos
drivers/pci/controller/pcie-mt7621.c | 2 ++
1 file changed, 2 insertions(+)
Comments
Hi! On Sat, Dec 31, 2022 at 8:40 AM Sergio Paracuellos <sergio.paracuellos@gmail.com> wrote: > > Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need > to sleep a bit after call to mt7621_pcie_init_port() driver function to get > into reliable boots for both warm and hard resets. The needed time for these > devices to always detect the ports seems to be from 75 to 100 milliseconds. > There is no datasheet or something similar to really understand why this > extra time is needed in these devices but not in most of the boards which > use mt7621 SoC. This issue has been reported by openWRT community and the > complete discussion is in [0]. The selected time of 100 milliseconds has > been also tested in these devices ending up in an always working platform. > Hence, properly add the extra 100 milliseconds msleep() function call to make > also these devices work. > > [0]: https://github.com/openwrt/openwrt/pull/11220 > > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> > --- > Hi Bjorn / Lorenzo, > > As per Lorenzo comments in v1[0] here it is the patch with changes in commit > message and introducing a new definition for this needed extra delay time. > I wish you the best new year for you both. > > Changes in v2: > - Add a new define 'INIT_PORTS_DELAY_MS' avoiding to reuse 'PERST_DELAY_MS'. > - Rewrite commit message and add a link to openWRT discussion. > > Previous patch lore link: > [0]: https://lore.kernel.org/lkml/20221209071703.2891714-1-sergio.paracuellos@gmail.com/T/ > > Thanks, > Sergio Paracuellos > > drivers/pci/controller/pcie-mt7621.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/controller/pcie-mt7621.c b/drivers/pci/controller/pcie-mt7621.c > index ee7aad09d627..63a5f4463a9f 100644 > --- a/drivers/pci/controller/pcie-mt7621.c > +++ b/drivers/pci/controller/pcie-mt7621.c > @@ -60,6 +60,7 @@ > #define PCIE_PORT_LINKUP BIT(0) > #define PCIE_PORT_CNT 3 > > +#define INIT_PORTS_DELAY_MS 100 > #define PERST_DELAY_MS 100 > > /** > @@ -369,6 +370,7 @@ static int mt7621_pcie_init_ports(struct mt7621_pcie *pcie) > } > } > > + msleep(INIT_PORTS_DELAY_MS); > mt7621_pcie_reset_ep_deassert(pcie); > > tmp = NULL; > -- > 2.25.1 > Gentle ping on this patch :-). Thanks, Sergio Paracuellos
On Mon, Jan 23, 2023 at 09:55:20AM +0100, Sergio Paracuellos wrote: > Hi! > > On Sat, Dec 31, 2022 at 8:40 AM Sergio Paracuellos > <sergio.paracuellos@gmail.com> wrote: > > > > Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need > > to sleep a bit after call to mt7621_pcie_init_port() driver function to get > > into reliable boots for both warm and hard resets. The needed time for these > > devices to always detect the ports seems to be from 75 to 100 milliseconds. > > There is no datasheet or something similar to really understand why this > > extra time is needed in these devices but not in most of the boards which > > use mt7621 SoC. This issue has been reported by openWRT community and the > > complete discussion is in [0]. The selected time of 100 milliseconds has > > been also tested in these devices ending up in an always working platform. > > Hence, properly add the extra 100 milliseconds msleep() function call to make > > also these devices work. > > > > [0]: https://github.com/openwrt/openwrt/pull/11220 > > > > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> > > --- > > Hi Bjorn / Lorenzo, > > > > As per Lorenzo comments in v1[0] here it is the patch with changes in commit > > message and introducing a new definition for this needed extra delay time. > > I wish you the best new year for you both. > > > > Changes in v2: > > - Add a new define 'INIT_PORTS_DELAY_MS' avoiding to reuse 'PERST_DELAY_MS'. > > - Rewrite commit message and add a link to openWRT discussion. > > > > Previous patch lore link: > > [0]: https://lore.kernel.org/lkml/20221209071703.2891714-1-sergio.paracuellos@gmail.com/T/ > > > > Thanks, > > Sergio Paracuellos > > > > drivers/pci/controller/pcie-mt7621.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/pci/controller/pcie-mt7621.c b/drivers/pci/controller/pcie-mt7621.c > > index ee7aad09d627..63a5f4463a9f 100644 > > --- a/drivers/pci/controller/pcie-mt7621.c > > +++ b/drivers/pci/controller/pcie-mt7621.c > > @@ -60,6 +60,7 @@ > > #define PCIE_PORT_LINKUP BIT(0) > > #define PCIE_PORT_CNT 3 > > > > +#define INIT_PORTS_DELAY_MS 100 > > #define PERST_DELAY_MS 100 > > > > /** > > @@ -369,6 +370,7 @@ static int mt7621_pcie_init_ports(struct mt7621_pcie *pcie) > > } > > } > > > > + msleep(INIT_PORTS_DELAY_MS); > > mt7621_pcie_reset_ep_deassert(pcie); > > > > tmp = NULL; > > -- > > 2.25.1 > > > > Gentle ping on this patch :-). I was about to merge it - there are a couple of things that I don't like. First one is the comment, "Sleep a bit" does not mean anything. I'd rather say "delay port initialization" or something like that, be precise please. More importantly, this is a fix but it is not clear from the commit log. Please report what's wrong in the commit log. I will rework the commit log and merge it then (if you want to avoid another version just post an updated log here and I will merge it). Thanks, Lorenzo
Hi Lorenzo, Thanks for your comments. On Thu, Feb 2, 2023 at 5:27 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote: > > On Mon, Jan 23, 2023 at 09:55:20AM +0100, Sergio Paracuellos wrote: > > Hi! > > > > On Sat, Dec 31, 2022 at 8:40 AM Sergio Paracuellos > > <sergio.paracuellos@gmail.com> wrote: > > > > > > Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need > > > to sleep a bit after call to mt7621_pcie_init_port() driver function to get > > > into reliable boots for both warm and hard resets. The needed time for these > > > devices to always detect the ports seems to be from 75 to 100 milliseconds. > > > There is no datasheet or something similar to really understand why this > > > extra time is needed in these devices but not in most of the boards which > > > use mt7621 SoC. This issue has been reported by openWRT community and the > > > complete discussion is in [0]. The selected time of 100 milliseconds has > > > been also tested in these devices ending up in an always working platform. > > > Hence, properly add the extra 100 milliseconds msleep() function call to make > > > also these devices work. > > > > > > [0]: https://github.com/openwrt/openwrt/pull/11220 > > > > > > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> > > > --- > > > Hi Bjorn / Lorenzo, > > > > > > As per Lorenzo comments in v1[0] here it is the patch with changes in commit > > > message and introducing a new definition for this needed extra delay time. > > > I wish you the best new year for you both. > > > > > > Changes in v2: > > > - Add a new define 'INIT_PORTS_DELAY_MS' avoiding to reuse 'PERST_DELAY_MS'. > > > - Rewrite commit message and add a link to openWRT discussion. > > > > > > Previous patch lore link: > > > [0]: https://lore.kernel.org/lkml/20221209071703.2891714-1-sergio.paracuellos@gmail.com/T/ > > > > > > Thanks, > > > Sergio Paracuellos > > > > > > drivers/pci/controller/pcie-mt7621.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/pci/controller/pcie-mt7621.c b/drivers/pci/controller/pcie-mt7621.c > > > index ee7aad09d627..63a5f4463a9f 100644 > > > --- a/drivers/pci/controller/pcie-mt7621.c > > > +++ b/drivers/pci/controller/pcie-mt7621.c > > > @@ -60,6 +60,7 @@ > > > #define PCIE_PORT_LINKUP BIT(0) > > > #define PCIE_PORT_CNT 3 > > > > > > +#define INIT_PORTS_DELAY_MS 100 > > > #define PERST_DELAY_MS 100 > > > > > > /** > > > @@ -369,6 +370,7 @@ static int mt7621_pcie_init_ports(struct mt7621_pcie *pcie) > > > } > > > } > > > > > > + msleep(INIT_PORTS_DELAY_MS); > > > mt7621_pcie_reset_ep_deassert(pcie); > > > > > > tmp = NULL; > > > -- > > > 2.25.1 > > > > > > > Gentle ping on this patch :-). > > I was about to merge it - there are a couple of things that I don't > like. > > First one is the comment, "Sleep a bit" does not mean anything. I'd > rather say "delay port initialization" or something like that, be > precise please. How about: PCI: mt7621: delay phy ports initialization > > More importantly, this is a fix but it is not clear from the commit > log. Please report what's wrong in the commit log. The problem is that PCI ports are not detected properly without this delay for those devices so plugged cards on them do not work at all. I don't really know how to write the commit log clearer but I'll try adding this cards plugged not working stuff :-) We can add maybe also if you want: Fixes: 2bdd5238e756 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver") > > I will rework the commit log and merge it then (if you want to avoid > another version just post an updated log here and I will merge it). Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need to sleep a bit after calling the mt7621_pcie_init_port() driver function to get into reliable boots for both warm and hard resets. The needed time for these devices to always detect the ports seems to be from 75 to 100 milliseconds. Without ports properly detected no card plugged into the PCI's work at all. There is no datasheet or something similar to really understand why this extra time is needed in these devices but not in most of the boards which use mt7621 SoC. This issue has been reported by openWRT community and the complete discussion is in [0]. The selected time of 100 milliseconds has been also tested in these devices ending up in an always working platform. Hence, properly add the extra 100 milliseconds msleep() function call to make also these devices work. [0]: https://github.com/openwrt/openwrt/pull/11220 > > Thanks, > Lorenzo Thanks, Sergio Paracuellos
On Sat, 31 Dec 2022 08:40:41 +0100, Sergio Paracuellos wrote: > Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need > to sleep a bit after call to mt7621_pcie_init_port() driver function to get > into reliable boots for both warm and hard resets. The needed time for these > devices to always detect the ports seems to be from 75 to 100 milliseconds. > There is no datasheet or something similar to really understand why this > extra time is needed in these devices but not in most of the boards which > use mt7621 SoC. This issue has been reported by openWRT community and the > complete discussion is in [0]. The selected time of 100 milliseconds has > been also tested in these devices ending up in an always working platform. > Hence, properly add the extra 100 milliseconds msleep() function call to make > also these devices work. > > [...] Applied to pci/controller/mt7621, thanks! [1/1] PCI: mt7621: Sleep a bit after power on the PCIs phy ports https://git.kernel.org/pci/pci/c/0cb2a8f3456f Thanks, Lorenzo
On Fri, Feb 3, 2023 at 10:29 AM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote: > > On Sat, 31 Dec 2022 08:40:41 +0100, Sergio Paracuellos wrote: > > Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need > > to sleep a bit after call to mt7621_pcie_init_port() driver function to get > > into reliable boots for both warm and hard resets. The needed time for these > > devices to always detect the ports seems to be from 75 to 100 milliseconds. > > There is no datasheet or something similar to really understand why this > > extra time is needed in these devices but not in most of the boards which > > use mt7621 SoC. This issue has been reported by openWRT community and the > > complete discussion is in [0]. The selected time of 100 milliseconds has > > been also tested in these devices ending up in an always working platform. > > Hence, properly add the extra 100 milliseconds msleep() function call to make > > also these devices work. > > > > [...] > > Applied to pci/controller/mt7621, thanks! > > [1/1] PCI: mt7621: Sleep a bit after power on the PCIs phy ports > https://git.kernel.org/pci/pci/c/0cb2a8f3456f > > Thanks, > Lorenzo Thanks! Sergio Paracuellos
diff --git a/drivers/pci/controller/pcie-mt7621.c b/drivers/pci/controller/pcie-mt7621.c index ee7aad09d627..63a5f4463a9f 100644 --- a/drivers/pci/controller/pcie-mt7621.c +++ b/drivers/pci/controller/pcie-mt7621.c @@ -60,6 +60,7 @@ #define PCIE_PORT_LINKUP BIT(0) #define PCIE_PORT_CNT 3 +#define INIT_PORTS_DELAY_MS 100 #define PERST_DELAY_MS 100 /** @@ -369,6 +370,7 @@ static int mt7621_pcie_init_ports(struct mt7621_pcie *pcie) } } + msleep(INIT_PORTS_DELAY_MS); mt7621_pcie_reset_ep_deassert(pcie); tmp = NULL;