[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZlWQB1q+8cE+mOAN@shell.armlinux.org.uk>
Date: Tue, 28 May 2024 09:04:23 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Samuel Holland <samuel.holland@...ive.com>
Cc: Stephen Boyd <sboyd@...nel.org>, Guenter Roeck <linux@...ck-us.net>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Dinh Nguyen <dinguyen@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Rob Herring <robh@...nel.org>, Yang Li <yang.lee@...ux.alibaba.com>,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] clk: sifive: Do not register clkdevs for PRCI clocks
On Mon, May 27, 2024 at 05:14:12PM -0700, Samuel Holland wrote:
> These clkdevs were unnecessary, because systems using this driver always
> look up clocks using the devicetree. And as Russell King points out[1],
> since the provided device name was truncated, lookups via clkdev would
> never match.
There is another reason they would never match - clkdev has always been
about matching the clock _consumer_ using the device name and connection
name to the producer. The device and connection name passed into clkdev
should always be the consumer (it's documented as such.)
Providing the producer device name to clkdev when registering an entry
will mean that clk_get(consumer_dev, consumer_name) will fail to find
the entry in clkdev's table, and thus fail to find the clock.
So, this code has been incorrect from the very start.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists