linux-kernel - Re: [PATCH 2/2] of: Warn when of_property_read_bool() is used on non-boolean properties

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z4a2t9tRaiPSAovk@smile.fi.intel.com>
Date: Tue, 14 Jan 2025 21:10:47 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: "Rob Herring (Arm)" <robh@...nel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Len Brown <lenb@...nel.org>, Daniel Scally <djrscally@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Danilo Krummrich <dakr@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH 2/2] of: Warn when of_property_read_bool() is used on
 non-boolean properties

On Tue, Jan 14, 2025 at 07:35:22PM +0100, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Thu, Jan 9, 2025 at 8:42 PM Rob Herring (Arm) <robh@...nel.org> wrote:
> > The use of of_property_read_bool() for non-boolean properties is
> > deprecated. The primary use of it was to test property presence, but
> > that has been replaced in favor of of_property_present(). With those
> > uses now fixed, add a warning to discourage new ones.
> >
> > Signed-off-by: Rob Herring (Arm) <robh@...nel.org>
> 
> Thanks for your patch, which is now commit c141ecc3cecd7647 ("of:
> Warn when of_property_read_bool() is used on non-boolean properties")
> in dt-rh/for-next.
> 
> I have bisected a failure in secondary CPU bring-up on R-Car H1 (quad
> Cortex-A9 MPCore) to this commit:
> 
>      Detected Renesas R-Car Gen1 r8a7779 ES1.0
>      smp: Bringing up secondary CPUs ...
>     -CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
>     -CPU1: Spectre v2: using BPIALL workaround
>     -CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
>     -CPU2: Spectre v2: using BPIALL workaround
>     -CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
>     -CPU3: Spectre v2: using BPIALL workaround
>     -smp: Brought up 1 node, 4 CPUs
>     -SMP: Total of 4 processors activated (2000.00 BogoMIPS).
>     +CPU1: failed to come online
>     +CPU2: failed to come online
>     +CPU3: failed to come online
>     +smp: Brought up 1 node, 1 CPU
>     +SMP: Total of 1 processors activated (500.00 BogoMIPS).
>      CPU: All CPU(s) started in SVC mode.
> 
> Reverting this commit on top of my work tree fixes the issue, too.
> However, I do not see how this commit could impact CPU bring-up?
> 
> I added debug code to of_property_read_bool(), to print all look-ups.
> I only saw a few before CPU bring-up, nothing relevant:
> 
>      NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>     +OF: of_property_read_bool(interrupt-controller): 1
>      rcu: srcu_init: Setting srcu_struct sizes based on contention.
>     +OF: of_property_read_bool(interrupt-controller): 1
>      sched_clock: 64 bits at 250MHz, resolution 4ns, wraps every 4398046511102ns
>      clocksource: arm_global_timer: mask: 0xffffffffffffffff
> max_cycles: 0x7350b89c29, max_idle_ns: 881590431910 ns
>      Switching to timer-based delay loop, resolution 4ns
>     +OF: of_property_read_bool(interrupt-controller): 1
>     +OF: of_property_read_bool(always-on): 0
>      Console: colour dummy device 80x30
>      printk: legacy console [tty0] enabled
> 
> Perhaps something shifted in the code layout?  The obvious suspects
> (shmobile_boot_* and shmobile_smp_* asm code, secondary_startup(),
> addresses in arch/arm/mach-shmobile/platsmp-scu.c) are still at the
> same addresses as before...
> 
> Anyone with a clue?

Hmm... You meant the patch 2 troubles this?

-- 
With Best Regards,
Andy Shevchenko