Ethernet STM32: Add API_V2 auto-negotiation support #86621
Conversation
marwaiehm-st
force-pushed
the
add_eth_autoneg_v2_rebased
branch
from
6f93ec2 to
1323be8
Compare
marwaiehm-st
changed the title
marwaiehm-st
force-pushed
the
add_eth_autoneg_v2_rebased
branch
3 times, most recently
from
8a9c135 to
149c715
Compare
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
decsny,
djiatsaf-st,
erwango,
gautierg-st,
lmajewski,
maass-hamburg,
mathieuchopstm and
pdgendt
|
@cperera-aud Please have a look |
There was a problem hiding this comment.
There is eth_stm32_hal_get_capabilities() that returns for example the 10Mbit/sec and 100Mbit/sec support information to the caller.
I am wondering should we return in that function the current status what is being negotiated or what the driver supports in the first place. The documentation does not seem to tell it clearly, what do you think?
Never mind, it makes sense to return the driver supported capabilities here.
drivers/ethernet/eth_stm32_hal.c
Outdated
| static void get_auto_nego_speed_duplex(ETH_HandleTypeDef *heth, ETH_MACConfigTypeDef *mac_config) | ||
| { | ||
| uint32_t phyLinkState; | ||
| uint32_t tickstart = HAL_GetTick(); |
There was a problem hiding this comment.
Use zephyr API: k_uptime_get_32()
I think the eth_stm32_hal_get_capabilities() function should return the static capabilities of the driver, such as support for 10Mbit/sec and 100Mbit/sec. Returning the current status of the link negotiation from this function can introduce several risks:
|
@erwango , thanks for letting me know about this PR. I suppose this PR would superseed the changes in #86643 isn't it? |
@cperera-aud, yes, this PR does supersede the changes in #86643. |
marwaiehm-st
force-pushed
the
add_eth_autoneg_v2_rebased
branch
from
149c715 to
ea8807b
Compare
@marwaiehm-st , thanks for letting me know. |
Do you confirm this is functional on your side and answers your need ? |
Sorry @erwango I haven't tried out the changes on my end. It would take a bit of time for us to integrate and try since we're on an old version of Zephyr. The auto negotiation is something that would certainly fit our needs. |
- Added definitions for LAN8742 PHY registers and bit masks to support auto-negotiation. - The function `eth_init_api_v2` requires the Ethernet interface to be properly initialized. In auto-negotiation mode, it reads the speed and duplex settings to configure the driver accordingly. - Implemented functions to get link state and configure speed and duplex mode based on auto-negotiation results. - Ensured proper initialization of semaphores and MAC configuration for both auto-negotiation enabled and disabled scenarios. Signed-off-by: IBEN EL HADJ MESSAOUD Marwa <[email protected]>
marwaiehm-st
force-pushed
the
add_eth_autoneg_v2_rebased
branch
from
ea8807b to
f8e6f88
Compare
ghost
mentioned this pull request
|
Does this also fix for the H5? It did not work on my initial tests. |
Yes, what board H5 did you use? |
stm32h573i_dk Is a special dt-overlay and/or config needed? |
There's no need for any special dt-overlay or configuration. I just wanted to make sure I have the board. I'll perform the test on my side to gain a better understanding of the problem. |
Custom test. Thank you. |
Testing with #87593 may be able to solve your issue. |
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This removes that call to setup_mac_filter() when API_V2 in enabled and calls it from eth_init_api_v2() instead, after HAL_ETH_Init(). I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This removes that call to setup_mac_filter() when API_V2 in enabled and calls it from eth_init_api_v2() instead, after HAL_ETH_Init(). I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This removes that call to setup_mac_filter() when API_V2 in enabled and calls it from eth_init_api_v2() instead, after HAL_ETH_Init(). I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This removes that call to setup_mac_filter() when API_V2 in enabled and calls it from eth_init_api_v2() instead, after HAL_ETH_Init(). I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This removes that call to setup_mac_filter() when API_V2 in enabled and calls it from eth_init_api_v2() instead, after HAL_ETH_Init(). I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This removes that call to setup_mac_filter() when API_V2 in enabled and calls it from eth_init_api_v2() instead, after HAL_ETH_Init(). I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This moves the call to setup_mac_filter() to eth_iface_init(), after HAL_ETH_Init() for both API_V1 and API_V2. I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by #86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This moves the call to setup_mac_filter() to eth_iface_init(), after HAL_ETH_Init() for both API_V1 and API_V2. I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
After API_V2 auto-negotiation support was added by zephyrproject-rtos#86621 setup_mac_filter() was called before HAL_ETH_Init(), which resulted in received multicast packets being discarded. This moves the call to setup_mac_filter() to eth_iface_init(), after HAL_ETH_Init() for both API_V1 and API_V2. I've verified the problem and tested the fix on a Nucleo-H563ZI with a simple application that just starts up and makes an mDNS query (which depends on working multicast). Signed-off-by: Kevin ORourke <[email protected]>
7 participants
eth_init_api_v2requires the Ethernet interface to be properly initialized. In auto-negotiation mode, it reads the speed and duplex settings to configure the driver accordingly.