[v2,0/3] Fix for arch timer users

This patchset is an attempt to fix arch timer users and with at it,
resolve dtbs_check warning.

v1 version can be found at below:
https://lore.kernel.org/linux-devicetree/20220316095433.20225-1-singh.kuldeep87k@gmail.com/

v2:
- Add Krzystof Rb tag in patch1
- Reword patch 2 commit message
- Drop v1 patch3 as driver change is not required
- Add new patch3, a fix in Aspeed DT to resolve dtbs_check warning

Patch 1 is done in preparation for following patches which defines
compatibles order in more clear way.
Patch 2 documents arm,cortex-a7-timer entry in bindings similar to an
existing entry arm,cortex-a15-timer.
Patch 3 fix Aspeed DT which is not compliant with binding as of now.

Kuldeep Singh (3):
  dt-bindings: timer: Rearrange compatible entries of arch timer
  dt-bindings: timer: Document arm,cortex-a7-timer in arch timer
  ARM: dts: aspeed: Remove arch timer clocks property

 .../devicetree/bindings/timer/arm,arch_timer.yaml   | 13 +++++--------
 arch/arm/boot/dts/aspeed-g6.dtsi                    |  1 -
 2 files changed, 5 insertions(+), 9 deletions(-)

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.

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

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

	M.

> 
> Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
> ---
>  arch/arm/boot/dts/aspeed-g6.dtsi | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
> index c32e87fad4dc..d5ef9aceb632 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -64,7 +64,6 @@ timer {
>  			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>  			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>  			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
> -		clocks = <&syscon ASPEED_CLK_HPLL>;
>  		arm,cpu-registers-not-fw-configured;
>  		always-on;
>  	};
> -- 
> 2.25.1
> 
>

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

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

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.

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.

- Kuldeep

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.

On Thu, 17 Mar 2022 at 21:46, Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 17 Mar 2022 21:10:24 +0000,
> Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:

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

Thanks Marc for stating this. I share this view; we shouldn't go
around deleting parts of device trees for the sake of the bindings.
It's been happening across the tree, and I think it's to the detriment
of the supported hardware.

In the case of this particular change: I suspect this property was
there for early bringup, before the firmware was in place to configure
CNTFRQ. Looking back in time we had:

 clock-frequency = <25000000>;
 arm,cpu-registers-not-fw-configured;

I'm not sure why that changed from clock-frequency to clocks when the
device tree was mainlined.

That was bringup. These days, the vendor u-boot programs CNTFRQ with a
value for the system. This code is also in mainline u-boot, so as long
as you're running one of those firmwares the standard method will
work.

The qemu model also sets CNTFRQ, so loading the kernel without going
through u-boot will be fine there too.

Given that, I think we can go ahead with removing the property in this case.

Reviewed-by: Joel Stanley <joel@jms.id.au>

I'll take the patch through my aspeed tree.

Cheers,

Joel

On 17/03/2022 20:15, Kuldeep Singh wrote:
> 
> 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]+'

Except of ongoing discussion, this paragraph is incorrect.  There is no
incorrect match of regex pattern. The field is simply not documented in
the bindings (not allowed by bindings). This paragraph is actually
confusing and misleading.


Best regards,
Krzysztof