When writing kernel drivers for this sort of thing, I think the rule of thumb should be to keep the driver as "thin" as possible. If the hardware doesn't provide a feature, the kernel should not be trying to emulate it. So for an H-bridge I would want something that just provides a way to tell it I want fast-decay mode with some normalized duty cycle between -1 and 1 (obviously we will have to multiply this by some factor since the kernel doesn't do floating point). A duty cycle of 0 will "brake" the motor. And then we would need one more control parameter to tell it to remove power completely to "coast" the motor. I guess this is what the "basic_run" and "basic_stop" are other than the run seems to have speed instead of duty cycle? The kernel shouldn't be trying to convert this duty cycle to speed or have a background task that tries to provide an acceleration profile or turn off the power after some time. Just let the kernel provide direct, low-level access to the hardware and let userspace handle all of the rest in a way that makes the most sense for the specific application. Sometimes they might not even be connected to a motor! With the LEGO MINDSTORMS and BeableBone Blue, the H-bridge outputs are hot-pluggable, so they can even be connected to things like LEDs or used as a general power supply. (A reason to call this subsystem "actuation" rather than "motion".) Another way of putting this is that it was very tempting to model the actual motor in the kernel. But that didn't work well because there are so many different kinds of motors and related mechanical systems that you can connect to the same motor driver chip. So the driver really should just be for the H-bridge chip itself and not care about the motor. And the rest can be put in a libmotion userspace library and have that be the convenient API for users that want to get something up and running quickly.
