Re: [PATCH] DT: mmc: sh_mmcif: fix "compatible" property text

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Sergei,

On Fri, Jul 31, 2015 at 4:59 AM, Sergei Shtylyov
<sergei.shtylyov@xxxxxxxxxxxxxxxxxx> wrote:
> The "compatible" property text contradicts even the example given in the MMCIF
> binding document itself; moreover, the Renesas MMCIF driver only  matches  on
> the generic "compatible" string, and doesn't look for at SoC specific strings
> currently at all. Thus describe "renesas,sh-mmcif" string as mandatory and the
> others as optional.
>
> Fixes: b4c27763d749 ("mmc: sh_mmcif: Document DT bindings")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx>

Thanks for your efforts trying to improve the DT binding documentation.

> --- renesas.orig/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> +++ renesas/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> @@ -6,11 +6,11 @@ and the properties used by the MMCIF dev
>
>  Required properties:
>
> -- compatible: must contain one of the following
> +- compatible: must contain "renesas,sh-mmcif"; may also contain one of
> +  the following:
>         - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
>         - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
>         - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
> -       - "renesas,sh-mmcif" for the generic MMCIF

As you know, each SoC contains a wide range of on-chip devices and the
MMCIF device is just one of them. Exactly how to manage the DT
bindings must be up to each maintainer and of course this needs to be
aligned with the SoC maintainer and SoC vendor with policies used for
SoC support and BSPs and whatnot. Changing policy like this for a
single device without at least discussing this with the SoC
maintainers does not help.

For Renesas hardware we so far use both SoC part number and optionally
a generic binding as well. As commonly expected, the DT binding is
supposed to describe the hardware and if hardware devices are
compatible. Unless we use SoC part number in the compatible string
there is a risk that the SoC integrator simply copy-and-pastes generic
bindings "because it works" but this will result in DT binding based
on software compatibility and not hardware compatibility. Later when
the driver support is extended this may result in broken software due
to incorrect compatibility information through generic bindings.

If anything is unclear please ask and feel free to discuss this DT
topic with Simon, Laurent, Geert and/or me.

Thanks,

/ magnus
--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux