RFC: mb/google/puff/kaisa: investigate hiding absent eMMC

[jackadam1981]

RFC / investigation draft

This PR is intentionally left as a draft. The current patch is useful as a tested experiment, but it should not be merged as-is because it hard-codes a single Kaisa CBI SKU (0x01000006 / sku16777222) as the NVMe SKU.

The maintainer feedback is valid: I do not currently have a complete public SKU-to-storage matrix for all KAISA units, so the change should not rely on SKU matching alone.

What was observed

On the tested KAISA-WVRW unit:

• The onboard eMMC controller is exposed as PCI 00:1a.0 (8086:02c4).
• The removable SD/TF card reader is a separate controller at PCI 00:14.5 (8086:02f5).
• The machine boots from NVMe at PCI 02:00.0.
• There is no observed onboard eMMC media on this NVMe unit.

The current experimental patch disables only PCH_DEVFN_EMMC; it does not disable the SD/TF reader.

Source-level notes

Puff/Kaisa already has a suitable timing hook for this kind of change:

• variant_devtree_update() is called from mainboard_silicon_init_params() before FSP-S parameters are finalized.
• Cannon Lake sets ScsEmmcEnabled from is_devfn_enabled(PCH_DEVFN_EMMC), so disabling the eMMC device there affects the FSP-S eMMC enable path.

Newer Google boards often solve this more cleanly with FW_CONFIG-backed devicetree probes, for example probe STORAGE STORAGE_EMMC / probe STORAGE STORAGE_NVME. I have not found an equivalent STORAGE FW_CONFIG field for KAISA in the current Puff/Kaisa devicetree.

Open question

The right fix should hide the eMMC controller only when eMMC storage is actually absent, or when a reliable board-provided configuration bit says the storage type is not eMMC.

I am keeping this PR as an RFC while looking for one of these:

• an official KAISA storage FW_CONFIG / CBI field,
• a documented KAISA SKU/HWID storage matrix,
• or an acceptable runtime absence-detection path that does not overcomplicate early boot.

Validation of the experiment

• Built Kaisa on MrChromebox-2603.
• Flashed the generated ROM on the tested KAISA-WVRW unit; flashrom write and verify passed.
• After reboot on the tested unit:
  • 00:1a.0 onboard eMMC controller was no longer enumerated.
  • 00:14.5 SD/TF card reader remained enumerated.
  • NVMe remained present at 02:00.0.

[MrChromebox]

how did you determine which SKU(s) are NVMe for KAISA?

[jackadam1981]

I rechecked this and the current SKU-based patch is not sufficiently justified for merge as-is. The tested KAISA-WVRW unit is NVMe and has no observed eMMC media, but I do not have a complete public KAISA SKU-to-storage matrix.

I have updated this PR into an RFC/investigation draft. The useful part of the experiment is that variant_devtree_update() happens early enough to affect ScsEmmcEnabled, and the tested change disables only the onboard eMMC controller (00:1a.0) while leaving the separate SD/TF reader (00:14.5) enabled.

The better fix should use a reliable absence/configuration signal instead of hard-coding this SKU. I am looking for a KAISA storage FW_CONFIG/CBI field, documented HWID/SKU mapping, or another acceptable runtime absence-detection path.

[MrChromebox]

FW_CONFIG/CBI is not reliable, and doesn't account for users installing NVMe on a device that originally shipped with eMMC - had this issue on another board. But maybe that's not an issue on puff boards?

the NVMe is always on PCIe RP9, you could potentially check if a downstream device is present, and if so disable the eMMC?