On Fri, Oct 4, 2019 at 11:19 AM Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > On Fri, Oct 04, 2019 at 11:07:34AM +0300, Yehezkel Bernat wrote: > > > 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? > > Those are the actual USB4 hardware maker values, directly from > ROUTER_CS_0 (p. 287 in the USB4 spec). This almost certainly differ from > the OEM values from DROM we currently expose. Makes sense to me. Userspace can learn the relevant IDs that their NVM format is known. > > > 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? > > So the bottom line is that if the kernel thinks the router supports NVM > upgrade it exposes the nvm_active/nvm_non_active files etc. I think > fwupd uses this information to display user whether the device can be > upgraded or not (for example ICL cannot as the NVM is part of BIOS). Yes, fwupd already takes this into account, but the question here is how to handle cases that NVM is available but the format isn't known to userspace (yet). > > Exposing hw_vendor_id and hw_product_id may speed up fwupd because it > does not need to go over the active NVM to figure out whether the new > image is for the correct controller. It's not about finding the relevant image for upgrade (which must be searched for by looking in the DROM vendor/product values), but about the question if the NVM format is known to userspace and skip the parsing work if it's anyway going to fail. So yes, I think exposing vendor ID (and maybe also product ID) can improve the situation. Thanks!
