* Re: [PATCH 0/9] media/arm64: HM1092 IR camera and ASUS Zenbook A14 (X1P42100) camera support
From: Ramshouriesh R @ 2026-06-11 10:55 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Loic Poulain, Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy
In-Reply-To: <8be0a964-e2fc-4c0a-a5ca-0e9e42b3d747@linaro.org>
On Thu, 11 Jun 2026 at 15:31, Vladimir Zapolskiy
<vladimir.zapolskiy@linaro.org> wrote:
> This patch should be removed from consideration, since it is not based on
> the upstream codebase.
>
> I'd suggest you to upstream the sensor driver only through linux-media, which
> is patches 2/9 and 3/8, all other changes should go only after it.
Will do, thanks. This is my first submission, so I hadn't realised the
sensor driver should go on its own. For v2, I'll send the HM1092 binding
and driver as a standalone linux-media series, and then I'll post the
A14 DTS and
PHY enablement separately once the driver and its prerequisites have landed
--
^ permalink raw reply
* Re: [PATCH v3 2/8] soc: qcom: Add support for QMI TMD cooling devices
From: Gaurav Kohli @ 2026-06-11 10:53 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi, Casey Connolly
In-Reply-To: <pyt62qpa75nzdatp5xl7vcqrdzmrzsf5ethw6wq62bzg6b7qtv@ts2v53im4bos>
On 6/9/2026 5:00 PM, Dmitry Baryshkov wrote:
> On Tue, Jun 09, 2026 at 03:52:57PM +0530, Gaurav Kohli wrote:
>> From: Casey Connolly <casey.connolly@linaro.org>
>>
>> Add a Qualcomm QMI Thermal Mitigation Device (TMD) to support thermal
>> cooling devices backed by remote subsystems.
>>
>> On several Qualcomm platforms, remote processors (for example modem and
>> CDSP) expose thermal mitigation controls through the TMD QMI service.
>> Client drivers need a way to discover that service, map DT thermal
>> mitigation endpoints to cooling devices, and forward cooling state
>> updates to the remote subsystem.
>>
>> Co-developed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
>
> Wrong SoB chain.
>
Thanks for review, Ack.
>> ---
>> MAINTAINERS | 6 +
>> drivers/soc/qcom/Kconfig | 10 +
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/qmi_tmd.c | 604 +++++++++++++++++++++++++++++++++++++++
>> include/linux/soc/qcom/qmi.h | 1 +
>> include/linux/soc/qcom/qmi_tmd.h | 23 ++
>> 6 files changed, 645 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 57656ec0e9d5..3d60702a655a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -22286,6 +22286,12 @@ F: Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
>> F: Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst
>> F: drivers/net/ethernet/qualcomm/ppe/
>>
>> +QUALCOMM QMI (REMOTEPROC THERMAL MITIGATION) TMD
>> +M: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> +L: linux-arm-msm@vger.kernel.org
>> +L: linux-pm@vger.kernel.org
>> +F: drivers/soc/qcom/qmi_tmd.c
>> +
>> QUALCOMM QSEECOM DRIVER
>> M: Maximilian Luz <luzmaximilian@gmail.com>
>> L: linux-arm-msm@vger.kernel.org
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 2caadbbcf830..a292ce57fd4a 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -128,6 +128,16 @@ config QCOM_QMI_HELPERS
>> tristate
>> depends on NET
>>
>> +config QCOM_QMI_TMD
>> + bool "Qualcomm QMI TMD library" if COMPILE_TEST
>> + depends on ARCH_QCOM
>> + select QCOM_QMI_HELPERS
>> + help
>> + This enables the QMI-based Thermal Mitigation Device (TMD) library
>> + for Qualcomm remote subsystems. The library manages TMD messaging and
>> + handles QMI communication with remote processors (modem, CDSP) to
>> + exchange mitigation state and apply thermal mitigation requests.
>> +
>> config QCOM_RAMP_CTRL
>> tristate "Qualcomm Ramp Controller driver"
>> depends on ARCH_QCOM || COMPILE_TEST
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index b7f1d2a57367..4544e61c74e7 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -14,6 +14,7 @@ obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
>> obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink_altmode.o
>> obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG) += pmic_pdcharger_ulog.o
>> CFLAGS_pmic_pdcharger_ulog.o := -I$(src)
>> +obj-$(CONFIG_QCOM_QMI_TMD) += qmi_tmd.o
>> obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
>> qmi_helpers-y += qmi_encdec.o qmi_interface.o
>> obj-$(CONFIG_QCOM_RAMP_CTRL) += ramp_controller.o
>> diff --git a/drivers/soc/qcom/qmi_tmd.c b/drivers/soc/qcom/qmi_tmd.c
>> new file mode 100644
>> index 000000000000..9d88ae48c864
>> --- /dev/null
>> +++ b/drivers/soc/qcom/qmi_tmd.c
>> @@ -0,0 +1,604 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2025, Linaro Limited
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + *
>> + * QMI Thermal Mitigation Device (TMD) library.
>> + * This library provides cooling device support for remote subsystems
>> + * (modem and CDSP) running the TMD service via QMI.
>
> Why are you limiting it to these DSPs only? I quickly checked, my X13s
> (sc8280xp) also has one on the ADSP.
>
Adsp is low power dsp, not prone to thermal issues and no TMD service is
up and running. So we are defining for Cdsp and Modem only.
>> + */
>> +#include <linux/cleanup.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/module.h>
>> +#include <linux/net.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/soc/qcom/qmi.h>
>> +#include <linux/soc/qcom/qmi_tmd.h>
>> +#include <linux/thermal.h>
>> +
>> +#define QMI_TMD_INSTANCE_MODEM 0x0
>> +#define QMI_TMD_INSTANCE_CDSP 0x43
>> +#define QMI_TMD_INSTANCE_CDSP1 0x44
>
> Other instances? Are those numbers fixed?
>
> Should we pass the instance ID from the PAS driver instead?
>
thanks for this suggestion, will move instance id part to pas driver.
>> +
>> +#define QMI_TMD_SERVICE_VERS_V01 0x01
>> +
>> +#define QMI_TMD_SET_LEVEL_REQ 0x0021
>> +#define QMI_TMD_GET_DEV_LIST_REQ 0x0020
>> +
>> +#define QMI_TMD_DEV_ID_LEN_MAX 32
>> +#define QMI_TMD_DEV_LIST_MAX 32
>> +#define QMI_TMD_RESP_TIMEOUT msecs_to_jiffies(100)
>> +#define TMD_GET_LEVEL_REQ_MAX_LEN 36
>> +#define TMD_SET_LEVEL_REQ_MAX_LEN 40
>> +
>> +#define TMD_GET_DEV_LIST_REQ_MAX_LEN 0
>> +#define TMD_GET_DEV_LIST_RESP_MAX_LEN 1099
>> +
>> +struct tmd_dev_id {
>> + char mitigation_dev_id[QMI_TMD_DEV_ID_LEN_MAX + 1];
>> +};
>> +
>> +static const struct qmi_elem_info tmd_dev_id_ei[] = {
>> + {
>> + .data_type = QMI_STRING,
>> + .elem_len = QMI_TMD_DEV_ID_LEN_MAX + 1,
>> + .elem_size = sizeof(char),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0,
>> + .offset = offsetof(struct tmd_dev_id,
>> + mitigation_dev_id),
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_dev_list {
>> + struct tmd_dev_id mitigation_dev_id;
>> + u8 max_mitigation_level;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_dev_list_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct tmd_dev_id),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0,
>> + .offset = offsetof(struct tmd_dev_list,
>> + mitigation_dev_id),
>> + .ei_array = tmd_dev_id_ei,
>> + },
>> + {
>> + .data_type = QMI_UNSIGNED_1_BYTE,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0,
>> + .offset = offsetof(struct tmd_dev_list,
>> + max_mitigation_level),
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_get_dev_list_req {
>> + char placeholder;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_get_dev_list_req_ei[] = {
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_get_dev_list_resp {
>> + struct qmi_response_type_v01 resp;
>> + u8 mitigation_device_list_valid;
>> + u32 mitigation_device_list_len;
>> + struct tmd_dev_list
>> + mitigation_device_list[QMI_TMD_DEV_LIST_MAX];
>> +};
>> +
>> +static const struct qmi_elem_info tmd_get_dev_list_resp_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct qmi_response_type_v01),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x02,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + resp),
>> + .ei_array = qmi_response_type_v01_ei,
>> + },
>> + {
>> + .data_type = QMI_OPT_FLAG,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x10,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + mitigation_device_list_valid),
>> + },
>> + {
>> + .data_type = QMI_DATA_LEN,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x10,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + mitigation_device_list_len),
>> + },
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = QMI_TMD_DEV_LIST_MAX,
>> + .elem_size = sizeof(struct tmd_dev_list),
>> + .array_type = VAR_LEN_ARRAY,
>> + .tlv_type = 0x10,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + mitigation_device_list),
>> + .ei_array = tmd_dev_list_ei,
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_set_level_req {
>> + struct tmd_dev_id mitigation_dev_id;
>> + u8 mitigation_level;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_set_level_req_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct tmd_dev_id),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x01,
>> + .offset = offsetof(struct tmd_set_level_req,
>> + mitigation_dev_id),
>> + .ei_array = tmd_dev_id_ei,
>> + },
>> + {
>> + .data_type = QMI_UNSIGNED_1_BYTE,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x02,
>> + .offset = offsetof(struct tmd_set_level_req,
>> + mitigation_level),
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_set_level_resp {
>> + struct qmi_response_type_v01 resp;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_set_level_resp_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct qmi_response_type_v01),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x02,
>> + .offset = offsetof(struct tmd_set_level_resp, resp),
>> + .ei_array = qmi_response_type_v01_ei,
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +/**
>> + * struct qmi_tmd - A TMD cooling device
>> + * @name: The name of this tmd shared by the remote subsystem
>> + * @cdev: Thermal cooling device handle
>> + * @cur_state: The current mitigation state
>> + * @max_state: The maximum state
>> + * @qmi_tmd_cli: Parent QMI TMD client
>> + */
>> +struct qmi_tmd {
>> + const char *name;
>> + struct thermal_cooling_device *cdev;
>> + unsigned int cur_state;
>> + unsigned int max_state;
>> + struct qmi_tmd_client *qmi_tmd_cli;
>> +};
>> +
>> +/**
>> + * struct qmi_tmd_client - QMI TMD client state
>> + * @dev: Device associated with this instance
>> + * @handle: QMI connection handle
>> + * @mutex: Lock to synchronise QMI communication
>
> What is it protecting?
>
Ack, will add more comment for this.
This is to serialize all TMD client qmi request/response sequences such
as qmi_txn_init, qmi_send_request during Dsp subsystem restart.
>> + * @connection_active: Whether or not we're connected to the QMI TMD service
>> + * @svc_arrive_work: Work item for initialising when the TMD service starts
>> + * @num_tmds: Number of tmds described in the device tree
>> + * @tmds: An array of tmd structures
>> + */
>> +struct qmi_tmd_client {
>> + struct device *dev;
>> + struct qmi_handle handle;
>> + /* protects QMI transactions and connection_active */
>> + struct mutex mutex;
>> + bool connection_active;
>> + struct work_struct svc_arrive_work;
>> + int num_tmds;
>> + struct qmi_tmd tmds[] __counted_by(num_tmds);
>> +};
>> +
>> +/* Notify the remote subsystem of the requested cooling state */
>> +static int qmi_tmd_send_state_request(struct qmi_tmd *tmd, int state)
>> +{
>> + struct tmd_set_level_resp resp = { 0 };
>> + struct tmd_set_level_req req = { 0 };
>> + struct qmi_tmd_client *qmi_tmd_cli = tmd->qmi_tmd_cli;
>> + struct qmi_txn txn;
>> + int ret = 0;
>> +
>> + guard(mutex)(&qmi_tmd_cli->mutex);
>> +
>> + if (!qmi_tmd_cli->connection_active)
>> + return 0;
>> +
>> + strscpy(req.mitigation_dev_id.mitigation_dev_id, tmd->name,
>> + QMI_TMD_DEV_ID_LEN_MAX + 1);
>> + req.mitigation_level = state;
>> +
>> + ret = qmi_txn_init(&qmi_tmd_cli->handle, &txn,
>> + tmd_set_level_resp_ei, &resp);
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "qmi set state %d txn init failed for %s ret %d\n",
>> + state, tmd->name, ret);
>> + return ret;
>> + }
>> +
>> + ret = qmi_send_request(&qmi_tmd_cli->handle, NULL, &txn,
>> + QMI_TMD_SET_LEVEL_REQ,
>> + TMD_SET_LEVEL_REQ_MAX_LEN,
>> + tmd_set_level_req_ei, &req);
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "qmi set state %d txn send failed for %s ret %d\n",
>> + state, tmd->name, ret);
>> + qmi_txn_cancel(&txn);
>> + return ret;
>> + }
>> +
>> + ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "qmi set state %d txn wait failed for %s ret %d\n",
>> + state, tmd->name, ret);
>> + return ret;
>> + }
>> +
>> + if (resp.resp.result != QMI_RESULT_SUCCESS_V01) {
>> + dev_err(qmi_tmd_cli->dev,
>> + "qmi set state %d failed for %s result %#x error %#x\n",
>> + state, tmd->name,
>> + resp.resp.result, resp.resp.error);
>> + return -EREMOTEIO;
>> + }
>> +
>> + dev_dbg(qmi_tmd_cli->dev, "Requested state %d/%d for %s\n", state,
>> + tmd->max_state, tmd->name);
>> +
>> + return 0;
>> +}
>> +
>> +static int qmi_tmd_get_max_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct qmi_tmd *tmd = cdev->devdata;
>> +
>> + *state = tmd->max_state;
>> +
>> + return 0;
>> +}
>> +
>> +static int qmi_tmd_get_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct qmi_tmd *tmd = cdev->devdata;
>> +
>> + *state = tmd->cur_state;
>
> Mutex protection?
>
This callback only reads the cached local state and does not perform any
QMI transaction, that's why not using lock here.
>> +
>> + return 0;
>> +}
>> +
>> +static int qmi_tmd_set_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long state)
>> +{
>> + struct qmi_tmd *tmd = cdev->devdata;
>> + int ret;
>> +
>> + if (state > tmd->max_state)
>> + return -EINVAL;
>> +
>> + if (tmd->cur_state == state)
>> + return 0;
>
> Hmm, again, mutex protection for the cur_state? Or is it provided by the
> thermal core?
>
Yes, it is already protected by cdev->lock.
>> +
>> + ret = qmi_tmd_send_state_request(tmd, state);
>> + if (!ret)
>> + tmd->cur_state = state;
>> +
>> + return ret;
>> +}
>> +
>> +static const struct thermal_cooling_device_ops qmi_tmd_cooling_ops = {
>> + .get_max_state = qmi_tmd_get_max_state,
>> + .get_cur_state = qmi_tmd_get_cur_state,
>> + .set_cur_state = qmi_tmd_set_cur_state,
>> +};
>> +
>> +static int qmi_tmd_register(struct qmi_tmd_client *qmi_tmd_cli,
>> + const char *label, u8 max_state)
>> +{
>> + struct device *dev = qmi_tmd_cli->dev;
>> + struct qmi_tmd *tmd;
>> + int index;
>> +
>> + for (index = 0; index < qmi_tmd_cli->num_tmds; index++) {
>> + tmd = &qmi_tmd_cli->tmds[index];
>> +
>> + if (!strncasecmp(tmd->name, label,
>> + QMI_TMD_DEV_ID_LEN_MAX + 1))
>> + goto found;
>> + }
>> +
>> + dev_dbg(qmi_tmd_cli->dev,
>> + "TMD '%s' available in firmware but not specified in DT\n",
>> + label);
>
> If we can read them from the firmware, why do you need to specify them
> in DT?
>
We need DT, because cooling-device binding is index-based as per new
thermal framework changes:
https://lore.kernel.org/all/20260526140802.1059293-12-daniel.lezcano@oss.qualcomm.com/
And also the firmware list is name-based and ordering is not consistent
across platforms/firmware. DT provides the explicit set and order of
TMDs that thermal framework should bind. Firmware may also expose
additional/virtual TMD's that are not used for binding with thermal zone.
>> + return 0;
>> +
>> +found:
>> + tmd->max_state = max_state;
>> +
>> + /*
>> + * If the cooling device already exists then the QMI service went away and
>> + * came back. So just make sure the current cooling device state is
>> + * reflected on the remote side and then return.
>> + */
>> + if (tmd->cdev)
>> + return qmi_tmd_send_state_request(tmd, tmd->cur_state);
>> +
>> + tmd->cdev = thermal_of_cooling_device_register(dev->of_node, index,
>> + label, tmd, &qmi_tmd_cooling_ops);
>> + if (IS_ERR(tmd->cdev))
>> + return PTR_ERR(tmd->cdev);
>> +
>> + return 0;
>> +}
>> +
>> +static void qmi_tmd_unregister(struct qmi_tmd_client *qmi_tmd_cli)
>> +{
>> + struct qmi_tmd *tmd;
>> + int index;
>> +
>> + for (index = 0; index < qmi_tmd_cli->num_tmds; index++) {
>> + tmd = &qmi_tmd_cli->tmds[index];
>> +
>> + if (!tmd->cdev)
>> + continue;
>> +
>> + thermal_cooling_device_unregister(tmd->cdev);
>> + tmd->cdev = NULL;
>> + }
>> +}
>> +
>> +static void qmi_tmd_svc_arrive(struct work_struct *work)
>> +{
>> + struct qmi_tmd_client *qmi_tmd_cli =
>> + container_of(work, struct qmi_tmd_client, svc_arrive_work);
>> +
>> + struct tmd_get_dev_list_req req = { 0 };
>> + struct tmd_get_dev_list_resp *resp __free(kfree) = NULL;
>> + int ret, i;
>> + struct qmi_txn txn;
>> +
>> + resp = kzalloc_obj(*resp, GFP_KERNEL);
>> + if (!resp) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex) {
>> + ret = qmi_txn_init(&qmi_tmd_cli->handle, &txn,
>> + tmd_get_dev_list_resp_ei, resp);
>> + if (ret < 0)
>> + goto out;
>> +
>> + ret = qmi_send_request(&qmi_tmd_cli->handle, NULL, &txn,
>> + QMI_TMD_GET_DEV_LIST_REQ,
>> + TMD_GET_DEV_LIST_REQ_MAX_LEN,
>> + tmd_get_dev_list_req_ei, &req);
>> + if (ret < 0) {
>> + qmi_txn_cancel(&txn);
>> + goto out;
>> + }
>> +
>> + ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
>> + if (ret < 0)
>> + goto out;
>> +
>> + if (resp->resp.result != QMI_RESULT_SUCCESS_V01) {
>> + ret = -EPROTO;
>> + goto out;
>> + }
>> +
>> + qmi_tmd_cli->connection_active = true;
>> + }
>> +
>> + for (i = 0; i < resp->mitigation_device_list_len; i++) {
>> + struct tmd_dev_list *device =
>> + &resp->mitigation_device_list[i];
>> +
>> + ret = qmi_tmd_register(qmi_tmd_cli,
>> + device->mitigation_dev_id.mitigation_dev_id,
>> + device->max_mitigation_level);
>> + if (ret)
>> + break;
>> + }
>> +
>> +out:
>> + if (ret)
>> + dev_err(qmi_tmd_cli->dev, "Failed to initialize TMD service: %d\n", ret);
>> +}
>> +
>> +static void qmi_tmd_del_server(struct qmi_handle *qmi, struct qmi_service *service)
>> +{
>> + struct qmi_tmd_client *qmi_tmd_cli =
>> + container_of(qmi, struct qmi_tmd_client, handle);
>> +
>> + kernel_sock_shutdown(qmi->sock, SHUT_RDWR);
>
> So, connection is protected by the mutex, but socket shutdown isn't.
> Why?
>
Ack.
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex)
>> + qmi_tmd_cli->connection_active = false;
>> +}
>> +
>> +static int qmi_tmd_new_server(struct qmi_handle *qmi, struct qmi_service *service)
>> +{
>> + struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node, service->port };
>> + struct qmi_tmd_client *qmi_tmd_cli;
>> + int ret;
>> +
>> + qmi_tmd_cli = container_of(qmi, struct qmi_tmd_client, handle);
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex) {
>> + ret = kernel_connect(qmi->sock, (struct sockaddr_unsized *)&sq,
>> + sizeof(sq), 0);
>> + }
>> +
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "QMI connect failed for node %u port %u: %d\n",
>> + service->node, service->port, ret);
>> + return ret;
>> + }
>> +
>> + queue_work(system_highpri_wq, &qmi_tmd_cli->svc_arrive_work);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct qmi_ops qmi_tmd_ops = {
>> + .new_server = qmi_tmd_new_server,
>> + .del_server = qmi_tmd_del_server,
>> +};
>> +
>> +static int qmi_tmd_get_instance_id(const char *remoteproc_name)
>> +{
>> + if (!strcmp(remoteproc_name, "modem"))
>> + return QMI_TMD_INSTANCE_MODEM;
>> +
>> + if (!strcmp(remoteproc_name, "cdsp"))
>> + return QMI_TMD_INSTANCE_CDSP;
>> +
>> + if (!strcmp(remoteproc_name, "cdsp1"))
>> + return QMI_TMD_INSTANCE_CDSP1;
>> +
>> + return -ENODEV;
>
> Okay, this definitely should be coming from the PAS driver, being a part
> of the platform data.
>
thanks for this suggestion, let me check with this approach and make
changes.
>> +}
>> +
>> +/**
>> + * qmi_tmd_init() - Initialize QMI TMD instance
>> + * @dev: Device pointer
>> + * @remoteproc_name: Remoteproc name (for example modem, cdsp)
>> + * @tmd_names: Array of TMD names
>> + * @num_tmds: Number of TMD names
>> + *
>> + * Return: Pointer to qmi_tmd_client on success, ERR_PTR on failure
>> + */
>> +struct qmi_tmd_client *qmi_tmd_init(struct device *dev,
>> + const char *remoteproc_name,
>> + const char * const *tmd_names,
>> + int num_tmds)
>> +{
>> + struct qmi_tmd_client *qmi_tmd_cli;
>> + int ret, i, instance_id;
>> +
>> + if (!dev || !remoteproc_name || !tmd_names || num_tmds <= 0)
>> + return ERR_PTR(-EINVAL);
>> +
>> + instance_id = qmi_tmd_get_instance_id(remoteproc_name);
>> + if (instance_id < 0) {
>> + dev_err(dev, "Unsupported remoteproc name '%s' for TMD lookup\n",
>> + remoteproc_name);
>> + return ERR_PTR(instance_id);
>> + }
>> +
>> + qmi_tmd_cli = devm_kzalloc(dev, struct_size(qmi_tmd_cli, tmds, num_tmds), GFP_KERNEL);
>> + if (!qmi_tmd_cli)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + qmi_tmd_cli->dev = dev;
>> + qmi_tmd_cli->num_tmds = num_tmds;
>> + mutex_init(&qmi_tmd_cli->mutex);
>> + INIT_WORK(&qmi_tmd_cli->svc_arrive_work, qmi_tmd_svc_arrive);
>> +
>> + /* Initialize TMD structures */
>
> Is it a useful comment?
>
>> + for (i = 0; i < num_tmds; i++) {
>> + qmi_tmd_cli->tmds[i].name = tmd_names[i];
>> + qmi_tmd_cli->tmds[i].qmi_tmd_cli = qmi_tmd_cli;
>> + }
>> +
>> + ret = qmi_handle_init(&qmi_tmd_cli->handle,
>> + TMD_GET_DEV_LIST_RESP_MAX_LEN,
>> + &qmi_tmd_ops, NULL);
>> + if (ret < 0) {
>> + dev_err(dev, "QMI handle init failed: %d\n", ret);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + ret = qmi_add_lookup(&qmi_tmd_cli->handle, QMI_SERVICE_ID_TMD,
>> + QMI_TMD_SERVICE_VERS_V01, instance_id);
>> + if (ret < 0) {
>> + dev_err(dev, "QMI add lookup failed: %d\n", ret);
>> + goto err_release_handle;
>> + }
>> +
>> + return qmi_tmd_cli;
>> +
>> +err_release_handle:
>> + qmi_handle_release(&qmi_tmd_cli->handle);
>> +
>> + return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(qmi_tmd_init);
>> +
>> +/**
>> + * qmi_tmd_exit() - Deinitialize QMI TMD instance
>> + * @qmi_tmd_cli: QMI TMD client to deinitialize
>> + */
>> +void qmi_tmd_exit(struct qmi_tmd_client *qmi_tmd_cli)
>> +{
>> + if (!qmi_tmd_cli)
>> + return;
>> +
>> + cancel_work_sync(&qmi_tmd_cli->svc_arrive_work);
>> + qmi_handle_release(&qmi_tmd_cli->handle);
>> + qmi_tmd_unregister(qmi_tmd_cli);
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex)
>> + qmi_tmd_cli->connection_active = false;
>> +}
>> +EXPORT_SYMBOL_GPL(qmi_tmd_exit);
>
^ permalink raw reply
* Re: [PATCH v5 3/4] clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 clocks support on Agatti
From: Imran Shaik @ 2026-06-11 10:52 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Richard Cochran,
Brian Masney
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, Krzysztof Kozlowski,
linux-arm-msm, linux-clk, devicetree, linux-kernel, netdev
In-Reply-To: <b86e9f5f-a7ec-489e-829e-6e07c62841a3@oss.qualcomm.com>
On 11-06-2026 03:10 pm, Konrad Dybcio wrote:
> On 6/8/26 2:21 PM, Imran Shaik wrote:
>> Add support for missing RF_CLK1/RF_CLK2 clocks on Qualcomm Agatti (QCM2290)
>> SoC.
>>
>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>> ---
>> drivers/clk/qcom/clk-smd-rpm.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
>> index 103db984a40b950bd33fba668a292be46af6326e..0b624ed4715c75042b92ec49c073b281533cace4 100644
>> --- a/drivers/clk/qcom/clk-smd-rpm.c
>> +++ b/drivers/clk/qcom/clk-smd-rpm.c
>> @@ -495,6 +495,7 @@ DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(rf_clk2, 5, 19200000);
>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(rf_clk3, 6, 19200000);
>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(ln_bb_clk, 8, 19200000);
>>
>> +DEFINE_CLK_SMD_RPM_XO_BUFFER_PREFIX(38m4_, rf_clk2, 5, 38400000);
>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PREFIX(38m4_, rf_clk3, 6, 38400000);
>>
>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(cxo_d0, 1, 19200000);
>> @@ -1262,6 +1263,10 @@ static struct clk_smd_rpm *qcm2290_clks[] = {
>> [RPM_SMD_QDSS_A_CLK] = &clk_smd_rpm_branch_qdss_a_clk,
>> [RPM_SMD_LN_BB_CLK2] = &clk_smd_rpm_ln_bb_clk2,
>> [RPM_SMD_LN_BB_CLK2_A] = &clk_smd_rpm_ln_bb_clk2_a,
>> + [RPM_SMD_RF_CLK1] = &clk_smd_rpm_rf_clk1,
>> + [RPM_SMD_RF_CLK1_A] = &clk_smd_rpm_rf_clk1_a,
>
> Is RF_CLK1 19.2 MHz (with the other RFCLKs being 38.4) on purpose?
>
Yes Konrad, as per the hardware connectivity, RF_CLK1 runs at 19.2 MHz,
while the other RF clocks operate at 38.4 MHz.
Thanks,
Imran
^ permalink raw reply
* Re: [PATCH V11 4/9] iio: imu: inv_icm42607: Add I2C and SPI For icm42607
From: Jonathan Cameron @ 2026-06-11 10:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <aipolU1W3QNXdd5b@ashevche-desk.local>
On Thu, 11 Jun 2026 10:49:41 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Wed, Jun 10, 2026 at 12:54:48PM -0500, Chris Morgan wrote:
>
> > Add I2C and SPI driver support for InvenSense ICM-42607 devices.
> > Add necessary Kconfig and Makefile to allow building of (incomplete)
> > driver.
>
> ...
>
> > drivers/iio/imu/Kconfig | 1 +
> > drivers/iio/imu/Makefile | 1 +
> > drivers/iio/imu/inv_icm42607/Kconfig | 30 +++++
> > drivers/iio/imu/inv_icm42607/Makefile | 10 ++
>
> These should be part of the previous patch.
>
> ...
>
> > +config INV_ICM42607
> > + tristate
>
> To make it compilable w.o. SPI/I2C make this as
>
> tristate "Inven... Core driver" if COMPILE_TEST
Hi Andy,
Is it worth it? I'm not convinced - we will get pretty
good build coverage with a dependence on either SPI or I2C.
Plus as someone who always builds with COMPILE_TEST this
seems overly noisy to me.
Jonathan
^ permalink raw reply
* Re: [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Krzysztof Kozlowski @ 2026-06-11 10:51 UTC (permalink / raw)
To: Zhang Yi; +Cc: linux-sound, broonie, devicetree, tiwai, robh, krzk+dt, conor+dt
In-Reply-To: <20260611-mamba-of-legendary-anger-af76a9@quoll>
On 11/06/2026 12:45, Krzysztof Kozlowski wrote:
> On Thu, Jun 11, 2026 at 11:18:18AM +0800, Zhang Yi wrote:
>> Add members related to HPF and mclk_source
>> The value of HPF is not dB, it is just the value of registers
>> And add HPF settings to the example
>>
>> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
>> ---
>> .../bindings/sound/everest,es8389.yaml | 23 +++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>
> So this is like third time you send the same.
>
> You never responded to feedback, I don't see improvements and you keep
> sending the same v1.
>
> Version your patches correctly - read help of git format-patch or just
> use b4.
>
> NAK again because you just ignore us.
This was v1:
https://lore.kernel.org/all/20260608083540.12581-1-zhangyi@everest-semi.com/
Then you send v2 calling it v1:
https://lore.kernel.org/all/20260609025605.16945-1-zhangyi@everest-semi.com/
Then you sent it again:
https://lore.kernel.org/all/20260609030623.17404-1-zhangyi@everest-semi.com/
And now you send v4 (??!?) calling it v1:
https://lore.kernel.org/all/20260611031824.4628-1-zhangyi@everest-semi.com/
All within three days. And in the same time you never responded to
actual feedback.
This is not acceptable. Please stop spamming the list with the same
version and respond to the feedback. I expect addressing EVERY email you
received with reviews.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/8] irqchip/qcom-pdc: restructure version support
From: Konrad Dybcio @ 2026-06-11 10:50 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260526-hamoa_pdc-v2-1-f6857af1ce91@oss.qualcomm.com>
On 5/26/26 12:54 PM, Maulik Shah wrote:
> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
> as below on various SoCs.
[...]
> +struct pdc_desc {
> + void __iomem *base;
> + void __iomem *prev_base;
> + u32 version;
> + const struct pdc_regs *regs;
> + const struct pdc_cfg *cfg;
"cfg" is a bit vague, perhaps irq_cfg_fields or something similar?
That said, "irq_cfg_fields" isn't very catchy, so if you have a better
name, go ahead
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/8] irqchip/qcom-pdc: restructure version support
From: Konrad Dybcio @ 2026-06-11 10:48 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260526-hamoa_pdc-v2-1-f6857af1ce91@oss.qualcomm.com>
On 5/26/26 12:54 PM, Maulik Shah wrote:
> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
> as below on various SoCs.
[...]
> +static const struct pdc_cfg pdc_cfg_v3_2 = {
> + .irq_enable = GENMASK(3, 3),
BIT(3)
[...]
> + pdc->base = ioremap(res.start, res_size);
Can we use devm_ioremap() here?
[...]
> if (of_device_is_compatible(node, "qcom,x1e80100-pdc")) {
> - pdc_prev_base = ioremap(res.start - PDC_DRV_SIZE, IRQ_ENABLE_BANK_MAX);
> - if (!pdc_prev_base) {
> + pdc->prev_base = ioremap(res.start - PDC_DRV_SIZE,
> + pdc->regs->irq_en_reg + IRQ_ENABLE_BANK_MAX);
likewise
Konrad
^ permalink raw reply
* Re: [PATCH v1 3/7] ASoC: codecs: ES8389: Fix the issue about mclk_src
From: Krzysztof Kozlowski @ 2026-06-11 10:46 UTC (permalink / raw)
To: Zhang Yi; +Cc: linux-sound, broonie, devicetree, tiwai, robh, krzk+dt, conor+dt
In-Reply-To: <20260611031824.4628-4-zhangyi@everest-semi.com>
On Thu, Jun 11, 2026 at 11:18:20AM +0800, Zhang Yi wrote:
> Fix the issue with incorrect modifications to mclk_src
> When the system needs to be configured to use the MCLK from the SCLK pin,
> the code still sets the relevant registers to use the MCLK from the MCLK pin
> And setting `mclk_src` to `u8` is inappropriate,
> because the purpose of `mclk_src` is to determine whether to use SCLK as MCLK.
> Therefore, we will change the `mclk_src` member from `u8` to `bool`.
>
> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
NAK, same comments as before. You just ignore feedback.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Krzysztof Kozlowski @ 2026-06-11 10:45 UTC (permalink / raw)
To: Zhang Yi; +Cc: linux-sound, broonie, devicetree, tiwai, robh, krzk+dt, conor+dt
In-Reply-To: <20260611031824.4628-2-zhangyi@everest-semi.com>
On Thu, Jun 11, 2026 at 11:18:18AM +0800, Zhang Yi wrote:
> Add members related to HPF and mclk_source
> The value of HPF is not dB, it is just the value of registers
> And add HPF settings to the example
>
> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
> ---
> .../bindings/sound/everest,es8389.yaml | 23 +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
So this is like third time you send the same.
You never responded to feedback, I don't see improvements and you keep
sending the same v1.
Version your patches correctly - read help of git format-patch or just
use b4.
NAK again because you just ignore us.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
From: Krzysztof Kozlowski @ 2026-06-11 10:42 UTC (permalink / raw)
To: Wadim Mueller, Jonathan Cameron
Cc: Krzysztof Kozlowski, Rob Herring, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Maxwell Doose, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260611-slf3s-v3-reply-compatibles-decision-wafgo01@gmail.com>
On 11/06/2026 12:35, Wadim Mueller wrote:
> Hi Krzysztof, Jonathan,
>
> for v4 I'd like to keep the three specific per-variant compatibles from
> v3 (sensirion,slf3s-0600f / -1300f / -4000b) and no generic fallback,
> since the flow scale differs per sub-type.
>
> Krzysztof, is that ok for you?
You should have a specific fallback (since we did not reach consensus on
more generic fallback). All your three variants are fully detectable.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/8] x1e80100: Enable PDC wake GPIOs and deepest idle state
From: Konrad Dybcio @ 2026-06-11 10:41 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad,
Stephan Gerhold
In-Reply-To: <20260526-hamoa_pdc-v2-0-f6857af1ce91@oss.qualcomm.com>
On 5/26/26 12:54 PM, Maulik Shah wrote:
> There are two modes PDC irqchip can work in
> - pass through mode
> - secondary controller mode
>
> Secondary mode is supported depending on SoC using PDC HW Version v3.0
> or higher.
[...]
> base-commit: 550604d6c9b9efc8d068aff94dc301694a7afdee
> change-id: 20260522-hamoa_pdc-1517acc2dcd4
> prerequisite-message-id: <20260410184124.1068210-1-mukesh.ojha@oss.qualcomm.com>
> prerequisite-patch-id: 152df6e30f70eb1b45909ce2793bc4277554b7ff
> prerequisite-patch-id: 118bd4216e0386e7214133f53153684947fa8dd3
> prerequisite-patch-id: 1f2f272d8ad1f7930d462e6349bc49de815e1ba1
> prerequisite-patch-id: 3754ffdf536206353f74953fd6d39804ff7787d4
This does depend on the changes you made on the driver, but not on
the 30 bundled DT changes - let's just point to the actual dependencies
Konrad
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C
From: Krzysztof Kozlowski @ 2026-06-11 10:40 UTC (permalink / raw)
To: Mohit Dsor
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-1-42abbcd3bb1e@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
> Add a new optional `lontium,port-select` property to describe the DSI
> input port configuration for the LT9611C variant, which supports
> single-port (A or B) and dual-port (A+B) operation.
>
> This property allows explicitly selecting the active DSI input port(s):
> 0 = port A (default)
> 1 = port B
> 2 = ports A and B (dual-port)
>
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> ---
> .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> index e0821a63d9d7..77220f893bf8 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> @@ -41,6 +41,17 @@ properties:
> vcc-supply:
> description: Regulator for 3.3V IO power.
>
> + lontium,port-select:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2]
> + default: 0
> + description: |
> + Selects which DSI input port(s) the bridge uses. Only relevant for
> + the lontium,lt9611c compatible.
> + 0 = PORT_SELECT_A - single DSI port A (default)
> + 1 = PORT_SELECT_B - single DSI port B
> + 2 = PORT_SELECT_AB - dual DSI ports A and B
Why graph is not enough? Seems exactly duplicating the graph ports.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,usb-hs-phy: add qcom,vendor-init-seq
From: Konrad Dybcio @ 2026-06-11 10:39 UTC (permalink / raw)
To: Dmitry Baryshkov, github.com, me
Cc: linux-phy, devicetree, linux-arm-msm, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson
In-Reply-To: <46lrfwoahgzoudq3afnhv4kxqs4fwj3w7u2dnx6ns6soo6pxt2@qkqbelan2iwq>
On 6/4/26 1:02 AM, Dmitry Baryshkov wrote:
> On Wed, Jun 03, 2026 at 06:09:18PM +0200, me@herrie.org wrote:
>> On 2026-06-03 15:57, Dmitry Baryshkov wrote:
>>> On Wed, Jun 03, 2026 at 07:48:08AM +0200, Herman van Hazendonk wrote:
>>>> Add an optional "qcom,vendor-init-seq" property carrying raw ULPI
>>>> (address, value) pairs that are written after PHY reset.
>>>>
>>>> Unlike the existing "qcom,init-seq" property, the address field is
>>>> NOT offset by ULPI_EXT_VENDOR_SPECIFIC, so the new property can
>>>> reach the standard ULPI vendor register range (0x30-0x3f). MSM8x60-
>>>> class hardware needs this range to programme pre-emphasis, HS driver
>>>> slope and CDR auto-reset bits the legacy msm_otg driver used to set
>>>> via platform data.
>>>
>>> Are those register writes specific to the device or to the whole
>>> platform? In the latter case please extend the driver to write them.
>>
>> Looking at every MSM8x60 reference kernel I could find (Qualcomm's own
>> msm8x60 board, HP TouchPad / APQ8060, and some HTC/Saumsung MSM8660
>> devices), the writes split into two groups:
>>
>> Platform-level (same across all MSM8x60 hardware):
>> - reg 0x36 bits 1+2: CDR auto-reset disabled, SE1 gating disabled
>> - reg 0x32 bits [5:4]: pre-emphasis at 20%
>>
>> Board-specific:
>> - reg 0x32 bits [3:0]: HS driver slope — HP TouchPad uses 5, HTC
>> devices use 1. This clearly depends on board layout (trace length,
>> connector loading, etc.).
>>
>> So the platform-level writes should move unconditionally into the driver
>> behind a match-data flag for the MSM8x60-class compatible, and only the
>> HS driver slope value belongs in DT.
>
> Looks like it. Please hardcode the value for your platform in the driver
> (with the comment), meanwhile we can try looking up the actual values.
Do we have the values for a MTP/QRD (or whatever they used to be called
back then..), like we would usually put in there?
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Krzysztof Kozlowski @ 2026-06-11 10:39 UTC (permalink / raw)
To: Amit Barzilai
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, javierm,
robh, krzk+dt, conor+dt, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260610164428.180091-2-amit.barzilai22@gmail.com>
> +properties:
> + compatible:
> + enum:
> + - solomon,ssd1351
> +
> + solomon,width:
> + default: 128
> +
> + solomon,height:
> + default: 128
Drop both - deducible from the compatible.
> +
> + rotation: true
Either drop or reference panel-common (if this is a panel) or at least
reference that property:
$ref: /schemas/display/panel/panel-common.yaml#/properties/rotation
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + oled@0 {
> + compatible = "solomon,ssd1351";
> + reg = <0x0>;
> + reset-gpios = <&gpio2 7>;
> + dc-gpios = <&gpio2 8>;
Use proper defines for GPIO flags
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] of: property: Fix of_fwnode_get_reference_args() with negative index
From: sashiko-bot @ 2026-06-11 10:39 UTC (permalink / raw)
To: Alban Bedel; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260611102806.2643869-1-alban.bedel@lht.dlh.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Integer overflow in the bounds check of `software_node_get_reference_args` allows out-of-bounds memory read and potential kernel panic.
--
commit c268eb898558d8f55476cb8562a12b6fa754123b
Author: Alban Bedel <alban.bedel@lht.dlh.de>
of: property: Fix of_fwnode_get_reference_args() with negative index
This commit catches negative index values that are implicitly cast to
unsigned in the fwnode API before they are passed to the OF backend.
It ensures out-of-bounds indices return -ENOENT instead of -EINVAL.
Link: https://lore.kernel.org/linux-leds/aimVRwJPhlGxsIUj@tom-desktop/T/#mc43cbf7e0599991b56dd0d9680714d28d145fbc8
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 136946f8b746f..eace2d1847b99 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1157,6 +1157,13 @@ of_fwnode_get_reference_args(const struct fwnode_handle *fwnode,
> unsigned int i;
> int ret;
>
> + /* This function should return -ENOENT for out of bound indexes,
> + * but the OF API uses signed indexes and consider negative indexes
> + * as invalid. Catch them here to correctly implement the fwnode API.
> + */
> + if ((int)index < 0)
> + return -ENOENT;
[Severity: High]
This is a pre-existing issue, but does this exact same implicit cast pattern
cause a regression in the software node backend?
Looking at software_node_get_reference_args() in drivers/base/swnode.c:
drivers/base/swnode.c:software_node_get_reference_args() {
...
if ((index + 1) * sizeof(*ref) > prop->length)
return -ENOENT;
ref_array = prop->pointer;
ref = &ref_array[index];
...
}
If index is 0xffffffff (from a -1 return value implicitly cast to unsigned),
index + 1 wraps around to 0. The check 0 * sizeof(*ref) evaluates as not
greater than prop->length, completely bypassing the bounds check.
Could this lead to an out-of-bounds array access when computing
&ref_array[index], causing a panic when dereferenced?
Should a similar check for negative indices be added to the swnode backend?
> +
> if (nargs_prop)
> ret = of_parse_phandle_with_args(to_of_node(fwnode), prop,
> nargs_prop, index, &of_args);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611102806.2643869-1-alban.bedel@lht.dlh.de?part=1
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: usb: dwc3: document snps,reinit-phy-on-resume
From: Konrad Dybcio @ 2026-06-11 10:37 UTC (permalink / raw)
To: Rob Herring, Dmitry Baryshkov
Cc: Oliver White, Greg Kroah-Hartman, Krzysztof Kozlowski,
Conor Dooley, Thinh Nguyen, Bjorn Andersson, Konrad Dybcio,
Felipe Balbi, linux-usb, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <CAL_JsqJi62TqakY6f+BzmaWx0Cr5m5KZT-GnMeLvNYRDTH-r3g@mail.gmail.com>
On 6/9/26 12:00 AM, Rob Herring wrote:
> On Sat, Jun 6, 2026 at 6:21 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Fri, Jun 05, 2026 at 02:06:38PM -0500, Rob Herring wrote:
>>> On Tue, Jun 02, 2026 at 11:12:34AM +1200, Oliver White wrote:
>>>> Add the documentation for the 'snps,reinit-phy-on-resume' boolean
>>>> property. When set, the DWC3 core will perform a full phy_exit() +
>>>> phy_init() cycle on each USB2 PHY during the host-mode fast resume
>>>> path. This is needed on platforms where the USB2 PHY power domain
>>>> is gated during deep sleep even when device_may_wakeup is true.
>>>>
>>>> Signed-off-by: Oliver White <oliverjwhite07@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/usb/snps,dwc3-common.yaml | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
>>>> index 6c0b8b653824..d12f6ae81ab8 100644
>>>> --- a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
>>>> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
>>>> @@ -212,6 +212,16 @@ properties:
>>>> When set, run the SOF/ITP counter based on ref_clk.
>>>> type: boolean
>>>>
>>>> + snps,reinit-phy-on-resume:
>>>> + description:
>>>> + When set, the DWC3 will re-initialize the USB2 PHYs during the
>>>> + host-mode fast resume path (device_may_wakeup). Some platforms
>>>> + cut PHY power during deep sleep even when USB wake is enabled,
>>>> + and the standard PHY runtime PM resume is insufficient to restore
>>>> + the PHY register state. This quirk forces a full phy_exit() +
>>>> + phy_init() cycle on each USB2 PHY.
>>>> + type: boolean
>>>
>>> This should be implied from a platform specific compatible string.
>>
>> Platform as in the "root node compatible"?
>
> No, the SoC specific one in the node you are trying to add this property to.
Taking a step back, wouldn't this point to an issue in the PHY driver
itself?
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands
From: Konrad Dybcio @ 2026-06-11 10:36 UTC (permalink / raw)
To: Fenglin Wu, Dmitry Baryshkov
Cc: linux-arm-msm, Bjorn Andersson, Konrad Dybcio, Linus Walleij,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, Maulik Shah, kernel, linux-kernel, linux-gpio,
devicetree
In-Reply-To: <837dc7e2-4db8-4a7d-a19f-e53ddbcc9cf6@oss.qualcomm.com>
On 6/9/26 3:28 AM, Fenglin Wu wrote:
>
> On 6/8/2026 5:21 AM, Dmitry Baryshkov wrote:
>> On Thu, Jun 04, 2026 at 10:02:43AM +0800, Fenglin Wu wrote:
>>> On 6/2/2026 3:29 PM, Fenglin Wu wrote:
>>>> On 6/1/2026 9:37 PM, Dmitry Baryshkov wrote:
>>>>> On Thu, May 28, 2026 at 06:05:35PM -0700, Fenglin Wu wrote:
>>>>>> Currently, the RPMH driver only allows child devices of the RPMH
>>>>>> controller to issue commands, as it assumes dev->parent points to the
>>>>>> RSC device.
>>>>>>
>>>>>> There is a possibility that certain devices which are not children of
>>>>>> the RPMH controller want to send commands for special control at the
>>>>>> RPMH side. For example, in PMH0101 PMICs, there are bidirectional
>>>>>> level shifter (LS) peripherals, and each LS works with a pair of PMIC
>>>>>> GPIOs. The control of the LS, which is combined with the GPIO
>>>>>> configuration, is handled by RPMH firmware for sharing the resource
>>>>>> between different subsystems. From a hardware point of view, the LS
>>>>>> functionality is tied to a pair of PMIC GPIOs, so its control is more
>>>>>> suitable to be added in the pinctrl-spmi-gpio driver by adding the
>>>>>> level-shifter function. However, the pinctrl-spmi-gpio device is a
>>>>>> child device of the SPMI controller, not the RPMH controller.
>>>>> This replicates the story of the PMIC regulators. There are two drivers,
>>>>> one SPMI and one RPMh. Why don't we add a separate, RPMh-based GPIO
>>>>> driver targeting only those paired GPIOs (and we don't even need to
>>>>> represent them as a pair, it might be just one pin).
>>>> Thanks for the suggestion.
>>>>
>>>> I agree that adding a separate, RPMh-based GPIO driver would be more
>>>> straightforward from RPMh control perspective. It makes the new device
>>>> as a child of the RSC device then it can naturally use the APIs for RPMh
>>>> commands. The main challenge here is, we need to make the level-shifter
>>>> mutually exclusive with other GPIO functions when the GPIO pairs are
>>>> used in level-shifter function, which means we need to write SPMI
>>>> commands to disable the associated GPIO modules. I am not sure if AOP
>>>> already handles this; as far as I know, AOP only manages the
>>>> BIDIR_LVL_SHIFTER module registers. Let me double check on this
>>>> internally, if the GPIO modules could be controlled along
>>>> with BIDIR_LVL_SHIFTER module registers at AOP side, and get back.
>>>>
>>> I checked on this internally, AOP only handles BIDIR_LVL_SHIFTER module
>>> registers, it doesn't disable the associated GPIO modules. Also, I still
>>> have no idea how could we make the "level-shifter" function to be mutually
>>> exclusive with other GPIO functions after moved it into a separate driver.
>>> Do you have further suggestions?
>> So, for my understanding, we still need to write SPMI registers to
>> configure the pins and only then AOP can handle the level shifter?
>>
>> I was thinking of using gpio-reserved-ranges to prevent those GPIOs from
>> being used by the normal SPMI driver.
>
> More background: "level-shifter" module is actually an independent hardware which is not part of the GPIO module. However, they are sharing the physical pins. Which means, from PMIC chip perspective, these pins can be configured to either a GPIO function or the "level-shifter" function. So in PMIC base dtsi file, for example, pmh0101.dtsi, these pins should not be restricted in the GPIO nodes in "gpio-reserved-ranges".
>
> Also, we need to make the GPIO modules are disabled when the "level-shifter" is enabled, to ensure that the "level-shifter" circuitry is not impacted by the GPIO modules internal circuitry. So it is supposed to write GPIO EN_CTL register (offset 0x46) to 0 through SPMI bus when the "level-shifter" is enabled.
>
> That's why we have the requirement to access both RPMh and SPMI bus in the same driver.
I was thinking about other ways to solve it.. maybe someting like:
&pmh0101_gpios {
pmh0101_ls_pins1_2: foo-bar {
pins = "gpio1", "gpio2";
// appropriate pinctrl config
};
};
&rpmh_rsc {
// should this be a gpio controller? a mux provider?
// is there another class that would better suit this?
rpmh_level_shifter: rpmh-foo-bar {
pinctrl-0 = <&>;
pinctrl-names = "default";
};
};
// but where would it make sense to describe?
// fixed-regulator or something akin to that?
&some_consumer {
someclass = <&rpmh_level_shifter 1>;
};
i.e. the "rpmh level shifter" driver would consume a reference to the
pins, configure them as necessary (just like any other pinctrl consumer)
upon request
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
From: Wadim Mueller @ 2026-06-11 10:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jonathan Cameron
Cc: Wadim Mueller, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260607-quixotic-steel-puma-133410@quoll>
Hi Krzysztof, Jonathan,
for v4 I'd like to keep the three specific per-variant compatibles from
v3 (sensirion,slf3s-0600f / -1300f / -4000b) and no generic fallback,
since the flow scale differs per sub-type.
Krzysztof, is that ok for you?
Thanks,
Wadim
^ permalink raw reply
* Re: [PATCH 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: sashiko-bot @ 2026-06-11 10:34 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260611-mt6323-nvmem-v1-2-b5e1b9ce51f2@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Blind dereference of `dev->parent->parent` can lead to a kernel panic if the device is not instantiated with the expected MFD hierarchy.
--
commit 227574270c722d2b535d72fadcf31ba55bc47f8e
Author: Roman Vivchar <rva333@protonmail.com>
nvmem: add mt6323 PMIC EFUSE driver
This commit adds support for the EFUSE controller found in the Mediatek
MT6323 PMIC. It introduces a new nvmem driver that reads 24 bytes of
hardware-related data using regmap over the PMIC wrapper.
> diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
> new file mode 100644
> index 0000000000000..c6fbfd96ac047
> --- /dev/null
> +++ b/drivers/nvmem/mt6323-efuse.c
[ ... ]
> +static int mt6323_efuse_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct nvmem_config config = {
> + .name = "mt6323-efuse",
> + .stride = 2,
> + .word_size = 2,
> + .size = MT6323_EFUSE_SIZE,
> + .reg_read = mt6323_efuse_read,
> + };
> + struct nvmem_device *nvmem;
> + struct regmap *regmap;
> +
> + /* efuse -> mfd -> pwrap */
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
[Severity: High]
Is it possible for dev->parent to be NULL here?
Because the driver defines an of_match_table, it might be instantiated directly
by the OF core or bound manually via sysfs, bypassing the MFD subsystem.
If dev->parent is NULL, evaluating dev->parent->parent will cause an immediate
NULL pointer dereference. Furthermore, if dev->parent is valid but has no
parent, dev->parent->parent evaluates to NULL. Passing a NULL device pointer to
dev_get_regmap() causes a fatal NULL pointer dereference inside devres_find()
when it attempts to acquire the devres_lock.
Would it be safer to explicitly verify that both dev->parent and
dev->parent->parent are non-NULL before dereferencing them?
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
> +
> + config.dev = dev;
> + config.priv = regmap;
> +
> + nvmem = devm_nvmem_register(dev, &config);
> + return PTR_ERR_OR_ZERO(nvmem);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com?part=2
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: sashiko-bot @ 2026-06-11 10:30 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260611-mt6323-nvmem-v1-1-b5e1b9ce51f2@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `efuse` subnode acts as an NVMEM provider but fails to reference the common NVMEM provider schema (`/schemas/nvmem/nvmem.yaml#`).
--
commit 6bc9ae8fe8f4cc07cc7210883f39574a57c6be49
Author: Roman Vivchar <rva333@protonmail.com>
dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
This commit adds the device tree binding documentation for the MediaTek
mt6323 EFUSE, which is included in the mt6323 PMIC for storing calibration
data.
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
[ ... ]
> @@ -145,6 +145,23 @@ properties:
> required:
> - compatible
>
> + efuse:
> + type: object
> + unevaluatedProperties: false
[Severity: Low]
Does this subnode need a reference to the common NVMEM provider schema?
Because unevaluatedProperties is set to false, any standard NVMEM properties
such as read-only, #address-cells, or #size-cells will trigger schema
validation errors if added to a device tree. Including a reference to
/schemas/nvmem/nvmem.yaml# would allow these standard properties to pass
validation.
> + description:
> + The efuse is responsible for storing calibration data, such as thermal
> + sensor calibration.
> +
> + properties:
> + compatible:
> + const: mediatek,mt6323-efuse
> +
> + nvmem-layout:
> + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
> +
> + required:
> + - compatible
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com?part=1
^ permalink raw reply
* [PATCH] of: property: Fix of_fwnode_get_reference_args() with negative index
From: Alban Bedel @ 2026-06-11 10:28 UTC (permalink / raw)
To: devicetree
Cc: Rob Herring, Saravana Kannan, driver-core, linux-kernel,
Alban Bedel, Tommaso Merciai
fwnode_property_get_reference_args() should return -ENOENT when an out
of bound index is passed. An issue arised with the OF backend because
the OF API use signed indexes while the fwnode API use unsigned ones.
When an index value greater the INT_MAX was passed to the OF backend
it got casted to a negative value and it returned -EINVAL instead of
-ENOENT. This patch add a check to of_fwnode_get_reference_args() to
catch negative index before they are passed to the OF API and return
-ENOENT right away.
This issue appeared when the following pattern was used in the LED
subsystem:
index = fwnode_property_match_string(fwnode, "led-names", name)
led_node = fwnode_find_reference(fwnode, "leds", index);
Unlike the same pattern with the OF API, this pattern implicitly cast
the signed return value of fwnode_property_match_string() to an
unsigned index leading to the above issue with the OF backend. It can
be argued that the return value of fwnode_property_match_string()
should be checked separately, but I think there is value in supporting
such simple and straight to the point patterns.
Link: https://lore.kernel.org/linux-leds/aimVRwJPhlGxsIUj@tom-desktop/T/#mc43cbf7e0599991b56dd0d9680714d28d145fbc8
Cc: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
---
drivers/of/property.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 136946f8b746f..eace2d1847b99 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1157,6 +1157,13 @@ of_fwnode_get_reference_args(const struct fwnode_handle *fwnode,
unsigned int i;
int ret;
+ /* This function should return -ENOENT for out of bound indexes,
+ * but the OF API uses signed indexes and consider negative indexes
+ * as invalid. Catch them here to correctly implement the fwnode API.
+ */
+ if ((int)index < 0)
+ return -ENOENT;
+
if (nargs_prop)
ret = of_parse_phandle_with_args(to_of_node(fwnode), prop,
nargs_prop, index, &of_args);
--
2.39.5
^ permalink raw reply related
* Re: [net-next 8/9] dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
From: sashiko-bot @ 2026-06-11 10:26 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: robh, wsa+renesas, conor+dt, devicetree
In-Reply-To: <20260610102432.3538432-9-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Introduction of a redundant vendor-specific devicetree property `renesas,gptp` instead of using standard generic properties.
--
commit 4c4c5b9d2738df48084bc14d69fc8572fafc601c
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
This commit adds an optional renesas,gptp phandle property to the
renesas,etheravb device tree binding to reference an external gPTP clock
for Gen4 platforms. It updates both the properties list and the schema
conditions to ensure this property is restricted to the Gen4 hardware variant.
> diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> index 1e00ef5b3acda..7bc910ab3ae0f 100644
> --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> @@ -122,6 +122,13 @@ properties:
> Specify when the AVB_LINK signal is active-low instead of normal
> active-high.
>
> + renesas,gptp:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + A phandle to an external gPTP clock for Gen4 platforms. The property is
[Severity: Low]
Could this use the standard generic ptp-timer property from
ethernet-controller.yaml instead of introducing a vendor-specific
renesas,gptp phandle?
The renesas,etheravb.yaml binding explicitly inherits from
ethernet-controller.yaml, which already defines ptp-timer as a standard
phandle for referencing an IEEE 1588 PTP device.
Alternatively, if this external module is simply a CCF reference clock,
could it be added to the standard clocks property instead?
> + optional for backwards compatibility, but without it gPTP timestamps are
> + disabled as Gen4 have no gPTP as part of the RAVB module itself.
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610102432.3538432-9-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [net-next 2/9] net: ethernet: ravb: Move programming of gPTP timer interval
From: sashiko-bot @ 2026-06-11 10:26 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: wsa+renesas, conor+dt, robh, devicetree
In-Reply-To: <20260610102432.3538432-3-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The gPTP initialization sequence incorrectly waits on the GCCR_TCR field instead of GCCR_LTI after requesting a timer increment load.
Pre-existing issues:
- [High] ravb_ptp_init() assigns the result of ptp_clock_register() to priv->ptp.clock without an IS_ERR() check, leading to invalid pointer dereferences.
--
commit 105bd561296a957da9d4e09fecae37137d532c98
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
net: ethernet: ravb: Move programming of gPTP timer interval
This commit moves the programming of the gPTP timer interval into the gPTP
initialization function. This allows the programming to occur while holding
the gPTP registers lock.
> diff --git a/drivers/net/ethernet/renesas/ravb_ptp.c b/drivers/net/ethernet/renesas/ravb_ptp.c
> index 226c6c0ab945b..7c78f75cb284a 100644
> --- a/drivers/net/ethernet/renesas/ravb_ptp.c
> +++ b/drivers/net/ethernet/renesas/ravb_ptp.c
[ ... ]
> @@ -319,11 +319,20 @@ void ravb_ptp_init(struct net_device *ndev, struct platform_device *pdev)
[ ... ]
> spin_lock_irqsave(&priv->lock, flags);
> +
> + /* Set gPTP Timer Increment Value. */
> + ravb_write(ndev, priv->ptp.default_addend, GTI);
> +
> + /* Request GTI loading. */
> + ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
> +
> + /* Wait for GIT loading to complete. */
> ravb_wait(ndev, GCCR, GCCR_TCR, GCCR_TCR_NOREQ);
[Severity: Medium]
The commit message states the goal is to wait for the timer interval
programming to be acknowledged by the hardware. Does waiting on GCCR_TCR
achieve this?
The code requests the load by setting GCCR_LTI, but the wait immediately
follows on GCCR_TCR. Since GCCR_TCR is typically 0 at this stage, the wait
will return immediately instead of waiting for the hardware to clear GCCR_LTI.
Could the subsequent ravb_modify() on GCCR execute before the hardware
clears GCCR_LTI, potentially writing a 1 back to it and disrupting the
initialization sequence?
> +
> ravb_modify(ndev, GCCR, GCCR_TCSS, GCCR_TCSS_ADJGPTP);
> spin_unlock_irqrestore(&priv->lock, flags);
[Severity: High]
This is a pre-existing issue, but looking at the rest of ravb_ptp_init()
just below this lock:
priv->ptp.clock = ptp_clock_register(&priv->ptp.info, &pdev->dev);
}
Should there be an IS_ERR() check here?
If ptp_clock_register() fails, it returns an ERR_PTR. Because the driver
does not validate the return value, priv->ptp.clock would hold this error
pointer.
When the interface is brought down via ravb_ptp_stop(), or when a hardware
PTP interrupt occurs, this pointer is passed to ptp_clock_unregister() or
ptp_clock_event(). Since neither function checks for error pointers, would
this lead to a panic from an invalid pointer dereference?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610102432.3538432-3-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [net-next 1/9] net: ethernet: ravb: Remove gPTP control from WoL setup and restore
From: sashiko-bot @ 2026-06-11 10:26 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: wsa+renesas, devicetree, conor+dt, robh
In-Reply-To: <20260610102432.3538432-2-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unchecked return value of ptp_clock_register() leads to a kernel panic in ravb_ptp_stop() on failure.
--
commit 4d5ada4dabf46fceeae07f219f72c4daaba09e17
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
net: ethernet: ravb: Remove gPTP control from WoL setup and restore
This commit removes the explicit stopping and starting of the gPTP clock
during Wake-on-LAN (WoL) setup and restore. This is because the ndev is
always closed and re-opened during system suspend and resume, which handles
the clock state automatically.
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 5f88733094d0f..77c0645a1c4d3 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
[ ... ]
> @@ -3201,9 +3198,6 @@ static int ravb_wol_restore(struct net_device *ndev)
> if (error)
> return error;
>
> - if (priv->info->ccc_gac)
> - ravb_ptp_init(ndev, priv->pdev);
> -
[Severity: High]
This is a pre-existing issue, but since this patch involves the usage of
ravb_ptp_init() and ravb_ptp_stop(), does ravb_ptp_init() need to check
the return value of ptp_clock_register()?
In drivers/net/ethernet/renesas/ravb_ptp.c:ravb_ptp_init(), the return value
is assigned directly without using IS_ERR():
priv->ptp.clock = ptp_clock_register(&priv->ptp.info, &pdev->dev);
If ptp_clock_register() fails and returns an error pointer like
ERR_PTR(-ENOMEM), priv->ptp.clock will hold this error pointer instead of
a valid clock or NULL.
Later, when ravb_ptp_stop() is unconditionally called during teardown or
driver removal, it executes:
ptp_clock_unregister(priv->ptp.clock);
Could this cause a kernel panic when ptp_clock_unregister() dereferences
the error pointer (e.g., when locking the internal mutex via
ptp_vclock_in_use)?
> if (info->nc_queues)
> napi_enable(&priv->napi[RAVB_NC]);
> napi_enable(&priv->napi[RAVB_BE]);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610102432.3538432-2-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* [PATCH 4/4] ARM: dts: mediatek: mt6323: add EFUSE support
From: Roman Vivchar via B4 Relay @ 2026-06-11 10:20 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, Jonathan Cameron, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 efuse.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
arch/arm/boot/dts/mediatek/mt6323.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..807e000a7ff6 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,10 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ efuse {
+ compatible = "mediatek,mt6323-efuse";
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
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