Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1470969
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger |
| Date | 2016-08-26 22:00 +0200 |
| Message-ID | <savsd-2Z5-11@gated-at.bofh.it> (permalink) |
| References | <sa48G-2d0-21@gated-at.bofh.it> <sa7SV-4G3-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Alan Stern <stern@rowland.harvard.edu> - 2016-08-25 16:50 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-08-25 20:50 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Alan Stern <stern@rowland.harvard.edu> - 2016-08-25 21:40 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Alan Stern <stern@rowland.harvard.edu> - 2016-08-25 22:10 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Rafał Miłecki <zajec5@gmail.com> - 2016-08-26 18:00 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-08-29 10:00 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Pavel Machek <pavel@ucw.cz> - 2016-08-29 10:10 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Rafał Miłecki <zajec5@gmail.com> - 2016-08-29 10:30 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Pavel Machek <pavel@ucw.cz> - 2016-08-29 10:50 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Rafał Miłecki <zajec5@gmail.com> - 2016-08-29 11:10 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Pavel Machek <pavel@ucw.cz> - 2016-08-26 22:00 +0200
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-08-29 10:40 +0200
csiph-web