From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752927AbcEXS5M (ORCPT ); Tue, 24 May 2016 14:57:12 -0400 Received: from 37-46-169-123.customers.ownit.se ([37.46.169.123]:50611 "EHLO zoo.weinigel.se" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751522AbcEXS5K (ORCPT ); Tue, 24 May 2016 14:57:10 -0400 Subject: Re: [PATCH] devicetree - document using aliases to set spi bus number. To: Mark Brown References: <1464107960-10775-1-git-send-email-christer@weinigel.se> <20160524172045.GN8206@sirena.org.uk> <57449784.4070108@weinigel.se> <20160524183256.GP8206@sirena.org.uk> Cc: linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, devicetree@vger.kernel.org From: Christer Weinigel X-Enigmail-Draft-Status: N1110 Message-ID: <5744A402.8050409@weinigel.se> Date: Tue, 24 May 2016 20:57:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160524183256.GP8206@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/24/2016 08:32 PM, Mark Brown wrote: > On Tue, May 24, 2016 at 08:03:48PM +0200, Christer Weinigel wrote: >> On 05/24/2016 07:20 PM, Mark Brown wrote: > >>> I'm not sure this is something we want to support at all, I >>> can't immediately see anything that does this deliberately in >>> the SPI code and obviously the "bus number" is something of a >>> Linux specific concept which would need some explanation if we >>> were going to document it. It's something I'm struggling a bit >>> to see a robust use case for that isn't better served by >>> parsing sysfs, what's the goal here? > >> If this isn't something that should be in the >> Documentation/devicetree because it's not generig enough, where >> should Linux-specific interpretations such as this be >> documented? > > I'm not clear that we want to document this at all since I am not > clear that there is a sensible use case for doing it. I did ask > for one but you've not articulated one in this reply. I am much > less gung ho than Grant on this one, even as a Linux specific > interface it seems very legacy. It's bloody convenient. I'm working with a Zync board right now where we have multiple SPI ports. Being able to label the ports on the board spi1, spi2 and spi3 and having spidev devices show up as /dev/spidev1.0 instead of dynamic assignment makes things much easier. Especially when doing driver development where unloading and reloading the spi driver module will give it a new dynamic number every time. Yes, it's possible to iterate through all files /sys/class/spi_master and then have a table to map those names to device names and create symlinks to them, it's just painful. It's much easier to do be able to do "cat data >/dev/spidev1.0" from busybox and not have to set up all that infrastructure. And yes, this is on an embedded system using busybox without udev. In addition, right now I have a couple of different variants of the boards that I work on, and with different SPI ports at different addresses. It's rather nice to be able to reuse the same kernel + ramdisk on multiple variants and only have to update the devicetree to get sensible devices names on all variants. /Christer