hisilicon: SD cards on generic-sdhci machines come up write-protected — vendor driver inverts the WP bit, wp-inverted is never set #209

Symptom

On the HiSilicon machines that wire their SD slot as QEMU's generic-sdhci (hw/arm/hisilicon.c, the num_sdhci / sdhci_bases loop), every card attached with -drive if=sd is presented to the guest as write-protected. The OpenIPC kernel then registers it read-only, and every mount comes out ro:

mmcblk0: mmc0:3244 QEMU! 64.0 MiB (ro)
 mmcblk0: p1
/dev/mmcblk0p1 /mnt/mmcblk0p1 vfat ro,relatime,... 0 0

This applies to a writable raw image, the same way test-flash-rw.sh / test-firstboot.sh attach theirs. Those tests only read the card, so neither has noticed.

Cause

The vendor SDHCI driver reads the write-protect pin the opposite way from the SDHCI spec. drivers/mmc/host/sdhci-hisi.c in OpenIPC/linux's hisilicon-hi3516ev200 tarball (ev200 / ev300 / 18ev300 / dv200 all include it):

static const struct sdhci_pltfm_data sdhci_hisi_pdata = {
	.ops = &sdhci_hisi_ops,
	.quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
		  SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
	...

QEMU's sdhci_set_readonly() sets PRNSTS bit 19 (SDHC_WRITE_PROTECT) for a writable card. Linux's sdhci_check_ro() then inverts that because of the quirk, so the card comes out read-only. hisilicon.c never sets wp-inverted on its TYPE_SYSBUS_SDHCI instances. hw/arm/goke.c already handles the same thing for the GK710x SDIO (qdev_prop_set_bit(dev, "wp-inverted", true), citing gk_sd_get_ro).

Evidence (hi3516ev300, qemu-bench 07ec628, OpenIPC nightly-20261006-8a81fed)

Booted from a synthetic NOR as test-flash-rw.sh does, with a 64 MiB FAT32 card:

Suggested fix

In the SDHCI loop in hisilicon.c, qdev_prop_set_bit(sdhci, "wp-inverted", true) before realize, with a comment citing SDHCI_QUIRK_INVERTED_WRITE_PROTECT. A per-SoC flag would be needed if any of the other kernels behind this loop turn out not to carry the quirk.

Not verified: the kernels of the other machines that go through the same loop: hi3516cv608 / cv610 / cv613, hi3519dv500 / hi3516dv500 and gk7202v330. I have only checked the ev200-family sdhci-hisi.c. Their drivers should be checked for the same quirk before flipping it everywhere.

Why it matters

Any guest test that writes to the card, or depends on how a rw mount behaves, is testing something real cameras never do. I ran into it while reproducing OpenIPC/firmware#170 (kernel log noise from SD automount). A read-only device makes every rw mount attempt fail in the VFS before any filesystem's fill_super runs, so the noise that issue is about cannot appear.