The PORTNUM is composed of two bytes values that are ASCII encoded: the
super-speed and high speed port numbers.
The result is PORTNUM_3434 for an usbhub device of 4/4 ports; 34 is the
ASCII encoded value for the character '4'.
The value PORTNUM_3434 is not straightforward if read by humans; however
PORTNUM_44 is more explicit.
This change encodes the two port numbers into a single byte instead of
ASCII-encoding to a 16-bits integer.
Example:
XPS 13 9370
│
└─USB2.0 Hub:
Device ID: 84d0e3f2a0f8b2328f7995767b23ebb40494723f
Current version: 92.24
Vendor: GenesysLogic (USB:0x05E3)
GUIDs: 0cdb6604-d595-5ca3-8da0-d05cb1b71ac1 ← USB\VID_05E3&PID_0610
ce9a28b1-f064-5b5a-b71b-3dea05905aea ← USB\VID_05E3&PID_0610&REV_9224
e89cae82-9975-55fb-802f-63d27dbcec19 ← VID\PID_0610&HUB_00
2ae5ae36-cf86-5486-bff2-1bfd30e0ac6d ← USB\VID_05E3&PID_0610&IC_352122
242eea14-5dfe-55d9-9d30-acfa9ec6a9a5 ← USB\VID_05E3&PID_0610&IC_352122&BONDING_00
f68080bb-3713-5154-9890-44fbd833d678 ← USB\VID_05E3&PID_0610&VENDOR_GENESYSLOGIC&IC_352122&BONDING_00&PORTNUM_44&VENDORSUP_E8A9A9E4-6C17-5F9C-B7BD-CDA49FE66D75
Device Flags: • Updatable
• Unsigned Payload
--force was there because HSI specification was incomplete. However
now we have the ability for plugins to report when not enough data
was gathered to make a calculation. So change it to instead only
run if enough data was gathered.
On supported CPUs this will show up at HSI level 1 meaning that HSI
should be supported and trusted on this CPU if all plugins provided
enough data.
On non-Intel CPUs this will show up as missing data, meaning
that not enough plugins provide data for HSI to be trusted by default.
older json-glib versions can't work with saving or retrieving
HSI security events. Rather than showing non-sensical errors
about too old of a json glib version that are out of context,
just compile this stuff out on the older versions.
This fixes HSI security events showing up too as a result.
This is a feature that seems useful, but one that no vendor has actually
asked for. It's also of limited use for peripheral devices.
Showing the instance IDs by default is also going to make it much easier
to explain to hardware vendors where the GUIDs come from.
Fixes https://github.com/fwupd/fwupd/issues/4445
Before we had FuInstallTask which represented the specific install
action (install foo on bar), FuEngineRequest which described why the
install task was created, and FuEngine. The latter being both reposible
for calling *into* FuInstallTask and also *from* FuInstallTask as well.
Depending on the code, we had XbNodes of component and release, *and*
FwupdReleases as releases and lots of duplicated code to marshall the
former into various forms of the latter.
Create a FuRelease wrapper around FwupdRelease to replace FuInstallTask
and to simplify the code. Make the FuRelease builder do the device
requirement checks, and then use the engine to do checks requiring
engine state and context.
