[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <075db1ba-e15c-4c3c-9430-99c866eca24d@sirena.org.uk>
Date: Wed, 31 May 2023 14:20:57 +0100
From: Mark Brown <broonie@...nel.org>
To: William Qiu <william.qiu@...rfivetech.com>
Cc: devicetree@...r.kernel.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Emil Renner Berthing <kernel@...il.dk>,
Ziv Xu <ziv.xu@...rfivetech.com>
Subject: Re: [PATCH v1 2/3] spi: cadence-quadspi: Add clock configuration for
StarFive JH7110 QSPI
On Wed, May 31, 2023 at 02:19:16PM +0800, William Qiu wrote:
> On 2023/5/30 18:33, Mark Brown wrote:
> > You could always specify a different array of clocks depending on which
> > compatible the driver sees, just like you'd conditionally request clocks
> > individually.
> If specify a different array of clocks depending on which compatible
> the driver sees, since there will also be clock operations in the suspend
> and resume interfaces, this can make the code look complicated.
If you store the clock count and array in the driver data that should be
fairly simple I think.
> as following:
> /* Obtain QSPI clock. */
> cqspi->num_clks = devm_clk_bulk_get_all(dev, &cqspi->clks);
> if (cqspi->num_clks < 0) {
> dev_err(dev, "Cannot claim QSPI clock: %u\n", cqspi->num_clks);
> return -EINVAL;
> }
> This way, the code will look simpler and clearer. How do you think
> about it.
I'm not clear how enable and disable would then work?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists