drivers: NXP ENET: fix for issue mutex called from ISR #89443
Conversation
|
Hello @duerrfk, and thank you very much for your first pull request to the Zephyr project! |
github-actions
bot
added
platform: NXP Drivers
github-actions
bot
requested review from
clamattia,
dbaluta,
decsny,
dleach02,
lmajewski,
maass-hamburg,
manuargue,
mmahadevan108,
pdgendt and
Raymond0225
|
please fix compliance failures |
The NXP ENET driver used a mutex inside an ISR. Since mutexes are not allowed in ISR, an assertion had been triggered. The mutex is not required since a semaphore ensures sequential writing (in ISR) and subsequent reading (after eth_wait_for_ptp_ts()). Fixed by removing calls to mutex. Signed-off-by: Frank Duerr <frank.duerr@ipvs.uni-stuttgart.de>
duerrfk
force-pushed
the
issue_mutex_in_isr
branch
from
0251d87 to
8b3b77e
Compare
|
Sorry for not checking for compliance! Compliance check passes now. |
Fixes #89442
The NXP ENET driver uses a mutex inside an ISR.
Function ts_register_tx_event() (source file zephyr/drivers/ethernet/eth_nxp_enet.c) is invoked from the ISR when a TX packet timestamp is available. Before the timestamp is copied to the packet, a mutex is locked, most likely to protect the timestamp from concurrent read/write operations. Since mutexes are not allowed in ISR, the following assertion is triggered (when compiled with assertions):
The problem can be fixed by simply removing the calls to the mutex in ts_register_tx_event() since the timestamp is also protected from concurrent read operations using a semaphore (ptp_ts_sem), which is only released after copying the timestamp to the packet. This semaphore ptp_ts_sem ensures sequential execution of writing the timestamp in ts_register_tx_event() (inside the ISR) and subsequently reading the timestamp after waiting for the semaphore ptp_ts_sem in eth_wait_for_ptp_ts().