[GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2

[Michal Simek]

Hi Arnd,

po 1. 6. 2026 v 22:39 odesílatel Arnd Bergmann <arnd at arndb.de> napsal:
>
> On Fri, May 29, 2026, at 12:15, Michal Simek wrote:
> > ----------------------------------------------------------------
> > arm64: Xilinx SOC changes for 7.2
> >
> > firmware:
> > - Add CSU register discovery with sysfs interface
>
> I looked at the contents here, and I'm not too fond of adding
> low-level register access interfaces to firmware drivers,
> that is usually a bad idea because it ties the interface
> to a particular platform.
>
> I have no idea what 'CSU registers' are and the ABI
> description does not really explain that either.

It is described in the commit message.
Configuration Security Unit (CSU) registers

And currently supported regs are described there too.
    Currently supported registers include:
      - multiboot (CSU_MULTI_BOOT)
      - idcode (CSU_IDCODE, read-only)
      - pcap-status (CSU_PCAP_STATUS, read-only)

multiboot - chip can boot from different offsets. (spi in 64kB offsets,
fat different boot image name).
idcode - full chip ID
pcap-status - to find out the state of programmable logic.

> What type of userspace would access those, and why can't
> this be done in a portable way?

multiboot is useful for A/B updates when used. It is also pointing to
where the boot image exactly is.

idcode/pcap for fpga programming case. That your bitstream matches the device
you use.
Scripts or user programs can use them.

IDcode could be the part of SMCCC_ARCH_SOC_ID but we can't change what
we have done in the past
but we plan to implement plat_get_soc_name() which will also contain
IDcode. That's the one
where a standard interface could be used.

If you have any suggestions on how to do it in a portable way please
let me know.

> > zynqmp_power:
> > - Fix race condition in event registration
> > - Fix shutdown and free rx mailbox channel
>
> No objections here, though they look like bugfixes that
> may be 7.1 material. Up to you, but don't be shy about
> sending things as bugfixes when they address real
> problems, it's better than waiting for the merge window
> and then immediately asking for a backport.

It is more about time not about being shy to send it.

Thanks,
Michal