[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1abeef45-df5f-4779-86e1-b89f179ccd0c@prevas.dk>
Date: Fri, 31 May 2024 12:07:36 +0200
From: Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To: NXP Linux Team <linux-imx@....com>, LKML <linux-kernel@...r.kernel.org>
Cc: Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
Adam Ford <aford173@...il.com>, Shengjiu Wang <shengjiu.wang@...escale.com>
Subject: effect of multiple spba bus nodes
[resending because I never got a reply]
So commit 9424e7f064055 (arm64: dts: imx8mp: Enable spba-bus on AIPS3)
caused us a little trouble [*], but I got curious and tried figuring out
what effect wrapping those nodes in an spba-bus node actually had.
Grepping for the compatible string, one finds
Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml which says
It is an extension of
"simple-bus" because the SDMA controller uses this compatible flag to
determine which peripherals are available to it and the range over
which the SDMA can access.
OK. The one and only place in .c files where that compatible is
mentioned is in drivers/dma/imx-sdma.c, which does
of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
which I suppose just returns some random (well, not random, just the
first in DT) node. Many .dtsi files, e.g. the imx8mp.dtsi as case in
point, have more than one spba-bus, so how does that work?
Rasmus
[*] We assign stable netdev names based on the full path to the device's
DT node, but that logic broke when the CAN devices got new DT paths. I'm
not disputing the correctness of 9424e7f064055, we've adapted on our end.
Powered by blists - more mailing lists