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

On Tue, Jun 2, 2026, at 14:29, Michal Simek wrote:
> po 1. 6. 2026 v 22:39 odesílatel Arnd Bergmann <[email protected]> napsal:
>>
>> 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.

That sounds like it should use a reboot-mode driver. There is
a patchset that streamlines the reboot parameter passing that
will hopefully get merged soon, see:

https://lore.kernel.org/all/20260514-arm-psci-system_reset2-vendor-reboots-v22-0-28a5bde07483@oss.qualcomm.com/

If you can't fit this into PSCI reboot arguments, you can
add a custom driver here that picks the A/B update etc

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

You already have an fpga driver, right? Why is that not part of
its user interface?

> 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.

I'm not sure what plat_get_soc_name() does, I don't see that in
the current sources, but can have multiple soc_device drivers
and use soc_device_match() in drivers to compare the ID
string from the platform with a known lists for things like
driver quirks.

If there is a hardware interface to find out the ID, just add
a driver that registers another soc_device in addition to the
SMCCC one, and soc_device_match() will attempt to match each
one separately.

>> > 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.

Ok.

     Arnd