[PATCH][FIX 3.15] b43: N-PHY: access B43_MMIO_PSM_PHY_HDR using 16b ops

[Larry Finger]

On 04/05/2014 09:35 AM, Rafał Miłecki wrote:
> 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 <zajec5 at gmail.com>
> ---
> John: I think this patch it worth picking for 3.15 release. This bug
> causes instability and can be triggered depending on the default state
> of B43_NPHY_BANDCTL register.
> It doesn't cause exception immediately, so I spent few hours tracing it.
> ---

I agree that this is a BUG fix that should be in 3.15, *and* in all stable 
versions to which it would apply.

To aid John, I suggest that a better subject would be something like "b43: Fix 
machine check error due to improper access of B43_MMIO_PSM_PHY_HDR". That makes 
it more obvious that a bug is being fixed. In addition, you should add a "Cc: 
Stable <stable at vger.kernel.org> [2.6.35+]".

As I rarely run an 802.11n Broadcom device, it is unlikely that I have 
encountered this problem, but your evidence is convincing. Once the subject and 
Cc are changed, then Acked-by: Larry Finger <Larry.Finger at lwfinger.net>

Larry