Defines HAL_ETH_STATE_BUSY and HAL_ETH_STATE_STARTED have the same value (0x23) breaking gState checks

[KarstenHohmeier]

Looking at HAL_ETH I noticed that these defines for the HAL_ETH global state (gState) have the same value (0x23):

stm32h7xx_hal_driver/Inc/stm32h7xx_hal_eth.h

Lines 1474 to 1478 in ceda3ce

	#define HAL_ETH_STATE_RESET 0x00000000U /*!< Peripheral not yet Initialized or disabled */
	#define HAL_ETH_STATE_READY 0x00000010U /*!< Peripheral Communication started */
	#define HAL_ETH_STATE_BUSY 0x00000023U /*!< an internal process is ongoing */
	#define HAL_ETH_STATE_STARTED 0x00000023U /*!< an internal process is started */
	#define HAL_ETH_STATE_ERROR 0x000000E0U /*!< Error State */

This breaks these checks:

stm32h7xx_hal_driver/Src/stm32h7xx_hal_eth.c

Lines 717 to 721 in ceda3ce

	HAL_StatusTypeDef HAL_ETH_Start(ETH_HandleTypeDef *heth)
	{
	if (heth->gState == HAL_ETH_STATE_READY)
	{
	heth->gState = HAL_ETH_STATE_BUSY;

Also the comments associated with these values are wrong/misleading. Maybe you can improve on these a little.
Here is how I understand the values after looking at how they are used in the code:

• HAL_ETH_STATE_RESET means: heth private data is not initialized at all, please call HAL_ETH_Init()
• HAL_ETH_STATE_READY means: you can register callbacks now, but to start the actual hardware and the interrupts please call HAL_ETH_Start() or HAL_ETH_Start_IT()
• HAL_ETH_STATE_STARTED means: heth is running and ready for RX and TX operations
• HAL_ETH_STATE_BUSY means: heth is currently doing something 'critical' that should not be done concurrently, because it would mess up the internal state of heth or the hardware
• HAL_ETH_STATE_ERROR means: heth encountered an error that needs external handling; see HAL_ETH_ErrorCallback() and HAL_ETH_DeInit()

[ASEHSTM]

Hello @KarstenHohmeier,

Thank you for your detailed report. I have reported this issue internally.
ST Internal Reference: 191045

With Regards,