What's with the GNRC dependencies in the driver code?

@miri64 The fix can be tested without having the hardware. If the compilations succeed, there is no further dependency on gnrc.

I hope it is Ok, that I'm pushing another very small fix related to lwip with this PR. The call of esp_wifi_setup has to be placed outside the conditional compilation. Otherwise, esp_wifi_netdev is not initialized for lwip_ipv4.

What's with the GNRC dependencies in the driver code?

Are there any? Hm, I will check again, but the compilations didn't complain.

Indeed, when auto_init is enabled.

Could it happen that auto_init_... is called without having gnrc enabled?

I suggest to put the gnrc_netif initialization into auto_init_gnrc_netif as all the rest. The gnrc_netif_t (if it is needed by the device for some reason) should be a more generic context: either a pointer to a netif_t instead or just a void pointer (the latter would be preferable as not every stack might use netif_t

Could it happen that auto_init_... is called without having gnrc enabled?

auto_init_gnrc_netif shouldn't be, but auto_init can be used without GNRC of course.

Hm, es simple #if MODULE_GNRC wrapper should help.

Hm, es simple #if MODULE_GNRC wrapper should help.

Yepp as a quick-fix this is also acceptable. However, I think in the long run the device / network interface initialization should be unified across all devices.

Rather use #ifdef MODULE_GNRC_NETIF or MODULE_GNRC_NETIF_ETHERNET (so the least broadest dependency)

I suggest to put the gnrc_netif initialization into auto_init_gnrc_netif as all the rest.

I was a bit unsure whether sys/auto_init/netif is the right location for platform specific initializations. The only other architecture I can see there is STM32.

Do you think that such a change would be good for this PR? I can do it.

The gnrc_netif_t (if it is needed by the device for some reason)

To be honest, I don't remember for what porpose the network devices have this gnrc_netif_t pointer at all. The netif is assigned during setup but never used. I will remove them.

Do you think that such a change would be good for this PR? I can do it.

The only other SoC-network device which has the init code not in auto_init_gnrc_netif seems to be nrfmin. However for that the GNRC code is separate from the device code (including the init function). I'd say it is cleaner to have it with the CPU-specific code (as you don't need to hand it parameters), but put it into a GNRC-specific context (e.g. esp_..._gnrc.c).

I'd say it is cleaner to have it with the CPU-specific code (as you don't need to hand it parameters), but put it into a GNRC-specific context (e.g. esp_..._gnrc.c).

I will do it in that way.

The longer I'm crawling through sys/auto_init/netif the more I'm wondering why it is for gnrc only? At least it is not really name giving, neither function name auto_init_* nor the directory nor the file names

I have removed the gnrc_netif_t pointer in netdevs and moved the auto intialization for gnrc in separate files called esp_*_gnrc.c.

The longer I'm crawling through sys/auto_init/netif the more I'm wondering why it is for gnrc only? At least it is not really name giving, neither function name auto_init_* nor the directory nor the file names

Mostly historical reasons. ^^" Hopefully, this will be a bit cleaner after @jia200x's rework :-)

@miri64 have your comments been addressed?

• esp_now: make BOARD=esp32-wroom-32 -C tests/lwip

With this I end up with an empty ifconfig output - is that to be expected?
I get something with USEMODULE=esp_wifi

(No IP in examples/gnrc_networking, but that's a known behavior SLAAC not activated…, I still get some interface information)

@miri64 have your comments been addressed?

Which ones are you referring to? From what I can see above, I'd say yes.

• esp_now: make BOARD=esp32-wroom-32 -C tests/lwip

With this I end up with an empty ifconfig output - is that to be expected?
I get something with USEMODULE=esp_wifi

Yes. esp-now isn't know as netdev driver in pkg/lwip/contrib. That is, there can't be a lwIP netif.

The tests are compilation tests only to prove that gnrc modules are not enabled if one of these netdev drivers is enabled.

Alright, then I'd say everything works as expected.
I didn't test esp_eth, but I assume you tested this already.
The code looks good - please squash.

(No IP in examples/gnrc_networking, but that's a known behavior SLAAC not activated…, I still get some interface information)

Yes, because it is not rebased onto a version with merged PR #12998.

@benpicco Please wait, I just squashed and pushed a wrong branch. I had cherry picks from other PR in my branch that were merged in the meantime.

@benpicco I have rebased and squashed. Everything is fine now.

@benpicco Thanks for reviewing, testing and merging.