Previously tested in every generation till Raptor Lake.

Tested now in Meteor Lake , Lunar Lake and Arrow Lake.

Missing is Panther Lake, and few Laptop architectures.

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?

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?

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..

Shall we simply name it hfsts ? It loads fine on my MacBook13,1

Some followups: Add NOTES entry on commit. Later consider MODULE_PNP_INFO. LGTM.

@ziaee Your signoff on the man page. Then we can land this.

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?

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.
If MEI is visible on PCI, hfsts_fd_identify() returns before adding the child, and hfsts attaches normally.
So you get either dev.hfsts.0 or dev.hfstsfd.0, never together.

For your MacBook, there are two reasons hfstsfd does not attach. First, MEI is already visible.
Second, hfstsfd only supports Ibex Peak through Wildcat Point, where I know the RCBA+FD2 layout.
Sunrise Point uses the newer P2SB/PCR mechanism, that i did not dig into.
The PCH list in the man page implies this, but I will make it clearer.

For your last question: no. If firmware hides HECI with Function Disable because it neutered, defective or HAP disabled,
the PCI function does not exist from the host's point of view. A full mei(4) would not even attach.

It could use a HARDWARE section too, but we can always add that later.

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.

Just whitespace nitpicks.

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.