Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932919AbaGRJLl (ORCPT <rfc822;w@1wt.eu>);
	Fri, 18 Jul 2014 05:11:41 -0400
Received: from mail-pd0-f179.google.com ([209.85.192.179]:44039 "EHLO
	mail-pd0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1761041AbaGRJL1 convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 18 Jul 2014 05:11:27 -0400
Date: Fri, 18 Jul 2014 02:11:26 -0700 (PDT)
Message-ID: <877g3bghfn.wl%kuninori.morimoto.gx@gmail.com>
From: Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>
To: Simon Horman <horms@verge.net.au>
Cc: Zhang Rui <rui.zhang@intel.com>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Magnus Damm <magnus.damm@gmail.com>, devicetree@vger.kernel.org,
        linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
        Eduardo Valentin <eduardo.valentin@ti.com>, linux-pm@vger.kernel.org
Subject: Re: [PATCH 05/13] thermal: rcar: Document SoC-specific bindings
In-Reply-To: <20140718074619.GA12613@verge.net.au>
References: <1404908623-909-1-git-send-email-geert+renesas@glider.be>
	<1404908623-909-6-git-send-email-geert+renesas@glider.be>
	<20140711091358.GK12420@verge.net.au>
	<1405435735.28592.50.camel@rzhang1-toshiba>
	<87mwcakpzw.wl%kuninori.morimoto.gx@renesas.com>
	<20140718074619.GA12613@verge.net.au>
User-Agent: Wanderlust/2.14.0 Emacs/23.3 Mule/6.0
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Hi Simon

> 1. That the (in this case thermal) IP on the SoC's listed is known
>    to work with the driver using the generic (in this case
>    renesas,rcar-thermal) compatibility string.
> 
> 2. That if some incompatibility is subsequently found such that the
>    IP on SoC does function correctly using the generic compatibility
>    string or some new feature is to be enabled which is not generic
>    then it the driver should be updated with code that is triggered
>    by the SoC-specific compat string.
> 3. That Soc dts(i) files should list the more specific SoC compat string
>    followed bu the generic compat string. In this way so long as the
>    driver only matches on the generic compat string it will be used. But
>    if the driver is updated match on the SoC-specific compat string
>    then it will be used instead. In this way dtbs should be forwards
>    compatible with driver updates.
> 
>    I believe that this series includes patches to update the relevant
>    dtsi files accordingly.
> 
> In relation to verification, I believe all the SoCs listed in this patch
> are known to work with the generic compat string. And they should continue
> to work with this change because its only an documentation change. In the
> future, if a SoC specific compat string is added to the driver code then
> verification would need to occur.
> 
> From my point of view the documentation in rcar-thermal.txt is consistent
> with the documentation for other drivers that use this binding scheme
> (at least the ones that are documented :). I would not have any problems
> examples but I don't think its entirely necessary.

>From my point of view,
I have no object to adding SoC-specific compatible
string on dts(i) file.
It can be insurance for future (above 1, 2, 3).

My concern is to add "known working SoC" to documentation.
I have no objection if this listed "known working SoC" 
was matched to "SoC-specific" compatible name.
Because driver cares it specially.
And, this case, documentation should list it.

But this case, listed SoC are matched to "generic name".

> +- compatible		: "renesas,thermal-<soctype>", "renesas,rcar-thermal"
> +			  as fallback.
> +			  Examples with soctypes are:
> +			    - "renesas,thermal-r8a73a4" (R-Mobile AP6)
> +			    - "renesas,thermal-r8a7779" (R-Car H1)
> +			    - "renesas,thermal-r8a7790" (R-Car H2)
> +			    - "renesas,thermal-r8a7791" (R-Car M2)

>From my (general?) point of view,
it seems that these listed SoC doesn't match to "generic name".
I mean that driver will do something special for these SoC.
And, we will confuse if driver supports "SoC-specific" compatible name.
(which one is special ? which one is generic ?)

And, I don't want to keep updating
"generic name matched SoC" on document.

Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/