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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191204075533.GI10631@localhost>
Date:   Wed, 4 Dec 2019 08:55:33 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Ikjoon Jang <ikjn@...omium.org>
Cc:     Johan Hovold <johan@...nel.org>, linux-usb@...r.kernel.org,
        GregKroah-Hartman <gregkh@...uxfoundation.org>,
        RobHerring <robh+dt@...nel.org>,
        MarkRutland <mark.rutland@....com>,
        AlanStern <stern@...land.harvard.edu>,
        SuwanKim <suwan.kim027@...il.com>,
        "GustavoA . R . Silva" <gustavo@...eddedor.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Nicolas Boichat <drinkcat@...omium.org>
Subject: Re: [PATCH v4 2/2] usb: overridable hub bInterval by device node

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@...nel.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@...omium.org>
> > > Acked-by: Alan Stern <stern@...land.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