* Re: [PATCH v11 0/9] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: Lee Jones @ 2026-03-26 9:25 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: AngeloGioacchino Del Regno, linux-mediatek, robh, krzk+dt,
conor+dt, matthias.bgg, lgirdwood, broonie, devicetree,
linux-kernel, linux-arm-kernel, kernel, igor.belwon
In-Reply-To: <20260326053449.GA910813@google.com>
On Thu, 26 Mar 2026, Chen-Yu Tsai wrote:
> On Fri, Nov 07, 2025 at 10:01:56AM +0100, AngeloGioacchino Del Regno wrote:
> > Il 06/11/25 17:11, Lee Jones ha scritto:
> > > On Mon, 27 Oct 2025, AngeloGioacchino Del Regno wrote:
> > >
> > > > Changes in v11:
> > > > - Removed unnecessary #address-cells in all mt6316 bindings
> > > >
> > > > Changes in v10:
> > > > - Added "struct" prefix to structs kerneldoc
> > > > - Renamed struct mtk_spmi_pmic_pdata to mtk_spmi_pmic_variant
> > > > - Added "REG_" to MT6363/73 mfd register definitions to disambiguate
> > > > - Expanded MTK_SPMI_PMIC_IRQ_GROUP macro parameter names as suggested
> > > > - Some rewording of comments as suggested, addition of more comments
> > > > - Refactored IRQ domain handling due to deprecation of function
> > > > irq_domain_add_tree() to use the new irq_domain_create_tree()
> > > > - Fixed to use generic_handle_domain_irq_safe() to avoid races
> > > > - Added support for two interrupt cells in translation
> > > > - Removed .irq_lock() and .irq_unlock() in favor of lockdep classes
> > > > - Added support for handling PMICs without IRQ Group register for
> > > > upcoming MT6685 implementation
> > >
> > > The MFD part looks okay.
> > >
> > > Let me know when you have all the Acks and the set is ready to be merged.
> > >
> >
> >
> > Lee, the regulators part was picked by Mark, so I guess you can take the MFD part
> > through your tree.
> >
> > I'm not sure if you can also take patch [7/9] (auxadc binding), but it would be
> > great if you could, because there is an auxadc example in the mfd binding that
> > needs that commit in order to succeed the binding check.
>
> Friendly ping. You might want to resend the remaining patches. Looks
> like they are all ready to be merged?
This is an _old_ set.
Please rebase it onto today's -next branch and provide a [RESEND].
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 8/9] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Ronald Claveau @ 2026-03-26 9:23 UTC (permalink / raw)
To: Rob Herring
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, linux-arm-kernel, linux-amlogic, devicetree,
linux-kernel, linux-mmc, linux-wireless
In-Reply-To: <20260325170922.GA3822305-robh@kernel.org>
On 3/25/26 6:09 PM, Rob Herring wrote:
> On Wed, Mar 25, 2026 at 10:15:26AM +0100, Ronald Claveau wrote:
>> Add bcm43752 compatible with its bcm4329 compatible fallback.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> Missing Conor's ack.
>
Thanks for pointing that out, I will add it.
>> ---
>> Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
>> index 3be7576787644..81fd3e37452a6 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
>> @@ -42,6 +42,7 @@ properties:
>> - brcm,bcm4356-fmac
>> - brcm,bcm4359-fmac
>> - brcm,bcm4366-fmac
>> + - brcm,bcm43752-fmac
>> - cypress,cyw4373-fmac
>> - cypress,cyw43012-fmac
>> - infineon,cyw43439-fmac
>>
>> --
>> 2.49.0
>>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v4 3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
From: Ronald Claveau @ 2026-03-26 9:22 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Johannes Berg, van Spriel
In-Reply-To: <4b2ba22d-7d0b-4c71-ad83-46d198718fec@linaro.org>
On 3/26/26 9:52 AM, Neil Armstrong wrote:
> On 3/25/26 10:15, Ronald Claveau wrote:
>> Add device tree nodes for the three MMC controllers available
>> on the Amlogic T7 SoC, using amlogic,meson-axg-mmc as fallback
>> compatible.
>> All nodes are disabled by default and should be
>> enabled in the board-specific DTS file.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 39 +++++++++++++++++++
>> ++++++++++
>> 1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/
>> boot/dts/amlogic/amlogic-t7.dtsi
>> index 016b5429c8d1b..62c87d0ef7065 100644
>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> @@ -374,6 +374,45 @@ sec_ao: ao-secure@10220 {
>> reg = <0x0 0x10220 0x0 0x140>;
>> amlogic,has-chip-id;
>> };
>> +
>> + sd_emmc_a: mmc@88000 {
>> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
>> + reg = <0x0 0x88000 0x0 0x800>;
>> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
>> + status = "disabled";
>
> move disabled at the end of the properties
>
Thanks I will do.
>> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_A>,
>> + <&clkc_periphs CLKID_SD_EMMC_A>,
>> + <&scmi_clk CLKID_FCLK_DIV2>;
>> + clock-names = "core", "clkin0", "clkin1";
>> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
>> + assigned-clock-parents = <&xtal>;
>> + };
>> +
>> + sd_emmc_b: mmc@8a000 {
>> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
>> + reg = <0x0 0x8a000 0x0 0x800>;
>> + interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
>> + status = "disabled";
> Ditto
>
>> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_B>,
>> + <&clkc_periphs CLKID_SD_EMMC_B>,
>> + <&scmi_clk CLKID_FCLK_DIV2>;
>> + clock-names = "core", "clkin0", "clkin1";
>> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
>> + assigned-clock-parents = <&xtal>;
>> + };
>> +
>> + sd_emmc_c: mmc@8c000 {
>> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
>> + reg = <0x0 0x8c000 0x0 0x800>;
>> + interrupts = <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>;
>> + status = "disabled";
> Ditto
>> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_C>,
>> + <&clkc_periphs CLKID_SD_EMMC_C>,
>> + <&scmi_clk CLKID_FCLK_DIV2>;
>> + clock-names = "core", "clkin0", "clkin1";
>> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
>> + assigned-clock-parents = <&xtal>;
>> + };
>> };
>> };
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v4 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Ronald Claveau @ 2026-03-26 9:21 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Johannes Berg, van Spriel
In-Reply-To: <5298e691-99ba-48fc-874b-c9af308664ee@linaro.org>
On 3/26/26 9:52 AM, Neil Armstrong wrote:
> On 3/25/26 10:15, Ronald Claveau wrote:
>> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
>> to configure pin muxing at runtime.
>>
>> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
>> - SD card: data, clock, command and clock gate pins
>> - SDIO: data, clock, command and clock gate pins
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++
>> ++++++++++
>> 1 file changed, 98 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/
>> boot/dts/amlogic/amlogic-t7.dtsi
>> index 6510068bcff92..016b5429c8d1b 100644
>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> @@ -250,6 +250,104 @@ gpio: bank@4000 {
>> #gpio-cells = <2>;
>> gpio-ranges = <&periphs_pinctrl 0 0 157>;
>> };
>> +
>> + emmc_ctrl_pins: emmc-ctrl {
>> + mux-0 {
>> + groups = "emmc_cmd";
>> + function = "emmc";
>> + bias-pull-up;
>> + };
>> +
>> + mux-1 {
>> + groups = "emmc_clk";
>> + function = "emmc";
>> + bias-disable;
>> + };
>> + };
>> +
>> + emmc_data_4b_pins: emmc-data-4b {
>> + mux-0 {
>
> No need for "-0"
>
Thanks I will change that for the three nodes.
>> + groups = "emmc_nand_d0",
>> + "emmc_nand_d1",
>> + "emmc_nand_d2",
>> + "emmc_nand_d3";
>> + function = "emmc";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + emmc_data_8b_pins: emmc-data-8b {
>> + mux-0 {
>
> No need for "-0"
>
>> + groups = "emmc_nand_d0",
>> + "emmc_nand_d1",
>> + "emmc_nand_d2",
>> + "emmc_nand_d3",
>> + "emmc_nand_d4",
>> + "emmc_nand_d5",
>> + "emmc_nand_d6",
>> + "emmc_nand_d7";
>> + function = "emmc";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + emmc_ds_pins: emmc-ds {
>> + mux {
>> + groups = "emmc_nand_ds";
>> + function = "emmc";
>> + bias-pull-down;
>> + };
>> + };
>> +
>> + emmc_clk_gate_pins: emmc-clk-gate {
>> + mux {
>> + groups = "GPIOB_8";
>> + function = "gpio_periphs";
>> + bias-pull-down;
>> + };
>> + };
>> +
>> + sdcard_pins: sdcard {
>> + mux {
>> + groups = "sdcard_d0",
>> + "sdcard_d1",
>> + "sdcard_d2",
>> + "sdcard_d3",
>> + "sdcard_clk",
>> + "sdcard_cmd";
>> + function = "sdcard";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + sdcard_clk_gate_pins: sdcard-clk-gate {
>> + mux {
>> + groups = "GPIOC_4";
>> + function = "gpio_periphs";
>> + bias-pull-down;
>> + };
>> + };
>> +
>> + sdio_pins: sdio {
>> + mux-0 {
>
> No need for "-0"
>
>> + groups = "sdio_d0",
>> + "sdio_d1",
>> + "sdio_d2",
>> + "sdio_d3",
>> + "sdio_clk",
>> + "sdio_cmd";
>> + function = "sdio";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + sdio_clk_gate_pins: sdio-clk-gate {
>> + mux {
>> + groups = "GPIOX_4";
>> + function = "gpio_periphs";
>> + bias-pull-up;
>> + };
>> + };
>> };
>> gpio_intc: interrupt-controller@4080 {
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mmc: hisilicon,hi3660-dw-mshc: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-26 9:17 UTC (permalink / raw)
To: Bhargav Joshi
Cc: devicetree, linux-arm-kernel, xuwei5, robh, krzk+dt, conor+dt,
ulf.hansson, zhangfei.gao, linux-mmc, daniel.baluta, simona.toaca,
d-gole, m-chawdhry, linux-kernel
In-Reply-To: <20260325225439.68161-2-rougueprince47@gmail.com>
On Thu, Mar 26, 2026 at 04:24:38AM +0530, Bhargav Joshi wrote:
> Convert the Hisilicon DesignWare Mobile Storage Host Controller
> (dw-mshc) bindings from text format to DT schema.
>
> As part of this conversion, the binding file is renamed from
> k3-dw-mshc.txt to hisilicon,hi3660-dw-mshc.yaml to align with compatible
> string naming conventions. Examples have been updated to pass schema
> validation.
>
> Note: synopsys-dw-mshc binding specifies clock names as "biu" followed
> by "ciu". However, this Hisilicon binding reverses the order to 'ciu'
> then 'biu' to match both the legacy text binding and in-kernel Hisilicon
> DTS board files.
>
> Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
> Acked-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] perf/arm-cmn: Fix incorrect error check for devm_ioremap()
From: Chen Ni @ 2026-03-26 9:08 UTC (permalink / raw)
To: will
Cc: robin.murphy, mark.rutland, ilkka, linux-arm-kernel,
linux-perf-users, Chen Ni
Check devm_ioremap() return value for NULL instead of ERR_PTR and return
-ENOMEM on failure. devm_ioremap() never returns ERR_PTR, using IS_ERR()
skips the error path and may cause a NULL pointer dereference.
Fixes: 5394396ff548 ("perf/arm-cmn: Stop claiming entire iomem region")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
---
drivers/perf/arm-cmn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 1ac91cda6780..9fe00d0f4deb 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -2573,8 +2573,8 @@ static int arm_cmn_probe(struct platform_device *pdev)
/* Map the whole region now, claim the DTCs once we've found them */
cmn->base = devm_ioremap(cmn->dev, cfg->start, resource_size(cfg));
- if (IS_ERR(cmn->base))
- return PTR_ERR(cmn->base);
+ if (!cmn->base)
+ return -ENOMEM;
rootnode = arm_cmn_get_root(cmn, cfg);
if (rootnode < 0)
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-03-26 9:06 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260326090645.22590-1-gakula@marvell.com>
The CN20K DRAM Subsystem exposes eight programmable
performance counters and two fixed counters for DDR
read and write traffic. Software selects events for
the programmable counters from traffic at the DDR PHY
interface, the CHI interconnect, or inside the DDR controller.
Add CN20K register offsets, event maps, and sysfs attributes;
match the device via OF (marvell,cn20k-ddr-pmu) and ACPI (MRVL000B).
Represent the SoC variant in platform data with bit flags so
CN20K can reuse the Odyssey PMU code path where appropriate.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
drivers/perf/marvell_cn10k_ddr_pmu.c | 187 ++++++++++++++++++++++++---
1 file changed, 171 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/marvell_cn10k_ddr_pmu.c b/drivers/perf/marvell_cn10k_ddr_pmu.c
index 72ac17efd846..7e2e1823b009 100644
--- a/drivers/perf/marvell_cn10k_ddr_pmu.c
+++ b/drivers/perf/marvell_cn10k_ddr_pmu.c
@@ -13,31 +13,43 @@
#include <linux/hrtimer.h>
#include <linux/acpi.h>
#include <linux/platform_device.h>
+#include <linux/bits.h>
+
+/* SoC variant flags for struct ddr_pmu_platform_data (mutually exclusive in pdata) */
+#define IS_CN10K BIT(0)
+#define IS_ODY BIT(1)
+#define IS_CN20K BIT(2)
/* Performance Counters Operating Mode Control Registers */
#define CN10K_DDRC_PERF_CNT_OP_MODE_CTRL 0x8020
#define ODY_DDRC_PERF_CNT_OP_MODE_CTRL 0x20020
+#define CN20K_DDRC_PERF_CNT_OP_MODE_CTRL 0x20000
#define OP_MODE_CTRL_VAL_MANUAL 0x1
/* Performance Counters Start Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_START_OP_CTRL 0x8028
#define ODY_DDRC_PERF_CNT_START_OP_CTRL 0x200A0
+#define CN20K_DDRC_PERF_CNT_START_OP_CTRL 0x20080
#define START_OP_CTRL_VAL_START 0x1ULL
#define START_OP_CTRL_VAL_ACTIVE 0x2
/* Performance Counters End Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_END_OP_CTRL 0x8030
#define ODY_DDRC_PERF_CNT_END_OP_CTRL 0x200E0
+#define CN20K_DDRC_PERF_CNT_END_OP_CTRL 0x200C0
#define END_OP_CTRL_VAL_END 0x1ULL
/* Performance Counters End Status Registers */
#define CN10K_DDRC_PERF_CNT_END_STATUS 0x8038
#define ODY_DDRC_PERF_CNT_END_STATUS 0x20120
+#define CN20K_DDRC_PERF_CNT_END_STATUS 0x20100
#define END_STATUS_VAL_END_TIMER_MODE_END 0x1
/* Performance Counters Configuration Registers */
#define CN10K_DDRC_PERF_CFG_BASE 0x8040
#define ODY_DDRC_PERF_CFG_BASE 0x20160
+#define CN20K_DDRC_PERF_CFG_BASE 0x20140
+#define CN20K_DDRC_PERF_CFG1_BASE 0x20180
/* 8 Generic event counter + 2 fixed event counters */
#define DDRC_PERF_NUM_GEN_COUNTERS 8
@@ -61,6 +73,23 @@
* DO NOT change these event-id numbers, they are used to
* program event bitmap in h/w.
*/
+
+/* CN20K specific events */
+#define EVENT_PERF_OP_IS_RD16 61
+#define EVENT_PERF_OP_IS_RD32 60
+#define EVENT_PERF_OP_IS_WR16 59
+#define EVENT_PERF_OP_IS_WR32 58
+#define EVENT_OP_IS_ENTER_DSM 44
+#define EVENT_OP_IS_RFM 43
+
+#define EVENT_CN20K_OP_IS_TCR_MRR 50
+#define EVENT_CN20K_OP_IS_DQSOSC_MRR 49
+#define EVENT_CN20K_OP_IS_DQSOSC_MPC 48
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR 47
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD 46
+#define EVENT_CN20K_OP_IS_ZQLATCH 21
+#define EVENT_CN20K_OP_IS_ZQSTART 22
+
#define EVENT_DFI_CMD_IS_RETRY 61
#define EVENT_RD_UC_ECC_ERROR 60
#define EVENT_RD_CRC_ERROR 59
@@ -87,6 +116,9 @@
#define EVENT_OP_IS_SPEC_REF 41
#define EVENT_OP_IS_CRIT_REF 40
#define EVENT_OP_IS_REFRESH 39
+#define EVENT_OP_IS_CAS_WCK_SUS 38
+#define EVENT_OP_IS_CAS_WS_OFF 37
+#define EVENT_OP_IS_CAS_WS 36
#define EVENT_OP_IS_ENTER_MPSM 35
#define EVENT_OP_IS_ENTER_POWERDOWN 31
#define EVENT_OP_IS_ENTER_SELFREF 27
@@ -183,8 +215,8 @@ struct ddr_pmu_platform_data {
u64 cnt_freerun_clr;
u64 cnt_value_wr_op;
u64 cnt_value_rd_op;
- bool is_cn10k;
- bool is_ody;
+ u64 cfg1_base;
+ unsigned int silicon_flags; /* IS_CN10K, IS_ODY, or IS_CN20K */
};
static ssize_t cn10k_ddr_pmu_event_show(struct device *dev,
@@ -336,6 +368,80 @@ static struct attribute *odyssey_ddr_perf_events_attrs[] = {
NULL
};
+static struct attribute *cn20k_ddr_perf_events_attrs[] = {
+ /* Programmable */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_or_wr_access, EVENT_HIF_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_wr_access, EVENT_HIF_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_access, EVENT_HIF_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rmw_access, EVENT_HIF_RMW),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_pri_rdaccess, EVENT_HIF_HI_PRI_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rd_bypass_access, EVENT_READ_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_act_bypass_access, EVENT_ACT_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_wr_data_access,
+ EVENT_DFI_WR_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_rd_data_access,
+ EVENT_DFI_RD_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hpri_sched_rd_crit_access,
+ EVENT_HPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_lpri_sched_rd_crit_access,
+ EVENT_LPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_wr_trxn_crit_access,
+ EVENT_WR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_active_access, EVENT_OP_IS_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_or_wr_access,
+ EVENT_OP_IS_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_active_access,
+ EVENT_OP_IS_RD_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_read, EVENT_OP_IS_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_write, EVENT_OP_IS_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_mwr, EVENT_OP_IS_MWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge, EVENT_OP_IS_PRECHARGE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_rdwr,
+ EVENT_PRECHARGE_FOR_RDWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_other,
+ EVENT_PRECHARGE_FOR_OTHER),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rdwr_transitions, EVENT_RDWR_TRANSITIONS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write_combine, EVENT_WRITE_COMBINE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_war_hazard, EVENT_WAR_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_raw_hazard, EVENT_RAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_waw_hazard, EVENT_WAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_selfref, EVENT_OP_IS_ENTER_SELFREF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_powerdown,
+ EVENT_OP_IS_ENTER_POWERDOWN),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws, EVENT_OP_IS_CAS_WS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws_off, EVENT_OP_IS_CAS_WS_OFF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_wck_sus, EVENT_OP_IS_CAS_WCK_SUS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_refresh, EVENT_OP_IS_REFRESH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_crit_ref, EVENT_OP_IS_CRIT_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_spec_ref, EVENT_OP_IS_SPEC_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_load_mode, EVENT_OP_IS_LOAD_MODE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rfm, EVENT_OP_IS_RFM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_dsm, EVENT_OP_IS_ENTER_DSM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_cycles, EVENT_DFI_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_rd,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_wr,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mpc, EVENT_CN20K_OP_IS_DQSOSC_MPC),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mrr, EVENT_CN20K_OP_IS_DQSOSC_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_tcr_mrr, EVENT_CN20K_OP_IS_TCR_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqstart, EVENT_CN20K_OP_IS_ZQSTART),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqlatch, EVENT_CN20K_OP_IS_ZQLATCH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read16, EVENT_PERF_OP_IS_RD16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read32, EVENT_PERF_OP_IS_RD32),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write16, EVENT_PERF_OP_IS_WR16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write32, EVENT_PERF_OP_IS_WR32),
+ /* Free run event counters */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_reads, EVENT_DDR_READS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_writes, EVENT_DDR_WRITES),
+ NULL
+};
+
+static struct attribute_group cn20k_ddr_perf_events_attr_group = {
+ .name = "events",
+ .attrs = cn20k_ddr_perf_events_attrs,
+};
+
static struct attribute_group odyssey_ddr_perf_events_attr_group = {
.name = "events",
.attrs = odyssey_ddr_perf_events_attrs,
@@ -393,6 +499,13 @@ static const struct attribute_group *odyssey_attr_groups[] = {
NULL
};
+static const struct attribute_group *cn20k_attr_groups[] = {
+ &cn20k_ddr_perf_events_attr_group,
+ &cn10k_ddr_perf_format_attr_group,
+ &cn10k_ddr_perf_cpumask_attr_group,
+ NULL
+};
+
/* Default poll timeout is 100 sec, which is very sufficient for
* 48 bit counter incremented max at 5.6 GT/s, which may take many
* hours to overflow.
@@ -412,7 +525,7 @@ static int ddr_perf_get_event_bitmap(int eventid, u64 *event_bitmap,
switch (eventid) {
case EVENT_DFI_PARITY_POISON ...EVENT_DFI_CMD_IS_RETRY:
- if (!ddr_pmu->p_data->is_ody) {
+ if (!(ddr_pmu->p_data->silicon_flags & IS_ODY)) {
err = -EINVAL;
break;
}
@@ -524,9 +637,9 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
int counter, bool enable)
{
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
u64 ctrl_reg = pmu->p_data->cnt_op_mode_ctrl;
const struct ddr_pmu_ops *ops = pmu->ops;
- bool is_ody = pmu->p_data->is_ody;
u32 reg;
u64 val;
@@ -546,7 +659,7 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
writeq_relaxed(val, pmu->base + reg);
- if (is_ody) {
+ if (silicon_flags & IS_ODY) {
if (enable) {
/*
* Setup the PMU counter to work in
@@ -621,6 +734,7 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
{
struct cn10k_ddr_pmu *pmu = to_cn10k_ddr_pmu(event->pmu);
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
const struct ddr_pmu_ops *ops = pmu->ops;
struct hw_perf_event *hwc = &event->hw;
u8 config = event->attr.config;
@@ -642,10 +756,17 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
if (counter < DDRC_PERF_NUM_GEN_COUNTERS) {
/* Generic counters, configure event id */
reg_offset = DDRC_PERF_CFG(p_data->cfg_base, counter);
- ret = ddr_perf_get_event_bitmap(config, &val, pmu);
- if (ret)
- return ret;
+ if (silicon_flags & IS_CN20K) {
+ val = (1ULL << (config - 1));
+ if (config == EVENT_CN20K_OP_IS_ZQSTART ||
+ config == EVENT_CN20K_OP_IS_ZQLATCH)
+ reg_offset = DDRC_PERF_CFG(p_data->cfg1_base, counter);
+ } else {
+ ret = ddr_perf_get_event_bitmap(config, &val, pmu);
+ if (ret)
+ return ret;
+ }
writeq_relaxed(val, pmu->base + reg_offset);
} else {
/* fixed event counter, clear counter value */
@@ -952,7 +1073,25 @@ static const struct ddr_pmu_platform_data cn10k_ddr_pmu_pdata = {
.cnt_freerun_clr = 0,
.cnt_value_wr_op = CN10K_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = CN10K_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_cn10k = TRUE,
+ .silicon_flags = IS_CN10K,
+};
+
+static const struct ddr_pmu_platform_data cn20k_ddr_pmu_pdata = {
+ .counter_overflow_val = 0,
+ .counter_max_val = GENMASK_ULL(63, 0),
+ .cnt_base = ODY_DDRC_PERF_CNT_VALUE_BASE,
+ .cfg_base = CN20K_DDRC_PERF_CFG_BASE,
+ .cfg1_base = CN20K_DDRC_PERF_CFG1_BASE,
+ .cnt_op_mode_ctrl = CN20K_DDRC_PERF_CNT_OP_MODE_CTRL,
+ .cnt_start_op_ctrl = CN20K_DDRC_PERF_CNT_START_OP_CTRL,
+ .cnt_end_op_ctrl = CN20K_DDRC_PERF_CNT_END_OP_CTRL,
+ .cnt_end_status = CN20K_DDRC_PERF_CNT_END_STATUS,
+ .cnt_freerun_en = 0,
+ .cnt_freerun_ctrl = ODY_DDRC_PERF_CNT_FREERUN_CTRL,
+ .cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
+ .cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
+ .cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
+ .silicon_flags = IS_CN20K,
};
#endif
@@ -979,7 +1118,7 @@ static const struct ddr_pmu_platform_data odyssey_ddr_pmu_pdata = {
.cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
.cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_ody = TRUE,
+ .silicon_flags = IS_ODY,
};
#endif
@@ -989,8 +1128,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
struct cn10k_ddr_pmu *ddr_pmu;
struct resource *res;
void __iomem *base;
- bool is_cn10k;
- bool is_ody;
+ unsigned int silicon_flags;
char *name;
int ret;
@@ -1014,10 +1152,9 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
ddr_pmu->base = base;
ddr_pmu->p_data = dev_data;
- is_cn10k = ddr_pmu->p_data->is_cn10k;
- is_ody = ddr_pmu->p_data->is_ody;
+ silicon_flags = ddr_pmu->p_data->silicon_flags;
- if (is_cn10k) {
+ if (silicon_flags & IS_CN10K) {
ddr_pmu->ops = &ddr_pmu_ops;
/* Setup the PMU counter to work in manual mode */
writeq_relaxed(OP_MODE_CTRL_VAL_MANUAL, ddr_pmu->base +
@@ -1039,7 +1176,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
- if (is_ody) {
+ if (silicon_flags & IS_ODY) {
ddr_pmu->ops = &ddr_pmu_ody_ops;
ddr_pmu->pmu = (struct pmu) {
@@ -1056,6 +1193,22 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
+ if (silicon_flags & IS_CN20K) {
+ ddr_pmu->ops = &ddr_pmu_ody_ops;
+
+ ddr_pmu->pmu = (struct pmu) {
+ .module = THIS_MODULE,
+ .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
+ .task_ctx_nr = perf_invalid_context,
+ .attr_groups = cn20k_attr_groups,
+ .event_init = cn10k_ddr_perf_event_init,
+ .add = cn10k_ddr_perf_event_add,
+ .del = cn10k_ddr_perf_event_del,
+ .start = cn10k_ddr_perf_event_start,
+ .stop = cn10k_ddr_perf_event_stop,
+ .read = cn10k_ddr_perf_event_update,
+ };
+ }
/* Choose this cpu to collect perf data */
ddr_pmu->cpu = raw_smp_processor_id();
@@ -1098,6 +1251,7 @@ static void cn10k_ddr_perf_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id cn10k_ddr_pmu_of_match[] = {
{ .compatible = "marvell,cn10k-ddr-pmu", .data = &cn10k_ddr_pmu_pdata },
+ { .compatible = "marvell,cn20k-ddr-pmu", .data = &cn20k_ddr_pmu_pdata },
{ },
};
MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
@@ -1107,6 +1261,7 @@ MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
static const struct acpi_device_id cn10k_ddr_pmu_acpi_match[] = {
{"MRVL000A", (kernel_ulong_t)&cn10k_ddr_pmu_pdata },
{"MRVL000C", (kernel_ulong_t)&odyssey_ddr_pmu_pdata},
+ {"MRVL000B", (kernel_ulong_t)&cn20k_ddr_pmu_pdata},
{},
};
MODULE_DEVICE_TABLE(acpi, cn10k_ddr_pmu_acpi_match);
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Geetha sowjanya @ 2026-03-26 9:06 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260326090645.22590-1-gakula@marvell.com>
Add a devicetree binding for the Marvell CN20K DDR performance
monitor block, including the marvell,cn20k-ddr-pmu compatible
string and the required MMIO reg region.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
.../bindings/perf/marvell-cn20k-ddr.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
new file mode 100644
index 000000000000..6677d9eb4ba3
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell CN20K DDR performance monitor
+
+maintainers:
+ - Geetha sowjanya <gakula@marvell.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - marvell,cn20k-ddr-pmu
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ddrcpmu {
+ compatible = "marvell,cn20k-ddr-pmu";
+ reg = <0xc200 0x00000000 0x0 0x100000>;
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH 0/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-03-26 9:06 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
This series adds support for the Marvell CN20K DRAM Subsystem (DSS)
performance monitor in the existing marvell_cn10k_ddr_pmu driver, and
documents the device tree binding for the new compatible string.
The CN20K PMU provides eight programmable counters and two fixed
counters (DDR reads and writes). Patch 1 adds the devicetree schema for
"marvell,cn20k-ddr-pmu". Patch 2 wires OF and ACPI (MRVL000B) match
entries, adds CN20K register offsets and event maps, and refactors
platform data to use silicon variant flags.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Geetha sowjanya (2):
dt-bindings: perf: marvell: Document CN20K DDR PMU
perf: marvell: Add CN20K DDR PMU support
.../bindings/perf/marvell-cn20k-ddr.yaml | 37 ++++
drivers/perf/marvell_cn10k_ddr_pmu.c | 186 ++++++++++++++++--
2 files changed, 207 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
--
2.25.1
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0
From: Neil Armstrong @ 2026-03-26 9:06 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel, Anand Moon
In-Reply-To: <20260219103548.18392-1-linux.amoon@gmail.com>
Hi,
On Thu, 19 Feb 2026 16:05:46 +0530, Anand Moon wrote:
> Add missing L1 data and instruction cache parameters to the CPU node 0
> for the Cortex-A53 caches on the Meson AXG SoC.
>
>
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0
https://git.kernel.org/amlogic/c/e28f4b18c134f944b0ae93ebf1bacc8e517fdcf5
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v2 0/4] arm64: dts: amlogic: meson-s4-khadas-vim1s: enable LEDs, Keys and Bluetooth
From: Neil Armstrong @ 2026-03-26 9:06 UTC (permalink / raw)
To: khilman, martin.blumenstingl, jbrunet, krzk+dt, Nick Xie
Cc: robh, conor+dt, linux-amlogic, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260228063750.701887-1-nick@khadas.com>
Hi,
On Sat, 28 Feb 2026 14:37:46 +0800, Nick Xie wrote:
> This series enables various user interfaces and the Bluetooth module
> for the Khadas VIM1S board (Amlogic S905Y4).
>
> This builds upon the existing board support to fully enable the
> user-facing peripherals.
>
> Changes in v2:
> - Dropped the SARADC and Function Key patches from this series. As
> suggested by Martin Blumenstingl, a dedicated compatible string and
> driver update for the S4 SARADC will be submitted in a separate series
> to ensure forward compatibility.
> - Patch 1: Split the UART_A pinctrl definitions in meson-s4.dtsi into
> separate rx/tx and rts/cts groups to keep the SoC dtsi generic
> (Martin Blumenstingl).
> - Patch 2: Assigned the UART_A pinctrl groups directly in the board dts.
> - Added Martin's 'Reviewed-by' tags to Patches 2, 3, and 4.
> - Link to v1: https://lore.kernel.org/linux-amlogic/20260123022258.136448-1-nick@khadas.com/
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/4] arm64: dts: amlogic: meson-s4: add UART_A node
https://git.kernel.org/amlogic/c/6710d76d7e51a24f978eb1ae0738d1e3c25e034c
[2/4] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable bluetooth
https://git.kernel.org/amlogic/c/ad44c753b976e469f0f014b6f92e7180b6a7ba59
[3/4] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add PWM LED support
https://git.kernel.org/amlogic/c/b8a95d4c054d9d2e784ce5eeb6a08be0ce9031d0
[4/4] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add POWER key support
https://git.kernel.org/amlogic/c/31132e11e9dd97c706434e4f9e86b503c67a6bac
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: Fix GIC register ranges for Amlogic T7
From: Neil Armstrong @ 2026-03-26 9:06 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260305-fix-amlt7-gic-dts-v1-1-5944415c74bf@aliel.fr>
Hi,
On Thu, 05 Mar 2026 23:11:25 +0100, Ronald Claveau wrote:
> This patch aims to fix the GIC register ranges for Amlogic T7 SoC family.
>
> - Context
> Kernel log shows a warning about GIC
> [ 0.000000] GIC: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
>
> Using cat /proc/interrupts command shows GIC as GIC-0
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: amlogic: Fix GIC register ranges for Amlogic T7
https://git.kernel.org/amlogic/c/dbb92c6f1ecd0dcd76a3d1002141f340737f55f2
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: meson-gxl-s905d-phicomm-n1: add bluetooth node
From: Neil Armstrong @ 2026-03-26 9:06 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-amlogic, Jun Yan
Cc: martin.blumenstingl, jbrunet, khilman, conor+dt, krzk+dt, robh,
yangxuan8282
In-Reply-To: <20260213073810.552341-1-jerrysteve1101@gmail.com>
Hi,
On Fri, 13 Feb 2026 15:38:10 +0800, Jun Yan wrote:
> The Phicomm N1 uses a CY43455 (BCM43438) module with its Bluetooth
> interface connected to uart_A.
>
> Add the required device tree node to enable proper functionality.
>
>
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: amlogic: meson-gxl-s905d-phicomm-n1: add bluetooth node
https://git.kernel.org/amlogic/c/d6df314c0165cb809d6c647a593664a4f5028230
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: fix board model name
From: Neil Armstrong @ 2026-03-26 9:06 UTC (permalink / raw)
To: khilman, martin.blumenstingl, jbrunet, Nick Xie
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260306030756.2421841-1-nick@khadas.com>
Hi,
On Fri, 06 Mar 2026 11:07:56 +0800, Nick Xie wrote:
> Update the model property to "Khadas VIM4" to match the official
> product branding and maintain consistency with other Khadas boards
> (e.g., VIM1, VIM2, VIM3) in the kernel tree.
>
>
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: amlogic: t7: khadas-vim4: fix board model name
https://git.kernel.org/amlogic/c/771d092af02a11ec565494052d18ddfb5e2f1428
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
From: Neil Armstrong @ 2026-03-26 9:02 UTC (permalink / raw)
To: khilman, martin.blumenstingl, jbrunet, Nick Xie
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel, Ronald Claveau
In-Reply-To: <20260319023446.3422695-1-nick@khadas.com>
Hi,
On Thu, 19 Mar 2026 10:34:46 +0800, Nick Xie wrote:
> The Khadas VIM4 features 8GB of LPDDR4X RAM. The previous memory node
> mapped a single incorrect region. This caused the kernel to map MMIO
> and secure firmware (ATF/TrustZone) memory holes as standard RAM,
> leading to an Asynchronous SError Interrupt during early boot
> (paging_init) when the kernel attempted to clear those pages.
>
> Fix this by splitting the 8GB memory layout into three separate
> regions to properly avoid the memory holes (e.g., 0xe0000000 -
> 0xffffffff):
> - 3.5GB @ 0x000000000
> - 3.5GB @ 0x100000000
> - 1.0GB @ 0x200000000
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
https://git.kernel.org/amlogic/c/4b3917cd8492d72e576b837f78c0c398bda4ec27
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH 0/4] arm64: dts: imx8mp-skov: add new 7" variant
From: Neil Armstrong @ 2026-03-26 9:02 UTC (permalink / raw)
To: Jessica Zhang, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Steffen Trumtrar
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-0-10255d236439@pengutronix.de>
Hi,
On Wed, 25 Mar 2026 12:31:58 +0100, Steffen Trumtrar wrote:
> Add a new board variant for the Skov i.MX8MP based family of boards.
>
> This variant uses a different 7" panel than the existing ones.
>
>
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/4] dt-bindings: display: simple: Add JuTouch JT070TM041 panel
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/87535f27061f3443e813a64f59fb1b0fcb916e08
[2/4] drm/panel: simple: add JuTouch JT070TM041
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/7a5b966952c0232d7083a496261880fc11cc8c4a
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH 0/7] arm64: dts: Drop CPU masks from GICv3 PPI interrupts
From: Neil Armstrong @ 2026-03-26 8:58 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Peter Griffin,
André Draszik, Tudor Ambarus, Alim Akhtar, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Bjorn Andersson, Konrad Dybcio, Thierry Reding, Marc Zyngier,
Geert Uytterhoeven
Cc: linux-arm-kernel, linux-amlogic, linux-samsung-soc, imx,
linux-arm-msm, linux-renesas-soc, linux-kernel
In-Reply-To: <cover.1772643434.git.geert+renesas@glider.be>
Hi,
On Wed, 04 Mar 2026 18:10:57 +0100, Geert Uytterhoeven wrote:
> Hi all,
>
> Unlike older GIC variants, the GICv3 DT bindings do not support
> specifying a CPU mask in PPI interrupt specifiers. Hence this patch
> series drop all such masks where they are still present.
>
> This has been compile-tested only. But note that all such masks were
> removed before from Renesas SoCs in commit 8b6a006c914aac17 ("arm64:
> dts: renesas: Drop specifying the GIC_CPU_MASK_SIMPLE() for GICv3
> systems")).
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/7] arm64: dts: amlogic: s6: Drop CPU masks from GICv3 PPI interrupts
https://git.kernel.org/amlogic/c/ff6c02a40dc8706c0b13b3b12cfe228c38bb7857
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v2 09/12] arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT
From: Laurent Pinchart @ 2026-03-26 8:58 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Daniel Scally, Marco Felsch, Gilles Talis, Viorel Suman,
Shengjiu Wang, Jagan Teki, Manoj Sai, Matteo Lisi, Ray Chang,
Richard Hu, Heiko Schocher, Martyn Welch, Josua Mayer,
Goran Rađenović, Börge Strümpfel,
Christoph Niedermaier, Marek Vasut, devicetree, imx,
linux-arm-kernel, linux-kernel, kernel, Peng Fan
In-Reply-To: <20260326-imx8mp-dts-fix-v2-v2-9-62c4ce727448@nxp.com>
On Thu, Mar 26, 2026 at 03:28:13PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
> there might be interrupt storm for this board. Need to set PAD PUE and PU
> together to make pull up work properly.
>
> Fixes: a009c0c66ecb4 ("arm64: dts: add description for solidrun imx8mp som and cubox-m")
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
> index 3cdb0bc0ab721709fc892931ea00a538ec6216ff..c3f7daa773eaf335deb6cc976a5e120abdae5967 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
> @@ -174,7 +174,7 @@ pmic: pmic@25 {
> pinctrl-0 = <&pmic_pins>;
> pinctrl-names = "default";
> interrupt-parent = <&gpio1>;
> - interrupts = <3 GPIO_ACTIVE_LOW>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
This is a good change, but it should be mentioned in the commit message,
or split to a separate patch. Same for other patches in this series
where you make the same change.
> nxp,i2c-lt-enable;
>
> regulators {
> @@ -417,7 +417,7 @@ MX8MP_IOMUXC_SAI1_RXD1__GPIO4_IO03 0x160
>
> pmic_pins: pinctrl-pmic-grp {
> fsl,pins = <
> - MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
> + MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
> >;
> };
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-26 8:57 UTC (permalink / raw)
To: Aaro Koskinen, Janusz Krzysztofik
Cc: Arnd Bergmann, Bartosz Golaszewski, Tony Lindgren, Russell King,
Dmitry Torokhov, Hans de Goede, Linux-OMAP, linux-arm-kernel,
linux-kernel, Kevin Hilman
In-Reply-To: <CAMRc=McosSU39SERKtjmhJdTv2cPi44PG=bYqAcfQLDX4QB0Tg@mail.gmail.com>
On Mon, Mar 16, 2026 at 9:50 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Fri, Mar 6, 2026 at 1:31 AM Kevin Hilman <khilman@kernel.org> wrote:
> >
> > Bartosz Golaszewski <brgl@kernel.org> writes:
> >
> > > On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > >>
> > >> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> > >> > Currently the board file for Nokia 770 creates dummy software nodes not
> > >> > attached in any way to the actual GPIO controller devices and uses the
> > >> > fact that GPIOLIB matching swnode's name to the GPIO chip's label during
> > >> > software node lookup. This behavior is wrong and we want to remove it.
> > >> > To that end, we need to first convert all existing users to creating
> > >> > actual fwnode links.
> > >> >
> > >> > Create real software nodes for GPIO controllers on OMAP16xx and
> > >> > reference them from the software nodes in the nokia board file.
> > >> >
> > >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > >>
> > >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Aaro, Janusz: Can you please pick it up for v7.1?
> >
> > I can take this via the OMAP tree once I have confirmation from
> > Aaro/Janusz that they've tested.
> >
> > Kevin
>
> Gentle ping.
>
> Bart
Hi again! Any chance we could get this queued? Janusz, Aaro: any objections?
Bart
^ permalink raw reply
* Re: [PATCH v2 0/4] arm64: Add BRBE support for bpf_get_branch_snapshot()
From: Puranjay Mohan @ 2026-03-26 8:57 UTC (permalink / raw)
To: bpf, Mark Rutland, Catalin Marinas, Will Deacon
Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Leo Yan, Rob Herring, Breno Leitao, linux-arm-kernel,
linux-perf-users, kernel-team
In-Reply-To: <20260318171706.2840512-1-puranjay@kernel.org>
Hi Catalin, Mark, and Will,
Would you mind taking a look at this patchset when you have a chance?
Thanks,
Puranjay
On Wed, Mar 18, 2026 at 5:17 PM Puranjay Mohan <puranjay@kernel.org> wrote:
>
> v1: https://lore.kernel.org/all/20260313180352.3800358-1-puranjay@kernel.org/
> Changes in v2:
> - Rebased on arm64/for-next/core
> - Add per-CPU brbe_active flag to guard against UNDEFINED sysreg access
> on non-BRBE CPUs in heterogeneous big.LITTLE systems.
> - Fix pre-existing bug in perf_clear_branch_entry_bitfields() that missed
> zeroing new_type and priv bitfields, added as a separate patch with
> Fixes tags (new patch 2).
> - Use architecture-specific selftest threshold (#if defined(__aarch64__))
> instead of raising the global threshold, to preserve x86 regression
> detection.
>
> RFC: https://lore.kernel.org/all/20260102214043.1410242-1-puranjay@kernel.org/
> Changes from RFC:
> - Fix pre-existing NULL pointer dereference in armv8pmu_sched_task()
> found by Leo Yan during testing (patch 1)
> - Pause BRBE before local_daif_save() to avoid branch pollution from
> trace_hardirqs_off()
> - Use local_daif_save() to prevent pNMI race from counter overflow
> (Mark Rutland)
> - Reuse perf_entry_from_brbe_regset() instead of duplicating register
> read logic, by making it accept NULL event (Mark Rutland)
> - Invalidate BRBE after reading to maintain record contiguity for
> other consumers (Mark Rutland)
> - Adjust selftest wasted_entries threshold for ARM64 (patch 3)
> - Tested on ARM FVP with BRBE enabled
>
> This series enables the bpf_get_branch_snapshot() BPF helper on ARM64
> by implementing the perf_snapshot_branch_stack static call for ARM's
> Branch Record Buffer Extension (BRBE).
>
> bpf_get_branch_snapshot() [1] allows BPF programs to capture hardware
> branch records on-demand from any BPF tracing context. This was
> previously only available on x86 (Intel LBR) since v5.16. With BRBE
> available on ARMv9, this series closes the gap for ARM64.
>
> Usage model
> -----------
>
> The helper works in conjunction with perf events. The userspace
> component of the BPF application opens a perf event with
> PERF_SAMPLE_BRANCH_STACK on each CPU, which configures the hardware
> to continuously record branches into BRBE (on ARM64) or LBR (on x86).
> A BPF program attached to a tracepoint, kprobe, or fentry hook can
> then call bpf_get_branch_snapshot() to snapshot the branch buffer at
> any point. Without an active perf event, BRBE is not recording and
> the buffer is empty.
>
> On-demand branch snapshots from BPF are useful for diagnosing which
> specific code path was taken inside a function. Stack traces only show
> function boundaries, but branch records reveal the exact sequence of
> jumps, calls, and returns within a function -- making it possible to
> identify which specific error check triggered a failure, or which
> callback implementation was invoked through a function pointer.
>
> For example, retsnoop [2] is a BPF-based tool for non-intrusive
> mass-tracing of kernel internals. Its LBR mode (--lbr) creates per-CPU
> perf events with PERF_SAMPLE_BRANCH_STACK and then uses
> bpf_get_branch_snapshot() in its fentry/fexit BPF programs to capture
> branch records whenever a traced function returns an error.
>
> Consider debugging a bpf() syscall that returns -EINVAL when creating
> a BPF map with invalid parameters. Running retsnoop on an ARM64 FVP
> with BRBE to trace the bpf() syscall and array_map_alloc_check():
>
> $ retsnoop -e '*sys_bpf' -a 'array_map_alloc_check' --lbr=any \
> -F -k vmlinux --debug full-lbr
> $ simfail bpf-bad-map-max-entries-array # in another terminal
>
> Output of retsnoop:
>
> --- fentry BPF program (entries #63-#17) ---
>
> [#63-#59] __htab_map_lookup_elem: hash table walk with memcmp (hashtab.c)
> [#58] __htab_map_lookup_elem+0x98 -> dump_bpf_prog+0xc850 (hashtab.c:750)
> [#57-#55] ... dump_bpf_prog internal branches ...
> [#54] dump_bpf_prog+0xcab8 -> bpf_get_current_pid_tgid+0x0 (helpers.c:225)
> [#53] bpf_get_current_pid_tgid+0x1c -> dump_bpf_prog+0xcabc (helpers.c:225)
> [#52-#51] ... dump_bpf_prog -> __htab_map_lookup_elem ...
> [#50-#47] __htab_map_lookup_elem: htab_map_hash (jhash2), select_bucket
> [#46-#42] lookup_nulls_elem_raw: hash chain walk with memcmp (hashtab.c:717)
> [#41] __htab_map_lookup_elem+0x98 -> dump_bpf_prog+0xcaf8 (hashtab.c:750)
> [#40-#37] ... dump_bpf_prog -> bpf_ktime_get_ns ...
> [#36] bpf_ktime_get_ns+0x10 -> ktime_get_mono_fast_ns+0x0 (helpers.c:178)
> [#35-#32] ktime_get_mono_fast_ns: tk_clock_read -> arch_counter_get_cntpct
> [#31] ktime_get_mono_fast_ns+0x9c -> bpf_ktime_get_ns+0x14 (timekeeping.c:493)
> [#30] bpf_ktime_get_ns+0x18 -> dump_bpf_prog+0xcd50 (helpers.c:178)
> [#29-#25] ... dump_bpf_prog internal branches ...
> [#24] dump_bpf_prog+0x11b28 -> __bpf_prog_exit_recur+0x0 (trampoline.c:1190)
> [#23-#17] __bpf_prog_exit_recur: rcu_read_unlock, migrate_enable (trampoline.c:1195)
>
> --- array_map_alloc_check (entries #16-#12) ---
>
> [#16] dump_bpf_prog+0x11b38 -> array_map_alloc_check+0x8 (arraymap.c:55)
> [#15] array_map_alloc_check+0x18 -> array_map_alloc_check+0xb8 (arraymap.c:56)
> . bpf_map_attr_numa_node . bpf_map_attr_numa_node
> [#14] array_map_alloc_check+0xbc -> array_map_alloc_check+0x20 (arraymap.c:59)
> . bpf_map_attr_numa_node
> [#13] array_map_alloc_check+0x24 -> array_map_alloc_check+0x94 (arraymap.c:64)
> [#12] array_map_alloc_check+0x98 -> dump_bpf_prog+0x11b3c (arraymap.c:82)
>
> --- fexit trampoline overhead (entries #11-#00) ---
>
> [#11] dump_bpf_prog+0x11b5c -> __bpf_prog_enter_recur+0x0 (trampoline.c:1145)
> [#10-#03] __bpf_prog_enter_recur: rcu_read_lock, migrate_disable (trampoline.c:1146)
> [#02] __bpf_prog_enter_recur+0x114 -> dump_bpf_prog+0x11b60 (trampoline.c:1157)
> [#01] dump_bpf_prog+0x11b6c -> dump_bpf_prog+0xd230
> [#00] dump_bpf_prog+0xd340 -> arm_brbe_snapshot_branch_stack+0x0 (arm_brbe.c:814)
>
> el0t_64_sync+0x168
> el0t_64_sync_handler+0x98
> el0_svc+0x28
> do_el0_svc+0x4c
> invoke_syscall.constprop.0+0x54
> 373us [-EINVAL] __arm64_sys_bpf+0x8
> __sys_bpf+0x87c
> map_create+0x120
> 95us [-EINVAL] array_map_alloc_check+0x8
>
> The FVP's BRBE buffer has 64 entries (BRBE supports 8, 16, 32, or
> 64). Of these, entries #63-#17 (47) are consumed by the fentry BPF
> trampoline that ran before the function, and entries #11-#00 (12)
> are consumed by the fexit trampoline that runs after. Entry #00
> shows the very last branch recorded before BRBE is paused: the call
> into arm_brbe_snapshot_branch_stack().
>
> The 5 useful entries (#16-#12) show the exact path taken inside
> array_map_alloc_check(). Record #14 shows a jump from line 56
> (bpf_map_attr_numa_node) to line 59 (the if-condition), and #13
> shows an immediate jump from line 59 (attr->max_entries == 0) to
> line 64 (return -EINVAL), skipping lines 60-63. This pinpoints
> max_entries==0 as the cause -- a diagnosis impossible with stack
> traces alone.
>
> [1] 856c02dbce4f ("bpf: Introduce helper bpf_get_branch_snapshot")
> [2] https://github.com/anakryiko/retsnoop
>
> Puranjay Mohan (4):
> perf/arm_pmuv3: Fix NULL pointer dereference in armv8pmu_sched_task()
> perf: Fix uninitialized bitfields in
> perf_clear_branch_entry_bitfields()
> perf/arm64: Add BRBE support for bpf_get_branch_snapshot()
> selftests/bpf: Adjust wasted entries threshold for ARM64 BRBE
>
> drivers/perf/arm_brbe.c | 79 ++++++++++++++++++-
> drivers/perf/arm_brbe.h | 9 +++
> drivers/perf/arm_pmuv3.c | 16 +++-
> include/linux/perf_event.h | 2 +
> .../bpf/prog_tests/get_branch_snapshot.c | 13 ++-
> 5 files changed, 110 insertions(+), 9 deletions(-)
>
>
> base-commit: d118f32246fdabfb4f6a3fd2e511dc5e622bc553
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Jinjie Ruan @ 2026-03-26 8:56 UTC (permalink / raw)
To: Thomas Gleixner, Mark Rutland
Cc: vladimir.murzin, peterz, catalin.marinas, linux-kernel, luto,
will, linux-arm-kernel
In-Reply-To: <87ecl7gbeu.ffs@tglx>
On 2026/3/25 23:46, Thomas Gleixner wrote:
> On Wed, Mar 25 2026 at 11:03, Mark Rutland wrote:
>> On Sun, Mar 22, 2026 at 12:25:06AM +0100, Thomas Gleixner wrote:
>>> The current sequence on entry is:
>>>
>>> // interrupts are disabled by interrupt/exception entry
>>> enter_from_kernel_mode()
>>> irqentry_enter(regs);
>>> mte_check_tfsr_entry();
>>> mte_disable_tco_entry();
>>> daif_inherit(regs);
>>> // interrupts are still disabled
>>
>> That last comment isn't quite right: we CAN and WILL enable interrupts
>> in local_daif_inherit(), if and only if they were enabled in the context
>> the exception was taken from.
>
> Ok.
>
>> As mentioned above, when handling an interrupt (rather than a
>> synchronous exception), we don't use local_daif_inherit(), and instead
>> use a different DAIF function to unmask everything except interrupts.
>>
>>> which then becomes:
>>>
>>> // interrupts are disabled by interrupt/exception entry
>>> irqentry_enter(regs)
>>> establish_state();
>>> // RCU is watching
>>> arch_irqentry_enter_rcu()
>>> mte_check_tfsr_entry();
>>> mte_disable_tco_entry();
>>> daif_inherit(regs);
>>> // interrupts are still disabled
>>>
>>> Which is equivalent versus the MTE/DAIF requirements, no?
>>
>> As above, we can't use local_daif_inherit() here because we want
>> different DAIF masking behavior for entry to interrupts and entry to
>> synchronous exceptions. While we could pass some token around to
>> determine the behaviour dynamically, that's less clear, more
>> complicated, and results in worse code being generated for something we
>> know at compile time.
>
> I get it. Duh what a maze.
>
>> If we can leave DAIF masked early on during irqentry_enter(), I don't
>> see why we can't leave all DAIF exceptions masked until the end of
>> irqentry_enter().
>
> Yes. Entry is not an issue.
>
>> I *think* what would work for us is we could split some of the exit
>> handling (including involuntary preemption) into a "prepare" step, as we
>> have for return to userspace. That way, arm64 could handle exiting
>> something like:
>>
>> local_irq_disable();
>> irqentry_exit_prepare(); // new, all generic logic
>> local_daif_mask();
>> arm64_exit_to_kernel_mode() {
>> ...
>> irqentry_exit(); // ideally irqentry_exit_to_kernel_mode().
>> ...
>> }
>>
>> ... and other architectures can use a combined exit_to_kernel_mode() (or
>> whatever we call that), which does both, e.g.
>>
>> // either noinstr, __always_inline, or a macro
>> void irqentry_prepare_and_exit(void)
>
> That's a bad idea as that would require to do a full kernel rename of
> all existing irqentry_exit() users.
I see your point about the rename. However, we can avoid a tree-wide
rename by keeping the irqentry_exit() name and interface exactly as it is.
The idea is to perform an internal refactoring: split the existing logic
into two helpers (e.g., irqentry_exit_prepare() and a core helper), and
then have the original irqentry_exit() call both of them. This way,
existing users like RISC-V remain untouched, while arm64 can choose to
call the two sub-functions individually to insert the DAIF masking in
between."
>
>> {
>> irqentry_exit_prepare();
>> irqentry_exit();
>> }
>
> Aside of the naming that should work.
>
> Thanks,
>
> tglx
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 08/13] firmware: arm_scmi: Harden clock protocol initialization
From: Alexander Stein @ 2026-03-26 8:55 UTC (permalink / raw)
To: Marek Szyprowski, Cristian Marussi
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-clk, linux-renesas-soc, sudeep.holla, philip.radford,
james.quinlan, f.fainelli, vincent.guittot, etienne.carriere,
peng.fan, michal.simek, dan.carpenter, geert+renesas,
kuninori.morimoto.gx, marek.vasut+renesas
In-Reply-To: <acPUxJ3N0QptmtlJ@pluto>
Hi,
Am Mittwoch, 25. März 2026, 13:27:48 CET schrieb Cristian Marussi:
> On Wed, Mar 25, 2026 at 12:02:41PM +0100, Marek Szyprowski wrote:
> > On 10.03.2026 19:40, Cristian Marussi wrote:
> > > Add proper error handling on failure to enumerate clocks features or
> > > rates.
> > >
> > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> >
>
> Hi Marek,
>
> > This patch landed yesterday in linux-next as commit 0d8b0c8068a8
> > ("firmware: arm_scmi: Harden clock protocol initialization"). In my
> > tests I found that it causes a regression on RK3568 Odroid-M1 board
> > (arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts), cpufreq and GPU
> > device are not probed properly:
> >
> > # dmesg | grep scmi
> > scmi_core: SCMI protocol bus registered
> > arm-scmi arm-scmi.0.auto: Using scmi_smc_transport
> > arm-scmi arm-scmi.0.auto: SCMI max-rx-timeout: 30ms / max-msg-size:
> > 104bytes / max-msg: 20
> > scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
> > arm-scmi arm-scmi.0.auto: SCMI Notifications - Core Enabled.
> > arm-scmi arm-scmi.0.auto: Malformed reply - real_sz:8 calc_sz:4
> > (loop_num_ret:1)
> > arm-scmi arm-scmi.0.auto: SCMI Protocol v2.0 'rockchip:' Firmware
> > version 0x0
> > arm-scmi arm-scmi.0.auto: Enabling SCMI Quirk
> > [quirk_clock_rates_triplet_out_of_spec]
> > scmi-clocks scmi_dev.3: probe with driver scmi-clocks failed with error -22
> >
>
> Yes there are multiple reports of issues on this hardening, the series
> is on hold and wont go into v7.1 as of now...it needs some basic fixes
> and various quirks probably to address non-compliant firmwares...
>
> It will be pushed to next again with a few more fixes in the coming
> days and then we'll need to figure out how many quirks will be needed on
> top of that and if it is acceptable at all...
Just for the records: imx95 (maybe imx94 as well) is also affected by this.
My board doesn't boot at all, because all the clocks are provided by SCMI.
With this diff I can see it's the 'ext' clock
-->8---
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -1253,8 +1253,11 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
cinfo->clkds[clkid].id = clkid;
ret = scmi_clock_attributes_get(ph, clkid, cinfo);
- if (ret)
+ if (ret) {
+ dev_warn(ph->dev, "scmi_clock_attributes_get failed for '%s': %d\n",
+ cinfo->clkds->info.name, ret);
return ret;
+ }
ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
if (ret)
-->8---
> arm-scmi arm-scmi.0.auto: scmi_clock_attributes_get failed for 'ext': -2
> scmi-clocks scmi_dev.6: probe with driver scmi-clocks failed with error -2
What's the idea of how to proceeed as apparently several platforms are
affected?
Best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v4 9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
From: Neil Armstrong @ 2026-03-26 8:54 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-9-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Enable and configure the three MMC controllers for the Khadas VIM4 board:
> - sd_emmc_a: SDIO interface for the BCM43752 Wi-Fi module
> - sd_emmc_b: SD card slot
> - sd_emmc_c: eMMC storage
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 +++++++++++++++++++++-
> 1 file changed, 89 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 770f06b0b16c7..5a73ae081036c 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -14,7 +14,10 @@ / {
> compatible = "khadas,vim4", "amlogic,a311d2", "amlogic,t7";
>
> aliases {
> - serial0 = &uart_a;
> + serial0 = &uart_a;
Spurious change
> + mmc0 = &sd_emmc_c;
> + mmc1 = &sd_emmc_b;
> + mmc2 = &sd_emmc_a;
> };
>
> memory@0 {
> @@ -159,6 +162,91 @@ &pwm_ab {
> pinctrl-names = "default";
> };
>
> +/* SDIO */
> +&sd_emmc_a {
> + status = "okay";
> + pinctrl-0 = <&sdio_pins>;
> + pinctrl-1 = <&sdio_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + cap-sdio-irq;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + no-mmc;
> + no-sd;
> +
> + power-domains = <&pwrc PWRC_T7_SDIO_A_ID>;
> +
> + keep-power-in-suspend;
> +
> + mmc-pwrseq = <&sdio_pwrseq>;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddao_1v8>;
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm43752-fmac", "brcm,bcm4329-fmac";
> + };
> +};
> +
> +/* SD card */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-1 = <&sdcard_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + max-frequency = <200000000>;
> + disable-wp;
> + no-sdio;
> + no-mmc;
> +
> + power-domains = <&pwrc PWRC_T7_SDIO_B_ID>;
> +
> + cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
> + vmmc-supply = <&sd_3v3>;
> + vqmmc-supply = <&vddio_c>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_8b_pins>, <&emmc_ds_pins>;
> + pinctrl-1 = <&emmc_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + max-frequency = <200000000>;
> + disable-wp;
> + non-removable;
> + no-sdio;
> + no-sd;
> +
> + power-domains = <&pwrc PWRC_T7_EMMC_ID>;
> +
> + vmmc-supply = <&vddio_3v3>;
> + vqmmc-supply = <&vddio_1v8>;
> +};
> +
> &uart_a {
> status = "okay";
> clocks = <&xtal>, <&xtal>, <&xtal>;
>
With that:
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-7-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add the SDIO power sequence node using mmc-pwrseq-simple and a
> 32.768kHz PWM-based clock required by the Wi-Fi module.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 2450084d37642..770f06b0b16c7 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -67,6 +67,15 @@ sd_3v3: regulator-sdcard-3v3 {
> regulator-always-on;
> };
>
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> + post-power-on-delay-ms = <500>;
> + power-off-delay-us = <200000>;
> + clocks = <&wifi32k>;
> + clock-names = "ext_clock";
> + };
> +
> vcc5v: regulator-vcc-5v {
> compatible = "regulator-fixed";
> regulator-name = "VCC5V";
> @@ -135,6 +144,19 @@ vddio_c: regulator-gpio-c {
> states = <1800000 1
> 3300000 0>;
> };
> +
> + wifi32k: wifi32k {
> + compatible = "pwm-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + pwms = <&pwm_ab 0 30518 0>;
> + };
> +};
> +
> +&pwm_ab {
> + status = "okay";
> + pinctrl-0 = <&pwm_a_pins>;
> + pinctrl-names = "default";
> };
>
> &uart_a {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-6-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add voltage regulator nodes describing the VIM4 power tree,
> required by peripheral nodes such as the SD card controller.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index fffdab96b12eb..2450084d37642 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -6,6 +6,8 @@
> /dts-v1/;
>
> #include "amlogic-t7.dtsi"
> +#include <dt-bindings/gpio/amlogic,t7-periphs-pinctrl.h>
> +#include <dt-bindings/gpio/gpio.h>
>
> / {
> model = "Khadas vim4";
> @@ -45,6 +47,94 @@ xtal: xtal-clk {
> #clock-cells = <0>;
> };
>
> + dc_in: regulator-dc-in {
> + compatible = "regulator-fixed";
> + regulator-name = "DC_IN";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +
> + sd_3v3: regulator-sdcard-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "SD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
> + regulator-boot-on;
> + enable-active-low;
> + regulator-always-on;
> + };
> +
> + vcc5v: regulator-vcc-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_in>;
> +
> + gpio = <&gpio GPIOH_4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vcc5v0_usb: regulator-vcc-usb {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V0_USB";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v>;
> +
> + gpio = <&gpio GPIOY_5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vddao_1v8: regulator-vddao-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddao_3v3: regulator-vddao-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&dc_in>;
> + regulator-always-on;
> + };
> +
> + vddio_1v8: regulator-vddio-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddio_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_3v3: regulator-vddio-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_c: regulator-gpio-c {
> + compatible = "regulator-gpio";
> + regulator-name = "VDDIO_C";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddio_3v3>;
> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
> + states = <1800000 1
> + 3300000 0>;
> + };
> };
>
> &uart_a {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ 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