applications: nrf_desktop: Prevent enabling HF clock lock on nRF54H

Add a Kconfig dependency to prevent enabling HF clock lock on nRF54H SoC
Series. The hotfix does not support this SoC Series. The commit also
improves Kconfig help of the option.

Jira: NCSDK-29545

Signed-off-by: Marek Pieta <[email protected]>
(cherry picked from commit 09b01f0)

Author: MarekPieta

applications/nrf_desktop/src/modules/Kconfig.hotfixes

@@ -8,12 +8,24 @@ menu "Hotfix set"
 
 config DESKTOP_HFCLK_LOCK_ENABLE
 	bool "Keep HF clock enabled"
+	depends on !SOC_SERIES_NRF54HX
 	help
-	  Keeping the HF clock enabled is needed to reduce the latency before
-	  the first packet (in a row) is transmitted over the BLE.
-	  If disabled a startup delay of around 1.5 ms will be added to
-	  overall latency of the first packet.
-	  If enabled current consumption is increased.
+	  The HF clock needs to be enabled during data transmission over BLE.
+	  Enabling the HF clock right before the data transmission adds an extra
+	  latency of around 1.4 ms (0.85 ms in case of nRF54L Series SoCs) for
+	  the first packet (in a row) that is transmitted. The extra latency is
+	  caused by the HF clock startup latency. Keeping the HF clock enabled
+	  all the time removes the extra latency caused by the clock startup at
+	  the cost of increased power consumption.
+
+	  The HF clock lock hotfix is not supported for nRF54H Series SoCs. For
+	  these SoCs, a part of the Bluetooth stack runs on the radio core.
+	  Keeping the HF clock enabled by the application running on application
+	  core does not mitigate the extra HID report latency caused by the HF
+	  clock startup, because the application cannot notify a part of the
+	  Bluetooth stack running on the radio core that HF clock is already
+	  enabled. The clock startup latency unconditionally affects the first
+	  transmitted packet.
 
 config DESKTOP_CONSTLAT_ENABLE
 	bool "Constant latency interrupts"