quoted

+static int fsl_sai_probe(struct platform_device *pdev) {

[...]

quoted

+
+	sai->dma_params_rx.addr =3D res->start + SAI_RDR;
+	sai->dma_params_rx.maxburst =3D 6;
+	index =3D of_property_match_string(np, "dma-names", "rx");
+	ret =3D of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
+				&dma_args);
+	if (ret)
+		return ret;
+	sai->dma_params_rx.slave_id =3D dma_args.args[1];
+
+	sai->dma_params_tx.addr =3D res->start + SAI_TDR;
+	sai->dma_params_tx.maxburst =3D 6;
+	index =3D of_property_match_string(np, "dma-names", "tx");
+	ret =3D of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
+				&dma_args);
+	if (ret)
+		return ret;
+	sai->dma_params_tx.slave_id =3D dma_args.args[1];

=20
The driver should not have to manually parse the dma devicetree
properties, this is something that should be handled by the dma engine
driver.
=20

Yes, the dma engine interface has already parsed the slave_id while
the dma customer requesting one dma channel.

Though this also could be a way to pass the slave_id to dma driver, but the=
=20
dma driver uses the way while requesting dma channels.

So I'll drop this code later.