Differential D58863
intel: add hfsts debug-probe driver for Intel ME/HECI firmware status Authored by seuros on Aug 15 2026, 8:12 PM. Tags Referenced Files
Subscribers
Details Add an amd64-only, Intel-only diagnostic driver that reads ME Host Select the HFS register count per device generation, decode sparse
Diff Detail
Event TimelineThere are a very large number of changes, so older changes are hidden. Show Older Changes Comment Actions This is close, a couple inline nits still to address. I think the sysctls should be live queries, not just display attach time cached values. I'm not sure if the rename is the right direction; this claims the mei attachment exclusively so maybe just call it that the limited scope is in the man page. If someone wants to wire up extended functionality in the future this is a good base to do so?
Comment Actions
This driver probes and attaches to the MEI/HECI PCI function no matter of whether the ME is actually alive, it only decodes HFS1-6 out of PCI config space, so it attaches even when the ME firmware is disabled (HAP bit set, neutered coreboot boards, X200-class Libreboot machines where the ME region is yanked). A live-protocol mei(4) driver needs the ME to actually answer the handshake over the messaging BAR to attach at all. So the two have different attach preconditions, not just different feature scope. I renamed it because I want the mei name reserved for that real driver when it's written, which we will need for multi-GPU support,HDCP and lot other feauture/capabilities. That's a much bigger driver: Linux's drivers/misc/mei is 20k+ LOC even before adding board-specific quirks. If Intel or some company decides to sponsor someone or even author it, the mei namespace will be available. I might later try to take a stab at mei(4). I currently have all the hardware to test across multiple generation. PS: I'm fine in renaming it to something else like intel_fwstatus or me_status.. ect.. Comment Actions This is substantively fine, I would fix up these 6 new suggestions and then see if @adrian has any desire for the naming.
Comment Actions Shall we simply name it hfsts ? It loads fine on my MacBook13,1
Comment Actions I think hfstsfd(4) manpage should be a symbolic link to hfsts(4). I find it a bit confusing to understand why I don't have dev.hfstsfd.0 on my machine. The manpage does not explain this very well ("modeled after ichwd_identify()" is not a good explanation to the user). The source code, however, does this nicely: /* MEI enumerated on PCI, so it is not firmware-hidden. */
if (hfsts_pci_present())
return;So maybe something like this: If Host Firmware Status registers are available on the PCI bus, the `hfstsfd` driver is not needed and will not be loaded. Do I understand it right that, if hfstsfd driver attaches, dev.hfsts.0 will NOT be available? Another question, will other Management Engine functions be available (not supported by this read-only driver) if hfsts is disabled by the firmware? Comment Actions I'm waiting for @ziaee's review before i reword it, but i agree with you On dev.hfstsfd.0, yes, they are mutually exclusive. For your MacBook, there are two reasons hfstsfd does not attach. First, MEI is already visible. For your last question: no. If firmware hides HECI with Function Disable because it neutered, defective or HAP disabled, Comment Actions It could use a HARDWARE section too, but we can always add that later.
Comment Actions Also, sorry for the delay, and thanks so much for waiting for me and pinging me again! I actually didn't see the first one. Comment Actions The more I think about it I somehow think maybe the FD register check should end up in the isab(4) driver. Maybe we should also think how to collect common knowledge in some ich.c/ich,.h files so that all the ich* drivers can share that and get rid of /sys/dev/intel - but this is not for this PR :) Regarding the documentation, I understand from my reading of the code that all the play about having the MEI functions enabled/disabled is done in the PCI-ISA bridge component register, but this has nothing to do with the classic ISA or LPC bus. Am I right? In that case we shall not mention "ISA" or "LPC" in the documentation unless some classic ISA resources such as I/O ports are accessed. We should at most mention "PCI-ISA bridge function" or isab(4). If this is correct, "hfstsd" code could live in the isab(4) driver. Not sure if all this makes any sense, I just try to grasp the code. Comment Actions @ziaee let's get your stamp on this so I can then stamp it and seuros can land it with the correct attribution. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||