summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2011-10-28oprofile, x86: Fix nmi-unsafe callgraph supportRobert Richter
commit a0e3e70243f5b270bc3eca718f0a9fa5e6b8262e upstream. Current oprofile's x86 callgraph support may trigger page faults throwing the BUG_ON(in_nmi()) message below. This patch fixes this by using the same nmi-safe copy-from-user code as in perf. ------------[ cut here ]------------ kernel BUG at .../arch/x86/kernel/traps.c:436! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:0a.0/0000:07:00.0/0000:08:04.0/net/eth0/broadcast CPU 5 Modules linked in: Pid: 8611, comm: opcontrol Not tainted 2.6.39-00007-gfe47ae7 #1 Advanced Micro Device Anaheim/Anaheim RIP: 0010:[<ffffffff813e8e35>] [<ffffffff813e8e35>] do_nmi+0x22/0x1ee RSP: 0000:ffff88042fd47f28 EFLAGS: 00010002 RAX: ffff88042c0a7fd8 RBX: 0000000000000001 RCX: 00000000c0000101 RDX: 00000000ffff8804 RSI: ffffffffffffffff RDI: ffff88042fd47f58 RBP: ffff88042fd47f48 R08: 0000000000000004 R09: 0000000000001484 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88042fd47f58 R13: 0000000000000000 R14: ffff88042fd47d98 R15: 0000000000000020 FS: 00007fca25e56700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000074 CR3: 000000042d28b000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process opcontrol (pid: 8611, threadinfo ffff88042c0a6000, task ffff88042c532310) Stack: 0000000000000000 0000000000000001 ffff88042c0a7fd8 0000000000000000 ffff88042fd47de8 ffffffff813e897a 0000000000000020 ffff88042fd47d98 0000000000000000 ffff88042c0a7fd8 ffff88042fd47de8 0000000000000074 Call Trace: <NMI> [<ffffffff813e897a>] nmi+0x1a/0x20 [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771 <<EOE>> Code: ff 59 5b 41 5c 41 5d c9 c3 55 65 48 8b 04 25 88 b5 00 00 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 f6 80 47 e0 ff ff 04 74 04 <0f> 0b eb fe 81 80 44 e0 ff ff 00 00 01 04 65 ff 04 25 c4 0f 01 RIP [<ffffffff813e8e35>] do_nmi+0x22/0x1ee RSP <ffff88042fd47f28> ---[ end trace ed6752185092104b ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 8611, comm: opcontrol Tainted: G D 2.6.39-00007-gfe47ae7 #1 Call Trace: <NMI> [<ffffffff813e5e0a>] panic+0x8c/0x188 [<ffffffff813e915c>] oops_end+0x81/0x8e [<ffffffff8100403d>] die+0x55/0x5e [<ffffffff813e8c45>] do_trap+0x11c/0x12b [<ffffffff810023c8>] do_invalid_op+0x91/0x9a [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee [<ffffffff8131e6fa>] ? oprofile_add_sample+0x83/0x95 [<ffffffff81321670>] ? op_amd_check_ctrs+0x4f/0x2cf [<ffffffff813ee4d5>] invalid_op+0x15/0x20 [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee [<ffffffff813e8e7a>] ? do_nmi+0x67/0x1ee [<ffffffff813e897a>] nmi+0x1a/0x20 [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771 <<EOE>> Cc: John Lumby <johnlumby@hotmail.com> Cc: Maynard Johnson <maynardj@us.ibm.com> Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I40fd03cc12738d031e2d276644b1b56301f4be9f Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35635 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28kexec, x86: Fix incorrect jump back address if not preserving contextHuang Ying
commit 050438ed5a05b25cdf287f5691e56a58c2606997 upstream. In kexec jump support, jump back address passed to the kexeced kernel via function calling ABI, that is, the function call return address is the jump back entry. Furthermore, jump back entry == 0 should be used to signal that the jump back or preserve context is not enabled in the original kernel. But in the current implementation the stack position used for function call return address is not cleared context preservation is disabled. The patch fixes this bug. Reported-and-tested-by: Yin Kangkai <kangkai.yin@intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@redhat.com> Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.com Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I75dc3aab96524ef899a3c40a3e759833d045987e Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35634 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28pnfs: use lwb as layoutcommit lengthPeng Tao
commit 3557c6c3be5b2ca0b11365db7f8a813253eb520b upstream. Using NFS4_MAX_UINT64 will break current protocol. [Needed in v3.0] Signed-off-by: Peng Tao <peng_tao@emc.com> Signed-off-by: Jim Rees <rees@umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ia331da3c27df7f5ba14e316f3dfd1717d67d1947 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35633 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28pnfs: let layoutcommit handle a list of lsegPeng Tao
commit a9bae5666d0510ad69bdb437371c9a3e6b770705 upstream. There can be multiple lseg per file, so layoutcommit should be able to handle it. [Needed in v3.0] Signed-off-by: Peng Tao <peng_tao@emc.com> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: Jim Rees <rees@umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I713a4a2a5eede21594125db9682a025a82142559 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35632 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28pnfs: save layoutcommit cred at layout header initPeng Tao
commit 9fa4075878a5faac872a63f4a97ce79c776264e9 upstream. No need to save it for every lseg. No need to save it at every pnfs_set_layoutcommit. [Needed in v3.0] Signed-off-by: Peng Tao <peng_tao@emc.com> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: Jim Rees <rees@umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I94971f2dea31dacfb681a13e5768714976add0e8 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35631 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28pnfs: save layoutcommit lwb at layout headerPeng Tao
commit acff5880539fe33897d016c0f3dcf062e67c61b6 upstream. No need to save it for every lseg. [Needed in v3.0] Signed-off-by: Peng Tao <peng_tao@emc.com> Signed-off-by: Jim Rees <rees@umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ibf606385c67299aab90342fb7cc32bfaf44c1b64 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35630 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ALSA: hda - Fix duplicated DAC assignments for RealtekTakashi Iwai
commit c48a8fb0d31d6147d8d76b8e2ad7f51a2fbb5c4d upstream. Copying hp_pins and speaker_pins from line_out_pins may confuse the parser, and it can lead to duplicated initializations for the same pin with a wrong DAC assignment. The problem appears in 3.0 kernel code. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I7e8e35f771d9e34c095927752b4ddc9bfd16d5c2 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35629 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ALSA: virtuoso: fix silent analog output on Xonar Essence ST DeluxeClemens Ladisch
commit c81c6b356b52d3fcb4d531d149573fc100aad643 upstream. Commit dd203fa97bd5 (ALSA: virtuoso: remove non-working controls on Essence ST Deluxe) made it impossible to adjust the volume after the driver initialized it to muted. Ensure that those DACs that can be accessed with I2C are initialized to the same volume that is the reset default of the DAC without I2C. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Id6e134a09984ae42267008363f5d9cdf34bbfa00 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35628 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28drm/radeon/kms: add missing vddci setting on NI+Alex Deucher
commit 4639dd21e759e32125adc7171abf6cb8140d54cf upstream. Need to add vddci setting to pm init as well as resume. Fixes hangs on load on some boards. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38754 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I7087d0a0ab2e95b13458d6705f9fc64e51031af2 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35627 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28drm/radeon/kms: fix DP training for DPEncoderService revision bigger than 1.1Jerome Glisse
commit 5a96a899bbdee86024ab9ea6d02b9e242faacbed upstream. DPEncoderService newer than 1.1 can't properly program the DP (display port) link training. When facing such version use the DIGxEncoderControl method instead. Fix DP link training on some R7XX. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I6f1ff7594795c32d7eccc6c892c54bb40b1073a7 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35626 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28drm/radeon/kms: fix i2c map for rv250/280Alex Deucher
commit 6dd666333ddee39903d86f870d5c40d9f100e0cc upstream. Those chips have crt2_ddc bus. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=39672 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I073e1575884accc31406cec1bb466f25d1c1c885 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35625 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28hpsa: do not attempt to read from a write-only registerStephen M. Cameron
commit fec62c368b9c8b05d5124ca6c3b8336b537f26f3 upstream. Most smartarrays tolerate it, but a few new ones don't. Without this change some newer Smart Arrays will lock up and i/o will grind to a halt. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ief78ccf0d95588a52e13839c9d02d4c56f18bc2a Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35624 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28pmcraid: reject negative request sizeDan Rosenberg
commit b5b515445f4f5a905c5dd27e6e682868ccd6c09d upstream. There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. First, the user can call pmcraid_chr_ioctl(), with a type PMCRAID_PASSTHROUGH_IOCTL. This calls through to pmcraid_ioctl_passthrough(). Next, a pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user. If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked. It looks like preventing this value from being negative in pmcraid_ioctl_passthrough() would be sufficient. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ie8eff0b5acf02c6437b104a8b556e832745a9be9 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35623 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28fix crash in scsi_dispatch_cmd()James Bottomley
commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 upstream. USB surprise removal of sr is triggering an oops in scsi_dispatch_command(). What seems to be happening is that USB is hanging on to a queue reference until the last close of the upper device, so the crash is caused by surprise remove of a mounted CD followed by attempted unmount. The problem is that USB doesn't issue its final commands as part of the SCSI teardown path, but on last close when the block queue is long gone. The long term fix is probably to make sr do the teardown in the same way as sd (so remove all the lower bits on ejection, but keep the upper disk alive until last close of user space). However, the current oops can be simply fixed by not allowing any commands to be sent to a dead queue. Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I5106bb4ec29746f65016511878286b5dc2c61324 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35622 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ses: requesting a fault indicationDouglas Gilbert
commit 2a350cab9daf9a46322d83b091bb05cf54ccf6ab upstream. Noticed that when the sysfs interface of the SCSI SES driver was used to request a fault indication the LED flashed but the buzzer didn't sound. So it was doing what REQUEST IDENT (locate) should do. Changelog: - fix the setting of REQUEST FAULT for the device slot and array device slot elements in the enclosure control diagnostic page - note the potentially defective code that reads the FAULT SENSED and FAULT REQUESTED bits from the enclosure status diagnostic page The attached patch is against git/scsi-misc-2.6 Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I10846eccc26fd3f0ea6ea7da957289b16ec15d49 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35621 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28sr: check_events() ignore GET_EVENT when TUR says otherwiseKay Sievers
commit 79b9677d885d1a792bc103f2febb06f91f92de43 upstream. Some broken devices indicates that media has changed on every GET_EVENT_STATUS_NOTIFICATION. This translates into MEDIA_CHANGE uevent on every open() which lets udev run into a loop. Verify GET_EVENT result against TUR and if it generates spurious events for several times in a row, ignore the GET_EVENT events, and trust only the TUR status. This is the log of a USB stick with a (broken) fake CDROM drive: scsi 5:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0 CCS sd 5:0:0:0: Attached scsi generic sg3 type 0 scsi 5:0:0:1: CD-ROM SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0 sd 5:0:0:0: [sdb] Attached SCSI removable disk sr2: scsi3-mmc drive: 48x/48x tray sr 5:0:0:1: Attached scsi CD-ROM sr2 sr 5:0:0:1: Attached scsi generic sg4 type 5 sr2: GET_EVENT and TUR disagree continuously, suppress GET_EVENT events sd 5:0:0:0: [sdb] 31777279 512-byte logical blocks: (16.2 GB/15.1 GiB) sd 5:0:0:0: [sdb] No Caching mode page present sd 5:0:0:0: [sdb] Assuming drive cache: write through sd 5:0:0:0: [sdb] No Caching mode page present sd 5:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 -tj: Updated to consider only spurious GET_EVENT events among different types of disagreement and allow using TUR for kernel event polling after GET_EVENT is ignored. Reported-By: Markus Rathgeb maggu2810@googlemail.com Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ie0b76b2c07b0b2c98231f2ce0e68fdf11ed15d0f Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35620 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28Blacklist Traxdata CDR4120 and IOMEGA Zip drive to avoid lock ups.Werner Fink
commit 82103978189e9731658cd32da5eb85ab7b8542b8 upstream. This patch resulted from the discussion at https://bugzilla.novell.com/show_bug.cgi?id=679277, https://bugzilla.novell.com/show_bug.cgi?id=681840 . Signed-off-by: Werner Fink <werner@novell.com> Signed-off-by: Ankit Jain <jankit@suse.de> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I22e2c18079c0798404ae7113c2ca6a84496514b2 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35619 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28perf: Fix software event overflowPeter Zijlstra
The below patch is for -stable only, upstream has a much larger patch that contains the below hunk in commit a8b0ca17b80e92faab46ee7179ba9e99ccb61233 Vince found that under certain circumstances software event overflows go wrong and deadlock. Avoid trying to delete a timer from the timer callback. Reported-by: Vince Weaver <vweaver1@eecs.utk.edu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ieaf67882ae859ae744fa53da83f29e7ce38f96f9 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35618 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIASLen Brown
commit abe48b108247e9b90b4c6739662a2e5c765ed114 upstream. Since 2.6.36 (23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo, Since 2.6.38 (d5532ee7b40), the x86_energy_perf_policy(8) utility has been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS. However, the typical BIOS fails to initialize the MSR, presumably because this is handled by high-volume shrink-wrap operating systems... Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8). As a result, WSM-EP, SNB, and later hardware from Intel will run in its default hardware power-on state (performance), which assumes that users care for performance at all costs and not for energy efficiency. While that is fine for performance benchmarks, the hardware's intended default operating point is "normal" mode... Initialize the MSR to the "normal" by default during kernel boot. x86_energy_perf_policy(8) is available to change the default after boot, should the user have a different preference. Signed-off-by: Len Brown <len.brown@intel.com> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980 Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I2f36d461fd32b4a48476ef35c07a30d7618242f6 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35617 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28perf tools: Fix endian conversion reading event attr from file headerDavid Ahern
commit eda3913bb70ecebac13adccffe1e7f96e93cee02 upstream. The perf_event_attr struct has two __u32's at the top and they need to be swapped individually. With this change I was able to analyze a perf.data collected in a 32-bit PPC VM on an x86 system. I tested both 32-bit and 64-bit binaries for the Intel analysis side; both read the PPC perf.data file correctly. -v2: - changed the existing perf_event__attr_swap() to swap only elements of perf_event_attr and exported it for use in swapping the attributes in the file header - updated swap_ops used for processing events Signed-off-by: David Ahern <dsahern@gmail.com> Acked-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: acme@ghostprotocols.net Cc: peterz@infradead.org Cc: paulus@samba.org Link: http://lkml.kernel.org/r/1310754849-12474-1-git-send-email-dsahern@gmail.com Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I1ea43d0c121009e8b44e9b68cc9aa7664f779db0 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35616 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28perf tools, x86: Fix 32-bit compile on 64-bit systemDavid Ahern
commit 08a4a43fc407d780bdde36d98f89c0dbb2a6be6b upstream. Builds for 32-bit perf binaries on a 64-bit host currently fail with this error: [...] bench/../../../arch/x86/lib/memcpy_64.S: Assembler messages: bench/../../../arch/x86/lib/memcpy_64.S:29: Error: bad register name `%rdi' bench/../../../arch/x86/lib/memcpy_64.S:34: Error: invalid instruction suffix for `movs' bench/../../../arch/x86/lib/memcpy_64.S:50: Error: bad register name `%rdi' bench/../../../arch/x86/lib/memcpy_64.S:61: Error: bad register name `%rdi' ... The problem is the detection of the host arch without considering passed in flags. This change fixes 32-bit builds via: make EXTRA_CFLAGS=-m32 and 64-bit builds still reference the memcpy_64.S. Signed-off-by: David Ahern <dsahern@gmail.com> Acked-by: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1310420304-21452-1-git-send-email-dsahern@gmail.com Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I24b196ff2710ca69c852d7b43f88c7eace1fefc4 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35615 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28irq_work, ppc: Fix up arch hooksPeter Zijlstra
commit 4f8b50bbbe63ae4ec6bea28a90a9a603c745ea71 upstream. Commit e360adbe29 ("irq_work: Add generic hardirq context callbacks") fouled up the ppc bit, not properly naming the arch specific function that raises the 'self-IPI'. Cc: Huang Ying <ying.huang@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Anton Blanchard <anton@samba.org> Cc: Eric B Munson <emunson@mgebm.net> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-eg0aqien8p1aqvzu9dft6dtv@git.kernel.org Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I074ec46e0af79391bdd04ee9df03aedf3a532b55 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35614 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28mac80211: Restart STA timers only on associated stateRajkumar Manoharan
commit 676b58c27475a9defccc025fea1cbd2b141ee539 upstream. A panic was observed when the device is failed to resume properly, and there are no running interfaces. ieee80211_reconfig tries to restart STA timers on unassociated state. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ieab38e91ba93b6829bc0d1537e4121f953c646b2 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35613 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28rtlwifi: rtl8192cu: Fix duplicate if testLarry Finger
commit 1288aa4e80145d9f4196df32f717b4c1cf6aab61 upstream. A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the same condition twice. The problem was found using cppcheck-1.49, and the proper fix was verified against the pre-mac80211 version of the code. Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ifd3c92620dd4fe558f89a7ea63ed8dc6d556fa06 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35612 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28libsas: remove expander from dev list on errorLuben Tuikov
commit 5911e963d3718e306bcac387b83e259aa4228896 upstream. If expander discovery fails (sas_discover_expander()), remove the expander from the port device list (sas_ex_discover_expander()), before freeing it. Else the list is corrupted and, e.g., when we attempt to send SMP commands to other devices, the kernel oopses. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Jack Wang <jack_wang@usish.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I78c093bbdd8786a6bd711224b7e2007b6f99bcf4 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35611 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28IB/srp: Avoid duplicate devices from LUN scanBart Van Assche
commit fd1b6c4a693c9cac59375ffb36ffe5d7c079037c upstream. SCSI scanning of a channel:id:lun triplet in Linux works as follows (function scsi_scan_target() in drivers/scsi/scsi_scan.c): - If lun == SCAN_WILD_CARD, send a REPORT LUNS command to the target and process the result. - If lun != SCAN_WILD_CARD, send an INQUIRY command to the LUN corresponding to the specified channel:id:lun triplet to verify whether the LUN exists. So a SCSI driver must either take the channel and target id values in account in its quecommand() function or it should declare that it only supports one channel and one target id. Currently the ib_srp driver does neither. As a result scanning the SCSI bus via e.g. rescan-scsi-bus.sh causes many duplicate SCSI devices to be created. For each 0:0:L device, several duplicates are created with the same LUN number and with (C:I) != (0:0). Fix this by declaring that the ib_srp driver only supports one channel and one target id. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Acked-by: David Dillow <dillowda@ornl.gov> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ic3a3d7ca60895d7890ed1f275db2f2fc49f75aac Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35610 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28firewire: cdev: prevent race between first get_info ioctl and bus reset ↵Stefan Richter
event queuing commit 93b37905f70083d6143f5f4dba0a45cc64379a62 upstream. Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events to be read(2) by the client. The get_info ioctl is practically always issued right away after open, hence this condition only occurs if the client opens during a bus reset, especially during a rapid series of bus resets. The problem with this condition is twofold: - These bus reset events carry the (as yet undocumented) @closure value of 0. But it is not the kernel's place to choose closures; they are privat to the client. E.g., this 0 value forced from the kernel makes it unsafe for clients to dereference it as a pointer to a closure object without NULL pointer check. - It is impossible for clients to determine the relative order of bus reset events from get_info ioctl(2) versus those from read(2), except in one way: By comparison of closure values. Again, such a procedure imposes complexity on clients and reduces freedom in use of the bus reset closure. So, change the ABI to suppress queuing of bus reset events before the first FW_CDEV_IOC_GET_INFO ioctl was issued by the client. Note, this ABI change cannot be version-controlled. The kernel cannot distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO ioctl. We will try to back-merge this change into currently maintained stable/ longterm series, and we only document the new behaviour. The old behavior is now considered a kernel bug, which it basically is. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: <stable@kernel.org> Change-Id: I790e269d95885c36b492d735bf457d4c2b103387 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35609 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28firewire: cdev: return -ENOTTY for unimplemented ioctls, not -EINVALStefan Richter
commit d873d794235efa590ab3c94d5ee22bb1fab19ac4 upstream. On Jun 27 Linus Torvalds wrote: > The correct error code for "I don't understand this ioctl" is ENOTTY. > The naming may be odd, but you should think of that error value as a > "unrecognized ioctl number, you're feeding me random numbers that I > don't understand and I assume for historical reasons that you tried to > do some tty operation on me". [...] > The EINVAL thing goes way back, and is a disaster. It predates Linux > itself, as far as I can tell. You'll find lots of man-pages that have > this line in it: > > EINVAL Request or argp is not valid. > > and it shows up in POSIX etc. And sadly, it generally shows up > _before_ the line that says > > ENOTTY The specified request does not apply to the kind of object > that the descriptor d references. > > so a lot of people get to the EINVAL, and never even notice the ENOTTY. [...] > At least glibc (and hopefully other C libraries) use a _string_ that > makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for > device" So let's correct this in the <linux/firewire-cdev.h> ABI while it is still young, relative to distributor adoption. Side note: We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch, but also on _IOC_SIZE mismatch. An ioctl with an unsupported size of argument structure can be seen as an unsupported version of that ioctl. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I9f0f4399a939bae2d5127ad5f76461660b711619 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35608 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ethtool: Allow zero-length register dumps againBen Hutchings
commit 67ae7cf1eeda777f79259c4c6cb17a0bd28dee71 upstream. Some drivers (ab)use the ethtool_ops::get_regs operation to expose only a hardware revision ID. Commit a77f5db361ed9953b5b749353ea2c7fed2bf8d93 ('ethtool: Allocate register dump buffer with vmalloc()') had the side-effect of breaking these, as vmalloc() returns a null pointer for size=0 whereas kmalloc() did not. For backward-compatibility, allow zero-length dumps again. Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Iac59f6b9d382c1b185492bf92d90eccc9bd16826 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35607 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: QABUILD Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28jme: Fix unmap error (Causing system freeze)Guo-Fu Tseng
commit 94c5b41b327e08de0ddf563237855f55080652a1 upstream. This patch add the missing dma_unmap(). Which solved the critical issue of system freeze on heavy load. Michal Miroslaw's rejected patch: [PATCH v2 10/46] net: jme: convert to generic DMA API Pointed out the issue also, thank you Michal. But the fix was incorrect. It would unmap needed address when low memory. Got lots of feedback from End user and Gentoo Bugzilla. https://bugs.gentoo.org/show_bug.cgi?id=373109 Thank you all. :) Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org> Acked-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ia65baf3b19f0ede8b9b328a2d0e274a9d80f6f22 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35606 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28staging: brcm80211: fix for reported log spam problemRoland Vossen
commit 37c962d195005d009e130e65a9e55960996c3cab upstream. Every few minutes, this message would appear in syslog: ieee80211 ph0: wl_ops_bss_info_changed: BSS idle: true (implement) The message has been deleted, the driver requires no special action on this particular event (). See: https://bugzilla.kernel.org/show_bug.cgi?id=38162 Reported-by: David Hill <hilld@binarystorm.net> Signed-off-by: Roland Vossen <rvossen@broadcom.com> Reviewed-by: Arend van Spriel <arend@broadcom.com> Reviewed-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Change-Id: Ic81a0d84f2a0f767b1fe881f19e3b59caedccf6f Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35605 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28CIFS: Fix oops while mounting with prefixpathPavel Shilovsky
commit f5bc1e755d23d022bf948904386337fc3e5e29a8 upstream. commit fec11dd9a0109fe52fd631e5c510778d6cbff6cc caused a regression when we have already mounted //server/share/a and want to mount //server/share/a/b. The problem is that lookup_one_len calls __lookup_hash with nd pointer as NULL. Then __lookup_hash calls do_revalidate in the case when dentry exists and we end up with NULL pointer deference in cifs_d_revalidate: if (nd->flags & LOOKUP_RCU) return -ECHILD; Fix this by checking nd for NULL. Signed-off-by: Pavel Shilovsky <piastryyy@gmail.com> Reviewed-by: Shirish Pargaonkar <shirishp@us.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Id7970ed5e567fd21e42ec661c2ab0f366f12779f Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35604 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ath9k_hw: Fix incorrect key_miss handlingSenthil Balasubramanian
commit 0472ade031b5c0c69c21cf96acf64c50eb9ba3c2 upstream. Decryping frames on key_miss handling shouldn't be done for Michael MIC failed frames as h/w would have already decrypted such frames successfully anyway. Also leaving CRC and PHY error(where the frame is going to be dropped anyway), we are left to prcoess Decrypt error for which s/w decrypt is selected anway and so having key_miss as a separate check doesn't serve anything. So making key_miss handling mutually exlusive with other RX status handling makes much more sense. This patch addresses an issue with STA not reporting MIC failure events resulting in STA being disconnected immediately. Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: If170874527c63528f357b451f8085cf0d813eb56 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35603 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ath6kl: fix crash when interface is closed but scan is ongoingKalle Valo
commit 98ab5c7755b5cc9e1a8f2a57ccb22eac5e13ec50 upstream. When ath6kl module was resumed while a scan was ongoing, for example during suspend, the driver would crash in ar6k_cfg80211_scanComplete_event(): [26581.586440] Call Trace: [26581.586440] [<f99ffeda>] ? ar6k_cfg80211_scanComplete_event+0xaa/0xaa [ath6kl] [26581.586440] [<f9a0a020>] wmi_iterate_nodes+0xb/0xd [ath6kl] [26581.586440] [<f99ffe78>] ar6k_cfg80211_scanComplete_event+0x48/0xaa [ath6kl] [26581.586440] [<f9a038ae>] ar6000_close+0x77/0x7e [ath6kl] [26581.586440] [<c139c25d>] __dev_close_many+0x87/0xab [26581.586440] [<c139c30a>] dev_close_many+0x54/0xab [26581.586440] [<c139c437>] rollback_registered_many+0xa5/0x19e [26581.586440] [<c139c595>] rollback_registered+0x23/0x2f [26581.586440] [<c139c5ed>] unregister_netdevice_queue+0x4c/0x69 [26581.586440] [<c139c6b2>] unregister_netdev+0x18/0x1f [26581.586440] [<f9a00d4c>] ar6000_destroy+0xf8/0x115 [ath6kl] [26581.586440] [<f9a0c765>] ar6k_cleanup_module+0x20/0x29 [ath6kl] [26581.586440] [<c1062843>] sys_delete_module+0x181/0x1d9 [26581.586440] [<c105876b>] ? lock_release_holdtime+0x2b/0xcd [26581.586440] [<c10b55dc>] ? sys_munmap+0x3b/0x42 [26581.586440] [<c14a99dc>] ? restore_all+0xf/0xf [26581.586440] [<c14aeb6c>] sysenter_do_call+0x12/0x32 [26581.586440] Code: 89 53 6c 75 07 89 d8 e8 c0 ff ff ff 89 f0 e8 2c f2 a9 c7 5b 5e 5d c3 55 89 e5 57 56 53 89 c3 83 ec 08 89 55 f0 8d 78 04 89 4d ec <8b> b0 b8 00 00 00 46 89 b0 b8 00 00 00 89 f8 e8 ae ed a9 c7 8b Fix the function not to iterate nodes when the scan is aborted. The nodes are already freed when the module is being unloaded. Patch "ath6kl: Fix a kernel panic furing suspend/resume" tried to fix this already but it wasn't enough as a pointer was still used even after the null check. This patch removes the null check entirely as the wmi structure is not accessed anymore during module unload. Also fix a bug where the status was checked as a bitfield with '&' operator. But it's not a bitfield, just a regular (enum like) value. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: If6eebd3738c1b46378cec6f0d39a6067e4e2b25e Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35602 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ath6kl: cache firmwareKalle Valo
commit b42a7b1bc7c0f535dfe35b2c934f239c60bb8d30 upstream. Drivers should not request firmware during resume. Fix ath6kl to cache the firmware instead. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ib6cde5c196da33787a9bc6c5efa9315227c33856 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35601 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ASoC: Mark cache as dirty when suspendingMark Brown
commit 7be4ba24a3ea53bc8ade841635e4d4a59e98ceb5 upstream. Since quite a few drivers are not managing to flag the cache as needing to be resynced after suspend and it's a reasonable thing to do flag the cache as needing sync automatically when suspending. The expectation is that systems will mainly only keep the CODEC powered when doing audio through the CODEC so we won't actually suspend the device anyway; drivers which want to can override this behaviour when they resume. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I3251da89d229c6dfe25b3e0ed269d36c6470702b Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35600 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ASoC: davinci: fix codec start and stop functionsRajashekhara, Sudhakar
commit 3012f43eaf7592d8121426918e43e3b5db013aff upstream. According to DM365 voice codec data sheet at [1], before starting recording or playback, ADC/DAC modules should follow a reset and enable cycle. Writing a 1 to the ADC/DAC bit in the register resets the module and clearing the bit to 0 will enable the module. But the driver seems to be doing the reverse of it. [1] http://focus.ti.com/lit/ug/sprufi9b/sprufi9b.pdf Signed-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ic51dd5415751fb011627a8f3a8ad4d51de626577 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35599 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ASoC: davinci: add missing break statementRajashekhara, Sudhakar
commit 82d1d521036eb3f5aae48b847f939d99a44c18bb upstream. In davinci_vcif_trigger() function, a break() statement was missing causing the davinci_vcif_stop() function to be called as a fallback after calling davinci_vcif_start(). Signed-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I58f55d9ff177ae79049c293bad984738c9244b29 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35598 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28ARM: pxa/cm-x300: fix V3020 RTC functionalityIgor Grinberg
commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 upstream. While in sleep mode the CS# and other V3020 RTC GPIOs must be driven high, otherwise V3020 RTC fails to keep the right time in sleep mode. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I44e37600a66d4097d489c04283af800db73543b0 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35597 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28drivers/rtc/rtc-tegra.c: properly initialize spinlockUwe Kleine-König
commit e57ee01750c4954fd0b5e3c6109cd4b870880eb9 upstream. Using __SPIN_LOCK_UNLOCKED for a dynamically allocated lock is wrong and breaks the build with PREEMPT_RT_FULL. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Andrew Chew <achew@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I28d31fa586ddab4be785d4bba1c2420ea0981161 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35596 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28rtc: limit frequencyThomas Gleixner
commit 431e2bcc371016824f419baa745f82388258f3ee upstream. Due to the hrtimer self rearming mode a user can DoS the machine simply because it's starved by hrtimer events. The RTC hrtimer is self rearming. We really need to limit the frequency to something sensible. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ben Greear <greearb@candelatech.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I9c1217a3d2e04c0be8a12b028d0a921c708b91d9 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35595 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28rtc: fix hrtimer deadlockThomas Gleixner
commit b830ac1d9a2262093bb0f3f6a2fd2a1c8278daf5 upstream. Ben reported a lockup related to rtc. The lockup happens due to: CPU0 CPU1 rtc_irq_set_state() __run_hrtimer() spin_lock_irqsave(&rtc->irq_task_lock) rtc_handle_legacy_irq(); spin_lock(&rtc->irq_task_lock); hrtimer_cancel() while (callback_running); So the running callback never finishes as it's blocked on rtc->irq_task_lock. Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while waiting for the callback. Fix this for both rtc_irq_set_state() and rtc_irq_set_freq(). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reported-by: Ben Greear <greearb@candelatech.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I2b1a13e50b81eda763e175c58c7886e7c7b7f692 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35594 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28rtc: handle errors correctly in rtc_irq_set_state()Thomas Gleixner
commit 2c4f57d12df7696d65b0247bfd57fd082a7719e6 upstream. The code checks the correctness of the parameters, but unconditionally arms/disarms the hrtimer. The result is that a random task might arm/disarm rtc timer and surprise the real owner by either generating events or by stopping them. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ben Greear <greearb@candelatech.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: If7bc32fff7a770c0e8a374f0e47cca6a0e6fcaa3 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35593 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28USB: EHCI: go back to using the system clock for QH unlinksAlan Stern
commit 004c19682884d4f40000ce1ded53f4a1d0b18206 upstream. This patch (as1477) fixes a problem affecting a few types of EHCI controller. Contrary to what one might expect, these controllers automatically stop their internal frame counter when no ports are enabled. Since ehci-hcd currently relies on the frame counter for determining when it should unlink QHs from the async schedule, those controllers run into trouble: The frame counter stops and the QHs never get unlinked. Some systems have also experienced other problems traced back to commit b963801164618e25fbdc0cd452ce49c3628b46c8 (USB: ehci-hcd unlink speedups), which made the original switch from using the system clock to using the frame counter. It never became clear what the reason was for these problems, but evidently it is related to use of the frame counter. To fix all these problems, this patch more or less reverts that commit and goes back to using the system clock. But this can't be done cleanly because other changes have since been made to the scan_async() subroutine. One of these changes involved the tricky logic that tries to avoid rescanning QHs that have already been seen when the scanning loop is restarted, which happens whenever an URB is given back. Switching back to clock-based unlinks would make this logic even more complicated. Therefore the new code doesn't rescan the entire async list whenever a giveback occurs. Instead it rescans only the current QH and continues on from there. This requires the use of a separate pointer to keep track of the next QH to scan, since the current QH may be unlinked while the scanning is in progress. That new pointer must be global, so that it can be adjusted forward whenever the _next_ QH gets unlinked. (uhci-hcd uses this same trick.) Simplification of the scanning loop removes a level of indentation, which accounts for the size of the patch. The amount of code changed is relatively small, and it isn't exactly a reversion of the b963801164 commit. This fixes Bugzilla #32432. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Matej Kenda <matejken@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I620d5e977656740a84fcbc88a03453a736d0624c Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35592 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28USB: OHCI: fix another regression for NVIDIA controllersAlan Stern
commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 upstream. The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related. It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware). The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly. This fixes Bugzilla #22052. Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: Ifa987254cbfa82aceca05093544e29d46e039619 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35591 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28Staging: hv: netvsc: Increase the timeout value in the netvsc driverK. Y. Srinivasan
commit 5c5781b3f88567211ecaaada13431af15c8c6003 upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: If27c75ecc09d3b259325d7ceb210d2b18409b7d2 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35590 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28Staging: hv: vmbus: Increase the timeout value in the vmbus driverK. Y. Srinivasan
commit 2dfde9644fe8c4a77f9c73f95b25d6300ca23b5d upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: If7edbf48ff9fba1003dd549482c0b0f9cf48dc0f Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35589 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28Staging: hv: storvsc: Increase the timeout value in the storvsc driverK. Y. Srinivasan
commit 46d2eb6d82ef44be58ae192c35e8cd52485f02eb upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. the 3.0 kernel as well. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I0834737d04e5f73d3bb139973bdd6b1170ca562e Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35588 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28staging: comedi: fix infoleak to userspaceVasiliy Kulikov
commit 819cbb120eaec7e014e5abd029260db1ca8c5735 upstream. driver_name and board_name are pointers to strings, not buffers of size COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: If5220b6600a85e49d657e4dfe005d6cc4677f1f8 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35587 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
2011-10-28staging: r8192e_pci: Handle duplicate PCI ID 0x10ec:0x8192 conflict with ↵Larry Finger
rtl8192se commit 1c50bf7e415cf6ce9545dbecc2ac0d89d3916c53 upstream. There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and RTL8192SE. The method of distinguishing them is by the revision ID at offset 0x8 of the PCI configuration space. If the value is 0x10, then the device uses rtl8192se for a driver. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Change-Id: I7bcf1251f21bac64374464ad8b5c4a2c61352245 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35586 Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com> Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-11 04:38:22 +0000