udev USB autosupend whitelist (was Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version)

[Hans de Goede <hdegoede@redhat.com>]

Hi,

Going a bit off-topic here, so changed the subject.
I will reply on topic in another mail.

On 16-02-18 03:27, Brian Norris wrote:
> Hi Hans,
> 
> On Tue, Feb 13, 2018 at 12:25:55PM +0100, Hans de Goede wrote:
>> On 13-02-18 03:24, Brian Norris wrote:
>>> On Mon, Jan 08, 2018 at 10:44:16AM +0100, Hans de Goede wrote:
>>>> Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
>>>> removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
>>>> instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
>>>>
>>>> This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
>>>> has several issues (see the original commit message). An added advantage
>>>> of moving over to the USB-core reset-resume handling is that it also
>>>> disables autosuspend for these devices, which is similarly broken on these.
>>>
>>> Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
>>> think so -- I'm using one now.
>>
>> And have you manually enabled USB autosuspend for it, or are you
>> running something which might have done so, e.g. powertop --auto-tune ?
>>
>> Because if you did not do that then you're already not using autosuspend
>> for your QCA devices and this patch will change nothing.
> 
> I use a set of udev rules that manually whitelist devices for
> autosuspend. You can see it here:
> 
> https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
> 
> You'll find at least one Rome chip in there.

Oh, that is a very interesting link for the work I've been doing to
improve Linux power-consumption in general:

https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife

I was actually planning on at least doing such a list for WWAN modems,
for btusb my approach has been to just enable it everywhere
(except for QCA devices as I got bugreports for those).

Note that I plan to eventually submit this whitelist to the
udev rules which are part of systemd upstream, so if chromeos
is using systemd too, this is something to be aware of for you.

Question, is the white-listing of the root and rate-limiting
hubs really necessary? I thought these have this enabled by default?

Also any caveats here I should be aware of?

Regards,

Hans