linux-kernel - Re: [STLinux Kernel] [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqLeD8uTmMYLFZ5Sh9=JV5s1xthvruXL-W=c=zcVS=G-ZA@mail.gmail.com>
Date:	Thu, 26 May 2016 08:20:39 -0500
From:	Rob Herring <robh@...nel.org>
To:	loic pallardy <loic.pallardy@...com>
Cc:	Gabriel Fernandez <gabriel.fernandez@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	"kernel@...inux.com" <kernel@...inux.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Michael Turquette <mturquette@...libre.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrzej Hajda <a.hajda@...sung.com>,
	linux-clk <linux-clk@...r.kernel.org>,
	Benjamin GAIGNARD <benjamin.gaignard@...com>,
	Olivier Bideau <olivier.bideau@...com>,
	Russell King <linux@...linux.org.uk>,
	Thierry Reding <treding@...dia.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Vincent ABRIOU <vincent.abriou@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Srinivas Kandagatla <srinivas.kandagatla@...il.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Kumar Gala <galak@...eaurora.org>,
	Dinh Nguyen <dinguyen@...nsource.altera.com>
Subject: Re: [STLinux Kernel] [PATCH 02/11] drivers: clk: st: Add clock
 propagation for audio clocks

On Thu, May 26, 2016 at 8:05 AM, loic pallardy <loic.pallardy@...com> wrote:
>
>
> On 05/26/2016 02:46 PM, Rob Herring wrote:
>>
>> On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez
>> <gabriel.fernandez@...aro.org> wrote:
>>>
>>> On 25 May 2016 at 19:24, Rob Herring <robh@...nel.org> wrote:
>>>>
>>>>
>>>> On Wed, May 18, 2016 at 10:41:23AM +0200, Gabriel Fernandez wrote:
>>>>>
>>>>> This patch allows fine tuning of the quads FS for audio clocks
>>>>> accuracy.
>>>>>
>>>>> Signed-off-by: Olivier Bideau <olivier.bideau@...com>
>>>>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@...aro.org>
>>>>> ---
>>>>>   .../devicetree/bindings/clock/st/st,flexgen.txt    |  1 +
>>>>>   drivers/clk/st/clk-flexgen.c                       | 24
>>>>> ++++++++++++++++++++++
>>>>>   2 files changed, 25 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt
>>>>> b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt
>>>>> index b7ee5c7..15b33c7 100644
>>>>> --- a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt
>>>>> +++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt
>>>>> @@ -60,6 +60,7 @@ This binding uses the common clock binding[2].
>>>>>   Required properties:
>>>>>   - compatible : shall be:
>>>>>     "st,flexgen"
>>>>> +  "st,stih407-clkgend0", "st,flexgen" (enable clock propagation on
>>>>> parent)
>>>>
>>>>
>>>> What do "d0" and "d2" refer to?
>>>>
>>>> This seems to indicate you have too much clock detail in the DT (with
>>>> individual clocks described) or not enough with genericish compatible
>>>> strings. What happens for the mext clock you need to adjust the flags
>>>> on? You should be able to make these adjustments without DT updates.
>>>> Perhaps you need a wider fixing of clock compatible strings.
>>>>
>>>> Rob
>>>
>>>
>>> Sorry i sent my response in html...
>>>
>>> Hi Rob,
>>>
>>> Thanks for reviewing.
>>>
>>> Can i remove
>>> "
>>> st,stih407-clkgend0" & "
>>> st,stih407-clkgend2" compatible strings and add proprieties instead ?
>>> I only need to activate 2 features and then we can keep generic
>>> compatible strings.
>>
>>
> Hi Rob,
>>
>> That is no different and suffers the same point I raised. It requires
>> updating the DT for any clock configuration change or enhancement.
>>
> Agree with you, DT update is needed as soon as a clock configuration should
> be changed. This is due to STiH clock driver design based on DT description
> of SoC clock tree.
>
> This clock driver was accepted 2 years ago. At the time being there was
> discussion about clock tree description location: driver or DT.
> Bad choice was done for this driver...
>
> If we decide to redesign STiH clock driver using in-driver clock tree
> description, this will modify STiH clock DT nodes description and so break
> DT backward compatibility.
>
> What's from your pov the best option?

You can break it once or every time you need a clock change. I'd go
with the former. Maybe more specific compatible strings throughout
alone would be enough rather than a flag day changing the binding.

Rob