On Tue, Feb 13, 2018 at 11:14 AM, Li Wei <liwei213@xxxxxxxxxx> wrote:
> add ufs node document for Hisilicon.
>
> Signed-off-by: Li Wei <liwei213@xxxxxxxxxx>
> ---
> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
I'm pretty sure we've discussed it before, but can you make this so that
the generic properties are part of the ufshcd binding, and you refer to it
from here, only describing in what ways the hisi ufs binding differs from
the standard?
> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> new file mode 100644
> index 000000000000..0d21b57496cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> @@ -0,0 +1,37 @@
> +* Hisilicon Universal Flash Storage (UFS) Host Controller
> +
> +UFS nodes are defined to describe on-chip UFS hardware macro.
> +Each UFS Host Controller should have its own node.
> +
> +Required properties:
> +- compatible : compatible list, contains one of the following -
> + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs
> + host controller present on Hi36xx chipset.
> +- reg : should contain UFS register address space & UFS SYS CTRL register address,
> +- interrupt-parent : interrupt device
> +- interrupts : interrupt number
> +- clocks : List of phandle and clock specifier pairs
> +- clock-names : List of clock input name strings sorted in the same
> + order as the clocks property. "ref_clk", "phy_clk" is optional
The clock names sound generic enough, should we have both in the
generic binding?
> +- resets : reset node register, one reset the clk and the other reset the controller
> +- reset-names : describe reset node register
This looks incomplete. What is the name of the reset line supposed to be?
I'd also suggest you document it in the ufshcd binding instead.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
