* Re: [PATCH v2 00/10] sh: remove NUMA and SPARSEMEM support
From: John Paul Adrian Glaubitz @ 2026-06-14 12:32 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-sh, Andrew Morton, Arnd Bergmann, Rich Felker,
Yoshinori Sato, linux-kernel, linux-mm
In-Reply-To: <ai6Diz0UgSGccbhY@kernel.org>
Hi Mike,
On Sun, 2026-06-14 at 13:33 +0300, Mike Rapoport wrote:
> On Tue, Jun 09, 2026 at 09:21:37AM +0200, John Paul Adrian Glaubitz wrote:
> > Hi Mike,
> >
> > On Wed, 2026-06-03 at 18:32 +0300, Mike Rapoport wrote:
> > > On Mon, May 18, 2026 at 02:05:39PM +0200, John Paul Adrian Glaubitz wrote:
> > > > Hi Mike,
> > > >
> > > > On Mon, 2026-05-18 at 14:43 +0300, Mike Rapoport wrote:
> > > > > Gentle ping?
> > > >
> > > > It's on my TODO list for this week!
> > >
> > > It's sad to see this being dragged since mid April (if we count v1 and
> > > there were really minor changes in v2).
> >
> > I apologize. I am doing the maintenance as a hobby in my free time, it's
> > not my primary job and it can sometimes take me a bit longer to take up
> > changes.
> >
> > > If you don't have time to take care of that, just say so and we'll take
> > > this via one of the mm trees in the next cycle.
> >
> > It should be better this week. I've been recently busy with CVE fixes during
> > my dayjob and the workload was extremely high.
> >
> > I am not going to let this slip, don't worry. It's just been a bit too much
> > stress the past weeks due to the AI CVE reporting.
>
> I understand that this is a hobby for you and there are a day job and other
> obligations and you don't have time for timely responses for arch/sh
> patches.
>
> I just don't understand why do you insist on taking this via sh tree given
> you don't have the resources to timely deal with the patches.
Because I want to learn something in the process and also perform some basic
testing where possible. I know it takes longer and I can only ask for some
patience, but I will take are of it.
I will get these changes landed for 7.2, promised.
> This set can perfectly go via mm tree as it cleanups a memory management
> feature that should not have been added to sh at the first place.
I appreciate your efforts in cleaning up arch/sh, so I don't want to stress
your patience too much. Again, I will get this into 7.2. Don't worry!
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v2 00/10] sh: remove NUMA and SPARSEMEM support
From: Mike Rapoport @ 2026-06-14 10:33 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: linux-sh, Andrew Morton, Arnd Bergmann, Rich Felker,
Yoshinori Sato, linux-kernel, linux-mm
In-Reply-To: <865aaa7aa64ab69ca9020d64d86baa8d9b700bcb.camel@physik.fu-berlin.de>
Hi Adrian,
On Tue, Jun 09, 2026 at 09:21:37AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Mike,
>
> On Wed, 2026-06-03 at 18:32 +0300, Mike Rapoport wrote:
> > On Mon, May 18, 2026 at 02:05:39PM +0200, John Paul Adrian Glaubitz wrote:
> > > Hi Mike,
> > >
> > > On Mon, 2026-05-18 at 14:43 +0300, Mike Rapoport wrote:
> > > > Gentle ping?
> > >
> > > It's on my TODO list for this week!
> >
> > It's sad to see this being dragged since mid April (if we count v1 and
> > there were really minor changes in v2).
>
> I apologize. I am doing the maintenance as a hobby in my free time, it's
> not my primary job and it can sometimes take me a bit longer to take up
> changes.
>
> > If you don't have time to take care of that, just say so and we'll take
> > this via one of the mm trees in the next cycle.
>
> It should be better this week. I've been recently busy with CVE fixes during
> my dayjob and the workload was extremely high.
>
> I am not going to let this slip, don't worry. It's just been a bit too much
> stress the past weeks due to the AI CVE reporting.
I understand that this is a hobby for you and there are a day job and other
obligations and you don't have time for timely responses for arch/sh
patches.
I just don't understand why do you insist on taking this via sh tree given
you don't have the resources to timely deal with the patches.
This set can perfectly go via mm tree as it cleanups a memory management
feature that should not have been added to sh at the first place.
> Adrian
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH] sh: mm: Remove checks for nonexistent CONFIG_CPU_SUBTYPE_ST40
From: Ethan Nelson-Moore @ 2026-06-13 21:05 UTC (permalink / raw)
To: GitAuthor: Ethan Nelson-Moore, linux-sh
Cc: Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
The CONFIG_CPU_SUBTYPE_ST40 option was removed in commit f96691872439
("sh: Kill off the remaining ST40 cruft."), but a check for it remained
in arch/sh/include/cpu-sh4/cpu/mmu_context.h. Remove this dead code.
Also remove the definition of and references to the MMUCR_SE bit mask,
because it is defined as zero on all CPUs other than ST40.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/sh/include/cpu-sh4/cpu/mmu_context.h | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/sh/include/cpu-sh4/cpu/mmu_context.h b/arch/sh/include/cpu-sh4/cpu/mmu_context.h
index 421b56d5c595..4a6148e1ea84 100644
--- a/arch/sh/include/cpu-sh4/cpu/mmu_context.h
+++ b/arch/sh/include/cpu-sh4/cpu/mmu_context.h
@@ -43,12 +43,6 @@
#define MMUCR_URC 0x0000FC00
#define MMUCR_URC_SHIFT 10
-#if defined(CONFIG_32BIT) && defined(CONFIG_CPU_SUBTYPE_ST40)
-#define MMUCR_SE (1 << 4)
-#else
-#define MMUCR_SE (0)
-#endif
-
#ifdef CONFIG_CPU_HAS_PTEAEX
#define MMUCR_AEX (1 << 6)
#else
@@ -69,7 +63,7 @@
#define MMU_NTLB_ENTRIES 64
#define MMU_CONTROL_INIT (MMUCR_AT | MMUCR_TI | MMUCR_SQMD | \
- MMUCR_ME | MMUCR_SE | MMUCR_AEX)
+ MMUCR_ME | MMUCR_AEX)
#define TRA 0xff000020
#define EXPEVT 0xff000024
--
2.43.0
^ permalink raw reply related
* [PATCH] sh: dma: Remove checks for nonexistent CONFIG_CPU_SUBTYPE_SH7730
From: Ethan Nelson-Moore @ 2026-06-13 20:56 UTC (permalink / raw)
To: GitAuthor: Ethan Nelson-Moore, linux-sh
Cc: Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Two headers in arch/sh/include contain references to
CONFIG_CPU_SUBTYPE_SH7730, which has never existed in the kernel.
Remove these references.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/sh/include/cpu-sh4/cpu/dma-register.h | 1 -
arch/sh/include/cpu-sh4a/cpu/dma.h | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/sh/include/cpu-sh4/cpu/dma-register.h b/arch/sh/include/cpu-sh4/cpu/dma-register.h
index 53f7ab990d88..af973c0f4f9d 100644
--- a/arch/sh/include/cpu-sh4/cpu/dma-register.h
+++ b/arch/sh/include/cpu-sh4/cpu/dma-register.h
@@ -21,7 +21,6 @@
#elif defined(CONFIG_CPU_SUBTYPE_SH7722) || \
defined(CONFIG_CPU_SUBTYPE_SH7723) || \
defined(CONFIG_CPU_SUBTYPE_SH7724) || \
- defined(CONFIG_CPU_SUBTYPE_SH7730) || \
defined(CONFIG_CPU_SUBTYPE_SH7786)
#define CHCR_TS_LOW_MASK 0x00000018
#define CHCR_TS_LOW_SHIFT 3
diff --git a/arch/sh/include/cpu-sh4a/cpu/dma.h b/arch/sh/include/cpu-sh4a/cpu/dma.h
index bdbbba8a784a..04992db01280 100644
--- a/arch/sh/include/cpu-sh4a/cpu/dma.h
+++ b/arch/sh/include/cpu-sh4a/cpu/dma.h
@@ -4,8 +4,7 @@
#include <linux/sh_intc.h>
-#if defined(CONFIG_CPU_SUBTYPE_SH7343) || \
- defined(CONFIG_CPU_SUBTYPE_SH7730)
+#ifdef CONFIG_CPU_SUBTYPE_SH7343
#define DMTE0_IRQ evt2irq(0x800)
#define DMTE4_IRQ evt2irq(0xb80)
#define DMAE0_IRQ evt2irq(0xbc0) /* DMA Error IRQ*/
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/2] sh: kfr2r09: fix i2c adapter leaks
From: John Paul Adrian Glaubitz @ 2026-06-13 5:11 UTC (permalink / raw)
To: Johan Hovold, Yoshinori Sato, Rich Felker; +Cc: linux-sh, linux-kernel
In-Reply-To: <aiwtIkdGNMFqJmHk@hovoldconsulting.com>
On Fri, 2026-06-12 at 18:00 +0200, Johan Hovold wrote:
> On Fri, May 08, 2026 at 02:05:59PM +0200, Johan Hovold wrote:
> > The kfr2r09 platform setup code fails to drop the references it acquires
> > to the I2C adapter.
>
> > Johan Hovold (2):
> > sh: kfr2r09: fix i2c adapter leak on USB gdaget setup
> > sh: kfr2r09: fix i2c adapter leak on serial console setup
>
> Can these be picked up now?
I will try to review some patches this weekend.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH 0/2] sh: kfr2r09: fix i2c adapter leaks
From: Johan Hovold @ 2026-06-12 16:00 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: linux-sh, linux-kernel
In-Reply-To: <20260508120601.426115-1-johan@kernel.org>
On Fri, May 08, 2026 at 02:05:59PM +0200, Johan Hovold wrote:
> The kfr2r09 platform setup code fails to drop the references it acquires
> to the I2C adapter.
> Johan Hovold (2):
> sh: kfr2r09: fix i2c adapter leak on USB gdaget setup
> sh: kfr2r09: fix i2c adapter leak on serial console setup
Can these be picked up now?
Johan
^ permalink raw reply
* Re: [PATCH] maple: switch to dynamic root device
From: Johan Hovold @ 2026-06-12 15:59 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: linux-sh, linux-kernel
In-Reply-To: <20260424104142.2617115-1-johan@kernel.org>
On Fri, Apr 24, 2026 at 12:41:42PM +0200, Johan Hovold wrote:
> Driver core expects devices to be dynamically allocated and will, for
> example, complain loudly when no release function has been provided.
>
> Use root_device_register() to allocate and register the root device
> instead of open coding using a static device.
>
> Note that this also fixes a reference leak in case device_register()
> fails which may be flagged by static checkers.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
Can this one be picked up now?
Johan
^ permalink raw reply
* Re: [PATCH 0/2] ASoC/sh: roll back Ecovec24/7724se Sound support
From: Mark Brown @ 2026-06-10 11:00 UTC (permalink / raw)
To: Bartosz Golaszewski, Geert Uytterhoeven, Jaroslav Kysela,
John Paul Adrian Glaubitz, Liam Girdwood, Linus Walleij,
Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh, linux-sound,
Kuninori Morimoto
In-Reply-To: <87wlw743x2.wl-kuninori.morimoto.gx@renesas.com>
On Wed, 10 Jun 2026 00:47:37 +0000, Kuninori Morimoto wrote:
> ASoC/sh: roll back Ecovec24/7724se Sound support
>
> Hi Mark, Adrian
>
> Due to a communication miss, the Ecovec24/7724se Sound support
> were removed. We need to keep them for a while, until they will
> support "DT-style".
> Roll back Ecovec24/7724se "platform data style", and its necessary header.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/2] sh: roll back Ecovec24/7724se Sound support
https://git.kernel.org/broonie/sound/c/fc83c6a271c1
[2/2] ASoC: renesas: fsi: remove platform data style support
https://git.kernel.org/broonie/sound/c/38d3273075d6
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: simple-card: remove platform data style
From: Kuninori Morimoto @ 2026-06-10 1:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: John Paul Adrian Glaubitz, Mark Brown, Bartosz Golaszewski,
Geert Uytterhoeven, Jaroslav Kysela, Liam Girdwood, Linus Walleij,
Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh, linux-sound
In-Reply-To: <87y0gn44zd.wl-kuninori.morimoto.gx@renesas.com>
Hi Mark, Adrian
> I have posted twice the patches. Basically both removes "platform data style"
> from driver, but 1st patches removes SH code too. 2nd doesn't.
>
> Sorry for my confusion, but I thought that 1st patches was rejected
> by Adrian. But it seems 1st patches were accepted.
>
> I will post fixup patch, soon. It will roll back 1st to 2nd patches.
It is complicated, so let me summarize.
Simple Card Driver
- Platform data style:
- Removed
- DT style:
- Keep supporting
SH (Ecovec24/7724se)
- Platform data style:
- This is no longer working while this 10 years, because of
Simple-Card driver, but no such report before.
- But it should be kept for a while untile it is converted
to DT-style.
"Platform data style" which SH is using is no longer working anyway.
So, its support was removed from Simple Card driver. This is OK.
But we would like to keep its code on SH side, until it switching to
"DT-style". I have posted roll back patch for this.
And, because "Platform data style" is no longer working anyway, not only
Simple-Card, but FSI driver also no need to keep "Platform data style"
support. I have posted it, too. It was included in 2nd patches.
FSI is still supporting "DT style".
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH 2/2] ASoC: renesas: fsi: remove platform data style support
From: Kuninori Morimoto @ 2026-06-10 0:49 UTC (permalink / raw)
To: Bartosz Golaszewski, Geert Uytterhoeven, Jaroslav Kysela,
John Paul Adrian Glaubitz, Liam Girdwood, Linus Walleij,
Mark Brown, Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh,
linux-sound
In-Reply-To: <87wlw743x2.wl-kuninori.morimoto.gx@renesas.com>
Renesas FSI driver has created for "platform data style" first, and
expanded to "DT style".
SuperH Ecovec24/7724se are the last user of "platform data style", but
its sound should not work during almost 10 years, because Simple-Card's
"platform data style" is broken, but no one reported it.
SuperH is planning to switch to "DT style", "platform data style" is no
longer working, and it seems there is no user. Let's remove "platform
data style", because keeping compatibility is difficult.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
This was included in 2nd patch-set.
sound/soc/renesas/fsi.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 8cbd7acc26f49..8b8c704ded2dc 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -1923,20 +1923,10 @@ static int fsi_probe(struct platform_device *pdev)
memset(&info, 0, sizeof(info));
- core = NULL;
- if (np) {
- core = of_device_get_match_data(&pdev->dev);
- fsi_of_parse("fsia", np, &info.port_a, &pdev->dev);
- fsi_of_parse("fsib", np, &info.port_b, &pdev->dev);
- } else {
- const struct platform_device_id *id_entry = pdev->id_entry;
- if (id_entry)
- core = (struct fsi_core *)id_entry->driver_data;
-
- if (pdev->dev.platform_data)
- memcpy(&info, pdev->dev.platform_data, sizeof(info));
- }
+ fsi_of_parse("fsia", np, &info.port_a, &pdev->dev);
+ fsi_of_parse("fsib", np, &info.port_b, &pdev->dev);
+ core = of_device_get_match_data(&pdev->dev);
if (!core) {
dev_err(&pdev->dev, "unknown fsi device\n");
return -ENODEV;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] sh: roll back Ecovec24/7724se Sound support
From: Kuninori Morimoto @ 2026-06-10 0:48 UTC (permalink / raw)
To: Bartosz Golaszewski, Geert Uytterhoeven, Jaroslav Kysela,
John Paul Adrian Glaubitz, Liam Girdwood, Linus Walleij,
Mark Brown, Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh,
linux-sound
In-Reply-To: <87wlw743x2.wl-kuninori.morimoto.gx@renesas.com>
Due to a communication miss, the Ecovec24/7724se Sound support
were removed. We need to keep them for a while, until they will
support "DT-style".
Roll back Ecovec24/7724se "platform data style", and its necessary header.
Fixes: deadb855b694d ("sh: 7724se: remove FSI/AK4642/Simple-Audio-Card support")
Fixes: 9cc93ebc85e71 ("sh: ecovec24: remove FSI/DA7210/Simple-Audio-Card support")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/sh/boards/mach-ecovec24/setup.c | 90 ++++++++++++++++++++++++
arch/sh/boards/mach-se/7724/setup.c | 101 +++++++++++++++++++++++++++
include/sound/simple_card.h | 26 +++++++
3 files changed, 217 insertions(+)
create mode 100644 include/sound/simple_card.h
diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index fe78dba442f91..a641e26f8fdf7 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -42,6 +42,9 @@
#include <media/i2c/mt9t112.h>
#include <media/i2c/tw9910.h>
+#include <sound/sh_fsi.h>
+#include <sound/simple_card.h>
+
#include <video/sh_mobile_lcdc.h>
/*
@@ -69,6 +72,16 @@
* OFF-ON : MMC
*/
+/*
+ * FSI - DA7210
+ *
+ * it needs amixer settings for playing
+ *
+ * amixer set 'HeadPhone' 80
+ * amixer set 'Out Mixer Left DAC Left' on
+ * amixer set 'Out Mixer Right DAC Right' on
+ */
+
#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
static phys_addr_t ceu0_dma_membase;
static phys_addr_t ceu1_dma_membase;
@@ -507,6 +520,9 @@ static struct mt9t112_platform_data mt9t112_1_pdata = {
};
static struct i2c_board_info i2c0_devices[] = {
+ {
+ I2C_BOARD_INFO("da7210", 0x1a),
+ },
{
I2C_BOARD_INFO("tw9910", 0x45),
.platform_data = &tw9910_info,
@@ -845,6 +861,51 @@ static struct gpiod_lookup_table msiof_gpio_table = {
#endif
+/* FSI */
+static struct resource fsi_resources[] = {
+ [0] = {
+ .name = "FSI",
+ .start = 0xFE3C0000,
+ .end = 0xFE3C021d,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = evt2irq(0xf80),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device fsi_device = {
+ .name = "sh_fsi",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(fsi_resources),
+ .resource = fsi_resources,
+};
+
+static struct simple_util_info fsi_da7210_info = {
+ .name = "DA7210",
+ .card = "FSIB-DA7210",
+ .codec = "da7210.0-001a",
+ .platform = "sh_fsi.0",
+ .daifmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBP_CFP,
+ .cpu_dai = {
+ .name = "fsib-dai",
+ },
+ .codec_dai = {
+ .name = "da7210-hifi",
+ },
+};
+
+static struct platform_device fsi_da7210_device = {
+ .name = "asoc-simple-card",
+ .dev = {
+ .platform_data = &fsi_da7210_info,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .dma_mask = &fsi_da7210_device.dev.coherent_dma_mask,
+ },
+};
+
+
/* IrDA */
static struct resource irda_resources[] = {
[0] = {
@@ -970,6 +1031,8 @@ static struct platform_device *ecovec_devices[] __initdata = {
#else
&msiof0_device,
#endif
+ &fsi_device,
+ &fsi_da7210_device,
&irda_device,
&vou_device,
#if defined(CONFIG_MMC_SH_MMCIF) || defined(CONFIG_MMC_SH_MMCIF_MODULE)
@@ -1294,6 +1357,33 @@ static int __init arch_setup(void)
__raw_writew((__raw_readw(IODRIVEA) & ~0x3000) | 0x2000,
IODRIVEA);
+ /* enable FSI */
+ gpio_request(GPIO_FN_FSIMCKB, NULL);
+ gpio_request(GPIO_FN_FSIIBSD, NULL);
+ gpio_request(GPIO_FN_FSIOBSD, NULL);
+ gpio_request(GPIO_FN_FSIIBBCK, NULL);
+ gpio_request(GPIO_FN_FSIIBLRCK, NULL);
+ gpio_request(GPIO_FN_FSIOBBCK, NULL);
+ gpio_request(GPIO_FN_FSIOBLRCK, NULL);
+ gpio_request(GPIO_FN_CLKAUDIOBO, NULL);
+
+ /* set SPU2 clock to 83.4 MHz */
+ clk = clk_get(NULL, "spu_clk");
+ if (!IS_ERR(clk)) {
+ clk_set_rate(clk, clk_round_rate(clk, 83333333));
+ clk_put(clk);
+ }
+
+ /* change parent of FSI B */
+ clk = clk_get(NULL, "fsib_clk");
+ if (!IS_ERR(clk)) {
+ /* 48kHz dummy clock was used to make sure 1/1 divide */
+ clk_set_rate(&sh7724_fsimckb_clk, 48000);
+ clk_set_parent(clk, &sh7724_fsimckb_clk);
+ clk_set_rate(clk, 48000);
+ clk_put(clk);
+ }
+
gpio_request(GPIO_PTU0, NULL);
gpio_direction_output(GPIO_PTU0, 0);
mdelay(20);
diff --git a/arch/sh/boards/mach-se/7724/setup.c b/arch/sh/boards/mach-se/7724/setup.c
index 58e86ba9ad735..e500feb910539 100644
--- a/arch/sh/boards/mach-se/7724/setup.c
+++ b/arch/sh/boards/mach-se/7724/setup.c
@@ -37,6 +37,9 @@
#include <mach-se/mach/se7724.h>
#include <media/drv-intf/renesas-ceu.h>
+#include <sound/sh_fsi.h>
+#include <sound/simple_card.h>
+
#include <video/sh_mobile_lcdc.h>
#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
@@ -63,6 +66,13 @@ static phys_addr_t ceu1_dma_membase;
* and change SW41 to use 720p
*/
+/*
+ * about sound
+ *
+ * This setup.c supports FSI slave mode.
+ * Please change J20, J21, J22 pin to 1-2 connection.
+ */
+
/* Heartbeat */
static struct resource heartbeat_resource = {
.start = PA_LED,
@@ -268,6 +278,50 @@ static struct platform_device ceu1_device = {
},
};
+/* FSI */
+/* change J20, J21, J22 pin to 1-2 connection to use slave mode */
+static struct resource fsi_resources[] = {
+ [0] = {
+ .name = "FSI",
+ .start = 0xFE3C0000,
+ .end = 0xFE3C021d,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = evt2irq(0xf80),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device fsi_device = {
+ .name = "sh_fsi",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(fsi_resources),
+ .resource = fsi_resources,
+};
+
+static struct simple_util_info fsi_ak4642_info = {
+ .name = "AK4642",
+ .card = "FSIA-AK4642",
+ .codec = "ak4642-codec.0-0012",
+ .platform = "sh_fsi.0",
+ .daifmt = SND_SOC_DAIFMT_LEFT_J | SND_SOC_DAIFMT_CBP_CFP,
+ .cpu_dai = {
+ .name = "fsia-dai",
+ },
+ .codec_dai = {
+ .name = "ak4642-hifi",
+ .sysclk = 11289600,
+ },
+};
+
+static struct platform_device fsi_ak4642_device = {
+ .name = "asoc-simple-card",
+ .dev = {
+ .platform_data = &fsi_ak4642_info,
+ },
+};
+
/* KEYSC in SoC (Needs SW33-2 set to ON) */
static struct sh_keysc_info keysc_info = {
.mode = SH_KEYSC_MODE_1,
@@ -535,12 +589,21 @@ static struct platform_device *ms7724se_devices[] __initdata = {
&sh_eth_device,
&sh7724_usb0_host_device,
&sh7724_usb1_gadget_device,
+ &fsi_device,
+ &fsi_ak4642_device,
&sdhi0_cn7_device,
&sdhi1_cn8_device,
&irda_device,
&vou_device,
};
+/* I2C device */
+static struct i2c_board_info i2c0_devices[] = {
+ {
+ I2C_BOARD_INFO("ak4642", 0x12),
+ },
+};
+
#define EEPROM_OP 0xBA206000
#define EEPROM_ADR 0xBA206004
#define EEPROM_DATA 0xBA20600C
@@ -603,9 +666,19 @@ extern char ms7724se_sdram_enter_end;
extern char ms7724se_sdram_leave_start;
extern char ms7724se_sdram_leave_end;
+static int __init arch_setup(void)
+{
+ /* enable I2C device */
+ i2c_register_board_info(0, i2c0_devices,
+ ARRAY_SIZE(i2c0_devices));
+ return 0;
+}
+arch_initcall(arch_setup);
+
static int __init devices_setup(void)
{
u16 sw = __raw_readw(SW4140); /* select camera, monitor */
+ struct clk *clk;
u16 fpga_out;
/* register board specific self-refresh code */
@@ -626,6 +699,7 @@ static int __init devices_setup(void)
(1 << 4) | /* AK8813 PDN */
(1 << 5) | /* AK8813 RESET */
(1 << 6) | /* VIDEO DAC */
+ (1 << 7) | /* AK4643 */
(1 << 8) | /* IrDA */
(1 << 12) | /* USB0 */
(1 << 14)); /* RMII */
@@ -755,6 +829,33 @@ static int __init devices_setup(void)
gpio_request(GPIO_FN_KEYOUT1, NULL);
gpio_request(GPIO_FN_KEYOUT0, NULL);
+ /* enable FSI */
+ gpio_request(GPIO_FN_FSIMCKA, NULL);
+ gpio_request(GPIO_FN_FSIIASD, NULL);
+ gpio_request(GPIO_FN_FSIOASD, NULL);
+ gpio_request(GPIO_FN_FSIIABCK, NULL);
+ gpio_request(GPIO_FN_FSIIALRCK, NULL);
+ gpio_request(GPIO_FN_FSIOABCK, NULL);
+ gpio_request(GPIO_FN_FSIOALRCK, NULL);
+ gpio_request(GPIO_FN_CLKAUDIOAO, NULL);
+
+ /* set SPU2 clock to 83.4 MHz */
+ clk = clk_get(NULL, "spu_clk");
+ if (!IS_ERR(clk)) {
+ clk_set_rate(clk, clk_round_rate(clk, 83333333));
+ clk_put(clk);
+ }
+
+ /* change parent of FSI A */
+ clk = clk_get(NULL, "fsia_clk");
+ if (!IS_ERR(clk)) {
+ /* 48kHz dummy clock was used to make sure 1/1 divide */
+ clk_set_rate(&sh7724_fsimcka_clk, 48000);
+ clk_set_parent(clk, &sh7724_fsimcka_clk);
+ clk_set_rate(clk, 48000);
+ clk_put(clk);
+ }
+
/* SDHI0 connected to cn7 */
gpio_request(GPIO_FN_SDHI0CD, NULL);
gpio_request(GPIO_FN_SDHI0WP, NULL);
diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
new file mode 100644
index 0000000000000..2e999916dbd7d
--- /dev/null
+++ b/include/sound/simple_card.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * ASoC simple sound card support
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+ */
+
+#ifndef __SIMPLE_CARD_H
+#define __SIMPLE_CARD_H
+
+#include <sound/soc.h>
+#include <sound/simple_card_utils.h>
+
+struct simple_util_info {
+ const char *name;
+ const char *card;
+ const char *codec;
+ const char *platform;
+
+ unsigned int daifmt;
+ struct simple_util_dai cpu_dai;
+ struct simple_util_dai codec_dai;
+};
+
+#endif /* __SIMPLE_CARD_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] ASoC/sh: roll back Ecovec24/7724se Sound support
From: Kuninori Morimoto @ 2026-06-10 0:47 UTC (permalink / raw)
To: Bartosz Golaszewski, Geert Uytterhoeven, Jaroslav Kysela,
John Paul Adrian Glaubitz, Liam Girdwood, Linus Walleij,
Mark Brown, Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh,
linux-sound
Hi Mark, Adrian
Due to a communication miss, the Ecovec24/7724se Sound support
were removed. We need to keep them for a while, until they will
support "DT-style".
Roll back Ecovec24/7724se "platform data style", and its necessary header.
Kuninori Morimoto (2):
sh: roll back Ecovec24/7724se Sound support
ASoC: renesas: fsi: remove platform data style support
arch/sh/boards/mach-ecovec24/setup.c | 90 ++++++++++++++++++++++++
arch/sh/boards/mach-se/7724/setup.c | 101 +++++++++++++++++++++++++++
include/sound/simple_card.h | 26 +++++++
sound/soc/renesas/fsi.c | 16 +----
4 files changed, 220 insertions(+), 13 deletions(-)
create mode 100644 include/sound/simple_card.h
--
2.53.0
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: simple-card: remove platform data style
From: Kuninori Morimoto @ 2026-06-10 0:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: John Paul Adrian Glaubitz, Mark Brown, Bartosz Golaszewski,
Geert Uytterhoeven, Jaroslav Kysela, Liam Girdwood, Linus Walleij,
Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh, linux-sound
In-Reply-To: <871pef5l0o.wl-kuninori.morimoto.gx@renesas.com>
Hi Mark, Adrian
> > > I actually wanted to keep the driver and convert it to using device-trees,
> > > not remove it. We have an out-of-tree patch for switching SuperH to device-
> > > tree support.
Oops ?
I have posted twice the patches. Basically both removes "platform data style"
from driver, but 1st patches removes SH code too. 2nd doesn't.
Sorry for my confusion, but I thought that 1st patches was rejected
by Adrian. But it seems 1st patches were accepted.
I will post fixup patch, soon. It will roll back 1st to 2nd patches.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: simple-card: remove platform data style
From: Kuninori Morimoto @ 2026-06-09 23:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: John Paul Adrian Glaubitz, Mark Brown, Bartosz Golaszewski,
Geert Uytterhoeven, Jaroslav Kysela, Liam Girdwood, Linus Walleij,
Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh, linux-sound
In-Reply-To: <CAMuHMdXVWPxu-5BXAgWOBoWdNXxZ2zeAfTovXxftXsKuCUUDww@mail.gmail.com>
Hi Adrian
> > I actually wanted to keep the driver and convert it to using device-trees,
> > not remove it. We have an out-of-tree patch for switching SuperH to device-
> > tree support.
>
> 1. The sound driver is not removed at all.
> 2. s/SuperH/SH7751R/.
As Geert explained, removed was "platform data style" support only which has
been used for non-DT user (= SuperH), and it had been no longer working
anyway. "DT style" is still supported.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: (subset) [PATCH v2 00/10] gpiolib: fence off legacy interfaces
From: Kevin Hilman @ 2026-06-09 22:25 UTC (permalink / raw)
To: linux-gpio, Arnd Bergmann
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Johannes Berg,
Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Thomas Bogendoerfer, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, Matti Vaittinen, Florian Fainelli, Jonas Gorski,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wireless, linux-omap,
linux-arm-kernel, linux-mips, linux-sh, linux-input, linux-leds,
netdev
In-Reply-To: <20260520183815.2510387-1-arnd@kernel.org>
On Wed, 20 May 2026 20:38:05 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This is an update of all the patches that are still required before
> we can actually turn off CONFIG_GPIOLIB_LEGACY for most platforms
> in the final patch of this series.
>
> I originally posted this as a series in
> https://lore.kernel.org/all/20250808151822.536879-1-arnd@kernel.org/
>
> [...]
Applied, thanks!
[09/10] ARM: dts: omap2: add stlc4560 spi-wireless node
commit: c5a0ac76b364bbd1d4fb7e440edabcd2a369343c
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: simple-card: remove platform data style
From: Geert Uytterhoeven @ 2026-06-09 13:37 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Mark Brown, Bartosz Golaszewski, Geert Uytterhoeven,
Jaroslav Kysela, Liam Girdwood, Linus Walleij, Rich Felker,
Takashi Iwai, Yoshinori Sato, linux-sh, linux-sound,
Kuninori Morimoto
In-Reply-To: <fa7d7af8a780c27f85e29c518ba45e39ab18abad.camel@physik.fu-berlin.de>
Hi Adrian,
On Tue, 9 Jun 2026 at 14:21, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Mon, 2026-06-08 at 18:55 +0100, Mark Brown wrote:
> > On Wed, 27 May 2026 06:45:26 +0000, Kuninori Morimoto wrote:
> > > ASoC: simple-card: remove platform data style
> > >
> > > Hi
> > >
> > > SuperH ecovec24/7724se are the last user of Simple Audio Card as
> > > "platform data style". It is mainly supporting "DT style" in these days.
> > >
> > > [...]
> >
> > Applied to
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
> >
> > Thanks!
> >
> > [1/3] sh: ecovec24: remove FSI/DA7210/Simple-Audio-Card support
> > https://git.kernel.org/broonie/sound/c/9cc93ebc85e7
> > [2/3] sh: 7724se: remove FSI/AK4642/Simple-Audio-Card support
> > https://git.kernel.org/broonie/sound/c/deadb855b694
> > [3/3] ASoC: simple-card: remove platform data style
> > https://git.kernel.org/broonie/sound/c/325fea33e141
> >
> > All being well this means that it will be integrated into the linux-next
> > tree (usually sometime in the next 24 hours) and sent to Linus during
> > the next merge window (or sooner if it is a bug fix), however if
> > problems are discovered then the patch may be dropped or reverted.
> >
> > You may get further e-mails resulting from automated or manual testing
> > and review of the tree, please engage with people reporting problems and
> > send followup patches addressing any issues that are reported if needed.
> >
> > If any updates are required or you are submitting further changes they
> > should be sent as incremental updates against current git, existing
> > patches will not be replaced.
> >
> > Please add any relevant lists and maintainers to the CCs when replying
> > to this mail.
>
> I actually wanted to keep the driver and convert it to using device-trees,
> not remove it. We have an out-of-tree patch for switching SuperH to device-
> tree support.
1. The sound driver is not removed at all.
2. s/SuperH/SH7751R/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: simple-card: remove platform data style
From: John Paul Adrian Glaubitz @ 2026-06-09 12:21 UTC (permalink / raw)
To: Mark Brown, Bartosz Golaszewski, Geert Uytterhoeven,
Jaroslav Kysela, Liam Girdwood, Linus Walleij, Rich Felker,
Takashi Iwai, Yoshinori Sato, linux-sh, linux-sound,
Kuninori Morimoto
In-Reply-To: <178094130630.20828.12708103059145547835.b4-ty@b4>
Hello Mark,
On Mon, 2026-06-08 at 18:55 +0100, Mark Brown wrote:
> On Wed, 27 May 2026 06:45:26 +0000, Kuninori Morimoto wrote:
> > ASoC: simple-card: remove platform data style
> >
> > Hi
> >
> > SuperH ecovec24/7724se are the last user of Simple Audio Card as
> > "platform data style". It is mainly supporting "DT style" in these days.
> >
> > [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
>
> Thanks!
>
> [1/3] sh: ecovec24: remove FSI/DA7210/Simple-Audio-Card support
> https://git.kernel.org/broonie/sound/c/9cc93ebc85e7
> [2/3] sh: 7724se: remove FSI/AK4642/Simple-Audio-Card support
> https://git.kernel.org/broonie/sound/c/deadb855b694
> [3/3] ASoC: simple-card: remove platform data style
> https://git.kernel.org/broonie/sound/c/325fea33e141
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
I actually wanted to keep the driver and convert it to using device-trees,
not remove it. We have an out-of-tree patch for switching SuperH to device-
tree support.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Geert Uytterhoeven @ 2026-06-09 9:55 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Ard Biesheuvel, linux-arm-kernel, linux-kernel, will,
catalin.marinas, mark.rutland, Ard Biesheuvel, Ryan Roberts,
Anshuman Khandual, Kevin Brodsky, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening, linuxppc-dev, linux-sh,
Linux-Renesas
In-Reply-To: <6a9c0f55-fe98-4063-864b-8f7e1f4fefd7@samsung.com>
On Tue, 9 Jun 2026 at 08:28, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> On 09.06.2026 08:22, Marek Szyprowski wrote:
> > On 29.05.2026 17:02, Ard Biesheuvel wrote:
> >> From: Ard Biesheuvel <ardb@kernel.org>
> >>
> >> The linear aliases of the kernel text and rodata are also mapped
> >> read-only in the linear map. Given that the contents of these regions
> >> are mostly identical to the version in the loadable image, mapping them
> >> read-only and leaving their contents visible is a reasonable hardening
> >> measure.
> >>
> >> Data and bss, however, are now also mapped read-only but the contents of
> >> these regions are more likely to contain data that we'd rather not leak.
> >> So let's unmap these entirely in the linear map when the kernel is
> >> running normally.
> >>
> >> When going into hibernation or waking up from it, these regions need to
> >> be mapped, so map the region initially, and toggle the valid bit so
> >> map/unmap the region as needed.
> >>
> >> Doing so is required because pages covering the kernel image are marked
> >> as PageReserved, and therefore disregarded for snapshotting by the
> >> hibernate logic unless they are mapped.
> >>
> >> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > This commit landed in yesterday's linux-next as commit 63e0b6a5b693
> > ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
> > In my tests I found that it breaks booting of RaspberryPi3 and
> > RaspberryPi4 boards with the following kernel panic:
Seeing the same panic on R-Car H3 ES2.0 (Cortex A57/A53), but not
on R-Car V4M (Cortex A76).
> One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
> change) on top of next-20260608 fixes this issue.
Confirmed, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: simple-card: remove platform data style
From: Mark Brown @ 2026-06-08 17:55 UTC (permalink / raw)
To: Bartosz Golaszewski, Geert Uytterhoeven, Jaroslav Kysela,
John Paul Adrian Glaubitz, Liam Girdwood, Linus Walleij,
Rich Felker, Takashi Iwai, Yoshinori Sato, linux-sh, linux-sound,
Kuninori Morimoto
In-Reply-To: <87zf1le4fu.wl-kuninori.morimoto.gx@renesas.com>
On Wed, 27 May 2026 06:45:26 +0000, Kuninori Morimoto wrote:
> ASoC: simple-card: remove platform data style
>
> Hi
>
> SuperH ecovec24/7724se are the last user of Simple Audio Card as
> "platform data style". It is mainly supporting "DT style" in these days.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/3] sh: ecovec24: remove FSI/DA7210/Simple-Audio-Card support
https://git.kernel.org/broonie/sound/c/9cc93ebc85e7
[2/3] sh: 7724se: remove FSI/AK4642/Simple-Audio-Card support
https://git.kernel.org/broonie/sound/c/deadb855b694
[3/3] ASoC: simple-card: remove platform data style
https://git.kernel.org/broonie/sound/c/325fea33e141
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Vladimir Murzin @ 2026-06-09 8:26 UTC (permalink / raw)
To: Marek Szyprowski, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <6a9c0f55-fe98-4063-864b-8f7e1f4fefd7@samsung.com>
Hi,
On 6/9/26 07:28, Marek Szyprowski wrote:
> On 09.06.2026 08:22, Marek Szyprowski wrote:
>> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> The linear aliases of the kernel text and rodata are also mapped
>>> read-only in the linear map. Given that the contents of these regions
>>> are mostly identical to the version in the loadable image, mapping them
>>> read-only and leaving their contents visible is a reasonable hardening
>>> measure.
>>>
>>> Data and bss, however, are now also mapped read-only but the contents of
>>> these regions are more likely to contain data that we'd rather not leak.
>>> So let's unmap these entirely in the linear map when the kernel is
>>> running normally.
>>>
>>> When going into hibernation or waking up from it, these regions need to
>>> be mapped, so map the region initially, and toggle the valid bit so
>>> map/unmap the region as needed.
>>>
>>> Doing so is required because pages covering the kernel image are marked
>>> as PageReserved, and therefore disregarded for snapshotting by the
>>> hibernate logic unless they are mapped.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
>> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
>> In my tests I found that it breaks booting of RaspberryPi3 and
>> RaspberryPi4 boards with the following kernel panic:
> One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
> change) on top of next-20260608 fixes this issue.
>
Thanks for report! It seems it already has been reported and discussed in
another thread [1].
[1] https://lore.kernel.org/linux-arm-kernel/aicVyebkEMs6w6UV@sirena.co.uk/
Cheers
Vladimir
> Best regards
> -- Marek Szyprowski, PhD Samsung R&D Institute Poland
>
^ permalink raw reply
* Re: [PATCH v2 00/10] sh: remove NUMA and SPARSEMEM support
From: John Paul Adrian Glaubitz @ 2026-06-09 7:21 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-sh, Andrew Morton, Arnd Bergmann, Rich Felker,
Yoshinori Sato, linux-kernel, linux-mm
In-Reply-To: <aiBI_QEmeVSBb2HY@kernel.org>
Hi Mike,
On Wed, 2026-06-03 at 18:32 +0300, Mike Rapoport wrote:
> On Mon, May 18, 2026 at 02:05:39PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi Mike,
> >
> > On Mon, 2026-05-18 at 14:43 +0300, Mike Rapoport wrote:
> > > Gentle ping?
> >
> > It's on my TODO list for this week!
>
> It's sad to see this being dragged since mid April (if we count v1 and
> there were really minor changes in v2).
I apologize. I am doing the maintenance as a hobby in my free time, it's
not my primary job and it can sometimes take me a bit longer to take up
changes.
> If you don't have time to take care of that, just say so and we'll take
> this via one of the mm trees in the next cycle.
It should be better this week. I've been recently busy with CVE fixes during
my dayjob and the workload was extremely high.
I am not going to let this slip, don't worry. It's just been a bit too much
stress the past weeks due to the AI CVE reporting.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Ard Biesheuvel @ 2026-06-09 6:31 UTC (permalink / raw)
To: Marek Szyprowski, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <6a9c0f55-fe98-4063-864b-8f7e1f4fefd7@samsung.com>
On Tue, 9 Jun 2026, at 08:28, Marek Szyprowski wrote:
> On 09.06.2026 08:22, Marek Szyprowski wrote:
>> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> The linear aliases of the kernel text and rodata are also mapped
>>> read-only in the linear map. Given that the contents of these regions
>>> are mostly identical to the version in the loadable image, mapping them
>>> read-only and leaving their contents visible is a reasonable hardening
>>> measure.
>>>
>>> Data and bss, however, are now also mapped read-only but the contents of
>>> these regions are more likely to contain data that we'd rather not leak.
>>> So let's unmap these entirely in the linear map when the kernel is
>>> running normally.
>>>
>>> When going into hibernation or waking up from it, these regions need to
>>> be mapped, so map the region initially, and toggle the valid bit so
>>> map/unmap the region as needed.
>>>
>>> Doing so is required because pages covering the kernel image are marked
>>> as PageReserved, and therefore disregarded for snapshotting by the
>>> hibernate logic unless they are mapped.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
>> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
>> In my tests I found that it breaks booting of RaspberryPi3 and
>> RaspberryPi4 boards with the following kernel panic:
> One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
> change) on top of next-20260608 fixes this issue.
>
Thanks for the report, and for the confirmation that those reverts fix
the issue - this was reported here as well:
https://lore.kernel.org/all/aicVyebkEMs6w6UV@sirena.co.uk/
^ permalink raw reply
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Marek Szyprowski @ 2026-06-09 6:28 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <a1b27e97-182c-485d-a448-56c19c5de2c2@samsung.com>
On 09.06.2026 08:22, Marek Szyprowski wrote:
> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>>
>> The linear aliases of the kernel text and rodata are also mapped
>> read-only in the linear map. Given that the contents of these regions
>> are mostly identical to the version in the loadable image, mapping them
>> read-only and leaving their contents visible is a reasonable hardening
>> measure.
>>
>> Data and bss, however, are now also mapped read-only but the contents of
>> these regions are more likely to contain data that we'd rather not leak.
>> So let's unmap these entirely in the linear map when the kernel is
>> running normally.
>>
>> When going into hibernation or waking up from it, these regions need to
>> be mapped, so map the region initially, and toggle the valid bit so
>> map/unmap the region as needed.
>>
>> Doing so is required because pages covering the kernel image are marked
>> as PageReserved, and therefore disregarded for snapshotting by the
>> hibernate logic unless they are mapped.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
> In my tests I found that it breaks booting of RaspberryPi3 and
> RaspberryPi4 boards with the following kernel panic:
One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
change) on top of next-20260608 fixes this issue.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Marek Szyprowski @ 2026-06-09 6:22 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <20260529150150.1670604-32-ardb+git@google.com>
Dear All,
On 29.05.2026 17:02, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The linear aliases of the kernel text and rodata are also mapped
> read-only in the linear map. Given that the contents of these regions
> are mostly identical to the version in the loadable image, mapping them
> read-only and leaving their contents visible is a reasonable hardening
> measure.
>
> Data and bss, however, are now also mapped read-only but the contents of
> these regions are more likely to contain data that we'd rather not leak.
> So let's unmap these entirely in the linear map when the kernel is
> running normally.
>
> When going into hibernation or waking up from it, these regions need to
> be mapped, so map the region initially, and toggle the valid bit so
> map/unmap the region as needed.
>
> Doing so is required because pages covering the kernel image are marked
> as PageReserved, and therefore disregarded for snapshotting by the
> hibernate logic unless they are mapped.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This commit landed in yesterday's linux-next as commit 63e0b6a5b693
("arm64: mm: Unmap kernel data/bss entirely from the linear map").
In my tests I found that it breaks booting of RaspberryPi3 and
RaspberryPi4 boards with the following kernel panic:
kvm [1]: nv: 570 coarse grained trap handlers
kvm [1]: nv: 710 fine grained trap handlers
kvm [1]: IPA Size Limit: 40 bits
Unable to handle kernel paging request at virtual address ffff000003a23000
Mem abort info:
ESR = 0x0000000096000147
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x07: level 3 translation fault
Data abort info:
ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
CM = 1, WnR = 1, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000002609000
[ffff000003a23000] pgd=0000000000000000, p4d=180000003b3ff403, pud=180000003b3fe403, pmd=180000003b3e6403, pte=00e8000003a23f06
Internal error: Oops: 0000000096000147 [#1] SMP
Modules linked in:
CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.1.0-rc1+ #16768 PREEMPT
Hardware name: Raspberry Pi 3 Model B (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : dcache_clean_inval_poc+0x24/0x48
lr : kvm_arm_init+0xa8c/0x165c
sp : ffff8000844bbd00
...
Call trace:
dcache_clean_inval_poc+0x24/0x48 (P)
do_one_initcall+0x68/0x4f4
kernel_init_freeable+0x24c/0x360
kernel_init+0x24/0x1dc
ret_from_fork+0x10/0x20
Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x00000000,03000008,00040000,0400421b
Memory Limit: none
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> ---
> arch/arm64/mm/mmu.c | 45 ++++++++++++++++++--
> 1 file changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 7b18dc2f1721..07a6fa210171 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -24,6 +24,7 @@
> #include <linux/mm.h>
> #include <linux/vmalloc.h>
> #include <linux/set_memory.h>
> +#include <linux/suspend.h>
> #include <linux/kfence.h>
> #include <linux/pkeys.h>
> #include <linux/mm_inline.h>
> @@ -1056,6 +1057,29 @@ static void __init __map_memblock(phys_addr_t start, phys_addr_t end,
> end - start, prot, early_pgtable_alloc, flags);
> }
>
> +static void mark_linear_data_alias_valid(bool valid)
> +{
> + set_memory_valid((unsigned long)lm_alias(__init_end),
> + (unsigned long)(__bss_stop - __init_end) / PAGE_SIZE,
> + valid);
> +}
> +
> +static int arm64_hibernate_pm_notify(struct notifier_block *nb,
> + unsigned long mode, void *unused)
> +{
> + switch (mode) {
> + default:
> + break;
> + case PM_POST_HIBERNATION:
> + mark_linear_data_alias_valid(false);
> + break;
> + case PM_HIBERNATION_PREPARE:
> + mark_linear_data_alias_valid(true);
> + break;
> + }
> + return 0;
> +}
> +
> void __init mark_linear_text_alias_ro(void)
> {
> /*
> @@ -1064,6 +1088,21 @@ void __init mark_linear_text_alias_ro(void)
> update_mapping_prot(__pa_symbol(_text), (unsigned long)lm_alias(_text),
> (unsigned long)__init_begin - (unsigned long)_text,
> PAGE_KERNEL_RO);
> +
> + /*
> + * Register a PM notifier to remap the linear alias of data/bss as
> + * valid read-only before hibernation. This is needed because the
> + * snapshot logic disregards PageReserved pages (such as the ones
> + * covering the kernel image) unless they are mapped in the linear
> + * map.
> + */
> + if (IS_ENABLED(CONFIG_HIBERNATION)) {
> + static struct notifier_block nb = {
> + .notifier_call = arm64_hibernate_pm_notify
> + };
> +
> + register_pm_notifier(&nb);
> + }
> }
>
> #ifdef CONFIG_KFENCE
> @@ -1193,10 +1232,8 @@ static void __init map_mem(void)
> flags);
> }
>
> - /* Map the kernel data/bss read-only in the linear map */
> - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> - (unsigned long)lm_alias(__bss_stop));
> + /* Map the kernel data/bss as invalid in the linear map */
> + mark_linear_data_alias_valid(false);
> }
>
> void mark_rodata_ro(void)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v4 5/5] sparc: Remove remaining defconfig references to the pktcdvd driver
From: Catalin Iacob @ 2026-06-08 14:29 UTC (permalink / raw)
To: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Rich Felker,
John Paul Adrian Glaubitz, David S. Miller, Andreas Larsson,
James E.J. Bottomley, Martin K. Petersen, Jens Axboe
Cc: linux-mips, linux-kernel, linuxppc-dev, linux-sh, sparclinux,
linux-scsi, Catalin Iacob
In-Reply-To: <20260608-remove-pktcdvd-references-v4-0-72f88b04cc87@gmail.com>
Commit 1cea5180f2f8 ("block: remove pktcdvd driver") left behind some
CONFIG_CONFIG_CDROM_PKTCDVD* references in defconfigs. Remove them.
Signed-off-by: Catalin Iacob <iacobcatalin@gmail.com>
---
arch/sparc/configs/sparc64_defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/sparc/configs/sparc64_defconfig b/arch/sparc/configs/sparc64_defconfig
index 632081a262ba..4abea39281cd 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -60,8 +60,6 @@ CONFIG_CONNECTOR=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
-CONFIG_CDROM_PKTCDVD=m
-CONFIG_CDROM_PKTCDVD_WCACHE=y
CONFIG_ATA_OVER_ETH=m
CONFIG_SUNVDC=m
CONFIG_ATA=y
--
2.54.0
^ permalink raw reply related
page: next (older)
- 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