Bug 1090555

Summary: Disable HID Battery reporting for Broadcom HID/HCI device
Product: [Fedora] Fedora Reporter: Bastien Nocera <bnocera>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: bnocera, btissoir, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab
Target Milestone: ---Flags: jforbes: needinfo?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-10 15:03:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
0001-HID-input-disable-battery-for-0A5C-4502.patch
none
0001-HID-input-disable-battery-for-0A5C-4502.patch V2 none

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.