diff mbox series

[1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

Message ID 1584475636-24521-2-git-send-email-twarren@nvidia.com
State Accepted
Commit a7a435e7d41db6a611427b4cc5fd506a18fb2c2f
Headers show
Series net: tegra: Misc network fixes | expand

Commit Message

Tom Warren March 17, 2020, 8:07 p.m. UTC
From: Tom Warren <twarren at nvidia.com>

This is a WAR for DHCP failure after rebooting from the L4T kernel. The
r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0,
which goes by FuncEvent and MISC in various driver source/datasheets.
That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it
here at the end of probe to ensure that U-Boot can get an IP assigned
via DHCP.

Signed-off-by: Tom Warren <twarren at nvidia.com>
---
 drivers/net/rtl8169.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Comments

Stephen Warren March 18, 2020, 11:29 p.m. UTC | #1
On 3/17/20 2:07 PM, twarren at nvidia.com wrote:
> From: Tom Warren <twarren at nvidia.com>
> 
> This is a WAR for DHCP failure after rebooting from the L4T kernel. The
> r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0,
> which goes by FuncEvent and MISC in various driver source/datasheets.
> That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it
> here at the end of probe to ensure that U-Boot can get an IP assigned
> via DHCP.

Is there a way to reset the entire chip back to power-on state instead,
just to make sure there aren't any other register bits that might cause
issues in the future?

Does this bit exist in all the different chips that the driver supports?
IIRC at least the Linux r8169 driver supports many different similar
chips; I'm not sure if the U-Boot driver does too. Since this driver is
shared between many boards in U-Boot, we need to make sure this change
doesn't break anyone using a different Realtek chip to the exact one we
use on Jetson.

We need to send this patch to the network maintainers so they're aware
of it, and they'll probably want to apply it.

> @@ -1207,6 +1210,19 @@ static int rtl8169_eth_probe(struct udevice *dev)

> +	u32 val = RTL_R32(FuncEvent);
> +	debug("%s: FuncEvent/Misc (0xF0) = 0x%08X\n", __func__, val);
> +	val &= ~RxDv_Gated_En;
> +	RTL_W32(FuncEvent, val);

I vagueley recall that U-Boot coding style wants variables declared at
the start of the block, but perhaps that's no longer true. What does
scripts/checkpatch.pl say?
Tom Warren March 18, 2020, 11:51 p.m. UTC | #2
-----Original Message-----
From: Stephen Warren <swarren at wwwdotorg.org> 
Sent: Wednesday, March 18, 2020 4:30 PM
To: Tom Warren <TWarren at nvidia.com>
Cc: u-boot at lists.denx.de; Stephen Warren <swarren at nvidia.com>; Thierry Reding <treding at nvidia.com>; Jonathan Hunter <jonathanh at nvidia.com>; tomcwarren3959 at gmail.com
Subject: Re: [PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

External email: Use caution opening links or attachments


On 3/17/20 2:07 PM, twarren at nvidia.com wrote:
> From: Tom Warren <twarren at nvidia.com>
>
> This is a WAR for DHCP failure after rebooting from the L4T kernel. 
> The r8169.c kernel driver is setting bit 19 of the rt816x HW register 
> 0xF0, which goes by FuncEvent and MISC in various driver source/datasheets.
> That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear 
> it here at the end of probe to ensure that U-Boot can get an IP 
> assigned via DHCP.

Is there a way to reset the entire chip back to power-on state instead, just to make sure there aren't any other register bits that might cause issues in the future?
[Tom] Maybe, I'll have to look at the RTL spec, it's been awhile since I came up with this WAR.

Does this bit exist in all the different chips that the driver supports?
IIRC at least the Linux r8169 driver supports many different similar chips; I'm not sure if the U-Boot driver does too. Since this driver is shared between many boards in U-Boot, we need to make sure this change doesn't break anyone using a different Realtek chip to the exact one we use on Jetson.
[Tom] I'll look into it after I get Nano patches all in place upstream. If anyone runs into the problem described here w/no IP on net boot, they can use this as a WAR until I try for a more robust fix.

We need to send this patch to the network maintainers so they're aware of it, and they'll probably want to apply it.
[Tom] Will do.

> @@ -1207,6 +1210,19 @@ static int rtl8169_eth_probe(struct udevice 
> *dev)

> +     u32 val = RTL_R32(FuncEvent);
> +     debug("%s: FuncEvent/Misc (0xF0) = 0x%08X\n", __func__, val);
> +     val &= ~RxDv_Gated_En;
> +     RTL_W32(FuncEvent, val);

I vagueley recall that U-Boot coding style wants variables declared at the start of the block, but perhaps that's no longer true. What does scripts/checkpatch.pl say?
[Tom] I don't recall, I'll run it again and see.


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Thierry Reding March 19, 2020, 8:03 a.m. UTC | #3
On Tue, Mar 17, 2020 at 01:07:15PM -0700, twarren at nvidia.com wrote:
> From: Tom Warren <twarren at nvidia.com>
> 
> This is a WAR for DHCP failure after rebooting from the L4T kernel. The
> r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0,
> which goes by FuncEvent and MISC in various driver source/datasheets.
> That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it
> here at the end of probe to ensure that U-Boot can get an IP assigned
> via DHCP.
> 
> Signed-off-by: Tom Warren <twarren at nvidia.com>
> ---
>  drivers/net/rtl8169.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)

Is this still needed? In my old p3450 branch that I worked on to get
Porg up and running I don't have this patch. It's also not in my local
development tree that I typically use to boot Tegra186 and earlier
boards. That branch works fine on the Jetson Nano, so I don't think this
is needed anymore. I vaguely recall that I determined that this was
fixed some other way, but unfortunately I don't remember the exact
details.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200319/f36936dc/attachment.sig>
Tom Warren March 19, 2020, 3:42 p.m. UTC | #4
-----Original Message-----
From: Thierry Reding <treding at nvidia.com> 
Sent: Thursday, March 19, 2020 1:04 AM
To: Tom Warren <TWarren at nvidia.com>
Cc: u-boot at lists.denx.de; Stephen Warren <swarren at nvidia.com>; Jonathan Hunter <jonathanh at nvidia.com>; tomcwarren3959 at gmail.com
Subject: Re: [PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

On Tue, Mar 17, 2020 at 01:07:15PM -0700, twarren at nvidia.com wrote:
> From: Tom Warren <twarren at nvidia.com>
> 
> This is a WAR for DHCP failure after rebooting from the L4T kernel. 
> The r8169.c kernel driver is setting bit 19 of the rt816x HW register 
> 0xF0, which goes by FuncEvent and MISC in various driver source/datasheets.
> That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear 
> it here at the end of probe to ensure that U-Boot can get an IP 
> assigned via DHCP.
> 
> Signed-off-by: Tom Warren <twarren at nvidia.com>
> ---
>  drivers/net/rtl8169.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)

Is this still needed? In my old p3450 branch that I worked on to get Porg up and running I don't have this patch. It's also not in my local development tree that I typically use to boot Tegra186 and earlier boards. That branch works fine on the Jetson Nano, so I don't think this is needed anymore. I vaguely recall that I determined that this was fixed some other way, but unfortunately I don't remember the exact details.

Thierry
[Tom] I'll retest as part of my Nano rework of your original patch, Thierry. So you've done network boot, then rebooted from the kernel (sudo reboot), and attempted net boot again and seen it work OK, w/an IP assigned by DHCP, etc.? (not static IP).  It's also possible that something in the kernel RT8169 driver has changed, and it's not setting the bit anymore.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
diff mbox series

Patch

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 5ccdfdd..ff89e28 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -237,6 +237,9 @@  enum RTL8169_register_content {
 
 	/*_TBICSRBit*/
 	TBILinkOK = 0x02000000,
+
+	/* FuncEvent/Misc */
+	RxDv_Gated_En = 0x80000,
 };
 
 static struct {
@@ -1207,6 +1210,19 @@  static int rtl8169_eth_probe(struct udevice *dev)
 		return ret;
 	}
 
+	/*
+	 * WAR for DHCP failure after rebooting from kernel.
+	 * Clear RxDv_Gated_En bit which was set by kernel driver.
+	 * Without this, U-Boot can't get an IP via DHCP.
+	 * Register (FuncEvent, aka MISC) and RXDV_GATED_EN bit are from
+	 * the r8169.c kernel driver.
+	 */
+
+	u32 val = RTL_R32(FuncEvent);
+	debug("%s: FuncEvent/Misc (0xF0) = 0x%08X\n", __func__, val);
+	val &= ~RxDv_Gated_En;
+	RTL_W32(FuncEvent, val);
+
 	return 0;
 }