> Date: Sat, 4 Jan 2020 16:15:22 +0100 > From: Martin Pieuchot <[email protected]> > > `delay' is expressed in ms, however since tsleep_nsec(9) doesn't add a > tick the conversions below might result in shorter sleeps. I'd > appreciate if uthum(4) owners could test this diff and report back.
I'm not sure I understand what you're saying here. But this made me look at the implementation of tsleep_nsec(), and I think its implementation is wrong. We should sleep for *at least* the number of nanoseconds specified. Therefore the number of ticks should be rounded up. That is, if nsecs is 999999999 and hz is 10, we should sleep for at least 10 full ticks. > Index: uthum.c > =================================================================== > RCS file: /cvs/src/sys/dev/usb/uthum.c,v > retrieving revision 1.32 > diff -u -p -r1.32 uthum.c > --- uthum.c 9 Jan 2017 14:44:28 -0000 1.32 > +++ uthum.c 1 Jan 2020 14:27:59 -0000 > @@ -311,7 +311,8 @@ uthum_issue_cmd(struct uthum_softc *sc, > > /* wait if required */ > if (delay > 0) > - tsleep(&sc->sc_sensortask, 0, "uthum", (delay*hz+999)/1000 + 1); > + tsleep_nsec(&sc->sc_sensortask, 0, "uthum", > + MSEC_TO_NSEC(delay)); > > return 0; > } > @@ -337,7 +338,8 @@ uthum_read_data(struct uthum_softc *sc, > > /* wait if required */ > if (delay > 0) > - tsleep(&sc->sc_sensortask, 0, "uthum", (delay*hz+999)/1000 + 1); > + tsleep_nsec(&sc->sc_sensortask, 0, "uthum", > + MSEC_TO_NSEC(delay)); > > /* get answer */ > if (uhidev_get_report(sc->sc_hdev.sc_parent, UHID_FEATURE_REPORT, > >
