linux-kernel - Re: [PATCH v4 3/6] ARM: at91/dt: define sama5d3 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]

Date:	Mon, 09 Dec 2013 18:02:21 +0100
From:	boris brezillon <b.brezillon@...rkiz.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	linux-arm-kernel@...ts.infradead.org,
	Russell King <linux@....linux.org.uk>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Mike Turquette <mturquette@...aro.org>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 3/6] ARM: at91/dt: define sama5d3 clocks

On 09/12/2013 17:48, Arnd Bergmann wrote:
> On Monday 09 December 2013, boris brezillon wrote:
>> Hello Arnd,
>>
>> On 09/12/2013 16:48, Arnd Bergmann wrote:
>>> On Monday 09 December 2013, boris brezillon wrote:
>>>>> You are adding "clock-names" properties in a lot of cases. Are you sure you
>>>>> are using the strings that are documented in the respective device bindings
>>>>> for each name? In a lot of cases, drivers just want an anonymous clock
>>>>> and we don't name them.
>>>> I rechecked it, and almost all drivers call [devm_]clk_get with a
>>>> specific clock
>>>> name, and as a result we must specify the "clock-names" property.
>>>> The only exceptions I found are the spi and PIT (Periodic Interval
>>>> Timer) drivers,
>>>> and "clock-names" property is not defined in these nodes.
>>> Yes, I understood that the *drivers* use the names, but are they actually
>>> documented in the device bindings? If not, it might be better to change the
>>> drivers.
>> We have to keep both clk system working for at91 platform (new CCF based
>> clk implementations and old clk implementations) for two reasons:
>> 1) the new clk implemetations are only compatible with DT enabled boards
>>       and some at91 boards are not yet ported to DT.
>> 2) we decided to move to the new clk implementations in multiple steps
>> (one SoC
>>       family after another) in order to ease PATCH review.
>>
>> If we change the drivers to avoid specific clock name request
>> ([devm]_clk_get(dev, NULL)),
>> we will have to change the old static clk lookup tables
>> (i.e.
>> http://lxr.free-electrons.com/source/arch/arm/mach-at91/at91sam9g45.c#L226,
>> http://lxr.free-electrons.com/source/arch/arm/mach-at91/at91sam9260.c#L202,
>> ...).
> Yes, that is a bit painful, but we really need to ensure that the drivers
> implement the documented binding. If they don't match we have to either
> review and change all the binding documents, or change the static clock
> tables and the drivers.
>
> Note that I have not checked your binding documents for the devices in
> question. If they already document these names, we don't need to change
> anything.

Are you talking about drivers or clk binding documentation ?
In either cases they're not defined :-), but I'd like to know which 
file(s) I
should update.

I'd rather not change the static clock lookup tables, but if you prefer this
approach (and Nicolas agrees), I'll propose a series modifying the drivers
and clk lookup table.

Whatever solution is choosen, I guess I'll have to update the drivers dt
binding documentation anyway ;-).

Best Regards,

Boris

>
> 	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/