Re: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4

[Yehezkel Bernat]

On Fri, Oct 4, 2019 at 10:54 AM Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
>
> 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?

Are those the chip vendor or the OEM, in case they are different?

Thinking about it again, I'd guess it shouldn't matter much, if the chip is from
Intel, the FW supports NVM upgrade, isn't it?