fix: match Intel HDA controllers enumerated as subclass 0x01
Restricting the IntelHDA PCI match to subclass 0x03 (e0c02f7) hid the
speakers on modern laptops, where the same HDA controller enumerates
as 0x01 (Multimedia audio controller) when the Smart Sound DSP is
enabled. Match any multimedia subclass instead; legacy AC'97 devices
also report 0x01 but expose an I/O-space BAR0, which Probe already
rejects via the ReadBar0 check.
Co-Authored-By: Claude Fable 5 <[email protected]>
This commit is contained in:
@@ -149,15 +149,20 @@ namespace Drivers {
|
||||
ProbeNvme,
|
||||
},
|
||||
// Order 7: Intel HDA — Normal phase, match vendor=0x8086 + class=0x04 (Multimedia)
|
||||
// SubClass 0x03 = "Audio device" = HD Audio controller.
|
||||
// SubClass 0x01 = "Multimedia audio controller" = legacy AC'97
|
||||
// (e.g. VirtualBox 8086:2415), which is NOT HDA and has an I/O
|
||||
// BAR, not an MMIO BAR — do NOT match it here.
|
||||
// SubClass 0x03 = "Audio device" (plain HD Audio controller).
|
||||
// SubClass 0x01 = "Multimedia audio controller": on modern
|
||||
// laptops this is the SAME HDA controller enumerated with the
|
||||
// audio DSP (Smart Sound Technology) enabled, so it MUST be
|
||||
// matched — restricting to 0x03 made the speakers vanish with
|
||||
// no HDA logs at all. Legacy AC'97 (e.g. VirtualBox 8086:2415)
|
||||
// also reports 0x01, but it exposes an I/O-space BAR0:
|
||||
// ReadBar0 returns 0 for I/O BARs and Probe rejects it
|
||||
// cleanly, so matching it here is harmless.
|
||||
{
|
||||
"IntelHDA",
|
||||
0x8086, // VendorId (Intel)
|
||||
0x04, // ClassCode (Multimedia)
|
||||
0x03, // SubClass (0x03 = HD Audio; excludes AC'97 0x01)
|
||||
0xFF, // SubClass (any — 0x03 HDA, 0x01 HDA-with-DSP; AC'97 rejected by BAR check)
|
||||
0xFF, // ProgIf (any)
|
||||
nullptr,
|
||||
0,
|
||||
|
||||
Reference in New Issue
Block a user