* [PATCH v2 1/1] arm64: dts: imx91-var-dart-sonata: add RGB enable supply for PCA6408
From: Stefano Radaelli @ 2026-03-31 9:21 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
From: Stefano Radaelli <stefano.r@variscite.com>
RGB enable pin, labeled as RGBSEL, is a board-level enable signal on
the Sonata carrier board.
The two PCA6408 GPIO expanders depend on this signal being asserted, so
model it as a fixed regulator and use it as their vcc-supply.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Fixed commit message and RGB pin references.
arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
index afa39dab240a..3f0fd321d95f 100644
--- a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
@@ -90,6 +90,13 @@ reg_vref_1v8: regulator-adc-vref {
regulator-max-microvolt = <1800000>;
};
+ reg_rgb_sel: regulator-rgb-enable {
+ compatible = "regulator-fixed";
+ regulator-name = "RGBSEL";
+ gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -195,6 +202,7 @@ pca6408_1: gpio@20 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca6408_2: gpio@21 {
@@ -204,6 +212,7 @@ pca6408_2: gpio@21 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca9534: gpio@22 {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: James Clark @ 2026-03-31 9:26 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <207b78e5-ed6b-4caf-b9ce-546cf33d6dfd@oss.qualcomm.com>
On 31/03/2026 4:18 am, Jie Gan wrote:
> Hi James,
>
> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>
>> Hi James,
>>
>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>
>>>
>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>> to userspace to support trace data parsing.
>>>>
>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>> to the connected TPDA device.
>>>>
>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>> ---
>>>> Changes in v3:
>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>> enabled.
>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>
>>>> Changes in V2:
>>>> 1. Use sysfs_emit instead of sprintf.
>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>>>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>> ---
>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 ++++++++++++++++
>>>> + + +++++++++-
>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/
>>>> hwtracing/coresight/coresight-tpdm.c
>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>> *drvdata)
>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>> perf_event *event,
>>>> enum cs_mode mode,
>>>> - __maybe_unused struct coresight_path *path)
>>>> + struct coresight_path *path)
>>>> {
>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>> >dev.parent);
>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>> *csdev, struct perf_event *event,
>>>> }
>>>> __tpdm_enable(drvdata);
>>>> + drvdata->traceid = path->trace_id;
>>>> drvdata->enable = true;
>>>> spin_unlock(&drvdata->spinlock);
>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>> .attrs = tpdm_attrs,
>>>> };
>>>> +static ssize_t traceid_show(struct device *dev,
>>>> + struct device_attribute *attr, char *buf)
>>>> +{
>>>> + unsigned long val;
>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +
>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>> + return -EINVAL;
>>>> +
>>>> + val = drvdata->traceid;
>>>
>>> You probably need to take the coresight_mutex here otherwise you
>>> could still return an invalid or stale value despite checking the mode.
>>>
>>
>> Acked. I have missed this potential race condition.
>>
>>> There might also be some value in it returning the last used trace ID
>>> even if the mode isn't enabled anymore. Because you can still read
>>> out of the sink after disabling, so it makes more sense for a script
>>> to read it at that point rather than when it's enabled. Also, you
>>> probably don't want to be doing other things in your script in the
>>> point between enabling and disabling.
>>
>> That's making sense. I shouldnt add such restriction for the read
>> process.
>>
>
> I missed one point in last message.
>
> Is that acceptable to export the coresight_mutex from the core module?
> Currently, the coresight_mutex is used within the module only.
>
> Thanks,
> Jie
>
If the plan is to only check for non-zero trace ID and not check the
mode any more then you don't need to lock. Maybe lets see what Suzuki
thinks about returning the last trace ID though as it was his idea to
add -EINVAL.
>> Scenarios for reading:
>> 1. device is enabled -> trace ID is valid
>> 2. device is enabled then disabled -> trace ID is valid for the last
>> trace event
>> 3. device is never enabled -> invalid trace ID (value 0)
>>
>> we only need to check the validation of the trace ID.
>>
>> mutex_lock(&coresight_mutex);
>> val = drvdata->traceid;
>> mutex_unlock(&coresight_mutex);
>>
>> if (!val)
>> return -EINVAL;
>>
>> return sysfs_emit(buf, "%#lx\n", val);
>>
>> Thanks,
>> Jie
>>
>>>
>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>> +}
>>>> +static DEVICE_ATTR_RO(traceid);
>>>> +
>>>> +static struct attribute *traceid_attrs[] = {
>>>> + &dev_attr_traceid.attr,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static struct attribute_group traceid_attr_grp = {
>>>> + .attrs = traceid_attrs,
>>>> +};
>>>> +
>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>> struct device_attribute *attr,
>>>> char *buf)
>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>> *tpdm_attr_grps[] = {
>>>> &tpdm_cmb_patt_grp,
>>>> &tpdm_cmb_msr_grp,
>>>> &tpdm_mcmb_attr_grp,
>>>> + &traceid_attr_grp,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>> + &traceid_attr_grp,
>>>> NULL,
>>>> };
>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>> struct resource *res)
>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>> if (res)
>>>> desc.groups = tpdm_attr_grps;
>>>> + else
>>>> + desc.groups = static_tpdm_attr_grps;
>>>> drvdata->csdev = coresight_register(&desc);
>>>> if (IS_ERR(drvdata->csdev))
>>>> return PTR_ERR(drvdata->csdev);
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/
>>>> hwtracing/coresight/coresight-tpdm.h
>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>> * @cmb Specifics associated to TPDM CMB.
>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>> + * @traceid Trace ID of the path.
>>>> */
>>>> struct tpdm_drvdata {
>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>> struct cmb_dataset *cmb;
>>>> u32 dsb_msr_num;
>>>> u32 cmb_msr_num;
>>>> + u8 traceid;
>>>> };
>>>> /* Enumerate members of various datasets */
>>>>
>>>> ---
>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>
>>>> Best regards,
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v3] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-31 9:28 UTC (permalink / raw)
To: Vincent Donnefort
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <acs0Qbjfdmlkvd1e@google.com>
On Tue, Mar 31, 2026 at 3:41 AM Vincent Donnefort <vdonnefort@google.com> wrote:
>
> On Mon, Mar 30, 2026 at 10:54:41AM +0000, Sebastian Ene wrote:
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field un-handled in pKVM when an SMC instruction is
> > trapped.
> > Since the HVC is a private interface between EL2 and the host,
> > enforce the host kernel running under pKVM to use an immediate value
> > of 0 only when using SMCs to make it clear for non-compliant software
> > talking to Trustzone that we only use SMCCC.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
>
Hello,
> Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
>
Thanks for reviewing,
Sebastian
> > ---
> > v2 -> current:
> > - move the ESR decoding of the imm16 in the handle_host_smc where it
> > was supposed to be
> > - updated the commit message to include the reason behind while we are
> > not doing for HVCs as well
> > - updated the commit message to clarify that pKVM is not handling the
> > imm16
> >
> > v1 -> v2:
> > - Dropped injecting an UNDEF and return an error instead
> > (SMCCC_RET_NOT_SUPPORTED)
> > - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> > - Updated the title of the commit message from:
> > "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> > smc with imm16 != 0"
> >
> > Link to v2:
> > https://lore.kernel.org/all/20260325113138.4171430-1-sebastianene@google.com/
> > Link to v1:
> > https://lore.kernel.org/all/20260324135728.3532400-1-sebastianene@google.com/
> >
> > ---
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index e7790097db93..461cf5cb5ac7 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -676,8 +676,14 @@ static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
> > static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> > {
> > DECLARE_REG(u64, func_id, host_ctxt, 0);
> > + u64 esr = read_sysreg_el2(SYS_ESR);
> > bool handled;
> >
> > + if (esr & ESR_ELx_xVC_IMM_MASK) {
> > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> > + goto exit_skip_instr;
> > + }
> > +
> > func_id &= ~ARM_SMCCC_CALL_HINTS;
> >
> > handled = kvm_host_psci_handler(host_ctxt, func_id);
> > @@ -686,6 +692,7 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> > if (!handled)
> > default_host_smc_handler(host_ctxt);
> >
> > +exit_skip_instr:
> > /* SMC was trapped, move ELR past the current PC. */
> > kvm_skip_host_instr();
> > }
> > --
> > 2.53.0.1018.g2bb0e51243-goog
> >
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 9:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260331091721.61613-3-krzysztof.kozlowski@oss.qualcomm.com>
On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
> The static 'struct qcom_cc_driver_data' contains probe match-like data
> and is not modified: neither by the driver defining it nor by common.c
> code using it.
>
> Make it const for code safety and code readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
[...]
> --- a/drivers/clk/qcom/common.h
> +++ b/drivers/clk/qcom/common.h
> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
> size_t num_icc_hws;
> unsigned int icc_first_node_id;
> bool use_rpm;
> - struct qcom_cc_driver_data *driver_data;
> + const struct qcom_cc_driver_data *driver_data;
This can be a const ptr to const data, even
Konrad
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 9:33 UTC (permalink / raw)
To: James Clark, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <7abe93fa-3748-4077-b75a-d28296862654@linaro.org>
On 3/31/2026 5:26 PM, James Clark wrote:
>
>
> On 31/03/2026 4:18 am, Jie Gan wrote:
>> Hi James,
>>
>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>
>>> Hi James,
>>>
>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>
>>>>
>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>> to userspace to support trace data parsing.
>>>>>
>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>> to the connected TPDA device.
>>>>>
>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>> ---
>>>>> Changes in v3:
>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>> enabled.
>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>
>>>>> Changes in V2:
>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>>>>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>> ---
>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++
>>>>> + + + +++++++++-
>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>> *drvdata)
>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>> perf_event *event,
>>>>> enum cs_mode mode,
>>>>> - __maybe_unused struct coresight_path *path)
>>>>> + struct coresight_path *path)
>>>>> {
>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>> >dev.parent);
>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>> *csdev, struct perf_event *event,
>>>>> }
>>>>> __tpdm_enable(drvdata);
>>>>> + drvdata->traceid = path->trace_id;
>>>>> drvdata->enable = true;
>>>>> spin_unlock(&drvdata->spinlock);
>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>> .attrs = tpdm_attrs,
>>>>> };
>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>> + struct device_attribute *attr, char *buf)
>>>>> +{
>>>>> + unsigned long val;
>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +
>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + val = drvdata->traceid;
>>>>
>>>> You probably need to take the coresight_mutex here otherwise you
>>>> could still return an invalid or stale value despite checking the mode.
>>>>
>>>
>>> Acked. I have missed this potential race condition.
>>>
>>>> There might also be some value in it returning the last used trace
>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>> read out of the sink after disabling, so it makes more sense for a
>>>> script to read it at that point rather than when it's enabled. Also,
>>>> you probably don't want to be doing other things in your script in
>>>> the point between enabling and disabling.
>>>
>>> That's making sense. I shouldnt add such restriction for the read
>>> process.
>>>
>>
>> I missed one point in last message.
>>
>> Is that acceptable to export the coresight_mutex from the core module?
>> Currently, the coresight_mutex is used within the module only.
>>
>> Thanks,
>> Jie
>>
>
> If the plan is to only check for non-zero trace ID and not check the
> mode any more then you don't need to lock. Maybe lets see what Suzuki
> thinks about returning the last trace ID though as it was his idea to
> add -EINVAL.
>
Sure. The trace ID is allocated during TPDA device probe and remains
unchanged for the entire lifetime of the device.
Thanks,
Jie
>>> Scenarios for reading:
>>> 1. device is enabled -> trace ID is valid
>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>> trace event
>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>
>>> we only need to check the validation of the trace ID.
>>>
>>> mutex_lock(&coresight_mutex);
>>> val = drvdata->traceid;
>>> mutex_unlock(&coresight_mutex);
>>>
>>> if (!val)
>>> return -EINVAL;
>>>
>>> return sysfs_emit(buf, "%#lx\n", val);
>>>
>>> Thanks,
>>> Jie
>>>
>>>>
>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>> +}
>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>> +
>>>>> +static struct attribute *traceid_attrs[] = {
>>>>> + &dev_attr_traceid.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>> + .attrs = traceid_attrs,
>>>>> +};
>>>>> +
>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>> struct device_attribute *attr,
>>>>> char *buf)
>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>> *tpdm_attr_grps[] = {
>>>>> &tpdm_cmb_patt_grp,
>>>>> &tpdm_cmb_msr_grp,
>>>>> &tpdm_mcmb_attr_grp,
>>>>> + &traceid_attr_grp,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>> + &traceid_attr_grp,
>>>>> NULL,
>>>>> };
>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>> struct resource *res)
>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>> if (res)
>>>>> desc.groups = tpdm_attr_grps;
>>>>> + else
>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>> drvdata->csdev = coresight_register(&desc);
>>>>> if (IS_ERR(drvdata->csdev))
>>>>> return PTR_ERR(drvdata->csdev);
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>> + * @traceid Trace ID of the path.
>>>>> */
>>>>> struct tpdm_drvdata {
>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>> struct cmb_dataset *cmb;
>>>>> u32 dsb_msr_num;
>>>>> u32 cmb_msr_num;
>>>>> + u8 traceid;
>>>>> };
>>>>> /* Enumerate members of various datasets */
>>>>>
>>>>> ---
>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>
>>>>> Best regards,
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 9:35 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <acuE-URAuRvmtd4u@orome>
On 31/03/2026 10:43, Thierry Reding wrote:
>>>> Maybe they had more time for previous versions, but
>>>> nevertheless it is also part of other patchset, so it will get into the
>>>> kernel other tree and nothing on v3 posting:
>>>> https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/
>>>> gives hints that there will be cross tree merge.
>>>
>>> Maybe look at the cover letter:
>>>
>>> https://lore.kernel.org/all/20260326135855.2795149-1-thierry.reding@kernel.org/
>>>
>>> I clearly pointed out the build dependencies and suggested a shared
>>> branch to resolve them in both trees. Given that the bindings were
>>
>> No problem, that's a valid solution. Can you point me with a lore link
>> to the shared branch posting (these tags/pull requests must be posted on
>> the lists)? Or to an ack from PCI maintainers?
>>
>> The commit itself does not have an Ack, but maybe was just missed.
>
> Yes, the DT bindings patch does not have an Acked-by, but again, I
> didn't think that was necessary, especially since we were going to have
> a cross-merge anyway.
>
> Here's the PR for PCI:
>
> https://lore.kernel.org/linux-tegra/20260329155040.1448158-1-thierry.reding@kernel.org/
Thanks, this solves my question. A note in the pull message (not
necessarily in the tag) would also solve it, BTW.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Suzuki K Poulose @ 2026-03-31 9:42 UTC (permalink / raw)
To: James Clark, Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <7abe93fa-3748-4077-b75a-d28296862654@linaro.org>
On 31/03/2026 10:26, James Clark wrote:
>
>
> On 31/03/2026 4:18 am, Jie Gan wrote:
>> Hi James,
>>
>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>
>>> Hi James,
>>>
>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>
>>>>
>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>> to userspace to support trace data parsing.
>>>>>
>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>> to the connected TPDA device.
>>>>>
>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>> ---
>>>>> Changes in v3:
>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>> enabled.
>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>
>>>>> Changes in V2:
>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>>>>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>> ---
>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++
>>>>> + + + +++++++++-
>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>> *drvdata)
>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>> perf_event *event,
>>>>> enum cs_mode mode,
>>>>> - __maybe_unused struct coresight_path *path)
>>>>> + struct coresight_path *path)
>>>>> {
>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>> >dev.parent);
>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>> *csdev, struct perf_event *event,
>>>>> }
>>>>> __tpdm_enable(drvdata);
>>>>> + drvdata->traceid = path->trace_id;
>>>>> drvdata->enable = true;
>>>>> spin_unlock(&drvdata->spinlock);
>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>> .attrs = tpdm_attrs,
>>>>> };
>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>> + struct device_attribute *attr, char *buf)
>>>>> +{
>>>>> + unsigned long val;
>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +
>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + val = drvdata->traceid;
>>>>
>>>> You probably need to take the coresight_mutex here otherwise you
>>>> could still return an invalid or stale value despite checking the mode.
>>>>
>>>
>>> Acked. I have missed this potential race condition.
>>>
>>>> There might also be some value in it returning the last used trace
>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>> read out of the sink after disabling, so it makes more sense for a
>>>> script to read it at that point rather than when it's enabled. Also,
>>>> you probably don't want to be doing other things in your script in
>>>> the point between enabling and disabling.
>>>
>>> That's making sense. I shouldnt add such restriction for the read
>>> process.
>>>
>>
>> I missed one point in last message.
>>
>> Is that acceptable to export the coresight_mutex from the core module?
>> Currently, the coresight_mutex is used within the module only.
>>
>> Thanks,
>> Jie
>>
>
> If the plan is to only check for non-zero trace ID and not check the
> mode any more then you don't need to lock. Maybe lets see what Suzuki
> thinks about returning the last trace ID though as it was his idea to
> add -EINVAL.
>
I think there is value in reading out the traceid that was used. Also,
I assume TPDM is always connected to a TPDA port and the traceID
wouldn't change, ever ?
I am happy with the proposal
Suzuki
>>> Scenarios for reading:
>>> 1. device is enabled -> trace ID is valid
>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>> trace event
>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>
>>> we only need to check the validation of the trace ID.
>>>
>>> mutex_lock(&coresight_mutex);
>>> val = drvdata->traceid;
>>> mutex_unlock(&coresight_mutex);
>>>
>>> if (!val)
>>> return -EINVAL;
>>>
>>> return sysfs_emit(buf, "%#lx\n", val);
>>>
>>> Thanks,
>>> Jie
>>>
>>>>
>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>> +}
>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>> +
>>>>> +static struct attribute *traceid_attrs[] = {
>>>>> + &dev_attr_traceid.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>> + .attrs = traceid_attrs,
>>>>> +};
>>>>> +
>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>> struct device_attribute *attr,
>>>>> char *buf)
>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>> *tpdm_attr_grps[] = {
>>>>> &tpdm_cmb_patt_grp,
>>>>> &tpdm_cmb_msr_grp,
>>>>> &tpdm_mcmb_attr_grp,
>>>>> + &traceid_attr_grp,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>> + &traceid_attr_grp,
>>>>> NULL,
>>>>> };
>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>> struct resource *res)
>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>> if (res)
>>>>> desc.groups = tpdm_attr_grps;
>>>>> + else
>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>> drvdata->csdev = coresight_register(&desc);
>>>>> if (IS_ERR(drvdata->csdev))
>>>>> return PTR_ERR(drvdata->csdev);
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>> + * @traceid Trace ID of the path.
>>>>> */
>>>>> struct tpdm_drvdata {
>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>> struct cmb_dataset *cmb;
>>>>> u32 dsb_msr_num;
>>>>> u32 cmb_msr_num;
>>>>> + u8 traceid;
>>>>> };
>>>>> /* Enumerate members of various datasets */
>>>>>
>>>>> ---
>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>
>>>>> Best regards,
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive
From: Marc Zyngier @ 2026-03-31 9:42 UTC (permalink / raw)
To: Vishnu Pajjuri
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Christoffer Dall, Mark Brown, kvm, linux-arm-kernel,
kvmarm
In-Reply-To: <1e050b67-2276-41ad-9265-796ba853dc7c@os.amperecomputing.com>
On Tue, 31 Mar 2026 07:31:54 +0100,
Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
>
> Hi Marc,
> Many thanks for your reply.
>
> On 30-03-2026 17:47, Marc Zyngier wrote:
> > On Mon, 30 Mar 2026 12:51:51 +0100,
> > Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
> >>
> >> Hi Fuad Tabba,
> >
> > To be brutally honest, I doubt Fuad really cares about NV,
>
> I see Tested-by: fuad Tabba on this patch so tried to reach out him.
Rather than the author of the patch?
>
> >
> >> I'm trying to run nested VMs on Ampere platforms after this patch
> >> series(v6.19+) but nested VMs are not booting and triggering soft
> >> lockups on L0 and L0 hang. But just before this patch I could able to
> >> successfully boot the Nested VMs.
> >
> > So the host dies? There isn't much here that interacts with the host
> > at all. Worse case, the L1 dies by not making progress.
>
> Initially L1 become unresponsive then L0 becomes unresponsive, soft
> lockups and L0 hang.
I've never seen this in the past 6 months. Doesn't mean there is no
bug, but so far I haven't seen any of that.
[...]
> >> Were you able to boot Nested VMs successfully after v6.19+?
> >
> > I boot L3s every day.
>
> Do you mean L2s or L3s on top of L2s?
I'm running an L0 host, itself running L1 guests, themselves running
L2 guests, themselves running L3 guests. That's what "running L3s"
means.
> I running L1 and L2 using latest QEMU, do you use QEMU or kvmtool run
> L1 and L2 in your regression tests?
Both. And that really shouldn't matter.
>
>
> >
> >> LOG:
> >> [ 164.647367] Call trace:
> >> [ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P)
> >> [ 164.647372] smp_call_function_many+0x20/0x40
> >> [ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8
> >> [ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8
> >> [ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0
> >> [ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400
> >> [ 164.647386] kvm_vm_ioctl+0x7b8/0xc88
> >> [ 164.647389] __arm64_sys_ioctl+0xb4/0x118
> >> [ 164.647393] invoke_syscall+0x6c/0x100
> >> [ 164.647397] el0_svc_common.constprop.0+0x48/0xf0
> >> [ 164.647398] do_el0_svc+0x24/0x38
> >> [ 164.647400] el0_svc+0x3c/0x170
> >> [ 164.647403] el0t_64_sync_handler+0xa0/0xe8
> >> [ 164.647405] el0t_64_sync+0x1b0/0x1b8
> >
> > This trace is about interrupt injection from userspace, not
> > deactivation of a HW interrupt.
> > None of that makes much sense.
>
> Although this behavior is puzzling, it matches the trace I typically
> observe on L0. After reverting the patch, I was able to boot L2 guests
> successfully.
Well, this patch fixes real bugs, so it isn't going anywhere.
The patch you are reverting addresses the deactivation of a HW
interrupt, which is likely to be a timer (that's the only one we
support). The stacktrace points to the userspace injection of an SPI.
If we need to broadcast IPI, that's because there is no other SPI
currently in flight. But if a CPU is not responding to the IPI, what
is it doing? How does this interact with the patch you are reverting?
Given that I don't know what you're running, how you are running it,
that I don't have access to whatever HW you are using, and that you
are providing no useful information that'd help me debug this, I will
leave it up to you to debug it and come back with a detailed analysis
of the problem.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: James Clark @ 2026-03-31 9:44 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <f038fd7c-d563-4583-ad6f-666e2816fdb7@oss.qualcomm.com>
On 31/03/2026 10:33 am, Jie Gan wrote:
>
>
> On 3/31/2026 5:26 PM, James Clark wrote:
>>
>>
>> On 31/03/2026 4:18 am, Jie Gan wrote:
>>> Hi James,
>>>
>>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>>
>>>> Hi James,
>>>>
>>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>>
>>>>>
>>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>>> to userspace to support trace data parsing.
>>>>>>
>>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>>> to the connected TPDA device.
>>>>>>
>>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>>> ---
>>>>>> Changes in v3:
>>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>>> enabled.
>>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>>
>>>>>> Changes in V2:
>>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-
>>>>>> show- for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>>> ---
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 ++++++++++++++
>>>>>> + + + + +++++++++-
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>>> *drvdata)
>>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>>> perf_event *event,
>>>>>> enum cs_mode mode,
>>>>>> - __maybe_unused struct coresight_path *path)
>>>>>> + struct coresight_path *path)
>>>>>> {
>>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>>> >dev.parent);
>>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>>> *csdev, struct perf_event *event,
>>>>>> }
>>>>>> __tpdm_enable(drvdata);
>>>>>> + drvdata->traceid = path->trace_id;
>>>>>> drvdata->enable = true;
>>>>>> spin_unlock(&drvdata->spinlock);
>>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>>> .attrs = tpdm_attrs,
>>>>>> };
>>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>>> + struct device_attribute *attr, char *buf)
>>>>>> +{
>>>>>> + unsigned long val;
>>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +
>>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + val = drvdata->traceid;
>>>>>
>>>>> You probably need to take the coresight_mutex here otherwise you
>>>>> could still return an invalid or stale value despite checking the
>>>>> mode.
>>>>>
>>>>
>>>> Acked. I have missed this potential race condition.
>>>>
>>>>> There might also be some value in it returning the last used trace
>>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>>> read out of the sink after disabling, so it makes more sense for a
>>>>> script to read it at that point rather than when it's enabled.
>>>>> Also, you probably don't want to be doing other things in your
>>>>> script in the point between enabling and disabling.
>>>>
>>>> That's making sense. I shouldnt add such restriction for the read
>>>> process.
>>>>
>>>
>>> I missed one point in last message.
>>>
>>> Is that acceptable to export the coresight_mutex from the core module?
>>> Currently, the coresight_mutex is used within the module only.
>>>
>>> Thanks,
>>> Jie
>>>
>>
>> If the plan is to only check for non-zero trace ID and not check the
>> mode any more then you don't need to lock. Maybe lets see what Suzuki
>> thinks about returning the last trace ID though as it was his idea to
>> add -EINVAL.
>>
>
> Sure. The trace ID is allocated during TPDA device probe and remains
> unchanged for the entire lifetime of the device.
>
> Thanks,
> Jie
>
>
Oh I missed that because it's assigned every time in tpdm_enable(). In
that case I don't see why it can't be just:
val = drvdata->traceid;
if (!val)
return -EINVAL;
return sysfs_emit(...)
>>>> Scenarios for reading:
>>>> 1. device is enabled -> trace ID is valid
>>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>>> trace event
>>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>>
>>>> we only need to check the validation of the trace ID.
>>>>
>>>> mutex_lock(&coresight_mutex);
>>>> val = drvdata->traceid;
>>>> mutex_unlock(&coresight_mutex);
>>>>
>>>> if (!val)
>>>> return -EINVAL;
>>>>
>>>> return sysfs_emit(buf, "%#lx\n", val);
>>>>
>>>> Thanks,
>>>> Jie
>>>>
>>>>>
>>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>>> +}
>>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>>> +
>>>>>> +static struct attribute *traceid_attrs[] = {
>>>>>> + &dev_attr_traceid.attr,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>>> + .attrs = traceid_attrs,
>>>>>> +};
>>>>>> +
>>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>>> struct device_attribute *attr,
>>>>>> char *buf)
>>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>>> *tpdm_attr_grps[] = {
>>>>>> &tpdm_cmb_patt_grp,
>>>>>> &tpdm_cmb_msr_grp,
>>>>>> &tpdm_mcmb_attr_grp,
>>>>>> + &traceid_attr_grp,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>>> + &traceid_attr_grp,
>>>>>> NULL,
>>>>>> };
>>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>>> struct resource *res)
>>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>>> if (res)
>>>>>> desc.groups = tpdm_attr_grps;
>>>>>> + else
>>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>>> drvdata->csdev = coresight_register(&desc);
>>>>>> if (IS_ERR(drvdata->csdev))
>>>>>> return PTR_ERR(drvdata->csdev);
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>>> + * @traceid Trace ID of the path.
>>>>>> */
>>>>>> struct tpdm_drvdata {
>>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>>> struct cmb_dataset *cmb;
>>>>>> u32 dsb_msr_num;
>>>>>> u32 cmb_msr_num;
>>>>>> + u8 traceid;
>>>>>> };
>>>>>> /* Enumerate members of various datasets */
>>>>>>
>>>>>> ---
>>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>>
>>>>>> Best regards,
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 9:48 UTC (permalink / raw)
To: Suzuki K Poulose, James Clark
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <04214197-f521-47d6-88a1-94be1a8b1981@arm.com>
On 3/31/2026 5:42 PM, Suzuki K Poulose wrote:
> On 31/03/2026 10:26, James Clark wrote:
>>
>>
>> On 31/03/2026 4:18 am, Jie Gan wrote:
>>> Hi James,
>>>
>>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>>
>>>> Hi James,
>>>>
>>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>>
>>>>>
>>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>>> to userspace to support trace data parsing.
>>>>>>
>>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>>> to the connected TPDA device.
>>>>>>
>>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>>> ---
>>>>>> Changes in v3:
>>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>>> enabled.
>>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>>
>>>>>> Changes in V2:
>>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-
>>>>>> show- for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>>> ---
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 ++++++++++++++
>>>>>> + + + + +++++++++-
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>>> *drvdata)
>>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>>> perf_event *event,
>>>>>> enum cs_mode mode,
>>>>>> - __maybe_unused struct coresight_path *path)
>>>>>> + struct coresight_path *path)
>>>>>> {
>>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>>> >dev.parent);
>>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>>> *csdev, struct perf_event *event,
>>>>>> }
>>>>>> __tpdm_enable(drvdata);
>>>>>> + drvdata->traceid = path->trace_id;
>>>>>> drvdata->enable = true;
>>>>>> spin_unlock(&drvdata->spinlock);
>>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>>> .attrs = tpdm_attrs,
>>>>>> };
>>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>>> + struct device_attribute *attr, char *buf)
>>>>>> +{
>>>>>> + unsigned long val;
>>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +
>>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + val = drvdata->traceid;
>>>>>
>>>>> You probably need to take the coresight_mutex here otherwise you
>>>>> could still return an invalid or stale value despite checking the
>>>>> mode.
>>>>>
>>>>
>>>> Acked. I have missed this potential race condition.
>>>>
>>>>> There might also be some value in it returning the last used trace
>>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>>> read out of the sink after disabling, so it makes more sense for a
>>>>> script to read it at that point rather than when it's enabled.
>>>>> Also, you probably don't want to be doing other things in your
>>>>> script in the point between enabling and disabling.
>>>>
>>>> That's making sense. I shouldnt add such restriction for the read
>>>> process.
>>>>
>>>
>>> I missed one point in last message.
>>>
>>> Is that acceptable to export the coresight_mutex from the core module?
>>> Currently, the coresight_mutex is used within the module only.
>>>
>>> Thanks,
>>> Jie
>>>
>>
>> If the plan is to only check for non-zero trace ID and not check the
>> mode any more then you don't need to lock. Maybe lets see what Suzuki
>> thinks about returning the last trace ID though as it was his idea to
>> add -EINVAL.
>>
>
> I think there is value in reading out the traceid that was used. Also,
> I assume TPDM is always connected to a TPDA port and the traceID
> wouldn't change, ever ?
>
Yes.
> I am happy with the proposal
>
James also agrees this proposal in other thread. I will submit a new
patch to address it.
ABI document missed in this patch also, I will add it in the new patch.
Thanks,
Jie
> Suzuki
>
>>>> Scenarios for reading:
>>>> 1. device is enabled -> trace ID is valid
>>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>>> trace event
>>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>>
>>>> we only need to check the validation of the trace ID.
>>>>
>>>> mutex_lock(&coresight_mutex);
>>>> val = drvdata->traceid;
>>>> mutex_unlock(&coresight_mutex);
>>>>
>>>> if (!val)
>>>> return -EINVAL;
>>>>
>>>> return sysfs_emit(buf, "%#lx\n", val);
>>>>
>>>> Thanks,
>>>> Jie
>>>>
>>>>>
>>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>>> +}
>>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>>> +
>>>>>> +static struct attribute *traceid_attrs[] = {
>>>>>> + &dev_attr_traceid.attr,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>>> + .attrs = traceid_attrs,
>>>>>> +};
>>>>>> +
>>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>>> struct device_attribute *attr,
>>>>>> char *buf)
>>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>>> *tpdm_attr_grps[] = {
>>>>>> &tpdm_cmb_patt_grp,
>>>>>> &tpdm_cmb_msr_grp,
>>>>>> &tpdm_mcmb_attr_grp,
>>>>>> + &traceid_attr_grp,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>>> + &traceid_attr_grp,
>>>>>> NULL,
>>>>>> };
>>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>>> struct resource *res)
>>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>>> if (res)
>>>>>> desc.groups = tpdm_attr_grps;
>>>>>> + else
>>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>>> drvdata->csdev = coresight_register(&desc);
>>>>>> if (IS_ERR(drvdata->csdev))
>>>>>> return PTR_ERR(drvdata->csdev);
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>>> + * @traceid Trace ID of the path.
>>>>>> */
>>>>>> struct tpdm_drvdata {
>>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>>> struct cmb_dataset *cmb;
>>>>>> u32 dsb_msr_num;
>>>>>> u32 cmb_msr_num;
>>>>>> + u8 traceid;
>>>>>> };
>>>>>> /* Enumerate members of various datasets */
>>>>>>
>>>>>> ---
>>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>>
>>>>>> Best regards,
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 9:50 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <act9hqxjL6wZ25dP@orome>
On 31/03/2026 10:25, Thierry Reding wrote:
>
>>> dt-bindings: phy: tegra-xusb: Document Type C support
>>
>> No acks, but that is waiting for one month so it is fine.
>
> It's got a Reviewed-by from Rob and there were no corresponding driver
> changes associated with it. There's literally no reason for this to go
> in through a subsystem tree.
There are reasons - process and technical:
1. It's a subsystem maintainer's patch, not yours. You rather should
have reason to take someone else's patches.
2. Conflict in that file.
>
>>> dt-bindings: clock: tegra124-dfll: Convert to json-schema
>>> dt-bindings: interrupt-controller: tegra: Fix reg entries
>>> dt-bindings: arm: tegra: Add missing compatible strings
>>> dt-bindings: phy: tegra: Document Tegra210 USB PHY
>>> dt-bindings: memory: Add Tegra210 memory controller bindings
>>> dt-bindings: memory: tegra210: Mark EMC as cooling device
>>
>> That's even my subsystem and I did not ack it. You did not even sent it
>> to me as requested by MAINTAINERS file (+dt is ignore alias), so
>> obviously I did not even had a chance to ack it.
>
> Ugh... really? I was Cc'ed to you as a DT maintainer as well as the
> devicetree mailing list, so I'm sure you've seen it. This had also been
Really, you are supposed to use get_maintainers.pl. Not invent the CC
list, not come with own filtered list.
I understand that my non dt address disappears when running
get_maintainers.pl on entire set.
But if you sent that patch targetting subsystem instead of combining 6
or 7 subsystems at once, it would pop up.
And yes, you are not supposed to mix 7 different subsystems in single
patchset. That's basic!
But sure, let's skip memory controllers patch cc list and:
> reviewed by Rob a long time ago, and honestly, it's also quite trivial.
> It's been on the list for a month and there were no objections, so it
> does pass all of the criteria you mentioned before.
No objections because you did not cc people. How can you claim "no
objections from person foo" if you do not cc person "foo", because you
do not use get_maintainers.pl?
Look, find me here phy mantainers:
https://lore.kernel.org/all/20260223143305.3771383-7-thierry.reding@kernel.org/
>
>> And we even had few days ago talk were I explained you how these
>> bindings must go. Seeing pull request completely ignoring that
>> discussion is just huge surprise.
>>
>> No, it cannot go in. Send patches to proper maintainers first.
>
> Stop making these baseless accusations, Krzysztof. You were on Cc and
Not using get_maintainers.pl so not ccing right address is not baseless.
This is the fact.
Neither phy, nor interrupts, nor clocks were sent to right people.
You mixed 6 or 7 different subsystems in on patchset, but you call my
remarks as baseless. You use several adjectives "trivial", "baseless",
but no actual facts.
Final commentary:
Stop taking patches from other subsystems, just because you want to
streamline your DTS. You are bypassing other subsystems review, other
people trees, and that's not acceptable.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] Enable Mali G310 GPU support on i.MX952 board
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
IP as the instance on i.MX95 boards.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
---
Guangliu Ding (2):
dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
arm64: dts: imx952: Describe Mali G310 GPU
.../bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 ++++++++++++++++++++++
2 files changed, 37 insertions(+)
---
base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
change-id: 20260331-master-7ec7ff0fe1b2
Best regards,
--
Guangliu Ding <guangliu.ding@nxp.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
In-Reply-To: <20260331-master-v1-0-65c8e318d462@nxp.com>
Add compatible string of Mali G310 GPU on i.MX952 board.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
---
Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index 8eccd4338a2b..6a10843a26e2 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -20,6 +20,7 @@ properties:
- enum:
- mediatek,mt8196-mali
- nxp,imx95-mali # G310
+ - nxp,imx952-mali # G310
- rockchip,rk3588-mali
- const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: imx952: Describe Mali G310 GPU
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
In-Reply-To: <20260331-master-v1-0-65c8e318d462@nxp.com>
Support Mali G310 GPU on i.MX952 board. Describe this GPU in the DT.
Include dummy GPU voltage regulator and OPP tables.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 +++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
index 91fe4916ac04..0bd3e7fc0674 100644
--- a/arch/arm64/boot/dts/freescale/imx952.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
@@ -318,6 +318,28 @@ usbphynop2: usbphynop2 {
clock-names = "main_clk";
};
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-hz-real = /bits/ 64 <500000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-hz-real = /bits/ 64 <800000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-hz-real = /bits/ 64 <1000000000>;
+ opp-microvolt = <920000>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -1262,5 +1284,19 @@ usbmisc2: usbmisc@4c200200 {
reg = <0x0 0x4c200200 0x0 0x200>,
<0x0 0x4c010014 0x0 0x4>;
};
+
+ gpu: gpu@4d900000 {
+ compatible = "nxp,imx952-mali", "arm,mali-valhall-csf";
+ reg = <0 0x4d900000 0 0x480000>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gpu", "job", "mmu";
+ clocks = <&scmi_clk IMX952_CLK_GPU>;
+ clock-names = "core";
+ power-domains = <&scmi_devpd IMX952_PD_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ dynamic-power-coefficient = <1013>;
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 10:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Jie Gan, Mao Jinlong
Save the trace ID in drvdata during TPDM enablement and expose it
to userspace to support trace data parsing.
The TPDM device’s trace ID corresponds to the trace ID allocated
to the connected TPDA device.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v4:
1. Return -EINVAL if the traceid is 0.
- Link to v3: https://lore.kernel.org/r/20260325-add-traceid-show-for-tpdm-v3-1-0eb836d4ec30@oss.qualcomm.com
Changes in v3:
1. Only allow user to read the traceid while the TPDM device is enabled.
- Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-for-tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
Changes in V2:
1. Use sysfs_emit instead of sprintf.
Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
---
.../ABI/testing/sysfs-bus-coresight-devices-tpdm | 10 +++++++
drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++++++++-
drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
index f8016df64532..bc36ba32c900 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
@@ -278,3 +278,13 @@ Date: Aug 2025
KernelVersion 6.18
Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
Description: (Read) Show hardware context information of device.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/traceid
+Date: March 2026
+KernelVersion: 7.1
+Contact: Jie Gan <jie.gan@oss.qualcomm.com>
+Description:
+ (R) Show the trace ID that will appear in the trace stream
+ coming from this TPDM. The trace ID is inherited from the
+ connected TPDA device and is fixed for the lifetime of the
+ device. Returns -EINVAL if the device has not been enabled yet.
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
index da77bdaad0a4..9b16f368a58b 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.c
+++ b/drivers/hwtracing/coresight/coresight-tpdm.c
@@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata *drvdata)
static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
enum cs_mode mode,
- __maybe_unused struct coresight_path *path)
+ struct coresight_path *path)
{
struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
}
__tpdm_enable(drvdata);
+ drvdata->traceid = path->trace_id;
drvdata->enable = true;
spin_unlock(&drvdata->spinlock);
@@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
.attrs = tpdm_attrs,
};
+static ssize_t traceid_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ unsigned long val;
+ struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+ val = drvdata->traceid;
+ if (!val)
+ return -EINVAL;
+
+ return sysfs_emit(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(traceid);
+
+static struct attribute *traceid_attrs[] = {
+ &dev_attr_traceid.attr,
+ NULL,
+};
+
+static struct attribute_group traceid_attr_grp = {
+ .attrs = traceid_attrs,
+};
+
static ssize_t dsb_mode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -1367,6 +1391,12 @@ static const struct attribute_group *tpdm_attr_grps[] = {
&tpdm_cmb_patt_grp,
&tpdm_cmb_msr_grp,
&tpdm_mcmb_attr_grp,
+ &traceid_attr_grp,
+ NULL,
+};
+
+static const struct attribute_group *static_tpdm_attr_grps[] = {
+ &traceid_attr_grp,
NULL,
};
@@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev, struct resource *res)
desc.access = CSDEV_ACCESS_IOMEM(base);
if (res)
desc.groups = tpdm_attr_grps;
+ else
+ desc.groups = static_tpdm_attr_grps;
drvdata->csdev = coresight_register(&desc);
if (IS_ERR(drvdata->csdev))
return PTR_ERR(drvdata->csdev);
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
index 2867f3ab8186..11da64e1ade8 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.h
+++ b/drivers/hwtracing/coresight/coresight-tpdm.h
@@ -300,6 +300,7 @@ struct cmb_dataset {
* @cmb Specifics associated to TPDM CMB.
* @dsb_msr_num Number of MSR supported by DSB TPDM
* @cmb_msr_num Number of MSR supported by CMB TPDM
+ * @traceid Trace ID of the path.
*/
struct tpdm_drvdata {
@@ -313,6 +314,7 @@ struct tpdm_drvdata {
struct cmb_dataset *cmb;
u32 dsb_msr_num;
u32 cmb_msr_num;
+ u8 traceid;
};
/* Enumerate members of various datasets */
---
base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH] mailbox: Fix NULL message support in mbox_send_message()
From: Joonwon Kang @ 2026-03-31 10:08 UTC (permalink / raw)
To: jassisinghbrar
Cc: andersson, dianders, joonwonkang, linux-arm-kernel, linux-kernel,
maz, shawn.guo, tglx
In-Reply-To: <20260327220040.53326-1-jassisinghbrar@gmail.com>
> The active_req field serves double duty as both the "is a TX in
> flight" flag (NULL means idle) and the storage for the in-flight
> message pointer. When a client sends NULL via mbox_send_message(),
> active_req is set to NULL, which the framework misinterprets as
> "no active request". This breaks the TX state machine by:
>
> - tx_tick() short-circuits on (!mssg), skipping the tx_done
> callback and the tx_complete completion
> - txdone_hrtimer() skips the channel entirely since active_req
> is NULL, so poll-based TX-done detection never fires.
>
> Fix this by introducing a MBOX_NO_MSG sentinel value that means
> "no active request," freeing NULL to be valid message data. The
> sentinel is defined in the subsystem-internal mailbox.h so that
> controller drivers within drivers/mailbox/ can reference it, but
> it is not exposed to clients outside the subsystem.
>
> Fifteen in-tree callers send NULL (doorbell-style IPCs on Qualcomm,
> Tegra, TI, Xilinx, i.MX, SCMI, and PCC platforms). All were
> audited for regression:
>
> - Most already work around the bug via knows_txdone=true with a
> manual mbox_client_txdone() call, making the framework's
> tracking irrelevant. These are unaffected.
>
> - Poll-based callers (Xilinx zynqmp/r5) are strictly better off:
> the poll timer now correctly detects NULL-active channels
> instead of silently skipping them.
>
> - irq-qcom-mpm.c was a pre-existing bug -- the only Qualcomm
> caller that omitted the knows_txdone + mbox_client_txdone()
> pattern. Fixed in a companion commit ("irqchip/qcom-mpm: Fix
> missing mailbox TX done acknowledgment").
>
> - No caller sets both a tx_done callback and sends NULL, nor
> combines tx_block=true with NULL sends, so the newly reachable
> callback/completion paths are never exercised.
>
> Also update tegra-hsp's flush callback, which directly inspects
> active_req to wait for the channel to drain: the old "!= NULL"
> check becomes "!= MBOX_NO_MSG", otherwise flush spins until
> timeout since the sentinel is non-NULL.
>
> The only tradeoff is that 'MBOX_NO_MSG' can not be used as a message
> by clients.
>
> Reported-by: Joonwon Kang <joonwonkang@google.com>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
Do you have plans to backport this patch to other stable versions?
If not, I can send the backport for you to the stable versions that are in my needs.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 10:09 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Maxime Coquelin, Alexandre Torgue, linux-arm-msm, linux-clk,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <a746be68-4f5d-4792-a896-bb693d029ea4@oss.qualcomm.com>
On 31/03/2026 11:33, Konrad Dybcio wrote:
> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>> and is not modified: neither by the driver defining it nor by common.c
>> code using it.
>>
>> Make it const for code safety and code readability.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> ---
>
> [...]
>
>> --- a/drivers/clk/qcom/common.h
>> +++ b/drivers/clk/qcom/common.h
>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>> size_t num_icc_hws;
>> unsigned int icc_first_node_id;
>> bool use_rpm;
>> - struct qcom_cc_driver_data *driver_data;
>> + const struct qcom_cc_driver_data *driver_data;
>
> This can be a const ptr to const data, even
None of other elements in 'qcom_cc_desc' is const pointer, even though
they also could. If doing this change, let's make it consistent - so
shall all of them be const?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 10:10 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <6ca492d7-c041-42b0-8f41-cd29ab7b4bab@oss.qualcomm.com>
On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 11:33, Konrad Dybcio wrote:
>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>> and is not modified: neither by the driver defining it nor by common.c
>>> code using it.
>>>
>>> Make it const for code safety and code readability.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> --- a/drivers/clk/qcom/common.h
>>> +++ b/drivers/clk/qcom/common.h
>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>> size_t num_icc_hws;
>>> unsigned int icc_first_node_id;
>>> bool use_rpm;
>>> - struct qcom_cc_driver_data *driver_data;
>>> + const struct qcom_cc_driver_data *driver_data;
>>
>> This can be a const ptr to const data, even
>
> None of other elements in 'qcom_cc_desc' is const pointer, even though
> they also could. If doing this change, let's make it consistent - so
> shall all of them be const?
I thought about it, but then it turns out that videocc-sm8550.c has:
video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
So we'd have to duplicate the entire struct
Konrad
^ permalink raw reply
* Re: [PATCH v4] coresight: tpdm: add traceid_show for checking traceid
From: James Clark @ 2026-03-31 10:10 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mao Jinlong,
Mike Leach, Leo Yan, Alexander Shishkin, Tingwei Zhang
In-Reply-To: <20260331-add-traceid-show-for-tpdm-v4-1-ed3dda24a562@oss.qualcomm.com>
On 31/03/2026 11:05 am, Jie Gan wrote:
> Save the trace ID in drvdata during TPDM enablement and expose it
> to userspace to support trace data parsing.
>
> The TPDM device’s trace ID corresponds to the trace ID allocated
> to the connected TPDA device.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> Changes in v4:
> 1. Return -EINVAL if the traceid is 0.
> - Link to v3: https://lore.kernel.org/r/20260325-add-traceid-show-for-tpdm-v3-1-0eb836d4ec30@oss.qualcomm.com
>
> Changes in v3:
> 1. Only allow user to read the traceid while the TPDM device is enabled.
> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-for-tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>
> Changes in V2:
> 1. Use sysfs_emit instead of sprintf.
> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
> ---
> .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 10 +++++++
> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++++++++-
> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
> 3 files changed, 45 insertions(+), 1 deletion(-)
>
Reviewed-by: James Clark <james.clark@linaro.org>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> index f8016df64532..bc36ba32c900 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> @@ -278,3 +278,13 @@ Date: Aug 2025
> KernelVersion 6.18
> Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
> Description: (Read) Show hardware context information of device.
> +
> +What: /sys/bus/coresight/devices/<tpdm-name>/traceid
> +Date: March 2026
> +KernelVersion: 7.1
> +Contact: Jie Gan <jie.gan@oss.qualcomm.com>
> +Description:
> + (R) Show the trace ID that will appear in the trace stream
> + coming from this TPDM. The trace ID is inherited from the
> + connected TPDA device and is fixed for the lifetime of the
> + device. Returns -EINVAL if the device has not been enabled yet.
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index da77bdaad0a4..9b16f368a58b 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata *drvdata)
>
> static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
> enum cs_mode mode,
> - __maybe_unused struct coresight_path *path)
> + struct coresight_path *path)
> {
> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
> }
>
> __tpdm_enable(drvdata);
> + drvdata->traceid = path->trace_id;
> drvdata->enable = true;
> spin_unlock(&drvdata->spinlock);
>
> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
> .attrs = tpdm_attrs,
> };
>
> +static ssize_t traceid_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> + val = drvdata->traceid;
> + if (!val)
> + return -EINVAL;
> +
> + return sysfs_emit(buf, "%#lx\n", val);
> +}
> +static DEVICE_ATTR_RO(traceid);
> +
> +static struct attribute *traceid_attrs[] = {
> + &dev_attr_traceid.attr,
> + NULL,
> +};
> +
> +static struct attribute_group traceid_attr_grp = {
> + .attrs = traceid_attrs,
> +};
> +
> static ssize_t dsb_mode_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -1367,6 +1391,12 @@ static const struct attribute_group *tpdm_attr_grps[] = {
> &tpdm_cmb_patt_grp,
> &tpdm_cmb_msr_grp,
> &tpdm_mcmb_attr_grp,
> + &traceid_attr_grp,
> + NULL,
> +};
> +
> +static const struct attribute_group *static_tpdm_attr_grps[] = {
> + &traceid_attr_grp,
> NULL,
> };
>
> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev, struct resource *res)
> desc.access = CSDEV_ACCESS_IOMEM(base);
> if (res)
> desc.groups = tpdm_attr_grps;
> + else
> + desc.groups = static_tpdm_attr_grps;
> drvdata->csdev = coresight_register(&desc);
> if (IS_ERR(drvdata->csdev))
> return PTR_ERR(drvdata->csdev);
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
> index 2867f3ab8186..11da64e1ade8 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
> @@ -300,6 +300,7 @@ struct cmb_dataset {
> * @cmb Specifics associated to TPDM CMB.
> * @dsb_msr_num Number of MSR supported by DSB TPDM
> * @cmb_msr_num Number of MSR supported by CMB TPDM
> + * @traceid Trace ID of the path.
> */
>
> struct tpdm_drvdata {
> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
> struct cmb_dataset *cmb;
> u32 dsb_msr_num;
> u32 cmb_msr_num;
> + u8 traceid;
> };
>
> /* Enumerate members of various datasets */
>
> ---
> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Krzysztof Hałasa @ 2026-03-31 10:11 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <20260330224619.2620782-4-paulk@sys-base.io>
Hi Paul,
Paul Kocialkowski writes:
> It is necessary to wait for the full frame to finish streaming
> through the DMA engine before we can safely disable it by removing
> the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> hardware confused and unable to resume streaming for the next frame.
>
> This causes the FIFO underrun and empty status bits to be set and
> a single solid color to be shown on the display, coming from one of
> the pixels of the previous frame. The issue occurs sporadically when
> a new mode is set, which triggers the crtc disable and enable paths.
>
> Setting the shadow load bit and waiting for it to be cleared by the
> DMA engine allows waiting for completion.
>
> The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
...or "addressed" in the previous version :-)
Test results: it works for me: at 1080p60 and 2160p30. I.e. it fixed the
underrun problem. It's interesting how a CRTC shutdown can affect it's
subsequent start following an SW_RESET.
Or... perhaps it has something to do with the clocks? Also see below.
If somehow the DMA engine was "running" with it's clock disabled, it
would result in an underrun, or worse.
BTW apparently something converted your tab characters into spaces.
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
> if (ret)
> drm_err(lcdif->drm, "Failed to disable controller!\n");
>
> + /*
> + * It is necessary to wait for the full frame to finish streaming
> + * through the DMA engine before we can safely disable it by removing
> + * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> + * hardware confused and unable to resume streaming for the next frame.
> + */
> + reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
> + reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
> + writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
> +
> + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> + 0, 36000); /* Wait ~2 frame times max */
I guess this comment is not necessarily correct - at 2160p30 one frame =
ca. 33 ms. Still works, though (I guess anything more than one frame is
enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can
take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60.
Also, found an issue. Perhaps unrelated? Powered the board without HDMI
connected. Then connected 1080p60 display. It came in 1024x768, console
64x24 :-)
Run weston. Pressed ctrl-alt-backspace. It deadlocked. Sysrq (serial
console, show blocked state) showed (with *lcdif* in it):
task:systemd-logind state:D stack:0 pid:253 tgid:253 ppid:1 task_flags:0x400100 flags:0x00000800
Call trace:
...
schedule+0x34/0x118
rpm_resume+0x188/0x678
__pm_runtime_resume+0x4c/0x98
clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
clk_core_set_rate_nolock+0xd0/0x2fc
clk_set_rate+0x38/0x158
lcdif_crtc_atomic_enable+0x74/0x8d0
drm_atomic_helper_commit_crtc_enable+0xac/0x104
drm_atomic_helper_commit_tail_rpm+0x68/0xd8
commit_tail+0xa4/0x1a4
drm_atomic_helper_commit+0x178/0x1a0
drm_atomic_commit+0x8c/0xcc
drm_client_modeset_commit_atomic+0x1f8/0x25c
drm_client_modeset_commit_locked+0x60/0x17c
__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x2c/0x8c
drm_fb_helper_set_par+0x5c/0x78
fb_set_var+0x190/0x35c
fbcon_blank+0x178/0x24c
do_unblank_screen+0xa8/0x19c
vt_ioctl+0x4fc/0x14c0
tty_ioctl+0x228/0xb88
__arm64_sys_ioctl+0x90/0xe4
...
This is reproducible, though not always.
It seems it locks on some mutex - the shell works until I do 'cat
log.txt' or similar. Now (with std output/error redirection?), weston
doesn't even start.
dmesg doesn't show anything of interest.
weston: 14.0.2
using /dev/dri/card1
DRM: supports atomic modesetting
DRM: supports GBM modifiers
DRM: does not support Atomic async page flip
DRM: supports picture aspect ratio
Loading module '/usr/lib64/libweston-14/gl-renderer.so'
Using rendering device: /dev/dri/renderD128
EGL version: 1.5
EGL vendor: Mesa Project
EGL client APIs: OpenGL OpenGL_ES
...
Registered plugin API 'weston_drm_output_api_v1' of size 40
Registered plugin API 'weston_drm_virtual_output_api_v2' of size 48
Color manager: no-op
protocol support: no
Output 'HDMI-A-1' attempts EOTF mode SDR and colorimetry mode default.
Output 'HDMI-A-1' using color profile: stock sRGB color profile
Chosen EGL config details: id: 17 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8
)
Output HDMI-A-1 (crtc 37) video modes:
1920x1080@60.0, preferred, current, 148.5 MHz
Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
Loading module '/usr/lib64/weston/desktop-shell.so'
launching '/usr/libexec/weston-keyboard'
launching '/usr/libexec/weston-desktop-shell'
Warning: computed repaint delay for output [HDMI-A-1] is abnormal: -69164 msec (happens always)
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
Why all these clk* mutexes? Perhaps something didn't work out as it
should there? clk_set_rate isn't supposed to take much time, is it?
$ grep clk /tmp/minicom.cap -C1
[ 728.310054] __pm_runtime_resume+0x4c/0x98
[ 728.310059] clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
[ 728.310065] clk_core_set_rate_nolock+0xd0/0x2fc
[ 728.310071] clk_set_rate+0x38/0x158
[ 728.310076] lcdif_crtc_atomic_enable+0x74/0x8d0
--
[ 728.310210] mutex_lock+0x48/0x58
[ 728.310216] clk_prepare_lock+0x80/0xc0
[ 728.310223] clk_unprepare+0x28/0x44
[ 728.310227] fsl_samsung_hdmi_phy_suspend+0x24/0x40
--
[ 728.310344] mutex_lock+0x48/0x58
[ 728.310350] clk_prepare_lock+0x80/0xc0
[ 728.310359] clk_unprepare+0x28/0x44
[ 728.310364] etnaviv_gpu_clk_disable.isra.0+0x28/0x80
[ 728.310372] etnaviv_gpu_rpm_suspend+0x78/0x1dc
--
[ 728.310494] mutex_lock+0x48/0x58
[ 728.310499] clk_prepare_lock+0x80/0xc0
[ 728.310506] clk_unprepare+0x28/0x44
[ 728.310512] sdhci_esdhc_runtime_suspend+0x7c/0x198
--
[ 728.310627] mutex_lock+0x48/0x58
[ 728.310632] clk_prepare_lock+0x80/0xc0
[ 728.310639] clk_round_rate+0x38/0x1d8
[ 728.310646] dev_pm_opp_set_rate+0xe4/0x2e0
--
[ 728.310760] mutex_lock+0x48/0x58
[ 728.310765] clk_prepare_lock+0x80/0xc0
[ 728.310771] clk_prepare+0x1c/0x50
[ 728.310778] sdhci_esdhc_runtime_resume+0x34/0x180
--
[ 728.311286] mutex_lock+0x48/0x58
[ 728.311292] clk_prepare_lock+0x80/0xc0
[ 728.311298] clk_prepare+0x1c/0x50
[ 728.311303] sdhci_esdhc_runtime_resume+0x34/0x180
Something fishy here.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Lee Jones @ 2026-03-31 10:12 UTC (permalink / raw)
To: Akashdeep Kaur
Cc: praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy, vishalm,
sebin.francis, d-gole, k-willis
In-Reply-To: <20260324101419.95616-3-a-kaur@ti.com>
---
On Tue, 24 Mar 2026, Akashdeep Kaur wrote:
> Currently, the TPS65219 driver unconditionally registers a poweroff
> handler. This causes issues on systems where a different component
> (such as TF-A firmware) should handle system poweroff instead.
>
> Make the poweroff handler registration conditional based on the
> "system-power-controller" device tree property. This follows the
> standard kernel pattern where only the designated power controller
> registers for system poweroff operations.
>
> On systems where the property is absent, the PMIC will not register
> a poweroff handler, allowing other poweroff mechanisms to function.
>
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
> drivers/mfd/tps65219.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
> index 7275dcdb7c44..6fa202339a0c 100644
> --- a/drivers/mfd/tps65219.c
> +++ b/drivers/mfd/tps65219.c
> @@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
> return ret;
> }
>
> - ret = devm_register_power_off_handler(tps->dev,
> - tps65219_power_off_handler,
> - tps);
> - if (ret) {
> - dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
> - return ret;
> + if (of_device_is_system_power_controller(tps->dev->of_node)) {
> + ret = devm_register_power_off_handler(tps->dev,
> + tps65219_power_off_handler,
> + tps);
> + if (ret)
> + return dev_err_probe(tps->dev, ret,
> + "failed to register power-off handler\n");
Couple of nits to fix.
The `"` should be aligned with the `(` and the `failed` should be capitalised.
> }
> +
> return 0;
> }
>
> --
> 2.34.1
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Arnd Bergmann @ 2026-03-31 10:11 UTC (permalink / raw)
To: Khristine Andreea Barbulescu, Krzysztof Kozlowski,
Ghennadi Procopciuc
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Aisheng Dong, Jacky Bai, Greg Kroah-Hartman, Rafael J . Wysocki,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, open list:GPIO SUBSYSTEM,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot, Rob Herring
In-Reply-To: <4c46909d-641b-4389-bc4a-29394cb1d46d@oss.nxp.com>
On Tue, Mar 31, 2026, at 09:48, Khristine Andreea Barbulescu wrote:
>
> With the current layout, the SIUL2 node itself now contains the two
> MMIO ranges directly, while the remaining child node is only the
> pinctrl/GPIO function.
The thread started by saying this is an MFD "It can export information
about the SoC, configure the pinmux&pinconf for pins and it is also
a GPIO controller with interrupt capability." Having a combined
pinctrl/gpio/irqchip driver is normal, but can you clarify what
you plan to do with the "information about the SoC" part?
Was this a "soc_device" driver, or something else? Have you
concluded now that this is not going to be needed at all?
In that case, I guess having a monolithic driver is
indeed simpler than an MFD.
What I wonder about then is whether the binding needs to be changed
at all. With the current nxp,s32g2-siul2-pinctrl.yaml binding
and pinctrl-s32g2.c implementation, you seem to have a monolithic
device already, though missing the gpio functionality. Rather
than completely replacing this, I assume the easiest way then
would be to add the PGPD registers into this device node, right?
It is still a bit weird to list the individual register areas
inside of the larger device here, but that still seems better
than an incompatible binding change.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 10:13 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Maxime Coquelin, Alexandre Torgue, linux-arm-msm, linux-clk,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <51a05279-1759-4c03-8bba-835a9e972ccb@oss.qualcomm.com>
On 31/03/2026 12:10, Konrad Dybcio wrote:
> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>> and is not modified: neither by the driver defining it nor by common.c
>>>> code using it.
>>>>
>>>> Make it const for code safety and code readability.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> --- a/drivers/clk/qcom/common.h
>>>> +++ b/drivers/clk/qcom/common.h
>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>> size_t num_icc_hws;
>>>> unsigned int icc_first_node_id;
>>>> bool use_rpm;
>>>> - struct qcom_cc_driver_data *driver_data;
>>>> + const struct qcom_cc_driver_data *driver_data;
>>>
>>> This can be a const ptr to const data, even
>>
>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>> they also could. If doing this change, let's make it consistent - so
>> shall all of them be const?
>
> I thought about it, but then it turns out that videocc-sm8550.c has:
>
> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>
> So we'd have to duplicate the entire struct
No, that's not a problem. Pointer is not modified and we speak here
about const pointer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Chen-Yu Tsai @ 2026-03-31 10:15 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Krzysztof Kozlowski, linux-mediatek, Fabien Parent, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+1bc9Z-opoNqyUU_WFzyXZKGQmR_Ur=4UonOC=AWtQ8w@mail.gmail.com>
On Tue, Mar 31, 2026 at 4:36 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > - required:
> > > - - compatible
> >
> > Not really, this affects existing ABI and might make the child schema
> > being applied. Basically regulators node can be anything now.
> >
> > This is definitely not a binding we want. The syntax for parent schema
> > when listing only compatibles is requiring this compatible. You cannot
> > have here whatever empty node.
>
> Hi, it felt quite strange to me too, but that's what I thought you
> meant with your previous suggestion [1].
> To keep the required attribute I would be happy to reintroduce the
> compatible here, in the regulator schema and the pmic dtsi.
>
> Before I do that and resubmit, could you please help me understand
> what you meant before?
I think the point is that compatibles for regulator sub-nodes on MFDs
is no longer accepted.
Instead if you want to have a separate binding for the regulator part,
you would need to reference the binding directly.
Say the binding is at bindings/regulator/mt6392.yaml, in this patch
you would have something after the "additionalProperties: false" like:
allOf:
- if:
properties:
"compatible":
contains:
const: mediatek,mt6392
then:
properties:
regulators:
$ref: /schemas/regulator/mt6392.yaml
else:
properties:
regulators:
required:
- compatible
And drop the "required: - compatible" part from the common regulator
node bits of the binding.
ChenYu
> Thank you!
>
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
>
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 10:17 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <445a53e3-f467-40fc-9b01-dc776555c3fb@oss.qualcomm.com>
On 3/31/26 12:13 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:10, Konrad Dybcio wrote:
>> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>>> and is not modified: neither by the driver defining it nor by common.c
>>>>> code using it.
>>>>>
>>>>> Make it const for code safety and code readability.
>>>>>
>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> --- a/drivers/clk/qcom/common.h
>>>>> +++ b/drivers/clk/qcom/common.h
>>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>>> size_t num_icc_hws;
>>>>> unsigned int icc_first_node_id;
>>>>> bool use_rpm;
>>>>> - struct qcom_cc_driver_data *driver_data;
>>>>> + const struct qcom_cc_driver_data *driver_data;
>>>>
>>>> This can be a const ptr to const data, even
>>>
>>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>>> they also could. If doing this change, let's make it consistent - so
>>> shall all of them be const?
>>
>> I thought about it, but then it turns out that videocc-sm8550.c has:
>>
>> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>>
>> So we'd have to duplicate the entire struct
>
> No, that's not a problem. Pointer is not modified and we speak here
> about const pointer.
Right, I already had constifying the various struct members in mind
Konrad
^ 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