diff mbox series

[7/9] net: Remove CONFIG_BOOTP_DHCP_REQUEST_DELAY

Message ID 20220225161953.1342594-7-trini@konsulko.com
State Accepted
Commit f0171e7ea79b73689a2a82f5c2826e22b2fda2af
Delegated to: Tom Rini
Headers show
Series [1/9] Convert CONFIG_BIOSEMU to Kconfig | expand

Commit Message

Tom Rini Feb. 25, 2022, 4:19 p.m. UTC
This option is not in use anywhere and the documentation implies it's
for some very old and unlikely to be seen currently issues.  Rather than
update the code so the CONFIG symbol could be easily in Kconfig, remove
the code.

Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
 README      | 14 --------------
 net/bootp.c |  3 ---
 2 files changed, 17 deletions(-)

Comments

Ramon Fried March 3, 2022, 7:54 a.m. UTC | #1
On Fri, Feb 25, 2022 at 6:20 PM Tom Rini <trini@konsulko.com> wrote:
>
> This option is not in use anywhere and the documentation implies it's
> for some very old and unlikely to be seen currently issues.  Rather than
> update the code so the CONFIG symbol could be easily in Kconfig, remove
> the code.
>
> Cc: Ramon Fried <rfried.dev@gmail.com>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
>  README      | 14 --------------
>  net/bootp.c |  3 ---
>  2 files changed, 17 deletions(-)
>
> diff --git a/README b/README
> index e7b2f83651c3..6bb8d6e25bdc 100644
> --- a/README
> +++ b/README
> @@ -1173,20 +1173,6 @@ The following options need to be configured:
>
>  - DHCP Advanced Options:
>
> -               CONFIG_BOOTP_DHCP_REQUEST_DELAY
> -
> -               A 32bit value in microseconds for a delay between
> -               receiving a "DHCP Offer" and sending the "DHCP Request".
> -               This fixes a problem with certain DHCP servers that don't
> -               respond 100% of the time to a "DHCP request". E.g. On an
> -               AT91RM9200 processor running at 180MHz, this delay needed
> -               to be *at least* 15,000 usec before a Windows Server 2003
> -               DHCP server would reply 100% of the time. I recommend at
> -               least 50,000 usec to be safe. The alternative is to hope
> -               that one of the retries will be successful but note that
> -               the DHCP timeout and retry process takes a longer than
> -               this delay.
> -
>   - Link-local IP address negotiation:
>                 Negotiate with other link-local clients on the local network
>                 for an address that doesn't require explicit configuration.
> diff --git a/net/bootp.c b/net/bootp.c
> index d83e4eb0ba9e..a896e1e5b546 100644
> --- a/net/bootp.c
> +++ b/net/bootp.c
> @@ -1038,9 +1038,6 @@ static void dhcp_send_request_packet(struct bootp_hdr *bp_offer)
>         bcast_ip.s_addr = 0xFFFFFFFFL;
>         net_set_udp_header(iphdr, bcast_ip, PORT_BOOTPS, PORT_BOOTPC, iplen);
>
> -#ifdef CONFIG_BOOTP_DHCP_REQUEST_DELAY
> -       udelay(CONFIG_BOOTP_DHCP_REQUEST_DELAY);
> -#endif /* CONFIG_BOOTP_DHCP_REQUEST_DELAY */
>         debug("Transmitting DHCPREQUEST packet: len = %d\n", pktlen);
>         net_send_packet(net_tx_packet, pktlen);
>  }
> --
> 2.25.1
>
Acked-by: Ramon Fried <rfried.dev@gmail.com>
Tom Rini March 4, 2022, 6:13 p.m. UTC | #2
On Fri, Feb 25, 2022 at 11:19:51AM -0500, Tom Rini wrote:

> This option is not in use anywhere and the documentation implies it's
> for some very old and unlikely to be seen currently issues.  Rather than
> update the code so the CONFIG symbol could be easily in Kconfig, remove
> the code.
> 
> Cc: Ramon Fried <rfried.dev@gmail.com>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> Acked-by: Ramon Fried <rfried.dev@gmail.com>

Applied to u-boot/next, thanks!
diff mbox series

Patch

diff --git a/README b/README
index e7b2f83651c3..6bb8d6e25bdc 100644
--- a/README
+++ b/README
@@ -1173,20 +1173,6 @@  The following options need to be configured:
 
 - DHCP Advanced Options:
 
-		CONFIG_BOOTP_DHCP_REQUEST_DELAY
-
-		A 32bit value in microseconds for a delay between
-		receiving a "DHCP Offer" and sending the "DHCP Request".
-		This fixes a problem with certain DHCP servers that don't
-		respond 100% of the time to a "DHCP request". E.g. On an
-		AT91RM9200 processor running at 180MHz, this delay needed
-		to be *at least* 15,000 usec before a Windows Server 2003
-		DHCP server would reply 100% of the time. I recommend at
-		least 50,000 usec to be safe. The alternative is to hope
-		that one of the retries will be successful but note that
-		the DHCP timeout and retry process takes a longer than
-		this delay.
-
  - Link-local IP address negotiation:
 		Negotiate with other link-local clients on the local network
 		for an address that doesn't require explicit configuration.
diff --git a/net/bootp.c b/net/bootp.c
index d83e4eb0ba9e..a896e1e5b546 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -1038,9 +1038,6 @@  static void dhcp_send_request_packet(struct bootp_hdr *bp_offer)
 	bcast_ip.s_addr = 0xFFFFFFFFL;
 	net_set_udp_header(iphdr, bcast_ip, PORT_BOOTPS, PORT_BOOTPC, iplen);
 
-#ifdef CONFIG_BOOTP_DHCP_REQUEST_DELAY
-	udelay(CONFIG_BOOTP_DHCP_REQUEST_DELAY);
-#endif	/* CONFIG_BOOTP_DHCP_REQUEST_DELAY */
 	debug("Transmitting DHCPREQUEST packet: len = %d\n", pktlen);
 	net_send_packet(net_tx_packet, pktlen);
 }