* Re: [PATCH] net: stmmac: fix missed le32_to_cpu()
From: Jakub Kicinski @ 2026-06-25 2:22 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Ben Dooks, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <b375d36c-112e-4662-b538-fd10fa927ecc@bootlin.com>
On Mon, 22 Jun 2026 19:51:39 +0200 Maxime Chevallier wrote:
> Hi Ben,
>
> On 6/22/26 16:37, Ben Dooks wrote:
> > The print in ndesc_display_ring() sends the des2 and des3
> > to the pr_info() without passing them through the relevant
> > conversion to cpu order.
> >
> > Fix the (prototype) sparse warnings by using le32_to_cpu():
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 6 (different base types)
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des2
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 7 (different base types)
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des3
> >
> > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>
> I agree on the principle, but this isn't a fix so this'll have to wait
> until net-next re-opens :)
Humpf, why are we not seeing this on x86 allmodconfig ? 🤔️
$ make C=1 W=1 drivers/net/ethernet/stmicro/stmmac/norm_desc.o
DESCEND objtool
CC [M] drivers/net/ethernet/stmicro/stmmac/norm_desc.o
CHECK drivers/net/ethernet/stmicro/stmmac/norm_desc.c
$
^ permalink raw reply
* RE: [PATCH v6 9/9] arm64: dts: freescale: imx95: Add video codec node
From: Nas Chung @ 2026-06-25 2:11 UTC (permalink / raw)
To: Francesco Dolcini
Cc: mchehab@kernel.org, hverkuil@xs4all.nl, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-imx@nxp.com, linux-arm-kernel@lists.infradead.org,
jackson.lee, lafley.kim, marek.vasut@mailbox.org
In-Reply-To: <20260624115050.GA38214@francesco-nb>
Hi, Francesco.
>-----Original Message-----
>From: Francesco Dolcini <francesco@dolcini.it>
>Sent: Wednesday, June 24, 2026 8:51 PM
>To: Nas Chung <nas.chung@chipsnmedia.com>
>Cc: mchehab@kernel.org; hverkuil@xs4all.nl; robh@kernel.org;
>krzk+dt@kernel.org; conor+dt@kernel.org; shawnguo@kernel.org;
>s.hauer@pengutronix.de; linux-media@vger.kernel.org;
>devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-imx@nxp.com;
>linux-arm-kernel@lists.infradead.org; jackson.lee
><jackson.lee@chipsnmedia.com>; lafley.kim <lafley.kim@chipsnmedia.com>;
>marek.vasut@mailbox.org
>Subject: Re: [PATCH v6 9/9] arm64: dts: freescale: imx95: Add video codec
>node
>
>On Wed, Jun 24, 2026 at 04:20:43PM +0900, Nas Chung wrote:
>> Add the Chips and Media wave633 video codec node on IMX95 SoCs.
>>
>> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
>> ---
>> .../boot/dts/freescale/imx95-19x19-evk.dts | 11 ++++++
>> arch/arm64/boot/dts/freescale/imx95.dtsi | 36 +++++++++++++++++++
>> 2 files changed, 47 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>> index 041fd838fabb..7edd1c69966a 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>> +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>> @@ -76,6 +76,11 @@ linux_cma: linux,cma {
>> linux,cma-default;
>> reusable;
>> };
>> +
>> + vpu_boot: memory@a0000000 {
>> + reg = <0 0xa0000000 0 0x100000>;
>> + no-map;
>> + };
>> };
>>
>> flexcan1_phy: can-phy0 {
>> @@ -1142,3 +1147,9 @@ &tpm6 {
>> pinctrl-0 = <&pinctrl_tpm6>;
>> status = "okay";
>> };
>> +
>> +&vpu {
>> + memory-region = <&vpu_boot>;
>> + sram = <&sram1>;
>
>Can the `sram` node moved to imx95.dtsi or not?
Thanks for your feedback.
Agreed, I'll move the sram property to imx95.dtsi in v7.
Thanks.
Nas.
>
>Francesco
^ permalink raw reply
* Re: [PATCH net v3] net: airoha: fix BQL underflow in shared QDMA TX ring
From: patchwork-bot+netdevbpf @ 2026-06-25 2:00 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, win847,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260620-airoha-bql-fixes-v3-1-76b95374e63e@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 20 Jun 2026 17:04:51 +0200 you wrote:
> When multiple netdevs share a QDMA TX ring and one device is stopped,
> netdev_tx_reset_subqueue() zeroes that device's BQL counters while its
> pending skbs remain in the shared HW TX ring. When NAPI later completes
> those skbs via netdev_tx_completed_queue(), the already-zeroed
> dql->num_queued counter underflows.
>
> Fix the issue:
> - Remove netdev_tx_reset_subqueue() from airoha_dev_stop() so pending
> skbs are completed naturally by NAPI with proper BQL accounting.
> - Rework airoha_qdma_tx_cleanup() to disable TX DMA, flush BQL
> counters, DMA-unmap and free all pending skbs while skb->dev
> references are still valid. Use a per-queue flushing flag checked
> under q->lock in airoha_dev_xmit() to prevent races between teardown
> and transmit. Call airoha_qdma_stop_napi() before
> airoha_qdma_tx_cleanup() at the call sites.
> - Move DMA engine start into probe. Split DMA teardown so TX DMA is
> disabled in airoha_qdma_tx_cleanup() and RX DMA in
> airoha_qdma_cleanup().
> - Remove qdma->users counter since DMA lifetime is now tied to
> probe/cleanup rather than per-netdev open/stop.
>
> [...]
Here is the summary with links:
- [net,v3] net: airoha: fix BQL underflow in shared QDMA TX ring
https://git.kernel.org/netdev/net/c/611709830945
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v3 0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Wu. JackBB (GSM) @ 2026-06-25 1:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260624170917.09967c74@kernel.org>
Hi Jakub,
> On Wed, 24 Jun 2026 18:04:06 +0800 Jack Wu via B4 Relay wrote:
> > T9XX is the PCIe host device driver for MediaTek's
> > t900 modem. The driver uses the WWAN framework
> > infrastructure to create the following control ports
> > and network interfaces for data transactions.
>
> Replying after a long delay and then immediately posting a new version
> of patches is very bad. Don't bother replying and just put the comments
> you had in the changelog of the new posting. Otherwise the discussion
> may get split.
Sorry about the confusion.
I have a question about the preferred workflow: the cover
letter changelog would get quite long if I include detailed
explanations for each sashiko comment we chose not to fix.
Was the concern more about timing? Should we have replied
to the sashiko review promptly when it came in, rather than
waiting until the full v3 was ready?
Thanks for the guidance.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* RE: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Nas Chung @ 2026-06-25 1:43 UTC (permalink / raw)
To: Conor Dooley
Cc: mchehab@kernel.org, hverkuil@xs4all.nl, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-imx@nxp.com, linux-arm-kernel@lists.infradead.org,
jackson.lee, lafley.kim, marek.vasut@mailbox.org
In-Reply-To: <20260624-junkyard-sensuous-fcd43189b593@spud>
Hi, Conor.
>-----Original Message-----
>From: Conor Dooley <conor@kernel.org>
>Sent: Thursday, June 25, 2026 1:42 AM
>To: Nas Chung <nas.chung@chipsnmedia.com>
>Cc: mchehab@kernel.org; hverkuil@xs4all.nl; robh@kernel.org;
>krzk+dt@kernel.org; conor+dt@kernel.org; shawnguo@kernel.org;
>s.hauer@pengutronix.de; linux-media@vger.kernel.org;
>devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-imx@nxp.com;
>linux-arm-kernel@lists.infradead.org; jackson.lee
><jackson.lee@chipsnmedia.com>; lafley.kim <lafley.kim@chipsnmedia.com>;
>marek.vasut@mailbox.org
>Subject: Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec
>device
>
>On Wed, Jun 24, 2026 at 04:20:36PM +0900, Nas Chung wrote:
>> Add documentation for the Chips&Media Wave6 video codec on NXP i.MX SoCs.
>>
>> The hardware contains one control register region and four interface
>> register regions for a shared video processing engine. The control region
>> manages shared resources such as firmware memory, while each interface
>> region has its own MMIO range and interrupt.
>>
>> The control region and each interface region are distinct DMA requesters
>> and can be associated with separate IOMMU stream IDs. Represent the
>> control region as the parent node and the interface register regions as
>> child nodes to describe these resources.
>>
>> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
>> ---
>> .../bindings/media/nxp,imx95-vpu.yaml | 163 ++++++++++++++++++
>> MAINTAINERS | 7 +
>> 2 files changed, 170 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-
>vpu.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> new file mode 100644
>> index 000000000000..9a5ca53e15a3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> @@ -0,0 +1,163 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/nxp,imx95-vpu.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Chips&Media Wave6 Series multi-standard codec IP on NXP i.MX SoCs
>> +
>> +maintainers:
>> + - Nas Chung <nas.chung@chipsnmedia.com>
>> + - Jackson Lee <jackson.lee@chipsnmedia.com>
>> +
>> +description:
>> + The Chips&Media Wave6 codec IP is a multi-standard video
>encoder/decoder.
>> + On NXP i.MX SoCs, the Wave6 codec IP exposes one control register
>region and
>> + four interface register regions for a shared video processing engine.
>> + The parent node describes the control region, which has its own MMIO
>range and
>> + manages shared resources such as firmware memory. The child nodes
>describe the
>> + interface register regions. Each interface region has its own MMIO
>range and
>> + interrupt.
>> + The control region and the interface regions are distinct DMA
>requesters.
>> + The control region and each interface region can be associated with
>separate
>> + IOMMU stream IDs, allowing DMA isolation between them.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - nxp,imx95-vpu
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + items:
>> + - description: VPU core clock
>> + - description: VPU associated block clock
>> +
>> + clock-names:
>> + items:
>> + - const: core
>> + - const: vpublk
>> +
>> + power-domains:
>> + items:
>> + - description: Main VPU power domain
>> + - description: Performance power domain
>> +
>> + power-domain-names:
>> + items:
>> + - const: vpu
>> + - const: perf
>> +
>> + memory-region:
>> + maxItems: 1
>> +
>> + sram:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + phandle to the SRAM node used to store reference data, reducing DMA
>> + memory bandwidth.
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + "#cooling-cells":
>> + const: 2
>> +
>> + "#address-cells":
>> + const: 2
>> +
>> + "#size-cells":
>> + const: 2
>> +
>> + ranges: true
>> +
>> +patternProperties:
>> + "^interface@[0-9a-f]+$":
>
>I have to wonder if this interface business is required at all.
>Why can this not go into the parent, with each region fetchable via
>reg-names, interrupt-names and iommu-names?
Thanks for your feedback.
I did try the flat model, but the blocker is the IOMMU.
The control region and four interface regions are independent DMA requesters
with distinct stream IDs, and each interface can be assigned to a different VM,
driving the video core with its own isolated memory.
If all stream IDs are listed under the parent's iommus, they bind to a
single device and share one domain, so the isolation is lost.
This is the main reason I added the interface nodes.
Thanks.
Nas.
>
>Cheers,
>Conor.
>
>> + type: object
>> + description:
>> + An interface register region within the Chips&Media Wave6 codec IP.
>> + Each region has its own MMIO range and interrupt and can be
>associated
>> + with a separate IOMMU stream ID for DMA isolation.
>> + additionalProperties: false
>> +
>> + properties:
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + required:
>> + - reg
>> + - interrupts
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> + - clock-names
>> + - power-domains
>> + - power-domain-names
>> + - memory-region
>> + - "#address-cells"
>> + - "#size-cells"
>> + - ranges
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/clock/nxp,imx95-clock.h>
>> +
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + video-codec@4c4c0000 {
>> + compatible = "nxp,imx95-vpu";
>> + reg = <0x0 0x4c4c0000 0x0 0x10000>;
>> + clocks = <&scmi_clk 115>,
>> + <&vpu_blk_ctrl IMX95_CLK_VPUBLK_WAVE>;
>> + clock-names = "core", "vpublk";
>> + power-domains = <&scmi_devpd 21>,
>> + <&scmi_perf 10>;
>> + power-domain-names = "vpu", "perf";
>> + memory-region = <&vpu_boot>;
>> + sram = <&sram1>;
>> + iommus = <&smmu 0x32>;
>> + #cooling-cells = <2>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + interface@4c480000 {
>> + reg = <0x0 0x4c480000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x33>;
>> + };
>> +
>> + interface@4c490000 {
>> + reg = <0x0 0x4c490000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x34>;
>> + };
>> +
>> + interface@4c4a0000 {
>> + reg = <0x0 0x4c4a0000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x35>;
>> + };
>> +
>> + interface@4c4b0000 {
>> + reg = <0x0 0x4c4b0000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x36>;
>> + };
>> + };
>> + };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index efbf808063e5..77ea3a1a966b 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -28688,6 +28688,13 @@ S: Maintained
>> F: Documentation/devicetree/bindings/media/cnm,wave521c.yaml
>> F: drivers/media/platform/chips-media/wave5/
>>
>> +WAVE6 VPU CODEC DRIVER
>> +M: Nas Chung <nas.chung@chipsnmedia.com>
>> +M: Jackson Lee <jackson.lee@chipsnmedia.com>
>> +L: linux-media@vger.kernel.org
>> +S: Maintained
>> +F: Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> +
>> WHISKEYCOVE PMIC GPIO DRIVER
>> M: Kuppuswamy Sathyanarayanan
><sathyanarayanan.kuppuswamy@linux.intel.com>
>> L: linux-gpio@vger.kernel.org
>> --
>> 2.31.1
>>
^ permalink raw reply
* Re: [PATCH v8 2/5] thermal: samsung: Add Exynos ACPM TMU driver GS101
From: Alexey Klimov @ 2026-06-25 1:32 UTC (permalink / raw)
To: Tudor Ambarus, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
Alim Akhtar
Cc: jyescas, linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20260603-acpm-tmu-v8-2-0f1810a356e6@linaro.org>
On Wed Jun 3, 2026 at 2:00 PM BST, Tudor Ambarus wrote:
> Add driver for the Thermal Management Unit (TMU) managed via the Alive
> Clock and Power Manager (ACPM), found on Samsung Exynos SoCs such as
> the Google GS101.
>
> The TMU on the GS101 utilizes a hybrid management model shared between
> the Application Processor (AP) and the ACPM firmware. The driver
> maintains direct memory-mapped access to the TMU interrupt pending
> registers to identify thermal events, while delegating functional
> tasks - such as sensor initialization, threshold configuration, and
> temperature acquisition, to the ACPM firmware via the ACPM IPC
> protocol.
[..]
> +++ b/drivers/thermal/samsung/acpm-tmu.c
[...]
> +static struct platform_driver acpm_tmu_driver = {
> + .driver = {
> + .name = "gs-tmu",
Should it be "gs-tmu" still?
https://lore.kernel.org/linux-samsung-soc/56c1bb6d-54e4-4977-bd88-9ce7a6086b1d@linaro.org/
> + .pm = pm_ptr(&acpm_tmu_pm_ops),
> + .of_match_table = acpm_tmu_match,
> + },
> + .probe = acpm_tmu_probe,
> + .remove = acpm_tmu_remove,
> +};
> +module_platform_driver(acpm_tmu_driver);
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH] net: ixp4xx_hss: fix duplicate HDLC netdev allocation
From: patchwork-bot+netdevbpf @ 2026-06-25 1:09 UTC (permalink / raw)
To: Haoxiang Li
Cc: linusw, kaloz, andrew+netdev, davem, edumazet, kuba, pabeni,
huangguangbin2, lipeng321, linux-arm-kernel, netdev, linux-kernel,
stable
In-Reply-To: <20260622043015.643637-1-haoxiang_li2024@163.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 12:30:15 +0800 you wrote:
> ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored
> in ndev, initialized, and registered with register_hdlc_device(). The
> second one is stored in port->netdev and later used by the remove path
> for unregister_hdlc_device() and free_netdev().
>
> This means that the registered netdev is not the same object that is
> unregistered and freed on remove. It also leaks the first allocation if
> the second alloc_hdlcdev() call fails, and the first allocation is not
> checked before ndev is used.
>
> [...]
Here is the summary with links:
- net: ixp4xx_hss: fix duplicate HDLC netdev allocation
https://git.kernel.org/netdev/net/c/db818b0e8af7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2 0/2] airoha: fixes for sched HTB offload support
From: patchwork-bot+netdevbpf @ 2026-06-25 1:08 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, win847,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260619-airoha-qos-fixes-v2-0-5c43485038f9@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 19 Jun 2026 13:37:12 +0200 you wrote:
> ---
> Changes in v2:
> - cosmetics
> - Link to v1: https://lore.kernel.org/r/20260618-airoha-qos-fixes-v1-0-37192652157f@kernel.org
>
> ---
> Lorenzo Bianconi (2):
> net: airoha: Fix off-by-one in airoha_tc_remove_htb_queue()
> net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
>
> [...]
Here is the summary with links:
- [net,v2,1/2] net: airoha: Fix off-by-one in airoha_tc_remove_htb_queue()
https://git.kernel.org/netdev/net/c/bfcce49c4aaa
- [net,v2,2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
https://git.kernel.org/netdev/net/c/788663dd28e4
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-25 1:01 UTC (permalink / raw)
To: Leo Yan, Suzuki K Poulose
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang, linux-arm-msm,
devicetree, linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <20260624151610.GC575984@e132581.arm.com>
On 6/24/2026 11:16 PM, Leo Yan wrote:
> On Wed, Jun 24, 2026 at 11:08:32PM +0800, Jie Gan wrote:
>
> [...]
>
>>> Why does it fail ? power management ? hw broken ? Is it really AMBA or
>>> do you pretend that to be an AMBA device by faking the CID/PID?
>>
>> The CID reads as 0 from the register, which I suspect is a hardware design
>> issue. I have not yet confirmed this with the hardware team. As a
>> workaround, I provided a fake periphid via a DT property to bypass
>> amba_read_periphid.
>>
>>
>> Leo commented in other thread:
>>>> tnoc.c registers both an AMBA driver and a platform driver. Shouldn't >>it
>>>> be registered as a platform device instead?
>>
>> The platform driver is intended for the interconnect TraceNoC device and is
>> not designed to allocate an ATID. The issue is that the TPDM device borrows
>> the ATID from the TraceNoC device, resulting in the ATID always being 0 when
>> associated with an interconnect NoC device.
>>
>> However, I believe it is acceptable to allocate an ATID for the itNoC device
>> and the issue can be fixed with this way.
>
> I think so.
Hi Suzuki/Leo
Which solution do you prefer to address the issue?
The interconnect traceNoC platform driver is intended for the itnoc
device, implying that no TPDM devices are connected to it. So, if I
modify it to allocate an ATID, I think it would be better to rename the
“itnoc” node accordingly? Or it's ok to leave it as-is?
BTW, the traceNoC device definitely is an AMBA device with CID/PID
registers.
Thanks,
Jie
^ permalink raw reply
* [RFC PATCH] wifi: mt76: fail channel switch when TX queues do not drain
From: Pengpeng Hou @ 2026-06-25 0:38 UTC (permalink / raw)
To: Felix Fietkau
Cc: pengpeng, Lorenzo Bianconi, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, linux-wireless,
linux-kernel, linux-arm-kernel, linux-mediatek
__mt76_set_channel() disables the TX worker, schedules pending TX queues,
sets MT76_RESET, and waits for pending TX to drain before changing the PHY
channel state and calling the driver set_channel() callback.
The wait result is ignored. If TX does not drain within the timeout, the
function still publishes the new channel state and asks the driver to
switch channels while old-channel TX may remain pending.
Return -ETIMEDOUT when the drain wait expires. Keep the survey update on
the old channel, then clear MT76_RESET and re-enable the TX worker through
the existing exit path.
This is marked RFC because the existing channel switch path treats the TX
drain wait as best-effort. Maintainer feedback is needed on whether a TX
drain timeout should fail the channel switch for all mt76 devices or
whether the current force-forward behavior is intentional.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 13c4e8abe..37474d64c 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -1033,6 +1033,7 @@ int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
bool offchannel)
{
struct mt76_dev *dev = phy->dev;
+ long time_left;
int timeout = HZ / 5;
int ret;
@@ -1040,8 +1041,13 @@ int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
mt76_txq_schedule_pending(phy);
set_bit(MT76_RESET, &phy->state);
- wait_event_timeout(dev->tx_wait, !mt76_has_tx_pending(phy), timeout);
+ time_left = wait_event_timeout(dev->tx_wait, !mt76_has_tx_pending(phy),
+ timeout);
mt76_update_survey(phy);
+ if (!time_left) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
if (phy->chandef.chan->center_freq != chandef->chan->center_freq ||
phy->chandef.width != chandef->width)
@@ -1059,6 +1065,7 @@ int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
ret = dev->drv->set_channel(phy);
+out:
clear_bit(MT76_RESET, &phy->state);
mt76_worker_enable(&dev->tx_worker);
mt76_worker_schedule(&dev->tx_worker);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [RFC PATCH] mtd: rawnand: mtk: return errors when reset does not idle
From: Pengpeng Hou @ 2026-06-25 0:37 UTC (permalink / raw)
To: Miquel Raynal
Cc: pengpeng, Richard Weinberger, Vignesh Raghavendra,
Matthias Brugger, AngeloGioacchino Del Regno, linux-mtd,
linux-kernel, linux-arm-kernel, linux-mediatek
mtk_nfc_hw_reset() waits for the NFI master to become idle after forcing a
reset, but it only logs a warning when the wait times out. Probe-time
hardware init and later exec_op() calls then continue as if the reset had
completed.
Make the reset helper return the poll error and propagate it through both
initial hardware setup and NAND operation execution. Keep the final reset
writes so status registers affected by the NFI master are still forced
back to the reset state before the error is returned.
This is marked RFC because the existing code only warns about the idle
timeout and then performs the final reset writes. Maintainer feedback is
needed on whether this timeout should be treated as fatal or as a
recoverable reset condition on affected hardware.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mtd/nand/raw/mtk_nand.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/mtk_nand.c b/drivers/mtd/nand/raw/mtk_nand.c
index 21c7e1102..059b8070f 100644
--- a/drivers/mtd/nand/raw/mtk_nand.c
+++ b/drivers/mtd/nand/raw/mtk_nand.c
@@ -255,7 +255,7 @@ static inline u8 nfi_readb(struct mtk_nfc *nfc, u32 reg)
return readb_relaxed(nfc->regs + reg);
}
-static void mtk_nfc_hw_reset(struct mtk_nfc *nfc)
+static int mtk_nfc_hw_reset(struct mtk_nfc *nfc)
{
struct device *dev = nfc->dev;
u32 val;
@@ -269,12 +269,14 @@ static void mtk_nfc_hw_reset(struct mtk_nfc *nfc)
!(val & MASTER_STA_MASK), 50,
MTK_RESET_TIMEOUT);
if (ret)
- dev_warn(dev, "master active in reset [0x%x] = 0x%x\n",
- NFI_MASTER_STA, val);
+ dev_err(dev, "master active in reset [0x%x] = 0x%x\n",
+ NFI_MASTER_STA, val);
/* ensure any status register affected by the NFI master is reset */
nfi_writel(nfc, CON_FIFO_FLUSH | CON_NFI_RST, NFI_CON);
nfi_writew(nfc, STAR_DE, NFI_STRDATA);
+
+ return ret;
}
static int mtk_nfc_send_command(struct mtk_nfc *nfc, u8 command)
@@ -517,7 +519,10 @@ static int mtk_nfc_exec_op(struct nand_chip *chip,
if (check_only)
return 0;
- mtk_nfc_hw_reset(nfc);
+ ret = mtk_nfc_hw_reset(nfc);
+ if (ret)
+ return ret;
+
nfi_writew(nfc, CNFG_OP_CUST, NFI_CNFG);
mtk_nfc_select_target(chip, op->cs);
@@ -1084,8 +1089,10 @@ static int mtk_nfc_read_oob_std(struct nand_chip *chip, int page)
return mtk_nfc_read_page_raw(chip, NULL, 1, page);
}
-static inline void mtk_nfc_hw_init(struct mtk_nfc *nfc)
+static int mtk_nfc_hw_init(struct mtk_nfc *nfc)
{
+ int ret;
+
/*
* CNRNB: nand ready/busy register
* -------------------------------
@@ -1095,10 +1102,14 @@ static inline void mtk_nfc_hw_init(struct mtk_nfc *nfc)
nfi_writew(nfc, 0xf1, NFI_CNRNB);
nfi_writel(nfc, PAGEFMT_8K_16K, NFI_PAGEFMT);
- mtk_nfc_hw_reset(nfc);
+ ret = mtk_nfc_hw_reset(nfc);
+ if (ret)
+ return ret;
nfi_readl(nfc, NFI_INTR_STA);
nfi_writel(nfc, 0, NFI_INTR_EN);
+
+ return 0;
}
static irqreturn_t mtk_nfc_irq(int irq, void *id)
@@ -1411,7 +1422,9 @@ static int mtk_nfc_nand_chip_init(struct device *dev, struct mtk_nfc *nfc,
mtd->name = MTK_NAME;
mtd_set_ooblayout(mtd, &mtk_nfc_ooblayout_ops);
- mtk_nfc_hw_init(nfc);
+ ret = mtk_nfc_hw_init(nfc);
+ if (ret)
+ return ret;
ret = nand_scan(nand, nsels);
if (ret)
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] mmc: mtk-sd: report DMA stop timeouts as data errors
From: Pengpeng Hou @ 2026-06-25 0:35 UTC (permalink / raw)
To: Chaotian Jing
Cc: pengpeng, Ulf Hansson, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mmc, linux-kernel,
linux-arm-kernel, linux-mediatek
msdc_data_xfer_done() stops the DMA engine before completing a data
request, but it only logs failures from the DMA stop and DMA-inactive
polls.
When the interrupt status also carries MSDC_INT_XFER_COMPL, the function
can still report the full data length as transferred even though the DMA
engine did not confirm that it stopped or became inactive.
Treat DMA stop/inactive timeouts as data errors. This reuses the existing
reset/error path and prevents a timed out DMA stop from being reported as a
successful full-length transfer.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mmc/host/mtk-sd.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b2680cc05..e3caa9c32 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1583,7 +1583,7 @@ static void msdc_data_xfer_done(struct msdc_host *host, u32 events,
| MSDC_INT_DMA_BDCSERR | MSDC_INT_DMA_GPDCSERR
| MSDC_INT_DMA_PROTECT);
u32 val;
- int ret;
+ int dma_err = 0, ret;
spin_lock_irqsave(&host->lock, flags);
done = !host->data;
@@ -1603,18 +1603,23 @@ static void msdc_data_xfer_done(struct msdc_host *host, u32 events,
ret = readl_poll_timeout_atomic(host->base + MSDC_DMA_CTRL, val,
!(val & MSDC_DMA_CTRL_STOP), 1, 20000);
- if (ret)
+ if (ret) {
dev_dbg(host->dev, "DMA stop timed out\n");
+ dma_err = ret;
+ }
ret = readl_poll_timeout_atomic(host->base + MSDC_DMA_CFG, val,
!(val & MSDC_DMA_CFG_STS), 1, 20000);
- if (ret)
+ if (ret) {
dev_dbg(host->dev, "DMA inactive timed out\n");
+ dma_err = ret;
+ }
sdr_clr_bits(host->base + MSDC_INTEN, data_ints_mask);
dev_dbg(host->dev, "DMA stop\n");
- if ((events & MSDC_INT_XFER_COMPL) && (!stop || !stop->error)) {
+ if (!dma_err && (events & MSDC_INT_XFER_COMPL) &&
+ (!stop || !stop->error)) {
data->bytes_xfered = data->blocks * data->blksz;
} else {
dev_dbg(host->dev, "interrupt events: %x\n", events);
@@ -1622,7 +1627,9 @@ static void msdc_data_xfer_done(struct msdc_host *host, u32 events,
host->error |= REQ_DAT_ERR;
data->bytes_xfered = 0;
- if (events & MSDC_INT_DATTMO)
+ if (dma_err)
+ data->error = -ETIMEDOUT;
+ else if (events & MSDC_INT_DATTMO)
data->error = -ETIMEDOUT;
else if (events & MSDC_INT_DATCRCERR)
data->error = -EILSEQ;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] bus: sunxi-rsb: fail hardware init on soft-reset timeout
From: Pengpeng Hou @ 2026-06-25 0:34 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: pengpeng, Jernej Skrabec, Samuel Holland, Philipp Zabel,
linux-arm-kernel, linux-sunxi, linux-kernel
sunxi_rsb_hw_init() issues a controller soft reset and waits for the reset
bit to clear, but it ignores readl_poll_timeout()'s return value.
If the controller never leaves reset, probe can continue to publish child
devices and system resume can report success without a usable RSB
controller.
Return the timeout error, assert reset again, and disable the clock before
leaving the hardware-init path.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/bus/sunxi-rsb.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index daf0ea563..f83224dea 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -669,8 +669,12 @@ static int sunxi_rsb_hw_init(struct sunxi_rsb *rsb)
/* reset the controller */
writel(RSB_CTRL_SOFT_RST, rsb->regs + RSB_CTRL);
- readl_poll_timeout(rsb->regs + RSB_CTRL, reg,
- !(reg & RSB_CTRL_SOFT_RST), 1000, 100000);
+ ret = readl_poll_timeout(rsb->regs + RSB_CTRL, reg,
+ !(reg & RSB_CTRL_SOFT_RST), 1000, 100000);
+ if (ret) {
+ dev_err(dev, "soft reset timed out\n");
+ goto err_reset_assert;
+ }
/*
* Clock frequency and delay calculation code is from
@@ -696,6 +700,8 @@ static int sunxi_rsb_hw_init(struct sunxi_rsb *rsb)
return 0;
+err_reset_assert:
+ reset_control_assert(rsb->rstc);
err_clk_disable:
clk_disable_unprepare(rsb->clk);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout
From: Pengpeng Hou @ 2026-06-25 0:33 UTC (permalink / raw)
To: Miquel Raynal
Cc: pengpeng, Richard Weinberger, Vignesh Raghavendra,
Vladimir Zapolskiy, Piotr Wojtaszczyk, linux-mtd,
linux-arm-kernel, linux-kernel
lpc32xx_xmit_dma() starts a DMA transfer and waits up to one second for
its completion, but it ignores the wait result and returns success after
unmapping the buffer.
A timed out read can therefore return success with incomplete data, and a
timed out write can continue the NAND operation without proof that the DMA
payload reached the controller.
Terminate the DMA channel on timeout, unmap the scatterlist through the
existing cleanup path, and return -ETIMEDOUT to the NAND read/write
callers.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mtd/nand/raw/lpc32xx_mlc.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/lpc32xx_mlc.c b/drivers/mtd/nand/raw/lpc32xx_mlc.c
index 19b13ae53..8f6a89d9b 100644
--- a/drivers/mtd/nand/raw/lpc32xx_mlc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_mlc.c
@@ -396,6 +396,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
struct lpc32xx_nand_host *host = nand_get_controller_data(chip);
struct dma_async_tx_descriptor *desc;
int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+ unsigned long time_left;
int res;
sg_init_one(&host->sgl, mem, len);
@@ -410,6 +411,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
flags);
if (!desc) {
dev_err(mtd->dev.parent, "Failed to prepare slave sg\n");
+ res = -ENXIO;
goto out1;
}
@@ -420,7 +422,13 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
dmaengine_submit(desc);
dma_async_issue_pending(host->dma_chan);
- wait_for_completion_timeout(&host->comp_dma, msecs_to_jiffies(1000));
+ time_left = wait_for_completion_timeout(&host->comp_dma,
+ msecs_to_jiffies(1000));
+ if (!time_left) {
+ dmaengine_terminate_sync(host->dma_chan);
+ res = -ETIMEDOUT;
+ goto out1;
+ }
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
@@ -428,7 +436,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
out1:
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
- return -ENXIO;
+ return res;
}
static int lpc32xx_read_page(struct nand_chip *chip, uint8_t *buf,
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] media: mediatek: jpeg: retry HW selection after successful wait
From: Pengpeng Hou @ 2026-06-25 0:31 UTC (permalink / raw)
To: Bin Liu
Cc: pengpeng, Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
wait_event_interruptible_timeout() returns a positive value when the
condition becomes true before the timeout expires.
mtk_jpegdec_worker() treats every non-zero return value as a failure and
finishes the mem2mem job with an error. A normal wakeup that indicates
that a decode engine is ready can therefore be handled as if all hardware
remained busy.
Only fail immediately on interrupted waits. Keep the existing retry limit
for real timeouts, and retry hardware selection after a successful wait.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483..391db77a6 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1697,7 +1697,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
ret = wait_event_interruptible_timeout(jpeg->hw_wq,
atomic_read(&jpeg->hw_rdy) > 0,
MTK_JPEG_HW_TIMEOUT_MSEC);
- if (ret != 0 || (i++ > MTK_JPEG_MAX_RETRY_TIME)) {
+ if (ret < 0 || (!ret && i++ > MTK_JPEG_MAX_RETRY_TIME)) {
dev_err(jpeg->dev, "%s : %d, all HW are busy\n",
__func__, __LINE__);
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v3 0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Jakub Kicinski @ 2026-06-25 0:09 UTC (permalink / raw)
To: Jack Wu via B4 Relay
Cc: jackbb_wu, Loic Poulain, Sergey Ryazanov, Johannes Berg,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, linux-doc
In-Reply-To: <20260624-t9xx_driver_v1-v3-0-73ff03f60c48@compal.com>
On Wed, 24 Jun 2026 18:04:06 +0800 Jack Wu via B4 Relay wrote:
> T9XX is the PCIe host device driver for MediaTek's
> t900 modem. The driver uses the WWAN framework
> infrastructure to create the following control ports
> and network interfaces for data transactions.
Replying after a long delay and then immediately posting a new version
of patches is very bad. Don't bother replying and just put the comments
you had in the changelog of the new posting. Otherwise the discussion
may get split.
^ permalink raw reply
* Re: [External Mail] [PATCH v2 1/7] net: wwan: t9xx: Add PCIe core
From: Jakub Kicinski @ 2026-06-24 23:35 UTC (permalink / raw)
To: Wu. JackBB (GSM)
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <b02c0e1e9f0449f2b819197e4329373b@compal.com>
On Wed, 24 Jun 2026 09:15:17 +0000 Wu. JackBB (GSM) wrote:
> ================================================================================================================================================================
> This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
> ================================================================================================================================================================
If you want to do anything upstream you have to get rid of this first.
^ permalink raw reply
* Re: [PATCH 7/7] i2c: nomadik: add support for I2C_XFER_V2 - detailed fault reporting
From: Linus Walleij @ 2026-06-24 22:56 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-7-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> I2C_XFER_V2 is a new API that allows I2C clients to get the detailed
> report in case of transmission failure. Previously, the only information
> returned by I2C bus controller was the error code; there was no way to
> find out how many messages or bytes in a certain message have been sent
> or received until the fault condition occurred.
>
> This commit introduces support of this feature in i2c-nomadik driver.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
I don't fully understand patch 1 but if that is fine, this is fine:
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 6/7] i2c: nomadik: add quirks max_len=2047 and no_zero_len_read
From: Linus Walleij @ 2026-06-24 22:55 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-6-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> In Nomadik I2c controller, register I2C_MCR has 11-bit wide LENGTH
> field. Its maximum value is 2047, so this is the maximum length of a
> single message. It is less than the common maximum I2C message length in
> I2C subsystem (8192), so define a quirk in order to report the
> unsupported message without any attempt to transfer it.
>
> Zero length reading doesn't work properly on this controller, so add
> `I2C_AQ_NO_ZERO_LEN_READ` quirk flag.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
Excellent improvements, almost a Fixes: patch.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/7] i2c: nomadik: change print level for fault messages to debug
From: Linus Walleij @ 2026-06-24 22:54 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-5-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> i2c-nomadik driver prints error message on every faulted message. This
> is not a good practice, because in I2C a fault not always is an error,
> sometimes it is the expected result. For example, scanning bus with
> `i2cdetects` prints over 100 messages in dmesg (two messages per each
> target address).
>
> To avoid excessive prints in the log, change the print level from err to
> debug.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/7] i2c: nomadik: return proper fault codes
From: Linus Walleij @ 2026-06-24 22:53 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-4-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> I2C documentation Documentation/i2c/fault-codes.rst defines fault codes
> for different negative results in I2C transmittion. Previously,
> i2c-nomadik driver didn't implement them properly - it returned
> ETIMEDOUT on most errors and EIO on master arbitration lost.
>
> To comply with the documentation, return the proper fault codes for
> different conditions, namely:
>
> - EAGAIN if arbitration lost
> - EOVERFLOW if message is too long (>2047 bytes)
> - ENXIO if target address is not acknowledged
> - EIO on other errors detected by controller (for example, NACK on data)
> - ETIMEDOUT if driver gets timeout waiting for message completion
> without any fault condition detected by the controller (for example,
> too long message, or SDA/SCL line stuck on 0).
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/7] i2c: nomadik: do not try to retransmit I2C message series on errors
From: Linus Walleij @ 2026-06-24 22:51 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-3-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> i2c-nomadik driver of I2C bus controller in `xfer` callback retransmits
> the whole message series in cause of any fault, and returns fault only
> after third failed attempt. This behavior contradicts with API because
> not only it hides hardware faults, but also re-sends messages, while
> they are not guaranteed to be idempotent.
>
> Remove the triple attempt to send messages in `xfer` callback.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
This originally came from:
commit ebd10e0783d9fb92a147e60902e22c2d3f3ad69d
Author: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Date: Fri May 13 12:30:23 2011 +0200
i2c-nomadik: add code to retry on timeout failure
It is seen that i2c-nomadik controller randomly stops generating the
interrupts leading to a i2c timeout. As a workaround to this problem,
add retries to the on going transfer on failure.
Signed-off-by: Virupax Sadashivpetimath
<virupax.sadashivpetimath@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
At that time the code looked very different:
for (j = 0; j < 3; j++) {
if (status || (dev->result)) {
(...)
break;
}
udelay(I2C_DELAY);
}
if (status == 0)
break;
We would only spin here if both status and dev->result
(the number of sent bytes) was 0. This doesn't seem to be
at all the case anymore!
I suppose it's a bit dubious code, so:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: mm: opaque hardware page-table entry handles
From: Muhammad Usama Anjum @ 2026-06-24 22:39 UTC (permalink / raw)
To: Zi Yan, Andrew Morton, Lorenzo Stoakes, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Ryan Roberts, Anshuman Khandual,
Catalin Marinas, Will Deacon, Samuel Holland
Cc: usama.anjum, linux-mm, linux-arm-kernel, linux-kernel
In-Reply-To: <DJHEF8MWTZSC.3KMTACZH7KWP@nvidia.com>
On 24/06/2026 4:52 pm, Zi Yan wrote:
> On Wed Jun 24, 2026 at 10:09 AM EDT, Usama Anjum wrote:
>> Hi all,
>>
>> This is a direction-check with the wider community before spending time on the
>> development. This picks up the idea that was raised and broadly agreed in the
>> earlier thread (Ryan Roberts, Lorenzo Stoakes, David Hildenbrand) [1].
>>
>> The problem
>> -----------
>> Core MM code reaches page-table entries by raw pointer dereference (pte_t *,
>> pmd_t *, *pud, ...) in places, implicitly assuming a single, uniform
>> representation. Sprinkling getters wouldn't solve the problem entirely. The
>> problem is one level up: the *pointer type* itself is overloaded. At each level
>> there are really three distinct things:
>>
>> 1. a page-table entry value (pte_t, pmd_t, ...)
>> 2. a pointer to an entry value, e.g. a pXX_t on the stack
>> 3. a pointer to a live entry in the hardware page table
>
> This sounds good to me, but can you clarify the situation below?
>
> A live entry means the entry can be accessed by hardware when the code
> is manipulating it?
I think live is wrong world to chose here. Its a mistake on my end. (3) means
the pointer points into real page-table memory and that table is complete,
whether or not it's linked in yet. A withdrawn-but-not-yet-installed table is
still a hardware table and can be represented by hw_pXXp type.
> What type should we use if we are pre-populating
> PTEs in a PMD page before we establish the PMD page as a HW page table?
> In __split_huge_pmd_locked(), we do that. A PMD page is first withdrawn
> and filled with after-split PTEs, pmd_populate() and pte_offset_map()
> are used for this not-yet-HW page table. Later, pmd_populate() is used> to make this page table visible to HW. Should we have two versions of
> pmd_populate() and pte_offset_map()? Since the first pmd_populate()
> would accept pmd_t*, but the second one would accept hw_pmdp, if we are
> pedantic. Of course, we can be flexible here to use pmd_populate()
> accpeting hw_pmdp for both, since the PMD page table we are modifying
> is going to be visible to HW soon. But I think we should have clear
> definitions for where these types are used and document them well.
This is exactly the example that causes the confusion. Following the definition
above, the pmd is on the stack while the PTEs are being prepared, and the PTE
table is complete — so the pmd pointer should be pmd_t * and the PTE table
hw_ptep. I'd keep the two APIs distinct rather than overloading hw_pmdp for
both: that's what enforces the rule that no stack pointer reaches a
table-writing API, and what lets the *_stack path drop the synchronization.
(One thing I still need to chase: there are cases where we convert between pmd
and pte. I need to understand how often that happens — if it's common, a
hw_ptep could get converted into a pmd and bring the confusion back, and if we
have to account for that, definition (3) may need to change.)
>
> You probably can ask LLMs to check these ambiguous/vague uses throughout
> the code base.
>
>>
>> Today (2) and (3) share the same type - pte_t *, pmd_t *, and so on. Nothing
>> distinguishes a pointer into a live table from a pointer to a stack copy.
>>
>> A pointer to an on-stack entry value and a pointer to a live hardware entry have
>> the same type, so the compiler cannot distinguish them. Passing the stack
>> pointer to an arch helper that expects a hardware-entry pointer compiles fine,
>> but is wrong - a bug class the type system makes invisible. It also blocks
>> evolution: an arch helper may need to read beyond the addressed entry (e.g.
>> adjacent or contiguous entries), which only makes sense for a real page-table
>> pointer, not a stack copy.
>>
>> The idea
>> --------
>> Give (3) its own opaque type that cannot be dereferenced:
>>
>> /* opaque handle to a HW page-table entry; not dereferenceable */
>> typedef struct {
>> pte_t *ptr;
>> } hw_ptep;
>>
>> With this:
>>
>> - a stack value can no longer masquerade as a hardware table entry,
>> - a hardware handle can no longer be raw-dereferenced,
>> - cases that genuinely operate on a value can be refactored to pass the value
>> and let the caller, which knows whether it holds a handle or a stack copy,
>> read it once.
>>
>> The overload becomes a compile-time type error instead of a silent runtime bug,
>> and converting the tree forces every such site to be made explicit. This gives
>> us a framework where the architecture can completely virtualize the pgtable if
>> it likes; and the compiler can enforce that higher level code can't accidentally
>> work around it.
>>
>> It is opt-in by architectures and incremental. The generic definition is
>> just an alias, so arches that do not care build unchanged:
>>
>> typedef pte_t *hw_ptep;
>>
>> An arch flips to the strong struct type when it is ready, and only then does
>> it get the stronger checking. This lets the conversion land gradually.
>>
>> Beyond fixing the latent bug class, this abstraction is an enabler for upcoming
>> features that need tighter control over how page tables are accessed and
>> manipulated.
>>
>> Getter flavours
>> ---------------
>> While converting, it is useful to have two accessor flavours at each level:
>>
>> - pXXp_get(hw_ptep) plain C dereference (compiler may optimize)
>> - pXXp_get_once(hw_ptep) single-copy-atomic, not torn, elided or
>> duplicated by the compiler
>>
>> Keeping them distinct simplifies the conversion and avoids re-introducing the
>> class of lockless-read bugs seen on 32-bit.
>>
>> Example conversion
>> ------------------
>> Most of the conversion is mechanical.
>>
>> -static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
>> - pte_t *ptep, pte_t pte, unsigned int nr)
>> +static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
>> + hw_ptep ptep, pte_t pte, unsigned int nr)
>> {
>> page_table_check_ptes_set(mm, addr, ptep, pte, nr);
>> for (;;) {
>> set_pte(ptep, pte);
>> if (--nr == 0)
>> break;
>> - ptep++;
>> + ptep = hw_pte_next(ptep);
>> pte = pte_next_pfn(pte);
>> }
>> }
>>
>> The bulk of work is this kind of rote substitution. The genuine work is the
>> handful of sites that turn out to be operating on a stack copy rather than a
>> live entry - those are exactly the ones the new type forces us to surface and
>> fix.
>>
>> Estimated churn:
>> ----------------
>> Half way through the prototyping converting only PTE and PMD levels:
>> 77 files changed, +1801 / -1425
>> ~57 files reference the new types
>>
>> So the line count will grow once PUD/P4D/PGD and the remaining call sites are
>> converted; expect meaningfully more churn than the numbers above.
>>
>> Introduce the type as an alias, convert one helper family per patch, and flip
>> an arch to the strong type last - with non-opted arches building unchanged at
>> every step.
>>
>> Open questions
>> --------------
>> - Is the type-safety + future-feature enablement worth the churn?
>> - Naming: hw_ptep/hw_pmdp vs something else?
>> - Should all five levels be converted before merging anything, or is a staged
>> PTE-and-PMD then landing others acceptable?
>> - Do we want the two getter flavours (pXXp_get / pXXp_get_once) at every
>> level?
>>
>> [1] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com
>>
>> Thanks,
>> Usama
>
>
>
>
--
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH 2/7] i2c: nomadik: optimize layout of struct nmk_i2c_dev
From: Linus Walleij @ 2026-06-24 22:36 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-2-6db1a8aabf18@mobileye.com>
Hi Dmitry,
thanks for your patch!
Also nice to see some kernel contributions directly from
MobilEye!
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> Put two bool variables `xfer_done` and `has_32b_bus` and two char
> variables `tft` and `rft` together in order to reduce struct size
> wasted for padding.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
(...)
> struct nmk_i2c_dev {
> struct i2c_vendor_data *vendor;
> @@ -206,13 +206,13 @@ struct nmk_i2c_dev {
> u32 clk_freq;
> unsigned char tft;
> unsigned char rft;
^
Maybe you want to take the opportunity to change these
two into u8 if you're anyway changing the layout of this
struct?
Either way:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] arm64: tlbflush: Reset active_cpu on ASID rollover
From: Sayali Kulkarni @ 2026-06-24 22:13 UTC (permalink / raw)
To: Linu Cherian
Cc: catalin.marinas, linux-arm-kernel, linux-kernel, will,
ryan.roberts, yang, cl, sskulkarni
In-Reply-To: <ajQM4bkKfWdPowpM@a079125.arm.com>
[-- Attachment #1: Type: text/plain, Size: 3653 bytes --]
Thank you for catching this. After going through the patch again, I
realize that the race is real. Resetting active_cpu to ACTIVE_CPU_NONE on
rollover can leave it in an inconsistent state when stale entries still
live. Note that the rollover state entries themselves aren’t the issue.
Those are handled by the existing reserved_asids/tlb_flush_pending
mechanism. It’s specifically active_cpu’s own record going inconsistent.
For v3, I am exploring handling active_cpu together with the generation so
that the reset can’t open a NONE window. Doing it in the slow path after
local flush and updating to the current CPU rather than NONE. Does that
direction seem reasonable or is there a cleaner way to avoid the
under-claim window? Will follow up with a patch once it’s figured out.
Thanks,
Sayali
On Thu, 18 Jun 2026, Linu Cherian wrote:
> Hi,
>
> On Fri, Jun 12, 2026 at 04:21:06PM -0700, Sayali Kulkarni wrote:
>> From: Sayali Kulkarni <sskulkarni@amperecomputing.com>
>>
>> Hi Catalin,
>>
>> Thank you for the review. I’ve addressed your feedback in v2:
>>
>> - Moved `WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE)` from `check_and_switch_context()` to `new_context()` after the `set_asid` label. At this point, a brand new ASID has been allocated that no CPU has ever used, so the reset is safe even for multi-threaded processes where other CPUs may still be running with the old ASID via `reserved_asids`.
>> - Updated the commit message to correct the safety reasoning: `flush_context()` only sets `tlb_flush_pending`; it does not issue a global TLB flush.
>>
>> Thanks,
>> Sayali
>>
>>
>> Once active_cpu flips to ACTIVE_CPU_MULTIPLE it never resets, even if
>> the process settles back to one CPU. Reset it to ACTIVE_CPU_NONE in
>> new_context() after a new ASID is allocated at the set_asid label.
>>
>> At this point a brand new ASID has been assigned that no CPU has ever
>> used, so ACTIVE_CPU_NONE accurately reflects reality. Any other threads
>> of the same process continue running with the old ASID via
>> reserved_asids and are unaffected.
>>
>> This gives processes a fresh chance at the local-only flush fast path
>> after each ASID generation rollover.
>>
>> Signed-off-by: Sayali Kulkarni <sskulkarni@amperecomputing.com> (Ampere)
>> ---
>> arch/arm64/mm/context.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
>> index f34ed78393e0..46c7fd07b9bf 100644
>> --- a/arch/arm64/mm/context.c
>> +++ b/arch/arm64/mm/context.c
>> @@ -209,6 +209,7 @@ static u64 new_context(struct mm_struct *mm)
>> set_asid:
>> __set_bit(asid, asid_map);
>> cur_idx = asid;
>> + WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE);
>
> Can the above store race with the store to active_cpu in another thread,
> that updates it to ACTIVE_CPU_MULTIPLE ?
>
> Lets say we have two threads both initially running in CPU 0,
>
> Thread 1: Runs in CPU 0
>
> Encounters a rollover, updates mm->context.active_cpu to ACTIVE_CPU_NONE and
> updates mm->context.id to new asid.
>
> Thread 2: Scheduled to run on CPU 1 for the first time
>
> Observes the updated mm->context.id that belongs to the current
> generation(after the rollover) and hence proceeds to switch_mm_fastpath
> and ends up updating the active_cpu to ACTIVE_CPU_MULTIPLE.
>
> If Thread 1 and Thread 2 races, then active_cpu can get corrupted ?
>
> The reason this could be possible is that, write to active_cpu and
> mm->context.id can get reordered and we need to enforce ordering for
> correctness ?
>
> Do you see this as a valid scenario ?
>
> --
> Thanks,
> Linu Cherian.
>
>
>
>
>
>
>
>
>
>
^ 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