* [PATCH 2/2] ASoC: uniphier: aio-dma: Use guard() for spin locks
From: phucduc.bui @ 2026-04-29 9:16 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Jaroslav Kysela, Takashi Iwai, Kunihiko Hayashi, Masami Hiramatsu,
Kuninori Morimoto, Joris Verhaegen, Miller Liang, linux-sound,
linux-arm-kernel, linux-kernel, bui duc phuc
In-Reply-To: <20260429091614.96667-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/uniphier/aio-dma.c | 52 ++++++++++++++++--------------------
1 file changed, 23 insertions(+), 29 deletions(-)
diff --git a/sound/soc/uniphier/aio-dma.c b/sound/soc/uniphier/aio-dma.c
index c1ca55997103..c01eae55d4fc 100644
--- a/sound/soc/uniphier/aio-dma.c
+++ b/sound/soc/uniphier/aio-dma.c
@@ -32,15 +32,15 @@ static void aiodma_pcm_irq(struct uniphier_aio_sub *sub)
runtime->channels * samples_to_bytes(runtime, 1);
int ret;
- spin_lock(&sub->lock);
- ret = aiodma_rb_set_threshold(sub, runtime->dma_bytes,
- sub->threshold + bytes);
- if (!ret)
- sub->threshold += bytes;
-
- aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes, bytes);
- aiodma_rb_clear_irq(sub);
- spin_unlock(&sub->lock);
+ scoped_guard(spinlock, &sub->lock) {
+ ret = aiodma_rb_set_threshold(sub, runtime->dma_bytes,
+ sub->threshold + bytes);
+ if (!ret)
+ sub->threshold += bytes;
+
+ aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes, bytes);
+ aiodma_rb_clear_irq(sub);
+ }
snd_pcm_period_elapsed(sub->substream);
}
@@ -51,15 +51,15 @@ static void aiodma_compr_irq(struct uniphier_aio_sub *sub)
int bytes = runtime->fragment_size;
int ret;
- spin_lock(&sub->lock);
- ret = aiodma_rb_set_threshold(sub, sub->compr_bytes,
- sub->threshold + bytes);
- if (!ret)
- sub->threshold += bytes;
+ scoped_guard(spinlock, &sub->lock) {
+ ret = aiodma_rb_set_threshold(sub, sub->compr_bytes,
+ sub->threshold + bytes);
+ if (!ret)
+ sub->threshold += bytes;
- aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
- aiodma_rb_clear_irq(sub);
- spin_unlock(&sub->lock);
+ aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
+ aiodma_rb_clear_irq(sub);
+ }
snd_compr_fragment_elapsed(sub->cstream);
}
@@ -113,18 +113,16 @@ static int uniphier_aiodma_prepare(struct snd_soc_component *component,
struct uniphier_aio_sub *sub = &aio->sub[substream->stream];
int bytes = runtime->period_size *
runtime->channels * samples_to_bytes(runtime, 1);
- unsigned long flags;
int ret;
ret = aiodma_ch_set_param(sub);
if (ret)
return ret;
- spin_lock_irqsave(&sub->lock, flags);
- ret = aiodma_rb_set_buffer(sub, runtime->dma_addr,
- runtime->dma_addr + runtime->dma_bytes,
- bytes);
- spin_unlock_irqrestore(&sub->lock, flags);
+ scoped_guard(spinlock_irqsave, &sub->lock)
+ ret = aiodma_rb_set_buffer(sub, runtime->dma_addr,
+ runtime->dma_addr + runtime->dma_bytes,
+ bytes);
if (ret)
return ret;
@@ -141,9 +139,8 @@ static int uniphier_aiodma_trigger(struct snd_soc_component *component,
struct device *dev = &aio->chip->pdev->dev;
int bytes = runtime->period_size *
runtime->channels * samples_to_bytes(runtime, 1);
- unsigned long flags;
- spin_lock_irqsave(&sub->lock, flags);
+ guard(spinlock_irqsave)(&sub->lock);
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes,
@@ -161,7 +158,6 @@ static int uniphier_aiodma_trigger(struct snd_soc_component *component,
dev_warn(dev, "Unknown trigger(%d) ignored\n", cmd);
break;
}
- spin_unlock_irqrestore(&sub->lock, flags);
return 0;
}
@@ -176,17 +172,15 @@ static snd_pcm_uframes_t uniphier_aiodma_pointer(
struct uniphier_aio_sub *sub = &aio->sub[substream->stream];
int bytes = runtime->period_size *
runtime->channels * samples_to_bytes(runtime, 1);
- unsigned long flags;
snd_pcm_uframes_t pos;
- spin_lock_irqsave(&sub->lock, flags);
+ guard(spinlock_irqsave)(&sub->lock);
aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes, bytes);
if (sub->swm->dir == PORT_DIR_OUTPUT)
pos = bytes_to_frames(runtime, sub->rd_offs);
else
pos = bytes_to_frames(runtime, sub->wr_offs);
- spin_unlock_irqrestore(&sub->lock, flags);
return pos;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/3] interconnect: qcom: Restrict drivers per ARM/ARM64
From: Konrad Dybcio @ 2026-04-29 9:21 UTC (permalink / raw)
To: Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel
In-Reply-To: <20260428-interconnect-qcom-clean-arm64-v1-2-e6bc3f7832db@oss.qualcomm.com>
On 4/28/26 7:32 PM, Krzysztof Kozlowski wrote:
> There is no point to allow selecting core SoC drivers like interconnects
> for Qualcomm ARMv7 SoCs when building ARM64 kernel, and vice versa.
>
> This makes kernel configuration more difficult as many do not remember
> the Qualcomm SoCs model names/numbers and their properties like
> architecture. No features should be lost because:
> 1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
> 2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Daniel Baluta @ 2026-04-29 9:26 UTC (permalink / raw)
To: Joseph Guo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
qijian.guo, justin.jiang
In-Reply-To: <20260428-imx95_frdm_pro-v2-2-434240b652f4@nxp.com>
[snip]
> +
> +&flexcan1 {
> + phys = <&flexcan1_phy>;
> + pinctrl-0 = <&pinctrl_flexcan1>;
> + pinctrl-names = "default";
> + status = "disabled";
> +};
Why add this if it is disabled?
^ permalink raw reply
* Re: [PATCH 3/3] interconnect: qcom: Make important drivers default
From: Konrad Dybcio @ 2026-04-29 9:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel
In-Reply-To: <20260428-interconnect-qcom-clean-arm64-v1-3-e6bc3f7832db@oss.qualcomm.com>
On 4/28/26 7:32 PM, Krzysztof Kozlowski wrote:
> The interconnect drivers for Qualcomm SoC Network-on-Chip are covering a
> basic or fundamental SoC feature: bandwidth management between internal
> SoC blocks. SoC can boot without these, but power management or
> performance will be affected. These drivers do not represent any sort
> of buses visible to the board designers/configurators, thus they should
> be always enabled, regardless how SoC is used in the final board.
>
> Kernel configuration should not ask users choice of drivers when that
> choice is obvious and known to the developers that answer should be
> 'yes' or 'module'.
I'd say let's make them all `default ARCH_QCOM` - all of these drivers
are required to boot (minus the OSM_L3 driver which is "only" highly
desired, so that your CPU's bus isn't heavily bottlenecked)
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Joseph Guo (OSS) @ 2026-04-29 9:26 UTC (permalink / raw)
To: Daniel Baluta, Joseph Guo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
justin.jiang
In-Reply-To: <d0dc01c7-dba1-4f25-88ea-a0840559cf38@oss.nxp.com>
On 4/29/2026 5:26 PM, Daniel Baluta wrote:
> [snip]
>
>> +
>> +&flexcan1 {
>> + phys = <&flexcan1_phy>;
>> + pinctrl-0 = <&pinctrl_flexcan1>;
>> + pinctrl-names = "default";
>> + status = "disabled";
>> +};
>
> Why add this if it is disabled?
Hi Daniel,
The resource of flexcan1 in System Manager is assign to M7 by default. But it is useful if we assign the resource back to A55.
The board hardware have the output pin of flexcan1, so I keep the node here but set it disabled by default.
Regards,
Joseph
^ permalink raw reply
* Re: [PATCH] arch: arm64: fix KERNEL_SEGMENT_COUNT error
From: Ard Biesheuvel @ 2026-04-29 9:27 UTC (permalink / raw)
To: zhaoyang.huang, Catalin Marinas, Will Deacon, linux-arm-kernel,
linux-kernel, Zhaoyang Huang, steve.kang
In-Reply-To: <20260429061752.2880923-1-zhaoyang.huang@unisoc.com>
Hello Zhaoyang,
On Wed, 29 Apr 2026, at 08:17, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> During debug of a kernel panic, we find that the pte_t of the final
> part of [data, end] segment got overflow to the next page of
> init_pg_end[1] which is the gap page before early_init_stack[2].
> This should be introduced by the KERNEL_SEGMENT_COUNT's value is 5
> which should be 6 as map_segment are called 6 times for the segments
> of (text, stext, rodata, inittext, initdata, data+bss)
>
> [1]
> crash_arm64_v9.0.1> vtop ffffffed00601000
> VIRTUAL PHYSICAL
> ffffffed00601000 83401000
>
> PAGE DIRECTORY: ffffffecffd62000
> PGD: ffffffecffd62da0 => 10000000833fb003
> PMD: ffffff80033fb018 => 10000000833fe003
> PTE: ffffff80033fe008 => 68000083401f03
> PAGE: 83401000
>
> PTE PHYSICAL FLAGS
> 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> fffffffec00d0040 83401000 0 0 1 4000 reserved
>
> [2]
> ffffffed002c8000 (r) __pi__data
> ffffffed0054e000 (d) __pi___bss_start
> ffffffed005f5000 (b) __pi_init_pg_dir
> ffffffed005fe000 (b) __pi_init_pg_end
> ffffffed005ff000 (B) early_init_stack
> ffffffed00608000 (b) __pi__end
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
> arch/arm64/include/asm/kernel-pgtable.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kernel-pgtable.h
> b/arch/arm64/include/asm/kernel-pgtable.h
> index 74a4f738c5f5..14dd1c52552a 100644
> --- a/arch/arm64/include/asm/kernel-pgtable.h
> +++ b/arch/arm64/include/asm/kernel-pgtable.h
> @@ -64,8 +64,8 @@
> #define INIT_IDMAP_FDT_PAGES (EARLY_PAGES(INIT_IDMAP_PGTABLE_LEVELS,
> 0UL, UL(MAX_FDT_SIZE), 1) - 1)
> #define INIT_IDMAP_FDT_SIZE ((INIT_IDMAP_FDT_PAGES +
> EARLY_IDMAP_EXTRA_FDT_PAGES) * PAGE_SIZE)
>
> -/* The number of segments in the kernel image (text, rodata, inittext,
> initdata, data+bss) */
> -#define KERNEL_SEGMENT_COUNT 5
> +/* The number of segments in the kernel image (text, stext, rodata,
> inittext, initdata, data+bss) */
> +#define KERNEL_SEGMENT_COUNT 6
>
> #if SWAPPER_BLOCK_SIZE > SEGMENT_ALIGN
> #define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 1)
I think the better fix would be
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -68,7 +68,7 @@
#define KERNEL_SEGMENT_COUNT 5
#if SWAPPER_BLOCK_SIZE > SEGMENT_ALIGN
-#define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 1)
+#define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 2)
/*
* The initial ID map consists of the kernel image, mapped as two separate
* segments, and may appear misaligned wrt the swapper block size. This means
and add a line
Fixes: 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only")
^ permalink raw reply
* Re: [PATCH 1/4] soc: qcom: Hide all drivers behind selectable menu
From: Konrad Dybcio @ 2026-04-29 9:28 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel
In-Reply-To: <20260429-qcom-soc-kconfig-v1-1-69ba540b3fe9@oss.qualcomm.com>
On 4/29/26 10:56 AM, Krzysztof Kozlowski wrote:
> Switch from a simple menu to menuconfig, so all Qualcomm SoC drivers
> will be under one selectable option, allowing to disable them all which
> should make kernel configuration easier when preparing a non-Qualcomm
> kernel.
>
> This has few benefits (functional impact of this commit):
>
> 1. Allow compile testing of QCOM_OCMEM, which previously required
> ARCH_QCOM.
>
> 2. Hide behind ARCH_QCOM or COMPILE_TEST drivers specific to Qualcomm
> which should not be available to other kernel builds:
> QCOM_PMIC_PDCHARGER_ULOG, QCOM_PMIC_GLINK, QCOM_SPM and QCOM_PBS.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
[...]
> +# Options selected by other drivers from different subsystems must be outside
> +# of the menuconfig if-block:
> +
> +config QCOM_INLINE_CRYPTO_ENGINE
> + tristate
> + select QCOM_SCM
> +
> +config QCOM_MDT_LOADER
> + tristate
> + select QCOM_SCM
> +
> +config QCOM_PDR_HELPERS
> + tristate
> + select QCOM_QMI_HELPERS
> + select QCOM_PDR_MSG
> + depends on NET
> +
> +config QCOM_QMI_HELPERS
> + tristate
> + depends on NET
also:
QCOM_KRYO_L2_ACCESSORS -> drivers/perf/Kconfig
QCOM_SPM -> drivers/cpuidle/Kconfig.arm
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Daniel Baluta @ 2026-04-29 9:31 UTC (permalink / raw)
To: Joseph Guo (OSS), Joseph Guo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
justin.jiang
In-Reply-To: <bde82660-0550-4614-80a2-bf4f49b92063@oss.nxp.com>
On 4/29/26 12:26, Joseph Guo (OSS) wrote:
> On 4/29/2026 5:26 PM, Daniel Baluta wrote:
>> [snip]
>>
>>> +
>>> +&flexcan1 {
>>> + phys = <&flexcan1_phy>;
>>> + pinctrl-0 = <&pinctrl_flexcan1>;
>>> + pinctrl-names = "default";
>>> + status = "disabled";
>>> +};
>>
>> Why add this if it is disabled?
>
> Hi Daniel,
>
> The resource of flexcan1 in System Manager is assign to M7 by default. But it is useful if we assign the resource back to A55.
> The board hardware have the output pin of flexcan1, so I keep the node here but set it disabled by default.
Well then at least add a comment above to explain this.
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Joseph Guo (OSS) @ 2026-04-29 9:29 UTC (permalink / raw)
To: Daniel Baluta, Joseph Guo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
justin.jiang
In-Reply-To: <f7257d2d-61d8-42e1-b589-874da203d851@oss.nxp.com>
On 4/29/2026 5:31 PM, Daniel Baluta wrote:
> On 4/29/26 12:26, Joseph Guo (OSS) wrote:
>> On 4/29/2026 5:26 PM, Daniel Baluta wrote:
>>> [snip]
>>>
>>>> +
>>>> +&flexcan1 {
>>>> + phys = <&flexcan1_phy>;
>>>> + pinctrl-0 = <&pinctrl_flexcan1>;
>>>> + pinctrl-names = "default";
>>>> + status = "disabled";
>>>> +};
>>>
>>> Why add this if it is disabled?
>>
>> Hi Daniel,
>>
>> The resource of flexcan1 in System Manager is assign to M7 by default. But it is useful if we assign the resource back to A55.
>> The board hardware have the output pin of flexcan1, so I keep the node here but set it disabled by default.
>
> Well then at least add a comment above to explain this.
Thanks to point out this. Will add comment in next version.
Regards,
Joseph
^ permalink raw reply
* Re: [PATCH v2] arm: mediatek: MAINTAINERS: Include SoC bindings
From: AngeloGioacchino Del Regno @ 2026-04-29 9:42 UTC (permalink / raw)
To: Krzysztof Kozlowski, Matthias Brugger, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <bb0e5f69-d451-4d95-8a4e-38d18582ccb2@oss.qualcomm.com>
Il 28/04/26 17:07, Krzysztof Kozlowski ha scritto:
> On 29/03/2026 10:53, Krzysztof Kozlowski wrote:
>> The ARM/ARM64 Mediatek SoC maintainer entry misses bindings directory
>> for SoC devices.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> FYI, there are already patches on the list which used get_maintainers.pl
>> script and did not CC Mediatek maintainers, so they might get
>> forgotten/missed.
>>
>
> This patch did not receive any comments from Mediatek maintainers - do
> you plan to apply it?
>
> Best regards,
> Krzysztof
Sorry, pretty-crazy-busy days around here.
I can take it or if Arnd wants to take that directly, I'm as well fine.
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v3 3/3] ARM: at91: remove unnecessary of_platform_default_populate calls
From: Miquel Raynal @ 2026-04-29 9:42 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Russell King, linux-mtd,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260429-lushly-greasily-c14c01c1aee8@thorsis.com>
Hi Alexander,
> [ 0.958298] bus: 'platform': add driver atmel-ebi
> [ 0.958451] platform 10000000.ebi: bus: 'platform': __driver_probe_device: matched device with driver atmel-ebi
> [ 0.958566] platform 10000000.ebi: error -EPROBE_DEFER: wait for supplier /ahb/apb/pinctrl@fffff400/ebi/ebi-data-lsb
> [ 0.958649] platform 10000000.ebi: Added to deferred list
> [ 0.959429] bus: 'platform': remove driver atmel-ebi
> [ 0.959540] driver: 'atmel-ebi': driver_release
Interesting.
If you look at the very last line of the driver, the EBI driver does not
use a standard "module_platform_driver" macro, it uses some kind of
run-once probe that is kept in an __init section:
https://elixir.bootlin.com/linux/v7.0.1/source/drivers/memory/atmel-ebi.c#L637
And this seems to be incompatible with probe deferrals:
https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/platform.c#L948
I would suggest trying something alone these lines:
--- a/drivers/memory/atmel-ebi.c
+++ b/drivers/memory/atmel-ebi.c
@@ -633,5 +633,6 @@ static struct platform_driver atmel_ebi_driver = {
.of_match_table = atmel_ebi_id_table,
.pm = &atmel_ebi_pm_ops,
},
+ .probe = atmel_ebi_probe,
};
-builtin_platform_driver_probe(atmel_ebi_driver, atmel_ebi_probe);
+builtin_platform_driver(atmel_ebi_driver);
Memory taken by the probe function will remain mapped. That seems to be
the drawback.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH v8 0/3] pinctrl: aspeed: Add AST2700 SoC0 support
From: Billy Tsai @ 2026-04-29 9:44 UTC (permalink / raw)
To: Stephen Boyd, Andrew Jeffery, Bartosz Golaszewski, Conor Dooley,
Joel Stanley, Krzysztof Kozlowski, Lee Jones, Linus Walleij,
Rob Herring, Ryan Chen
Cc: Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <177742778029.5403.7247019083523002317@localhost.localdomain>
> > AST2700 is composed of two interconnected SoC instances, each providing
> > its own pin control hardware. This series introduces bindings describing
> > the AST2700 pinctrl architecture and adds pinctrl driver support for the
> > SoC0 instance.
> >
> > The bindings document the AST2700 dual-SoC design and follow common
> > pinctrl conventions, while the SoC0 driver implementation builds upon
> > the existing ASPEED pinctrl infrastructure.
> >
> > ---
> Why is this being Cc'ed to linux-clk? I'm hoping it's a manual typo and
> not some sort of misconfiguration in ./scripts/get_maintainer.pl,
> please?
This was automatically added by b4 prep --auto-to-cc. According to the
output of ./scripts/get_maintainer.pl for the patch `[PATCH 2/3]
dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0`,
linux-clk@vger.kernel.org is included in the Cc list.
Thanks
Billy Tsai
^ permalink raw reply
* [PATCH 1/9] dt-bindings: mfd: mediatek: mt6397: Add rtc for MT6359
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
The rtc block of MT6359 PMIC is compatible with the one found in MT6358
but this compatibility was never expressed in the dt-bindings, so add
the missing compatible string for the rtc subnode.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..dc2b38cf285d 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -70,6 +70,7 @@ properties:
- mediatek,mt6397-rtc
- items:
- enum:
+ - mediatek,mt6359-rtc
- mediatek,mt6366-rtc
- const: mediatek,mt6358-rtc
--
2.54.0
^ permalink raw reply related
* [PATCH 0/9] MT6365 PMIC support cleanup
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
Several Mediatek and Radxa boards, based on MT8370, MT8390 or MT8395
SoC, integrate the MT6365 PMIC, that is a MT6359P variant:
- Mediatek Genio 1200-EVK
- Mediatek Genio 700-EVK
- Mediatek Genio 510-EVK
- Radxa NIO-12L
It is compatible with the MT6359 PMIC.
But both MT6365 PMIC support and compatibility were never expressed in
the dt-bindings and there is no MT6365 include file as well.
So, since these board support was introduced, their devicetrees use the
mt6359 include file to enable this PMIC support.
The goal of this series is to clean this support by adding the missing
compatible strings for this MFD main and subdevices in the dt-bindings,
and add a include for MT6365 definitions to replace the MT6359 include
in these board devicetrees and for future ones (like Genio 520/720
EVKs).
The series is based on linux-next tree (tag: next-20260428) and has
been tested on Mediatek Genio 510, 700 and 1200-EVK boards.
---
Louis-Alexis Eyraud (9):
dt-bindings: mfd: mediatek: mt6397: Add rtc for MT6359
dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
arm64: dts: mediatek: mt6359: use proper compatible for rtc
arm64: dts: mediatek: add MT6365 PMIC include
arm64: dts: mediatek: mt8390-genio-common: use MT6365 PMIC definitions
arm64: dts: mediatek: mt8395-genio-common: use MT6365 PMIC definitions
arm64: dts: mediatek: mt8395-radxa-nio-12l: use MT6365 PMIC definitions
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 17 +++++++++-----
.../bindings/input/mediatek,pmic-keys.yaml | 21 ++++++++++-------
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 14 ++++++++++++
arch/arm64/boot/dts/mediatek/mt6359.dtsi | 4 ++--
arch/arm64/boot/dts/mediatek/mt6365.dtsi | 26 ++++++++++++++++++++++
.../boot/dts/mediatek/mt8390-genio-common.dtsi | 8 +++----
.../boot/dts/mediatek/mt8395-genio-common.dtsi | 8 +++----
.../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 6 ++---
8 files changed, 77 insertions(+), 27 deletions(-)
---
base-commit: 0f3ef35b0747832b58b97171bad99011d084c6b1
change-id: 20260428-mediatek-genio-mt6365-cleanup-6cdd84c3f098
Best regards,
--
Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
^ permalink raw reply
* [PATCH 2/9] dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
MT6365 PMIC is compatible with MT6359, so add the compatible strings
for the main and sub devices (regulator, rtc, audio codec).
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index dc2b38cf285d..122aba7a54f8 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -44,6 +44,10 @@ properties:
- enum:
- mediatek,mt6366
- const: mediatek,mt6358
+ - items:
+ - enum:
+ - mediatek,mt6365
+ - const: mediatek,mt6359
interrupts:
maxItems: 1
@@ -71,6 +75,7 @@ properties:
- items:
- enum:
- mediatek,mt6359-rtc
+ - mediatek,mt6365-rtc
- mediatek,mt6366-rtc
- const: mediatek,mt6358-rtc
@@ -99,6 +104,10 @@ properties:
- enum:
- mediatek,mt6366-regulator
- const: mediatek,mt6358-regulator
+ - items:
+ - enum:
+ - mediatek,mt6365-regulator
+ - const: mediatek,mt6359-regulator
required:
- compatible
@@ -125,6 +134,10 @@ properties:
- enum:
- mediatek,mt6366-sound
- const: mediatek,mt6358-sound
+ - items:
+ - enum:
+ - mediatek,mt6365-codec
+ - const: mediatek,mt6359-codec
required:
- compatible
--
2.54.0
^ permalink raw reply related
* [PATCH 3/9] dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
Add compatible string for the pmic keys block found on the MT6365 PMIC,
that is compatible with the one found in MT6359.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
.../bindings/input/mediatek,pmic-keys.yaml | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
index b95435bd6a9b..140a862ecfbe 100644
--- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
+++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
@@ -23,14 +23,19 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt6323-keys
- - mediatek,mt6328-keys
- - mediatek,mt6331-keys
- - mediatek,mt6357-keys
- - mediatek,mt6358-keys
- - mediatek,mt6359-keys
- - mediatek,mt6397-keys
+ oneOf:
+ - enum:
+ - mediatek,mt6323-keys
+ - mediatek,mt6328-keys
+ - mediatek,mt6331-keys
+ - mediatek,mt6357-keys
+ - mediatek,mt6358-keys
+ - mediatek,mt6359-keys
+ - mediatek,mt6397-keys
+ - items:
+ - enum:
+ - mediatek,mt6365-keys
+ - const: mediatek,mt6359-keys
power-off-time-sec: true
--
2.54.0
^ permalink raw reply related
* [PATCH 4/9] dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
Add compatible string for the AuxADC block found on the MT6365 PMIC,
that is compatible with the one found in MT6359.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
index 5d4ab701f51a..9936aa605c7b 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -18,12 +18,17 @@ description:
properties:
compatible:
- enum:
- - mediatek,mt6357-auxadc
- - mediatek,mt6358-auxadc
- - mediatek,mt6359-auxadc
- - mediatek,mt6363-auxadc
- - mediatek,mt6373-auxadc
+ oneOf:
+ - enum:
+ - mediatek,mt6357-auxadc
+ - mediatek,mt6358-auxadc
+ - mediatek,mt6359-auxadc
+ - mediatek,mt6363-auxadc
+ - mediatek,mt6373-auxadc
+ - items:
+ - enum:
+ - mediatek,mt6365-auxadc
+ - const: mediatek,mt6359-auxadc
"#io-channel-cells":
const: 1
--
2.54.0
^ permalink raw reply related
* [PATCH 5/9] arm64: dts: mediatek: mt6359: use proper compatible for rtc
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
The MT6359 PMIC include file uses directly "mediatek,mt6358-rtc"
compatible string for the rtc subnode, but not its own compatible
string.
Now that the "mediatek,mt6359-rtc" compatible is properly declared in
the dt-bindings, use it with "mediatek,mt6358-rtc" as fallback.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt6359.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt6359.dtsi b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
index 45ad69ee49ed..c279b3372eda 100644
--- a/arch/arm64/boot/dts/mediatek/mt6359.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
@@ -19,7 +19,7 @@ mt6359codec: audio-codec {
compatible = "mediatek,mt6359-codec";
};
- regulators {
+ mt6359regulators: regulators {
compatible = "mediatek,mt6359-regulator";
mt6359_vs1_buck_reg: buck_vs1 {
@@ -301,7 +301,7 @@ mt6359_vsram_others_sshub_ldo: ldo_vsram_others_sshub {
};
mt6359rtc: rtc {
- compatible = "mediatek,mt6358-rtc";
+ compatible = "mediatek,mt6359-rtc", "mediatek,mt6358-rtc";
};
};
};
--
2.54.0
^ permalink raw reply related
* [PATCH 6/9] arm64: dts: mediatek: add MT6365 PMIC include
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
The MT6365 PMIC, compatible with MT6359 PMIC, never had its own include
file so the boards that integrates this PMIC used mt6359.dtsi in their
devicetree to enable its support.
So, add the mt6365 include file for the MT6365 definitions and labels.
In order not to duplicate all of them, make it include mt6359.dtsi and
override the compatible strings for the MFD main and sub devices with
the MT6365 ones.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt6365.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt6365.dtsi b/arch/arm64/boot/dts/mediatek/mt6365.dtsi
new file mode 100644
index 000000000000..ed4e349f63c9
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6365.dtsi
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2026 MediaTek Inc.
+ */
+
+#include "mt6359.dtsi"
+
+&pmic {
+ compatible = "mediatek,mt6365", "mediatek,mt6359";
+};
+
+&pmic_adc {
+ compatible = "mediatek,mt6365-auxadc", "mediatek,mt6359-auxadc";
+};
+
+mt6365codec: &mt6359codec {
+ compatible = "mediatek,mt6365-codec", "mediatek,mt6359-codec";
+};
+
+mt6365regulators: &mt6359regulators {
+ compatible = "mediatek,mt6365-regulator", "mediatek,mt6359-regulator";
+};
+
+mt6365rtc: &mt6359rtc{
+ compatible = "mediatek,mt6365-rtc", "mediatek,mt6358-rtc";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH 7/9] arm64: dts: mediatek: mt8390-genio-common: use MT6365 PMIC definitions
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
Mediatek Genio 510 and 700 EVK boards integrate a MT6365 PMIC,
compatible with MT6359, but the board common definition include file
used the mt6359.dtsi to enable its support since the board support was
introduced.
Now that mt6365.dtsi has been created, include it instead of mt6359.dtsi
and use MT6365 labels and pmic key compatible too.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi b/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
index 2062506f6cc5..5303add717bf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
@@ -10,7 +10,7 @@
* AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
*/
-#include "mt6359.dtsi"
+#include "mt6365.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
@@ -695,7 +695,7 @@ &mt6359_vufs_ldo_reg {
regulator-always-on;
};
-&mt6359codec {
+&mt6365codec {
mediatek,mic-type-0 = <1>; /* ACC */
mediatek,mic-type-1 = <3>; /* DCC */
};
@@ -1281,8 +1281,8 @@ &pmic {
interrupt-parent = <&pio>;
interrupts = <222 IRQ_TYPE_LEVEL_HIGH>;
- mt6359keys: keys {
- compatible = "mediatek,mt6359-keys";
+ mt6365keys: keys {
+ compatible = "mediatek,mt6365-keys", "mediatek,mt6359-keys";
mediatek,long-press-mode = <1>;
power-off-time-sec = <0>;
--
2.54.0
^ permalink raw reply related
* [PATCH 9/9] arm64: dts: mediatek: mt8395-radxa-nio-12l: use MT6365 PMIC definitions
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
Radxa NIO-12L EVK board integrates a MT6365 PMIC, compatible with
MT6359, but its devicetree used mt6359.dtsi to enable its support since
the board support was introduced.
Now that mt6365.dtsi has been created, include it instead of mt6359.dtsi
and use MT6365 labels and pmic key compatible too.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index bf91305e8e4a..8bd3b3250b87 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -6,7 +6,7 @@
*/
#include "mt8195.dtsi"
-#include "mt6359.dtsi"
+#include "mt6365.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
@@ -1034,8 +1034,8 @@ &pciephy {
&pmic {
interrupts-extended = <&pio 222 IRQ_TYPE_LEVEL_HIGH>;
- mt6359keys: keys {
- compatible = "mediatek,mt6359-keys";
+ mt6365keys: keys {
+ compatible = "mediatek,mt6365-keys", "mediatek,mt6359-keys";
mediatek,long-press-mode = <1>;
power-off-time-sec = <0>;
--
2.54.0
^ permalink raw reply related
* [PATCH 8/9] arm64: dts: mediatek: mt8395-genio-common: use MT6365 PMIC definitions
From: Louis-Alexis Eyraud @ 2026-04-29 9:44 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio, Louis-Alexis Eyraud
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
Mediatek Genio 1200 EVK board integrates a MT6365 PMIC, compatible
with MT6359, but the board common definition include file (for the eMMC
and UFS configurations) used the mt6359.dtsi to enable its support
since the board support was introduced.
Now that mt6365.dtsi has been created, include it instead of mt6359.dtsi
and use MT6365 labels and pmic key compatible too.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8395-genio-common.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-genio-common.dtsi b/arch/arm64/boot/dts/mediatek/mt8395-genio-common.dtsi
index 62c336e21500..6df614c471fc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-genio-common.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8395-genio-common.dtsi
@@ -7,7 +7,7 @@
/dts-v1/;
#include "mt8195.dtsi"
-#include "mt6359.dtsi"
+#include "mt6365.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
@@ -728,7 +728,7 @@ &mt6359_vsram_others_ldo_reg {
regulator-max-microvolt = <750000>;
};
-&mt6359codec {
+&mt6365codec {
mediatek,mic-type-0 = <1>; /* ACC */
mediatek,mic-type-1 = <3>; /* DCC */
mediatek,mic-type-2 = <1>; /* ACC */
@@ -1151,8 +1151,8 @@ pins {
&pmic {
interrupts-extended = <&pio 222 IRQ_TYPE_LEVEL_HIGH>;
- mt6359keys: keys {
- compatible = "mediatek,mt6359-keys";
+ mt6365keys: keys {
+ compatible = "mediatek,mt6365-keys", "mediatek,mt6359-keys";
mediatek,long-press-mode = <1>;
power-off-time-sec = <0>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v21 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-04-29 9:45 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki,
Daniel Lezcano, Christian Loehle, Ulf Hansson, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <d6112b9c-01ea-483c-98fe-b480e78872e5@oss.qualcomm.com>
On 28-04-2026 18:33, Shivendra Pratap wrote:
>
>
> On 28-04-2026 18:21, Bartosz Golaszewski wrote:
>> On Tue, Apr 28, 2026 at 2:18 PM Shivendra Pratap
>> <shivendra.pratap@oss.qualcomm.com> wrote:
>>>
>>>
>>>
>>> On 28-04-2026 13:33, Bartosz Golaszewski wrote:
>>>> On Mon, 27 Apr 2026 19:34:48 +0200, Shivendra Pratap
>>>> <shivendra.pratap@oss.qualcomm.com> said:
>>>>> MFD core has no way to register a child device using an explicit
>>>>> firmware
>>>>> node. This prevents drivers from registering child nodes when those
>>>>> nodes
>>>>> do not define a compatible string. One such example is the PSCI
>>>>> "reboot-mode" node, which omits a compatible string as it describes
>>>>> boot-states provided by the underlying firmware.
>>>>>
>>>>> Extend struct mfd_cell with an optional fwnode pointer and attach
>>>>> it to the
>>>>> child device during registration when no firmware node is already
>>>>> assigned.
>>>>>
>>>>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> In the following patch you use this and violate the supposed
>>>> constness of
>>>> MFD cells. This also mean you need to modify the mfd_cell at run-
>>>> time. I would
>>>> prefer introducing a field in mfd_cell: bool use_parent_fwnode which
>>>> would
>>>> indicate to MFD core that - in case no fwnode was assigned from
>>>> other sources:
>>>> DT or software node - it should reuse the parent MFD device's node.
>>>
>>> Have one doubt on this, When we fallback to use_parent_fwnode for cell:
>>> psci-reboot-mode, at psci_reboot_mode_probe(), pDev->dev->of_node point
>>> to psci node.
>>>
>>> But we want dev->of_node to point to "reboot-mode" node. This may need
>>> an explicit assignment again of of_node?
>>>
>>
>> Ah, sorry you're right. I'd like to avoid having to modify the
>> mfd_cell entry at run-time if possible.
>>
>> How about a callback in mfd_cell like:
>>
>> struct fwnode_handle *(*get_fwnode)(struct device *parent);
>>
>> If set, it would be called from MFD core and would do the name lookup
>> and return the fwnode which would then be assigned to the cell device?
>
Or should we just drop this patch for fwnode in mfd-core?
Export a new call in reboot-mode framework as:
reboot_mode_register_node(struct reboot_mode_driver *reboot,
struct device_node *np / fwnode)
Use the parent node in psci-reboot-mode and find reboot-mode and call
reboot_mode_register_node?
thanks,
Shivendra
> sure. thanks. We can make it a callback from MFD core.
>
> thanks,
> Shivendra
^ permalink raw reply
* Re: [PATCH v8 next 00/10] arm_mpam: Introduce Narrow-PARTID feature
From: Zeng Heng @ 2026-04-29 9:47 UTC (permalink / raw)
To: Shaopeng Tan (Fujitsu), ben.horgan@arm.com, Dave.Martin@arm.com,
james.morse@arm.com, reinette.chatre@intel.com,
fenghuay@nvidia.com, tglx@kernel.org, will@kernel.org,
hpa@zytor.com, bp@alien8.de, babu.moger@amd.com,
dave.hansen@linux.intel.com, mingo@redhat.com,
tony.luck@intel.com, gshan@redhat.com, catalin.marinas@arm.com,
TY4PR01MB16930EB1ACB3A3356A92169BC8B232@TY4PR01MB16930.jpnprd01.prod.outlook.com
Cc: linux-arm-kernel@lists.infradead.org, x86@kernel.org,
linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com
In-Reply-To: <TY4PR01MB169309175E789FEDACA22619F8B372@TY4PR01MB16930.jpnprd01.prod.outlook.com>
Hi Shaopeng,
On 2026/4/28 12:20, Shaopeng Tan (Fujitsu) wrote:
> Hello Zeng Heng,
>
>
> I hope this email finds you well.
>
>> As indicated in the patch series tags, this patch set applies to the
>> linux-next repository, specifically the master branch at:
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
>
> This patch series could not be applied correctly to the master branch.
>
Thank you very much for your reply.
I checked the patch and found that patch 2 has the following context
conflict, which is not a logical conflict:
~~~
diff a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
(rejected hunks)
@@ -223,7 +223,7 @@ int resctrl_arch_set_cdp_enabled(enum
resctrl_res_level rid, bool enable)
mpam_resctrl_controls[RDT_RESOURCE_MBA].resctrl_res.alloc_capable =
false;
if (enable) {
- if (mpam_partid_max < 1)
+ if (mpam_intpartid_max < 1)
return -EINVAL;
partid_d = resctrl_get_config_index(RESCTRL_RESERVED_CLOSID, CDP_DATA);
~~~
This conflict is caused by the following commit:
~~~
commit f758340da529ccb12531c3f83d5992e912f6c8d5
Author: Zeng Heng <zengheng4@huawei.com>
Date: Mon Apr 13 17:00:41 2026 +0800
arm_mpam: resctrl: Fix MBA CDP alloc_capable handling on unmount
~~~
This is merely a context conflict. Please feel free to resolve it
locally for now, or I will fix this patch conflict in the next version
as soon as possible.
Apart from this, the remaining patches apply cleanly against the latest
linux-next or linux mainline tree.
>
>> Keep me in the mail list for follow-up responses if you want my feedback
>> in time. I was accidentally dropped from the mail list in a previous
>> thread (see
>> https://lore.kernel.org/all/TY4PR01MB16930EB1ACB3A3356A92169BC8B232@TY4PR01MB16930.jpnprd01.prod.outlook.com/).
>
> I've confirmed that your email address was correctly in the recipient field, and the email was sent successfully on my end.
> Also, it seems that I sometimes don't receive your emails.
> I'm not entirely sure why this is happening, as my email settings appear to be configured correctly.
>
>
From the lore archive records, it exactly appears that my email address
was indeed not included in the recipient list. Please double-check:
https://lore.kernel.org/all/TY4PR01MB16930EB1ACB3A3356A92169BC8B232@TY4PR01MB16930.jpnprd01.prod.outlook.com/
I believe this was simply a typo. And Looking forward to hearing from
you.
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH v21 08/13] mfd: core: Add firmware-node support to MFD cells
From: Bartosz Golaszewski @ 2026-04-29 9:50 UTC (permalink / raw)
To: Shivendra Pratap
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki,
Daniel Lezcano, Christian Loehle, Ulf Hansson, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <ce92a493-5016-41a2-8337-d2227cdf760a@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 11:46 AM Shivendra Pratap
<shivendra.pratap@oss.qualcomm.com> wrote:
>
> >>
> >> If set, it would be called from MFD core and would do the name lookup
> >> and return the fwnode which would then be assigned to the cell device?
> >
>
> Or should we just drop this patch for fwnode in mfd-core?
>
> Export a new call in reboot-mode framework as:
> reboot_mode_register_node(struct reboot_mode_driver *reboot,
> struct device_node *np / fwnode)
>
> Use the parent node in psci-reboot-mode and find reboot-mode and call
> reboot_mode_register_node?
>
No, I think the reboot-mode device (as pointed to by the dev field of
struct reboot_mode_driver) should be associated with the right fwnode
from the start so it should be handled in MFD core.
I'm of course open to other ideas on how to do it.
Bart
^ 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