From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756665AbcH2HwX (ORCPT ); Mon, 29 Aug 2016 03:52:23 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:43747 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756124AbcH2HwU (ORCPT ); Mon, 29 Aug 2016 03:52:20 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed X-AuditID: cbfec7f4-f79cb6d000001359-37-57c3e71a8476 Subject: Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger To: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Jacek Anaszewski References: <57BF3D64.3090402@gmail.com> Cc: Alan Stern , Richard Purdie , Felipe Balbi , Greg KH , Peter Chen , "linux-usb@vger.kernel.org" , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Jonathan Corbet , Ezequiel Garcia , Stephan Linz , Matthias Brugger , Boris Brezillon , Geert Uytterhoeven , "open list:DOCUMENTATION" , open list , "open list:LED SUBSYSTEM" , Pavel Machek From: Jacek Anaszewski Message-id: <25cdf5e1-c3b5-e8a3-8213-f35a6f6160c2@samsung.com> Date: Mon, 29 Aug 2016 09:41:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-reply-to: Content-transfer-encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsVy+t/xK7pSzw+HG0w/qW1xrO0Ju8WBFwtZ LJ4caGe02PjiM4vFs1t7mSyaF69ns+i6uonN4vbWDSwWC9uWsFhc3jWHzWLrm3WMFouWtTJb XH29iMViweQnrBZ3Tx1ls9i9dhGTxe5dT1ktJvy+wGax5mSqg7DHk00XGT12zrrL7rFpVSeb x+63qR6HDncweuyfu4bdY3HfZFaP81M9PWbf/cHosWf+D1aP9VuusnisWP2d3aPryHU2j8+b 5AL4orhsUlJzMstSi/TtErgy2uYkFewSrZgw/wd7A+MEwS5GTg4JAROJq40TmSBsMYkL99az dTFycQgJLGWUaJq+iRkkwSsgKPFj8j0WEJtZwEziy8vDrBBFzxgl+nrvsYIkhAW8JE7eWwQ2 SUQgQ2LX13aook2MEr3bZjODOMwCH1klPp//zQ5SxSZgKPHzxWsmiBV2ErO+7wBbwSKgKrF/ w1OwuKhAhMStVR8ZQWxOgWCJv1enQJ0hL3HwynOWCYwCs5BcOAvJhbOQlC1gZF7FKJpamlxQ nJSea6hXnJhbXJqXrpecn7uJERK1X3YwLj5mdYhRgINRiYc34vmhcCHWxLLiytxDjBIczEoi vCvvHQ4X4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjt31/sQIYH0xJLU7NTUgtQimCwTB6dUA+NM Zg8epytsmWayG47JyJ3QfbBkDrPldsuZhUer7Zilpxpt2vTux7ek7wdjDn86sMtcV7pN9F6Z jiznxTsd201nSMUc3+Z1dI548ZI7xeHX9P0nPAkWXrHwuOWqx3+UTaY63vzFdDrzZu6/UocJ 9Q+idVL+LjK7Yf/HIf/rDaN4fYvJt3/5uWcosRRnJBpqMRcVJwIAnTmnDNYCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/26/2016 05:58 PM, Rafał Miłecki wrote: > On 25 August 2016 at 20:48, Jacek Anaszewski wrote: >> On 08/25/2016 04:30 PM, Alan Stern wrote: >>> >>> On Thu, 25 Aug 2016, Jacek Anaszewski wrote: >>> >>>> I'd see it as follows: >>>> >>>> #cat available_ports >>>> #1-1 1-2 2-1 >>>> >>>> #echo "1-1" > new_port >>>> >>>> #cat observed_ports >>>> #1-1 >>>> >>>> #echo "2-1" > new_port >>>> >>>> #cat observed_ports >>>> #1-1 2-1 >>>> >>>> We've already had few discussions about the sysfs designs trying >>>> to break the one-value-per-file rule for LED class device, and >>>> there was always strong resistance against. >>> >>> >>> This scheme has multiple values in both the available_ports and >>> observed_ports files. :-( Not that I have any better suggestions... >> >> >> Right, I forgot to add a note here, that this follows space >> separated list pattern similarly as in case of triggers attribute. >> Of course other suggestions are welcome. > > So ppl have doubts about multiple values in a single sysfs file > (whatever we call it: "ports" or "observed_ports"). Greg clearly said: >> sysfs is "one value per file", here you are listing a bunch of things in >> one sysfs file. Please don't do that. > > What about my idea of using "ports" subdirectory and having each port > as separated file inside that subdir? I think there are two ways of > doing this: > > 1) Having "ports" subdir with 0x0000 chmod files, one per each port > specified as observable > In this solution we need "new_port" and "remove_port" that can be used > for management of observable ports. > I think Jacek wasn't happy with this chmod and he believes Greg meant R/W files. It looks odd to me. In this case it would also abuse "one value per file" rule - the files would have no value, and only their names would carry an information. > 2) Having "ports" subdir with RW files, one per each existing physical port > In this situation we don't need "new_port" or "remove_port". If we > want port to be observable we just do: > echo 1 > 1-1 > Implementing this solution needs reading more details from USB subsystem. The situation here is clear IMO - the number of USB ports in the system can change dynamically. I'm not sure if this can be handled easily with sysfs, where we usually expose an interface for known set of settings. struct attribute arrays are usually defined statically at the compile time and filled with the variables, that are created with DEVICE_ATTR macro. > Do you find any of solutions with "ports" subdir better than dealing > with new-line/space separated values in a single sysfs file? > -- Best regards, Jacek Anaszewski