[PATCH 0/3] SM8450 IPA support

[PATCH 0/3] SM8450 IPA support

[Esteban Urrutia via B4 Relay]

This series adds support for the IPA subsystem found in the SM8450 SoC.
While IPA v5.0 is very similar to IPA v5.1 (heck, it even managed to
properly get the modem up and running), it wasn't perfect, since the
modem would sometimes hang when rebooting or powering the AP off.
After a thorough investigation, I managed to create the proper data file
required for IPA v5.1.

Regards,
Esteban

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
Esteban Urrutia (3):
      arm64: dts: qcom: sm8450: Add IPA support
      dt-bindings: net: qcom,ipa: Add SM8450 compatible string
      net: ipa: Add IPA v5.1 data

 .../devicetree/bindings/net/qcom,ipa.yaml          |   1 +
 arch/arm64/boot/dts/qcom/sm8450.dtsi               |  55 ++-
 drivers/net/ipa/Makefile                           |   2 +-
 drivers/net/ipa/data/ipa_data-v5.1.c               | 477 +++++++++++++++++++++
 drivers/net/ipa/gsi_reg.c                          |   1 +
 drivers/net/ipa/ipa_data.h                         |   1 +
 drivers/net/ipa/ipa_main.c                         |   4 +
 drivers/net/ipa/ipa_reg.c                          |   1 +
 8 files changed, 536 insertions(+), 6 deletions(-)
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260622-sm8450-ipa-5da81f67eb65

Best regards,
--  
Esteban Urrutia <esteuwu@proton.me>

[PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Esteban Urrutia via B4 Relay]

From: Esteban Urrutia <esteuwu@proton.me>

Add support for IPA in DT while expanding the IMEM region just enough to
accommodate the modem tables used by IPA.
As reference, SM8450 uses IPA v5.1.

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 55 ++++++++++++++++++++++++++++++++----
 1 file changed, 50 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 56cb6e959e4e..c904720008fa 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -2639,6 +2639,47 @@ adreno_smmu: iommu@3da0000 {
 			dma-coherent;
 		};
 
+		ipa: ipa@3f40000 {
+			compatible = "qcom,sm8450-ipa";
+
+			iommus = <&apps_smmu 0x5c0 0x0>,
+				 <&apps_smmu 0x5c2 0x0>;
+			reg = <0 0x3f40000 0 0x10000>,
+			      <0 0x3f50000 0 0x5000>,
+			      <0 0x3e04000 0 0xfc000>;
+			reg-names = "ipa-reg",
+				    "ipa-shared",
+				    "gsi";
+
+			interrupts-extended = <&intc GIC_SPI 654 IRQ_TYPE_EDGE_RISING>,
+					      <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
+					      <&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+					      <&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "ipa",
+					  "gsi",
+					  "ipa-clock-query",
+					  "ipa-setup-ready";
+
+			clocks = <&rpmhcc RPMH_IPA_CLK>;
+			clock-names = "core";
+
+			interconnects = <&aggre2_noc MASTER_IPA 0 &mc_virt SLAVE_EBI1 0>,
+					<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_IPA_CFG 0>;
+			interconnect-names = "memory",
+					     "config";
+
+			qcom,qmp = <&aoss_qmp>;
+
+			qcom,smem-states = <&ipa_smp2p_out 0>,
+					   <&ipa_smp2p_out 1>;
+			qcom,smem-state-names = "ipa-clock-enabled-valid",
+						"ipa-clock-enabled";
+
+			sram = <&ipa_modem_tables>;
+
+			status = "disabled";
+		};
+
 		usb_1_hsphy: phy@88e3000 {
 			compatible = "qcom,sm8450-usb-hs-phy",
 				     "qcom,usb-snps-hs-7nm-phy";
@@ -4970,17 +5011,21 @@ cti@13900000 {
 			clock-names = "apb_pclk";
 		};
 
-		sram@146aa000 {
+		sram@146a8000 {
 			compatible = "qcom,sm8450-imem", "syscon", "simple-mfd";
-			reg = <0 0x146aa000 0 0x1000>;
-			ranges = <0 0 0x146aa000 0x1000>;
+			reg = <0 0x146a8000 0 0x3000>;
+			ranges = <0 0 0x146a8000 0x3000>;
 
 			#address-cells = <1>;
 			#size-cells = <1>;
 
-			pil-reloc@94c {
+			ipa_modem_tables: modem-tables@0 {
+				reg = <0 0x2000>;
+			};
+
+			pil-reloc@294c {
 				compatible = "qcom,pil-reloc-info";
-				reg = <0x94c 0xc8>;
+				reg = <0x294c 0xc8>;
 			};
 		};
 

-- 
2.54.0

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Krzysztof Kozlowski]

On Mon, Jun 22, 2026 at 09:44:17PM -0400, Esteban Urrutia wrote:
> Add support for IPA in DT while expanding the IMEM region just enough to
> accommodate the modem tables used by IPA.
> As reference, SM8450 uses IPA v5.1.
> 
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
>  arch/arm64/boot/dts/qcom/sm8450.dtsi | 55 ++++++++++++++++++++++++++++++++----
>  1 file changed, 50 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 56cb6e959e4e..c904720008fa 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2639,6 +2639,47 @@ adreno_smmu: iommu@3da0000 {
>  			dma-coherent;
>  		};
>  
> +		ipa: ipa@3f40000 {
> +			compatible = "qcom,sm8450-ipa";
> +
> +			iommus = <&apps_smmu 0x5c0 0x0>,
> +				 <&apps_smmu 0x5c2 0x0>;
> +			reg = <0 0x3f40000 0 0x10000>,

'reg' is always the second property, followed by reg-names.

> +			      <0 0x3f50000 0 0x5000>,
> +			      <0 0x3e04000 0 0xfc000>;
> +			reg-names = "ipa-reg",
> +				    "ipa-shared",
> +				    "gsi";

Best regards,
Krzysztof

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Konrad Dybcio]

On 6/23/26 3:44 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
> 
> Add support for IPA in DT while expanding the IMEM region just enough to
> accommodate the modem tables used by IPA.
> As reference, SM8450 uses IPA v5.1.
> 
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---

[...]

>  arch/arm64/boot/dts/qcom/sm8450.dtsi | 55 ++++++++++++++++++++++++++++++++----
>  1 file changed, 50 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 56cb6e959e4e..c904720008fa 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2639,6 +2639,47 @@ adreno_smmu: iommu@3da0000 {
>  			dma-coherent;
>  		};
>  
> +		ipa: ipa@3f40000 {
> +			compatible = "qcom,sm8450-ipa";
> +
> +			iommus = <&apps_smmu 0x5c0 0x0>,
> +				 <&apps_smmu 0x5c2 0x0>;
> +			reg = <0 0x3f40000 0 0x10000>,
> +			      <0 0x3f50000 0 0x5000>,

size = 0xb0000 for the RAM and uC regions that the driver seems
to poke at (at a glance anyway..)

[...]

>  		usb_1_hsphy: phy@88e3000 {
>  			compatible = "qcom,sm8450-usb-hs-phy",
>  				     "qcom,usb-snps-hs-7nm-phy";
> @@ -4970,17 +5011,21 @@ cti@13900000 {
>  			clock-names = "apb_pclk";
>  		};
>  
> -		sram@146aa000 {
> +		sram@146a8000 {
>  			compatible = "qcom,sm8450-imem", "syscon", "simple-mfd";
> -			reg = <0 0x146aa000 0 0x1000>;
> -			ranges = <0 0 0x146aa000 0x1000>;
> +			reg = <0 0x146a8000 0 0x3000>;

base=0x1468_0000
size=0x40_000

Konrad

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Esteban Urrutia]

On 6/23/26 5:37 AM, Konrad Dybcio wrote:
> size = 0xb0000 for the RAM and uC regions that the driver seems
> to poke at (at a glance anyway..)

Sorry, I don't quite understand. Could you please clarify?

> base=0x1468_0000
> size=0x40_000

Noted, will fix in v2.

Regards,
Esteban

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Konrad Dybcio]

On 6/24/26 3:52 AM, Esteban Urrutia wrote:
> On 6/23/26 5:37 AM, Konrad Dybcio wrote:
>> size = 0xb0000 for the RAM and uC regions that the driver seems
>> to poke at (at a glance anyway..)
> 
> Sorry, I don't quite understand. Could you please clarify?

Please alter the size of the register range that I mentioned this under,
as the range is wider than what you specified - the driver takes a big
offset from this base and accesses far outside the bounds of that range

Konrad

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Esteban Urrutia]

On 6/29/26 10:18 AM, Konrad Dybcio wrote:
> Please alter the size of the register range that I mentioned this under,
> as the range is wider than what you specified - the driver takes a big
> offset from this base and accesses far outside the bounds of that range
Just to make sure:

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index dd151a2c48ec..100daf8120ce 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -2643,7 +2643,7 @@ ipa: ipa@3f40000 {
                        compatible = "qcom,sm8450-ipa";
 
                        reg = <0 0x3f40000 0 0x10000>,
-                             <0 0x3f50000 0 0x5000>,
+                             <0 0x3f50000 0 0xb0000>,
                              <0 0x3e04000 0 0xfc000>;
                        reg-names = "ipa-reg",
                                    "ipa-shared",

Is this what you're referring to?

Regards,
Esteban

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Konrad Dybcio]

On 6/30/26 3:57 AM, Esteban Urrutia wrote:
> On 6/29/26 10:18 AM, Konrad Dybcio wrote:
>> Please alter the size of the register range that I mentioned this under,
>> as the range is wider than what you specified - the driver takes a big
>> offset from this base and accesses far outside the bounds of that range
> Just to make sure:
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index dd151a2c48ec..100daf8120ce 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2643,7 +2643,7 @@ ipa: ipa@3f40000 {
>                         compatible = "qcom,sm8450-ipa";
>  
>                         reg = <0 0x3f40000 0 0x10000>,
> -                             <0 0x3f50000 0 0x5000>,
> +                             <0 0x3f50000 0 0xb0000>,
>                               <0 0x3e04000 0 0xfc000>;
>                         reg-names = "ipa-reg",
>                                     "ipa-shared",
> 
> Is this what you're referring to?

Yes

Konrad

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support

[Esteban Urrutia]

On 7/7/26 6:35 AM, Konrad Dybcio wrote:
> Yes

On SM8475 I get this warning though:

[    9.551813] ipa 3f40000.ipa: limiting IPA memory size to 0x00005000

Both SM8450 and SM8475 use the same IPA version, so that shouldn't be an
issue.
On SM8550 and SM8650 this area is set to 0x5000 as well.
What should the proper solution be?

Regards,
Esteban

[PATCH 2/3] dt-bindings: net: qcom,ipa: Add SM8450 compatible string

[Esteban Urrutia via B4 Relay]

From: Esteban Urrutia <esteuwu@proton.me>

Declare compatible string in ipa binding for SM8450,
which uses IPA v5.1.

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
 Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
index 68ec76fe4473..db91bfaaf833 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -53,6 +53,7 @@ properties:
           - qcom,sdx65-ipa
           - qcom,sm6350-ipa
           - qcom,sm8350-ipa
+          - qcom,sm8450-ipa
           - qcom,sm8550-ipa
       - items:
           - enum:

-- 
2.54.0

Re: [PATCH 2/3] dt-bindings: net: qcom,ipa: Add SM8450 compatible string

[Krzysztof Kozlowski]

On Mon, Jun 22, 2026 at 09:44:18PM -0400, Esteban Urrutia wrote:
> Declare compatible string in ipa binding for SM8450,
> which uses IPA v5.1.

Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597

Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46

With this fixed:

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH 3/3] net: ipa: Add IPA v5.1 data

[Esteban Urrutia via B4 Relay]

From: Esteban Urrutia <esteuwu@proton.me>

Add the required ipa_data-v5.1.c file for IPA v5.1 along with changes
that declare IPA v5.1 support.
This version of IPA is used in both SM8450 and SM8475 SoCs.

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
 drivers/net/ipa/Makefile             |   2 +-
 drivers/net/ipa/data/ipa_data-v5.1.c | 477 +++++++++++++++++++++++++++++++++++
 drivers/net/ipa/gsi_reg.c            |   1 +
 drivers/net/ipa/ipa_data.h           |   1 +
 drivers/net/ipa/ipa_main.c           |   4 +
 drivers/net/ipa/ipa_reg.c            |   1 +
 6 files changed, 485 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ipa/Makefile b/drivers/net/ipa/Makefile
index e148ec3c1a10..d4995c2e8ca0 100644
--- a/drivers/net/ipa/Makefile
+++ b/drivers/net/ipa/Makefile
@@ -7,7 +7,7 @@ IPA_REG_VERSIONS	:=	3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.5
 # Some IPA versions can reuse another set of GSI register definitions.
 GSI_REG_VERSIONS	:=	3.1 3.5.1 4.0 4.5 4.9 4.11 5.0
 
-IPA_DATA_VERSIONS	:=	3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.2 5.5
+IPA_DATA_VERSIONS	:=	3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.1 5.2 5.5
 
 obj-$(CONFIG_QCOM_IPA)	+=	ipa.o
 
diff --git a/drivers/net/ipa/data/ipa_data-v5.1.c b/drivers/net/ipa/data/ipa_data-v5.1.c
new file mode 100644
index 000000000000..85b21efa1224
--- /dev/null
+++ b/drivers/net/ipa/data/ipa_data-v5.1.c
@@ -0,0 +1,477 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* Copyright (C) 2023-2024 Linaro Ltd. */
+/* Copyright (C) 2026 Esteban Urrutia <esteuwu@proton.me> */
+
+#include <linux/array_size.h>
+#include <linux/log2.h>
+
+#include "../ipa_data.h"
+#include "../ipa_endpoint.h"
+#include "../ipa_mem.h"
+#include "../ipa_version.h"
+
+/** enum ipa_resource_type - IPA resource types for an SoC having IPA v5.1 */
+enum ipa_resource_type {
+	/* Source resource types; first must have value 0 */
+	IPA_RESOURCE_TYPE_SRC_PKT_CONTEXTS		= 0,
+	IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_LISTS,
+	IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_BUFF,
+	IPA_RESOURCE_TYPE_SRC_HPS_DMARS,
+	IPA_RESOURCE_TYPE_SRC_ACK_ENTRIES,
+
+	/* Destination resource types; first must have value 0 */
+	IPA_RESOURCE_TYPE_DST_DATA_SECTORS		= 0,
+	IPA_RESOURCE_TYPE_DST_DPS_DMARS,
+	IPA_RESOURCE_TYPE_DST_ULSO_SEGMENTS,
+};
+
+/* Resource groups used for an SoC having IPA v5.1 */
+enum ipa_rsrc_group_id {
+	/* Source resource group identifiers */
+	IPA_RSRC_GROUP_SRC_UL				= 0,
+	IPA_RSRC_GROUP_SRC_DL,
+	IPA_RSRC_GROUP_SRC_UNUSED_2,
+	IPA_RSRC_GROUP_SRC_UNUSED_3,
+	IPA_RSRC_GROUP_SRC_URLLC,
+	IPA_RSRC_GROUP_SRC_U_RX_QC,
+	IPA_RSRC_GROUP_SRC_COUNT,	/* Last in set; not a source group */
+
+	/* Destination resource group identifiers */
+	IPA_RSRC_GROUP_DST_UL				= 0,
+	IPA_RSRC_GROUP_DST_DL,
+	IPA_RSRC_GROUP_DST_UNUSED_2,
+	IPA_RSRC_GROUP_DST_UNUSED_3,
+	IPA_RSRC_GROUP_DST_UNUSED_4,
+	IPA_RSRC_GROUP_DST_UC,
+	IPA_RSRC_GROUP_DST_DRB_IP,
+	IPA_RSRC_GROUP_DST_COUNT,	/* Last; not a destination group */
+};
+
+/* QSB configuration data for an SoC having IPA v5.1 */
+static const struct ipa_qsb_data ipa_qsb_data[] = {
+	[IPA_QSB_MASTER_DDR] = {
+		.max_writes		= 0,
+		.max_reads		= 0,	/* no limit (hardware max) */
+		.max_reads_beats	= 0,
+	},
+	[IPA_QSB_MASTER_PCIE] = {
+		.max_writes		= 0,
+		.max_reads		= 0,	/* no limit (hardware max) */
+		.max_reads_beats	= 0,
+	},
+};
+
+/* Endpoint configuration data for an SoC having IPA v5.1 */
+static const struct ipa_gsi_endpoint_data ipa_gsi_endpoint_data[] = {
+	[IPA_ENDPOINT_AP_COMMAND_TX] = {
+		.ee_id		= GSI_EE_AP,
+		.channel_id	= 12,
+		.endpoint_id	= 14,
+		.toward_ipa	= true,
+		.channel = {
+			.tre_count	= 256,
+			.event_count	= 256,
+			.tlv_count	= 20,
+		},
+		.endpoint = {
+			.config = {
+				.resource_group	= IPA_RSRC_GROUP_SRC_UL,
+				.dma_mode	= true,
+				.dma_endpoint	= IPA_ENDPOINT_AP_LAN_RX,
+				.tx = {
+					.seq_type = IPA_SEQ_DMA,
+				},
+			},
+		},
+	},
+	[IPA_ENDPOINT_AP_LAN_RX] = {
+		.ee_id		= GSI_EE_AP,
+		.channel_id	= 13,
+		.endpoint_id	= 16,
+		.toward_ipa	= false,
+		.channel = {
+			.tre_count	= 256,
+			.event_count	= 256,
+			.tlv_count	= 9,
+		},
+		.endpoint = {
+			.config = {
+				.resource_group	= IPA_RSRC_GROUP_DST_UL,
+				.aggregation	= true,
+				.status_enable	= true,
+				.rx = {
+					.buffer_size	= 8192,
+					.pad_align	= ilog2(sizeof(u32)),
+					.aggr_time_limit = 500,
+				},
+			},
+		},
+	},
+	[IPA_ENDPOINT_AP_MODEM_TX] = {
+		.ee_id		= GSI_EE_AP,
+		.channel_id	= 11,
+		.endpoint_id	= 2,
+		.toward_ipa	= true,
+		.channel = {
+			.tre_count	= 512,
+			.event_count	= 512,
+			.tlv_count	= 25,
+		},
+		.endpoint = {
+			.filter_support	= true,
+			.config = {
+				.resource_group	= IPA_RSRC_GROUP_SRC_UL,
+				.checksum       = true,
+				.qmap		= true,
+				.status_enable	= true,
+				.tx = {
+					.seq_type = IPA_SEQ_2_PASS_SKIP_LAST_UC,
+					.status_endpoint =
+						IPA_ENDPOINT_MODEM_AP_RX,
+				},
+			},
+		},
+	},
+	[IPA_ENDPOINT_AP_MODEM_RX] = {
+		.ee_id		= GSI_EE_AP,
+		.channel_id	= 1,
+		.endpoint_id	= 23,
+		.toward_ipa	= false,
+		.channel = {
+			.tre_count	= 256,
+			.event_count	= 256,
+			.tlv_count	= 9,
+		},
+		.endpoint = {
+			.config = {
+				.resource_group	= IPA_RSRC_GROUP_DST_UL,
+				.checksum       = true,
+				.qmap		= true,
+				.aggregation	= true,
+				.rx = {
+					.buffer_size	= 8192,
+					.aggr_time_limit = 500,
+					.aggr_close_eof	= true,
+				},
+			},
+		},
+	},
+	[IPA_ENDPOINT_MODEM_AP_TX] = {
+		.ee_id		= GSI_EE_MODEM,
+		.channel_id	= 0,
+		.endpoint_id	= 12,
+		.toward_ipa	= true,
+		.endpoint = {
+			.filter_support	= true,
+		},
+	},
+	[IPA_ENDPOINT_MODEM_AP_RX] = {
+		.ee_id		= GSI_EE_MODEM,
+		.channel_id	= 7,
+		.endpoint_id	= 21,
+		.toward_ipa	= false,
+	},
+	[IPA_ENDPOINT_MODEM_DL_NLO_TX] = {
+		.ee_id		= GSI_EE_MODEM,
+		.channel_id	= 2,
+		.endpoint_id	= 15,
+		.toward_ipa	= true,
+		.endpoint = {
+			.filter_support	= true,
+		},
+	},
+};
+
+/* Source resource configuration data for an SoC having IPA v5.1 */
+static const struct ipa_resource ipa_resource_src[] = {
+	[IPA_RESOURCE_TYPE_SRC_PKT_CONTEXTS] = {
+		.limits[IPA_RSRC_GROUP_SRC_UL] = {
+			.min = 7,	.max = 12,
+		},
+		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+			.min = 1,	.max = 63,
+		},
+		.limits[IPA_RSRC_GROUP_SRC_U_RX_QC] = {
+			.min = 0,	.max = 63,
+		},
+	},
+	[IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_LISTS] = {
+		.limits[IPA_RSRC_GROUP_SRC_UL] = {
+			.min = 21,	.max = 21,
+		},
+		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+			.min = 10,	.max = 10,
+		},
+	},
+	[IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_BUFF] = {
+		.limits[IPA_RSRC_GROUP_SRC_UL] = {
+			.min = 33,	.max = 33,
+		},
+		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+			.min = 20,	.max = 20,
+		},
+	},
+	[IPA_RESOURCE_TYPE_SRC_HPS_DMARS] = {
+		.limits[IPA_RSRC_GROUP_SRC_UL] = {
+			.min = 0,	.max = 63,
+		},
+		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+			.min = 1,	.max = 63,
+		},
+		.limits[IPA_RSRC_GROUP_SRC_U_RX_QC] = {
+			.min = 0,	.max = 63,
+		},
+	},
+	[IPA_RESOURCE_TYPE_SRC_ACK_ENTRIES] = {
+		.limits[IPA_RSRC_GROUP_SRC_UL] = {
+			.min = 38,	.max = 38,
+		},
+		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+			.min = 16,	.max = 16,
+		},
+	},
+};
+
+/* Destination resource configuration data for an SoC having IPA v5.1 */
+static const struct ipa_resource ipa_resource_dst[] = {
+	[IPA_RESOURCE_TYPE_DST_DATA_SECTORS] = {
+		.limits[IPA_RSRC_GROUP_DST_UL] = {
+			.min = 6,	.max = 6,
+		},
+		.limits[IPA_RSRC_GROUP_DST_DL] = {
+			.min = 5,	.max = 5,
+		},
+		.limits[IPA_RSRC_GROUP_DST_DRB_IP] = {
+			.min = 39,	.max = 39,
+		},
+	},
+	[IPA_RESOURCE_TYPE_DST_DPS_DMARS] = {
+		.limits[IPA_RSRC_GROUP_DST_UL] = {
+			.min = 0,	.max = 3,
+		},
+		.limits[IPA_RSRC_GROUP_DST_DL] = {
+			.min = 0,	.max = 3,
+		},
+	},
+	[IPA_RESOURCE_TYPE_DST_ULSO_SEGMENTS] = {
+		.limits[IPA_RSRC_GROUP_DST_UL] = {
+			.min = 0,	.max = 63,
+		},
+		.limits[IPA_RSRC_GROUP_DST_DL] = {
+			.min = 0,	.max = 63,
+		},
+	},
+};
+
+/* Resource configuration data for an SoC having IPA v5.1 */
+static const struct ipa_resource_data ipa_resource_data = {
+	.rsrc_group_dst_count	= IPA_RSRC_GROUP_DST_COUNT,
+	.rsrc_group_src_count	= IPA_RSRC_GROUP_SRC_COUNT,
+	.resource_src_count	= ARRAY_SIZE(ipa_resource_src),
+	.resource_src		= ipa_resource_src,
+	.resource_dst_count	= ARRAY_SIZE(ipa_resource_dst),
+	.resource_dst		= ipa_resource_dst,
+};
+
+/* IPA-resident memory region data for an SoC having IPA v5.1 */
+static const struct ipa_mem ipa_mem_local_data[] = {
+	{
+		.id		= IPA_MEM_UC_EVENT_RING,
+		.offset		= 0x0000,
+		.size		= 0x1000,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_UC_SHARED,
+		.offset		= 0x1000,
+		.size		= 0x0080,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_UC_INFO,
+		.offset		= 0x1080,
+		.size		= 0x0200,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_V4_FILTER_HASHED,
+		.offset		= 0x1288,
+		.size		= 0x0078,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_V4_FILTER,
+		.offset		= 0x1308,
+		.size		= 0x0078,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_V6_FILTER_HASHED,
+		.offset		= 0x1388,
+		.size		= 0x0078,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_V6_FILTER,
+		.offset		= 0x1408,
+		.size		= 0x0078,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_V4_ROUTE_HASHED,
+		.offset		= 0x1488,
+		.size		= 0x0098,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_V4_ROUTE,
+		.offset		= 0x1528,
+		.size		= 0x0098,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_V6_ROUTE_HASHED,
+		.offset		= 0x15c8,
+		.size		= 0x0098,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_V6_ROUTE,
+		.offset		= 0x1668,
+		.size		= 0x0098,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_MODEM_HEADER,
+		.offset		= 0x1708,
+		.size		= 0x0240,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_AP_HEADER,
+		.offset		= 0x1948,
+		.size		= 0x01e0,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_MODEM_PROC_CTX,
+		.offset		= 0x1b40,
+		.size		= 0x0b20,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_AP_PROC_CTX,
+		.offset		= 0x2660,
+		.size		= 0x0200,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_STATS_QUOTA_MODEM,
+		.offset		= 0x2868,
+		.size		= 0x0060,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_STATS_QUOTA_AP,
+		.offset		= 0x28c8,
+		.size		= 0x0048,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_STATS_TETHERING,
+		.offset		= 0x2910,
+		.size		= 0x03c0,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_AP_V4_FILTER,
+		.offset		= 0x29b8,
+		.size		= 0x0188,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_AP_V6_FILTER,
+		.offset		= 0x2b40,
+		.size		= 0x0228,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_STATS_FILTER_ROUTE,
+		.offset		= 0x2cd0,
+		.size		= 0x0ba0,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_STATS_DROP,
+		.offset		= 0x3870,
+		.size		= 0x0020,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_MODEM,
+		.offset		= 0x3898,
+		.size		= 0x0d48,
+		.canary_count	= 2,
+	},
+	{
+		.id		= IPA_MEM_NAT_TABLE,
+		.offset		= 0x45e0,
+		.size		= 0x0900,
+		.canary_count	= 0,
+	},
+	{
+		.id		= IPA_MEM_PDN_CONFIG,
+		.offset		= 0x4ee8,
+		.size		= 0x0100,
+		.canary_count	= 2,
+	},
+};
+
+/* Memory configuration data for an SoC having IPA v5.1 */
+static const struct ipa_mem_data ipa_mem_data = {
+	.local_count	= ARRAY_SIZE(ipa_mem_local_data),
+	.local		= ipa_mem_local_data,
+	.imem_addr	= 0x146a8000,
+	.imem_size	= 0x00002000,
+	/*
+	 * While this value is 0xb000 on SM8450 and 0x9000 on SM8475,
+	 * it has been left set to 0x9000 for compatibility with SM8475
+	 */
+	.smem_size	= 0x00009000,
+};
+
+/* Interconnect rates are in 1000 byte/second units */
+static const struct ipa_interconnect_data ipa_interconnect_data[] = {
+	{
+		.name			= "memory",
+		.peak_bandwidth		= 1900000,	/* 1.9 GBps */
+		.average_bandwidth	= 590000,	/* 590 MBps */
+	},
+	/* Average rate is unused for the next interconnect */
+	{
+		.name			= "config",
+		.peak_bandwidth		= 76800,	/* 76.8 MBps */
+		.average_bandwidth	= 0,		/* unused */
+	},
+};
+
+/* Clock and interconnect configuration data for an SoC having IPA v5.1 */
+static const struct ipa_power_data ipa_power_data = {
+	.core_clock_rate	= 120 * 1000 * 1000,	/* Hz */
+	.interconnect_count	= ARRAY_SIZE(ipa_interconnect_data),
+	.interconnect_data	= ipa_interconnect_data,
+};
+
+/* Configuration data for an SoC having IPA v5.1. */
+const struct ipa_data ipa_data_v5_1 = {
+	.version		= IPA_VERSION_5_1,
+	.qsb_count		= ARRAY_SIZE(ipa_qsb_data),
+	.qsb_data		= ipa_qsb_data,
+	.modem_route_count	= 11,
+	.endpoint_count		= ARRAY_SIZE(ipa_gsi_endpoint_data),
+	.endpoint_data		= ipa_gsi_endpoint_data,
+	.resource_data		= &ipa_resource_data,
+	.mem_data		= &ipa_mem_data,
+	.power_data		= &ipa_power_data,
+};
diff --git a/drivers/net/ipa/gsi_reg.c b/drivers/net/ipa/gsi_reg.c
index e13cf835a013..a57072ba4bef 100644
--- a/drivers/net/ipa/gsi_reg.c
+++ b/drivers/net/ipa/gsi_reg.c
@@ -110,6 +110,7 @@ static const struct regs *gsi_regs(struct gsi *gsi)
 		return &gsi_regs_v4_11;
 
 	case IPA_VERSION_5_0:
+	case IPA_VERSION_5_1:
 	case IPA_VERSION_5_2:
 	case IPA_VERSION_5_5:
 		return &gsi_regs_v5_0;
diff --git a/drivers/net/ipa/ipa_data.h b/drivers/net/ipa/ipa_data.h
index 3eb9dc2ce339..fe6f7d5bfe88 100644
--- a/drivers/net/ipa/ipa_data.h
+++ b/drivers/net/ipa/ipa_data.h
@@ -253,6 +253,7 @@ extern const struct ipa_data ipa_data_v4_7;
 extern const struct ipa_data ipa_data_v4_9;
 extern const struct ipa_data ipa_data_v4_11;
 extern const struct ipa_data ipa_data_v5_0;
+extern const struct ipa_data ipa_data_v5_1;
 extern const struct ipa_data ipa_data_v5_2;
 extern const struct ipa_data ipa_data_v5_5;
 
diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
index 788dd99af2a4..6c449032ae45 100644
--- a/drivers/net/ipa/ipa_main.c
+++ b/drivers/net/ipa/ipa_main.c
@@ -669,6 +669,10 @@ static const struct of_device_id ipa_match[] = {
 		.compatible	= "qcom,sdx65-ipa",
 		.data		= &ipa_data_v5_0,
 	},
+	{
+		.compatible	= "qcom,sm8450-ipa",
+		.data		= &ipa_data_v5_1,
+	},
 	{
 		.compatible	= "qcom,milos-ipa",
 		.data		= &ipa_data_v5_2,
diff --git a/drivers/net/ipa/ipa_reg.c b/drivers/net/ipa/ipa_reg.c
index 30bd69f4c147..5f22ca6295b1 100644
--- a/drivers/net/ipa/ipa_reg.c
+++ b/drivers/net/ipa/ipa_reg.c
@@ -125,6 +125,7 @@ static const struct regs *ipa_regs(enum ipa_version version)
 	case IPA_VERSION_4_11:
 		return &ipa_regs_v4_11;
 	case IPA_VERSION_5_0:
+	case IPA_VERSION_5_1:
 	case IPA_VERSION_5_2:
 		return &ipa_regs_v5_0;
 	case IPA_VERSION_5_5:

-- 
2.54.0

Re: [PATCH 3/3] net: ipa: Add IPA v5.1 data

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Driver probe failure on SM8450 due to intentional SMEM size mismatch.
- [High] Overlapping IPA local memory regions will cause silent data corruption between filter tables and routing statistics.
- [Medium] The AP_MODEM_RX endpoint is incorrectly assigned to the DST_UL resource group, causing resource starvation and unused DST_DL resources.
--

commit 6da897f459f64d1618e077cb44111c9397ad478b
Author: Esteban Urrutia <esteuwu@proton.me>

net: ipa: Add IPA v5.1 data

Add the required ipa_data-v5.1.c file for IPA v5.1 along with changes
that declare IPA v5.1 support. This version of IPA is used in both SM8450
and SM8475 SoCs.

> diff --git a/drivers/net/ipa/data/ipa_data-v5.1.c b/drivers/net/ipa/data/ipa_data-v5.1.c
> new file mode 100644
> index 0000000000000..85b21efa1224d
> --- /dev/null
> +++ b/drivers/net/ipa/data/ipa_data-v5.1.c
[ ... ]
> +	[IPA_ENDPOINT_AP_MODEM_RX] = {
> +		.ee_id		= GSI_EE_AP,
> +		.channel_id	= 1,
> +		.endpoint_id	= 23,
> +		.toward_ipa	= false,
> +		.channel = {
> +			.tre_count	= 256,
> +			.event_count	= 256,
> +			.tlv_count	= 9,
> +		},
> +		.endpoint = {
> +			.config = {
> +				.resource_group	= IPA_RSRC_GROUP_DST_UL,

[Severity: Medium]
Will assigning this downlink endpoint to the UL resource group cause
resource starvation?

Since this is the AP_MODEM_RX endpoint, should it be assigned to
IPA_RSRC_GROUP_DST_DL instead?

Later in the ipa_resource_dst[] configuration, 5 data sectors are allocated
to IPA_RSRC_GROUP_DST_DL. If no endpoints are assigned to the DL group,
those sectors will remain unused while AP_MODEM_RX competes with AP_LAN_RX
for the limited DST_UL resources.

[ ... ]
> +/* IPA-resident memory region data for an SoC having IPA v5.1 */
> +static const struct ipa_mem ipa_mem_local_data[] = {
[ ... ]
> +	{
> +		.id		= IPA_MEM_STATS_TETHERING,
> +		.offset		= 0x2910,
> +		.size		= 0x03c0,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_AP_V4_FILTER,
> +		.offset		= 0x29b8,
> +		.size		= 0x0188,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_AP_V6_FILTER,
> +		.offset		= 0x2b40,
> +		.size		= 0x0228,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_STATS_FILTER_ROUTE,
> +		.offset		= 0x2cd0,
> +		.size		= 0x0ba0,
> +		.canary_count	= 2,
> +	},

[Severity: High]
Do these memory region offsets overlap and lead to data corruption?

IPA_MEM_STATS_TETHERING starts at 0x2910 and has a size of 0x03c0, which
means it extends up to 0x2cd0.

However, IPA_MEM_AP_V4_FILTER begins at 0x29b8, placing it entirely inside
the tethering region. Similarly, IPA_MEM_AP_V6_FILTER starts at 0x2b40,
which overlaps both the end of the tethering region and the start of
IPA_MEM_STATS_FILTER_ROUTE.

Could hardware updates to the routing and filter stats corrupt the AP
filter tables here?

[ ... ]
> +/* Memory configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_mem_data ipa_mem_data = {
> +	.local_count	= ARRAY_SIZE(ipa_mem_local_data),
> +	.local		= ipa_mem_local_data,
> +	.imem_addr	= 0x146a8000,
> +	.imem_size	= 0x00002000,
> +	/*
> +	 * While this value is 0xb000 on SM8450 and 0x9000 on SM8475,
> +	 * it has been left set to 0x9000 for compatibility with SM8475
> +	 */
> +	.smem_size	= 0x00009000,

[Severity: High]
Will this hardcoded SMEM size cause the driver probe to fail on SM8450?

When the SM8450 bootloader or modem pre-allocates 0xb000 bytes,
qcom_smem_get() will return that actual size.

Looking at ipa_smem_init() in drivers/net/ipa/ipa_mem.c:

	if (ret && actual != size) {
		dev_err(dev, "SMEM item has size %zu, expected %zu\n",
			actual, size);
		return -EINVAL;
	}

Because this strictly validates the returned size against
ipa->mem_data->smem_size, setting this to 0x9000 for SM8475 compatibility
would cause the size check to fail and abort the driver probe.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-sm8450-ipa-v1-0-532f0299f96e@proton.me?part=3

Re: [PATCH 3/3] net: ipa: Add IPA v5.1 data

[Alex Elder]

On 6/22/26 8:44 PM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
> 
> Add the required ipa_data-v5.1.c file for IPA v5.1 along with changes
> that declare IPA v5.1 support.
> This version of IPA is used in both SM8450 and SM8475 SoCs.
> 
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>

OK I'm finally reviewing this.  Thank you again for sharing links to
the resources you used and developed while doing this work.


For the most part this looks entirely correct.  There is one
pair of memory table entries that I think should not be there,
otherwise everything looks just about perfect.

I'm not totally sure that reducing the SMEM size will work
correctly.


I'm taking this opportunity to explain a LOT of things about
IPA and the driver code.  It's much more than what's typical
for a review, but I thought this provided a good chance to
explain some things in context.  You can add it to your notes
file if you like...

> ---
>   drivers/net/ipa/Makefile             |   2 +-
>   drivers/net/ipa/data/ipa_data-v5.1.c | 477 +++++++++++++++++++++++++++++++++++
>   drivers/net/ipa/gsi_reg.c            |   1 +
>   drivers/net/ipa/ipa_data.h           |   1 +
>   drivers/net/ipa/ipa_main.c           |   4 +
>   drivers/net/ipa/ipa_reg.c            |   1 +
>   6 files changed, 485 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ipa/Makefile b/drivers/net/ipa/Makefile
> index e148ec3c1a10..d4995c2e8ca0 100644
> --- a/drivers/net/ipa/Makefile
> +++ b/drivers/net/ipa/Makefile
> @@ -7,7 +7,7 @@ IPA_REG_VERSIONS	:=	3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.5
>   # Some IPA versions can reuse another set of GSI register definitions.
>   GSI_REG_VERSIONS	:=	3.1 3.5.1 4.0 4.5 4.9 4.11 5.0
>   
> -IPA_DATA_VERSIONS	:=	3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.2 5.5
> +IPA_DATA_VERSIONS	:=	3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.1 5.2 5.5
>   
>   obj-$(CONFIG_QCOM_IPA)	+=	ipa.o
>   
> diff --git a/drivers/net/ipa/data/ipa_data-v5.1.c b/drivers/net/ipa/data/ipa_data-v5.1.c
> new file mode 100644
> index 000000000000..85b21efa1224
> --- /dev/null
> +++ b/drivers/net/ipa/data/ipa_data-v5.1.c
> @@ -0,0 +1,477 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/* Copyright (C) 2023-2024 Linaro Ltd. */
> +/* Copyright (C) 2026 Esteban Urrutia <esteuwu@proton.me> */
> +
> +#include <linux/array_size.h>
> +#include <linux/log2.h>
> +
> +#include "../ipa_data.h"
> +#include "../ipa_endpoint.h"
> +#include "../ipa_mem.h"
> +#include "../ipa_version.h"
> +
> +/** enum ipa_resource_type - IPA resource types for an SoC having IPA v5.1 */
> +enum ipa_resource_type {
> +	/* Source resource types; first must have value 0 */
> +	IPA_RESOURCE_TYPE_SRC_PKT_CONTEXTS		= 0,
> +	IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_LISTS,
> +	IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_BUFF,
> +	IPA_RESOURCE_TYPE_SRC_HPS_DMARS,
> +	IPA_RESOURCE_TYPE_SRC_ACK_ENTRIES,
> +
> +	/* Destination resource types; first must have value 0 */
> +	IPA_RESOURCE_TYPE_DST_DATA_SECTORS		= 0,
> +	IPA_RESOURCE_TYPE_DST_DPS_DMARS,
> +	IPA_RESOURCE_TYPE_DST_ULSO_SEGMENTS,
> +};

The above looks correct to me.  They come from downstream
"ipa_utils.c", in the ipa3_rsrc_src_grp_config[IPA_5_1][][]
array and the ipa3_rsrc_dst_grp_config[IPA_5_1][][] array.

The *_SRC_* symbols are the index values used in the
ipa_resource_src[] array upstream, and the *_DST_* symbols
are indexes in the upstream ipa_resource_dst[] array.

> +/* Resource groups used for an SoC having IPA v5.1 */
> +enum ipa_rsrc_group_id {
> +	/* Source resource group identifiers */
> +	IPA_RSRC_GROUP_SRC_UL				= 0,
> +	IPA_RSRC_GROUP_SRC_DL,
> +	IPA_RSRC_GROUP_SRC_UNUSED_2,
> +	IPA_RSRC_GROUP_SRC_UNUSED_3,
> +	IPA_RSRC_GROUP_SRC_URLLC,
> +	IPA_RSRC_GROUP_SRC_U_RX_QC,
> +	IPA_RSRC_GROUP_SRC_COUNT,	/* Last in set; not a source group */
> +
> +	/* Destination resource group identifiers */
> +	IPA_RSRC_GROUP_DST_UL				= 0,
> +	IPA_RSRC_GROUP_DST_DL,
> +	IPA_RSRC_GROUP_DST_UNUSED_2,
> +	IPA_RSRC_GROUP_DST_UNUSED_3,
> +	IPA_RSRC_GROUP_DST_UNUSED_4,
> +	IPA_RSRC_GROUP_DST_UC,
> +	IPA_RSRC_GROUP_DST_DRB_IP,
> +	IPA_RSRC_GROUP_DST_COUNT,	/* Last; not a destination group */
> +};

These look correct.  They correspond to the second index values
in the downstream arrays mentioned earlier, and are used as
indexes into the limits[] array within an ipa_resource structure.

As you probably now know, the symbols correspond to these comments
in the downstream code:
                 /* UL  DL  unused  unused  URLLC UC_RX_Q N/A */
                 /* UL  DL  unused  unused unused  UC_RX_Q DRBIP N/A */
> +/* QSB configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_qsb_data ipa_qsb_data[] = {
> +	[IPA_QSB_MASTER_DDR] = {
> +		.max_writes		= 0,
> +		.max_reads		= 0,	/* no limit (hardware max) */
> +		.max_reads_beats	= 0,
> +	},
> +	[IPA_QSB_MASTER_PCIE] = {
> +		.max_writes		= 0,
> +		.max_reads		= 0,	/* no limit (hardware max) */
> +		.max_reads_beats	= 0,
> +	},
> +};

I think the DDR values might be wrong, but it's difficult to be
sure.  In some cases, in arrays like this in the downstream code,
if there is no entry found in an array, the *earlier* version
values should be used.  (Unless someone better informed states
that this is wrong, I think it's fine as-is.)

This information is found in the ipa3_qmb_outstanding[IPA_5_1][]
array in the downstream code.  However there is no entry for that
version.  Given that, all zeroes (as you have it) makes sense.
But it's possible this applies instead:

         [IPA_5_0][IPA_QMB_INSTANCE_DDR]         = {12, 12, 0},
         [IPA_5_0][IPA_QMB_INSTANCE_PCIE]        = {0, 0, 0},

I have no way of knowing; perhaps someone from Qualcomm can
get confirmation that all zeroes is correct.

(Note the order of values presented in the downstream code
differs from upstream.)



Most of the information in the structure below comes from the
ipa3_ep_mapping[IPA_V5_1][] array in the downstream code.
Many of the entries in that array are unused in the upstream
code, because we only use a small subset of the available
endpoints.

> +/* Endpoint configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_gsi_endpoint_data ipa_gsi_endpoint_data[] = {
> +	[IPA_ENDPOINT_AP_COMMAND_TX] = {

IPA_ENDPOINT_AP_COMMAND_TX corresponds to IPA_CLIENT_APPS_CMD_PROD
in the downstream code.  The downstream code doesn't label the
assignments within the ipa3_ep_mapping[][] array, so I think it's
a little harder to understand.  Anyway I'll show how they map
between downstream and upstream below.

The downstream structure is named ipa_ep_configuration.  The
upstream structure is named ipa_gsi_endpoint_data.

struct ipa_ep_configuration {
         bool valid;
         int group_num;
         bool support_flt;
         int sequencer_type;
         u8 qmb_master_sel;
         struct ipa_gsi_ep_config ipa_gsi_ep_info;
         u8 tx_instance;
};

And although ipa_gsi_ep_config is not defined in this code
base, here is what it looks like:

struct ipa_gsi_ep_config {
         int ipa_ep_num;
         int ipa_gsi_chan_num;
         int ipa_if_tlv;
         int ipa_if_aos;
         int ee;
         enum gsi_prefetch_mode prefetch_mode;
         uint8_t prefetch_threshold;
};

This might not be current; I'm using code found here:
   https://git.codelinaro.org/clo/la/kernel/msm-5.15.git


Here is the upstream structure, and I indicate where the
information comes from in the downstream code:

struct ipa_gsi_endpoint_data {
         u8 ee_id;	/* ipa_ep_configuration->ee */
         u8 channel_id;  /* ipa_ep_configuration->ipa_gsi_chan_num */
         u8 endpoint_id;	/* ipa_ep_configuration->ipa_ep_num */
         bool toward_ipa;

         struct gsi_channel_data channel;
         struct ipa_endpoint_data endpoint;
};

And here is the first sub-structure:

struct gsi_channel_data {
         u16 tre_count;	/* Computed based on other code (see below) */
         u16 event_count;
         u8 tlv_count;	/* ipa_ep_configuration->ipa_if_tlv */
};

> +		.ee_id		= GSI_EE_AP,

This is the "execution environment" that the endpoint is
associated with.  For upstream, that's either the AP or
the modem.  The "_AP_" sitting where it does in the
IPA_ENDPOINT_AP_COMMAND_TX endpoint ID also indicates
this is an AP endpoint.  It also matches what's seen
in the downstream ipa_gsi_ep_config->ee field.

> +		.channel_id	= 12,
> +		.endpoint_id	= 14,
> +		.toward_ipa	= true,
> +		.channel = {
> +			.tre_count	= 256,
> +			.event_count	= 256,
> +			.tlv_count	= 20,

The tre_count number was derived from code in ipa3_setup_apps_pipes()
in downstream "ipa/ipa_v3/ipa.c".  There a ipa_sys_connect_params
structure contains a field desc_fifo_size, which is the size in bytes
of the transfer ring buffer.  The tre_count in upsteram code is in
units of a TRE (transfer ring element), i.e. it's the number of such
entries (that fit in that number of bytes).

The downstream IPA_CLIENT_APPS_CMD_PROD corresponds to upstream
IPA_ENDPOINT_AP_COMMAND_TX (the array entry we're in the middle
of here), and the downstream size is IPA_SYS_DESC_FIFO_SZ, or
0x800=2048 bytes.  Each TRE (struct gsi_tre) is 16 bytes.

In the downstream code--confusingly--ipa_gsi_setup_channel()
doubles the desc_fifo_sz value (for GSI, versus the older BAM
interface).  So the ring size becomes 4096 bytes, and that
works out to 256 16-byte GSI TRE entries.  I'm not sure why
512 is used for IPA v3.5.1, but it probably just means it's
bigger than it needs to be.

The event_count should be the same as the tre_count.  Again
I no longer know why that's not the case for IPA v3.5.1.


> +		},

Below is the second sub-structure in the upstream structure
ipa_gsi_endpoint_data, and the other structures it
incorporates.

struct ipa_endpoint_data {
         bool filter_support;
         struct ipa_endpoint_config config;
};

struct ipa_endpoint_config {
         u32 resource_group;
         bool checksum;
         bool qmap;
         bool aggregation;
         bool status_enable;
         bool dma_mode;
         enum ipa_endpoint_name dma_endpoint;
         union {
                 struct ipa_endpoint_tx tx;
                 struct ipa_endpoint_rx rx;
         };
};

struct ipa_endpoint_tx {
         enum ipa_seq_type seq_type;
         enum ipa_seq_rep_type seq_rep_type;
         enum ipa_endpoint_name status_endpoint;
};

struct ipa_endpoint_rx {
         u32 buffer_size;
         u32 pad_align;
         u32 aggr_time_limit;
         bool aggr_hard_limit;
         bool aggr_close_eof;
         bool holb_drop;
};

> +		.endpoint = {
> +			.config = {
> +				.resource_group	= IPA_RSRC_GROUP_SRC_UL,

This resource group corresponds to IPA_v5_0_GROUP_UL in
the downstream code.

> +				.dma_mode	= true,

The dma_mode is always true for the AP->IPA command TX
endpoint, false for others.

> +				.dma_endpoint	= IPA_ENDPOINT_AP_LAN_RX,

This is always the DMA endpoint id for the command
endpoint. I think it's where the status messages
related to transmitted commands get sent.  The AP<-LAN
(RX) endpoint is the "default" endpoint.

> +				.tx = {
> +					.seq_type = IPA_SEQ_DMA,

This is the sequencer type, always DMA for the command
endpoint.  The sequencer types are set based on what the
downstream code does.

> +				},
> +			},
> +		},
> +	},
> +	[IPA_ENDPOINT_AP_LAN_RX] = {

This is the default RX endpoint on the AP.  If a LAN
interface were supported it would also be the RX
endpoint for the LAN.  This corresponds to
IPA_CLIENT_APPS_LAN_CONS

> +		.ee_id		= GSI_EE_AP,
> +		.channel_id	= 13,
> +		.endpoint_id	= 16,
> +		.toward_ipa	= false,
> +		.channel = {
> +			.tre_count	= 256,
> +			.event_count	= 256,
> +			.tlv_count	= 9,
> +		},
> +		.endpoint = {
> +			.config = {
> +				.resource_group	= IPA_RSRC_GROUP_DST_UL,
> +				.aggregation	= true,

Aggregation enabled means multiple received messages will
be placed by the IPA hardware into a single receive buffer
before forwarding the buffer to the host for processing.

> +				.status_enable	= true,

This setting means every transfer causes a status header to be
generated for each received message.  ipa_endpoint_status_parse()
splits them apart using information in the status header and
hands each de-aggregated message to the network stack.

> +				.rx = {
> +					.buffer_size	= 8192,

Each receive buffer is this big (in bytes).

> +					.pad_align	= ilog2(sizeof(u32)),

Before a received message is placed in the receive buffer,
IPA updates current buffer pointer to be aligned to this
boundary (in this case, 2^2 bytes).

> +					.aggr_time_limit = 500,

If aggregation hasn't exhausted the receive buffer in this many
microseconds, it forwards the buffer to the host anyway.

The time limit comes from IPA_GENERIC_AGGR_TIME_LIMIT in the
downstream code.

> +				},
> +			},
> +		},
> +	},
> +	[IPA_ENDPOINT_AP_MODEM_TX] = {

The AP_MODEM_TX here says that this is an AP endpoint,
whose destination is the modem (WAN in the downstream
code), and it is a TX endpoint (from the AP to the modem).
This corresponds to IPA_CLIENT_APPS_WAN_PROD.

> +		.ee_id		= GSI_EE_AP,
> +		.channel_id	= 11,
> +		.endpoint_id	= 2,
> +		.toward_ipa	= true,
> +		.channel = {
> +			.tre_count	= 512,
> +			.event_count	= 512,
> +			.tlv_count	= 25,
> +		},
> +		.endpoint = {
> +			.filter_support	= true,
> +			.config = {
> +				.resource_group	= IPA_RSRC_GROUP_SRC_UL,
> +				.checksum       = true,

The checksum true flag means IPA performs checksumming
on messages being sent (so the host doesn't have to).

> +				.qmap		= true,

The qmap true flag says that this channel uses QMAP
protocol (ETH_P_MAP).  A single message contains one
or more QMAP messages, which multiplexes multiple
logical channels over a single connection.

> +				.status_enable	= true,
> +				.tx = {
> +					.seq_type = IPA_SEQ_2_PASS_SKIP_LAST_UC,
> +					.status_endpoint =
> +						IPA_ENDPOINT_MODEM_AP_RX,

This says that status messages generated as a result
of messages received on this channel (i.e., using
this endpoint) are delivered to the *modem* endpoint
that recieves data from the AP.

> +				},
> +			},
> +		},
> +	},
> +	[IPA_ENDPOINT_AP_MODEM_RX] = {

AP endpoint, *from* the modem.  This corresponds to
IPA_CLIENT_APPS_WAN_CONS.

> +		.ee_id		= GSI_EE_AP,
> +		.channel_id	= 1,
> +		.endpoint_id	= 23,
> +		.toward_ipa	= false,
> +		.channel = {
> +			.tre_count	= 256,
> +			.event_count	= 256,
> +			.tlv_count	= 9,
> +		},
> +		.endpoint = {
> +			.config = {
> +				.resource_group	= IPA_RSRC_GROUP_DST_UL,
> +				.checksum       = true,
> +				.qmap		= true,
> +				.aggregation	= true,
> +				.rx = {
> +					.buffer_size	= 8192,
> +					.aggr_time_limit = 500,
> +					.aggr_close_eof	= true,

The aggr_close_eof flag determines which of two ways
aggregation in a receive buffer "closes".  (Closing
means th receive buffer is delivered to the host for
processing, and a new receive buffer begins to be
used.)

One policy closes aggregation when there is not enough
space left to hold an entire incoming message in the
buffer.  The other policy closes aggregation when the
data from a received message crosses a certain mark
(byte count) in the receive buffer.  (I no longer
recall which is which.)

> +				},
> +			},
> +		},
> +	},
> +	[IPA_ENDPOINT_MODEM_AP_TX] = {

Modem endpoint, transmitting (from the modem) *to* the AP.
Downstream calls the modem "Q6".  Configuring these endpoints
is the modem's responsibility, but the AP IPA driver needs
to be aware of these, so they're included in this data.
(I don't remember why; maybe it's to ensure endpoints and
channels are accounted for, and/or not reused?)

This endpoint id corresponds to IPA_CLIENT_Q6_WAN_CONS.

> +		.ee_id		= GSI_EE_MODEM,
> +		.channel_id	= 0,
> +		.endpoint_id	= 12,
> +		.toward_ipa	= true,
> +		.endpoint = {
> +			.filter_support	= true,
> +		},
> +	},
> +	[IPA_ENDPOINT_MODEM_AP_RX] = {

This corresponds to IPA_CLIENT_Q6_WAN_CONS.

> +		.ee_id		= GSI_EE_MODEM,
> +		.channel_id	= 7,
> +		.endpoint_id	= 21,
> +		.toward_ipa	= false,
> +	},
> +	[IPA_ENDPOINT_MODEM_DL_NLO_TX] = {

This has to do with a feature we don't use, but we still
need to configure it (I think so we take into account that
it implements filtering).  This endpoint corresponds to
IPA_CLIENT_Q6_DL_NLO_DATA_PROD.

> +		.ee_id		= GSI_EE_MODEM,
> +		.channel_id	= 2,
> +		.endpoint_id	= 15,
> +		.toward_ipa	= true,
> +		.endpoint = {
> +			.filter_support	= true,
> +		},
> +	},
> +};
"Resources" are data structures managed by the IPA/GSI
firmware.  We must configure these at initialization
time, and once configured, that firmware operates
using these resources.  I don't know much more than
that, and basically we just configure things the way
the downstream code does.

> +
> +/* Source resource configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_resource ipa_resource_src[] = {

Again, this array is filled with information that comes from the
ipa3_rsrc_src_grp_config[IPA_5_1][][] array in the downstream
code, in "ipa_utils.c".  Everything you have here looks correct.

> +	[IPA_RESOURCE_TYPE_SRC_PKT_CONTEXTS] = {
> +		.limits[IPA_RSRC_GROUP_SRC_UL] = {
> +			.min = 7,	.max = 12,
> +		},
> +		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
> +			.min = 1,	.max = 63,
> +		},
> +		.limits[IPA_RSRC_GROUP_SRC_U_RX_QC] = {
> +			.min = 0,	.max = 63,
> +		},
> +	},
> +	[IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_LISTS] = {
> +		.limits[IPA_RSRC_GROUP_SRC_UL] = {
> +			.min = 21,	.max = 21,
> +		},
> +		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
> +			.min = 10,	.max = 10,
> +		},
> +	},
> +	[IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_BUFF] = {
> +		.limits[IPA_RSRC_GROUP_SRC_UL] = {
> +			.min = 33,	.max = 33,
> +		},
> +		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
> +			.min = 20,	.max = 20,
> +		},
> +	},
> +	[IPA_RESOURCE_TYPE_SRC_HPS_DMARS] = {
> +		.limits[IPA_RSRC_GROUP_SRC_UL] = {
> +			.min = 0,	.max = 63,
> +		},
> +		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
> +			.min = 1,	.max = 63,
> +		},
> +		.limits[IPA_RSRC_GROUP_SRC_U_RX_QC] = {
> +			.min = 0,	.max = 63,
> +		},
> +	},
> +	[IPA_RESOURCE_TYPE_SRC_ACK_ENTRIES] = {
> +		.limits[IPA_RSRC_GROUP_SRC_UL] = {
> +			.min = 38,	.max = 38,
> +		},
> +		.limits[IPA_RSRC_GROUP_SRC_URLLC] = {
> +			.min = 16,	.max = 16,
> +		},
> +	},
> +};
> +
> +/* Destination resource configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_resource ipa_resource_dst[] = {

And the content of this array comes from ipa3_rsrc_dst_grp_config[][].
Everything you have here looks correct as well.

> +	[IPA_RESOURCE_TYPE_DST_DATA_SECTORS] = {
> +		.limits[IPA_RSRC_GROUP_DST_UL] = {
> +			.min = 6,	.max = 6,
> +		},
> +		.limits[IPA_RSRC_GROUP_DST_DL] = {
> +			.min = 5,	.max = 5,
> +		},
> +		.limits[IPA_RSRC_GROUP_DST_DRB_IP] = {
> +			.min = 39,	.max = 39,
> +		},
> +	},
> +	[IPA_RESOURCE_TYPE_DST_DPS_DMARS] = {
> +		.limits[IPA_RSRC_GROUP_DST_UL] = {
> +			.min = 0,	.max = 3,
> +		},
> +		.limits[IPA_RSRC_GROUP_DST_DL] = {
> +			.min = 0,	.max = 3,
> +		},
> +	},
> +	[IPA_RESOURCE_TYPE_DST_ULSO_SEGMENTS] = {
> +		.limits[IPA_RSRC_GROUP_DST_UL] = {
> +			.min = 0,	.max = 63,
> +		},
> +		.limits[IPA_RSRC_GROUP_DST_DL] = {
> +			.min = 0,	.max = 63,
> +		},
> +	},
> +};
> +
> +/* Resource configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_resource_data ipa_resource_data = {
> +	.rsrc_group_dst_count	= IPA_RSRC_GROUP_DST_COUNT,
> +	.rsrc_group_src_count	= IPA_RSRC_GROUP_SRC_COUNT,
> +	.resource_src_count	= ARRAY_SIZE(ipa_resource_src),
> +	.resource_src		= ipa_resource_src,
> +	.resource_dst_count	= ARRAY_SIZE(ipa_resource_dst),
> +	.resource_dst		= ipa_resource_dst,
> +};
> +
> +/* IPA-resident memory region data for an SoC having IPA v5.1 */

Memory regions are sort of similar to resources, in that
there are ranges of available (IPA-local) memory that are
used by IPA for various purposes.  We need to configure
these, and this configuration (base and size of various
memory regions) is shared with the modem via a QMI message
exchange during initialization.

> +static const struct ipa_mem ipa_mem_local_data[] = {

IPA has local memory that is partitioned as defined by this
array.  The regions are used by IPA/GSI firmware and/or
hardware.  The configuration defined here is sent to
the modem in an ipa_init_modem_driver_req QMI message
so both the modem and AP have a consistent view of
how the memory is used.

Many memory regions are preceded by 0-2 "canaries", which
are 32-byte values initialized to IPA_MEM_CANARY_VAL.

In the downstream code there is structure ipa3_mem_partition
that defines these things, and structures of this type are
defined in "ipa_utils.c".  For IPA v5.1, ipa_5_1_mem_part
defines them all.  The mapping between downstream and
upstream is not trivial and direct, but it should be
obvious how they get translated.


With two exceptions, what I see here looks like you
correctly transferred everything.  (The two exceptions
are entries that from what I can tell, should not be
present.)

> +	{
> +		.id		= IPA_MEM_UC_EVENT_RING,
> +		.offset		= 0x0000,
> +		.size		= 0x1000,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_UC_SHARED,
> +		.offset		= 0x1000,
> +		.size		= 0x0080,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_UC_INFO,
> +		.offset		= 0x1080,
> +		.size		= 0x0200,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_V4_FILTER_HASHED,
> +		.offset		= 0x1288,
> +		.size		= 0x0078,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_V4_FILTER,
> +		.offset		= 0x1308,
> +		.size		= 0x0078,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_V6_FILTER_HASHED,
> +		.offset		= 0x1388,
> +		.size		= 0x0078,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_V6_FILTER,
> +		.offset		= 0x1408,
> +		.size		= 0x0078,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_V4_ROUTE_HASHED,
> +		.offset		= 0x1488,
> +		.size		= 0x0098,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_V4_ROUTE,
> +		.offset		= 0x1528,
> +		.size		= 0x0098,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_V6_ROUTE_HASHED,
> +		.offset		= 0x15c8,
> +		.size		= 0x0098,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_V6_ROUTE,
> +		.offset		= 0x1668,
> +		.size		= 0x0098,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_MODEM_HEADER,
> +		.offset		= 0x1708,
> +		.size		= 0x0240,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_AP_HEADER,
> +		.offset		= 0x1948,
> +		.size		= 0x01e0,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_MODEM_PROC_CTX,
> +		.offset		= 0x1b40,
> +		.size		= 0x0b20,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_AP_PROC_CTX,
> +		.offset		= 0x2660,
> +		.size		= 0x0200,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_STATS_QUOTA_MODEM,
> +		.offset		= 0x2868,
> +		.size		= 0x0060,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_STATS_QUOTA_AP,
> +		.offset		= 0x28c8,
> +		.size		= 0x0048,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_STATS_TETHERING,
> +		.offset		= 0x2910,
> +		.size		= 0x03c0,
> +		.canary_count	= 0,
> +	},

The next two entries look wrong to me.  Can you explain where
you got these offsets and sizes?  Is it from "ipa_data-v5.0.c"?

Here are the relevant entries I see in ipa_5_1_mem_part
in the downstream code:
         .stats_flt_v4_ofst = 0,
         .stats_flt_v4_size = 0,
         .stats_flt_v6_ofst = 0,
         .stats_flt_v6_size = 0,
         .stats_rt_v4_ofst = 0,
         .stats_rt_v4_size = 0,
         .stats_rt_v6_ofst = 0,
         .stats_rt_v6_size = 0,
(Since their size is zero, their entries can be omitted.)

> +	{
> +		.id		= IPA_MEM_AP_V4_FILTER,
> +		.offset		= 0x29b8,
> +		.size		= 0x0188,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_AP_V6_FILTER,
> +		.offset		= 0x2b40,
> +		.size		= 0x0228,
> +		.canary_count	= 0,
> +	},

The remaining entries (below) look good.

> +	{
> +		.id		= IPA_MEM_STATS_FILTER_ROUTE,
> +		.offset		= 0x2cd0,
> +		.size		= 0x0ba0,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_STATS_DROP,
> +		.offset		= 0x3870,
> +		.size		= 0x0020,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_MODEM,
> +		.offset		= 0x3898,
> +		.size		= 0x0d48,
> +		.canary_count	= 2,
> +	},
> +	{
> +		.id		= IPA_MEM_NAT_TABLE,
> +		.offset		= 0x45e0,
> +		.size		= 0x0900,
> +		.canary_count	= 0,
> +	},
> +	{
> +		.id		= IPA_MEM_PDN_CONFIG,
> +		.offset		= 0x4ee8,
> +		.size		= 0x0100,
> +		.canary_count	= 2,
> +	},
> +};
> +
> +/* Memory configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_mem_data ipa_mem_data = {
> +	.local_count	= ARRAY_SIZE(ipa_mem_local_data),
> +	.local		= ipa_mem_local_data,
> +	.imem_addr	= 0x146a8000,

I think I needed to look up the imem offset value
in Qualcomm documentation I no longer have access
to.  Perhaps someone from there could confirm you
are using the right values here.

> +	.imem_size	= 0x00002000,
> +	/*
> +	 * While this value is 0xb000 on SM8450 and 0x9000 on SM8475,
> +	 * it has been left set to 0x9000 for compatibility with SM8475
> +	 */

As I said earlier, I'm not completely sure this will still
work on the SM8450.  Someone should confirm this, and it
really ought to be tested somehow.

> +	.smem_size	= 0x00009000,
> +};
> +
> +/* Interconnect rates are in 1000 byte/second units */
> +static const struct ipa_interconnect_data ipa_interconnect_data[] = {
> +	{
> +		.name			= "memory",
> +		.peak_bandwidth		= 1900000,	/* 1.9 GBps */
> +		.average_bandwidth	= 590000,	/* 590 MBps */

I no longer recall where to get these bandwidth values
for the interconnects.  Perhaps someone from Qualcomm
can find this out/confirm what you have.

Really nice work figuring out all this stuff...

					-Alex

> +	},
> +	/* Average rate is unused for the next interconnect */
> +	{
> +		.name			= "config",
> +		.peak_bandwidth		= 76800,	/* 76.8 MBps */
> +		.average_bandwidth	= 0,		/* unused */
> +	},
> +};
> +
> +/* Clock and interconnect configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_power_data ipa_power_data = {
> +	.core_clock_rate	= 120 * 1000 * 1000,	/* Hz */
> +	.interconnect_count	= ARRAY_SIZE(ipa_interconnect_data),
> +	.interconnect_data	= ipa_interconnect_data,
> +};
> +
> +/* Configuration data for an SoC having IPA v5.1. */
> +const struct ipa_data ipa_data_v5_1 = {
> +	.version		= IPA_VERSION_5_1,
> +	.qsb_count		= ARRAY_SIZE(ipa_qsb_data),
> +	.qsb_data		= ipa_qsb_data,
> +	.modem_route_count	= 11,
> +	.endpoint_count		= ARRAY_SIZE(ipa_gsi_endpoint_data),
> +	.endpoint_data		= ipa_gsi_endpoint_data,
> +	.resource_data		= &ipa_resource_data,
> +	.mem_data		= &ipa_mem_data,
> +	.power_data		= &ipa_power_data,
> +};
> diff --git a/drivers/net/ipa/gsi_reg.c b/drivers/net/ipa/gsi_reg.c
> index e13cf835a013..a57072ba4bef 100644
> --- a/drivers/net/ipa/gsi_reg.c
> +++ b/drivers/net/ipa/gsi_reg.c
> @@ -110,6 +110,7 @@ static const struct regs *gsi_regs(struct gsi *gsi)
>   		return &gsi_regs_v4_11;
>   
>   	case IPA_VERSION_5_0:
> +	case IPA_VERSION_5_1:
>   	case IPA_VERSION_5_2:
>   	case IPA_VERSION_5_5:
>   		return &gsi_regs_v5_0;
> diff --git a/drivers/net/ipa/ipa_data.h b/drivers/net/ipa/ipa_data.h
> index 3eb9dc2ce339..fe6f7d5bfe88 100644
> --- a/drivers/net/ipa/ipa_data.h
> +++ b/drivers/net/ipa/ipa_data.h
> @@ -253,6 +253,7 @@ extern const struct ipa_data ipa_data_v4_7;
>   extern const struct ipa_data ipa_data_v4_9;
>   extern const struct ipa_data ipa_data_v4_11;
>   extern const struct ipa_data ipa_data_v5_0;
> +extern const struct ipa_data ipa_data_v5_1;
>   extern const struct ipa_data ipa_data_v5_2;
>   extern const struct ipa_data ipa_data_v5_5;
>   
> diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
> index 788dd99af2a4..6c449032ae45 100644
> --- a/drivers/net/ipa/ipa_main.c
> +++ b/drivers/net/ipa/ipa_main.c
> @@ -669,6 +669,10 @@ static const struct of_device_id ipa_match[] = {
>   		.compatible	= "qcom,sdx65-ipa",
>   		.data		= &ipa_data_v5_0,
>   	},
> +	{
> +		.compatible	= "qcom,sm8450-ipa",
> +		.data		= &ipa_data_v5_1,
> +	},
>   	{
>   		.compatible	= "qcom,milos-ipa",
>   		.data		= &ipa_data_v5_2,
> diff --git a/drivers/net/ipa/ipa_reg.c b/drivers/net/ipa/ipa_reg.c
> index 30bd69f4c147..5f22ca6295b1 100644
> --- a/drivers/net/ipa/ipa_reg.c
> +++ b/drivers/net/ipa/ipa_reg.c
> @@ -125,6 +125,7 @@ static const struct regs *ipa_regs(enum ipa_version version)
>   	case IPA_VERSION_4_11:
>   		return &ipa_regs_v4_11;
>   	case IPA_VERSION_5_0:
> +	case IPA_VERSION_5_1:
>   	case IPA_VERSION_5_2:
>   		return &ipa_regs_v5_0;
>   	case IPA_VERSION_5_5:
> 

Re: [PATCH 3/3] net: ipa: Add IPA v5.1 data

[Esteban Urrutia]

On 7/8/26 4:06 PM, Alex Elder wrote:
> I think the DDR values might be wrong, but it's difficult to be
> sure.  In some cases, in arrays like this in the downstream code,
> if there is no entry found in an array, the *earlier* version
> values should be used.  (Unless someone better informed states
> that this is wrong, I think it's fine as-is.)
> 
> This information is found in the ipa3_qmb_outstanding[IPA_5_1][]
> array in the downstream code.  However there is no entry for that
> version.  Given that, all zeroes (as you have it) makes sense.
> But it's possible this applies instead:
> 
>          [IPA_5_0][IPA_QMB_INSTANCE_DDR]         = {12, 12, 0},
>          [IPA_5_0][IPA_QMB_INSTANCE_PCIE]        = {0, 0, 0},
> 
> I have no way of knowing; perhaps someone from Qualcomm can
> get confirmation that all zeroes is correct.
> 
> (Note the order of values presented in the downstream code
> differs from upstream.)

In downstream ipa_utils.c there's a function called ipa3_cfg_qsb() which
is in charge of reading these values from ipa3_qmb_outstanding.
Since these values are not present for IPA v5.1, one would assume
they're not set and that, since this is the first time such behavior is
found, additional changes would need to be made to the IPA driver.
However, looking at this function, which I'll leave as a snippet below
given its shortness:

static void ipa3_cfg_qsb(void)
{
	u8 hw_type_idx;
	const struct ipa_qmb_outstanding *qmb_ot;
	struct ipahal_reg_qsb_max_reads max_reads = { 0 };
	struct ipahal_reg_qsb_max_writes max_writes = { 0 };

	hw_type_idx = ipa3_ctx->hw_type_index;

	/*
	 * Read the register values before writing to them to ensure
	 * other values are not overwritten
	 */
	ipahal_read_reg_fields(IPA_QSB_MAX_WRITES, &max_writes);
	ipahal_read_reg_fields(IPA_QSB_MAX_READS, &max_reads);

	qmb_ot = &(ipa3_qmb_outstanding[hw_type_idx][IPA_QMB_INSTANCE_DDR]);
	max_reads.qmb_0_max_reads = qmb_ot->ot_reads;
	max_writes.qmb_0_max_writes = qmb_ot->ot_writes;
	max_reads.qmb_0_max_read_beats = qmb_ot->ot_read_beats;

	qmb_ot = &(ipa3_qmb_outstanding[hw_type_idx][IPA_QMB_INSTANCE_PCIE]);
	max_reads.qmb_1_max_reads = qmb_ot->ot_reads;
	max_writes.qmb_1_max_writes = qmb_ot->ot_writes;

	ipahal_write_reg_fields(IPA_QSB_MAX_WRITES, &max_writes);
	ipahal_write_reg_fields(IPA_QSB_MAX_READS, &max_reads);
}

There are no conditions for writing ot_reads, ot_writes and
ot_read_beats, which would correspond to max_reads, max_writes and
max_reads_beats in upstream.
Since hw_type_idx is set to IPA_5_1, this should give a null pointer.
With this info, there are two possibilities:

1. Null pointer dereference, resulting in a kernel oops downstream.
2. qmb_ot is set with all values to 0.

I have never seen a null pointer dereference downstream, so I'm more
inclined to believe option 2 is what's actually happening.
IPA v5.0 also zeroes these values, but I wasn't able to actually confirm
this.
This because in downstream, IPA versions are split into subversions,
which are:

1. Normal IPA (IPA_X_Y)
2. MHI IPA (IPA_X_Y_MHI)
3. APQ IPA (IPA_X_Y_APQ)

Data for IPA v5.0 seems to be of the MHI type, since it's only used in
the SDX65 SoC, which I believe is mostly used in 5G modems.
I realized this while cross-checking since some values didn't really
match, so I had to cross-check with different ipa_data-vX.Y.c files
because of this.

> And although ipa_gsi_ep_config is not defined in this code
> base, here is what it looks like:
> 
> struct ipa_gsi_ep_config {
>          int ipa_ep_num;
>          int ipa_gsi_chan_num;
>          int ipa_if_tlv;
>          int ipa_if_aos;
>          int ee;
>          enum gsi_prefetch_mode prefetch_mode;
>          uint8_t prefetch_threshold;
> };
> 
> This might not be current; I'm using code found here:
>    https://git.codelinaro.org/clo/la/kernel/msm-5.15.git

Many thanks for providing the declaration for this struct.

> In the downstream code--confusingly--ipa_gsi_setup_channel()
> doubles the desc_fifo_sz value (for GSI, versus the older BAM
> interface).  So the ring size becomes 4096 bytes, and that
> works out to 256 16-byte GSI TRE entries.  I'm not sure why
> 512 is used for IPA v3.5.1, but it probably just means it's
> bigger than it needs to be.
> 
> The event_count should be the same as the tre_count.  Again
> I no longer know why that's not the case for IPA v3.5.1.

For the record (since this is off-topic). I tried to get the modem up in
a device whose SoC was using IPA v3.5.1 and I was experimenting weird
behavior, such as IPA crashing the SoC when removing the module or when
it automatically loaded at boot.
The reason I mention this is because a warning similar to "channel 4
limited to 256 TREs" appeared whenever IPA was loaded. That may be the
reason I was experimenting those issues.

>> +static const struct ipa_mem ipa_mem_local_data[] = {
> 
> IPA has local memory that is partitioned as defined by this
> array.  The regions are used by IPA/GSI firmware and/or
> hardware.  The configuration defined here is sent to
> the modem in an ipa_init_modem_driver_req QMI message
> so both the modem and AP have a consistent view of
> how the memory is used.
> 
> Many memory regions are preceded by 0-2 "canaries", which
> are 32-byte values initialized to IPA_MEM_CANARY_VAL.
> 
> In the downstream code there is structure ipa3_mem_partition
> that defines these things, and structures of this type are
> defined in "ipa_utils.c".  For IPA v5.1, ipa_5_1_mem_part
> defines them all.  The mapping between downstream and
> upstream is not trivial and direct, but it should be
> obvious how they get translated.
> 
> 
> With two exceptions, what I see here looks like you
> correctly transferred everything.  (The two exceptions
> are entries that from what I can tell, should not be
> present.)

[...]

> The next two entries look wrong to me.  Can you explain where
> you got these offsets and sizes?  Is it from "ipa_data-v5.0.c"?
> 
> Here are the relevant entries I see in ipa_5_1_mem_part
> in the downstream code:
>          .stats_flt_v4_ofst = 0,
>          .stats_flt_v4_size = 0,
>          .stats_flt_v6_ofst = 0,
>          .stats_flt_v6_size = 0,
>          .stats_rt_v4_ofst = 0,
>          .stats_rt_v4_size = 0,
>          .stats_rt_v6_ofst = 0,
>          .stats_rt_v6_size = 0,
> (Since their size is zero, their entries can be omitted.)
> 
>> +	{
>> +		.id		= IPA_MEM_AP_V4_FILTER,
>> +		.offset		= 0x29b8,
>> +		.size		= 0x0188,
>> +		.canary_count	= 2,
>> +	},
>> +	{
>> +		.id		= IPA_MEM_AP_V6_FILTER,
>> +		.offset		= 0x2b40,
>> +		.size		= 0x0228,
>> +		.canary_count	= 0,
>> +	},
> 
> The remaining entries (below) look good.

While cross-referencing IPA data files upstream, I found these two
regions to be present in data for IPA v5.5, even though they aren't
defined in ipa_5_5_mem_part. At the start I assumed these were correct
since they were present upstream, but I took a closer look at that file
and I believe data for this version was directly added without going
through a proper review process.

The reason why I used IPA v5.5 memory regions in IPA v5.1 is because
their memory partitions are identical.

Now, with this information, I would like to ask whether both of these
memory regions are correct for both IPA v5.1 and v5.5 data files.

>> +/* Memory configuration data for an SoC having IPA v5.1 */
>> +static const struct ipa_mem_data ipa_mem_data = {
>> +	.local_count	= ARRAY_SIZE(ipa_mem_local_data),
>> +	.local		= ipa_mem_local_data,
>> +	.imem_addr	= 0x146a8000,
> 
> I think I needed to look up the imem offset value
> in Qualcomm documentation I no longer have access
> to.  Perhaps someone from there could confirm you
> are using the right values here.

After cross-checking I believe this may be the qcom,additional-mapping
property downstream, which specifies the IMEM starting address and size.
I'll leave (2) and (3) for reference.
(2) corresponds to SM8450, while (3) corresponds to SM8475.

> 
>> +	.imem_size	= 0x00002000,
>> +	/*
>> +	 * While this value is 0xb000 on SM8450 and 0x9000 on SM8475,
>> +	 * it has been left set to 0x9000 for compatibility with SM8475
>> +	 */
> 
> As I said earlier, I'm not completely sure this will still
> work on the SM8450.  Someone should confirm this, and it
> really ought to be tested somehow.

I have clarified this in my previous email (4), so I'll skip this part.

> 
>> +	.smem_size	= 0x00009000,
>> +};
>> +
>> +/* Interconnect rates are in 1000 byte/second units */
>> +static const struct ipa_interconnect_data ipa_interconnect_data[] = {
>> +	{
>> +		.name			= "memory",
>> +		.peak_bandwidth		= 1900000,	/* 1.9 GBps */
>> +		.average_bandwidth	= 590000,	/* 590 MBps */
> 
> I no longer recall where to get these bandwidth values
> for the interconnects.  Perhaps someone from Qualcomm
> can find this out/confirm what you have.

This was a tricky part. These seem to come from the qcom,svs2 property
which seems to be mapped to the interconnects specified downstream.
Since the IPA interconnects declared in device trees are different in
both downstream and upstream I had to make some adjustments, such as
using the minimum value between both ipa_to_llcc and llcc_to_ebi1
interconnects.
An example of this can be seen in (5), which corresponds to the SM8350
SoC using IPA v4.9.

Again, thanks for taking the time to properly explain things.

(1) https://github.com/LineageOS/android_kernel_qcom_sm8450-modules/blob/lineage-20/qcom/opensource/dataipa/drivers/platform/msm/ipa/ipa_v3/ipa_utils.c#L7881
https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/waipio.dtsi#L3404
https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/cape.dtsi#L2723
(4) https://lore.kernel.org/all/3e70d77e-6bec-4e16-ae88-a4f5161f182e@proton.me/
(5) https://github.com/LineageOS/android_kernel_motorola_sm7325/blob/lineage-23.2/arch/arm64/boot/dts/vendor/qcom/lahaina.dtsi#L4683

Regards,
Esteban

Re: [PATCH 0/3] SM8450 IPA support

[Alex Elder]

On 6/22/26 8:44 PM, Esteban Urrutia via B4 Relay wrote:
> This series adds support for the IPA subsystem found in the SM8450 SoC.
> While IPA v5.0 is very similar to IPA v5.1 (heck, it even managed to
> properly get the modem up and running), it wasn't perfect, since the
> modem would sometimes hang when rebooting or powering the AP off.
> After a thorough investigation, I managed to create the proper data file
> required for IPA v5.1.
> 
> Regards,
> Esteban

I assume you have implemented this based on what you found in
some downstream code.  And if so, could you please indicate
where to find that (so I can do some cross-referencing myself).
I no longer have access to any Qualcomm internal documentation.

Thanks.

					-Alex

> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> Esteban Urrutia (3):
>        arm64: dts: qcom: sm8450: Add IPA support
>        dt-bindings: net: qcom,ipa: Add SM8450 compatible string
>        net: ipa: Add IPA v5.1 data
> 
>   .../devicetree/bindings/net/qcom,ipa.yaml          |   1 +
>   arch/arm64/boot/dts/qcom/sm8450.dtsi               |  55 ++-
>   drivers/net/ipa/Makefile                           |   2 +-
>   drivers/net/ipa/data/ipa_data-v5.1.c               | 477 +++++++++++++++++++++
>   drivers/net/ipa/gsi_reg.c                          |   1 +
>   drivers/net/ipa/ipa_data.h                         |   1 +
>   drivers/net/ipa/ipa_main.c                         |   4 +
>   drivers/net/ipa/ipa_reg.c                          |   1 +
>   8 files changed, 536 insertions(+), 6 deletions(-)
> ---
> base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
> change-id: 20260622-sm8450-ipa-5da81f67eb65
> 
> Best regards,
> --
> Esteban Urrutia <esteuwu@proton.me>
> 
> 

Re: [PATCH 0/3] SM8450 IPA support

[Esteban Urrutia]

On 6/23/26 11:56 AM, Alex Elder wrote:
> I assume you have implemented this based on what you found in
> some downstream code.  And if so, could you please indicate
> where to find that (so I can do some cross-referencing myself).
> I no longer have access to any Qualcomm internal documentation.

Hello. Yes, that would be the case. What I used goes as follows.

1. My personal findings regarding IPA:
https://gist.github.com/esteuwu/bd49ed67ed9290f41612bdae1cacb5bc

Note that these may be subject to errors since I mostly cross-checked
values to get here.

2. SM8450 downstream device tree:
https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/waipio.dtsi#L3304

3. SM8475 downstream device tree:
https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/cape.dtsi#L2624

It's worth mentioning that between SM8450 and SM8475, IPA SRAM size is
different, so I used the smaller SRAM size to support SM8475 as well. Hence
the reason why I included SM8475's downstream device tree as well.

4. SM8450/SM8475 downstream IPA driver:
https://github.com/LineageOS/android_kernel_qcom_sm8450-modules/tree/lineage-20/qcom/opensource/dataipa

Most of my cross-checking came from the source code in this folder.

Finally, for some values such as qmap, aggregation, tre_count and
event_count, I had to cross-check on the same folder that all
ipa_data-vX.Y.c files reside, since I couldn't find any reference to these
values in downstream code.

Regards,
Esteban

Re: [PATCH 0/3] SM8450 IPA support

[Alex Elder]

On 6/23/26 8:57 PM, Esteban Urrutia wrote:
> On 6/23/26 11:56 AM, Alex Elder wrote:
>> I assume you have implemented this based on what you found in
>> some downstream code.  And if so, could you please indicate
>> where to find that (so I can do some cross-referencing myself).
>> I no longer have access to any Qualcomm internal documentation.
> 
> Hello. Yes, that would be the case. What I used goes as follows.

Thank you very much for sharing this information.

> 1. My personal findings regarding IPA:
> https://gist.github.com/esteuwu/bd49ed67ed9290f41612bdae1cacb5bc

This was interesting to see.  It's something I should probably
document better.  Most everything maps to the downstream code,
but it's not always completely obvious how, because the upstream
driver has evolved substantially.

> Note that these may be subject to errors since I mostly cross-checked
> values to get here.
> 
> 2. SM8450 downstream device tree:
> https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/waipio.dtsi#L3304
> 
> 3. SM8475 downstream device tree:
> https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/cape.dtsi#L2624
> 
> It's worth mentioning that between SM8450 and SM8475, IPA SRAM size is
> different, so I used the smaller SRAM size to support SM8475 as well. Hence
> the reason why I included SM8475's downstream device tree as well.

This means that the SRAM size (ipa_mem_data->smem_size) should
possibly be defined in devicetree (as the IMEM address and size
now are).

The SMEM region is used for "IPA filter tables", and access to
it is shared between the AP and the modem.  Unlike the other
(host) memory regions, the size used is *not* included in the
ipa_init_modem_driver_req message that communicates from the
AP to the modem where the regions are, and their sizes.

So it's possible that the size used must actually match what
is expected by both the AP and modem.  If that is the case,
using the smaller size might have problems on whichever
platform (SM8450?) expects the larger one.

So I'm not sure whether using the smaller size for both
platforms is OK; someone from Qualcomm might be able to
answer that question.

> 4. SM8450/SM8475 downstream IPA driver:
> https://github.com/LineageOS/android_kernel_qcom_sm8450-modules/tree/lineage-20/qcom/opensource/dataipa
> 
> Most of my cross-checking came from the source code in this folder.

Yes, "ipa_utils.c" contains a great deal of the information
needed.

> 
> Finally, for some values such as qmap, aggregation, tre_count and
> event_count, I had to cross-check on the same folder that all
> ipa_data-vX.Y.c files reside, since I couldn't find any reference to these
> values in downstream code.

I'll try to explain those things separately.

					-Alex

> Regards,
> Esteban
> 

Re: [PATCH 0/3] SM8450 IPA support

[Esteban Urrutia]

On 7/8/26 3:49 PM, Alex Elder wrote:
> This was interesting to see.  It's something I should probably
> document better.  Most everything maps to the downstream code,
> but it's not always completely obvious how, because the upstream
> driver has evolved substantially.

On a personal note, I'm surprised to see someone not from Qualcomm
maintaining this driver. It must be hard, so kudos.

> This means that the SRAM size (ipa_mem_data->smem_size) should
> possibly be defined in devicetree (as the IMEM address and size
> now are).
> 
> The SMEM region is used for "IPA filter tables", and access to
> it is shared between the AP and the modem.  Unlike the other
> (host) memory regions, the size used is *not* included in the
> ipa_init_modem_driver_req message that communicates from the
> AP to the modem where the regions are, and their sizes.
> 
> So it's possible that the size used must actually match what
> is expected by both the AP and modem.  If that is the case,
> using the smaller size might have problems on whichever
> platform (SM8450?) expects the larger one.
> 
> So I'm not sure whether using the smaller size for both
> platforms is OK; someone from Qualcomm might be able to
> answer that question.

I actually went ahead and reviewed downstream device trees I found on
GitHub (1) which contain both SM8450 and SM8475 device trees looking for
the qcom,ipa-q6-smem-size property, which would correspond to the SRAM
size, and to my surprise, this was set to 0x9000 for both SoCs.
Most likely the commit I got the SRAM information from (2) never made it
to production devices.

With this clarified, I think it should be okay to keep things defined as
they currently are.

> I'll try to explain those things separately.
Regarding this, I have a question: where would this be published?

Thanks for taking the time to properly review my changes.
I'll address the review when I can.

(1) https://github.com/sm8450-mainline/fdt
(2) https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/commit/477aab9e7479ff553c7a162ae74029170a2e8291.patch

Regards,
Esteban

Re: [PATCH 0/3] SM8450 IPA support

[Dmitry Baryshkov]

On Mon, Jun 22, 2026 at 09:44:16PM -0400, Esteban Urrutia via B4 Relay wrote:
> This series adds support for the IPA subsystem found in the SM8450 SoC.
> While IPA v5.0 is very similar to IPA v5.1 (heck, it even managed to
> properly get the modem up and running), it wasn't perfect, since the
> modem would sometimes hang when rebooting or powering the AP off.
> After a thorough investigation, I managed to create the proper data file
> required for IPA v5.1.
> 
> Regards,
> Esteban
> 
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> Esteban Urrutia (3):
>       arm64: dts: qcom: sm8450: Add IPA support
>       dt-bindings: net: qcom,ipa: Add SM8450 compatible string
>       net: ipa: Add IPA v5.1 data

Please reoder the patches:
- DT bindings
- driver
- DTS.

It follows the natural way you'd read the patchset.

> 
>  .../devicetree/bindings/net/qcom,ipa.yaml          |   1 +
>  arch/arm64/boot/dts/qcom/sm8450.dtsi               |  55 ++-
>  drivers/net/ipa/Makefile                           |   2 +-
>  drivers/net/ipa/data/ipa_data-v5.1.c               | 477 +++++++++++++++++++++
>  drivers/net/ipa/gsi_reg.c                          |   1 +
>  drivers/net/ipa/ipa_data.h                         |   1 +
>  drivers/net/ipa/ipa_main.c                         |   4 +
>  drivers/net/ipa/ipa_reg.c                          |   1 +
>  8 files changed, 536 insertions(+), 6 deletions(-)
> ---
> base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
> change-id: 20260622-sm8450-ipa-5da81f67eb65
> 
> Best regards,
> --  
> Esteban Urrutia <esteuwu@proton.me>
> 
> 

-- 
With best wishes
Dmitry