lkml.org 
[lkml]   [2022]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer
On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> 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 agree with Robin on dropping. More specific here is not useful. If
we're going to add some cores, then we should add every core
implementation.

If one has a big.LITTLE system with A15/A7 what would be the right
compatible value?

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

Every situation tends to be different.

Rob

\
 
 \ /
  Last update: 2022-03-20 19:49    [W:0.221 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site