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?