[PATCH v2 0/2] dmaengine: apple-admac: Add support for M3 generation

[PATCH v2 0/2] dmaengine: apple-admac: Add support for M3 generation

[Sasha Finkelstein]

The ADMACs present in M3 series devices (t8122 and t603x SoCs) need
additional register writes in order to function correctly. Add a new
compatible chain for those, and change the driver to do the write.

To simplify the merge strategy, the device tree entries will be sent
in a future patch series.

Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
Changes in v2:
- Typo fix
- Link to v1: https://patch.msgid.link/20260725-t603x-admac-v1-0-6a4dec023f02@chaosmail.tech

---
Sasha Finkelstein (2):
      dt-bindings: dma: apple,admac: Add M3 generation ADMACs
      dmaengine: apple-admac: Add M3 generation ADMACs

 Documentation/devicetree/bindings/dma/apple,admac.yaml | 10 ++++++++--
 drivers/dma/apple-admac.c                              | 32 ++++++++++++++++++++++++++++++--
 2 files changed, 38 insertions(+), 4 deletions(-)
---
base-commit: 0ce37745d4bfbc493f718169c3974898ffec8ee7
change-id: 20260725-t603x-admac-a1b07a2ccb54

Best regards,
--  
Sasha Finkelstein <k@chaosmail.tech>

[PATCH v2 1/2] dt-bindings: dma: apple,admac: Add M3 generation ADMACs

[Sasha Finkelstein]

The admacs seen in M3-generation SoCs (t603x, t8122) need additional
configuration writes and so are getting a new compatible chain.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
 Documentation/devicetree/bindings/dma/apple,admac.yaml | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/apple,admac.yaml b/Documentation/devicetree/bindings/dma/apple,admac.yaml
index 6a200cbd7d02..5b4fd8348f99 100644
--- a/Documentation/devicetree/bindings/dma/apple,admac.yaml
+++ b/Documentation/devicetree/bindings/dma/apple,admac.yaml
@@ -10,7 +10,7 @@ description: |
   Apple's Audio DMA Controller (ADMAC) is used to fetch and store audio samples
   on SoCs from the "Apple Silicon" family.
 
-  The controller has been seen with up to 24 channels. Even-numbered channels
+  The controller has been seen with up to 32 channels. Even-numbered channels
   are TX-only, odd-numbered are RX-only. Individual channels are coupled to
   fixed device endpoints.
 
@@ -33,6 +33,12 @@ properties:
               - apple,t8103-admac
               - apple,t8112-admac
           - const: apple,admac
+      - items:
+          - enum:
+              - apple,t6030-admac
+              - apple,t6031-admac
+          - const: apple,t8122-admac
+      - const: apple,t8122-admac
 
   reg:
     maxItems: 1
@@ -43,7 +49,7 @@ properties:
       Clients specify a single cell with channel number.
 
   dma-channels:
-    maximum: 24
+    maximum: 32
 
   interrupts:
     minItems: 4

-- 
2.55.0

[PATCH v2 2/2] dmaengine: apple-admac: Add M3 generation ADMACs

[Sasha Finkelstein]

The admacs present on t8122 and t603x SoCs need additional writes in
order to operate correctly. The exact purpose of this register
is unknown

Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
 drivers/dma/apple-admac.c | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/apple-admac.c b/drivers/dma/apple-admac.c
index 14a5ee14a481..72ff677c8ce5 100644
--- a/drivers/dma/apple-admac.c
+++ b/drivers/dma/apple-admac.c
@@ -39,10 +39,14 @@
 
 #define FLAG_DESC_NOTIFY	BIT(16)
 
+#define T8122_UNK_28_VAL	0x200000
+
 #define REG_TX_START		0x0000
 #define REG_TX_STOP		0x0004
 #define REG_RX_START		0x0008
 #define REG_RX_STOP		0x000c
+#define REG_UNK_28		0x0028
+#define REG_UNK_2C		0x002c
 #define REG_IMPRINT		0x0090
 #define REG_TX_SRAM_SIZE	0x0094
 #define REG_RX_SRAM_SIZE	0x0098
@@ -127,6 +131,7 @@ struct admac_data {
 	struct mutex cache_alloc_lock;
 	struct admac_sram txcache, rxcache;
 
+	bool set_unk28;
 	int irq;
 	int irq_index;
 	int nchannels;
@@ -147,6 +152,10 @@ struct admac_tx {
 	struct list_head node;
 };
 
+struct admac_hw {
+	bool set_unk28;
+};
+
 static int admac_alloc_sram_carveout(struct admac_data *ad,
 				     enum dma_transfer_direction dir,
 				     u32 *out)
@@ -747,6 +756,11 @@ static int admac_device_config(struct dma_chan *chan,
 	u32 bus_width = readl_relaxed(ad->base + REG_BUS_WIDTH(adchan->no)) &
 		~(BUS_WIDTH_WORD_SIZE | BUS_WIDTH_FRAME_SIZE);
 
+	if (ad->set_unk28) {
+		writel_relaxed(T8122_UNK_28_VAL, ad->base + REG_UNK_28);
+		writel_relaxed(T8122_UNK_28_VAL, ad->base + REG_UNK_2C);
+	}
+
 	switch (is_tx ? config->dst_addr_width : config->src_addr_width) {
 	case DMA_SLAVE_BUSWIDTH_1_BYTE:
 		wordsize = 1;
@@ -805,6 +819,7 @@ static int admac_probe(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	struct admac_data *ad;
 	struct dma_device *dma;
+	const struct admac_hw *hw;
 	int nchannels;
 	int err, irq, i;
 
@@ -813,6 +828,9 @@ static int admac_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "missing or invalid dma-channels property\n");
 		return -EINVAL;
 	}
+	hw = of_device_get_match_data(&pdev->dev);
+	if (!hw)
+		return -EINVAL;
 
 	ad = devm_kzalloc(&pdev->dev, struct_size(ad, channels, nchannels), GFP_KERNEL);
 	if (!ad)
@@ -821,6 +839,7 @@ static int admac_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, ad);
 	ad->dev = &pdev->dev;
 	ad->nchannels = nchannels;
+	ad->set_unk28 = hw->set_unk28;
 	mutex_init(&ad->cache_alloc_lock);
 
 	/*
@@ -935,9 +954,18 @@ static void admac_remove(struct platform_device *pdev)
 	reset_control_rearm(ad->rstc);
 }
 
+static const struct admac_hw admac_t8103_hw = {
+	.set_unk28 = false,
+};
+
+static const struct admac_hw admac_t8122_hw = {
+	.set_unk28 = true,
+};
+
 static const struct of_device_id admac_of_match[] = {
-	{ .compatible = "apple,t8103-admac", },
-	{ .compatible = "apple,admac", },
+	{ .compatible = "apple,t8122-admac", .data = &admac_t8122_hw },
+	{ .compatible = "apple,t8103-admac", .data = &admac_t8103_hw },
+	{ .compatible = "apple,admac", .data = &admac_t8103_hw },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, admac_of_match);

-- 
2.55.0

Re: [PATCH v2 2/2] dmaengine: apple-admac: Add M3 generation ADMACs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The driver schedules a tasklet for DMA channel completion but fails to kill it upon driver unbind, leading to a Use-After-Free.
- [High] Missing memory barrier between CPU writes to the DMA buffer and triggering the hardware via MMIO.
--

--- Patch [2]: [PATCH v2 2/2] dmaengine: apple-admac: Add M3 generation ADMACs ---
commit 3e4665bdfbbc14988e79c929d83bff445def0885
Author: Sasha Finkelstein <k@chaosmail.tech>

dmaengine: apple-admac: Add M3 generation ADMACs
    
The admacs present on t8122 and t603x SoCs need additional writes in
order to operate correctly. The exact purpose of this register
is unknown

> diff --git a/drivers/dma/apple-admac.c b/drivers/dma/apple-admac.c
> index 14a5ee14a4815..72ff677c8ce54 100644
> --- a/drivers/dma/apple-admac.c
> +++ b/drivers/dma/apple-admac.c
[ ... ]
> @@ -935,9 +954,18 @@ static void admac_remove(struct platform_device *pdev)
>  	reset_control_rearm(ad->rstc);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but I noticed the driver schedules
a tasklet for DMA channel completion but fails to kill it upon driver unbind.

Does this leave the code open to a use-after-free? If an interrupt fires just
before free_irq() and schedules the tasklet, the tasklet may run after
admac_remove() returns and the devm_kzalloc managed memory (struct admac_data)
is freed.

Could we add a call to tasklet_kill() during the teardown sequence?

[Severity: High]
This is another pre-existing issue not touched by this patch, but I noticed
missing memory barriers when the hardware is started via MMIO.

Looking at admac_start_chan() and admac_cyclic_write_one_desc():

drivers/dma/apple-admac.c:admac_start_chan() {
    ...
	switch (admac_chan_direction(adchan->no)) {
	case DMA_MEM_TO_DEV:
		writel_relaxed(startbit, ad->base + REG_TX_START);
		break;
    ...
}

drivers/dma/apple-admac.c:admac_cyclic_write_one_desc() {
    ...
	writel_relaxed(lower_32_bits(addr), ad->base + REG_DESC_WRITE(channo));
	writel_relaxed(upper_32_bits(addr), ad->base + REG_DESC_WRITE(channo));
    ...
}

Could CPU writes to the DMA buffer be delayed and become visible to the DMA
controller only after it starts fetching data? 

Since writel_relaxed() does not include a memory barrier on ARM64 architectures
and spin_lock only provides ACQUIRE semantics, prior memory stores to the DMA
buffer might be reordered after the MMIO write. Does this require a memory
barrier to prevent transmitting stale data?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-t603x-admac-v2-0-e4b2bb6ca45e@chaosmail.tech?part=2