* Re: [PATCH v4 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround
From: Ashish Mhetre @ 2026-06-17 3:58 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra
In-Reply-To: <20260609073204.1760077-1-amhetre@nvidia.com>
On 6/9/2026 1:02 PM, Ashish Mhetre wrote:
> Nvidia Tegra264 SMMUs are affected by an erratum where a TLB entry can
> survive an invalidation that races with concurrent traffic targeting
> the same entry. The hardware-recommended software workaround is to
> issue every CFGI/TLBI command (each followed by CMD_SYNC) twice.
> The second issue must execute only after the first issue's CMD_SYNC
> has completed, giving the sequence:
>
> TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC
>
> ATC_INV is not affected and must not be doubled.
>
> The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
> cannot be detected from hardware ID. Tegra264 is device-tree-only
> (no ACPI/IORT support), so detection is purely by compatible string.
>
> This series is structured as a small refactor + detect + apply
> sequence so that each step is reviewable in isolation:
>
> 1/3 Pure refactor (no functional change): lift the existing
> force-sync conditions out of arm_smmu_cmdq_batch_add_cmd_p()
> into a new arm_smmu_cmdq_batch_force_sync() helper, so that
> adding another condition (in patch 3) is a one-liner.
> Authored by Nicolin Chen.
>
> 2/3 Detect the erratum and provide the classifier. Adds the
> ARM_SMMU_OPT_REPEAT_TLBI_CFGI per-instance option, a global
> arm_smmu_erratum_repeat_tlbi_cfgi_key static key, and the
> arm_smmu_erratum_cmd_needs_repeating() predicate. The static
> key means the wrapper compiles to a single tested branch on
> unaffected kernels.
>
> 3/3 Apply the workaround: factor arm_smmu_cmdq_issue_cmdlist()
> into a thin wrapper around __arm_smmu_cmdq_issue_cmdlist()
> that re-issues the cmdlist a second time when the predicate
> fires; register the same condition with the batch helper so
> full batches of CFGI/TLBI flush with sync=true; and add
> arm_vsmmu_can_batch_cmd() so iommufd does not mix command
> classes inside a single batch. Also documents the erratum
> in silicon-errata.rst.
>
> The series applies cleanly on linux-next/master (base-commit below).
>
> Changes since v3:
> - Drop the cmds->num == 0 early-return so the refactor is
> truly "no functional change".
> - Rename ARM_SMMU_OPT_TLBI_TWICE -> ARM_SMMU_OPT_REPEAT_TLBI_CFGI
> and rephrase its kdoc to be hardware-agnostic.
> - Rename arm_smmu_cmd_needs_tlbi_twice() ->
> arm_smmu_erratum_cmd_needs_repeating() and drop the kdoc
> above it.
> - Replace the explicit opcode switch with a single range check
> opcode >= CMDQ_OP_CFGI_STE && opcode < CMDQ_OP_ATC_INV.
> - Introduce arm_smmu_erratum_repeat_tlbi_cfgi_key static key:
> the predicate gates on it first so unaffected kernels pay
> only a single static_branch_unlikely() check.
> - Drop the verbose Tegra264-specific comments above
> arm_vsmmu_can_batch_cmd() and inside the batch helper.
> - Document the erratum in
> Documentation/arch/arm64/silicon-errata.rst.
> - Guard the repeat path in arm_smmu_cmdq_issue_cmdlist() with
> an n > 0 check so we never inspect cmds[0] on the bare-SYNC
> flush emitted by arm_smmu_cmdq_batch_add_cmd_p() when the
> next command is unsupported by the batch's pre-selected
> cmdq.
> - Drop the carried Reviewed-by tags now that the patch
> shape has changed; re-review appreciated.
>
> Changes since v2:
> - Split into a 3-patch series (refactor / detect / apply) to keep
> each step small and bisectable.
> - Move the classifier to arm-smmu-v3.h as static inline so the
> iommufd file can share it.
> - Add arm_vsmmu_can_batch_cmd() to split iommufd batches at
> "needs repeating" transitions so the per-batch decision based
> on the first command stays correct under mixed user input.
> - Spell out in the commit message why detection is via DT and
> not via IIDR/ACPI.
>
> Changes since v1:
> - Detect the erratum from the existing "nvidia,tegra264-smmu"
> compatible instead of adding a new property.
> - Centralise the doubling at the CMDQ submission layer and only
> apply it to CFGI/TLBI (not ATC_INV).
> - Drop the binding/dtsi patches accordingly.
>
> Ashish Mhetre (2):
> iommu/arm-smmu-v3: Detect Tegra264 erratum
> iommu/arm-smmu-v3: Issue CFGI/TLBI twice on Tegra264
>
> Nicolin Chen (1):
> iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
>
> Documentation/arch/arm64/silicon-errata.rst | 2 +
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 15 ++++-
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 65 +++++++++++++++----
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 24 +++++++
> 4 files changed, 94 insertions(+), 12 deletions(-)
>
>
> base-commit: 7da7f07112610a520567421dd2ffcb51beaefbcc
Hi all,
A gentle reminder to review the patches and share your comments.
Thanks,
Ashish Mhetre
^ permalink raw reply
* Re: [PATCH v2 1/3] Bluetooth: btmtksdio: correct btmtksdio_txrx_work() loop timeout check
From: Sergey Senozhatsky @ 2026-06-17 3:43 UTC (permalink / raw)
To: Sean Wang
Cc: Sergey Senozhatsky, Marcel Holtmann, Luiz Augusto von Dentz,
Mark-yw Chen, Sean Wang, Tomasz Figa, linux-bluetooth,
linux-kernel, linux-arm-kernel, linux-mediatek, stable
In-Reply-To: <CAGp9LzpCMGr2hyVJRMehs_BD4Rk6mS2jAifWuCgBaANdqgtvqA@mail.gmail.com>
On (26/06/16 19:40), Sean Wang wrote:
> > The btmtksdio_txrx_work() loop is expected to be terminated if running
> > for longer than 5*HZ. However the timeout check is reversed:
> > time_is_before_jiffies(old_jiffies + 5*HZ) evaluates to true when
> > old_jiffies + 5*HZ is in the past i.e. when a timeout has occurred.
> > Using OR with time_is_before_jiffies(txrx_timeout) means that:
> > - before the 5-second timeout: the condition is `int_status || false`,
> > so it loops as long as there are pending interrupts.
> > - after the 5-second timeout: the condition becomes `int_status || true`,
> > which is always true.
> >
> > Fix loop termination condition to actually enforce a 5*HZ timeout.
> >
> > Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> > ---
> > drivers/bluetooth/btmtksdio.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> > index 5b0fab7b89b5..c6f80c419e90 100644
> > --- a/drivers/bluetooth/btmtksdio.c
> > +++ b/drivers/bluetooth/btmtksdio.c
> > @@ -620,7 +620,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> > if (btmtksdio_rx_packet(bdev, rx_size) < 0)
> > bdev->hdev->stat.err_rx++;
> > }
> > - } while (int_status || time_is_before_jiffies(txrx_timeout));
> > + } while (int_status && time_is_after_jiffies(txrx_timeout));
> >
>
> This patch has already been merged, so I think the series should be
> respun based on the latest code.
Oh, I see. Any chance it can be dropped from the tree or updated?
The patch is identical it's the commit message that has changed.
Otherwise, I can drop it from a v3 re-spin.
^ permalink raw reply
* Re: [PATCH v2 3/3] Bluetooth: btmtksdio: call cancel_work_sync() outside of host lock scope
From: Sergey Senozhatsky @ 2026-06-17 3:41 UTC (permalink / raw)
To: Sean Wang
Cc: Sergey Senozhatsky, Marcel Holtmann, Luiz Augusto von Dentz,
Mark-yw Chen, Sean Wang, Tomasz Figa, linux-bluetooth,
linux-kernel, linux-arm-kernel, linux-mediatek, stable
In-Reply-To: <CAGp9LzqT4knwk9hONu43cGDr005Phs3xw6T+YexXa3X6JEBOpA@mail.gmail.com>
On (26/06/16 19:56), Sean Wang wrote:
> The patch looks good to me. Inspired by your patch,
> do you think should we add another patch to keep txrx_work out of the
> reset window by rejecting TX during reset,
> ignoring reset-time interrupts, and making queued workers exit early?
I honestly don't know, it's hard for to me judge as I'm not all that
familiar with the code. To make things more complex, I don't think we
see any crashes on reset path. My personal preference maybe would be
to keep things the way they are?
> Some code like:
>
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -567,6 +567,8 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> pm_runtime_get_sync(bdev->dev);
>
> sdio_claim_host(bdev->func);
> + if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
> + goto out;
A nit: I think you can test_bit() outside of host lock scope.
Other than that I'm afraid I cannot be of much help here.
> /* Disable interrupt */
> sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
> @@ -628,6 +630,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> !test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
> sdio_writel(bdev->func, C_INT_EN_SET, MTK_REG_CHLPCR, NULL);
>
> +out:
> sdio_release_host(bdev->func);
>
> pm_runtime_put_autosuspend(bdev->dev);
> @@ -646,6 +649,9 @@ static void btmtksdio_interrupt(struct sdio_func *func)
> /* Disable interrupt */
> sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
>
> + if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
> + return;
> +
> schedule_work(&bdev->txrx_work);
> }
>
> @@ -1250,6 +1256,9 @@ static int btmtksdio_send_frame(struct hci_dev
> *hdev, struct sk_buff *skb)
> {
> struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
>
> + if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
> + return -EBUSY;
> +
> switch (hci_skb_pkt_type(skb)) {
> case HCI_COMMAND_PKT:
> hdev->stat.cmd_tx++;
^ permalink raw reply
* [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Wayen Yan @ 2026-06-17 3:20 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
- channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
- channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
- channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
- channel 3: clears bit 24..31 (channel 3 only) - correct by accident
While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
mask parameter, the loop still incorrectly clears queues within the
same channel beyond queue 7.
Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..a1eda13400 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2217,7 +2217,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
struct airoha_gdm_port *port = netdev_priv(dev);
int i;
- for (i = 0; i < AIROHA_NUM_TX_RING; i++)
+ for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
--
2.51.0
^ permalink raw reply related
* [PATCH v3] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Hongling Zeng @ 2026-06-17 2:34 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, Frank Li
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>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Suggested-by: Frank Li <Frank.li@oss.nxp.com>
---
Change in v2;
-Add pchan->desc != pchan->done check to prevent race condition
where completed descriptors could be double-added to desc_completed
list, causing list corruption
---
Change in v3:
-Fix by using vchan_terminate_vdesc() as suggested by Frank Li
---
drivers/dma/sun6i-dma.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 7a79f346250a..134ae840f176 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -946,16 +946,13 @@ 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;
-
- list_add_tail(&vd->node, &vc->desc_completed);
- }
+ if (pchan && pchan->desc && pchan->desc != pchan->done) {
+ struct virt_dma_desc *vd = &pchan->desc->vd;
+
+ vchan_terminate_vdesc(vd);
}
+ vchan->cyclic = false;
vchan_get_all_descriptors(&vchan->vc, &head);
if (pchan) {
--
2.25.1
^ permalink raw reply related
* [PATCH v4 0/2] pwm: Add Nuvoton MA35D1 PWM controller support
From: Chi-Wen Weng @ 2026-06-17 2:59 UTC (permalink / raw)
To: ukleinek, robh, krzk+dt, conor+dt
Cc: linux-arm-kernel, linux-pwm, devicetree, linux-kernel, cwweng,
cwweng.linux
From: Chi-Wen Weng <cwweng@nuvoton.com>
This series adds support for the Nuvoton MA35D1 PWM controller.
The MA35D1 PWM controller provides 6 PWM channels. The hardware supports
several counter types and output modes. This driver configures the controller
to use up-counting mode, auto-reload mode and independent output mode. The
waveform generator is configured to drive the output high at the zero point
and low at the compare-up point.
For the up-counting mode used by this driver, the counter counts from 0 to
PERIOD inclusive. Therefore, the programmed period is PERIOD + 1 cycles. The
hardware can generate 0% duty cycle with CMPDAT = 0 and 100% duty cycle with
CMPDAT > PERIOD. To keep 100% duty cycle representable, the driver limits the
maximum PERIOD value to 0xfffe and reserves CMPDAT = 0xffff for the full-duty
case.
The hardware buffers PERIOD and CMPDAT updates when IMMLDENn is disabled. The
driver keeps IMMLDENn disabled, so period and duty cycle updates take effect
at the end of the current period. Polarity and waveform-control changes are
applied directly and may cause transient output changes if the PWM is running.
When the PWM output is disabled by clearing POENn, the output pin is put into
tri-state according to the MA35D1 reference manual.
Changes in v4:
- Add a Limitations section to describe the hardware capabilities and driver
limitations.
- Add a link to the MA35D1 reference manual.
- Replace register address macros containing the base pointer with register
offset macros.
- Add readl/writel/rmw helper functions.
- Rename TOTAL_CHANNELS to NUM_CHANNELS.
- Use unsigned long for the cached clock rate.
- Use devm_clk_rate_exclusive_get().
- Configure polarity before enabling the counter and output.
- Add controller initialization for up-counting, auto-reload and independent
output mode.
- Configure the waveform generator for zero-point-high and compare-up-low
output.
- Fix the period conversion because the hardware period is PERIOD + 1 cycles.
- Limit the maximum PERIOD value to 0xfffe so that CMPDAT = 0xffff can be used
to generate 100% duty cycle.
- Use CNTEN and POEN bits to report the enabled state in .get_state().
- Disable the PWM by clearing POENn and CNTENn.
- Fix error message capitalization and trailing newlines.
- Fix coding style issues reported by review/checkpatch-style tools.
Changes in v3:
- Update nuvoton,ma35d1-pwm.yaml
- Add maintainers entry
- Increse "#pwm-cells" to 3
- Update ma35d1 pwm driver
- Make include header and macros definitions organized alphabetically
- Rename macros REG_PWM_XXXX to MA35D1_REG_PWM_XXXX
- Add macros for register address
v2 resend:
- Remove wrong 'Reviewed-by' tags.
Changes in v2:
- Update nuvoton,ma35d1-pwm.yaml
- Fix 'maxItems' of 'reg' to 1.
- Remove unused label
- Update ma35d1 pwm driver
- Remove MODULE_ALIAS()
- Add chip->atomic = true
Chi-Wen Weng (2):
dt-bindings: pwm: Add Nuvoton MA35D1 PWM controller
pwm: Add Nuvoton MA35D1 PWM controller support
.../bindings/pwm/nuvoton,ma35d1-pwm.yaml | 45 +++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-ma35d1.c | 344 ++++++++++++++++++
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/nuvoton,ma35d1-pwm.yaml
create mode 100644 drivers/pwm/pwm-ma35d1.c
--
2.25.1
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a779g0: Add GICv3 ITS and update PCIe nodes
From: Marek Vasut @ 2026-06-17 2:59 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org>
This SoC implements GIC600 with GICv3 ITS and PCIe host mode on this
SoC can use it. Add GIC ITS node into GIC node, update interrupt-map
and add msi-map into PCIe controller node.
The GIC ITS does have master interface to issue transactions to RAM.
The interface does support cacheable transactions, however, it does
not support shareable attribute, because the AXI port signals are tied
to inactive in this implementation. Therefore, add "dma-noncoherent"
DT property into the GIC ITS subnode.
The GIC redistributor does not have cacheable/shareable, therefore
add "dma-noncoherent" DT property into the GIC node.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
NOTE: This would not be possible without prior work from Shimoda-san
https://lore.kernel.org/all/20240214052144.1966569-1-yoshihiro.shimoda.uh@renesas.com/
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 31 ++++++++++++++++-------
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
index 3a8af825bb253..82e864acf2601 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
@@ -792,6 +792,7 @@ pciec0: pcie@e65d0000 {
resets = <&cpg 624>;
reset-names = "pwr";
max-link-speed = <4>;
+ msi-parent = <&its>;
num-lanes = <2>;
#address-cells = <3>;
#size-cells = <2>;
@@ -802,10 +803,10 @@ pciec0: pcie@e65d0000 {
dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>;
snps,enable-cdm-check;
status = "disabled";
@@ -839,6 +840,7 @@ pciec1: pcie@e65d8000 {
resets = <&cpg 625>;
reset-names = "pwr";
max-link-speed = <4>;
+ msi-parent = <&its>;
num-lanes = <2>;
#address-cells = <3>;
#size-cells = <2>;
@@ -849,10 +851,10 @@ pciec1: pcie@e65d8000 {
dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>;
snps,enable-cdm-check;
status = "disabled";
@@ -2131,11 +2133,22 @@ ipmmu_mm: iommu@eefc0000 {
gic: interrupt-controller@f1000000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
- #address-cells = <0>;
+ #address-cells = <2>;
+ #size-cells = <2>;
interrupt-controller;
reg = <0x0 0xf1000000 0 0x20000>,
<0x0 0xf1060000 0 0x110000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ dma-noncoherent;
+
+ ranges = <0x0 0x0 0x0 0xf1000000 0x0 0x200000>;
+
+ its: msi-controller@40000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x40000 0x0 0x20000>;
+ dma-noncoherent;
+ msi-controller;
+ };
};
gpu: gpu@fd000000 {
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-17 2:59 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org>
Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
or APB interface configured to 32 bit, it can therefore access only
the first 4 GiB of physical address space. This information comes from
R-Car V4H Interface Specification sheet, there is currently no technical
update number assigned to this limitation. Further input from hardware
engineer indicates that this limitation also applies to R-Car S4 and V4M.
Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
limitation.
Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
common for many ARM GICv3 implementations. Therefore, add an extra
of_machine_is_compatible() check.
The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
NOTE: This would not be possible without prior work from Shimoda-san
https://lore.kernel.org/all/20240214052050.1966439-1-yoshihiro.shimoda.uh@renesas.com/
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
Documentation/arch/arm64/silicon-errata.rst | 1 +
arch/arm64/Kconfig | 9 +++++++++
drivers/irqchip/irq-gic-v3-its.c | 20 ++++++++++++++++++++
3 files changed, 30 insertions(+)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 014aa1c215a16..b0c68b64f5ac2 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -352,6 +352,7 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
+----------------+-----------------+-----------------+-----------------------------+
+| Renesas | S4/V4H/V4M | N/A | RENESAS_ERRATUM_GEN4GICITS1 |
+----------------+-----------------+-----------------+-----------------------------+
| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
+----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b3afe0688919b..b9e17ce475e61 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1382,6 +1382,15 @@ config NVIDIA_CARMEL_CNP_ERRATUM
If unsure, say Y.
+config RENESAS_ERRATUM_GEN4GICITS1
+ bool "Renesas R-Car Gen4: GIC600 can not access physical addresses above 4 GiB"
+ default y
+ help
+ The Renesas R-Car Gen4 S4/V4H/V4M GIC600 SoC integrations have AXI
+ addressing limited to the first 32-bit of physical address space.
+
+ If unsure, say Y.
+
config ROCKCHIP_ERRATUM_3568002
bool "Rockchip 3568002: GIC600 can not access physical addresses higher than 4GB"
default y
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index b57d81ad33a0a..ec3756f29cf1a 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4901,6 +4901,18 @@ static bool __maybe_unused its_enable_rk3568002(void *data)
return true;
}
+static bool __maybe_unused its_enable_renesas_gen4(void *data)
+{
+ if (!of_machine_is_compatible("renesas,r8a779f0") &&
+ !of_machine_is_compatible("renesas,r8a779g0") &&
+ !of_machine_is_compatible("renesas,r8a779h0"))
+ return false;
+
+ gfp_flags_quirk |= GFP_DMA32;
+
+ return true;
+}
+
static const struct gic_quirk its_quirks[] = {
#ifdef CONFIG_CAVIUM_ERRATUM_22375
{
@@ -4975,6 +4987,14 @@ static const struct gic_quirk its_quirks[] = {
.mask = 0xffffffff,
.init = its_enable_rk3568002,
},
+#endif
+#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
+ {
+ .desc = "ITS: Renesas R-Car Gen4 GIC600 32-bit limit",
+ .iidr = 0x0201743b,
+ .mask = 0xffffffff,
+ .init = its_enable_renesas_gen4,
+ },
#endif
{
}
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-17 2:59 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
MSI are handled via GIC ITS. Configure all controller MSI registers
fully.
Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
enable MSI_CTRL_INT bit according to MSI enable state, set both bits
if MSI are enabled, clear both bits if MSI are disabled.
If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
pass through of MSI TLPs onto the AXI bus and then further into
GIC ITS translation registers.
If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
with target address of GIC ITS translation registers, and configure
AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
GIC ITS. This specific configuration allows handling of MSI via the
GIC ITS instead of integrated iMSI-RX.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
NOTE: This would not be possible without prior work from Shimoda-san
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 53 +++++++++++++++++++--
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 485cfa8bd9692..ba6e3bedd6d0a 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -31,6 +31,10 @@
#define DEVICE_TYPE_RC BIT(4)
#define BIFUR_MOD_SET_ON BIT(0)
+/* MSI Capability */
+#define MSICAP0 0x0050
+#define MSICAP0_MSIE BIT(16)
+
/* PCIe Interrupt Status 0 */
#define PCIEINTSTS0 0x0084
@@ -55,6 +59,16 @@
#define APP_HOLD_PHY_RST BIT(16)
#define APP_LTSSM_ENABLE BIT(0)
+/* INTC address */
+#define AXIINTCADDR 0x0a00
+/* GITS GIC ITS translation register */
+#define AXIINTCADDR_VAL 0xf1050000
+
+/* INTC control & mask */
+#define AXIINTCCONT 0x0a04
+#define INTC_EN BIT(31)
+#define INTC_MASK GENMASK(11, 2)
+
/* PCIe Power Management Control */
#define PCIEPWRMNGCTRL 0x0070
#define APP_CLK_REQ_N BIT(11)
@@ -305,6 +319,39 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
return rcar;
}
+static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+ u32 val;
+
+ /* Make sure MSICAP0 MSIE is configured. */
+ val = dw_pcie_readl_dbi(dw, MSICAP0);
+ if (pci_msi_enabled())
+ val |= MSICAP0_MSIE;
+ else
+ val &= ~MSICAP0_MSIE;
+ dw_pcie_writel_dbi(dw, MSICAP0, val);
+
+ if (!pci_msi_enabled() || pp->use_imsi_rx) {
+ /* Clear AXIINTC mapping. */
+ writel(0, rcar->base + AXIINTCADDR);
+ writel(0, rcar->base + AXIINTCCONT);
+ } else {
+ /* Point AXIINTC to GIC ITS and enable. */
+ writel(AXIINTCADDR_VAL, rcar->base + AXIINTCADDR);
+ writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
+ }
+
+ /* Configure MSI interrupt signal */
+ val = readl(rcar->base + PCIEINTSTS0EN);
+ if (pci_msi_enabled())
+ val |= MSI_CTRL_INT;
+ else
+ val &= ~MSI_CTRL_INT;
+ writel(val, rcar->base + PCIEINTSTS0EN);
+}
+
static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
struct pci_dev *dev)
{
@@ -359,7 +406,6 @@ static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
int ret;
- u32 val;
if (pp->bridge)
pp->bridge->enable_device = rcar_gen4_pcie_enable_device;
@@ -379,10 +425,7 @@ static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_0, 0x0);
dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_1, 0x0);
- /* Enable MSI interrupt signal */
- val = readl(rcar->base + PCIEINTSTS0EN);
- val |= MSI_CTRL_INT;
- writel(val, rcar->base + PCIEINTSTS0EN);
+ rcar_gen4_pcie_host_msi_init(pp);
msleep(PCIE_T_PVPERL_MS); /* pe_rst requires 100msec delay */
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/2] pwm: Add Nuvoton MA35D1 PWM controller support
From: Chi-Wen Weng @ 2026-06-17 2:59 UTC (permalink / raw)
To: ukleinek, robh, krzk+dt, conor+dt
Cc: linux-arm-kernel, linux-pwm, devicetree, linux-kernel, cwweng,
cwweng.linux, Trevor Gamblin
In-Reply-To: <20260617025925.2539334-1-cwweng.linux@gmail.com>
From: Chi-Wen Weng <cwweng@nuvoton.com>
Add a PWM framework driver for the Nuvoton MA35D1 PWM controller.
The MA35D1 PWM controller provides 6 PWM channels. The hardware supports
up, down and up-down counter types, auto-reload and one-shot modes, and
independent and complementary output modes. This driver configures all
channels to up-counting mode, auto-reload mode and independent output mode.
The waveform generator is configured to drive the output high at the zero
point and low at the compare-up point. In up-counting mode the counter
counts from 0 to PERIOD inclusive, so the PWM period is PERIOD + 1 cycles.
With the selected waveform actions, CMPDAT = 0 generates 0% duty cycle and
CMPDAT > PERIOD generates 100% duty cycle. Limit PERIOD to 0xfffe so that
CMPDAT = 0xffff can be used for the full-duty case.
PERIOD and CMPDAT updates are buffered by the hardware and take effect at
the end of the current period because IMMLDENn is left disabled. When the
PWM output is disabled, POENn is cleared and the output pin is put into
tri-state.
Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
---
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-ma35d1.c | 344 +++++++++++++++++++++++++++++++++++++++
3 files changed, 354 insertions(+)
create mode 100644 drivers/pwm/pwm-ma35d1.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e8886a9b64d9..355131e6efac 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -463,6 +463,15 @@ config PWM_LPSS_PLATFORM
To compile this driver as a module, choose M here: the module
will be called pwm-lpss-platform.
+config PWM_MA35D1
+ tristate "Nuvoton MA35D1 PWM support"
+ depends on ARCH_MA35 || COMPILE_TEST
+ help
+ Generic PWM framework driver for Nuvoton MA35D1.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-ma35d1.
+
config PWM_MAX7360
tristate "MAX7360 PWMs"
depends on MFD_MAX7360
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5630a521a7cf..7ad761ea27d1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
obj-$(CONFIG_PWM_LPSS_PLATFORM) += pwm-lpss-platform.o
+obj-$(CONFIG_PWM_MA35D1) += pwm-ma35d1.o
obj-$(CONFIG_PWM_MAX7360) += pwm-max7360.o
obj-$(CONFIG_PWM_MC33XS2410) += pwm-mc33xs2410.o
obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
diff --git a/drivers/pwm/pwm-ma35d1.c b/drivers/pwm/pwm-ma35d1.c
new file mode 100644
index 000000000000..c07eedeca035
--- /dev/null
+++ b/drivers/pwm/pwm-ma35d1.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Nuvoton MA35D1 PWM controller
+ *
+ * Copyright (C) 2026 Nuvoton Corporation
+ * Chi-Wen Weng <cwweng@nuvoton.com>
+ *
+ * Reference Manual:
+ * https://www.nuvoton.com.cn/resource-download.jsp?tp_GUID=DA05-MA35D16
+ *
+ * Limitations:
+ * - The hardware supports 6 PWM channels.
+ * - The hardware supports up, down and up-down counter types. This driver
+ * configures all channels to up-counting mode.
+ * - The hardware supports auto-reload and one-shot counter modes. This driver
+ * configures all channels to auto-reload mode.
+ * - The hardware supports independent and complementary output modes. This
+ * driver configures all channels to independent output mode.
+ * - The hardware supports programmable waveform actions at zero, period and
+ * compare points. This driver uses zero point high and compare-up point low
+ * actions for normal PWM output.
+ * - In up-counting mode, the counter counts from 0 to PERIOD inclusive. With
+ * zero point high and compare-up point low actions, CMPDAT = 0 produces 0%
+ * duty and CMPDAT > PERIOD produces 100% duty.
+ * - The driver limits PERIOD to 0xfffe so that CMPDAT can be set greater than
+ * PERIOD to generate a 100% duty cycle.
+ * - Period and duty cycle changes are buffered by hardware and take effect at
+ * the end of the current period because IMMLDENn is left disabled.
+ * - Polarity changes are applied directly and may cause a transient output
+ * change if the PWM output is running.
+ * - When disabled, the output pin is put in tri-state by clearing POENn.
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/math64.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+
+#define MA35D1_REG_PWM_CTL0 0x00
+#define MA35D1_REG_PWM_CTL1 0x04
+#define MA35D1_REG_PWM_CNTEN 0x20
+#define MA35D1_REG_PWM_PERIOD(ch) (0x30 + 4 * (ch))
+#define MA35D1_REG_PWM_CMPDAT(ch) (0x50 + 4 * (ch))
+#define MA35D1_REG_PWM_WGCTL0 0xb0
+#define MA35D1_REG_PWM_WGCTL1 0xb4
+#define MA35D1_REG_PWM_POLCTL 0xd4
+#define MA35D1_REG_PWM_POEN 0xd8
+
+#define MA35D1_PWM_CTL1_CNTMODE_MASK(ch) BIT(16 + (ch))
+#define MA35D1_PWM_CTL1_OUTMODE_MASK(ch) BIT(24 + ((ch) / 2))
+
+#define MA35D1_PWM_WGCTL_ACTION_MASK 0x3
+#define MA35D1_PWM_WGCTL_ACTION_LOW 1
+#define MA35D1_PWM_WGCTL_ACTION_HIGH 2
+
+#define MA35D1_PWM_WGCTL_ZERO_HIGH(ch) \
+ (MA35D1_PWM_WGCTL_ACTION_HIGH << (2 * (ch)))
+#define MA35D1_PWM_WGCTL_CMP_UP_LOW(ch) \
+ (MA35D1_PWM_WGCTL_ACTION_LOW << (2 * (ch)))
+
+#define MA35D1_PWM_CNTEN_EN(ch) BIT(ch)
+#define MA35D1_PWM_POEN_EN(ch) BIT(ch)
+#define MA35D1_PWM_POLCTL_INV(ch) BIT(ch)
+
+#define MA35D1_PWM_MAX_CMPDAT 0xffff
+#define MA35D1_PWM_MAX_PERIOD 0xfffe
+#define MA35D1_PWM_MAX_PERIOD_CYCLES (MA35D1_PWM_MAX_PERIOD + 1)
+#define MA35D1_PWM_NUM_CHANNELS 6
+
+struct nuvoton_pwm {
+ void __iomem *base;
+ unsigned long clkrate;
+};
+
+static inline struct nuvoton_pwm *nuvoton_pwm_from_chip(struct pwm_chip *chip)
+{
+ return pwmchip_get_drvdata(chip);
+}
+
+static inline u32 nuvoton_pwm_ctl1_cnttype_mask(unsigned int ch)
+{
+ return MA35D1_PWM_WGCTL_ACTION_MASK << (2 * ch);
+}
+
+static inline u32 nuvoton_pwm_wgctl_zero_mask(unsigned int ch)
+{
+ return MA35D1_PWM_WGCTL_ACTION_MASK << (2 * ch);
+}
+
+static inline u32 nuvoton_pwm_wgctl_period_mask(unsigned int ch)
+{
+ return MA35D1_PWM_WGCTL_ACTION_MASK << (16 + 2 * ch);
+}
+
+static inline u32 nuvoton_pwm_wgctl_cmp_up_mask(unsigned int ch)
+{
+ return MA35D1_PWM_WGCTL_ACTION_MASK << (2 * ch);
+}
+
+static inline u32 nuvoton_pwm_wgctl_cmp_down_mask(unsigned int ch)
+{
+ return MA35D1_PWM_WGCTL_ACTION_MASK << (16 + 2 * ch);
+}
+
+static inline u32 nuvoton_pwm_readl(struct nuvoton_pwm *nvtpwm,
+ unsigned int offset)
+{
+ return readl(nvtpwm->base + offset);
+}
+
+static inline void nuvoton_pwm_writel(struct nuvoton_pwm *nvtpwm,
+ unsigned int offset, u32 value)
+{
+ writel(value, nvtpwm->base + offset);
+}
+
+static inline void nuvoton_pwm_rmw(struct nuvoton_pwm *nvtpwm,
+ unsigned int offset, u32 mask, u32 value)
+{
+ u32 reg;
+
+ reg = nuvoton_pwm_readl(nvtpwm, offset);
+ reg &= ~mask;
+ reg |= value & mask;
+ nuvoton_pwm_writel(nvtpwm, offset, reg);
+}
+
+static void nuvoton_pwm_init(struct nuvoton_pwm *nvtpwm)
+{
+ u32 ctl1_mask = 0;
+ u32 wgctl0_mask = 0;
+ u32 wgctl0_val = 0;
+ u32 wgctl1_mask = 0;
+ u32 wgctl1_val = 0;
+ int ch;
+
+ for (ch = 0; ch < MA35D1_PWM_NUM_CHANNELS; ch++) {
+ /* CNTTYPEn = 00: up counter type */
+ ctl1_mask |= nuvoton_pwm_ctl1_cnttype_mask(ch);
+
+ /* CNTMODEn = 0: auto-reload mode */
+ ctl1_mask |= MA35D1_PWM_CTL1_CNTMODE_MASK(ch);
+
+ /* ZPCTLn = 10: output high at zero point */
+ wgctl0_mask |= nuvoton_pwm_wgctl_zero_mask(ch);
+ wgctl0_val |= MA35D1_PWM_WGCTL_ZERO_HIGH(ch);
+
+ /* PRDPCTLn = 00: do nothing at period point */
+ wgctl0_mask |= nuvoton_pwm_wgctl_period_mask(ch);
+
+ /* CMPUCTLn = 01: output low at compare up point */
+ wgctl1_mask |= nuvoton_pwm_wgctl_cmp_up_mask(ch);
+ wgctl1_val |= MA35D1_PWM_WGCTL_CMP_UP_LOW(ch);
+
+ /* CMPDCTLn = 00: do nothing at compare down point */
+ wgctl1_mask |= nuvoton_pwm_wgctl_cmp_down_mask(ch);
+ }
+
+ for (ch = 0; ch < MA35D1_PWM_NUM_CHANNELS; ch += 2) {
+ /* OUTMODEn = 0: independent mode */
+ ctl1_mask |= MA35D1_PWM_CTL1_OUTMODE_MASK(ch);
+ }
+
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_CTL1, ctl1_mask, 0);
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_WGCTL0,
+ wgctl0_mask, wgctl0_val);
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_WGCTL1,
+ wgctl1_mask, wgctl1_val);
+}
+
+static int nuvoton_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct nuvoton_pwm *nvtpwm = nuvoton_pwm_from_chip(chip);
+ u32 ch = pwm->hwpwm;
+ u64 duty_cycles, period_cycles;
+ u32 cmpdat, period;
+
+ if (!state->enabled) {
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_POEN,
+ MA35D1_PWM_POEN_EN(ch), 0);
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_CNTEN,
+ MA35D1_PWM_CNTEN_EN(ch), 0);
+
+ return 0;
+ }
+
+ period_cycles = mul_u64_u64_div_u64(nvtpwm->clkrate,
+ state->period,
+ NSEC_PER_SEC);
+ if (!period_cycles)
+ return -EINVAL;
+
+ if (period_cycles > MA35D1_PWM_MAX_PERIOD_CYCLES)
+ period_cycles = MA35D1_PWM_MAX_PERIOD_CYCLES;
+
+ duty_cycles = mul_u64_u64_div_u64(nvtpwm->clkrate,
+ state->duty_cycle,
+ NSEC_PER_SEC);
+ if (duty_cycles > period_cycles)
+ duty_cycles = period_cycles;
+
+ if (state->polarity == PWM_POLARITY_NORMAL)
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_POLCTL,
+ MA35D1_PWM_POLCTL_INV(ch), 0);
+ else
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_POLCTL,
+ MA35D1_PWM_POLCTL_INV(ch),
+ MA35D1_PWM_POLCTL_INV(ch));
+
+ /*
+ * In up-counting mode the counter counts from 0 to PERIOD inclusive.
+ * With zero point high and compare-up point low actions:
+ * - CMPDAT = 0 produces 0% duty.
+ * - CMPDAT > PERIOD produces 100% duty.
+ * PERIOD is limited to 0xfffe, so duty_cycles can be written directly
+ * to CMPDAT and still fit in the 16-bit compare field for 100% duty.
+ */
+ period = period_cycles - 1;
+ cmpdat = duty_cycles;
+
+ nuvoton_pwm_writel(nvtpwm, MA35D1_REG_PWM_PERIOD(ch), period);
+ nuvoton_pwm_writel(nvtpwm, MA35D1_REG_PWM_CMPDAT(ch), cmpdat);
+
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_CNTEN,
+ MA35D1_PWM_CNTEN_EN(ch), MA35D1_PWM_CNTEN_EN(ch));
+ nuvoton_pwm_rmw(nvtpwm, MA35D1_REG_PWM_POEN,
+ MA35D1_PWM_POEN_EN(ch), MA35D1_PWM_POEN_EN(ch));
+
+ return 0;
+}
+
+static int nuvoton_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct nuvoton_pwm *nvtpwm = nuvoton_pwm_from_chip(chip);
+ u32 ch = pwm->hwpwm;
+ u32 cmpdat, cnten, period, poen, polctl;
+ u64 duty_cycles, period_cycles;
+
+ cnten = nuvoton_pwm_readl(nvtpwm, MA35D1_REG_PWM_CNTEN);
+ poen = nuvoton_pwm_readl(nvtpwm, MA35D1_REG_PWM_POEN);
+ polctl = nuvoton_pwm_readl(nvtpwm, MA35D1_REG_PWM_POLCTL);
+ period = nuvoton_pwm_readl(nvtpwm, MA35D1_REG_PWM_PERIOD(ch)) &
+ MA35D1_PWM_MAX_CMPDAT;
+ cmpdat = nuvoton_pwm_readl(nvtpwm, MA35D1_REG_PWM_CMPDAT(ch)) &
+ MA35D1_PWM_MAX_CMPDAT;
+
+ period_cycles = period + 1;
+ if (cmpdat > period)
+ duty_cycles = period_cycles;
+ else
+ duty_cycles = cmpdat;
+
+ state->enabled = (cnten & MA35D1_PWM_CNTEN_EN(ch)) &&
+ (poen & MA35D1_PWM_POEN_EN(ch));
+ state->polarity = (polctl & MA35D1_PWM_POLCTL_INV(ch)) ?
+ PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
+ state->period = DIV64_U64_ROUND_UP(period_cycles * NSEC_PER_SEC,
+ nvtpwm->clkrate);
+ state->duty_cycle = DIV64_U64_ROUND_UP(duty_cycles * NSEC_PER_SEC,
+ nvtpwm->clkrate);
+
+ return 0;
+}
+
+static const struct pwm_ops nuvoton_pwm_ops = {
+ .apply = nuvoton_pwm_apply,
+ .get_state = nuvoton_pwm_get_state,
+};
+
+static int nuvoton_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pwm_chip *chip;
+ struct nuvoton_pwm *nvtpwm;
+ struct clk *clk;
+ int ret;
+
+ chip = devm_pwmchip_alloc(dev, MA35D1_PWM_NUM_CHANNELS,
+ sizeof(*nvtpwm));
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ nvtpwm = nuvoton_pwm_from_chip(chip);
+
+ nvtpwm->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(nvtpwm->base))
+ return PTR_ERR(nvtpwm->base);
+
+ clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "Unable to get the clock\n");
+
+ ret = devm_clk_rate_exclusive_get(dev, clk);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Unable to get exclusive clock rate\n");
+
+ nvtpwm->clkrate = clk_get_rate(clk);
+ if (!nvtpwm->clkrate)
+ return dev_err_probe(dev, -EINVAL,
+ "PWM clock rate is zero\n");
+
+ if (nvtpwm->clkrate > NSEC_PER_SEC)
+ return dev_err_probe(dev, -EINVAL,
+ "PWM clock out of range (%lu)\n",
+ nvtpwm->clkrate);
+
+ nuvoton_pwm_init(nvtpwm);
+
+ chip->ops = &nuvoton_pwm_ops;
+ chip->atomic = true;
+
+ ret = devm_pwmchip_add(dev, chip);
+ if (ret)
+ return dev_err_probe(dev, ret, "Unable to add PWM chip\n");
+
+ return 0;
+}
+
+static const struct of_device_id nuvoton_pwm_of_match[] = {
+ { .compatible = "nuvoton,ma35d1-pwm" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, nuvoton_pwm_of_match);
+
+static struct platform_driver nuvoton_pwm_driver = {
+ .probe = nuvoton_pwm_probe,
+ .driver = {
+ .name = "nuvoton-pwm",
+ .of_match_table = nuvoton_pwm_of_match,
+ },
+};
+module_platform_driver(nuvoton_pwm_driver);
+
+MODULE_AUTHOR("Chi-Wen Weng <cwweng@nuvoton.com>");
+MODULE_DESCRIPTION("Nuvoton MA35D1 PWM driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: pwm: Add Nuvoton MA35D1 PWM controller
From: Chi-Wen Weng @ 2026-06-17 2:59 UTC (permalink / raw)
To: ukleinek, robh, krzk+dt, conor+dt
Cc: linux-arm-kernel, linux-pwm, devicetree, linux-kernel, cwweng,
cwweng.linux, Krzysztof Kozlowski
In-Reply-To: <20260617025925.2539334-1-cwweng.linux@gmail.com>
From: Chi-Wen Weng <cwweng@nuvoton.com>
Add device tree binding for the Nuvoton MA35D1 PWM controller.
The MA35D1 PWM controller provides 6 PWM channels and uses one register
region and one functional clock. The binding uses the standard PWM binding
with three PWM cells.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
---
.../bindings/pwm/nuvoton,ma35d1-pwm.yaml | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/nuvoton,ma35d1-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/nuvoton,ma35d1-pwm.yaml b/Documentation/devicetree/bindings/pwm/nuvoton,ma35d1-pwm.yaml
new file mode 100644
index 000000000000..47a59bdd14d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/nuvoton,ma35d1-pwm.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/nuvoton,ma35d1-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 PWM controller
+
+maintainers:
+ - Chi-Wen Weng <cwweng@nuvoton.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,ma35d1-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+
+ pwm@40580000 {
+ compatible = "nuvoton,ma35d1-pwm";
+ reg = <0x40580000 0x400>;
+ clocks = <&clk EPWM0_GATE>;
+ #pwm-cells = <3>;
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH] net: airoha: Fix off-by-one error in HTB rate-limit channel removal
From: Wayen Yan @ 2026-06-17 2:51 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_tc_remove_htb_queue(), the rate-limit was being cleared
using (queue + 1) instead of queue, causing:
- The original channel rate-limit configuration to remain active
- The next channel to be incorrectly disabled
- Potential out-of-bounds access when queue == 3 (channel 4)
The alloc path (airoha_tc_htb_alloc_leaf_queue) correctly uses
channel (0..3), but the remove path incorrectly added 1.
Fix by using queue directly to match the alloc and rollback paths.
Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..02807b3967 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2805,7 +2805,7 @@ static void airoha_tc_remove_htb_queue(struct net_device *dev, int queue)
struct airoha_gdm_port *port = netdev_priv(dev);
netif_set_real_num_tx_queues(dev, dev->real_num_tx_queues - 1);
- airoha_qdma_set_tx_rate_limit(dev, queue + 1, 0, 0);
+ airoha_qdma_set_tx_rate_limit(dev, queue, 0, 0);
clear_bit(queue, port->qos_sq_bmap);
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: nv: Translate vEL2 PSTATE to EL1 in kvm_hyp_handle_mops()
From: swing sze @ 2026-06-17 2:52 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Andrew Morton,
Jakub Kicinski, Bjorn Andersson, Mark Rutland, Kristina Martsenko,
linux-arm-kernel, kvmarm, Zhong Wang, Xuanqing Shi
In-Reply-To: <ajGur_YEMoMLZPSF@kernel.org>
Oliver Upton <oupton@kernel.org> 于2026年6月17日周三 04:14写道：
>
> Hi Weiming,
>
> Thanks for the fix.
>
> On Tue, Jun 16, 2026 at 07:49:44PM +0800, Weiming Shi wrote:
> > When a nested virtualisation guest is running its virtual EL2 (vEL2),
> > fixup_guest_exit() rewrites vcpu_cpsr() to the guest's virtual exception
> > level: a hardware PSTATE.M of EL1{t,h} is presented as EL2{t,h}. The
> > hardware, however, executes vEL2 at EL1.
> >
> > kvm_hyp_handle_mops() runs on the fast guest re-entry path, where it
> > clears the single-step bit and restores SPSR_EL2 directly from
> > vcpu_cpsr():
> >
> > *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
> > write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> >
> > For a guest hypervisor this writes the vEL2 view (PSTATE.M == EL2h) into
> > the hardware SPSR_EL2 without translating it back. The fast path re-enters
> > the guest via __guest_enter()/ERET without going through
> > __sysreg_restore_el2_return_state(), so neither to_hw_pstate() nor the
> > "return to a less privileged mode" safety check there (which would set
> > PSR_IL_BIT) is applied. The ERET therefore restores PSTATE.M = EL2h and
> > re-enters the guest at the real EL2 with a guest-controlled ELR, escaping
> > stage-2 and the guest/host boundary.
> >
> > This is reachable on a kernel with FEAT_MOPS running a KVM nested guest
> > (kvm-arm.mode=nested): KVM sets HCRX_EL2.MCE2, which the guest hypervisor
> > cannot clear for its own context (is_nested_ctxt() is false), so a vEL2
> > MOPS exception is taken to the host and dispatched to kvm_hyp_handle_mops()
> > with VCPU_IN_HYP_CONTEXT set.
> >
> > Translate EL2{t,h} back to EL1{t,h} before writing SPSR_EL2, mirroring
> > kvm_hyp_handle_eret(). For non-nested guests vcpu_cpsr() never holds an
> > EL2 mode, so the translation is a no-op and behaviour is unchanged.
>
> The changelog is unnecessarily verbose, instead:
>
> kvm_hyp_handle_mops() resets the single-step state machine as part of
> rewinding state for a MOPS exception by modifying vcpu_cpsr() and
> writing the result directly into hardware.
>
> In the case of nested virtualization, vcpu_cpsr() is a synthetic value
> such that the rest of KVM can deal with vEL2 cleanly. That means the
> value requires translation before being written into hardware, which is
> unfortunately missing from the MOPS handler.
>
> Fix it by directly modifying SPSR_EL2 and avoiding the synthetic state
> altogether, which will be resynchronized on the next 'full' exit back
> to KVM.
>
> Also:
>
> Cc: stable@vger.kernel.org
>
> Definitely meets the bar :)
>
> > Fixes: 2de451a329cf ("KVM: arm64: Add handler for MOPS exceptions")
> > Assisted-by: Claude:claude-opus-4-8
> > Reported-by: Zhong Wang <wangzhong.c0ss4ck@bytedance.com>
> > Reported-by: Xuanqing Shi <shixuanqing.11@bytedance.com>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> > ---
> > arch/arm64/kvm/hyp/include/hyp/switch.h | 23 ++++++++++++++++++++++-
> > 1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > index e9b36a3b27bbc..a6b7963ddbf0b 100644
> > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > @@ -448,6 +448,8 @@ static inline bool __populate_fault_info(struct kvm_vcpu *vcpu)
> >
> > static inline bool kvm_hyp_handle_mops(struct kvm_vcpu *vcpu, u64 *exit_code)
> > {
> > + u64 spsr, mode;
> > +
> > *vcpu_pc(vcpu) = read_sysreg_el2(SYS_ELR);
> > arm64_mops_reset_regs(vcpu_gp_regs(vcpu), vcpu->arch.fault.esr_el2);
> > write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> > @@ -457,7 +459,26 @@ static inline bool kvm_hyp_handle_mops(struct kvm_vcpu *vcpu, u64 *exit_code)
> > * instruction.
> > */
> > *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
> > - write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> > +
> > + /*
> > + * For a guest hypervisor, vcpu_cpsr() holds the vEL2 view
> > + * (PSTATE.M == EL2h) installed by fixup_guest_exit(), but vEL2
> > + * runs at EL1. Translate it back before restoring SPSR_EL2, as in
> > + * kvm_hyp_handle_eret().
> > + */
> > + spsr = *vcpu_cpsr(vcpu);
> > + mode = spsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> > + switch (mode) {
> > + case PSR_MODE_EL2t:
> > + mode = PSR_MODE_EL1t;
> > + break;
> > + case PSR_MODE_EL2h:
> > + mode = PSR_MODE_EL1h;
> > + break;
> > + }
> > + spsr = (spsr & ~(PSR_MODE_MASK | PSR_MODE32_BIT)) | mode;
> > +
> > + write_sysreg_el2(spsr, SYS_SPSR);
>
> As I allude to in the modified changelog, I'd rather we just manipulate
> the hardware value of SPSR_EL2 directly. We already do this in
> kvm_hyp_handle_eret()
>
> spsr = read_sysreg_el2(SYS_SPSR);
> write_sysreg_el2(spsr & ~DBG_SPSR_SS, SYS_SPSR);
>
> Thanks,
> Oliver
Hi Oliver,
Thanks for your review. I will send the v2 version later.
Best
Weiming Shi
^ permalink raw reply
* [PATCH] ARM: smp: Always separate IPI labels from counters
From: xuchenchen @ 2026-06-17 2:30 UTC (permalink / raw)
To: linux; +Cc: linux-arm-kernel, linux-kernel, xuchenchen
From: xuchenchen <xuchenchen@kylinos.cn>
The ARM IPI lines in /proc/interrupts print the IPI label separately
from the per-CPU counters. The first counter is printed with "%10u",
which only provides a leading space while the value is less than ten
digits.
Once the counter reaches ten digits, the output can become:
IPI0:1234129290 ...
Keep a fixed separator after the IPI label so the first counter is
always separated from the label, matching the arm64 output format.
Signed-off-by: xuchenchen <xuchenchen@kylinos.cn>
---
arch/arm/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b5fb4697b..721c5f9f9 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -551,7 +551,7 @@ void show_ipi_list(struct seq_file *p, int prec)
if (!ipi_desc[i])
continue;
- seq_printf(p, "%*s%u:", prec - 1, "IPI", i);
+ seq_printf(p, "%*s%u: ", prec - 1, "IPI", i);
for_each_online_cpu(cpu)
seq_printf(p, "%10u ", irq_desc_kstat_cpu(ipi_desc[i], cpu));
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Hongling Zeng @ 2026-06-17 2:28 UTC (permalink / raw)
To: Frank Li
Cc: Hongling Zeng, vkoul, Frank.Li, wens, jernej.skrabec, samuel,
mripard, arnd, dmaengine, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <ajG2aR70B4z6j1fd@SMW015318>
Hi Frank and Jernej Skrabec:
Thanks for all the review!
You're absolutely right.After checking virt-dma.h, I see that
desc_terminated is the correct queue for actively terminated transfers.
I'll update to use:
- vchan_terminate_vdesc(vd);
I'll send v3 ,Please help to review.
Best regards,
Hongling Zeng
在 2026年06月17日 04:47, Frank Li 写道:
> On Tue, Jun 16, 2026 at 02:04:49PM +0800, Hongling Zeng wrote:
>> 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>
>>
>> ---
>> Change in v2;
>> -Add pchan->desc != pchan->done check to prevent race condition
>> where completed descriptors could be double-added to desc_completed
>> list, causing list corruption
>> ---
>> 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..12d038ef5f2e 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 && pchan->desc != pchan->done) {
>> + 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);
> should It be in desc_terminated queue?
>
> ref: https://lore.kernel.org/dmaengine/ajETw7uwVx_U9o5F@ryzen/T/#m541c24b45fb425c6a8a81d800db225b58411447e
>
> Frank
>> }
>>
>> + vchan->cyclic = false;
>> vchan_get_all_descriptors(&vchan->vc, &head);
>>
>> if (pchan) {
>> --
>> 2.25.1
>>
^ permalink raw reply
* Re: [PATCH v2 01/11] ASoC: fsl_asrc: Use guard() for spin locks
From: Bui Duc Phuc @ 2026-06-17 2:25 UTC (permalink / raw)
To: Frank Li
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen,
Sascha Hauer, Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev
In-Reply-To: <ajAJt-EV1sSfG3OC@SMW015318>
Hi Frank,
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
Thank you for taking the time to review the series and for providing
the Reviewed-by tags.
Best regards,
Phuc
^ permalink raw reply
* [PATCH 1/5] ARM: dts: mediatek: mt8127: Fix indentation error
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Fix an indentation error caused by a space at the start of a line.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/mt8127.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mediatek/mt8127.dtsi b/arch/arm/boot/dts/mediatek/mt8127.dtsi
index aced173c2a52..bd61ec7e70c0 100644
--- a/arch/arm/boot/dts/mediatek/mt8127.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt8127.dtsi
@@ -75,7 +75,7 @@ uart_clk: dummy26m {
compatible = "fixed-clock";
clock-frequency = <26000000>;
#clock-cells = <0>;
- };
+ };
};
timer {
--
2.54.0
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: mediatek: mt8127: Add watchdog support
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add watchdog node and disable it by default as it was not present
initially.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/mt8127.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt8127.dtsi b/arch/arm/boot/dts/mediatek/mt8127.dtsi
index bd61ec7e70c0..1855dda42710 100644
--- a/arch/arm/boot/dts/mediatek/mt8127.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt8127.dtsi
@@ -159,5 +159,12 @@ uart3: serial@11005000 {
clocks = <&uart_clk>;
status = "disabled";
};
+
+ watchdog: watchdog@10007000 {
+ compatible = "mediatek,mt8127-wdt","mediatek,mt6589-wdt";
+ reg = <0 0x10007000 0 0x100>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
+ status = "disabled";
+ };
};
};
--
2.54.0
^ permalink raw reply related
* [PATCH 5/5] dt-bindings: watchdog: mediatek: Add MT8127
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for MT8127 SoC's watchdog which is compatible with MT6589's
one.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index 953629cb9558..e6e4546da0aa 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -40,6 +40,7 @@ properties:
- mediatek,mt7622-wdt
- mediatek,mt7623-wdt
- mediatek,mt7629-wdt
+ - mediatek,mt8127-wdt
- mediatek,mt8173-wdt
- mediatek,mt8188-wdt
- mediatek,mt8189-wdt
--
2.54.0
^ permalink raw reply related
* [PATCH 0/5] ARM: Basic support for Amazon ford tablet (MT8127)
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
This series of patches adds basic support for MT8127 SoC based Amazon ford
tablet and fixes a small indentation error in the dtsi file.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Zakariya Hadrami (5):
ARM: dts: mediatek: mt8127: Fix indentation error
ARM: dts: mediatek: mt8127: Add watchdog support
ARM: dts: mediatek: Add basic support for Amazon ford board
dt-bindings: arm: mediatek: Add MT8127 Amazon ford
dt-bindings: watchdog: mediatek: Add MT8127
.../devicetree/bindings/arm/mediatek.yaml | 4 ++
.../bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 ++++++++++++++++++++++
arch/arm/boot/dts/mediatek/mt8127.dtsi | 9 ++++-
5 files changed, 60 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260616-mt8127-amazon-ford-basic-1509d7052f7e
Best regards,
--
Zakariya Hadrami <zkh1@proton.me>
^ permalink raw reply
* [PATCH 3/5] ARM: dts: mediatek: Add basic support for Amazon ford board
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
This tablet uses a MediaTek MT8127 system-on-chip with 1GB of RAM.
It can currently boot into initramfs with a working UART and
Simple Framebuffer using already initialized panel by the bootloader.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 +++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/Makefile b/arch/arm/boot/dts/mediatek/Makefile
index 37c4cded0eae..a610bc75c7d9 100644
--- a/arch/arm/boot/dts/mediatek/Makefile
+++ b/arch/arm/boot/dts/mediatek/Makefile
@@ -14,5 +14,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-rfb-emmc.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
+ mt8127-amazon-ford.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
diff --git a/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
new file mode 100644
index 000000000000..21bdab0e43f8
--- /dev/null
+++ b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+#include "mt8127.dtsi"
+
+/ {
+ model = "MediaTek MT8127 Amazon Ford";
+ compatible = "amazon,ford", "mediatek,mt8127";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+
+ framebuffer0: framebuffer@b7a00000 {
+ compatible = "simple-framebuffer";
+ memory-region = <&framebuffer_reserved>;
+ width = <1024>;
+ height = <600>;
+ stride = <(1024 * 2)>;
+ format = "r5g6b5";
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0 0x80000000 0 0x40000000>;
+ };
+
+ reserved-memory {
+ framebuffer_reserved: framebuffer@b7a00000 {
+ reg = <0 0xb7a00000 0 0x1000000>;
+ no-map;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&watchdog {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH 4/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for the MT8127 based Amazon ford tablet.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 382d0eb4d0af..5ddc79689df9 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -124,6 +124,10 @@ properties:
- enum:
- mediatek,mt8127-moose
- const: mediatek,mt8127
+ - items:
+ - enum:
+ - amazon,ford
+ - const: mediatek,mt8127
- items:
- enum:
- mediatek,mt8135-evbp1
--
2.54.0
^ permalink raw reply related
* [PATCH v3] clk: mvebu: ap-cpu: fix missing clk_put() in ap_cpu_clock_probe()
From: Wentao Liang @ 2026-06-17 1:41 UTC (permalink / raw)
To: andrew, gregory.clement, sebastian.hesselbarth, mturquette, sboyd
Cc: bmasney, linux-arm-kernel, linux-clk, linux-kernel, Wentao Liang
The function ap_cpu_clock_probe() calls of_clk_get() to obtain a
reference to the parent clock for each CPU cluster, but it never
releases it with clk_put(). The returned clk is used only to read
the parent's name via __clk_get_name(), and the reference is leaked
on every successful cluster initialization as well as on the error
path when devm_clk_hw_register() fails.
Rather than adding clk_put() calls, replace the of_clk_get() +
__clk_get_name() pattern with of_clk_get_parent_name(), which is
the intended API for this use case and handles the reference
counting internally. This matches the pattern already used by the
sibling drivers clk-cpu.c and clk-corediv.c.
Fixes: f756e362d9384 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
v3: Replace incorrect Fixes tag.
v2: Replace of_clk_get() + __clk_get_name() with of_clk_get_parent_name()
as suggested by Brian Masney, instead of adding clk_put() calls.
Also correct the Fixes: tag to point to the original commit that
introduced the leak.
---
drivers/clk/mvebu/ap-cpu-clk.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mvebu/ap-cpu-clk.c b/drivers/clk/mvebu/ap-cpu-clk.c
index a8175908e353..1cf63c7a0bc3 100644
--- a/drivers/clk/mvebu/ap-cpu-clk.c
+++ b/drivers/clk/mvebu/ap-cpu-clk.c
@@ -288,7 +288,6 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
char *clk_name = "cpu-cluster-0";
struct clk_init_data init;
const char *parent_name;
- struct clk *parent;
u64 cpu;
cpu = of_get_cpu_hwid(dn, 0);
@@ -304,13 +303,12 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
if (ap_cpu_data->hws[cluster_index])
continue;
- parent = of_clk_get(np, cluster_index);
- if (IS_ERR(parent)) {
- dev_err(dev, "Could not get the clock parent\n");
+ parent_name = of_clk_get_parent_name(np, cluster_index);
+ if (!parent_name) {
+ dev_err(dev, "Could not get the clock parent name\n");
of_node_put(dn);
return -EINVAL;
}
- parent_name = __clk_get_name(parent);
clk_name[12] += cluster_index;
ap_cpu_clk[cluster_index].clk_name =
ap_cp_unique_name(dev, np->parent, clk_name);
@@ -328,11 +326,9 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
ret = devm_clk_hw_register(dev, &ap_cpu_clk[cluster_index].hw);
if (ret) {
of_node_put(dn);
- clk_put(parent);
return ret;
}
ap_cpu_data->hws[cluster_index] = &ap_cpu_clk[cluster_index].hw;
- clk_put(parent);
}
ap_cpu_data->num = cluster_index + 1;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] Bluetooth: btmtksdio: call cancel_work_sync() outside of host lock scope
From: Sean Wang @ 2026-06-17 0:56 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen, Sean Wang,
Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, stable
In-Reply-To: <20260616111224.152140-4-senozhatsky@chromium.org>
Hi,
On Tue, Jun 16, 2026 at 6:15 AM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> cancel_work_sync() should be called outside of host lock scope
> in order to avoid circular locking scenario:
>
> CPU0 CPU1
> close()/reset()
> sdio_claim_host()
> txrx_work
> sdio_claim_host() // sleeps
> cancel_work_sync() // sleeps
>
> In addition, when txrx_work() runs concurrently with close()/reset()
> it better not to re-enable interrupts by testing for BTMTKSDIO_FUNC_ENABLED
> and not BTMTKSDIO_HW_RESET_ACTIVE before C_INT_EN_SET write. However,
> btmtksdio_close() clears the BTMTKSDIO_FUNC_ENABLED too late (after
> cancel_work_sync() call). Move BTMTKSDIO_FUNC_ENABLED bit-clear earlier
> so that txrx_work can see concurrent close().
>
> Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> drivers/bluetooth/btmtksdio.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> index d8c8d2857527..207d04cc2282 100644
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -625,7 +625,9 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> } while (int_status && time_is_after_jiffies(txrx_timeout));
>
> /* Enable interrupt */
> - if (bdev->func->irq_handler)
> + if (bdev->func->irq_handler &&
> + test_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state) &&
> + !test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
> sdio_writel(bdev->func, C_INT_EN_SET, MTK_REG_CHLPCR, NULL);
>
> sdio_release_host(bdev->func);
> @@ -741,6 +743,8 @@ static int btmtksdio_close(struct hci_dev *hdev)
> if (!test_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state))
> return 0;
>
> + clear_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state);
> +
> sdio_claim_host(bdev->func);
>
> /* Disable interrupt */
> @@ -748,11 +752,12 @@ static int btmtksdio_close(struct hci_dev *hdev)
>
> sdio_release_irq(bdev->func);
>
> + sdio_release_host(bdev->func);
> cancel_work_sync(&bdev->txrx_work);
> + sdio_claim_host(bdev->func);
>
> btmtksdio_fw_pmctrl(bdev);
>
> - clear_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state);
> sdio_disable_func(bdev->func);
>
> sdio_release_host(bdev->func);
> @@ -1295,7 +1300,10 @@ static void btmtksdio_reset(struct hci_dev *hdev)
>
> sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
> skb_queue_purge(&bdev->txq);
> +
> + sdio_release_host(bdev->func);
> cancel_work_sync(&bdev->txrx_work);
> + sdio_claim_host(bdev->func);
>
> gpiod_set_value_cansleep(bdev->reset, 1);
> msleep(100);
The patch looks good to me. Inspired by your patch,
do you think should we add another patch to keep txrx_work out of the
reset window by rejecting TX during reset,
ignoring reset-time interrupts, and making queued workers exit early?
Some code like:
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -567,6 +567,8 @@ static void btmtksdio_txrx_work(struct work_struct *work)
pm_runtime_get_sync(bdev->dev);
sdio_claim_host(bdev->func);
+ if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
+ goto out;
/* Disable interrupt */
sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
@@ -628,6 +630,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
!test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
sdio_writel(bdev->func, C_INT_EN_SET, MTK_REG_CHLPCR, NULL);
+out:
sdio_release_host(bdev->func);
pm_runtime_put_autosuspend(bdev->dev);
@@ -646,6 +649,9 @@ static void btmtksdio_interrupt(struct sdio_func *func)
/* Disable interrupt */
sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
+ if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
+ return;
+
schedule_work(&bdev->txrx_work);
}
@@ -1250,6 +1256,9 @@ static int btmtksdio_send_frame(struct hci_dev
*hdev, struct sk_buff *skb)
{
struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
+ if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
+ return -EBUSY;
+
switch (hci_skb_pkt_type(skb)) {
case HCI_COMMAND_PKT:
hdev->stat.cmd_tx++;
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
>
^ permalink raw reply
* Re: [PATCH v6 03/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
From: Alexey Kardashevskiy @ 2026-06-17 0:50 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley, Cheloha, Scott
In-Reply-To: <20260604083959.1265923-4-aneesh.kumar@kernel.org>
On 4/6/26 18:39, Aneesh Kumar K.V (Arm) wrote:
> Propagate force_dma_unencrypted() into DMA_ATTR_CC_SHARED in the
> dma-direct allocation path and use the attribute to drive the related
> decisions.
>
> This updates dma_direct_alloc(), dma_direct_free(), and
> dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.
>
> Tested-by: Jiri Pirko <jiri@nvidia.com>
> Tested-by: Michael Kelley <mhklinux@outlook.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> kernel/dma/direct.c | 53 +++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index a741c8a2ee66..90dc5057a0c0 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -193,16 +193,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> bool remap = false, set_uncached = false;
> - bool mark_mem_decrypt = true;
> + bool mark_mem_decrypt = false;
> struct page *page;
> void *ret;
>
> + /*
> + * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
> + * attribute. The direct allocator uses it internally after it has
> + * decided that the backing pages must be shared/decrypted, so the
> + * rest of the allocation path can consistently select DMA addresses,
> + * choose compatible pools and restore encryption on free.
Why this limit?
Context: I am looking for a memory pool for a few shared pages (to do some guest<->host communication), SWIOTLB seems like the right fit but swiotlb_alloc() is not exported and dma_direct_alloc(DMA_ATTR_CC_SHARED) is not allowed. Thanks,
> + */
> + if (attrs & DMA_ATTR_CC_SHARED)
> + return NULL;
> +
> + if (force_dma_unencrypted(dev)) {
> + attrs |= DMA_ATTR_CC_SHARED;
> + mark_mem_decrypt = true;
> + }
> +
> size = PAGE_ALIGN(size);
> if (attrs & DMA_ATTR_NO_WARN)
> gfp |= __GFP_NOWARN;
>
> - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> - !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))
> + if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
> + DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev))
> return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
>
> if (!dev_is_dma_coherent(dev)) {
> @@ -236,7 +251,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> * Remapping or decrypting memory may block, allocate the memory from
> * the atomic pools instead if we aren't allowed block.
> */
> - if ((remap || force_dma_unencrypted(dev)) &&
> + if ((remap || (attrs & DMA_ATTR_CC_SHARED)) &&
> dma_direct_use_pool(dev, gfp))
> return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>
> @@ -312,12 +327,24 @@ void dma_direct_free(struct device *dev, size_t size,
> void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
> {
> phys_addr_t phys;
> - bool mark_mem_encrypted = true;
> + bool mark_mem_encrypted = false;
> struct io_tlb_pool *swiotlb_pool;
> unsigned int page_order = get_order(size);
>
> - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> - !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
> + /* see dma_direct_alloc() for details */
> + WARN_ON(attrs & DMA_ATTR_CC_SHARED);
> +
> + /*
> + * if the device had requested for an unencrypted buffer,
> + * convert it to encrypted on free
> + */
> + if (force_dma_unencrypted(dev)) {
> + attrs |= DMA_ATTR_CC_SHARED;
> + mark_mem_encrypted = true;
> + }
> +
> + if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
> + DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev)) {
> /* cpu_addr is a struct page cookie, not a kernel address */
> dma_free_contiguous(dev, cpu_addr, size);
> return;
> @@ -366,10 +393,14 @@ void dma_direct_free(struct device *dev, size_t size,
> struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
> dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
> {
> + unsigned long attrs = 0;
> struct page *page;
> void *ret;
>
> - if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
> + if (force_dma_unencrypted(dev))
> + attrs |= DMA_ATTR_CC_SHARED;
> +
> + if ((attrs & DMA_ATTR_CC_SHARED) && dma_direct_use_pool(dev, gfp))
> return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>
> if (is_swiotlb_for_alloc(dev)) {
> @@ -403,7 +434,11 @@ void dma_direct_free_pages(struct device *dev, size_t size,
> phys_addr_t phys;
> void *vaddr = page_address(page);
> struct io_tlb_pool *swiotlb_pool;
> - bool mark_mem_encrypted = true;
> + /*
> + * if the device had requested for an unencrypted buffer,
> + * convert it to encrypted on free
> + */
> + bool mark_mem_encrypted = force_dma_unencrypted(dev);
>
> /* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
> if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
--
Alexey
^ 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