On Mon, Dec 09, 2019 at 12:05:53PM +0800, Ikjoon Jang wrote: > On Fri, Dec 6, 2019 at 11:25 PM Johan Hovold <johan@xxxxxxxxxx> wrote: > > > > On Fri, Dec 06, 2019 at 11:57:30AM +0800, Ikjoon Jang wrote: > > > On Thu, Dec 5, 2019 at 10:26 PM Johan Hovold <johan@xxxxxxxxxx> wrote: > > > > The fundamental problem here is that you're using devicetree, which is > > > > supposed to only describe the hardware, to encode policy which should be > > > > deferred to user space. > > > > > > The hub hardware has a default bInterval inside which is actually > > > adjustable. So I can think setting bInterval is to describe the hardware > > > rather than policy. > > > > No, the USB spec says bInterval is a maximum requested value and that > > the host is free to poll more often. And that's policy. > > Honestly I'm a bit confused on the border line between hardware > and software definition. That's quite reasonable it's policy that software > can poll more often than hardware specified, but can we think it's just > overriding hardware property specifying maximum value from beginning? > Is it still policy? or 'overriding hardware property' part is already not > a hardware description? :-S The hardware is supposed to give you the upper limit, and then software is allowed to poll more often if it wants to and is able to do so. In this case that decision depends partly on what is connected to the hub but also on how that device in turn has been configured, specifically, whether runtime PM has been enabled or not. Someone who doesn't use the downstream device, or who prefers to never suspend it, may not be willing to pay the price for polling the hub more frequently, for example. So this ends up being very much a policy decision which should be left for user space. But if you can come up with a generic interface for this, it could be useful in other setups as well (non-DT, hot-pluggable, etc). Johan
