From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932744AbcH2IaP (ORCPT ); Mon, 29 Aug 2016 04:30:15 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:37207 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756577AbcH2IaN (ORCPT ); Mon, 29 Aug 2016 04:30:13 -0400 X-AuditID: cbfec7f4-f79cb6d000001359-1a-57c3f272dfb0 Subject: Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger To: Pavel Machek , Jacek Anaszewski References: <57BF3D64.3090402@gmail.com> <20160826195034.GC21442@amd> Cc: Alan Stern , =?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" From: Jacek Anaszewski Message-id: <2f89516b-f9bb-451a-9db2-6d9c245018a0@samsung.com> Date: Mon, 29 Aug 2016 10:29:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-version: 1.0 In-reply-to: <20160826195034.GC21442@amd> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Ra0hTYRjHeXfOzi44PU6tF6OUUUFBphLxKmV+SDgZVlSkGF2WHlRyKueo ZH0RLHWDTFuSrkS3pdZcLmeKulKZzusHjVrCYkqxdMMb3moZamwj8Nvvz/P7P8+Hh4+JB/FQ flZOPs3kSLMlhBAf3x7+coxZHUiOtNjD0VCpg4f6nWocOfrLAGpzruFo1vaRg0q0BgIprEYC fet4hyN16Sscfe55SaCOhVaANE2PMGSd1+CoQengIvuYhUCmtxoOMvX85KLKv5ME0o/S8UGU w/gJUN0qO48y6uQEZVqkKfNAOaD66vQ8Sluh5FIT1eeoF3Y3oD7Uu7mU4b0Vp163/OZRisEp glozHrjknyo8lU5nZxXSzPG428JM9docnrcZeM/y9AkoBp3+CiDgQ/IEHBlZxXy8B05OGwgF EPLFZCOAv6rGcF+YBfB5bTfhsYLIRDg6reF4OJi8AKu2XFyfVA6gRT7jDRgpJ+BmmdXbIMgo +Mc5722IyDg4MVzjvYeTh2DFhpzn4RAyBdp0K8DnBEK3chr3sIA8AmtGF7x7MPI0bFhuxX0c Btv1i1glIFW7KqpdmmqX1gAwHQihC9Ly2DsZsqgIVipjC3IyItJyZUbg++16F9AOxZoByQcS P1HKnDlZzJUWskUyM4B8TBIsolcGksWidGnRfZrJvcUUZNOsGezj45K9orqe5atiMkOaT9+l 6Tya+T/l8AWhxYApbLtyeSngZLQ1YCohvKkkpv57rEQlT3pW0yz7qp3vOlMd1rtku1hb9cAw +Ng8pu7dbkmLKO5cAg9d5k2du6IvxXXY2ZS/0R49OePYuUzbGkEJm7SVoLWafqjPRl6bexPT HZvaxtqbw84nbo0nHLx+Y79fvEnvEqzf3LEp2yU4mymNOooxrPQffr6Ej9cCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/26/2016 09:50 PM, Pavel Machek wrote: > On Thu 2016-08-25 20:48:04, 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. >> >>>>>> 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. > > Actually, they don't. They identify device _type_. If you have two > mice of the same type connected, they'll have same idProduct / > idVendor values. That's true. We'd have to be able to distinguish between the devices of the same type. The only way seems to be the port id, whereas the initial intention was to give a hint on what device is represented by given port id :-) Regardless of that, having a device name instead of port id would allow for unique identification of a device in most of cases. -- Best regards, Jacek Anaszewski