* [PATCH] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Hongling Zeng @ 2026-06-16 3:31 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng
When terminating a non-cyclic DMA transfer, the active descriptor
is not properly reclaimed. The descriptor is removed from the
desc_issued list in sun6i_dma_start_desc(), but in
sun6i_dma_terminate_all(), only cyclic transfer descriptors are
added to the desc_completed list before cleanup.
For non-cyclic transfers, pchan->desc is set to NULL without first
adding the descriptor back to a list that vchan_get_all_descriptors()
can collect. This causes the descriptor and its associated LLI chain
to be permanently leaked.
Fix by ensuring both cyclic and non-cyclic active descriptors are
added to the desc_completed list before setting pchan->desc to NULL.
Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
drivers/dma/sun6i-dma.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 7a79f346250a..97730ba6c874 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -946,16 +946,14 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
spin_lock_irqsave(&vchan->vc.lock, flags);
- if (vchan->cyclic) {
- vchan->cyclic = false;
- if (pchan && pchan->desc) {
- struct virt_dma_desc *vd = &pchan->desc->vd;
- struct virt_dma_chan *vc = &vchan->vc;
+ if (pchan && pchan->desc) {
+ struct virt_dma_desc *vd = &pchan->desc->vd;
+ struct virt_dma_chan *vc = &vchan->vc;
- list_add_tail(&vd->node, &vc->desc_completed);
- }
+ list_add_tail(&vd->node, &vc->desc_completed);
}
+ vchan->cyclic = false;
vchan_get_all_descriptors(&vchan->vc, &head);
if (pchan) {
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] pinctrl: aspeed: Split TRST out of the AST2700 SoC1 JTAGM1 group
From: Billy Tsai @ 2026-06-16 3:30 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: linux-aspeed, openbmc, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel, Billy Tsai
In-Reply-To: <20260616-pinctrl-fix-v1-0-621036e45c7c@aspeedtech.com>
The JTAGM1 group includes the D12 ball carrying the TRST signal, but
TRST is optional for a JTAG master and the ball may be needed for other
functions on designs that do not wire it. With TRST embedded in the
group, such designs cannot use the JTAG master at all.
Move D12 into a new JTAGM1TRST group under the same JTAGM1 function so
TRST is muxed only when a board requests it. Boards that do use TRST
now need to select both the JTAGM1 and JTAGM1TRST groups.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c
index 50027d69c342..f8b4066699ce 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c
@@ -1018,7 +1018,8 @@ PIN_GROUP(I3C6, AA22, AB20);
PIN_GROUP(I3C7, AF18, AE19);
PIN_GROUP(I3C8, AD20, AC20);
PIN_GROUP(I3C9, AA21, AB21);
-PIN_GROUP(JTAGM1, D12, F10, E11, F11, F13);
+PIN_GROUP(JTAGM1, F10, E11, F11, F13);
+PIN_GROUP(JTAGM1TRST, D12);
PIN_GROUP(LPC0, AF26, AF25, B16, D14, B15, B14, C17, B13, E14, C15);
PIN_GROUP(LPC1, C16, C14, C11, D9, F14, D10, C12, C13, AE16, AE17);
PIN_GROUP(LTPI, U25, U26, Y26, AA24);
@@ -1263,6 +1264,7 @@ static const struct pingroup aspeed_g7_soc1_groups[] = {
GROUP(I3C8),
GROUP(I3C9),
GROUP(JTAGM1),
+ GROUP(JTAGM1TRST),
GROUP(LPC0),
GROUP(LPC1),
GROUP(LTPI),
@@ -1528,7 +1530,7 @@ static const struct aspeed_g7_soc1_function aspeed_g7_soc1_functions[] = {
FUNC(I3C7, (1), "I3C7"),
FUNC(I3C8, (1), "I3C8"),
FUNC(I3C9, (1), "I3C9"),
- FUNC(JTAGM1, (1), "JTAGM1"),
+ FUNC(JTAGM1, (1, 1), "JTAGM1", "JTAGM1TRST"),
FUNC(LPC0, (2), "LPC0"),
FUNC(LPC1, (2), "LPC1"),
FUNC(LTPI, (2), "LTPI"),
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: pinctrl: aspeed,ast2700-soc1: Add JTAGM1TRST group
From: Billy Tsai @ 2026-06-16 3:30 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: linux-aspeed, openbmc, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel, Billy Tsai
In-Reply-To: <20260616-pinctrl-fix-v1-0-621036e45c7c@aspeedtech.com>
The TRST signal of the JTAG master is optional and may not be wired on
every design, but it is only selectable as part of the JTAGM1 group,
which forces the D12 ball to be muxed whenever the JTAG master is used.
Add a separate JTAGM1TRST group so boards can enable TRST independently
of the other JTAG master signals.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
index 76944fd14e2c..fe7cef4fef6a 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
@@ -356,6 +356,7 @@ patternProperties:
- I3C8
- I3C9
- JTAGM1
+ - JTAGM1TRST
- LPC0
- LPC1
- LTPI
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] pinctrl: aspeed: Make AST2700 SoC1 JTAG master TRST optional
From: Billy Tsai @ 2026-06-16 3:30 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: linux-aspeed, openbmc, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel, Billy Tsai
The JTAGM1 pin group of the AST2700 SoC1 includes ball D12, which
carries the TRST signal. TRST is an optional signal for a JTAG master:
designs that do not wire it may need the D12 ball for other functions,
but with TRST embedded in the group they cannot use the JTAG master at
all.
Split D12 into a new JTAGM1TRST group under the existing JTAGM1
function, so TRST is only muxed when a board explicitly requests it.
Patch 1 adds the new group to the device tree binding and patch 2
splits the group in the driver.
Note that this changes the meaning of the existing JTAGM1 group: boards
that do use TRST now need to select both the JTAGM1 and JTAGM1TRST
groups.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
Billy Tsai (2):
dt-bindings: pinctrl: aspeed,ast2700-soc1: Add JTAGM1TRST group
pinctrl: aspeed: Split TRST out of the AST2700 SoC1 JTAGM1 group
.../devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml | 1 +
drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c | 6 ++++--
2 files changed, 5 insertions(+), 2 deletions(-)
---
base-commit: 761af93c9f1a100b8d9f71aa744b8f9abbbbbfb2
change-id: 20260612-pinctrl-fix-1c1e7c37261c
Best regards,
--
Billy Tsai <billy_tsai@aspeedtech.com>
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Xianwei Zhao @ 2026-06-16 2:54 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <542ec217-1187-4fb2-8fd3-b90a6143b84d@kernel.org>
Hi Krzysztof,
Thanks for your detailed review. After considering the feedback, I
think this approach is not suitable, so I will drop this patch.
On 2026/6/15 13:32, Krzysztof Kozlowski wrote:
> On 15/06/2026 04:47, Xianwei Zhao wrote:
>> Hi Conor,
>> Thanks for your review.
>>
>> On 2026/6/12 01:39, Conor Dooley wrote:
>>> Subject:
>>> Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio
>>> irq property
>>> From:
>>> Conor Dooley<conor@kernel.org>
>>> Date:
>>> 2026/6/12 01:39
>>>
>>> To:
>>> xianwei.zhao@amlogic.com
>>> CC:
>>> Linus Walleij<linusw@kernel.org>, Rob Herring<robh@kernel.org>,
>>> Krzysztof Kozlowski<krzk+dt@kernel.org>, Conor Dooley
>>> <conor+dt@kernel.org>, Neil Armstrong<neil.armstrong@linaro.org>, Kevin
>>> Hilman<khilman@baylibre.com>, Jerome Brunet<jbrunet@baylibre.com>,
>>> Martin Blumenstingl<martin.blumenstingl@googlemail.com>,
>>> linux-amlogic@lists.infradead.org,linux-gpio@vger.kernel.org,
>>> devicetree@vger.kernel.org,linux-kernel@vger.kernel.org,
>>> linux-arm-kernel@lists.infradead.org
>>>
>>>
>>>
>>> On Thu, Jun 11, 2026 at 07:54:33AM +0000, Xianwei Zhao via B4 Relay wrote:
>>>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>>>
>>>> Add the hw-irq property for each GPIO bank and enable interrupt-parent
>>>> for pinctrl so that gpiod_to_irq() can translate GPIO lines to IRQs.
>>> Uhhhhh, what? Why can't you just use the normal interrupts property?
>>>
>> The interrupt cannot be used directly because the GPIO bank only
>> provides an IRQ base, which does not have a one-to-one mapping with the
>> actual hardware interrupts.
>>
>> On Amlogic SoCs, GPIO interrupts are handled through a mux. Multiple
>> GPIO pins are mapped to a limited number of real interrupt sources. The
>> implementation can be found here:
>>
>> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
>>
>> To use a GPIO interrupt, an unused hardware interrupt must first be
>> allocated, and then the corresponding mux register must be configured.
>> This allocation and mapping are already implemented in the existing driver.
>>
>> In that driver, the mapping is performed dynamically rather than simply
>> calculating:
>>
>> irq = irq_start + gpio_offset
>>
>> If the interrupt is used directly, only the GPIO index can be obtained.
>
> If it is performed dynamically, then it is not suitable for DT.
>
> You still did not explain what hardware aspect exactly is described by
> "hw-irq".
>
>
>
>> The real interrupt number cannot be derived by simply adding an offset,
>> because the hardware interrupt must be allocated first. Pre-allocating
>> all interrupts during initialization would prevent later GPIOs from
>> obtaining available interrupt sources.
>>
>> Perhaps other names would be more appropriate here, such as "irq_start".
>>
>>>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>>> ---
> Best regards,
> Krzysztof
^ permalink raw reply
* RE: [PATCH v6 1/3] dt-bindings: imx6q-pcie: Add optional intr/aer/pme interrupts for i.MX95
From: Hongxing Zhu @ 2026-06-16 2:56 UTC (permalink / raw)
To: Rob Herring, Hongxing Zhu (OSS)
Cc: krzk+dt@kernel.org, conor+dt@kernel.org, bhelgaas@google.com,
Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20260612151348.GA1040341-robh@kernel.org>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Friday, June 12, 2026 11:14 PM
> To: Hongxing Zhu (OSS) <hongxing.zhu@oss.nxp.com>
> Cc: krzk+dt@kernel.org; conor+dt@kernel.org; bhelgaas@google.com; Frank Li
> <frank.li@nxp.com>; l.stach@pengutronix.de; lpieralisi@kernel.org;
> kwilczynski@kernel.org; mani@kernel.org; s.hauer@pengutronix.de;
> kernel@pengutronix.de; festevam@gmail.com; linux-pci@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; Hongxing Zhu
> <hongxing.zhu@nxp.com>
> Subject: Re: [PATCH v6 1/3] dt-bindings: imx6q-pcie: Add optional intr/aer/pme
> interrupts for i.MX95
>
> On Wed, Jun 03, 2026 at 02:25:08PM +0800, hongxing.zhu@oss.nxp.com wrote:
> > From: Richard Zhu <hongxing.zhu@nxp.com>
> >
> > The i.MX95 PCIe controller introduces three additional dedicated
> > hardware interrupt lines for specific events:
> > - intr: general controller events
> > - aer: Advanced Error Reporting events
> > - pme: Power Management Events
> >
> > These interrupts are optional on i.MX95. PCIe basic functionality
> > (enumeration, configuration, and data transfer) works correctly
> > without them, as the controller can operate using only the existing msi
> interrupt.
> >
> > Earlier i.MX PCIe variants (imx6q, imx6sx, imx6qp, imx7d, imx8mm,
> > imx8mp, imx8mq, imx8q) do not have these three dedicated interrupt lines.
> >
> > Update the binding to allow up to 5 interrupts for i.MX95, while
> > restricting earlier variants to a maximum of 2 interrupts using
> > conditional constraints (if/then schema). This ensures the schema
> > accurately reflects the hardware capabilities of each SoC variant.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > ---
> > .../bindings/pci/fsl,imx6q-pcie.yaml | 29 +++++++++++++++++++
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index e8b8131f5f23..9b5d4e59dfff 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -58,12 +58,18 @@ properties:
> > items:
> > - description: builtin MSI controller.
> > - description: builtin DMA controller.
> > + - description: PCIe event interrupt.
> > + - description: builtin AER SPI standalone interrupt line.
> > + - description: builtin PME SPI standalone interrupt line.
> >
> > interrupt-names:
> > minItems: 1
> > items:
> > - const: msi
> > - const: dma
> > + - const: intr
> > + - const: aer
> > + - const: pme
> >
> > reset-gpio:
> > deprecated: true
> > @@ -248,6 +254,29 @@ allOf:
> > - const: pcie_aux
> > - const: ref
> > - const: extref # Optional
> > + interrupts:
> > + maxItems: 5
> > + interrupt-names:
> > + maxItems: 5
>
> 5 is already the max.
Thank you for the review.
You're correct. These maxItems constraints are redundant and will be removed
later.
Best Regards
Richard Zhu
>
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + enum:
> > + - fsl,imx6q-pcie
> > + - fsl,imx6sx-pcie
> > + - fsl,imx6qp-pcie
> > + - fsl,imx7d-pcie
> > + - fsl,imx8mm-pcie
> > + - fsl,imx8mp-pcie
> > + - fsl,imx8mq-pcie
> > + - fsl,imx8q-pcie
> > + then:
> > + properties:
> > + interrupts:
> > + maxItems: 2
> > + interrupt-names:
> > + maxItems: 2
> >
> > unevaluatedProperties: false
> >
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Xianwei Zhao @ 2026-06-16 2:56 UTC (permalink / raw)
To: Conor Dooley
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260615-ultra-pagan-84de490070e1@spud>
Hi Conor,
Thanks for your detailed review. I will drop this patch.
On 2026/6/16 00:52, Conor Dooley wrote:
> Subject:
> Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio
> irq property
> From:
> Conor Dooley <conor@kernel.org>
> Date:
> 2026/6/16 00:52
>
> To:
> xianwei.zhao@amlogic.com
> CC:
> Linus Walleij <linusw@kernel.org>, Rob Herring <robh@kernel.org>,
> Krzysztof Kozlowski <krzk+dt@kernel.org>, Conor Dooley
> <conor+dt@kernel.org>, Neil Armstrong <neil.armstrong@linaro.org>, Kevin
> Hilman <khilman@baylibre.com>, Jerome Brunet <jbrunet@baylibre.com>,
> Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
> linux-amlogic@lists.infradead.org, linux-gpio@vger.kernel.org,
> devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org
>
>
> Given Linus' comments on the cover letter,
> pw-bot: changes-requested
>
> Thanks,
> Conor.
^ permalink raw reply
* Re: [PATCH 4/6] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Kemeng Shi @ 2026-06-16 1:48 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87h5n489dr.wl-maz@kernel.org>
在 2026/6/15 17:01:52, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:08 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> We have a lot of logs containing ITS address info which is helpful to
>> distiguish which ITS occurs error. Just add ITS address info into more
>> exsiting error logs.
>
> That's only useful on buggy HW, for people debugging it. I don't think
> that's useful outside of these scenarios, and this hack can live out
> of tree.
>
I agree this is only useful in rare cases, but I believe there
is no lose...
But no insistant on this anyway...
Thanks,
Kemeng
> M.
>
^ permalink raw reply
* Re: [PATCH RFC 0/2] pinctrl: Add support gpiod_to_irq
From: Xianwei Zhao @ 2026-06-16 2:45 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <CAD++jLm9+8RSbBCi-k=8S98XvVJ7taYrK=kuBp3_RqxE_bcxbg@mail.gmail.com>
Hi Linus,
Understood. Thank you for your detailed explanation. I will drop
this patch.
On 2026/6/15 20:59, Linus Walleij wrote:
>>> Hi Xianwei,
>>>
>>> thanks for your patches!
>>>
>>> On Thu, Jun 11, 2026 at 9:54 AM Xianwei Zhao via B4 Relay
>>> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>>>
>>>> Some users need to obtain an IRQ directly from a GPIO descriptor through gpiod_to_irq().
>>>> Add the required DT binding and implementation to support this use case.
>>>> Since this introduces a new DT property, the property is kept optional to
>>>> maintain compatibility with existing SoCs and DTS files.
>>> To me it looks like you have just re-implemented hierarchical
>>> irqs.
>>>
>>> Look into the section "Infrastructure helpers for GPIO irqchips"
>>> in Documentation/driver-api/gpio/driver.rst, especially towards
>>> the end.
>>>
>>> Solve this by using GPIOLIB_IRQCHIP and a custom
>>> child_to_parent_hwirq() callback to translate the GPIO into
>>> an IRQ.
>>>
>>> To just implement gpiod_to_irq() without any irqchip abstraction
>>> is also broken: you can't force all users to just use this way
>>> to get an IRQ it's excessively restricting.
>>>
>>> Add
>>>
>>> interrupt-controller: true
>>>
>>> "#interrupt-cells":
>>> const: 2
>>>
>>> to the pinctrl node as well so that DT users can simply request
>>> the IRQ from the irqchip inside of the pin controller. It will
>>> be hierarchical and lightweight but an irqchip nevertheless.
>>>
>>> The GPIOLIB_IRQCHIP approach will help you to get this
>>> right.
>>>
>> I read the document (Documentation/driver-api/gpio/driver.rst) you
>> pointed me to and found that the corresponding implementation has
>> already been added in this file:
>>
>> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
> That is the parent interrupt controller to the pinctrl+gpio isn't it.
>
> It will be even clearer once you use interrupts = <>; instead of
> the hwirq = <>; hack.
>
>> However, it is implemented as a standalone irqchip and is not integrated
>> with the GPIO controller.
> Right, so it is the parent. Of course it it stand alone.
>
>> In this patch, I implemented the GPIO-to-IRQ conversion through
>> gpiod_to_irq(). Users can still obtain the interrupt directly through
>> the interrupt property, for example:
>>
>> interrupts-extended = <&gpio_intc 16 1>;
>>
>> The purpose of this change is to make GPIO-to-IRQ conversion easier for
>> users who do not want to know the actual interrupt number. The interrupt
>> mapping is not fixed and varies between different SoCs, so users should
>> not need to handle the hardware interrupt allocation details.
> This is not why gpiod_to_irq() exists. It is not a convenience function
> that is voluntary to implement.
>
> If you implement gpiod_to_irq() you implement an entire
> irqchip otherwise it is a bug.
>
> If the pin control + GPIO driver should serve IRQ numbers in any
> shape or form, you need to go the whole way and provide a
> hierarchical irqchip.
>
> It doesn't matter if you don't need to set a single bit in the
> pinctrl + GPIO hardware for these IRQs, the fact that they are
> routed internally on the SoC out through the pin control and
> GPIO block by definition makes it hierarchical.
>
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH v3] dmaengine: sun6i-dma: Fix use-after-free in error handling paths
From: Hongling Zeng @ 2026-06-16 2:31 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng
In error handling paths, the for loop frees v_lli in the loop body,
then accesses v_lli->v_lli_next and v_lli->p_lli_next in the
increment expression, which is use-after-free.
Fix by saving both the next virtual and physical pointers before
freeing the current node.
Fixes: 555859308723 ("dmaengine: Add driver for Allwinner sun6i DMA")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
Changes in v2:
-Refactored the fix to avoid code duplication by creating a helper function
sun6i_dma_free_lli_list() that handles LLI list cleanup
-Add Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
Change in v3:
-Further refactoring to move txd handling into the helper function
as suggested by Jernej
---
drivers/dma/sun6i-dma.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index a9a254dbf8cb..7a79f346250a 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -406,16 +406,12 @@ static inline void sun6i_dma_dump_lli(struct sun6i_vchan *vchan,
v_lli->len, v_lli->para, v_lli->p_lli_next);
}
-static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
+static void sun6i_dma_free_desc(struct sun6i_dma_dev *sdev,
+ struct sun6i_desc *txd)
{
- struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
- struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
struct sun6i_dma_lli *v_lli, *v_next;
dma_addr_t p_lli, p_next;
- if (unlikely(!txd))
- return;
-
p_lli = txd->p_lli;
v_lli = txd->v_lli;
@@ -432,6 +428,17 @@ static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
kfree(txd);
}
+static void sun6i_dma_free_desc_virt(struct virt_dma_desc *vd)
+{
+ struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
+ struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
+
+ if (unlikely(!txd))
+ return;
+
+ sun6i_dma_free_desc(sdev, txd);
+}
+
static int sun6i_dma_start_desc(struct sun6i_vchan *vchan)
{
struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vchan->vc.chan.device);
@@ -788,10 +795,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_slave_sg(
return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
err_lli_free:
- for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
- p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
- dma_pool_free(sdev->pool, v_lli, p_lli);
- kfree(txd);
+ sun6i_dma_free_desc(sdev, txd);
return NULL;
}
@@ -869,10 +873,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
err_lli_free:
- for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
- p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
- dma_pool_free(sdev->pool, v_lli, p_lli);
- kfree(txd);
+ sun6i_dma_free_desc(sdev, txd);
return NULL;
}
@@ -1431,7 +1432,7 @@ static int sun6i_dma_probe(struct platform_device *pdev)
struct sun6i_vchan *vchan = &sdc->vchans[i];
INIT_LIST_HEAD(&vchan->node);
- vchan->vc.desc_free = sun6i_dma_free_desc;
+ vchan->vc.desc_free = sun6i_dma_free_desc_virt;
vchan_init(&vchan->vc, &sdc->slave);
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v3 0/8] net: dsa: mt7530: modernise register access and add two DSA ops
From: Jakub Kicinski @ 2026-06-16 2:04 UTC (permalink / raw)
To: Daniel Golle
Cc: Chester A. Unal, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1781500517.git.daniel@makrotopia.org>
On Mon, 15 Jun 2026 06:20:55 +0100 Daniel Golle wrote:
> The mt7530 driver carries its own register accessors that predate the
> regmap conversion and now largely duplicate what regmap already
> provides, including locking. Most of this series removes that layer.
>
> It first moves the MDIO bus locking into the switch regmap via
> .lock/.unlock callbacks, matching the PCS regmaps, so any path reaching
> the regmap is serialised automatically. With the wrappers no longer
> adding locking, the thin mt7530_mii_* indirection is folded away and the
> remaining accessors are replaced mechanically with the plain regmap API,
> using the coccinelle semantic patches included in the commit messages.
> Open-coded register fields are then converted to FIELD_GET/FIELD_PREP.
> None of this is intended to change behaviour.
>
> The last two patches implement .port_fast_age, which flushes dynamically
> learned MAC entries on topology changes, and .port_change_conduit, which
> moves a user port's CPU-port affinity at runtime.
Oh, v3. I guess the kernel.org bot missed it.
Too late to apply this anyway, but also you put the zero init
in the wrong place AFAICT.
--
pw-bot: defer
^ permalink raw reply
* [soc:soc/drivers] BUILD SUCCESS c7437fab2f2249c1f12d805770c5ba15cbd0e46a
From: kernel test robot @ 2026-06-16 2:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/drivers
branch HEAD: c7437fab2f2249c1f12d805770c5ba15cbd0e46a Merge tag 'memory-controller-drv-7.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
elapsed time: 844m
configs tested: 229
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260615 gcc-10.5.0
arc randconfig-001-20260616 gcc-9.5.0
arc randconfig-002-20260615 gcc-16.1.0
arc randconfig-002-20260616 gcc-9.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig clang-23
arm defconfig gcc-16.1.0
arm imx_v4_v5_defconfig clang-23
arm randconfig-001-20260615 gcc-12.5.0
arm randconfig-001-20260616 gcc-9.5.0
arm randconfig-002-20260615 gcc-8.5.0
arm randconfig-002-20260616 gcc-9.5.0
arm randconfig-003-20260615 gcc-16.1.0
arm randconfig-003-20260616 gcc-9.5.0
arm randconfig-004-20260615 clang-23
arm randconfig-004-20260616 gcc-9.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260615 clang-23
arm64 randconfig-001-20260616 gcc-13.4.0
arm64 randconfig-002-20260615 gcc-8.5.0
arm64 randconfig-002-20260616 gcc-13.4.0
arm64 randconfig-003-20260615 clang-16
arm64 randconfig-003-20260616 gcc-13.4.0
arm64 randconfig-004-20260615 clang-23
arm64 randconfig-004-20260616 gcc-13.4.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260615 gcc-16.1.0
csky randconfig-001-20260616 gcc-13.4.0
csky randconfig-002-20260615 gcc-10.5.0
csky randconfig-002-20260616 gcc-13.4.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig clang-23
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260616 clang-23
hexagon randconfig-002-20260616 clang-23
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260616 clang-22
i386 buildonly-randconfig-002-20260616 clang-22
i386 buildonly-randconfig-003-20260616 clang-22
i386 buildonly-randconfig-004-20260616 clang-22
i386 buildonly-randconfig-005-20260616 clang-22
i386 buildonly-randconfig-006-20260616 clang-22
i386 defconfig clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260615 gcc-14
i386 randconfig-001-20260616 gcc-14
i386 randconfig-002-20260615 clang-22
i386 randconfig-002-20260616 gcc-14
i386 randconfig-003-20260615 clang-22
i386 randconfig-003-20260616 gcc-14
i386 randconfig-004-20260615 clang-22
i386 randconfig-004-20260616 gcc-14
i386 randconfig-005-20260615 clang-22
i386 randconfig-005-20260616 gcc-14
i386 randconfig-006-20260615 clang-22
i386 randconfig-006-20260616 gcc-14
i386 randconfig-007-20260615 gcc-14
i386 randconfig-007-20260616 gcc-14
i386 randconfig-011-20260616 clang-22
i386 randconfig-012-20260616 clang-22
i386 randconfig-013-20260616 clang-22
i386 randconfig-014-20260616 clang-22
i386 randconfig-015-20260616 clang-22
i386 randconfig-016-20260616 clang-22
i386 randconfig-017-20260616 clang-22
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260616 clang-23
loongarch randconfig-002-20260616 clang-23
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001-20260616 clang-23
nios2 randconfig-002-20260616 clang-23
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260616 gcc-8.5.0
parisc randconfig-002-20260616 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc ep88xc_defconfig gcc-16.1.0
powerpc pmac32_defconfig clang-23
powerpc randconfig-001-20260616 gcc-8.5.0
powerpc randconfig-002-20260616 gcc-8.5.0
powerpc64 randconfig-001-20260616 gcc-8.5.0
powerpc64 randconfig-002-20260616 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260615 clang-19
riscv randconfig-001-20260616 gcc-16.1.0
riscv randconfig-002-20260615 gcc-16.1.0
riscv randconfig-002-20260616 gcc-16.1.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260615 gcc-11.5.0
s390 randconfig-001-20260616 gcc-16.1.0
s390 randconfig-002-20260615 clang-23
s390 randconfig-002-20260616 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001-20260615 gcc-16.1.0
sh randconfig-001-20260616 gcc-16.1.0
sh randconfig-002-20260615 gcc-10.5.0
sh randconfig-002-20260616 gcc-16.1.0
sh sh7785lcr_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260616 gcc-8.5.0
sparc randconfig-002-20260616 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260616 gcc-8.5.0
sparc64 randconfig-002-20260616 gcc-8.5.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260616 gcc-8.5.0
um randconfig-002-20260616 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260616 gcc-14
x86_64 buildonly-randconfig-002-20260616 gcc-14
x86_64 buildonly-randconfig-003-20260616 gcc-14
x86_64 buildonly-randconfig-004-20260616 gcc-14
x86_64 buildonly-randconfig-005-20260616 gcc-14
x86_64 buildonly-randconfig-006-20260616 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260616 clang-22
x86_64 randconfig-002-20260616 clang-22
x86_64 randconfig-003-20260616 clang-22
x86_64 randconfig-004-20260616 clang-22
x86_64 randconfig-005-20260616 clang-22
x86_64 randconfig-006-20260616 clang-22
x86_64 randconfig-011-20260616 clang-22
x86_64 randconfig-012-20260616 clang-22
x86_64 randconfig-013-20260616 clang-22
x86_64 randconfig-014-20260616 clang-22
x86_64 randconfig-015-20260616 clang-22
x86_64 randconfig-016-20260616 clang-22
x86_64 randconfig-071-20260616 gcc-14
x86_64 randconfig-072-20260616 clang-22
x86_64 randconfig-072-20260616 gcc-14
x86_64 randconfig-073-20260616 gcc-14
x86_64 randconfig-074-20260616 gcc-14
x86_64 randconfig-075-20260616 gcc-12
x86_64 randconfig-075-20260616 gcc-14
x86_64 randconfig-076-20260616 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260616 gcc-8.5.0
xtensa randconfig-002-20260616 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 6/6] irqchip/gic-v3-its: some minor cleanups
From: Kemeng Shi @ 2026-06-16 1:50 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87eci888ss.wl-maz@kernel.org>
在 2026/6/15 17:14:27, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:10 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> 1. Remove unneeded NULL check in itt_alloc_pool() as addr will always be
>> NULL when we reach here.
>> 2. Correct indentation in cpumask_pick_least_loaded()
>> 3. Remove unneeded updation of range node when it is to be deleted in
>> alloc_lpi_range().
>> 4. Remove unneeded assignment to baser->psz which is already used
>> as input inits_setup_baser()
>
> Honestly, these changes, aside from (maybe) the last one, are pretty
> pointless. I'm sure there are better things to waste your time on.
>
No insistant on this. I will drop this in next version.
Thanks,
Kemeng> M.
>
^ permalink raw reply
* Re: [PATCH 5/6] irqchip/gic-v3-its: fix typo in comments
From: Kemeng Shi @ 2026-06-16 1:49 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87fr2o89ak.wl-maz@kernel.org>
在 2026/6/15 17:03:47, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:09 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> 1. "If it some" -> "If some"
>> 2. "by table by reading" -> by reading"
>>
>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index becd8dd51720..fc32a1709f76 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -163,7 +163,7 @@ struct event_lpi_map {
>>
>> /*
>> * The ITS view of a device - belongs to an ITS, owns an interrupt
>> - * translation table, and a list of interrupts. If it some of its
>> + * translation table, and a list of interrupts. If some of its
>> * LPIs are injected into a guest (GICv4), the event_map.vm field
>> * indicates which one.
>> */
>> @@ -2501,7 +2501,7 @@ static bool its_parse_indirect_baser(struct its_node *its,
>> if ((esz << ids) > (psz * 2)) {
>> /*
>> * Find out whether hw supports a single or two-level table by
>> - * table by reading bit at offset '62' after writing '1' to it.
>> + * reading bit at offset '62' after writing '1' to it.
>> */
>
> If you are going to fix that comment, fix it for good by replacing the
> reference to a bit number with its actual name, making it valuable for
> everyone.
Will improve with this in next version.
Thanks,
Kemeng>
> M.
>
>> its_write_baser(its, baser, val | GITS_BASER_INDIRECT);
>> indirect = !!(baser->val & GITS_BASER_INDIRECT);
>> --
>> 2.36.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH 2/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Kemeng Shi @ 2026-06-16 1:39 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87ik7k89i5.wl-maz@kernel.org>
在 2026/6/15 16:59:14, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:06 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> Fix collection leak when its_init_domain() failed in its_probe_one().
>>
>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 2b7b546c43c8..df26ddc97ae2 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -3032,6 +3032,12 @@ static int its_alloc_collections(struct its_node *its)
>> return 0;
>> }
>>
>> +static void its_free_collections(struct its_node *its)
>> +{
>> + kfree(its->collections);
>> + its->collections = NULL;
>> +}
>
> Why do we need an extra helper for something that has a single calling
> spot? Why is it important to set collections to NULL, given that we're
> about to free the structure without even looking further?
>
The extra helper is added for symmetry with its_alloc_collections(), keeping
allocation/deallocation logic paired. In this way, we need to only modified
allocation/deallocation function if more member is added for collections.
Setting collections to NULL is a personal habit to quickly catch use-after-free
of collections. Could drop this which is not that import.
Thanks,
Kemeng
> M.
>
^ permalink raw reply
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Kemeng Shi @ 2026-06-16 1:31 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87jys089sn.wl-maz@kernel.org>
在 2026/6/15 16:52:56, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:05 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor
>
> Typo.
>
>> error handling code to make it a little simpler.
>
> No. Please don't mix fixes and (totally pointless) refactoring.
OK, I will only keep fix in this patch.>
>>
>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------
>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 291d7668cc8d..2b7b546c43c8 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits)
>> static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
>> {
>> unsigned long *bitmap = NULL;
>> - int err = 0;
>>
>> do {
>> - err = alloc_lpi_range(nr_irqs, base);
>> + int err = alloc_lpi_range(nr_irqs, base);
>> if (!err)
>> break;
>>
>> @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
>> } while (nr_irqs > 0);
>>
>> if (!nr_irqs)
>> - err = -ENOSPC;
>> -
>> - if (err)
>> - goto out;
>> + goto err_out;
>>
>> bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC);
>> if (!bitmap)
>> - goto out;
>> + goto err_free_lpi;
>>
>> *nr_ids = nr_irqs;
>> -
>> -out:
>> - if (!bitmap)
>> - *base = *nr_ids = 0;
>> -
>> return bitmap;
>> +
>> +err_free_lpi:
>> + free_lpi_range(*base, nr_irqs);
>> +err_out:
>> + *base = *nr_ids = 0;
>> + return NULL;
>> }
>>
>> static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids)
>
> Honestly, I question the validity of handling errors this way. You are
> already unable to allocate a per-device bitmap. And yet you are
> calling free_lpi_range(), which has the interesting property of
> *allocating* memory. Which you don't have. Oh wait...
You are right. I'm considering use xarray to track the lpi range or
modify free_lpi_range to try merge first before memory allocation.
What would you recommend?
Thanks,
Kemeng Shi>
> M.
>
^ permalink raw reply
* [PATCH v2] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Kunihiko Hayashi @ 2026-06-16 1:12 UTC (permalink / raw)
To: Mark Brown, linux-spi
Cc: linux-arm-kernel, linux-kernel, Kunihiko Hayashi, Sangyun Kim,
Kyungwook Boo, stable, Masami Hiramatsu
The driver calls devm_request_irq() before initializing the completion
used by the interrupt handler. Because the interrupt may occur immediately
after devm_request_irq(), the handler may execute before init_completion().
This may result in calling complete() on an uninitialized completion,
causing undefined behavior. This has been observed with KASAN.
Fix this by initializing the completion before registering the IRQ.
Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC")
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Changes in v2:
- Rebase onto latest, no functional changes
drivers/spi/spi-uniphier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index cc20fd11f03f..86fce9a571da 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -656,6 +656,8 @@ static int uniphier_spi_probe(struct platform_device *pdev)
priv->host = host;
priv->is_save_param = false;
+ init_completion(&priv->xfer_done);
+
priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
@@ -679,8 +681,6 @@ static int uniphier_spi_probe(struct platform_device *pdev)
return ret;
}
- init_completion(&priv->xfer_done);
-
clk_rate = clk_get_rate(priv->clk);
host->max_speed_hz = DIV_ROUND_UP(clk_rate, SSI_MIN_CLK_DIVIDER);
--
2.34.1
^ permalink raw reply related
* [PATCH] firmware: imx: scu: manage mailbox channels and global handle
From: Pengpeng Hou @ 2026-06-16 0:59 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
imx, linux-arm-kernel, linux-kernel
Cc: Pengpeng Hou
imx_scu_probe() requests mailbox channels with the non-managed
mbox_request_channel_byname() helper and then publishes sc_ipc through
the global imx_sc_ipc_handle. Later probe failures, including child
population failure, can leave the channels and global handle live after
the probe has failed.
Register devres actions to free each mailbox channel and clear the global
handle. Also depopulate partially created child devices when
devm_of_platform_populate() reports an error.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/firmware/imx/imx-scu.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index 67b267a7408a..203aac421252 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -82,6 +82,17 @@ static int imx_sc_linux_errmap[IMX_SC_ERR_LAST] = {
static struct imx_sc_ipc *imx_sc_ipc_handle;
+static void imx_scu_free_mbox_chan(void *data)
+{
+ mbox_free_channel(data);
+}
+
+static void imx_scu_clear_handle(void *data)
+{
+ if (imx_sc_ipc_handle == data)
+ imx_sc_ipc_handle = NULL;
+}
+
static inline int imx_sc_to_linux_errno(int errno)
{
if (errno >= IMX_SC_ERR_NONE && errno < IMX_SC_ERR_LAST)
@@ -321,6 +332,11 @@ static int imx_scu_probe(struct platform_device *pdev)
dev_dbg(dev, "request mbox chan %s\n", chan_name);
/* chan_name is not used anymore by framework */
kfree(chan_name);
+
+ ret = devm_add_action_or_reset(dev, imx_scu_free_mbox_chan,
+ sc_chan->ch);
+ if (ret)
+ return ret;
}
sc_ipc->dev = dev;
@@ -330,6 +346,9 @@ static int imx_scu_probe(struct platform_device *pdev)
init_completion(&sc_ipc->done);
imx_sc_ipc_handle = sc_ipc;
+ ret = devm_add_action_or_reset(dev, imx_scu_clear_handle, sc_ipc);
+ if (ret)
+ return ret;
ret = imx_scu_soc_init(dev);
if (ret)
@@ -342,7 +361,11 @@ static int imx_scu_probe(struct platform_device *pdev)
dev_info(dev, "NXP i.MX SCU Initialized\n");
- return devm_of_platform_populate(dev);
+ ret = devm_of_platform_populate(dev);
+ if (ret)
+ of_platform_depopulate(dev);
+
+ return ret;
}
static const struct of_device_id imx_scu_match[] = {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v2 2/3] drm/msm/adreno: Add support for A704 GPU
From: Dmitry Baryshkov @ 2026-06-16 0:56 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bibek Kumar Patro,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
linux-arm-kernel, iommu, Aditya Sherawat, Konrad Dybcio
In-Reply-To: <20260615-shikra-gpu-v2-2-2f2d1347c3fb@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 03:02:58AM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very
> minimal changes. The only KMD facing difference is the chipid and the
> zap firmware which is specified via devicetree.
>
> Just add the new chipid to enable support for A704 GPU in Shikra.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RESEND PATCH v1] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Kunihiko Hayashi @ 2026-06-16 0:55 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-arm-kernel, linux-kernel, Sangyun Kim,
Kyungwook Boo, Masami Hiramatsu
In-Reply-To: <dffb3303-6371-4415-ac0e-488c421e2555@sirena.org.uk>
On 2026/06/15 20:45, Mark Brown wrote:
> On Mon, Jun 15, 2026 at 11:34:15AM +0900, Kunihiko Hayashi wrote:
>> The driver calls devm_request_irq() before initializing the completion
>> used by the interrupt handler. Because the interrupt may occur immediately
>> after devm_request_irq(), the handler may execute before init_completion().
>>
>> This may result in calling complete() on an uninitialized completion,
>> causing undefined behavior. This has been observed with KASAN.
>>
>> Fix this by initializing the completion before registering the IRQ.
>
> I thought you were going to rebase this, why resend the same version?
Sorry for confusion.
The patch was rebased due to upstream changes.
I'll resend it as v2 with a change comment.
Thank you,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* [PATCH] soc: apple: sart: require device link for consumers
From: Pengpeng Hou @ 2026-06-16 0:53 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, asahi, linux-arm-kernel,
linux-kernel
Cc: Pengpeng Hou
devm_apple_sart_get() obtains the supplier platform device and attempts
to create a runtime-PM device link to it, but it ignores device_link_add()
failure. A consumer can then continue without the dependency that keeps
the SART supplier ordered and runtime-PM reachable.
Treat a failed device link as an error and drop the supplier device
reference before returning.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/soc/apple/sart.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/apple/sart.c b/drivers/soc/apple/sart.c
index 9eaf3febb382..66b99955b395 100644
--- a/drivers/soc/apple/sart.c
+++ b/drivers/soc/apple/sart.c
@@ -218,6 +218,7 @@ struct apple_sart *devm_apple_sart_get(struct device *dev)
{
struct device_node *sart_node;
struct platform_device *sart_pdev;
+ struct device_link *link;
struct apple_sart *sart;
sart_node = of_parse_phandle(dev->of_node, "apple,sart", 0);
@@ -236,8 +237,12 @@ struct apple_sart *devm_apple_sart_get(struct device *dev)
return ERR_PTR(-EPROBE_DEFER);
}
- device_link_add(dev, &sart_pdev->dev,
- DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
+ link = device_link_add(dev, &sart_pdev->dev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
+ if (!link) {
+ put_device(&sart_pdev->dev);
+ return ERR_PTR(-ENODEV);
+ }
put_device(&sart_pdev->dev);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] mmc: sdhci-of-aspeed: depopulate slots before disabling clock
From: Pengpeng Hou @ 2026-06-16 0:49 UTC (permalink / raw)
To: Adrian Hunter, Andrew Jeffery, Ulf Hansson, Joel Stanley,
linux-mmc, linux-aspeed, openbmc, linux-arm-kernel, linux-kernel
Cc: Pengpeng Hou
aspeed_sdc_probe() creates child slot devices one by one after enabling
the controller clock. If a later slot creation fails, the already-created
slot devices remain registered while the parent probe returns an error.
Depopulate any created slot devices on probe failure and during remove,
before disabling the shared controller clock used by the slots.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mmc/host/sdhci-of-aspeed.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
index f5d973783cbe..3e941b176687 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -560,12 +560,14 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
cpdev = of_platform_device_create(child, NULL, &pdev->dev);
if (!cpdev) {
ret = -ENODEV;
- goto err_clk;
+ goto err_depopulate;
}
}
return 0;
+err_depopulate:
+ of_platform_depopulate(&pdev->dev);
err_clk:
clk_disable_unprepare(sdc->clk);
return ret;
@@ -575,6 +577,7 @@ static void aspeed_sdc_remove(struct platform_device *pdev)
{
struct aspeed_sdc *sdc = dev_get_drvdata(&pdev->dev);
+ of_platform_depopulate(&pdev->dev);
clk_disable_unprepare(sdc->clk);
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] firmware: ti_sci: undo list publication on populate failure
From: Pengpeng Hou @ 2026-06-16 0:47 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, linux-arm-kernel,
linux-kernel
Cc: Pengpeng Hou
ti_sci_probe() publishes the controller on the global ti_sci_list before
creating child devices. If of_platform_populate() fails after creating
some children, the probe error path leaves the children around and leaves
the failed controller visible through ti_sci_get_handle().
Depopulate any children created by the failed populate call and remove
the controller from the global list before returning the probe error.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/firmware/ti_sci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index e027a2bd8f26..670ed1fcd8ef 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -4050,6 +4050,10 @@ static int ti_sci_probe(struct platform_device *pdev)
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "platform_populate failed %pe\n", ERR_PTR(ret));
+ of_platform_depopulate(dev);
+ mutex_lock(&ti_sci_list_mutex);
+ list_del(&info->node);
+ mutex_unlock(&ti_sci_list_mutex);
goto out;
}
return 0;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [GIT PULL] arm64 updates for 7.2
From: pr-tracker-bot @ 2026-06-16 0:33 UTC (permalink / raw)
To: Will Deacon
Cc: torvalds, catalin.marinas, linux-arm-kernel, linux-kernel,
kernel-team, maz
In-Reply-To: <ai_PGPYpLyFr2Vyb@willie-the-truck>
The pull request you sent on Mon, 15 Jun 2026 11:08:24 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-upstream
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/80476f22b8b7e193b26f285a7c9f9e4b63abca16
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Dmitry Baryshkov @ 2026-06-16 0:22 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <8518a085-b8b7-4ee6-b08c-8dde3971a6f1@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 06:55:45PM +0530, Bibek Kumar Patro wrote:
>
>
> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
> > On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
> > > On some SoCs the SMMU registers require an active interconnect
> > > bandwidth vote to be accessible. While other clients typically
> > > satisfy this requirement implicitly, certain corner cases (e.g.
> > > during sleep/wakeup transitions) can leave the SMMU without a
> > > vote, causing intermittent register access failures.
> > >
> > > Add support for an optional interconnect path to the arm-smmu
> > > driver and vote for bandwidth while the SMMU is active. The path
> > > is acquired from DT if present and ignored otherwise.
> > >
> > > The bandwidth vote is enabled before accessing SMMU registers
> > > during probe and runtime resume, and released during runtime
> > > suspend and on error paths.
> > >
> > > Generally, from an architectural perspective, GEM_NOC and DDR are
> > > expected to have an active vote whenever the adreno_smmu block is
> > > powered on. In most common use cases, this requirement is implicitly
> > > satisfied because other GPU-related clients (for example, the GMU
> > > device) already hold a GEM_NOC vote when adreno_smmu is enabled.
> > >
> > > However, there are certain corner cases, such as during sleep/wakeup
> > > transitions, where the GEM_NOC vote can be removed before adreno_smmu
> > > is powered down. If adreno_smmu is then accessed while the interconnect
> > > vote is missing, it can lead to the observed failures. Because of the
> > > precise ordering involved, this scenario is difficult to reproduce
> > > consistently.
> > > (also GDSC is involved in adreno usecases can have an independent vote)
> > >
> > > Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> > > ---
> > > drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
> > > drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
> > > 2 files changed, 57 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
> > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > @@ -53,6 +53,11 @@
> > > #define MSI_IOVA_BASE 0x8000000
> > > #define MSI_IOVA_LENGTH 0x100000
> > > +/* Interconnect bandwidth vote values for the SMMU register access path */
> > > +#define ARM_SMMU_ICC_AVG_BW 0
> > > +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
> >
> > totally random numbers, which might be different for non-Qualcomm platform.
> >
> > > +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
> > > +
> > > static int force_stage;
> > > module_param(force_stage, int, S_IRUGO);
> > > MODULE_PARM_DESC(force_stage,
> > > @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
> > > }
> > > }
> > > +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
> > > +{
> > > + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
> >
> > Is there always only one bus / path in question?
> >
>
> <Apologies, missed to respond to this query>
> Yes for TCU, it needs to only have a vote on GEM_NOC interconnect
> while accessing the DDR in downstream path (client->TCU->DDR), which we are
> addressing here.
> Hence it's only one icc path in question here.
Again, you are describing Qualcomm platform, while the code part is
generic.
--
With best wishes
Dmitry
^ 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