Re: [PATCH v9 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver

[Shawn Guo]

On Wed, Aug 12, 2015 at 06:49:21PM +0530, Sanchayan Maity wrote:
> Add the devicetree bindings for the Freescale Vybrid On-Chip
> OTP driver.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan@xxxxxxxxx>
> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>
> ---
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt       | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> new file mode 100644
> index 0000000..b29f65f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> @@ -0,0 +1,21 @@
> +On-Chip OTP Memory for Freescale Vybrid
> +
> +Required Properties:
> +  compatible:
> +  - "fsl,vf610-ocotp" for VF5xx/VF6xx
> +  #address-cells : Should be 1
> +  #size-cells : Should be 1
> +  reg : Address and length of OTP controller and fuse map registers
> +  clocks : ipg clock we associate with the OCOTP peripheral
> +  clock-names : Must contain "ocotp" as matching entry

I'm not sure "ocotp" is a good name for describing a clock from OCOTP
internal point of view.  "ipg" might be better.  But I would suggest you
drop clock-names property completely, if "ipg" is the only clock you
need to describe here.  The clock-names is necessary only when there are
multiple clocks to distinguish.

With clock-names dropped, the driver works by passing NULL as the second
parameter to devm_clk_get() call.

Shawn

> +
> +Example for Vybrid VF5xx/VF6xx:
> +
> +	ocotp: ocotp@400a5000 {
> +		compatible = "fsl,vf610-ocotp";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x400a5000 0xCF0>;
> +		clocks = <&clks VF610_CLK_OCOTP>;
> +		clock-names = "ocotp";
> +	};
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/