Drivers: add Holybro Pixhawk 6C USB ID (VID_3162 PID_0053)

[PROF0UND]

The Holybro Pixhawk 6C uses VID 0x3162 PID 0x0053 as a composite USB device, presenting two interfaces:

1. MI_00 for MAVLink and
2. MI_02 for SLCAN.

This PID was not in Holybro.inf, causing the board to appear as a generic "USB Serial Device" in Windows rather than identifying itself.

This was confirmed on a physical Pixhawk 6C:

Get-PnpDevice -Class Ports | Select-Object FriendlyName, InstanceId, Status

shows

USB\VID_3162&PID_0053&MI_00 

and

USB\VID_3162&PID_0053&MI_02 

with status OK but no friendly name.

Related to #2095 (which added earlier Holybro PIDs but predates the 6C).

[robertlong13]

I can confirm that the VID/PID matches ArduPilot's hwedef for that board, and the .inf changes seem to be correct.

But Holybro.cat will need to be re-signed with Michael's cert. Which only @meee1 (and apparently @tridge ) can do.

[PROF0UND]

oh no! Mission planner's connect dropdown shows a bunch of COM ports for me and I though this would be a nice fix for everyone. Hopefully gets signed!

[tridge]

Automated review note — AI-generated (Claude), validated against the live diff. Please sanity-check before acting.
Full report: https://uav.tridgell.net/DevCallReviews/2026_08_30/devcall_pr_reviews.html#prMissionPlanner-3735

Reviewed at head 4d64501d1f. Verdict: COMMENT — the INF edit itself is correct; the blocker is external to your diff.

What I actually checked, rather than eyeballing it: VID 0x3162 / PID 0x0053 were re-derived from upstream ArduPilot's Pixhawk6C/hwdef.dat instead of trusting the PR text; the &MI_00 / &MI_02 composite split is right because that hwdef's SERIAL_ORDER includes OTG2, giving two CDC-ACM functions of two interfaces each — the same shape as the long-shipping Durandal entry. [Manufacturer] declares exactly two models sections ([DeviceList], [DeviceList.NTamd64]) and both got both lines; there's no NTarm64 section to miss. Both %DESCRIPTION53% tokens resolve to real [Strings] entries, and a sweep of all 25 INFs under Drivers/ found no conflicting 3162/0053 claim. Utilities/BoardDetect.cs matches VID_3162 vendor-wide, so no second table needs updating.

1. ISSUE (merge blocker, maintainer-side). Drivers/Holybro.inf:11 declares CatalogFile=Holybro.cat, and editing the INF invalidates that catalogue's hash — decoding the committed Drivers/holybro.cat confirms it still carries the old INF hash and only the pre-PR hardware IDs. Drivers/inf2cat.bat regenerates and signs it as "Michael Oborne", so this needs @meee1 (or tridge) to produce the new signed .cat; you can't complete it yourself. @robertlong13 called this out on 2026-06-10 and the PR has been sitting since.
2. NOTE. DriverVer is left at 12/26/2019,2.0.0.10; the closest precedent (07677551c, which added Durandal's dual-interface entries) bumped it. Low impact — these are brand-new hardware IDs and dpinst.xml carries forceIfDriverIsNotBetter — but worth bumping in the same pass as the catalogue.
3. NOTE (cosmetic). The strings are "Pixhawk6C-MAVLink" / "Pixhawk6C-SLCAN", where the file's convention gives the primary port the bare board name and only suffixes the second ("Durandal" / "Durandal SLCAN"). Also, OTG2 defaults to MAVLink2 rather than SLCAN unless changed, so "SLCAN" names an intended use rather than the default. These are what users see in Device Manager.

Since a maintainer has to touch this anyway for the catalogue, it'd be a good moment to fold in 2 and 3.