* Re: [PATCH] arm64: dts: aspeed: Fix duplicate pinctrl labels and address scheme
From: Andrew Jeffery @ 2026-06-12 6:42 UTC (permalink / raw)
To: Ryan Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Arnd Bergmann
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260611-dtsi_fix-v1-1-ef2b7cd86d6d@aspeedtech.com>
Hi Ryan,
On Thu, 2026-06-11 at 14:50 +0800, Ryan Chen wrote:
> Fix duplicate pinctrl_tach{0-15} and pinctrl_n{cts,dcd,dsr,ri}5 labels
> in aspeed-g7-soc1-pinctrl.dtsi.
>
> Drop the cpu-index from secondary/tertiary container nodes: reduce the
> "#address-cells" from 2 to 1 and update ssp_nvic/tsp_nvic unit-address
> and reg accordingly. Also remove URL comments from the DTS.
>
> Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au>
> Fixes: e77bb5dc5759 ("arm64: dts: aspeed: Add initial AST27xx SoC device tree")
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> This series contains follow-up fixes for the AST27xx DTS support that
> was merged into linux-next (e77bb5dc5759).
>
> Two issues were identified after merge by Andrew Jeffery during review
> of the pending v11 series:
These were identified by the sashiko bot, not so much by me, as I
hadn't got around to looking at the patches at the time. I did comment
in the replies though:
https://lore.kernel.org/all/20260609025708.ADBFE1F00893@smtp.kernel.org/
Separately, the series at hand was v9, so any subsequent revision would
have been v10, not v11. This isn't significant on its own, but it is
another contribution to the collection of small errors that are
accumulating at this point, which concerns me. Please take care.
>
> 1. Duplicate pinctrl state labels in aspeed-g7-soc1-pinctrl.dtsi caused
> dtc to abort with fatal label-redefinition errors.
However, it didn't. soc/dt @ 564edaca1486 ("Merge tag 'sunxi-dt-for-
7.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux
into soc/dt"), which includes the v9 patches at e77bb5dc5759 ("arm64:
dts: aspeed: Add initial AST27xx SoC device tree"), builds without
error.
Why? Well, the report from sashiko appears misleading. Usually
duplicate labels do cause an error, for example:
$ cat dle.dts
/dts-v1/;
/ {
inner: test1 {
prop-inner;
};
inner: test1 {
prop-inner;
};
};
$ dtc -o /dev/null dle.dts
dle.dts:6.15-8.4: ERROR (duplicate_node_names): /test1: Duplicate node name
ERROR: Input tree has errors, aborting (use -f to force output)
$ cat dle-1.dts
/dts-v1/;
/ { };
&{/} {
inner: test0 {
prop-inner;
};
inner: test1 {
prop-inner;
};
};
$ dtc -o /dev/null dle-1.dts
dle-1.dts:8.15-10.4: ERROR (duplicate_label): /test1: Duplicate label 'inner' on /test1 and /test0
ERROR: Input tree has errors, aborting (use -f to force output)
However, a relatively minimal reproduction of the case at hand is:
$ cat dlu.dts
/dts-v1/;
/ { };
&{/} {
inner: test1 {
prop-inner;
};
inner: test1 {
prop-inner;
};
};
$ dtc -o /dev/null dlu.dts
$
This doesn't error out. I recommend not assuming reports from the bot
are entirely accurate. Please test that its claims make sense before
proceeding.
While it's not good that there were duplicate nodes and labels, it is
good that you've tidied them up.
If there are modifications to the aspeed-g7-soc*-pinctrl.dtsi files in
the future, I ask that you them sorted first so we can minimise the
chance of falling into this trap again. The current order seems fairly
haphazard and likely contributed to the oversight.
>
> 2. The synthetic container nodes (secondary, tertiary) for sub-processor
I'm not sure synthetic is the right word here. We're still describing
the hardware, just components that have their own distinct address
spaces.
On a separate note, if you feel the need to make a list when describing
the change (e.g. in the commit message or patch notes) it's usually an
indicator that the change should be split into separate commits. Please
keep this in mind for future changes.
> interrupt controllers used a 2-cell address scheme to encode a
> <cpu-index reg-base> tuple. Since the cpu-index adds no value for
> nodes that are purely phandle anchors, Andrew requested we drop it
> and use the bare register address instead.
> ---
> arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi | 14 ++-
> .../boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi | 102 ---------------------
> 2 files changed, 6 insertions(+), 110 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> index ef283d95649a..58193c3c3696 100644
> --- a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> +++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> @@ -84,32 +84,30 @@ l2: l2-cache0 {
> };
>
> secondary {
> - #address-cells = <2>;
> - /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n491 */
> + #address-cells = <1>;
> #size-cells = <0>;
> - /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n430 */
>
> - ssp_nvic: interrupt-controller@1,e000e100 {
> + ssp_nvic: interrupt-controller@e000e100 {
> compatible = "arm,v7m-nvic";
> #interrupt-cells = <2>;
> #address-cells = <0>;
> interrupt-controller;
> - reg = <1 0xe000e100>;
> + reg = <0xe000e100>;
Some other cleanups to consider are ensuring the property ordering
conforms to the DTS coding style:
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node
The following grep is likely helpful:
git grep -C1 -F 'compatible =' arch/arm64/boot/dts/aspeed
Andrew
^ permalink raw reply
* Re: [PATCH v7 6/6] coco: guest: arm64: Replace dummy CCA device with sysfs ABI
From: Aneesh Kumar K.V @ 2026-06-12 6:07 UTC (permalink / raw)
To: Dan Williams (nvidia), linux-coco, linux-arm-kernel, linux-kernel
Cc: Catalin Marinas, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price, Suzuki K Poulose, Andre Przywara
In-Reply-To: <6a2b103d77596_344af1000@djbw-dev.notmuch>
"Dan Williams (nvidia)" <djbw@kernel.org> writes:
> Aneesh Kumar K.V (Arm) wrote:
>> The SMCCC firmware driver now creates the arm-smccc platform device and
>> instantiates the CCA RSI auxiliary devices once the RSI ABI is discovered.
>> The arm64-specific arm-cca-dev platform device stub is therefore no longer
>> needed.
>>
>> However, userspace has used the arm-cca-dev platform device to detect Arm
>> CCA Realm guests [1]. Removing it without a replacement would break that
>> detection and would also leave userspace depending on kernel device-model
>> details.
>>
>> Add /sys/firmware/cca/realm_guest as a stable, architecture-provided ABI
>> for detecting whether the kernel is running as an Arm CCA Realm guest. The
>> file returns 1 in Realm world and 0 otherwise, similar to the existing s390
>> /sys/firmware/uv/prot_virt_guest interface for protected virtualization
>> guests.
>>
>> Remove the dummy arm-cca-dev registration now that userspace has a
>> dedicated CCA Realm guest indicator, and document the new ABI in
>> Documentation/ABI/testing/sysfs-firmware-cca.
>
> I would have expected an attribute in /sys/class/tsm/tsmX to be the
> common protected guest indicator. Then, if you need to distinguish the
> architecture that registered that tsm it would be in the name of the
> parent device for the tsm class device.
>
It is not clear whether we need this capability early, for example in an
initrd configuration before loading the TSM driver, since
systemd-detect-virt reports the CC architecture.
Also, the general feedback was not to depend on device names or paths to
identify a confidential computing guest. Hence, parsing paths such as
../../devices/arm-rmi-dev-1/tsm/tsm0 may not be advisable.
>
> That also gives you the property that a uevent has signalled the arrival
> of tsm guest services. Otherwise, userspace still needs some custom
> device-model details to know when it can start issuing tsm requests.
>
> Is auxilliary device arrival too late in the flow for what systemd
> needs?
Systemd uses that to build part of its trust model.
static int import_credentials_qemu(ImportCredentialsContext *c) {
if (detect_container() > 0) /* don't access /sys/ in a container */
return 0;
if (detect_confidential_virtualization() > 0) /* don't trust firmware if confidential VMs */
return 0;
....
It also use that to build environment settings
cv = detect_confidential_virtualization();
if (cv > 0) {
r = strv_env_assign(&nl, "SYSTEMD_CONFIDENTIAL_VIRTUALIZATION", confidential_virtualization_to_string(cv));
IIUC, this would require the facility to be present even before we can
load the full set of modules.
-aneesh
^ permalink raw reply
* Re: [PATCH 2/2] phy: nuvoton: Add MA35D1 USB2 OTG PHY driver
From: Joey Lu @ 2026-06-12 5:53 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jacky Huang, Shan-Chun Hung, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <aiqWSGCuhAK7hoY9@vaman>
On 6/11/2026 7:04 PM, Vinod Koul wrote:
> On 04-06-26, 18:12, Joey Lu wrote:
>> Add a PHY driver for the USB 2.0 PHYs in the Nuvoton MA35D1 SoC,
>> intended for use with the EHCI and OHCI host controllers.
>>
>> The MA35D1 SoC has two USB ports:
>>
>> - USB0: an OTG port shared between a DWC2 gadget controller and
>> EHCI0/OHCI0 host controllers. A hardware mux automatically routes
>> the physical USB0 signals to the appropriate controller based on the
>> USB ID pin state. The DWC2 IP is device-only in hardware,
>> so host-mode operation on USB0 is handled entirely by EHCI0/OHCI0.
>>
>> - USB1: a dedicated host-only port served by EHCI1/OHCI1.
>>
>> The driver implements:
>> - Power-On Reset sequence with a guard that skips re-initialization if
>> the PHY is already operational. This protects PHY0 when the DWC2
>> gadget driver has already run its own init before EHCI0 probes.
>> - Optional resistor calibration trim via nuvoton,rcalcode.
>> - Optional over-current detect polarity via nuvoton,oc-active-high.
>> - For PHY0 only: a USB role switch that exposes the hardware ID pin
>> state (PWRONOTP[16]).
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/phy/nuvoton/Kconfig | 15 ++
>> drivers/phy/nuvoton/Makefile | 1 +
>> drivers/phy/nuvoton/phy-ma35d1-otg.c | 264 +++++++++++++++++++++++++++
>> 3 files changed, 280 insertions(+)
>> create mode 100644 drivers/phy/nuvoton/phy-ma35d1-otg.c
>>
>> diff --git a/drivers/phy/nuvoton/Kconfig b/drivers/phy/nuvoton/Kconfig
>> index d02cae2db315..5fdd13f841e7 100644
>> --- a/drivers/phy/nuvoton/Kconfig
>> +++ b/drivers/phy/nuvoton/Kconfig
>> @@ -10,3 +10,18 @@ config PHY_MA35_USB
>> help
>> Enable this to support the USB2.0 PHY on the Nuvoton MA35
>> series SoCs.
>> +
>> +config PHY_MA35_USB_OTG
>> + tristate "Nuvoton MA35 USB2.0 OTG PHY driver"
>> + depends on ARCH_MA35 || COMPILE_TEST
>> + depends on OF
>> + select GENERIC_PHY
>> + select MFD_SYSCON
>> + select USB_ROLE_SWITCH
>> + help
>> + Enable this to support the USB2.0 OTG PHY on the Nuvoton MA35
>> + series SoCs. This driver handles PHY initialization for the
>> + EHCI/OHCI host controllers, including per-PHY power-on reset,
>> + resistor calibration trim, and over-current polarity
>> + configuration. For the OTG port (PHY0), it also monitors the
>> + USB ID pin and registers a USB role switch.
>> diff --git a/drivers/phy/nuvoton/Makefile b/drivers/phy/nuvoton/Makefile
>> index 2937e3921898..3ecd76f35d7c 100644
>> --- a/drivers/phy/nuvoton/Makefile
>> +++ b/drivers/phy/nuvoton/Makefile
>> @@ -1,3 +1,4 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> obj-$(CONFIG_PHY_MA35_USB) += phy-ma35d1-usb2.o
>> +obj-$(CONFIG_PHY_MA35_USB_OTG) += phy-ma35d1-otg.o
> Have you considered reusing usb2 driver with a different power_on
> function? Or handle the differences internally in the driver. There are
> few similarities in two and some things are different
Thank you for the excellent suggestion regarding reusing the existing
USB2 driver.
After further evaluation and local testing, I verified that it is
entirely feasible to reuse the driver. Consequently, I will drop the
separate phy-ma35d1-otg.c patch series and submit a new patch set that
extends the existing phy-ma35d1-usb2.c mainline driver.
In the upcoming patch series, I will expand the driver's capability from
a single-port PHY0 peripheral driver to a dual-port manager supporting
both PHY0 and PHY1, while integrating OTG features.
BR,
Joey
>
^ permalink raw reply
* Re: [PATCH v7 5/6] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Aneesh Kumar K.V @ 2026-06-12 5:47 UTC (permalink / raw)
To: Suzuki K Poulose, linux-coco, linux-arm-kernel, linux-kernel
Cc: Catalin Marinas, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price, Andre Przywara
In-Reply-To: <b1d4b888-bdbe-4a45-8561-4f27e0e9a1de@arm.com>
Suzuki K Poulose <suzuki.poulose@arm.com> writes:
..
>> diff --git a/include/linux/arm-smccc-rsi.h b/include/linux/arm-smccc-rsi.h
>> index fddb77986f70..ae663aa8fd7f 100644
>> --- a/include/linux/arm-smccc-rsi.h
>> +++ b/include/linux/arm-smccc-rsi.h
>> @@ -8,6 +8,8 @@
>>
>> #include <linux/arm-smccc.h>
>>
>> +#define RSI_DEV_NAME "arm-rsi-dev"
>
> This shouldn't be here ? This is not part of the SMCCC RSI standard, but
> a linux thing. May be in drivers/firmware/../rsi.h ?
>
The name is used by the Arm SMCCC firmware driver
(drivers/firmware/smccc/smccc.c) and the arm-cca-guest driver.
Since it is used by the Arm SMCCC firmware driver, I used the above
header. We do not currently have a generic placeholder for RSI/RMI
definitions under drivers/.
-aneesh
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Chen-Yu Tsai @ 2026-06-12 5:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Heikki Krogerus, Bartosz Golaszewski, Greg Kroah-Hartman,
Daniel Scally, Sakari Ailus, Rafael J. Wysocki, Danilo Krummrich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <aisEccAOm3qoXjxd@ashevche-desk.local>
On Fri, Jun 12, 2026 at 3:54 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Jun 11, 2026 at 06:48:56PM +0300, Heikki Krogerus wrote:
> > On Thu, Jun 11, 2026 at 11:35:13AM +0200, Bartosz Golaszewski wrote:
> > > On Thu, Jun 11, 2026 at 10:37 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
> > > > > On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
> > > > > <andriy.shevchenko@linux.intel.com> said:
> > > > > > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
> > > > > >> When a USB hub port is connected to a connector in a firmware node
> > > > > >> graph, the port itself has a node in the graph.
> > > > > >>
> > > > > >> Associate the port's firmware node with the USB port's device,
> > > > > >> usb_port::dev. This is used in later changes for the M.2 slot power
> > > > > >> sequencing provider to match against the requesting port.
> > > > > >
> > > > > > Okay, would this affect ACPI-based systems? if so, how?
> > > > > > Can you elaborate on that, please?
> > > > >
> > > > > Is it possible that there's an ACPI device node associated with the port like
> > > > > on some DT systems? I don't think so and there should be no impact IMO but I
> > > > > also don't know enough about ACPI.
> >
> > There are device nodes for the USB ports in ACPI, and I think they get
> > always assigned in drivers/usb/core/usb-acpi.c.
> >
> > > > The API is agnostic. There is a possibility to have software nodes associated
> > > > with the port. I think the best is to be sure that ACPI-aware people who are
> > > > experts in USB will check this (Heikki?).
> >
> > I can't say what's the impact from this patch - I'm not an expert with
> > this side of USB. Is there a danger that we end up overwriting the
> > ACPI node for the port, or something else?
>
> Exactly this one is my worrying, but I haven't checked the actual flow.
Looking through ACPI code, ACPI_COMPANION_SET() is used, which boils
down to
set_primary_fwnode(dev, acpi_fwnode_handle(acpi_dev))
This is called through
usb_hub_create_port_device()
device_register()
device_add()
device_platform_notify()
acpi_device_notify()
usb_acpi_find_companion()
usb_acpi_find_companion_for_port()
acpi_bind_one()
ACPI_COMPANION_SET()
set_primary_fwnode()
Looking at device_add_software_node(), all swnodes are secondary.
set_primary_fwnode() seems to be able to make the ACPI handle / fwnode
the primary, keeping any existing fwnode as the secondary. However
if we do end up assigning a primary fwnode to the device using
device_set_node() as in this patch, set_primary_fwnode() is going
to complain loudly.
On another front, the ACPI representation of the USB ports looks nothing
like the OF graphs, at least on my X1 Carbon:
For a usb port device on the root hub such as
/sys/bus/usb/devices/4-0:1.0/usb4-port1/firmware_node/path
looks like
\_SB_.PC00.XHCI.RHUB.SS01
while a usb port's firmware node link
/sys/bus/usb/devices/4-0:1.0/usb4-port1//firmware_node
resolves to
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/device:1a/device:29
Neither looks anything like the graph "port" / "endpoint" node names.
So maybe we're in the clear here.
Besides the loud warning from set_primary_fwnode(), the major issue stemming
from a wrong node is that power management (through ACPI) is likely to fail.
If we're still concerned, I think we can skip the assignment if the fwnode
is an ACPI node, i.e. check it with is_acpi_node().
I've never worked on ACPI systems, so this is just me checking the code.
Thanks
ChenYu
^ permalink raw reply
* Re: [PATCH v7 3/6] firmware: smccc: Move RSI definitions to include/linux
From: Aneesh Kumar K.V @ 2026-06-12 5:41 UTC (permalink / raw)
To: Suzuki K Poulose, linux-coco, linux-arm-kernel, linux-kernel
Cc: Catalin Marinas, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price, Andre Przywara
In-Reply-To: <b009e840-6b79-415c-a3da-705ea569af38@arm.com>
Suzuki K Poulose <suzuki.poulose@arm.com> writes:
> On 11/06/2026 14:04, Aneesh Kumar K.V (Arm) wrote:
>> The RSI SMCCC function IDs describe a firmware ABI and are not arm64
>> architecture specific definitions. Follow-up changes need to use them from
>> non-arch code, including drivers/firmware/smccc and the Arm CCA guest
>> driver.
>>
>> Move the RSI SMCCC definitions from arch/arm64/include/asm/ to
>> include/linux/ so they can be shared with the driver code. This also
>> keeps the firmware interface outside architecture code, as requested [1].
>
> Please could we also mention about moving the "wrappers" only used by
> drivers accordingly ?
>
Added this
Not all helpers in rsi_cmds.h are used by architecture code. The
attestation token helper wrappers are only used by the Arm CCA guest
driver, so move them to a driver-private header under
drivers/virt/coco/arm-cca-guest/. Keep the remaining RSI command helpers,
which are shared by architecture code and drivers, in the arm64 header.
>
>>
>> [1] https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
>>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>> arch/arm64/include/asm/rsi_cmds.h | 74 +---------------
>> .../virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +
>> drivers/virt/coco/arm-cca-guest/rsi.h | 84 +++++++++++++++++++
>> .../linux/arm-smccc-rsi.h | 6 +-
>> 4 files changed, 90 insertions(+), 76 deletions(-)
>> create mode 100644 drivers/virt/coco/arm-cca-guest/rsi.h
>> rename arch/arm64/include/asm/rsi_smc.h => include/linux/arm-smccc-rsi.h (98%)
>>
>> diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
>> index 2c8763876dfb..633123a4e5d5 100644
>> --- a/arch/arm64/include/asm/rsi_cmds.h
>> +++ b/arch/arm64/include/asm/rsi_cmds.h
>> @@ -8,10 +8,9 @@
>>
>> #include <linux/arm-smccc.h>
>> #include <linux/string.h>
>> +#include <linux/arm-smccc-rsi.h>
>
> super minor nit: Please keep them in the alphabetical order.
>
> With that:
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
Thanks
-aneesh
^ permalink raw reply
* [RFC PATCH 2/2] kasan: hw_tags: Add boot option to elide free time poisoning
From: Dev Jain @ 2026-06-12 4:44 UTC (permalink / raw)
To: ryabinin.a.a, akpm, corbet
Cc: Dev Jain, glider, andreyknvl, dvyukov, vincenzo.frascino,
kasan-dev, linux-mm, linux-kernel, skhan, workflows, linux-doc,
linux-arm-kernel, ryan.roberts, anshuman.khandual, kaleshsingh,
21cnbao, david, will, catalin.marinas
In-Reply-To: <20260612044425.763060-1-dev.jain@arm.com>
Introduce a boot option to tag only at allocation time of the objects. This
reduces KASAN MTE overhead, the tradeoff being reduced ability
of catching bugs.
Now, when a memory object will be freed, it will retain the random tag it
had at allocation time. This compromises on catching UAF bugs, till the
time the object is not reallocated.
Hence, not catching "use-after-free-before-reallocation" and not catching
"double-free" will be the compromise for reduced KASAN overhead.
Keep this as a boot time feature to prevent building two kernel images.
To implement the feature, we need to effectively render kasan_poison()
redundant for hw tags case, but keep it working in the case where it is
used not in an object-freeing code path, but the redzoning path (which
means, poisoning the tail end of a vmalloc or kmalloc allocation).
We achieve this by overloading the poison values for the hw tags case: we
define the four poison values as 0x0E, 0x1E, 0x2E, 0x3E. In kasan_poison(),
if we arrive with KASAN_SLAB_REDZONE or KASAN_PAGE_REDZONE, do a bitwise
OR on the value of the tag to make it equal to KASAN_TAG_INVALID.
If not, then, if init is true, zero out the memory and bail out.
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
Documentation/dev-tools/kasan.rst | 4 +++
mm/kasan/hw_tags.c | 43 ++++++++++++++++++++++++++++++-
mm/kasan/kasan.h | 23 ++++++++++++++++-
3 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 4968b2aa60c80..b0c30584b5062 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -146,6 +146,10 @@ disabling KASAN altogether or controlling its features:
- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc
allocations (default: ``on``).
+- ``kasan.tag_only_on_alloc=off`` or ``=on`` disables or enables skipping
+ free-time tagging (poisoning) while keeping allocation-time tagging enabled
+ (default: ``off``).
+
- ``kasan.page_alloc.sample=<sampling interval>`` makes KASAN tag only every
Nth page_alloc allocation with the order equal or greater than
``kasan.page_alloc.sample.order``, where N is the value of the ``sample``
diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c
index c1a2b48808ed7..a392e34d11e3a 100644
--- a/mm/kasan/hw_tags.c
+++ b/mm/kasan/hw_tags.c
@@ -41,9 +41,16 @@ enum kasan_arg_vmalloc {
KASAN_ARG_VMALLOC_ON,
};
+enum kasan_arg_tag_only_on_alloc {
+ KASAN_ARG_TAG_ONLY_ON_ALLOC_DEFAULT,
+ KASAN_ARG_TAG_ONLY_ON_ALLOC_OFF,
+ KASAN_ARG_TAG_ONLY_ON_ALLOC_ON,
+};
+
static enum kasan_arg kasan_arg __ro_after_init;
static enum kasan_arg_mode kasan_arg_mode __ro_after_init;
static enum kasan_arg_vmalloc kasan_arg_vmalloc __initdata;
+static enum kasan_arg_tag_only_on_alloc kasan_arg_tag_only_on_alloc __initdata;
/*
* Whether the selected mode is synchronous, asynchronous, or asymmetric.
@@ -63,6 +70,10 @@ EXPORT_SYMBOL_GPL(kasan_flag_vmalloc);
/* Whether to check write accesses only. */
static bool kasan_flag_write_only = false;
+/* Whether to skip free-time tagging. */
+DEFINE_STATIC_KEY_FALSE(kasan_flag_tag_only_on_alloc);
+EXPORT_SYMBOL_GPL(kasan_flag_tag_only_on_alloc);
+
#define PAGE_ALLOC_SAMPLE_DEFAULT 1
#define PAGE_ALLOC_SAMPLE_ORDER_DEFAULT 3
@@ -154,6 +165,23 @@ static int __init early_kasan_flag_write_only(char *arg)
}
early_param("kasan.write_only", early_kasan_flag_write_only);
+/* kasan.tag_only_on_alloc=off/on */
+static int __init early_kasan_flag_tag_only_on_alloc(char *arg)
+{
+ if (!arg)
+ return -EINVAL;
+
+ if (!strcmp(arg, "off"))
+ kasan_arg_tag_only_on_alloc = KASAN_ARG_TAG_ONLY_ON_ALLOC_OFF;
+ else if (!strcmp(arg, "on"))
+ kasan_arg_tag_only_on_alloc = KASAN_ARG_TAG_ONLY_ON_ALLOC_ON;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+early_param("kasan.tag_only_on_alloc", early_kasan_flag_tag_only_on_alloc);
+
static inline const char *kasan_mode_info(void)
{
if (kasan_mode == KASAN_MODE_ASYNC)
@@ -270,14 +298,27 @@ void __init kasan_init_hw_tags(void)
break;
}
+ switch (kasan_arg_tag_only_on_alloc) {
+ case KASAN_ARG_TAG_ONLY_ON_ALLOC_DEFAULT:
+ /* Default is specified by kasan_flag_tag_only_on_alloc. */
+ break;
+ case KASAN_ARG_TAG_ONLY_ON_ALLOC_OFF:
+ static_branch_disable(&kasan_flag_tag_only_on_alloc);
+ break;
+ case KASAN_ARG_TAG_ONLY_ON_ALLOC_ON:
+ static_branch_enable(&kasan_flag_tag_only_on_alloc);
+ break;
+ }
+
kasan_init_tags();
/* KASAN is now initialized, enable it. */
kasan_enable();
- pr_info("KernelAddressSanitizer initialized (hw-tags, mode=%s, vmalloc=%s, stacktrace=%s, write_only=%s)\n",
+ pr_info("KernelAddressSanitizer initialized (hw-tags, mode=%s, vmalloc=%s, tag_only_on_alloc=%s, stacktrace=%s, write_only=%s)\n",
kasan_mode_info(),
str_on_off(kasan_vmalloc_enabled()),
+ str_on_off(kasan_tag_only_on_alloc_enabled()),
str_on_off(kasan_stack_collection_enabled()),
str_on_off(kasan_flag_write_only));
}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index fc9169a547662..4fa8abb312faa 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -33,6 +33,7 @@ static inline bool kasan_stack_collection_enabled(void)
#include "../slab.h"
DECLARE_STATIC_KEY_TRUE(kasan_flag_vmalloc);
+DECLARE_STATIC_KEY_FALSE(kasan_flag_tag_only_on_alloc);
enum kasan_mode {
KASAN_MODE_SYNC,
@@ -52,6 +53,11 @@ static inline bool kasan_vmalloc_enabled(void)
return static_branch_likely(&kasan_flag_vmalloc);
}
+static inline bool kasan_tag_only_on_alloc_enabled(void)
+{
+ return static_branch_unlikely(&kasan_flag_tag_only_on_alloc);
+}
+
static inline bool kasan_async_fault_possible(void)
{
return kasan_mode == KASAN_MODE_ASYNC || kasan_mode == KASAN_MODE_ASYMM;
@@ -145,12 +151,17 @@ static inline bool kasan_requires_meta(void)
#define KASAN_SLAB_REDZONE 0xFC /* redzone for slab object */
#define KASAN_SLAB_FREE 0xFB /* freed slab object */
#define KASAN_VMALLOC_INVALID 0xF8 /* inaccessible space in vmap area */
+#elif defined(CONFIG_KASAN_HW_TAGS)
+#define KASAN_PAGE_FREE 0x0E
+#define KASAN_PAGE_REDZONE 0x1E
+#define KASAN_SLAB_REDZONE 0x2E
+#define KASAN_SLAB_FREE 0x3E
#else
#define KASAN_PAGE_FREE KASAN_TAG_INVALID
#define KASAN_PAGE_REDZONE KASAN_TAG_INVALID
#define KASAN_SLAB_REDZONE KASAN_TAG_INVALID
#define KASAN_SLAB_FREE KASAN_TAG_INVALID
-#define KASAN_VMALLOC_INVALID KASAN_TAG_INVALID /* only used for SW_TAGS */
+#define KASAN_VMALLOC_INVALID KASAN_TAG_INVALID
#endif
#ifdef CONFIG_KASAN_GENERIC
@@ -478,6 +489,16 @@ static inline u8 kasan_random_tag(void) { return 0; }
static inline void kasan_poison(const void *addr, size_t size, u8 value, bool init)
{
+ if (kasan_tag_only_on_alloc_enabled()) {
+ if ((value != KASAN_SLAB_REDZONE) && (value != KASAN_PAGE_REDZONE)) {
+ if (init)
+ memset((void *)kasan_reset_tag(addr), 0, size);
+ return;
+ }
+ }
+
+ value |= 0xF0;
+
if (WARN_ON((unsigned long)addr & KASAN_GRANULE_MASK))
return;
if (WARN_ON(size & KASAN_GRANULE_MASK))
--
2.43.0
^ permalink raw reply related
* [RFC PATCH 1/2] kasan: hw_tags: Use KASAN_PAGE_REDZONE for vmalloc redzoning
From: Dev Jain @ 2026-06-12 4:44 UTC (permalink / raw)
To: ryabinin.a.a, akpm, corbet
Cc: Dev Jain, glider, andreyknvl, dvyukov, vincenzo.frascino,
kasan-dev, linux-mm, linux-kernel, skhan, workflows, linux-doc,
linux-arm-kernel, ryan.roberts, anshuman.khandual, kaleshsingh,
21cnbao, david, will, catalin.marinas
In-Reply-To: <20260612044425.763060-1-dev.jain@arm.com>
In preparation for adding "tag only on alloc" boot time option, use
KASAN_PAGE_REDZONE instead of KASAN_TAG_INVALID for poisoning the tail end
of the vmalloc allocation.
Although both values are the same for hw tags, KASAN_SLAB_REDZONE is used
for poisoning the tail end of a kmalloc object allocation, so maintain
the pattern.
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
mm/kasan/hw_tags.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c
index cbef5e450954e..c1a2b48808ed7 100644
--- a/mm/kasan/hw_tags.c
+++ b/mm/kasan/hw_tags.c
@@ -375,7 +375,7 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
redzone_start = round_up((unsigned long)start + size,
KASAN_GRANULE_SIZE);
redzone_size = round_up(redzone_start, PAGE_SIZE) - redzone_start;
- kasan_poison((void *)redzone_start, redzone_size, KASAN_TAG_INVALID,
+ kasan_poison((void *)redzone_start, redzone_size, KASAN_PAGE_REDZONE,
flags & KASAN_VMALLOC_INIT);
/*
--
2.43.0
^ permalink raw reply related
* [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Dev Jain @ 2026-06-12 4:44 UTC (permalink / raw)
To: ryabinin.a.a, akpm, corbet
Cc: Dev Jain, glider, andreyknvl, dvyukov, vincenzo.frascino,
kasan-dev, linux-mm, linux-kernel, skhan, workflows, linux-doc,
linux-arm-kernel, ryan.roberts, anshuman.khandual, kaleshsingh,
21cnbao, david, will, catalin.marinas
Introduce a boot option to tag only at allocation time of the objects. This
reduces KASAN MTE overhead, the tradeoff being reduced ability of
catching bugs.
Now, when a memory object will be freed, it will retain the random tag it
had at allocation time. This compromises on catching UAF bugs, till the
time the object is not reallocated, at which point it will have a new
random tag.
Hence, not catching "use-after-free-before-reallocation" and not catching
"double-free" will be the compromise for reduced KASAN overhead.
This is an RFC because we are not clear about the performance benefit.
Android folks, please help with testing!
---
Applies on Linus master (9716c086c8e8).
Dev Jain (2):
kasan: hw_tags: Use KASAN_PAGE_REDZONE for vmalloc redzoning
kasan: hw_tags: Add boot option to elide free time poisoning
Documentation/dev-tools/kasan.rst | 4 +++
mm/kasan/hw_tags.c | 45 +++++++++++++++++++++++++++++--
mm/kasan/kasan.h | 23 +++++++++++++++-
3 files changed, 69 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 0/2] ACPM cpufreq with fast_switch support, fast path xfer in ACPM
From: Alexey Klimov @ 2026-06-12 4:36 UTC (permalink / raw)
To: Tudor Ambarus, Sam Protsenko, Krzysztof Kozlowski, Peter Griffin,
Alim Akhtar, Rafael J. Wysocki, Viresh Kumar
Cc: Sudeep Holla, linux-samsung-soc, linux-arm-kernel, linux-pm,
kernel-team, linux-kernel
In-Reply-To: <20260612-acpm-fast-xfer-v1-0-1aa6cd2268ba@linaro.org>
On Fri Jun 12, 2026 at 5:34 AM BST, Alexey Klimov wrote:
> The series implements acpm_do_xfer_fast() that does as little
> as possible to make it usabe in atomic context to eventually
Sorry, I forgot to add RFC tags. This is RFC/work-in-progress
series.
Thanks,
Alexey
^ permalink raw reply
* [PATCH 1/2] firmware: samsung: acpm: add fire-and-forget xfer support
From: Alexey Klimov @ 2026-06-12 4:34 UTC (permalink / raw)
To: Tudor Ambarus, Sam Protsenko, Krzysztof Kozlowski, Peter Griffin,
Alim Akhtar, Rafael J. Wysocki, Viresh Kumar
Cc: Sudeep Holla, linux-samsung-soc, linux-arm-kernel, linux-pm,
kernel-team, linux-kernel, Alexey Klimov
In-Reply-To: <20260612-acpm-fast-xfer-v1-0-1aa6cd2268ba@linaro.org>
The current ACPM IPC protocol relies on synchronous polling
(acpm_dequeue_by_polling) to process mailbox responses.
For CPU DVFS, cpufreqs schedutil governor requires ->fast_switch() to
execute in an atomic context. Waiting for firmware acknowledgments
in a loop in such case also using udelay(20) under spinlock doesn't
make a lot of sense. Experiemnts on Exynos850 showed that even with
removed udelay() or with it significantly decreased, the firmware
processing takes 15us...250us.
Introduce acpm_do_xfer_fast(), which implements a fire-and-forget
asynchronous path:
- utilizes spin_trylock() to exit without sleeping if the channel
is busy;
- adds/sends the message and kicks the mailbox doorbell;
- exits immediately, allowing fast_switch to complete quickly.
To prevent the unread asynchronous responses from permanently exhausting
the 63-slot sequence ring buffer, implement an acpm_drain_stale_rx().
This drains the RX queue during the fast path:
- copies payloads and sets completion flags for sleeping
synchronous users;
- explicitly acks 'is_async' messages.
Hooks it up in the right places of ACPM dvfs machinery.
The channels {tx,rx}_lock needs probably a bit of rework to
differentiate between channels that support or need fast xfer and
those that do not.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/firmware/samsung/exynos-acpm-dvfs.c | 14 ++
drivers/firmware/samsung/exynos-acpm-dvfs.h | 3 +
drivers/firmware/samsung/exynos-acpm.c | 142 +++++++++++++++++++--
drivers/firmware/samsung/exynos-acpm.h | 3 +
.../linux/firmware/samsung/exynos-acpm-protocol.h | 2 +
5 files changed, 154 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm-dvfs.c b/drivers/firmware/samsung/exynos-acpm-dvfs.c
index 7266312ef5a6..5411aa121b73 100644
--- a/drivers/firmware/samsung/exynos-acpm-dvfs.c
+++ b/drivers/firmware/samsung/exynos-acpm-dvfs.c
@@ -43,6 +43,20 @@ int acpm_dvfs_set_rate(struct acpm_handle *handle,
return acpm_do_xfer(handle, &xfer);
}
+int acpm_dvfs_set_rate_fast(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, unsigned int clk_id,
+ unsigned long rate)
+{
+ struct acpm_xfer xfer = {0};
+ u32 cmd[4];
+
+ acpm_dvfs_init_set_rate_cmd(cmd, clk_id, rate);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, false);
+
+ return acpm_do_xfer_fast(handle, &xfer);
+}
+
+
static void acpm_dvfs_init_get_rate_cmd(u32 cmd[4], unsigned int clk_id)
{
cmd[0] = FIELD_PREP(ACPM_DVFS_ID, clk_id);
diff --git a/drivers/firmware/samsung/exynos-acpm-dvfs.h b/drivers/firmware/samsung/exynos-acpm-dvfs.h
index b37b15426102..107d9aa27690 100644
--- a/drivers/firmware/samsung/exynos-acpm-dvfs.h
+++ b/drivers/firmware/samsung/exynos-acpm-dvfs.h
@@ -14,6 +14,9 @@ struct acpm_handle;
int acpm_dvfs_set_rate(struct acpm_handle *handle,
unsigned int acpm_chan_id, unsigned int id,
unsigned long rate);
+int acpm_dvfs_set_rate_fast(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, unsigned int id,
+ unsigned long rate);
unsigned long acpm_dvfs_get_rate(struct acpm_handle *handle,
unsigned int acpm_chan_id,
unsigned int clk_id);
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 942a2e9f02f5..3caab47adf26 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -20,13 +20,13 @@
#include <linux/mailbox/exynos-message.h>
#include <linux/mailbox_client.h>
#include <linux/module.h>
-#include <linux/mutex.h>
#include <linux/math.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/spinlock.h>
#include <linux/types.h>
#include "exynos-acpm.h"
@@ -109,12 +109,16 @@ struct acpm_queue {
* @rxcnt: expected length of the response in 32-bit words.
* @completed: flag indicating if the firmware response has been fully
* processed.
+ * @is_async: For fire-and-forget xfer. Set to true to just ack
+ * responses without processing.
+ * By default, set to false for regular senders.
*/
struct acpm_rx_data {
u32 *cmd __counted_by_ptr(cmdcnt);
size_t cmdcnt;
size_t rxcnt;
bool completed;
+ bool is_async;
};
#define ACPM_SEQNUM_MAX 64
@@ -148,8 +152,8 @@ struct acpm_chan {
struct acpm_info *acpm;
struct acpm_queue tx;
struct acpm_queue rx;
- struct mutex tx_lock;
- struct mutex rx_lock;
+ spinlock_t tx_lock;
+ spinlock_t rx_lock;
unsigned int qlen;
unsigned int mlen;
@@ -232,7 +236,7 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer,
*native_match = false;
- guard(mutex)(&achan->rx_lock);
+ guard(spinlock)(&achan->rx_lock);
rx_front = readl(achan->rx.front);
i = readl(achan->rx.rear);
@@ -297,6 +301,9 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer,
*native_match = true;
}
+ if (rx_data->is_async)
+ clear_bit_unlock(seqnum, achan->bitmap_seqnum);
+
i = (i + 1) % achan->qlen;
} while (i != rx_front);
@@ -306,6 +313,57 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer,
return 0;
}
+static void acpm_drain_stale_rx(struct acpm_chan *achan)
+{
+ u32 rx_front, seqnum, rx_seqnum;
+ const void __iomem *base = achan->rx.base;
+ struct acpm_rx_data *rx_data;
+ u32 i, val, mlen = achan->mlen;
+
+ if (!spin_trylock(&achan->rx_lock))
+ return;
+
+ rx_front = readl(achan->rx.front);
+ i = readl(achan->rx.rear);
+
+ /* Get out quick if we nothing to process */
+ if (i == rx_front) {
+ spin_unlock(&achan->rx_lock);
+ return;
+ }
+
+ do {
+ val = readl(base + mlen * i);
+ rx_seqnum = FIELD_GET(ACPM_PROTOCOL_SEQNUM, val);
+
+ if (rx_seqnum) {
+ seqnum = rx_seqnum - 1;
+ rx_data = &achan->rx_data[seqnum];
+
+ if (rx_data->rxcnt)
+ __ioread32_copy(rx_data->cmd, base + mlen * i, rx_data->rxcnt);
+
+ /* Signal the waiting thread (if any). If it hasn't started
+ * spinning yet, it will see this instantly when it does. */
+ smp_store_release(&rx_data->completed, true);
+
+ /* Only free the sequence number if it belongs to an
+ * async request. Senders who use regular acpm_do_xfer()
+ * will free their own sequence numbers in
+ * acpm_dequeue_by_polling().
+ */
+ if (rx_data->is_async)
+ clear_bit_unlock(seqnum, achan->bitmap_seqnum);
+ }
+
+ i = (i + 1) % achan->qlen;
+ } while (i != rx_front);
+
+ writel(rx_front, achan->rx.rear);
+
+ spin_unlock(&achan->rx_lock);
+}
+
/**
* acpm_dequeue_by_polling() - RX dequeue by polling.
* @achan: ACPM channel info.
@@ -388,15 +446,15 @@ static int acpm_wait_for_queue_slots(struct acpm_chan *achan, u32 next_tx_front)
}
/**
- * acpm_prepare_xfer() - prepare a transfer before writing the message to the
+ * __acpm_prepare_xfer() - prepare a transfer before writing the message to the
* TX queue.
* @achan: ACPM channel info.
* @xfer: reference to the transfer being prepared.
*
* Return: 0 on success, -errno otherwise.
*/
-static int acpm_prepare_xfer(struct acpm_chan *achan,
- const struct acpm_xfer *xfer)
+static int __acpm_prepare_xfer(struct acpm_chan *achan,
+ const struct acpm_xfer *xfer, bool is_async)
{
struct acpm_rx_data *rx_data;
u32 *txd = (u32 *)xfer->txd;
@@ -429,6 +487,7 @@ static int acpm_prepare_xfer(struct acpm_chan *achan,
/* Clear data for upcoming responses */
rx_data = &achan->rx_data[bit];
rx_data->completed = false;
+ rx_data->is_async = is_async;
memset(rx_data->cmd, 0, sizeof(*rx_data->cmd) * rx_data->cmdcnt);
/* zero means no response expected */
rx_data->rxcnt = xfer->rxcnt;
@@ -436,6 +495,12 @@ static int acpm_prepare_xfer(struct acpm_chan *achan,
return 0;
}
+static int acpm_prepare_xfer(struct acpm_chan *achan,
+ const struct acpm_xfer *xfer)
+{
+ return __acpm_prepare_xfer(achan, xfer, false);
+}
+
/**
* acpm_wait_for_message_response - an helper to group all possible ways of
* waiting for a synchronous message response.
@@ -452,6 +517,62 @@ static int acpm_wait_for_message_response(struct acpm_chan *achan,
return acpm_dequeue_by_polling(achan, xfer);
}
+int acpm_do_xfer_fast(struct acpm_handle *handle, const struct acpm_xfer *xfer)
+{
+ struct acpm_info *acpm = handle_to_acpm_info(handle);
+ struct exynos_mbox_msg msg;
+ struct acpm_chan *achan;
+ u32 idx, tx_front;
+ int ret;
+
+ if (xfer->acpm_chan_id >= acpm->num_chans)
+ return -EINVAL;
+
+ achan = &acpm->chans[xfer->acpm_chan_id];
+
+ msg.chan_id = xfer->acpm_chan_id;
+ msg.chan_type = EXYNOS_MBOX_CHAN_TYPE_DOORBELL;
+
+ /* Ideally should be a raw_spin_trylock.
+ * If we can't get it immediately, then give up.
+ */
+ if (!spin_trylock(&achan->tx_lock))
+ return -EBUSY;
+
+ /* clean up/ack previous responses */
+ acpm_drain_stale_rx(achan);
+
+ tx_front = readl(achan->tx.front);
+ idx = (tx_front + 1) % achan->qlen;
+
+ if (idx == readl(achan->tx.rear)) {
+ /* stalled; queue is full? */
+ spin_unlock(&achan->tx_lock);
+ return -EBUSY;
+ }
+
+ ret = __acpm_prepare_xfer(achan, xfer, true);
+ if (ret) {
+ spin_unlock(&achan->tx_lock);
+ return ret;
+ }
+
+ __iowrite32_copy(achan->tx.base + achan->mlen * tx_front,
+ xfer->txd, xfer->txcnt);
+
+ /* advance TX front */
+ writel(idx, achan->tx.front);
+
+ /* ring the doorbell */
+ ret = mbox_send_message(achan->chan, (void *)&msg);
+ if (ret >= 0)
+ mbox_client_txdone(achan->chan, 0);
+
+ spin_unlock(&achan->tx_lock);
+
+ return ret < 0 ? ret : 0;
+}
+
/**
* acpm_do_xfer() - do one transfer.
* @handle: pointer to the acpm handle.
@@ -485,7 +606,7 @@ int acpm_do_xfer(struct acpm_handle *handle, const struct acpm_xfer *xfer)
msg.chan_id = xfer->acpm_chan_id;
msg.chan_type = EXYNOS_MBOX_CHAN_TYPE_DOORBELL;
- scoped_guard(mutex, &achan->tx_lock) {
+ scoped_guard(spinlock, &achan->tx_lock) {
tx_front = readl(achan->tx.front);
idx = (tx_front + 1) % achan->qlen;
@@ -654,8 +775,8 @@ static int acpm_channels_init(struct acpm_info *acpm)
if (ret)
return ret;
- mutex_init(&achan->rx_lock);
- mutex_init(&achan->tx_lock);
+ spin_lock_init(&achan->rx_lock);
+ spin_lock_init(&achan->tx_lock);
cl->dev = dev;
@@ -675,6 +796,7 @@ static void acpm_clk_pdev_unregister(void *data)
static const struct acpm_ops exynos_acpm_driver_ops = {
.dvfs = {
.set_rate = acpm_dvfs_set_rate,
+ .set_rate_fast = acpm_dvfs_set_rate_fast,
.get_rate = acpm_dvfs_get_rate,
},
diff --git a/drivers/firmware/samsung/exynos-acpm.h b/drivers/firmware/samsung/exynos-acpm.h
index 708f6b0102ac..210709326a1f 100644
--- a/drivers/firmware/samsung/exynos-acpm.h
+++ b/drivers/firmware/samsung/exynos-acpm.h
@@ -22,4 +22,7 @@ void acpm_set_xfer(struct acpm_xfer *xfer, u32 *cmd, size_t cmdcnt,
int acpm_do_xfer(struct acpm_handle *handle,
const struct acpm_xfer *xfer);
+int acpm_do_xfer_fast(struct acpm_handle *handle,
+ const struct acpm_xfer *xfer);
+
#endif /* __EXYNOS_ACPM_H__ */
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index c6b35c0ff300..93c9b20517f8 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -16,6 +16,8 @@ struct device_node;
struct acpm_dvfs_ops {
int (*set_rate)(struct acpm_handle *handle, unsigned int acpm_chan_id,
unsigned int clk_id, unsigned long rate);
+ int (*set_rate_fast)(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ unsigned int clk_id, unsigned long rate);
unsigned long (*get_rate)(struct acpm_handle *handle,
unsigned int acpm_chan_id,
unsigned int clk_id);
--
2.51.0
^ permalink raw reply related
* [PATCH 2/2] cpufreq: add ACPM-based CPU DVFS driver for Exynos SoCs
From: Alexey Klimov @ 2026-06-12 4:34 UTC (permalink / raw)
To: Tudor Ambarus, Sam Protsenko, Krzysztof Kozlowski, Peter Griffin,
Alim Akhtar, Rafael J. Wysocki, Viresh Kumar
Cc: Sudeep Holla, linux-samsung-soc, linux-arm-kernel, linux-pm,
kernel-team, linux-kernel, Alexey Klimov
In-Reply-To: <20260612-acpm-fast-xfer-v1-0-1aa6cd2268ba@linaro.org>
Exynos-based SoCs (e.g., Exynos850, gs101) manage CPU DVFS via an
ACPM co-processor (sometimes co-processor specifically called APM).
Historically, routing CPU frequencies through the clock framework
breaks fast frequency switching as it is implemented in cpufreq-dt.
The clk_set_rate() uses mutexes, which prevents the scheduler to
utilize schedutil's fast path.
Introduce a dedicated ACPM-based cpufreq driver that bypasses the clock
framework and communicates directly with the ACPM firmware protocol.
It implements ->fast_switch() to rely on acpm_dvfs_set_rate_fast(),
enabling faster frequency transitions.
Add Google gs101 and Samsung exynos850 to the cpufreq-dt-platdev
blocklist to prevent driver cpufreq-dt initialisation.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 8 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/acpm-cpufreq.c | 195 +++++++++++++++++++++++++++++++++++
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
4 files changed, 207 insertions(+)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index a441668f9e0c..891ff4b6ec22 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -24,6 +24,14 @@ config ARM_AIROHA_SOC_CPUFREQ
help
This adds the CPUFreq driver for Airoha EN7581 SoCs.
+config ARM_ACPM_CPUFREQ
+ tristate "ACPM based CPUFreq support"
+ depends on ARCH_EXYNOS || (COMPILE_TEST && 64BIT)
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Exynos-based machines
+ with ACPM firmware.
+
config ARM_APPLE_SOC_CPUFREQ
tristate "Apple Silicon SoC CPUFreq support"
depends on ARCH_APPLE || (COMPILE_TEST && 64BIT)
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 6c7a39b7f8d2..c54d2dd6629d 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_X86_AMD_FREQ_SENSITIVITY) += amd_freq_sensitivity.o
##################################################################################
# ARM SoC drivers
obj-$(CONFIG_ARM_AIROHA_SOC_CPUFREQ) += airoha-cpufreq.o
+obj-$(CONFIG_ARM_ACPM_CPUFREQ) += acpm-cpufreq.o
obj-$(CONFIG_ARM_APPLE_SOC_CPUFREQ) += apple-soc-cpufreq.o
obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ) += armada-37xx-cpufreq.o
obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ) += armada-8k-cpufreq.o
diff --git a/drivers/cpufreq/acpm-cpufreq.c b/drivers/cpufreq/acpm-cpufreq.c
new file mode 100644
index 000000000000..20fb79169993
--- /dev/null
+++ b/drivers/cpufreq/acpm-cpufreq.c
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Exynos ACPM-based CPUFreq DVFS driver
+ */
+
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+
+#include <linux/firmware/samsung/exynos-acpm-protocol.h>
+
+#define ACPM_DVFS_TRANSITION_TIMEOUT 400
+
+struct acpm_cpu_priv {
+ struct device *cpu_dev;
+ struct acpm_handle *handle;
+ unsigned int acpm_chan_id;
+ unsigned int clk_id;
+};
+
+static unsigned int acpm_soc_cpufreq_get_rate(unsigned int cpu)
+{
+ struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+ struct acpm_cpu_priv *priv;
+
+ if (unlikely(!policy))
+ return 0;
+
+ priv = policy->driver_data;
+
+ /* return priv->handle->ops->dvfs.get_rate(priv->handle, priv->acpm_chan_id,
+ * priv->clk_id) / 1000;
+ */
+
+ /* TODO: FIXME. Exynos850 doesn't return rate via ACPM */
+ return policy->cur;
+}
+
+static int acpm_soc_cpufreq_set_target(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ struct acpm_cpu_priv *priv = policy->driver_data;
+ unsigned long freq_khz = policy->freq_table[index].frequency;
+
+ /* standard slow path */
+ return priv->handle->ops->dvfs.set_rate(priv->handle, priv->acpm_chan_id,
+ priv->clk_id, freq_khz * 1000);
+}
+
+static unsigned int acpm_soc_cpufreq_fast_switch(struct cpufreq_policy *policy,
+ unsigned int target_freq)
+{
+ struct acpm_cpu_priv *priv = policy->driver_data;
+ int ret;
+
+ ret = priv->handle->ops->dvfs.set_rate_fast(priv->handle, priv->acpm_chan_id,
+ priv->clk_id, target_freq * 1000);
+ if (ret < 0)
+ return 0;
+
+ return target_freq;
+}
+
+static int acpm_soc_cpufreq_init(struct cpufreq_policy *policy)
+{
+ struct device *cpu_dev = get_cpu_device(policy->cpu);
+ struct cpufreq_frequency_table *freq_table;
+ struct acpm_cpu_priv *priv;
+ struct of_phandle_args args;
+ unsigned int transition_latency;
+ int ret;
+
+ if (!cpu_dev)
+ return -ENODEV;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ ret = of_parse_phandle_with_args(cpu_dev->of_node, "clocks",
+ "#clock-cells", 0, &args);
+ if (ret) {
+ dev_err(cpu_dev, "failed to parse clocks property\n");
+ goto out_free_priv;
+ }
+
+ priv->clk_id = args.args[0];
+
+ /*
+ * DVFS communication is expected to happen only via channel 0
+ * for now for known SoCs with ACPM firmware. Hardcoding.
+ */
+ priv->acpm_chan_id = 0;
+
+ priv->handle = devm_acpm_get_by_node(cpu_dev, args.np);
+ of_node_put(args.np);
+
+ if (IS_ERR(priv->handle)) {
+ ret = PTR_ERR(priv->handle);
+ goto out_free_priv;
+ }
+
+ priv->cpu_dev = cpu_dev;
+
+ ret = dev_pm_opp_of_add_table(cpu_dev);
+ if (ret < 0) {
+ dev_err(cpu_dev, "failed to add OPP table: %d\n", ret);
+ goto out_free_priv;
+ }
+
+ dev_pm_opp_of_get_sharing_cpus(cpu_dev, policy->cpus);
+
+ ret = dev_pm_opp_get_opp_count(cpu_dev);
+ if (ret <= 0) {
+ ret = -EPROBE_DEFER;
+ goto out_remove_table;
+ }
+
+ ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
+ if (ret) {
+ dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
+ goto out_remove_table;
+ }
+
+ policy->driver_data = priv;
+ policy->freq_table = freq_table;
+
+ transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev);
+ if (!transition_latency)
+ transition_latency = ACPM_DVFS_TRANSITION_TIMEOUT * NSEC_PER_USEC;
+
+ policy->cpuinfo.transition_latency = transition_latency;
+ policy->dvfs_possible_from_any_cpu = true;
+ policy->fast_switch_possible = true;
+ policy->suspend_freq = freq_table[0].frequency;
+
+ /* TODO: FIXME. Exynos850 doesn't expose rate of clocks via ACPM (get_rate doesn't work) */
+ policy->cur = freq_table[0].frequency;
+
+ return 0;
+
+out_remove_table:
+ dev_pm_opp_of_remove_table(cpu_dev);
+out_free_priv:
+ kfree(priv);
+ return ret;
+}
+
+static void acpm_soc_cpufreq_exit(struct cpufreq_policy *policy)
+{
+ struct acpm_cpu_priv *priv = policy->driver_data;
+
+ dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
+ dev_pm_opp_of_remove_table(priv->cpu_dev);
+ kfree(priv);
+}
+
+static struct cpufreq_driver acpm_soc_cpufreq_driver = {
+ .name = "acpm-cpufreq",
+ .flags = CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+ CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_IS_COOLING_DEV,
+ .verify = cpufreq_generic_frequency_table_verify,
+ .get = acpm_soc_cpufreq_get_rate,
+ .init = acpm_soc_cpufreq_init,
+ .exit = acpm_soc_cpufreq_exit,
+ .target_index = acpm_soc_cpufreq_set_target,
+ .fast_switch = acpm_soc_cpufreq_fast_switch,
+ .register_em = cpufreq_register_em_with_opp,
+ .set_boost = cpufreq_boost_set_sw,
+ .suspend = cpufreq_generic_suspend,
+};
+
+static int __init acpm_soc_cpufreq_module_init(void)
+{
+ if (!of_machine_is_compatible("google,gs101") &&
+ !of_machine_is_compatible("samsung,exynos850"))
+ return -ENODEV;
+
+ return cpufreq_register_driver(&acpm_soc_cpufreq_driver);
+}
+module_init(acpm_soc_cpufreq_module_init);
+
+static void __exit acpm_soc_cpufreq_module_exit(void)
+{
+ cpufreq_unregister_driver(&acpm_soc_cpufreq_driver);
+}
+module_exit(acpm_soc_cpufreq_module_exit);
+
+MODULE_AUTHOR("Alexey Klimov <alexey.klimov@linaro.org>");
+MODULE_DESCRIPTION("ACPM-based CPUfreq DVFS driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index ff1204c666b1..ae58aa92fc40 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -186,6 +186,9 @@ static const struct of_device_id blocklist[] __initconst = {
{ .compatible = "qcom,sm8550", },
{ .compatible = "qcom,sm8650", },
+ { .compatible = "google,gs101", },
+ { .compatible = "samsung,exynos850", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
{ .compatible = "st,stih418", },
--
2.51.0
^ permalink raw reply related
* [PATCH 0/2] ACPM cpufreq with fast_switch support, fast path xfer in ACPM
From: Alexey Klimov @ 2026-06-12 4:34 UTC (permalink / raw)
To: Tudor Ambarus, Sam Protsenko, Krzysztof Kozlowski, Peter Griffin,
Alim Akhtar, Rafael J. Wysocki, Viresh Kumar
Cc: Sudeep Holla, linux-samsung-soc, linux-arm-kernel, linux-pm,
kernel-team, linux-kernel, Alexey Klimov
The series implements acpm_do_xfer_fast() that does as little
as possible to make it usabe in atomic context to eventually
use it in cpufreq path with ->fast_switch(). That's basically it.
Cpufreq deals directly with ACPM dvfs instead of going through
clk framework.
This series is Work-In-Progress / RFC.
This is currently a working prototype, but I am sending it as an RFC to
get feedback on the approach — specifically the ACPM fast path of sending
messages. If ACPM part is no-go then cpufreq is not needed.
Known TODO items:
-- rx/tx channels locks rework;
-- initial frequency fetching: Exynos850 firmware currently lacks a
clean get_rate, so the driver falls back to dump defaults until the
first freq transition.
-- potential mailbox channels re-implementation.
Any thoughts, testing, or feedback on the architecture would be greatly
appreciated.
This was tested on Exynos850 with example of DT nodes described
in [1] and [2].
Dependencies are different series that adds Exynos850 ACPM support:
-- ACPM mailbox support for Exynos850:
https://lore.kernel.org/linux-samsung-soc/20260429-exynos850-mbox-dts-v1-1-7f3ad27ed4f4@linaro.org/
-- sram DT node:
https://lore.kernel.org/linux-samsung-soc/20260413-exynos850_sram-v1-1-7fda5b7fb7d4@linaro.org/
-- ACPM support on Exynos850:
https://lore.kernel.org/linux-samsung-soc/20260513-exynos850-acpm-firmware-support-v1-0-3858d097e433@linaro.org/
(the above dependencies pull some other series as well)
[1]:
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a55";
reg = <0x0>;
clocks = <&acpm_ipc E850_CLK_ACPM_DVFS_CPUCL0>;
enable-method = "psci";
operating-points-v2 = <&cpucl0_opp_table>;
capacity-dmips-mhz = <250>;
dynamic-power-coefficient = <70>;
};
[2]:
cpucl0_opp_table: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-130000000 {
opp-hz = /bits/ 64 <130000000>;
opp-microvolt = <625000>;
clock-latency-ns = <500000>;
};
opp-182000000 {
opp-hz = /bits/ 64 <182000000>;
opp-microvolt = <625000>;
clock-latency-ns = <500000>;
};
opp-247000000 {
opp-hz = /bits/ 64 <247000000>;
opp-microvolt = <625000>;
clock-latency-ns = <500000>;
};
opp-351000000 {
opp-hz = /bits/ 64 <351000000>;
opp-microvolt = <625000>;
clock-latency-ns = <500000>;
};
opp-442000000 {
opp-hz = /bits/ 64 <442000000>;
opp-microvolt = <625000>;
clock-latency-ns = <500000>;
};
opp-546000000 {
opp-hz = /bits/ 64 <546000000>;
opp-microvolt = <625000>;
clock-latency-ns = <500000>;
};
opp-650000000 {
opp-hz = /bits/ 64 <650000000>;
opp-microvolt = <625000>;
clock-latency-ns = <500000>;
};
opp-806000000 {
opp-hz = /bits/ 64 <806000000>;
opp-microvolt = <656250>;
clock-latency-ns = <500000>;
};
opp-949000000 {
opp-hz = /bits/ 64 <949000000>;
opp-microvolt = <681250>;
clock-latency-ns = <500000>;
};
opp-1053000000 {
opp-hz = /bits/ 64 <1053000000>;
opp-microvolt = <706250>;
clock-latency-ns = <500000>;
};
opp-1157000000 {
opp-hz = /bits/ 64 <1157000000>;
opp-microvolt = <737500>;
clock-latency-ns = <500000>;
};
opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <781250>;
clock-latency-ns = <500000>;
};
opp-1456000000 {
opp-hz = /bits/ 64 <1456000000>;
opp-microvolt = <825000>;
clock-latency-ns = <500000>;
};
opp-1586000000 {
opp-hz = /bits/ 64 <1586000000>;
opp-microvolt = <875000>;
clock-latency-ns = <500000>;
};
opp-1742000000 {
opp-hz = /bits/ 64 <1742000000>;
opp-microvolt = <937500>;
clock-latency-ns = <500000>;
};
opp-1846000000 {
opp-hz = /bits/ 64 <1846000000>;
opp-microvolt = <981250>;
clock-latency-ns = <500000>;
};
opp-2002000000 {
opp-hz = /bits/ 64 <2002000000>;
opp-microvolt = <1050000>;
clock-latency-ns = <500000>;
};
opp-2106000000 {
opp-hz = /bits/ 64 <2106000000>;
opp-microvolt = <1106250>;
clock-latency-ns = <500000>;
};
opp-2210000000 {
opp-hz = /bits/ 64 <2210000000>;
opp-microvolt = <1181250>;
clock-latency-ns = <500000>;
};
};
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Alexey Klimov (2):
firmware: samsung: acpm: add fire-and-forget xfer support
cpufreq: add ACPM-based CPU DVFS driver for Exynos SoCs
drivers/cpufreq/Kconfig.arm | 8 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/acpm-cpufreq.c | 195 +++++++++++++++++++++
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/firmware/samsung/exynos-acpm-dvfs.c | 14 ++
drivers/firmware/samsung/exynos-acpm-dvfs.h | 3 +
drivers/firmware/samsung/exynos-acpm.c | 142 +++++++++++++--
drivers/firmware/samsung/exynos-acpm.h | 3 +
.../linux/firmware/samsung/exynos-acpm-protocol.h | 2 +
9 files changed, 361 insertions(+), 10 deletions(-)
---
base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
change-id: 20260612-acpm-fast-xfer-86c4de78c20b
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply
* Re: [PATCH] media: bcm2835-unicam: Fix querycap multiple caps
From: kernel test robot @ 2026-06-12 4:31 UTC (permalink / raw)
To: Eugen Hristev, Raspberry Pi Kernel Maintenance,
Mauro Carvalho Chehab, Florian Fainelli, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Sakari Ailus,
Dave Stevenson, Laurent Pinchart, Jean-Michel Hautbois,
Naushir Patuck
Cc: oe-kbuild-all, linux-media, Hans Verkuil, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Eugen Hristev
In-Reply-To: <20260611-bcmpiqcap-v1-1-10cf7fb438df@kernel.org>
Hi Eugen,
kernel test robot noticed the following build errors:
[auto build test ERROR on a87737435cfa134f9cdcc696ba3080759d04cf72]
url: https://github.com/intel-lab-lkp/linux/commits/Eugen-Hristev/media-bcm2835-unicam-Fix-querycap-multiple-caps/20260611-141320
base: a87737435cfa134f9cdcc696ba3080759d04cf72
patch link: https://lore.kernel.org/r/20260611-bcmpiqcap-v1-1-10cf7fb438df%40kernel.org
patch subject: [PATCH] media: bcm2835-unicam: Fix querycap multiple caps
config: arc-allmodconfig (https://download.01.org/0day-ci/archive/20260612/202606121218.nV4fMXUr-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260612/202606121218.nV4fMXUr-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606121218.nV4fMXUr-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/media/platform/broadcom/bcm2835-unicam.c: In function 'unicam_querycap':
>> drivers/media/platform/broadcom/bcm2835-unicam.c:1836:27: error: 'node' undeclared (first use in this function)
1836 | if (is_image_node(node))
| ^~~~
drivers/media/platform/broadcom/bcm2835-unicam.c:1836:27: note: each undeclared identifier is reported only once for each function it appears in
vim +/node +1836 drivers/media/platform/broadcom/bcm2835-unicam.c
1825
1826 /* -----------------------------------------------------------------------------
1827 * V4L2 video device operations
1828 */
1829
1830 static int unicam_querycap(struct file *file, void *priv,
1831 struct v4l2_capability *cap)
1832 {
1833 strscpy(cap->driver, UNICAM_MODULE_NAME, sizeof(cap->driver));
1834 strscpy(cap->card, UNICAM_MODULE_NAME, sizeof(cap->card));
1835
> 1836 if (is_image_node(node))
1837 cap->capabilities |= V4L2_CAP_VIDEO_CAPTURE;
1838 else
1839 cap->capabilities |= V4L2_CAP_META_CAPTURE;
1840
1841 return 0;
1842 }
1843
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Nihal Kumar Gupta @ 2026-06-12 4:28 UTC (permalink / raw)
To: Bryan O'Donoghue, Krzysztof Kozlowski
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bjorn Andersson,
Konrad Dybcio, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-msm, linux-media, devicetree,
linux-kernel, linux-i2c, imx, linux-arm-kernel, Suresh Vankadara,
Vikram Sharma
In-Reply-To: <ab1055a2-6916-4083-a360-62eb15171fe3@linaro.org>
On 11-06-2026 20:06, Bryan O'Donoghue wrote:
>
> @Nihal.
>
> If this is the only change you get asked to make, I will just fix this up on application for you. There's no need to v3 the series for this.
Thank you for offering to fix this up on application.
That works for me!
--
Regards,
Nihal Kumar Gupta
^ permalink raw reply
* [PATCH wireless] wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
From: Runyu Xiao @ 2026-06-12 4:13 UTC (permalink / raw)
To: nbd
Cc: lorenzo, ryder.lee, shayne.chen, sean.wang, matthias.bgg,
angelogioacchino.delregno, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, jianhao.xu, runyu.xiao, stable
mt7615_suspend() takes the mt76 mutex and then waits for mac_work with
cancel_delayed_work_sync(). mt7615_mac_work() takes the same mutex at
the top of the worker, so the suspend path can deadlock against the
delayed work it is trying to flush.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the mt7615_suspend() ->
cancel_delayed_work_sync(&phy->mt76->mac_work) path and the
mt7615_mac_work() -> mt7615_mutex_acquire() edge. Lockdep reported:
WARNING: possible circular locking dependency detected
mt7615_mac_work+0x1b/0x29 [vuln_msv]
__cancel_work_timer
*** DEADLOCK ***
Stop queueing mac_work while the mutex is held, drop the mutex, and then
flush the delayed work from the sleepable post-unlock path.
Fixes: c6bf20109a3f ("mt76: mt7615: add WoW support")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
Notes:
- Validated with a grounded Lockdep PoC that preserves the
mt7615_suspend() -> cancel_delayed_work_sync(&phy->mt76->mac_work)
path and the mt7615_mac_work() -> mt7615_mutex_acquire() edge.
- checkpatch.pl --strict: clean.
- Not tested on mt7615 hardware.
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 15fe155ac3f3..fcb619c0f6cf 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -1242,7 +1242,8 @@ static int mt7615_suspend(struct ieee80211_hw *hw,
clear_bit(MT76_STATE_RUNNING, &phy->mt76->state);
cancel_delayed_work_sync(&phy->scan_work);
- cancel_delayed_work_sync(&phy->mt76->mac_work);
+ /* mac_work re-enters the mt76 mutex, so flush it after unlock. */
+ cancel_delayed_work(&phy->mt76->mac_work);
set_bit(MT76_STATE_SUSPEND, &phy->mt76->state);
ieee80211_iterate_active_interfaces(hw,
@@ -1254,6 +1255,7 @@ static int mt7615_suspend(struct ieee80211_hw *hw,
err = mt76_connac_mcu_set_hif_suspend(&dev->mt76, true, true);
mt7615_mutex_release(dev);
+ cancel_delayed_work_sync(&phy->mt76->mac_work);
return err;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] KVM: arm64: nv: Expose shadow page tables in debugfs
From: Itaru Kitayama @ 2026-06-12 4:06 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon
In-Reply-To: <20260317182638.1592507-3-weilin.chang@arm.com>
Hi Wei Lin,
On Tue, Mar 17, 2026 at 06:26:38PM +0000, Wei-Lin Chang wrote:
> Exposing shadow page tables in debugfs improves the debugability and
> testability of NV. With this patch a new directory "nested" is created
> for each VM created if the host is NV capable. Within the directory each
> valid s2 mmu will have its shadow page table exposed as a readable file
> with the file name formatted as 0x<vttbr>-0x<vtcr>-s2-{en,dis}abled. The
> creation and removal of the files happen at the points when an s2 mmu
> becomes valid, or the context it represents change. In the future the
> "nested" directory can also hold other NV related information.
>
> This is gated behind CONFIG_PTDUMP_STAGE2_DEBUGFS.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Reviewed-by: Sebastian Ene <sebastianene@google.com>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 9 +++++++++
> arch/arm64/include/asm/kvm_mmu.h | 4 ++++
> arch/arm64/kvm/nested.c | 6 +++++-
> arch/arm64/kvm/ptdump.c | 27 +++++++++++++++++++++++++++
> 4 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 5d5a3bbdb95e..52977c9a11c3 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -217,6 +217,10 @@ struct kvm_s2_mmu {
> */
> bool nested_stage2_enabled;
>
> +#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> + struct dentry *shadow_pt_debugfs_dentry;
> +#endif
> +
> /*
> * true when this MMU needs to be unmapped before being used for a new
> * purpose.
> @@ -405,6 +409,11 @@ struct kvm_arch {
> * the associated pKVM instance in the hypervisor.
> */
> struct kvm_protected_vm pkvm;
> +
> +#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> + /* Nested virtualization info */
> + struct dentry *debugfs_nv_dentry;
> +#endif
> };
>
> struct kvm_vcpu_fault_info {
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index d968aca0461a..01e9c72d6aa7 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -393,8 +393,12 @@ static inline bool kvm_supports_cacheable_pfnmap(void)
>
> #ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> void kvm_s2_ptdump_create_debugfs(struct kvm *kvm);
> +void kvm_nested_s2_ptdump_create_debugfs(struct kvm_s2_mmu *mmu);
> +void kvm_nested_s2_ptdump_remove_debugfs(struct kvm_s2_mmu *mmu);
> #else
> static inline void kvm_s2_ptdump_create_debugfs(struct kvm *kvm) {}
> +static inline void kvm_nested_s2_ptdump_create_debugfs(struct kvm_s2_mmu *mmu) {}
> +static inline void kvm_nested_s2_ptdump_remove_debugfs(struct kvm_s2_mmu *mmu) {}
> #endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
>
> #endif /* __ASSEMBLER__ */
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index eeea5e692370..31d74ed8449e 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -730,8 +730,10 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
> kvm->arch.nested_mmus_next = (i + 1) % kvm->arch.nested_mmus_size;
>
> /* Make sure we don't forget to do the laundry */
> - if (kvm_s2_mmu_valid(s2_mmu))
> + if (kvm_s2_mmu_valid(s2_mmu)) {
> + kvm_nested_s2_ptdump_remove_debugfs(s2_mmu);
> s2_mmu->pending_unmap = true;
> + }
>
> /*
> * The virtual VMID (modulo CnP) will be used as a key when matching
> @@ -745,6 +747,8 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
> s2_mmu->tlb_vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
> s2_mmu->nested_stage2_enabled = vcpu_read_sys_reg(vcpu, HCR_EL2) & HCR_VM;
>
> + kvm_nested_s2_ptdump_create_debugfs(s2_mmu);
> +
This function can sleep, so I get while running your shadow stage 2 KVM
selftest a messge:
[ 4408.411009] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1624
[ 4408.411075] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 164, name: shadow_stage2
[ 4408.411136] preempt_count: 2, expected: 0
[ 4408.411172] RCU nest depth: 0, expected: 0
[ 4408.411228] CPU: 1 UID: 0 PID: 164 Comm: shadow_stage2 Tainted: G W 7.1.0-rc2+ #48 PREEMPT(full)
[ 4408.411336] Tainted: [W]=WARN
[ 4408.411368] Hardware name: , BIOS
[ 4408.411403] Call trace:
[ 4408.411427] show_stack+0x24/0x50 (C)
[ 4408.411524] dump_stack_lvl+0x90/0x158
[ 4408.411633] dump_stack+0x1c/0x38
[ 4408.411741] __might_resched+0x168/0x208
[ 4408.411839] __might_sleep+0x54/0xb0
[ 4408.411936] down_write+0x30/0xe8
[ 4408.412048] start_dirop+0x3c/0xc0
[ 4408.412149] simple_start_creating+0xb8/0xc8
[ 4408.412241] debugfs_start_creating.part.0+0x68/0x180
[ 4408.412375] __debugfs_create_file+0x80/0x1f8
[ 4408.412505] debugfs_create_file_full+0x28/0x68
[ 4408.412637] kvm_nested_s2_ptdump_create_debugfs+0xa0/0x108
[ 4408.412734] kvm_vcpu_load_hw_mmu+0x27c/0x320
[ 4408.412839] kvm_arch_vcpu_load+0x318/0x5a0
[ 4408.412971] kvm_emulate_nested_eret+0x148/0x3d8
[ 4408.413072] kvm_handle_eret+0x110/0x138
[ 4408.413190] handle_exit+0x6c/0x1e8
[ 4408.413306] kvm_arch_vcpu_ioctl_run+0x3c4/0xc90
[ 4408.413396] kvm_vcpu_ioctl+0x1a0/0xa68
[ 4408.413508] __arm64_sys_ioctl+0xd0/0x160
[L1] L2 exit[ 4408.413631] invoke_syscall+0xa8/0x138
[ 4408.413723] el0_svc_common.constprop.0+0x4c/0x140
[ 4408.413821] do_el0_svc+0x28/0x58
[ 4408.413911] el0_svc+0x48/0x230
[ 4408.414035] el0t_64_sync_handler+0xc0/0x108
[ 4408.414166] el0t_64_sync+0x1b4/0x1b8
I tried to move this function out under the KVM MMU lock, but then I see
a debug entry is duplicated error. I am not sure where exactly this
nested stage 2 debugfs entry create function should go, your help is
much appreciated.
Thanks,
Itaru.
> out:
> atomic_inc(&s2_mmu->refcnt);
>
> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> index 98763b291956..aebbbad85d38 100644
> --- a/arch/arm64/kvm/ptdump.c
> +++ b/arch/arm64/kvm/ptdump.c
> @@ -10,12 +10,14 @@
> #include <linux/kvm_host.h>
> #include <linux/seq_file.h>
>
> +#include <asm/cpufeature.h>
> #include <asm/kvm_mmu.h>
> #include <asm/kvm_pgtable.h>
> #include <asm/ptdump.h>
>
> #define MARKERS_LEN 2
> #define KVM_PGTABLE_MAX_LEVELS (KVM_PGTABLE_LAST_LEVEL + 1)
> +#define S2FNAMESZ sizeof("0x0123456789abcdef-0x0123456789abcdef-s2-disabled")
>
> struct kvm_ptdump_guest_state {
> struct kvm_s2_mmu *mmu;
> @@ -277,6 +279,28 @@ static const struct file_operations kvm_pgtable_levels_fops = {
> .release = kvm_pgtable_debugfs_close,
> };
>
> +void kvm_nested_s2_ptdump_create_debugfs(struct kvm_s2_mmu *mmu)
> +{
> + struct dentry *dent;
> + char file_name[S2FNAMESZ];
> +
> + snprintf(file_name, sizeof(file_name), "0x%llx-0x%llx-s2-%sabled",
> + mmu->tlb_vttbr,
> + mmu->tlb_vtcr,
> + mmu->nested_stage2_enabled ? "en" : "dis");
> +
> + dent = debugfs_create_file(file_name, 0400,
> + mmu->arch->debugfs_nv_dentry, mmu,
> + &kvm_ptdump_guest_fops);
> +
> + mmu->shadow_pt_debugfs_dentry = dent;
> +}
> +
> +void kvm_nested_s2_ptdump_remove_debugfs(struct kvm_s2_mmu *mmu)
> +{
> + debugfs_remove(mmu->shadow_pt_debugfs_dentry);
> +}
> +
> void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
> {
> debugfs_create_file("stage2_page_tables", 0400, kvm->debugfs_dentry,
> @@ -285,4 +309,7 @@ void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
> &kvm->arch.mmu, &kvm_pgtable_range_fops);
> debugfs_create_file("stage2_levels", 0400, kvm->debugfs_dentry,
> &kvm->arch.mmu, &kvm_pgtable_levels_fops);
> + if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT))
> + kvm->arch.debugfs_nv_dentry =
> + debugfs_create_dir("nested", kvm->debugfs_dentry);
> }
> --
> 2.43.0
>
^ permalink raw reply
* RE: Re: Re: [PATCH v2] PCI: host-common: Request bus reassignment when not probe-only
From: Ratheesh Kannoth @ 2026-06-12 4:03 UTC (permalink / raw)
To: bjorn@helgaas.com
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
will@kernel.org, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, robh@kernel.org, vidyas@nvidia.com
In-Reply-To: <MN0PR18MB5847913D9E15805B85A0AAD2D33F2@MN0PR18MB5847.namprd18.prod.outlook.com>
> >From: Bjorn Helgaas <bjorn.helgaas@gmail.com>
> >Sent: Tuesday, May 5, 2026 8:55 PM
>
> >I don't have access to that bug report. If there's nothing secret in
> >it, can you make it public?
> Apologies for the access issue. I am still familiarizing myself with the
> platform's privacy settings, but I certainly intended for this to be a public
> report.
> I'll explore the settings now to make it generic/public and will get back to you
>
> >I assume this is the same issue you mentioned at
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_al
> >l_abkqm-5FLCd9zAM8cW-40rkannoth-2DOptiPlex-2D7090_-
> 3F&d=DwIFaQ&c=nKjWec
> >2b6R0mOyPaz7xtfQ&r=aekcsyBCH00_LewrEDcQBzsRw8KCpUR0vZb_auTHk4
> M&m=yH7EeB
> >e9HwRllD8K-
> >PFNS2CMFSlcaBHU6o3DYa1xndJvwVSHI4aPWi98uDKPRIJI&s=BK4_NvmXa
> >qyszkMVHWAPTa9MeaX-26Ka3xT6NKSXwFQ&e=
> Yes. I believe, we can ignore Bugzilla report as per
> https://www.kernel.org/doc/html/v4.19/admin-guide/reporting-bugs.html ?
> "Once you know the subsystem that is causing the issue, you should send a
> bug report. Some maintainers prefer bugs to be reported via bugzilla
> (https://bugzilla.kernel.org), while others prefer that bugs be reported via the
> subsystem mailing list."
>
> >Your email response was HTML, so the mailing lists rejected it, which
> >is why your response doesn't appear here:
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_al
> >l_20260414081730.3864372-2D1-2Drkannoth-40marvell.com_t_-
> 23u&d=DwIFaQ&c
> >=nKjWec2b6R0mOyPaz7xtfQ&r=aekcsyBCH00_LewrEDcQBzsRw8KCpUR0vZb
> _auTHk4M&m
> >=yH7EeBe9HwRllD8K-
> >PFNS2CMFSlcaBHU6o3DYa1xndJvwVSHI4aPWi98uDKPRIJI&s=7X
> >f3ikUPZpTjbnX3B0zimpsHFMgJx8guRkyGAl7GXz8&e=
> Sorry about that. My mail client (Outlook) defaulted to HTML formatting. Will
> be more careful in future.
Kindly advise if there are any outstanding action items required from my side. I see that the patch is not available in net-next yet
or backported to stable versions. I want to ensure I haven't missed a step, so please excuse my impatience if it is simply a matter
of the usual release cycle.
^ permalink raw reply
* [soc:sunxi/dt-2] BUILD SUCCESS 6b81aa0c8a4f038712fa549e4d44d8279eeb0440
From: kernel test robot @ 2026-06-12 2:48 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git sunxi/dt-2
branch HEAD: 6b81aa0c8a4f038712fa549e4d44d8279eeb0440 arm64: dts: allwinner: a523: Add missing GPIO interrupt
elapsed time: 767m
configs tested: 191
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-13.4.0
arc randconfig-001-20260612 gcc-13.4.0
arc randconfig-002 gcc-13.4.0
arc randconfig-002-20260612 gcc-13.4.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm at91_dt_defconfig clang-17
arm defconfig gcc-16.1.0
arm randconfig-001 gcc-13.4.0
arm randconfig-001-20260612 gcc-13.4.0
arm randconfig-002 gcc-13.4.0
arm randconfig-002-20260612 gcc-13.4.0
arm randconfig-003 gcc-13.4.0
arm randconfig-003-20260612 gcc-13.4.0
arm randconfig-004 gcc-13.4.0
arm randconfig-004-20260612 gcc-13.4.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260612 gcc-13.4.0
arm64 randconfig-002-20260612 gcc-13.4.0
arm64 randconfig-003-20260612 gcc-13.4.0
arm64 randconfig-004-20260612 gcc-13.4.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260612 gcc-13.4.0
csky randconfig-002-20260612 gcc-13.4.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260612 clang-23
hexagon randconfig-002-20260612 clang-23
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260612 gcc-14
i386 buildonly-randconfig-002-20260612 gcc-14
i386 buildonly-randconfig-003-20260612 gcc-14
i386 buildonly-randconfig-004-20260612 gcc-14
i386 buildonly-randconfig-005-20260612 gcc-14
i386 buildonly-randconfig-006-20260612 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260612 clang-22
i386 randconfig-002-20260612 clang-22
i386 randconfig-003-20260612 clang-22
i386 randconfig-004-20260612 clang-22
i386 randconfig-005-20260612 clang-22
i386 randconfig-006-20260612 clang-22
i386 randconfig-007-20260612 clang-22
i386 randconfig-011-20260612 clang-22
i386 randconfig-012-20260612 clang-22
i386 randconfig-013-20260612 clang-22
i386 randconfig-014-20260612 clang-22
i386 randconfig-015-20260612 clang-22
i386 randconfig-016-20260612 clang-22
i386 randconfig-017-20260612 clang-22
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260612 clang-23
loongarch randconfig-002-20260612 clang-23
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
m68k m5272c3_defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips ci20_defconfig clang-23
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001-20260612 clang-23
nios2 randconfig-002-20260612 clang-23
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260612 gcc-11.5.0
riscv randconfig-002-20260612 gcc-11.5.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260612 gcc-11.5.0
s390 randconfig-002-20260612 gcc-11.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001-20260612 gcc-11.5.0
sh randconfig-002-20260612 gcc-11.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260612 gcc-8.5.0
sparc randconfig-002-20260612 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260612 gcc-8.5.0
sparc64 randconfig-002-20260612 gcc-8.5.0
um allmodconfig clang-17
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260612 gcc-8.5.0
um randconfig-002-20260612 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260612 gcc-14
x86_64 buildonly-randconfig-002-20260612 gcc-14
x86_64 buildonly-randconfig-003-20260612 gcc-14
x86_64 buildonly-randconfig-004-20260612 gcc-14
x86_64 buildonly-randconfig-005-20260612 gcc-14
x86_64 buildonly-randconfig-006-20260612 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260612 clang-22
x86_64 randconfig-002-20260612 clang-22
x86_64 randconfig-003-20260612 clang-22
x86_64 randconfig-004-20260612 clang-22
x86_64 randconfig-005-20260612 clang-22
x86_64 randconfig-006-20260612 clang-22
x86_64 randconfig-011-20260612 clang-22
x86_64 randconfig-012-20260612 clang-22
x86_64 randconfig-013-20260612 clang-22
x86_64 randconfig-014-20260612 clang-22
x86_64 randconfig-015-20260612 clang-22
x86_64 randconfig-016-20260612 clang-22
x86_64 randconfig-071-20260612 gcc-14
x86_64 randconfig-072-20260612 gcc-14
x86_64 randconfig-073-20260612 gcc-14
x86_64 randconfig-074-20260612 gcc-14
x86_64 randconfig-075-20260612 gcc-14
x86_64 randconfig-076-20260612 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa allyesconfig gcc-16.1.0
xtensa randconfig-001-20260612 gcc-8.5.0
xtensa randconfig-002-20260612 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] ASoC: meson: axg-tdm-formatter: Use guard() for mutex locks
From: Bui Duc Phuc @ 2026-06-12 2:36 UTC (permalink / raw)
To: Jerome Brunet
Cc: Mark Brown, Liam Girdwood, Neil Armstrong, Kevin Hilman,
Martin Blumenstingl, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <1jo6hhebus.fsf@starbuckisacylon.baylibre.com>
Hi Jerome,
Thank you for the review and for the Reviewed-by tag.
>
> The code is not better or worse with the change but you went through the
> trouble of doing so, if Mark is fine with it, let's have it
>
> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
>
Regarding the point about whether the change makes the code better or worse,
I have sent an additional patch to address related cleanup in the same area:
https://lore.kernel.org/all/20260612020113.9557-1-phucduc.bui@gmail.com/
Would appreciate your review on that as well.
While looking into the Meson ASoC probe paths,
I noticed a few consistency issues that seem to appear across multiple drivers:
1. Mixed usage of dev_err_probe() and dev_err() in probe error paths.
2. Inconsistent error message formatting: some messages start with lowercase
("failed to init..."), while others start with uppercase ("Failed
to register...").
3. In aiu_probe(), error paths for IRQ retrieval do not provide
additional context,
making it harder to identify which resource failed:
aiu->i2s.irq = platform_get_irq_byname(pdev, "i2s");
if (aiu->i2s.irq < 0)
return aiu->i2s.irq;
aiu->spdif.irq = platform_get_irq_byname(pdev, "spdif");
if (aiu->spdif.irq < 0)
return aiu->spdif.irq;
4 ......
Do you think addressing these issues would improve readability and
maintainability of the Meson codebase over time?
Or is it generally preferred to leave these kinds of consistency
improvements untouched unless a functional bug is being fixed?
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic: Check the interrupt is still ours before migrating it
From: Hyunwoo Kim @ 2026-06-12 2:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, Sascha.Bischoff, jic23, timothy.hayes,
andre.przywara, linux-arm-kernel, kvmarm, imv4bel
In-Reply-To: <865x3qtmg6.wl-maz@kernel.org>
On Wed, Jun 10, 2026 at 05:00:25PM +0100, Marc Zyngier wrote:
> On Wed, 10 Jun 2026 14:52:10 +0100,
> Hyunwoo Kim <imv4bel@gmail.com> wrote:
> >
> > On Fri, Jun 05, 2026 at 01:43:32AM -0700, Oliver Upton wrote:
> > > On Fri, Jun 05, 2026 at 08:42:52AM +0100, Marc Zyngier wrote:
> > > > On Fri, 05 Jun 2026 07:00:37 +0100,
> > > > Oliver Upton <oupton@kernel.org> wrote:
> > > > >
> > > > > On Fri, Jun 05, 2026 at 05:59:15AM +0900, Hyunwoo Kim wrote:
> > > > > > vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating
> > > > > > an interrupt to another vCPU. After reacquiring the locks it only checks
> > > > > > that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq))
> > > > > > before moving the interrupt, which assumes that an interrupt whose affinity
> > > > > > is preserved is still queued on this vCPU's ap_list.
> > > > > >
> > > > > > That assumption no longer holds if the interrupt is taken off the ap_list
> > > > > > while the locks are dropped. vgic_flush_pending_lpis() removes the
> > > > > > interrupt from the list and sets irq->vcpu to NULL, but leaves
> > > > > > enabled/pending/target_vcpu untouched. As the interrupt is still enabled
> > > > > > and pending, vgic_target_oracle() returns the same target_vcpu, so the
> > > > > > affinity check passes and list_del() is run a second time on an entry that
> > > > > > has already been removed.
> > > > > >
> > > > > > Also check that the interrupt is still assigned to this vCPU
> > > > > > (irq->vcpu == vcpu) before moving it.
> > > > > >
> > > > > > Fixes: 0919e84c0fc1 ("KVM: arm/arm64: vgic-new: Add IRQ sync/flush framework")
> > > > > > Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
> > > > >
> > > > > Looking at this and the other VGIC patch you sent (which should've been
> > > > > a combined series), are you trying to deal with a vCPU writing to
> > > > > another vCPU's redistributor? I.e. vCPU B setting GICR_CTLR.EnableLPIs=0
> > > > > behind the back of vCPU A?
> > > > >
> > > > > That is extremely relevant information as the off-the-cuff reaction is
> > > > > that no race exists. But since the GIC architecture is awesome and
> > > > > allows for this sort of insanity, it obviously does....
> > > > >
> > > > > Anyway, for LPIs resident on a particular RD, there's zero expectation
> > > > > that the pending state is preserved when EnableLPIs=0. So I'd rather
> > > > > vgic_flush_pending_lpis() just invalidate the pending state.
> > > >
> > > > Just clearing the pending state introduces a potential problem as we
> > > > now have an interrupt that is neither active nor pending on the AP
> > > > list. It is not impossible to solve (we now have similar behaviours
> > > > with SPI deactivation from another vcpu), but that requires posting a
> > > > KVM_REQ_VGIC_PROCESS_UPDATE to the target vcpu.
> > >
> > > Right, I was suggesting that in addition to deleting the LPI from the AP
> > > list we actually invalidate the pending state so that someone sitting on
> > > a pointer to a to-be-freed LPI sees vgic_target_oracle() returning
> > > NULL
> > >
> > > > > Beyond that, I see two other fixes for lifetime issues around the
> > > > > vgic_irq in the middle of migration. I'd like to see explicit RCU
> > > > > protection around the release && reacquire of the ap_list_lock rather
> > > > > than depending on the precondition that IRQs are disabled.
> > > >
> > > > I'm not sure I follow. Are you suggesting turning the AP list into an
> > > > RCU protected list?
> > >
> > > No, sorry, I should expand a little.
> > >
> > > We store a reference on the vgic_irq struct in the AP list, which is
> > > stable so long as the ap_list_lock is held. It should be possible for
> > > the refcount to drop to 0 between releasing the ap_list_lock and
> > > reacquiring it.
> > >
> > > So either vgic_prune_ap_list() takes an additional reference on the
> > > vgic_irq before dropping the ap_list_lock or rely on RCU to protect
> > > vgic_irq structs observed with a non-zero refcount.
> >
> > What are your thoughts on this approach?
> >
> >
> > Best regards,
> > Hyunwoo Kim
> >
> > ---
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
> > index 933983bb2005..7fb871c3ccd8 100644
> > --- a/arch/arm64/kvm/vgic/vgic-init.c
> > +++ b/arch/arm64/kvm/vgic/vgic-init.c
> > @@ -523,7 +523,7 @@ static void __kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
> > * Retire all pending LPIs on this vcpu anyway as we're
> > * going to destroy it.
> > */
> > - vgic_flush_pending_lpis(vcpu);
> > + vgic_flush_pending_lpis(vcpu, true);
> >
> > INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
> > kfree(vgic_cpu->private_irqs);
> > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > index 5913a20d8301..f85d63f17af0 100644
> > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > @@ -303,7 +303,7 @@ static void vgic_mmio_write_v3r_ctlr(struct kvm_vcpu *vcpu,
> > if (ctlr != GICR_CTLR_ENABLE_LPIS)
> > return;
> >
> > - vgic_flush_pending_lpis(vcpu);
> > + vgic_flush_pending_lpis(vcpu, false);
> > vgic_its_invalidate_all_caches(vcpu->kvm);
> > atomic_set_release(&vgic_cpu->ctlr, 0);
> > } else {
> > diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> > index 1e9fe8764584..09629a38fc0a 100644
> > --- a/arch/arm64/kvm/vgic/vgic.c
> > +++ b/arch/arm64/kvm/vgic/vgic.c
> > @@ -192,7 +192,7 @@ static void vgic_release_deleted_lpis(struct kvm *kvm)
> > xa_unlock_irqrestore(&dist->lpi_xa, flags);
> > }
> >
> > -void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu)
> > +void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu, bool destroy)
> > {
> > struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> > struct vgic_irq *irq, *tmp;
> > @@ -204,6 +204,13 @@ void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu)
> > list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) {
> > if (irq_is_lpi(vcpu->kvm, irq->intid)) {
> > raw_spin_lock(&irq->irq_lock);
> > + /* Leave interrupts pending a migration for prune. */
> > + if (!destroy && irq->vcpu != vgic_target_oracle(irq)) {
> > + raw_spin_unlock(&irq->irq_lock);
> > + continue;
> > + }
>
> It's rather unclear to me what the semantics of this are.
>
> If vcpu-a decides to nuke the LPIs of vcpu-b and the LPI had in the
> meantime been migrated to vcpu-c, but obviously not observed by vcpu-c
> yet as the LPI is still on vcpu-b's AP-list, then I don't see the
> point in keeping this state.
>
> Am I missing something obvious?
I looked a bit more into Oliver's review, the one suggesting that pending
be cleared only for resident LPIs while the ones being migrated are left
in place.
What the leave preserves is the pending edge of a single LPI whose target
is already vcpu-c but which is still on vcpu-b's ap_list. This edge is
always lost when we just clear it, but for a device that fires again a
later INT reaches vcpu-c through the oracle, so it is mostly harmless. The
exception is a software LPI that never fires again(irq->hw == false):
that edge is then lost with no way to recover it, because
its_sync_lpi_pending_table only re-syncs the LPIs whose target_vcpu matches,
and the disable path does no pending writeback. I am not entirely sure about
this part, though.
Since this does not look like the common case, if it does not need to be
covered I will send v2 keeping only the pending clear and the ref hold in
vgic_prune_ap_list(). What do you think?
>
> > + /* Pending state is not preserved across EnableLPIs=0. */
> > + irq->pending_latch = false;
>
> That part I agree with.
>
> > list_del(&irq->ap_list);
> > irq->vcpu = NULL;
> > raw_spin_unlock(&irq->irq_lock);
> > @@ -797,6 +804,9 @@ static void vgic_prune_ap_list(struct kvm_vcpu *vcpu)
> >
> > /* This interrupt looks like it has to be migrated. */
> >
> > + /* Keep the interrupt alive while the locks are dropped. */
> > + vgic_get_irq_ref(irq);
> > +
> > raw_spin_unlock(&irq->irq_lock);
> > raw_spin_unlock(&vgic_cpu->ap_list_lock);
> >
> > @@ -839,6 +849,8 @@ static void vgic_prune_ap_list(struct kvm_vcpu *vcpu)
> > raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
> > raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock);
> >
> > + deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq);
> > +
> > if (target_vcpu_needs_kick) {
> > kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu);
> > kvm_vcpu_kick(target_vcpu);
> > diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
> > index 9d941241c8a2..c1ac24ede899 100644
> > --- a/arch/arm64/kvm/vgic/vgic.h
> > +++ b/arch/arm64/kvm/vgic/vgic.h
> > @@ -341,7 +341,7 @@ void vgic_v3_put(struct kvm_vcpu *vcpu);
> > bool vgic_has_its(struct kvm *kvm);
> > int kvm_vgic_register_its_device(void);
> > void vgic_enable_lpis(struct kvm_vcpu *vcpu);
> > -void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu);
> > +void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu, bool destroy);
> > int vgic_its_inject_msi(struct kvm *kvm, struct kvm_msi *msi);
> > int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr);
> > int vgic_v3_dist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> >
>
> I reckon this would work just as well with just the pending state
> being removed in vgic_flush_pending_lpis(), and the reference holding
> hack in gvgic_prune_ap_list().
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Best regards,
Hyunwoo Kim
^ permalink raw reply
* Re: [PATCH] media: bcm2835-unicam: Fix querycap multiple caps
From: kernel test robot @ 2026-06-12 2:14 UTC (permalink / raw)
To: Eugen Hristev, Raspberry Pi Kernel Maintenance,
Mauro Carvalho Chehab, Florian Fainelli, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Sakari Ailus,
Dave Stevenson, Laurent Pinchart, Jean-Michel Hautbois,
Naushir Patuck
Cc: llvm, oe-kbuild-all, linux-media, Hans Verkuil, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Eugen Hristev
In-Reply-To: <20260611-bcmpiqcap-v1-1-10cf7fb438df@kernel.org>
Hi Eugen,
kernel test robot noticed the following build errors:
[auto build test ERROR on a87737435cfa134f9cdcc696ba3080759d04cf72]
url: https://github.com/intel-lab-lkp/linux/commits/Eugen-Hristev/media-bcm2835-unicam-Fix-querycap-multiple-caps/20260611-141320
base: a87737435cfa134f9cdcc696ba3080759d04cf72
patch link: https://lore.kernel.org/r/20260611-bcmpiqcap-v1-1-10cf7fb438df%40kernel.org
patch subject: [PATCH] media: bcm2835-unicam: Fix querycap multiple caps
config: um-allmodconfig (https://download.01.org/0day-ci/archive/20260612/202606121013.RsnqIwho-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260612/202606121013.RsnqIwho-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606121013.RsnqIwho-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/media/platform/broadcom/bcm2835-unicam.c:33:
In file included from include/linux/dma-mapping.h:8:
In file included from include/linux/scatterlist.h:9:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:1209:55: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
1209 | return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port;
| ~~~~~~~~~~ ^
>> drivers/media/platform/broadcom/bcm2835-unicam.c:1836:20: error: use of undeclared identifier 'node'
1836 | if (is_image_node(node))
| ^
1 warning and 1 error generated.
vim +/node +1836 drivers/media/platform/broadcom/bcm2835-unicam.c
1825
1826 /* -----------------------------------------------------------------------------
1827 * V4L2 video device operations
1828 */
1829
1830 static int unicam_querycap(struct file *file, void *priv,
1831 struct v4l2_capability *cap)
1832 {
1833 strscpy(cap->driver, UNICAM_MODULE_NAME, sizeof(cap->driver));
1834 strscpy(cap->card, UNICAM_MODULE_NAME, sizeof(cap->card));
1835
> 1836 if (is_image_node(node))
1837 cap->capabilities |= V4L2_CAP_VIDEO_CAPTURE;
1838 else
1839 cap->capabilities |= V4L2_CAP_META_CAPTURE;
1840
1841 return 0;
1842 }
1843
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] arm64: dts: bst: enable eMMC controller in C1200
From: gordon.ge @ 2026-06-12 0:40 UTC (permalink / raw)
To: arnd; +Cc: soc, linux-arm-kernel, yangzh0906
Add mmc0 node for the DWCMSHC SDHCI controller with basic configuration
(disabled by default) and fixed clock definition in bstc1200.dtsi.
Enable mmc0 with board-specific configuration including 8-bit bus
width and reserved SRAM bounce buffer on the CDCU1.0 ADAS 4C2G board.
The bounce buffer in reserved SRAM addresses hardware constraints
where the eMMC controller cannot access main system memory through
SMMU due to a hardware bug, and all DRAM is located outside the
4GB boundary.
Signed-off-by: Albert Yang <yangzh0906@thundersoft.com>
Acked-by: Gordon Ge <gordon.ge@bst.ai>
Signed-off-by: Gordon Ge <gordon.ge@bst.ai>
---
.../dts/bst/bstc1200-cdcu1.0-adas_4c2g.dts | 19 +++++++++++++++++++
arch/arm64/boot/dts/bst/bstc1200.dtsi | 18 ++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/bst/bstc1200-cdcu1.0-adas_4c2g.dts b/arch/arm64/boot/dts/bst/bstc1200-cdcu1.0-adas_4c2g.dts
index 5eb9ef369d8c..178ad4bf4f0a 100644
--- a/arch/arm64/boot/dts/bst/bstc1200-cdcu1.0-adas_4c2g.dts
+++ b/arch/arm64/boot/dts/bst/bstc1200-cdcu1.0-adas_4c2g.dts
@@ -17,6 +17,25 @@ memory@810000000 {
<0x8 0xc0000000 0x1 0x0>,
<0xc 0x00000000 0x0 0x40000000>;
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ mmc0_reserved: mmc0-reserved@5160000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x5160000 0x0 0x10000>;
+ no-map;
+ };
+ };
+};
+
+&mmc0 {
+ bus-width = <8>;
+ memory-region = <&mmc0_reserved>;
+ non-removable;
+ status = "okay";
};
&uart0 {
diff --git a/arch/arm64/boot/dts/bst/bstc1200.dtsi b/arch/arm64/boot/dts/bst/bstc1200.dtsi
index dd13c6bfc3c8..9660d8396e27 100644
--- a/arch/arm64/boot/dts/bst/bstc1200.dtsi
+++ b/arch/arm64/boot/dts/bst/bstc1200.dtsi
@@ -7,6 +7,12 @@ / {
#address-cells = <2>;
#size-cells = <2>;
+ clk_mmc: clock-4000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <4000000>;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -72,6 +78,18 @@ uart0: serial@20008000 {
status = "disabled";
};
+ mmc0: mmc@22200000 {
+ compatible = "bst,c1200-sdhci";
+ reg = <0x0 0x22200000 0x0 0x1000>,
+ <0x0 0x23006000 0x0 0x1000>;
+ clocks = <&clk_mmc>;
+ clock-names = "core";
+ dma-coherent;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ max-frequency = <200000000>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@32800000 {
compatible = "arm,gic-v3";
reg = <0x0 0x32800000 0x0 0x10000>,
--
2.50.1
^ permalink raw reply related
* [PATCH] arm64: defconfig: enable BST SDHCI controller
From: gordon.ge @ 2026-06-12 0:42 UTC (permalink / raw)
To: arnd; +Cc: soc, linux-arm-kernel, yangzh0906
In-Reply-To: <178123037729.455092.8454252669856079676@bst.ai>
Enable CONFIG_MMC_SDHCI_BST to support eMMC on Black Sesame
Technologies C1200 boards.
Signed-off-by: Albert Yang <yangzh0906@thundersoft.com>
Acked-by: Gordon Ge <gordon.ge@bst.ai>
Signed-off-by: Gordon Ge <gordon.ge@bst.ai>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d905a0777f93..304e12c80af9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1292,6 +1292,7 @@ CONFIG_MMC_SDHCI_OF_SPARX5=y
CONFIG_MMC_SDHCI_CADENCE=y
CONFIG_MMC_SDHCI_ESDHC_IMX=y
CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_MMC_SDHCI_BST=y
CONFIG_MMC_SDHCI_F_SDH30=y
CONFIG_MMC_MESON_GX=y
CONFIG_MMC_SDHCI_MSM=y
--
2.50.1
^ permalink raw reply related
* [PATCH] ASoC: meson: Use dev_err_probe() for device reset failures
From: phucduc.bui @ 2026-06-12 2:01 UTC (permalink / raw)
To: Mark Brown, Jerome Brunet
Cc: Liam Girdwood, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Jaroslav Kysela, Takashi Iwai, linux-sound, linux-arm-kernel,
linux-amlogic, linux-kernel, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
device_reset() may return -EPROBE_DEFER. Switch to dev_err_probe() so
probe failures are reported consistently and deferred probing is handled
properly.
This matches the existing pattern used in aiu_probe().
No functional change intended.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/meson/g12a-toacodec.c | 2 +-
sound/soc/meson/g12a-tohdmitx.c | 2 +-
sound/soc/meson/t9015.c | 6 ++----
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/sound/soc/meson/g12a-toacodec.c b/sound/soc/meson/g12a-toacodec.c
index a95375b53f0a..21941ee552c5 100644
--- a/sound/soc/meson/g12a-toacodec.c
+++ b/sound/soc/meson/g12a-toacodec.c
@@ -312,7 +312,7 @@ static int g12a_toacodec_probe(struct platform_device *pdev)
ret = device_reset(dev);
if (ret)
- return ret;
+ return dev_err_probe(dev, ret, "failed to reset device\n");
regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(regs))
diff --git a/sound/soc/meson/g12a-tohdmitx.c b/sound/soc/meson/g12a-tohdmitx.c
index d541ca4acfaf..967109ca2b57 100644
--- a/sound/soc/meson/g12a-tohdmitx.c
+++ b/sound/soc/meson/g12a-tohdmitx.c
@@ -251,7 +251,7 @@ static int g12a_tohdmitx_probe(struct platform_device *pdev)
ret = device_reset(dev);
if (ret)
- return ret;
+ return dev_err_probe(dev, ret, "failed to reset device\n");
regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(regs))
diff --git a/sound/soc/meson/t9015.c b/sound/soc/meson/t9015.c
index da1a93946d67..f0b55aee5241 100644
--- a/sound/soc/meson/t9015.c
+++ b/sound/soc/meson/t9015.c
@@ -265,10 +265,8 @@ static int t9015_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(priv->avdd), "failed to AVDD\n");
ret = device_reset(dev);
- if (ret) {
- dev_err(dev, "reset failed\n");
- return ret;
- }
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to reset device\n");
regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(regs)) {
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox