On 8/18/20 3:51 PM, Valdis Klētnieks wrote: > On Mon, 10 Aug 2020 07:10:32 -0700, Guenter Roeck said: >>> ERROR: modpost: "__bad_udelay" >>> [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined! >>> >> >> I don't think that is new. If anything, it is surprising that builds don't >> fail more >> widely because of it. AFAICS it was introduced back in 2018 (a hot 50-ms >> delay loop >> really isn't such a good idea). > > Well...it wasn't broken in next-20200720. A bit of poking with nm, > and building hw_atl/hw_atl_b0.s, it looks like the culprit is this commit: > > commit 8dcf2ad39fdb2d183b7bd4307c837713e3150b9a > Author: Mark Starovoytov <mstarovoi...@marvell.com> > Date: Mon Jul 20 21:32:44 2020 +0300 > > net: atlantic: add hwmon getter for MAC temperature > > specifically this chunk around line 1634 of hw_atl/hw_atl_b0.c: > > > + err = readx_poll_timeout_atomic(hw_atl_b0_ts_ready_and_latch_high_get, > + self, val, val == 1, 10000U, 500000U); > > And doing a 'git revert' makes the build work.... >
Nice catch. FWIW, there is no obvious reason why this would need to be atomic. The calling code does not set a lock, meaning there can be two (or more) callers entering this code. Weird, especially since the code looks like it would actually need a mutex to work correctly. It might be interesting to see what happens if there are, say, half a dozen scripts/processes trying to read the hwmon attribute introduced by this patch at the same time. Guenter
