> -----Original Message----- > From: Mika Westerberg <[email protected]> > Sent: Thursday, October 3, 2019 3:00 AM > To: Limonciello, Mario > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4 > > > [EXTERNAL EMAIL] > > On Wed, Oct 02, 2019 at 04:00:55PM +0000, [email protected] 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).
