[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f9fb2174-5bc5-4c7b-b74b-8542b4f7cbe0@sirena.org.uk>
Date: Tue, 29 Jul 2025 12:31:35 +0100
From: Mark Brown <broonie@...nel.org>
To: Leo Yan <leo.yan@....com>
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
Subject: Re: [PATCH v5 04/10] coresight: Appropriately disable programming
clocks
On Mon, Jul 28, 2025 at 05:45:04PM +0100, Mark Brown wrote:
> On Thu, Jul 24, 2025 at 04:22:34PM +0100, Leo Yan wrote:
>
> Previously we would return NULL for any error (which isn't super great
> for deferred probe but never mind).
>
> > + pclk = devm_clk_get_enabled(dev, "apb_pclk");
> > + if (IS_ERR(pclk))
> > + pclk = devm_clk_get_enabled(dev, "apb");
>
> ...
>
> > return pclk;
> > }
>
> Now we pass errors back to the caller, making missing clocks fatal.
Thinking about this some more I think for compatiblity these clocks need
to be treated as optional - that's what the original code was
effectively doing, and I can imagine this isn't the only SoC which has
(hopefully) always on clocks and didn't wire things up in DT.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists