Re: [PATCH] bus: mhi: host: pci_generic: Add per-device ACPI reset

[Hongxing Xu]

Jeff,

You are right, and my wording was wrong. I will remove the claim from the
commit message.

Now the background, which I should have led with.

On Windows wwan modules are reset through PLDR. The platform firmware exposes
an ACPI method that drives the module's power and reset pins (FCPO#, RESET#,
PERST#) instead of resetting the SoC with the link in place, and the Windows
driver uses it for that. I am adding the Linux equivalent so that the same
board can be supported without a vendor driver.

What that path gives us, beyond simply being what the platform provides:

  - It does not depend on the endpoint's PCIe function being usable. No MMIO
    access, no config space access, no link.
  - The platform owns the pin sequence and the timing, so the host does not
    have to estimate it with a fixed delay.
  - The link goes down with the module's power, so the endpoint is
    re-enumerated and starts from a clean PCIe and MHI state.

Concretely, on two of our modules, RW135R (SDX35) and RW151 (SDX81), writing
soc_reset from Ubuntu reproduces exactly the situation your commit message
describes, and it does so every time rather than occasionally. The module does
come back on the bus, but it comes up reporting a MHI system error:
pci_generic takes MHI_CB_SYS_ERROR, logs "firmware crashed" and forbids
runtime PM, and from there nothing gets the MHI state back. The only thing
that recovers the module is a reboot, which is also the only step in the whole
flow that actually toggles PERST#. Resetting the same module through the ACPI
method recovers it every time, because the module is power cycled and the link
is retrained, instead of staying up across a reset that only targets the SoC.

So I am not asking for SOC_RESET to change. On these two boards it is not the
reset that gets the module back, and the platform already provides one that
does.

The point is narrower: these boards provide the host with a reset path that
the MHI driver currently has no way to reach, and the MediaTek vendor driver
already uses it. I only hope that the MHI driver can use this method as well.

Thanks for catching the first paragraph.