* RE: [PATCH V2 1/2] PCI: host-generic: Simplify return value handling in pci_host_common_parse_port(s)
From: Hongxing Zhu @ 2026-05-25 8:26 UTC (permalink / raw)
To: Sherry Sun (OSS), l.stach@pengutronix.de, Frank Li,
bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, robh@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
will@kernel.org
Cc: imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sherry Sun
In-Reply-To: <20260525065443.2338629-2-sherry.sun@oss.nxp.com>
> -----Original Message-----
> From: Sherry Sun (OSS) <sherry.sun@oss.nxp.com>
> Sent: Monday, May 25, 2026 2:55 PM
> To: Hongxing Zhu <hongxing.zhu@nxp.com>; l.stach@pengutronix.de; Frank Li
> <frank.li@nxp.com>; bhelgaas@google.com; lpieralisi@kernel.org;
> kwilczynski@kernel.org; mani@kernel.org; robh@kernel.org;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> will@kernel.org
> Cc: imx@lists.linux.dev; linux-pci@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Sherry Sun
> <sherry.sun@nxp.com>
> Subject: [PATCH V2 1/2] PCI: host-generic: Simplify return value handling in
> pci_host_common_parse_port(s)
>
> From: Sherry Sun <sherry.sun@nxp.com>
>
> The pci_host_common_parse_port() shouldn't check the RC-level binding.
> That's a policy decision that belongs to the caller, not this common helper.
>
> Simplify pci_host_common_parse_port() to only parse properties from the Root
> Port (and its children) without checking the RC node. Also change
> pci_host_common_parse_ports() to return 0 when no ports are found, since it is
> not an error.
>
> So now both functions won't return failure for "property not found" or "port not
> found", they purely return 0 on success and a negative error code on real failures.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Best Regards
Richard Zhu
> ---
> drivers/pci/controller/pci-host-common.c | 29 ++++--------------------
> 1 file changed, 5 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-
> host-common.c
> index 2ce6f4b66133..c93de5a10758 100644
> --- a/drivers/pci/controller/pci-host-common.c
> +++ b/drivers/pci/controller/pci-host-common.c
> @@ -108,8 +108,7 @@ static int pci_host_common_parse_perst(struct device
> *dev,
> * dependencies and the driver may fail to operate if required resources
> * are missing.
> *
> - * Return: 0 on success, -ENODEV if PERST# found in RC node (legacy binding
> - * should be used), Other negative error codes on failure.
> + * Return: 0 on success, negative error codes on failure.
> */
> static int pci_host_common_parse_port(struct device *dev,
> struct pci_host_bridge *bridge, @@ -128,22
> +127,6 @@ static int pci_host_common_parse_port(struct device *dev,
> if (ret)
> return ret;
>
> - /*
> - * 1. PERST# found in RP or its child nodes - list is not empty,
> - * continue
> - *
> - * 2. PERST# not found in RP/children, but found in RC node -
> - * return -ENODEV to fallback legacy binding
> - *
> - * 3. PERST# not found anywhere - list is empty, continue (optional
> - * PERST#)
> - */
> - if (list_empty(&port->perst)) {
> - if (of_property_present(dev->of_node, "reset-gpios") ||
> - of_property_present(dev->of_node, "reset-gpio"))
> - return -ENODEV;
> - }
> -
> INIT_LIST_HEAD(&port->list);
> list_add_tail(&port->list, &bridge->ports);
>
> @@ -158,13 +141,11 @@ static int pci_host_common_parse_port(struct device
> *dev,
> * Iterate through child nodes of the host bridge and parse Root Port
> * properties (currently only reset GPIOs).
> *
> - * Return: 0 on success, -ENODEV if no ports found or PERST# found in RC
> - * node (legacy binding should be used), Other negative error codes on
> - * failure.
> + * Return: 0 on success, negative error codes on failure.
> */
> int pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge
> *bridge) {
> - int ret = -ENODEV;
> + int ret = 0;
>
> for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> if (!of_node_is_type(of_port, "pci")) @@ -174,8 +155,8 @@ int
> pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge *brid
> goto err_cleanup;
> }
>
> - if (ret)
> - return ret;
> + if (list_empty(&bridge->ports))
> + return 0;
>
> return devm_add_action_or_reset(dev, pci_host_common_delete_ports,
> &bridge->ports);
> --
> 2.37.1
^ permalink raw reply
* Re: [PATCH] pinctrl: meson: amlogic-a4: fix gpio output glitch
From: Linus Walleij @ 2026-05-25 8:34 UTC (permalink / raw)
To: xianwei.zhao
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260518-fix-set-value-glitch-v1-1-d350732dc934@amlogic.com>
On Mon, May 18, 2026 at 10:26 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> When the system transitions from bootloader to kernel, the GPIO is
> expected to keep driving high.
>
> However, the Linux kernel first configures the pin direction and then
> sets the output value. This may cause a brief low-level glitch on the
> GPIO line, which can be problematic for regulator control.
>
> By configuring the output value before switching the pin direction to
> output, the glitch can be avoided.
>
> This commit fixes the issue by swapping the configuration order.
>
> Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Is this a regression? I.e. does it cause problems on a supported
system with mainline?
Linus (the big penguin) is unhappy with too many non-critical fixes
so I wanna check this before this goes into fixes.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] gfp_types: Introduce a new GFP_ATOMIC_RT gfp flag
From: Michal Hocko @ 2026-05-25 8:41 UTC (permalink / raw)
To: Waiman Long
Cc: Marc Zyngier, Thomas Gleixner, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, Andrew Morton, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, linux-arm-kernel, linux-kernel, linux-mm,
linux-rt-devel
In-Reply-To: <20260520204628.933654-1-longman@redhat.com>
On Wed 20-05-26 16:46:27, Waiman Long wrote:
> The GFP_ATOMIC flag is to be used in atomic context where user cannot
> sleep and need the allocation to succeed. However, it does not support
> contexts where preemption or interrupt is disabled under PREEMPT_RT
> like raw_spin_lock_irqsave() or plain preempt_disable().
>
> With the advance of the ALLOC_TRYLOCK allocation flag in the v7.1
> kernel, it is possible to allocate memory under such contexts by using
> spin_trylock to acquire the spinlock in the memory allocation path. This
> does increase the chance that the allocation can fail due to the presence
> of concurrent memory allocation requests. So its users must be able to
> handle such memory allocation failure gracefully.
>
> The ALLOC_TRYLOCK flag will only be enabled if none of the
> ___GFP_DIRECT_RECLAIM and ___GFP_KSWAPD_RECLAIM flags are set.
>
> Introduce a new GFP_ATOMIC_RT gfp flag for those PREEMPT_RT
> atomic contexts. This new flag will fall back to GFP_ATOMIC in
> non-PREEMPT_RT kernel. GFP_ATOMIC can continue to be used in contexts
> where preemption and interrupt are not disabled in PREEMPT_RT kernel
> like spin_lock_irqsave().
Before we go this way we need to really be clear we do want to support
raw_spinlock (aka RT) contexts. This is a big commitment because it
dictates internal allocator locking that would have potentially a much
bigger impact long term. I would go this way only after/when we conclude
there is absolutely no other way and we need to have allocator in those
critical sections. Now you have a single place which complains ATM
without much of an explanation why this cannot be really handled in
other way. Have you even considered any options to pull the allocation
from within the raw spin lock section?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH RESEND] arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T
From: AngeloGioacchino Del Regno @ 2026-05-25 8:43 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, matthias.bgg, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Aleksander Jan Bajkowski
In-Reply-To: <20260523101904.293215-1-olek2@wp.pl>
On Sat, 23 May 2026 12:18:55 +0200, Aleksander Jan Bajkowski wrote:
> This patch adds support for keys and LEDs on the Xiaomi AX3000T.
Applied to v7.1-next/dts64, thanks!
[1/1] arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T
commit: 9897c586b09f79ebcf2e67a888743c046b20d254
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v9 1/7] pinctrl: s32cc: use dev_err_probe() and improve error messages
From: Linus Walleij @ 2026-05-25 8:45 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot
In-Reply-To: <20260504131148.3622697-2-khristineandreea.barbulescu@oss.nxp.com>
On Mon, May 4, 2026 at 3:11 PM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
> Change dev_err&return statements into dev_err_probe throughout the driver
> on the probing path.
>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
This patch 1/7 applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] soc: mediatek: pwrap: Remove obsolete NEED CONFIRM comments
From: AngeloGioacchino Del Regno @ 2026-05-25 8:46 UTC (permalink / raw)
To: Akari Tsuyukusa, matthias.bgg
Cc: james.lo, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260522134522.368073-1-akkun11.open@gmail.com>
On 5/22/26 15:45, Akari Tsuyukusa wrote:
> Remove the obsolete "/* NEED CONFIRM */" comments from the MT8196
s/mt8196/mt8195/g
> configuration. These values were previously confirmed during review,
> but the placeholder comments were accidentally left behind.
>
> Link: https://lore.kernel.org/all/2a117e5fe9fe0ece39e9165a463082ef42be973f.camel@mediatek.com/
> Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
after which...
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 0bcd85826375..87bcbfa2d5f1 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -2396,8 +2396,8 @@ static const struct pmic_wrapper_type pwrap_mt8183 = {
> static const struct pmic_wrapper_type pwrap_mt8195 = {
> .regs = mt8195_regs,
> .type = PWRAP_MT8195,
> - .arb_en_all = 0x777f, /* NEED CONFIRM */
> - .int_en_all = 0x180000, /* NEED CONFIRM */
> + .arb_en_all = 0x777f,
> + .int_en_all = 0x180000,
> .int1_en_all = 0,
> .spi_w = PWRAP_MAN_CMD_SPI_WRITE,
> .wdt_src = PWRAP_WDT_SRC_MASK_ALL,
^ permalink raw reply
* Re: [PATCH] clk: mediatek: mt8196: Select REGMAP_MMIO for vlpckgen
From: AngeloGioacchino Del Regno @ 2026-05-25 8:46 UTC (permalink / raw)
To: Akari Tsuyukusa, mturquette, sboyd, bmasney, matthias.bgg, wenst,
laura.nao
Cc: linux-clk, linux-kernel, linux-arm-kernel, linux-mediatek, stable
In-Reply-To: <20260522133023.355404-1-akkun11.open@gmail.com>
On 5/22/26 15:30, Akari Tsuyukusa wrote:
> The MediaTek MT8196 vlpckgen clock driver uses
> __devm_regmap_init_mmio_clk() by devm_regmap_init_mmio(),
> which is defined in drivers/base/regmap/regmap-mmio.c.
> However, the driver's Kconfig entry does not select REGMAP_MMIO.
> This causes a linker error when REGMAP_MMIO is not enabled.
>
> Fix this by selecting REGMAP_MMIO in the Kconfig entry.
>
> Fixes: 2f8b3ae6f0cb ("clk: mediatek: Add MT8196 vlpckgen clock support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/clk/mediatek/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index 2c09fd729bab..fd8440122ec2 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -1006,6 +1006,7 @@ config COMMON_CLK_MT8196
> tristate "Clock driver for MediaTek MT8196"
> depends on ARM64 || COMPILE_TEST
> select COMMON_CLK_MEDIATEK
> + select REGMAP_MMIO
> default ARCH_MEDIATEK
> help
> This driver supports MediaTek MT8196 basic clocks.
^ permalink raw reply
* Re: [PATCH 02/10] [v3] input: gpio-keys: make legacy gpiolib optional
From: Linus Walleij @ 2026-05-25 8:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, linux-kernel, Arnd Bergmann, Christian Lamparter,
Johannes Berg, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Thomas Bogendoerfer,
John Paul Adrian Glaubitz, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Bartosz Golaszewski, Dmitry Torokhov, Lee Jones, Pavel Machek,
Matti Vaittinen, Florian Fainelli, Jonas Gorski, Andrew Lunn,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-wireless, linux-omap, linux-arm-kernel,
linux-mips, linux-sh, linux-input, linux-leds, netdev
In-Reply-To: <20260520183815.2510387-3-arnd@kernel.org>
On Wed, May 20, 2026 at 8:38 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Most users of gpio-keys and gpio-keys-polled use modern gpiolib
> interfaces, but there are still number of ancient sh, arm32 and x86
> machines that have never been converted.
>
> Add an #ifdef block for the parts of the driver that are only used on
> those legacy machines.
>
> The two Rohm PMIC drivers use a gpio-keys device without an actual GPIO,
> passing an IRQ number instead. In order to keep this working both with
> and with CONFIG_GPIOLIB_LEGACY, change the gpio-keys driver to ignore
> the gpio number if an IRQ is passed.
>
> Link: https://lore.kernel.org/all/b3c94552-c104-42e3-be15-7e8362e8039e@gmail.com/
> Link: https://lore.kernel.org/all/afJXG4_rtaj3l2Dk@google.com/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: bind WLAN-bound flows on PPE driver L2 cache miss
From: Lorenzo Bianconi @ 2026-05-25 8:09 UTC (permalink / raw)
To: Jihong Min
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <20260524224330.3995807-1-hurryman2212@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8142 bytes --]
> The Linux bridge FDB can resolve a destination station to WDMA even when
> the Airoha PPE driver's L2 offload cache has no entry for that MAC pair.
> The normal bind path only checks the PPE driver's L2 offload cache, so an
> unbound PPE hit for WLAN egress can stay unbound even though the bridge
> already knows the right output path, unless a later offload event fills
> that PPE driver cache.
>
> This matters for bridge-visible WLAN egress, such as wired-to-WLAN
> forwarding or WLAN peer forwarding across another BSS, radio or MLO link.
> Same-link or same-radio intra-BSS forwarding can stay inside the WLAN
> datapath and is not covered.
Hi Jihong,
In order to offload L2 flows, I assume you are using the OpenWrt bridger
package, right?
IIUC the issue you want to resolve is we are not adding PPE L2 entries for
the specified cases (same-link or same-radio intra-BSS forwarding), correct?
Using this approach, we are breaking the assumption PPE flow-table and hw
flow-table are in sync. If the issue is the one described above, why not
fixing the problem directly in the bridger package?
Moreover, I see you developed the patch using Codex:gpt-5.5. Have you tested it
on a real hw?
Some comments inline.
Regards,
Lorenzo
>
> Before touching the PPE table, resolve the destination MAC through the
> bridge device above the ingress netdev. If the PPE driver's L2 offload
> cache lookup misses, bind the hardware flow to the resolved CDM4/WDMA
> path.
>
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_ppe.c | 138 +++++++++++++++++++----
> 1 file changed, 119 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 26da519236bf..ea932e6d87f6 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -803,65 +803,163 @@ static void airoha_ppe_foe_flow_remove_entry(struct airoha_ppe *ppe,
> }
>
> static int
> -airoha_ppe_foe_commit_subflow_entry(struct airoha_ppe *ppe,
> - struct airoha_flow_table_entry *e,
> - u32 hash, bool rx_wlan)
> +airoha_ppe_foe_commit_subflow(struct airoha_ppe *ppe,
> + const struct airoha_foe_entry *bridge,
maybe l2_hwe instead of bridge?
> + u32 hash, bool rx_wlan)
> {
> u32 mask = AIROHA_FOE_IB1_BIND_PACKET_TYPE | AIROHA_FOE_IB1_BIND_UDP;
> struct airoha_foe_entry *hwe_p, hwe;
> - struct airoha_flow_table_entry *f;
> int type;
>
> hwe_p = airoha_ppe_foe_get_entry_locked(ppe, hash);
> if (!hwe_p)
> return -EINVAL;
>
> - f = kzalloc_obj(*f, GFP_ATOMIC);
> - if (!f)
> - return -ENOMEM;
> -
> - hlist_add_head(&f->l2_subflow_node, &e->l2_flows);
> - f->type = FLOW_TYPE_L2_SUBFLOW;
> - f->hash = hash;
> -
> memcpy(&hwe, hwe_p, sizeof(*hwe_p));
> - hwe.ib1 = (hwe.ib1 & mask) | (e->data.ib1 & ~mask);
> + hwe.ib1 = (hwe.ib1 & mask) | (bridge->ib1 & ~mask);
>
> type = FIELD_GET(AIROHA_FOE_IB1_BIND_PACKET_TYPE, hwe.ib1);
> if (type >= PPE_PKT_TYPE_IPV6_ROUTE_3T) {
> - memcpy(&hwe.ipv6.l2, &e->data.bridge.l2, sizeof(hwe.ipv6.l2));
> - hwe.ipv6.ib2 = e->data.bridge.ib2;
> + memcpy(&hwe.ipv6.l2, &bridge->bridge.l2,
> + sizeof(hwe.ipv6.l2));
> + hwe.ipv6.ib2 = bridge->bridge.ib2;
> /* setting smac_id to 0xf instruct the hw to keep original
> * source mac address
> */
> hwe.ipv6.l2.src_mac_hi = FIELD_PREP(AIROHA_FOE_MAC_SMAC_ID,
> 0xf);
> } else {
> - memcpy(&hwe.bridge.l2, &e->data.bridge.l2,
> + memcpy(&hwe.bridge.l2, &bridge->bridge.l2,
> sizeof(hwe.bridge.l2));
> - hwe.bridge.ib2 = e->data.bridge.ib2;
> + hwe.bridge.ib2 = bridge->bridge.ib2;
> if (type == PPE_PKT_TYPE_IPV4_HNAPT)
> memcpy(&hwe.ipv4.new_tuple, &hwe.ipv4.orig_tuple,
> sizeof(hwe.ipv4.new_tuple));
> }
>
> - hwe.bridge.data = e->data.bridge.data;
> - airoha_ppe_foe_commit_entry(ppe, &hwe, hash, rx_wlan);
> + hwe.bridge.data = bridge->bridge.data;
> +
> + return airoha_ppe_foe_commit_entry(ppe, &hwe, hash, rx_wlan);
> +}
> +
> +static int
> +airoha_ppe_foe_commit_subflow_entry(struct airoha_ppe *ppe,
> + struct airoha_flow_table_entry *e,
> + u32 hash, bool rx_wlan)
> +{
> + struct airoha_flow_table_entry *f;
> + int err;
> +
> + f = kzalloc_obj(*f, GFP_ATOMIC);
> + if (!f)
> + return -ENOMEM;
> +
> + err = airoha_ppe_foe_commit_subflow(ppe, &e->data, hash, rx_wlan);
> + if (err) {
> + kfree(f);
> + return err;
> + }
> +
> + hlist_add_head(&f->l2_subflow_node, &e->l2_flows);
> + f->type = FLOW_TYPE_L2_SUBFLOW;
> + f->hash = hash;
>
> return 0;
> }
>
> +static bool
> +airoha_ppe_foe_prepare_wdma_subflow_dev(struct airoha_ppe *ppe,
> + struct net_device *dev,
> + struct airoha_flow_data *data,
> + struct airoha_foe_entry *hwe)
> +{
> + u32 pse_port;
> + int err;
> +
> + err = airoha_ppe_foe_entry_prepare(ppe->eth, hwe, dev,
> + PPE_PKT_TYPE_BRIDGE, data, 0);
> + if (err)
> + return false;
> +
> + pse_port = FIELD_GET(AIROHA_FOE_IB2_PSE_PORT, hwe->bridge.ib2);
> + if (pse_port != FE_PSE_PORT_CDM4)
> + return false;
> +
> + return true;
return pse_port == FE_PSE_PORT_CDM4;
> +}
> +
> +static struct net_device *
> +airoha_ppe_foe_get_bridge_master(struct net_device *dev)
> +{
> + struct net_device *master = NULL;
> +
> + rcu_read_lock();
> + master = netdev_master_upper_dev_get_rcu(dev);
> + if (master && netif_is_bridge_master(master))
> + dev_hold(master);
> + else
> + master = NULL;
> + rcu_read_unlock();
> +
> + return master;
> +}
> +
> +static bool
> +airoha_ppe_foe_prepare_wdma_subflow(struct airoha_ppe *ppe,
> + struct sk_buff *skb,
> + struct airoha_foe_entry *hwe)
> +{
> + struct ethhdr *eh = eth_hdr(skb);
> + struct airoha_flow_data data = {};
> + struct net_device *master;
> +
> + if (!is_valid_ether_addr(eh->h_source) ||
> + !is_valid_ether_addr(eh->h_dest))
> + return false;
> +
> + ether_addr_copy(data.eth.h_dest, eh->h_dest);
> + ether_addr_copy(data.eth.h_source, eh->h_source);
> +
> + if (!skb->dev)
> + return false;
> +
> + /* WLAN egress unbound hits can arrive before flowtable creates the
> + * L2 master flow normally used for subflow binding. Resolve only
> + * through the bridge master so dev_fill_forward_path() must use the
> + * bridge FDB for the destination MAC. Calling the ingress AP netdev
> + * directly can describe the source station's WDMA path and would
> + * corrupt Wi-Fi-to-wired flows whose real egress is not WDMA.
> + */
> + master = airoha_ppe_foe_get_bridge_master(skb->dev);
> + if (!master)
> + return false;
> +
> + if (airoha_ppe_foe_prepare_wdma_subflow_dev(ppe, master, &data,
> + hwe)) {
> + dev_put(master);
> + return true;
> + }
> +
> + dev_put(master);
> + return false;
maybe something like:
ret = airoha_ppe_foe_prepare_wdma_subflow_dev();
dev_put(master);
return ret;
> +}
> +
> static void airoha_ppe_foe_insert_entry(struct airoha_ppe *ppe,
> struct sk_buff *skb,
> u32 hash, bool rx_wlan)
> {
> + struct airoha_foe_entry wdma_hwe = {};
> struct airoha_flow_table_entry *e;
> struct airoha_foe_bridge br = {};
> struct airoha_foe_entry *hwe;
> bool commit_done = false;
> + bool wdma_ready = false;
> struct hlist_node *n;
> u32 index, state;
>
> + wdma_ready = airoha_ppe_foe_prepare_wdma_subflow(ppe, skb,
> + &wdma_hwe);
> +
> spin_lock_bh(&ppe_lock);
>
> hwe = airoha_ppe_foe_get_entry_locked(ppe, hash);
> @@ -899,6 +997,8 @@ static void airoha_ppe_foe_insert_entry(struct airoha_ppe *ppe,
> airoha_l2_flow_table_params);
> if (e)
> airoha_ppe_foe_commit_subflow_entry(ppe, e, hash, rx_wlan);
> + else if (wdma_ready)
> + airoha_ppe_foe_commit_subflow(ppe, &wdma_hwe, hash, rx_wlan);
> unlock:
> spin_unlock_bh(&ppe_lock);
> }
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v18 0/7] coresight: ctcu: Enable byte-cntr function for TMC ETR
From: Jie Gan @ 2026-05-25 9:04 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Bjorn Andersson, Konrad Dybcio
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <20260507-enable-byte-cntr-for-ctcu-v18-0-2b2d590463a3@oss.qualcomm.com>
On 5/7/2026 10:11 PM, Jie Gan wrote:
> The byte-cntr function provided by the CTCU device is used to count the
> trace data entering the ETR. An interrupt is triggered if the data size
> exceeds the threshold set in the BYTECNTRVAL register. The interrupt
> handler counts the number of triggered interruptions.
>
Gentle ping.
I would be grateful if you could review this patch series when you have
time.
> Based on this concept, the irq_cnt can be used to determine whether
> the etr_buf is full. The ETR device will be disabled when the active
> etr_buf is nearly full or a timeout occurs. The nearly full buffer will
> be switched to background after synced. A new buffer will be picked from
> the etr_buf_list, then restart the ETR device.
>
> The byte-cntr reading functions can access data from the synced and
> deactivated buffer, transferring trace data from the etr_buf to userspace
> without stopping the ETR device.
>
> The byte-cntr read operation has integrated with the file node tmc_etr,
> for example:
> /dev/tmc_etr0
> /dev/tmc_etr1
>
> There are two scenarios for the tmc_etr file node with byte-cntr function:
> 1. BYTECNTRVAL register is configured and byte-cntr is enabled -> byte-cntr read
> 2. BYTECNTRVAL register is reset or byte-cntr is disabled -> original behavior
>
> Shell commands to enable byte-cntr reading for etr0:
> echo 1 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
> echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
> echo 1 > /sys/bus/coresight/devices/etm0/enable_source
> cat /dev/tmc_etr0
>
> Reset the BYTECNTR register for etr0:
> echo 0 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
>
> Test Report:
> === Module setup ===
> CONFIG_CORESIGHT=y (built-in, no action needed)
> CONFIG_CORESIGHT_LINK_AND_SINK_TMC=y (built-in, no action needed)
> coresight-ctcu: not loaded, running modprobe...
> coresight-ctcu: loaded
> CTCU byte-cntr test
> CTCU : ctcu0
> ETR : tmc_etr0
> source : etm0
> chardev: /dev/tmc_etr0
> module : coresight-ctcu
>
> === T1: device presence ===
> PASS: CTCU device found: ctcu0
> PASS: TMC ETR device found: tmc_etr0
>
> === T2: irq_enabled sysfs attributes ===
> PASS: irq_enabled0 attribute exists
> PASS: irq_enabled0 readable, value=0
> PASS: irq_enabled1 attribute exists
> PASS: irq_enabled1 readable, value=0
>
> === T3: irq_enabled write/read round-trip ===
> PASS: irq_enabled0: write 1 -> read back 1
> PASS: irq_enabled0: write 0 -> read back 0
> PASS: irq_enabled1: write 1 -> read back 1
> PASS: irq_enabled1: write 0 -> read back 0
>
> === T4: byte-cntr read with active trace ===
> [step] cleanup: byte_cntr_disable
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> [step] byte_cntr_enable
> [step] set irq_enabled0 = 1
> [step] set buffer_size = 0x2000000
> [step] enable_sink = 1 (tmc_etr0)
> [step] enable_source = 1 (etm0)
> [step] byte_cntr_enable done
> [step] cat /dev/tmc_etr0 > /tmp/tmc_etr0.bin &
> [step] sleep 5 (accumulate trace data)
> [step] byte_cntr_disable
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> PASS: T4: cat exited naturally after source disabled (EOF delivered)
> PASS: byte-cntr read returned 35333968 bytes -> /tmp/tmc_etr0.bin
> PASS: no kernel warnings/oops after: byte-cntr read
>
> === T5: EBUSY on concurrent open while byte-cntr reading ===
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> [step] set irq_enabled0 = 1
> [step] set buffer_size = 0x2000000
> [step] enable_sink = 1 (tmc_etr0)
> [step] enable_source = 1 (etm0)
> [step] byte_cntr_enable done
> PASS: T5: second open correctly refused (EBUSY)
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> PASS: no kernel warnings/oops after: concurrent open test
>
> === T6: rmmod while byte-cntr read is active ===
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> [step] set irq_enabled0 = 1
> [step] set buffer_size = 0x2000000
> [step] enable_sink = 1 (tmc_etr0)
> [step] enable_source = 1 (etm0)
> [step] byte_cntr_enable done
> PASS: T6: rmmod returned non-zero (device busy), no panic
> PASS: no kernel warnings/oops after: rmmod while reading
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
>
> === T7: insmod after rmmod and re-probe sanity ===
> [step] module still loaded after T6, retrying rmmod
> PASS: T7: modprobe coresight-ctcu succeeded
> PASS: T7: CTCU device reappeared: ctcu0
> PASS: no kernel warnings/oops after: insmod / re-probe
>
> ===================================
> ===================================
>
> Results: PASS=20 FAIL=0 SKIP=0
> ---
> Changes in v18:
> 1. add a NULL check for the in_conns instance in patch 1.
> 2. fix a bug in patch 2: the tmc_alloc_etr_buf never return NULL and the
> previous check for the return value is incorrect.
> 3. add more kernel_doc description for tmc_clean_etr_buf_list function
> in patch 2
> - Link to v17: https://lore.kernel.org/r/20260421-enable-byte-cntr-for-ctcu-v17-0-9cf36ff55fc0@oss.qualcomm.com
>
> Changes in v17:
> 1. fix race issue during allocat buffer.
> 2. fix user after free issue observed when remove module.
> - Link to v16: https://lore.kernel.org/r/20260323-enable-byte-cntr-for-ctcu-v16-0-7a413d211b8d@oss.qualcomm.com
>
> Changes in v16:
> 1. Remove lock/unlock processes in patch "coresight: tmc: add create/clean
> functions for etr_buf_list" because we are allocating/freeing memory.
> - Link to v15: https://lore.kernel.org/r/20260313-enable-byte-cntr-for-ctcu-v15-0-1777f14ed319@oss.qualcomm.com
>
> Changes in v15:
> 1. add lockdep_assert_held in patch "coresight: tmc: add create/clean
> functions for etr_buf_list"
> 2. optimize tmc_clean_etr_buf_list function
> 3. optimize the patch "enable byte-cntr for TMC ETR devices" according
> to Suzuki's comments
> - call byte_cntr_sysfs_ops from etr_sysfs_ops
> - optimize the lock usage in all functions
> - remove the buf_node parameter in etr_drvdata, move it to
> byte_cntr_data
> - move the tmc_reset_sysfs_buf function to tmc-etr.c
> - add a read flag to struct etr_buf_node to allow updating pos while
> traversing etr_buf_list during data reads.
> Link to v14: https://lore.kernel.org/r/20260309-enable-byte-cntr-for-ctcu-v14-0-c08823e5a8e6@oss.qualcomm.com
>
> Changes in V14:
> 1. Drop the patch: integrate byte-cntr's sysfs_ops with tmc sysfs file_ops
> 2. Replace tmc_sysfs_ops with byte_cntr_sysfs_ops in byte_cntr_start
> function and restore etr_sysfs_ops in byte_cntr_unprepare function.
> 3. Remove redundant checks in byte‑cntr functions.
> Link to V13: https://lore.kernel.org/all/20260223-enable-byte-cntr-for-ctcu-v13-0-9cb44178b250@oss.qualcomm.com/
>
> Changes in v13:
> 1. initilize the byte_cntr_data->raw_spin_lock before using.
> 2. replace kzalloc with kzalloc_obj.
> Link to V12: https://lore.kernel.org/all/20260203-enable-byte-cntr-for-ctcu-v12-0-7bf81b86b70e@oss.qualcomm.com/
>
> Changes in v12:
> 1. Add a new function for retrieving the CTCU's coresight_dev instead of
> refactor the existing function.
> Link to v11: https://lore.kernel.org/r/20260126-enable-byte-cntr-for-ctcu-v11-0-c0af66ba15cf@oss.qualcomm.com
>
> Changes in v11:
> 1. Correct the description in patch1 for the function coresight_get_in_port.
> 2. Renaming the sysfs_ops to tmc_sysfs_ops per Suzuki's suggestion.
> Link to v10: https://lore.kernel.org/r/20260122-enable-byte-cntr-for-ctcu-v10-0-22978e3c169f@oss.qualcomm.com
>
> Changes in v10:
> 1. fix a free memory issue that is reported by robot for patch 2.
> Link to v9: https://lore.kernel.org/r/20251224-enable-byte-cntr-for-ctcu-v9-0-886c4496fed4@oss.qualcomm.com
>
> Changes in v9:
> 1. Drop the patch: add a new API to retrieve the helper device
> 2. Add a new patch to refactor the tmc_etr_get_catu_device function,
> making it generic to support all types of helper devices associated with ETR.
> 3. Optimizing the code for creating irq_threshold sysfs node.
> 4. Remove interrupt-name property and obtain the IRQ based on the
> in-port number.
> Link to v8: https://lore.kernel.org/r/20251211-enable-byte-cntr-for-ctcu-v8-0-3e12ff313191@oss.qualcomm.com
>
> Changes in V8:
> 1. Optimizing the patch 1 and patch 2 according to Suzuki's comments.
> 2. Combine the patch 3 and patch 4 together.
> 3. Rename the interrupt-name to prevent confusion, for example:etr0->etrirq0.
> Link to V7 - https://lore.kernel.org/all/20251013-enable-byte-cntr-for-ctcu-v7-0-e1e8f41e15dd@oss.qualcomm.com/
>
> Changes in V7:
> 1. rebased on tag next-20251010
> 2. updated info for sysfs node document
> Link to V6 - https://lore.kernel.org/all/20250908-enable-byte-cntr-for-tmc-v6-0-1db9e621441a@oss.qualcomm.com/
>
> Changes in V6:
> 1. rebased on next-20250905.
> 2. fixed the issue that the dtsi file has re-named from sa8775p.dtsi to
> lemans.dtsi.
> 3. fixed some minor issues about comments.
> Link to V5 - https://lore.kernel.org/all/20250812083731.549-1-jie.gan@oss.qualcomm.com/
>
> Changes in V5:
> 1. Add Mike's reviewed-by tag for patchset 1,2,5.
> 2. Remove the function pointer added to helper_ops according to Mike's
> comment, it also results the patchset has been removed.
> 3. Optimizing the paired create/clean functions for etr_buf_list.
> 4. Remove the unneeded parameter "reading" from the etr_buf_node.
> Link to V4 - https://lore.kernel.org/all/20250725100806.1157-1-jie.gan@oss.qualcomm.com/
>
> Changes in V4:
> 1. Rename the function to coresight_get_in_port_dest regarding to Mike's
> comment (patch 1/10).
> 2. Add lock to protect the connections regarding to Mike's comment
> (patch 2/10).
> 3. Move all byte-cntr functions to coresight-ctcu-byte-cntr file.
> 4. Add tmc_read_ops to wrap all read operations for TMC device.
> 5. Add a function in helper_ops to check whether the byte-cntr is
> enabkled.
> 6. Call byte-cntr's read_ops if byte-cntr is enabled when reading data
> from the sysfs node.
> Link to V3 resend - https://lore.kernel.org/all/20250714063109.591-1-jie.gan@oss.qualcomm.com/
>
> Changes in V3 resend:
> 1. rebased on next-20250711.
> Link to V3 - https://lore.kernel.org/all/20250624060438.7469-1-jie.gan@oss.qualcomm.com/
>
> Changes in V3:
> 1. The previous solution has been deprecated.
> 2. Add a etr_buf_list to manage allcated etr buffers.
> 3. Add a logic to switch buffer for ETR.
> 4. Add read functions to read trace data from synced etr buffer.
> Link to V2 - https://lore.kernel.org/all/20250410013330.3609482-1-jie.gan@oss.qualcomm.com/
>
> Changes in V2:
> 1. Removed the independent file node /dev/byte_cntr.
> 2. Integrated the byte-cntr's file operations with current ETR file
> node.
> 3. Optimized the driver code of the CTCU that associated with byte-cntr.
> 4. Add kernel document for the export API tmc_etr_get_rwp_offset.
> 5. Optimized the way to read the rwp_offset according to Mike's
> suggestion.
> 6. Removed the dependency of the dts patch.
> Link to V1 - https://lore.kernel.org/all/20250310090407.2069489-1-quic_jiegan@quicinc.com/
>
> To: Suzuki K Poulose <suzuki.poulose@arm.com>
> To: Mike Leach <mike.leach@arm.com>
> To: James Clark <james.clark@linaro.org>
> To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: Tingwei Zhang <tingwei.zhang@oss.qualcomm.com>
> To: Bjorn Andersson <andersson@kernel.org>
> To: Konrad Dybcio <konradybcio@kernel.org>
> Cc: coresight@lists.linaro.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-msm@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>
> ---
> Jie Gan (7):
> coresight: core: refactor ctcu_get_active_port and make it generic
> coresight: tmc: add create/clean functions for etr_buf_list
> coresight: tmc: introduce tmc_sysfs_ops to wrap sysfs read operations
> coresight: etr: add a new function to retrieve the CTCU device
> dt-bindings: arm: add an interrupt property for Coresight CTCU
> coresight: ctcu: enable byte-cntr for TMC ETR devices
> arm64: dts: qcom: lemans: add interrupts to CTCU device
>
> .../ABI/testing/sysfs-bus-coresight-devices-ctcu | 9 +
> .../bindings/arm/qcom,coresight-ctcu.yaml | 10 +
> arch/arm64/boot/dts/qcom/lemans.dtsi | 3 +
> drivers/hwtracing/coresight/Makefile | 2 +-
> drivers/hwtracing/coresight/coresight-core.c | 27 ++
> .../hwtracing/coresight/coresight-ctcu-byte-cntr.c | 304 +++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-ctcu-core.c | 146 ++++++++--
> drivers/hwtracing/coresight/coresight-ctcu.h | 79 +++++-
> drivers/hwtracing/coresight/coresight-priv.h | 2 +
> drivers/hwtracing/coresight/coresight-tmc-core.c | 55 ++--
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 243 +++++++++++++++-
> drivers/hwtracing/coresight/coresight-tmc.h | 42 +++
> 12 files changed, 850 insertions(+), 72 deletions(-)
> ---
> base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
> change-id: 20260309-enable-byte-cntr-for-ctcu-ff86e6198b7f
>
> Best regards,
^ permalink raw reply
* Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
From: Alexis Lothoré @ 2026-05-25 9:05 UTC (permalink / raw)
To: Emil Tsalapatis, Alexis Lothoré, Alexei Starovoitov
Cc: Andrey Konovalov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <DIPDH3PCUDDG.EGYL0SYSG1IO@etsalapatis.com>
On Fri May 22, 2026 at 7:13 PM CEST, Emil Tsalapatis wrote:
> On Fri May 22, 2026 at 10:14 AM EDT, Alexis Lothoré wrote:
>> On Tue Apr 14, 2026 at 4:38 PM CEST, Alexei Starovoitov wrote:
>>> On Tue, Apr 14, 2026 at 6:24 AM Alexis Lothoré
>>> <alexis.lothore@bootlin.com> wrote:
>>>>
>>>> On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote:
>>>> > On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
>>>> > <alexis.lothore@bootlin.com> wrote:
>>
>> [...]
>>
>>>> >> +config BPF_JIT_KASAN
>>>> >> + bool
>>>> >> + depends on HAVE_EBPF_JIT_KASAN
>>>> >> + default y if BPF_JIT && KASAN_GENERIC
>>>> >
>>>> > Should this be "depends on KASAN && KASAN_GENERIC"?
>>>>
>>>> Meaning, making it an explicit user-selectable option ?
>>>>
>>>> If so, the current design choice is voluntary and based on the feedback
>>>> received on the original RFC, where I have been suggested to
>>>> automatically enable the KASAN instrumentation in BPF programs if KASAN
>>>> support is enabled in the kernel ([1]). But if a user-selectable toggle
>>>> is eventually a better solution, I'm fine with changing it.
>>>
>>> Let's not add more config knobs.
>>> Even this patch looks redundant.
>>> Inside JIT do instrumentation when KASAN_GENERIC is set.
>>
>> (with quite some delay) I think it would be better to keep this new
>> BPF_JIT_KASAN, because aside from the possibility to use it in
>> bpf_jit_comp.c, it allows to update tests affected by KASAN
>> instrumentation in a nicer way. For example, the test_loader subtests
>> that monitor JITted instructions are confused by KASAN. I can either
>> skip them or make them smarter when KASAN is enabled for BPF, but in
>> both cases, it would be nicer to just adapt the behavior based on a
>> generic CONFIG_BPF_JIT_KASAN, rather than sprinkling some "if
>> jit_enabled AND CONFIG_KASAN_GENERIC AND ARCH_X86" in selftests. That
>> still does not make it a config knob, that just creates an internal
>> Kconfig option that is automatically turned on when KASAN and JIT are
>> enabled at build time.
>
> Having a togglable config knob gives us the option to set up KASAN for
> the kernel but not for BPF, and I don't see why we'd want that. Imo we are
> already paying the cost of KASAN for the rest of the kernel, there is no
> incentive to not run it for the BPF JIT. Having to eat the complexity cost
> in the selftests seems reasonable if the alternative means a cleaner
> interface for the user (preventing them from choosing an unreasonable
> combination of options).
Again, this does not expose a togglable knob, this is a purely internal
kconfig, automatically enabled if CONFIG_KASAN_GENERIC is set and if the
architecture-specific Kconfig defines HAVE_EBPF_JIT_KASAN (since we want
it for x86 only), and there would be no way to enable KASAN for kernel
only and not for BPF, or the other way around. What I am proposing is
just an internal, architecture-agnostice kconfig to avoid conditioning
some selftests to any architecture.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] arm64: tlb: Flush walk cache when unsharing PMD tables
From: Zeng Heng @ 2026-05-25 9:20 UTC (permalink / raw)
To: Catalin Marinas, will, akpm, npiggin, aneesh.kumar, peterz
Cc: linux-kernel, wangkefeng.wang, linux-arm-kernel, linux-mm,
linux-arch, zengheng4, sunnanyong, blingxue
In-Reply-To: <177944657885.252010.9796978866224637120.b4-ty@arm.com>
Hi Catalin,
On 2026/5/22 18:42, Catalin Marinas wrote:
> On Thu, 21 May 2026 15:30:11 +0800, Zeng Heng wrote:
>> When huge_pmd_unshare() is called to unshare a PMD table, the
>> tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true
>> but the aarch64 tlb_flush() only checked tlb->freed_tables to
>> determine whether to use TLBF_NONE (vae1is, invalidates walk
>> cache) or TLBF_NOWALKCACHE (vale1is, leaf-only).
>>
>> This caused the stale PMD page table entry to remain in the walk cache
>> after unshare, potentially leading to incorrect page table walks.
>>
>> [...]
> Applied to arm64 (for-next/fixes), thanks!
>
> [1/1] arm64: tlb: Flush walk cache when unsharing PMD tables
> https://git.kernel.org/arm64/c/c2ff4764e03e
This original issue was reported by our customer, who also participated
in the root cause analysis and resolution.
Could you please help add the below tags:
Co-developed-by: Xue Xiaowei <blingxue@tencent.com>
Signed-off-by: Xue Xiaowei <blingxue@tencent.com>
Thank you in advance.
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Robby Cai @ 2026-05-25 9:26 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam,
sebastian.krzyszkowiak, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <ag8byj8ZavKyxWRR@lizhi-Precision-Tower-5810>
On Thu, May 21, 2026 at 10:50:50AM -0400, Frank Li wrote:
> On Thu, May 21, 2026 at 07:49:52PM +0800, Robby Cai wrote:
> > On Wed, May 20, 2026 at 02:52:24PM -0400, Frank Li wrote:
> > > On Wed, May 20, 2026 at 02:54:52PM +0800, Robby Cai wrote:
> > > > On Fri, May 15, 2026 at 10:01:47AM -0400, Frank Li wrote:
> > > > > On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> > > > > > Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> > > > > > on the i.MX8MQ EVK, and add two OV5640 camera sensors.
> > > > > >
> > > > > > The sensors are connected via I2C1 and I2C2, each with proper
> > > > > > endpoint descriptions to form complete media pipelines.
> > > > > >
> > > > > > The resulting pipelines are:
> > > > > >
> > > > > > - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
> > > > > > - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
> > > > > >
> > > > > > Both pipelines have been validated on the i.MX8MQ EVK using the
> > > > > > upstream OV5640 driver.
> > > > > >
> > > > > > Both OV5640 sensors share a single reset GPIO on this board,
> > > > > > which prevents independent hardware reset when both cameras
> > > > > > are enabled. As a result, the reset line is kept deasserted
> > > > > > via a GPIO hog, and sensor reset is performed via software.
> > > > >
> > > > > Does reset_control_get_shared() resolve this problem?
> > > > >
> > > >
> > > > No, reset_control_get_shared() does not really solve this issue.
> > > >
> > > > The problem here is not about software coordination, but about the
> > > > hardware topology: both sensors are physically tied to the same reset
> > > > line. This means any reset operation will always affect both devices
> > > > simultaneously, regardless of how the reset framework is used.
> > >
> > > Reset framework is resolve this problem. It is quite common that many devices
> > > shared one reset pin.
> >
> > okay, I'll try to switch to use this approach in next revision.
> >
> > Some devices require coordinated RESET and PWDN sequencing, but in this
> > case the device can be properly initialized with RESET held inactive and
> > controlled solely via the PWDN signal, which makes this approach viable.
>
> PWDN should go through regulator interface.
Thanks for the suggestion.
Modeling PWDN via the regulator framework makes sense, but it would require
changes across multiple platforms beyond NXP. To keep this series focused
and easier to review, I would prefer to address this in a follow-up patch set.
>
> >
> > >
> > > >
> > > > While reset_control_get_shared() introduces reference counting to avoid
> > > > unintended assertions, it does not allow independent reset control.
> > > > In particular:
> > > >
> > > > - A reset operation (assert) will still impact both sensors.
> > >
> > > yes, only when first devices toggle reset signal. Second device do nothing.
> > >
> > > > - It does not solve the requirement for per-device hardware reset.
> > >
> > > It is hardware limitation.
> > >
> > > >
> > > > Therefore, using a shared reset control does not provide true isolation
> > > > between the two OV5640 instances.
> > >
> > > It is not isolation. Just don't allow second device to toggle reset pin.
> > >
> > > >
> > > > Keeping the reset line permanently deasserted (e.g. via GPIO hog) and
> > > > handling initialization through software/power sequencing is a valid
> > > > and practical solution for this hardware design.
> > >
> > > If use i2c gpio, expandor driver may probe after sensor driver probe. So
> > > reset may happen after sensor driver probe.
> >
> >
> > Just to clarify, the reset GPIO in this design is provided by the SoC GPIO
> > controller (gpio1), not an external I2C GPIO expander.
>
> It is just special case. you touch ov5640 driver code, so need consider
> more general case.
Yes, agreed. I will take the more general use cases into account.
Regards,
Robby
>
> Frank
> >
> > Therefore, the "late reset" issue you mentioned does not apply here.
> >
> > Regards,
> > Robby
> > >
> > > Frank
> > > >
> > > > This matches the intention of the upstream changes as well, where GPIO-
> > > > based resets are treated as simple control signals rather than fully
> > > > isolated reset domains.
> > > >
> > > > In practice, using a shared reset here can even introduce subtle
> > > > interference between the two cameras during probe or power cycling,
> > > > so it is safer to avoid using reset for runtime control entirely.
> > > >
> > > > Regards,
> > > > Robby
> > > >
^ permalink raw reply
* [PATCH v7 0/5] Add microchip sama7d65 SoC I3C support
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan
Add support for microchip sama7d65 SoC I3C master only IP which is
based on mipi-i3c-hci from synopsys implementing version 1.0
specification. The platform specific changes are integrated in the
mipi-i3c-hci driver using existing quirks.
I3C in master mode supports up to 12.5MHz, SDR mode data transfer in
mixed bus mode (I2C and I3C target devices on same i3c bus).
Please refer to the individual patches for changelogs.
Durai Manickam KR (2):
clk: at91: sama7d65: add peripheral clock for I3C
ARM: dts: microchip: add I3C controller
Manikandan Muralidharan (3):
dt-bindings: i3c: mipi-i3c-hci: add Microchip SAMA7D65 compatible
i3c: mipi-i3c-hci: add microchip sama7d65 SoC compatible with the
required quirk
ARM: configs: at91: sama7: add sama7d65 i3c-hci
.../devicetree/bindings/i3c/mipi-i3c-hci.yaml | 27 ++++++++++++++++---
arch/arm/boot/dts/microchip/sama7d65.dtsi | 8 ++++++
arch/arm/configs/sama7_defconfig | 2 ++
drivers/clk/at91/sama7d65.c | 1 +
drivers/i3c/master/mipi-i3c-hci/core.c | 10 +++++++
5 files changed, 44 insertions(+), 4 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH v7 1/5] dt-bindings: i3c: mipi-i3c-hci: add Microchip SAMA7D65 compatible
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan, Conor Dooley
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
Add the microchip,sama7d65-i3c-hci compatible string to the MIPI I3C
HCI binding. The Microchip SAMA7D65 I3C controller is based on the
MIPI HCI specification but requires two clocks, so add a conditional
constraint when this compatible is present.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v5:
- drop min/maxItems around clock entries
- use if/then/else clause instead of separate allOf entry
- cosmetic fixes for indentation and formatting
Changes in v4:
- Define and describe the clock property in the top-level properties
section rather than inside the if/then conditional
.../devicetree/bindings/i3c/mipi-i3c-hci.yaml | 27 ++++++++++++++++---
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
index 39bb1a1784c9..d488fb420945 100644
--- a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
+++ b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
@@ -9,9 +9,6 @@ title: MIPI I3C HCI
maintainers:
- Nicolas Pitre <npitre@baylibre.com>
-allOf:
- - $ref: /schemas/i3c/i3c.yaml#
-
description: |
MIPI I3C Host Controller Interface
@@ -28,9 +25,17 @@ description: |
properties:
compatible:
- const: mipi-i3c-hci
+ enum:
+ - mipi-i3c-hci
+ - microchip,sama7d65-i3c-hci
reg:
maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral bus clock
+ - description: System Generic clock
+
interrupts:
maxItems: 1
@@ -39,6 +44,20 @@ required:
- reg
- interrupts
+allOf:
+ - $ref: /schemas/i3c/i3c.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,sama7d65-i3c-hci
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
unevaluatedProperties: false
examples:
--
2.25.1
^ permalink raw reply related
* [PATCH v7 2/5] clk: at91: sama7d65: add peripheral clock for I3C
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Durai Manickam KR, Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
From: Durai Manickam KR <durai.manickamkr@microchip.com>
Add peripheral clock description for I3C.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v3:
- Fixed indentation issues in the clock table entry
drivers/clk/at91/sama7d65.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/at91/sama7d65.c b/drivers/clk/at91/sama7d65.c
index 7dee2b160ffb..ba8ff413fa2c 100644
--- a/drivers/clk/at91/sama7d65.c
+++ b/drivers/clk/at91/sama7d65.c
@@ -677,6 +677,7 @@ static struct {
{ .n = "uhphs_clk", .p = PCK_PARENT_HW_MCK5, .id = 101, },
{ .n = "dsi_clk", .p = PCK_PARENT_HW_MCK3, .id = 103, },
{ .n = "lvdsc_clk", .p = PCK_PARENT_HW_MCK3, .id = 104, },
+ { .n = "i3cc_clk", .p = PCK_PARENT_HW_MCK8, .id = 105, },
};
/*
--
2.25.1
^ permalink raw reply related
* [PATCH v2] soc: mediatek: pwrap: Remove obsolete NEED CONFIRM comments
From: Akari Tsuyukusa @ 2026-05-25 9:24 UTC (permalink / raw)
To: matthias.bgg, angelogioacchino.delregno
Cc: james.lo, linux-kernel, linux-arm-kernel, linux-mediatek,
Akari Tsuyukusa
In-Reply-To: <dd1136db-1a78-4d32-a3ed-13691621c8ba@collabora.com>
Remove the obsolete "/* NEED CONFIRM */" comments from the MT8195
configuration. These values were previously confirmed during review,
but the placeholder comments were accidentally left behind.
Link: https://lore.kernel.org/all/2a117e5fe9fe0ece39e9165a463082ef42be973f.camel@mediatek.com/
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
changes in v2
- Fix commit message (MT8196 -> MT8195)
- Add Reviewed-by tag
drivers/soc/mediatek/mtk-pmic-wrap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 0bcd85826375..87bcbfa2d5f1 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -2396,8 +2396,8 @@ static const struct pmic_wrapper_type pwrap_mt8183 = {
static const struct pmic_wrapper_type pwrap_mt8195 = {
.regs = mt8195_regs,
.type = PWRAP_MT8195,
- .arb_en_all = 0x777f, /* NEED CONFIRM */
- .int_en_all = 0x180000, /* NEED CONFIRM */
+ .arb_en_all = 0x777f,
+ .int_en_all = 0x180000,
.int1_en_all = 0,
.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
--
2.54.0
^ permalink raw reply related
* [PATCH v7 3/5] i3c: mipi-i3c-hci: add microchip sama7d65 SoC compatible with the required quirk
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
Add support for microchip sama7d65 SoC I3C HCI master only IP
with additional clock support to enable bulk clock acquisition
and apply the required quirks.
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v7:
- Use (void *)(ulong) cast instead of direct (void *) cast in
of_device_id.data for pointer-size safety across architectures
- Update commit message body to explicitly mention quirk application
Changes in v6:
- Reorder local variable definitions in i3c_hci_probe in descending
order of line length
Changes in v5:
- Remove HCI_QUIRK_CLK_SUPPORT quirk and call
devm_clk_bulk_get_all_enabled unconditionally, eliminating the
need for a clock-specific quirk flag
Changes in v4:
- Remove the clock index variable MCHP_I3C_CLK_IDX as it is no
longer needed after switching to bulk clock handling
Changes in v3:
- Make use of existing HCI_QUIRK_* code base instead of introducing
separate MCHP_HCI_QUIRK_* flags
- Introduce HCI_QUIRK_CLK_SUPPORT to handle peripheral and system
generic clk in bulk
Changes in v2:
- Platform specific changes integrated in the existing mipi-i3c-hci
driver by introducing separate MCHP_HCI_QUIRK_* quirks and vendor
specific quirk files rather than a standalone driver
drivers/i3c/master/mipi-i3c-hci/core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c
index b781dbed2165..4cdf2abd4219 100644
--- a/drivers/i3c/master/mipi-i3c-hci/core.c
+++ b/drivers/i3c/master/mipi-i3c-hci/core.c
@@ -8,6 +8,7 @@
*/
#include <linux/bitfield.h>
+#include <linux/clk.h>
#include <linux/device.h>
#include <linux/errno.h>
#include <linux/i3c/master.h>
@@ -969,6 +970,7 @@ static int i3c_hci_init(struct i3c_hci *hci)
static int i3c_hci_probe(struct platform_device *pdev)
{
const struct mipi_i3c_hci_platform_data *pdata = pdev->dev.platform_data;
+ struct clk_bulk_data *clks;
struct i3c_hci *hci;
int irq, ret;
@@ -1001,6 +1003,11 @@ static int i3c_hci_probe(struct platform_device *pdev)
if (!hci->quirks && platform_get_device_id(pdev))
hci->quirks = platform_get_device_id(pdev)->driver_data;
+ ret = devm_clk_bulk_get_all_enabled(&pdev->dev, &clks);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret,
+ "Failed to get clocks\n");
+
ret = i3c_hci_init(hci);
if (ret)
return ret;
@@ -1031,6 +1038,9 @@ static void i3c_hci_remove(struct platform_device *pdev)
static const __maybe_unused struct of_device_id i3c_hci_of_match[] = {
{ .compatible = "mipi-i3c-hci", },
+ { .compatible = "microchip,sama7d65-i3c-hci",
+ .data = (void *)(ulong)(HCI_QUIRK_PIO_MODE | HCI_QUIRK_OD_PP_TIMING |
+ HCI_QUIRK_RESP_BUF_THLD) },
{},
};
MODULE_DEVICE_TABLE(of, i3c_hci_of_match);
--
2.25.1
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: microchip: add I3C controller
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Durai Manickam KR, Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
From: Durai Manickam KR <durai.manickamkr@microchip.com>
Add I3C controller for sama7d65 SoC.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v3:
- Remove clock-names property as the driver acquires and enables
clocks in bulk using devm_clk_bulk_get_all_enabled
arch/arm/boot/dts/microchip/sama7d65.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
index 67253bbc08df..ec200848c153 100644
--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
+++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
@@ -1055,5 +1055,13 @@ gic: interrupt-controller@e8c11000 {
#address-cells = <0>;
interrupt-controller;
};
+
+ i3c: i3c@e9000000 {
+ compatible = "microchip,sama7d65-i3c-hci";
+ reg = <0xe9000000 0x300>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 105>, <&pmc PMC_TYPE_GCK 105>;
+ status = "disabled";
+ };
};
};
--
2.25.1
^ permalink raw reply related
* [PATCH v7 5/5] ARM: configs: at91: sama7: add sama7d65 i3c-hci
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan, Durai Manickam KR
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
Enable the configs needed for I3C framework and microchip
sama7d65 i3c-hci driver.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/configs/sama7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/sama7_defconfig b/arch/arm/configs/sama7_defconfig
index e52f671ccec4..6470c7d3fe8a 100644
--- a/arch/arm/configs/sama7_defconfig
+++ b/arch/arm/configs/sama7_defconfig
@@ -117,6 +117,8 @@ CONFIG_HW_RANDOM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_AT91=y
+CONFIG_I3C=y
+CONFIG_MIPI_I3C_HCI=y
CONFIG_SPI=y
CONFIG_SPI_ATMEL=y
CONFIG_SPI_ATMEL_QUADSPI=y
--
2.25.1
^ permalink raw reply related
* Re: (subset) [PATCH v3 0/5] Initial Apple silicon M3 device trees and dt-bindings
From: Sven Peter @ 2026-05-25 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Neal Gompa, Wim Van Sebroeck, Guenter Roeck, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, Janne Grunau
Cc: Sven Peter, devicetree, linux-kernel, asahi, linux-arm-kernel,
linux-watchdog, linux-pwm, Joshua Peisach, Michael Reeves
In-Reply-To: <20260507-apple-m3-initial-devicetrees-v3-0-ca07c81b5dc7@jannau.net>
On Thu, 07 May 2026 09:33:06 +0200, Janne Grunau wrote:
> Hej,
>
> This series adds initial device trees for M3 Apple silicon devices. The
> device trees contain only a minimal set of hardware not going much
> beyond the minimum required for booting kernel and initramfs and
> verify via serial console that the hardware and drivers work.
> The hardware with the exception of the interrupt controller is
> compatible with the M1 and M2 SoCs and the existing drivers.
> `make dtbs_check` depends on the already applied and dropped apple,i2c
> and apple,pmgr dt-binding changes.
> The watchdog load depends on stalled and forgotten addition of the
> "apple,t8103-wdt" compatible posted in [1]. I've replied to the thread
> to get the change merged.
>
> [...]
Applied to local tree (apple-soc/dt-7.2), thanks!
[1/5] dt-bindings: power: apple,pmgr-pwrstate: Add t8122 compatible
https://github.com/AsahiLinux/linux/commit/4d28a9a428f6
[3/5] dt-bindings: pwm: apple,s5l-fpwm: Add t8122 compatible
https://github.com/AsahiLinux/linux/commit/d0960529afbd
[4/5] dt-bindings: arm: apple: Add M3 based devices
https://github.com/AsahiLinux/linux/commit/5701af106b03
[5/5] arm64: dts: apple: Initial t8122 (M3) device trees
https://github.com/AsahiLinux/linux/commit/1dfa78533534
Best regards,
--
Sven Peter <sven@kernel.org>
^ permalink raw reply
* [PATCH] crypto: atmel-tdes - use min3 to simplify sg_copy and crypt_start
From: Thorsten Blum @ 2026-05-25 9:29 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Replace multiple min() and min_t() calls with min3() to simplify the
code. Using min3() instead of min_t() in atmel_tdes_crypt_start() is
safe since the values are all unsigned and compatible.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-tdes.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
index 643e507f9c02..834c6d3e1b06 100644
--- a/drivers/crypto/atmel-tdes.c
+++ b/drivers/crypto/atmel-tdes.c
@@ -143,8 +143,7 @@ static int atmel_tdes_sg_copy(struct scatterlist **sg, size_t *offset,
size_t count, off = 0;
while (buflen && total) {
- count = min((*sg)->length - *offset, total);
- count = min(count, buflen);
+ count = min3((*sg)->length - *offset, total, buflen);
if (!count)
return off;
@@ -469,8 +468,8 @@ static int atmel_tdes_crypt_start(struct atmel_tdes_dev *dd)
if (fast) {
- count = min_t(size_t, dd->total, sg_dma_len(dd->in_sg));
- count = min_t(size_t, count, sg_dma_len(dd->out_sg));
+ count = min3(sg_dma_len(dd->in_sg), sg_dma_len(dd->out_sg),
+ dd->total);
err = dma_map_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
if (!err) {
^ permalink raw reply related
* Re: [PATCH 3/5] arm64: dts: freescale: imx95-toradex-smarc: move CM7 node to SoC DTSI
From: Laurentiu Mihalcea @ 2026-05-25 9:33 UTC (permalink / raw)
To: Peng Fan
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam, Pengutronix Kernel Team,
linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ahOwvnij7Fwxh3La@shlinux89>
On 5/24/2026 7:15 PM, Peng Fan wrote:
> On Fri, May 22, 2026 at 04:18:47AM -0700, Laurentiu Mihalcea wrote:
>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>
>> The CM7 remoteproc configuration is common to multiple MX95-based
>> platforms (e.g. MX95-19x19-EVK, MX95-15x15-FRDM, SMARC-IMX95, etc.).
>> Therefore, move the node to the MX95 SoC DTSI. While at it, split the mbox
>> channels using <>.
>>
>> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>> ---
>> .../boot/dts/freescale/imx95-toradex-smarc.dtsi | 14 ++++++--------
>> arch/arm64/boot/dts/freescale/imx95.dtsi | 7 +++++++
>> 2 files changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
>> index 7d760470201f..c94a63a3bf8f 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
>> @@ -145,14 +145,6 @@ reg_wifi_en: regulator-wifi-en {
>> startup-delay-us = <2000>;
>> };
>>
>> - remoteproc-cm7 {
>> - compatible = "fsl,imx95-cm7";
>> - mboxes = <&mu7 0 1 &mu7 1 1 &mu7 3 1>;
>> - mbox-names = "tx", "rx", "rxdb";
>> - memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
>> - <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
>> - };
>> -
>> reserved-memory {
>> #address-cells = <2>;
>> #size-cells = <2>;
>> @@ -204,6 +196,12 @@ vdevbuffer: vdevbuffer@88020000 {
>> };
>> };
>>
>> +&cm7 {
>> + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
>> + <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
>> + status = "okay";
>> +};
>> +
>> /* SMARC GBE0 */
>> &enetc_port0 {
>> pinctrl-names = "default";
>> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> index 3e35c956a4d7..f8760ac067fa 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> @@ -272,6 +272,13 @@ opp-1000000000 {
>> };
>> };
>>
>> + cm7: remoteproc-cm7 {
>> + compatible = "fsl,imx95-cm7";
>> + mboxes = <&mu7 0 1>, <&mu7 1 1>, <&mu7 3 1>;
>> + mbox-names = "tx", "rx", "rxdb";
>
> Please not put mboxes and mbox-names in dtsi. Some demos may not
> require them and boards may use different MUs.
>
> Regards
> Peng
>
Not going to insist on this.
Frank Li, are you ok with dropping this patch and handling this at board/SoM level?
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-05-25 9:34 UTC (permalink / raw)
To: Bartosz Golaszewski, Lee Jones
Cc: Sebastian Reichel, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla,
linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Bartosz Golaszewski
In-Reply-To: <CAMRc=MdiwwX_XH7JFW8HuLvYA_ao50fjj0Oip2WMM4QROHRiFA@mail.gmail.com>
On 22-05-2026 14:38, Bartosz Golaszewski wrote:
> On Thu, May 21, 2026 at 6:27 PM Lee Jones <lee@kernel.org> wrote:
>>
>> On Thu, 21 May 2026, Bartosz Golaszewski wrote:
>>
>>> On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
>>>>
>>>>>
>>>>> I suggested it because of its flexibility. The alternative I had in
>>>>> mind is something like a new field in mfd_cell:
>>>>>
>>>>> const char *cell_node_name;
>>>>>
>>>>> Which - if set - would tell MFD to look up an fwnode that's a child of
>>>>> the parent device's node by name - as it may not have a compatible.
>>>>
>>>> Remind me why the chlid device can't look-up its own fwnode?
>>>>
>>>
>>> Oh sure it can, but should it? I'm not sure it's logically sound to
>>> have the child device reach into the parent, look up the fwnode and
>>> then assign it to itself after it's already attached to the driver.
>>> This should be done at the subsystem level before the device is
>>> registered.
>>
>> Leaf drivers reach back into the parent all the time.
>>
>
> But drivers don't generally assign firmware nodes to devices they are
> already bound to. This is racy as in probe() the device is already
> visible to the system. There's no synchronization of device property
> access - properties are assumed to be read-only for a registered
> device.
thanks Bart/Lee. Any pointers to take this from here?
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH RESEND 1/2] stm class: Replace kmalloc + copy_from_user with memdup_user
From: Thorsten Blum @ 2026-05-25 9:36 UTC (permalink / raw)
To: Alexander Shishkin, Maxime Coquelin, Alexandre Torgue
Cc: linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260402165933.895706-4-thorsten.blum@linux.dev>
Gentle ping?
On Thu, Apr 02, 2026 at 06:59:35PM +0200, Thorsten Blum wrote:
> Replace kmalloc() followed by copy_from_user() with memdup_user() to
> simplify and improve stm_char_write().
>
> Allocate and copy only 'count' bytes instead of 'count + 1' since the
> extra byte is unused.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/hwtracing/stm/core.c | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> index 37584e786bb5..49791024bb86 100644
> --- a/drivers/hwtracing/stm/core.c
> +++ b/drivers/hwtracing/stm/core.c
> @@ -645,15 +645,9 @@ static ssize_t stm_char_write(struct file *file, const char __user *buf,
> return err;
> }
>
> - kbuf = kmalloc(count + 1, GFP_KERNEL);
> - if (!kbuf)
> - return -ENOMEM;
> -
> - err = copy_from_user(kbuf, buf, count);
> - if (err) {
> - kfree(kbuf);
> - return -EFAULT;
> - }
> + kbuf = memdup_user(buf, count);
> + if (IS_ERR(kbuf))
> + return PTR_ERR(kbuf);
>
> pm_runtime_get_sync(&stm->dev);
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox