On Tue, Oct 29, 2013 at 02:04:06PM +0100, Michal Simek wrote: > On 10/29/2013 09:26 AM, Kumar Gala wrote: > > > > On Oct 28, 2013, at 5:17 PM, Tomasz Figa wrote: > > > >>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
