From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756161AbcECT1N (ORCPT ); Tue, 3 May 2016 15:27:13 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:58795 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752111AbcECT1L (ORCPT ); Tue, 3 May 2016 15:27:11 -0400 From: Arnd Bergmann To: Rob Herring Cc: Sagar Dharia , gregkh@linuxfoundation.org, bp@suse.de, poeschel@lemonage.de, treding@nvidia.com, broonie@kernel.org, gong.chen@linux.intel.com, andreas.noever@gmail.com, alan@linux.intel.com, mathieu.poirier@linaro.org, daniel@ffwll.ch, jkosina@suse.cz, sharon.dvir1@mail.huji.ac.il, joe@perches.com, davem@davemloft.net, james.hogan@imgtec.com, michael.opdenacker@free-electrons.com, daniel.thompson@linaro.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kheitke@audience.com, mlocke@codeaurora.org, agross@codeaurora.org, sheetal.tigadoli@gmail.com, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH V5 2/6] of/slimbus: OF helper for SLIMbus Date: Tue, 03 May 2016 21:26:25 +0200 Message-ID: <2394122.1OlmZMdZVa@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160503161156.GA12898@rob-hp-laptop> References: <1461801489-16254-1-git-send-email-sdharia@codeaurora.org> <1461801489-16254-3-git-send-email-sdharia@codeaurora.org> <20160503161156.GA12898@rob-hp-laptop> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:eG7A1KD9jh6Kx2nLa3WITq+m/8eVGcjQIFMc/zIOHqbiHV1GLTR VT7w7BHGE9tsmDxVLUtBfRkX22kwHom2EkwXX0XKNBfLOHVZ40DcK7OTebhClRhNJKz7kzH 1FYaw88VbgoVsRIxvGniTfJA48kOcoOPHlHY1OVfr5pJGYYKOOReG54OQWryfTMQAqymxkj 2755xXqaJELQMbtrHuYVg== X-UI-Out-Filterresults: notjunk:1;V01:K0:SChXEzUTiFk=:JjUAPmG76m8uIX3wRTL4oR fWvqiuXQI/gkUy3ODe056Wu5dfXtroDSvP0kuFd+GHz1lp3gfyFXFYlnX7rDStxE/k3gEMl+v IdAci5RBDIkOWaVb5tszB+lBeCAc82PYue5ysszgmThln4/MJdsTIRLd4M/6zV73XWQVajv+b fg8QHZ/TmfcqGHgLserWD9p9iUJWVllwE5V6NPMR/P0JAwBtF86PQkdHFcmsdT3SAfMIRvR6L qkCUszegaDTBALprG08oafc+94qaT2EjwR2sdQa81Q+/tDMrrCFT+HV5YcfMAaeZJJUaPWTYM FQ6QSKVERX4jz7WUtOrMtx2x/+oO7uYPpJuB1WLGeN4MZuFCObM6e3dZkuiuYA0v21E0yEr6P gdIP0LKfi35/5XXL2R5UmPEFfuKBEuDiUB42RM2pl6Jhsg039zLl+Pse1OQOCkMEZdZT0XFEk zN+jV09wFB9fW7XFpRVyKOaYrAUV/GSUNvRSDClEgGiteYF9cnAMFS4mruKaqB9v5oowCPgQs cBA58YM8k63TuEAQMQIHHpTN0ug4bdHRo7QwVtWr25EittO5e7RWOTgOoLoRKDn+Lb0caX9pN 7Yr6vdVizu9V2Lr3MdH1sAQvMq3ittzqd54dsayFC1tjcWGMQCjM6zUtXkSgr67eZ2TUI0m+X IcaDEwBbFbNz5KgjqAw3rx/RgreY7Smo+ux9sEIf15c1Vd/fCA8DwKxxvFM0p35XkOh+oWZ0/ gA/t8hd32vqonW7Q Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 03 May 2016 11:11:56 Rob Herring wrote: > > + > > +Child nodes: > > +Every SLIMbus controller node can contain zero or more child nodes > > +representing slave devices on the bus. Every SLIMbus slave device is > > +uniquely determined by the enumeration address containing 4 fields: > > +Manufacturer ID, Product code, Device index, and Instance value for > > +the device. > > +If child node is not present and it is instantiated after device > > +discovery (slave device reporting itself present), > > +its name will be in this format: "217:60:1:0" > > + > > +However, the device may need additional non-standard way to power it > > +up so that it can start functioning. In that case, child node will > > +need to be present as slave of the slimbus-controller device. > > +The compatible property will be necessary so that corresponding > > +driver can probe and execute the required procedure to make it > > +functional. > > + > > +Required property for SLIMbus child node if it is present: > > +- reg - enumeration address fields of the device > > + > > +- compatible - name of SLIMbus child node using practice typically > > + followed by discoverable buses: > > + ",", "slim" > > Im most cases for compatible strings on discoverable buses, the VID and > PID (and perhaps more) are used to form the compatible string. See USB > binding for a recent example. This will save you from having to make up > strings for every device. Actually it seems like the current binding puts the same manufacturer ID and product ID pair into both address and compatible string. Is that correct? I would have expected the address to have only index and instance fields and the compatible string match whatever we can detect by looking at that device. This has probably been discussed 5 years ago when the patches were first posted, but I don't remember the outcome. Arnd