[PATCH] net: lwip: dns depend on enabled protocol config instead of command

Quentin Schulz quentin.schulz at cherry.de
Fri Jul 18 15:25:31 CEST 2025


Hi Jerome, E,

On 7/18/25 12:29 PM, Jerome Forissier wrote:
> Hi E,
> 
> On 7/14/25 03:52, E Shattow wrote:
>>
>>
>> On 7/11/25 22:01, E Shattow wrote:
>>> Allow dns when enabled CONFIG_PROT_DNS_LWIP=y CONFIG_CMD_DNS=n
>>>
>>> Fixes: a383869d6b58 ("net: lwip: move dns init to common function")
>>> Signed-off-by: E Shattow <e at freeshell.de>
>>> ---
>>>   net/lwip/net-lwip.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/lwip/net-lwip.c b/net/lwip/net-lwip.c
>>> index 3918d57d7e5..5d247c3721b 100644
>>> --- a/net/lwip/net-lwip.c
>>> +++ b/net/lwip/net-lwip.c
>>> @@ -147,7 +147,7 @@ static int get_udev_ipv4_info(struct udevice *dev, ip4_addr_t *ip,
>>>    */
>>>   int net_lwip_dns_init(void)
>>>   {
>>> -#if CONFIG_IS_ENABLED(CMD_DNS)
>>> +#if CONFIG_IS_ENABLED(PROT_DNS_LWIP)
>>>   	bool has_server = false;
>>>   	ip_addr_t ns;
>>>   	char *nsenv;
>>>
>>> base-commit: 6bb0679377abb01a82db1ce69b5bf1d40aa02ace
> 
> I think the proper way is to introduce a new "DNS" Kconfig symbol to
> differentiate between DNS support and the DNS command itself. PROT_DNS_LWIP
> should remain an internal symbol not exposed to the user and selected
> automatically when DNS is enabled. DNS would apply to both NET and NET_LWIP.
> 
> We already have a similar mechanism in place for WGET and CMD_WGET.
> 
>>
>> Postscript: There was recently a U-Boot release and the above patch only
>> applies to origin/master (is apparently not needed or applicable to
>> origin/next). However on origin/next there are similar troubles where
>> DNS is disabled unless the dns command is enabled in several network
>> commands, which is something I can test for but am not the expert to
>> make a patch or suggestion for.
> 
> IIUC origin/next is not the proper reference at this point in the release
> cycle, so I would say it doesn't matter.
> 

next is pushed only after -rc2. We are currently in the merge window, so 
master is the target for patches, c.f. 
https://docs.u-boot.org/en/latest/develop/release_cycle.html#release-cycle

Cheers,
Quentin


More information about the U-Boot mailing list