linux/drivers, branch v3.2.58

Revert "isci: fix reset timeout handling"

2014-04-30T15:23:27Z

This reverts commit 584ec12265192bf49dfa270d517380f6723a6956, which was commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream. It causes boot failure on 3.2 although no such problem occurs upstream. Reported-by: Ondrej Zary Signed-off-by: Ben Hutchings Acked-by: Dan Williams

powernow-k6: reorder frequencies

2014-04-30T15:23:27Z

commit 22c73795b101597051924556dce019385a1e2fa0 upstream. This patch reorders reported frequencies from the highest to the lowest, just like in other frequency drivers. Signed-off-by: Mikulas Patocka Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: cpu_frequency_table::driver_data is called index] Signed-off-by: Ben Hutchings

powernow-k6: correctly initialize default parameters

2014-04-30T15:23:27Z

commit d82b922a4acc1781d368aceac2f9da43b038cab2 upstream. The powernow-k6 driver used to read the initial multiplier from the powernow register. However, there is a problem with this: * If there was a frequency transition before, the multiplier read from the register corresponds to the current multiplier. * If there was no frequency transition since reset, the field in the register always reads as zero, regardless of the current multiplier that is set using switches on the mainboard and that the CPU is running at. The zero value corresponds to multiplier 4.5, so as a consequence, the powernow-k6 driver always assumes multiplier 4.5. For example, if we have 550MHz CPU with bus frequency 100MHz and multiplier 5.5, the powernow-k6 driver thinks that the multiplier is 4.5 and bus frequency is 122MHz. The powernow-k6 driver then sets the multiplier to 4.5, underclocking the CPU to 450MHz, but reports the current frequency as 550MHz. There is no reliable way how to read the initial multiplier. I modified the driver so that it contains a table of known frequencies (based on parameters of existing CPUs and some common overclocking schemes) and sets the multiplier according to the frequency. If the frequency is unknown (because of unusual overclocking or underclocking), the user must supply the bus speed and maximum multiplier as module parameters. This patch should be backported to all stable kernels. If it doesn't apply cleanly, change it, or ask me to change it. Signed-off-by: Mikulas Patocka Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: - Adjust context - s/driver_data/index/] Signed-off-by: Ben Hutchings

powernow-k6: disable cache when changing frequency

2014-04-30T15:23:27Z

commit e20e1d0ac02308e2211306fc67abcd0b2668fb8b upstream. I found out that a system with k6-3+ processor is unstable during network server load. The system locks up or the network card stops receiving. The reason for the instability is the CPU frequency scaling. During frequency transition the processor is in "EPM Stop Grant" state. The documentation says that the processor doesn't respond to inquiry requests in this state. Consequently, coherency of processor caches and bus master devices is not maintained, causing the system instability. This patch flushes the cache during frequency transition. It fixes the instability. Other minor changes: * u64 invalue changed to unsigned long because the variable is 32-bit * move the logic to set the multiplier to a separate function powernow_k6_set_cpu_multiplier * preserve lower 5 bits of the powernow port instead of 4 (the voltage field has 5 bits) * mask interrupts when reading the multiplier, so that the port is not open during other activity (running other kernel code with the port open shouldn't cause any misbehavior, but we should better be safe and keep the port closed) This patch should be backported to all stable kernels. If it doesn't apply cleanly, change it, or ask me to change it. Signed-off-by: Mikulas Patocka Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

Char: ipmi_bt_sm, fix infinite loop

2014-04-30T15:23:27Z

commit a94cdd1f4d30f12904ab528152731fb13a812a16 upstream. In read_all_bytes, we do unsigned char i; ... bt->read_data[0] = BMC2HOST; bt->read_count = bt->read_data[0]; ... for (i = 1; i <= bt->read_count; i++) bt->read_data[i] = BMC2HOST; If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the 'for' loop. Make 'i' an 'int' instead of 'char' to get rid of the overflow and finish the loop after 255 iterations every time. Signed-off-by: Jiri Slaby Reported-and-debugged-by: Rui Hui Dian Cc: Tomas Cech Cc: Corey Minyard Cc: Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings

drivers: hv: additional switch to use mb() instead of smp_mb()

2014-04-30T15:23:27Z

commit e4af376d04b0(drivers: hv: switch to use mb() instead of smp_mb()), the adjustment mistakenly dropped the change in hv_ringbuffer_read, so add it. Signed-off-by: Qiang Huang Signed-off-by: Ben Hutchings

target/tcm_fc: Fix use-after-free of ft_tpg

2014-04-30T15:23:26Z

commit 2c42be2dd4f6586728dba5c4e197afd5cfaded78 upstream. ft_del_tpg checks tpg->tport is set before unlinking the tpg from the tport when the tpg is being removed. Set this pointer in ft_tport_create, or the unlinking won't happen in ft_del_tpg and tport->tpg will reference a deleted object. This patch sets tpg->tport in ft_tport_create, because that's what ft_del_tpg checks, and is the only way to get back to the tport to clear tport->tpg. The bug was occuring when: - lport created, tport (our per-lport, per-provider context) is allocated. tport->tpg = NULL - tpg created - a PRLI is received. ft_tport_create is called, tpg is found and tport->tpg is set - tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not set, tport->tpg is not cleared and points at freed memory - Future calls to ft_tport_create return tport via first conditional, instead of searching for new tpg by calling ft_lport_find_tpg. tport->tpg is still invalid, and will access freed memory. see https://bugzilla.redhat.com/show_bug.cgi?id=1071340 Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings

b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR

2014-04-30T15:23:26Z

commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream. Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b functions isn't safe. On my machine it causes delayed (!) CPU exception: Disabling lock debugging due to kernel taint mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f mce: [Hardware Error]: TSC 164083803dc mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Processor context corrupt Kernel panic - not syncing: Fatal machine check on current CPU Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) Signed-off-by: Rafał Miłecki Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

iscsi-target: Fix ERL=2 ASYNC_EVENT connection pointer bug

2014-04-30T15:23:25Z

commit d444edc679e7713412f243b792b1f964e5cff1e1 upstream. This patch fixes a long-standing bug in iscsit_build_conn_drop_async_message() where during ERL=2 connection recovery, a bogus conn_p pointer could end up being used to send the ISCSI_OP_ASYNC_EVENT + DROPPING_CONNECTION notifying the initiator that cmd->logout_cid has failed. The bug was manifesting itself as an OOPs in iscsit_allocate_cmd() with a bogus conn_p pointer in iscsit_build_conn_drop_async_message(). Reported-by: Arshad Hussain Reported-by: santosh kulkarni Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings

drm/radeon: call drm_edid_to_eld when we update the edid

2014-04-30T15:23:25Z

commit 16086279353cbfecbb3ead474072dced17b97ddc upstream. This needs to be done to update some of the fields in the connector structure used by the audio code. Noticed by several users on irc. Signed-off-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Ben Hutchings