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] [day] [month] [year] [list]

Message-Id: <201312092205.08933.arnd@arndb.de>
Date:	Mon, 9 Dec 2013 22:05:08 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	boris brezillon <b.brezillon@...rkiz.com>
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 Monday 09 December 2013, boris brezillon wrote:
> 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 mean bindings for the devices using these clocks. Each of them should
list among its properties something like

|Mandatory properties:
|  clocks:	One phandle and clock specifier for xxxx
|  clock-names:	The name of this clock, must be "xxxx"

Of course if we decide to make it an anonymous clock, we still need to
document the fact that the clock is required.

> 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 ;-).

Ok. FWIW, I think the best way to stage the clock updates (if the decision
is to make them anonymous) would be to duplicate all the clocks in question
in a first patch, and then submit changes for each driver to the respective
subsystem maintainers with a patch based on the first changeset.

Once all the drivers are converted (i.e. the following merge window), we can
remove the obsolete entries.

	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/