From: Marc Zyngier <maz@kernel.org> To: Kuldeep Singh <singh.kuldeep87k@gmail.com> Cc: Rob Herring <robh+dt@kernel.org>, Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org Subject: Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property Date: Thu, 17 Mar 2022 21:46:12 +0000 [thread overview] Message-ID: <87fsngxnff.wl-maz@kernel.org> (raw) In-Reply-To: <20220317211024.GA99538@9a2d8922b8f1> On Thu, 17 Mar 2022 21:10:24 +0000, Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote: > > On Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote: > > On Thu, 17 Mar 2022 19:15:26 +0000, > > Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote: > > > > > > Arch timer either require clock-frequency property or doesn't need to > > > specify clock at all in DT. In general, frequency can be determined > > > internally and in case of brokern firmwares, need to extend > > > clock-frequency to pass info to driver. > > > > A clock frequency and a clock are not the same thing. > > Yes Marc, That's what I have mentioned in commit description. > > Driver uses "clock-frequency" property only and doesn't take inputs from > "clocks" property. So, any platform should refrain from defining such > entity at first place in DT. Binding also says the same i.e pass info > via "clock-frequency" property and no mention of "clocks". And what do you think provides this clock frequency? Do you believe it comes out of thin air? No, the driver doesn't use a clock, because it *assumes* the clock feeding the counter is enabled at all times. Does it mean such clock doesn't exist? > > > > > > > > > Aspeed BMC is the platform which defines clocks property, an invalid > > > entry which can be safely removed. > > > > Safely removed? Says who? Have you tested this change? > > Since "clocks" is never read by driver and driver incorporates > "clock-frequency" which was certainly not defined here, I believe this > reasoning is sufficient for my clause. As it's safe to remove an entry > which was never used. Really? And you have of course audited all possible firmware implementations (the bootloader, for example, which would *enable* this clock) and other operating systems than Linux that use the same DT and run on the same HW? The kernel tree unfortunately serves as a repository for all the DTs, including for payloads other than Linux. > Please note, it's just Aspeed BMC which had "clocks" defined, other > platforms which require input from DT have extended "clock-frequency" > property like I mentioned before. Again: clock frequency and clock are not the same thing. > I don't possess this platform physically,and did successfull compile > time testing. I have initally copied few Aspeed folks, they can help in > reviewing and confirming this. > > > > > > > > > Moreover, clocks also matches incorrectly with the regex pattern. > > > Remove this entry altogether to fix it. > > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+' > > > > NAK. That's not a reason to randomly butcher things. > > I hope I explained my reasons above. My position on this sort of change remains. Blindly changing existing DTs based on a warning provided by a tool that totally ignores the reality of what is out there is not acceptable. M. -- Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Kuldeep Singh <singh.kuldeep87k@gmail.com> Cc: Rob Herring <robh+dt@kernel.org>, Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org Subject: Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property Date: Thu, 17 Mar 2022 21:46:12 +0000 [thread overview] Message-ID: <87fsngxnff.wl-maz@kernel.org> (raw) In-Reply-To: <20220317211024.GA99538@9a2d8922b8f1> On Thu, 17 Mar 2022 21:10:24 +0000, Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote: > > On Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote: > > On Thu, 17 Mar 2022 19:15:26 +0000, > > Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote: > > > > > > Arch timer either require clock-frequency property or doesn't need to > > > specify clock at all in DT. In general, frequency can be determined > > > internally and in case of brokern firmwares, need to extend > > > clock-frequency to pass info to driver. > > > > A clock frequency and a clock are not the same thing. > > Yes Marc, That's what I have mentioned in commit description. > > Driver uses "clock-frequency" property only and doesn't take inputs from > "clocks" property. So, any platform should refrain from defining such > entity at first place in DT. Binding also says the same i.e pass info > via "clock-frequency" property and no mention of "clocks". And what do you think provides this clock frequency? Do you believe it comes out of thin air? No, the driver doesn't use a clock, because it *assumes* the clock feeding the counter is enabled at all times. Does it mean such clock doesn't exist? > > > > > > > > > Aspeed BMC is the platform which defines clocks property, an invalid > > > entry which can be safely removed. > > > > Safely removed? Says who? Have you tested this change? > > Since "clocks" is never read by driver and driver incorporates > "clock-frequency" which was certainly not defined here, I believe this > reasoning is sufficient for my clause. As it's safe to remove an entry > which was never used. Really? And you have of course audited all possible firmware implementations (the bootloader, for example, which would *enable* this clock) and other operating systems than Linux that use the same DT and run on the same HW? The kernel tree unfortunately serves as a repository for all the DTs, including for payloads other than Linux. > Please note, it's just Aspeed BMC which had "clocks" defined, other > platforms which require input from DT have extended "clock-frequency" > property like I mentioned before. Again: clock frequency and clock are not the same thing. > I don't possess this platform physically,and did successfull compile > time testing. I have initally copied few Aspeed folks, they can help in > reviewing and confirming this. > > > > > > > > > Moreover, clocks also matches incorrectly with the regex pattern. > > > Remove this entry altogether to fix it. > > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+' > > > > NAK. That's not a reason to randomly butcher things. > > I hope I explained my reasons above. My position on this sort of change remains. Blindly changing existing DTs based on a warning provided by a tool that totally ignores the reality of what is out there is not acceptable. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ 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-17 21:46 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 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 [this message] 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=87fsngxnff.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=andrew@aj.id.au \ --cc=devicetree@vger.kernel.org \ --cc=joel@jms.id.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-aspeed@lists.ozlabs.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=singh.kuldeep87k@gmail.com \ /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.