ACK/Cmnt: [PATCH 0/2][SRU][K/J/OEM-6.0] Fix iosm: WWAN cannot build the connection (DW5823e)

Cory Todd cory.todd at canonical.com
Wed Nov 30 15:47:11 UTC 2022


On Mon, Nov 28, 2022 at 10:41:54PM +0800, Koba Ko wrote:
> BugLink: https://bugs.launchpad.net/bugs/1998115
> 
> [Impact]
>  WWAN(DW5823e) can't build the connection successfully.
> 
> [Fix]
>  With INTEL_IOMMU disable config or by forcing intel_iommu=off from
>  grub some of the features of IOSM driver like browsing, flashing &
>  coredump collection is not working.
> 
>  When driver calls DMA API - dma_map_single() for tx transfers. It is
>  resulting in dma mapping error.
> 
>  Set the device DMA addressing capabilities using dma_set_mask() and
>  remove the INTEL_IOMMU dependency in kconfig so that driver follows
>  the platform config either INTEL_IOMMU enable or disable.
> 
>  Because the generic jammy(5.15) doesn't contain NET_DEVLINK and RELAY
>  CONFIGs yet on iosm module, the single patch is necessary for Jammy.
> 
> [Test Case]
>  1. boot up with kernel applied the FIX.
>  2. check the status of wwan by "mmcli -m 0"
>      Status| unlock retries: sim-pin (3)
>            | state: ^[32mconnected^[0m
>            | power state: on
>            | access tech: lte
>            | signal quality: 45% (recent)
>       ----------------------------------
>       3GPP | imei: ######
>            | enabled locks: sim, fixed-dialing
>            | operator id: 46692
>            | operator name: Chunghwa Telecom
>            | registration: home
>            | packet service state: attached
>            | pco:
>            | 0: (complete)
> 
> [Where problems could occur]
> remove the dependency for intel_iommu, iosm would fit better on other platforms not only Intel.
> 
> M Chetan Kumar (1):
>   net: wwan: iosm: fix driver not working with INTEL_IOMMU disabled
> 
>  drivers/net/wwan/Kconfig              | 2 +-
>  drivers/net/wwan/iosm/iosm_ipc_pcie.c | 7 +++++++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 

A minor nitpick since the patch routing is obvious in this case but
perhaps the numbering as shown below would have been more clear,
particularly for any scripts we may have handling these.

[PATCH 0/1][SRU][J/K/OEM-6.0] ...
[PATCH 1/1][SRU][J] ...
[PATCH 1/1][SRU][K/OEM-6.0] ...

Acked-by: Cory Todd <cory.todd at canonical.com>




More information about the kernel-team mailing list