On Mon, Aug 13, 2007 at 11:18:21PM +0200, Steffen Koepf wrote:
> On Mon, Aug 13, 2007 at 05:04:40PM -0400, Alan Stern wrote:
> > On further thought, perhaps we shouldn't retry on -ETIMEDOUT errors.
> >
> > - if (result == 0 || result == -EPIPE)
> > + if (result <= 0 && result !
On Mon, Aug 13, 2007 at 05:04:40PM -0400, Alan Stern wrote:
> On further thought, perhaps we shouldn't retry on -ETIMEDOUT errors.
>
> - if (result == 0 || result == -EPIPE)
> + if (result <= 0 && result != -ETIMEDOUT)
I can test this patch if desired. But is it planned to
On Mon, 13 Aug 2007, Alan Stern wrote:
> This patch is the wrong way to do it. You should try this patch
> instead.
>
> Alan Stern
>
>
> Index: 2.6.22/drivers/usb/core/message.c
> ===
> --- 2.6.22.orig/drivers/usb/core/message.c
On Mon, 13 Aug 2007, Steffen Koepf wrote:
> From: Steffen Koepf <[EMAIL PROTECTED]>
>
> There is a USB-Device Init-Problem with the Apacer AE161 USB-Cardreader,
> which contains the Chip AU6375. The Cardreader init fails in about 50%
> of system boots, with the following lines:
>
> usb 1-6: unab
On Mon, 2007-08-13 at 08:36 -0700, Johannes Erdfelt wrote:
> Completely agreed. The hub driver entry should be removed. The hub
> driver is part of the USB core and should be maintained as such.
Removed
-
This SF.net email i
On Mon, 2007-08-13 at 16:11 +0200, Stefan Richter wrote:
> Joe Perches wrote:
> > I'll fix it and resubmit about 10 non-individual patches
> > in a couple of days.
>
> Better resubmit a single updated combo patch, for the entire MAINTAINERS
> file in one go. Unless you receive general objections.
On Mon, Aug 13, 2007, David Brownell <[EMAIL PROTECTED]> wrote:
> I'm also concerned with the reality that the MAINTAINERS file is
> not accurate. The $SUBJECT patch is one example; the named maintainer
> is no longer active (in that area, at least) and the named driver is
> not actually separable
David Brownell wrote:
> Is there general agreement that these "F:" entries should be used?
> Rather than, say, embedding references in the relevant parts of
> the source tree, adjacent to those files, where they would be more
> visible to people making relevant changes.
>
> I'm also concerned with
Joe Perches wrote:
> I'll fix it and resubmit about 10 non-individual patches
> in a couple of days.
Better resubmit a single updated combo patch, for the entire MAINTAINERS
file in one go. Unless you receive general objections.
--
Stefan Richter
-=-=-=== =--- -==-=
http://arcgraph.de/sr/
-
Am Montag 13 August 2007 schrieb Alan Cox:
> On Mon, 13 Aug 2007 15:48:40 +0200
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > Am Montag 13 August 2007 schrieb Alan Cox:
> > > +static int iuu_alloc_buf(struct iuu_private *priv)
> > > > +{
> > > > + priv->buf = kzalloc(256, GFP_KERNEL);
>
On Mon, 13 Aug 2007 15:48:40 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Montag 13 August 2007 schrieb Alan Cox:
> > +static int iuu_alloc_buf(struct iuu_private *priv)
> > > +{
> > > + priv->buf = kzalloc(256, GFP_KERNEL);
> > > + priv->dbgbuf = kzalloc(256, GFP_KERNEL);
> > > + priv->wr
> +static int
> +iuu_ioctl(struct usb_serial_port *port, struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> +
This is very wrong. Your driver may not intercept TCGETS and similar
ioctls. In fact you don't seem to need any of it. Terminal changes are
handled by the set_termios
Am Montag 13 August 2007 schrieb Alan Cox:
> +static int iuu_alloc_buf(struct iuu_private *priv)
> > +{
> > + priv->buf = kzalloc(256, GFP_KERNEL);
> > + priv->dbgbuf = kzalloc(256, GFP_KERNEL);
> > + priv->writebuf = kzalloc(256, GFP_KERNEL);
> > + if (!priv->buf || !priv->dbgbuf || !priv
+static int iuu_alloc_buf(struct iuu_private *priv)
> +{
> + priv->buf = kzalloc(256, GFP_KERNEL);
> + priv->dbgbuf = kzalloc(256, GFP_KERNEL);
> + priv->writebuf = kzalloc(256, GFP_KERNEL);
> + if (!priv->buf || !priv->dbgbuf || !priv->writebuf) {
> + dbg("%s problem a
On Sun, 12 Aug 2007, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d822865..fc87fa7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4764,6 +4764,7 @@ L: linux-usb-devel
Am Sonntag 12 August 2007 schrieb [EMAIL PROTECTED]:
> In this release, the driver use the interrupt context.
> So no more latency problem.
> I still kfree the buffers provided by the usb-serial framework.
>
> All comments/remarks are welcome
>
> This driver seems very stable ( tested with 5 read
On Sunday 12 August 2007, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
I seem to be missing some context for these "2many" patches; and
don't really see any in the MARC archives either. This seems like
about 600 patches out
On Mon, 2007-08-13 at 00:04 -0700, Pete Zaitcev wrote:
> I received two updates, and something jumped out:
>
> On Sun, 12 Aug 2007 23:38:00 -0700, [EMAIL PROTECTED] wrote:
> > +F: drivers/block/ub.c
>
> On Sun, 12 Aug 2007 23:38:30 -0700, [EMAIL PROTECTED] wrote:
> > +F: /drivers/usb/class/usblp.
I received two updates, and something jumped out:
On Sun, 12 Aug 2007 23:38:00 -0700, [EMAIL PROTECTED] wrote:
> +F: drivers/block/ub.c
On Sun, 12 Aug 2007 23:38:30 -0700, [EMAIL PROTECTED] wrote:
> +F: /drivers/usb/class/usblp.c
Why do some patterns start with a leading slash and others do
By the way,
What are the condition to see this driver in the main kernel tree ?
Alain
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de
[EMAIL PROTECTED]
Envoyé : dimanche 12 août 2007 11:02
À : [email protected]
Objet : [linux-usb-de
On Sat, 11 Aug 2007, [EMAIL PROTECTED] wrote:
> On my system(2.6.22) I don't have
> > @@ -327,6 +327,13 @@ UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x
> > US_SC_DEVICE, US_PR_DEVICE, NULL,
> > US_FL_FIX_CAPACITY),
>
> 2 Alan Stern: sorry for duplication - forgot to add 'c
On Saturday 11 August 2007, Alan Stern wrote:
> On Fri, 10 Aug 2007, David Brownell wrote:
>
> > > The code in ohci-hcd isn't very sophisticated about
> > > checking for interference from the firmware. Maybe because there are
> > > so many different implementations of OHCI floating around, it'
On my system(2.6.22) I don't have
> @@ -327,6 +327,13 @@ UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x
> US_SC_DEVICE, US_PR_DEVICE, NULL,
> US_FL_FIX_CAPACITY),
2 Alan Stern: sorry for duplication - forgot to add 'cc'.
Best regards,
Dima.
-
Hi,
On 8/10/07, David Brownell <[EMAIL PROTECTED]> wrote:
> On Friday 10 August 2007, Felipe Balbi wrote:
>
> >Better indentation
>
> I don't think so. This whole patch seems to make one
> type of change:
>
>
> > -unsigned charSt_ModeID;
> > -unsigned shortSt_ModeFlag;
> > -unsigned charSt_StTabl
On Fri, 10 Aug 2007 [EMAIL PROTECTED] wrote:
> From: Milinevsky Dmitry <[EMAIL PROTECTED]>
>
> This short patch allows NIKON D50 to be mounted as UMS[unusual device]
> on Linux niam 2.6.22-rc7-cfs-v18 #2 PREEMPT Tue Jul 3 22:35:53 EEST
> 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIn
On Fri, 10 Aug 2007, David Brownell wrote:
> > The code in ohci-hcd isn't very sophisticated about
> > checking for interference from the firmware. Maybe because there are
> > so many different implementations of OHCI floating around, it's hard
> > to know what approach will work on all of th
On Friday 10 August 2007, Felipe Balbi wrote:
>Better indentation
I don't think so. This whole patch seems to make one
type of change:
> - unsigned char St_ModeID;
> - unsigned short St_ModeFlag;
> - unsigned char St_StTableIndex;
> - unsigned char St_CRT2CRTC;
>
On Friday 10 August 2007, [EMAIL PROTECTED] wrote:
> Previous boards were likely seeing USB_ARCH_HAS_HCD selected by way of
> PCMCIA or PCI, though none of those are required for hcd support on SH.
> Enable support unconditionally.
In fact, maybe that ARCH_HAS_HCD switch should vanish.
On Friday 10 August 2007, Alan Stern wrote:
> > When the OLPC comes up from suspend, a small bit of Open Firmware code
> > gets run, this writes 1 to HcCommandStatus, resetting the OHCI chip into
> > Suspend mode, then writes into HcRhDescriptorB and HcRhPortStatus*,
> > bringing up the power to th
On Fri, 10 Aug 2007, Zephaniah E. Hull wrote:
> > After you get up :-), check udev->state at the end of
> > usb_suspend_device(). It should be USB_STATE_SUSPENDED, and nothing
> > should change it until usb_resume_device() runs.
> >
> > Are you maybe seeing ohci_rh_resume() get called twice in
On Thu, Aug 09, 2007 at 02:56:08PM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > Urgh, I definitely need some sleep, yes, it's a &&.
>
> > Which, from the debugging statements from previous failed runs, we have
> > something odder.
> >
> > reset_resume == 0, udev-
On Fri, 10 Aug 2007, Yoshihiro Shimoda wrote:
> Hi, Alan
>
> > Please test the changes to your respective drivers. I don't have the
> > necessary hardware.
>
> I applied this patch. I tested USB testing driver and some usb device
> and I confirmed it is working.
Good. Thank you for testing.
Hi,
On 8/10/07, Felipe Balbi <[EMAIL PROTECTED]> wrote:
> The following patch series implements a series of cleanups in the sisusbvga
> driver.
>
> Still some stuff to do, but at least we can have better readability on the
> code.
>
> If anyone has any comments, please do.
>
> TODO:
> * R
Hi, Alan
> Please test the changes to your respective drivers. I don't have the
> necessary hardware.
I applied this patch. I tested USB testing driver and some usb device
and I confirmed it is working.
Thanks,
Yoshihiro Shimoda
--
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> Urgh, I definitely need some sleep, yes, it's a &&.
> Which, from the debugging statements from previous failed runs, we have
> something odder.
>
> reset_resume == 0, udev->state == USB_STATE_CONFIGURED.
>
> This is an even more bizarre state then
On Thu, Aug 09, 2007 at 01:00:09PM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > I'll try to keep this making sense, but I'm going to have to reply to
> > things slightly out of order.
>
> Thanks for the detailed reply.
>
> > On Thu, Aug 09, 2007 at 11:27:02AM -04
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> I'll try to keep this making sense, but I'm going to have to reply to
> things slightly out of order.
Thanks for the detailed reply.
> On Thu, Aug 09, 2007 at 11:27:02AM -0400, Alan Stern wrote:
> > On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> >
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> OHCI isn't coming back on the OLPC after resume.
>
> After a bit of testing, the problem seems to have come down to two points.
>
> The first is that ohci_pci_resume is not forcing the root hub to be resumed
> properly, that's a fairly trivial and o
> > You mean ohci->regs->control doesn't contain OHCI_USB_RESET in the
> > appropriate bits? What does it contain? And why?
>
> ohci->hc_control & OHCI_CTRL_HCFS == OHCI_USB_SUSPEND, and I honestly
> don't have the foggiest clue how or why it has that after coming back
> from the chip being pow
I'll try to keep this making sense, but I'm going to have to reply to
things slightly out of order.
On Thu, Aug 09, 2007 at 11:27:02AM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > OHCI isn't coming back on the OLPC after resume.
> >
> > After a bit of testing, th
On Thursday 09 August 2007, Zephaniah E. Hull wrote:
> OHCI isn't coming back on the OLPC after resume.
>
> After a bit of testing, the problem seems to have come down to two points.
>
> The first is that ohci_pci_resume is not forcing the root hub to be resumed
> properly, that's a fairly trivia
On Thu, 9 Aug 2007, Andrew Morton wrote:
> This failed the Vaio test. I guess it triggered a USB bug.
>
> With this patch applied, when I hotplug my wireless mouse, the little LED
> on the mouse comes on for a second or so then goes out and no pointy clicky
> for me.
>
> It says:
>
> [ 152.48
On Fri, 03 Aug 2007 12:37:12 -0600 Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> Here's the second (and probably final) posting of the msleep() with
> hrtimers patch. The problem being addressed here is that the current
> msleep() will stop for a minimum of two jiffies, meaning that, on a
> HZ=100
On Wed, 8 Aug 2007, Greg KH wrote:
> On Wed, Aug 08, 2007 at 11:59:18AM -0400, Alan Stern wrote:
> > This patch (as955) prevents the interface-related sysfs files and
> > endpoint pseudo-devices from being deleted and recreated when a call
> > to usb_set_interface() specifies the current altsettin
On Wed, Aug 08, 2007 at 11:59:18AM -0400, Alan Stern wrote:
> This patch (as955) prevents the interface-related sysfs files and
> endpoint pseudo-devices from being deleted and recreated when a call
> to usb_set_interface() specifies the current altsetting. Since the
> altsetting doesn't get chang
On 8/3/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> I am wondering if Ubuntu has better user reporting, so if Matthew
> complains, it really means something.
https://bugs.launchpad.net/bugs/85488
Most of the current quirks list was assembled by Oliver from this thread IIRC.
/Amit
--
Amit Kuch
On Tue, 7 Aug 2007, David Engraf wrote:
> You said your Intel board has also problems with the handoff.
> Could you try the follwing patch, because the EHCI documentation
> says that the OS must set the EHCI_USBLEGSUP_OS bit and then
> wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never
>
You said your Intel board has also problems with the handoff.
Could you try the follwing patch, because the EHCI documentation
says that the OS must set the EHCI_USBLEGSUP_OS bit and then
wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never
uses the EHCI_USBLEGSUP_OS flag at the moment.
On m
Greg KH wrote:
> On Tue, Aug 07, 2007 at 05:46:05AM +0300, Faidon Liambotis wrote:
>> Dell Wireless Broadband ExpressCards are rebrands of Novatel's cards.
>> Add all of their known PCI IDs to date along with their mapping to the exact
>> Novatel model to the Option driver which already claims to s
On Tue, Aug 07, 2007 at 05:46:05AM +0300, Faidon Liambotis wrote:
> Dell Wireless Broadband ExpressCards are rebrands of Novatel's cards.
> Add all of their known PCI IDs to date along with their mapping to the exact
> Novatel model to the Option driver which already claims to support them.
Are yo
On Fri, 3 Aug 2007, Inaky Perez-Gonzalez wrote:
> +static
> +void usb_dev_reset_delayed_task(struct work_struct *ws)
> +{
> + struct usb_dev_reset_ctx *reset_ctx =
> + container_of(ws, struct usb_dev_reset_ctx, ws);
> + struct usb_device *usb_dev = reset_ctx->usb_dev;
> + s
On Fri, 3 Aug 2007, Inaky Perez-Gonzalez wrote:
> +/*
> + * WUSB devices are simple: they have no hubs behind, so the mapping
> + * device <-> virtual port number becomes 1:1. Why? to simplify the
> + * life of the device connection logic in
> + * drivers/usb/wusbcore/devconnect.c. When we do the
On Fri, 03 Aug 2007 15:29:21 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > Well, we did - with hindsight it may not have been such a great plan :)
> > I believe that Fedora did as well, but have disabled it in an update
> > kernel.
>
> Yeah, autosuspend broke too many devices. Way too many
On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:
> > Plus if you're connected to such a device for monitoring purposes you're
> > probably powered by it as well, so you have little to gain from suspend
> > even if it works.
>
> I currently don't have any HID UPS by hand to veri
Dave Jones wrote:
> On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:
>
>>> Plus if you're connected to such a device for monitoring purposes
>>> you're probably powered by it as well, so you have little to gain
>>> from suspend even if it works.
>>
>> I currently don't have any HID UPS
On Friday 03 August 2007, Dave Jones wrote:
> > > Plus if you're connected to such a device for monitoring purposes you're
> > > probably powered by it as well, so you have little to gain from suspend
> > > even if it works.
> >
> > I currently don't have any HID UPS by hand to verify, but
On Fri, 3 Aug 2007, Adam Kropelin wrote:
> Although I have no proof immediately at hand, I suspect at a minimum HID
> power class devices should be blacklisted from autosuspend. Given the
> spotty USB implementations on many such devices I'd be surprised if
> suspend worked reliably.
I agree
On Thu, Aug 02, 2007 at 09:43:29AM -0700, Greg KH wrote:
...
> It wasn't just MIPS. IBM has a very popular blade system that has huge
> issues with this, and I think there are some other IBM systems based on
> the same BIOS that also do bad things if we don't grab the USB
> controller away from th
On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote:
> The last report appears to be related more to the EHCI-cpufreq problem,
> for which a patch was recently posted.
There seem to be multiple issues there, with at least one of them being
autosuspend related.
--
Matthew Garrett | [EMA
On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote:
> On Fri, 3 Aug 2007, Dave Jones wrote:
>
> > here's a head start for you.
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
> > https://bugzilla.re
On Fri, 3 Aug 2007, Dave Jones wrote:
> here's a head start for you.
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953
> https://bugzilla.redhat.com/bugzilla/s
On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
> On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
> > On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
> >
> > > Compare that to:
> > >
> > > "My USB printer broke, guess I'd better report it to LKML".
>
On Fri, Aug 03, 2007 at 06:08:11PM +0200, Oliver Neukum wrote:
> Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > > Which is why I didn't suggest doing that, of course. The only
> > > one making that kind of straw man argument seems to be you.
> >
> > But however you phrase it, that's
On Fri, 3 Aug 2007 15:45:32 -0400, Dave Jones <[EMAIL PROTECTED]> wrote:
> > > My experience suggests the opposite. Of the several I've tried so far,
> > > none have worked with usb suspend.
> >
> > All of mine work. I'm wondering if this has something to do with
> > a hub or motherboard...
On Fri, Aug 03, 2007 at 12:34:47PM -0700, Pete Zaitcev wrote:
> On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones <[EMAIL PROTECTED]> wrote:
> > On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
> >
> > > Kernel developers are a diverser lot than you think ;-)
> > > We don't enabl
On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
>
> > Kernel developers are a diverser lot than you think ;-)
> > We don't enable autosuspend in drivers we can't test, except where
> > the lack of a kerne
On 08/03/2007 01:48 PM, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
>> On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
>>> But while this is still a likely probability, the chances are no
>>> distribution is going to ship with CONFIG_USB_SUSPE
Hi Greg,
here is the patch again, this time against 2.6.23-rc1.
Best Regards,
Hermann
This patch contains two fixes submitted by Ondrej Palkovsky:
- the 'ACK' packet is sent after the transfer of the USB packet is
completed, i.e. in the write_callback function. Because the close
function send
On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
> On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
> > But while this is still a likely probability, the chances are no
> > distribution is going to ship with CONFIG_USB_SUSPEND enabled.
>
> I wouldn't be so sure, I was thin
On Fri, 3 Aug 2007, Oliver Neukum wrote:
> Devices rarely simply crash.
It's rare, but it does happen. I've seen a device get so messed up by
suspend that it needed a reset; it wouldn't be surprising to find other
devices requiring a power cycle.
Alan Stern
-
On Fri, 3 Aug 2007, Jiri Kosina wrote:
> What I have been seeing with both these keyboards was: if connected to
> UHCI controller, root hub not auto-suspended, as soon as they got
> autosuspended, and keys were pressed on them rapidly, very often some
> keypressess got lost. I didn't experience
On Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > > Speaking of which, what's this /dev/bus/usb/* crap on Ubuntu?
> > > I had to undo all that on my Feisty system before any normal
> > > /proc/bus/usb stuff would work again.
> >
On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
>
> > Compare that to:
> >
> > "My USB printer broke, guess I'd better report it to LKML".
>
> But while this is still a likely probability, the chances are no
> distr
On Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > And, frankly, if I got a requestor like that every time I plugged in a
> > new USB device I'd be fairly unhappy.
>
> Which is why my comment was about something else entirely!
>
On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
> > On Friday 03 August 2007, Matthew Garrett wrote:
> > > Popping up a box saying "Is your device broken?" isn't good UI.
> >
> > Which is why I didn't suggest doing that, of course
Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > Which is why I didn't suggest doing that, of course. The only
> > one making that kind of straw man argument seems to be you.
>
> But however you phrase it, that's effectively what it is. "Does your
> device work?" just makes users wonder wh
On Friday 03 August 2007, Dave Jones wrote:
> > We have been playing with runtime autosuspend of HID devices, are
> > currently postponed the full support, as it turns out that many devices
> > don't support this feature properly (probably due to not being tested in
> > Windows).
>
> Intere
On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
> are you sure about windows suspending the HID devices in runtime? I have
> never seen LEDs of USB keyboard connected to windows host to go off after
> some time of not using it.
Ah, sorry - on reading more closely, HID devices will
On Fri, 3 Aug 2007, David Brownell wrote:
> And could you elaborate on "many"? What proportion of HID devices (by
> volume, model, etc) seem to have problems?
Last time I tried with two random USB keyboards - one from Logitech and
one from Chicony, I don't remember the exact PIDs, but could lo
Dave Jones wrote:
> On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
>> On Fri, 3 Aug 2007, Matthew Garrett wrote:
>>
>>> Windows will autosuspend hubs, bluetooth devices, HID devices
>>
>> Hi Matthew,
>>
>> are you sure about windows suspending the HID devices in runtime? I
>> have nev
On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 07:01:11AM -0700, David Brownell wrote:
>
> > Which is, as I pointed out, the wrong response. Desktoppy
> > people should be making their tools do more intelligent things
> > with new USB devices they see ... like updating
On Fri, Aug 03, 2007 at 10:41:13AM -0400, Alan Stern wrote:
> On Fri, 3 Aug 2007, Matthew Garrett wrote:
> > I'm not so
> > enthusiastic about the "Increase the timeout case" - it doesn't avoid
> > any races, just makes them less likely. USB is likely to get loaded in
> > the initramfs, but we m
On Fri, 3 Aug 2007, David Engraf wrote:
> So we have hardware which has problems when we are not doing the
> handoff, and hardware which has
> problems when we are doing the handoff...
What hardware has problems when we do the handoff? Your system and
mine experience a delay, but it doesn't br
On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > Popping up a box saying "Is your device broken?" isn't good UI.
>
> Which is why I didn't suggest doing that, of course. The only
> one making that kind of straw man argument se
On Fri, 3 Aug 2007, Dave Jones wrote:
> Interesting. Which devices did you notice failing? Was it a case that
> they would sleep and not come back out of that state?
Random keyboards, even connection to EHCI/OHCI seemed to make difference.
We have been doing some experiments with Alan during O
On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
> On Fri, 3 Aug 2007, Matthew Garrett wrote:
>
> > Windows will autosuspend hubs, bluetooth devices, HID devices
>
> Hi Matthew,
>
> are you sure about windows suspending the HID devices in runtime? I have
> never seen LEDs of
On Friday 03 August 2007, Dave Jones wrote:
> On Thu, Aug 02, 2007 at 11:06:08PM -0700, David Brownell wrote:
>
> > Sometimes when I plug in a USB device I get a dialog asking if I want to
> > configure it ... surely it would be possible to have that mechanism also
> > consult a database (part
On Fri, Aug 03, 2007 at 04:32:07PM +0200, Oliver Neukum wrote:
> Am Freitag 03 August 2007 schrieb Dave Jones:
> > On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
> >
> > > Kernel developers are a diverser lot than you think ;-)
> > > We don't enable autosuspend in drivers w
On Fri, 3 Aug 2007, Matthew Garrett wrote:
> Windows will autosuspend hubs, bluetooth devices, HID devices
Hi Matthew,
are you sure about windows suspending the HID devices in runtime? I have
never seen LEDs of USB keyboard connected to windows host to go off after
some time of not using it.
On Fri, 3 Aug 2007, Matthew Garrett wrote:
> Windows will autosuspend hubs, bluetooth devices, HID devices and CDC
> devices, so I think we're safe suspending those by default.
And we know that we're not safe suspending scanners and many printers
by default. But that leaves plenty of other dev
On Fri, Aug 03, 2007 at 10:28:19AM -0400, Alan Stern wrote:
> On Fri, 3 Aug 2007, Matthew Garrett wrote:
> There are two possible solutions, both involving the kernel (since
> userspace can't respond in time). One is to change the default timeout
> to something larger, or even disable it complete
Am Freitag 03 August 2007 schrieb Dave Jones:
> On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
>
> > Kernel developers are a diverser lot than you think ;-)
> > We don't enable autosuspend in drivers we can't test, except where
> > the lack of a kernel driver forces us to use a
On Fri, 3 Aug 2007, Matthew Garrett wrote:
> This patch is exactly that - a way of getting most of the benefits of
> autosuspend without any real probability of breaking hardware. If you
> mean "Are the distributions willing to pop up dialogs asking users to
> start caring about obscure aspects
On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
> Kernel developers are a diverser lot than you think ;-)
> We don't enable autosuspend in drivers we can't test, except where
> the lack of a kernel driver forces us to use a broad swipe. Printers
> were tested, too, and most pri
On Thu, Aug 02, 2007 at 11:06:08PM -0700, David Brownell wrote:
> Sometimes when I plug in a USB device I get a dialog asking if I want to
> configure it ... surely it would be possible to have that mechanism also
> consult a database (part of a distro, or on some web server) fpr info
> about
On Fri, Aug 03, 2007 at 07:01:11AM -0700, David Brownell wrote:
> Which is, as I pointed out, the wrong response. Desktoppy
> people should be making their tools do more intelligent things
> with new USB devices they see ... like updating databases of
> broken devices, and configuring *this* syst
On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
>
> > Which one is more likely to conclude at some point?
Good question ... though "how will it conclude" is also relevant.
> > Compare that to:
> >
> > "My USB printer broke, guess I
On 8/3/07, Rogan Dawes <[EMAIL PROTECTED]> wrote:
> Matthew Garrett wrote:
> > On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote:
> >> Am Freitag 03 August 2007 schrieb Matthew Garrett:
> >>> It's certainly possible to do that, but it's also possible to have a
> >>> userspace solution t
On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
> Compare that to:
>
> "My USB printer broke, guess I'd better report it to LKML".
But while this is still a likely probability, the chances are no
distribution is going to ship with CONFIG_USB_SUSPEND enabled. Breaking
people's hard
Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote:
>> Am Freitag 03 August 2007 schrieb Matthew Garrett:
>>> It's certainly possible to do that, but it's also possible to have a
>>> userspace solution that whitelists devices. The question is whether the
>>> de
1 - 100 of 5055 matches
Mail list logo
