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

[Mario.Limonciello]

> -----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

> 
> > However the kernel has this information handy already from thunderbolt init
> and can
> > easily export an attribute which can then come from udev with no startup
> penalty.
> 
> Indeed kernel has this information but I'm bit hesitant to add new
> attributes if that same information is already available to the
> userspace rather easily. IMHO we can always add this to the driver later
> as we learn new NVM formats that require more parsing from fwupd side
> slowing it down considerably.

I guess we can wait until new NVM formats come and cross the bridge at that point.
If we encounter a new NVM format that kernel recognizes but old fwupd doesn't it
will reject it anyway (just the error won't be super clear why).