Hi Rob,

On 27/08/2025 17:16, Rob Herring wrote:

On Wed, Aug 27, 2025 at 10:39 AM Rob Herring [off-list ref] wrote:

quoted

On Fri, Aug 22, 2025 at 10:32 AM James Morse [off-list ref] wrote:

quoted

Probing MPAM is convoluted. MSCs that are integrated with a CPU may
only be accessible from those CPUs, and they may not be online.
Touching the hardware early is pointless as MPAM can't be used until
the system-wide common values for num_partid and num_pmg have been
discovered.

[...]

quoted

quoted

+static int mpam_dt_parse_resources(struct mpam_msc *msc, void *ignored)
+{
+       int err, num_ris = 0;
+       const u32 *ris_idx_p;
+       struct device_node *iter, *np;
+
+       np = msc->pdev->dev.of_node;
+       for_each_child_of_node(np, iter) {

Use for_each_available_child_of_node_scoped()

quoted

+               ris_idx_p = of_get_property(iter, "reg", NULL);

This is broken on big endian and new users of of_get_property() are
discouraged. Use of_property_read_reg().

Err, this is broken on little endian as the DT is big endian.

So this was obviously not tested as I'm confident you didn't test on BE.

'not tested' is shades of grey. I fed the FVP ~6 different DTB files to hit the different
paths through the driver. The FVP only has controls under RIS-0, so all of those only
defined RIS-0, and unsurprisingly didn't notice the helper isn't endian safe.


Thanks,

James