- 05 Nov, 2012 11 commits
-
-
Ben Skeggs authored
This is to prevent nouveau from taking over the console on headless boards such as Tesla. Backport of upstream commit: e412e95aSigned-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Skeggs authored
Backport of fixes from upstream commit: 9430738dSigned-off-by:
-
Ben Skeggs authored
commit cee59f15 upstream. Signed-off-by:
-
Jiri Slaby authored
commit 3ccc60f9 upstream. Microsoft Digital Media Keyboard 3000 has two interfaces, and the second one has a report descriptor with a bug. The second collection says: 05 01 -- global; usage page -- 01 -- Generic Desktop Controls 09 80 -- local; usage -- 80 -- System Control a1 01 -- main; collection -- 01 -- application 85 03 -- global; report ID -- 03 19 00 -- local; Usage Minimum -- 00 29 ff -- local; Usage Maximum -- ff 15 00 -- global; Logical Minimum -- 0 26 ff 00 -- global; Logical Maximum -- ff 81 00 -- main; input c0 -- main; End Collection I.e. it makes us think that there are all kinds of usages of system control. That the keyboard is a not only a keyboard, but also a joystick, mouse, gamepad, keypad, etc. The same as for the Wireless Desktop Receiver, this should be Physical Min/Max. So fix that appropriately. References: https://bugzilla.novell.com/show_bug.cgi?id=776834Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Nicholas Bellinger authored
commit e13d5fef upstream. Fabric drivers currently expect to internally release se_cmd in the event of a TMR failure during target_submit_tmr(), which means the immediate call to transport_generic_free_cmd() after TFO->queue_tm_rsp() from within target_complete_tmr_failure() workqueue context is wrong. This is done as some fabrics expect TMR operations to be acknowledged before releasing the descriptor, so the assumption that core is releasing se_cmd associated TMR memory is incorrect. This fixes a OOPs where transport_generic_free_cmd() was being called more than once. This bug was originally observed with tcm_qla2xxx fabric ports. Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Roland Dreier <roland@purestorage.com> Cc: Andy Grover <agrover@redhat.com> Signed-off-by:
-
Larry Finger authored
commit f89ff644 upstream. When b43 fails to find firmware when loaded, a subsequent unload will oops due to calling ieee80211_unregister_hw() when the corresponding register call was never made. Commit 2d838bb6 fixed the same problem for b43legacy. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Tested-by:
Markus Kanet <dvmailing@gmx.eu> Cc: Markus Kanet <dvmailing@gmx.eu> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 238ab784 upstream. If blk_init_queue fails, we do not call put_disk on the current dr (dr is decremented first in the error handling loop). Reviewed-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
NeilBrown authored
commit 02b898f2 upstream. setup_conf in raid1.c uses conf->raid_disks before assigning a value. It is used when including 'Replacement' devices. The consequence is that assembling an array which contains a replacement will misbehave and either not include the replacement, or not include the device being replaced. Though this doesn't lead directly to data corruption, it could lead to reduced data safety. So use mddev->raid_disks, which is initialised, instead. Bug was introduced by commit c19d5798 md/raid1: recognise replacements when assembling arrays. in 3.3, so fix is suitable for 3.3.y thru 3.6.y. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Mathias Nyman authored
commit ad2fab36 upstream. gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit d79550a7 upstream. ->last_ier is an unsigned long but the high bits can't be used int the original code because the shift wraps. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Eric Sandeen authored
commit ffb5387e upstream. commit 119c0d44 changed ext4_new_inode() such that the inode bitmap was being modified outside a transaction, which could lead to corruption, and was discovered when journal_checksum found a bad checksum in the journal during log replay. Nix ran into this when using the journal_async_commit mount option, which enables journal checksumming. The ensuing journal replay failures due to the bad checksums led to filesystem corruption reported as the now infamous "Apparent serious progressive ext4 data corruption bug" [ Changed by tytso to only call ext4_journal_get_write_access() only when we're fairly certain that we're going to allocate the inode. ] I've tested this by mounting with journal_checksum and running fsstress then dropping power; I've also tested by hacking DM to create snapshots w/o first quiescing, which allows me to test journal replay repeatedly w/o actually power-cycling the box. Without the patch I hit a journal checksum error every time. With this fix it survives many iterations. Reported-by:
Nix <nix@esperi.org.uk> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
- 31 Oct, 2012 29 commits
-
-
Greg Kroah-Hartman authored
-
Sjoerd Simons authored
commit 9756fe38 upstream. This box claims to have an LVDS interface but doesn't actually have one. Signed-off-by:
Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Yinghai Lu authored
commit 1f2ff682 upstream. We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time. Also memblock has page aligned range for ram, so we could avoid mapping partial pages. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.comAcked-by:
Jacob Shin <jacob.shin@amd.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Ian Abbott authored
commit aaeb61a9 upstream. `pc236_detach()` is called by the comedi core if it attempted to attach a device and failed. `pc236_detach()` calls `pc236_intr_disable()` if the comedi device private data pointer (`devpriv`) is non-null. This test is insufficient as `pc236_intr_disable()` accesses hardware registers and the attach routine may have failed before it has saved their I/O base addresses. Fix it by checking `dev->iobase` is non-zero before calling `pc236_intr_disable()` as that means the I/O base addresses have been saved and the hardware registers can be accessed. It also implies the comedi device private data pointer is valid, so there is no need to check it. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Olof Johansson authored
commit 5189c2a7 upstream. When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off efi_enabled once setup is done. Beyond setup, it is normally used to determine if runtime services are available and we will have none. This will resolve issues stemming from efivars modprobe panicking on a 32/64-bit setup, as well as some reboot issues on similar setups. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991Reported-by:
Marko Kohtala <marko.kohtala@gmail.com> Reported-by:
Maxim Kammerer <mk@dee.su> Signed-off-by:
Olof Johansson <olof@lixom.net> Acked-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Josh Triplett authored
commit 78510792 upstream. Some new ACPI 5.0 tables reference resources stored in boot services memory, so keep that memory around until we have ACPI and can extract data from it. Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.orgSigned-off-by:
-
Yinghai Lu authored
commit f82f64dd upstream. Commit 844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped added back some lines back wrongly that has been removed in commit 7b16bbf9 Revert "x86/mm: Fix the size calculation of mapping tables" remove them again. Signed-off-by:
-
Jacob Shin authored
commit 844ab6f9 upstream. Current logic finds enough space for direct mapping page tables from 0 to end. Instead, we only need to find enough space to cover mr[0].start to mr[nr_range].end -- the range that is actually being mapped by init_memory_mapping() This is needed after 1bbbbe77, to address the panic reported here: https://lkml.org/lkml/2012/10/20/160 https://lkml.org/lkml/2012/10/21/157Signed-off-by:
Tom Rini <trini@ti.com> Signed-off-by:
-
Felix Fietkau authored
commit 73b26df5 upstream. This reverts commit a240dc7b. This commit is reducing tx power by at least 10 db on some devices, e.g. the Buffalo WZR-HP-G450H. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: rmanohar@qca.qualcomm.com Signed-off-by:
-
Andreas Herrmann authored
commit e4df1cbc upstream. Commit 6889125b (cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU) causes powernow-k8 to trigger a preempt warning, e.g.: BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776 caller is powernowk8_target+0x20/0x49 Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9 Call Trace: [<ffffffff8125b447>] debug_smp_processor_id+0xc7/0xe0 [<ffffffff814877e7>] powernowk8_target+0x20/0x49 [<ffffffff81482b02>] __cpufreq_driver_target+0x82/0x8a [<ffffffff81484fc6>] cpufreq_governor_performance+0x4e/0x54 [<ffffffff81482c50>] __cpufreq_governor+0x8c/0xc9 [<ffffffff81482e6f>] __cpufreq_set_policy+0x1a9/0x21e [<ffffffff814839af>] store_scaling_governor+0x16f/0x19b [<ffffffff81484f16>] ? cpufreq_update_policy+0x124/0x124 [<ffffffff8162b4a5>] ? _raw_spin_unlock_irqrestore+0x2c/0x49 [<ffffffff81483640>] store+0x60/0x88 [<ffffffff811708c0>] sysfs_write_file+0xf4/0x130 [<ffffffff8111243b>] vfs_write+0xb5/0x151 [<ffffffff811126e0>] sys_write+0x4a/0x71 [<ffffffff816319a9>] system_call_fastpath+0x16/0x1b Fix this by by always using work_on_cpu(). Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Piotr Haber authored
commit 1fffa905 upstream. When cores are unregistered, entries need to be removed from cores list in a safe manner. Reported-by:
Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by:
Arend Van Spriel <arend@broadcom.com> Signed-off-by:
Piotr Haber <phaber@broadcom.com> Signed-off-by:
-
Wei Yongjun authored
commit 720dfd25 upstream. Add the missing unlock on the error handling path in function imxdma_xfer_desc(). Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by:
-
Barry Song authored
commit 26fd1220 upstream. list_move_tail(&schan->queued, &schan->active) makes the list_empty(schan->queued) undefined, we either should change it to: list_move_tail(schan->queued.next, &schan->active) or list_move_tail(&sdesc->node, &schan->active) Signed-off-by:
Barry Song <Baohua.Song@csr.com> Signed-off-by:
-
Barry Song authored
commit 5997e089 upstream. either DEV_TO_MEM or MEM_TO_DEV is supported, so change OR to AND. Signed-off-by:
-
Oleg Nesterov authored
commit b40a7959 upstream. flush_old_exec() clears PF_KTHREAD but forgets about PF_NOFREEZE. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Johan Hedberg authored
commit 065a13e2 upstream. When sending a pairing request or response we should not just blindly copy the value that the remote device sent. Instead we should at least make sure to mask out any unknown bits. This is particularly critical from the upcoming LE Secure Connections feature perspective as incorrectly indicating support for it (by copying the remote value) would cause a failure to pair with devices that support it. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Stanislaw Gruszka authored
commit 4045f72b upstream. This patch fix corruption which can manifest itself by following crash when switching on rfkill switch with rt2x00 driver: https://bugzilla.redhat.com/attachment.cgi?id=615362 Pointer key->u.ccmp.tfm of group key get corrupted in: ieee80211_rx_h_michael_mic_verify(): /* update IV in key information to be able to detect replays */ rx->key->u.tkip.rx[rx->security_idx].iv32 = rx->tkip_iv32; rx->key->u.tkip.rx[rx->security_idx].iv16 = rx->tkip_iv16; because rt2x00 always set RX_FLAG_MMIC_STRIPPED, even if key is not TKIP. We already check type of the key in different path in ieee80211_rx_h_michael_mic_verify() function, so adding additional check here is reasonable. Signed-off-by:
-
Ivan Shugov authored
commit 3d9a0183 upstream. Newer at91sam9g10 SoC revision can't be detected, so the kernel can't boot with this kind of kernel panic: "AT91: Impossible to detect the SOC type" CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Atmel AT91SAM9G10-EK Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback Kernel panic - not syncing: AT91: Impossible to detect the SOC type [<c00133d4>] (unwind_backtrace+0x0/0xe0) from [<c02366dc>] (panic+0x78/0x1cc) [<c02366dc>] (panic+0x78/0x1cc) from [<c02fa35c>] (at91_map_io+0x90/0xc8) [<c02fa35c>] (at91_map_io+0x90/0xc8) from [<c02f9860>] (paging_init+0x564/0x6d0) [<c02f9860>] (paging_init+0x564/0x6d0) from [<c02f7914>] (setup_arch+0x464/0x704) [<c02f7914>] (setup_arch+0x464/0x704) from [<c02f44f8>] (start_kernel+0x6c/0x2d4) [<c02f44f8>] (start_kernel+0x6c/0x2d4) from [<20008040>] (0x20008040) The reason for this is that the Debug Unit Chip ID Register has changed between Engineering Sample and definitive revision of the SoC. Changing the check of cidr to socid will address the problem. We do not integrate this check to the list just above because we also have to make sure that the extended id is disregarded. Signed-off-by:
Ivan Shugov <ivan.shugov@gmail.com> [nicolas.ferre@atmel.com: change commit message] Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Bo Shen authored
commit 7840487c upstream. The i2c core driver will turn the platform device ID to busnum When using platfrom device ID as -1, it means dynamically assigned the busnum. When writing code, we need to make sure the busnum, and call i2c_register_board_info(int busnum, ...) to register device if using -1, we do not know the value of busnum In order to solve this issue, set the platform device ID as a fix number Here using 0 to match the busnum used in i2c_regsiter_board_info() Signed-off-by:
Bo Shen <voice.shen@atmel.com> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Josh Wu authored
commit 11930c53 upstream. Signed-off-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
-
Heiko Stuebner authored
commit 308b3afb upstream. Commit a5238e36 (spi: s3c64xx: move controller information into driver data) introduced separate device names for the different subtypes of the spi controller but forgot to set these in the relevant machines. To fix this introduce a s3c64xx_spi_setname function and populate all Samsung arches with the correct names. The function resides in a new header, as the s3c64xx-spi.h contains driver platform data and should therefore at some later point move out of the Samsung include dir. Tested on a s3c2416-based machine. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> [s.nawrocki@samsung.com: tested on mach-exynos] Tested-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Michael S. Tsirkin authored
commit 910a578f upstream. We copy head count to a 16 bit field, this works by chance on LE but on BE guest gets 0. Fix it up. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Johan Hovold authored
commit e681b66f upstream. Remove private zombie flag used to signal disconnect and to prevent control urb from being submitted from interrupt urb completion handler. The control urb will not be re-submitted as both the control urb and the interrupt urb is killed on disconnect. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 28c3ae9a upstream. The private int_urb is never allocated so the submission from the control completion handler will always fail. Remove this odd piece of broken code. Signed-off-by:
-
Johan Hovold authored
commit 3eb55cc4 upstream. The driver set the usb-serial port pointers to NULL on errors in attach, effectively preventing usb-serial core from decrementing the port ref counters and releasing the port devices and associated data. Signed-off-by:
-
Johan Hovold authored
commit 65a4cdbb upstream. Make sure control urb is freed at release. Signed-off-by:
-
Johan Hovold authored
commit 084817d7 upstream. Move interface data allocation to attach so that it is deallocated on errors in usb-serial probe. Signed-off-by:
-
Johan Hovold authored
commit 7e41f9bc upstream. Make sure port private data is deallocated on errors in attach. Signed-off-by:
-
Lennart Sorensen authored
commit f7bc5051 upstream. I found a memory leak in sierra_release() (well sierra_probe() I guess) that looses 8 bytes each time the driver releases a device. Signed-off-by:
Len Sorensen <lsorense@csclub.uwaterloo.ca> Acked-by:
-
