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

Sören Brinkmann soren.brinkmann at xilinx.com
Wed Oct 30 14:44:03 EDT 2013


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





More information about the linux-arm-kernel mailing list