From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755252AbcEXXfD (ORCPT ); Tue, 24 May 2016 19:35:03 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:32822 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753725AbcEXXfA (ORCPT ); Tue, 24 May 2016 19:35:00 -0400 Message-ID: <5744E51A.1040506@gmail.com> Date: Tue, 24 May 2016 16:34:50 -0700 From: Frank Rowand Reply-To: frowand.list@gmail.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Brown CC: Christer Weinigel , linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH] devicetree - document using aliases to set spi bus number. References: <1464107960-10775-1-git-send-email-christer@weinigel.se> <20160524172045.GN8206@sirena.org.uk> <57449784.4070108@weinigel.se> <20160524183256.GP8206@sirena.org.uk> In-Reply-To: <20160524183256.GP8206@sirena.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/24/2016 11:32 AM, 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. > The time for the use case was when the patch was accepted. It is in the kernel, it is appropriate to document it. -Frank