Skip to content

Conversation

@DragonBluep
Copy link
Contributor

@DragonBluep DragonBluep commented Nov 11, 2022

Some users report that their Wi-Fi interface is lost after reboot, which may be caused by allocating the wrong pcie port. This commit fixes these wrong ports.

For Netgear R6220, WAC104 and WNDR3700 v5, according to bootlog, MT7612E (5GHz) is connected to pcie0, and MT7603E (2GHz) is connected to pcie2:

[2.758986] mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
[2.772862] mt7621-pci 1e140000.pcie: PCIE0 enabled
[2.782579] mt7621-pci 1e140000.pcie: PCIE2 enabled
...
[3.009151] pci 0000:01:00.0: [14c3:7662] type 00 class 0x028000
[3.125715] pci 0000:02:00.0: [14c3:7603] type 00 class 0x028000

For Zbtlink ZBT-WE1326, according to bootlog, MT7612E (5GHz) is connected to pcie1, and MT7603E (2GHz) is connected to pcie2:

[4.197658] mt7621-pci 1e140000.pcie: pcie0 no card, disable it (RST & CLK)
[4.204609] mt7621-pci 1e140000.pcie: PCIE1 enabled
[4.209476] mt7621-pci 1e140000.pcie: PCIE2 enabled
...
[4.307988] pci 0000:01:00.0: [14c3:7662] type 00 class 0x028000
[4.367206] pci 0000:02:00.0: [14c3:7603] type 00 class 0x028000

OpenWrt Forum Link:
Missing 2.4GHz interface on WAC104 & difficulty setting up forwarding
R6220 ” Could not find PHY for device ‘radio0’” mt76x2 .. issue continues
ZBT-1326 OpenWRT stable 21.02 results in no Wifi

GitHub issues:
openwrt/mt76#199
openwrt/mt76#601
#9374

I have no relevant device to test, but this should be the correct fix.

@github-actions github-actions bot added the target/ramips pull request/issue for ramips target label Nov 11, 2022
@renamed98324
Copy link

renamed98324 commented Nov 12, 2022

Edited because i was trying on kernel 5.10

@DragonBluep
Copy link
Contributor Author

DragonBluep commented Nov 13, 2022

@wifiseguro Can you try the latest patch?
Reference: 6f2c95f 06356f0 af1b679
And #9810 ramips: zbt-wg2626: Add the reset gpio for PCIe port 1

@renamed98324
Copy link

renamed98324 commented Nov 13, 2022

Edited same reason

@DragonBluep
Copy link
Contributor Author

Does your router have a 3G/4G module or other pcie device? I see a pcie slot on the board.
The bootlog I found on the forum shows pcie0 no card, disable it (RST&CLK). So I'm pretty sure we only use pcie1 and pcie2.

@DragonBluep DragonBluep marked this pull request as draft November 14, 2022 01:40
@DragonBluep DragonBluep force-pushed the pr_correct_mt7621_pcie_port branch from 7223919 to cdd1d96 Compare November 14, 2022 02:04
@DragonBluep
Copy link
Contributor Author

Test Firmware: https://we.tl/t-8MWLM0P0W0

@renamed98324
Copy link

renamed98324 commented Nov 14, 2022

edited, i was trying leds patch on 5.10

@DragonBluep
Copy link
Contributor Author

@paraka Can you provide some suggestions? Great thanks!

@paraka
Copy link
Contributor

paraka commented Nov 15, 2022

So normally when the detection fails while the PCI bus is being set up is because one of this two problems:

  • One GPIO has not properly been reset.
  • Time after reseting stuff is not enough.

If the problem is related with timing, the way to go should be to change PERS_DELAY_MS definition 0 since this is the one used after the related resets 1 and 2.

Regarding pcie ports used in dts files (this have sense after phisical ports and link are properly detected), old legacy driver made some changes in configuration registers to map working physical pci ports with virtual devices that linux finally show. This means that in your bootlog pci0 no card, pcie1 enabled and pcie2 enabled are referring to physical pci ports. MT7621 has three assigned interrupts for the pcie. This interrupts should properly being mapped taking into account which devices are finally connected in which bus according to link status (physical detected pcie ports link). So the irq mappings should be as follows according to link status (three bits indicating which devices are link up):

  • For PCIe Bus 1 slot 0:
    • status = 0x2 || status = 0x6 => IRQ = pcie1_irq (24).
    • status = 0x4 => IRQ = pcie2_irq (25).
    • default => IRQ = pcie0_irq (23).
  • For PCIe Bus 2 slot 0:
    • status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25).
    • default => IRQ = pcie1_irq (24).
  • For PCIe Bus 2 slot 1:
    • status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25).
    • default => IRQ = pcie1_irq (24).
  • For PCIe Bus 3 any slot:
    • default => IRQ = pcie2_irq (25).

Old legacy driver used custom IRQ map function avoiding standar 'interrupt-map' and 'interrupt-map-mask' dts properties. New driver suffered some changes because of this along its life in staging kernel area. See 0 where old legacy driver approach was used because the bad understanding of the renamed stuff. And finally 1 and 2 where the properties are used and interrupts are properly mapped along the buses as they are without any kind of internal register configuration. This is important since ports that are used in specific board device tree should properly match to get the devices properly working so if previously with old driver there was a "pcie1 enabled" with a "pcie0 configuration node", now for interrupts to be properly mapped this would become into "pcie1 configuration node" in the new device tree with new driver.

Hope this helps.

@renamed98324
Copy link

So normally when the detection fails while the PCI bus is being set up is because one of this two problems:

  • One GPIO has not properly been reset.
    > * Time after reseting stuff is not enough.

If the problem is related with timing, the way to go should be to change PERS_DELAY_MS definition [0](https://elixir.bootlin.com/linux/v6.1-rc1/source/drivers/pci/controller/pcie-mt7621.c#L63) since this is the one used after the related resets 1 and 2.

What I tried on a ZBT WE1326:
Increased PERS_DELAY_MS definition [0] to 200 ms -> Issue is still there.
Increased PERS_DELAY_MS definition [0] to 400 ms -> Issue Fixed :-)
I belive this might help other devices, not just ZBT WE1326, because applying the DELAY in a similar way (#10985) also fixes the pcie iniatialization for the Netgear R6220
Of course, Paraka's way of applying the delay is the proper way. I will mention there just in case can be changed and done properly.

@dfateyev
Copy link

Could anybody clarify whether we need DTS changes for the devices (proposed in this PR) if we introduce PERST_DELAY_MS value increase?

@paraka
Copy link
Contributor

paraka commented Nov 19, 2022

What I tried on a ZBT WE1326: Increased PERS_DELAY_MS definition [0] to 200 ms -> Issue is still there. Increased PERS_DELAY_MS definition [0] to 400 ms -> Issue Fixed :-)

Thanks for letting me know. I have just sent a patch increasing this value to 500 ms to the mainline [0]. Hope this helps!

[0]: https://lore.kernel.org/linux-pci/20221119110837.2419466-1-sergio.paracuellos@gmail.com/T/#u

@paraka
Copy link
Contributor

paraka commented Nov 19, 2022

Could anybody clarify whether we need DTS changes for the devices (proposed in this PR) if we introduce PERST_DELAY_MS value increase?

DTS changes are not related with pcie port detection but for the correct way interrupts are expanded along the PCI bus once are properly detected since new driver in use now use interrupt-maps and interrupt-map-mask properties in general mt7621.dtsi file. If your problem is with initial detection only bad gpio reset or a timing issue applies, AFAICT.

@renamed98324
Copy link

renamed98324 commented Nov 19, 2022

What I tried on a ZBT WE1326: Increased PERS_DELAY_MS definition 0 to 200 ms -> Issue is still there. Increased PERS_DELAY_MS definition 0 to 400 ms -> Issue Fixed :-)

Thanks for letting me know. I have just sent a patch increasing this value to 500 ms to the mainline 0. Hope this helps!

First of all, thanks for all your work and explanations, it really means a lot to me
Today Ive been doing a lot of tests to be sure we are sending the right patch, dont wanna rush to have it in the mainline if I am not sure that we really found a solution, after all, I've been suffering this issue for many yeas(I have been applying a patch to my own builds that worked flawless though), but having a fix in the mainline is far more satisfacing and many other can benefit of it.
Well, lets explain the tests I've done today, hoping you can help to figure out:

1 - I first tried a build with a 400ms delay, then 500 and finally 750 ms patch and the issue was gone. So why I was trying longer delays if 400ms was enough? The reason is weird: when I warm reboot the device using Luci o reboot command, the issue is back. If I cold reboot, removing the power adaptor and waiting a few seconds there is no issue detecting both pcie cards. Weird isn't it?
After doing many cold and warm reboots to be sure that this behaviour is repetitive, I decided to try again my previous patch, which has been working many years with no issue, no matter I warm or cold reboot.
So I restore the PERS_DELAY_MS to 100ms and I decide to dig a bit on my own patch, and I dont understand why, but the conclusion, also after many reboots with this patch, was that my device needs just 75ms delay!, but placed in a diferent place of the firmware code.
I am putting just 75 ms delay right before function mt7621_pcie_reset_ep_deassert(pcie) and that fixes 2.4 pcie card detection, as I told, in this case no matter I cold or warm reboot the device.
My previous version of the patch was applying a 250 ms delay, not only where I mentioned but also after the resets, just like the PERS_DELAY_MS does. Though definitelly are not necessary in my device, and dont make any diferrence.
Hope this is worth to send a patch, at least to be applied to the zbt we1326 device.

This is how the patch looks like:

--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -520,6 +520,7 @@
list_del(&port->list);
}
}
+ mdelay(75);

mt7621_pcie_reset_ep_deassert(pcie);

I hope I have explained this case properly (my native languaje is spanish)
I look forward your comments.

@renamed98324
Copy link

Could anybody clarify whether we need DTS changes for the devices (proposed in this PR) if we introduce PERST_DELAY_MS value increase?

At least, on my zbt we1326 device is not needed. It just soft briks the device.

@paraka
Copy link
Contributor

paraka commented Nov 20, 2022

@wifiseguro Does changing mdelay with msleep and putting inside mt7621_pcie_reset_rc_deassert function works for you in both warn and cold resets? Something like the following:

@@ -332,6 +332,8 @@ static void mt7621_pcie_reset_rc_deassert(struct mt7621_pcie *pcie)
 
        list_for_each_entry(port, &pcie->ports, list)
                mt7621_control_deassert(port);
+
+       msleep(PERST_DELAY_MS);
 }
 
 static void mt7621_pcie_reset_ep_deassert(struct mt7621_pcie *pcie)

@renamed98324
Copy link

@wifiseguro Does changing mdelay with msleep and putting inside mt7621_pcie_reset_rc_deassert function works for you in both warn and cold resets? Something like the following:

@@ -332,6 +332,8 @@ static void mt7621_pcie_reset_rc_deassert(struct mt7621_pcie *pcie)
 
        list_for_each_entry(port, &pcie->ports, list)
                mt7621_control_deassert(port);
+
+       msleep(PERST_DELAY_MS);
 }
 
 static void mt7621_pcie_reset_ep_deassert(struct mt7621_pcie *pcie)

I have just build with that patch. Results:
On first boot right after flashing: Both radios came up.
When I reboot, tried several times cold and warm, just one radio come up.
There is a detail I want to mention:
When no patch is applied, no msdelay, no msleep, Luci shows only one card, MT76x2E 802.11bgnac.
And when I apply one of the differents patches, on warm reboot, Luci shows a Generic bgn card, instead of MT7603E.
Despite logs show same error in both cases:

Sat Sep 10 11:03:30 2022 kern.err kernel: [ 1.288233] mt7621-pci 1e140000.pcie: pcie0 no card, disable it (RST & CLK)
Sat Sep 10 11:03:30 2022 kern.err kernel: [ 1.295165] mt7621-pci 1e140000.pcie: pcie2 no card, disable it (RST & CLK)
Sat Sep 10 11:03:30 2022 kern.info kernel: [ 1.302113] mt7621-pci 1e140000.pcie: PCIE1 enabled

Luci Generic bg
Captura desde 2022-11-20 11-31-47

Luci no card at all
Captura desde 2022-11-20 11-39-59

@DragonBluep
Copy link
Contributor Author

@wifiseguro Can you test again with the second commit in this PR ramips: overwrite reset gpio properties in ZBT WE1326 and your delay patch.

@paraka
Copy link
Contributor

paraka commented Nov 20, 2022

@wifiseguro Weird... It looks like your HW needs to wait a bit after making the phy_power-on of the physical port... Does your patch work if you replace mdelay with msleep?

@renamed98324
Copy link

@wifiseguro Can you test again with the second commit in this PR ramips: overwrite reset gpio properties in ZBT WE1326 and your delay patch.

Built as suggested, with second commit "overwrite reset gpio properties" and my delay patch (75ms delay before mt7621_pcie_reset_ep_deassert(pcie) function.)
Result:
Device working properly no issue of any kind. And I can warm or cold reboot with no issues either.
I Don't know what the "reset gpio" does but for sure my device is a little better now.
Thank you!

@renamed98324
Copy link

renamed98324 commented Nov 20, 2022

@wifiseguro Weird... It looks like your HW needs to wait a bit after making the phy_power-on of the physical port... Does your patch work if you replace mdelay with msleep?

@paraka
Built with msleep and the patch works. All issues are gone with msleep too. :-)
Would it be "msleep" a more proper way to fix it?

@renamed98324
Copy link

renamed98324 commented Nov 20, 2022

Could anybody clarify whether we need DTS changes for the devices (proposed in this PR) if we introduce PERST_DELAY_MS value increase?

At least, on my zbt we1326 device is not needed. It just soft briks the device.

@DragonBluep @dfateyev
Are there any recent changes in the DTS update to correct the pcie port number for zbt we1326?
I wonder because I have just built and now it does boot, but it doesn't detect any card, consequentelly LUCI shows no wireless menu.

image

Sun Nov 13 17:11:41 2022 kern.err kernel: [ 1.367603] mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
Sun Nov 13 17:11:41 2022 kern.err kernel: [ 1.374554] mt7621-pci 1e140000.pcie: pcie2 no card, disable it (RST & CLK)
Sun Nov 13 17:11:41 2022 kern.err kernel: [ 1.381500] mt7621-pci 1e140000.pcie: Nothing is connected in virtual bridges. Exiting...

Also there is no pcie0 in the logs (the DTS declares it as "disabled", so in case I attach a card to it it wouldn't be available, Am I right?
Note I have built with both commits and the msleep(75) patch

@DragonBluep DragonBluep force-pushed the pr_correct_mt7621_pcie_port branch from cdd1d96 to 7ecd405 Compare November 21, 2022 03:07
@DragonBluep
Copy link
Contributor Author

DragonBluep commented Nov 21, 2022

@wifiseguro This change will only take effect on 5.15 kernel.

See 0 where old legacy driver approach was used because the bad understanding of the renamed stuff. And finally 1 and 2 where the properties are used and interrupts are properly mapped along the buses as they are without any kind of internal register configuration.

It seems that interrupt-map have been configured correctly. I'm still not clear about it.

pcie: pcie@1e140000 {
compatible = "mediatek,mt7621-pci";
reg = <0x1e140000 0x100>, /* host-pci bridge registers */
<0x1e142000 0x100>, /* pcie port 0 RC control registers */
<0x1e143000 0x100>, /* pcie port 1 RC control registers */
<0x1e144000 0x100>; /* pcie port 2 RC control registers */
#address-cells = <3>;
#size-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
device_type = "pci";
#ifdef DTS_LEGACY
ranges = <0x02000000 0 0x00000000 0x60000000 0 0x10000000>, /* pci memory */
<0x01000000 0 0x00000000 0x1e160000 0 0x00010000>; /* io space */
#else
ranges = <0x02000000 0 0x60000000 0x60000000 0 0x10000000>, /* pci memory */
<0x01000000 0 0x00000000 0x1e160000 0 0x00010000>; /* io space */
#endif
status = "disabled";
#ifdef DTS_LEGACY
interrupt-parent = <&gic>;
interrupts = <GIC_SHARED 4 IRQ_TYPE_LEVEL_HIGH
GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH
GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;
resets = <&rstctrl 24>, <&rstctrl 25>, <&rstctrl 26>;
reset-names = "pcie0", "pcie1", "pcie2";
clocks = <&clkctrl 24>, <&clkctrl 25>, <&clkctrl 26>;
clock-names = "pcie0", "pcie1", "pcie2";
phys = <&pcie0_phy 1>, <&pcie2_phy 0>;
phy-names = "pcie-phy0", "pcie-phy2";
#else
#interrupt-cells = <1>;
interrupt-map-mask = <0xF800 0 0 0>;
interrupt-map = <0x0000 0 0 0 &gic GIC_SHARED 4 IRQ_TYPE_LEVEL_HIGH>,
<0x0800 0 0 0 &gic GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>,
<0x1000 0 0 0 &gic GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;
#endif
reset-gpios = <&gpio 19 GPIO_ACTIVE_LOW>;
pcie0: pcie@0,0 {
reg = <0x0000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges;
#ifndef DTS_LEGACY
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SHARED 4 IRQ_TYPE_LEVEL_HIGH>;
resets = <&rstctrl 24>;
clocks = <&sysc MT7621_CLK_PCIE0>;
phys = <&pcie0_phy 1>;
phy-names = "pcie-phy0";
#endif
};
pcie1: pcie@1,0 {
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges;
#ifndef DTS_LEGACY
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>;
resets = <&rstctrl 25>;
clocks = <&sysc MT7621_CLK_PCIE1>;
phys = <&pcie0_phy 1>;
phy-names = "pcie-phy1";
#endif
};
pcie2: pcie@2,0 {
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges;
#ifndef DTS_LEGACY
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;
resets = <&rstctrl 26>;
clocks = <&sysc MT7621_CLK_PCIE2>;
phys = <&pcie2_phy 0>;
phy-names = "pcie-phy2";
#endif

OpenWrt use DTS_LEGACY to ensure that the correct properties are provided for the new pcie driver.

ifdef CONFIG_LINUX_5_10
DTS_CPPFLAGS += -DDTS_LEGACY
endif

@paraka
Copy link
Contributor

paraka commented Nov 21, 2022

@wifiseguro Weird... It looks like your HW needs to wait a bit after making the phy_power-on of the physical port... Does your patch work if you replace mdelay with msleep?

@paraka Built with msleep and the patch works. All issues are gone with msleep too. :-) Would it be "msleep" a more proper way to fix it?

@wifiseguro Kernel maintainers prefer to use msleep where possible when patches are submited, so I needed to know.

@DragonBluep BTW, Does the netgear router also affected with similar issue work with this msleep or PERS_DELAY value needs also to be set to 250???

ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 8, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this pull request Mar 10, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this pull request Mar 10, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 10, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Mar 10, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ionutnechita pushed a commit to sunlightlinux/linux-sunlight that referenced this pull request Mar 19, 2023
[ Upstream commit 0cb2a8f ]

Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

The delay required to detect the ports seems to be in the range [75-100]
milliseconds.

If the ports are not detected the controller is not functional.

There is no datasheet or something similar to really understand why this
extra delay is needed only for these devices and it is not for most of
the boards that are built on mt7621 SoC.

This issue has been reported by openWRT community and the complete
discussion is in [0]. The 100 milliseconds delay has been tested in all
devices to validate it.

Add the extra 100 milliseconds delay to fix the issue.

[0]: openwrt/openwrt#11220

Link: https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuellos@gmail.com
Fixes: 2bdd523 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@DragonBluep
Copy link
Contributor Author

@paraka A feedback: MT7915 datasheet said PERST_N need to keep low for at least 500 ms to reset the chip. I think this is the reason why additional delay is needed (MT7603 and MT7612 should also require the same time).
https://edit.wpgdadawant.com/uploads/news_file/blog/2020/2406/tech_files/blog_2406_suggest_other_file.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

target/ramips pull request/issue for ramips target

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants