* [PATCH 0/7] dts: Add and use UART AP_DMA controller on MTK SoCs
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, kernel, justin.yeh
First of all: not all of them will use this and that's sure - but the
devicetree describes hardware, and this hardware was not described on
any of the SoCs that support the UART AP_DMA controller.
Besides, there is also driver support for this controller for all SoCs!
Let's add support for this IP in all of the SoCs that have it.
AngeloGioacchino Del Regno (7):
arm64: dts: mediatek: mt6795: Remove deprecated UART DMA property
arm64: dts: mediatek: mt8173: Add and use UART AP_DMA controller
arm64: dts: mediatek: mt8183: Add and use UART AP_DMA controller
arm64: dts: mediatek: mt8186: Add and use UART AP_DMA controller
arm64: dts: mediatek: mt8188: Add and use UART AP_DMA controller
arm64: dts: mediatek: mt8192: Add and use UART AP_DMA controller
arm64: dts: mediatek: mt8195: Add and use UART AP_DMA controller
arch/arm64/boot/dts/mediatek/mt6795.dtsi | 4 +--
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 27 +++++++++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 22 ++++++++++++++
arch/arm64/boot/dts/mediatek/mt8186.dtsi | 22 ++++++++++++++
arch/arm64/boot/dts/mediatek/mt8188.dtsi | 33 +++++++++++++++++++++
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 17 +++++++++++
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 37 ++++++++++++++++++++++++
7 files changed, 159 insertions(+), 3 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH 4/4] pmdomain: mediatek: Add support for MT8196 HFRP DirectCTL domains
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
To: ulfh
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
nfraprado, irving-ch.lin, macpaul.lin, aford173, mbrugger,
devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, justin.yeh, kernel
In-Reply-To: <20260701121920.19347-1-angelogioacchino.delregno@collabora.com>
Add support for the power domains provided by the HFRPSYS Power
Controller of the MT8196 SoC.
Those control power to the eDP and DP Transmitter IPs.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/pmdomain/mediatek/mt8196-pm-domains.h | 27 +++++++++++++++++++
drivers/pmdomain/mediatek/mtk-pm-domains.c | 4 +++
2 files changed, 31 insertions(+)
diff --git a/drivers/pmdomain/mediatek/mt8196-pm-domains.h b/drivers/pmdomain/mediatek/mt8196-pm-domains.h
index 2e4b28720659..d704c9fa9337 100644
--- a/drivers/pmdomain/mediatek/mt8196-pm-domains.h
+++ b/drivers/pmdomain/mediatek/mt8196-pm-domains.h
@@ -602,6 +602,27 @@ static const struct scpsys_hwv_domain_data hfrpsys_hwv_domain_data_mt8196[] = {
},
};
+static const struct scpsys_domain_data hfrpsys_domain_data_mt8196[] = {
+ [MT8196_POWER_DOMAIN_EDPTX] = {
+ .name = "edp-tx",
+ .sta_mask = MT8196_PWR_ACK,
+ .sta2nd_mask = MT8196_PWR_ACK_2ND,
+ .ctl_offs = 0x74,
+ .pwr_sta_offs = 0x74,
+ .pwr_sta2nd_offs = 0x74,
+ .caps = MTK_SCPD_SIMPLE_PWRSEQ,
+ },
+ [MT8196_POWER_DOMAIN_DPTX] = {
+ .name = "dp-tx",
+ .sta_mask = MT8196_PWR_ACK,
+ .sta2nd_mask = MT8196_PWR_ACK_2ND,
+ .ctl_offs = 0x78,
+ .pwr_sta_offs = 0x78,
+ .pwr_sta2nd_offs = 0x78,
+ .caps = MTK_SCPD_SIMPLE_PWRSEQ,
+ },
+};
+
static const struct scpsys_soc_data mt8196_scpsys_data = {
.domains_data = scpsys_domain_data_mt8196,
.num_domains = ARRAY_SIZE(scpsys_domain_data_mt8196),
@@ -616,6 +637,12 @@ static const struct scpsys_soc_data mt8196_scpsys_hwv_data = {
.type = SCPSYS_MTCMOS_TYPE_HW_VOTER,
};
+static const struct scpsys_soc_data mt8196_hfrpsys_data = {
+ .domains_data = hfrpsys_domain_data_mt8196,
+ .num_domains = ARRAY_SIZE(hfrpsys_domain_data_mt8196),
+ .type = SCPSYS_MTCMOS_TYPE_DIRECT_CTL,
+};
+
static const struct scpsys_soc_data mt8196_hfrpsys_hwv_data = {
.hwv_domains_data = hfrpsys_hwv_domain_data_mt8196,
.num_hwv_domains = ARRAY_SIZE(hfrpsys_hwv_domain_data_mt8196),
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index 5276adea1d04..f69cf69ba0f6 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -1252,6 +1252,10 @@ static const struct of_device_id scpsys_of_match[] = {
.compatible = "mediatek,mt8196-power-controller",
.data = &mt8196_scpsys_data,
},
+ {
+ .compatible = "mediatek,mt8196-hfrp-power-controller",
+ .data = &mt8196_hfrpsys_data,
+ },
{
.compatible = "mediatek,mt8196-hwv-hfrp-power-controller",
.data = &mt8196_hfrpsys_hwv_data,
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] pmdomain: mediatek: Respect PD relationships during error cleanup
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
To: ulfh
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
nfraprado, irving-ch.lin, macpaul.lin, aford173, mbrugger,
devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, justin.yeh, kernel
In-Reply-To: <20260701121920.19347-1-angelogioacchino.delregno@collabora.com>
In case any probe error occurs (usually, a probe deferral) the
power domains shall be cleaned up while respecting their child
to parent relationship, or the system may freeze.
In order to do that without any memory footprint impacts after
the fact, allocate a temporary array in the probe function and
use it to store the indices of the added power domains in the
correct order.
This will be used in the error cleanup path and will be freed
at the end regardless of the probe status as, when the probing
succeeds, the genpd API takes care of unregistering all PDs in
the correct order anyway.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/pmdomain/mediatek/mtk-pm-domains.c | 43 +++++++++++++++++-----
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index e1cfd4223473..db543d4b1813 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -738,7 +738,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
}
static struct
-generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_node *node)
+generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_node *node,
+ u8 *domains_idx, u8 *num_domains)
{
const struct scpsys_domain_data *domain_data;
const struct scpsys_hwv_domain_data *hwv_domain_data;
@@ -906,6 +907,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
else
pm_genpd_init(&pd->genpd, NULL, false);
+ domains_idx[(*num_domains)++] = (u8) id;
scpsys->domains[id] = &pd->genpd;
return scpsys->pd_data.domains[id];
@@ -917,7 +919,8 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
return ERR_PTR(ret);
}
-static int scpsys_add_subdomain(struct scpsys *scpsys, struct device_node *parent)
+static int scpsys_add_subdomain(struct scpsys *scpsys, struct device_node *parent,
+ u8 *domains_idx, u8 *num_domains)
{
struct generic_pm_domain *child_pd, *parent_pd;
struct device_node *child;
@@ -940,7 +943,7 @@ static int scpsys_add_subdomain(struct scpsys *scpsys, struct device_node *paren
parent_pd = scpsys->pd_data.domains[id];
- child_pd = scpsys_add_one_domain(scpsys, child);
+ child_pd = scpsys_add_one_domain(scpsys, child, domains_idx, num_domains);
if (IS_ERR(child_pd)) {
ret = PTR_ERR(child_pd);
dev_err_probe(scpsys->dev, ret, "%pOF: failed to get child domain id\n",
@@ -949,7 +952,7 @@ static int scpsys_add_subdomain(struct scpsys *scpsys, struct device_node *paren
}
/* recursive call to add all subdomains */
- ret = scpsys_add_subdomain(scpsys, child);
+ ret = scpsys_add_subdomain(scpsys, child, domains_idx, num_domains);
if (ret)
goto err_put_node;
@@ -991,14 +994,16 @@ static void scpsys_remove_one_domain(struct scpsys_domain *pd)
clk_bulk_put(pd->num_subsys_clks, pd->subsys_clks);
}
-static void scpsys_domain_cleanup(struct scpsys *scpsys)
+static void scpsys_domain_cleanup(struct scpsys *scpsys, u8 *domains_idx, u8 num_probed)
{
struct generic_pm_domain *genpd;
struct scpsys_domain *pd;
int i;
- for (i = scpsys->pd_data.num_domains - 1; i >= 0; i--) {
- genpd = scpsys->pd_data.domains[i];
+ for (i = num_probed - 1; i >= 0; i--) {
+ u8 pd_idx = domains_idx[i];
+
+ genpd = scpsys->pd_data.domains[pd_idx];
if (genpd) {
pd = to_scpsys_domain(genpd);
scpsys_remove_one_domain(pd);
@@ -1215,6 +1220,8 @@ static int scpsys_probe(struct platform_device *pdev)
struct device *parent;
struct scpsys *scpsys;
int num_domains, ret;
+ u8 num_added_pds = 0;
+ u8 *added_pds_idx;
soc = of_device_get_match_data(&pdev->dev);
if (!soc) {
@@ -1228,6 +1235,19 @@ static int scpsys_probe(struct platform_device *pdev)
if (!scpsys)
return -ENOMEM;
+ /*
+ * Temporarily store the IDs of the power domains that are added as in
+ * case of a probe deferral this can be used to correctly cleanup all
+ * of what was added before.
+ *
+ * Note that this array is used only in the probe function and must be
+ * freed at the end, regardless of whether all of the power domains were
+ * probed successfully or any failure happened.
+ */
+ added_pds_idx = devm_kmalloc_array(dev, num_domains, sizeof(*added_pds_idx), GFP_KERNEL);
+ if (!added_pds_idx)
+ return -ENOMEM;
+
scpsys->dev = dev;
scpsys->soc_data = soc;
@@ -1258,13 +1278,15 @@ static int scpsys_probe(struct platform_device *pdev)
for_each_available_child_of_node_scoped(np, node) {
struct generic_pm_domain *domain;
- domain = scpsys_add_one_domain(scpsys, node);
+ domain = scpsys_add_one_domain(scpsys, node,
+ added_pds_idx, &num_added_pds);
if (IS_ERR(domain)) {
ret = PTR_ERR(domain);
goto err_cleanup_domains;
}
- ret = scpsys_add_subdomain(scpsys, node);
+ ret = scpsys_add_subdomain(scpsys, node,
+ added_pds_idx, &num_added_pds);
if (ret)
goto err_cleanup_domains;
}
@@ -1280,10 +1302,11 @@ static int scpsys_probe(struct platform_device *pdev)
goto err_cleanup_domains;
}
+ devm_kfree(dev, added_pds_idx);
return 0;
err_cleanup_domains:
- scpsys_domain_cleanup(scpsys);
+ scpsys_domain_cleanup(scpsys, added_pds_idx, num_added_pds);
return ret;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: power: mediatek: Add support for MT8196 direct HFRP
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
To: ulfh
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
nfraprado, irving-ch.lin, macpaul.lin, aford173, mbrugger,
devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, justin.yeh, kernel
In-Reply-To: <20260701121920.19347-1-angelogioacchino.delregno@collabora.com>
Add support for the HFRPSYS direct control power domains in the
MT8196 SoC, controlling power for the DisplayPort and for the
Embedded DisplayPort Transmitter IPs.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../devicetree/bindings/power/mediatek,power-controller.yaml | 1 +
include/dt-bindings/power/mediatek,mt8196-power.h | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
index 07f046277f8a..070c6e5666dc 100644
--- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -34,6 +34,7 @@ properties:
- mediatek,mt8189-power-controller
- mediatek,mt8192-power-controller
- mediatek,mt8195-power-controller
+ - mediatek,mt8196-hfrp-power-controller
- mediatek,mt8196-hwv-hfrp-power-controller
- mediatek,mt8196-hwv-scp-power-controller
- mediatek,mt8196-power-controller
diff --git a/include/dt-bindings/power/mediatek,mt8196-power.h b/include/dt-bindings/power/mediatek,mt8196-power.h
index 0f622a93c807..085790bf8124 100644
--- a/include/dt-bindings/power/mediatek,mt8196-power.h
+++ b/include/dt-bindings/power/mediatek,mt8196-power.h
@@ -30,6 +30,10 @@
#define MT8196_POWER_DOMAIN_MM_PROC_DORMANT 0
#define MT8196_POWER_DOMAIN_SSR 1
+/* HFRPSYS Multimedia Power Control (MMPC) - Direct Control */
+#define MT8196_POWER_DOMAIN_EDPTX 0
+#define MT8196_POWER_DOMAIN_DPTX 1
+
/* HFRPSYS MultiMedia Power Control (MMPC) - HW Voter */
#define MT8196_POWER_DOMAIN_VDE0 0
#define MT8196_POWER_DOMAIN_VDE1 1
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] pmdomains: Fixes and add support for HFRP Direct
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
To: ulfh
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
nfraprado, irving-ch.lin, macpaul.lin, aford173, mbrugger,
devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, justin.yeh, kernel
This series adds support for the DirectCTL HFRPSYS power domains found
on the MT8196 SoC (the ones without HW Voter support) and also adds a
fix to respect the power domain relationships during error cleanup,
which avoids HW lockups in case probe deferrals in the specific case
of "almost fully probed" power domains (where most of them probed and
got set up but a probe deferral happened almost at the end), behavior
seen on the MT8189 SoC during bringup (but honestly I have no idea how
are the current ones working fine without this fix...!).
This was tested on MT8173, MT8186, MT8188, MT8189, MT8192, MT8195 and
also on MT8196, over months of development, both manually and over CI,
with no regressions detected.
AngeloGioacchino Del Regno (4):
dt-bindings: power: mediatek: Add support for MT8196 direct HFRP
pmdomain: mediatek: Respect PD relationships during error cleanup
pmdomain: mediatek: Add support for Direct CTL simple power sequence
pmdomain: mediatek: Add support for MT8196 HFRP DirectCTL domains
.../power/mediatek,power-controller.yaml | 1 +
drivers/pmdomain/mediatek/mt8196-pm-domains.h | 27 ++++
drivers/pmdomain/mediatek/mtk-pm-domains.c | 134 ++++++++++++++----
drivers/pmdomain/mediatek/mtk-pm-domains.h | 1 +
.../dt-bindings/power/mediatek,mt8196-power.h | 4 +
5 files changed, 141 insertions(+), 26 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH] spmi: mtk-pmif: Add workaround for FSM lockup/error in read operation
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
To: sboyd
Cc: matthias.bgg, angelogioacchino.delregno, justin.yeh, gregkh,
nfraprado, linux-kernel, linux-arm-kernel, linux-mediatek, kernel
The SPMI PMIF in some SoCs like MT8196 is affected by a hardware
issue that makes the first read operation on each SID to fail as
the FSM locks up after sending the read command, and this happens
at least in the following conditions:
- At boot, after bootloader handoff; and
- At every suspend->resume cycle.
This critical bug may produce unwanted issues in regulator drivers
which may fail to set voltages, making the platform to end up in a
undervoltage or, a bit more critically, an overvoltage condition,
producing instability or ... worse.
In order to work around this issue, add a retry mechanism into the
pmif_spmi_read_cmd() callback which will resend the read command
up to 3 times in the following conditions:
- Software Interface returns an error; or
- Software Interface never gets in WFVLDCLR state.
As to avoid uselessly blocking for too much time, only during the
read-retry loop, the maximum SWINF polling time for each trial is
reduced to PMIF_TIMEOUT_US / 2: this was tested on multiple SoCs
and seems to always be enough, as when any read succeeds it will
always take less than 40ms.
In any case, this is still allowing 1.5 times the previous maximum
polling time, reaching a total maximum (for 3 retries) of 150ms.
Worst case testing that I performed saw a third retry only 3 times
out of ~100 reboots.
Fixes: 1f5be2d7f743 ("spmi: mtk-pmif: Add support for MT8196 SPMI Controller")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/spmi/spmi-mtk-pmif.c | 38 +++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
index 1048420b5afb..61c916edaec4 100644
--- a/drivers/spmi/spmi-mtk-pmif.c
+++ b/drivers/spmi/spmi-mtk-pmif.c
@@ -21,6 +21,7 @@
#define SWINF_WFVLDCLR 0x06
#define GET_SWINF(x) (((x) >> 1) & 0x7)
+#define GET_SWINFERR(x) (((x) >> 18) & 0x1)
#define PMIF_CMD_REG_0 0
#define PMIF_CMD_REG 1
@@ -349,6 +350,7 @@ static int pmif_spmi_read_cmd(struct spmi_controller *ctrl, u8 opc, u8 sid,
struct pmif *arb = to_mtk_pmif(ctrl);
struct ch_reg *inf_reg;
int ret;
+ u8 retry = 0;
u32 data, cmd;
unsigned long flags;
@@ -385,17 +387,35 @@ static int pmif_spmi_read_cmd(struct spmi_controller *ctrl, u8 opc, u8 sid,
return ret;
}
- /* Send the command. */
cmd = (opc << 30) | (sid << 24) | ((len - 1) << 16) | addr;
- pmif_writel(arb, pbus, cmd, inf_reg->ch_send);
+ do {
+ /* Send the command. */
+ pmif_writel(arb, pbus, cmd, inf_reg->ch_send);
+
+ /*
+ * Wait for Software Interface FSM state to be WFVLDCLR or to
+ * return an error.
+ *
+ * If this is WFVLDCLR, read the data and clear the valid flag;
+ * If error or timeout, retry for a maximum of 3 times as a
+ * workaround for an hardware issue.
+ */
+ ret = readl_poll_timeout_atomic(pbus->base + arb->data->regs[inf_reg->ch_sta],
+ data,
+ GET_SWINF(data) == SWINF_WFVLDCLR ||
+ GET_SWINFERR(data),
+ PMIF_DELAY_US, PMIF_TIMEOUT_US / 2);
+ if (ret < 0)
+ continue;
+
+ if (GET_SWINFERR(data)) {
+ ret = -EIO;
+ continue;
+ }
+
+ break;
+ } while (++retry < 3);
- /*
- * Wait for Software Interface FSM state to be WFVLDCLR,
- * read the data and clear the valid flag.
- */
- ret = readl_poll_timeout_atomic(pbus->base + arb->data->regs[inf_reg->ch_sta],
- data, GET_SWINF(data) == SWINF_WFVLDCLR,
- PMIF_DELAY_US, PMIF_TIMEOUT_US);
if (ret < 0) {
raw_spin_unlock_irqrestore(&pbus->lock, flags);
dev_err(&ctrl->dev, "failed to wait for SWINF_WFVLDCLR\n");
--
2.54.0
^ permalink raw reply related
* [RFC 0/2] arm64: kprobes: Fix single-step fault and reentry handling
From: Pu Hu @ 2026-07-01 12:14 UTC (permalink / raw)
To: catalin.marinas@arm.com, will@kernel.org, naveen@kernel.org,
davem@davemloft.net, mhiramat@kernel.org,
yang@os.amperecomputing.com, Hongyan Xia, Jiazi Li,
ada.coupriediaz@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Cc: Pu Hu
From: hupu <hupu@transsion.com>
This series fixes two arm64 kprobes issues observed when running
simpleperf with preemptirq tracepoints and dwarf callchains while a
kprobe is active on a frequently executed kernel function.
The crash happens in the kprobe debug exception path. While a kprobe is
preparing or executing its XOL single-step instruction, perf/trace code
can run in the same window. That code may either take a fault of its own
or hit another kprobe.
Patch 1 makes kprobe_fault_handler() handle a fault in
KPROBE_HIT_SS/KPROBE_REENTER only when the faulting PC points at the
current kprobe's XOL instruction. Otherwise the fault is left to the
normal fault handling path.
Patch 2 allows a kprobe hit in KPROBE_HIT_SS to be handled as a
recoverable one-level reentry. Only a hit while already in
KPROBE_REENTER remains unrecoverable.
This follows the same logic as the existing x86 fixes:
6381c24cd6d5 ("kprobes/x86: Fix page-fault handling logic")
6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on single-stepping")
Reproducer:
simpleperf record -p <pid> -f 10000 \
-e preemptirq:preempt_disable \
-e preemptirq:preempt_enable \
--duration 9 --call-graph dwarf \
-o /data/local/tmp/perf.data
Before this series, the crash reproduced frequently. With both patches
applied, it was no longer reproduced in our testing.
hupu (2):
arm64: kprobes: Do not handle non-XOL faults as kprobe faults
arm64: kprobes: Allow reentering kprobes while single-stepping
arch/arm64/kernel/probes/kprobes.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-07-01 12:08 UTC (permalink / raw)
To: Michael Walle
Cc: Andy Shevchenko, Linus Walleij, Bartosz Golaszewski,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <DJN7EN61AJGW.2TV8JLMVRFTJ@kernel.org>
On Wed, Jul 01, 2026 at 01:38:54PM +0200, Michael Walle wrote:
> On Wed Jul 1, 2026 at 12:55 PM CEST, Andy Shevchenko wrote:
> > On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
> >> On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle@kernel.org> wrote:
> >> > On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
> >> > > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
> >> > >
> >> > >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> >> > >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> >> > >> >>> map() function.
> >> > >>
> >> > >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
> >> > >> only called if the irq handling is set up via gc->irq.chip and not
> >> > >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
> >> > >
> >> > > Not really, the gpiochip_irq_reqres() is called to mark that a
> >> > > GPIO line is used for IRQ, so the gpiolib cannot turn this
> >> > > GPIO into an output line, gpiod_direction_out() will fail
> >> > > on lines used for IRQ. So it's a failsafe.
> >> > >
> >> > > You can live without it of course, but then you don't get
> >> > > this failsafe.
> >> >
> >> > Thanks for the explanation! So did I make a mistake years ago by
> >> > adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
> >> > ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
> >> >
> >> > As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
> >> > to be a gpio_chip, which isn't the case (in general) for an
> >> > externally allocated domain, is it?
> >>
> >> So the whole issue comes from the fact that the IRQ chip is not marked
> >> as immutable. For immutable IRQ chips (which all GPIO provides should
> >> have) there is no such issue to begin with, id est there is no
> >> gpiochip_irq_reqres() callback assigned (and respective _relres).
> >
> > Ah, for immutable chips we put either custom ones or
> > GPIOCHIP_IRQ_RESOURCE_HELPERS which actually refers to those callbacks.
> >
> > So, if the domain is external, it should also provide irq_request_resources
> > and release callbacks. In the custom case we can wrap gpiochip_reqres_irq()
> > and gpiochip_relres_irq() respectively.
>
> Exactly. And its seems that this should have been possible with this
> series, too.
>
> Apart from that, most drivers use regmap-irq with gpio-regmap. For
> this we'd probably have to add something to regmap-irq because that
> module owns the irq_chip.
>
> > But we need to have a struct gpio_chip pointer for them. And note, the
> > IRQ chip data can be anything in that case, so it's not a requirement.
>
> That's what I've meant. Conceptionally, it should be part of
> gpiochip_irqchip_add_domain()/gpiolib, so a user doesn't have to
> have that knowledge. But I don't see how this could be achieved.
But it can be hidden in gpio-regmap + regmap-irq.
So, what we need is:
- patch regmap-irq to be able to customize irq_request_resources and release
- provide default callbacks in gpio-regmap (and export for external domains)
- use those callbacks by default when gpio-regmap creates an IRQ chip
The leftovers are the drivers that use gpio-regmap + their own call to
regmap-irq. I haven't looked into them closely, they usually have custom
xlate and something else. OTOH, they will be able to customize the resource
handling as well.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-07-01 12:03 UTC (permalink / raw)
To: Michael Walle
Cc: Andy Shevchenko, Linus Walleij, Bartosz Golaszewski,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <DJN7HPMWJLXG.157YRMNW34NJQ@kernel.org>
On Wed, Jul 01, 2026 at 01:42:55PM +0200, Michael Walle wrote:
> On Wed Jul 1, 2026 at 1:38 PM CEST, Andy Shevchenko wrote:
> > On Wed, Jul 01, 2026 at 01:55:11PM +0300, Andy Shevchenko wrote:
> >> On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
> >> > On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle@kernel.org> wrote:
> >> > > On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
> >> > > > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
> >> > > >
> >> > > >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> >> > > >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> >> > > >> >>> map() function.
> >> > > >>
> >> > > >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
> >> > > >> only called if the irq handling is set up via gc->irq.chip and not
> >> > > >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
> >> > > >
> >> > > > Not really, the gpiochip_irq_reqres() is called to mark that a
> >> > > > GPIO line is used for IRQ, so the gpiolib cannot turn this
> >> > > > GPIO into an output line, gpiod_direction_out() will fail
> >> > > > on lines used for IRQ. So it's a failsafe.
> >> > > >
> >> > > > You can live without it of course, but then you don't get
> >> > > > this failsafe.
> >> > >
> >> > > Thanks for the explanation! So did I make a mistake years ago by
> >> > > adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
> >> > > ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
> >> > >
> >> > > As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
> >> > > to be a gpio_chip, which isn't the case (in general) for an
> >> > > externally allocated domain, is it?
> >> >
> >> > So the whole issue comes from the fact that the IRQ chip is not marked
> >> > as immutable. For immutable IRQ chips (which all GPIO provides should
> >> > have) there is no such issue to begin with, id est there is no
> >> > gpiochip_irq_reqres() callback assigned (and respective _relres).
> >>
> >> Ah, for immutable chips we put either custom ones or
> >> GPIOCHIP_IRQ_RESOURCE_HELPERS which actually refers to those callbacks.
> >>
> >> So, if the domain is external, it should also provide irq_request_resources
> >> and release callbacks. In the custom case we can wrap gpiochip_reqres_irq()
> >> and gpiochip_relres_irq() respectively.
> >>
> >> But we need to have a struct gpio_chip pointer for them. And note, the
> >> IRQ chip data can be anything in that case, so it's not a requirement.
> >
> > And looking back for implementation in v3 the whole mistake was to use
> > GPIOCHIP_IRQ_RESOURCE_HELPERS. It just wanted custom callbacks with
> > the IRQ chip data assigned to whatever from which we may then deduce
> > struct gpio_chip. It does *not* require to be struct gpio_chip.
> > The local driver data structure should keep pointer to struct gpio_regmap.
> > That one can be used in the respective .irq_request_resources() and
> > .irq_release_resources(). The default ones for gpio-regmap may also
> > be provided via a macro, say GPIO_REGMAP_IRQ_RESOURCE_HELPERS.
> >
> > Hence I don't see the need of having gpio_regmap_get_gpiochip() helper
> > and driver can be implemented using gpio-regmap and external IRQ domain.
> >
> > What did I miss?
>
> IMHO nothing, that's exactly my understanding, too. Except for the
> GPIO_REGMAP_IRQ_RESOURCE_HELPERS. See my previous mail. Because that
> would have to be set by regmap-irq.
There are two cases:
- easy, when the chip is provided by the user
(in this case we just missing a couple of callbacks in gpio-regmap)
- hard, when chip is created by regmap-irq
(in this case regmap-irq missing to setup the callbacks)
So, effectively all GPIO drivers that use regmap-irq facility are
now missing the functionality of tracking "GPIO locked as IRQ".
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] ACPI: CPPC: add paired FFH feedback-counter read hook
From: Pengjie Zhang @ 2026-07-01 12:01 UTC (permalink / raw)
To: Beata Michalska
Cc: catalin.marinas, will, rafael, lenb, robert.moore, zhenglifeng1,
zhanjie9, sumitg, cuiyunhui, linux-arm-kernel, linux-kernel,
linux-acpi, acpica-devel, linuxarm, jonathan.cameron, prime.zeng,
wanghuiqiang, xuwei5, lihuisong, yubowen8, wangzhi12
In-Reply-To: <akNyNKSGf5yKwtwN@arm.com>
Hi Beata,
Thanks for taking the time to review this patch.
Please see my inline comments below.
On 6/30/2026 3:37 PM, Beata Michalska wrote:
> Gonna be a bit picky with wording so do bear with me ...
>
> On Fri, Apr 10, 2026 at 05:41:44PM +0800, Pengjie Zhang wrote:
>> cppc_get_perf_ctrs() reads the delivered and reference performance
>> counters one at a time.
>>
>> Allow architectures to provide both FFH feedback counters in one
>> operation when that either narrows the sampling window or avoids extra
>> cross-CPU reads. Add a small FFH-specific hook for that case and fall
>> back to the existing per-register reads when unsupported.
>>
>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>> ---
>> drivers/acpi/cppc_acpi.c | 58 ++++++++++++++++++++++++++++++++++++----
>> include/acpi/cppc_acpi.h | 7 +++++
>> 2 files changed, 60 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
>> index 2e91c5a97761..7b3e8b0597dc 100644
>> --- a/drivers/acpi/cppc_acpi.c
>> +++ b/drivers/acpi/cppc_acpi.c
>> @@ -988,6 +988,23 @@ int __weak cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val)
>> return -ENOTSUPP;
>> }
>>
>> +/**
>> + * cpc_read_ffh_fb_ctrs() - Read FFH feedback counters together
>> + * @cpunum: CPU number to read
> This reads bit awkward. Target CPU maybe ?
>> + * @reg1: first CPPC register information
>> + * @val1: place holder for first return value
>> + * @reg2: second CPPC register information
>> + * @val2: place holder for second return value
>> + *
>> + * Return: 0 for success and error code
> 0 on success, error code otherwise ?
Will update the wording as suggested.
>> + */
>> +int __weak cpc_read_ffh_fb_ctrs(int cpunum, struct cpc_reg *reg1,
>> + u64 *val1, struct cpc_reg *reg2, u64 *val2)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +
>> /**
>> * cpc_write_ffh() - Write FFH register
>> * @cpunum: CPU number to write
>> @@ -1504,6 +1521,40 @@ bool cppc_perf_ctrs_in_pcc(void)
>> }
>> EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
>>
>> +static int cppc_read_perf_fb_ctrs(int cpunum,
>> + struct cpc_register_resource *delivered_reg,
>> + struct cpc_register_resource *reference_reg,
>> + u64 *delivered, u64 *reference)
> The signature here differs from cpc_read_ffh_fb_ctrs.
> It's not an issue but it might be good idea to stay consistent maybe ?
> Also ... was about to suggest to stick to either perf_ctrs or feedback_ctrs
> in naming but it seems the is no clear pattern withint the file
> ...
You're right about the mixed naming.
I will use the _fb_ctrs suffix for all new functions in v2.
>> +{
>> + int ret;
>> +
>> + /*
>> + * For FFH feedback counters, try a paired read first to reduce
>> + * sampling skew between delivered and reference counters. Fall
>> + * back to the existing per-register reads if unsupported.
>> + */
>> + if (CPC_IN_FFH(delivered_reg) && CPC_IN_FFH(reference_reg)) {
>> + ret = cpc_read_ffh_fb_ctrs(cpunum,
>> + &delivered_reg->cpc_entry.reg, delivered,
>> + &reference_reg->cpc_entry.reg, reference);
>> + if (!ret)
>> + return 0;
>> +
>> + if (ret != -EOPNOTSUPP)
>> + return ret;
> Shouldn't this one be enough ? Don't think you need the first condition.
right，I will drop the redundant if (!ret) check in v2
>> + }
>> +
>> + ret = cpc_read(cpunum, delivered_reg, delivered);
>> + if (ret)
>> + return ret;
>> +
>> + ret = cpc_read(cpunum, reference_reg, reference);
>> + if (ret)
>> + return ret;
> As you are not doing anything with 'ret' this could just be:
> ret = cpc_read(cpunum, delivered_reg, delivered);
> if (ret) return ret;
> return cpc_read(cpunum, reference_reg, reference);
>
> Though that's minor.
Good catch, this is much cleaner. I will apply this change.
Thanks again for the constructive feedback!
Best regards,
Pengjie
>
> ---
> BR
> Beata
>> +
>> + return 0;
>> +}
>> +
>> /**
>> * cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
>> * @cpunum: CPU from which to read counters.
>> @@ -1547,11 +1598,8 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
>> }
>> }
>>
>> - ret = cpc_read(cpunum, delivered_reg, &delivered);
>> - if (ret)
>> - goto out_err;
>> -
>> - ret = cpc_read(cpunum, reference_reg, &reference);
>> + ret = cppc_read_perf_fb_ctrs(cpunum, delivered_reg, reference_reg,
>> + &delivered, &reference);
>> if (ret)
>> goto out_err;
>>
>> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
>> index d1f02ceec4f9..006b42dbbd4b 100644
>> --- a/include/acpi/cppc_acpi.h
>> +++ b/include/acpi/cppc_acpi.h
>> @@ -172,6 +172,8 @@ extern int cppc_get_transition_latency(int cpu);
>> extern bool cpc_ffh_supported(void);
>> extern bool cpc_supported_by_cpu(void);
>> extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
>> +extern int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
>> + struct cpc_reg *reg2, u64 *val2);
>> extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
>> extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
>> extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable);
>> @@ -246,6 +248,11 @@ static inline int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val)
>> {
>> return -EOPNOTSUPP;
>> }
>> +static inline int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
>> + struct cpc_reg *reg2, u64 *val2)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> static inline int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
>> {
>> return -EOPNOTSUPP;
>> --
>> 2.33.0
>>
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-07-01 11:42 UTC (permalink / raw)
To: Andy Shevchenko, Andy Shevchenko
Cc: Linus Walleij, Bartosz Golaszewski, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
wbg@kernel.org, mathieu.dubois-briand@bootlin.com,
lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <akT8Niv1ddo-uWmc@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 3418 bytes --]
On Wed Jul 1, 2026 at 1:38 PM CEST, Andy Shevchenko wrote:
> On Wed, Jul 01, 2026 at 01:55:11PM +0300, Andy Shevchenko wrote:
>> On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
>> > On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle@kernel.org> wrote:
>> > > On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
>> > > > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
>> > > >
>> > > >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
>> > > >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
>> > > >> >>> map() function.
>> > > >>
>> > > >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
>> > > >> only called if the irq handling is set up via gc->irq.chip and not
>> > > >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
>> > > >
>> > > > Not really, the gpiochip_irq_reqres() is called to mark that a
>> > > > GPIO line is used for IRQ, so the gpiolib cannot turn this
>> > > > GPIO into an output line, gpiod_direction_out() will fail
>> > > > on lines used for IRQ. So it's a failsafe.
>> > > >
>> > > > You can live without it of course, but then you don't get
>> > > > this failsafe.
>> > >
>> > > Thanks for the explanation! So did I make a mistake years ago by
>> > > adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
>> > > ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
>> > >
>> > > As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
>> > > to be a gpio_chip, which isn't the case (in general) for an
>> > > externally allocated domain, is it?
>> >
>> > So the whole issue comes from the fact that the IRQ chip is not marked
>> > as immutable. For immutable IRQ chips (which all GPIO provides should
>> > have) there is no such issue to begin with, id est there is no
>> > gpiochip_irq_reqres() callback assigned (and respective _relres).
>>
>> Ah, for immutable chips we put either custom ones or
>> GPIOCHIP_IRQ_RESOURCE_HELPERS which actually refers to those callbacks.
>>
>> So, if the domain is external, it should also provide irq_request_resources
>> and release callbacks. In the custom case we can wrap gpiochip_reqres_irq()
>> and gpiochip_relres_irq() respectively.
>>
>> But we need to have a struct gpio_chip pointer for them. And note, the
>> IRQ chip data can be anything in that case, so it's not a requirement.
>
> And looking back for implementation in v3 the whole mistake was to use
> GPIOCHIP_IRQ_RESOURCE_HELPERS. It just wanted custom callbacks with
> the IRQ chip data assigned to whatever from which we may then deduce
> struct gpio_chip. It does *not* require to be struct gpio_chip.
> The local driver data structure should keep pointer to struct gpio_regmap.
> That one can be used in the respective .irq_request_resources() and
> .irq_release_resources(). The default ones for gpio-regmap may also
> be provided via a macro, say GPIO_REGMAP_IRQ_RESOURCE_HELPERS.
>
> Hence I don't see the need of having gpio_regmap_get_gpiochip() helper
> and driver can be implemented using gpio-regmap and external IRQ domain.
>
> What did I miss?
IMHO nothing, that's exactly my understanding, too. Except for the
GPIO_REGMAP_IRQ_RESOURCE_HELPERS. See my previous mail. Because that
would have to be set by regmap-irq.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-07-01 11:38 UTC (permalink / raw)
To: Andy Shevchenko, Andy Shevchenko
Cc: Linus Walleij, Bartosz Golaszewski, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
wbg@kernel.org, mathieu.dubois-briand@bootlin.com,
lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <akTyDzdrt949VnWK@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]
On Wed Jul 1, 2026 at 12:55 PM CEST, Andy Shevchenko wrote:
> On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
>> On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle@kernel.org> wrote:
>> > On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
>> > > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
>> > >
>> > >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
>> > >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
>> > >> >>> map() function.
>> > >>
>> > >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
>> > >> only called if the irq handling is set up via gc->irq.chip and not
>> > >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
>> > >
>> > > Not really, the gpiochip_irq_reqres() is called to mark that a
>> > > GPIO line is used for IRQ, so the gpiolib cannot turn this
>> > > GPIO into an output line, gpiod_direction_out() will fail
>> > > on lines used for IRQ. So it's a failsafe.
>> > >
>> > > You can live without it of course, but then you don't get
>> > > this failsafe.
>> >
>> > Thanks for the explanation! So did I make a mistake years ago by
>> > adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
>> > ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
>> >
>> > As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
>> > to be a gpio_chip, which isn't the case (in general) for an
>> > externally allocated domain, is it?
>>
>> So the whole issue comes from the fact that the IRQ chip is not marked
>> as immutable. For immutable IRQ chips (which all GPIO provides should
>> have) there is no such issue to begin with, id est there is no
>> gpiochip_irq_reqres() callback assigned (and respective _relres).
>
> Ah, for immutable chips we put either custom ones or
> GPIOCHIP_IRQ_RESOURCE_HELPERS which actually refers to those callbacks.
>
> So, if the domain is external, it should also provide irq_request_resources
> and release callbacks. In the custom case we can wrap gpiochip_reqres_irq()
> and gpiochip_relres_irq() respectively.
Exactly. And its seems that this should have been possible with this
series, too.
Apart from that, most drivers use regmap-irq with gpio-regmap. For
this we'd probably have to add something to regmap-irq because that
module owns the irq_chip.
> But we need to have a struct gpio_chip pointer for them. And note, the
> IRQ chip data can be anything in that case, so it's not a requirement.
That's what I've meant. Conceptionally, it should be part of
gpiochip_irqchip_add_domain()/gpiolib, so a user doesn't have to
have that knowledge. But I don't see how this could be achieved.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-07-01 11:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Michael Walle, Linus Walleij, Bartosz Golaszewski,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <akTyDzdrt949VnWK@ashevche-desk.local>
On Wed, Jul 01, 2026 at 01:55:11PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
> > On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle@kernel.org> wrote:
> > > On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
> > > > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
> > > >
> > > >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> > > >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> > > >> >>> map() function.
> > > >>
> > > >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
> > > >> only called if the irq handling is set up via gc->irq.chip and not
> > > >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
> > > >
> > > > Not really, the gpiochip_irq_reqres() is called to mark that a
> > > > GPIO line is used for IRQ, so the gpiolib cannot turn this
> > > > GPIO into an output line, gpiod_direction_out() will fail
> > > > on lines used for IRQ. So it's a failsafe.
> > > >
> > > > You can live without it of course, but then you don't get
> > > > this failsafe.
> > >
> > > Thanks for the explanation! So did I make a mistake years ago by
> > > adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
> > > ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
> > >
> > > As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
> > > to be a gpio_chip, which isn't the case (in general) for an
> > > externally allocated domain, is it?
> >
> > So the whole issue comes from the fact that the IRQ chip is not marked
> > as immutable. For immutable IRQ chips (which all GPIO provides should
> > have) there is no such issue to begin with, id est there is no
> > gpiochip_irq_reqres() callback assigned (and respective _relres).
>
> Ah, for immutable chips we put either custom ones or
> GPIOCHIP_IRQ_RESOURCE_HELPERS which actually refers to those callbacks.
>
> So, if the domain is external, it should also provide irq_request_resources
> and release callbacks. In the custom case we can wrap gpiochip_reqres_irq()
> and gpiochip_relres_irq() respectively.
>
> But we need to have a struct gpio_chip pointer for them. And note, the
> IRQ chip data can be anything in that case, so it's not a requirement.
And looking back for implementation in v3 the whole mistake was to use
GPIOCHIP_IRQ_RESOURCE_HELPERS. It just wanted custom callbacks with
the IRQ chip data assigned to whatever from which we may then deduce
struct gpio_chip. It does *not* require to be struct gpio_chip.
The local driver data structure should keep pointer to struct gpio_regmap.
That one can be used in the respective .irq_request_resources() and
.irq_release_resources(). The default ones for gpio-regmap may also
be provided via a macro, say GPIO_REGMAP_IRQ_RESOURCE_HELPERS.
Hence I don't see the need of having gpio_regmap_get_gpiochip() helper
and driver can be implemented using gpio-regmap and external IRQ domain.
What did I miss?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net] net: ti: icssg-prueth: Fix link-local addresses being forwarded out of slave ports
From: MD Danish Anwar @ 2026-07-01 11:25 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Meghana Malladi
Cc: linux-arm-kernel, netdev, linux-kernel, danishanwar
Link-local multicast addresses (01:80:c2:00:00:0x) must only be
delivered to the host port (P0) and must not be forwarded out of
the physical slave ports. icssg_fdb_add_del() was programming these
addresses with P1/P2 membership bits set, causing the firmware to
forward them out of slave ports.
Clear P1/P2 membership and set only P0 membership when
is_link_local_ether_addr() returns true.
Fixes: 487f7323f39a ("net: ti: icssg-prueth: Add helper functions to configure FDB")
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
drivers/net/ethernet/ti/icssg/icssg_config.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/ti/icssg/icssg_config.c b/drivers/net/ethernet/ti/icssg/icssg_config.c
index 3f8237c17d099..04a81402e3f3c 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_config.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_config.c
@@ -732,6 +732,16 @@ int icssg_fdb_add_del(struct prueth_emac *emac, const unsigned char *addr,
u8 fid = vid;
int ret;
+ /* Link-local addresses (01:80:c2:00:00:0x) must only be delivered to
+ * the host port (P0). Clear P1/P2 membership to prevent the firmware
+ * from forwarding them out of the physical slave ports.
+ */
+ if (is_link_local_ether_addr(addr)) {
+ fid_c2 |= ICSSG_FDB_ENTRY_P0_MEMBERSHIP;
+ fid_c2 &= ~(ICSSG_FDB_ENTRY_P1_MEMBERSHIP |
+ ICSSG_FDB_ENTRY_P2_MEMBERSHIP);
+ }
+
icssg_fdb_setup(emac, &fdb_cmd, addr, fid, add ? ICSS_CMD_ADD_FDB : ICSS_CMD_DEL_FDB);
fid_c2 |= ICSSG_FDB_ENTRY_VALID;
base-commit: a225f8c20712713406ae47024b8df42deacddd4a
--
2.34.1
^ permalink raw reply related
* [PATCH] media: rkvdec: Propagate platform_get_irq() errors
From: Narasimharao Vadlamudi @ 2026-07-01 11:12 UTC (permalink / raw)
To: Detlev Casanova
Cc: Ezequiel Garcia, Mauro Carvalho Chehab, Heiko Stuebner,
Hans Verkuil, Boris Brezillon, linux-media, linux-rockchip,
linux-arm-kernel, linux-kernel, Narasimharao Vadlamudi
platform_get_irq() returns a positive IRQ number on success and a
negative error code on failure. It no longer returns zero. The driver
currently returns -ENXIO for all failures, which loses useful errors
such as -EPROBE_DEFER.
Return the error from platform_get_irq() directly.
Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Narasimharao Vadlamudi <ahmisaranrao@gmail.com>
---
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
index 1d1e9bfef8e9..37683a6bb40f 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
@@ -1818,8 +1818,8 @@ static int rkvdec_probe(struct platform_device *pdev)
vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
irq = platform_get_irq(pdev, 0);
- if (irq <= 0)
- return -ENXIO;
+ if (irq < 0)
+ return irq;
ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
rkvdec_irq_handler, IRQF_ONESHOT,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] ARM: breakpoint: CFI breakpoints only on demand
From: Russell King @ 2026-07-01 11:10 UTC (permalink / raw)
To: Linus Walleij
Cc: Nathan Chancellor, Sami Tolvanen, Kees Cook, linux-arm-kernel,
linux-kernel, stable, slipher
In-Reply-To: <20260701-arm32-cfi-bug-v3-1-e3c37e2b80a4@kernel.org>
On Wed, Jul 01, 2026 at 12:42:09PM +0200, Linus Walleij wrote:
> This removes the stub hw_breakpoint_cfi_handler() from ARM, making
> it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless
> CFI is actively used in the kernel.
>
> When not instrumenting with CFI, we fall through to return 1 from
> hw_breakpoint_pending() "unhandled fault" so userspace can make use
> of this breakpoint.
>
> This of course does not work if userspace want to use CFI and custom
> breakpoints at the same time, and CONFIG_CFI does exist as something
> users might want to select for their kernel. If this is not good
> acceptable we need to think about other ways for CFI to interfer, such
> as not using BKPT at all (rather something like BUG()) and back out
> the offending patch until the compiler behaviour has changed.
>
> Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints")
> Reported-by: slipher <slipher@protonmail.com>
> Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
> Trying to solve the CFI bug. Let's see of this first
> approach is acceptable for the reporter.
Looks fine to me, but will depend whether the reporter has CONFIG_CFI
enabled in their kernel build.
Have the LLVM compiler people responded to this bug yet? What is their
plan with the silly choice of BKPT usage for CFI failure?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 2/3] can: rockchip: add RK3588 CAN-FD support
From: Marc Kleine-Budde @ 2026-07-01 11:07 UTC (permalink / raw)
To: Heiko Stübner
Cc: linux-can, 1579567540, Vincent Mailhol, kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <2064877.jZfb76A358@diego>
[-- Attachment #1: Type: text/plain, Size: 3951 bytes --]
On 01.07.2026 11:55:39, Heiko Stübner wrote:
> Hi,
>
> Am Mittwoch, 1. Juli 2026, 09:01:27 Mitteleuropäische Sommerzeit schrieb 1579567540@qq.com:
> > From: luch00 <1579567540@qq.com>
>
> please use a real name, not an alias.
>
>
> > Add support for the RK3588v2 CAN-FD controller by introducing a
> > dedicated model ID and OF match entry.
> >
> > The block is closely related to the existing RK3568 variants, but it
> > cannot reuse their match data unchanged. In particular, RK3588v2
> > encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
> > SoC-specific handling.
> >
> > Validation on RK3588v2 also shows that its observed errata profile does
> > not fully match rk3568v2/rk3568v3, so keep a dedicated devtype for this
> > variant instead of relying on an rk3568 fallback.
>
> Funnily enough, we seem to have worked on the same topic
> at the same time :-)
>
> https://lore.kernel.org/lkml/20260630164336.3444550-1-heiko@sntech.de/
>
> > Signed-off-by: luch00 <1579567540@qq.com>
> > ---
> > drivers/net/can/rockchip/rockchip_canfd-core.c | 14 ++++++++++++++
> > drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++++-
> > drivers/net/can/rockchip/rockchip_canfd.h | 12 +++++++++++-
> > 3 files changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
> > index 29de0c01e..3c2480785 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd-core.c
> > +++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
> > @@ -50,6 +50,15 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
> > RKCANFD_QUIRK_CANFD_BROKEN,
> > };
> >
> > +/* Tests on the rk3588v2 reproduce Erratum 5, but not
> > + * Erratum 6 or the special CAN-FD frames that trigger Error Interrupts
> > + * on rk3568v2/rk3568v3.
> > + */
>
> Here I could reproduce erratum 6 though:
> https://lore.kernel.org/lkml/20260630164336.3444550-4-heiko@sntech.de/
>
>
> [...]
>
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > index 475c0409e..fe64db373 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > +++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > @@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
> > {
> > const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
> >
> > - return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
> > + if (priv->devtype_data.model == RKCANFD_MODEL_RK3588V2)
> > + return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
> > +
> > + return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
> > }
> >
> > int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
> > index 93131c7d7..f6105b904 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd.h
> > +++ b/drivers/net/can/rockchip/rockchip_canfd.h
> > @@ -214,7 +214,8 @@
> > #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
> >
> > #define RKCANFD_REG_RX_FIFO_CTRL 0x118
> > -#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
> > +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
> > +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
>
> Oh, didn't see this when doing my variant of the support, so cool that you
> found this.
The "Rockchip RK3588 TRM V1.0-Part1-20220309.pdf" datasheet says bits
"7:5" are RX_FIFO_FRAME_CNT, while bit "6" is marked as reserved. 🤷
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Linus Walleij @ 2026-07-01 11:04 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君]
Cc: brgl@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, mwalle@kernel.org,
andriy.shevchenko@intel.com, TY_Chang[張子逸],
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], Krzysztof Kozlowski
In-Reply-To: <56be68cba7d9461d9a1ec66ed1a1417a@realtek.com>
On Wed, Jul 1, 2026 at 12:41 PM Yu-Chun Lin [林祐君]
<eleanor.lin@realtek.com> wrote:
> To clarify the hardware design: this SoC does not use a banked GPIO
> architecture.
>
> Each GPIO pin has its own dedicated 32-bit control register that handles
> both GPIO configuration and interrupt settings (e.g., edge/level enable).
> The only exception is the interrupt status register, which is grouped into
> 32-bit words.
Aha, I get it!
> Since physical GPIO banks do not exist, using a 3-cell <bank offset flags>
> format would misrepresent the hardware. Therefore,
> keeping #gpio-cells = <2> and #interrupt-cells = <2> is the most accurate
> reflection of the actual silicon.
Hmmmm I would argue that the way the interrupts are routed into a
single 32-bit register for 32 GPIOs would be an argument for using
#interrupt-cells = <3> but it would be confusing to use a mixture of
2 and 3 cells for GPIOs and interrupts, so I guess 2 is OK for both.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Konrad Dybcio @ 2026-07-01 11:02 UTC (permalink / raw)
To: Jie Gan, Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, linux-arm-msm,
devicetree, linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <62ac6887-1551-490b-b42b-2661d7152734@oss.qualcomm.com>
On 7/1/26 9:31 AM, Jie Gan wrote:
>
>
> On 7/1/2026 3:26 PM, Krzysztof Kozlowski wrote:
>> On 01/07/2026 09:16, Jie Gan wrote:
>>>
>>>
>>> On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
>>>> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>>>>> The TNOC compatible previously only allowed the two-string AMBA form
>>>>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>>>>> AMBA bus.
>>>>>
>>>>> Convert the compatible to a oneOf and add a standalone
>>>>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>>>>> standalone string carries no "arm,primecell" entry, so the device is
>>>>> created on the platform bus instead of the AMBA bus.
[...]
>>> AMBA primecell identification. The purpose of the new compatible is to
>>> clearly distinguish this platform-specific case from the standard
>>> AMBA-based implementation. Or shall I re-use the existing compatible
>>> "qcom,coresight-tnoc" as platform standalone compatible?
>>>
>>> We already have a similar pattern for the interconnect TraceNoC device,
>>> which uses the platform-specific compatible string qcom,coresight-itnoc.
>> I do not see there a fake, duplicated compatible for the same device.
>> Can you elaborate how is that relevant?
>
> Will fix it by removing AMBA related description.
>
> Shall I update the clock name from apb_pclk to apb as a platform device?
Why?
Konrad
^ permalink raw reply
* Re: [PATCH v4 0/3] regulator: Rework i2c_device_id initialisation
From: Mark Brown @ 2026-06-30 22:40 UTC (permalink / raw)
To: Liam Girdwood, Woodrow Douglass, Michael Hennerich,
Support Opensource, Laurent Pinchart, Ivaylo Ivanov,
Claudiu Beznea, Andrei Simion, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Jagan Teki, Icenowy Zheng,
Alexis Czezar Torreno, Uwe Kleine-König (The Capable Hub)
Cc: linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1782827697.git.u.kleine-koenig@baylibre.com>
On Tue, 30 Jun 2026 16:01:06 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> regulator: Rework i2c_device_id initialisation
>
> Hello,
>
> changes since v2
> (https://lore.kernel.org/lkml/cover.1781888370.git.u.kleine-koenig@baylibre.com):
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.3
Thanks!
[1/3] regulator: Drop unused i2c driver data
https://git.kernel.org/broonie/regulator/c/3ac69e3cb288
[2/3] regulator: Use named initializers for arrays of i2c_device_data
https://git.kernel.org/broonie/regulator/c/8e74b2db5867
[3/3] regulator: Improve style of i2c_device_id arrays
https://git.kernel.org/broonie/regulator/c/2924fa8381ee
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v5 8/8] futex: Use runtime constants for __futex_hash() hot path
From: Sebastian Andrzej Siewior @ 2026-07-01 11:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: K Prateek Nayak, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Catalin Marinas, Will Deacon,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Darren Hart, Davidlohr Bueso,
André Almeida, linux-arch, linux-kernel, Samuel Holland,
Charlie Jenkins, linux-arm-kernel, linux-riscv, linux-s390,
H. Peter Anvin, Thomas Huth, Sean Christopherson, Jisheng Zhang,
Alexandre Ghiti, Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260701084150.GNOeboLw@linutronix.de>
On 2026-07-01 10:41:55 [+0200], To Peter Zijlstra wrote:
> This makes it go away at no extra price but yeah let me boot a big box
> and see.
as-is:
|$ ./perf bench futex hash -f 1 -t 1 -r 10 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 3588]: 1 threads, each operating on 1 [private] futexes for 10 secs.
|
| [thread 0] futex: 0x5555e5ad4740 [ 6449632 ops/sec ]
|
| Averaged 6449632 operations/sec (+- 0,00%), total secs = 10
| Futex hashing: global hash
roughly that area, repeated runs usually change the last three digits.
Patched:
| $ ./perf bench futex hash -f 1 -t 1 -r 10 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 2375]: 1 threads, each operating on 1 [private] futexes for 10 secs.
|
| [thread 0] futex: 0x5585ddebd740 [ 6532004 ops/sec ]
|
| Averaged 6532004 operations/sec (+- 0,00%), total secs = 10
| Futex hashing: global hash
for private hash there is change within the noise area for -b 8192.
So we have here +1.28% ops/sec. Not ground breaking, not bad either.
With more threads:
| $ ./perf bench futex hash -r 30 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 2424]: 144 threads, each operating on 1024 [private] futexes for 30 secs.
|
| [thread 0] futexes: 0x556f3a3387c0 ... 0x556f3a3397bc [ 2104422 ops/sec ]
…
| [thread 143] futexes: 0x556f3a3d9660 ... 0x556f3a3da65c [ 2105480 ops/sec ]
|
| Averaged 2111486 operations/sec (+- 0,03%), total secs = 30
| Futex hashing: global hash
To:
| $ ./perf bench futex hash -r 30 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 2723]: 144 threads, each operating on 1024 [private] futexes for 30 secs.
|
|[thread 0] futexes: 0x560a09e487c0 ... 0x560a09e497bc [ 2135688 ops/sec ]
…
|[thread 143] futexes: 0x560a09ee9660 ... 0x560a09eea65c [ 2137668 ops/sec ]
|
| Averaged 2139685 operations/sec (+- 0,03%), total secs = 30
| Futex hashing: global hash
+1.34%. Again, not ground breaking but still visible. And the memory
savings.
That is btw, 7.2-rc1 on a Intel(R) Xeon(R) CPU E7-8890 v3 (4 NUMA
nodes).
Sebastian
^ permalink raw reply
* [PATCH RESEND v3] drm/rockchip: Remove dependency on DRM simple helpers
From: Diogo Silva @ 2026-07-01 10:59 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan
Cc: Thomas Zimmermann, linux-kernel, linux-rockchip, linux-arm-kernel,
dri-devel, Simona Vetter, David Airlie, Maxime Ripard,
Maarten Lankhorst
In-Reply-To: <20260608124018.480365-2-diogompaissilva@gmail.com>
Simple KMS helper are deprecated since they only add an intermediate
layer between drivers and the atomic modesetting.
This patch removes the dependency on drm simple helpers from rockchip
DRM drivers.
Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
---
Resending just in case this was missed. Thanks.
v3:
- rebase on drm-tip tree
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 ++++++---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 ++++++---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 9 +++++++--
drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c | 8 ++++++--
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 1 -
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 1 -
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 ++++++--
drivers/gpu/drm/rockchip/rockchip_lvds.c | 9 +++++++--
drivers/gpu/drm/rockchip/rockchip_rgb.c | 8 ++++++--
10 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 776954c7d052..46c245e35d21 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -30,7 +30,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
@@ -303,6 +302,10 @@ rockchip_dp_drm_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
rockchip_dp_encoder_helper_funcs = {
.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
.mode_set = rockchip_dp_drm_encoder_mode_set,
@@ -361,8 +364,8 @@ static int rockchip_dp_drm_create_encoder(struct
rockchip_dp_device *dp)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_simple_encoder_init(drm_dev, encoder,
- DRM_MODE_ENCODER_TMDS);
+ ret = drm_encoder_init(drm_dev, encoder, &rockchip_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 190cce9530c8..c3f41a4449f5 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -23,7 +23,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "cdn-dp-core.h"
#include "cdn-dp-reg.h"
@@ -671,6 +670,10 @@ static int cdn_dp_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs cdn_dp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs cdn_dp_encoder_helper_funcs = {
.atomic_check = cdn_dp_encoder_atomic_check,
};
@@ -988,8 +991,8 @@ static int cdn_dp_bind(struct device *dev, struct
device *master, void *data)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_simple_encoder_init(drm_dev, encoder,
- DRM_MODE_ENCODER_TMDS);
+ ret = drm_encoder_init(drm_dev, encoder, &cdn_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 3547d91b25d3..a09b382d208e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -25,7 +25,6 @@
#include <drm/drm_mipi_dsi.h>
#include <drm/drm_of.h>
#include <drm/drm_print.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
@@ -825,6 +824,10 @@ static void dw_mipi_dsi_encoder_enable(struct
drm_encoder *encoder)
clk_disable_unprepare(dsi->grf_clk);
}
+static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
@@ -840,7 +843,9 @@ static int rockchip_dsi_drm_create_encoder(struct
dw_mipi_dsi_rockchip *dsi,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dsi->dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
+ ret = drm_encoder_init(drm_dev, encoder,
+ &dw_mipi_dsi_encoder_funcs,
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
DRM_ERROR("Failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
index d2e76d36d724..9dc207c2d20d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
@@ -23,7 +23,6 @@
#include <drm/bridge/dw_mipi_dsi2.h>
#include <drm/drm_mipi_dsi.h>
#include <drm/drm_of.h>
-#include <drm/drm_simple_kms_helper.h>
#include <uapi/linux/videodev2.h>
@@ -275,6 +274,10 @@ dw_mipi_dsi2_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs dw_mipi_dsi2_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
dw_mipi_dsi2_encoder_helper_funcs = {
.atomic_enable = dw_mipi_dsi2_encoder_atomic_enable,
@@ -290,7 +293,8 @@ static int rockchip_dsi2_drm_create_encoder(struct
dw_mipi_dsi2_rockchip *dsi2,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dsi2->dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
+ ret = drm_encoder_init(drm_dev, encoder, &dw_mipi_dsi2_encoder_funcs,
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
dev_err(dsi2->dev, "Failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
index 0de822360c8d..b23efb153c9e 100644
--- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
@@ -20,7 +20,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index cffc0af5190f..b6e154c35e7c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -18,7 +18,6 @@
#include <drm/drm_managed.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
index f35484715c2d..af34062685cd 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
@@ -24,7 +24,6 @@
#include <drm/drm_managed.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 1996f8656612..b4ba9f894360 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -12,7 +12,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include <linux/clk.h>
#include <linux/mfd/syscon.h>
@@ -454,6 +453,10 @@ rk3066_hdmi_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rk3066_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rk3066_hdmi_encoder_helper_funcs = {
.atomic_check = rk3066_hdmi_encoder_atomic_check,
@@ -696,7 +699,8 @@ rk3066_hdmi_register(struct drm_device *drm,
struct rk3066_hdmi *hdmi)
return -EPROBE_DEFER;
drm_encoder_helper_add(encoder, &rk3066_hdmi_encoder_helper_funcs);
- drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(drm, encoder, &rk3066_hdmi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = &rk3066_hdmi_bridge_funcs;
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 7a0c4fa29f2f..f3be2c91d147 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -24,7 +24,6 @@
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
#include "rockchip_lvds.h"
@@ -427,6 +426,10 @@ static void px30_lvds_encoder_disable(struct
drm_encoder *encoder)
drm_panel_unprepare(lvds->panel);
}
+static const struct drm_encoder_funcs rockchip_lvds_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rk3288_lvds_encoder_helper_funcs = {
.enable = rk3288_lvds_encoder_enable,
@@ -594,7 +597,9 @@ static int rockchip_lvds_bind(struct device *dev,
struct device *master,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_LVDS);
+ ret = drm_encoder_init(drm_dev, encoder,
+ &rockchip_lvds_encoder_funcs,
+ DRM_MODE_ENCODER_LVDS, NULL);
if (ret < 0) {
drm_err(drm_dev,
"failed to initialize encoder: %d\n", ret);
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
index add3123e5ce7..2ad24b914989 100644
--- a/drivers/gpu/drm/rockchip/rockchip_rgb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -17,7 +17,6 @@
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
#include "rockchip_rgb.h"
@@ -65,6 +64,10 @@ rockchip_rgb_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rockchip_rgb_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rockchip_rgb_encoder_helper_funcs = {
.atomic_check = rockchip_rgb_encoder_atomic_check,
@@ -127,7 +130,8 @@ struct rockchip_rgb *rockchip_rgb_init(struct device *dev,
encoder = &rgb->encoder.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_NONE);
+ ret = drm_encoder_init(drm_dev, encoder, &rockchip_rgb_encoder_funcs,
+ DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0) {
DRM_DEV_ERROR(drm_dev->dev,
"failed to initialize encoder: %d\n", ret);
--
2.51.2
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: rockchip: pmu: Narrow definition of reboot-mode
From: Krzysztof Kozlowski @ 2026-07-01 10:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Elaine Zhang, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Cc: Krzysztof Kozlowski
The 'reboot-mode' child of PMU node must be a syscon-reboot-mode one, so
add missing $ref to enforce the validation and disallow other
reboot-mode handlers.
Defining 'type: object' is on the other hand not necessary when other
schema is referenced.
This can be further restricted to match hardware/firmware:
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only
a subset actually makes sense and is valid. Provide negative look-ahead
pattern to disallow any modes not supported by the device, which
tightens the binding.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/rockchip/pmu.yaml | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
index 55b2200d6e75..1cff2328cd01 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -61,7 +61,13 @@ properties:
type: object
reboot-mode:
- type: object
+ $ref: /schemas/power/reset/syscon-reboot-mode.yaml
+ unevaluatedProperties: false
+
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|loader$|normal$|recovery$))": false
required:
- compatible
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: rockchip: grf: Narrow allowed reboot modes
From: Krzysztof Kozlowski @ 2026-07-01 10:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Elaine Zhang, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260701105849.197086-3-krzysztof.kozlowski@oss.qualcomm.com>
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only
a subset actually makes sense and is valid. Provide negative look-ahead
pattern to disallow any modes not supported by the device, which
tightens the binding.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 2cc43742b8e3..7bcb4e2f47ec 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -239,11 +239,14 @@ allOf:
properties:
reboot-mode:
type: object
-
$ref: /schemas/power/reset/syscon-reboot-mode.yaml#
-
unevaluatedProperties: false
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|fastboot$|loader$|normal$|recovery$))": false
+
- if:
properties:
compatible:
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: samsung: exynos-pmu: Narrow allowed reboot modes
From: Krzysztof Kozlowski @ 2026-07-01 10:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Peter Griffin,
Alim Akhtar, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260701105731.196618-3-krzysztof.kozlowski@oss.qualcomm.com>
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only
a subset actually makes sense and is valid. Provide negative look-ahead
pattern to disallow any modes not supported by the device, which
tightens the binding.
Most of Android-based Exynos devices share the bootloader or its parts,
thus reboot modes are most likely the same, however only a few upstream
DTS define them, so add restrictions only for these.
Google GS101 has on the other hand quite different bootloader with many
known reboot modes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/soc/samsung/exynos-pmu.yaml | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index d124f3ae9fbd..5bd39876e3b3 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -176,6 +176,20 @@ allOf:
properties:
dp-phy: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos7-pmu
+ then:
+ properties:
+ reboot-mode:
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|download$|fastboot$|recovery$))": false
+
- if:
properties:
compatible:
@@ -183,6 +197,13 @@ allOf:
enum:
- google,gs101-pmu
then:
+ properties:
+ reboot-mode:
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|charge$|dm-verity-device-corrupted$|fastboot$|reboot-ab-update$|recovery$)|rescue$|shutdown-thermal$|shutdown-thermal-battery$)": false
+
required:
- google,pmu-intr-gen-syscon
else:
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox