From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH] of: support an enumerated-bus compatible value Date: Mon, 02 Jul 2012 17:17:18 -0600 Message-ID: <4FF22BFE.8020905@wwwdotorg.org> References: <1340924755-31447-1-git-send-email-swarren@wwwdotorg.org> <4FF0A6B6.8040902@gmail.com> <4FF1C567.4060809@wwwdotorg.org> <4FF22095.4030106@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Grant Likely Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org List-Id: devicetree@vger.kernel.org On 07/02/2012 04:37 PM, Grant Likely wrote: > On Mon, Jul 2, 2012 at 4:28 PM, Stephen Warren wrote: >> On 07/02/2012 03:43 PM, Grant Likely wrote: >>> On Mon, Jul 2, 2012 at 9:59 AM, Stephen Warren wrote: >>>> On 07/01/2012 04:03 PM, Grant Likely wrote: >>>> ... >>>>> Besides; if they are enumerated, non-memory mapped devices, then is it >>>>> really appropriate to use platform_{device,driver}? I don't think it >>>>> is. >>>> >>>> Hmm, well /everything/ that gets instantiated from DT is a platform >>>> device at present, at least for the platforms and bus types we're using >>>> on Tegra and I believe all/most ARM platforms, except some small amounts >>>> of AMBA. >>> >>> Not true. SPI devices beget spi_device, i2c devices i2c_client, etc. >>> The appropriate structure for the kind of device should always be >>> used. >> >> Yes, that's true. >> >> But doesn't that lend even more weight to the need for an enumerated-bus >> bus-type/compatible value? After all, the more important issue here (at >> least initially) is the DT representation that we're defining, rather >> than what Linux does with it internally. > > ... another thought: If the thing doesn't actually have any kind of > address (like a audio complex) then it probably makes more sense to > drop reg entirely since it is meaningless. That may not be relevant > for your regulartors example though. I'd love to drop the reg property, but it's needed since there are multiple nodes with the same name, so they need to be differentiated by unit address, and AIUI, you can't have a unit address without a matching reg property.