[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250730175736.GD143191@e132581.arm.com>
Date: Wed, 30 Jul 2025 18:57:36 +0100
From: Leo Yan <leo.yan@....com>
To: Mark Brown <broonie@...nel.org>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>,
James Clark <james.clark@...aro.org>,
Anshuman Khandual <anshuman.khandual@....com>,
Yeoreum Yun <yeoreum.yun@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v5 04/10] coresight: Appropriately disable programming
clocks
On Wed, Jul 30, 2025 at 12:09:42PM +0100, Mark Brown wrote:
> On Wed, Jul 30, 2025 at 12:01:25PM +0100, Suzuki K Poulose wrote:
>
> > I would recommend using that and don't force the use of apb_clk/apb
> > for AMBA devices. If the firmware doesn't specify a clock, but does
> > specify the CoreSight components, it knows it better.
>
> And perhaps more to the point if a currently working system suddenly
> starts requiring additional clocks in it's binding that's an ABI break.
Yes, the change should not break any platforms if the DT binding is
passed correctly. I will update with devm_clk_get_optional_enabled().
Just for the record, I was a bit concerned that the driver might not
report a missing clock after switching to the optional clock API.
After discussed with Rob and Suzuki, I understand this should not be a
problem. Any missing clock issue can be caught by the DT schema static
checker, or a system hang during the development phase would remind
developers to bind clocks properly.
Thanks,
Leo
Powered by blists - more mailing lists