embassy time driver appears to be unsound

[TheButlah]

I was attempting to use esp-wifi along with esp32c3-hal and was worried that esp wifi might need peripherals used by the embassy time driver.

To my pleasant surprise, I saw that initializing embassy appears to not need any ownership over the peripheral:

esp-hal/esp32c3-hal/examples/embassy_hello_world.rs

Line 41 in 096ff34

embassy::init(&clocks);

However, I was confused when I realized that I was able to use the embassy timer even without calling the init method. To further my confusion, I found this in the hal code:

esp-hal/esp-hal-common/src/embassy/time_driver_systimer.rs

Lines 21 to 26 in 096ff34

	embassy_time::time_driver_impl!(static DRIVER: EmbassyTimer = EmbassyTimer {
	alarms: Mutex::new([ALARM_STATE_NONE; ALARM_COUNT]),
	alarm0: unsafe { Alarm::<_, 0>::conjure() },
	alarm1: unsafe { Alarm::<_, 1>::conjure() },
	alarm2: unsafe { Alarm::<_, 2>::conjure() },
	});

I am not knowledgeable on the safety of this, but from my inexperienced perspective, this implies that esp-hal is lying to me about the peripherals its using. Instead of passing the alarm peripherals explicitly into the embassy::init() method, they are being manufactured into existance via the dark arts of unsafe.

My question is: Is the current implementation unsound? Can I use alarm0 in esp-wifi or something else that needs the alarm? Is this leaving me vulnerable to race conditions (not just data races!) in the state of the peripheral?

[MabezDev]

Yeah, this is probably an oversight, thanks for bringing it up! We can just change the signature of init depending on the feature flag enabled.