Re: [PATCH v4 2/2] usb: overridable hub bInterval by device node

From: Johan Hovold <johan@kernel.org>
To: Ikjoon Jang <ikjn@chromium.org>
Cc: Johan Hovold <johan@kernel.org>,
	linux-usb@vger.kernel.org,
	GregKroah-Hartman <gregkh@linuxfoundation.org>,
	RobHerring <robh+dt@kernel.org>,
	MarkRutland <mark.rutland@arm.com>,
	AlanStern <stern@rowland.harvard.edu>,
	SuwanKim <suwan.kim027@gmail.com>,
	"GustavoA . R . Silva" <gustavo@embeddedor.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	Mathias Nyman <mathias.nyman@linux.intel.com>
Subject: Re: [PATCH v4 2/2] usb: overridable hub bInterval by device node
Date: Tue, 10 Dec 2019 16:02:58 +0100	[thread overview]
Message-ID: <20191210150258.GR10631@localhost> (raw)
In-Reply-To: <CAATdQgDAZ21bEXh+YFh+fCdBxnuRi-1_x0o_hpxW0Vj0zY-j8A@mail.gmail.com>

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@kernel.org> 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@kernel.org> 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