* [GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2
@ 2026-05-29 10:15 Michal Simek
2026-06-01 20:39 ` Arnd Bergmann
0 siblings, 1 reply; 5+ messages in thread
From: Michal Simek @ 2026-05-29 10:15 UTC (permalink / raw)
To: SoC Team; +Cc: linux-arm
Hi,
please pull these 4 patches to your tree.
Thanks,
Michal
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-soc-for-7.2
for you to fetch changes up to 47d7bca76dd4f36ba0525d761f247c76ec9e4b17:
firmware: zynqmp: Add dynamic CSU register discovery and sysfs
interface (2026-05-25 16:09:15 +0200)
----------------------------------------------------------------
arm64: Xilinx SOC changes for 7.2
firmware:
- Add CSU register discovery with sysfs interface
zynqmp_power:
- Fix race condition in event registration
- Fix shutdown and free rx mailbox channel
----------------------------------------------------------------
Prasanna Kumar T S M (2):
soc: xilinx: Fix race condition in event registration
soc: xilinx: Shutdown and free rx mailbox channel
Ronak Jain (2):
Documentation: ABI: add sysfs interface for ZynqMP CSU registers
firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface
Documentation/ABI/stable/sysfs-driver-firmware-zynqmp | 33 +++
MAINTAINERS | 10 +
drivers/firmware/xilinx/Makefile | 2 +-
drivers/firmware/xilinx/zynqmp-csu-reg.c | 258
++++++++++++++++++++
drivers/firmware/xilinx/zynqmp-csu-reg.h | 18 ++
drivers/firmware/xilinx/zynqmp.c | 6 +
drivers/soc/xilinx/zynqmp_power.c | 47 ++--
include/linux/firmware/xlnx-zynqmp.h | 4 +-
8 files changed, 349 insertions(+), 29 deletions(-)
create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.c
create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.h
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2
2026-05-29 10:15 [GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2 Michal Simek
@ 2026-06-01 20:39 ` Arnd Bergmann
2026-06-02 12:29 ` Michal Simek
0 siblings, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2026-06-01 20:39 UTC (permalink / raw)
To: Michal Simek, SoC Team; +Cc: linux-arm
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.
What type of userspace would access those, and why can't
this be done in a portable way?
> 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.
Arnd
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2
2026-06-01 20:39 ` Arnd Bergmann
@ 2026-06-02 12:29 ` Michal Simek
2026-06-02 13:00 ` Arnd Bergmann
0 siblings, 1 reply; 5+ messages in thread
From: Michal Simek @ 2026-06-02 12:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: SoC Team, linux-arm
Hi Arnd,
po 1. 6. 2026 v 22:39 odesílatel Arnd Bergmann <arnd@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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2
2026-06-02 12:29 ` Michal Simek
@ 2026-06-02 13:00 ` Arnd Bergmann
2026-06-02 13:45 ` Michal Simek
0 siblings, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2026-06-02 13:00 UTC (permalink / raw)
To: Michal Simek; +Cc: SoC Team, linux-arm
On Tue, Jun 2, 2026, at 14:29, Michal Simek wrote:
> po 1. 6. 2026 v 22:39 odesílatel Arnd Bergmann <arnd@arndb•de> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2
2026-06-02 13:00 ` Arnd Bergmann
@ 2026-06-02 13:45 ` Michal Simek
0 siblings, 0 replies; 5+ messages in thread
From: Michal Simek @ 2026-06-02 13:45 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: SoC Team, linux-arm
út 2. 6. 2026 v 15:00 odesílatel Arnd Bergmann <arnd@arndb•de> napsal:
>
> On Tue, Jun 2, 2026, at 14:29, Michal Simek wrote:
> > po 1. 6. 2026 v 22:39 odesílatel Arnd Bergmann <arnd@arndb•de> 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:
not really. When you ask for a reboot you could reuse this mechanism
to boot to a different
image but in A/B which would be a very hard way to do it. We do use
ARM DEN0118 spec
with mdata for it. It means actual change in multiboot is done by low
level firmware where
different values are read based on mdata structure.
> 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
A/B in our way will be handled via capsule update/u-boot via ESP partition.
Maybe it was misleading to point to A/B. Even when you have a single image
it is useful to know which offset was used for boot. Because you can
have fallback images
if the first one is broken/corrupted.
I was more thinking that maybe useful would be to share it via nvmem
like it is done for some other options
drivers/nvmem/zynqmp_nvmem.c.
> > 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?
The fpga driver is just loading the boot image and providing a way to
firmware to do it.
There are different types of bitstreams/formats. Bitstream in bit
format has header which you can validate,
bitstream in bin format don't have this header. Then you have also
encrypted bitstreamed, compressed one, etc.
When you have support for more silicons (different PL sizes) you
should know which bitstreams need to be loaded,
passed to be programmed.
Maybe at the end of a day instead of creating a custom driver with a
custom sysfs interface we can create a nvmem driver
which can dynamically create cells based on firmware 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.
Sorry that's function name from TF-A
In Linux kernel you have smccc_soc_name_init()
in our case version/revisions are defined (and to be fair to say our
firmware messes up with version/revision)
but SOC_NAME is unused today for us and that can be used for passing more
information about system/chip.
> 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.
yep.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-06-02 13:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-29 10:15 [GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2 Michal Simek
2026-06-01 20:39 ` Arnd Bergmann
2026-06-02 12:29 ` Michal Simek
2026-06-02 13:00 ` Arnd Bergmann
2026-06-02 13:45 ` Michal Simek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox