Re: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4
From: Mika Westerberg
Date: Fri Oct 04 2019 - 03:54:37 EST
On Thu, Oct 03, 2019 at 02:41:11PM +0000, Mario.Limonciello@xxxxxxxx wrote:
> > -----Original Message-----
> > From: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> > Sent: Thursday, October 3, 2019 3:00 AM
> > To: Limonciello, Mario
> > Cc: yehezkelshb@xxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx;
> > andreas.noever@xxxxxxxxx; michael.jamet@xxxxxxxxx;
> > rajmohan.mani@xxxxxxxxx; nicholas.johnson-opensource@xxxxxxxxxxxxxx;
> > lukas@xxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; stern@xxxxxxxxxxxxxxxxxxx;
> > anthony.wong@xxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> > Subject: Re: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On Wed, Oct 02, 2019 at 04:00:55PM +0000, Mario.Limonciello@xxxxxxxx wrote:
> > > > It's not even "same location - another meaning", the vendor ID comes from
> > the
> > > > DROM section, so it takes a few internal jumps inside the NVM to find the
> > > > location. One of the "pointers" or section headers will be broken for sure.
> > > >
> > > > And after this, we need to find the NVM in LVFS and it has to pass validation
> > in
> > > > a few other locations. The chances are so low that I'd think it isn't worth
> > > > worrying about it.
> > >
> > > And now I remember why the back of my mind was having this thought of
> > wanting
> > > sysfs attribute in the first place. The multiple jumps means that a lot more of
> > the
> > > NVM has to be dumped to get that data, which slows down fwupd startup
> > significantly.
> >
> > IIRC currently fwupd does two reads of total 128 bytes from the active
> > NVM. Is that really slowing down fwupd startup significantly?
>
> Yeah, I timed it with fwupd. Here's the averages:
>
> Without doing the reads to jump to this it's 0:00.06 seconds to probe a tree of
> Host controller and dock plugged in.
>
> With doing the reads and just host controller:
> 0:04.40 seconds
>
> With doing the reads and host controller and dock plugged in:
> 0:10.73 seconds
OK, it clearly takes time to read them. I wonder if this includes
powering up the controller?
Also if you can get the hw_vendor_id and hw_product_id from the kernel
does that mean you don't need to do the two reads or you still need
those?