arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Pavel Pisa]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

Dear maintainers and developers,

we are running CAN/CAN FD subsystem daily correct function
and latency evaluation on Zynq platform with our CAN FD IPs
on mainline and RT kernels for years already

  https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing

and we experience problem that attempt to set performance
scaling governor though

  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

started to fail on mainline kernels. The last day
when setting worked has been 2025-12-04 with
6.18.0-g8f7aa3d3c732 kernel. Then the cpufreq
/sys interface seems to be missing.

I have checked boot even with latest DTB and the
intreface is missing still. The driver seems to be
present

  /sys/bus/platform/drivers/cpufreq-dt

the code builds cpufreq-dt-platdev.o which contains
"xlnx,zynq-7000". The directory

  /sys/devices/system/cpu/cpufreq

is present, but it is empty. The module is present and
linked into kernel

  /sys/module/cpufreq

The next config options are set

  CONFIG_CPUFREQ_DT=y
  CONFIG_CPUFREQ_DT_PLATDEV=y

The whole kernel configuration is attached.

Please, have you some idea what could be a problem?
Is it necessary to update something or is something missing
in the device tree?

I can try to bisect to exact commit or add some debugging
printks into kernel to obtain more information,
but it would take some time. What else do you suggest?

Best wishes,

                Pavel

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    social:     https://social.kernel.org/ppisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

[-- Attachment #2: config-zynq-latester.gz --]
[-- Type: application/x-gzip, Size: 62789 bytes --]

Re: arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Viresh Kumar]

On 08-12-25, 17:58, Pavel Pisa wrote:
> Dear maintainers and developers,
> 
> we are running CAN/CAN FD subsystem daily correct function
> and latency evaluation on Zynq platform with our CAN FD IPs
> on mainline and RT kernels for years already
> 
>   https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing
> 
> and we experience problem that attempt to set performance
> scaling governor though
> 
>   /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>   /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
> 
> started to fail on mainline kernels. The last day
> when setting worked has been 2025-12-04 with
> 6.18.0-g8f7aa3d3c732 kernel. Then the cpufreq
> /sys interface seems to be missing.
> 
> I have checked boot even with latest DTB and the
> intreface is missing still. The driver seems to be
> present
> 
>   /sys/bus/platform/drivers/cpufreq-dt
> 
> the code builds cpufreq-dt-platdev.o which contains
> "xlnx,zynq-7000". The directory
> 
>   /sys/devices/system/cpu/cpufreq
> 
> is present, but it is empty. The module is present and
> linked into kernel
> 
>   /sys/module/cpufreq
> 
> The next config options are set
> 
>   CONFIG_CPUFREQ_DT=y
>   CONFIG_CPUFREQ_DT_PLATDEV=y
> 
> The whole kernel configuration is attached.
> 
> Please, have you some idea what could be a problem?
> Is it necessary to update something or is something missing
> in the device tree?
> 
> I can try to bisect to exact commit or add some debugging
> printks into kernel to obtain more information,
> but it would take some time. What else do you suggest?

Try reverting:

commit 6ea891a6dd37 ("cpufreq: dt-platdev: Simplify with of_machine_get_match_data()")

Also if you can provide your boot logs, it could be useful. Either the probing
of the cpufreq driver isn't attempted, or it just fails somewhere now.

-- 
viresh

Re: arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Viresh Kumar]

Fix Krzysztof's email address.

On 09-12-25, 11:07, Viresh Kumar wrote:
> On 08-12-25, 17:58, Pavel Pisa wrote:
> > Dear maintainers and developers,
> > 
> > we are running CAN/CAN FD subsystem daily correct function
> > and latency evaluation on Zynq platform with our CAN FD IPs
> > on mainline and RT kernels for years already
> > 
> >   https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing
> > 
> > and we experience problem that attempt to set performance
> > scaling governor though
> > 
> >   /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> >   /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
> > 
> > started to fail on mainline kernels. The last day
> > when setting worked has been 2025-12-04 with
> > 6.18.0-g8f7aa3d3c732 kernel. Then the cpufreq
> > /sys interface seems to be missing.
> > 
> > I have checked boot even with latest DTB and the
> > intreface is missing still. The driver seems to be
> > present
> > 
> >   /sys/bus/platform/drivers/cpufreq-dt
> > 
> > the code builds cpufreq-dt-platdev.o which contains
> > "xlnx,zynq-7000". The directory
> > 
> >   /sys/devices/system/cpu/cpufreq
> > 
> > is present, but it is empty. The module is present and
> > linked into kernel
> > 
> >   /sys/module/cpufreq
> > 
> > The next config options are set
> > 
> >   CONFIG_CPUFREQ_DT=y
> >   CONFIG_CPUFREQ_DT_PLATDEV=y
> > 
> > The whole kernel configuration is attached.
> > 
> > Please, have you some idea what could be a problem?
> > Is it necessary to update something or is something missing
> > in the device tree?
> > 
> > I can try to bisect to exact commit or add some debugging
> > printks into kernel to obtain more information,
> > but it would take some time. What else do you suggest?
> 
> Try reverting:
> 
> commit 6ea891a6dd37 ("cpufreq: dt-platdev: Simplify with of_machine_get_match_data()")
> 
> Also if you can provide your boot logs, it could be useful. Either the probing
> of the cpufreq driver isn't attempted, or it just fails somewhere now.

-- 
viresh

Re: arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Pavel Pisa]

[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]

Dear Viresh Kumar,

thanks for fast response.

On Tuesday 09 of December 2025 06:37:02 Viresh Kumar wrote:
> On 08-12-25, 17:58, Pavel Pisa wrote:
...
> > and we experience problem that attempt to set performance
> > scaling governor though
> >
> >   /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> >   /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
> >
...
> Try reverting:
>
> commit 6ea891a6dd37 ("cpufreq: dt-platdev: Simplify with
> of_machine_get_match_data()")
>
> Also if you can provide your boot logs, it could be useful. Either the
> probing of the cpufreq driver isn't attempted, or it just fails somewhere
> now.

The cpufreq is back after the revert.

I am attaching logs from failing mainline, then with
revert applied and their diff. At our standard debug
level, there is only single line interesting in the diff

+cpufreq: cpufreq_policy_online: CPU0: Running at unlisted initial frequency: 666666 kHz, changing to: 666667 kHz

The rest are some timing perturbations (lines swapped etc.)
and at the end mismatch in dtbocfg with test kernel.
But we have run whole round successfully when the revert patch
has been added into test automation system.

The /sys with the revert patch applied shows next
cpufreq entries (only some subentries shown)

/sys/devices/platform/cpufreq-dt
  driver -> ../../../bus/platform/drivers/cpufreq-dt
  driver_override (null)
  modalias platform:cpufreq-dt
  subsystem -> ../../../bus/platform
/sys/devices/system/cpu/cpufreq
  boost 0
  ondemand
  policy0
    affected_cpus 0 1
    related_cpus  0 1
    scaling_governor ondemand
    scaling_available_governors ondemand performance schedutil
/sys/devices/system/cpu/cpu0/cpufreq -> ../cpufreq/policy0
/sys/devices/system/cpu/cpu1/cpufreq -> ../cpufreq/policy0
/sys/bus/platform/devices/cpufreq-dt
  modalias  platform:cpufreq-dt
/sys/bus/platform/drivers/cpufreq-dt
/sys/bus/platform/drivers/cpufreq-dt/cpufreq-dt
/sys/module/cpufreq

So the all seems normal from my understanding.

The device-tree is slightly modified zynq-microzed.dts,

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/xilinx/zynq-microzed.dts

the console is switched to the UART0 which is routed
over galvanic insulator and break to reset cicuitry to
the FTDI device on baseboard. System is connected to
OrangePi testbed controller with test system power
supply control etc. 

If you have some patch to test or some suggestion
for some testing with more debugging options
switch on, then I will be happy to test that
as my time between teaching and other duties
allows.

Best wishes and thanks for help again,

                Pavel

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    social:     https://social.kernel.org/ppisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

[-- Attachment #2: boot-mainline.log.gz --]
[-- Type: application/x-gzip, Size: 8868 bytes --]

[-- Attachment #3: boot-with-revert.log.diff --]
[-- Type: text/x-diff, Size: 6028 bytes --]

--- boot-mainline.log	2025-12-09 10:25:58.444776512 +0100
+++ boot-with-revert.log	2025-12-09 10:26:14.148777077 +0100
@@ -1,5 +1,5 @@
 Booting Linux on physical CPU 0x0
-Linux version 6.18.0-dut (hronepa1@can-tester) (arm-linux-gnueabihf-gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP Tue Dec  9 04:21:45 CET 2025
+Linux version 6.18.0+ (hronepa1@can-tester) (arm-linux-gnueabihf-gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #2 SMP Tue Dec  9 10:01:18 CET 2025
 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
 CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
 OF: fdt: Machine model: Avnet MicroZed board
@@ -163,8 +163,8 @@
 9p: Installing v9fs 9p2000 file system support
 xor: measuring software checksum speed
    arm4regs        :  1074 MB/sec
-   8regs           :   818 MB/sec
-   32regs          :   815 MB/sec
+   8regs           :   815 MB/sec
+   32regs          :   816 MB/sec
    neon            :   769 MB/sec
 xor: using function: arm4regs (1074 MB/sec)
 Key type asymmetric registered
@@ -209,6 +209,7 @@
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 1 port detected
 i2c_dev: i2c /dev entries driver
+cpufreq: cpufreq_policy_online: CPU0: Running at unlisted initial frequency: 666666 kHz, changing to: 666667 kHz
 Xilinx Zynq CpuIdle Driver started
 sdhci: Secure Digital Host Controller Interface driver
 sdhci: Copyright(c) Pierre Ossman
@@ -220,27 +221,27 @@
 usbhid: USB HID core driver
 armv7-pmu f8891000.pmu: hw perfevents: no interrupt-affinity property, guessing.
 hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 (8000003f) counters available
-NET: Registered PF_INET6 protocol family
 mmc0: SDHCI controller on e0100000.mmc [e0100000.mmc] using ADMA
+NET: Registered PF_INET6 protocol family
 Segment Routing with IPv6
 In-situ OAM (IOAM) with IPv6
 sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
 NET: Registered PF_PACKET protocol family
 can: controller area network core
 NET: Registered PF_CAN protocol family
+mmc0: new high speed SDHC card at address aaaa
 can: raw protocol
 can: broadcast manager protocol
 can: netlink gateway - max_hops=1
 9pnet: Installing 9P2000 support
 Key type dns_resolver registered
 ThumbEE CPU extension supported.
+mmcblk0: mmc0:aaaa SB16G 14.8 GiB
 Registering SWP/SWPB emulation handler
+ mmcblk0: p1 p2
 Loading compiled-in X.509 certificates
 Btrfs loaded, zoned=no, fsverity=no
 of-fpga-region fpga-full: FPGA Region probed
-mmc0: new high speed SDHC card at address aaaa
-mmcblk0: mmc0:aaaa SB16G 14.8 GiB
- mmcblk0: p1 p2
 macb e000b000.ethernet eth0: PHY [e000b000.ethernet-ffffffff:00] driver [Marvell 88E1510] (irq=POLL)
 macb e000b000.ethernet eth0: configuring for phy/rgmii-id link mode
 macb e000b000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
@@ -307,31 +308,15 @@
 systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices...
 systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System.
 systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System.
+systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System.
+systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes.
 systemd[1]: Started systemd-journald.service - Journal Service.
 systemd-journald[179]: Received client request to flush runtime journal.
 random: crng init done
 macb e000b000.ethernet end0: renamed from eth0 (while UP)
-dtbocfg: loading out-of-tree module taints kernel.
-dtbocfg: 0.1.0
-dtbocfg: OK
-fpga_manager fpga0: writing system.bit.bin to Xilinx Zynq FPGA Manager
-OF: overlay: WARNING: memory leak will occur if overlay removed, property: /fpga-full/firmware-name
-OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/CTU_CAN_FD_0
-OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/CTU_CAN_FD_1
-OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/CTU_CAN_FD_2
-OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/CTU_CAN_FD_3
-OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/can_crossbar_0
-ctucanfd 43c30000.CTU_CAN_FD can2: ctu_can_fd device registered
-ctucanfd 43c30000.CTU_CAN_FD can2: ctucan_err_interrupt: ISR = 0x00000010, rxerr 0, txerr 0, error type 0, pos 31, ALC id_field 0, bit 0
-ctucanfd 43c30000.CTU_CAN_FD can2: state changes from CAN_STATE_STOPPED to CAN_STATE_ERROR_ACTIVE
-ctucanfd 43c70000.CTU_CAN_FD can3: ctu_can_fd device registered
-ctucanfd 43c70000.CTU_CAN_FD can3: ctucan_err_interrupt: ISR = 0x00000010, rxerr 0, txerr 0, error type 0, pos 31, ALC id_field 0, bit 0
-ctucanfd 43c70000.CTU_CAN_FD can3: state changes from CAN_STATE_STOPPED to CAN_STATE_ERROR_ACTIVE
-ctucanfd 43bf0000.CTU_CAN_FD can4: ctu_can_fd device registered
-ctucanfd 43bf0000.CTU_CAN_FD can4: ctucan_err_interrupt: ISR = 0x00000010, rxerr 0, txerr 0, error type 0, pos 31, ALC id_field 0, bit 0
-ctucanfd 43bf0000.CTU_CAN_FD can4: state changes from CAN_STATE_STOPPED to CAN_STATE_ERROR_ACTIVE
-ctucanfd 43bb0000.CTU_CAN_FD can5: ctu_can_fd device registered
-ctucanfd 43bb0000.CTU_CAN_FD can5: ctucan_err_interrupt: ISR = 0x00000010, rxerr 0, txerr 0, error type 0, pos 31, ALC id_field 0, bit 0
-ctucanfd 43bb0000.CTU_CAN_FD can5: state changes from CAN_STATE_STOPPED to CAN_STATE_ERROR_ACTIVE
+module dtbocfg: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time
+8<--- cut here ---
+Unhandled fault: external abort on non-linefetch (0x818) at 0xb6fae000
+[b6fae000] *pgd=30226831
 systemd-journald[179]: Oldest entry in /var/log/journal/fde1c56518324c06a97facd0c2f87076/system.journal is older than the configured file retention duration (1month), suggesting rotation.
 systemd-journald[179]: /var/log/journal/fde1c56518324c06a97facd0c2f87076/system.journal: Journal header limits reached or header out-of-date, rotating.

[-- Attachment #4: boot-with-revert.log.gz --]
[-- Type: application/x-gzip, Size: 8615 bytes --]

Re: arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Viresh Kumar]

Fixed Krzysztof's email id.

On 09-12-25, 14:47, Pavel Pisa wrote:
> Dear Viresh Kumar,
> 
> thanks for fast response.
> 
> On Tuesday 09 of December 2025 06:37:02 Viresh Kumar wrote:
> > On 08-12-25, 17:58, Pavel Pisa wrote:
> ...
> > > and we experience problem that attempt to set performance
> > > scaling governor though
> > >
> > >   /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> > >   /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
> > >
> ...
> > Try reverting:
> >
> > commit 6ea891a6dd37 ("cpufreq: dt-platdev: Simplify with
> > of_machine_get_match_data()")
> >
> > Also if you can provide your boot logs, it could be useful. Either the
> > probing of the cpufreq driver isn't attempted, or it just fails somewhere
> > now.
> 
> The cpufreq is back after the revert.

Great. Thanks for testing this.

Geert already highlighted an issue with the commit earlier [1].

Krzysztof can you provide a fix please ? Or do you want me to revert the patch
for now ?

> I am attaching logs from failing mainline, then with
> revert applied and their diff. At our standard debug
> level, there is only single line interesting in the diff
> 
> +cpufreq: cpufreq_policy_online: CPU0: Running at unlisted initial frequency: 666666 kHz, changing to: 666667 kHz

Which means the driver is probed. With the earlier mentioned patch, the
cpufreq-dt platform device isn't getting created probably and so driver probe.

> The rest are some timing perturbations (lines swapped etc.)
> and at the end mismatch in dtbocfg with test kernel.
> But we have run whole round successfully when the revert patch
> has been added into test automation system.
> 
> The /sys with the revert patch applied shows next
> cpufreq entries (only some subentries shown)
> 
> /sys/devices/platform/cpufreq-dt
>   driver -> ../../../bus/platform/drivers/cpufreq-dt
>   driver_override (null)
>   modalias platform:cpufreq-dt
>   subsystem -> ../../../bus/platform
> /sys/devices/system/cpu/cpufreq
>   boost 0
>   ondemand
>   policy0
>     affected_cpus 0 1
>     related_cpus  0 1
>     scaling_governor ondemand
>     scaling_available_governors ondemand performance schedutil
> /sys/devices/system/cpu/cpu0/cpufreq -> ../cpufreq/policy0
> /sys/devices/system/cpu/cpu1/cpufreq -> ../cpufreq/policy0
> /sys/bus/platform/devices/cpufreq-dt
>   modalias  platform:cpufreq-dt
> /sys/bus/platform/drivers/cpufreq-dt
> /sys/bus/platform/drivers/cpufreq-dt/cpufreq-dt
> /sys/module/cpufreq
> 
> So the all seems normal from my understanding.
> 
> The device-tree is slightly modified zynq-microzed.dts,
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/xilinx/zynq-microzed.dts
> 
> the console is switched to the UART0 which is routed
> over galvanic insulator and break to reset cicuitry to
> the FTDI device on baseboard. System is connected to
> OrangePi testbed controller with test system power
> supply control etc. 
> 
> If you have some patch to test or some suggestion
> for some testing with more debugging options
> switch on, then I will be happy to test that
> as my time between teaching and other duties
> allows.

-- 
viresh

[1] https://lore.kernel.org/all/CAMuHMdVJD4+J9QpUUs-sX0feKfuPD72CO0dcqN7shvF_UYpZ3Q@mail.gmail.com/

Re: arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Krzysztof Kozlowski]

On 10/12/2025 05:12, Viresh Kumar wrote:
> Fixed Krzysztof's email id.
> 
> On 09-12-25, 14:47, Pavel Pisa wrote:
>> Dear Viresh Kumar,
>>
>> thanks for fast response.
>>
>> On Tuesday 09 of December 2025 06:37:02 Viresh Kumar wrote:
>>> On 08-12-25, 17:58, Pavel Pisa wrote:
>> ...
>>>> and we experience problem that attempt to set performance
>>>> scaling governor though
>>>>
>>>>   /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>>>>   /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
>>>>
>> ...
>>> Try reverting:
>>>
>>> commit 6ea891a6dd37 ("cpufreq: dt-platdev: Simplify with
>>> of_machine_get_match_data()")
>>>
>>> Also if you can provide your boot logs, it could be useful. Either the
>>> probing of the cpufreq driver isn't attempted, or it just fails somewhere
>>> now.
>>
>> The cpufreq is back after the revert.
> 
> Great. Thanks for testing this.
> 
> Geert already highlighted an issue with the commit earlier [1].

I did not get it... Why do the people do not use get_maintainers which
properly handles mailmap... or actually check the commit on recent tree
because that one would have the old address properly mapped.

> 
> Krzysztof can you provide a fix please ? Or do you want me to revert the patch
> for now ?

I will take a look now, but I am at LPC so I am less responsive.

I did not get any logs though, but I will take a look now.


Best regards,
Krzysztof

Re: arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Viresh Kumar]

On 10-12-25, 05:40, Krzysztof Kozlowski wrote:
> I did not get it...

That's what I thought when I didn't see a response from you.

> > Krzysztof can you provide a fix please ? Or do you want me to revert the patch
> > for now ?
> 
> I will take a look now, but I am at LPC so I am less responsive.

Thanks.

> I did not get any logs though, but I will take a look now.

I bounced the email to you now. The issue is simple though, the table entry
doesn't have data for them and the recent code changed the logic a bit
unintentionally I guess.

-- 
viresh

Re: arm:xlnx,zynq-7000: missing CPU freq in /sys after 6.18.0-g8f7aa3d3c732 from 2025-12-04

[Krzysztof Kozlowski]

On 10/12/2025 05:48, Viresh Kumar wrote:
> On 10-12-25, 05:40, Krzysztof Kozlowski wrote:
>> I did not get it...
> 
> That's what I thought when I didn't see a response from you.
> 
>>> Krzysztof can you provide a fix please ? Or do you want me to revert the patch
>>> for now ?
>>
>> I will take a look now, but I am at LPC so I am less responsive.
> 
> Thanks.
> 
>> I did not get any logs though, but I will take a look now.
> 
> I bounced the email to you now. The issue is simple though, the table entry
> doesn't have data for them and the recent code changed the logic a bit
> unintentionally I guess.
> 

Yeah, I see the bug. My platform was passing tests because  it has
OPPv2, so the second if() was working. I will send a fix.

Best regards,
Krzysztof