On Friday 22 April 2005 7:39 pm, Glenn Maynard wrote:
> > I think the "greedy" approach is probably best.
>
> Based on David's explanation, yes; I'll have it choose the highest-power
> configuration <= 100mA, or the lowest power configuration if none fit.
> (I have one pen drive, a 128mb Attache,
Sorry for the late reply on this--I missed this message while off on
another project for a while, and I'm just getting back to this.
On Fri, Feb 25, 2005 at 10:57:44AM -0500, Alan Stern wrote:
> On Thu, 24 Feb 2005, Glenn Maynard wrote:
>
> > > It's probably not a good idea to prefer the lower-po
On Thursday 24 February 2005 2:20 pm, Glenn Maynard wrote:
> > The exception is that some (self-powered) root hubs have limits on the
> > amount of power they put out. For example, they might not be able to
> > put more than 250 mA out on their single port, or they might have two
> > ports each l
On Thu, 24 Feb 2005, Glenn Maynard wrote:
> > It's probably not a good idea to prefer the lower-power configuration by
> > default. A better heuristic might be to prefer the highest-power
> > configuration that fits within the parent hub's power budget.
>
> A quick look suggests that doing this
On Thursday 24 February 2005 11:45 am, Glenn Maynard wrote:
>
> Also, reading /proc/bus/usb/devices or lsusb -v will (currently) query
> string descriptors, even if I don't want them at all (and usb/devices
> will do so for all devices, not just the ones I'm interested in).
Feel free to submit a
On Thu, Feb 24, 2005 at 01:50:59PM -0800, David Brownell wrote:
> Feel free to submit a patch against lsusb (CVS), maybe adding/documenting
> a new flag that says not to do no more than read /proc/bus/usb/BBB/DDD
> files. There's already a way to say "just look at device BBB/DDD",
> you may have m
On Thursday 24 February 2005 8:16 am, Randy.Dunlap wrote:
> Steve Calfee wrote:
> >
> > IIRC, one reason this was tried (and dropped) is that some devices
> > load new firmware which alters all/most/some of the device
> > descriptors, so the kernel cache is incorrect... unless they are
> > re-read
On Thu, Feb 24, 2005 at 02:04:38PM -0800, David Brownell wrote:
>
> That works for EZ-USB ... someone once told me that scheme is
> patented, which would explain why DFU uses a less robust scheme!
Yes, the EZ-USB scheme is patented, and yes, that is why the DFU spec
does not use that scheme.
tha
On Wed, 23 Feb 2005, Randy.Dunlap wrote:
> IIRC, one reason this was tried (and dropped) is that some devices
> load new firmware which alters all/most/some of the device
> descriptors, so the kernel cache is incorrect... unless they are
> re-read after a firmware download.
>
> Anybody else recal
On Thu, Feb 24, 2005 at 10:30:17AM -0500, Alan Stern wrote:
> Anyway there's no reason to put the extra information about inactive
> configurations or altsettings in sysfs, since it's already available in
> usbfs.
> Your program can always use the information in /proc/bus/usb/devices, or
> it can
Steve Calfee wrote:
Hi Randy,
Ironically, my spam trap email account is now blocked from sending to
the mailing list, probably because of too much spamming from hotmail.
So, if you think this is relevant, please forward to the list. Anyway
see below:
At 02:18 PM 2/23/2005 -0800, you wrote:
A
On Wed, 23 Feb 2005, Glenn Maynard wrote:
> On Wed, Feb 23, 2005 at 05:11:16PM -0500, Alan Stern wrote:
> > lsusb does make the queries (going through usbfs). lsusb _has_ to use
> > libusb; sysfs only includes information for active configurations whereas
> > lsusb wants to print out information
Hi Randy,
Ironically, my spam trap email account is now blocked from sending to the
mailing list, probably because of too much spamming from hotmail. So, if you
think this is relevant, please forward to the list. Anyway see below:
At 02:18 PM 2/23/2005 -0800, you wrote:
Alan Stern wrote:
On W
On Wed, Feb 23, 2005 at 05:11:16PM -0500, Alan Stern wrote:
> lsusb does make the queries (going through usbfs). lsusb _has_ to use
> libusb; sysfs only includes information for active configurations whereas
> lsusb wants to print out information for all configurations.
Is there a design reason f
Alan Stern wrote:
On Wed, 23 Feb 2005, Glenn Maynard wrote:
On Wed, Feb 23, 2005 at 03:39:29PM -0500, Alan Stern wrote:
I ngelected to mention it above, but the stored strings should also be
used in core/devices.c for populating /proc/bus/usb/devices. And since
the strings should be accessible t
On Wed, 23 Feb 2005, Glenn Maynard wrote:
> On Wed, Feb 23, 2005 at 03:39:29PM -0500, Alan Stern wrote:
> > I ngelected to mention it above, but the stored strings should also be
> > used in core/devices.c for populating /proc/bus/usb/devices. And since
> > the strings should be accessible throu
On Wed, Feb 23, 2005 at 03:39:29PM -0500, Alan Stern wrote:
> I ngelected to mention it above, but the stored strings should also be
> used in core/devices.c for populating /proc/bus/usb/devices. And since
> the strings should be accessible through the usb_device and related
> structures, other d
On Wed, 23 Feb 2005, Greg KH wrote:
> On Tue, Feb 22, 2005 at 01:38:03PM -0500, Alan Stern wrote:
> >
> > A less general solution that could suffice for your problem would be to
> > have the kernel store the Manufacturer, Product, and Serial strings (and
> > also the Configuration and Interface n
On Tue, Feb 22, 2005 at 01:38:03PM -0500, Alan Stern wrote:
>
> A less general solution that could suffice for your problem would be to
> have the kernel store the Manufacturer, Product, and Serial strings (and
> also the Configuration and Interface name strings) rather than query the
> device eve
On Tue, 22 Feb 2005, Glenn Maynard wrote:
> On Tue, Feb 22, 2005 at 01:38:03PM -0500, Alan Stern wrote:
> > At present there's no way to do it in general. If you restrict your
> > program to the period while usb-storage waits before scanning the devices
> > then things will work, as you've seen.
On Tue, Feb 22, 2005 at 01:38:03PM -0500, Alan Stern wrote:
> At present there's no way to do it in general. If you restrict your
> program to the period while usb-storage waits before scanning the devices
> then things will work, as you've seen. But there's no guarantee about how
> long that per
On Tue, 22 Feb 2005, Glenn Maynard wrote:
> The system isn't hung. (cat is hung, until the timeout completes.) usb-
> storage/ub is timing out as a result of serial being read. All I want
> is to be able to read the serial (and product and manufacturer strings)
> without risking interference wi
On Tue, Feb 22, 2005 at 10:27:51AM -0500, Alan Stern wrote:
> If I'm reading your timestamps correctly (seconds and fractions of a
> second), you made the stack dump only 4 seconds after things stopped
> happening. That's not long enough; the SCSI drivers have a timeout of 10
> seconds (I think) f
On Mon, 21 Feb 2005, Glenn Maynard wrote:
> > It's known that some USB mass storage devices are unable to handle control
> > requests on endpoint 0 while carrying out SCSI commands. Since reading
> > the serial string involves just such a control request, it's not
> > surprising that your stic
On Mon, 21 Feb 2005, Glenn Maynard wrote:
> I'm polling for changes in USB devices; when something changes, I grab the
> contents of idVendor, idProduct, serial, product and manufacturer. (The
> serial is used to make a best effort at detecting when a previously-known
> device was inserted; thoug
I'm polling for changes in USB devices; when something changes, I grab the
contents of idVendor, idProduct, serial, product and manufacturer. (The
serial is used to make a best effort at detecting when a previously-known
device was inserted; though I'm seeing that many devices don't have unique
se
26 matches
Mail list logo
