ivmarkov

Can you describe a bit your specific use case, and in particular - why dropping and re-creating the driver would not work for your case?

PR for light/deep sleep greatly appreciated! Please start simple, and then we can refine the PR with discussion / suggestions. Note that the raw ESP IDF APIs for light/deep sleep...

> [embedded-svc](https://github.com/esp-rs/embedded-svc) is meant to be completely unaware of esp-idf, so I don't think we should be changing this struct to fit esp-idf's alignment needs unless there is another valid...

Sorry for the delay here. Will look at it over the weekend.

> Actually I just realized that if I do this so that EspWifi isn't borrowed for the lifetime of the object that handles esp_supp_dpp_init/deinit then we could end up unsafely...

> Ackd, I think the right compromise here is to have a member of EspWifi that you can borrow to access esp_supp_dpp_*. I'll still keep the code in wifi_dpp.rs so...

> Thanks, I'll iterate a bit on my end and update the PR when it's ready for you to look again. > > FWIW, the DPP lifecycle is pretty mysterious...

> This is my understanding as well. Rust is unaware of this because we don't have targets for the new architecture (which ofc aren't really new but for our purposes...

@jasta Yes, sorry for the noise. I've moved my comment to the issue here: https://github.com/esp-rs/esp-idf-sys/issues/176

@jasta Very sorry for having you wait for so long for my feedback!