From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH] DT: mmc: sh_mmcif: fix "compatible" property text References: <201404250239.39150.sergei.shtylyov@cogentembedded.com> <3979266.lQrOKbu0yo@wasted.cogentembedded.com> From: Sergei Shtylyov Message-ID: <55BB44DC.8040706@cogentembedded.com> Date: Fri, 31 Jul 2015 12:50:20 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: Magnus Damm Cc: Rob Herring , Pawel Moll , Mark Rutland , "ijc+devicetree@hellion.org.uk" , Kumar Gala , "devicetree@vger.kernel.org" , ulf.hansson@linaro.org, linux-mmc@vger.kernel.org, SH-Linux , Simon, Horms, horms@verge.net.au, Geert Uytterhoeven , Laurent Pinchart List-ID: Hello. On 7/31/2015 5:23 AM, Magnus Damm 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 > 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. I'm not changing the policy, I'm making the binding actually reflect the driver reality (and even the example given in the binding). > 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. I didn't quite understand what you're proposing instead. Making SoC based strings mandatory? Changing the driver to look at the SoC based strings? > Thanks, > / magnus MBR, Sergei