* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 14:25 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Yuanfang Zhang,
Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 05:49:26PM +0800, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
> Add the arm,primecell-periphid property to bypass the AMBA bus
> check and resolve the probe issue.
tnoc.c registers both an AMBA driver and a platform driver. Shouldn't it
be registered as a platform device instead?
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v5 15/16] media: venus: skip QCM2290 if Iris driver is enabled
From: Vikash Garodia @ 2026-06-24 14:24 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-15-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> As the Iris driver now supports the QCM2290 hardware too, there is a
> race between Venus and Iris drivers on binding to the corresponding
> device. Follow the approach used by other platforms and skip QCM2290 in
> the Venus driver if Iris is enabled.
>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Dikshita Agarwal<dikshita.agarwal@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/venus/core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 16/16] media: iris: constify inst_fw_cap_sm8250_dec
From: Vikash Garodia @ 2026-06-24 14:23 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-16-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Mark inst_fw_cap_sm8250_dec as a const array, the data is read-only.
>
> Suggested-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: David Lechner @ 2026-06-24 14:18 UTC (permalink / raw)
To: Lukas, Siratul Islam
Cc: andy, conor+dt, devicetree, jic23, krzk+dt, linux-iio,
linux-kernel, nuno.sa, robh
In-Reply-To: <ajuVjk-lw-DqUVnl@berta-MS-7693>
On 6/24/26 3:30 AM, Lukas wrote:
> Thanks for the review. As i said this is my first time submitting a
> patch. I have looked at already existing spi dac drivers for reference
> but i seemed to have missed quite a lot. But the comments are greatly
> appreciated.
>
> On Wed, Jun 24, 2026 at 12:56:15AM +0600, Siratul Islam wrote:
>> A link to the datasheet here would be nice.
>
> I will try to add all the small suggestions i dont mention explicitly,
> like style issues or using guard instead of manual lock/unlock to v2.
>
>>> +
>>> + if (st->internal_ref) {
>>> + st->vref_uv = 2500000; /* 2.5V internal reference */
>> A note on where this value came from or why this was chosen, or a reference to datasheet would be better.
>
> I think i would add the suggestion from David Lechner to remove the
> internal_ref property completly and add "the way of doing optional
> voltage references". This includes using the macro
> DAC8163_INTERNAL_REF_mV. Would this be acceptable?
>
>> You have a CMD_SOFT_RST defined but not used. Should this be used to reset before doing any configuration?
>
> Yes this is a command which isnt used at this point. But maybe it makes
> sense to reset the DAC first when probing.
In general we tend to reset IIO devices during probe. DACs can be an exception
though since they are output devices and resetting it could change the output.
This device is quite simple anyway, so reset probably isn't needed.
>
> Best regards
> Lukas
^ permalink raw reply
* Re: [PATCH v5 12/16] media: iris: implement support for the Agatti platform
From: Vikash Garodia @ 2026-06-24 14:17 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-12-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Port support for the AR50Lt video codec core (present for example on the
> Agatti platform) to the Iris driver. Unlike more recent cores this
> generation doesn't have the PIPE property (as it always has only one
> pipe). Also, unlike newer platforms, buffer sizes are requested from the
> firmware instead of being calculated by the driver.
>
> Co-developed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Makefile | 1 +
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 227 +++++++++++++++++++++
> .../platform/qcom/iris/iris_platform_common.h | 6 +
> .../platform/qcom/iris/iris_platform_vpu_ar50lt.c | 110 ++++++++++
> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
> drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 13 ++
> drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 1 +
> 7 files changed, 362 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index f1b204b95694..bbd1f724963e 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -14,6 +14,7 @@ qcom-iris-objs += iris_buffer.o \
> iris_hfi_queue.o \
> iris_platform_vpu2.o \
> iris_platform_vpu3x.o \
> + iris_platform_vpu_ar50lt.o \
> iris_power.o \
> iris_probe.o \
> iris_resources.o \
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> index ca1545d28b53..f57af31dbd9f 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> @@ -443,3 +443,230 @@ const struct iris_firmware_data iris_hfi_gen1_data = {
> .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> };
> +
> +static const struct platform_inst_fw_cap iris_inst_fw_cap_gen1_ar50lt_dec[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> +};
> +
> +static const struct platform_inst_fw_cap inst_fw_cap_gen1_ar50lt_enc[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> + {
> + .cap_id = PROFILE_H264,
> + .min = V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE,
> + .max = V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_MAIN) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_HIGH) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_STEREO_HIGH) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH),
> + .value = V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = PROFILE_HEVC,
> + .min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> + .max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE),
> + .value = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = LEVEL_H264,
> + .min = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .max = V4L2_MPEG_VIDEO_H264_LEVEL_4_2,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1B) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_3) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_2),
> + .value = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = LEVEL_HEVC,
> + .min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
> + .max = V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_2) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_2_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_3) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_3_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_4) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1),
> + .value = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = HEADER_MODE,
> + .min = V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE,
> + .max = V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) |
> + BIT(V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME),
> + .value = V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
> + .hfi_id = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_header_mode_gen1,
> + },
> + {
> + .cap_id = BITRATE,
> + .min = BITRATE_MIN,
> + .max = BITRATE_MAX_AR50LT,
> + .step_or_mask = BITRATE_STEP,
> + .value = BITRATE_DEFAULT_AR50LT,
> + .hfi_id = HFI_PROPERTY_CONFIG_VENC_TARGET_BITRATE,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_INPUT_PORT |
> + CAP_FLAG_DYNAMIC_ALLOWED,
> + .set = iris_set_bitrate_gen1,
> + },
> + {
> + .cap_id = BITRATE_MODE,
> + .min = V4L2_MPEG_VIDEO_BITRATE_MODE_VBR,
> + .max = V4L2_MPEG_VIDEO_BITRATE_MODE_CBR,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_BITRATE_MODE_VBR) |
> + BIT(V4L2_MPEG_VIDEO_BITRATE_MODE_CBR),
> + .value = V4L2_MPEG_VIDEO_BITRATE_MODE_VBR,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_RATE_CONTROL,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_bitrate_mode_gen1,
> + },
> + {
> + .cap_id = FRAME_SKIP_MODE,
> + .min = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED,
> + .max = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED) |
> + BIT(V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT),
> + .value = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + },
> + {
> + .cap_id = FRAME_RC_ENABLE,
> + .min = 0,
> + .max = 1,
> + .step_or_mask = 1,
> + .value = 1,
> + },
> + {
> + .cap_id = GOP_SIZE,
> + .min = 0,
> + .max = (1 << 16) - 1,
> + .step_or_mask = 1,
> + .value = 30,
> + .set = iris_set_u32
> + },
> + {
> + .cap_id = ENTROPY_MODE,
> + .min = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC,
> + .max = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC) |
> + BIT(V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC),
> + .value = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_H264_ENTROPY_CONTROL,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_entropy_mode_gen1,
> + },
> + {
> + .cap_id = MIN_FRAME_QP_H264,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP,
> + .step_or_mask = 1,
> + .value = MIN_QP_8BIT_AR50LT,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MIN_FRAME_QP_HEVC,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP_HEVC,
> + .step_or_mask = 1,
> + .value = MIN_QP_8BIT_AR50LT,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MAX_FRAME_QP_H264,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP,
> + .step_or_mask = 1,
> + .value = MAX_QP,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MAX_FRAME_QP_HEVC,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP_HEVC,
> + .step_or_mask = 1,
> + .value = MAX_QP_HEVC,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> +};
> +
> +static const u32 iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl[] = {
> + BUF_BIN,
> + BUF_SCRATCH_1,
> +};
> +
> +const struct iris_firmware_data iris_hfi_gen1_ar50lt_data = {
> + .init_hfi_ops = &iris_hfi_gen1_sys_ops_init,
> +
> + .inst_fw_caps_dec = iris_inst_fw_cap_gen1_ar50lt_dec,
> + .inst_fw_caps_dec_size = ARRAY_SIZE(iris_inst_fw_cap_gen1_ar50lt_dec),
> + .inst_fw_caps_enc = inst_fw_cap_gen1_ar50lt_enc,
> + .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_gen1_ar50lt_enc),
> +
> + .dec_input_config_params_default =
> + sm8250_vdec_input_config_param_default,
> + .dec_input_config_params_default_size =
> + ARRAY_SIZE(sm8250_vdec_input_config_param_default),
> + .enc_input_config_params = sm8250_venc_input_config_param,
> + .enc_input_config_params_size =
> + ARRAY_SIZE(sm8250_venc_input_config_param),
> +
> + .dec_ip_int_buf_tbl = iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl,
> + .dec_ip_int_buf_tbl_size = ARRAY_SIZE(iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl),
> + .dec_op_int_buf_tbl = sm8250_dec_op_int_buf_tbl,
> + .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8250_dec_op_int_buf_tbl),
> +
> + .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> + .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> +};
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> index 6a189489369f..bc04831ae7fc 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> @@ -39,6 +39,10 @@ struct iris_inst;
> #define MAX_HEVC_VBR_LAYER_HP_SLIDING_WINDOW 5
> #define MAX_HIER_CODING_LAYER_GEN1 6
>
> +#define BITRATE_MAX_AR50LT 100000000
> +#define BITRATE_DEFAULT_AR50LT 20000000
> +#define MIN_QP_8BIT_AR50LT 0
> +
> enum stage_type {
> STAGE_1 = 1,
> STAGE_2 = 2,
> @@ -51,8 +55,10 @@ enum pipe_type {
> };
>
> extern const struct iris_firmware_data iris_hfi_gen1_data;
> +extern const struct iris_firmware_data iris_hfi_gen1_ar50lt_data;
> extern const struct iris_firmware_data iris_hfi_gen2_data;
>
> +extern const struct iris_platform_data qcm2290_data;
> extern const struct iris_platform_data qcs8300_data;
> extern const struct iris_platform_data sc7280_data;
> extern const struct iris_platform_data sm8250_data;
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c b/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c
> new file mode 100644
> index 000000000000..393256f39112
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "iris_core.h"
> +#include "iris_ctrls.h"
> +#include "iris_hfi_gen2.h"
> +#include "iris_hfi_gen2_defines.h"
> +#include "iris_platform_common.h"
> +#include "iris_vpu_buffer.h"
> +#include "iris_vpu_common.h"
> +
> +#define WRAPPER_INTR_STATUS_A2HWD_BMSK 0x10
> +
> +const struct iris_firmware_desc iris_vpu_ar50lt_p1_gen1_s6_desc = {
> + .firmware_data = &iris_hfi_gen1_ar50lt_data,
> + .get_vpu_buffer_size = iris_vpu_ar50lt_gen1_buf_size,
unlike gen2, gen1 is calling buffer_requirement from firmware for every
buffer types. And given that call is a synchronous call to firmware i.e
it calls and wait for a response, i see it can cause delay (and infact
not needed) if called for multiple internal buffer types. Can we see if
we can call that call once ? That call to firmware (get prop for
HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS) fetches requirement for all
buffer types.
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: dac: Add DAC8163
From: David Lechner @ 2026-06-24 14:14 UTC (permalink / raw)
To: Lukas Metz
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-iio,
devicetree
In-Reply-To: <ajt0vibLhh6Mmhoc@berta-MS-7693>
On 6/24/26 1:25 AM, Lukas Metz wrote:
> Thanks a lot for the review. This is my first time submitting a
> patch so im grateful for the detailed comments and suggestions.
>
> On Tue, Jun 23, 2026 at 02:17:04PM -0500, David Lechner wrote:
>> It is more logical to put the dt-bindings patch first in the series
>> before the driver that makes use of it.
>
> I will reorder the commits in v2.
For future reference, you don't need to respond to comments that you
agree with (save us time reading).
>
>> There are a couple of more SPI properties needed since this is not a "normal"
>> SPI device. We can only write and not read because there is no D_OUT pin. So
>>
>> spi-rx-bus-width:
>> items:
>> - const: 0
>>
>> will describe this.
>
> I will the add the suggested changes to v2. Are there any other poperties
> i have missed? Same for the other comments regarding vendor-prefix,
> spi-max-frequency, avdd-supply and vref supply name.
>
>> We also want the binding to be complete even if the driver doesn't all of it, so
>> `clear-gpios` and `sync-gpios` probably make sense too.
>
> SYNC pin is the chip select pin of the device as described below. In
> that case i dont need to add it here right?
Ah, OK. It is probably worth mentioning that in the top-level description
here in the bindings.
>
>> Usually, we don't bother with a property like this since it is redundant.
>> If an external reference supply is given, then it gets used, otherwise
>> the internal reference is used.
>
> That sounds logical. I will remove the property completly.
>
>> These chips don't appear to have a chip select pin, so this comment
>> doesn't make sense to me. More logical would be to just use dac@0
>> and reg = <0>; since it should just be ignored.
>
> The SYNC pin on the device acts like a chip select pin.
> According to the datasheet: when the pin goes low it enables the input shift
> register. At least that was my understanding. On my board i have tested the
> driver with the chip select signal connected to the SYNC pin. The
> example comes straight from my own device tree where i have two devices
> on the bus. Thats why i used reg<1> here but i can change it to 0 and
> remove the comment.>
>> The pin is marked active low in the datasheet, so I would expect
>> this to be GPIO_ACTIVE_LOW.
>
> I wasnt sure about that. The pin needs to be held low continuously. I
> thought when the pin is marked active low and i initialize the pin with
> GPIOD_OUT_LOW the result will be that the pin is held high. To match the
> datasheet description seems logical though.
>
The GPIOD_OUT_LOW and GPIOD_OUT_HIGH names in the kernel are not ideal.
Think of them as "deasserted" and "asserted". If the devicetree has
GPIO_ACTIVE_LOW, then GPIOD_OUT_HIGH will "assert" the pin by pulling
the voltage low (because it is active low).
^ permalink raw reply
* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Mark Brown @ 2026-06-24 14:13 UTC (permalink / raw)
To: Rob Herring
Cc: Otto Pflüger, Liam Girdwood, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260624130613.GA4054894-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On Wed, Jun 24, 2026 at 08:06:13AM -0500, Rob Herring wrote:
> On Sat, Jun 20, 2026 at 10:54:00AM +0200, Otto Pflüger wrote:
> > Add bindings for the regulators found in the Spreadtrum/Unisoc SC2730
> > PMIC, used e.g. with the UMS512 and UMS9230 SoCs.
> >
> > Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> > .../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
> > 1 file changed, 44 insertions(+)
> Applied for rc1 to fix the warnings.
Warnings?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-24 14:05 UTC (permalink / raw)
To: Sunyun Yang, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, dmitry.baryshkov, maarten.lankhorst, rfoss,
mripard
Cc: Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNYq5QYAXRzcUBnyvVh5ofPBVYONCs1dM6qPgK0BDja5Ow@mail.gmail.com>
On 11/05/2026 05:28, Sunyun Yang wrote:
> <syyang@lontium.com> 于2026年5月8日周五 22:25写道：
>>
>> From: Sunyun Yang <syyang@lontium.com>
>>
>> LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port
>> mipi dsi and output hdmi, differences in hardware features:
>> - LT9611C: supports 1-port mipi dsi to hdmi 1.4
>> - LT9611EX: supports 2-port mipi dsi to hdmi 1.4
>> - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0
>>
>> Signed-off-by: Sunyun Yang <syyang@lontium.com>
>> ---
>> .../bindings/display/bridge/lontium,lt9611.yaml | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> index 429a06057ae8..e0821a63d9d7 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> @@ -4,19 +4,23 @@
>> $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
>> +title: Lontium LT9611(UXC/C/EX/UXD) 2 Port MIPI DSI to HDMI Bridge
>>
>> maintainers:
>> - Vinod Koul <vkoul@kernel.org>
>>
>> description: |
>> - The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
>> + The LT9611、LT9611UXC、LT9611C、LT9611EX and LT9611UXD
>> + are bridge devices which convert DSI to HDMI
>>
>> properties:
>> compatible:
>> enum:
>> - lontium,lt9611
>> + - lontium,lt9611c
>> + - lontium,lt9611ex
>> - lontium,lt9611uxc
>> + - lontium,lt9611uxd
>>
>> reg:
>> maxItems: 1
>> --
>
> Gentle ping.
> Thanks.
Except mess with threading, your patchset does not build, when applied
on next-20260618.
What is the base of this?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The PCIe PHY node references mipi_pcie_analog_dphy via its phys property.
Enable this analog PHY node to make PCIe functionally viable.
Fixes: 9715b01da6cf ("arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 7ba249cc3d56..4f13e2b041e1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -431,6 +431,10 @@ gpio_speaker: gpio-controller@1f {
};
};
+&mipi_pcie_analog_dphy {
+ status = "okay";
+};
+
&pdm {
pinctrl-0 = <&pdm_dclk_a14_pins>, <&pdm_din0_pins>,
<&pdm_din1_pins>, <&pdm_din2_pins>, <&pdm_din3_pins>;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- 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/
Changes in v3:
- squash "disable pcie_phy node by default" and "enable pcie_phy in
meson-axg-s400" patches
- Link to v2:
https://lore.kernel.org/all/20260617071604.635627-1-jerrysteve1101@gmail.com/
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (4):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for
PCIe
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 8 ++++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Suzuki K Poulose @ 2026-06-24 13:51 UTC (permalink / raw)
To: Jie Gan, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f39ec59f-97c4-4d5f-bf02-560adae312d9@oss.qualcomm.com>
On 24/06/2026 14:48, Jie Gan wrote:
>
>
> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>> its probe function if the arm,primecell-periphid property is absent.
>>> This causes a deferred probe issue for the TraceNoC device, as the
>>> CID/PID cannot be read from the periphid register.
>>
>> Why does it probe defer?
>>
>
> For an AMBA device, the periphid is mandatory for probing. In the
> amba_match function, AMBA attempts to read the periphid from the CID/PID
> registers if the arm,primecell-periphid property is absent in the device
> tree. If this read fails, it returns -EPROBE_DEFER, and the probe
> ultimately fails.
Why does it fail ? power management ? hw broken ? Is it really AMBA or
do you pretend that to be an AMBA device by faking the CID/PID?
Suzuki
> Most AMBA devices expose valid CID/PID registers, so specifying
> arm,primecell-periphid in the device tree is usually unnecessary.
> However, for the TraceNoC device in this case, AMBA cannot reliably read
> the periphid from the corresponding registers.
>
>> And is this required for all TNOC devices?
>
> So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
> platforms, and all exhibit probe failures due to the same root cause.
>
> I prefer to fix it on Kaanapali first.
>
> Thanks,
> Jie
>
>>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 13:48 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f0634a64-1141-4ff9-9033-825e3c75d28d@oss.qualcomm.com>
On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
> On 6/24/26 11:49 AM, Jie Gan wrote:
>> The AMBA bus attempts to read the CID/PID of a device before invoking
>> its probe function if the arm,primecell-periphid property is absent.
>> This causes a deferred probe issue for the TraceNoC device, as the
>> CID/PID cannot be read from the periphid register.
>
> Why does it probe defer?
>
For an AMBA device, the periphid is mandatory for probing. In the
amba_match function, AMBA attempts to read the periphid from the CID/PID
registers if the arm,primecell-periphid property is absent in the device
tree. If this read fails, it returns -EPROBE_DEFER, and the probe
ultimately fails.
Most AMBA devices expose valid CID/PID registers, so specifying
arm,primecell-periphid in the device tree is usually unnecessary.
However, for the TraceNoC device in this case, AMBA cannot reliably read
the periphid from the corresponding registers.
> And is this required for all TNOC devices?
So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
platforms, and all exhibit probe failures due to the same root cause.
I prefer to fix it on Kaanapali first.
Thanks,
Jie
>
> Konrad
^ permalink raw reply
* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 13:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-copper-albatross-of-youth-6abae8@quoll>
Hi Krzysztof,
> Please start testing your patches. This for sure fails tests.
>
> It does not look like you tested the DTS against bindings. Please run
> 'make dtbs_check W=1' (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
You are right, I had tested my patches but wrongly. It is indeed failling.
I'm very sorry for that. Thank's for taking the time to explain.
Best regards,
Grégoire
^ permalink raw reply
* [PATCH] dt-bindings: mfd: khadas,mcu: Drop type reference from "fan-supply"
From: Rob Herring (Arm) @ 2026-06-24 13:36 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Ronald Claveau
Cc: Conor Dooley, linux-amlogic, devicetree, linux-kernel
"fan-supply" already has a type and shouldn't have a type $ref. Drop the
$ref to fix the warning.
Fixes: 39dd85d9246e ("dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
Applying this to my tree and sending to Linus for rc1.
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 1f135618e3b6..c6f91e7bc8aa 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -28,7 +28,6 @@ properties:
fan-supply:
description: Phandle to the regulator that powers the fan.
- $ref: /schemas/types.yaml#/definitions/phandle
required:
- compatible
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
From: William Bright @ 2026-06-24 13:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com>
Hi all,
Another gentle ping on this patch series.
Many thanks,
Will
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Konrad Dybcio @ 2026-06-24 13:28 UTC (permalink / raw)
To: Esteban Urrutia, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <b3541802-3035-40ee-8327-a65bd5d2dfee@proton.me>
On 6/24/26 3:26 PM, Esteban Urrutia wrote:
>
>
> On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>>> This is mentioned in the memory map description, but is not part
>>> of it.
>>>
>>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>>> probably valid
>>
>> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
>> trapping it.
> Then, should device trees delete these memory regions on a case-by-case
> basis, or be left as is?
I'd delete it and reintroduce as necessary
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Konrad Dybcio @ 2026-06-24 13:27 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On 6/24/26 11:49 AM, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
Why does it probe defer?
And is this required for all TNOC devices?
Konrad
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Esteban Urrutia @ 2026-06-24 13:26 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <6123a923-21dd-4f69-9ac5-02165963027c@oss.qualcomm.com>
On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>> This is mentioned in the memory map description, but is not part
>> of it.
>>
>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>> probably valid
>
> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
> trapping it.
Then, should device trees delete these memory regions on a case-by-case
basis, or be left as is?
Regards,
Esteban
^ permalink raw reply
* Re: [PATCH v11] PCI: Add support for PCIe WAKE# interrupt
From: Krishna Chaitanya Chundru @ 2026-06-24 13:25 UTC (permalink / raw)
To: sashiko-reviews; +Cc: linux-pci, devicetree, robh, conor+dt
In-Reply-To: <20260624114008.7F7A51F00A3A@smtp.kernel.org>
On 6/24/2026 5:10 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
> - [High] Hot-removing an endpoint sharing a WAKE# GPIO breaks wakeup for all remaining endpoints on that line.
> - [High] pci_remove_of_wake_gpio() unconditionally clears the device's wakeup configuration and wake IRQ, even if it never acquired the WAKE# GPIO.
> - [High] WAKE# GPIO configuration forces device wakeup to be enabled by default, violating PCI PM policy.
> - [Medium] Calling platform_pci_configure_wake() after device_add() creates a race condition that overwrites driver or userspace wakeup configuration.
> - [Medium] Hardcoded IRQ_TYPE_LEVEL_LOW ignores Device Tree GPIO polarity for the WAKE# interrupt.
> - [Medium] WAKE# GPIO configuration permanently fails if the GPIO provider returns -EPROBE_DEFER.
> --
>
> commit 9e1cd6307066585f1f51b9e7de95ae7950936ba0
> Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> PCI: Add support for PCIe WAKE# interrupt
>
> According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2),
> two link wakeup mechanisms are defined: Beacon and WAKE#. This change adds
> support for the WAKE# mechanism in the PCI core.
>
> Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
> Link: https://github.com/devicetree-org/dt-schema/pull/170
>
>> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
>> index 8b18c4ba845cf..0f5effe1d7026 100644
>> --- a/drivers/pci/of.c
>> +++ b/drivers/pci/of.c
> [ ... ]
>
>> + ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, wake_irq);
>> + if (ret < 0) {
>> + pci_err(pdev, "Failed to set WAKE# IRQ: %d\n", ret);
>> + return;
>> + }
>> +
>> + ret = irq_set_irq_type(wake_irq, IRQ_TYPE_LEVEL_LOW);
> [Severity: Medium]
> Does hardcoding IRQ_TYPE_LEVEL_LOW here override the logical polarity
> specified in the Device Tree?
>
> If the WAKE# GPIO is specified via the wake-gpios property with flags like
> GPIO_ACTIVE_HIGH, this explicit type setting might ignore those flags and
> fail to trigger on platforms with an inverted physical signal.
As per PCIe spec WAKE# is active low signal.
>
>> + if (ret < 0) {
>> + dev_pm_clear_wake_irq(&pdev->dev);
>> + pci_err(pdev, "Failed to set irq_type: %d\n", ret);
>> + return;
>> + }
>> +
>> + device_init_wakeup(&pdev->dev, true);
> [Severity: High]
> Could this forcefully enable wakeup by default and violate standard PCI PM
> policy?
>
> Calling device_init_wakeup() with true marks the device as wakeup capable
> and also sets dev->power.should_wakeup = true. The standard PCI core
> behavior usually marks devices as wakeup capable but leaves enablement to
> userspace opt-in.
if the client driver wants to enable wakeup IRQ, and if the WAKE# is described for
root port only, then we can't ask client driver to enable root port device wake up
capability and in suspend noirq we are not allowed to enable wakeirq, so we
are enabling here.
>> +}
>> +
>> +void pci_configure_of_wake_gpio(struct pci_dev *dev)
>> +{
>> + struct device_node *dn = pci_device_to_OF_node(dev);
>> + struct gpio_desc *gpio;
>> +
>> + if (!dn)
>> + return;
>> + /*
>> + * fwnode_gpiod_get() may fail with -EBUSY (e.g. shared WAKE#), but the
>> + * actual WAKE# trigger from the device would still work and the host
>> + * controller driver will enable power to the topology.
>> + *
>> + * -EPROBE_DEFER cannot be propagated here since pci_device_add() has no
>> + * retry mechanism.
>> + */
>> + gpio = fwnode_gpiod_get(of_fwnode_handle(dn), "wake", GPIOD_IN, NULL);
>> + if (!IS_ERR(gpio)) {
> [Severity: Medium]
> Since pci_device_add() has no retry mechanism, does swallowing -EPROBE_DEFER
> here mean WAKE# functionality will permanently fail if the GPIO controller
> providing the WAKE# line hasn't probed yet?
In device tree model -EPROBE_DEFER for GPIO is highly unlikely. since PERST gpio's
is already parsed in the controller driver before enumeration starts.
> [Severity: High]
> If multiple endpoints share a WAKE# GPIO, only the first device acquires
> it while the rest fail with -EBUSY. Can this break wakeup capabilities
> for all remaining endpoints if the first device is later hot-removed?
>
> When the first device is removed, it frees the shared GPIO via
> pci_remove_of_wake_gpio(), leaving the remaining active endpoints without
> an associated wake IRQ.
in this scenarios, ideally bridge also will share same WAKE# gpio, so if the
bridge
is removed below devices also removed. so it should not effect.
>> + dev->wake = gpio;
>> + pci_configure_wake_irq(dev, gpio);
>> + }
>> +}
>> +
>> +void pci_remove_of_wake_gpio(struct pci_dev *dev)
>> +{
>> + struct device_node *dn = pci_device_to_OF_node(dev);
>> +
>> + if (!dn)
>> + return;
>> +
>> + device_init_wakeup(&dev->dev, false);
>> + dev_pm_clear_wake_irq(&dev->dev);
>> + gpiod_put(dev->wake);
>> + dev->wake = NULL;
>> +}
> [Severity: High]
> Should this cleanup block be guarded by a check for dev->wake?
>
> As it stands, if a PCI device with an OF node failed to acquire the GPIO
> (e.g., it returned -EBUSY) or didn't have a wake property, this will still
> unconditionally clear its PME wakeup capability and detach any dedicated
> wake IRQ the driver might have configured itself.
ack.
- Krishna Chaitanya.
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index b63cd0c310bc0..143b0bd35b3c9 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
> [ ... ]
>
>> @@ -2775,6 +2775,8 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>> /* Establish pdev->tsm for newly added (e.g. new SR-IOV VFs) */
>> pci_tsm_init(dev);
>>
>> + platform_pci_configure_wake(dev);
> [Severity: Medium]
> Does calling platform_pci_configure_wake() after device_add() create a race
> condition?
>
> By the time this is called, the device is already visible in sysfs and
> uevents have fired. Local userspace tools configuring power/wakeup or
> asynchronous driver probes could have their configurations silently
> overwritten by the subsequent device_init_wakeup() call.
>
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64: dts: qcom: Add Vicharak Axon Mini
From: Konrad Dybcio @ 2026-06-24 13:24 UTC (permalink / raw)
To: Ajit Singh, Bjorn Andersson
Cc: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260624125443.18729-4-blfizzyy@gmail.com>
On 6/24/26 2:54 PM, Ajit Singh wrote:
> Add DTS for the Vicharak Axon Mini board based on the Qualcomm
> QCS6490 SoC.
>
> This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0 host, PCIe
> support along with regulators.
>
> The UFS ICE block is kept disabled because enabling it currently causes
> an SError during qcom_ice_create() on this board. UFS works without ICE.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Biju Das @ 2026-06-24 13:24 UTC (permalink / raw)
To: geert
Cc: Krzysztof Kozlowski, biju.das.au, Geert Uytterhoeven, Alex Helms,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, magnus.damm, Brian Masney,
linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <CAMuHMdV67ZuhpSjiu-rWrgyPAMafEDVALD5b0k_bFMYkfQnP8A@mail.gmail.com>
Hi Geert,
> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 24 June 2026 14:16
> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
>
> Hi Biju,
>
> On Wed, 24 Jun 2026 at 11:59, Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > From: Krzysztof Kozlowski <krzk@kernel.org> On 24/06/2026 11:46,
> > > Biju Das wrote:
> > > >> From: Krzysztof Kozlowski <krzk@kernel.org>
> > > >> Sent: 24 June 2026 10:42
> > > >> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7:
> > > >> Update maintainer
> > > >>
> > > >> On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
> > > >>> From: Biju Das <biju.das.jz@bp.renesas.com>
> > > >>>
> > > >>> Alex's email is bouncing. Update the maintainers list with my
> > > >>> contact details to take over the schema maintenance.
> > > >>>
> > > >>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > >>> ---
> > > >>> Ref [1]
> > > >>> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
> > > >>> ---
> > > >>> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
> > > >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> Please also update MAINTAINERS file.
> > > >
> > > > It is taken care in [1]
> > > >
> > > > [1]
> > > > https://lore.kernel.org/all/CAMuHMdW0-WsZuuc7PoVNC5DBUoY9dP+ULmGTQ
> > > > 76VW
> > > > MO_SjpbuQ@mail.gmail.com/
> > >
> > > Just squash them together.
> > >
> > > When you fix such issue like wrong email, fix it everywhere, not
> > > just one-by-one where the maintainers need to poke you to fix in
> > > other places as well. It is generic rule for bugs as well. The wrong email address is the most
> obvious example here, because it is also extremely easy. Just use git grep.
> >
> > Ok, but both patches were already queued by Geert for 7.3.
>
> I will squash them while committing.
Thank you for handling this.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Geert Uytterhoeven @ 2026-06-24 13:16 UTC (permalink / raw)
To: Biju Das
Cc: Krzysztof Kozlowski, biju.das.au, Geert Uytterhoeven, Alex Helms,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, magnus.damm, Brian Masney,
linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB11346A6077B4F7380078EA3B486ED2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi Biju,
On Wed, 24 Jun 2026 at 11:59, Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > From: Krzysztof Kozlowski <krzk@kernel.org>
> > On 24/06/2026 11:46, Biju Das wrote:
> > >> From: Krzysztof Kozlowski <krzk@kernel.org>
> > >> Sent: 24 June 2026 10:42
> > >> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update
> > >> maintainer
> > >>
> > >> On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
> > >>> From: Biju Das <biju.das.jz@bp.renesas.com>
> > >>>
> > >>> Alex's email is bouncing. Update the maintainers list with my
> > >>> contact details to take over the schema maintenance.
> > >>>
> > >>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > >>> ---
> > >>> Ref [1]
> > >>> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
> > >>> ---
> > >>> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
> > >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> Please also update MAINTAINERS file.
> > >
> > > It is taken care in [1]
> > >
> > > [1]
> > > https://lore.kernel.org/all/CAMuHMdW0-WsZuuc7PoVNC5DBUoY9dP+ULmGTQ76VW
> > > MO_SjpbuQ@mail.gmail.com/
> >
> > Just squash them together.
> >
> > When you fix such issue like wrong email, fix it everywhere, not just one-by-one where the maintainers
> > need to poke you to fix in other places as well. It is generic rule for bugs as well. The wrong email
> > address is the most obvious example here, because it is also extremely easy. Just use git grep.
>
> Ok, but both patches were already queued by Geert for 7.3.
I will squash them while committing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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