On 16.03.21 14:51, Matúš Olekšák via Xenomai wrote: > udelay() should not be used with values over 20 000. But the first calling of > udelay() in e1000e_phy_has_link_generic(), does not check delay value. It > causes compile-time trap __bad_udelay() to occur. Bug is present on all > Xenomai versions since commit 106ffba7b55d506143966ff16158ee79b0007336.
Already merged into next, see https://source.denx.de/Xenomai/xenomai/-/commit/7857a1b154c327d68c5a5e5deedd908f6e0095a1 I'll push that to stable branches as well. Thanks nevertheless! Jan > > Signed-off-by: Matúš Olekšák <oleksak.ma...@gmail.com> > --- > kernel/drivers/net/drivers/e1000e/phy.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/kernel/drivers/net/drivers/e1000e/phy.c > b/kernel/drivers/net/drivers/e1000e/phy.c > index 66ae3891a..9ec7835bc 100644 > --- a/kernel/drivers/net/drivers/e1000e/phy.c > +++ b/kernel/drivers/net/drivers/e1000e/phy.c > @@ -1787,13 +1787,17 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, > u32 iterations, > * it across the board. > */ > ret_val = e1e_rphy(hw, PHY_STATUS, &phy_status); > - if (ret_val) > + if (ret_val) { > /* > * If the first read fails, another entity may have > * ownership of the resources, wait and try again to > * see if they have relinquished the resources yet. > */ > - udelay(usec_interval); > + if (usec_interval >= 1000) > + mdelay(usec_interval/1000); > + else > + udelay(usec_interval); > + } > ret_val = e1e_rphy(hw, PHY_STATUS, &phy_status); > if (ret_val) > break; > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
