From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757119AbcHYSss (ORCPT ); Thu, 25 Aug 2016 14:48:48 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:37975 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751397AbcHYSsp (ORCPT ); Thu, 25 Aug 2016 14:48:45 -0400 Subject: Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger To: Alan Stern , Jacek Anaszewski References: 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" , Pavel Machek From: Jacek Anaszewski Message-ID: <57BF3D64.3090402@gmail.com> Date: Thu, 25 Aug 2016 20:48:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >>>> Also a description of the device connected to the port would be a nice >>>> feature, however I am not certain about the feasibility thereof. >>> >>> What kind of description do you mean? Where should it be used / where >>> should it appear? >>> >> >> Product name/symbol. Actually it should be USB subsystem responsibility >> to provide the means for querying the product name by port id, if it >> is possible at all. > > cat /sys/bus/usb/devices/PORT/product > cat /sys/bus/usb/devices/PORT/manufacturer > > These will work if there is a device registered under PORT. I've found only idProduct and idVendor files. They indeed uniquely identify the device, but the numbers are not human readable. Is there a way to retrieve the corresponding names in kernel? Does the lsusb command do the mapping in the user space or maybe it takes the names from kernel? -- Best regards, Jacek Anaszewski