Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

["manivannan.sadhasivam@linaro.org" <manivannan.sadhasivam@linaro.org>]

+ Slark (Foxconn PoC), MHI list

Hi Johannes,

On Fri, Jul 12, 2024 at 02:57:57PM +0000, Johannes Fischer wrote:
> Hi Mani,
> found you for a maintainer for the MHI package at kernel.org .
> 
> We are building up a BananaPi-R4  openwrt (snapshot) box where we ant to have a SierraWireless EM9191 modem in the M.2 slot being connected via PCIe. First, we had some trouble detecting the SIM, that is solved by isolating the SIM_DET pin on the module, the BPI-R4 has wrong logic on SIM detection contact (in opposite to statement in schematic). The EM9191 runs on almost latest firmware.
> The BPI-R4 has the specialty that FULL_CARD_POWER_OFF# and RESET# are not controlled by GPIO. PCIe Interface PERST is controlled as expected
> After solving this, adding right kernel modules and powering up the box we saw module coming up exposing a "wwan0" network interface and devices for AT, mbim(ctrl) and qxdm.
> We were able to set up traffic using mbim-network and mbim-set-ip script, very manual, no modemmanager or similar.
> After a reboot (or a pci device remove / pci bus rescan in sysfs) the modules showed up differently. We got a network interface named "mhi_hwip0", devices were AT, mbim(ctrl), qmi, qxdm.
> AT/qxdm was accessible, the mbim and qmi channels as well, however we were not able to start traffic by configuring the interface as before.
> 
> Looking at dmesg revealed the lines given below. The module looks to enumerate differently, reason is not known to us.
> 
> <power on>
> root@ROOter:~# dmesg | grep "MHI PCI device found"
> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
> root@ROOter:~# echo 1 > /sys/bus/pci/devices/0003:01:00.0/remove
> root@ROOter:~# echo 1 > /sys/bus/pci/rescan
> root@ROOter:~# dmesg | grep "MHI PCI device found"
> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
> [  144.317656] mhi-pci-generic 0003:01:00.0: MHI PCI device found: sierra-em919x
> root@ROOter:~##
> 

I believe the reason for 2 different enumeration behavior is due to the firmware
not detecting the reboot properly. So if your host SoC is not toggling the
PERST# as expected, you will end up seeing these kind of behaviors.

@Slark: Correct me if I'm wrong. Also please share the reboot steps expected by
the firmware.

During PCI remove/rescan, if the driver is unloaded then we just power down the
MHI stack, but don't reset the device. And when the driver is loaded again, it
again powers up the MHI stack. And this means, only the MHI state machine will
be reset. So this should not change the firmware flow. But I don't exactly know
how the firmware behaves. Maybe the firmware gets reset?

@Slark: Again, please share what is the expected behavior of the firmware during
host driver unload/reload.

> With this information I went into pci-generic.c and this showed for the two types of devices
> static const struct mhi_channel_config mhi_foxconn_sdx55_channels[] = {
>                 MHI_CHANNEL_CONFIG_UL(0, "LOOPBACK", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(1, "LOOPBACK", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 1),
>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 1),
>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0_MBIM", 128, 2),
>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0_MBIM", 128, 3),
> };
> 
> And
> 
> static const struct mhi_channel_config mhi_sierra_em919x_channels[] = {
>                 MHI_CHANNEL_CONFIG_UL_SBL(2, "SAHARA", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL_SBL(3, "SAHARA", 256, 0),
>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 128, 0),
>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 128, 0),
>                 MHI_CHANNEL_CONFIG_UL(14, "QMI", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(15, "QMI", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0", 512, 1),
>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0", 512, 2),
> };
> 
> Here you can see, that the IP channels are configured differently.
> 
> I gave it a try and configure the IP channels for EM919x for MBIM as well.
> This solved the issue, EM9191 enumerates now for "wwan0" as well after restart of the PCIe link by rescan and reboot.
> 
> Th EM9191 is a 5GNR Sub6 module and follow the QC strategy only to expose MBIM for IP connectivity, RMNET and RNDIS are not supported as per documentation.
> 
> My question here would be why this got not reported before, I see a lot of activities ongoing for Foxconn-SDX55 but low for the restart issues. It may be the the missing GPIOs for RESET#/FULL_CARD_POWER_OFF# are special for the BPI-R4 board. We saw for Techship MC201 that these can be directed to GPIO by setting a jumper. Maybe Lenovo laptops etc always invoke RESET# if such modules have to recover.
> 
> Anyway, I think we can live with the change, proposal would be to add this to upstream.  Question is still open, why it enumerates differently.
> 

No, we cannot change the modem config due errantic firmware behavior. This will
affect other modems depending on this config.

Let's hear from Slark first.

- Mani

-- 
மணிவண்ணன் சதாசிவம்