* Re: [PATCH v3 4/5] clk: spacemit: k3: mark top_dclk as CLK_IS_CRITICAL
From: Brian Masney @ 2026-03-31 14:16 UTC (permalink / raw)
To: Troy Mitchell
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, dmaengine, devicetree, linux-riscv, spacemit,
linux-kernel, linux-clk
In-Reply-To: <20260331-k3-pdma-v3-4-a4e60dd8b4b3@linux.spacemit.com>
On Tue, Mar 31, 2026 at 04:27:07PM +0800, Troy Mitchell wrote:
> top_dclk is the DDR bus clock. If it is gated by clk_disable_unused,
> all memory-mapped bus transactions cease to function, causing DMA
> engines to hang and general system instability.
>
> Mark it CLK_IS_CRITICAL so the CCF never gates it during the
> unused clock sweep.
>
> Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree")
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Frank Li @ 2026-03-31 14:12 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260331102303.33181-9-akhilrajeev@nvidia.com>
On Tue, Mar 31, 2026 at 03:53:01PM +0530, Akhil R wrote:
> Use 'iommu-map', when provided, to get the stream ID to be programmed
> for each channel. Iterate over the channels registered and configure
> each channel device separately using of_dma_configure_id() to allow
> it to use a separate IOMMU domain for the transfer. However, do this
> in a second loop since the first loop populates the DMA device channels
> list and async_device_register() registers the channels. Both are
> prerequisites for using the channel device in the next loop.
>
> Channels will continue to use the same global stream ID if the
> 'iommu-map' property is not present in the device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/dma/tegra186-gpc-dma.c | 53 ++++++++++++++++++++++++++++------
> 1 file changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
> index 9bea2ffb3b9e..cd480d047204 100644
> --- a/drivers/dma/tegra186-gpc-dma.c
> +++ b/drivers/dma/tegra186-gpc-dma.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_dma.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/reset.h>
> #include <linux/slab.h>
> @@ -1380,9 +1381,13 @@ static int tegra_dma_program_sid(struct tegra_dma_channel *tdc, int stream_id)
> static int tegra_dma_probe(struct platform_device *pdev)
> {
> const struct tegra_dma_chip_data *cdata = NULL;
> + struct tegra_dma_channel *tdc;
> + struct tegra_dma *tdma;
> + struct dma_chan *chan;
> + struct device *chdev;
> + bool use_iommu_map = false;
> unsigned int i;
> u32 stream_id;
> - struct tegra_dma *tdma;
> int ret;
>
> cdata = of_device_get_match_data(&pdev->dev);
> @@ -1410,9 +1415,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
>
> tdma->dma_dev.dev = &pdev->dev;
>
> - if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id)) {
> - dev_err(&pdev->dev, "Missing iommu stream-id\n");
> - return -EINVAL;
> + use_iommu_map = of_property_present(pdev->dev.of_node, "iommu-map");
> + if (!use_iommu_map) {
> + if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id))
> + return dev_err_probe(&pdev->dev, -EINVAL, "Missing iommu stream-id\n");
> }
>
> ret = device_property_read_u32(&pdev->dev, "dma-channel-mask",
> @@ -1424,9 +1430,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
> tdma->chan_mask = TEGRA_GPCDMA_DEFAULT_CHANNEL_MASK;
> }
>
> + /* Initialize vchan for each channel and populate the channels list */
> INIT_LIST_HEAD(&tdma->dma_dev.channels);
> for (i = 0; i < cdata->nr_channels; i++) {
> - struct tegra_dma_channel *tdc = &tdma->channels[i];
> + tdc = &tdma->channels[i];
>
> /* Check for channel mask */
> if (!(tdma->chan_mask & BIT(i)))
> @@ -1446,10 +1453,6 @@ static int tegra_dma_probe(struct platform_device *pdev)
>
> vchan_init(&tdc->vc, &tdma->dma_dev);
> tdc->vc.desc_free = tegra_dma_desc_free;
> -
> - /* program stream-id for this channel */
> - tegra_dma_program_sid(tdc, stream_id);
> - tdc->stream_id = stream_id;
> }
>
> dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(cdata->addr_bits));
> @@ -1483,6 +1486,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
> tdma->dma_dev.device_synchronize = tegra_dma_chan_synchronize;
> tdma->dma_dev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
>
> + /* Register the DMA device and the channels */
> ret = dmaenginem_async_device_register(&tdma->dma_dev);
> if (ret < 0) {
> dev_err_probe(&pdev->dev, ret,
> @@ -1490,6 +1494,37 @@ static int tegra_dma_probe(struct platform_device *pdev)
> return ret;
> }
>
> + /*
> + * Configure stream ID for each channel from the channels registered
> + * above. This is done in a separate iteration to ensure that only
> + * the channels available and registered for the DMA device are used.
> + */
> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
> + chdev = &chan->dev->device;
> + tdc = to_tegra_dma_chan(chan);
> +
> + if (use_iommu_map) {
> + chdev->bus = pdev->dev.bus;
> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
> +
> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
> + true, &tdc->id);
> + if (ret)
> + return dev_err_probe(chdev, ret,
> + "Failed to configure IOMMU for channel %d\n", tdc->id);
> +
> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id))
> + return dev_err_probe(chdev, -EINVAL,
> + "Failed to get stream ID for channel %d\n", tdc->id);
> +
> + chan->dev->chan_dma_dev = true;
> + }
> +
> + /* program stream-id for this channel */
> + tegra_dma_program_sid(tdc, stream_id);
> + tdc->stream_id = stream_id;
> + }
> +
> ret = devm_of_dma_controller_register(&pdev->dev, pdev->dev.of_node,
> tegra_dma_of_xlate, tdma);
> if (ret < 0) {
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Arnd Bergmann @ 2026-03-31 14:08 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: <fd8c90ec-927e-4395-85ba-9e45c23fd799@oss.nxp.com>
On Tue, Mar 31, 2026, at 15:43, Khristine Andreea Barbulescu wrote:
> On 3/31/2026 1:11 PM, Arnd Bergmann wrote:
>
> Our initial intention had been to expose that SoC-information as
> discussed in the earlier revisions of this series. However,
> taking the review feedback into account, the current direction is
> to stop handling those SoC information registers in the Linux driver
> altogether and instead rely on a boot firmware to pass that
> information forward, as you suggested.
>
> With this approach, the SIUL2 driver would no longer be responsible
> for any separate SoC-information functionality. In that case,
> I understand your point that a monolithic pinctrl/GPIO/irqchip
> driver is a better fit than keeping the MFD structure.
Ok
> However, as you mentioned, this is still weird because it means
> listing individual register areas of the larger device inside.
>
> For this reason, I was wondering whether it would still be
> acceptable to move forward with the new binding introduced
> in this series, but simplify it so that it describes a single
> monolithic SIUL2 pinctrl/GPIO device instead of an MFD,
> following the example node I included in my previous reply [1].
>
> [1]
> https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@oss.nxp.com/T/#m778088251774a15bde7463350d6e75d5e9b9b57d
I can't think of a justification for making this an incompatible
binding change, if the new "nxp,s32g-siul2-pinctrl" binding is almost
the same as the old "nxp,s32g2-siul2-pinctrl" one, and you still
plan to support both versions in the same driver indefinitely.
It would seem much easier to me to make sure that nxp,s32g-siul2-pinctrl
remains backwards compatible with the existing driver and only
adds the properties for gpio support on top, so a single
driver can handle both old and new dts files.
Arnd
^ permalink raw reply
* Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display
From: Krzysztof Kozlowski @ 2026-03-31 14:05 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <20260331-dts-qcom-eliza-display-v1-0-856f0b66b282@oss.qualcomm.com>
On 31/03/2026 16:02, Krzysztof Kozlowski wrote:
> Dependency
> ==========
> Depends on USB patches, which are being reviewed, therefore marking it
> as RFC as it cannot be applied.
> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>
> Unmerged bindings used here
> ===========================
> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
> (DRM MDSS bindings were applied)
I missed update from Bjorn - the dispcc bindings were merged, so the DTS
depends on that branch with clock headers.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v12 3/3] of: Respect #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta, Charan Teja Kalla
In-Reply-To: <20260331-parse_iommu_cells-v12-0-decfd305eea9@oss.qualcomm.com>
From: Robin Murphy <robin.murphy@arm.com>
So far our parsing of {iommu,msi}-map properties has always blindly
assumed that the output specifiers will always have exactly 1 cell.
This typically does happen to be the case, but is not actually enforced
(and the PCI msi-map binding even explicitly states support for 0 or 1
cells) - as a result we've now ended up with dodgy DTs out in the field
which depend on this behaviour to map a 1-cell specifier for a 2-cell
provider, despite that being bogus per the bindings themselves.
Since there is some potential use in being able to map at least single
input IDs to multi-cell output specifiers (and properly support 0-cell
outputs as well), add support for properly parsing and using the target
nodes' #cells values, albeit with the unfortunate complication of still
having to work around expectations of the old behaviour too.
Since there are multi-cell output specifiers, the callers of of_map_id()
may need to get the exact cell output value for further processing.
Update of_map_id() to set args_count in the output to reflect the actual
number of output specifier cells.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
drivers/of/base.c | 155 ++++++++++++++++++++++++++++++++++++++++-------------
include/linux/of.h | 6 ++-
2 files changed, 123 insertions(+), 38 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b3d002015192..7b22e2484e1c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2096,18 +2096,48 @@ int of_find_last_cache_level(unsigned int cpu)
return cache_level;
}
+/*
+ * Some DTs have an iommu-map targeting a 2-cell IOMMU node while
+ * specifying only 1 cell. Fortunately they all consist of value '1'
+ * as the 2nd cell entry with the same target, so check for that pattern.
+ *
+ * Example:
+ * IOMMU node:
+ * #iommu-cells = <2>;
+ *
+ * Device node:
+ * iommu-map = <0x0000 &smmu 0x0000 0x1>,
+ * <0x0100 &smmu 0x0100 0x1>;
+ */
+static bool of_check_bad_map(const __be32 *map, int len)
+{
+ __be32 phandle = map[1];
+
+ if (len % 4)
+ return false;
+ for (int i = 0; i < len; i += 4) {
+ if (map[i + 1] != phandle || map[i + 3] != cpu_to_be32(1))
+ return false;
+ }
+ return true;
+}
+
/**
* of_map_id - Translate an ID through a downstream mapping.
* @np: root complex device node.
* @id: device ID to map.
* @map_name: property name of the map to use.
+ * @cells_name: property name of target specifier cells.
* @map_mask_name: optional property name of the mask to use.
* @filter_np: optional device node to filter matches by, or NULL to match any.
* If non-NULL, only map entries targeting this node will be matched.
* @arg: pointer to a &struct of_phandle_args for the result. On success,
- * @arg->args[0] will contain the translated ID. If a map entry was
- * matched, @arg->np will be set to the target node with a reference
- * held that the caller must release with of_node_put().
+ * @arg->args_count will be set to the number of output specifier cells
+ * as defined by @cells_name in the target node, and
+ * @arg->args[0..args_count-1] will contain the translated output
+ * specifier values. If a map entry was matched, @arg->np will be set
+ * to the target node with a reference held that the caller must release
+ * with of_node_put().
*
* Given a device ID, look up the appropriate implementation-defined
* platform ID and/or the target device which receives transactions on that
@@ -2116,17 +2146,19 @@ int of_find_last_cache_level(unsigned int cpu)
* Return: 0 on success or a standard error code on failure.
*/
int of_map_id(const struct device_node *np, u32 id,
- const char *map_name, const char *map_mask_name,
+ const char *map_name, const char *cells_name,
+ const char *map_mask_name,
const struct device_node *filter_np, struct of_phandle_args *arg)
{
u32 map_mask, masked_id;
- int map_len;
+ int map_bytes, map_len, offset = 0;
+ bool bad_map = false;
const __be32 *map = NULL;
if (!np || !map_name || !arg)
return -EINVAL;
- map = of_get_property(np, map_name, &map_len);
+ map = of_get_property(np, map_name, &map_bytes);
if (!map) {
if (filter_np)
return -ENODEV;
@@ -2136,11 +2168,9 @@ int of_map_id(const struct device_node *np, u32 id,
return 0;
}
- if (!map_len || map_len % (4 * sizeof(*map))) {
- pr_err("%pOF: Error: Bad %s length: %d\n", np,
- map_name, map_len);
- return -EINVAL;
- }
+ if (map_bytes % sizeof(*map))
+ goto err_map_len;
+ map_len = map_bytes / sizeof(*map);
/* The default is to select all bits. */
map_mask = 0xffffffff;
@@ -2153,39 +2183,82 @@ int of_map_id(const struct device_node *np, u32 id,
of_property_read_u32(np, map_mask_name, &map_mask);
masked_id = map_mask & id;
- for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+
+ while (offset < map_len) {
struct device_node *phandle_node;
- u32 id_base = be32_to_cpup(map + 0);
- u32 phandle = be32_to_cpup(map + 1);
- u32 out_base = be32_to_cpup(map + 2);
- u32 id_len = be32_to_cpup(map + 3);
+ u32 id_base, phandle, id_len, id_off, cells = 0;
+ const __be32 *out_base;
+
+ if (map_len - offset < 2)
+ goto err_map_len;
+
+ id_base = be32_to_cpup(map + offset);
if (id_base & ~map_mask) {
- pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n",
- np, map_name, map_name,
- map_mask, id_base);
+ pr_err("%pOF: Invalid %s translation - %s (0x%x) ignores id-base (0x%x)\n",
+ np, map_name, map_mask_name, map_mask, id_base);
return -EFAULT;
}
- if (masked_id < id_base || masked_id >= id_base + id_len)
- continue;
-
+ phandle = be32_to_cpup(map + offset + 1);
phandle_node = of_find_node_by_phandle(phandle);
if (!phandle_node)
return -ENODEV;
+ if (!bad_map && of_property_read_u32(phandle_node, cells_name, &cells)) {
+ pr_err("%pOF: missing %s property\n", phandle_node, cells_name);
+ of_node_put(phandle_node);
+ return -EINVAL;
+ }
+
+ if (map_len - offset < 3 + cells) {
+ of_node_put(phandle_node);
+ goto err_map_len;
+ }
+
+ if (offset == 0 && cells == 2) {
+ bad_map = of_check_bad_map(map, map_len);
+ if (bad_map) {
+ pr_warn_once("%pOF: %s mismatches target %s, assuming extra cell of 0\n",
+ np, map_name, cells_name);
+ cells = 1;
+ }
+ }
+
+ out_base = map + offset + 2;
+ offset += 3 + cells;
+
+ id_len = be32_to_cpup(map + offset - 1);
+ if (id_len > 1 && cells > 1) {
+ /*
+ * With 1 output cell we reasonably assume its value
+ * has a linear relationship to the input; with more,
+ * we'd need help from the provider to know what to do.
+ */
+ pr_err("%pOF: Unsupported %s - cannot handle %d-ID range with %d-cell output specifier\n",
+ np, map_name, id_len, cells);
+ of_node_put(phandle_node);
+ return -EINVAL;
+ }
+ id_off = masked_id - id_base;
+ if (masked_id < id_base || id_off >= id_len) {
+ of_node_put(phandle_node);
+ continue;
+ }
+
if (filter_np && filter_np != phandle_node) {
of_node_put(phandle_node);
continue;
}
arg->np = phandle_node;
- arg->args[0] = masked_id - id_base + out_base;
- arg->args_count = 1;
+ for (int i = 0; i < cells; i++)
+ arg->args[i] = id_off + be32_to_cpu(out_base[i]);
+ arg->args_count = cells;
pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
- np, map_name, map_mask, id_base, out_base,
- id_len, id, masked_id - id_base + out_base);
+ np, map_name, map_mask, id_base, be32_to_cpup(out_base),
+ id_len, id, id_off + be32_to_cpup(out_base));
return 0;
}
@@ -2196,6 +2269,10 @@ int of_map_id(const struct device_node *np, u32 id,
arg->args[0] = id;
arg->args_count = 1;
return 0;
+
+err_map_len:
+ pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
+ return -EINVAL;
}
EXPORT_SYMBOL_GPL(of_map_id);
@@ -2205,18 +2282,21 @@ EXPORT_SYMBOL_GPL(of_map_id);
* @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
* stream/device ID) used as the lookup key in the iommu-map table.
* @arg: pointer to a &struct of_phandle_args for the result. On success,
- * @arg->args[0] contains the translated ID. If a map entry was matched,
- * @arg->np holds a reference to the target node that the caller must
- * release with of_node_put().
+ * @arg->args_count will be set to the number of output specifier cells
+ * and @arg->args[0..args_count-1] will contain the translated output
+ * specifier values. If a map entry was matched, @arg->np holds a
+ * reference to the target node that the caller must release with
+ * of_node_put().
*
- * Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask".
+ * Convenience wrapper around of_map_id() using "iommu-map", "#iommu-cells",
+ * and "iommu-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_iommu_id(const struct device_node *np, u32 id,
struct of_phandle_args *arg)
{
- return of_map_id(np, id, "iommu-map", "iommu-map-mask", NULL, arg);
+ return of_map_id(np, id, "iommu-map", "#iommu-cells", "iommu-map-mask", NULL, arg);
}
EXPORT_SYMBOL_GPL(of_map_iommu_id);
@@ -2229,17 +2309,20 @@ EXPORT_SYMBOL_GPL(of_map_iommu_id);
* to match any. If non-NULL, only map entries targeting this node will
* be matched.
* @arg: pointer to a &struct of_phandle_args for the result. On success,
- * @arg->args[0] contains the translated ID. If a map entry was matched,
- * @arg->np holds a reference to the target node that the caller must
- * release with of_node_put().
+ * @arg->args_count will be set to the number of output specifier cells
+ * and @arg->args[0..args_count-1] will contain the translated output
+ * specifier values. If a map entry was matched, @arg->np holds a
+ * reference to the target node that the caller must release with
+ * of_node_put().
*
- * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask".
+ * Convenience wrapper around of_map_id() using "msi-map", "#msi-cells",
+ * and "msi-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_msi_id(const struct device_node *np, u32 id,
const struct device_node *filter_np, struct of_phandle_args *arg)
{
- return of_map_id(np, id, "msi-map", "msi-map-mask", filter_np, arg);
+ return of_map_id(np, id, "msi-map", "#msi-cells", "msi-map-mask", filter_np, arg);
}
EXPORT_SYMBOL_GPL(of_map_msi_id);
diff --git a/include/linux/of.h b/include/linux/of.h
index 8548cd9eb4f1..51ac8539f2c3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -462,7 +462,8 @@ const char *of_prop_next_string(const struct property *prop, const char *cur);
bool of_console_check(const struct device_node *dn, char *name, int index);
int of_map_id(const struct device_node *np, u32 id,
- const char *map_name, const char *map_mask_name,
+ const char *map_name, const char *cells_name,
+ const char *map_mask_name,
const struct device_node *filter_np, struct of_phandle_args *arg);
int of_map_iommu_id(const struct device_node *np, u32 id,
@@ -934,7 +935,8 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag
}
static inline int of_map_id(const struct device_node *np, u32 id,
- const char *map_name, const char *map_mask_name,
+ const char *map_name, const char *cells_name,
+ const char *map_mask_name,
const struct device_node *filter_np,
struct of_phandle_args *arg)
{
--
2.34.1
^ permalink raw reply related
* [PATCH v12 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta, Charan Teja Kalla
In-Reply-To: <20260331-parse_iommu_cells-v12-0-decfd305eea9@oss.qualcomm.com>
From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Change of_map_id() to take a pointer to struct of_phandle_args
instead of passing target device node and translated IDs separately.
Update all callers accordingly.
Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
to separate the filter input from the output. Previously, the target
parameter served dual purpose: as an input filter (if non-NULL, only
match entries targeting that node) and as an output (receiving the
matched node with a reference held). Now filter_np is the explicit
input filter and arg->np is the pure output.
Previously, of_map_id() would call of_node_put() on the matched node
when a filter was provided, making reference ownership inconsistent.
Remove this internal of_node_put() call so that of_map_id() now always
transfers ownership of the matched node reference to the caller via
arg->np. Callers are now consistently responsible for releasing this
reference with of_node_put(arg->np) when done.
Suggested-by: Rob Herring (Arm) <robh@kernel.org>
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
drivers/cdx/cdx_msi.c | 7 ++--
drivers/iommu/of_iommu.c | 4 +-
drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++--
drivers/of/base.c | 68 +++++++++++++++++---------------
drivers/of/irq.c | 10 ++++-
drivers/pci/controller/dwc/pci-imx6.c | 32 +++++++--------
drivers/pci/controller/pcie-apple.c | 5 ++-
drivers/xen/grant-dma-ops.c | 4 +-
include/linux/of.h | 14 ++++---
9 files changed, 89 insertions(+), 66 deletions(-)
diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c
index 63b3544ec997..6924e07c7528 100644
--- a/drivers/cdx/cdx_msi.c
+++ b/drivers/cdx/cdx_msi.c
@@ -121,22 +121,23 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain,
struct device *dev,
int nvec, msi_alloc_info_t *info)
{
+ struct of_phandle_args msi_spec = {};
struct cdx_device *cdx_dev = to_cdx_device(dev);
struct device *parent = cdx_dev->cdx->dev;
struct msi_domain_info *msi_info;
- u32 dev_id;
int ret;
/* Retrieve device ID from requestor ID using parent device */
- ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id);
+ ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &msi_spec);
if (ret) {
dev_err(dev, "of_map_id failed for MSI: %d\n", ret);
return ret;
}
+ of_node_put(msi_spec.np);
#ifdef GENERIC_MSI_DOMAIN_OPS
/* Set the device Id to be passed to the GIC-ITS */
- info->scratchpad[0].ul = dev_id;
+ info->scratchpad[0].ul = msi_spec.args[0];
#endif
msi_info = msi_get_domain_info(msi_domain->parent);
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index a511ecf21fcd..a18bb60f6f3d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -45,10 +45,10 @@ static int of_iommu_configure_dev_id(struct device_node *master_np,
struct device *dev,
const u32 *id)
{
- struct of_phandle_args iommu_spec = { .args_count = 1 };
+ struct of_phandle_args iommu_spec = {};
int err;
- err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args);
+ err = of_map_iommu_id(master_np, *id, &iommu_spec);
if (err)
return err;
diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c
index b63343a227a9..dd5f84b6470a 100644
--- a/drivers/irqchip/irq-gic-its-msi-parent.c
+++ b/drivers/irqchip/irq-gic-its-msi-parent.c
@@ -152,6 +152,8 @@ static int its_v5_pci_msi_prepare(struct irq_domain *domain, struct device *dev,
static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u32 *dev_id,
phys_addr_t *pa)
{
+ struct device_node *msi_ctrl __free(device_node) = NULL;
+ struct of_phandle_args msi_spec = {};
struct of_phandle_iterator it;
int ret;
@@ -178,9 +180,12 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u
}
}
- struct device_node *msi_ctrl __free(device_node) = NULL;
-
- return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id);
+ ret = of_map_msi_id(dev->of_node, dev->id, NULL, &msi_spec);
+ if (!ret) {
+ msi_ctrl = msi_spec.np;
+ *dev_id = msi_spec.args[0];
+ }
+ return ret;
}
static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ae04487bd614..b3d002015192 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2102,36 +2102,37 @@ int of_find_last_cache_level(unsigned int cpu)
* @id: device ID to map.
* @map_name: property name of the map to use.
* @map_mask_name: optional property name of the mask to use.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
+ * @filter_np: optional device node to filter matches by, or NULL to match any.
+ * If non-NULL, only map entries targeting this node will be matched.
+ * @arg: pointer to a &struct of_phandle_args for the result. On success,
+ * @arg->args[0] will contain the translated ID. If a map entry was
+ * matched, @arg->np will be set to the target node with a reference
+ * held that the caller must release with of_node_put().
*
* Given a device ID, look up the appropriate implementation-defined
* platform ID and/or the target device which receives transactions on that
- * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
- * @id_out may be NULL if only the other is required. If @target points to
- * a non-NULL device node pointer, only entries targeting that node will be
- * matched; if it points to a NULL value, it will receive the device node of
- * the first matching target phandle, with a reference held.
+ * ID, as per the "iommu-map" and "msi-map" bindings.
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np, struct of_phandle_args *arg)
{
u32 map_mask, masked_id;
int map_len;
const __be32 *map = NULL;
- if (!np || !map_name || (!target && !id_out))
+ if (!np || !map_name || !arg)
return -EINVAL;
map = of_get_property(np, map_name, &map_len);
if (!map) {
- if (target)
+ if (filter_np)
return -ENODEV;
/* Otherwise, no map implies no translation */
- *id_out = id;
+ arg->args[0] = id;
+ arg->args_count = 1;
return 0;
}
@@ -2173,18 +2174,14 @@ int of_map_id(const struct device_node *np, u32 id,
if (!phandle_node)
return -ENODEV;
- if (target) {
- if (*target)
- of_node_put(phandle_node);
- else
- *target = phandle_node;
-
- if (*target != phandle_node)
- continue;
+ if (filter_np && filter_np != phandle_node) {
+ of_node_put(phandle_node);
+ continue;
}
- if (id_out)
- *id_out = masked_id - id_base + out_base;
+ arg->np = phandle_node;
+ arg->args[0] = masked_id - id_base + out_base;
+ arg->args_count = 1;
pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
np, map_name, map_mask, id_base, out_base,
@@ -2193,11 +2190,11 @@ int of_map_id(const struct device_node *np, u32 id,
}
pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
- id, target && *target ? *target : NULL);
+ id, filter_np);
/* Bypasses translation */
- if (id_out)
- *id_out = id;
+ arg->args[0] = id;
+ arg->args_count = 1;
return 0;
}
EXPORT_SYMBOL_GPL(of_map_id);
@@ -2207,17 +2204,19 @@ EXPORT_SYMBOL_GPL(of_map_id);
* @np: root complex device node.
* @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
* stream/device ID) used as the lookup key in the iommu-map table.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
+ * @arg: pointer to a &struct of_phandle_args for the result. On success,
+ * @arg->args[0] contains the translated ID. If a map entry was matched,
+ * @arg->np holds a reference to the target node that the caller must
+ * release with of_node_put().
*
* Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_iommu_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ struct of_phandle_args *arg)
{
- return of_map_id(np, id, "iommu-map", "iommu-map-mask", target, id_out);
+ return of_map_id(np, id, "iommu-map", "iommu-map-mask", NULL, arg);
}
EXPORT_SYMBOL_GPL(of_map_iommu_id);
@@ -2226,16 +2225,21 @@ EXPORT_SYMBOL_GPL(of_map_iommu_id);
* @np: root complex device node.
* @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
* stream/device ID) used as the lookup key in the msi-map table.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
+ * @filter_np: optional MSI controller node to filter matches by, or NULL
+ * to match any. If non-NULL, only map entries targeting this node will
+ * be matched.
+ * @arg: pointer to a &struct of_phandle_args for the result. On success,
+ * @arg->args[0] contains the translated ID. If a map entry was matched,
+ * @arg->np holds a reference to the target node that the caller must
+ * release with of_node_put().
*
* Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_msi_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np, struct of_phandle_args *arg)
{
- return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out);
+ return of_map_id(np, id, "msi-map", "msi-map-mask", filter_np, arg);
}
EXPORT_SYMBOL_GPL(of_map_msi_id);
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index e37c1b3f8736..f86a56bd81fc 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -817,8 +817,16 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in)
* "msi-map" or an "msi-parent" property.
*/
for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
- if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out))
+ struct of_phandle_args msi_spec = {};
+
+ if (!of_map_msi_id(parent_dev->of_node, id_in, *msi_np, &msi_spec)) {
+ id_out = msi_spec.args[0];
+ if (!*msi_np)
+ *msi_np = msi_spec.np;
+ else
+ of_node_put(msi_spec.np);
break;
+ }
if (!of_check_msi_parent(parent_dev->of_node, msi_np))
break;
}
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index bff8289f804a..c0544d9c0921 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1137,30 +1137,32 @@ static void imx_pcie_remove_lut(struct imx_pcie *imx_pcie, u16 rid)
static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
{
+ struct of_phandle_args iommu_spec = {};
+ struct of_phandle_args msi_spec = {};
struct device *dev = imx_pcie->pci->dev;
- struct device_node *target;
u32 sid_i, sid_m;
int err_i, err_m;
u32 sid = 0;
- target = NULL;
- err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i);
- if (target) {
- of_node_put(target);
- } else {
+ err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec);
+ if (!err_i)
+ sid_i = iommu_spec.args[0];
+ of_node_put(iommu_spec.np);
+ if (!err_i && !iommu_spec.np) {
/*
- * "target == NULL && err_i == 0" means RID out of map range.
- * Use 1:1 map RID to streamID. Hardware can't support this
- * because the streamID is only 6 bits
+ * "iommu_spec.np == NULL && err_i == 0" means RID out of map
+ * range. Use 1:1 map RID to streamID. Hardware can't support
+ * this because the streamID is only 6 bits.
*/
err_i = -EINVAL;
}
- target = NULL;
- err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m);
-
+ err_m = of_map_msi_id(dev->of_node, rid, NULL, &msi_spec);
+ if (!err_m)
+ sid_m = msi_spec.args[0];
+ of_node_put(msi_spec.np);
/*
- * err_m target
+ * err_m msi_spec.np
* 0 NULL RID out of range. Use 1:1 map RID to
* streamID, Current hardware can't
* support it, so return -EINVAL.
@@ -1168,10 +1170,8 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
* 0 != NULL Get correct streamID from RID
* != 0 != NULL Invalid combination
*/
- if (!err_m && !target)
+ if (!err_m && !msi_spec.np)
return -EINVAL;
- else if (target)
- of_node_put(target); /* Find streamID map entry for RID in msi-map */
/*
* msi-map iommu-map
diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
index a0937b7b3c4d..c2cffc0659f4 100644
--- a/drivers/pci/controller/pcie-apple.c
+++ b/drivers/pci/controller/pcie-apple.c
@@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
{
u32 sid, rid = pci_dev_id(pdev);
struct apple_pcie_port *port;
+ struct of_phandle_args iommu_spec = {};
int idx, err;
port = apple_pcie_get_port(pdev);
@@ -764,10 +765,12 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
dev_dbg(&pdev->dev, "added to bus %s, index %d\n",
pci_name(pdev->bus->self), port->idx);
- err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid);
+ err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec);
if (err)
return err;
+ of_node_put(iommu_spec.np);
+ sid = iommu_spec.args[0];
mutex_lock(&port->pcie->lock);
idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0);
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 1b7696b2d762..2aa1a772a0ff 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -319,13 +319,13 @@ static int xen_dt_grant_init_backend_domid(struct device *dev,
struct device_node *np,
domid_t *backend_domid)
{
- struct of_phandle_args iommu_spec = { .args_count = 1 };
+ struct of_phandle_args iommu_spec = {};
if (dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(dev);
u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
- if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) {
+ if (of_map_iommu_id(np, rid, &iommu_spec)) {
dev_dbg(dev, "Cannot translate ID\n");
return -ESRCH;
}
diff --git a/include/linux/of.h b/include/linux/of.h
index fe841f3cc747..8548cd9eb4f1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -463,13 +463,13 @@ bool of_console_check(const struct device_node *dn, char *name, int index);
int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out);
+ const struct device_node *filter_np, struct of_phandle_args *arg);
int of_map_iommu_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out);
+ struct of_phandle_args *arg);
int of_map_msi_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out);
+ const struct device_node *filter_np, struct of_phandle_args *arg);
phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
@@ -935,19 +935,21 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag
static inline int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np,
+ struct of_phandle_args *arg)
{
return -EINVAL;
}
static inline int of_map_iommu_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ struct of_phandle_args *arg)
{
return -EINVAL;
}
static inline int of_map_msi_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np,
+ struct of_phandle_args *arg)
{
return -EINVAL;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v12 1/3] of: Add convenience wrappers for of_map_id()
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta
In-Reply-To: <20260331-parse_iommu_cells-v12-0-decfd305eea9@oss.qualcomm.com>
From: Robin Murphy <robin.murphy@arm.com>
Since we now have quite a few users parsing "iommu-map" and "msi-map"
properties, give them some wrappers to conveniently encapsulate the
appropriate sets of property names. This will also make it easier to
then change of_map_id() to correctly account for specifier cells.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
drivers/cdx/cdx_msi.c | 3 +--
drivers/iommu/of_iommu.c | 4 +---
drivers/irqchip/irq-gic-its-msi-parent.c | 2 +-
drivers/of/base.c | 38 ++++++++++++++++++++++++++++++++
drivers/of/irq.c | 3 +--
drivers/pci/controller/dwc/pci-imx6.c | 6 ++---
drivers/pci/controller/pcie-apple.c | 3 +--
drivers/xen/grant-dma-ops.c | 3 +--
include/linux/of.h | 18 +++++++++++++++
9 files changed, 64 insertions(+), 16 deletions(-)
diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c
index 91b95422b263..63b3544ec997 100644
--- a/drivers/cdx/cdx_msi.c
+++ b/drivers/cdx/cdx_msi.c
@@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain,
int ret;
/* Retrieve device ID from requestor ID using parent device */
- ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask",
- NULL, &dev_id);
+ ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id);
if (ret) {
dev_err(dev, "of_map_id failed for MSI: %d\n", ret);
return ret;
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 6b989a62def2..a511ecf21fcd 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np,
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
- err = of_map_id(master_np, *id, "iommu-map",
- "iommu-map-mask", &iommu_spec.np,
- iommu_spec.args);
+ err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args);
if (err)
return err;
diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c
index d36b278ae66c..b63343a227a9 100644
--- a/drivers/irqchip/irq-gic-its-msi-parent.c
+++ b/drivers/irqchip/irq-gic-its-msi-parent.c
@@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u
struct device_node *msi_ctrl __free(device_node) = NULL;
- return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id);
+ return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id);
}
static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 57420806c1a2..ae04487bd614 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2201,3 +2201,41 @@ int of_map_id(const struct device_node *np, u32 id,
return 0;
}
EXPORT_SYMBOL_GPL(of_map_id);
+
+/**
+ * of_map_iommu_id - Translate an ID using "iommu-map" bindings.
+ * @np: root complex device node.
+ * @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
+ * stream/device ID) used as the lookup key in the iommu-map table.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask".
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_iommu_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return of_map_id(np, id, "iommu-map", "iommu-map-mask", target, id_out);
+}
+EXPORT_SYMBOL_GPL(of_map_iommu_id);
+
+/**
+ * of_map_msi_id - Translate an ID using "msi-map" bindings.
+ * @np: root complex device node.
+ * @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
+ * stream/device ID) used as the lookup key in the msi-map table.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask".
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_msi_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out);
+}
+EXPORT_SYMBOL_GPL(of_map_msi_id);
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 6367c67732d2..e37c1b3f8736 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in)
* "msi-map" or an "msi-parent" property.
*/
for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
- if (!of_map_id(parent_dev->of_node, id_in, "msi-map",
- "msi-map-mask", msi_np, &id_out))
+ if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out))
break;
if (!of_check_msi_parent(parent_dev->of_node, msi_np))
break;
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index a5b8d0b71677..bff8289f804a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
u32 sid = 0;
target = NULL;
- err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask",
- &target, &sid_i);
+ err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i);
if (target) {
of_node_put(target);
} else {
@@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
}
target = NULL;
- err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask",
- &target, &sid_m);
+ err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m);
/*
* err_m target
diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
index 2d92fc79f6dd..a0937b7b3c4d 100644
--- a/drivers/pci/controller/pcie-apple.c
+++ b/drivers/pci/controller/pcie-apple.c
@@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
dev_dbg(&pdev->dev, "added to bus %s, index %d\n",
pci_name(pdev->bus->self), port->idx);
- err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map",
- "iommu-map-mask", NULL, &sid);
+ err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid);
if (err)
return err;
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index c2603e700178..1b7696b2d762 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev,
struct pci_dev *pdev = to_pci_dev(dev);
u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
- if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np,
- iommu_spec.args)) {
+ if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) {
dev_dbg(dev, "Cannot translate ID\n");
return -ESRCH;
}
diff --git a/include/linux/of.h b/include/linux/of.h
index be6ec4916adf..fe841f3cc747 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -465,6 +465,12 @@ int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
struct device_node **target, u32 *id_out);
+int of_map_iommu_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out);
+
+int of_map_msi_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out);
+
phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
struct kimage;
@@ -934,6 +940,18 @@ static inline int of_map_id(const struct device_node *np, u32 id,
return -EINVAL;
}
+static inline int of_map_iommu_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return -EINVAL;
+}
+
+static inline int of_map_msi_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return -EINVAL;
+}
+
static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
{
return PHYS_ADDR_MAX;
--
2.34.1
^ permalink raw reply related
* [PATCH v12 0/3] of: parsing of multi #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta, Charan Teja Kalla
So far our parsing of {iommu,msi}-map properties has always blindly
assumed that the output specifiers will always have exactly 1 cell.
This typically does happen to be the case, but is not actually enforced
(and the PCI msi-map binding even explicitly states support for 0 or 1
cells) - as a result we've now ended up with dodgy DTs out in the field
which depend on this behaviour to map a 1-cell specifier for a 2-cell
provider, despite that being bogus per the bindings themselves.
Since there is some potential use[1] in being able to map at least
single input IDs to multi-cell output specifiers (and properly support
0-cell outputs as well), add support for properly parsing and using the
target nodes' #cells values, albeit with the unfortunate complication of
still having to work around expectations of the old behaviour too.
-- Robin.
Unlike single #{}-cell, it is complex to establish a linear relation
between input 'id' and output specifier for multi-cell properties, thus
it is always expected that len never going to be > 1.
These changes have been tested on QEMU for the arm64 architecture.
Since, this would also need update in dt-schema, raised PR[2] for the
same.
[1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
[2] PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
Robin,
Could this series be pulled into an immutable branch/tag, if it doesn't make
it into the v7.1 merge window? There are client changes dependent on it,
So it would help to get them moving forward rather than waiting another
cycle.
Thanks,
Vijay
V12:
- Call of_node_put() unconditionally in imx_pcie_add_lut_by_rid()
thereby addressing comments from Bjorn Helgaas.
Link to v11:
https://lore.kernel.org/r/20260325-parse_iommu_cells-v11-0-1fefa5c0e82c@oss.qualcomm.com
V11:
- Added explicit filter_np parameter to of_map_id() and of_map_msi_id()
per Dmitry Baryshkov's review feedback, making the filter explicit
instead of overloading arg->np as both input filter and output parameter.
- Removed of_node_put() from inside of_map_id(), making the caller responsible
for reference management. Updated of_msi_xlate() to properly handle reference counting.
- Collected ACKed by tags, and fixed minor typos.
Link to v10:
https://lore.kernel.org/r/20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com
V10:
- Move of_map_iommu_id()/of_map_msi_id() from include/linux/of.h to
drivers/of/base.c as out-of-line helpers per feedback from Marc Zyngier
and Rob Herring.
- Add kernel-doc to document both helpers for discoverability and
usage clarity.
- Fix of_map_msi_id() wrapper and all its callers (cdx_msi.c,
irq-gic-its-msi-parent.c, drivers/of/irq.c) to correctly use the new
struct of_phandle_args-based API with proper of_node_put() handling
as per feeback from Dmitry.
Link to v9:
https://lore.kernel.org/r/20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com
V9:
- Updated TO/CC list based on feedback to include all relevant
maintainers.
- No functional changes to the patches themselves.
Link to V8:
https://lore.kernel.org/all/20260226074245.3098486-1-vijayanand.jitta@oss.qualcomm.com/
V8:
- Removed mentions of of_map_args from commit message to match code.
Link to V7:
https://lore.kernel.org/all/20260210101157.2145113-1-vijayanand.jitta@oss.qualcomm.com/
V7:
- Removed of_map_id_args structure and replaced it with
of_phandle_args as suggested by Dmitry.
Link to V6:
https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
V6:
- Fixed build error reported by kernel test bot.
Link to V5:
https://lore.kernel.org/all/20260118181125.1436036-1-vijayanand.jitta@oss.qualcomm.com/
V5:
- Fixed Build Warnings.
- Raised PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
Link to V4:
https://lore.kernel.org/all/20251231114257.2382820-1-vijayanand.jitta@oss.qualcomm.com/
V4:
- Added Reviewed-by tag.
- Resolved warnings reported by kernel test bot, minor code
reorganization.
Link to V3:
https://lore.kernel.org/all/20251221213602.2413124-1-vijayanand.jitta@oss.qualcomm.com/
V3:
- Added Reviewed-by tag.
- Updated of_map_id_args struct as a wrapper to of_phandle_args and
added comment description as suggested by Rob Herring.
Link to V2:
https://lore.kernel.org/all/20251204095530.8627-1-vijayanand.jitta@oss.qualcomm.com/
V2:
- Incorporated the patches from Robin that does the clean implementation.
- Dropped the patches the were adding multi-map support from this series
as suggested.
V1:
https://lore.kernel.org/all/cover.1762235099.git.charan.kalla@oss.qualcomm.com/
RFC:
https://lore.kernel.org/all/20250928171718.436440-1-charan.kalla@oss.qualcomm.com/#r
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
Charan Teja Kalla (1):
of: Factor arguments passed to of_map_id() into a struct
Robin Murphy (2):
of: Add convenience wrappers for of_map_id()
of: Respect #{iommu,msi}-cells in maps
drivers/cdx/cdx_msi.c | 8 +-
drivers/iommu/of_iommu.c | 6 +-
drivers/irqchip/irq-gic-its-msi-parent.c | 11 +-
drivers/of/base.c | 213 ++++++++++++++++++++++++-------
drivers/of/irq.c | 11 +-
drivers/pci/controller/dwc/pci-imx6.c | 34 +++--
drivers/pci/controller/pcie-apple.c | 6 +-
drivers/xen/grant-dma-ops.c | 5 +-
include/linux/of.h | 30 ++++-
9 files changed, 240 insertions(+), 84 deletions(-)
---
base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
change-id: 20260301-parse_iommu_cells-1c33768aebba
Best regards,
--
Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
^ permalink raw reply
* [PATCH RFC 2/2] arm64: dts: qcom: eliza-mtp: Enable DSI display panel
From: Krzysztof Kozlowski @ 2026-03-31 14:02 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa,
Krzysztof Kozlowski
In-Reply-To: <20260331-dts-qcom-eliza-display-v1-0-856f0b66b282@oss.qualcomm.com>
Enable display on Eliza MTP board with Visionox VTDR6130 panel.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza-mtp.dts | 63 ++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza-mtp.dts b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
index c31f00e36eee..df0cfffcef61 100644
--- a/arch/arm64/boot/dts/qcom/eliza-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
@@ -417,6 +417,48 @@ vreg_l7k: ldo7 {
};
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&vreg_l4b>;
+
+ status = "okay";
+
+ panel@0 {
+ compatible = "visionox,vtdr6130";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 12 GPIO_ACTIVE_LOW>;
+
+ vci-supply = <&vreg_l19b>;
+ vdd-supply = <&vreg_l1g>;
+ vddio-supply = <&vreg_l8b>;
+
+ pinctrl-0 = <&disp0_reset_n_active>, <&mdp_vsync>;
+ pinctrl-1 = <&disp0_reset_n_suspend>, <&mdp_vsync>;
+ pinctrl-names = "default", "sleep";
+
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+};
+
+&mdss_dsi0_out {
+ remote-endpoint = <&panel0_in>;
+ data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+ vdds-supply = <&vreg_l2b>;
+
+ status = "okay";
+};
+
&pm7550ba_eusb2_repeater {
vdd18-supply = <&vreg_l7b>;
vdd3-supply = <&vreg_l17b>;
@@ -433,6 +475,27 @@ &tlmm {
gpio-reserved-ranges = <20 4>, /* NFC SPI */
<111 2>, /* WCN UART1 */
<118 1>; /* NFC Secure I/O */
+
+ disp0_reset_n_active: disp0-reset-n-active-state {
+ pins = "gpio12";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ disp0_reset_n_suspend: disp0-reset-n-suspend-state {
+ pins = "gpio12";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ mdp_vsync: mdp-vsync-state {
+ pins = "gpio17";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
};
&uart14 {
--
2.51.0
^ permalink raw reply related
* [PATCH RFC 1/2] arm64: dts: qcom: eliza: Add display (MDSS) with Display CC
From: Krzysztof Kozlowski @ 2026-03-31 14:02 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa,
Krzysztof Kozlowski
In-Reply-To: <20260331-dts-qcom-eliza-display-v1-0-856f0b66b282@oss.qualcomm.com>
Add device nodes for almost entire display: MDSS, DPU, DSI, DSI PHYs,
DisplayPort and Display Clock Controller.
Missing pieces are HDMI PHY and HDMI controller.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Lack of hardware for HDMI testing, but the work on drivers is in
progress.
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 433 ++++++++++++++++++++++++++++++++++++
1 file changed, 433 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 37baa4b240d6..e9b522b88690 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -3,6 +3,8 @@
* Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
+#include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
+#include <dt-bindings/clock/qcom,eliza-dispcc.h>
#include <dt-bindings/clock/qcom,eliza-gcc.h>
#include <dt-bindings/clock/qcom,eliza-tcsr.h>
#include <dt-bindings/clock/qcom,rpmh.h>
@@ -1035,6 +1037,7 @@ port@2 {
reg = <2>;
usb_dp_qmpphy_dp_in: endpoint {
+ remote-endpoint = <&mdss_dp0_out>;
};
};
};
@@ -1131,6 +1134,436 @@ usb_dwc3_ss: endpoint {
};
};
+ mdss: display-subsystem@ae00000 {
+ compatible = "qcom,eliza-mdss";
+ reg = <0x0 0x0ae00000 0x0 0x1000>;
+ reg-names = "mdss";
+ ranges;
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+
+ resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+ interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "mdp0-mem",
+ "cpu-cfg";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ iommus = <&apps_smmu 0x800 0x2>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ status = "disabled";
+
+ mdss_mdp: display-controller@ae01000 {
+ compatible = "qcom,eliza-dpu";
+ reg = <0x0 0x0ae01000 0x0 0x93000>,
+ <0x0 0x0aeb0000 0x0 0x2008>;
+ reg-names = "mdp",
+ "vbif";
+
+ interrupts-extended = <&mdss 0>;
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&mdss_dsi1_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&mdss_dp0_in>;
+ };
+ };
+ /* TODO: HDMI */
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-150000000 {
+ opp-hz = /bits/ 64 <150000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-207000000 {
+ opp-hz = /bits/ 64 <207000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-342000000 {
+ opp-hz = /bits/ 64 <342000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-417000000 {
+ opp-hz = /bits/ 64 <417000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-532000000 {
+ opp-hz = /bits/ 64 <532000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ required-opps = <&rpmhpd_opp_nom_l1>;
+ };
+
+ opp-660000000 {
+ opp-hz = /bits/ 64 <660000000>;
+ required-opps = <&rpmhpd_opp_turbo>;
+ };
+ };
+ };
+
+ mdss_dsi0: dsi@ae94000 {
+ compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0 0x0ae94000 0x0 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupts-extended = <&mdss 4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>,
+ <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
+ <&dispcc DISP_CC_ESYNC0_CLK>,
+ <&dispcc DISP_CC_OSC_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus",
+ "dsi_pll_pixel",
+ "dsi_pll_byte",
+ "esync",
+ "osc",
+ "byte_src",
+ "pixel_src";
+
+ operating-points-v2 = <&mdss_dsi_opp_table>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+
+ mdss_dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-140630000 {
+ opp-hz = /bits/ 64 <140630000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@ae95000 {
+ compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm";
+ reg = <0x0 0x0ae95000 0x0 0x200>,
+ <0x0 0x0ae95200 0x0 0x280>,
+ <0x0 0x0ae95500 0x0 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&bi_tcxo_div2>;
+ clock-names = "iface",
+ "ref";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ mdss_dsi1: dsi@ae96000 {
+ compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0 0x0ae96000 0x0 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupts-extended = <&mdss 5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&mdss_dsi1_phy DSI_PIXEL_PLL_CLK>,
+ <&mdss_dsi1_phy DSI_BYTE_PLL_CLK>,
+ <&dispcc DISP_CC_ESYNC1_CLK>,
+ <&dispcc DISP_CC_OSC_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus",
+ "dsi_pll_pixel",
+ "dsi_pll_byte",
+ "esync",
+ "osc",
+ "byte_src",
+ "pixel_src";
+
+ operating-points-v2 = <&mdss_dsi_opp_table>;
+
+ phys = <&mdss_dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi1_phy: phy@ae97000 {
+ compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm";
+ reg = <0x0 0x0ae97000 0x0 0x200>,
+ <0x0 0x0ae97200 0x0 0x280>,
+ <0x0 0x0ae97500 0x0 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface",
+ "ref";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ mdss_dp0: displayport-controller@af54000 {
+ compatible = "qcom,eliza-dp", "qcom,sm8650-dp";
+ reg = <0x0 0xaf54000 0x0 0x104>,
+ <0x0 0xaf54200 0x0 0xc0>,
+ <0x0 0xaf55000 0x0 0x770>,
+ <0x0 0xaf56000 0x0 0x9c>,
+ <0x0 0xaf57000 0x0 0x9c>;
+
+ interrupts-extended = <&mdss 12>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_AUX_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_PIXEL1_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_DPTX0_PIXEL1_CLK_SRC>;
+ assigned-clock-parents = <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ operating-points-v2 = <&dp_opp_table>;
+
+ phys = <&usb_dp_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ status = "disabled";
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp0_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp0_out: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+ };
+ };
+ };
+ };
+ };
+
+ dispcc: clock-controller@af00000 {
+ compatible = "qcom,eliza-dispcc";
+ reg = <0x0 0x0af00000 0x0 0x20000>;
+
+ clocks = <&bi_tcxo_div2>,
+ <&bi_tcxo_ao_div2>,
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&sleep_clk>,
+ <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
+ <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>,
+ <&mdss_dsi1_phy DSI_BYTE_PLL_CLK>,
+ <&mdss_dsi1_phy DSI_PIXEL_PLL_CLK>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
+ <0>, /* dp1 */
+ <0>,
+ <0>, /* dp2 */
+ <0>,
+ <0>, /* dp3 */
+ <0>,
+ <0>; /* HDMI phy */
+
+ power-domains = <&rpmhpd RPMHPD_MX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
pdc: interrupt-controller@b220000 {
compatible = "qcom,eliza-pdc", "qcom,pdc";
reg = <0x0 0x0b220000 0x0 0x40000>,
--
2.51.0
^ permalink raw reply related
* [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display
From: Krzysztof Kozlowski @ 2026-03-31 14:02 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa,
Krzysztof Kozlowski
Dependency
==========
Depends on USB patches, which are being reviewed, therefore marking it
as RFC as it cannot be applied.
https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
Unmerged bindings used here
===========================
dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
(DRM MDSS bindings were applied)
Description
===========
I did not enable DisplayPort because it does not work on my board and I
don't know why. I double checked QMP combo phy and other bits, and
everything is looking fine, but still no USB display, so maybe I miss
some other dependencies as this is early upstream.
DSI panel works fine.
HDMI is not yet ready, because of lack of hardware with HDMI.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (2):
arm64: dts: qcom: eliza: Add display (MDSS) with Display CC
arm64: dts: qcom: eliza-mtp: Enable DSI display panel
arch/arm64/boot/dts/qcom/eliza-mtp.dts | 63 +++++
arch/arm64/boot/dts/qcom/eliza.dtsi | 433 +++++++++++++++++++++++++++++++++
2 files changed, 496 insertions(+)
---
base-commit: 1f68839a688f612e0dc183559adf9161f15db297
change-id: 20260327-dts-qcom-eliza-display-64de3cfc8a50
prerequisite-change-id: 20260330-eliza-adsp-usb-8ef2b1b0fc13:v1
prerequisite-patch-id: e0744310fa58e080587218e62aa6686ed841689f
prerequisite-patch-id: 1b4e40eb33adf28c8b6105f25f6636f82239a962
prerequisite-patch-id: 4671af784a83f9ce69cc2c502912698476ee7719
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: glymur: Add qfprom efuse node
From: Pankaj Patil @ 2026-03-31 13:54 UTC (permalink / raw)
To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Pankaj Patil
In-Reply-To: <20260331-glymur-qfprom-v1-0-5b4284d23c80@oss.qualcomm.com>
Add the qfprom (Qualcomm Fuse ROM) efuse node and gpu speed bin child
node for Glymur SoC
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f23cf81ddb77..7a72fcf292dc 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5914,6 +5914,18 @@ nsp_noc: interconnect@320c0000 {
#interconnect-cells = <2>;
};
+ qfprom: efuse@361c8000 {
+ compatible = "qcom,glymur-qfprom", "qcom,qfprom";
+ reg = <0x0 0x361c8000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ gpu_speed_bin: gpu-speed-bin@138 {
+ reg = <0x138 0x2>;
+ bits = <0 9>;
+ };
+ };
+
imem: sram@81e08000 {
compatible = "mmio-sram";
reg = <0x0 0x81e08600 0x0 0x300>;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: nvmem: qfprom: Add glymur compatible
From: Pankaj Patil @ 2026-03-31 13:54 UTC (permalink / raw)
To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Pankaj Patil
In-Reply-To: <20260331-glymur-qfprom-v1-0-5b4284d23c80@oss.qualcomm.com>
Document compatible string for the QFPROM on Glymur platform.
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
---
Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index 2ab047f2bb69..aad8f5ea6fff 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -19,6 +19,7 @@ properties:
- enum:
- qcom,apq8064-qfprom
- qcom,apq8084-qfprom
+ - qcom,glymur-qfprom
- qcom,ipq5018-qfprom
- qcom,ipq5332-qfprom
- qcom,ipq5424-qfprom
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: qcom: glymur: Add QFPROM efuse support
From: Pankaj Patil @ 2026-03-31 13:54 UTC (permalink / raw)
To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Pankaj Patil
Add dt-bindings and dt-node for Glymur QFPROM efuse. The GPU speed bin
child node nvmem cell contains details of clk frequencies supported by
the GPU, which is then read by the GPU driver to select the correct set
of operating performance points (OPPs) for the device
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
---
Pankaj Patil (2):
dt-bindings: nvmem: qfprom: Add glymur compatible
arm64: dts: qcom: glymur: Add qfprom efuse node
Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 12 ++++++++++++
2 files changed, 13 insertions(+)
---
base-commit: cf7c3c02fdd0dfccf4d6611714273dcb538af2cb
change-id: 20260311-glymur-qfprom-51c7521e4da0
Best regards,
--
Pankaj Patil <pankaj.patil@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Khristine Andreea Barbulescu @ 2026-03-31 13:43 UTC (permalink / raw)
To: Arnd Bergmann, 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: <e1c341d6-e60d-4200-a094-48667e8ccd5c@app.fastmail.com>
On 3/31/2026 1:11 PM, Arnd Bergmann wrote:
> 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.
>
Hi Arnd,
Our initial intention had been to expose that SoC-information as
discussed in the earlier revisions of this series. However,
taking the review feedback into account, the current direction is
to stop handling those SoC information registers in the Linux driver
altogether and instead rely on a boot firmware to pass that
information forward, as you suggested.
With this approach, the SIUL2 driver would no longer be responsible
for any separate SoC-information functionality. In that case,
I understand your point that a monolithic pinctrl/GPIO/irqchip
driver is a better fit than keeping the MFD structure.
> 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?
>
There is indeed the option of extending the current
nxp,s32g2-siul2-pinctrl.yaml binding and adding the GPIO related
register areas to that existing device node.
> 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
However, as you mentioned, this is still weird because it means
listing individual register areas of the larger device inside.
For this reason, I was wondering whether it would still be
acceptable to move forward with the new binding introduced
in this series, but simplify it so that it describes a single
monolithic SIUL2 pinctrl/GPIO device instead of an MFD,
following the example node I included in my previous reply [1].
[1] https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@oss.nxp.com/T/#m778088251774a15bde7463350d6e75d5e9b9b57d
Best regards,
Khristine
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: x1e80100-dell-xps13-9345: enable onboard accelerometers
From: Aleksandrs Vinarskis @ 2026-03-31 13:36 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: laurentiu.tudor1, linux-arm-msm, devicetree, linux-kernel,
Dmitry Baryshkov
Particular laptop comes with two sets of sensors:
1. Motherboard: accelerometer
2. Display/Camera module: accelerometer, ambient ligth (and more)
sensor
Both i2c busses are bound to Snapdragon Sensor Core (SSC) and are
typically controlled by (A)DSP thus allowing for great power
efficiency. This however requires DSP libraries matching ADSP firmware,
sensors descriptions (must be extracted from Windows) and other
potentially closed-source libraries. Opensource tooling includes
`libssc` and `hexagonrpcd`, but they were not verified to be working.
Until SSC support for X1E lands, bitbang both i2c busses to enable
accelerometer functionality. In the future if/when sensors on this
platform can be used from DSP directly, this commit can be reverted.
Both accelerometers were tested individually via `monitor-sensor`.
Display accelerometer is defined first, as it appears automatic
screen rotation tools simply pick the 1st iio device.
Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
---
Enable two accelerometers, one on the motherboard, one in display.
In combination with userland screen rotation tools such as Gnome's
'screen rotate' [1] this allows for automatic screen rotation depending
on device orientation.
There appears to be an ALS, a "True Color Sensor with Flicker Detection"
AMS TCS3530 at 0x39. Out-of-tree driver from OSRAM is available [2].
Document bus, address, IRQ such that it could be added in the future.
There is an issue with st_sensors which prevents initializing two
sensors at the time, fix submitted [3]. It is not blocking this series,
as without it, 2nd currently unused accelerometer on the motherboard
will simply fail to probe.
[1] https://extensions.gnome.org/extension/5389/screen-rotate
[2] https://ams-osram.com/support/download-center?search=TCS3530&type=software&subtype=driver
[3] https://lore.kernel.org/all/20260228-st-iio-trigger-v1-1-abf5909e547f@vinarskis.com/
---
Changes in v2:
- Fixed i2c node names to pass dtbs_check
- Updated commit description to reflect discussions of v1
- Link to v1: https://lore.kernel.org/r/20260228-dell-xps-9345-accel-v1-1-daf9e3b3b5ee@vinarskis.com
---
.../boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
index ce7b10ea89b6dcb2a4a65c114037f4c90a4b0c6d..bde88655c36889cc4865a109370a9d2cd0166a00 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
@@ -40,6 +40,67 @@ switch-lid {
};
};
+ /* Display-mounted sensors */
+ i2c-sensors1 {
+ compatible = "i2c-gpio";
+ i2c-gpio,delay-us = <2>;
+
+ scl-gpios = <&tlmm 232 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&tlmm 231 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ pinctrl-0 = <&sensors_i2c_display_default>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@18 {
+ compatible = "st,lis2dw12";
+ reg = <0x18>;
+
+ interrupts-extended = <&tlmm 29 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&acc_display_int_n_default>;
+ pinctrl-names = "default";
+
+ mount-matrix = "-1", "0", "0",
+ "0", "1", "0",
+ "0", "0", "-1";
+ };
+
+ /* AMS TCS3530 @ 0x39, IRQ 93 */
+ };
+
+ /* Motherboard-mounted sensors */
+ i2c-sensors2 {
+ compatible = "i2c-gpio";
+ i2c-gpio,delay-us = <2>;
+
+ scl-gpios = <&tlmm 216 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&tlmm 215 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ pinctrl-0 = <&sensors_i2c_mobo_default>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@18 {
+ compatible = "st,lis2dw12";
+ reg = <0x18>;
+
+ interrupts-extended = <&tlmm 28 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&acc_mobo_int_n_default>;
+ pinctrl-names = "default";
+
+ vdd-supply = <&vreg_l10b_1p8>;
+ vddio-supply = <&vreg_l10b_1p8>;
+
+ mount-matrix = "0", "1", "0",
+ "0", "0", "1",
+ "1", "0", "0";
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -450,6 +511,13 @@ vreg_l9b_2p9: ldo9 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
+ vreg_l10b_1p8: ldo10 {
+ regulator-name = "vreg_l10b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
vreg_l12b_1p2: ldo12 {
regulator-name = "vreg_l12b_1p2";
regulator-min-microvolt = <1200000>;
@@ -1074,6 +1142,18 @@ &tlmm {
<76 4>, /* SPI19 (TZ Protected) */
<238 1>; /* UFS Reset */
+ acc_display_int_n_default: acc-display-int-n-state {
+ pins = "gpio29";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ acc_mobo_int_n_default: acc-mobo-int-n-state {
+ pins = "gpio28";
+ function = "gpio";
+ bias-pull-up;
+ };
+
cam_indicator_en: cam-indicator-en-state {
pins = "gpio110";
function = "gpio";
@@ -1197,6 +1277,20 @@ rtmr1_default: rtmr1-reset-n-active-state {
bias-disable;
};
+ sensors_i2c_display_default: sensors-i2c-display-state {
+ pins = "gpio231", "gpio232";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sensors_i2c_mobo_default: sensors-i2c-mobo-state {
+ pins = "gpio215", "gpio216";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
tpad_default: tpad-default-state {
disable-pins {
pins = "gpio38";
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260228-dell-xps-9345-accel-4ab40ed9c827
Best regards,
--
Aleksandrs Vinarskis <alex@vinarskis.com>
^ permalink raw reply related
* Re: [PATCH 1/3] arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes
From: Konrad Dybcio @ 2026-03-31 13:37 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-eliza-adsp-usb-v1-1-d8a251be20c3@oss.qualcomm.com>
On 3/31/26 12:37 PM, Abel Vesa wrote:
> Describe the ADSP remoteproc node along with its dependencies, including
> the IPCC mailbox, AOSS QMP and SMP2P links used for communication.
>
> The Eliza SoC features a USB 3.1 Gen 2 controller connected to a QMP
> combo PHY and an SNPS eUSB2 PHY. Describe them.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
[...]
> + usb_hsphy: phy@88e3000 {
> + compatible = "qcom,eliza-snps-eusb2-phy",
> + "qcom,sm8550-snps-eusb2-phy";
> + reg = <0x0 0x088e3000 0x0 0x154>;
> + #phy-cells = <0>;
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>;
This is TCSR_USB2_CLKREF_EN
> + usb: usb@a600000 {
> + compatible = "qcom,eliza-dwc3", "qcom,snps-dwc3";
Does the device suspend and resume successfully?
Konrad
^ permalink raw reply
* Re: [PATCH v8 2/3] hwmon: ltc4283: Add support for the LTC4283 Swap Controller
From: Guenter Roeck @ 2026-03-31 13:31 UTC (permalink / raw)
To: Nuno Sá
Cc: Nuno Sá, linux-gpio, linux-hwmon, devicetree, linux-doc,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <acuLynb1hRFJRcEf@nsa>
On 3/31/26 02:48, Nuno Sá wrote:
> On Mon, Mar 30, 2026 at 08:47:32AM -0700, Guenter Roeck wrote:
>> On 3/30/26 02:28, Nuno Sá wrote:
>>> Hi Guenter, Regarding AI review, I think most of the points were
>>> discussed in previous revisions, but there are two valid.
>>>
>>> On Fri, Mar 27, 2026 at 05:26:15PM +0000, Nuno Sá wrote:
>>>> Support the LTC4283 Hot Swap Controller. The device features programmable
>>>> current limit with foldback and independently adjustable inrush current to
>>>> optimize the MOSFET safe operating area (SOA). The SOA timer limits MOSFET
>>>> temperature rise for reliable protection against overstresses.
>>>>
>>>> An I2C interface and onboard ADC allow monitoring of board current,
>>>> voltage, power, energy, and fault status.
>>>>
>>>> Signed-off-by: Nuno Sá <nuno.sa@analog.com>
>>>> ---
>>>> Documentation/hwmon/index.rst | 1 +
>>>> Documentation/hwmon/ltc4283.rst | 266 ++++++
>>>> MAINTAINERS | 1 +
>>>> drivers/hwmon/Kconfig | 12 +
>>>> drivers/hwmon/Makefile | 1 +
>>>> drivers/hwmon/ltc4283.c | 1796 +++++++++++++++++++++++++++++++++++++++
>>>> 6 files changed, 2077 insertions(+)
>>>>
>>>
>>> ...
>>>
>>>> +static int ltc4283_read_in_alarm(struct ltc4283_hwmon *st, u32 channel,
>>>> + bool max_alm, long *val)
>>>> +{
>>>> + if (channel == LTC4283_VPWR)
>>>> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_1,
>>>> + BIT(2 + max_alm), val);
>>>> +
>>>> + if (channel >= LTC4283_CHAN_ADI_1 && channel <= LTC4283_CHAN_ADI_4) {
>>>> + u32 bit = (channel - LTC4283_CHAN_ADI_1) * 2;
>>>> + /*
>>>> + * Lower channels go to higher bits. We also want to go +1 down
>>>> + * in the min_alarm case.
>>>> + */
>>>> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_2,
>>>> + BIT(7 - bit - !max_alm), val);
>>>> + }
>>>> +
>>>> + if (channel >= LTC4283_CHAN_ADIO_1 && channel <= LTC4283_CHAN_ADIO_4) {
>>>> + u32 bit = (channel - LTC4283_CHAN_ADIO_1) * 2;
>>>> +
>>>> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_3,
>>>> + BIT(7 - bit - !max_alm), val);
>>>> + }
>>>> +
>>>> + if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
>>>> + u32 bit = (channel - LTC4283_CHAN_ADIN12) * 2;
>>>> +
>>>> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_5,
>>>> + BIT(7 - bit - !max_alm), val);
>>>> + }
>>>
>>> "Will this condition handle the ADIO12 and ADIO34 differential channels?
>>> It looks like channels 14 and 15 fall through to the default return intended
>>> for the DRAIN channel. Since reading the alarm implicitly clears the register
>>> bits, could reading these ADIO alarms unintentionally clear actual DRAIN
>>> alarms? Should the upper bound be LTC4283_CHAN_ADIO34?"
>>>
>>> Good catch and should be:
>>>
>>> - if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
>>> + if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIO34) {
>>>
>>>> +
>>>> + if (channel == LTC4283_CHAN_DRNS)
>>>> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4,
>>>> + BIT(6 + max_alm), val);
>>>> +
>>>> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4, BIT(4 + max_alm),
>>>> + val);
>>>> +}
>>>
>>> ...
>>>
>>>> +
>>>> +static int ltc4283_probe(struct i2c_client *client)
>>>> +{
>>>> + struct device *dev = &client->dev, *hwmon;
>>>> + struct auxiliary_device *adev;
>>>> + struct ltc4283_hwmon *st;
>>>> + int ret;
>>>> +
>>>> + st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
>>>> + if (!st)
>>>> + return -ENOMEM;
>>>> +
>>>> + if (!i2c_check_functionality(client->adapter,
>>>> + I2C_FUNC_SMBUS_BYTE_DATA |
>>>> + I2C_FUNC_SMBUS_WORD_DATA |
>>>> + I2C_FUNC_SMBUS_READ_I2C_BLOCK))
>>>> + return -EOPNOTSUPP;
>>>> +
>>>> + st->client = client;
>>>> + st->map = devm_regmap_init(dev, <c4283_regmap_bus, client,
>>>> + <c4283_regmap_config);
>>>> + if (IS_ERR(st->map))
>>>> + return dev_err_probe(dev, PTR_ERR(st->map),
>>>> + "Failed to create regmap\n");
>>>> +
>>>> + ret = ltc4283_setup(st, dev);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + hwmon = devm_hwmon_device_register_with_info(dev, "ltc4283", st,
>>>> + <c4283_chip_info, NULL);
>>>> +
>>>> + if (IS_ERR(hwmon))
>>>> + return PTR_ERR(hwmon);
>>>> +
>>>> + ltc4283_debugfs_init(st, client);
>>>> +
>>>> + if (!st->gpio_mask)
>>>> + return 0;
>>>> +
>>>> + adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
>>>> + if (!adev)
>>>> + return dev_err_probe(dev, -ENODEV, "Failed to add GPIO device\n");
>>>
>>> "Does this allow multiple LTC4283 chips to probe successfully?
>>> Without allocating a unique ID per I2C instance, it seems the first probed
>>> chip takes the generic name. If a second chip is present, it might attempt
>>> to register with the exact same name, resulting in a failure in device_add()
>>> and aborting the probe."
>>>
>>> Also looks valid and I suspect is one of those that a quick look will
>>> find more "offenders". I would purpose:
>>>
>>> - adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
>>> + adev = __devm_auxiliary_device_create(dev, KBUILD_MODNAME, "gpio",
>>> + &st->gpio_mask, client->addr);
>>>
>>
>> That would still fail if there are multiple chips at the same I2C address
>> on multiple I2C busses. Check drivers/gpu/drm/bridge/ti-sn65dsi86.c which has
>> the same problem.
>
> I did looked at that one but totally forgot the multiple busses
> scenario.
>
>>
>>> If there's nothing else and you agree with the above, is this something
>>> you can tweak while applying or should I spin a new version?
>>>
>>
>> Please respin. Also, regarding the other concerns:
>>
>> Can BIT(8) * st->rsense wrap to zero on 32-bit architectures?
>> BIT(8) is a 32-bit unsigned long and st->rsense is a u32. If a user sets a
>> very large sense resistor value via the device tree, the multiplication could
>> wrap to 0, causing a division-by-zero kernel panic. Should the divisor use
>> BIT_ULL(8)?
>>
>> Unless I am missing something, this _can_ overflow. Try to provide a sense
>> resistor value of 1677721600. Yes, it is unreasonable to specify such large
>> rsense values, but why not just limit it such that it does not overflow ?
>
> Yes, that's pretty much my reasoning (regarding the unreasonable
> rsense). I could just make BIT_ULL() and be done with it. I can also
> also cap rsense to a max value but i'm not 100% what that value would
> be. Maybe 1 ohm is already more than reasonable. I can also ask internally. Any
> preference on this one?
>
I'd suggest to reject large (unreasonable) values. In this case, rejecting rsense
values >= 1677721600 should solve the problem.
>>
>> Also, for the overflow concerns, if you are sure they can not happen, I'll
>> really need to write the unit test code to make sure that this is indeed
>> the case.
>>
>
> Hmm, for the val * MILLI case, well it should not happen but given it
> depends on user input, better if I clamp it before passing the
> value to ltc4283_write_in_byte(). Yes, we clamp again inside the
> write_bytes() API but not a big deal.
>
> For the st->power_max is again one of those cases where the values would
> not make sense (I think - the combination of vsense_max and rsense). Just looking
> at the code, it can overflow but this one I'm not really sure how we could handle it.
> Maybe clamp power_max to U8_MAX and have a warning message in ltc4283_read_power_byte() if
> we overflow long in which case we need a power64 attr?
>
> But even clamping does not make much sense here. The power limit register
> is 8 bits, so if our design (rsense + vsense_max) overflows that,
> there's nothing we can do other that erroring out.
>
Again, why not just reject unreasonable values such that calculations
can not overflow ?
In other drivers, the common approach is to reject unreeasonable values if
provided through devicetree and to clamp them if provided through sysfs.
I don't see why that would not work here.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: qcom: sm6350: Add CAMSS node
From: Vladimir Zapolskiy @ 2026-03-31 13:29 UTC (permalink / raw)
To: Luca Weiss
Cc: Bryan O'Donoghue, Robert Foss, ~postmarketos/upstreaming,
phone-devel, linux-arm-msm, linux-media, devicetree, linux-kernel,
Todor Tomov, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio
In-Reply-To: <20260216-sm6350-camss-v4-3-b9df35f87edb@fairphone.com>
On 2/16/26 10:54, Luca Weiss wrote:
> Add a node for the CAMSS on the SM6350 SoC.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> arch/arm64/boot/dts/qcom/sm6350.dtsi | 233 +++++++++++++++++++++++++++++++++++
> 1 file changed, 233 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
> index 9f9b9f9af0da..9ff9508c5ce6 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
> @@ -2161,6 +2161,239 @@ cci1_i2c0: i2c-bus@0 {
> /* SM6350 seems to have cci1_i2c1 on gpio2 & gpio3 but unused downstream */
> };
>
> + camss: isp@acb3000 {
> + compatible = "qcom,sm6350-camss";
> +
> + reg = <0x0 0x0acb3000 0x0 0x1000>,
> + <0x0 0x0acba000 0x0 0x1000>,
> + <0x0 0x0acc1000 0x0 0x1000>,
> + <0x0 0x0acc8000 0x0 0x1000>,
> + <0x0 0x0ac65000 0x0 0x1000>,
> + <0x0 0x0ac66000 0x0 0x1000>,
> + <0x0 0x0ac67000 0x0 0x1000>,
> + <0x0 0x0ac68000 0x0 0x1000>,
> + <0x0 0x0acaf000 0x0 0x4000>,
> + <0x0 0x0acb6000 0x0 0x4000>,
> + <0x0 0x0acbd000 0x0 0x4000>,
> + <0x0 0x0acc4000 0x0 0x4000>,
> + <0x0 0x0ac18000 0x0 0x3000>,
> + <0x0 0x0ac00000 0x0 0x6000>,
> + <0x0 0x0ac10000 0x0 0x8000>,
> + <0x0 0x0ac6f000 0x0 0x8000>,
> + <0x0 0x0ac42000 0x0 0x4600>,
> + <0x0 0x01fc0000 0x0 0x40000>,
I notice that this memory range is very distant, can somebody with
the access to the specs confirm that it is a part of CAMSS IP?
> + <0x0 0x0ac48000 0x0 0x1000>,
> + <0x0 0x0ac40000 0x0 0x1000>,
> + <0x0 0x0ac87000 0x0 0xa000>,
> + <0x0 0x0ac52000 0x0 0x4000>,
> + <0x0 0x0ac4e000 0x0 0x4000>,
> + <0x0 0x0ac6b000 0x0 0xa00>;
> + reg-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite",
> + "a5_csr",
> + "a5_qgic",
> + "a5_sierra",
> + "bps",
> + "camnoc",
> + "core_top_csr_tcsr",
Looking at the memory map I have a feeling that this "core_top_csr_tcsr"
is not a natural part of CAMSS IPs, it should be clarified by someone
else.
> + "cpas_cdm",
> + "cpas_top",
> + "ipe",
> + "jpeg_dma",
> + "jpeg_enc",
> + "lrme";
> +
The .dtsi change strictly follows the dt bindings description, won't
repeat previously given concerns here, so
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: eliza-mtp: Enable USB and ADSP support
From: Krzysztof Kozlowski @ 2026-03-31 13:27 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-eliza-adsp-usb-v1-3-d8a251be20c3@oss.qualcomm.com>
On 31/03/2026 12:37, Abel Vesa wrote:
> The Eliza MTP features a single USB Type-C port. Its USB 2.0 lines are
> routed through an eUSB2 repeater provided by the PM7750BA PMIC.
>
> Describe the port and repeater, and enable the USB controller and PHYs.
>
> Also specify the ADSP firmware and enable the remoteproc.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza-mtp.dts | 83 ++++++++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
>
With fix as pointed out by Konrad:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes
From: Krzysztof Kozlowski @ 2026-03-31 13:27 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-eliza-adsp-usb-v1-1-d8a251be20c3@oss.qualcomm.com>
On 31/03/2026 12:37, Abel Vesa wrote:
> Describe the ADSP remoteproc node along with its dependencies, including
> the IPCC mailbox, AOSS QMP and SMP2P links used for communication.
>
> The Eliza SoC features a USB 3.1 Gen 2 controller connected to a QMP
> combo PHY and an SNPS eUSB2 PHY. Describe them.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 261 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 261 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v13 0/5] PolarFire SoC GPIO interrupt support
From: Bartosz Golaszewski @ 2026-03-31 13:25 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-gpio, Conor Dooley, Herve Codina, Daire McNamara,
Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Linus Walleij, linux-riscv,
devicetree, linux-kernel, Thomas Gleixner
In-Reply-To: <20260331-dominion-conjoined-c87ec5bc7db2@spud>
On Tue, Mar 31, 2026 at 3:15 PM Conor Dooley <conor@kernel.org> wrote:
>
> From: Conor Dooley <conor.dooley@microchip.com>
>
> On Wed, 18 Mar 2026 11:04:31 +0000, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> >
> > Yo,
> >
> > Here's a v3 with an extra patch updating the gpio binding from fished
> > out from my old branch, fixing the examples and setting the permitted
> > values of gpios for the controllers on polarfire soc and the existing
> > binding patch's example fixed.
> >
> > [...]
>
> Gonna interpret the ack and lack of response to me asking if the gpio
> change was mine to take as it being the case.
> Applied to riscv-soc-for-next, thanks!
>
> [2/5] gpio: mpfs: Add interrupt support
> https://git.kernel.org/conor/c/e57b53f0f36a
> [3/5] dt-bindings: soc: microchip: document PolarFire SoC's gpio interrupt mux
> https://git.kernel.org/conor/c/5f3575cc73dc
> [4/5] soc: microchip: add mpfs gpio interrupt mux driver
> https://git.kernel.org/conor/c/bd34cdd6d214
>
> Thanks,
> Conor.
Ah, yes sorry, your email went under my radar. Feel free to take them.
Bart
^ permalink raw reply
* Re: [PATCH v4 2/3] media: qcom: camss: Add SM6350 support
From: Vladimir Zapolskiy @ 2026-03-31 13:20 UTC (permalink / raw)
To: Luca Weiss, Bryan O'Donoghue, Robert Foss, Todor Tomov,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Bjorn Andersson,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-media, devicetree, linux-kernel
In-Reply-To: <20260216-sm6350-camss-v4-2-b9df35f87edb@fairphone.com>
On 2/16/26 10:54, Luca Weiss wrote:
> Add the necessary support for CAMSS on the SM6350 SoC.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v5 09/11] mfd: bq257xx: Add BQ25792 support
From: Lee Jones @ 2026-03-31 13:17 UTC (permalink / raw)
To: Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chris Morgan,
Liam Girdwood, Mark Brown, Sebastian Reichel, devicetree,
linux-kernel, Sebastian Reichel, linux-pm
In-Reply-To: <CAKTNdwE4omfEkd6FNdj=hZUY2ZwLprXzUu1L4juFhWCxbWEjpQ@mail.gmail.com>
On Tue, 31 Mar 2026, Alexey Charkov wrote:
> On Tue, Mar 31, 2026 at 2:27 PM Lee Jones <lee@kernel.org> wrote:
> >
> > On Tue, 24 Mar 2026, Alexey Charkov wrote:
> >
> > > Add register definitions and a new 'type' enum to be passed via MFD
> > > private data to support the BQ25792, which is a newer variant of the
> > > BQ257xx family.
> > >
> > > BQ25792 shares similar logic of operation with the already supported
> > > BQ25703A but has a completely different register map and different
> > > electrical constraints.
> > >
> > > Tested-by: Chris Morgan <macromorgan@hotmail.com>
> > > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > > ---
> > > drivers/mfd/bq257xx.c | 54 +++++-
> > > include/linux/mfd/bq257xx.h | 412 ++++++++++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 463 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/mfd/bq257xx.c b/drivers/mfd/bq257xx.c
> > > index e9d49dac0a16..31654925afa5 100644
> > > --- a/drivers/mfd/bq257xx.c
> > > +++ b/drivers/mfd/bq257xx.c
> > > @@ -39,6 +39,39 @@ static const struct regmap_config bq25703_regmap_config = {
> > > .val_format_endian = REGMAP_ENDIAN_LITTLE,
> > > };
> > >
> > > +static const struct regmap_range bq25792_writeable_reg_ranges[] = {
> > > + regmap_reg_range(BQ25792_REG00_MIN_SYS_VOLTAGE,
> > > + BQ25792_REG18_NTC_CONTROL_1),
> > > + regmap_reg_range(BQ25792_REG28_CHARGER_MASK_0,
> > > + BQ25792_REG30_ADC_FUNCTION_DISABLE_1),
> > > +};
> > > +
> > > +static const struct regmap_access_table bq25792_writeable_regs = {
> > > + .yes_ranges = bq25792_writeable_reg_ranges,
> > > + .n_yes_ranges = ARRAY_SIZE(bq25792_writeable_reg_ranges),
> > > +};
> > > +
> > > +static const struct regmap_range bq25792_volatile_reg_ranges[] = {
> > > + regmap_reg_range(BQ25792_REG19_ICO_CURRENT_LIMIT,
> > > + BQ25792_REG27_FAULT_FLAG_1),
> > > + regmap_reg_range(BQ25792_REG31_IBUS_ADC,
> > > + BQ25792_REG47_DPDM_DRIVER),
> > > +};
> > > +
> > > +static const struct regmap_access_table bq25792_volatile_regs = {
> > > + .yes_ranges = bq25792_volatile_reg_ranges,
> > > + .n_yes_ranges = ARRAY_SIZE(bq25792_volatile_reg_ranges),
> > > +};
> > > +
> > > +static const struct regmap_config bq25792_regmap_config = {
> > > + .reg_bits = 8,
> > > + .val_bits = 8,
> > > + .max_register = BQ25792_REG48_PART_INFORMATION,
> > > + .cache_type = REGCACHE_MAPLE,
> > > + .wr_table = &bq25792_writeable_regs,
> > > + .volatile_table = &bq25792_volatile_regs,
> > > +};
> > > +
> > > static const struct mfd_cell cells[] = {
> > > MFD_CELL_NAME("bq257xx-regulator"),
> > > MFD_CELL_NAME("bq257xx-charger"),
> > > @@ -46,6 +79,7 @@ static const struct mfd_cell cells[] = {
> > >
> > > static int bq257xx_probe(struct i2c_client *client)
> > > {
> > > + const struct regmap_config *rcfg;
> > > struct bq257xx_device *ddata;
> > > int ret;
> > >
> > > @@ -53,9 +87,21 @@ static int bq257xx_probe(struct i2c_client *client)
> > > if (!ddata)
> > > return -ENOMEM;
> > >
> > > + ddata->type = (uintptr_t)i2c_get_match_data(client);
> > > ddata->client = client;
> > >
> > > - ddata->regmap = devm_regmap_init_i2c(client, &bq25703_regmap_config);
> > > + switch (ddata->type) {
> > > + case BQ25703A:
> > > + rcfg = &bq25703_regmap_config;
> > > + break;
> > > + case BQ25792:
> > > + rcfg = &bq25792_regmap_config;
> > > + break;
> > > + default:
> > > + return dev_err_probe(&client->dev, -EINVAL, "Unsupported device type\n");
> >
> > Nit: Shouldn't we be returning '-ENODEV' here for an unsupported device?
>
> Hi Lee,
>
> Indeed, I've had a quick look and other drivers seem to return -ENODEV
> in similar situations. Shall I respin a new version with that change?
Yes please. And add a change log so I am reminded of it.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v13 0/5] PolarFire SoC GPIO interrupt support
From: Conor Dooley @ 2026-03-31 13:14 UTC (permalink / raw)
To: linux-gpio, Conor Dooley
Cc: Conor Dooley, Herve Codina, Daire McNamara, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Linus Walleij, Bartosz Golaszewski, linux-riscv,
devicetree, linux-kernel, Thomas Gleixner
In-Reply-To: <20260318-gift-nearest-fd3ef3e4819b@spud>
From: Conor Dooley <conor.dooley@microchip.com>
On Wed, 18 Mar 2026 11:04:31 +0000, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
>
> Yo,
>
> Here's a v3 with an extra patch updating the gpio binding from fished
> out from my old branch, fixing the examples and setting the permitted
> values of gpios for the controllers on polarfire soc and the existing
> binding patch's example fixed.
>
> [...]
Gonna interpret the ack and lack of response to me asking if the gpio
change was mine to take as it being the case.
Applied to riscv-soc-for-next, thanks!
[2/5] gpio: mpfs: Add interrupt support
https://git.kernel.org/conor/c/e57b53f0f36a
[3/5] dt-bindings: soc: microchip: document PolarFire SoC's gpio interrupt mux
https://git.kernel.org/conor/c/5f3575cc73dc
[4/5] soc: microchip: add mpfs gpio interrupt mux driver
https://git.kernel.org/conor/c/bd34cdd6d214
Thanks,
Conor.
^ 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