he necessary changes were
so widespread and the resulting text file would not be easily readable.
Replacing things of the form "A ->dep B" just scratches the surface.
That document teems with variable names, formulas, code extracts, and
other things which would all need to be rendered in a different font
style. The density of the markup required to do this would be
phenomenally high.
In my opinion it simply was not worthwhile.
Alan Stern
iver can instruct the amba bus via the "driver PM
> flags"?
PM flags won't directly be able to cover things like disabling clocks.
But they could be useful for indicating explicitly whether the code to
take care of those things needs to reside at the driver layer or at the
bus l
vel.
I'm curious: Why does the PCI bus type (and others) do this? Why
doesn't it do what the driver says to do?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ns hard-wire the mount options for usbfs
> in their init scripts, such as ``/etc/rc.d/rc.sysinit``, rather than
> making it easy to set this per-system policy in ``/etc/fstab``.
This is all totally out of date. usbfs is no longer a filesystem that
can be mounted.
Alan Stern
--
To unsubs
On Thu, 30 Mar 2017, Oliver Neukum wrote:
> Am Donnerstag, den 30.03.2017, 11:55 -0400 schrieb Alan Stern:
> >
> > I'm pretty sure that usb-storage does not do this, at least, not when
> > operating in its normal Bulk-Only-Transport mode. It never tries to
> >
On Thu, 30 Mar 2017, Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 10:26:32 -0400 (EDT)
> Alan Stern escreveu:
>
> > On Thu, 30 Mar 2017, Oliver Neukum wrote:
> >
> > > > Btw, I'm a lot more concerned about USB storage drivers. When I was
>
te "the buffer can be
continuous", but that is certainly not what he meant.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t it is possible to register trigger for many
> ports.
The patch could be changed to remove that assumption.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ign for defining and
> presenting multiple USB ports. I'm still in favour of a single
> attribute with space separated list. This scheme is commonly used
> in existing interfaces.
No such interface is needed if you do things the way I outlined above.
Each trigger would require the user to specify either one port, one
hub, or nothing at all. Multiple ports would not be used.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s/class/led/foo/trigger
echo hub1-4 >/sys/class/led/foo/trigger
echo usb >/sys/class/led/foo/trigger
Yes, it would be possible to have a port-specific trigger for one LED
and an overall USB activity trigger for another LED. I don't know how
useful this would be -- you cou
On Thu, 1 Sep 2016, Jacek Anaszewski wrote:
> On 09/01/2016 07:25 AM, Rafał Miłecki wrote:
> > On 31 August 2016 at 21:00, Rafał Miłecki wrote:
> >> On 31 August 2016 at 20:23, Alan Stern wrote:
> >>> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
> >>>
reply starts with "Anyway, the serious limitation I see").
The code for a bunch of triggers must already be written. What would
the user do if he wanted to flash a single LED in response to both
CPU activity and MTD activity? If not
echo "cpu mtd" >/sys/class/leds/foo/trigger
then what?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
think this is such a bad use of the USB notifier. All you need
to know is when a device is attached to or unplugged from an LED's
port. Neither of these is a very frequent event.
However, there is still the question of how to know when an URB is
submitted or completed for the device in question. Obviously the USB
core would have to call an LED routine. But how would you determine
which LED(s) to toggle? Go through the entire list, looking for ones
that are bound to the USB device in question? This seems inefficient.
Use a hash table?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 25 Aug 2016, Alan Stern wrote:
> > Does the lsusb command do the mapping in the user space or maybe
> > it takes the names from kernel?
>
> lsusb does the mapping in userspace, based on an ID database. On my
> system (Fedora), the database is /etc/udev/hwdb.bi
manufacturer files are available in sysfs, otherwise they aren't.
> Does the lsusb command do the mapping in the user space or maybe
> it takes the names from kernel?
lsusb does the mapping in userspace, based on an ID database. On my
system (Fedora), the database is /etc/udev
> > 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/dev
16 matches
Mail list logo
