lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121016165436.GA5140@kroah.com>
Date:	Tue, 16 Oct 2012 09:54:36 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Michael Spang <spang@...gle.com>, linux-usb@...r.kernel.org
Cc:	Dave Jones <davej@...hat.com>, Michael Spang <spang@...omium.org>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>, greno@...izon.net,
	Fedora Kernel Team <kernel-team@...oraproject.org>
Subject: Re: USB keyboard backlight powering down.

On Tue, Oct 16, 2012 at 12:45:56PM -0400, Michael Spang wrote:
> On Tue, Oct 16, 2012 at 11:20 AM, Dave Jones <davej@...hat.com> 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.
> >
> > Looking over the 3.6.1 changelog, I see this change, which sounds
> > like it might be responsible ?
> >
> > commit ee537508bdc0c00b96ac497f3d82a68f820e6182
> > Author: Michael Spang <spang@...omium.org>
> > Date:   Fri Sep 14 13:05:49 2012 -0400
> >
> >     Increase XHCI suspend timeout to 16ms
> 
> I don't think this is related to your problem, as this patch is in
> suspend/resume code. It just allows the controller more time to halt.

Yeah, that looks odd.

But, (adding linux-usb@...r), I think we enabled some "put the device to
sleep if it is idle" logic for all devices, which is what is looking
like is happening here.  The keyboard is being told to go to sleep in
order to save power.

We are saving more power, but it looks like the user wants to disable
it, which makes sense for this device.

So, do we do this from within the kernel with a blacklist, or rely on
the user knowing how to poke the proper sysfs file to turn the keyboard
back on?

greg k-h

> 
> Thanks,
> Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ