kernel/linux.git/drivers, branch v3.0.35

e1000: save skb counts in TX to avoid cache misses

2012-06-17T18:23:12+00:00

commit 31c15a2f24ebdab14333d9bf5df49757842ae2ec upstream. Virtual Machines with emulated e1000 network adapter running on Parallels' server were seeing kernel panics due to the e1000 driver dereferencing an unexpected NULL pointer retrieved from buffer_info->skb. The problem has been addressed for the e1000e driver, but not for the e1000. Since the two drivers share similar code in the affected area, a port of the following e1000e driver commit solves the issue for the e1000 driver: commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180 Author: Tom Herbert Date: Wed May 5 14:02:27 2010 +0000 e1000e: save skb counts in TX to avoid cache misses In e1000_tx_map, precompute number of segements and bytecounts which are derived from fields in skb; these are stored in buffer_info. When cleaning tx in e1000_clean_tx_irq use the values in the associated buffer_info for statistics counting, this eliminates cache misses on skb fields. Signed-off-by: Dean Nelson Acked-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Roman Kagan

iwlwifi: don't mess up the SCD when removing a key

2012-06-17T18:23:12+00:00

commit d6ee27eb13beab94056e0de52d81220058ca2297 upstream. When we remove a key, we put a key index which was supposed to tell the fw that we are actually removing the key. But instead the fw took that index as a valid index and messed up the SRAM of the device. This memory corruption on the device mangled the data of the SCD. The impact on the user is that SCD queue 2 got stuck after having removed keys. The message is the log that was printed is: Queue 2 stuck for 10000ms This doesn't seem to fix the higher queues that get stuck from time to time. Reviewed-by: Meenakshi Venkataraman Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

acpi_video: fix leaking PCI references

2012-06-17T18:23:11+00:00

commit cfb46f433a4da97c31780e08a259fac2cb6bd61f upstream. Signed-off-by: Alan Cox Acked-by: Matthew Garrett Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

hwmon: (fam15h_power) Increase output resolution

2012-06-17T18:23:11+00:00

commit 941a956b0e387b21f385f486c34ef67576775cfc upstream. On high CPU load the accumulating values in the running_avg_cap register are very low (below 10), so averaging them too early leads to unnecessary poor output resolution. Since we pretend to output micro-Watt we better keep all the bits we have as long as possible. Signed-off-by: Andre Przywara Signed-off-by: Andreas Herrmann Acked-by: Guenter Roeck Signed-off-by: Jean Delvare Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman

can: c_can: fix race condition in c_can_open()

2012-06-17T18:23:11+00:00

commit f461f27a4436dbe691908fe08b867ef888848cc3 upstream. Fix the issue of C_CAN interrupts getting disabled forever when canconfig utility is used multiple times. According to NAPI usage we disable all the hardware interrupts in ISR and re-enable them in poll(). Current implementation calls napi_enable() after hardware interrupts are enabled. If we get any interrupts between these two steps then we do not process those interrupts because napi is not enabled. Mostly these interrupts come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable() happens before HW interrupts enabled then c_can_poll() function will be called eventual re-enabling. This patch moves the napi_enable() call before interrupts enabled. Signed-off-by: AnilKumar Ch Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: c_can: fix an interrupt thrash issue with c_can driver

2012-06-17T18:23:11+00:00

commit 148c87c89e1a8863d3d965179f3ab1a06490569e upstream. This patch fixes an interrupt thrash issue with c_can driver. In c_can_isr() function interrupts are disabled and enabled only in c_can_poll() function. c_can_isr() & c_can_poll() both read the irqstatus flag. However, irqstatus is always read as 0 in c_can_poll() because all C_CAN interrupts are disabled in c_can_isr(). This causes all interrupts to be re-enabled in c_can_poll() which in turn causes another interrupt since the event is not really handled. This keeps happening causing a flood of interrupts. To fix this, read the irqstatus register in isr and use the same cached value in the poll function. Signed-off-by: AnilKumar Ch Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: c_can: fix "BUG! echo_skb is occupied!" during transmit

2012-06-17T18:23:11+00:00

commit 617caccebe451716df21c069b079d5936ed7b0f3 upstream. This patch fixes an issue with transmit routine, which causes "can_put_echo_skb: BUG! echo_skb is occupied!" message when using "cansequence -p" on D_CAN controller. In c_can driver, while transmitting packets tx_echo flag holds the no of can frames put for transmission into the hardware. As the comment above c_can_do_tx() indicates, if we find any packet which is not transmitted then we should stop looking for more. In the current implementation this is not taken care of causing the said message. Also, fix the condition used to find if the packet is transmitted or not. Current code skips the first tx message object and ends up checking one extra invalid object. While at it, fix the comment on top of c_can_do_tx() to use the terminology "packet" instead of "package" since it is more standard. Signed-off-by: AnilKumar Ch Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

net: sierra_net: device IDs for Aircard 320U++

2012-06-17T18:23:11+00:00

commit dd03cff23d694cfb0fdae80cb618e7ced05ea696 upstream. Adding device IDs for Aircard 320U and two other devices found in the out-of-tree version of this driver. Cc: linux@sierrawireless.com Cc: Autif Khan Cc: Tom Cassidy Signed-off-by: Bjørn Mork Acked-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

char/agp: add another Ironlake host bridge

2012-06-17T18:23:10+00:00

commit 67384fe3fd450536342330f684ea1f7dcaef8130 upstream. This seems to come on Gigabyte H55M-S2V and was discovered through the https://bugs.freedesktop.org/show_bug.cgi?id=50381 debugging. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50381 Signed-off-by: Eugeni Dodonov Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

wl1251: fix oops on early interrupt

2012-06-09T15:33:05+00:00

commit f380f2c4a12e913356bd49f8790ec1063c4fe9f8 upstream. This driver disables interrupt just after requesting it and enables it later, after interface is up. However currently there is a time window between request_irq() and disable_irq() where if interrupt arrives, the driver oopses because it's not yet ready to process it. This can be reproduced by inserting the module, associating and removing the module multiple times. Eliminate this race by setting IRQF_NOAUTOEN flag before request_irq(). Signed-off-by: Grazvydas Ignotas Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman