From: Rob Herring <robh@kernel.org> To: Kuldeep Singh <singh.kuldeep87k@gmail.com> Cc: Robin Murphy <robin.murphy@arm.com>, Marc Zyngier <maz@kernel.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <marc.zyngier@arm.com>, Mark Rutland <mark.rutland@arm.com>, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer Date: Sun, 20 Mar 2022 14:47:56 -0400 [thread overview] Message-ID: <Yjd23Gro6B6zWCrO@robh.at.kernel.org> (raw) In-Reply-To: <20220317212508.GB99538@9a2d8922b8f1> 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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Kuldeep Singh <singh.kuldeep87k@gmail.com> Cc: Robin Murphy <robin.murphy@arm.com>, Marc Zyngier <maz@kernel.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <marc.zyngier@arm.com>, Mark Rutland <mark.rutland@arm.com>, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer Date: Sun, 20 Mar 2022 14:47:56 -0400 [thread overview] Message-ID: <Yjd23Gro6B6zWCrO@robh.at.kernel.org> (raw) In-Reply-To: <20220317212508.GB99538@9a2d8922b8f1> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-03-20 18:48 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-17 19:15 [PATCH v2 0/3] Fix for arch timer users Kuldeep Singh 2022-03-17 19:15 ` Kuldeep Singh 2022-03-17 19:15 ` [PATCH v2 1/3] dt-bindings: timer: Rearrange compatible entries of arch timer Kuldeep Singh 2022-03-17 19:15 ` Kuldeep Singh 2022-03-17 19:15 ` [PATCH v2 2/3] dt-bindings: timer: Document arm,cortex-a7-timer in " Kuldeep Singh 2022-03-17 19:15 ` [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer " Kuldeep Singh 2022-03-17 20:25 ` Robin Murphy 2022-03-17 20:25 ` Robin Murphy 2022-03-17 21:25 ` Kuldeep Singh 2022-03-17 21:25 ` Kuldeep Singh 2022-03-20 18:47 ` Rob Herring [this message] 2022-03-20 18:47 ` Rob Herring 2022-03-21 11:52 ` Robin Murphy 2022-03-21 11:52 ` Robin Murphy 2022-03-23 18:35 ` Kuldeep Singh 2022-03-23 18:35 ` Kuldeep Singh 2022-03-25 21:23 ` Rob Herring 2022-03-25 21:23 ` Rob Herring 2022-04-11 12:35 ` Geert Uytterhoeven 2022-04-11 12:35 ` Geert Uytterhoeven 2022-03-17 19:15 ` [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property Kuldeep Singh 2022-03-17 19:15 ` Kuldeep Singh 2022-03-17 19:54 ` Marc Zyngier 2022-03-17 19:54 ` Marc Zyngier 2022-03-17 21:10 ` Kuldeep Singh 2022-03-17 21:10 ` Kuldeep Singh 2022-03-17 21:46 ` Marc Zyngier 2022-03-17 21:46 ` Marc Zyngier 2022-03-18 6:18 ` Joel Stanley 2022-03-18 6:18 ` Joel Stanley 2022-03-18 13:44 ` Krzysztof Kozlowski 2022-03-18 13:44 ` Krzysztof Kozlowski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Yjd23Gro6B6zWCrO@robh.at.kernel.org \ --to=robh@kernel.org \ --cc=daniel.lezcano@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=robin.murphy@arm.com \ --cc=singh.kuldeep87k@gmail.com \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.