From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754005AbcHZTtA (ORCPT ); Fri, 26 Aug 2016 15:49:00 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:42580 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752325AbcHZTs5 (ORCPT ); Fri, 26 Aug 2016 15:48:57 -0400 Date: Fri, 26 Aug 2016 21:48:47 +0200 From: Pavel Machek To: Jacek Anaszewski Cc: =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , 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" Subject: Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Message-ID: <20160826194847.GB21442@amd> References: <20160823220404.9887-1-zajec5@gmail.com> <20160824175345.7033-1-zajec5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2016-08-25 11:04:38, Jacek Anaszewski wrote: > On 08/25/2016 10:29 AM, Rafał Miłecki wrote: > >On 25 August 2016 at 10:03, Jacek Anaszewski wrote: > >>On 08/24/2016 07:52 PM, Rafał Miłecki wrote: > >>> > >>>From: Rafał Miłecki > >>> > >>>This commit adds a new trigger responsible for turning on LED when USB > >>>device gets connected to the specified USB port. This can can useful for > >>>various home routers that have USB port(s) and a proper LED telling user > >>>a device is connected. > >>> > >>>The trigger gets its documentation file but basically it just requires > >>>specifying USB port in a Linux format (e.g. echo 1-1 > new_port). > >>> > >>>During work on this trigger there was a plan to add DT bindings for it, > >>>but there wasn't an agreement on the format yet. This can be worked on > >>>later, a sysfs interface is needed anyway for platforms not using DT. > >>> > >>>Signed-off-by: Rafał Miłecki > >>>--- > >>>V2: Trying to add DT support, idea postponed as it will take more time > >>> to discuss the bindings. > >>>V3: Fix typos in commit and Documentation (thanks Jacek!) > >>> Use "ports" sysfs file for adding and removing USB ports (thx Jacek) > >>> Check if there is USB device connected after adding new USB port > >>> Fix memory leak or two > >>>V3.5: Fix e-mail address (thanks Matthias) > >>> Simplify conditions in usbport_trig_notify (thx Matthias) > >>> Make "ports" a subdirectory with file per port, to match one value > >>> per file sysfs rule (thanks Greg) > >>> As "ports" couldn't be used for adding and removing ports anymore, > >>> there are now "new_port" and "remove_port". Having them makes this > >>> API also common with e.g. pci and usb buses. > >> > >> > >>Now writing new_port with "1-1" produces a file named "1-1" in the > >>ports directory with 000 permissions. I think that what Greg had > >>on mind by referring to "one value per file" rule was a set of > >>files representing ports, like "1-1 1-2 2-1", and each file should be > >>readable/writeable. > >> > >>For instance "echo 1 > 1-1" would enable the trigger for the port 1-1 > >>and "echo 0 > 1-1" would disable it. The problem is that we don't know > >>the number of required ports at compilation time and the sysfs > >>attributes would have to be dynamically created on driver instantiation. > >>What is more, as the USB ports can dynamically appear/disappear in the > >>system, the files would have to be created/removed accordingly during > >>LED class device lifetime, which is not the best design for the sysfs > >>interface I think. Could we add a flag to the USB port, instead? That way, USB code would take care of creating the enable file in its own directory. Is per-port control needed? Would just global control be sufficient? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html