_DSM Deep Dive
A practical firmware note on ACPI _DSM, vendor-specific device methods, UUID functions, and OS-specific feature behavior.
A device works on Windows but behaves differently on Linux. Or a feature is enabled only after a vendor driver loads. Or a Thunderbolt, graphics, battery, camera, or touchpad feature depends on a strange ACPI method with a UUID.
That is often where _DSM appears.
_DSM means Device Specific Method. It gives firmware a way to expose vendor-specific or device-specific functions that do not fit cleanly into standard ACPI methods.
The shape of _DSM
A typical _DSM receives four arguments:
Method (_DSM, 4, Serialized)
{
// Arg0: UUID
// Arg1: revision
// Arg2: function index
// Arg3: function-specific package
}The OS or driver calls _DSM with a UUID and function number. Firmware returns a package, integer, buffer, or other object depending on that function.
| Item | Value | Note |
|---|---|---|
| Arg0 | UUID | Identifies the function set. |
| Arg1 | Revision | Version of the function interface. |
| Arg2 | Function index | Selects a specific operation or query. |
| Arg3 | Package | Input arguments for that function. |
| Function 0 | Function support query | Usually returns a bitmask of supported functions. |
Real World Example: vendor feature switch
Method (_DSM, 4, Serialized)
{
If (LEqual (Arg0, ToUUID ("12345678-1234-1234-1234-123456789abc"))) {
Switch (ToInteger (Arg2)) {
Case (Zero) {
Return (Buffer() { 0x03 }) // function 0 and 1 supported
}
Case (One) {
Return (Package() { One, "FeatureEnabled" })
}
}
}
Return (Buffer() { 0x00 })
}This is not self-explanatory from the AML alone. You usually need the driver expectation, vendor documentation, or OS behavior to interpret the return value.
Debug Diary: OS-specific behavior
A common _DSM debug trap:
Windows driver calls UUID A, function 1 → feature enabled
Linux driver does not call the same _DSM → feature absent
Firmware engineer sees no ACPI error → still a platform integration issueThe bug may be in firmware, driver assumptions, or an unsupported vendor extension.
_DSM debug checklist
Firmware Engineer Notes
_DSM is powerful but dangerous. It can solve real platform gaps, but it can also hide undocumented behavior that only one OS driver understands.
For a Knowledge Base, I read _DSM as a boundary between firmware description and vendor driver contract.
Related notes
Found this useful?
Save it or share it with someone learning firmware, BIOS/UEFI, and embedded systems.
Nội dung liên quan
Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.
Device Manager Through Firmware Engineer Eyes
How to read Windows Device Manager symptoms as ACPI, PCI, resource, and firmware handoff clues.
RWEverything for Platform Debug
How RWEverything can help inspect ACPI, PCI, IO, memory, EC, and MSR state during Windows-side firmware debugging.
What is ACPI Method?
Quick note explaining ACPI Method for BIOS/UEFI and embedded firmware readers.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.