I think this breaks 32-bit builds since ps_per_tick is too small there. I think it needs to be bumped to uint64_t.

Just a comment on uint64_t: ps is 10^12, which is 36 bits to represent 1s, so switching to uint64_t will gives the most safety, especially given that the howmany macro isn't careful about overflow. Since it's just used in DELAY, and we know n for delay is usually small except in some crazy old ISA drivers, it likely worked or closely worked with 32-bit types. It wouldn't hit problems until several hundred or maybe thousand milliseconds if the back of the envelop numbers I just ran are right....
I'd be tempted in DELAY to s/u_quad_t/uint64_t/g since the quad name for that type is discouraged, but it's not a bug deal either way.
Quibbles aside, this was a good change before the change to 64-bit, and is a better change with that change as clocks will only get faster from here.