Bug 1090555 - Disable HID Battery reporting for Broadcom HID/HCI device [NEEDINFO]
Summary: Disable HID Battery reporting for Broadcom HID/HCI device
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-23 15:06 UTC by Bastien Nocera
Modified: 2014-12-10 15:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-10 15:03:23 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)
0001-HID-input-disable-battery-for-0A5C-4502.patch (3.63 KB, patch)
2014-04-23 15:47 UTC, Benjamin Tissoires
no flags Details | Diff
0001-HID-input-disable-battery-for-0A5C-4502.patch V2 (3.63 KB, patch)
2014-04-24 15:47 UTC, Benjamin Tissoires
no flags Details | Diff

Description Bastien Nocera 2014-04-23 15:06:25 UTC
Tested with:
kernel-3.14.1-200.fc20.x86_64
kernel-3.13.10-200.fc20.x86_64

Those are the devices shown by the builtin HID/HCI Broadcom chip:
Bus 001 Device 008: ID 0a5c:4503 Broadcom Corp. Mouse (Boot Interface Subclass)
Bus 001 Device 007: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface Subclass)
Bus 001 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)

0A5C:4502 exports a "power supply" through its HID report descriptors, but trying to get the capacity will fail after a while:
$ time cat /sys/class/power_supply/hid--battery/capacity 
cat: /sys/class/power_supply/hid--battery/capacity: No data available

real	0m5.003s
user	0m0.001s
sys	0m0.001s

This causes a very slow boot, as udev tries to gather information about it, and will show up in upower as well with somewhat bizarre values:
Device: /org/freedesktop/UPower/devices/battery_hid__battery
  native-path:          hid--battery
  model:                HID 0a5c:4502
  power supply:         no
  updated:              Wed 23 Apr 2014 17:05:26 CEST (22 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       action
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    percentage:          0%
    capacity:            100%
    icon-name:          'battery-caution-symbolic'

This device should be blacklisted, and its power supply support not exposed.

Comment 1 Josh Boyer 2014-04-23 15:32:54 UTC
What does "...fail after a while" mean?  Does it report valid values after a fresh boot and then they aren't updated after that?

Comment 2 Benjamin Tissoires 2014-04-23 15:47:04 UTC
Created attachment 889001 [details]
0001-HID-input-disable-battery-for-0A5C-4502.patch

Adding a proposed patch to fix the issue: taking the hammer, and disabling the battery property :)

I just scheduled a test build here, any feedback appreciated so I can also send this upstream:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6770010

Comment 3 Bastien Nocera 2014-04-23 22:59:24 UTC
(In reply to Josh Boyer from comment #1)
> What does "...fail after a while" mean?

That it times out. It usually takes longer than those 5 seconds.

>  Does it report valid values after a
> fresh boot and then they aren't updated after that?

Never does, even using the provided keyboard.

Comment 4 Bastien Nocera 2014-04-24 09:07:12 UTC
The power supply class still shows up with the new kernel:
$ ls -l /sys/class/power_supply/
total 0
0 lrwxrwxrwx. 1 root root 0 Apr 24 11:04 hid--battery -> ../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:0A5C:4502.0004/power_supply/hid--battery
$ uname -r
3.14.1-200.bz1090555.fc20.x86_64

Comment 5 Bastien Nocera 2014-04-24 09:09:23 UTC
#define USB_VENDOR_ID_BROADCOM		0x046e

That should probably read 0x0a5c?

Comment 6 Benjamin Tissoires 2014-04-24 15:47:17 UTC
Created attachment 889340 [details]
0001-HID-input-disable-battery-for-0A5C-4502.patch V2

Sorry for the typo in the patch.

New patch and new build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6775015

Comment 7 Bastien Nocera 2014-04-24 19:12:52 UTC
Bizarrely, it's not working and the battery still shows up:

$ uname -r
3.14.1-200.bz1090555.1.fc20.x86_64
$ ls -l /sys/class/power_supply/
total 0
lrwxrwxrwx. 1 root root 0 Apr 24 21:04 hid--battery -> ../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.2/1-1.5.2:1.0/0003:0A5C:4503.0005/power_supply/hid--battery

Comment 8 Justin M. Forbes 2014-05-21 19:41:31 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.14.4-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 9 Bastien Nocera 2014-05-22 09:43:22 UTC
It's obviously not been resolved.

Comment 10 Justin M. Forbes 2014-11-13 16:05:03 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

Comment 11 Justin M. Forbes 2014-12-10 15:03:23 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.