From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Subject: Re: [PATCH 1/7] Documentation: of: add type property
Date: Mon, 27 Jun 2016 00:09:13 +0000
Message-ID: <87r3bjxzw7.wl%kuninori.morimoto.gx@renesas.com>
References: <87fus3xr2q.wl%kuninori.morimoto.gx@renesas.com>
 <87eg7nxr00.wl%kuninori.morimoto.gx@renesas.com>
 <CAL_JsqKxYUXJoAmYQOiSVdodKmrEPqVgm84ZVhhEw=FuJQhZTw@mail.gmail.com>
Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
In-Reply-To: <CAL_JsqKxYUXJoAmYQOiSVdodKmrEPqVgm84ZVhhEw=FuJQhZTw@mail.gmail.com>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/options/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel/>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Errors-To: alsa-devel-bounces@alsa-project.org
Sender: alsa-devel-bounces@alsa-project.org
To: Rob Herring <robh+dt@kernel.org>
Cc: Linux-DT <devicetree@vger.kernel.org>, Linux-ALSA <alsa-devel@alsa-project.org>, Mark Brown <broonie@linaro.org>, Linux-Kernel <linux-kernel@vger.kernel.org>, Mark Brown <broonie@kernel.org>, Laurent <laurent.pinchart@ideasonboard.com>, Grant Likely <grant.likely@linaro.org>, Frank Rowand <frowand.list@gmail.com>, Guennadi <g.liakhovetski@gmx.de>
List-Id: devicetree@vger.kernel.org


Hi Rob

Thank you for your review

> > +Each ports / port / endpoint can have its type if needed.
> 
> I think type should only apply to a port. ports is only a grouping for
> multiple ports. endpoints are just the connection. A port is a single
> data flow, so 2 endpoints on a port reflect 2 possible connections for
> that data flow.
> 
> > +child node can take over parent node type. below example indicates
> > +device0 type is "typeA" && "typeB",
> > +device1 type is "typeA" && "typeB" && "typeC".
> 
> This does not make sense to me. A concrete example perhaps using HDMI
> audio would be helpful.

"type" on "port" only is OK. I will fix that.

Multi type feature (= take over from parent) and type on "endpoint"
is not urgent at this point, so I will drop these in v2.
I just thought that it will be necessary in the future.