Thread (10 messages) 10 messages, 5 authors, 2013-10-30

Re: [PATCH v2 1/2] clk/zynq/clkc: Add 'fclk-enable' feature

From: Sören Brinkmann <hidden>
Date: 2013-10-30 18:44:16
Also in: linux-arm-kernel, lkml

On Tue, Oct 29, 2013 at 02:04:06PM +0100, Michal Simek wrote:
On 10/29/2013 09:26 AM, Kumar Gala wrote:
quoted
On Oct 28, 2013, at 5:17 PM, Tomasz Figa wrote:
quoted
quoted
quoted
quoted
diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt
b/Documentation/devicetree/bindings/clock/zynq-7000.txt index
d99af878f5d7..11fdd146ec83 100644
--- a/Documentation/devicetree/bindings/clock/zynq-7000.txt
+++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt
@@ -22,6 +22,10 @@ Required properties:
Optional properties:
 - clocks : as described in the clock bindings
 - clock-names : as described in the clock bindings

+ - fclk-enable : Bit mask to enable FCLKs in cases no proper CCF
Since it's a vendor specific property, it should include vendor
prefix.
The whole driver is vendor specific. Should there really be another
prefix for that property?
Yes. If a property is introduced just for use by this particular driver 
then it must be prepended by a vendor prefix. That's a general rule.
Most all nodes are vendor specific by definition ;).
Is this really generic rule? I haven't seen/heard any point regarding this on KS.

I don't think we should use prefix here. It is xilinx specific option
but there shouldn't be any problem to use fclk-enable without any prefix.
Because it means we have to also rename ps-clk-frequency.

We are using xlnx prefix for properties which are autogenerated from design tools
which is not even this case.
So, what is the final call on this? Respin this and changing the prop name,
or leaving it as is?

	Thanks,
	Sören
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help