public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: Dave Jones <davej@redhat.com>, Michael Spang <spang@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	greno@verizon.net,
	Fedora Kernel Team <kernel-team@fedoraproject.org>
Subject: Re: USB keyboard backlight powering down.
Date: Tue, 16 Oct 2012 10:29:30 -0700	[thread overview]
Message-ID: <20121016172930.GF5378@xanatos> (raw)
In-Reply-To: <20121016152023.GA25506@redhat.com>

On Tue, Oct 16, 2012 at 11:20:23AM -0400, Dave Jones wrote:
> Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
> Logitech USB keyboard doesn't light up until he hits a key, and then
> it immediately powers back off, defeating the purpose of having an
> illumated keyboard.

Does he have the udev bug that turns on auto-suspend for USB keyboards?
ISTR there was a Fedora bug that was fixed.

I ask because it sounds like the keyboard is suspended between key
strokes, and that powers down the light.  The USB hid driver doesn't
auto-suspend devices that have user toggleable LEDs.  For instance, it
won't suspend a keyboard if the caps lock or num lock key is set.  But
I'm betting the device doesn't advertise the backlight like the caps
lock key is advertised.

> Looking over the 3.6.1 changelog, I see this change, which sounds
> like it might be responsible ?

Did he actually do a git bisect?  Because that commit only applies to
when the system is suspended, not when the USB device is suspended.

Sarah Sharp

> commit ee537508bdc0c00b96ac497f3d82a68f820e6182
> Author: Michael Spang <spang@chromium.org>
> Date:   Fri Sep 14 13:05:49 2012 -0400
> 
>     Increase XHCI suspend timeout to 16ms
>     
>     commit a6e097dfdfd189b6929af6efa1d289af61858386 upstream.
>     
>     The Intel XHCI specification says that after clearing the run/stop bit
>     the controller may take up to 16ms to halt. We've seen a device take
>     14ms, which with the current timeout of 10ms causes the kernel to
>     abort the suspend. Increasing the timeout to the recommended value
>     fixes the problem.
>     
>     This patch should be backported to kernels as old as 2.6.37, that
>     contain the commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI:
>     PCI power management implementation".
>     
>     Signed-off-by: Michael Spang <spang@chromium.org>
>     Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> 
> Any thoughts on how we could prevent this generically, or is this
> something we're going to have to quirk around for specific devices we
> don't want to power down ?
> 
> 	Dave
> 

      parent reply	other threads:[~2012-10-16 17:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16 15:20 USB keyboard backlight powering down Dave Jones
2012-10-16 16:45 ` Michael Spang
2012-10-16 16:54   ` Greg Kroah-Hartman
2012-10-16 17:35     ` Sarah Sharp
2012-10-17 12:55       ` Josh Boyer
2012-10-17 13:09         ` Gerry Reno
2012-10-17 13:31           ` Josh Boyer
2012-10-17 13:49             ` Gerry Reno
2012-10-16 17:29 ` Sarah Sharp [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121016172930.GF5378@xanatos \
    --to=sarah.a.sharp@linux.intel.com \
    --cc=davej@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=greno@verizon.net \
    --cc=kernel-team@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spang@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox