* Re: [PATCH 3/8] firmware: arm_ffa: Align RxTx buffer size before mapping
From: Sebastian Ene @ 2026-04-27 9:30 UTC (permalink / raw)
To: Sudeep Holla; +Cc: linux-kernel, linux-arm-kernel, Jens Wiklander
In-Reply-To: <20260423-ffa_fixes-v1-3-61189661affe@kernel.org>
On Thu, Apr 23, 2026 at 06:22:53PM +0100, Sudeep Holla wrote:
> Commit 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during
> RXTX_MAP") advertises PAGE_ALIGN(rxtx_bufsz) to firmware when mapping the
> buffers but the driver continues to stores the minimum FF-A buffer size
> in drv_info->rxtx_bufsz which is used elsewhere in the driver.
Hello Sudeep,
>
> Align the size before storing it so that the allocation, validation and
> FFA_RXTX_MAP all use the same buffer size.
>
Thanks for fixing this,
Reviewed-by: Sebastian Ene <sebastianene@google.com>.
> Fixes: 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP")
> Cc: Sebastian Ene <sebastianene@google.com>
> Link: https://sashiko.dev/#/patchset/20260402113939.930221-1-sebastianene@google.com
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> ---
> drivers/firmware/arm_ffa/driver.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index e6a051b20cb7..4dec7ca52f8c 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -2063,6 +2063,7 @@ static int __init ffa_init(void)
> rxtx_bufsz = SZ_4K;
> }
>
> + rxtx_bufsz = PAGE_ALIGN(rxtx_bufsz);
> drv_info->rxtx_bufsz = rxtx_bufsz;
> drv_info->rx_buffer = alloc_pages_exact(rxtx_bufsz, GFP_KERNEL);
> if (!drv_info->rx_buffer) {
> @@ -2078,7 +2079,7 @@ static int __init ffa_init(void)
>
> ret = ffa_rxtx_map(virt_to_phys(drv_info->tx_buffer),
> virt_to_phys(drv_info->rx_buffer),
> - PAGE_ALIGN(rxtx_bufsz) / FFA_PAGE_SIZE);
> + rxtx_bufsz / FFA_PAGE_SIZE);
> if (ret) {
> pr_err("failed to register FFA RxTx buffers\n");
> goto free_pages;
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 6/9] soc: imx8m: don't access of_root directly
From: Francesco Dolcini @ 2026-04-27 9:31 UTC (permalink / raw)
To: Francesco Dolcini, peng.fan, Alexander Stein, Bartosz Golaszewski
Cc: Rob Herring, Saravana Kannan, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Christophe Leroy (CS GROUP),
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Frank Li, linux-arm-kernel, devicetree,
linux-kernel, linuxppc-dev, imx, linux-renesas-soc, linux-sunxi,
driver-core, regressions
In-Reply-To: <20260427064704.GA17710@francesco-nb>
+Peng
Hello all,
On Mon, Apr 27, 2026 at 08:47:04AM +0200, Francesco Dolcini wrote:
> On Tue, Mar 24, 2026 at 11:24:09AM +0100, Alexander Stein wrote:
> > Hi,
> >
> > Am Montag, 23. Februar 2026, 14:37:21 CET schrieb Bartosz Golaszewski:
> > > Don't access of_root directly as it reduces the build test coverage for
> > > this driver with COMPILE_TEST=y and OF=n. Use existing helper functions
> > > to retrieve the relevant information.
> > >
> > > Suggested-by: Rob Herring <robh@kernel.org>
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >
> > today I noticed the following warning running next-20260323:
> > > caam 30900000.crypto: No clock data provided for i.MX SoC
> >
> > This happens when there is no matching against the soc_id.
> >
> > Checking the source it turns out this patch is the cause that the SoC info
> > does not provide soc_id anymore.
> > next-20260323:
> > > $ grep . /sys/devices/soc0/*
> > > /sys/devices/soc0/family:Freescale i.MX
> > > /sys/devices/soc0/machine:TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MP-RAS314
> > > grep: /sys/devices/soc0/power: Is a directory
> > > /sys/devices/soc0/revision:unknown
> > > /sys/devices/soc0/serial_number:0000000000000000
> > > grep: /sys/devices/soc0/subsystem: Is a directory
> >
> > reverting this patch (2524b293a59e586afd06358d0b191ab57208a920):
> > > $ grep . /sys/devices/soc0/*
> > > /sys/devices/soc0/family:Freescale i.MX
> > > /sys/devices/soc0/machine:TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MP-RAS314
> > > grep: /sys/devices/soc0/power: Is a directory
> > > /sys/devices/soc0/revision:1.1
> > > /sys/devices/soc0/serial_number:469677A693A4B8CE131D180033E44903
> > > /sys/devices/soc0/soc_id:i.MX8MP
> > > grep: /sys/devices/soc0/subsystem: Is a directory
> >
> > soc_id is restored. Now that I write these lines I noticed that
> > serial_number also contained empty value which is restored with the revert.
>
> Any update on this? I would say this is a regression in 7.1-rc1.
>
> I noticed the same issue, and CAAM is not working.
>
> [ 0.000000] Linux version 7.1.0-rc1-0.0.0-devel (oe-user@oe-host) (aarch64-tdx-linux-gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.46) #1 SMP PREEMPT Sun Apr 26 21:19:00 UTC 2026
> ...
> [ 10.611139] caam 30900000.crypto: No clock data provided for i.MX SoC
> [ 10.611211] caam 30900000.crypto: probe with driver caam failed with error -22
I guess this is the fix
https://lore.kernel.org/all/20260427-soc-imx8m-fix-v1-1-1fe5b43d8090@nxp.com/
^ permalink raw reply
* Re: [PATCH 1/3] iio: adc: xilinx-xadc: remove unnecessary includes and add missing ones
From: Andy Shevchenko @ 2026-04-27 9:50 UTC (permalink / raw)
To: Joshua Crofts
Cc: Caio Morais, andy, dlechner, jic23, michal.simek, nuno.sa,
linux-arm-kernel, linux-iio
In-Reply-To: <CALoEA-zz-2cG7SJr1iKNQ0H81TVMXLQh3omkxJc9YRW673Kqqw@mail.gmail.com>
On Mon, Apr 27, 2026 at 08:42:55AM +0200, Joshua Crofts wrote:
> On Sun, 26 Apr 2026 at 23:20, Caio Morais <caiomorais@usp.br> wrote:
> >
> > Signed-off-by: Caio Morais <caiomorais@usp.br>
> > ---
>
> You're missing the commit message body. While it's understandable
> what changes you've done in this patch, it's good to expand the idea
> further (what you did, how you did it, why you did it). This goes for all
> of the patches in your series.
Dunno if it's your first review (congrats in that case!), but I fully agree with.
We do not accept patches with the empty commit message bodies.
(*Yes, it used to be okay twenty ears ago, but now.)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] iio: adc: meson-saradc: fix calibration buffer leak on error
From: Jonathan Cameron @ 2026-04-27 9:54 UTC (permalink / raw)
To: Felix Gu
Cc: Rosen Penev, David Lechner, Nuno Sá, Andy Shevchenko,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-iio, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <CAN4SLj1_45OG+1AdzCfNiV7T3VX9tpQTcX8krsTDruhtYLzEGw@mail.gmail.com>
On Sun, 26 Apr 2026 23:26:33 +0800
Felix Gu <ustc.gu@gmail.com> wrote:
> On Sun, Apr 26, 2026 at 6:41 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > That is the minimal fix, so we should probably do that first
> > even if we then circle back to consider if __free() magic is worth using here.
> >
> > J
>
> Hi Jonathan,
> You prefer a minimal fix here?
Yes please. Then if you like we can carry on discussion about whether
__free() is a good change here as a follow up.
That can include the fact that it would have avoided this bug ever being
introduced.
Thanks,
Jonathan
>
> Best regards,
> Felix
^ permalink raw reply
* Re: [PATCH 2/3] iio: buffer: industrialio-triggered-buffer: fix includes with IWYU
From: Andy Shevchenko @ 2026-04-27 9:59 UTC (permalink / raw)
To: Caio Morais
Cc: andy, dlechner, jic23, michal.simek, nuno.sa, linux-arm-kernel,
linux-iio
In-Reply-To: <20260426211834.3318306-3-caiomorais@usp.br>
On Sun, Apr 26, 2026 at 06:18:01PM -0300, Caio Morais wrote:
...
> -#include <linux/kernel.h>
> -#include <linux/export.h>
> +#include <linux/errno.h>
> +#include <linux/linkage.h>
Hmm... This one rarely appears in the drivers. What do we get from it here?
> #include <linux/module.h>
> +#include <linux/stddef.h>
This one for NULL, for example, which is fine.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] iio: adc: xilinx-xadc: remove unnecessary includes and add missing ones
From: Joshua Crofts @ 2026-04-27 10:00 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Caio Morais, andy, dlechner, jic23, michal.simek, nuno.sa,
linux-arm-kernel, linux-iio
In-Reply-To: <ae8xeI8VVUWn6OqQ@ashevche-desk.local>
On Mon, 27 Apr 2026 at 11:50, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
> Dunno if it's your first review (congrats in that case!), but I fully agree with.
Yes, this is my first review :)
> We do not accept patches with the empty commit message bodies.
> (*Yes, it used to be okay twenty ears ago, but now.)
I maybe also take issue with the fact that the series (although they are
the same logical change) is composed of changes in different iio
subsystems (adc, buffer and common). Shouldn't these be sent
separately?
--
Kind regards
CJD
^ permalink raw reply
* [PATCH] media: cedrus: clean up media device on probe failure
From: 박명훈 @ 2026-04-27 10:00 UTC (permalink / raw)
To: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland
Cc: Myeonghun Pak, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel, stable, Ijae Kim
From: Myeonghun Pak <mhun512@gmail.com>
cedrus_probe() initializes the media device before registering the video
device, the media controller, and the media device. If any of those later
steps fails, probe returns without calling media_device_cleanup(), so the
media device internals initialized by media_device_init() are left behind.
Add a media-device cleanup label to the probe unwind path and route video
registration failures through it as well.
Fixes: 50e761516f2b8c ("media: platform: Add Cedrus VPU decoder driver")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 6600245dff..2c25654640 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -507,7 +507,7 @@ static int cedrus_probe(struct platform_device *pdev)
ret = video_register_device(vfd, VFL_TYPE_VIDEO, 0);
if (ret) {
v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
- goto err_m2m;
+ goto err_media_cleanup;
}
v4l2_info(&dev->v4l2_dev,
@@ -533,6 +533,8 @@ static int cedrus_probe(struct platform_device *pdev)
v4l2_m2m_unregister_media_controller(dev->m2m_dev);
err_video:
video_unregister_device(&dev->vfd);
+err_media_cleanup:
+ media_device_cleanup(&dev->mdev);
err_m2m:
v4l2_m2m_release(dev->m2m_dev);
err_v4l2:
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v2 0/3]: fix unnecessary includes and add missing ones across multiple drivers
From: Jonathan Cameron @ 2026-04-27 10:03 UTC (permalink / raw)
To: Caio Morais
Cc: andy, dlechner, michal.simek, nuno.sa, linux-arm-kernel,
linux-iio
In-Reply-To: <20260426211834.3318306-1-caiomorais@usp.br>
On Sun, 26 Apr 2026 18:17:59 -0300
Caio Morais <caiomorais@usp.br> wrote:
> From: Caio Morais <caiomorais@usp.br>
>
> This series removes unnecessary includes and adds missing ones as reported
> by the include-what-you-use (IWYU) tool across different IIO drivers.
One series per driver. Having a shared one for the core is fine but definitely
don't mix core and drivers. Tend to have entirely different sets of
reviewers!
J
>
> Caio Morais (3):
> iio: adc: xilinx-xadc: remove unnecessary includes and add missing
> ones
> iio: buffer: industrialio-triggered-buffer: fix includes with IWYU
> iio: common: st_sensors: fix includes with IWYU
>
> drivers/iio/adc/xilinx-xadc-events.c | 6 +++++-
> drivers/iio/buffer/industrialio-triggered-buffer.c | 6 ++++--
> drivers/iio/common/st_sensors/st_sensors_i2c.c | 7 +++++--
> drivers/iio/common/st_sensors/st_sensors_spi.c | 9 +++++++--
> 4 files changed, 21 insertions(+), 7 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/3] iio: adc: xilinx-xadc: remove unnecessary includes and add missing ones
From: Jonathan Cameron @ 2026-04-27 10:05 UTC (permalink / raw)
To: Joshua Crofts
Cc: Caio Morais, andy, dlechner, michal.simek, nuno.sa,
linux-arm-kernel, linux-iio
In-Reply-To: <CALoEA-zz-2cG7SJr1iKNQ0H81TVMXLQh3omkxJc9YRW673Kqqw@mail.gmail.com>
On Mon, 27 Apr 2026 08:42:55 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> On Sun, 26 Apr 2026 at 23:20, Caio Morais <caiomorais@usp.br> wrote:
> >
> > From: Caio Morais <caiomorais@usp.br>
> >
> > Signed-off-by: Caio Morais <caiomorais@usp.br>
> > ---
>
> You're missing the commit message body. While it's understandable
> what changes you've done in this patch, it's good to expand the idea
> further (what you did, how you did it, why you did it). This goes for all
> of the patches in your series.
Also, why only this file of the several that make up that driver?
Looks like kernel.h is included in xilinx-xadc-core.c as well.
I'd talk about kernel.h specifically in the patch description and
why stopping including that is seen as a nice to have.
>
> > +#include <linux/bitmap.h>
> > +#include <linux/errno.h>
> > +#include <linux/mutex.h>
> > +#include <linux/types.h>
> > +
> > #include <linux/iio/events.h>
> > #include <linux/iio/iio.h>
> > -#include <linux/kernel.h>
> >
> > #include "xilinx-xadc.h"
> >
> > --
> > 2.54.0
> >
> >
^ permalink raw reply
* Re: [PATCH 2/3] iio: buffer: industrialio-triggered-buffer: fix includes with IWYU
From: Jonathan Cameron @ 2026-04-27 10:08 UTC (permalink / raw)
To: Caio Morais
Cc: andy, dlechner, michal.simek, nuno.sa, linux-arm-kernel,
linux-iio
In-Reply-To: <20260426211834.3318306-3-caiomorais@usp.br>
On Sun, 26 Apr 2026 18:18:01 -0300
Caio Morais <caiomorais@usp.br> wrote:
> From: Caio Morais <caiomorais@usp.br>
>
> Signed-off-by: Caio Morais <caiomorais@usp.br>
> ---
> drivers/iio/buffer/industrialio-triggered-buffer.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/buffer/industrialio-triggered-buffer.c b/drivers/iio/buffer/industrialio-triggered-buffer.c
> index 9bf75dee7..a91d439d7 100644
> --- a/drivers/iio/buffer/industrialio-triggered-buffer.c
> +++ b/drivers/iio/buffer/industrialio-triggered-buffer.c
> @@ -4,9 +4,11 @@
> * Author: Lars-Peter Clausen <lars@metafoo.de>
> */
>
> -#include <linux/kernel.h>
> -#include <linux/export.h>
Why? There are numerous uses of EXPORT_SYMBOL() in this file.
> +#include <linux/errno.h>
> +#include <linux/linkage.h>
Wow. That one is obscure. What needed that?
For these, IWYU patches, I prefer to add that info after the ---
so it's easy to review them without opening the code up to take a closer look.
> #include <linux/module.h>
> +#include <linux/stddef.h>
> +
> #include <linux/iio/iio.h>
> #include <linux/iio/buffer.h>
> #include <linux/iio/buffer_impl.h>
^ permalink raw reply
* Re: [PATCH 3/3] iio: common: st_sensors: fix includes with IWYU
From: Jonathan Cameron @ 2026-04-27 10:10 UTC (permalink / raw)
To: Caio Morais
Cc: andy, dlechner, michal.simek, nuno.sa, linux-arm-kernel,
linux-iio
In-Reply-To: <20260426211834.3318306-4-caiomorais@usp.br>
On Sun, 26 Apr 2026 18:18:02 -0300
Caio Morais <caiomorais@usp.br> wrote:
> From: Caio Morais <caiomorais@usp.br>
>
> Signed-off-by: Caio Morais <caiomorais@usp.br>
> ---
> drivers/iio/common/st_sensors/st_sensors_i2c.c | 7 +++++--
> drivers/iio/common/st_sensors/st_sensors_spi.c | 9 +++++++--
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_i2c.c b/drivers/iio/common/st_sensors/st_sensors_i2c.c
> index 7156302fe..04d106def 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_i2c.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_i2c.c
> @@ -7,12 +7,15 @@
> * Denis Ciocca <denis.ciocca@st.com>
> */
>
> +#include <linux/device.h>
> +#include <linux/err.h>
> #include <linux/i2c.h>
> -#include <linux/kernel.h>
> +#include <linux/linkage.h>
> #include <linux/module.h>
> -#include <linux/iio/iio.h>
> #include <linux/regmap.h>
>
> +#include <linux/iio/iio.h>
> +
> #include <linux/iio/common/st_sensors_i2c.h>
>
> #define ST_SENSORS_I2C_MULTIREAD 0x80
> diff --git a/drivers/iio/common/st_sensors/st_sensors_spi.c b/drivers/iio/common/st_sensors/st_sensors_spi.c
> index 0da270139..884077d51 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_spi.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_spi.c
> @@ -7,12 +7,17 @@
> * Denis Ciocca <denis.ciocca@st.com>
> */
>
> -#include <linux/kernel.h>
> +#include <linux/device.h>
This one is similar to kernel.h in that it's mostly a catch all header
that we prefer to replace if possible with more specific ones.
Now the driver might directly dereference a struct device, but if
so that normally indicates something we should clean up.
Maybe it's something else. As mentioned in previous review
providing that info under the --- in the patch can save time on
questions like this.
> +#include <linux/err.h>
> +#include <linux/linkage.h>
> #include <linux/module.h>
> -#include <linux/iio/iio.h>
> #include <linux/property.h>
> #include <linux/regmap.h>
> #include <linux/spi/spi.h>
> +#include <linux/stddef.h>
> +#include <linux/types.h>
> +
> +#include <linux/iio/iio.h>
>
> #include <linux/iio/common/st_sensors_spi.h>
>
^ permalink raw reply
* [PATCH v2 0/4] ARM: pxa: attach software nodes to the GPIO controllers
From: Bartosz Golaszewski @ 2026-04-27 10:14 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
Convert GPIO controllers and their consumers on the PXA platform to using
"attached" software nodes. Since everything happens in a bord-file, it's
quite straightforward. We technically now have a way of passing an
unregistered software node to platform_device_register_full() but that
requires using struct platform_device_info and since the existing
platform devices are either referenced from other places or defined in a
different compilation unit, I wanted to reduce the impact of the changes
I can't test and went with the older method.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v2:
- Rebase on top of v7.1-rc1
- Add a patch making some platform device definitions static
- Link to v1: https://patch.msgid.link/20260331-pxa-gpio-swnodes-v1-0-f66d86d10d8d@oss.qualcomm.com
---
Bartosz Golaszewski (4):
ARM: pxa: statify platform device definitions in spitz board file
ARM: pxa: spitz: attach software nodes to their target GPIO controllers
ARM: pxa: pxa25x: attach software node to its target GPIO controller
ARM: pxa: pxa27x: attach software node to its target GPIO controller
arch/arm/mach-pxa/pxa25x.c | 5 ++++-
arch/arm/mach-pxa/pxa27x.c | 5 ++++-
arch/arm/mach-pxa/spitz.c | 11 ++++++++---
3 files changed, 16 insertions(+), 5 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260330-pxa-gpio-swnodes-132a81af10e3
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 2/4] ARM: pxa: spitz: attach software nodes to their target GPIO controllers
From: Bartosz Golaszewski @ 2026-04-27 10:14 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260427-pxa-gpio-swnodes-v2-0-86fc24b9e714@oss.qualcomm.com>
Software nodes describing the GPIO controllers for the spitz platform
are currently "dangling" - they're not actually attached to the relevant
controllers and don't allow real fwnode lookup. Attach them either by
directly assigning them to the struct device or by using the i2c board
info struct.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/spitz.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 3284b9f62be970555042a7292993e45d56fde47e..5091b601c4e1bf25cfee07429881894929853dfe 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -204,11 +204,15 @@ static struct platform_device spitz_scoop_2_device = {
static void __init spitz_scoop_init(void)
{
+ spitz_scoop_1_device.dev.fwnode = software_node_fwnode(&spitz_scoop_1_gpiochip_node);
platform_device_register(&spitz_scoop_1_device);
/* Akita doesn't have the second SCOOP chip */
- if (!machine_is_akita())
+ if (!machine_is_akita()) {
+ spitz_scoop_2_device.dev.fwnode = software_node_fwnode(
+ &spitz_scoop_2_gpiochip_node);
platform_device_register(&spitz_scoop_2_device);
+ }
}
/* Power control is shared with between one of the CF slots and SD */
@@ -988,6 +992,7 @@ static struct i2c_board_info spitz_i2c_devs[] = {
.type = "max7310",
.addr = 0x18,
.platform_data = &akita_pca953x_pdata,
+ .swnode = &akita_max7310_gpiochip_node,
},
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/4] ARM: pxa: statify platform device definitions in spitz board file
From: Bartosz Golaszewski @ 2026-04-27 10:14 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260427-pxa-gpio-swnodes-v2-0-86fc24b9e714@oss.qualcomm.com>
The scoop devices are not used outside of this board file so make them
static.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/spitz.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index c0b1f7e6be87411359b0020257ff12c73bbcbae3..3284b9f62be970555042a7292993e45d56fde47e 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -165,7 +165,7 @@ static struct scoop_config spitz_scoop_1_setup = {
.gpio_base = SPITZ_SCP_GPIO_BASE,
};
-struct platform_device spitz_scoop_1_device = {
+static struct platform_device spitz_scoop_1_device = {
.name = "sharp-scoop",
.id = 0,
.dev = {
@@ -192,7 +192,7 @@ static struct scoop_config spitz_scoop_2_setup = {
.gpio_base = SPITZ_SCP2_GPIO_BASE,
};
-struct platform_device spitz_scoop_2_device = {
+static struct platform_device spitz_scoop_2_device = {
.name = "sharp-scoop",
.id = 1,
.dev = {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 4/4] ARM: pxa: pxa27x: attach software node to its target GPIO controller
From: Bartosz Golaszewski @ 2026-04-27 10:14 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260427-pxa-gpio-swnodes-v2-0-86fc24b9e714@oss.qualcomm.com>
Software node describing the GPIO controller for the pxa27x platforms is
currently "dangling" - it's not actually attached to the relevant
controller and doesn't allow real fwnode lookup. Attach it once it's
registered as a firmware node before adding the platform device.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/pxa27x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index ff63619790383859ba111e3efe7619aa6cbd248e..bacfd50939fd447ffa11d398867dea7fa638988b 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -277,7 +277,6 @@ void __init pxa27x_set_i2c_power_info(struct i2c_pxa_platform_data *info)
}
static struct platform_device *devices[] __initdata = {
- &pxa27x_device_gpio,
&pxa27x_device_udc,
&pxa_device_pmu,
&pxa_device_i2s,
@@ -342,6 +341,10 @@ static int __init pxa27x_init(void)
if (!of_have_populated_dt()) {
software_node_register(&pxa2xx_gpiochip_node);
+ pxa27x_device_gpio.dev.fwnode = software_node_fwnode(
+ &pxa2xx_gpiochip_node);
+ platform_device_register(&pxa27x_device_gpio);
+
pxa2xx_set_dmac_info(&pxa27x_dma_pdata);
ret = platform_add_devices(devices,
ARRAY_SIZE(devices));
--
2.47.3
^ permalink raw reply related
* [PATCH v2 3/4] ARM: pxa: pxa25x: attach software node to its target GPIO controller
From: Bartosz Golaszewski @ 2026-04-27 10:14 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260427-pxa-gpio-swnodes-v2-0-86fc24b9e714@oss.qualcomm.com>
Software node describing the GPIO controller for the pxa25x platforms is
currently "dangling" - it's not actually attached to the relevant
controller and doesn't allow real fwnode lookup. Attach it once it's
registered as a firmware node before adding the platform device.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/pxa25x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 70509a5998142ec6b9c484e5f094751eda6db6cd..6875774f2cae1db4798d18c813f445bdc31b15de 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -179,7 +179,6 @@ void __init pxa25x_map_io(void)
}
static struct platform_device *pxa25x_devices[] __initdata = {
- &pxa25x_device_gpio,
&pxa25x_device_udc,
&pxa_device_pmu,
&pxa_device_i2s,
@@ -240,6 +239,10 @@ static int __init pxa25x_init(void)
if (!of_have_populated_dt()) {
software_node_register(&pxa2xx_gpiochip_node);
+ pxa25x_device_gpio.dev.fwnode = software_node_fwnode(
+ &pxa2xx_gpiochip_node);
+ platform_device_register(&pxa25x_device_gpio);
+
pxa2xx_set_dmac_info(&pxa25x_dma_pdata);
ret = platform_add_devices(pxa25x_devices,
ARRAY_SIZE(pxa25x_devices));
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] pinctrl: qcom: Make important drivers default
From: Konrad Dybcio @ 2026-04-27 10:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Russell King, Bjorn Andersson, Konrad Dybcio,
Linus Walleij, linux-arm-kernel, linux-kernel, linux-arm-msm,
linux-gpio
In-Reply-To: <20260425155505.83688-2-krzysztof.kozlowski@oss.qualcomm.com>
On 4/25/26 5:55 PM, Krzysztof Kozlowski wrote:
> The main SoC TLMM (Top-Level Multiplexer) pin controller drivers are
> essential for booting up SoCs and are not really optional for a given
> platform. Kernel should not ask users choice of drivers when that
> choice is obvious and known to the developers that answer should be
> 'yes' or 'module'.
>
> Switch all Qualcomm TLMM pin controller drivers to a default 'yes' for
> ARCH_QCOM. This has impact:
>
> 1. arm64 defconfig: enable PINCTRL_SM7150 and PINCTRL_HAWI, which were
> not selected before but should be, because these platforms need them
> for proper boot.
>
> 2. arm qcom_defconfig: no changes.
>
> 3. arm multi_v7 defconfig: enable drivers necessary to boot ARM 32-bit
> platforms, which are already enabled on qcom_defconfig.
>
> 4. COMPILE_TEST builds: enable by default all drivers for arm or arm64
> builds, whenever ARCH_QCOM is selected. This has impact on build
> time and feels logical, because if one selects ARCH_QCOM then
> probably by default wants to build test it entirely. Kernels with
> COMPILE_TEST are not supposed to be used for booting.
>
> 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] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
From: Bartosz Golaszewski @ 2026-04-27 10:32 UTC (permalink / raw)
To: Linus Walleij
Cc: Frank Wunderlich, Frank Wunderlich, bartosz.golaszewski, linux,
sean.wang, matthias.bgg, angelogioacchino.delregno,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel
In-Reply-To: <CAD++jLkz189qT1kJr34ratZT_n20oWEAQg8q0ttQ-VrsFchp7g@mail.gmail.com>
On Sun, Apr 19, 2026 at 11:25 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Mon, Apr 13, 2026 at 6:59 PM Frank Wunderlich
> <frank.wunderlich@linux.dev> wrote:
> > Am 13. April 2026 um 10:01 schrieb "Linus Walleij" <linusw@kernel.org mailto:linusw@kernel.org?to=%22Linus%20Walleij%22%20%3Clinusw%40kernel.org%3E >:
> > >
> > > On Fri, Apr 10, 2026 at 11:24 AM Frank Wunderlich
> > > <frank-w@public-files.de> wrote:
> > >
> > > >
> > > > Gesendet: Freitag, 10. April 2026 um 09:09
> > > > Von: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > > > An: "Frank Wunderlich" <linux@fw-web.de>, "Sean Wang" <sean.wang@kernel.org>, "Linus Walleij" <linusw@kernel.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Bartosz Golaszewski" <brgl@kernel.org>
> > > > CC: linux-mediatek@lists.infradead.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > > > Betreff: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
> > > >
> > > > If the gpio_chip::get_direction() callback is not implemented by the GPIO
> > > > controller driver, GPIOLIB emits a warning.
> > > >
> > > > Implement get_direction() for the GPIO part of pinctrl-moore.
> > > >
> > > > Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check")
> > > > Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()")
> > > > Reported-by: Frank Wunderlich <linux@fw-web.de>
> > > >
> > > > please use the email i used for SoB in my linked patch (closes link below), the other email i use only for sending patches due to mail provider limitation.
> > > >
> > > I can't fix this up because the closes link isn't working right now.
> > > Is it the same
> > > as the one this mail came from frank-w@public-files.de?
> >
> > yes, closes-link works for me
>
> Fixed up and applied. Will be going in as fix for v7.1.
>
> Yours,
> Linus Walleij
>
Hi Linus!
It seems this one got lost somewhere along the way? I don't see it in
mainline nor next.
Bart
^ permalink raw reply
* Re: [PATCH v4 3/3] coco: guest: arm64: Query host IPA-change alignment via RHI
From: Marc Zyngier @ 2026-04-27 10:33 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-kernel, iommu, linux-coco, linux-arm-kernel, kvmarm,
Catalin Marinas, Jason Gunthorpe, Marek Szyprowski, Robin Murphy,
Steven Price, Suzuki K Poulose, Thomas Gleixner, Will Deacon
In-Reply-To: <20260427063108.909019-4-aneesh.kumar@kernel.org>
On Mon, 27 Apr 2026 07:31:08 +0100,
"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
>
> Add the Realm Host Interface support needed to query host configuration
> from a Realm guest. Define the RHI hostconf SMCs, add rsi_host_call(), and
> use them during Realm initialization to retrieve the host IPA-change
> alignment size.
I don't understand what "IPA-change" means. What you are after is the
host's sharing granule size.
>
> Expose that alignment through realm_get_hyp_pagesize() and
> mem_decrypt_granule_size() so shared-buffer allocation and
> encryption/decryption paths can honor the ipa change page-size requirement.
>
> If the host reports an invalid alignment (when alginment value is not
> multiple of 4K), do not enable Realm support.
>
> This provides the host alignment information required by the shared buffer
> alignment changes.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/include/asm/mem_encrypt.h | 3 ++
> arch/arm64/include/asm/rhi.h | 24 +++++++++++++
> arch/arm64/include/asm/rsi.h | 2 ++
> arch/arm64/include/asm/rsi_cmds.h | 10 ++++++
> arch/arm64/include/asm/rsi_smc.h | 7 ++++
> arch/arm64/kernel/Makefile | 2 +-
> arch/arm64/kernel/rhi.c | 54 ++++++++++++++++++++++++++++
> arch/arm64/kernel/rsi.c | 13 +++++++
> arch/arm64/mm/mem_encrypt.c | 8 +++++
> 9 files changed, 122 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/include/asm/rhi.h
> create mode 100644 arch/arm64/kernel/rhi.c
>
> diff --git a/arch/arm64/include/asm/mem_encrypt.h b/arch/arm64/include/asm/mem_encrypt.h
> index 314b2b52025f..5541911eb028 100644
> --- a/arch/arm64/include/asm/mem_encrypt.h
> +++ b/arch/arm64/include/asm/mem_encrypt.h
> @@ -16,6 +16,9 @@ int arm64_mem_crypt_ops_register(const struct arm64_mem_crypt_ops *ops);
> int set_memory_encrypted(unsigned long addr, int numpages);
> int set_memory_decrypted(unsigned long addr, int numpages);
>
> +#define mem_decrypt_granule_size mem_decrypt_granule_size
> +size_t mem_decrypt_granule_size(void);
> +
> int realm_register_memory_enc_ops(void);
>
> static inline bool force_dma_unencrypted(struct device *dev)
> diff --git a/arch/arm64/include/asm/rhi.h b/arch/arm64/include/asm/rhi.h
> new file mode 100644
> index 000000000000..0895dd92ea1d
> --- /dev/null
> +++ b/arch/arm64/include/asm/rhi.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2026 ARM Ltd.
> + */
> +
> +#ifndef __ASM_RHI_H_
> +#define __ASM_RHI_H_
> +
> +#include <linux/types.h>
> +
> +#define SMC_RHI_CALL(func) \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_STANDARD_HYP,\
> + (func))
> +
> +unsigned long rhi_get_ipa_change_alignment(void);
> +#define RHI_HOSTCONF_VER_1_0 0x10000
> +#define RHI_HOSTCONF_VERSION SMC_RHI_CALL(0x004E)
> +
> +#define __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT BIT(0)
> +#define RHI_HOSTCONF_FEATURES SMC_RHI_CALL(0x004F)
> +#define RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT SMC_RHI_CALL(0x0050)
> +#endif
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index 88b50d660e85..ae54fb3b1429 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -67,4 +67,6 @@ static inline int rsi_set_memory_range_shared(phys_addr_t start,
> return rsi_set_memory_range(start, end, RSI_RIPAS_EMPTY,
> RSI_CHANGE_DESTROYED);
> }
> +
> +unsigned long realm_get_hyp_pagesize(void);
> #endif /* __ASM_RSI_H_ */
> diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
> index 2c8763876dfb..a341ce0eeda1 100644
> --- a/arch/arm64/include/asm/rsi_cmds.h
> +++ b/arch/arm64/include/asm/rsi_cmds.h
> @@ -159,4 +159,14 @@ static inline unsigned long rsi_attestation_token_continue(phys_addr_t granule,
> return res.a0;
> }
>
> +static inline unsigned long rsi_host_call(struct rsi_host_call *rhi_call)
> +{
> + phys_addr_t addr = virt_to_phys(rhi_call);
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_invoke(SMC_RSI_HOST_CALL, addr, &res);
Errr... What guarantees that *rhi_call is *IPA contiguous*? This is
incredibly fragile. You should at the very least check that this isn't
vmalloc'd.
> +
> + return res.a0;
> +}
> +
> #endif /* __ASM_RSI_CMDS_H */
> diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rsi_smc.h
> index e19253f96c94..9ee8b5c7612e 100644
> --- a/arch/arm64/include/asm/rsi_smc.h
> +++ b/arch/arm64/include/asm/rsi_smc.h
> @@ -182,6 +182,13 @@ struct realm_config {
> */
> #define SMC_RSI_IPA_STATE_GET SMC_RSI_FID(0x198)
>
> +struct rsi_host_call {
> + union {
> + u16 imm;
> + u64 padding0;
> + };
> + u64 gprs[31];
> +} __aligned(0x100);
> /*
> * Make a Host call.
> *
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index fe627100d199..3e72dd9584ed 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -34,7 +34,7 @@ obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
> cpufeature.o alternative.o cacheinfo.o \
> smp.o smp_spin_table.o topology.o smccc-call.o \
> syscall.o proton-pack.o idle.o patching.o pi/ \
> - rsi.o jump_label.o
> + rsi.o jump_label.o rhi.o
>
> obj-$(CONFIG_COMPAT) += sys32.o signal32.o \
> sys_compat.o
> diff --git a/arch/arm64/kernel/rhi.c b/arch/arm64/kernel/rhi.c
> new file mode 100644
> index 000000000000..7cd6c5102464
> --- /dev/null
> +++ b/arch/arm64/kernel/rhi.c
> @@ -0,0 +1,54 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 ARM Ltd.
> + */
> +
> +#include <linux/mm.h>
> +#include <asm/rsi.h>
> +#include <asm/rhi.h>
> +
> +/* we need an aligned rhicall for rsi_host_call. slab is not yet ready */
> +static struct rsi_host_call hyp_pagesize_rhicall;
Why the "hyp_" prefix? This has absolutely nothing to with the
hypervisor.
> +unsigned long rhi_get_ipa_change_alignment(void)
> +{
> + long ret;
> + unsigned long ipa_change_align;
> +
> + hyp_pagesize_rhicall.imm = 0;
> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_VERSION;
> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
> + if (ret != RSI_SUCCESS)
> + goto err_out;
> +
> + if (hyp_pagesize_rhicall.gprs[0] != RHI_HOSTCONF_VER_1_0)
> + goto err_out;
> +
> + hyp_pagesize_rhicall.imm = 0;
> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_FEATURES;
> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
> + if (ret != RSI_SUCCESS)
> + goto err_out;
> +
> + if (!(hyp_pagesize_rhicall.gprs[0] & __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT))
> + goto err_out;
> +
> + hyp_pagesize_rhicall.imm = 0;
> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT;
> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
> + if (ret != RSI_SUCCESS)
> + goto err_out;
> +
> + ipa_change_align = hyp_pagesize_rhicall.gprs[0];
> + /* This error needs special handling in the caller */
> + if (ipa_change_align & (SZ_4K - 1))
> + return 0;
> +
> + return ipa_change_align;
> +
> +err_out:
> + /*
> + * For failure condition assume host is built with 4K page size
> + * and hence ipa change alignment can be guest PAGE_SIZE.
> + */
> + return PAGE_SIZE;
> +}
Why can't this be part of rsi.c? This is an RSI call, and it should be
part of the RSI initialisation.
> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
> index 9e846ce4ef9c..ff735c04e236 100644
> --- a/arch/arm64/kernel/rsi.c
> +++ b/arch/arm64/kernel/rsi.c
> @@ -14,8 +14,10 @@
> #include <asm/mem_encrypt.h>
> #include <asm/pgtable.h>
> #include <asm/rsi.h>
> +#include <asm/rhi.h>
>
> static struct realm_config config;
> +static unsigned long ipa_change_alignment = PAGE_SIZE;
>
> unsigned long prot_ns_shared;
> EXPORT_SYMBOL(prot_ns_shared);
> @@ -139,6 +141,11 @@ static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
> return 0;
> }
>
> +unsigned long realm_get_hyp_pagesize(void)
> +{
> + return ipa_change_alignment;
> +}
Again, this has nothing to do with the hypervisor, but the host. And
ipa_change_alignment is still a wording I can't wrap my small head
around.
> +
> void __init arm64_rsi_init(void)
> {
> if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
> @@ -147,6 +154,12 @@ void __init arm64_rsi_init(void)
> return;
> if (WARN_ON(rsi_get_realm_config(&config)))
> return;
> +
> + ipa_change_alignment = rhi_get_ipa_change_alignment();
> + /* If we don't get a correct alignment response, don't enable realm */
> + if (!ipa_change_alignment)
> + return;
But at the same time, you override a global value with an error, and
then paper over it in mem_decrypt_granule_size()...
> +
> prot_ns_shared = __phys_to_pte_val(BIT(config.ipa_bits - 1));
>
> if (arm64_ioremap_prot_hook_register(realm_ioremap_hook))
> diff --git a/arch/arm64/mm/mem_encrypt.c b/arch/arm64/mm/mem_encrypt.c
> index 38c62c9e4e74..f5d64bc29c20 100644
> --- a/arch/arm64/mm/mem_encrypt.c
> +++ b/arch/arm64/mm/mem_encrypt.c
> @@ -59,3 +59,11 @@ int set_memory_decrypted(unsigned long addr, int numpages)
> return crypt_ops->decrypt(addr, numpages);
> }
> EXPORT_SYMBOL_GPL(set_memory_decrypted);
> +
> +size_t mem_decrypt_granule_size(void)
> +{
> + if (is_realm_world())
> + return max(PAGE_SIZE, realm_get_hyp_pagesize());
If you didn't mess with ipa_change_alignment above, you shouldn't need
this max().
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v8 0/6] Add support for Orange Pi 5 Pro
From: Heiko Stuebner @ 2026-04-27 10:37 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Dennis Gilmore
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
Hi Dennis,
Am Samstag, 25. April 2026, 05:10:05 Mitteleuropäische Sommerzeit schrieb Dennis Gilmore:
> This series adds initial support for the Xunlong Orange Pi 5 Pro, based on
> the Rockchip RK3588S SoC. The board features eMMC, SD card, NVMe (PCIe),
> a Motorcomm YT6801 NIC (PCIe), WiFi/BT (BCM43456), dual HDMI output (the
> second via a Lontium LT8711UXD DP-to-HDMI bridge on dp0), and a 40-pin
> expansion header.
more as a general node as the dp-hdmi thing is ongoing, you might want
to just submit the orange-pi5-pro basics first and do a separate series
with the display parts (both driver + dts integration).
That way the core board support can already be applied and get testing.
Heiko
^ permalink raw reply
* Re: [PATCH v5 07/10] drm/rockchip: dw_hdmi_qp: Add missing newlines in dev_err_probe() messages
From: Heiko Stuebner @ 2026-04-27 10:39 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Andy Yan, Cristian Ciocaltea
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260426-dw-hdmi-qp-scramb-v5-7-d778e70c317b@collabora.com>
Am Sonntag, 26. April 2026, 02:20:19 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> Add the missing trailing newlines to a couple of dev_err_probe() calls
> in dw_hdmi_qp_rockchip_bind().
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v5 08/10] drm/rockchip: dw_hdmi_qp: Use local dev variable consistently in bind()
From: Heiko Stuebner @ 2026-04-27 10:39 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Andy Yan, Cristian Ciocaltea
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260426-dw-hdmi-qp-scramb-v5-8-d778e70c317b@collabora.com>
Am Sonntag, 26. April 2026, 02:20:20 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> Replace indirect struct device accesses via hdmi->dev and pdev->dev with
> the local dev parameter already available in dw_hdmi_qp_rockchip_bind(),
> for consistency and readability.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v5 06/10] drm/bridge: dw-hdmi-qp: Rate limit i2c read error messages
From: Heiko Stuebner @ 2026-04-27 10:41 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Andy Yan, Cristian Ciocaltea
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260426-dw-hdmi-qp-scramb-v5-6-d778e70c317b@collabora.com>
Am Sonntag, 26. April 2026, 02:20:18 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> During EDID reads, repeated i2c errors can flood the kernel log:
>
> [ 25.361716] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
> [ 25.363376] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
> ...
> [ 25.368671] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
> [ 25.369440] dwhdmiqp-rockchip fde80000.hdmi: failed to get edid
>
> Switch to dev_err_ratelimited() in dw_hdmi_qp_i2c_read() to reduce log
> spam while still reporting the condition.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH v6 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-04-27 10:46 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
This converts Nokia 770 to using real firmware node lookup for GPIOs by
attaching the software nodes describing GPIO controllers to their target
devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v6:
- Switch to using platform_device_register_full() and pass the software
node via the swnode field of struct platform_device_info
- Drop driver-core prerequisites from the series
- Rebase on top of v7.1-rc1
- Add patch dropping an unused variable
- Link to v5: https://patch.msgid.link/20260402-nokia770-gpio-swnodes-v5-0-d730db3dd299@oss.qualcomm.com
Changes in v5:
- Put ksysfs_init() in a separate new header
- Remove software_node_exit() in a separate patch
- Link to v4: https://patch.msgid.link/20260330-nokia770-gpio-swnodes-v4-0-b68592e977d0@oss.qualcomm.com
Changes in v4:
- Add patches making software nodes available earlier
- Remove stray newline
- Link to v3: https://lore.kernel.org/all/20260212112508.73500-1-bartosz.golaszewski@oss.qualcomm.com/
Changes in v3:
- fix references to the MPU node
Changes in v2:
- fix build with CONFIG_I2C_CBUS_GPIO
- only export the two symbols that are actually required by the nokia
board file
---
Bartosz Golaszewski (3):
ARM: omap1: drop unused variable from omap16xx_gpio_init()
ARM: omap1: use platform_device_register_full() for GPIO devices on OMAP 16xx
ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
arch/arm/mach-omap1/board-nokia770.c | 30 +++-----------
arch/arm/mach-omap1/common.h | 3 ++
arch/arm/mach-omap1/gpio16xx.c | 77 ++++++++++++++++++------------------
3 files changed, 47 insertions(+), 63 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260330-nokia770-gpio-swnodes-5da8ba35946e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v6 1/3] ARM: omap1: drop unused variable from omap16xx_gpio_init()
From: Bartosz Golaszewski @ 2026-04-27 10:46 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
In-Reply-To: <20260427-nokia770-gpio-swnodes-v6-0-b693296c1985@oss.qualcomm.com>
The pdata variable is set but not used. Remove it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-omap1/gpio16xx.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 55acec22fef4e73f20935473602ef6cb2f4f379c..e8dbe173bd33fae72c7c884f930a530f78096839 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -212,7 +212,6 @@ static int __init omap16xx_gpio_init(void)
void __iomem *base;
struct resource *res;
struct platform_device *pdev;
- struct omap_gpio_platform_data *pdata;
if (!cpu_is_omap16xx())
return -EINVAL;
@@ -226,7 +225,6 @@ static int __init omap16xx_gpio_init(void)
for (i = 0; i < ARRAY_SIZE(omap16xx_gpio_dev); i++) {
pdev = omap16xx_gpio_dev[i];
- pdata = pdev->dev.platform_data;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (unlikely(!res)) {
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox