linux-kernel - Re: USB autosuspend causing trouble with bluetooth

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: <CABVT_gdCvbK8mUQMjDmiAmc_6kbBUMf4XFeAZ=zzjOYS+7oCGg@mail.gmail.com>
Date:	Tue, 20 Jan 2015 18:58:13 +0400
From:	Kirill Elagin <kirelagin@...il.com>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: USB autosuspend causing trouble with bluetooth

On Tue, Jan 20, 2015 at 5:06 PM, Oliver Neukum <oneukum@...e.de> wrote:
> On Tue, 2015-01-20 at 16:18 +0400, Kirill Elagin wrote:
>> I use a Logitech wireless keyboard (with a Unifying receiver) and it
>> keeps working fine even with `auto`.
>>
>> That is, everything is OK if the receiver is plugged before
>> `power/control` is switched to `auto`.
>
> Wait. There is no power/control file for the receiver before
> you plug it in. We are having a very big misunderstanding here.

Sorry for not being clear. I was referring to `power/control` of the
USB-device itself except for the cases when I was talking about
hot-plugging issues — in those cases I was referring to the
`power/control` of the root hub.

I might be using terminology in a wrong way. By `power/control` of a
root hub I mean `/sys/bus/usb/devices/usb<bus_number>/power/control`
and by `power/control` of a device I mean
`/sys/bus/usb/devices/<bus_number>-<port_number>/power/control`.

>> But if I first set it to `auto`, then plug the receiver in, it is not
>> detected (nothing in dmesg). Kernel
>> detects it as soon as I `echo on` to the relevant `power/control`.
>
> Are you on power/control for the device or the port?
> If you are using the port's control file you might be switching
> on Port Power Off. Then of course the port will not process
> hotplugs. Please clarify!

In this particular case I was talking about the `power/control` of the root hub.

`laptop-mode-tools` by default writes `auto` to `power/control` of
_all_ the USB devices, root hubs included (even when on AC). Is it
really expected that kernel might completely power off the physical
USB port? Sounds weird.

Here is an even more strange thing. First I set all the USB power
management to the defaults (that is, `auto` for all the usb devices
including root hubs). Again, the keyboard keeps working and as soon as
I unplug the receiver kernel says the device was disconnected. Now if
I plug the receiver back nothing happens. _But_ if I plug a flash
drive in the save physical port it gets detected. So, I tried a number
of other usb devices and it totally looks like USB2.0 ones are
properly hot-plugged while USB1.1 devices are not. Does this sound to
you like a bug in my laptop's hardware?
--
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/