linux-kernel - Re: [PATCH 0/4] clk: mvebu: fix clk init order

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: <53022504.1010908@free-electrons.com>
Date:	Mon, 17 Feb 2014 16:04:36 +0100
From:	Gregory CLEMENT <gregory.clement@...e-electrons.com>
To:	Emilio López <emilio@...pez.com.ar>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
CC:	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	Jason Cooper <jason@...edaemon.net>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Andrew Lunn <andrew@...n.ch>,
	Mike Turquette <mturquette@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/4] clk: mvebu: fix clk init order

On 17/02/2014 15:42, Emilio López wrote:
> Hi Gregory, Ezequiel,
> 
>  >> Are we still in time to consider Emilio's oneline proposal?
>>> (Emilio: would you mind preparing a suitable patch against dove,
>>> kirkwood, armada370/xp, so we can see the real thing?).
> 
> The patch is in a common file, so it does not need patching anything for 
> each platform.
> 
>> I am still strongly against this proposal because hard-coded the parent
>> clock name in the driver seems very wrong
> 
> It is hardcoded already when the parent is registered, so I do not 
> understand your concern.
> 
> http://lxr.free-electrons.com/source/drivers/clk/mvebu/common.c?v=3.13#L34
> 
>> and moreover in some circumstances
>> (if there is no output-name, which is our default case) this proposal
>> just ignored the parent clock given by the device tree and this looked
>> more wrong.
> 
> I have sent a second patch addressing this comment, but you do not seem 
> to have taken too serious a look at it.
> 
> http://www.spinics.net/lists/arm-kernel/msg305922.html
> 

Please read what I have written: "if there is no output-name, which is our
default case) this proposal just ignored the parent clock given by the device
tree".

Extract of your code from the link you pointed:

const char *default_parent = "tclk";

[...]

of_property_read_string_index(clkspec.np, "clock-output-names",
					      clkspec.args_count ? clkspec.args[0] : 0,
					      &default_parent);

example of a valid dts:
			gateclk: clock-gating-control@...20 {
				compatible = "marvell,foo-bar-gating-clock";
				reg = <0x18220 0x4>;
				clocks = <&coreclk 1>;
				#clock-cells = <1>;
			};

So in this fictional but still valid example, the device tree indicates that the parent
clock of the gating clock is the 2nd clock provided by the coreclk which is currently
"cpuclk". As no clock-output-names is used, then this will be totally ignore and instead
of using "cpuclk" as parent "tclk" will be used.

I hope this example will show you, what I disagree with this proposal and why it
introduce some regression.

Regards,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/