* Re: [PATCH v9 3/3] PCI: mediatek: Add support for EcoNet EN7528 SoC
From: sashiko-bot @ 2026-05-21 18:27 UTC (permalink / raw)
To: Caleb James DeLisle; +Cc: conor+dt, robh, linux-pci, devicetree
In-Reply-To: <20260521171951.1495781-4-cjd@cjdns.fr>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The driver bypasses module export boundaries and locking encapsulation by using IS_BUILTIN() to access unexported PCI core functions and locks.
- [High] Retraining the PCIe link after `pci_host_probe()` causes the link to drop while endpoint drivers are actively probing and operating.
- [High] A failure to retrain one root port aborts the entire loop, leaving subsequent ports stuck at Gen1.
--
commit c15a1642adf464e152e3330bafda659a6425825d
Author: Caleb James DeLisle <cjd@cjdns.fr>
Subject: PCI: mediatek: Add support for EcoNet EN7528 SoC
This commit adds support for the PCIe controller present on the EcoNet EN7528
and EN751221 SoCs. It includes a quirk to retrain the link to Gen2 after
startup, as some Gen2-capable ports initially start in Gen1 mode.
> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index c503fbd774d09..30f8070967b82 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
[ ... ]
> +static int mtk_pcie_retrain(struct device *dev, struct pci_host_bridge *host)
> +{
> + struct pci_dev *rp;
> + int ret = -ENOENT;
> + u16 lnksta = 0;
> + u32 speed;
> +
> + /* Should already have been warned about during startup_port */
> + if (!IS_BUILTIN(CONFIG_PCIE_MEDIATEK))
> + return 0;
> +
> + guard(rwsem_read)(&pci_bus_sem);
[Severity: High]
Does using IS_BUILTIN() to conditionally access internal locks like pci_bus_sem
and unexported functions bypass module export boundaries?
When compiled as a module, does this silently break functionality by
completely skipping the Gen2 link retraining and leaving the ports permanently
degraded to Gen1?
> +
> + for_each_pci_bridge(rp, host->bus) {
> + if (pci_pcie_type(rp) != PCI_EXP_TYPE_ROOT_PORT)
> + continue;
> +
> +#if IS_BUILTIN(CONFIG_PCIE_MEDIATEK)
> + ret = pcie_retrain_link(rp, true);
> +#endif
> +
> + if (ret)
> + return dev_err_probe(&rp->dev, ret,
> + "failed to retrain port\n");
[Severity: High]
If pcie_retrain_link() fails for one root port, does returning immediately skip
retraining for all remaining root ports on the bus?
Since the caller explicitly ignores the return value of mtk_pcie_retrain(),
should this perhaps just log an error and continue to the next port instead?
> +
> + pcie_capability_read_word(rp, PCI_EXP_LNKSTA, &lnksta);
> + speed = lnksta & PCI_EXP_LNKSTA_CLS;
> +
> + pci_info(rp, "link retrained, speed %s\n",
> + pci_speed_string(pcie_link_speed[speed]));
> +
> + }
> +
> + return 0;
> +}
[ ... ]
> @@ -1159,6 +1298,13 @@ static int mtk_pcie_probe(struct platform_device *pdev)
> if (err)
> goto put_resources;
>
> + /*
> + * Ignore error because pci_host_probe() was already called, and in any
> + * case it is possible that the port will still work as Gen1.
> + */
> + if (pcie->soc->quirks & MTK_PCIE_RETRAIN)
> + mtk_pcie_retrain(dev, host);
[Severity: High]
Does retraining the link here cause it to drop while endpoint drivers are
already actively probing?
Because pci_host_probe() enumerates the bus and binds endpoint drivers,
taking the link down immediately after could cause concurrent MMIO or DMA
transactions to fail. Could this also result in endpoint drivers observing
incorrect Gen1 link speeds during their initialization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260521171951.1495781-1-cjd@cjdns.fr?part=3
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc: xlnx: enable auto boot feature
From: Shah, Tanmay @ 2026-05-21 18:38 UTC (permalink / raw)
To: Mathieu Poirier, Tanmay Shah
Cc: andersson, robh, krzk+dt, conor+dt, michal.simek, ben.levinsky,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <ag9FcXeIIiJWdld7@p14s>
Hello,
Thank you for the reviews, please find my comments below:
On 5/21/2026 12:48 PM, Mathieu Poirier wrote:
> Good morning,
>
> I don't recal reviewing the first revision of this set. Can you provide a link
> to it so that I can read the comments that were provided?
>
Here it is:
https://lore.kernel.org/linux-remoteproc/20260422202558.2362971-1-tanmay.shah@amd.com/
The device-tree bindings needed rework in v1, so I sent v2, before we
ever reviewed the driver part.
> On Fri, May 01, 2026 at 07:37:07AM -0700, Tanmay Shah wrote:
>> remoteproc framework has capability to start (or attach to) the remote
>
> The remoteproc framework...
>
Ack.
>> processor automatically if auto boot flag is set by the driver during
>> probe. If remote core is not started before the Linux boot, and linux is
>> expected to start the remote core then it uses "firmware-name" property
>> to load default firmware during auto boot.
>>
>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>> ---
>> drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
>> 1 file changed, 34 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> index 45a62cb98072..652030f9cea2 100644
>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> @@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
>> };
>>
>> /**
>> - * zynqmp_r5_add_rproc_core() - Add core data to framework.
>> - * Allocate and add struct rproc object for each r5f core
>> + * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
>> + * Allocate struct rproc object for each r5f core
>> * This is called for each individual r5f core
>> *
>> * @cdev: Device node of each r5 core
>> *
>> * Return: zynqmp_r5_core object for success else error code pointer
>> */
>> -static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> +static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
>
> Why is there a need to change the function's name?
>
Before, the function was actually adding the rproc core by calling
rproc_add() function, but now it only allocates the memory by calling
rproc_alloc(). For auto boot to work it's important to add rproc core
after all the other hw is initialized (such as mbox, tcm, sram,
power-domains etc). More details below [1].
>> {
>> struct zynqmp_r5_core *r5_core;
>> + const char *fw_name = NULL;
>> struct rproc *r5_rproc;
>> int ret;
>>
>> @@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> if (ret)
>> return ERR_PTR(ret);
>>
>> + ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
>> + if (ret < 0 && ret != -EINVAL)
>> + return ERR_PTR(dev_err_probe(cdev, ret,
>> + "failed to parse firmware-name\n"));
>> +
>> /* Allocate remoteproc instance */
>> r5_rproc = rproc_alloc(cdev, dev_name(cdev),
>> &zynqmp_r5_rproc_ops,
>> - NULL, sizeof(struct zynqmp_r5_core));
>> + fw_name, sizeof(struct zynqmp_r5_core));
>> if (!r5_rproc) {
>> dev_err(cdev, "failed to allocate memory for rproc instance\n");
>> return ERR_PTR(-ENOMEM);
>> @@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> r5_rproc->recovery_disabled = true;
>> r5_rproc->has_iommu = false;
>> r5_rproc->auto_boot = false;
>> +
>> + /* attempt to boot automatically if the firmware-name is provided */
>> + if (fw_name)
>> + r5_rproc->auto_boot = true;
>> +
>
> What happens when a firmware name needs to be provided in the DT but you don't
> want to automatically boot the remote processor?
>
I think that use case is not needed. If the user/system-designer doesn't
want auto-boot, then having firmware-name in the device-tree serves no
purpose. User can always load the firmware via sysfs once kernel boots.
>> r5_core = r5_rproc->priv;
>> r5_core->dev = cdev;
>> r5_core->np = dev_of_node(cdev);
>> @@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> goto free_rproc;
>> }
>>
>> - /* Add R5 remoteproc core */
>> - ret = rproc_add(r5_rproc);
>> - if (ret) {
>> - dev_err(cdev, "failed to add r5 remoteproc\n");
>> - goto free_rproc;
>> - }
>> -
>
> I'm not sure why there is a need to move this to zynqmp_r5_cluster_init()? Is
> it simply to make the error path easier to handle? If so, please do that in a
> separate patch.
>
[1] This was moved to make auto-boot work. The remote core can auto-boot
only after other hardware is initialized. The zynqmp_r5_core_init()
initializes sram, TCM and power-domains of the core. Also, mailbox is
requested before zynqmp_r5_core_init() as well. We can't auto-boot core
directly without all this. So, I had to move rproc_add() at the end of
the cluster init, and rename above function from
zynqmp_r5_add_rproc_core to zynqmp_r5_alloc_rproc_core.
If you prefer, I will add above explanation in the commit text, or as
comment right before rproc_add().
>> r5_core->rproc = r5_rproc;
>> return r5_core;
>>
>> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
>> if (zynqmp_r5_get_rsc_table_va(r5_core))
>> dev_dbg(r5_core->dev, "rsc tbl not found\n");
>> r5_core->rproc->state = RPROC_DETACHED;
>> + r5_core->rproc->auto_boot = true;
>
> I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?
>
That function is now zynqmp_r5_alloc_core() as mentioned above. Also,
until now, auto_boot was set to 'false' only to show that it is
disabled. It is actually used and enabled now.
> Thanks,
> Mathieu
>
>> }
>> }
>>
>> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>> enum rpu_oper_mode fw_reg_val;
>> struct device **child_devs;
>> enum rpu_tcm_comb tcm_mode;
>> - int core_count, ret, i;
>> + int core_count, ret, i, j;
>> struct mbox_info *ipi;
>>
>> ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
>> @@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>> child_devs[i] = &child_pdev->dev;
>>
>> /* create and add remoteproc instance of type struct rproc */
>> - r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
>> + r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
>> if (IS_ERR(r5_cores[i])) {
>> ret = PTR_ERR(r5_cores[i]);
>> r5_cores[i] = NULL;
>> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>> goto release_r5_cores;
>> }
>>
>> + for (j = 0; j < cluster->core_count; j++) {
>> + /* Add R5 remoteproc core */
>> + ret = rproc_add(r5_cores[j]->rproc);
>> + if (ret) {
>> + dev_err_probe(r5_cores[j]->dev, ret,
>> + "failed to add remoteproc\n");
>> + goto delete_r5_cores;
>> + }
>> + }
>> +
>> kfree(child_devs);
>> return 0;
>>
>> +delete_r5_cores:
>> + i = core_count - 1;
>> + /* delete previous added rproc */
>> + while (--j >= 0)
>> + rproc_del(r5_cores[j]->rproc);
>> +
>> release_r5_cores:
>> while (i >= 0) {
>> put_device(child_devs[i]);
>> if (r5_cores[i]) {
>> zynqmp_r5_free_mbox(r5_cores[i]->ipi);
>> of_reserved_mem_device_release(r5_cores[i]->dev);
>> - rproc_del(r5_cores[i]->rproc);
>> rproc_free(r5_cores[i]->rproc);
>> }
>> i--;
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: mdio: remove deprecated .txt binding stub
From: Krzysztof Kozlowski @ 2026-05-21 18:41 UTC (permalink / raw)
To: Akash Sukhavasi, krzk+dt
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Conor Dooley, netdev, devicetree, linux-kernel
In-Reply-To: <20260521144235.3414-1-akash.sukhavasi@gmail.com>
On 21/05/2026 16:42, Akash Sukhavasi wrote:
> The plain text binding file was superseded by the YAML schema in
> commit 62d77ff7ecbf ("dt-bindings: net: Add a YAML schemas for the
> generic MDIO options"). The file now contains only a redirect notice.
> Remove it.
Why removing it? The file was left on purpose why converting, so you
should provide reasons why now it is worth to remove it.
Don't do such patches one by one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc: xlnx: enable auto boot feature
From: Shah, Tanmay @ 2026-05-21 18:48 UTC (permalink / raw)
To: Mathieu Poirier, Tanmay Shah
Cc: andersson, robh, krzk+dt, conor+dt, michal.simek, ben.levinsky,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cbd418a3-1585-4592-8e86-b0750e19ec0f@amd.com>
On 5/21/2026 1:38 PM, Shah, Tanmay wrote:
> Hello,
>
> Thank you for the reviews, please find my comments below:
>
> On 5/21/2026 12:48 PM, Mathieu Poirier wrote:
>> Good morning,
>>
>> I don't recal reviewing the first revision of this set. Can you provide a link
>> to it so that I can read the comments that were provided?
>>
>
> Here it is:
> https://lore.kernel.org/linux-remoteproc/20260422202558.2362971-1-tanmay.shah@amd.com/
>
> The device-tree bindings needed rework in v1, so I sent v2, before we
> ever reviewed the driver part.
>
>
>> On Fri, May 01, 2026 at 07:37:07AM -0700, Tanmay Shah wrote:
>>> remoteproc framework has capability to start (or attach to) the remote
>>
>> The remoteproc framework...
>>
>
> Ack.
>
>>> processor automatically if auto boot flag is set by the driver during
>>> probe. If remote core is not started before the Linux boot, and linux is
>>> expected to start the remote core then it uses "firmware-name" property
>>> to load default firmware during auto boot.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>> drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
>>> 1 file changed, 34 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> index 45a62cb98072..652030f9cea2 100644
>>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> @@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
>>> };
>>>
>>> /**
>>> - * zynqmp_r5_add_rproc_core() - Add core data to framework.
>>> - * Allocate and add struct rproc object for each r5f core
>>> + * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
>>> + * Allocate struct rproc object for each r5f core
>>> * This is called for each individual r5f core
>>> *
>>> * @cdev: Device node of each r5 core
>>> *
>>> * Return: zynqmp_r5_core object for success else error code pointer
>>> */
>>> -static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> +static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
>>
>> Why is there a need to change the function's name?
>>
>
> Before, the function was actually adding the rproc core by calling
> rproc_add() function, but now it only allocates the memory by calling
> rproc_alloc(). For auto boot to work it's important to add rproc core
> after all the other hw is initialized (such as mbox, tcm, sram,
> power-domains etc). More details below [1].
>
>>> {
>>> struct zynqmp_r5_core *r5_core;
>>> + const char *fw_name = NULL;
>>> struct rproc *r5_rproc;
>>> int ret;
>>>
>>> @@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> if (ret)
>>> return ERR_PTR(ret);
>>>
>>> + ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
>>> + if (ret < 0 && ret != -EINVAL)
>>> + return ERR_PTR(dev_err_probe(cdev, ret,
>>> + "failed to parse firmware-name\n"));
>>> +
>>> /* Allocate remoteproc instance */
>>> r5_rproc = rproc_alloc(cdev, dev_name(cdev),
>>> &zynqmp_r5_rproc_ops,
>>> - NULL, sizeof(struct zynqmp_r5_core));
>>> + fw_name, sizeof(struct zynqmp_r5_core));
>>> if (!r5_rproc) {
>>> dev_err(cdev, "failed to allocate memory for rproc instance\n");
>>> return ERR_PTR(-ENOMEM);
>>> @@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> r5_rproc->recovery_disabled = true;
>>> r5_rproc->has_iommu = false;
>>> r5_rproc->auto_boot = false;
>>> +
>>> + /* attempt to boot automatically if the firmware-name is provided */
>>> + if (fw_name)
>>> + r5_rproc->auto_boot = true;
>>> +
>>
>> What happens when a firmware name needs to be provided in the DT but you don't
>> want to automatically boot the remote processor?
>>
>
> I think that use case is not needed. If the user/system-designer doesn't
> want auto-boot, then having firmware-name in the device-tree serves no
> purpose. User can always load the firmware via sysfs once kernel boots.
>
>>> r5_core = r5_rproc->priv;
>>> r5_core->dev = cdev;
>>> r5_core->np = dev_of_node(cdev);
>>> @@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> goto free_rproc;
>>> }
>>>
>>> - /* Add R5 remoteproc core */
>>> - ret = rproc_add(r5_rproc);
>>> - if (ret) {
>>> - dev_err(cdev, "failed to add r5 remoteproc\n");
>>> - goto free_rproc;
>>> - }
>>> -
>>
>> I'm not sure why there is a need to move this to zynqmp_r5_cluster_init()? Is
>> it simply to make the error path easier to handle? If so, please do that in a
>> separate patch.
>>
>
> [1] This was moved to make auto-boot work. The remote core can auto-boot
> only after other hardware is initialized. The zynqmp_r5_core_init()
> initializes sram, TCM and power-domains of the core. Also, mailbox is
> requested before zynqmp_r5_core_init() as well. We can't auto-boot core
> directly without all this. So, I had to move rproc_add() at the end of
> the cluster init, and rename above function from
> zynqmp_r5_add_rproc_core to zynqmp_r5_alloc_rproc_core.
>
> If you prefer, I will add above explanation in the commit text, or as
> comment right before rproc_add().
>
>
>
>>> r5_core->rproc = r5_rproc;
>>> return r5_core;
>>>
>>> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
>>> if (zynqmp_r5_get_rsc_table_va(r5_core))
>>> dev_dbg(r5_core->dev, "rsc tbl not found\n");
>>> r5_core->rproc->state = RPROC_DETACHED;
>>> + r5_core->rproc->auto_boot = true;
>>
>> I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?
>>
>
> That function is now zynqmp_r5_alloc_core() as mentioned above. Also,
> until now, auto_boot was set to 'false' only to show that it is
> disabled. It is actually used and enabled now.
>
"I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?"
I probably misunderstood this comment. Here is the correct explanation:
The auto_boot setting in the zynqmp_r5_alloc_core() is done if the
'firmware-name' property is present in the device-tree.
Here it is done, if the remote core is already running. This is to
support attach-detach use case.
So, auto_boot is possible in two cases: 1) If firmware-name property is
available (Linux boots the remote), 2) If firmware is already loaded and
remote was started by the boot loader. (Linux attaches to the running
remote).
This is the second use case.
Thanks,
Tanmay
>> Thanks,
>> Mathieu
>>
>>> }
>>> }
>>>
>>> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>>> enum rpu_oper_mode fw_reg_val;
>>> struct device **child_devs;
>>> enum rpu_tcm_comb tcm_mode;
>>> - int core_count, ret, i;
>>> + int core_count, ret, i, j;
>>> struct mbox_info *ipi;
>>>
>>> ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
>>> @@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>>> child_devs[i] = &child_pdev->dev;
>>>
>>> /* create and add remoteproc instance of type struct rproc */
>>> - r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
>>> + r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
>>> if (IS_ERR(r5_cores[i])) {
>>> ret = PTR_ERR(r5_cores[i]);
>>> r5_cores[i] = NULL;
>>> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>>> goto release_r5_cores;
>>> }
>>>
>>> + for (j = 0; j < cluster->core_count; j++) {
>>> + /* Add R5 remoteproc core */
>>> + ret = rproc_add(r5_cores[j]->rproc);
>>> + if (ret) {
>>> + dev_err_probe(r5_cores[j]->dev, ret,
>>> + "failed to add remoteproc\n");
>>> + goto delete_r5_cores;
>>> + }
>>> + }
>>> +
>>> kfree(child_devs);
>>> return 0;
>>>
>>> +delete_r5_cores:
>>> + i = core_count - 1;
>>> + /* delete previous added rproc */
>>> + while (--j >= 0)
>>> + rproc_del(r5_cores[j]->rproc);
>>> +
>>> release_r5_cores:
>>> while (i >= 0) {
>>> put_device(child_devs[i]);
>>> if (r5_cores[i]) {
>>> zynqmp_r5_free_mbox(r5_cores[i]->ipi);
>>> of_reserved_mem_device_release(r5_cores[i]->dev);
>>> - rproc_del(r5_cores[i]->rproc);
>>> rproc_free(r5_cores[i]->rproc);
>>> }
>>> i--;
>>> --
>>> 2.34.1
>>>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: Configure DP endpoints for 2-lane operation
From: Val Packett @ 2026-05-21 18:57 UTC (permalink / raw)
To: Saurabh Anand, andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, quic_riteshk,
quic_vproddut, quic_mkuntuma, mahadevan.p
In-Reply-To: <20260521120058.2966709-1-saurabh.anand@oss.qualcomm.com>
On 5/21/26 9:00 AM, Saurabh Anand wrote:
> Add explicit data-lanes to the MDSS DP output endpoints to enable
> display port in 2 lanes configuration and disable the mode-switch
> property from the USB QMP PHY node.
Why?
4 lane DP has been working great on hamoa and makena for quite a while now..
If there's something missing for now specifically on glymur, please add
an explanation.
~val
^ permalink raw reply
* [PATCH v2 1/6] ARM: dts: imx: add (power|vdd)-supply for related node
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add required power-supply and vdd-supply properties to fix below CHECK_DTB
warnings:
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dtb: panel (edt,etm0700g0dh6): 'power-supply' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- change regulator name to 5v (sashika AI)
---
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 9 +++++++++
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +++++++
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
4 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
index 6210673f93bea..2acbc86cabb31 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
@@ -84,6 +84,7 @@ panel {
pinctrl-0 = <&pinctrl_display_gpio>;
pinctrl-names = "default";
enable-gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_3p2v>;
port {
panel_in: endpoint {
@@ -98,6 +99,13 @@ beeper {
gpios = <&gpio6 3 GPIO_ACTIVE_HIGH>;
};
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
reg_usbh1_vbus: regulator-usbh1-vbus {
compatible = "regulator-fixed";
regulator-name = "vbus";
@@ -259,6 +267,7 @@ eeprom@50 {
dac@60 {
compatible = "microchip,mcp4725";
reg = <0x60>;
+ vdd-supply = <®_3v3>;
};
};
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
index e395004e80e6d..34cb0c344ff6e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
@@ -10,6 +10,7 @@
/ {
panel: panel-rgb {
compatible = "powertip,ph800480t013-idf02";
+ power-supply = <®_5v>;
port {
panel_rgb_in: endpoint {
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
index 1a00d290092ad..ebec884958776 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
@@ -29,6 +29,13 @@ memory@70000000 {
reg = <0x70000000 0x20000000>;
};
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
reg_usb1_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts b/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
index 24fc3ff1c70c2..cd9a050fa906e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
@@ -109,6 +109,7 @@ led-heartbeat {
panel: panel {
compatible = "innolux,n133hse-ea1";
backlight = <&backlight>;
+ power-supply = <®_lvds_lcd>;
};
reg_2p5v: regulator-2p5v {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/6] ARM: dts: cleanup some CHECK_DTBS warning for imx5/6 (round 2)
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
Cleanup CHECK_DTBS warning for imx_v6_v7_defconfig. (below 500 line warning
left) after apply pending binding doc patch.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
- fix sashiko AI's feedback, detail see each patch's change log
- Link to v1: https://lore.kernel.org/r/20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com
---
Frank Li (6):
ARM: dts: imx: add (power|vdd)-supply for related node
ARM: dts: imx: remove redundant bus-width for video-mux
ARM: dts: imx: Add bus-type for ov5642/ov5640
ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 11 ++++++++++-
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +++++++
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 ----
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 5 ++---
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 2 +-
30 files changed, 37 insertions(+), 39 deletions(-)
---
base-commit: d26bfe9856a36453f591b9620dac996ff9f02443
change-id: 20260511-imx25_dts_simple_warning_2-10d3c75b8889
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v2 2/6] ARM: dts: imx: remove redundant bus-width for video-mux
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Remove redundant bus-width property according to video-mux.yaml to fix
below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-gw51xx.dtb: ipu1_csi0_mux (video-mux): port@4:endpoint: Unevaluated properties are not allowed ('bus-width' was unexpected)
from schema $id: http://devicetree.org/schemas/media/video-mux.yaml
The bus-width already set at remote endpoint (camera).
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 ----
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 --
10 files changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
index 9ea23dd54f3ce..62b05fe70cd97 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
index 182e8194c2490..c1787510d3941 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
index a106c4e3e3299..934b0325e6f5a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
index 6e1c493c9c8c4..31996ddde117a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu2_csi1_mux: endpoint {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
index f13df8e9c8c4b..f224273fa863e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu2_csi1_mux: endpoint {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
index d5d46908cf6ed..804ee044be52d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
@@ -90,12 +90,10 @@ tda1997x_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <16>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
- bus-width = <16>;
};
&ipu1_csi0 {
@@ -104,12 +102,10 @@ &ipu1_csi0 {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
index beff5a0f58ab4..fb18b87adb441 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
@@ -384,12 +384,10 @@ adv7180_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
index 6136a95b92599..55647c1dacfa5 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
@@ -440,12 +440,10 @@ tda1997x_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <16>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
- bus-width = <16>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
index 552114a69f5b9..bdbcad5e35d82 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
@@ -397,12 +397,10 @@ adv7180_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
index b9dde0af3b995..40d8887cb8bc7 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
@@ -245,12 +245,10 @@ accelerometer@1c {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/6] ARM: dts: imx: Add bus-type for ov5642/ov5640
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add bus-type (MEDIA_BUS_TYPE_PARALLEL) for ov5642/ov5640. i.MX53 and
i.MX6UL only supports parallel csi interface. Fix below CHECK_DTBS
warnings:
arm/boot/dts/nxp/imx/imx53-smd.dtb: ov5642@3c (ovti,ov5642): port:endpoint: 'bus-type' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-smd.dts b/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
index a1e19f9709b2c..8c02731c7ba9d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include <dt-bindings/input/input.h>
+#include <dt-bindings/media/video-interfaces.h>
#include "imx53.dtsi"
/ {
@@ -314,6 +315,7 @@ camera: ov5642@3c {
port {
ov5642_to_ipu_csi0: endpoint {
remote-endpoint = <&ipu_csi0_from_parallel_sensor>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
bus-width = <8>;
hsync-active = <1>;
vsync-active = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
index 3d147b160ecf1..32afe4130e211 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
@@ -217,6 +217,7 @@ camera@3c {
port {
ov5640_to_parallel: endpoint {
remote-endpoint = <¶llel_from_ov5640>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
bus-width = <8>;
data-shift = <2>; /* lines 9:2 are used */
hsync-active = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/6] ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Remove the undocumented and unused compatible karo,imx6qdl-tx6-sgtl5000 and
retain only the generic simple-audio-card sound configuration.
The karo,imx6qdl-tx6-sgtl5000 compatible is not documented and is not
referenced by any in-kernel driver. The audio setup is already fully
described using simple-audio-card, which is the standard and supported
binding for this hardware configuration.
No known users (such as uboot) rely on karo,imx6qdl-tx6-sgtl5000.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-tx6dl-comtft.dtb: /sound: failed to match any schema with compatible: ['karo,imx6qdl-tx6-sgtl5000', 'simple-audio-card']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
index 57297d6521cf0..ec1528ff3ea01 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
@@ -148,8 +148,7 @@ reg_usbotg_vbus: regulator-usbotg-vbus {
};
sound {
- compatible = "karo,imx6qdl-tx6-sgtl5000",
- "simple-audio-card";
+ compatible = "simple-audio-card";
simple-audio-card,name = "imx6qdl-tx6-sgtl5000-audio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/6] ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
The edt,edt-ft5x06 compatible is not referenced in
drivers/input/touchscreen/edt-ft5x06.c and is not documented.
There is no publicly available datasheet or binding information that
distinguishes edt-ft5206/ft5306/ft5406 variants and the driver treats these
FT5x06-family controllers with the same configuration model. So switch to
the lowest common and documented baseline compatible edt,edt-ft5206.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dtb: /soc/bus@60000000/i2c@63fc8000/touchscreen@38: failed to match any schema with compatible: ['edt,edt-ft5x06']
ABI impact consideration:
Not affect Linux kernel. The I2C subsystem uses a legacy fallback mechanism
where it strips the vendor prefix from the compatible string to derive the
client name, resulting in edt-ft5x06
{ .name = "edt-ft5x06", .driver_data = (long)&edt_ft5x06_data },
After this, the driver was actively binding to these devices based on the
compatible string.
Known user (U-Boot) does not parse or use edt,edt-ft* touchscreen
compatibles.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- update commit about ABI impact base on feedback from sashiko AI
- add missed change in imx6qdl-nitrogen6_som2.dtsi (sashiko AI)
Change binding doc discuss at
- https://lore.kernel.org/imx/aasmQiZJO2gSKzNH@lizhi-Precision-Tower-5810/
---
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 2 +-
14 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
index 2acbc86cabb31..aa1c7e5012c6a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
@@ -248,7 +248,7 @@ &i2c1 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts b/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
index 872cf7e16f20c..6a1063c455f0c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
@@ -201,7 +201,7 @@ sgtl5000: codec@a {
};
polytouch: edt-ft5x06@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06_1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts b/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
index 0225a621ec7a9..ccf6a048c9184 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
@@ -169,7 +169,7 @@ &i2c3 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
index 610b2a72fe825..cebfd622df688 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
@@ -256,7 +256,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
index ef0c26688446e..f8a7218b13ef2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
@@ -405,7 +405,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi
index 03fe053880ca6..fb1c923c46bca 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi
@@ -326,7 +326,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
index 6a353a99e13da..9fe52e0ca7aa2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
@@ -333,7 +333,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
index c39a9ebdaba1c..ca4cb986efbc2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
@@ -217,7 +217,7 @@ &i2c2 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio5>;
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
index ec1528ff3ea01..fe25934e06b1f 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
@@ -292,7 +292,7 @@ sgtl5000: sgtl5000@a {
};
polytouch: edt-ft5x06@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
index bf7dbb4f1f3ed..e99ba04216b86 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
@@ -62,7 +62,7 @@ &i2c3 {
status = "okay";
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
index 6cfc943a8fa3e..f79090fb2e6e2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
@@ -65,7 +65,7 @@ &i2c3 {
status = "okay";
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
index 1992dfb53b45c..192c6a95ae589 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
@@ -317,7 +317,7 @@ sgtl5000: codec@a {
};
polytouch: polytouch@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
index 347dd0fe4f82e..fca8aab9d8507 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
@@ -70,7 +70,7 @@ pca9554: io-expander@25 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_touchscreen>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
index 62221131336f1..673bbe49de525 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
@@ -49,7 +49,7 @@ sgtl5000: codec@a {
&i2c4 {
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_touchscreen>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 6/6] ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Replace the vendor-specific PHY compatible string with the generic
ethernet-phy-ieee802.3-c22 compatible.
The marvell,88E1510 compatible is listed in whitelist_phys[] and is
never matched against a PHY driver. PHY devices are expected to use
the generic ethernet-phy-ieee802.3-c22 compatible unless a specific
MDIO driver match is required.
The 88E1510 is compatible with Clause 22 PHY devices, so use the
generic compatible string instead.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6q-display5-tianma-tm070-1280x768.dtb: /soc/bus@2100000/ethernet@2188000/mdio/ethernet-phy@0: failed to match any schema with compatible: ['marvell,88E1510']
Known other user (uboot) did not use marvell,88E1510.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi b/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
index 4e448b4810f27..21e8bbdab4e69 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
@@ -208,7 +208,7 @@ mdio {
#address-cells = <1>;
#size-cells = <0>;
ethernet_phy0: ethernet-phy@0 {
- compatible = "marvell,88E1510";
+ compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
/* Set LED0 control: */
/* On - Link, Blink - Activity, Off - No Link */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 8/8] iio: temperature: ltc2983: Add support for ADT7604
From: sashiko-bot @ 2026-05-21 19:18 UTC (permalink / raw)
To: Liviu Stan; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260521164323.770626-9-liviu.stan@analog.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Reading the IIO_RESISTANCE channel bypasses hardware fault detection, causing hardware errors (like broken sensor traces) to be silently reported as valid data.
Pre-existing issues:
- [High] reinit_completion() is called after initiating the hardware conversion, creating a race condition that can cause spurious read timeouts.
--
commit d382a4cbefd41723ab5ddd91fd399d716c8faaec
Author: Liviu Stan <liviu.stan@analog.com>
Subject: iio: temperature: ltc2983: Add support for ADT7604
This commit adds support for the ADT7604 temperature sensor by repurposing
custom RTD and thermistor types as copper trace resistance and leak detector
sensors. It introduces two new software sensor types and exposes a new
IIO_RESISTANCE channel reading from a separate result register bank. The
ltc2983_chip_info struct is also extended to use a 64-bit supported_sensors
bitmask for the new types.
> diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
> index 326f843f42713..e2ffeee026eef 100644
> --- a/drivers/iio/temperature/ltc2983.c
> +++ b/drivers/iio/temperature/ltc2983.c
[ ... ]
> @@ -1205,7 +1502,8 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
> }
>
> static int ltc2983_chan_read(struct ltc2983_data *st,
> - const struct ltc2983_sensor *sensor, int *val)
> + const struct ltc2983_sensor *sensor,
> + u32 base_reg, int *val)
> {
> struct device *dev = &st->spi->dev;
> u32 start_conversion = 0;
[Severity: High]
This is a pre-existing issue, but can this function experience spurious
read timeouts due to a race condition with the completion?
Looking at the rest of this function:
ret = regmap_write(st->regmap, LTC2983_STATUS_REG, start_conversion);
if (ret)
return ret;
reinit_completion(&st->completion);
If the hardware conversion finishes very quickly after regmap_write(),
could the interrupt fire and call complete() before the CPU executes
reinit_completion()? This would overwrite the completion event, causing the
subsequent wait_for_completion_timeout() to spuriously time out.
Would it be safer to call reinit_completion() before initiating the hardware
action?
[ ... ]
> @@ -1236,13 +1534,23 @@ static int ltc2983_chan_read(struct ltc2983_data *st,
> }
>
> /* read the converted data */
> - ret = regmap_bulk_read(st->regmap, LTC2983_RESULT_ADDR(sensor->chan),
> + ret = regmap_bulk_read(st->regmap, LTC2983_RESULT_ADDR(sensor->chan, base_reg),
> &st->temp, sizeof(st->temp));
> if (ret)
> return ret;
>
> *val = __be32_to_cpu(st->temp);
>
> + if (base_reg == ADT7604_RES_RES_START_REG) {
> + /*
> + * Resistance result register gives a plain unsigned value,
> + * D31 is always 0, no valid bit, no fault bits. Read bits[30:0]
> + * directly — the temperature result format does not apply here.
> + */
> + *val &= GENMASK(30, 0);
> + return 0;
[Severity: High]
Will returning early here bypass hardware fault detection for resistance
channels?
As the comment notes, the resistance result register does not contain fault
bits. However, hardware fault indicators (like Hard Fault, Soft Fault, or
Over Range) are stored in the primary Temperature Result register.
By returning before reading the Temperature Result register and calling
sensor->fault_handler(), does this code silently ignore sensor faults? This
might be problematic for sub-ohm copper traces, which only expose the
IIO_RESISTANCE channel, leaving users with no mechanism to detect a broken
trace.
> + }
> +
> if (!(LTC2983_RES_VALID_MASK & *val)) {
> dev_err(dev, "Invalid conversion detected\n");
> return -EIO;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260521164323.770626-1-liviu.stan@analog.com?part=8
^ permalink raw reply
* Re: [PATCH 0/2] soc: qcom: socinfo: Add SoC ID for SM7750
From: Bjorn Andersson @ 2026-05-21 19:28 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Koskovich
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260412-sm7550-id-v1-0-958a673ff791@pm.me>
On Sun, 12 Apr 2026 15:42:33 +0000, Alexander Koskovich wrote:
> Add the ID for the SM7750 which is a variant of Eliza, and found on the
> Nothing Phone (4a) Pro.
>
>
Applied, thanks!
[1/2] dt-bindings: arm: qcom,ids: Add SoC ID for SM7750
commit: 5073d284650a585dc2450d682ae0c0052b253ae4
[2/2] soc: qcom: socinfo: Add SoC ID for SM7750
commit: d8eae83cefbc251f090b074b533616684e7b60cf
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] Add SoC ID for Nord SA8797P
From: Bjorn Andersson @ 2026-05-21 19:28 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Jingyi Wang, Bartosz Golaszewski, Deepti Jaggi,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20260427003531.229671-1-shengchao.guo@oss.qualcomm.com>
On Mon, 27 Apr 2026 08:35:29 +0800, Shawn Guo wrote:
> Nord is a SoC family from Qualcomm designed as the next generation of
> Lemans series. SA8797P is the automotive variant of Nord, where the
> platform resources such as clocks, regulators, interconnects, etc. are
> managed by firmware through SCMI.
>
> This series adds Nord SA8797P SoC ID to dt-bindngs header and socinfo
> driver.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: arm: qcom,ids: Add SoC ID for Nord SA8797P
commit: 0670a10b7c22bef36d9e1ca5a75b832db4508a1b
[2/2] soc: qcom: socinfo: Add SoC ID for Nord SA8797P
commit: b0bc160c311a0e7163c00a7e66116d28ce9771df
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* [PATCH v2 1/1] dt-bindings: display: imx: Add television encoder (TVE) for imx53
From: Frank.Li @ 2026-05-21 19:37 UTC (permalink / raw)
To: Philipp Zabel, 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,
open list:DRM DRIVERS FOR FREESCALE IMX 5/6,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx, Krzysztof Kozlowski
From: Frank Li <Frank.Li@nxp.com>
Add television encoder (TVE) for legacy i.MX53 (over 15 years) to fix below
DTB_CHECK warnings:
arch/arm/boot/dts/nxp/imx/imx53-ard.dtb: /soc/bus@60000000/tve@63ff0000: failed to match any schema with compatible: ['fsl,imx53-tve']
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Change in v2
- add Krzysztof Kozlowski's review tag
- move fsl,tve-mode to required list
About cleanup 300 lines warnings for i.MX ARM platformi
---
.../bindings/display/imx/fsl,imx53-tve.yaml | 104 ++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml
new file mode 100644
index 0000000000000..2fcf447459122
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx53-tve.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX53 Television Encoder (TVE)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The Television Encoder (TVE) is a hardware block in the i.MX53 SoC that
+ converts digital video data into analog TV signals (NTSC/PAL).
+
+properties:
+ compatible:
+ const: fsl,imx53-tve
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TVE gate clock
+ - description: Display interface selector clock
+
+ clock-names:
+ items:
+ - const: tve
+ - const: di_sel
+
+ ddc-i2c-bus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the I2C bus used for DDC (Display Data Channel) communication
+ to read EDID information from the connected display.
+
+ dac-supply:
+ description:
+ Regulator supply for the TVE DAC (Digital-to-Analog Converter).
+
+ fsl,tve-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ TVE output mode selection.
+ enum:
+ - ntsc
+ - pal
+ - vga
+
+ fsl,hsync-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Pin number for horizontal sync signal in VGA mode.
+ minimum: 0
+ maximum: 8
+
+ fsl,vsync-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Pin number for vertical sync signal in VGA mode.
+ minimum: 0
+ maximum: 8
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port node with one endpoint connected to the IPU display interface.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - fsl,tve-mode
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx5-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ tve@63ff0000 {
+ compatible = "fsl,imx53-tve";
+ reg = <0x63ff0000 0x1000>;
+ interrupts = <92>;
+ clocks = <&clks IMX5_CLK_TVE_GATE>,
+ <&clks IMX5_CLK_IPU_DI1_SEL>;
+ clock-names = "tve", "di_sel";
+ fsl,tve-mode = "vga";
+
+ port {
+ endpoint {
+ remote-endpoint = <&ipu_di1_tve>;
+ };
+ };
+ };
+
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 4/5] dt-bindings: display: Add Synaptics R63455 panel support
From: Conor Dooley @ 2026-05-21 19:45 UTC (permalink / raw)
To: Jun Nie
Cc: Rob Clark, Dmitry Baryshkov, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, dri-devel,
freedreno, linux-kernel, devicetree
In-Reply-To: <20260521-sm8650-7-1-bonded-dsi-v4-4-a4dd5e0850f1@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 4787 bytes --]
On Thu, May 21, 2026 at 10:46:06PM +0800, Jun Nie wrote:
> Add support for the dual-panel system found in the virtual reality device.
> This system consists of two physical 2160x2160 panels, each connected via
> a MIPI DSI interface. The backlight is managed through DSI link.
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> .../bindings/display/panel/synaptics,r63455.yaml | 125 +++++++++++++++++++++
> 1 file changed, 125 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
> new file mode 100644
> index 0000000000000..a94b355ed9557
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/synaptics,r63455.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synaptics R63455 based dual 2160x2160 MIPI-DSI Panel
> +
> +maintainers:
> + - Jun Nie <jun.nie@linaro.org>
> +
> +description:
> + Synaptics R63455 is a Virtual Reality Display Driver and VR Bridge, used in
> + pair in Headset devices. The Virtual Reality Display complex is composed of
> + two strictly identical display panels, each driven by its own DSI interface
> + but forms a single virtual display for the human eye perception and thus
> + requires a strict synchronization of the two display panel content update.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - sharp,ls026b3sa06
> + - boe,vs026c4m-n52-6000
> + - const: synaptics,r63455
> +
> + reset-gpios:
> + maxItems: 2
> + description: 2 reset pins for 2 physical panels
> +
> + left-pos-supply:
> + description: Positive 5.7V supply for left panel
> +
> + right-pos-supply:
> + description: Positive 5.7V supply for right panel
> +
> + left-neg-supply:
> + description: Negative 5.7V supply for left panel
> +
> + right-neg-supply:
> + description: Negative 5.7V supply for right panel
> +
> + left-backlight-supply:
> + description: Backlight 21V supply for left panel
> +
> + right-backlight-supply:
> + description: Backlight 21V supply for right panel
> +
> + vdda-supply:
> + description: core 1.8V supply for panels
> +
> + ports: $ref: /schemas/graph.yaml#/properties/ports
Missing a newline in this, but also probably missing going into more
detail about the ports themselves.
Sashiko complaints look valid.
pw-bot: changes-requested
Thanks,
Conor.
> +
> +required:
> + - compatible
> + - reset-gpios
> + - left-pos-supply
> + - left-neg-supply
> + - right-pos-supply
> + - right-neg-supply
> + - left-backlight-supply
> + - right-backlight-supply
> + - vdda-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + &mdss_dsi0 {
> + vdda-supply = <&vreg_l3i_1p2>;
> + status = "okay";
> +
> + qcom,dual-dsi-mode;
> + qcom,master-dsi;
> +
> + panel: panel@0 {
> + compatible = "sharp,ls026b3sa06", "synaptics,r63455";
> + reg = <0>;
> +
> + reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>,
> + <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
> +
> + left-pos-supply = <&vpos_left>;
> + left-neg-supply = <&vneg_left>;
> + right-pos-supply = <&vpos_right>;
> + right-neg-supply = <&vneg_right>;
> + left-backlight-supply = <&backlight_left>;
> + right-backlight-supply = <&backlight_right>;
> +
> + vdda-supply = <&vreg_l12b_1p8>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <&mdss_dsi0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + panel1_in: endpoint {
> + remote-endpoint = <&mdss_dsi1_out>;
> + };
> + };
> + };
> + };
> +
> + &mdss_dsi0_out {
> + remote-endpoint = <&panel0_in>;
> + data-lanes = <0 1 2>;
> + };
> +
> + &mdss_dsi1_out {
> + remote-endpoint = <&panel1_in>;
> + data-lanes = <0 1 2>;
> + };
> +...
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] spi: dt-bindings: fsl-qspi: support SpacemiT K3
From: Conor Dooley @ 2026-05-21 19:46 UTC (permalink / raw)
To: Zhengyu He
Cc: Han Xu, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-spi, imx, devicetree, linux-kernel,
linux-riscv, spacemit, Wei Fu, Cody Kang
In-Reply-To: <20260521-k3-pico-itx-qspi-v2-for-next-20260521-v2-1-52bce26e5fd8@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: rockchip: analogix-dp: Add data-lanes example
From: Conor Dooley @ 2026-05-21 19:47 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521114459.1394264-3-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
On Thu, May 21, 2026 at 07:44:58PM +0800, Damon Ding wrote:
> Add data-lanes setting in endpoint example to show actual lane mapping
> usage.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Squash this with patch 1.
pw-bot: changes-requested
Thanks,
Conor.
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index bb75d898a5c5..cf75c926318b 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -151,6 +151,7 @@ examples:
> reg = <1>;
>
> edp_out_panel: endpoint {
> + data-lanes = <0 1>;
> remote-endpoint = <&panel_in_edp>;
> };
> };
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: display: bridge: analogix-dp: Add data-lanes support for endpoint
From: Conor Dooley @ 2026-05-21 19:50 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521114459.1394264-2-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]
On Thu, May 21, 2026 at 07:44:57PM +0800, Damon Ding wrote:
> Add data-lanes property support to the port@1 endpoint for physical
> lane mapping configuration.
>
> Lane mapping is mainly used for below scenarios:
> 1. Correct PCB lane swap and differential line routing crossover
> without hardware changes;
> 2. Adapt mismatched lane pin definitions between SoC and eDP panel;
> 3. Support multiple panel hardware variants on the same board
> by configuring data-lanes in device tree only.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Sashiko complaint here looks valid.
pw-bot: changes-requested
Thanks,
Conor.
>
> ---
>
> Changes in v2:
> - Add lane mapping application scenarios in commit message.
> - Remove redundant deprecated property 'data-lanes' for eDP node.
> - Update port@1 $ref to /schemas/graph.yaml#/$defs/port-base.
> ---
> .../bindings/display/bridge/analogix,dp.yaml | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> index 62f0521b0924..e34fdb21adb4 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> @@ -42,13 +42,20 @@ properties:
> properties:
> port@0:
> $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Input node to receive pixel data.
> + description: Input node to receive pixel data.
>
> port@1:
> - $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Port node with one endpoint connected to a dp-connector node.
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description: Port node with one endpoint connected to sink device node.
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> + items:
> + enum: [ 0, 1, 2, 3 ]
>
> required:
> - port@0
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 1/1] dt-bindings: trivial-devices: add fsl,mc1323
From: Frank.Li @ 2026-05-21 19:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Guenter Roeck,
Frank Li, Wensheng Wang, Cosmo Chou, Brian Chiang, Eddie James,
Nuno Sá, Antoni Pokusinski, Dixit Parmar,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
From: Frank Li <Frank.Li@nxp.com>
Add freescale 2.4 GHz IEEE® 802.15.4/ZigBee mc1323 to fix the below
CHECK_DTBS warnings.
arch/arm/boot/dts/nxp/imx/imx53-smd.dtb: /soc/bus@60000000/tve@63ff0000: failed to match any schema with compatible: ['fsl,imx53-tve']
Since the i.MX53 platform is more than 20 years old, it is difficult to
find detailed information about how the MC1323 was used on the i.MX53 SMD
board, as the functionality depended on firmware.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- add descript about reason in commit message
---
Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 46a4dca50c485..6ff96e10d0785 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -127,6 +127,8 @@ properties:
- domintech,dmard09
# DMARD10: 3-axis Accelerometer
- domintech,dmard10
+ # Freescale 2.4 GHz IEEE® 802.15.4/ZigBee
+ - fsl,mc1323
# MMA7660FC: 3-Axis Orientation/Motion Detection Sensor
- fsl,mma7660
# MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Conor Dooley @ 2026-05-21 19:54 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521080835.1362416-2-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]
On Thu, May 21, 2026 at 04:08:26PM +0800, Damon Ding wrote:
> RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
> registers and enable the video datapath.
>
> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
> phandle reference, which allowed the eDP to work without explicitly
> managing the hclk_vo1 clock. However, this is not safe or explicit.
>
> To make the clock dependency explicit, enforce per-SoC clock-names
> requirements:
> - RK3288: 2 clocks (dp, pclk)
> - RK3399: 3 clocks (dp, pclk, grf)
> - RK3588: 3 clocks (dp, pclk, hclk)
>
> Do not reuse the 'grf' clock name for RK3588 because it represents
> a different clock with distinct control logic:
> - The 'grf' clock is only for GRF register access and is toggled
> dynamically during register access.
> - The 'hclk' clock controls both GRF access and video datapath
> gating, and must remain enabled during probe.
>
> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v4:
> - Modify the commit msg.
>
> Changes in v5:
> - Enforce the correct third clock name on a per-compatible basis.
> - Modify the commit msg simultaneously.
>
> Changes in v6:
> - Expand more detail commit msg about using hclk instead of grf clock.
> ---
> .../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index d99b23b88cc5..8001c1facf98 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -23,10 +23,7 @@ properties:
>
> clock-names:
> minItems: 2
> - items:
> - - const: dp
> - - const: pclk
> - - const: grf
Instead of removing this, you can make it
items:
- const: dp
- const pclk
- enum:
- grf
- hclk
> + maxItems: 3
And delete this.
>
> power-domains:
> maxItems: 1
> @@ -60,6 +57,33 @@ required:
> allOf:
> - $ref: /schemas/display/bridge/analogix,dp.yaml#
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3288-dp
> + then:
> + properties:
> + clock-names:
> + items:
> + - const: dp
> + - const: pclk
Then this becomes
clock-names:
maxItems: 2
clocks:
maxItems: 2
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3399-edp
> + then:
> + properties:
> + clock-names:
> + items:
> + - const: dp
> + - const: pclk
> + - const: grf
maybe this needs a minItems: 3? Depends on if the grf clock is
mandatory. Also probably needs a
clocks:
minItems: 3
if that's the case.
> +
> - if:
> properties:
> compatible:
> @@ -68,6 +92,11 @@ allOf:
> - rockchip,rk3588-edp
> then:
> properties:
> + clock-names:
> + items:
> + - const: dp
> + - const: pclk
> + - const: hclk
And the same here as for the 3399.
Cheers,
Conor.
> resets:
> minItems: 2
> reset-names:
> --
> 2.34.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: display: panel: document the Renesas R63419 based dual-DSI video mode Display Panels
From: Conor Dooley @ 2026-05-21 19:55 UTC (permalink / raw)
To: Neil Armstrong
Cc: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, dri-devel, devicetree, linux-kernel,
linux-renesas-soc, Dmitry Baryshkov
In-Reply-To: <20260521-topic-sm8650-ayaneo-pocket-s2-r63419-v5-1-dd5700299390@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v9 1/2] dt-bindings: usb: cdns3: Add cdns,cdnsp compatible string
From: Conor Dooley @ 2026-05-21 19:59 UTC (permalink / raw)
To: pawell
Cc: Peter Chen, Roger Quadros, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb, devicetree,
linux-kernel
In-Reply-To: <20260521-no_drd_config_v9-v9-1-2512cef10104@cadence.com>
[-- Attachment #1: Type: text/plain, Size: 3824 bytes --]
On Thu, May 21, 2026 at 10:16:23AM +0200, Pawel Laszczak via B4 Relay wrote:
> From: Pawel Laszczak <pawell@cadence.com>
>
> Introduce a new generic fallback compatible string 'cdns,cdnsp' for
> Cadence USBSSP controllers to support hardware configurations where
> the Dual-Role Device (DRD) register block is missing or inaccessible.
>
> Following the maintainer's feedback, avoid generic property-like naming
> (such as "-no-drd") and use a clean generic fallback. To keep the schema
> resource-driven and strictly validated, define a two-string compatible
> matrix using an empty schema ({}) wildcard. This allows future vendor
> SoC compatibles to be prepended while safely falling back to the 2-resource
> USBSSP configuration.
>
> When 'cdns,cdnsp' is matched:
> - The 'otg' register and interrupt resources are not required.
> - The 'reg' and 'interrupts' properties are restricted to 2 items
> (host and device).
> - 'dr_mode' must be explicitly set to either 'host' or 'peripheral'.
>
> The standard 'cdns,usb3' compatible remains unchanged, maintaining
> backward compatibility by requiring all 3 resource sets (otg, host, dev).
>
> Signed-off-by: Pawel Laszczak <pawell@cadence.com>
> ---
> v9:
> - Dropped the "cdns,cdnsp-no-drd" string to avoid generic property-like
> naming as requested by Conor.
> - Introduced the clean generic fallback "cdns,cdnsp".
>
> v8:
> - Update commit message to reflect schema changes.
> - Removed 'cdns,no-drd' boolean property as per Rob Herring's suggestion.
> - Introduced a new compatible string 'cdns,cdnsp-no-drd' for controller
> variants that lack the DRD/OTG register block.
>
> v7:
> - Rename 'no_drd' to 'cdns,no-drd'.
> - Update commit message to reflect property renaming and schema changes.
> - Simplify 'reg-names' using a single enum.
> - Revert 'interrupt-names' to a list of constants.
> - Move 'reg' item descriptions to if/else blocks for accuracy.
> - Clean up 'if/then' logic (remove redundant checks).
> - Add explicit 'items' list for 'interrupt-names' in the 'else' block.
>
> v6:
> - Fixed validation error for 'interrupt-names' by correcting
> the items definition.
> - Adjusted 'minItems'/'maxItems' to properly support the optional
> 'wakeup' interrupt.
> - Fixed 'too long' schema error in examples.
>
> v5:
> - Implemented strict conditional validation using if-then-else logic.
> - Enforced 2 register/interrupt items and required 'dr_mode'
> (host or peripheral) when 'no_drd' is present.
> - Enforced the standard 3 register/interrupt items (otg, host, dev)
> when 'no_drd' is absent to ensure backward compatibility.
> - Updated 'reg-names' and 'interrupt-names' to use enums in the main
> properties section to support flexible resource ordering during
> validation.
> ---
> ---
> .../devicetree/bindings/usb/cdns,usb3.yaml | 63 ++++++++++++++++++----
> 1 file changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
> index 2d95fb7321af..e8082c5c05a2 100644
> --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
> +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
> @@ -17,22 +17,24 @@ description:
>
> properties:
> compatible:
> - const: cdns,usb3
> + oneOf:
> + - const: cdns,usb3
> + - items:
> + - {}
> + - const: cdns,cdnsp
I think this is reasonable now. If you respin again, could you add a
comment here to the cdnsp case to explain what it represents, unless
"cdnsp" will be really obvious to anyone who has this IP in their
device?
Otherwise,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: trivial-devices: add fsl,mc1323
From: sashiko-bot @ 2026-05-21 20:02 UTC (permalink / raw)
To: Frank.Li; +Cc: devicetree, Frank.Li, conor+dt, robh, imx
In-Reply-To: <20260521195233.1532852-1-Frank.Li@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The commit message incorrectly cites a CHECK_DTBS warning for a TV encoder ('fsl,imx53-tve') instead of the ZigBee transceiver ('fsl,mc1323') that the patch actually adds.
- [Low] A complex ZigBee radio transceiver is incorrectly classified as a trivial device, masking an incomplete device tree node.
--
commit 2100488cb966e136f1c1fefe29da8444b4dcd893
Author: Frank Li <Frank.Li@nxp.com>
dt-bindings: trivial-devices: add fsl,mc1323
This commit adds the Freescale MC1323 2.4 GHz IEEE 802.15.4/ZigBee
transceiver to the trivial-devices bindings list to resolve dtbs_check
warnings on the i.MX53 SMD board.
> Add freescale 2.4 GHz IEEE® 802.15.4/ZigBee mc1323 to fix the below
> CHECK_DTBS warnings.
> arch/arm/boot/dts/nxp/imx/imx53-smd.dtb: /soc/bus@60000000/tve@63ff0000: failed to match any schema with compatible: ['fsl,imx53-tve']
[Severity: Medium]
Is the CHECK_DTBS warning cited here correct for this patch?
The warning mentions a TV encoder ('fsl,imx53-tve') at a different node,
but this patch adds the ZigBee transceiver ('fsl,mc1323').
It looks like the wrong error log might have been pasted into the commit
message.
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 23fd4513933a4..28b059c858dd1 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -127,6 +127,8 @@ properties:
> - domintech,dmard09
> # DMARD10: 3-axis Accelerometer
> - domintech,dmard10
> + # Freescale 2.4 GHz IEEE® 802.15.4/ZigBee
> + - fsl,mc1323
[Severity: Low]
Should a complex ZigBee radio transceiver be classified as a trivial device?
The trivial-devices.yaml schema is intended for simple devices requiring
only compatible, reg, and optionally interrupts properties. As an IEEE
802.15.4 MAC/PHY transceiver, wouldn't the MC1323 inherently require other
hardware resources like clocks or regulators?
Adding it to the trivial list seems to bypass proper DT validation and
could mask an incomplete device tree node.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260521195233.1532852-1-Frank.Li@oss.nxp.com?part=1
^ 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