[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9be7d712-33ae-3e5b-beeb-a14faa51e777@ti.com>
Date: Thu, 18 Jan 2018 13:23:08 +0530
From: Sekhar Nori <nsekhar@...com>
To: David Lechner <david@...hnology.com>, <linux-clk@...r.kernel.org>,
<devicetree@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>
CC: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...eaurora.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Kevin Hilman <khilman@...nel.org>,
Adam Ford <aford173@...il.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 11/44] clk: davinci: Add platform information for TI
DA830 PSC
On Wednesday 17 January 2018 11:02 PM, David Lechner wrote:
>>>>> + clk_register_clkdev(clk_data->clks[3], "gpio", NULL);
>>>>
>>>> This is pretty bad (and no fault of yours) - having a con_id but no
>>>> device name. Can you please make a pre-series which passes NULL con_id
>>>> in gpio-davinci.c?
>>>
>>> I'll give it a try. This is complicated by the fact that the con_id has
>>> made it's way into the device tree bindings. However, I think we can
>>> safely deprecate clock-names = "gpio" in the device tree bindings since
>>> we can make the driver ignore that property to preserve backwards
>>> compatibility.
>
> Agreed.
>
>> I don't think this breaks DT-backward compatibility. Passing a NULL
>> con_id in driver should find the clock for that device even if DT entry
>> has clock-names present. As far as I can read clk_find().
>>
>> The less intrusive alternate is to add the GPIO device name in the table
>> here, while keeping the con_id and keeping the driver untouched. The
>> advantage of that is lesser number of dependent patches for this series
>> to go in.
>>
>> Later once CCF conversion has been there in the kernel for one full
>> release and no regressions, these other clean-ups can be done.
>
> I like this approach.
One downside is that we will have to have clock-names = "gpio" in da850
device-tree too. Since its already present in keystone already, I don't
think adding one more is such a big issue.
Thanks,
Sekhar
Powered by blists - more mailing lists