* [PATCH v4 0/4] ASoC: qcom and pinctrl: add LPASS LPR voting and Hawi LPASS LPI TLMM
From: Prasad Kumpatla @ 2026-07-20 13:05 UTC (permalink / raw)
To: Bartosz Golaszewski, Bjorn Andersson, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Srinivas Kandagatla, Jaroslav Kysela, Takashi Iwai,
Prasad Kumpatla
Cc: Krzysztof Kozlowski, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree, linux-kernel, linux-sound
This series adds support for LPASS low-power resource (LPR) voting
through PRM and introduces LPASS LPI TLMM pinctrl support for newer
platforms such as Hawi.
On such platforms, LPASS requires LPR resource voting via PRM to keep
the subsystem active. This is handled by adding a new clock ID and
support for PARAM_ID_RSC_CPU_LPR in q6prm.
Additionally, a new LPASS LPI TLMM block is introduced, requiring a
dedicated DT binding and pinctrl driver.
Chanes in v4:
- Addressed Krzysztof comments, Drop Q6AFE_MAX_CLK_ID from the bindings
since it is not used in-tree.
- Link to v3: https://lore.kernel.org/linux-arm-msm/20260715133243.3170821-1-prasad.kumpatla@oss.qualcomm.com/
Changes in v3:
- Drop the mutex cleanup patch from this series. Since this change
is not required for Hawi enablement, keep the current series
focused on LPASS LPR voting and LPASS LPI TLMM support, and
address the cleanup in a dedicated follow-up series.
- As Srini suggested changed LPR_CPU_SS_SLEEP_DISABLED to LPR_CPU_SS_SLEEP_DISABLE in patch#2.
- Link to v2: https://lore.kernel.org/all/20260713184549.929569-1-prasad.kumpatla@oss.qualcomm.com/
Changes in v2:
- Add mutex cleanup devm-managed in LPASS LPI Pinctrl.
- Addressed Bart Comments related to newline and readability.
- Link to v1: https://lore.kernel.org/linux-arm-msm/20260708114924.1069239-1-prasad.kumpatla@oss.qualcomm.com/
Prasad Kumpatla (4):
ASoC: dt-bindings: qcom: add LPASS LPR vote clock ID
ASoC: qcom: q6prm: add support for LPASS LPR resource voting
dt-bindings: pinctrl: qcom,hawi-lpass-lpi-pinctrl: Add Hawi LPI
pinctrl
pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM
.../pinctrl/qcom,hawi-lpass-lpi-pinctrl.yaml | 109 ++++++++
drivers/pinctrl/qcom/Kconfig | 10 +
drivers/pinctrl/qcom/Makefile | 1 +
drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c | 244 ++++++++++++++++++
drivers/pinctrl/qcom/pinctrl-lpass-lpi.h | 17 ++
.../sound/qcom,q6dsp-lpass-ports.h | 2 +-
sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c | 2 +-
sound/soc/qcom/qdsp6/q6prm-clocks.c | 2 +
sound/soc/qcom/qdsp6/q6prm.c | 16 +-
sound/soc/qcom/qdsp6/q6prm.h | 1 +
10 files changed, 399 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,hawi-lpass-lpi-pinctrl.yaml
create mode 100644 drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c
--
2.34.1
^ permalink raw reply
* [PATCH v4 2/4] ASoC: qcom: q6prm: add support for LPASS LPR resource voting
From: Prasad Kumpatla @ 2026-07-20 13:05 UTC (permalink / raw)
To: Bartosz Golaszewski, Bjorn Andersson, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Srinivas Kandagatla, Jaroslav Kysela, Takashi Iwai,
Prasad Kumpatla
Cc: Krzysztof Kozlowski, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree, linux-kernel, linux-sound
In-Reply-To: <20260720130511.493295-1-prasad.kumpatla@oss.qualcomm.com>
Add support for issuing LPASS low-power resource (LPR) votes through
the PRM interface.
Some platforms (e.g. Hawi) require the LPASS to be kept active via LPR
resource voting instead of the existing hardware core vote mechanism.
Handle this by introducing support for PARAM_ID_RSC_CPU_LPR when the
LPR vote clock ID is requested.
For LPR requests, use the appropriate parameter ID and payload format
to disable CPU subsystem sleep, ensuring that the LPASS register space
remains accessible.
Also add the corresponding clock mapping for LPASS_HW_LPR_VOTE and
update Q6DSP_MAX_CLK_ID to 105 to keep the q6dsp clock ID range
consistent with the dt-bindings.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
---
sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c | 2 +-
sound/soc/qcom/qdsp6/q6prm-clocks.c | 2 ++
sound/soc/qcom/qdsp6/q6prm.c | 16 +++++++++++++---
sound/soc/qcom/qdsp6/q6prm.h | 1 +
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c b/sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c
index 03838582a..ab7d20580 100644
--- a/sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c
+++ b/sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c
@@ -12,7 +12,7 @@
#include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
#include "q6dsp-lpass-clocks.h"
-#define Q6DSP_MAX_CLK_ID 104
+#define Q6DSP_MAX_CLK_ID 105
#define Q6DSP_LPASS_CLK_ROOT_DEFAULT 0
diff --git a/sound/soc/qcom/qdsp6/q6prm-clocks.c b/sound/soc/qcom/qdsp6/q6prm-clocks.c
index 4c574b48a..2b2b3872e 100644
--- a/sound/soc/qcom/qdsp6/q6prm-clocks.c
+++ b/sound/soc/qcom/qdsp6/q6prm-clocks.c
@@ -63,6 +63,8 @@ static const struct q6dsp_clk_init q6prm_clks[] = {
"LPASS_HW_MACRO"),
Q6DSP_VOTE_CLK(LPASS_HW_DCODEC_VOTE, Q6PRM_HW_CORE_ID_DCODEC,
"LPASS_HW_DCODEC"),
+ Q6DSP_VOTE_CLK(LPASS_HW_LPR_VOTE, Q6PRM_HW_LPR_VOTE,
+ "LPASS_HW_LPR_VOTE"),
};
static const struct q6dsp_clk_desc q6dsp_clk_q6prm __maybe_unused = {
diff --git a/sound/soc/qcom/qdsp6/q6prm.c b/sound/soc/qcom/qdsp6/q6prm.c
index 04892fb44..1f3ce4cc0 100644
--- a/sound/soc/qcom/qdsp6/q6prm.c
+++ b/sound/soc/qcom/qdsp6/q6prm.c
@@ -31,10 +31,16 @@ struct q6prm {
#define PARAM_ID_RSC_HW_CORE 0x08001032
#define PARAM_ID_RSC_LPASS_CORE 0x0800102B
#define PARAM_ID_RSC_AUDIO_HW_CLK 0x0800102C
+#define PARAM_ID_RSC_CPU_LPR 0x08001A6E
+
+#define LPR_CPU_SS_SLEEP_DISABLE 0x1
struct prm_cmd_request_hw_core {
struct apm_module_param_data param_data;
- uint32_t hw_clk_id;
+ union {
+ u32 hw_clk_id;
+ u32 lpr_state;
+ };
} __packed;
struct prm_cmd_request_rsc {
@@ -62,6 +68,7 @@ static int q6prm_set_hw_core_req(struct device *dev, uint32_t hw_block_id, bool
struct prm_cmd_request_hw_core *req;
gpr_device_t *gdev = prm->gdev;
uint32_t opcode, rsp_opcode;
+ bool lpr_req = (hw_block_id == Q6PRM_HW_LPR_VOTE);
if (enable) {
opcode = PRM_CMD_REQUEST_HW_RSC;
@@ -82,10 +89,13 @@ static int q6prm_set_hw_core_req(struct device *dev, uint32_t hw_block_id, bool
param_data->module_instance_id = GPR_PRM_MODULE_IID;
param_data->error_code = 0;
- param_data->param_id = PARAM_ID_RSC_HW_CORE;
+ param_data->param_id = lpr_req ? PARAM_ID_RSC_CPU_LPR : PARAM_ID_RSC_HW_CORE;
param_data->param_size = sizeof(*req) - APM_MODULE_PARAM_DATA_SIZE;
- req->hw_clk_id = hw_block_id;
+ if (lpr_req)
+ req->lpr_state = LPR_CPU_SS_SLEEP_DISABLE;
+ else
+ req->hw_clk_id = hw_block_id;
return q6prm_send_cmd_sync(prm, pkt, rsp_opcode);
}
diff --git a/sound/soc/qcom/qdsp6/q6prm.h b/sound/soc/qcom/qdsp6/q6prm.h
index a988a3208..bd5ee0c40 100644
--- a/sound/soc/qcom/qdsp6/q6prm.h
+++ b/sound/soc/qcom/qdsp6/q6prm.h
@@ -87,6 +87,7 @@
#define Q6PRM_LPASS_CLK_ROOT_DEFAULT 0
#define Q6PRM_HW_CORE_ID_LPASS 1
#define Q6PRM_HW_CORE_ID_DCODEC 2
+#define Q6PRM_HW_LPR_VOTE 3
int q6prm_set_lpass_clock(struct device *dev, int clk_id, int clk_attr,
int clk_root, unsigned int freq);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/4] arm64: dts: qcom: shikra-cqm-evk: Enable display and add ili7807s panel
From: Dmitry Baryshkov @ 2026-07-20 13:05 UTC (permalink / raw)
To: Arpit Saini
Cc: Konrad Dybcio, Nabige Aala, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <6c89ef9d-3551-4b92-904c-316dbcffcfbd@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 05:37:25PM +0530, Arpit Saini wrote:
> Hi Konrad,
>
> On 7/16/2026 11:21 PM, Konrad Dybcio wrote:
> > On 7/14/26 9:21 AM, Arpit Saini wrote:
> >> Hi Dmitry,Konrad
> >>
> >> On 7/10/2026 6:09 PM, Dmitry Baryshkov wrote:
> >>> On Fri, Jul 10, 2026 at 05:28:04PM +0530, Arpit Saini wrote:
> >>>> Hi Konrad,
> >>>>
> >>>> On 7/10/2026 2:31 PM, Arpit Saini wrote:
> >
> > [...]
> >
> >>>> Normally the backlight EN pin is controlled by a backlight driver.
> >>>>
> >>>> However, this panel uses MIPI DCS based backlight control with no
> >>>>
> >>>> separate backlight driver. Since there is no driver to assert gpio91,
> >>>>
> >>>> we control it via the panel's pinctrl default state..
> >>>>
> >>>> So this is platform specific pin , we need this to enable/disable
> >>>>
> >>>> the backlight.
> >>>
> >>> Handle it from the panel driver. Also please fix your editor to prevent
> >>> it from inserting extra empty lines.
> >>>
> >>
> >> Earlier I handled it through panel driver, but this GPIO is specific to our
> >> Qualcomm Daughter Card, it is not going to the panel connector.
> >
> > So is it an enable pin of a voltage regulator maybe? I'm having trouble
> > understanding how this is all tied together, given the panel driver
> > uses DCS commands to control the backlight status
> >
> > Konrad
>
> No, it is not a voltage regulator enable.
> GPIO91 (WLED_P1_EN) is the enable pin of the WLED driver IC on the Qualcomm daughter card.
> The WLED driver is a boost LED driver that powers the backlight LEDs.
> The backlight control works in two parts:
_that powers the backlight LEDs_.
So it is a power supply.
>
> 1. GPIO91 must be asserted to enable the WLED driver IC itself.
> 2. The panel's CABC output (a PWM signal) is connected to the WLED driver's PWM input
> and controls the actual brightness.
> This CABC output is driven by the DCS set_display_brightness command sent from the panel driver.
>
> So the DCS commands control brightness via the panel's PWM/CABC output,
> but the WLED driver IC needs to be enabled first via GPIO91.
>
> Since GPIO91 is on the Qualcomm daughter card and not on the panel connector.
>
> Dmitry suggested , it is not appropriate to model it in the panel binding.
> The current approach of asserting it via pinctrl default state in the board DTS keeps it board-specific.
>
> If you have a better suggestion for modelling this, I'm happy to follow your guidance.
>
> SoC (ITP Baseband Card)
> ├── GPIO91 (WLED_P1_EN) ─────────────────────────────────────┐
> │ │
> └── DSI ──────────────────────────────────────────────────┐ │
> │ │
> ┌──────────────────────────────────────────────────────────┼──┼──────────────────────────────────┐
> │ Qualcomm Display Daughter Card │ │ │
> │ │ │ │
> │ ┌─────────────────────────────────┐ │ │ ┌──────────────────────┐ │
> │ │ DLC DLC0697 Panel (ILI7807S) │◄────────────────────┘ │ │ WLED Driver IC │ │
> │ │ │ | │ │ │
> │ │ DCS set_display_brightness() │ └──►│ EN │ │
> │ │ │ │ │ │ │
> │ │ ▼ │ │ │ │
> │ │ CABC output ───────────────────┼───────────────────────────►│ PWM │ │
> │ │ │ │ │ │
> │ │ │ │ LED outputs ────────┼──► Backlight LEDs
> │ └─────────────────────────────────┘ └──────────────────────┘ │
> │ │
> └────────────────────────────────────────────────────────────────────────────────────────────────┘
This is a nice diagram, but it shows backlight LEDs as something
completely separate. Usually they are a part of the panel. Are they not
in this case?
I'd be more interested in a different representation of the information.
What are the _actual_ panel inputs? Decribe those (and only those) in
the panel bindings.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 6/6] arm64: dts: qcom: Add device tree for Nord RRD board
From: Shawn Guo @ 2026-07-20 13:02 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, devicetree,
linux-arm-msm, linux-kernel, Bartosz Golaszewski
In-Reply-To: <b522c9b4-4944-4fb2-94f9-bd2553690901@oss.qualcomm.com>
On Thu, Jul 16, 2026 at 07:17:14PM +0200, Konrad Dybcio wrote:
> On 7/16/26 4:26 PM, Shawn Guo wrote:
> > Add initial device tree for the Qualcomm Dragonwing IQ10 RRD (Robotics
> > Reference Design) board, which is built on Nord Embedded variant. Enable
> > the debug UART, UFS storage, PMICs, I2C and SPI.
> >
> > Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> > ---
>
> [...]
>
> > + /* PMIC A - Kobra_MM (PMM8650AU) - SID 0x0, Bus E0 */
>
> This comment is very useful
>
> > + regulators-0 {
> > + compatible = "qcom,pmm8654au-rpmh-regulators";
> > + qcom,pmic-id = "A_E0";
> > +
> > + /* LDO Regulators */
>
> This is much less so
>
> [...]
Indeed! Will drop.
> > + vreg_l7a_1p2: ldo7 {
> > + regulator-name = "vreg_l7a_1p2";
> > + regulator-min-microvolt = <1200000>;
> > + regulator-max-microvolt = <1200000>;
> > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + regulator-allow-set-load;
>
> You made a lot of the regulators always-/boot-on - are you sure about
> each one of them?
As Bartosz replied, we will drop always-on/boot-on from vreg_l3e_1p8 and
vreg_l2i_1p2 regulator.
> > + regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
> > + RPMH_REGULATOR_MODE_HPM>;
>
> It's commonplace to restrict regulators to HPM only because not all of
> the drivers that should be voting on desired load actually do it. Do
> you have any intermittent failures, particularly around PHYs?
We haven't seen failures like that. But to be on the side side, I would
rather follow your suggest to restrict UFS PHY regulators to be HPM only.
>
> [...]
>
>
> > +&i2c7 {
> > + clock-frequency = <400000>;
> > +
> > + status = "okay";
>
> It's commonplace to add comments like:
>
> /* Type-C controller @ 0x15 */
We would like to drop untested/unused I2C buses/devices instead.
>
> Otherwise this lgtm
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Thank you, Konrad!
Shawn
^ permalink raw reply
* AW: [PATCH 3/4] drm/rockchip: lvds: add RK3568 support
From: Jakob Loe @ 2026-07-20 12:20 UTC (permalink / raw)
To: 'Alibek Omarov', 'Rok Markovic'
Cc: 'Heiko Stuebner', 'Sandy Huang',
'Andy Yan', 'Maarten Lankhorst',
'Maxime Ripard', 'Thomas Zimmermann',
'David Airlie', 'Simona Vetter',
'Rob Herring', 'Krzysztof Kozlowski',
'Conor Dooley', dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <CAKyg=SV2-81VFgr+Tq=-Si5EO-86MA+ZFoQ+DX1fEYdnnLYJng@mail.gmail.com>
Hello!
Nice to see this is still being used.
I can confirm that this actually works and outputs fine LVDS on a RK3566. Also reliably so far...
Any questions, I will see what I can help.
All the best
Jakob
-----Ursprüngliche Nachricht-----
Von: Alibek Omarov <a1ba.omarov@gmail.com>
Gesendet: Montag, 20. Juli 2026 07:39
An: Rok Markovic <rok@kanardia.eu>
Cc: Heiko Stuebner <heiko@sntech.de>; Sandy Huang <hjc@rock-chips.com>; Andy Yan <andy.yan@rock-chips.com>; Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>; David Airlie <airlied@gmail.com>; Simona Vetter <simona@ffwll.ch>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; dri-devel@lists.freedesktop.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-rockchip@lists.infradead.org; linux-kernel@vger.kernel.org; Jakob Loeschke <jakob@loe-web.de>
Betreff: Re: [PATCH 3/4] drm/rockchip: lvds: add RK3568 support
> Based on Alibek Omarov's earlier posting [1], with the changes below.
Hi, I'm Alibek Omarov and thanks for picking up my patches. I didn't had time to finish them and these days I don't work on hardware that uses any of Rockchip SoCs. However, if I'm not wrong, it's still used in production and I had report from Jakob Loeschke (added in CC) who confirmed it worked in their setup as well.
Thanks.
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8192-asurada: Disable mmc1 on Spherion
From: AngeloGioacchino Del Regno @ 2026-07-20 12:58 UTC (permalink / raw)
To: Matthias Brugger, Chen-Yu Tsai
Cc: linux-mediatek, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260720092759.1831105-1-wenst@chromium.org>
On Mon, 20 Jul 2026 17:27:57 +0800, Chen-Yu Tsai wrote:
> Spherion does not have an micro SD card slot.
>
> Disable mmc1.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8192-asurada: Disable mmc1 on Spherion
commit: 934cccd2c6795a20d04bd470ec7eb3151950fbfc
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v6 01/14] media: mediatek: vcodec: support vcp architecture
From: Nicolas Dufresne @ 2026-07-20 12:57 UTC (permalink / raw)
To: Kyrie Wu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Ricardo Ribalda, Kees Cook, Hans Verkuil, Fei Shao, Haoxiang Li,
Chen-Yu Tsai, Laurent Pinchart, Tomasz Figa, Sebastian Fricke,
Philipp Zabel, Benjamin Gaignard, Qianfeng Rong, Irui Wang,
Jacopo Mondi, Fan Wu, linux-media, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: Sakari Ailus
In-Reply-To: <20260720012056.1026551-2-kyrie.wu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
Hi,
Le lundi 20 juillet 2026 à 09:20 +0800, Kyrie Wu a écrit :
> Some platforms expose the video codec through the VCP coprocessor.
> Use the VCP architecture when the VCP coprocessor is found.
>
> Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> ---
> drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h | 1 +
> .../platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> index 300363a40..c1642fb09 100644
> --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> @@ -14,6 +14,7 @@ struct mtk_vcodec_enc_dev;
> enum mtk_vcodec_fw_type {
> VPU,
> SCP,
> + VCP,
> };
>
> enum mtk_vcodec_fw_use {
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> index e936ed8df..d220b645e 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> @@ -379,6 +379,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
> &rproc_phandle)) {
> fw_type = SCP;
> + } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vcp",
> + &rproc_phandle)) {
> + fw_type = VCP;
I know I gave an rb a while ago, but then we reviewed the 8189 code, and we
underlined that this makes little sense, and that fw_type should simply be set
in the pdata. Same applies to mtk_vcodec_dec_get_chip_name(), the chip "name",
or integer form of, is clearly a 1 to 1 match for pdata.
Nicolas
> } else {
> dev_dbg(&pdev->dev, "Could not get vdec IPI device");
> return -ENODEV;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Manivannan Sadhasivam @ 2026-07-20 12:53 UTC (permalink / raw)
To: Rob Herring, Bjorn Helgaas, Chen-Yu Tsai
Cc: Matthias Brugger, AngeloGioacchino Del Regno, linux-pci,
linux-mediatek, devicetree, linux-arm-kernel, linux-kernel,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260720092116.1823562-1-wenst@chromium.org>
On Mon, 20 Jul 2026 17:21:15 +0800, Chen-Yu Tsai wrote:
> On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> controller memory access could be limited to a small region by the
> firmware configuring a memory protection unit. This memory region
> must be assigned to the PCIe controller so that the OS knows to
> use that region. Otherwise PCIe devices would not work properly.
>
> Allow the memory-region property with one item pointing to a
> restricted DMA buffer.
>
> [...]
Applied, thanks!
[1/1] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
commit: 7e38b7b0e0e582024e97289a3b63c201f226124d
Best regards,
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Manivannan Sadhasivam @ 2026-07-20 12:51 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Bjorn Helgaas, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pci, linux-mediatek, devicetree,
linux-arm-kernel, linux-kernel, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260720092116.1823562-1-wenst@chromium.org>
On Mon, Jul 20, 2026 at 05:21:15PM +0800, Chen-Yu Tsai wrote:
> On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> controller memory access could be limited to a small region by the
> firmware configuring a memory protection unit. This memory region
> must be assigned to the PCIe controller so that the OS knows to
> use that region. Otherwise PCIe devices would not work properly.
>
> Allow the memory-region property with one item pointing to a
> restricted DMA buffer.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Can we get this merged for v7.2? A matching device tree change was
> already merged in v7.2-rc1.
>
This is not a bug fix, so not sure if this patch can be applied for 7.2. But DTS
change getting applied before the binding change was a mistake first of all.
- Mani
>
> Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> index fbc0378392d4..b88717dec1fa 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> @@ -116,6 +116,10 @@ properties:
> power-domains:
> maxItems: 1
>
> + memory-region:
> + maxItems: 1
> + description: phandle to restricted DMA buffer
> +
> mediatek,pbus-csr:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> --
> 2.55.0.229.g6434b31f56-goog
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: mtk-efuse: add support for 32-bit aligned reads
From: AngeloGioacchino Del Regno @ 2026-07-20 12:48 UTC (permalink / raw)
To: rva333, Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260715-6572-nvmem-v1-2-9c13be99d077@protonmail.com>
On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> Some MediaTek SoCs, such as mt6572, don't support 8-bit reads, leading
> to zeroes or garbage data. 32-bit aligned reads must be used instead.
>
> Introduce an 'needs_aligned_read' field to the platform data to enforce
> 32-bit aligned register access. All reads will be performed by reading
> 4-byte words and masking them.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
You're effectively overriding the entire mtk_reg_read function when
needs_aligned_read==true... so.... (check below)
> ---
> drivers/nvmem/mtk-efuse.c | 31 ++++++++++++++++++++++++++++---
> 1 file changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index af953e1d9230..1462f2760818 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -4,6 +4,7 @@
> * Author: Andrew-CT Chen <andrew-ct.chen@mediatek.com>
> */
>
> +#include <linux/align.h>
> #include <linux/device.h>
> #include <linux/module.h>
> #include <linux/mod_devicetable.h>
> @@ -14,10 +15,12 @@
>
> struct mtk_efuse_pdata {
> bool uses_post_processing;
> + bool needs_aligned_read;
> };
>
> struct mtk_efuse_priv {
> void __iomem *base;
> + const struct mtk_efuse_pdata *data;
...instead of adding pdata here...
> };
>
> static int mtk_reg_read(void *context,
> @@ -28,6 +31,26 @@ static int mtk_reg_read(void *context,
> u8 *val = _val;
> int i;
>
> + if (priv->data->needs_aligned_read) {
> + u32 pos, shift, val32;
> +
> + for (i = 0; i < bytes; i++, val++) {
> + pos = reg + i;
> +
> + /*
> + * Read on 32-bit word boundary or if it's the first
> + * iteration
> + */
> + if (i == 0 || IS_ALIGNED(pos, 4))
> + val32 = readl(priv->base + (pos & ~3));
> +
> + shift = (pos & 3) * 8;
> + *val = (val32 >> shift) & 0xff;
> + }
> +
> + return 0;
> + }
> +
> for (i = 0; i < bytes; i++, val++)
> *val = readb(addr + i);
>
> @@ -67,7 +90,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> struct nvmem_device *nvmem;
> struct nvmem_config econfig = {};
> struct mtk_efuse_priv *priv;
> - const struct mtk_efuse_pdata *pdata;
> struct platform_device *socinfo;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> @@ -78,7 +100,8 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
>
> - pdata = device_get_match_data(dev);
> + priv->data = device_get_match_data(dev);
> +
...and instead of changing a bunch of lines here...
> econfig.add_legacy_fixed_of_cells = true;
> econfig.stride = 1;
> econfig.word_size = 1;
it's easier at this point if you simply do
if (pdata->needs_aligned_read) {
econfig.stride = 4;
econfig.reg_read = mtk_reg_read_aligned;
} else {
econfig.stride = 1;
econfig.reg_read = mtk_reg_read;
}
and you avoid touching mtk_reg_read entirely.
Though it's not going to be used in any performance path, that's also faster as
there's one less branch per execution.
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: nvmem: mediatek: efuse: add mt6572
From: AngeloGioacchino Del Regno @ 2026-07-20 12:48 UTC (permalink / raw)
To: rva333, Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260715-6572-nvmem-v1-1-9c13be99d077@protonmail.com>
On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> Add a compatible string for the mt6572 SoC efuse controller.
>
Please, avoid adding this to the list of compatibles that need you do specify
"mediatek,mt6572-efuse", "mediatek,efuse";
The "generic" compatible should disappear.. and plus, the MT6572 SoC seems to
be pretty special, as you had to implement aligned read just for that.
This won't be the only SoC as well, as probably all of the legacy one from the
same era will be affected... so please, add it as a const so that you can have
a devicetree with an efuse node declaring
compatible = "mediatek,mt6572-efuse";
Cheers,
Angelo
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> index f9323b3ecfc8..269e2b09f5c8 100644
> --- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> @@ -44,6 +44,7 @@ properties:
>
> - items:
> - enum:
> + - mediatek,mt6572-efuse
> - mediatek,mt7622-efuse
> - mediatek,mt7623-efuse
> - mediatek,mt7981-efuse
>
^ permalink raw reply
* Re: [PATCH 3/3] nvmem: mtk-efuse: add mt6572 support
From: AngeloGioacchino Del Regno @ 2026-07-20 12:48 UTC (permalink / raw)
To: rva333, Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260715-6572-nvmem-v1-3-9c13be99d077@protonmail.com>
On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> Add a platform data struct for the efuse controller.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> drivers/nvmem/mtk-efuse.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 1462f2760818..a79434608465 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -124,6 +124,11 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_efuse_pdata mtk_mt6572_efuse_pdata = {
> + .uses_post_processing = false,
Are you sure this SoC (or any other compatible with it) doesn't have any GPU speed
binning?
If you're really sure
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> + .needs_aligned_read = true,
> +};
> +
> static const struct mtk_efuse_pdata mtk_mt8186_efuse_pdata = {
> .uses_post_processing = true,
> .needs_aligned_read = false,
> @@ -135,6 +140,7 @@ static const struct mtk_efuse_pdata mtk_efuse_pdata = {
> };
>
> static const struct of_device_id mtk_efuse_of_match[] = {
> + { .compatible = "mediatek,mt6572-efuse", .data = &mtk_mt6572_efuse_pdata },
> { .compatible = "mediatek,mt8173-efuse", .data = &mtk_efuse_pdata },
> { .compatible = "mediatek,mt8186-efuse", .data = &mtk_mt8186_efuse_pdata },
> { .compatible = "mediatek,efuse", .data = &mtk_efuse_pdata },
>
^ permalink raw reply
* Re: [PATCH 2/5] drm: panel: jd9365da: Add prepare_prev_first flag to drm_panel
From: Neil Armstrong @ 2026-07-20 12:41 UTC (permalink / raw)
To: Marc-Olivier Champagne, Jagan Teki, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hugo Villeneuve, dri-devel, devicetree, linux-kernel,
Jerome Oufella, Felix Boucher, Quentin Lehoux
In-Reply-To: <20260708213500.1867092-3-marc-olivier.champagne@savoirfairelinux.com>
On 7/8/26 23:34, Marc-Olivier Champagne wrote:
> The DSI host must be enabled for the panel to be initialized in
> prepare(). Set the prepare_prev_first flag to guarantee this.
> This fixes the panel operation on Renesas RZ/G2LC SoC DSI host.
>
> Suggested-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> Signed-off-by: Marc-Olivier Champagne <marc-olivier.champagne@savoirfairelinux.com>
> ---
> drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> index 1ef0c937863a..a79dc8f8d5af 100644
> --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> @@ -2993,6 +2993,8 @@ static int jadard_dsi_probe(struct mipi_dsi_device *dsi)
> return dev_err_probe(&dsi->dev, PTR_ERR(jadard->vccio),
> "failed to get vccio regulator\n");
>
> + jadard->panel.prepare_prev_first = true;
> +
> ret = of_drm_get_panel_orientation(dev->of_node, &jadard->orientation);
> if (ret < 0)
> return dev_err_probe(dev, ret, "failed to get orientation\n");
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH 1/5] drm: panel: jd9365da: Enable LPM mode
From: Neil Armstrong @ 2026-07-20 12:40 UTC (permalink / raw)
To: Marc-Olivier Champagne, Jagan Teki, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hugo Villeneuve, dri-devel, devicetree, linux-kernel,
Jerome Oufella, Felix Boucher, Quentin Lehoux
In-Reply-To: <20260708213500.1867092-2-marc-olivier.champagne@savoirfairelinux.com>
On 7/8/26 23:34, Marc-Olivier Champagne wrote:
> The JD9365DA-H3 uses DSI LPM for command transmissions, make sure
> this is configured correctly in the DSI mode flags.
>
> Suggested-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> Signed-off-by: Marc-Olivier Champagne <marc-olivier.champagne@savoirfairelinux.com>
> ---
> drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> index f6b04de1182e..1ef0c937863a 100644
> --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> @@ -2950,7 +2950,8 @@ static int jadard_dsi_probe(struct mipi_dsi_device *dsi)
> else
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> MIPI_DSI_MODE_VIDEO_BURST |
> - MIPI_DSI_MODE_NO_EOT_PACKET;
> + MIPI_DSI_MODE_NO_EOT_PACKET |
> + MIPI_DSI_MODE_LPM;
>
> dsi->format = desc->format;
> dsi->lanes = desc->lanes;
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH V2] scsi: ufs: dt-bindings: Document the Maili UFS Controller
From: Manivannan Sadhasivam @ 2026-07-20 12:35 UTC (permalink / raw)
To: Nitin Rawat
Cc: krzk+dt, robh, andersson, alim.akhtar, bvanassche, avri.altman,
conor+dt, linux-arm-msm, linux-kernel, devicetree, linux-scsi
In-Reply-To: <20260719195833.136543-1-nitin.rawat@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 01:28:33AM +0530, Nitin Rawat wrote:
> Document the UFS Controller on Maili SoC.
>
> Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> Change from v1:
> 1. Addressed Krzysztof's comment to update 'qcom,maili-ufshc'
> to the allOf condition required for MCQ targets.
> ---
> Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
> index b441f0d26081..d03295806657 100644
> --- a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
> +++ b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
> @@ -18,6 +18,7 @@ select:
> - qcom,eliza-ufshc
> - qcom,hawi-ufshc
> - qcom,kaanapali-ufshc
> + - qcom,maili-ufshc
> - qcom,nord-ufshc
> - qcom,sm8650-ufshc
> - qcom,sm8750-ufshc
> @@ -31,6 +32,7 @@ properties:
> - qcom,eliza-ufshc
> - qcom,hawi-ufshc
> - qcom,kaanapali-ufshc
> + - qcom,maili-ufshc
> - qcom,nord-ufshc
> - qcom,sm8650-ufshc
> - qcom,sm8750-ufshc
> @@ -78,6 +80,7 @@ allOf:
> contains:
> enum:
> - qcom,eliza-ufshc
> + - qcom,maili-ufshc
> - qcom,nord-ufshc
> then:
> properties:
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Neil Armstrong @ 2026-07-20 12:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov, Jun Yan
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
Hi,
On Wed, 24 Jun 2026 21:56:40 +0800, Jun Yan wrote:
> - Disable nfc node by default ahead of nand_rb0 pin addition.
> - Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
> - Disable pcie_phy by default to suppress probe warning.
> - Re-enable pcie_phy on S400 board to preserve PCIe functionality.
> - Enable mipi_pcie_analog_dphy for PCIe on S400 board.
>
> Changes in v4:
> - Add patch to enable mipi_pcie_analog_dphy for PCIe on S400 board.
> - Link to v3:
> https://lore.kernel.org/all/20260617082239.645562-1-jerrysteve1101@gmail.com/
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/arm64-dt)
[1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
https://git.kernel.org/amlogic/c/77c63ef3be3972eb3d8aac2dd36f349d78620b0d
[2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
https://git.kernel.org/amlogic/c/45eb76f9ab6854f79690d56d04df227429a536b8
[3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
https://git.kernel.org/amlogic/c/25ab968f7d27f46927658150bf466cac856e4f4f
[4/4] arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
https://git.kernel.org/amlogic/c/7f1d0cc86cb70fa550163b6f70fd1d484c03218e
These changes has been applied on the intermediate git tree [1].
The v7.3/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: Correct indentation and whitespace
From: Neil Armstrong @ 2026-07-20 12:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260706093508.273968-2-krzysztof.kozlowski@oss.qualcomm.com>
Hi,
On Mon, 06 Jul 2026 11:35:09 +0200, Krzysztof Kozlowski wrote:
> Correct spaces or mix of tabs+spaces into proper tab-indented lines and
> remove other whitespace violations. No functional impact (same DTB).
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/arm64-dt)
[1/1] arm64: dts: amlogic: Correct indentation and whitespace
https://git.kernel.org/amlogic/c/6c4345eb714f094ea579e3234cafed9f8c0634f8
These changes has been applied on the intermediate git tree [1].
The v7.3/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v3 2/4] media: synopsys: hdmirx: add HDMI audio capture support
From: Igor Paunovic @ 2026-07-20 12:30 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Mauro Carvalho Chehab, Sebastian Reichel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <25922edc-4ff1-4d28-9a64-2c28b2b690cb@collabora.com>
Hi Dmitry,
Great to hear it works on the 5B -- thanks for testing!
Agreed on the -EBUSY guard, done in my tree exactly as you wrote it.
It also supersedes the suspend cancel/re-arm I had queued from the
bot review: with suspend refused while audio_streaming is set, the
worker can never be armed at suspend time, so those hunks are
dropped.
v4 follows shortly with this plus Sebastian's dts restructuring
(shared disabled-by-default card in rk3588-extra.dtsi, renamed to
"RK3588 HDMI-IN") and Krzysztof's binding comments (dai-common.yaml
reference + unevaluatedProperties).
Igor
On Mon, Jul 20, 2026 at 3:43 AM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> On 7/18/26 11:57, Igor Paunovic wrote:
> > The Synopsys DesignWare HDMI RX controller extracts the audio stream
> > embedded in the incoming HDMI signal and feeds it to an on-SoC I2S
> > controller. Expose it as an ALSA capture device by registering the
> > generic hdmi-codec as a child of the controller, so that a
> > simple-audio-card in the device tree can bind the HDMI RX audio DAI.
> >
> > The sample rate is recovered from the ACR N/CTS values together with the
> > measured TMDS character rate. A periodic worker keeps the local audio
> > reference clock locked to the source by nudging it in small ppm steps to
> > hold the audio FIFO fill level near its target, which avoids FIFO
> > under/overflow and the resulting dropped samples.
> >
> > Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
> > ---
> > Changes in v3:
> > - restore the v1 audio teardown in remove(): audio_shutdown() already
> > stops the worker when the stream closes, so the extra flag clear
> > and trailing cancel added in v2 were redundant (Dmitry Osipenko)
> > - rename the ACR read locals and add a comment documenting the
> > register byte packing
> > - drop the get_dai_id stub so OF-graph cards resolve the DAI index
> > from the reg property
> >
> > Changes in v2:
> > - register the S/PDIF DAI so the indexes match the binding and reject
> > it with -EOPNOTSUPP until wired up (Sebastian Reichel)
> > - use platform_device_register_data() and drop the fixed 32-bit DMA
> > mask (Dmitry Osipenko)
> > - don't leave an ERR_PTR in audio_pdev on registration failure
> > - fix teardown ordering in remove()
> > - stop the worker before reprogramming shared state in hw_params()
> > - look up the "audio" clock by name instead of indexing clks[1]
> > - keep the worker on system_unbound_wq when re-arming
> >
> > .../platform/synopsys/hdmirx/snps_hdmirx.c | 271 ++++++++++++++++++
> > .../platform/synopsys/hdmirx/snps_hdmirx.h | 8 +
> > 2 files changed, 279 insertions(+)
>
> Works well on 5b, thanks. Only one additional review comment:
>
> Please update hdmirx_suspend() to return -EBUSY if audio_streaming=true.
>
> ```
> static __maybe_unused int hdmirx_suspend(struct device *dev)
> {
> struct snps_hdmirx_dev *hdmirx_dev = dev_get_drvdata(dev);
>
> if (READ_ONCE((hdmirx_dev->audio_streaming)))
> return -EBUSY;
> ```
>
> --
> Best regards,
> Dmitry
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: qcom: Add PMIC thermal support for Shikra IQ2390S SoM platform
From: Rakesh Kota @ 2026-07-20 12:23 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Jishnu Prakash, devicetree, robh, conor+dt
In-Reply-To: <20260715075839.B05821F000E9@smtp.kernel.org>
On Wed, Jul 15, 2026 at 07:58:39AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Mismatched PMIC ADC channels and pinctrl configurations for thermistors.
> --
>
> --- Patch [4]: [PATCH v4 4/4] arm64: dts: qcom: Add PMIC thermal support for Shikra IQ2390S SoM platform ---
> commit 5e80ce0d3c9c4dc567c3d3d335a508d11f309e50
> Author: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
>
> arm64: dts: qcom: Add PMIC thermal support for Shikra IQ2390S SoM platform
>
> This commit adds ADC channels for system thermistors used for thermal
> mitigation. It includes ADC_TM nodes for PA, quiet, and MSM thermistors,
> along with corresponding thermal zones.
>
> > diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
> > index 73945bf42112d..9ab0b44b00bed 100644
> > --- a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
>
> [ ... ]
>
> > +&pm8150_adc {
> > + pinctrl-0 = <&pm8150_adc_gpio2_default>, <&pm8150_adc_gpio3_default>;
> > + pinctrl-names = "default";
> > +
>
> [ ... ]
>
> > + channel@52 {
> > + reg = <ADC5_GPIO1_100K_PU>;
> > + label = "gnss_therm";
> > + qcom,ratiometric;
> > + qcom,hw-settle-time = <200>;
> > + qcom,pre-scaling = <1 1>;
> > + };
> > +
> > + channel@55 {
> > + reg = <ADC5_GPIO4_100K_PU>;
> > + label = "pa_therm";
> > + qcom,ratiometric;
> > + qcom,hw-settle-time = <200>;
> > + qcom,pre-scaling = <1 1>;
> > + };
> > +};
>
> [Severity: High]
> Is there a mismatch between the pinctrl configurations and the ADC channels
> being used?
>
> The pinctrl-0 property specifies configurations for gpio2 and gpio3, but the
> ADC channels instruct the hardware to read from ADC5_GPIO1 and ADC5_GPIO4.
>
> Could this result in the gnss_therm and pa_therm thermal zones reading
> garbage data since they point to unconfigured PMIC GPIOs?
>
> If the unconfigured pins float to a voltage that translates to a temperature
> above the 125°C trip point, it might cause spurious system shutdowns or
> unnecessary throttling.
>
The pinctrl state names (gpio2, gpio3) are symbolic labels only and vary
between PMICs — they carry no functional meaning to the hardware or
driver. The ADC channel selection is determined solely by the reg value
(ADC5_GPIO1_100K_PU, ADC5_GPIO4_100K_PU), which directly encodes the
AMUX channel the hardware reads from. There is no mismatch — no garbage
data or spurious shutdowns are expected.
> [ ... ]
>
> > &pm8150_gpios {
> > + pm8150_adc_gpio2_default: pm8150-adc-gpio2-state {
> > + pins = "gpio2";
> > + function = PMIC_GPIO_FUNC_NORMAL;
> > + bias-high-impedance;
> > + };
> > +
> > + pm8150_adc_gpio3_default: pm8150-adc-gpio3-state {
> > + pins = "gpio3";
> > + function = PMIC_GPIO_FUNC_NORMAL;
> > + bias-high-impedance;
> > + };
> > +
>
> [Severity: High]
> Because these configurations explicitly target gpio2 and gpio3 instead of the
> pins actually used by the ADC, does forcing them into high-impedance mode
> risk breaking or interfering with whatever hardware is actually connected
> to them?
>
The pinctrl state names are symbolic labels only and vary between PMICs
— the ADC channel is determined solely by the reg value
(ADC5_GPIO3_100K_PU, ADC5_GPIO4_100K_PU). No mismatch here.
regards
Rakesh Kota
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260715-shikra_adc_support-v4-0-5e07b6d21429@oss.qualcomm.com?part=4
^ permalink raw reply
* RE: [PATCH v10 3/4] reset: cix: add sky1 audss auxiliary reset driver
From: Joakim Zhang @ 2026-07-20 12:17 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <0d0c7befafd2e60b8887245f4e60a504704014dc.camel@pengutronix.de>
Hello Philipp,
> -----Original Message-----
> From: Philipp Zabel <p.zabel@pengutronix.de>
> Sent: Monday, July 20, 2026 3:20 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org
> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v10 3/4] reset: cix: add sky1 audss auxiliary reset driver
>
> EXTERNAL EMAIL
>
> CAUTION: Suspicious Email from unusual domain.
>
> On Mo, 2026-07-20 at 13:15 +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > Add an auxiliary reset controller driver for the AUDSS CRU. Sixteen
> > software reset lines for audio subsystem peripherals are controlled
> > through one register in the CRU register map.
> >
> > The driver is created by the AUDSS clock platform driver and registers
> > the reset controller on the CRU device node.
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > drivers/reset/Kconfig | 13 +++
> > drivers/reset/Makefile | 1 +
> > drivers/reset/reset-sky1-audss.c | 137
> > +++++++++++++++++++++++++++++++
> > 3 files changed, 151 insertions(+)
> > create mode 100644 drivers/reset/reset-sky1-audss.c
> >
> > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> > d009eb0849a3..b19e719f2abe 100644
> > --- a/drivers/reset/Kconfig
> > +++ b/drivers/reset/Kconfig
> > @@ -300,6 +300,19 @@ config RESET_SKY1
> > help
> > This enables the reset controller for Cix Sky1.
> >
> > +config RESET_SKY1_AUDSS
> > + tristate "Cix Sky1 Audio Subsystem reset controller"
> > + depends on ARCH_CIX || COMPILE_TEST
> > + select AUXILIARY_BUS
> > + default CLK_SKY1_AUDSS
> > + help
> > + Support for block-level software reset lines in the Cix Sky1
> > + Audio Subsystem (AUDSS) Clock and Reset Unit. Sixteen reset
> > + outputs for audio peripherals are controlled through the CRU
> > + register map. The driver binds as an auxiliary device from
> > + the AUDSS clock driver. Say M or Y here if you want to build
> > + this driver.
> > +
> > config RESET_SOCFPGA
> > bool "SoCFPGA Reset Driver" if COMPILE_TEST && (!ARM
> || !ARCH_INTEL_SOCFPGA)
> > default ARM && ARCH_INTEL_SOCFPGA diff --git
> > a/drivers/reset/Makefile b/drivers/reset/Makefile index
> > 3e52569bd276..e81407ea3e29 100644
> > --- a/drivers/reset/Makefile
> > +++ b/drivers/reset/Makefile
> > @@ -39,6 +39,7 @@ obj-$(CONFIG_RESET_RZV2H_USB2PHY) +=
> > reset-rzv2h-usb2phy.o
> > obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
> > obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> > obj-$(CONFIG_RESET_SKY1) += reset-sky1.o
> > +obj-$(CONFIG_RESET_SKY1_AUDSS) += reset-sky1-audss.o
> > obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
> > obj-$(CONFIG_RESET_SUNPLUS) += reset-sunplus.o
> > obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o diff --git
> > a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> > new file mode 100644
> > index 000000000000..d31d80e1251a
> > --- /dev/null
> > +++ b/drivers/reset/reset-sky1-audss.c
> > @@ -0,0 +1,137 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Cix Sky1 Audio Subsystem reset controller driver
> > + *
> > + * Copyright 2026 Cix Technology Group Co., Ltd.
> > + */
> > +
> > +#include <dt-bindings/reset/cix,sky1-audss-cru.h>
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
>
> What is this used for?
Nothing; will drop it.
> > +#include <linux/regmap.h>
> > +#include <linux/reset-controller.h>
> > +
> > +#define SKY1_RESET_SLEEP_MIN_US 50
> > +#define SKY1_RESET_SLEEP_MAX_US 100
>
> Is this delay compatible with all possible modules being reset?
>
> Are min and max from a spec or is this just some safe value?
> Maybe you could only define the _MIN_US and use fsleep() below.
There is no per-block reset timing in the TRM for AUDSS SW_RST; 50 us
is a conservative safe delay. Happy to switch to fsleep(SKY1_RESET_SLEEP_MIN_US)
and drop MAX.
> > +
> > +#define AUDSS_SW_RST 0x78
> > +
> > +struct sky1_audss_reset_map {
> > + unsigned int offset;
> > + unsigned int mask;
> > +};
> > +
> > +struct sky1_audss_reset {
> > + struct reset_controller_dev rcdev;
> > + struct regmap *regmap;
> > + const struct sky1_audss_reset_map *map; };
> > +
> > +static const struct sky1_audss_reset_map sky1_audss_reset_map[] = {
> > + [AUDSS_I2S0_SW_RST] = { AUDSS_SW_RST, BIT(0) },
> > + [AUDSS_I2S1_SW_RST] = { AUDSS_SW_RST, BIT(1) },
> > + [AUDSS_I2S2_SW_RST] = { AUDSS_SW_RST, BIT(2) },
> > + [AUDSS_I2S3_SW_RST] = { AUDSS_SW_RST, BIT(3) },
> > + [AUDSS_I2S4_SW_RST] = { AUDSS_SW_RST, BIT(4) },
> > + [AUDSS_I2S5_SW_RST] = { AUDSS_SW_RST, BIT(5) },
> > + [AUDSS_I2S6_SW_RST] = { AUDSS_SW_RST, BIT(6) },
> > + [AUDSS_I2S7_SW_RST] = { AUDSS_SW_RST, BIT(7) },
> > + [AUDSS_I2S8_SW_RST] = { AUDSS_SW_RST, BIT(8) },
> > + [AUDSS_I2S9_SW_RST] = { AUDSS_SW_RST, BIT(9) },
> > + [AUDSS_WDT_SW_RST] = { AUDSS_SW_RST, BIT(10) },
> > + [AUDSS_TIMER_SW_RST] = { AUDSS_SW_RST, BIT(11) },
> > + [AUDSS_MB0_SW_RST] = { AUDSS_SW_RST, BIT(12) },
> > + [AUDSS_MB1_SW_RST] = { AUDSS_SW_RST, BIT(13) },
> > + [AUDSS_HDA_SW_RST] = { AUDSS_SW_RST, BIT(14) },
> > + [AUDSS_DMAC_SW_RST] = { AUDSS_SW_RST, BIT(15) },
> > +};
> > +
> > +static struct sky1_audss_reset *to_sky1_audss_reset(struct
> > +reset_controller_dev *rcdev) {
> > + return container_of(rcdev, struct sky1_audss_reset, rcdev); }
> > +
> > +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> > + unsigned long id, bool assert) {
> > + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> > + const struct sky1_audss_reset_map *signal = &priv->map[id];
> > + unsigned int value = assert ? 0 : signal->mask;
> > +
> > + return regmap_update_bits(priv->regmap, signal->offset,
> > + signal->mask, value);
>
> Consider using regmap_assign_bits() instead.
OK
> > +}
> > +
> > +static int sky1_audss_reset_assert(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + int ret;
> > +
> > + ret = sky1_audss_reset_set(rcdev, id, true);
> > + if (ret)
> > + return ret;
> > +
> > + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> > + return 0;
> > +}
> > +
> > +static int sky1_audss_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + int ret;
> > +
> > + ret = sky1_audss_reset_set(rcdev, id, false);
> > + if (ret)
> > + return ret;
> > +
> > + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
>
> This is the same in both assert and deassert. You could move it into the helper
> function.
Agreed. Will move the delay into sky1_audss_reset_set() and keep
assert/deassert as thin wrappers.
Thanks,
Joakim
^ permalink raw reply
* Re: [External] [PATCH v5 4/8] riscv_cbqri: Add capacity controller probe and allocation device ops
From: yunhui cui @ 2026-07-20 12:12 UTC (permalink / raw)
To: Drew Fustini
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, Zhanpeng Zhang, linux-kernel,
linux-riscv, x86, devicetree, linux-rt-devel, linux-doc
In-Reply-To: <20260714-dfustini-atl-sc-cbqri-dt-v5-4-b0ae7e9c932e@kernel.org>
Hi Drew,
On Wed, Jul 15, 2026 at 8:24 AM Drew Fustini <fustini@kernel.org> wrote:
>
> Add support for the RISC-V CBQRI capacity controller. A platform driver
> passes a cbqri_controller_info descriptor together with the cache level
> to riscv_cbqri_register_cc_dt(), which probes the controller and adds it
> to the controller list.
>
> Assisted-by: Claude:claude-opus-4-8
> Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Drew Fustini <fustini@kernel.org>
> ---
> MAINTAINERS | 3 +
> drivers/resctrl/Kconfig | 13 +
> drivers/resctrl/Makefile | 3 +
> drivers/resctrl/cbqri_devices.c | 563 +++++++++++++++++++++++++++++++++++++++
> drivers/resctrl/cbqri_internal.h | 122 +++++++++
> include/linux/riscv_cbqri.h | 45 ++++
> 6 files changed, 749 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a0a4b41f02c5..064a6ae2823e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23365,6 +23365,9 @@ L: linux-riscv@lists.infradead.org
> S: Supported
> F: arch/riscv/include/asm/qos.h
> F: arch/riscv/kernel/qos.c
> +F: drivers/resctrl/cbqri_devices.c
> +F: drivers/resctrl/cbqri_internal.h
> +F: include/linux/riscv_cbqri.h
>
> RISC-V RPMI AND MPXY DRIVERS
> M: Rahul Pathak <rahul@summations.net>
> diff --git a/drivers/resctrl/Kconfig b/drivers/resctrl/Kconfig
> index 672abea3b03c..92b9c82cf9f3 100644
> --- a/drivers/resctrl/Kconfig
> +++ b/drivers/resctrl/Kconfig
> @@ -29,3 +29,16 @@ config ARM64_MPAM_RESCTRL_FS
> default y if ARM64_MPAM_DRIVER && RESCTRL_FS
> select RESCTRL_RMID_DEPENDS_ON_CLOSID
> select RESCTRL_ASSIGN_FIXED
> +
> +menuconfig RISCV_CBQRI
> + bool "RISC-V CBQRI support"
> + depends on RISCV && RISCV_ISA_SSQOSID
> + help
> + Capacity and Bandwidth QoS Register Interface (CBQRI) support for
> + RISC-V cache QoS resources. CBQRI exposes cache capacity
> + allocation through the resctrl filesystem at /sys/fs/resctrl when
> + RESCTRL_FS is also enabled.
> +
> +if RISCV_CBQRI
> +
> +endif
> diff --git a/drivers/resctrl/Makefile b/drivers/resctrl/Makefile
> index 4f6d0e81f9b8..4d8a2c4b5627 100644
> --- a/drivers/resctrl/Makefile
> +++ b/drivers/resctrl/Makefile
> @@ -3,3 +3,6 @@ mpam-y += mpam_devices.o
> mpam-$(CONFIG_ARM64_MPAM_RESCTRL_FS) += mpam_resctrl.o
>
> ccflags-$(CONFIG_ARM64_MPAM_DRIVER_DEBUG) += -DDEBUG
> +
> +obj-$(CONFIG_RISCV_CBQRI) += cbqri.o
> +cbqri-y += cbqri_devices.o
> diff --git a/drivers/resctrl/cbqri_devices.c b/drivers/resctrl/cbqri_devices.c
> new file mode 100644
> index 000000000000..3e1df660920e
> --- /dev/null
> +++ b/drivers/resctrl/cbqri_devices.c
> @@ -0,0 +1,563 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__
> +
> +#include <linux/bitfield.h>
> +#include <linux/cleanup.h>
> +#include <linux/riscv_cbqri.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/ioport.h>
> +#include <linux/list.h>
> +#include <linux/mutex.h>
> +#include <linux/printk.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +
> +#include <asm/csr.h>
> +
> +#include "cbqri_internal.h"
> +
> +LIST_HEAD(cbqri_controllers);
> +
> +/*
> + * Serializes cbqri_controllers mutations against a concurrent insert under
> + * asynchronous driver probing, and against the boot-time walk in the resctrl
> + * glue. Runtime cpuhp walks happen after registration has settled.
> + */
> +DEFINE_MUTEX(cbqri_controllers_lock);
> +
> +/*
> + * CBQRI registers are 64-bit, but the spec only guarantees single-copy
> + * atomicity for naturally aligned 4-byte accesses. Read the two halves and
> + * reconstruct, so the driver does not rely on native 64-bit MMIO.
> + *
> + * The halves are not sampled atomically, but a tear is harmless. The fields
> + * that change while an operation runs, BUSY (bit 39) and STATUS (bits
> + * 38:32), are in the high half and read by the single high readl(). The low
> + * half (OP/AT/RCID) is software-written and constant for the operation.
> + */
> +static u64 cbqri_readq(void __iomem *addr)
> +{
> + u32 lo = readl(addr);
> + u32 hi = readl(addr + 4);
> +
> + return (u64)hi << 32 | lo;
> +}
> +
> +/* Set capacity block mask (cc_block_mask) */
> +static void cbqri_set_cbm(struct cbqri_controller *ctrl, u64 cbm)
> +{
> + /*
> + * cbqri_probe_cc() rejects ncblks > 32, so the mask fits the low word.
> + * Per CBQRI 3.5 the cc_block_mask bits above NCBLKS are read-only zero,
> + * so the upper word needs no write.
> + */
> + writel(lower_32_bits(cbm), ctrl->base + CBQRI_CC_BLOCK_MASK_OFF);
> +}
> +
> +/*
> + * Clear cc_cunits so a CONFIG_LIMIT on a CUNITS-capable controller imposes no
> + * capacity-unit limit. resctrl models only the block mask. On controllers
> + * with cc_capabilities.CUNITS == 0 the register is read-only zero, so there is
> + * nothing to do.
> + */
> +static void cbqri_clear_cunits(struct cbqri_controller *ctrl)
> +{
> + if (ctrl->cc.cunits) {
> + writel(0, ctrl->base + CBQRI_CC_CUNITS_OFF);
> + writel(0, ctrl->base + CBQRI_CC_CUNITS_OFF + 4);
> + }
> +}
> +
> +static int cbqri_wait_busy_flag(struct cbqri_controller *ctrl, int reg_offset,
> + u64 *regp)
> +{
> + u64 reg;
> + int ret;
> +
> + /*
> + * Sleeping poll: caller holds ctrl->lock as a sleeping mutex, so
> + * 10us/1ms is safe under PREEMPT_RT.
> + */
> + ret = read_poll_timeout(cbqri_readq, reg,
> + !FIELD_GET(CBQRI_CONTROL_REGISTERS_BUSY_MASK, reg),
> + 10, 1000, false, ctrl->base + reg_offset);
> + if (ret)
> + return ret;
> + if (regp)
> + *regp = reg;
> + return 0;
> +}
> +
> +/*
> + * Perform capacity allocation control operation on capacity controller.
> + * Caller must hold ctrl->lock.
> + */
> +static int cbqri_cc_alloc_op(struct cbqri_controller *ctrl, int operation,
> + int rcid, u32 at)
> +{
> + int reg_offset = CBQRI_CC_ALLOC_CTL_OFF;
> + int status;
> + u64 reg;
> +
> + lockdep_assert_held(&ctrl->lock);
> +
> + if (cbqri_wait_busy_flag(ctrl, reg_offset, ®) < 0) {
> + pr_err_ratelimited("BUSY timeout before starting operation\n");
> + return -EIO;
> + }
> + FIELD_MODIFY(CBQRI_CONTROL_REGISTERS_OP_MASK, ®, operation);
> + FIELD_MODIFY(CBQRI_CONTROL_REGISTERS_RCID_MASK, ®, rcid);
> +
> + /*
> + * CBQRI Table 1: AT 0=Data, 1=Code. Program AT on controllers
> + * that report supports_alloc_at_code. On controllers that don't,
> + * AT is reserved-zero and the op acts on both halves.
> + */
> + reg &= ~CBQRI_CONTROL_REGISTERS_AT_MASK;
> + if (ctrl->cc.supports_alloc_at_code)
> + reg |= FIELD_PREP(CBQRI_CONTROL_REGISTERS_AT_MASK, at);
> +
> + writel(lower_32_bits(reg), ctrl->base + reg_offset);
> +
> + if (cbqri_wait_busy_flag(ctrl, reg_offset, ®) < 0) {
> + pr_err_ratelimited("BUSY timeout during operation\n");
> + return -EIO;
> + }
> +
> + status = FIELD_GET(CBQRI_CONTROL_REGISTERS_STATUS_MASK, reg);
> + if (status != CBQRI_CC_ALLOC_CTL_STATUS_SUCCESS) {
> + pr_err_ratelimited("operation %d failed: status=%d\n", operation, status);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Apply a capacity block mask and verify via CONFIG_LIMIT + READ_LIMIT.
> + *
> + * AT-capable controllers with CDP off need a second CONFIG_LIMIT on the
> + * other AT half (the spec encodes AT only as 0=Data / 1=Code, there is
> + * no "both halves" value). CDP-on issues separate per-type writes from
> + * resctrl, so a single CONFIG_LIMIT per call is correct.
> + */
> +int cbqri_apply_cache_config(struct cbqri_controller *ctrl, u32 closid,
> + const struct cbqri_cc_config *cfg)
> +{
> + bool need_at_mirror;
> + u64 saved_cbm = 0;
> + int err = 0;
> + u64 reg;
> +
> + mutex_lock(&ctrl->lock);
> +
> + need_at_mirror = ctrl->cc.supports_alloc_at_code && !cfg->cdp_enabled;
> +
> + /*
> + * Capture the cfg->at half CBM before any write so a partial
> + * AT-mirror failure can revert and keep the two halves consistent.
> + * Pre-clear cc_block_mask so a silent firmware no-op (status
> + * SUCCESS but staging not updated) shows as a zero readback
> + * rather than carrying stale data from a prior op.
> + */
> + if (need_at_mirror) {
> + cbqri_set_cbm(ctrl, 0);
> + err = cbqri_cc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT,
> + closid, cfg->at);
> + if (err < 0)
> + goto out;
> + saved_cbm = cbqri_readq(ctrl->base + CBQRI_CC_BLOCK_MASK_OFF);
> + }
> +
> + /* Set capacity block mask (cc_block_mask) */
> + cbqri_set_cbm(ctrl, cfg->cbm);
> + cbqri_clear_cunits(ctrl);
> +
> + /* Capacity config limit operation for the AT half implied by cfg->at */
> + err = cbqri_cc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_CONFIG_LIMIT,
> + closid, cfg->at);
> + if (err < 0)
> + goto out;
> +
> + /*
> + * CDP-off mirror: on AT-capable controllers, also program the
> + * other AT half with the same mask so the two halves stay in sync.
> + */
> + if (need_at_mirror) {
> + u32 other = (cfg->at == CBQRI_CONTROL_REGISTERS_AT_CODE) ?
> + CBQRI_CONTROL_REGISTERS_AT_DATA :
> + CBQRI_CONTROL_REGISTERS_AT_CODE;
> +
> + cbqri_set_cbm(ctrl, cfg->cbm);
> + cbqri_clear_cunits(ctrl);
> + err = cbqri_cc_alloc_op(ctrl,
> + CBQRI_CC_ALLOC_CTL_OP_CONFIG_LIMIT,
> + closid, other);
> + if (err < 0) {
> + int rerr;
> +
> + /*
> + * Best-effort revert of the cfg->at half so the two
> + * halves stay in sync. A schemata read sees only one
> + * half, so silent divergence would otherwise report
> + * the new value as if the write had succeeded.
> + */
> + cbqri_set_cbm(ctrl, saved_cbm);
> + cbqri_clear_cunits(ctrl);
> + rerr = cbqri_cc_alloc_op(ctrl,
> + CBQRI_CC_ALLOC_CTL_OP_CONFIG_LIMIT,
> + closid, cfg->at);
> + if (rerr < 0)
> + pr_err_ratelimited("AT-mirror revert failed (err=%d), AT halves diverged\n",
> + rerr);
> + goto out;
> + }
> + }
> +
> + /* Clear cc_block_mask before read limit to verify op works */
> + cbqri_set_cbm(ctrl, 0);
> +
> + /* Perform a capacity read limit operation to verify blockmask */
> + err = cbqri_cc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT,
> + closid, cfg->at);
> + if (err < 0)
> + goto out;
> +
> + /*
> + * Read capacity blockmask and narrow to u32 to match resctrl's CBM
> + * width. cbqri_probe_cc() rejects ncblks > 32 so the upper bits are
> + * reserved zero.
> + */
> + reg = cbqri_readq(ctrl->base + CBQRI_CC_BLOCK_MASK_OFF);
> + if (lower_32_bits(reg) != cfg->cbm) {
> + pr_err_ratelimited("CBM verify mismatch (reg=%llx != cbm=%llx)\n",
> + reg, cfg->cbm);
> + err = -EIO;
> + }
> +
> +out:
> + mutex_unlock(&ctrl->lock);
> + return err;
> +}
> +
> +/*
> + * Read the configured CBM for closid on the at half via READ_LIMIT.
> + * Pre-clears cc_block_mask before the op so a silent firmware no-op
> + * (status SUCCESS but staging not updated) is detectable in cbm_out.
> + */
> +int cbqri_read_cache_config(struct cbqri_controller *ctrl, u32 closid,
> + u32 at, u32 *cbm_out)
> +{
> + int err;
> +
> + mutex_lock(&ctrl->lock);
> + cbqri_set_cbm(ctrl, 0);
> + err = cbqri_cc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT, closid, at);
> + if (err == 0) {
> + /*
> + * resctrl exposes the CBM as a u32 and cbqri_probe_cc() rejects
> + * ncblks > 32, so the mask fits the low 32-bit word of the
> + * cc_block_mask register.
> + */
> + *cbm_out = readl(ctrl->base + CBQRI_CC_BLOCK_MASK_OFF);
> + }
> + mutex_unlock(&ctrl->lock);
> + return err;
> +}
> +
> +static int cbqri_probe_feature(struct cbqri_controller *ctrl, int reg_offset,
> + int operation, int *status, bool *access_type_supported)
> +{
> + const u64 active_mask = CBQRI_CONTROL_REGISTERS_OP_MASK |
> + CBQRI_CONTROL_REGISTERS_AT_MASK |
> + CBQRI_CONTROL_REGISTERS_RCID_MASK;
> + u64 reg, saved_reg;
> + int at;
> +
> + /*
> + * Default the output to false so the status==0 (feature not
> + * implemented) path returns a deterministic value to the caller
> + * rather than leaving an uninitialized bool.
> + */
> + *access_type_supported = false;
> +
> + /* Keep the initial register value to preserve the WPRI fields */
> + reg = cbqri_readq(ctrl->base + reg_offset);
> + saved_reg = reg;
> +
> + /* Drain any in-flight firmware op before issuing our own write. */
> + if (cbqri_wait_busy_flag(ctrl, reg_offset, &saved_reg) < 0) {
> + pr_err("BUSY timeout before probe operation\n");
> + return -EIO;
> + }
> +
> + /*
> + * Execute the requested operation with all active fields
> + * (OP/AT/RCID) zeroed except OP itself. Every bit not in
> + * active_mask is WPRI and gets carried over from saved_reg.
> + */
> + reg = (saved_reg & ~active_mask) |
> + FIELD_PREP(CBQRI_CONTROL_REGISTERS_OP_MASK, operation);
> + writel(lower_32_bits(reg), ctrl->base + reg_offset);
> + if (cbqri_wait_busy_flag(ctrl, reg_offset, ®) < 0) {
> + pr_err_ratelimited("BUSY timeout during operation\n");
> + return -EIO;
> + }
> +
> + /* Get the operation status */
> + *status = FIELD_GET(CBQRI_CONTROL_REGISTERS_STATUS_MASK, reg);
> +
> + /*
> + * Check for the AT support if the register is implemented
> + * (if not, the status value will remain 0)
> + */
> + if (*status != 0) {
> + /*
> + * Re-issue operation with AT=CODE so the controller
> + * latches AT=CODE on supported hardware (or resets it to 0
> + * on hardware that doesn't). OP must be a defined CBQRI op
> + * here. OP=0 is a no-op and would silently disable CDP.
> + */
> + reg = (saved_reg & ~active_mask) |
> + FIELD_PREP(CBQRI_CONTROL_REGISTERS_OP_MASK, operation) |
> + FIELD_PREP(CBQRI_CONTROL_REGISTERS_AT_MASK,
> + CBQRI_CONTROL_REGISTERS_AT_CODE);
> + writel(lower_32_bits(reg), ctrl->base + reg_offset);
> + if (cbqri_wait_busy_flag(ctrl, reg_offset, ®) < 0) {
> + pr_err("BUSY timeout setting AT field\n");
> + return -EIO;
> + }
> +
> + /*
> + * If the AT field value has been reset to zero,
> + * then the AT support is not present
> + */
> + at = FIELD_GET(CBQRI_CONTROL_REGISTERS_AT_MASK, reg);
> + if (at == CBQRI_CONTROL_REGISTERS_AT_CODE)
> + *access_type_supported = true;
> + }
> +
> + /*
> + * Restore the original register value.
> + * Clear OP to avoid re-triggering the probe op.
> + */
> + saved_reg &= ~CBQRI_CONTROL_REGISTERS_OP_MASK;
> + writel(lower_32_bits(saved_reg), ctrl->base + reg_offset);
> + if (cbqri_wait_busy_flag(ctrl, reg_offset, NULL) < 0) {
> + pr_err("BUSY timeout restoring register value\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int cbqri_probe_cc(struct cbqri_controller *ctrl)
> +{
> + int err, status;
> + int ver_major, ver_minor;
> + u64 reg;
> +
> + reg = cbqri_readq(ctrl->base + CBQRI_CC_CAPABILITIES_OFF);
> + if (reg == 0)
> + return -ENODEV;
> +
> + ver_minor = FIELD_GET(CBQRI_CC_CAPABILITIES_VER_MINOR_MASK, reg);
> + ver_major = FIELD_GET(CBQRI_CC_CAPABILITIES_VER_MAJOR_MASK, reg);
> + ctrl->cc.ncblks = FIELD_GET(CBQRI_CC_CAPABILITIES_NCBLKS_MASK, reg);
> +
> + pr_debug("version=%d.%d ncblks=%d cache_level=%d\n",
> + ver_major, ver_minor,
> + ctrl->cc.ncblks, ctrl->cache.cache_level);
> +
> + /*
> + * NCBLKS == 0 would divide-by-zero in the schemata math while
> + * ctrl->lock is held.
> + */
> + if (!ctrl->cc.ncblks) {
> + pr_warn("CC at %pa has 0 capacity blocks, skipping\n",
> + &ctrl->addr);
> + return -ENODEV;
> + }
> +
> + if (ctrl->cc.ncblks > 32) {
> + pr_warn("CC at %pa has ncblks=%u > 32 (resctrl CBM is u32), skipping\n",
> + &ctrl->addr, ctrl->cc.ncblks);
> + return -ENODEV;
> + }
Could you add a short comment here, like MPAM does, to note that the
NCBLKS <= 32 limit comes from resctrl using u32 bitmap configs?
> +
> + /*
> + * On a CUNITS-capable controller, CONFIG_LIMIT also consumes cc_cunits,
> + * whose reset value is unspecified. The driver clears it to 0 (no limit)
> + * on every CONFIG_LIMIT, so cc_cunits at 0x28 must be within the mapping.
> + */
> + ctrl->cc.cunits = FIELD_GET(CBQRI_CC_CAPABILITIES_CUNITS_MASK, reg);
> + if (ctrl->cc.cunits && ctrl->size < CBQRI_CC_CUNITS_OFF + 8) {
> + pr_warn("CC at %pa supports CUNITS but maps only %pa, skipping\n",
> + &ctrl->addr, &ctrl->size);
> + return -ENODEV;
> + }
> +
> + /* Probe allocation features */
> + err = cbqri_probe_feature(ctrl, CBQRI_CC_ALLOC_CTL_OFF,
> + CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT,
> + &status, &ctrl->cc.supports_alloc_at_code);
> + if (err)
> + return err;
> +
> + if (status == CBQRI_CC_ALLOC_CTL_STATUS_SUCCESS)
> + ctrl->alloc_capable = true;
> +
> + return 0;
> +}
> +
> +static int cbqri_probe_controller(struct cbqri_controller *ctrl)
> +{
> + int err;
> +
> + pr_debug("controller info: type=%d addr=%pa size=%pa max-rcid=%u\n",
> + ctrl->type, &ctrl->addr, &ctrl->size, ctrl->rcid_count);
> +
> + if (!ctrl->addr) {
> + pr_warn("controller has invalid addr=0x0, skipping\n");
> + return -EINVAL;
> + }
> +
> + if (ctrl->size < CBQRI_CTRL_MIN_REG_SPAN) {
> + pr_warn("controller at %pa: size %pa < minimum 0x%x, skipping\n",
> + &ctrl->addr, &ctrl->size, CBQRI_CTRL_MIN_REG_SPAN);
> + return -EINVAL;
> + }
> +
> + if (!request_mem_region(ctrl->addr, ctrl->size, "cbqri_controller")) {
> + pr_err("request_mem_region failed for %pa\n", &ctrl->addr);
> + return -EBUSY;
> + }
> +
> + ctrl->base = ioremap(ctrl->addr, ctrl->size);
> + if (!ctrl->base) {
> + pr_err("ioremap failed for %pa\n", &ctrl->addr);
> + err = -ENOMEM;
> + goto err_release;
> + }
> +
> + switch (ctrl->type) {
> + case CBQRI_CONTROLLER_TYPE_CAPACITY:
> + err = cbqri_probe_cc(ctrl);
> + break;
> + default:
> + pr_err("unknown controller type %d\n", ctrl->type);
> + err = -ENODEV;
> + break;
> + }
> +
> + if (err)
> + goto err_iounmap;
> +
> + return 0;
> +
> +err_iounmap:
> + iounmap(ctrl->base);
> + ctrl->base = NULL;
> +err_release:
> + release_mem_region(ctrl->addr, ctrl->size);
> + return err;
> +}
> +
> +void cbqri_controller_destroy(struct cbqri_controller *ctrl)
> +{
> + /*
> + * cbqri_probe_controller() clears ctrl->base on its error paths and
> + * releases the mem region itself, so reach into both only when
> + * destroy is rolling back a successful probe.
> + */
> + if (ctrl->base) {
> + iounmap(ctrl->base);
> + release_mem_region(ctrl->addr, ctrl->size);
> + }
> + kfree(ctrl);
> +}
> +
> +/**
> + * riscv_cbqri_register_cc_dt() - register a DT-described capacity controller
> + * @info: registration descriptor. info->cache_id is used as the
> + * resctrl domain id. info->type must be CAPACITY.
> + * @cache_level: cache level (2 or 3) the controller backs, mapped to the
> + * resctrl L2/L3 resource by the resctrl glue.
> + *
> + * The cache level and id (info->cache_id) are supplied directly by the
> + * caller, which resolves them from cacheinfo. Domain membership is resolved
> + * per CPU at hotplug, so no cpu mask is stored. There is no firmware table
> + * to resolve any of this from.
> + *
> + * Return: 0 on success, or a negative errno on failure.
> + */
> +int riscv_cbqri_register_cc_dt(const struct cbqri_controller_info *info,
> + u32 cache_level)
> +{
> + struct cbqri_controller *ctrl;
> + int err;
> +
> + if (!info->addr) {
> + pr_warn("skipping controller with invalid addr=0x0\n");
> + return -EINVAL;
> + }
> +
> + if (info->type != CBQRI_CONTROLLER_TYPE_CAPACITY) {
> + pr_warn("register_cc_dt called with non-capacity type %u\n",
> + info->type);
> + return -EINVAL;
> + }
> +
> + ctrl = kzalloc(sizeof(*ctrl), GFP_KERNEL);
> + if (!ctrl)
> + return -ENOMEM;
> +
> + mutex_init(&ctrl->lock);
> +
> + ctrl->addr = info->addr;
> + ctrl->size = info->size;
> + ctrl->type = info->type;
> + ctrl->rcid_count = info->rcid_count;
> +
> + /*
> + * SRMCFG encodes RCID in 12 bits. Reject an out-of-range count rather
> + * than silently truncating in every FIELD_PREP(SRMCFG_RCID_MASK, closid)
> + * on the schedule-in fast path.
> + */
> + if (ctrl->rcid_count > FIELD_MAX(SRMCFG_RCID_MASK) + 1) {
> + pr_warn("CC at %pa has RCID count %u beyond the 12-bit SRMCFG field, skipping\n",
> + &ctrl->addr, ctrl->rcid_count);
> + cbqri_controller_destroy(ctrl);
> + return -EINVAL;
> + }
> +
> + ctrl->cache.cache_id = info->cache_id;
> + ctrl->cache.cache_level = cache_level;
> +
> + err = cbqri_probe_controller(ctrl);
> + if (err) {
> + cbqri_controller_destroy(ctrl);
> + return err;
> + }
> +
> + /*
> + * Allocation capability comes from the capabilities register probed
> + * above, not from device tree. rcid_count only bounds the RCID range,
> + * so a controller the hardware reports as alloc-capable but described
> + * with no RCID count cannot be driven. Reject that inconsistency. A
> + * monitoring-only controller (not alloc_capable) needs no RCID count.
> + */
> + if (ctrl->alloc_capable && !ctrl->rcid_count) {
> + pr_warn("CC at %pa is alloc-capable but has no RCID count, skipping\n",
> + &ctrl->addr);
> + cbqri_controller_destroy(ctrl);
> + return -EINVAL;
> + }
> +
> + guard(mutex)(&cbqri_controllers_lock);
> + list_add_tail(&ctrl->list, &cbqri_controllers);
> + return 0;
> +}
> diff --git a/drivers/resctrl/cbqri_internal.h b/drivers/resctrl/cbqri_internal.h
> new file mode 100644
> index 000000000000..77429f39f874
> --- /dev/null
> +++ b/drivers/resctrl/cbqri_internal.h
> @@ -0,0 +1,122 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef _DRIVERS_RESCTRL_CBQRI_INTERNAL_H
> +#define _DRIVERS_RESCTRL_CBQRI_INTERNAL_H
> +
> +#include <linux/bitfield.h>
> +#include <linux/riscv_cbqri.h>
> +#include <linux/list.h>
> +#include <linux/mutex.h>
> +#include <linux/types.h>
> +
> +/* Capacity Controller (CC) MMIO register offsets. */
> +#define CBQRI_CC_CAPABILITIES_OFF 0
> +#define CBQRI_CC_ALLOC_CTL_OFF 24
> +#define CBQRI_CC_BLOCK_MASK_OFF 32
> +
> +/*
> + * Per CBQRI 3.5 the block-mask width BMW is the smallest multiple of 64 bits
> + * that holds NCBLKS, so cc_cunits sits at 32 + BMW/8 bytes. This constant is
> + * valid only while NCBLKS <= 64. cbqri_probe_cc() rejects ncblks > 32 before
> + * it reads cc_capabilities.CUNITS, forcing BMW to 64 bits, one 8-byte block
> + * mask, and cc_cunits at 0x28. Raising that cap above 64 would require
> + * computing 32 + roundup(ncblks, 64) / 8 instead of a constant.
> + */
> +#define CBQRI_CC_CUNITS_OFF 40
> +
> +/*
> + * Highest base register offset (cc_block_mask at 0x20) plus its 8-byte width.
> + * cbqri_probe_controller() rejects smaller mappings. cc_cunits at 0x28 is
> + * optional and only required when cc_capabilities.CUNITS is set, which
> + * cbqri_probe_cc() checks against the mapping size separately.
> + */
> +#define CBQRI_CTRL_MIN_REG_SPAN 0x28u
> +
> +#define CBQRI_CC_CAPABILITIES_VER_MINOR_MASK GENMASK_ULL(3, 0)
> +#define CBQRI_CC_CAPABILITIES_VER_MAJOR_MASK GENMASK_ULL(7, 4)
> +#define CBQRI_CC_CAPABILITIES_NCBLKS_MASK GENMASK_ULL(23, 8)
> +#define CBQRI_CC_CAPABILITIES_CUNITS_MASK BIT_ULL(25)
> +
> +/*
> + * CC control registers are 64-bit, but the CBQRI spec only guarantees
> + * single-copy atomicity for naturally aligned 4-byte accesses. They are read
> + * as two 32-bit halves (cbqri_readq) reconstructed into a u64 for field
> + * extraction, and written via the low 32-bit half, so the driver does not
> + * depend on native 64-bit MMIO. Keep every field mask GENMASK_ULL so
> + * FIELD_MODIFY() or ~mask on the reconstructed u64 never zero-extends a
> + * 32-bit mask and clobbers STATUS/BUSY/WPRI in bits 63:32.
> + */
> +#define CBQRI_CONTROL_REGISTERS_OP_MASK GENMASK_ULL(4, 0)
> +#define CBQRI_CONTROL_REGISTERS_AT_MASK GENMASK_ULL(7, 5)
> +/* AT field values (CBQRI Table 1): data vs code half for CDP */
> +#define CBQRI_CONTROL_REGISTERS_AT_DATA 0
> +#define CBQRI_CONTROL_REGISTERS_AT_CODE 1
> +#define CBQRI_CONTROL_REGISTERS_RCID_MASK GENMASK_ULL(19, 8)
> +#define CBQRI_CONTROL_REGISTERS_STATUS_MASK GENMASK_ULL(38, 32)
> +#define CBQRI_CONTROL_REGISTERS_BUSY_MASK GENMASK_ULL(39, 39)
> +
> +#define CBQRI_CC_ALLOC_CTL_OP_CONFIG_LIMIT 1
> +#define CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT 2
> +#define CBQRI_CC_ALLOC_CTL_STATUS_SUCCESS 1
> +
> +/* Capacity Controller hardware capabilities */
> +struct riscv_cbqri_capacity_caps {
> + u16 ncblks;
> + bool supports_alloc_at_code;
> + /* cc_capabilities.CUNITS: controller enforces a capacity-unit limit */
> + bool cunits;
> +};
> +
> +/**
> + * struct cbqri_cc_config - desired capacity allocation state for one rcid
> + * @cbm: capacity block mask
> + * @at: AT half the @cbm applies to (CBQRI_CONTROL_REGISTERS_AT_DATA
> + * or CBQRI_CONTROL_REGISTERS_AT_CODE)
> + * @cdp_enabled: when false and the controller supports AT, mirror @cbm
> + * into the other AT half so both stay in sync
> + */
> +struct cbqri_cc_config {
> + u64 cbm;
> + u32 at;
> + bool cdp_enabled;
> +};
> +
> +struct cbqri_controller {
> + void __iomem *base;
> + /*
> + * Serializes the write-then-poll-busy MMIO sequences on this
> + * controller. Each CBQRI op may busy-wait up to 1 ms on slow
> + * firmware, so use a sleeping mutex to keep preemption enabled.
> + * All resctrl-arch entry points run in process context.
> + */
> + struct mutex lock;
> +
> + struct riscv_cbqri_capacity_caps cc;
> +
> + bool alloc_capable;
> +
> + phys_addr_t addr;
> + phys_addr_t size;
> + enum cbqri_controller_type type;
> + u32 rcid_count;
> +
> + struct list_head list;
> +
> + struct cache_controller {
> + u32 cache_level;
> + /* Cache id used as the resctrl domain id */
> + u32 cache_id;
> + } cache;
> +};
> +
> +extern struct list_head cbqri_controllers;
> +extern struct mutex cbqri_controllers_lock;
> +
> +void cbqri_controller_destroy(struct cbqri_controller *ctrl);
> +
> +int cbqri_apply_cache_config(struct cbqri_controller *ctrl, u32 closid,
> + const struct cbqri_cc_config *cfg);
> +
> +int cbqri_read_cache_config(struct cbqri_controller *ctrl, u32 closid,
> + u32 at, u32 *cbm_out);
> +
> +#endif /* _DRIVERS_RESCTRL_CBQRI_INTERNAL_H */
> diff --git a/include/linux/riscv_cbqri.h b/include/linux/riscv_cbqri.h
> new file mode 100644
> index 000000000000..e6b3febbed89
> --- /dev/null
> +++ b/include/linux/riscv_cbqri.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Public registration API for the RISC-V Capacity and Bandwidth QoS
> + * Register Interface (CBQRI) core. Discovery layers (device tree
> + * platform drivers) call riscv_cbqri_register_cc_dt() to hand a capacity
> + * controller descriptor to the core, which owns all subsequent state.
> + */
> +#ifndef _LINUX_RISCV_CBQRI_H
> +#define _LINUX_RISCV_CBQRI_H
> +
> +#include <linux/types.h>
> +
> +enum cbqri_controller_type {
> + CBQRI_CONTROLLER_TYPE_CAPACITY,
> +};
> +
> +/**
> + * struct cbqri_controller_info - registration descriptor
> + * @addr: MMIO base address of the controller's register interface
> + * @size: size of the MMIO region
> + * @type: controller type (capacity)
> + * @rcid_count: number of supported RCIDs
> + * @cache_id: cache id used as the resctrl domain id
> + */
> +struct cbqri_controller_info {
> + phys_addr_t addr;
> + phys_addr_t size;
> + enum cbqri_controller_type type;
> + u32 rcid_count;
> + u32 cache_id;
> +};
> +
> +#if IS_ENABLED(CONFIG_RISCV_CBQRI)
> +int riscv_cbqri_register_cc_dt(const struct cbqri_controller_info *info,
> + u32 cache_level);
> +#else
> +static inline int
> +riscv_cbqri_register_cc_dt(const struct cbqri_controller_info *info,
> + u32 cache_level)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> +#endif /* _LINUX_RISCV_CBQRI_H */
>
> --
> 2.43.0
>
Thanks,
Yunhui
^ permalink raw reply
* Re: [PATCH v17 2/4] crypto: spacc - Add SPAcc ahash support
From: sashiko-bot @ 2026-07-20 12:09 UTC (permalink / raw)
To: Pavitrakumar Managutte; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260720113740.64960-3-pavitrakumarm@vayavyalabs.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Race condition and ring buffer corruption in `spacc_process_jb` due to unsafe reloading of the tail pointer.
- [High] Use-After-Free of algorithm structures during `spacc_unregister_hash_algs`.
- [High] Device teardown sequence in `spacc_crypto_remove()` causes deadlock, hangs, and DMA Use-After-Free.
- [High] DDT DMA descriptors are written in CPU endianness, causing memory corruption on big-endian architectures.
- [High] The `SPACC_AADCOPY_FLAG` multiplexing causes hash requests of 2GB or more to be silently truncated.
- [Low] Mixing goto-based error handling with guard() cleanup in the same function.
--
--- Patch [2]: [PATCH v17 2/4] crypto: spacc - Add SPAcc ahash support ---
commit 21597ca0ff89c5c87f4b74d99d92b89fb2a1eac7
Author: Pavitrakumar Managutte <pavitrakumarm@vayavyalabs.com>
crypto: spacc - Add SPAcc ahash support
This commit adds ahash support to the SPAcc driver. It implements various
hash algorithms including CMAC, XCBC, MD5, and SHA variants, along with
crypto engine integration, hardware descriptor management, and device
teardown sequences.
> diff --git a/drivers/crypto/dwc-spacc/spacc_ahash.c b/drivers/crypto/dwc-spacc/spacc_ahash.c
> --- /dev/null
> +++ b/drivers/crypto/dwc-spacc/spacc_ahash.c
> @@ -311,10 +311,10 @@ static int spacc_hash_do_one_request(struct crypto_engine *engine, void *areq)
> [ ... ]
> + {
> + guard(mutex)(&tctx->lock);
> +
> + if (tctx->handle < 0 || !tctx->ctx_valid) {
> [ ... ]
> + tctx->handle = spacc_open(&priv->spacc,
> + CRYPTO_MODE_NULL, salg->mode->id,
> + -1, 0, spacc_digest_cb, reqtfm);
> + if (tctx->handle < 0) {
> + dev_dbg(salg->dev,
> + "context open failed, fallback\n");
> + goto fallback;
[Severity: Low]
Does this code violate the cleanup subsystem technical guidelines?
The guidelines explicitly prohibit mixing goto-based error handling and
guard() declarations in the same function to prevent confusing ownership
semantics. Here, the goto fallback jumps out of a block protected by
guard(mutex)(&tctx->lock).
> [ ... ]
> + }
> + rc = spacc_packet_enqueue_ddt(&priv->spacc, ctx->acb.new_handle,
> + &ctx->src, &ctx->dst, req->nbytes,
> + 0, req->nbytes, 0, 0, 0);
[Severity: High]
Could this cause silent truncation for hash requests of 2GB or larger?
In spacc_hash_do_one_request(), req->nbytes is passed as pre_aad_sz
to spacc_packet_enqueue_ddt_ex(). This creates an issue when multiplexing
large lengths with control flags in the lower layers.
> @@ -978,5 +978,5 @@ int spacc_unregister_hash_algs(struct spacc_priv *priv)
> [ ... ]
> + list_for_each_entry_safe(salg, tmp, &priv->hash_alg_list, list) {
> + crypto_engine_unregister_ahash(&salg->alg.hash);
> + list_del(&salg->list);
> + }
[Severity: High]
Could this lead to a use-after-free during module unload?
When crypto_engine_unregister_ahash() is called on salg->alg.hash, it
drops the final reference to the algorithm, triggering the asynchronous
destructor spacc_hash_alg_destroy() which calls kfree(salg). The
immediate next line executes list_del(&salg->list), dereferencing the
freed salg pointer.
> diff --git a/drivers/crypto/dwc-spacc/spacc_core.c b/drivers/crypto/dwc-spacc/spacc_core.c
> --- /dev/null
> +++ b/drivers/crypto/dwc-spacc/spacc_core.c
> @@ -1286,7 +1286,7 @@ int spacc_packet_enqueue_ddt_ex(struct spacc_device *spacc, int use_jb,
> [ ... ]
> + if (pre_aad_sz & SPACC_AADCOPY_FLAG) {
> + job->ctrl |= SPACC_CTRL_MASK(SPACC_CTRL_AAD_COPY);
> + pre_aad_sz &= ~(SPACC_AADCOPY_FLAG);
> + } else
> + job->ctrl &= ~SPACC_CTRL_MASK(SPACC_CTRL_AAD_COPY);
> +
> + job->pre_aad_sz = pre_aad_sz;
[Severity: High]
Is the SPACC_AADCOPY_FLAG multiplexing safe for large hash requests?
If req->nbytes from ahash requests is greater than or equal to 0x80000000
(2GB), the driver interprets the MSB as the SPACC_AADCOPY_FLAG here. It
strips the MSB from the length, silently truncating the requested hash length,
and sets the hardware control flag instead of processing the full buffer.
> diff --git a/drivers/crypto/dwc-spacc/spacc_device.c b/drivers/crypto/dwc-spacc/spacc_device.c
> --- /dev/null
> +++ b/drivers/crypto/dwc-spacc/spacc_device.c
> @@ -185,8 +185,8 @@ static void spacc_crypto_remove(struct platform_device *pdev)
> [ ... ]
> + spacc_irq_glbl_disable(&priv->spacc);
> + spacc_unregister_algs(priv);
> +
> + if (priv->engine)
> + crypto_engine_exit(priv->engine);
[Severity: High]
Is the teardown sequence ordered correctly?
During driver removal, spacc_irq_glbl_disable() turns off hardware IRQs. Next,
spacc_unregister_algs() destroys the DMA hash_pool. Then crypto_engine_exit()
tries to stop the engine, waiting up to 10 seconds for engine->busy to clear.
Because IRQs are disabled, inflight requests can never finish. The engine
fails to stop, leaks its worker thread, and the hardware can perform DMA
writes into the destroyed pool, resulting in a use-after-free.
> diff --git a/drivers/crypto/dwc-spacc/spacc_hal.c b/drivers/crypto/dwc-spacc/spacc_hal.c
> --- /dev/null
> +++ b/drivers/crypto/dwc-spacc/spacc_hal.c
> @@ -251,8 +251,8 @@ int pdu_ddt_add(struct device *dev, struct pdu_ddt *ddt, dma_addr_t phys,
> [ ... ]
> + if (ddt->idx == ddt->limit)
> + return -EINVAL;
> +
> + ddt->virt[ddt->idx * 2 + 0] = (uint32_t)phys;
> + ddt->virt[ddt->idx * 2 + 1] = size;
> + ddt->virt[ddt->idx * 2 + 2] = 0;
> + ddt->virt[ddt->idx * 2 + 3] = 0;
[Severity: High]
Does this code handle endianness correctly for the DMA descriptors?
The SPAcc hardware uses a little-endian DMA bus interface, but the code
writes the phys address and size parameters directly to ddt->virt
without a cpu_to_le32() conversion. On big-endian architectures, this
results in byteswapped addresses and lengths being read by the hardware,
leading to out-of-bounds DMA accesses and memory corruption.
> diff --git a/drivers/crypto/dwc-spacc/spacc_manager.c b/drivers/crypto/dwc-spacc/spacc_manager.c
> --- /dev/null
> +++ b/drivers/crypto/dwc-spacc/spacc_manager.c
> @@ -350,10 +350,10 @@ int spacc_process_jb(struct spacc_device *spacc, unsigned long *lock_flag)
> [ ... ]
> + spin_unlock_irqrestore(&spacc->lock,
> + *lock_flag);
> + job->cb(spacc, job->cbdata);
> + spin_lock_irqsave(&spacc->lock,
> + *lock_flag);
> + tail = spacc->jb_tail;
> + } else if (!spacc->autodetect) {
> + job->job_done = 1;
> + wake_up_interruptible(&job->waitq);
> + }
> + }
> + }
> +
> + tail++;
> + if (tail == SPACC_MAX_JOB_BUFFERS)
> + tail = 0;
> +
> + spacc->jb_tail = tail;
[Severity: High]
Can this sequence cause a race condition and corrupt the ring buffer?
In spacc_process_jb(), the lock is dropped to call job->cb. If another
thread queues a new job and processes it, advancing spacc->jb_tail, the
first thread will wake up, reload the newly advanced jb_tail into tail,
and unconditionally increment it here. This skips the unprocessed job at
the new tail index and corrupts the buffer state.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720113740.64960-1-pavitrakumarm@vayavyalabs.com?part=2
^ permalink raw reply
* Re: [PATCH v3 0/8] Arm Live Firmware Activation (LFA) support
From: Andre Przywara @ 2026-07-20 12:08 UTC (permalink / raw)
To: Michal Suchánek
Cc: Mark Rutland, Lorenzo Pieralisi, Sudeep Holla, Conor Dooley,
vsethi, Salman Nabi, Rob Herring, linux-kernel, Varun Wadekar,
Trilok Soni, devicetree, Nirmoy Das, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <alYjFwi0dnld-wP3@kunlun.suse.cz>
Hi Michal,
thanks for having a look and for testing!
On 7/14/26 13:52, Michal Suchánek wrote:
> On Mon, Jul 13, 2026 at 06:02:35PM +0200, Michal Suchánek wrote:
>> On Mon, Jul 06, 2026 at 03:44:40PM +0200, Andre Przywara wrote:
>>> Hi all,
>>>
>>> this is version 3 of the Live Firmware Activation kernel support. The
>>> device part of the code now relies on Aneesh's SMCCC bus patches[1],
>>> which solves some problems rather nicely. I also added the formerly
>>> missing sysfs ABI documentation. Based on v7.2-rc1, plus the first
>>> two patches from Aneesh's series. More detailed changelog below.
>>> ==============================
>>>
>>> This series implements the kernel side support of the Arm Live
>>> Firmware Activation (LFA) specification [2]. LFA enables the activation
>>> of updated firmware components without requiring a system reboot,
>>> reducing downtime and allowing quicker deployment of critical bug fixes
>>> in environments such as data centers and hyperscale systems.
>>> It requires explicit firmware support, both via an agent running in EL3
>>> (for instance in TF-A, already merged), but also in the firmware
>>> component to be activated. TF-RMM recently merged support for this.
>>>
>>> Unlike the usual firmware update process (which may use tools like
>>> fwupd), LFA focuses solely on the activation of an already updated
>>> firmware component, called "pending activation" in LFA lingo. This works
>>> by signalling the LFA agent (part of the EL3 runtime firmware) via an
>>> SMC call, which then does the heavy lifting of the live update, in
>>> cooperation with the to-be-updated firmware component.
>>>
>>> Key features of the driver:
>>> * Detects LFA support in system firmware (EL3).
>>> * Lists all firmware components that support live activation, identified
>>> by their GUID.
>>> * Exposes component attributes (e.g., activation capability, and
>>> activation pending) via sysfs under /sys/firmware/lfa/<GUID>/.
>>> * Provides interfaces to:
>>> - Trigger activation of an updated firmware component.
>>> - Cancel an ongoing activation if required.
>>> A more detailed list of features can be found in patch 2/8.
>>> Based on v7.2-rc1.
>>>
>>> This work is conceptually similar to Intel’s Platform Firmware Runtime
>>> Update and telemetry (PFRUT) [3] and TDX module updates [4], but
>>> targets Arm platforms. The driver has been used to successfully activate
>>> a Realm Management Monitor (RMM) firmware image in a controlled test
>>> environment. RMM is analogous to Intel’s TDX module.
>>>
>>> There is effort on similar work from the OCP [5]. Future work may
>>> include integration with utilities like fwupd to automatically select
>>> the appropriate driver, based on platform architecture, for Live/Runtime
>>> firmware updates.
>>>
>>> Please have a look, test and comment!
>>
>> Hello,
>>
>> booting a kernel with v2 of this patchset applied the module does not
>> get autoloaded. Loading it manually I get
>>
>> [ 1972.957282] [ T5195] Arm LFA: Live Firmware Activation: detected v1.0
>> [ 1972.958620] [ T5195] Arm LFA: registered LFA ACPI notification
>>
>> Is this expected?
>>
>> I would expect the driver to load automatically.
>>
>> I do not see anything in the v3 changelog obviously addressing
>> autoloading but changing to using a bus might affect that.
>>
>> I will try to update to v3 later.
>
> Hello,
>
> updating to v3 of the patchset resolves the problem.
Yes, that was indeed a change that came for free with changing the
probing method to be now SMCCC bus based. As Krzysztof rightfully
mentioned before, the driver was always probing, then bailing out if the
service was not available, which is not the way it should work under the
driver model. As a side effect, there wasn't really any discovery or
auto-loading mechanism. With the new SMCCC bus this should now all be
solved.
Thanks for testing!
Cheers,
Andre
> The driver is now autoloaded.
>
> Thanks
>
> Michal
^ permalink raw reply
* Re: [PATCH v2 2/4] arm64: dts: qcom: shikra-cqm-evk: Enable display and add ili7807s panel
From: Arpit Saini @ 2026-07-20 12:07 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Baryshkov
Cc: Nabige Aala, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <fa5bf9e0-66ec-4506-a2fa-bf1d95adf9a6@oss.qualcomm.com>
Hi Konrad,
On 7/16/2026 11:21 PM, Konrad Dybcio wrote:
> On 7/14/26 9:21 AM, Arpit Saini wrote:
>> Hi Dmitry,Konrad
>>
>> On 7/10/2026 6:09 PM, Dmitry Baryshkov wrote:
>>> On Fri, Jul 10, 2026 at 05:28:04PM +0530, Arpit Saini wrote:
>>>> Hi Konrad,
>>>>
>>>> On 7/10/2026 2:31 PM, Arpit Saini wrote:
>
> [...]
>
>>>> Normally the backlight EN pin is controlled by a backlight driver.
>>>>
>>>> However, this panel uses MIPI DCS based backlight control with no
>>>>
>>>> separate backlight driver. Since there is no driver to assert gpio91,
>>>>
>>>> we control it via the panel's pinctrl default state..
>>>>
>>>> So this is platform specific pin , we need this to enable/disable
>>>>
>>>> the backlight.
>>>
>>> Handle it from the panel driver. Also please fix your editor to prevent
>>> it from inserting extra empty lines.
>>>
>>
>> Earlier I handled it through panel driver, but this GPIO is specific to our
>> Qualcomm Daughter Card, it is not going to the panel connector.
>
> So is it an enable pin of a voltage regulator maybe? I'm having trouble
> understanding how this is all tied together, given the panel driver
> uses DCS commands to control the backlight status
>
> Konrad
No, it is not a voltage regulator enable.
GPIO91 (WLED_P1_EN) is the enable pin of the WLED driver IC on the Qualcomm daughter card.
The WLED driver is a boost LED driver that powers the backlight LEDs.
The backlight control works in two parts:
1. GPIO91 must be asserted to enable the WLED driver IC itself.
2. The panel's CABC output (a PWM signal) is connected to the WLED driver's PWM input
and controls the actual brightness.
This CABC output is driven by the DCS set_display_brightness command sent from the panel driver.
So the DCS commands control brightness via the panel's PWM/CABC output,
but the WLED driver IC needs to be enabled first via GPIO91.
Since GPIO91 is on the Qualcomm daughter card and not on the panel connector.
Dmitry suggested , it is not appropriate to model it in the panel binding.
The current approach of asserting it via pinctrl default state in the board DTS keeps it board-specific.
If you have a better suggestion for modelling this, I'm happy to follow your guidance.
SoC (ITP Baseband Card)
├── GPIO91 (WLED_P1_EN) ─────────────────────────────────────┐
│ │
└── DSI ──────────────────────────────────────────────────┐ │
│ │
┌──────────────────────────────────────────────────────────┼──┼──────────────────────────────────┐
│ Qualcomm Display Daughter Card │ │ │
│ │ │ │
│ ┌─────────────────────────────────┐ │ │ ┌──────────────────────┐ │
│ │ DLC DLC0697 Panel (ILI7807S) │◄────────────────────┘ │ │ WLED Driver IC │ │
│ │ │ | │ │ │
│ │ DCS set_display_brightness() │ └──►│ EN │ │
│ │ │ │ │ │ │
│ │ ▼ │ │ │ │
│ │ CABC output ───────────────────┼───────────────────────────►│ PWM │ │
│ │ │ │ │ │
│ │ │ │ LED outputs ────────┼──► Backlight LEDs
│ └─────────────────────────────────┘ └──────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────────────────────────────┘
Thanks,
Arpit
^ permalink raw reply
* Re: [PATCH v17 4/4] crypto: spacc - Add SPAcc Kconfig and Makefile
From: sashiko-bot @ 2026-07-20 11:53 UTC (permalink / raw)
To: Pavitrakumar Managutte; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260720113740.64960-5-pavitrakumarm@vayavyalabs.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] CRYPTO_DEV_SPACC_HASH is defined as a tristate option but controls a component of a composite module, leading to an undefined reference linker error when configured as 'm' while the main driver is 'y'.
--
--- Patch [4]: [PATCH v17 4/4] crypto: spacc - Add SPAcc Kconfig and Makefile ---
commit 6d5d2ec49262f31f1558921632e08b8a62362a2d
Author: Pavitrakumar Managutte <pavitrakumarm@vayavyalabs.com>
crypto: spacc - Add SPAcc Kconfig and Makefile
Add Makefile and Kconfig for SPAcc driver.
> diff --git a/drivers/crypto/dwc-spacc/Kconfig b/drivers/crypto/dwc-spacc/Kconfig
> new file mode 100644
> index 0000000000000..edc550562235e
> --- /dev/null
> +++ b/drivers/crypto/dwc-spacc/Kconfig
> @@ -0,0 +1,83 @@
[ ... ]
> +if CRYPTO_DEV_SPACC
> +
> +config CRYPTO_DEV_SPACC_HASH
> + tristate "Enable HASH functionality"
[Severity: Low]
Will this cause a build failure if CONFIG_CRYPTO_DEV_SPACC=y and
CONFIG_CRYPTO_DEV_SPACC_HASH=m?
Since CRYPTO_DEV_SPACC_HASH is a tristate, it can be set to 'm' while the
main driver is built-in ('y'). If that happens, Kbuild will add
spacc_ahash.o to snps-spacc-m in the Makefile:
snps-spacc-$(CONFIG_CRYPTO_DEV_SPACC_HASH) += spacc_ahash.o
Because snps-spacc is built-in, Kbuild ignores the -m list, meaning
spacc_ahash.o won't be linked into the final kernel image.
However, IS_ENABLED(CONFIG_CRYPTO_DEV_SPACC_HASH) evaluates to true for 'm'
as well. This can lead to undefined reference errors when spacc_crypto_probe()
tries to call spacc_probe_hashes() and spacc_unregister_hash_algs() in
spacc_device.c.
Should CRYPTO_DEV_SPACC_HASH be a bool instead to prevent this mismatch?
> + default CRYPTO_DEV_SPACC
> + select CRYPTO_HASH
> + select CRYPTO_SHA1
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720113740.64960-1-pavitrakumarm@vayavyalabs.com?part=4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox