From e21d3b2e5c4387b243424daa0ff2d45c6fbf73e2 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 20 May 2026 17:51:29 +0300 Subject: soc: qcom: ubwc: set min_acc length to 64 for all UBWC 1.0 targets According to the documentation, the MAL should be set for all UBWC 1.0 targets, no matter what is the version of the UBWC decoders are present on the device. The helper comes from DPU / GPU world, where there was no separate bit to control MAL before UBWC 2.0. As the helper is now being used by other drivers too, correct the helper to return the correct MAL value (Iris doesn't support UBWC 1.0 devices for now, so there is no changes of the behaviour). Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-22-72f2749bc807@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/ubwc.h | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h index 83d2c2a7116c..0b5aa9d0343b 100644 --- a/include/linux/soc/qcom/ubwc.h +++ b/include/linux/soc/qcom/ubwc.h @@ -75,14 +75,9 @@ static inline bool qcom_ubwc_get_ubwc_mode(const struct qcom_ubwc_cfg_data *cfg) return ret; } -/* - * This is the best guess, based on the MDSS driver, which worked so far. - */ static inline bool qcom_ubwc_min_acc_length_64b(const struct qcom_ubwc_cfg_data *cfg) { - return cfg->ubwc_enc_version == UBWC_1_0 && - (cfg->ubwc_dec_version == UBWC_2_0 || - cfg->ubwc_dec_version == UBWC_3_0); + return cfg->ubwc_enc_version == UBWC_1_0; } static inline bool qcom_ubwc_macrotile_mode(const struct qcom_ubwc_cfg_data *cfg) -- cgit v1.2.3 From e7012ac2fc000fe7ae3e58a7449b80fa955b124a Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 20 May 2026 17:51:30 +0300 Subject: soc: qcom: ubwc: drop ubwc_dec_version The ubwc_dec_version field has been inherited from the MDSS driver and it is equal to the version of the UBWC decoder in the display block only. Other IP Cores can have different UBWC decoders and so the version would vary between blocks. As the value is no longer used as is not relevant to other UBWC database consumers, drop it from the UBWC database. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-23-72f2749bc807@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/ubwc.h | 2 -- 1 file changed, 2 deletions(-) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h index 0b5aa9d0343b..c3f9efae5db8 100644 --- a/include/linux/soc/qcom/ubwc.h +++ b/include/linux/soc/qcom/ubwc.h @@ -13,8 +13,6 @@ struct qcom_ubwc_cfg_data { u32 ubwc_enc_version; - /* Can be read from MDSS_BASE + 0x58 */ - u32 ubwc_dec_version; /** * @ubwc_swizzle: Whether to enable level 1, 2 & 3 bank swizzling. -- cgit v1.2.3 From 5a9f4c535ae05facd4f6ef116b18062f9f2ad768 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 20 May 2026 17:51:31 +0300 Subject: soc: qcom: ubwc: drop ubwc_bank_spread According to the documentation, UBWC bank spreading should be enabled for all targets. It's just not all targets have separate bit to control it. Drop the bit from the database and make the helper always return true. If we need to change it later, the helper can be adjusted according to the programming guides. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-24-72f2749bc807@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/ubwc.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h index c3f9efae5db8..254721f5ea3c 100644 --- a/include/linux/soc/qcom/ubwc.h +++ b/include/linux/soc/qcom/ubwc.h @@ -33,7 +33,6 @@ struct qcom_ubwc_cfg_data { * DDR bank. This should ideally use DRAM type detection. */ int highest_bank_bit; - bool ubwc_bank_spread; /** * @macrotile_mode: Macrotile Mode @@ -85,7 +84,7 @@ static inline bool qcom_ubwc_macrotile_mode(const struct qcom_ubwc_cfg_data *cfg static inline bool qcom_ubwc_bank_spread(const struct qcom_ubwc_cfg_data *cfg) { - return cfg->ubwc_bank_spread; + return true; } static inline u32 qcom_ubwc_swizzle(const struct qcom_ubwc_cfg_data *cfg) -- cgit v1.2.3 From fc54caf87a5a7289502ecbcdc80bb71f7bb5de9c Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 20 May 2026 17:51:32 +0300 Subject: soc: qcom: ubwc: drop macrotile_mode from the database All the users have been migrated to using qcom_ubwc_macrotile_mode() instead of reading the raw value from the config structure. Drop the field from struct qcom_ubwc_cfg_data and replace it with the calculated value. Split single UBWC_3_0 into UBWC_3_0 (no macrotile mode) and UBWC_3_1 (with macrotile mode). Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-25-72f2749bc807@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/ubwc.h | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h index 254721f5ea3c..fee778360ac2 100644 --- a/include/linux/soc/qcom/ubwc.h +++ b/include/linux/soc/qcom/ubwc.h @@ -33,15 +33,6 @@ struct qcom_ubwc_cfg_data { * DDR bank. This should ideally use DRAM type detection. */ int highest_bank_bit; - - /** - * @macrotile_mode: Macrotile Mode - * - * Whether to use 4-channel macrotiling mode or the newer - * 8-channel macrotiling mode introduced in UBWC 3.1. 0 is - * 4-channel and 1 is 8-channel. - */ - bool macrotile_mode; }; #define UBWC_1_0 0x10000000 @@ -77,9 +68,16 @@ static inline bool qcom_ubwc_min_acc_length_64b(const struct qcom_ubwc_cfg_data return cfg->ubwc_enc_version == UBWC_1_0; } +/* + * @qcom_ubwc_macrotile_mode: whether to use 4-channel or 8-channel macrotiling + * + * The 8-channel macrotiling mode was introduced in UBWC 3.1. + * + * Returns: false for the 4-channel and true for 8-channel. + */ static inline bool qcom_ubwc_macrotile_mode(const struct qcom_ubwc_cfg_data *cfg) { - return cfg->macrotile_mode; + return cfg->ubwc_enc_version >= UBWC_3_1; } static inline bool qcom_ubwc_bank_spread(const struct qcom_ubwc_cfg_data *cfg) -- cgit v1.2.3 From 17120525ff070da978effc009877bace3d788698 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 20 May 2026 17:51:33 +0300 Subject: soc: qcom: ubwc: use fixed values for UBWC swizzle for UBWC < 4.0 UBWC devices before 4.0 use standard UBWC swizzle levels. As all the drivers now use the qcom_ubwc_swizzle() helper, move those values to the helper, leaving UBWC 4.0+ intact for now. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-26-72f2749bc807@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/ubwc.h | 33 ++++++++++++++++++++++++--------- 1 file changed, 24 insertions(+), 9 deletions(-) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h index fee778360ac2..7c9506741001 100644 --- a/include/linux/soc/qcom/ubwc.h +++ b/include/linux/soc/qcom/ubwc.h @@ -22,9 +22,6 @@ struct qcom_ubwc_cfg_data { * UBWC 4.0 adds the optional ability to disable levels 2 & 3. */ u32 ubwc_swizzle; -#define UBWC_SWIZZLE_ENABLE_LVL1 BIT(0) -#define UBWC_SWIZZLE_ENABLE_LVL2 BIT(1) -#define UBWC_SWIZZLE_ENABLE_LVL3 BIT(2) /** * @highest_bank_bit: Highest Bank Bit @@ -55,12 +52,7 @@ static inline const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void) static inline bool qcom_ubwc_get_ubwc_mode(const struct qcom_ubwc_cfg_data *cfg) { - bool ret = cfg->ubwc_enc_version == UBWC_1_0; - - if (ret && !(cfg->ubwc_swizzle & UBWC_SWIZZLE_ENABLE_LVL1)) - pr_err("UBWC config discrepancy - level 1 swizzling disabled on UBWC 1.0\n"); - - return ret; + return cfg->ubwc_enc_version == UBWC_1_0; } static inline bool qcom_ubwc_min_acc_length_64b(const struct qcom_ubwc_cfg_data *cfg) @@ -85,8 +77,31 @@ static inline bool qcom_ubwc_bank_spread(const struct qcom_ubwc_cfg_data *cfg) return true; } +#define UBWC_SWIZZLE_ENABLE_LVL1 BIT(0) +#define UBWC_SWIZZLE_ENABLE_LVL2 BIT(1) +#define UBWC_SWIZZLE_ENABLE_LVL3 BIT(2) + +/** + * @qcom_ubwc_swizzle: Whether to enable level 1, 2 & 3 bank swizzling. + * + * UBWC 1.0 always enables all three levels. + * UBWC 2.0 removes level 1 bank swizzling, leaving levels 2 & 3. + * UBWC 4.0 adds the optional ability to disable levels 2 & 3. + */ static inline u32 qcom_ubwc_swizzle(const struct qcom_ubwc_cfg_data *cfg) { + if (cfg->ubwc_enc_version == 0) + return 0; + + if (cfg->ubwc_enc_version == UBWC_1_0) + return UBWC_SWIZZLE_ENABLE_LVL1 | + UBWC_SWIZZLE_ENABLE_LVL2 | + UBWC_SWIZZLE_ENABLE_LVL3; + + if (cfg->ubwc_enc_version < UBWC_4_0) + return UBWC_SWIZZLE_ENABLE_LVL2 | + UBWC_SWIZZLE_ENABLE_LVL3; + return cfg->ubwc_swizzle; } -- cgit v1.2.3 From 31e1c3248586dcc9aae42539152ab271dcfd37b6 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 20 May 2026 17:51:34 +0300 Subject: soc: qcom: ubwc: sort out the rest of the UBWC swizzle settings Sort out the remaining UBWC swizzle values, using flags to control whether level 2 and level 3 swizzling are enabled or not. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-27-72f2749bc807@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/ubwc.h | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h index 7c9506741001..a7372d9c25fb 100644 --- a/include/linux/soc/qcom/ubwc.h +++ b/include/linux/soc/qcom/ubwc.h @@ -14,15 +14,6 @@ struct qcom_ubwc_cfg_data { u32 ubwc_enc_version; - /** - * @ubwc_swizzle: Whether to enable level 1, 2 & 3 bank swizzling. - * - * UBWC 1.0 always enables all three levels. - * UBWC 2.0 removes level 1 bank swizzling, leaving levels 2 & 3. - * UBWC 4.0 adds the optional ability to disable levels 2 & 3. - */ - u32 ubwc_swizzle; - /** * @highest_bank_bit: Highest Bank Bit * @@ -30,6 +21,10 @@ struct qcom_ubwc_cfg_data { * DDR bank. This should ideally use DRAM type detection. */ int highest_bank_bit; + + unsigned int flags; +#define UBWC_FLAG_DISABLE_SWIZZLE_LVL2 BIT(0) +#define UBWC_FLAG_DISABLE_SWIZZLE_LVL3 BIT(1) }; #define UBWC_1_0 0x10000000 @@ -98,11 +93,16 @@ static inline u32 qcom_ubwc_swizzle(const struct qcom_ubwc_cfg_data *cfg) UBWC_SWIZZLE_ENABLE_LVL2 | UBWC_SWIZZLE_ENABLE_LVL3; - if (cfg->ubwc_enc_version < UBWC_4_0) - return UBWC_SWIZZLE_ENABLE_LVL2 | - UBWC_SWIZZLE_ENABLE_LVL3; + u32 ubwc_swizzle = UBWC_SWIZZLE_ENABLE_LVL2 | + UBWC_SWIZZLE_ENABLE_LVL3; + + if (cfg->flags & UBWC_FLAG_DISABLE_SWIZZLE_LVL2) + ubwc_swizzle &= ~UBWC_SWIZZLE_ENABLE_LVL2; + + if (cfg->flags & UBWC_FLAG_DISABLE_SWIZZLE_LVL3) + ubwc_swizzle &= ~UBWC_SWIZZLE_ENABLE_LVL3; - return cfg->ubwc_swizzle; + return ubwc_swizzle; } static inline u32 qcom_ubwc_version_tag(const struct qcom_ubwc_cfg_data *cfg) -- cgit v1.2.3 From 08314e7c2c38b9ae6a5e01c58ed10a950859404d Mon Sep 17 00:00:00 2001 From: Sumit Garg Date: Thu, 2 Jul 2026 17:28:17 +0530 Subject: firmware: qcom: Add a generic PAS service Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. Reviewed-by: Mukesh Ojha Tested-by: Mukesh Ojha # Lemans Reviewed-by: Harshal Dev Tested-by: Vignesh Viswanathan # IPQ9650 Signed-off-by: Sumit Garg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260702115835.167602-2-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson --- include/linux/firmware/qcom/qcom_pas.h | 43 ++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 include/linux/firmware/qcom/qcom_pas.h (limited to 'include/linux') diff --git a/include/linux/firmware/qcom/qcom_pas.h b/include/linux/firmware/qcom/qcom_pas.h new file mode 100644 index 000000000000..65b1c9564458 --- /dev/null +++ b/include/linux/firmware/qcom/qcom_pas.h @@ -0,0 +1,43 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2010-2015, 2018-2019 The Linux Foundation. All rights reserved. + * Copyright (C) 2015 Linaro Ltd. + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. + */ + +#ifndef __QCOM_PAS_H +#define __QCOM_PAS_H + +#include +#include + +struct qcom_pas_context { + struct device *dev; + u32 pas_id; + phys_addr_t mem_phys; + size_t mem_size; + void *ptr; + dma_addr_t phys; + ssize_t size; + bool use_tzmem; +}; + +bool qcom_pas_is_available(void); +struct qcom_pas_context *devm_qcom_pas_context_alloc(struct device *dev, + u32 pas_id, + phys_addr_t mem_phys, + size_t mem_size); +int qcom_pas_init_image(u32 pas_id, const void *metadata, size_t size, + struct qcom_pas_context *ctx); +struct resource_table *qcom_pas_get_rsc_table(struct qcom_pas_context *ctx, + void *input_rt, size_t input_rt_size, + size_t *output_rt_size); +int qcom_pas_mem_setup(u32 pas_id, phys_addr_t addr, phys_addr_t size); +int qcom_pas_auth_and_reset(u32 pas_id); +int qcom_pas_prepare_and_auth_reset(struct qcom_pas_context *ctx); +int qcom_pas_set_remote_state(u32 state, u32 pas_id); +int qcom_pas_shutdown(u32 pas_id); +bool qcom_pas_supported(u32 pas_id); +void qcom_pas_metadata_release(struct qcom_pas_context *ctx); + +#endif /* __QCOM_PAS_H */ -- cgit v1.2.3 From 522bfb4f33c0930b3d14d5c5ee80bc93a883b544 Mon Sep 17 00:00:00 2001 From: Viken Dadhaniya Date: Thu, 2 Jul 2026 11:12:23 +0530 Subject: soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware size The hardcoded MAX_GENI_CFG_RAMn_CNT limit is not accurate for all SoCs: some targets have less CFG RAM than the constant implies, while others like QCS615 need more entries than the old limit of 455 allowed, causing valid firmware to be rejected at load time. Rather than hardcoding a constant, read PROG_RAM_DEPTH from SE_HW_PARAM_2 at runtime to get the actual CFG RAM depth of the hardware instance and use that as the upper bound for firmware size validation. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20260702-qup-se-increase-ram-cnt-v3-1-80b363373a5b@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/geni-se.h | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/geni-se.h b/include/linux/soc/qcom/geni-se.h index c5e6ab85df09..0991ef7ec092 100644 --- a/include/linux/soc/qcom/geni-se.h +++ b/include/linux/soc/qcom/geni-se.h @@ -124,6 +124,7 @@ struct geni_se { #define SE_DMA_RX_FSM_RST 0xd58 #define SE_HW_PARAM_0 0xe24 #define SE_HW_PARAM_1 0xe28 +#define SE_HW_PARAM_2 0xe2c /* GENI_FORCE_DEFAULT_REG fields */ #define FORCE_DEFAULT BIT(0) @@ -291,6 +292,9 @@ struct geni_se { #define RX_FIFO_DEPTH_MSK GENMASK(21, 16) #define RX_FIFO_DEPTH_SHFT 16 +/* SE_HW_PARAM_2 fields */ +#define PROG_RAM_DEPTH_MSK GENMASK(10, 0) + #define HW_VER_MAJOR_MASK GENMASK(31, 28) #define HW_VER_MAJOR_SHFT 28 #define HW_VER_MINOR_MASK GENMASK(27, 16) -- cgit v1.2.3 From 1d234eeafc56af8c9af6eee857f41a4310615e78 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Mon, 27 Jul 2026 11:59:28 +0200 Subject: soc: qcom: smem: Expose DDR data from SMEM Most modern Qualcomm platforms (>= SM8150) expose information about the DDR memory present on the system via SMEM. Details from this information is used in various scenarios, such as multimedia drivers configuring the hardware based on the "Highest Bank address Bit" (hbb), or the list of valid frequencies in validation scenarios... Add support for parsing v3-v7 version of the structs. Unforunately, they are not versioned, so some elbow grease is necessary to determine which one is present. See for reference: ver 3: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a ver 4: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/f6e9aa549260bbc0bdcb156c2b05f48dc5963203 ver 5: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/617d3297abe8b1b8dd3de3d1dd69c3961e6f343f ver 5 with 6regions: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/d770e009f9bae58d56d926f7490bbfb45af8341f ver 6: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/62659b557fdb1551b20fae8073d1d701dfa8a62e ver 7: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/734d95599c5ebb1ca0d4e1639142e65c590532b7 Reviewed-by: Bjorn Andersson Signed-off-by: Konrad Dybcio Link: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a Link: https://lore.kernel.org/r/20260727-topic-smem_dramc-v5-2-66188b3e338d@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/smem.h | 2 ++ 1 file changed, 2 insertions(+) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h index f946e3beca21..3249cbd2016b 100644 --- a/include/linux/soc/qcom/smem.h +++ b/include/linux/soc/qcom/smem.h @@ -17,4 +17,6 @@ int qcom_smem_get_feature_code(u32 *code); int qcom_smem_bust_hwspin_lock_by_host(unsigned int host); +int qcom_smem_dram_get_hbb(void); + #endif -- cgit v1.2.3 From 4f6981ea8fdb1916bff5d35e39634d5a5abb631a Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Wed, 22 Jul 2026 02:16:02 +0300 Subject: soc: fsl: guts: implement the RCW override procedure Add support for the RCW override procedure which enables runtime reconfiguration of the protocol running on a SerDes lane. The procedure is done through the DCFG DCSR space which now can be defined as the second memory region of the guts DT node. Support is added on the following SoCs: LS1046A, LS1088A, LS2088A. The procedure is exported to the "client" driver - the Lynx10G SerDes PHY driver - through the following functions: - fsl_guts_lane_validate() used to validate that changing the protocol on a specific lane is supported. - fsl_guts_lane_set_mode() which can be used to request the RCW procedure be executed for a specific lane. Since the RCW override procedure is different depending on the SoC, the private fsl_soc_data structure is updated with two new per SoC callbacks (.serdes_get_rcw_override() and .serdes_init_rcwcr()) which get used from the generic fsl_guts_lane_set_mode() function. These two callbacks hide all the SoC specific register offsets, masks and values so that the _set_mode() procedure is straightforward. Signed-off-by: Ioana Ciornei Signed-off-by: Vladimir Oltean Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20260721231603.67865-9-vladimir.oltean@nxp.com Signed-off-by: Christophe Leroy (CS GROUP) --- include/linux/fsl/guts.h | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) (limited to 'include/linux') diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h index fdb55ca47a4f..8d5ffb985fee 100644 --- a/include/linux/fsl/guts.h +++ b/include/linux/fsl/guts.h @@ -13,6 +13,7 @@ #include #include +#include /* * Global Utility Registers. @@ -91,9 +92,15 @@ struct ccsr_guts { u32 iovselsr; /* 0x.00c0 - I/O voltage select status register Called 'elbcvselcr' on 86xx SOCs */ u8 res0c4[0x100 - 0xc4]; - u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers - There are 16 registers */ - u8 res140[0x224 - 0x140]; + /* 0x.0100 - read-only Reset Configuration Word Status registers in + * CCSR, or write-only Reset Configuration Word Control registers in + * DCSR. In both cases there are 32 registers. + */ + union { + u32 rcwsr[32]; + u32 rcwcr[32]; + }; + u8 res180[0x224 - 0x180]; u32 iodelay1; /* 0x.0224 - IO delay control register 1 */ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */ u8 res22c[0x604 - 0x22c]; @@ -131,6 +138,11 @@ struct ccsr_guts { u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */ } __attribute__ ((packed)); +int fsl_guts_lane_validate(int serdes_idx, int lane, + enum lynx_lane_mode lane_mode); +int fsl_guts_lane_set_mode(int serdes_idx, int lane, + enum lynx_lane_mode lane_mode); + /* Alternate function signal multiplex control */ #define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x)) -- cgit v1.2.3 From 00bee072c8ae394b029ed4ce6fc8def3e5627e1c Mon Sep 17 00:00:00 2001 From: Jay Buddhabhatti Date: Wed, 29 Jul 2026 05:25:20 -0700 Subject: firmware: xilinx: Add support to clear EL3 PM state Currently, during a kexec restart, only the kernel is reloaded, while EL3-specific data remain unchanged. This leads to a mismatch between the kernel state and secure firmware state like SGI number and shutdown scope variable. For example, the kernel registers an SGI number with EL3 firmware so that secure firmware can notify the kernel of events via that SGI. EL3 stores this SGI number in its internal state. After a kexec, the newly loaded kernel re-registers and may request a different SGI number, but the stale value programmed in EL3 remains, so event notifications are delivered on the old SGI and are missed by the new kernel. The shutdown scope variable has a similar stale state problem. To resolve this, the TF_A_CLEAR_PM_STATE PM API is introduced to clear EL3 PM subsystem state during kexec. On a graceful reboot, this API is triggered by zynqmp_firmware_shutdown(), while in a crash kernel scenario, it is invoked by zynqmp_firmware_probe() in the reloaded kernel. Signed-off-by: Jay Buddhabhatti Reviewed-by: Radhey Shyam Pandey Reviewed-by: Prasanna Kumar T S M Link: https://patch.msgid.link/20260729122522.3732875-2-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek --- include/linux/firmware/xlnx-zynqmp.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'include/linux') diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h index 7e27b0f7bf7e..baaa88b0b197 100644 --- a/include/linux/firmware/xlnx-zynqmp.h +++ b/include/linux/firmware/xlnx-zynqmp.h @@ -3,7 +3,7 @@ * Xilinx Zynq MPSoC Firmware layer * * Copyright (C) 2014-2021 Xilinx - * Copyright (C) 2022 - 2025 Advanced Micro Devices, Inc. + * Copyright (C) 2022 - 2026 Advanced Micro Devices, Inc. * * Michal Simek * Davorin Mista @@ -66,6 +66,7 @@ #define FIRMWARE_VERSION_MASK 0xFFFFU /* ATF only commands */ +#define TF_A_CLEAR_PM_STATE 0xa05 #define TF_A_PM_REGISTER_SGI 0xa04 #define PM_GET_TRUSTZONE_VERSION 0xa03 #define PM_SET_SUSPEND_MODE 0xa02 -- cgit v1.2.3 From 84dbfa5519cf6583d09ee0123ac580542b144553 Mon Sep 17 00:00:00 2001 From: Jay Buddhabhatti Date: Wed, 29 Jul 2026 05:25:21 -0700 Subject: firmware: xilinx: Release all peripheral devices from firmware During a kexec restart, only the kernel is reloaded while devices allocated in firmware persist, causing state mismatches between the kernel and firmware. Introduce PM_DEV_ALL_PERIPH node ID (0x18224FFFU) to release all peripheral devices during kexec. On graceful restarts, this happens in zynqmp_firmware_shutdown(). On crash kernel restarts, it happens in zynqmp_firmware_probe() of the reloaded kernel. Releasing all peripherals depends on firmware support for the PM_DEV_ALL_PERIPH node ID. On firmware that does not implement it (the feature check reports a version below PM_API_VERSION_3) the release is skipped and a warning such as "Bulk device release is not supported by firmware" is logged, e.g. on Versal NET firmware that predates this API. Signed-off-by: Jay Buddhabhatti Reviewed-by: Radhey Shyam Pandey Reviewed-by: Prasanna Kumar T S M Link: https://patch.msgid.link/20260729122522.3732875-3-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek --- include/linux/firmware/xlnx-zynqmp.h | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'include/linux') diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h index baaa88b0b197..ac39e5492961 100644 --- a/include/linux/firmware/xlnx-zynqmp.h +++ b/include/linux/firmware/xlnx-zynqmp.h @@ -50,6 +50,7 @@ /* PM API versions */ #define PM_API_VERSION_1 1 #define PM_API_VERSION_2 2 +#define PM_API_VERSION_3 3 #define PM_PINCTRL_PARAM_SET_VERSION 2 @@ -145,6 +146,9 @@ #define XPM_EVENT_ERROR_MASK_NOC_NCR BIT(13) #define XPM_EVENT_ERROR_MASK_NOC_CR BIT(12) +/* Node ID for all peripheral devices */ +#define PM_DEV_ALL_PERIPH 0x18224FFFU + enum pm_module_id { PM_MODULE_ID = 0x0, XPM_MODULE_ID = 0x2, -- cgit v1.2.3 From 0e8860367da261116cd290bcd6a54d2e597a0c5c Mon Sep 17 00:00:00 2001 From: Jay Buddhabhatti Date: Wed, 29 Jul 2026 05:25:22 -0700 Subject: firmware: xilinx: Clear firmware notifiers across kexec transitions During a kexec restart, only the kernel is reloaded but notifier callbacks in firmware persist, causing state mismatches between kernel and firmware. To address this, introduce PM_ALL_NOTIFIERS node ID to unregister all notifier callbacks during kexec. On a graceful kexec restart, this occurs in zynqmp_firmware_shutdown(). On a crash kernel restart, it happens in zynqmp_firmware_probe() in the reloaded kernel. Unregistering all notifiers depends on firmware support for the PM_ALL_NOTIFIERS node ID. On firmware that does not implement it (the feature check reports a version below PM_API_VERSION_3) the step is skipped and a warning such as "Firmware doesn't support unregister all notifiers at once" is logged, e.g. on Versal NET firmware that predates this API. Signed-off-by: Jay Buddhabhatti Reviewed-by: Radhey Shyam Pandey Reviewed-by: Prasanna Kumar T S M Link: https://patch.msgid.link/20260729122522.3732875-4-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek --- include/linux/firmware/xlnx-zynqmp.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'include/linux') diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h index ac39e5492961..69a2f74269f3 100644 --- a/include/linux/firmware/xlnx-zynqmp.h +++ b/include/linux/firmware/xlnx-zynqmp.h @@ -149,6 +149,9 @@ /* Node ID for all peripheral devices */ #define PM_DEV_ALL_PERIPH 0x18224FFFU +/* Node ID for all notifier callbacks */ +#define PM_ALL_NOTIFIERS 0xFFFFFFFFU + enum pm_module_id { PM_MODULE_ID = 0x0, XPM_MODULE_ID = 0x2, -- cgit v1.2.3 From c6441becf4d064bb1dcbccbd3e2276833804cff5 Mon Sep 17 00:00:00 2001 From: Daniel Baluta Date: Mon, 17 Aug 2026 15:35:41 +0300 Subject: soc: qcom: ubwc: Fix missing include MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When CONFIG_QCOM_UBWC_CONFIG=n, compiler needs to know the definition of ERR_PTR otherwise there will be a compilation error: In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.c:7: ./include/linux/soc/qcom/ubwc.h: In function ‘qcom_ubwc_config_get_data’: ./include/linux/soc/qcom/ubwc.h:45:16: error: implicit declaration of function ‘ERR_PTR’ [-Wimplicit-function-declaration] Fix this by including Fixes: 1924272b9ce1 ("soc: qcom: Add UBWC config provider") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Daniel Baluta Tested-by: Nathan Chancellor # build Signed-off-by: Arnd Bergmann --- include/linux/soc/qcom/ubwc.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux') diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h index a7372d9c25fb..f3a70360b177 100644 --- a/include/linux/soc/qcom/ubwc.h +++ b/include/linux/soc/qcom/ubwc.h @@ -8,6 +8,7 @@ #define __QCOM_UBWC_H__ #include +#include #include #include -- cgit v1.2.3