linux-stable.git/drivers, branch v3.7.2

can: Do not call dev_put if restart timer is running upon close

2013-01-11T17:19:05+00:00

commit ab48b03ec9ae1840a1e427e2375bd0d9d554b4ed upstream.

If the restart timer is running due to BUS-OFF and the device is
disconnected an dev_put will decrease the usage counter to -1 thus
blocking the interface removal, resulting in the following dmesg
lines repeating every 10s:
can: notifier: receive list not found for dev can0
can: notifier: receive list not found for dev can0
can: notifier: receive list not found for dev can0
unregister_netdevice: waiting for can0 to become free. Usage count = -1

Signed-off-by: Alexander Stein 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

HID: Add Apple wireless keyboard 2011 ANSI to special driver list

2013-01-11T17:19:05+00:00

commit f9af7b9edccb87d4d80b58687ab63e58f3b64c4c upstream.

Commit 0a97e1e9f9a6 ('HID: apple: Add Apple wireless keyboard 2011 ANSI PID')
did not update the special driver list in hid-core.c, so hid-generic may
still bind to this device.

Reported-by: Ari Pollak 
References: http://bugs.debian.org/694546
Signed-off-by: Ben Hutchings 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

drivers/rtc/rtc-vt8500.c: fix handling of data passed in struct rtc_time

2013-01-11T17:19:05+00:00

commit 2f90b68309683f2c5765a1b04ca23d71e51f1494 upstream.

tm_mon is 0..11, whereas vt8500 expects 1..12 for the month field,
causing invalid date errors for January, and causing the day field to
roll over incorrectly.

The century flag is only handled in vt8500_rtc_read_time, but not set in
vt8500_rtc_set_time.  This patch corrects the behaviour of the century
flag.

Signed-off-by: Edgar Toernig 
Signed-off-by: Tony Prisk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drivers/rtc/rtc-vt8500.c: correct handling of CR_24H bitfield

2013-01-11T17:19:04+00:00

commit 532db570e5181abc8f4f7bfa6c77c69ec2240198 upstream.

Control register bitfield for 12H/24H mode is handled incorrectly.
Setting CR_24H actually enables 12H mode.  This patch renames the define
and changes the initialization code to correctly set 24H mode.

Signed-off-by: Tony Prisk 
Cc: Edgar Toernig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

revert "rtc: recycle id when unloading a rtc driver"

2013-01-11T17:19:04+00:00

commit 5abe257af8b95857b95fa0ba694530b446ae32d8 upstream.

Revert commit 2830a6d20139df2198d63235df7957712adb28e5.

We already perform the ida_simple_remove() in rtc_device_release(),
which is an appropriate place.  Commit 2830a6d20 ("rtc: recycle id when
unloading a rtc driver") caused the kernel to emit

	ida_remove called for id=0 which is not allocated.

warnings when rtc_device_release() tries to release an alread-released
ID.

Let's restore things to their previous state and then work out why
Vincent's kernel wasn't calling rtc_device_release() - presumably a bug
in a specific sub-driver.

Reported-by: Lothar Waßmann 
Acked-by: Alexander Holler 
Cc: Vincent Palatin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Add support for BCM20702A0 [0b05, 17b5]

2013-01-11T17:19:03+00:00

commit 1ee3ff6110c16acfc915a79b1e3feb5013c41e75 upstream.

Vendor-specific ID for BCM20702A0.
Support for bluetooth over Asus Wi-Fi GO!, included with Asus P8Z77-V
Deluxe.

T:  Bus=07 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0b05 ProdID=17b5 Rev=01.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
S:  SerialNumber=94DBC98AC113
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

Signed-off-by: Jeff Cook 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

PCI/PM: Do not suspend port if any subordinate device needs PME polling

2013-01-11T17:19:03+00:00

commit c733b77475707cc3980542c86ee0ad5c841d544c upstream.

Ulrich reported that his USB3 cardreader does not work reliably when
connected to the USB3 port.  It turns out that USB3 controller failed to
awaken when plugging in the USB3 cardreader.  Further experiments found
that the USB3 host controller can only be awakened via polling, not via PME
interrupt.  But if the PCIe port to which the USB3 host controller is
connected is suspended, we cannot poll the controller because its config
space is not accessible when the PCIe port is in a low power state.

To solve the issue, the PCIe port will not be suspended if any subordinate
device needs PME polling.

[bhelgaas: use bool consistently rather than mixing int/bool]
Reference: http://lkml.kernel.org/r/50841CCC.9030809@uli-eckhardt.de
Reported-by: Ulrich Eckhardt 
Tested-by: Sarah Sharp 
Signed-off-by: Huang Ying 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz

2013-01-11T17:19:02+00:00

commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream.

Otherwise it fails like this on cards like the Transcend 16GB SDHC card:

    mmc0: new SDHC card at address b368
    mmcblk0: mmc0:b368 SDC   15.0 GiB
    mmcblk0: error -110 sending status command, retrying
    mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0

Tested on my Lenovo x200 laptop.

[bhelgaas: changelog]
Signed-off-by: Andy Lutomirski 
Signed-off-by: Bjorn Helgaas 
Acked-by: Chris Ball 
CC: Manoj Iyer 
Signed-off-by: Greg Kroah-Hartman

PCI/PM: Keep runtime PM enabled for unbound PCI devices

2013-01-11T17:19:02+00:00

commit 967577b062417b4e4b8e27b711220f4124f5153a upstream.

For unbound PCI devices, what we need is:

 - Always in D0 state, because some devices do not work again after
   being put into D3 by the PCI bus.

 - In SUSPENDED state if allowed, so that the parent devices can still
   be put into low power state.

To satisfy these requirements, the runtime PM for the unbound PCI
devices are disabled and set to SUSPENDED state.  One issue of this
solution is that the PCI devices will be put into SUSPENDED state even
if the SUSPENDED state is forbidden via the sysfs interface
(.../power/control) of the device.  This is not an issue for most
devices, because most PCI devices are not used at all if unbound.
But there are exceptions.  For example, unbound VGA card can be used
for display, but suspending its parents makes it stop working.

To fix the issue, we keep the runtime PM enabled when the PCI devices
are unbound.  But the runtime PM callbacks will do nothing if the PCI
devices are unbound.  This way, we can put the PCI devices into
SUSPENDED state without putting the PCI devices into D3 state.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48201
Signed-off-by: Huang Ying 
Signed-off-by: Bjorn Helgaas 
Acked-by: Alan Stern 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

solos-pci: fix double-free of TX skb in DMA mode

2013-01-11T17:19:02+00:00

commit cae49ede00ec3d0cda290b03fee55b72b49efc11 upstream.

We weren't clearing card->tx_skb[port] when processing the TX done interrupt.
If there wasn't another skb ready to transmit immediately, this led to a
double-free because we'd free it *again* next time we did have a packet to
send.

Signed-off-by: David Woodhouse 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman