devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH v4 2/2] usb: overridable hub bInterval by device node
Date: Wed, 4 Dec 2019 08:55:33 +0100	[thread overview]
Message-ID: <20191204075533.GI10631@localhost> (raw)
In-Reply-To: <CAATdQgCqYrd_aXN5GDsso+F3WadNx3DQKK3Efk3tgkrv2VXjyw@mail.gmail.com>

On Wed, Dec 04, 2019 at 03:04:53PM +0800, Ikjoon Jang wrote:
> On Wed, Dec 4, 2019 at 12:52 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Tue, Dec 03, 2019 at 06:15:52PM +0800, Ikjoon Jang wrote:
> > > This patch enables hub device to override its own endpoint descriptor's
> > > bInterval when the hub has a device node with "hub,interval" property.
> > >
> > > When we know reducing autosuspend delay for built-in HIDs is better for
> > > power saving, we can reduce it to the optimal value. But if a parent hub
> > > has a long bInterval, mouse lags a lot from more frequent autosuspend.
> > > So this enables overriding bInterval for a hard wired hub device only
> > > when we know that reduces the power consumption.
> >
> > I think I saw you argue about why this shouldn't simply be configured at
> > runtime. Please include that here too, I can't seem to remember why...
> 
> Okay.
> 
> >
> > > Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
> > > Acked-by: Alan Stern <stern@rowland.harvard.edu>
> > > ---
> > >  drivers/usb/core/config.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
> > > index 5f40117e68e7..95ec5af42a1c 100644
> > > --- a/drivers/usb/core/config.c
> > > +++ b/drivers/usb/core/config.c
> > > @@ -6,6 +6,7 @@
> > >  #include <linux/usb.h>
> > >  #include <linux/usb/ch9.h>
> > >  #include <linux/usb/hcd.h>
> > > +#include <linux/usb/of.h>
> > >  #include <linux/usb/quirks.h>
> > >  #include <linux/module.h>
> > >  #include <linux/slab.h>
> > > @@ -257,6 +258,14 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
> > >       memcpy(&endpoint->desc, d, n);
> > >       INIT_LIST_HEAD(&endpoint->urb_list);
> > >
> > > +     /* device node property overrides bInterval */
> > > +     if (usb_of_has_combined_node(to_usb_device(ddev))) {
> >
> > Not only hubs have combined nodes so you probably need to check
> > bDeviceClass here instead.
> 
> yes, you're right, I didn't think of that case:
> if (to_usb_device(ddev)->descriptor.bDeviceClass == USB_CLASS_HUB &&
> ddev->of_node && !of_property_read_u32(...))
> 
> Or is it better to check bInterfaceClass, for composite devices with a
> hub interface inside?
> if (ifp->desc.bInterfaceClass == USB_CLASS_HUB && ddev->of_node &&
> !of_property_read_u32(...))
> 
> I think checking bInterfaceClass is better.

Yep, that seems better (but please use two conditionals for
readability).

But related to my question above, why do you need to do this during
enumeration? Why not just set the lower interval value in the hub
driver?

> > > +             u32 interval = 0;
> > > +             if (!of_property_read_u32(ddev->of_node, "hub,interval",
> > > +                                 &interval))
> > > +                     d->bInterval = min_t(u8, interval, 255);
> >
> > You want min_t(u32, ...) here to avoid surprises when someone specifies
> > a value > 255.
> 
> yes, thanks.

And I guess you should really be honouring bInterval as a maximum value,
right?

> > > +     }
> > > +
> > >       /*
> > >        * Fix up bInterval values outside the legal range.
> > >        * Use 10 or 8 ms if no proper value can be guessed.

Johan

  reply	other threads:[~2019-12-04  7:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 10:15 [PATCH v4 2/2] usb: overridable hub bInterval by device node Ikjoon Jang
2019-12-03 15:23 ` Alan Stern
2019-12-04  7:07   ` Ikjoon Jang
2019-12-03 16:53 ` Johan Hovold
2019-12-04  7:04   ` Ikjoon Jang
2019-12-04  7:55     ` Johan Hovold [this message]
2019-12-05  7:32       ` Ikjoon Jang
2019-12-05 14:26         ` Johan Hovold
2019-12-06  3:57           ` Ikjoon Jang
2019-12-06 15:00             ` Alan Stern
2019-12-09  3:47               ` Ikjoon Jang
2019-12-06 15:26             ` Johan Hovold
2019-12-09  4:05               ` Ikjoon Jang
2019-12-10 15:02                 ` Johan Hovold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191204075533.GI10631@localhost \
    --to=johan@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo@embeddedor.com \
    --cc=ikjn@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=suwan.kim027@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).