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]
Date:   Fri, 18 Mar 2022 02:55:08 +0530
From:   Kuldeep Singh <singh.kuldeep87k@...il.com>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Marc Zyngier <maz@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Mark Rutland <mark.rutland@....com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer
 in arch timer

On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> On 2022-03-17 19:15, Kuldeep Singh wrote:
> > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > conjugation with "arm,armv7-timer". Since, initial entry is not
> > documented, it start raising dtbs_check warnings.
> > 
> > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > 
> > Document this compatible to address it. The motivation to add this
> > change is taken from an already existing entry "arm,cortex-a15-timer".
> > Please note, this will not hurt any arch timer users.
> 
> Eh, if it's never been documented or supported, I say just get rid of it.
> The arch timer interface is by definition part of a CPU, and we can tell
> what the CPU is by reading its ID registers. Indeed that's how the driver
> handles the non-zero number of CPU-specific errata that already exist - we
> don't need compatibles for that.
> 
> In some ways it might have been nice to have *SoC-specific* compatibles
> given the difficulty some integrators seem to have had in wiring up a stable
> count *to* the interface, but it's not like they could be magically added to
> already-deployed DTs after a bug is discovered, and nor could we have
> mandated them from day 1 just in case and subsequently maintained a binding
> that is just an ever-growing list of every SoC. Oh well.

Robin, A similar discussion was already done on v1 thread. Please see
below for details:
https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/

And final outcome of discussion turns out to add this compatible string.

I see people with different set of perspective in regard to whether keep
compatible string or not. We should have some sort of evidences to
support claims so that next time when similar situation arises, we'll be
aware beforehand how to proceed.

- Kuldeep
> 
> Robin.
> 
> > Signed-off-by: Kuldeep Singh <singh.kuldeep87k@...il.com>
> > ---
> >   Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > index ba2910f0a7b2..ea390e5df71d 100644
> > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > @@ -26,6 +26,7 @@ properties:
> >             - arm,armv8-timer
> >         - items:
> >             - enum:
> > +              - arm,cortex-a7-timer
> >                 - arm,cortex-a15-timer
> >             - const: arm,armv7-timer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ