- 03 Mar, 2013 15 commits
-
-
Niu Yawei authored
commit f1167009 upstream. In ext4_mb_add_n_trim(), lg_prealloc_lock should be taken when changing the lg_prealloc_list. Signed-off-by:
Niu Yawei <yawei.niu@intel.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
commit 30ebc5e4 upstream. We recently introduced a new return -ENODEV in this function but we need to unlock before returning. [mchehab@redhat.com: found two patches with the same fix. Merged SOB's/acks into one patch] Acked-by:
Herton R. Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Douglas Bagnall <douglas@paradise.net.nz> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Xi Wang authored
commit df1778be upstream. The null check of `strchr() + 1' is broken, which is always non-null, leading to OOB read. Instead, check the result of strchr(). Signed-off-by:
Xi Wang <xi.wang@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Tejun Heo authored
commit 3bec60d5 upstream. fw_device_init() didn't check whether the allocated minor number isn't too large. Fail if it goes overflows MINORBITS. Signed-off-by:
Tejun Heo <tj@kernel.org> Suggested-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by:
-
Tejun Heo authored
commit 6cdae741 upstream. The iteration logic of idr_get_next() is borrowed mostly verbatim from idr_for_each(). It walks down the tree looking for the slot matching the current ID. If the matching slot is not found, the ID is incremented by the distance of single slot at the given level and repeats. The implementation assumes that during the whole iteration id is aligned to the layer boundaries of the level closest to the leaf, which is true for all iterations starting from zero or an existing element and thus is fine for idr_for_each(). However, idr_get_next() may be given any point and if the starting id hits in the middle of a non-existent layer, increment to the next layer will end up skipping the same offset into it. For example, an IDR with IDs filled between [64, 127] would look like the following. [ 0 64 ... ] /----/ | | | NULL [ 64 ... 127 ] If idr_get_next() is called with 63 as the starting point, it will try to follow down the pointer from 0. As it is NULL, it will then try to proceed to the next slot in the same level by adding the slot distance at that level which is 64 - making the next try 127. It goes around the loop and finds and returns 127 skipping [64, 126]. Note that this bug also triggers in idr_for_each_entry() loop which deletes during iteration as deletions can make layers go away leaving the iteration with unaligned ID into missing layers. Fix it by ensuring proceeding to the next slot doesn't carry over the unaligned offset - ie. use round_up(id + 1, slot_distance) instead of id += slot_distance. Signed-off-by:
David Teigland <teigland@redhat.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Jan Beulich authored
commit 9d092603 upstream. "be->mode" is obtained from xenbus_read(), which does a kmalloc() for the message body. The short string is never released, so do it along with freeing "be" itself, and make sure the string isn't kept when backend_changed() doesn't complete successfully (which made it desirable to slightly re-structure that function, so that the error cleanup can be done in one place). Reported-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Xiaowei.Hu authored
commit 309a85b6 upstream. ocfs2_block_group_alloc_discontig() disables chain relink by setting ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple cluster groups. It doesn't keep the credits for all chain relink,but ocfs2_claim_suballoc_bits overrides this in this call trace: ocfs2_block_group_claim_bits()->ocfs2_claim_clusters()-> __ocfs2_claim_clusters()->ocfs2_claim_suballoc_bits() ocfs2_claim_suballoc_bits set ac->ac_allow_chain_relink = 1; then call ocfs2_search_chain() one time and disable it again, and then we run out of credits. Fix is to allow relink by default and disable it in ocfs2_block_group_alloc_discontig. Without this patch, End-users will run into a crash due to run out of credits, backtrace like this: RIP: 0010:[<ffffffffa0808b14>] [<ffffffffa0808b14>] jbd2_journal_dirty_metadata+0x164/0x170 [jbd2] RSP: 0018:ffff8801b919b5b8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88022139ddc0 RCX: ffff880159f652d0 RDX: ffff880178aa3000 RSI: ffff880159f652d0 RDI: ffff880087f09bf8 RBP: ffff8801b919b5e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000001e00 R11: 00000000000150b0 R12: ffff880159f652d0 R13: ffff8801a0cae908 R14: ffff880087f09bf8 R15: ffff88018d177800 FS: 00007fc9b0b6b6e0(0000) GS:ffff88022fd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000040819c CR3: 0000000184017000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process dd (pid: 9945, threadinfo ffff8801b919a000, task ffff880149a264c0) Call Trace: ocfs2_journal_dirty+0x2f/0x70 [ocfs2] ocfs2_relink_block_group+0x111/0x480 [ocfs2] ocfs2_search_chain+0x455/0x9a0 [ocfs2] ... Signed-off-by:
Xiaowei.Hu <xiaowei.hu@oracle.com> Reviewed-by:
Srinivas Eeda <srinivas.eeda@oracle.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by:
-
Nicholas Bellinger authored
commit fbbf8555 upstream. This patch adds missing bounds checking for the configfs provided mapped_lun value during target_fabric_make_mappedlun() setup ahead of se_lun_acl initialization. This addresses a potential OOPs when using a mapped_lun value that exceeds the hardcoded TRANSPORT_MAX_LUNS_PER_TPG-1 value within se_node_acl->device_list[]. Reported-by:
Jan Engelhardt <jengelh@inai.de> Cc: Jan Engelhardt <jengelh@inai.de> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
H. Peter Anvin authored
commit 7c100936 upstream. On non-BIOS platforms it is possible that the BIOS data area contains garbage instead of being zeroed or something equivalent (firmware people: we are talking of 1.5K here, so please do the sane thing.) We need on the order of 20-30K of low memory in order to boot, which may grow up to < 64K in the future. We probably want to avoid the lowest of the low memory. At the same time, it seems extremely unlikely that a legitimate EBDA would ever reach down to the 128K (which would require it to be over half a megabyte in size.) Thus, pick 128K as the cutoff for "this is insane, ignore." We may still end up reserving a bunch of extra memory on the low megabyte, but that is not really a major issue these days. In the worst case we lose 512K of RAM. This code really should be merged with trim_bios_range() in arch/x86/kernel/setup.c, but that is a bigger patch for a later merge window. Reported-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/n/tip-oebml055yyfm8yxmria09rja@git.kernel.orgSigned-off-by:
-
Konrad Rzeszutek Wilk authored
commit a2fd6419 upstream. Both the PowerPC hypervisor and Xen hypervisor can utilize the hvc driver. Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit 2482a92e upstream. The earlyprintk for Xen PV guests utilizes a simple hypercall (console_io) to provide output to Xen emergency console. Note that the Xen hypervisor should be booted with 'loglevel=all' to output said information. Reported-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 8c189ea6 upstream. Commit: c1bf08ac "ftrace: Be first to run code modification on modules" changed ftrace module notifier's priority to INT_MAX in order to process the ftrace nops before anything else could touch them (namely kprobes). This was the correct thing to do. Unfortunately, the ftrace module notifier also contains the ftrace clean up code. As opposed to the set up code, this code should be run *after* all the module notifiers have run in case a module is doing correct clean-up and unregisters its ftrace hooks. Basically, ftrace needs to do clean up on module removal, as it needs to know about code being removed so that it doesn't try to modify that code. But after it removes the module from its records, if a ftrace user tries to remove a probe, that removal will fail due as the record of that code segment no longer exists. Nothing really bad happens if the probe removal is called after ftrace did the clean up, but the ftrace removal function will return an error. Correct code (such as kprobes) will produce a WARN_ON() if it fails to remove the probe. As people get annoyed by frivolous warnings, it's best to do the ftrace clean up after everything else. By splitting the ftrace_module_notifier into two notifiers, one that does the module load setup that is run at high priority, and the other that is called for module clean up that is run at low priority, the problem is solved. Reported-by:
Frank Ch. Eigler <fche@redhat.com> Acked-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tejun Heo authored
commit e182bb38 upstream. When idr_find() was fed a negative ID, it used to look up the ID ignoring the sign bit before recent ("idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c") patch. Now a negative ID triggers a WARN_ON_ONCE(). __lock_timer() feeds timer_id from userland directly to idr_find() without sanitizing it which can trigger the above malfunctions. Add a range check on @timer_id before invoking idr_find() in __lock_timer(). While timer_t is defined as int by all archs at the moment, Andrew worries that it may be defined as a larger type later on. Make the test cover larger integers too so that it at least is guaranteed to not return the wrong timer. Note that WARN_ON_ONCE() in idr_find() on id < 0 is transitional precaution while moving away from ignoring MSB. Once it's gone we can remove the guard as long as timer_t isn't larger than int. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/20130220232412.GL3570@htj.dyndns.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Joerg Roedel authored
commit f528d980 upstream. When dma_ops are initialized the unity mappings are created. The init_device_table_dma() function makes sure DMA from all devices is blocked by default. This opens a short window in time where DMA to unity mapped regions is blocked by the IOMMU. Make sure this does not happen by initializing the device table after dma_ops. Signed-off-by:
Joerg Roedel <joro@8bytes.org> Signed-off-by:
Shuah Khan <shuah.khan@hp.com> Signed-off-by:
-
Theodore Ts'o authored
commit c3ad83d9 upstream. Otherwise, ext4 file systems with the quota featured enable will get a very confusing "No such process" error message if the quota code is built as a module and the quota_v2 module has not been loaded. Signed-off-by:
Carlos Maiolino <cmaiolino@redhat.com> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
- 28 Feb, 2013 25 commits
-
-
Greg Kroah-Hartman authored
-
Josh Boyer authored
commit 18e03310 upstream. The current entry in unusual_cypress.h for the Super TOP SATA bridge devices seems to be causing corruption on newer revisions of this device. This has been reported in Arch Linux and Fedora. The original patch was tested on devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591 The Arch Forum post on this is here: https://bbs.archlinux.org/viewtopic.php?id=152011Reported-by:
Carsten S. <carsteniq@yahoo.com> Tested-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
fangxiaozhi authored
commit cd060956 upstream. 1. The idProduct is little endian, so make sure its value to be compatible with the current CPU. Make no break on big endian processors. Signed-off-by:
fangxiaozhi <huananhu@huawei.com> Signed-off-by:
-
Roger Quadros authored
commit 04753523 upstream. The module alias should be "ehci-omap" and not "omap-ehci" to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by:
Roger Quadros <rogerq@ti.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Bjørn Mork authored
commit 1f3f6877 upstream. The USB device descriptor of one identity presented by a few Huawei morphing devices have serial functions with class codes 02/02/ff, indicating CDC ACM with a vendor specific protocol. This combination is often used for MSFT RNDIS functions, and the CDC ACM class driver will therefore ignore such functions. The CDC ACM class driver cannot support functions with only 2 endpoints. The underlying serial functions of these modems are also believed to be the same as for alternate device identities already supported by the option driver. Letting the same driver handle these functions independently of the current identity ensures consistent handling and user experience. There is no need to blacklist these devices in the rndis_host driver. Huawei serial functions will either have only 2 endpoints or a CDC ACM functional descriptor with bmCapabilities != 0, making them correctly ignored as "non RNDIS" by that driver. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
commit cd565279 upstream. Interface layout: 00 CD-ROM 01 debug COM port 02 AP control port 03 modem 04 usb-ethernet Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0408 ProdID=ea42 Rev= 0.00 S: Manufacturer=Qualcomm, Incorporated S: Product=Qualcomm CDMA Technologies MSM S: SerialNumber=353568051xxxxxx C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms Signed-off-by:
-
Bjørn Mork authored
commit f8f0302b upstream. Adding three currently unsupported modems based on information from .inf driver files: Diag VID_1BBB&PID_0052&MI_00 AGPS VID_1BBB&PID_0052&MI_01 VOICE VID_1BBB&PID_0052&MI_02 AT VID_1BBB&PID_0052&MI_03 Modem VID_1BBB&PID_0052&MI_05 wwan VID_1BBB&PID_0052&MI_06 Diag VID_1BBB&PID_00B6&MI_00 AT VID_1BBB&PID_00B6&MI_01 Modem VID_1BBB&PID_00B6&MI_02 wwan VID_1BBB&PID_00B6&MI_03 Diag VID_1BBB&PID_00B7&MI_00 AGPS VID_1BBB&PID_00B7&MI_01 VOICE VID_1BBB&PID_00B7&MI_02 AT VID_1BBB&PID_00B7&MI_03 Modem VID_1BBB&PID_00B7&MI_04 wwan VID_1BBB&PID_00B7&MI_05 Updating the blacklist info for the X060S_X200 and X220_X500D, reserving interfaces for a wwan driver, based on wwan VID_1BBB&PID_0000&MI_04 wwan VID_1BBB&PID_0017&MI_06 Signed-off-by:
-
Maciej Sosnowski authored
commit c419fcfd upstream. When providers get blocked unregister_dca_providers() is called ending up with dca_providers and dca_domain lists emptied. Dca should be prevented from trying to unregister any provider if dca_domain list is found empty. Reported-by:
Jiang Liu <jiang.liu@huawei.com> Tested-by:
Gaohuai Han <hangaohuai@huawei.com> Signed-off-by:
Maciej Sosnowski <maciej.sosnowski@intel.com> Signed-off-by:
Dan Williams <djbw@fb.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 08dcdbf6 ] It looks like its possible to open thousands of TCP IPv6 sessions on a server, all landing in a single slot of TCP hash table. Incoming packets have to lookup sockets in a very long list. We should hash all bits from foreign IPv6 addresses, using a salt and hash mix, not a simple XOR. inet6_ehashfn() can also separately use the ports, instead of xoring them. Reported-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Yuchung Cheng <ycheng@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Li Wei authored
[ Upstream commit b531ed61 ] We should get 'type' and 'code' from the outer ICMP header. Signed-off-by:
Li Wei <lw@cn.fujitsu.com> Signed-off-by:
-
David Vrabel authored
[ Upstream commit 3e55f8b3 ] If the credit timer is left armed after calling xen_netbk_remove_xenvif(), then it may fire and attempt to schedule the vif which will then oops as vif->netbk == NULL. This may happen both in the fatal error path and during normal disconnection from the front end. The sequencing during shutdown is critical to ensure that: a) vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif is not freed. 1. Mark as unschedulable (netif_carrier_off()). 2. Synchronously cancel the timer. 3. Remove the vif from the schedule list. 4. Remove it from it netback thread group. 5. Wait for vif->refcnt to become 0. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Reported-by:
Christopher S. Aker <caker@theshore.net> Signed-off-by:
-
David Vrabel authored
[ Upstream commit 35876b5f ] netbk_count_requests() could detect an error, call netbk_fatal_tx_error() but return 0. The vif may then be used afterwards (e.g., in a call to netbk_tx_error(). Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may be freed immediately after the call to netbk_fatal_tx_error() (e.g., if the vif is also removed). Netback thread Xenwatch thread ------------------------------------------- netbk_fatal_tx_err() netback_remove() xenvif_disconnect() ... free_netdev() netbk_tx_err() Oops! Signed-off-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
Stephen Hemminger authored
[ Upstream commit 547b4e71 ] Spanning Tree Protocol packets should have always been marked as control packets, this causes them to get queued in the high prirority FIFO. As Radia Perlman mentioned in her LCA talk, STP dies if bridge gets overloaded and can't communicate. This is a long-standing bug back to the first versions of Linux bridge. Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Takashi Iwai authored
commit e93a9a86 upstream. I've still got lockdep warnings even after Alan's patch, and it seems that yet more band aids are required to paper over similar paths for unbind_con_driver() and unregister_con_driver(). After this hack, lockdep warnings are finally gone. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Jiri Kosina <jkosina@suse.cz> Tested-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alan Cox authored
commit 50e244cc upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment] [akpm@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by:
Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Jiri Kosina <jkosina@suse.cz> Tested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Dave Airlie authored
commit ae128786 upstream. If grub2 loads efifb/vesafb, then when systemd starts it can set the console font on that framebuffer device, however when we then load the native KMS driver, the first thing it does is tear down the generic framebuffer driver. The thing is the generic code is doing the right thing, it frees the font because otherwise it would leak memory. However we can assume that if you are removing the generic firmware driver (vesa/efi/offb), that a new driver *should* be loading soon after, so we effectively leak the font. However the old code left a dangling pointer in vc->vc_font.data and we can now reuse that dangling pointer to load the font into the new driver, now that we aren't freeing it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340Signed-off-by:
-
Jean Delvare authored
commit 811af972 upstream. It doesn't seem this spinlock was properly initialized. This bug was introduced by commit 7a410e8d. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
John David Anglin authored
commit 7139bc15 upstream. This patch goes a long way toward fixing the minifail bug, and it significantly improves the stability of SMP machines such as the rp3440. When write protecting a page for COW, we need to purge the existing translation. Otherwise, the COW break doesn't occur as expected because the TLB may still have a stale entry which allows writes. [jejb: fix up checkpatch errors] Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Phileas Fogg authored
commit 8520e443 upstream. Disable hard IRQ before kexec a new kernel image. Not doing it can result in corrupted data in the memory segments reserved for the new kernel. Signed-off-by:
Phileas Fogg <phileas-fogg@mail.ru> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Igor Grinberg authored
commit d107a204 upstream. The Chip Select Configuration Register must be programmed to 0x2 in order to achieve the correct behavior of the Static Memory Controller. Without this patch devices wired to DFI and accessed through SMC cannot be accessed after resume from S2. Do not rely on the boot loader to program the CSMSADRCFG register by programming it in the kernel smemc module. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Acked-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
commit ae5943de upstream. This error happens because PIPEnsControlOut and PIPEnsControlIn unlock the spin lock for delay, letting in another thread. The patch moves the current MP_SET_FLAG to before filling of sUsbCtlRequest for pControlURB and clears it in event of failing. Any thread calling either function while fMP_CONTROL_READS or fMP_CONTROL_WRITES flags set will return STATUS_FAILURE. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Ian Abbott authored
commit 754ab5c0 upstream. Comedi has two sorts of minor devices: (a) normal board minor devices in the range 0 to COMEDI_NUM_BOARD_MINORS-1 inclusive; and (b) special subdevice minor devices in the range COMEDI_NUM_BOARD_MINORS upwards that are used to open the same underlying comedi device as the normal board minor devices, but with non-default read and write subdevices for asynchronous commands. The special subdevice minor devices get created when a board supporting asynchronous commands is attached to a normal board minor device, and destroyed when the board is detached from the normal board minor device. One way to attach or detach a board is by using the COMEDI_DEVCONFIG ioctl. This should only be used on normal board minors as the special subdevice minors are too ephemeral. In particular, the change introduced in commit 7d3135af ("staging: comedi: prevent auto-unconfig of manually configured devices") breaks horribly for special subdevice minor devices. Since there's no legitimate use for the COMEDI_DEVCONFIG ioctl on a special subdevice minor device node, disallow it and return -ENOTTY. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Mika Kuoppala authored
commit 24a1f16d upstream. If encoder is switched off by BIOS, but the panel fitter is left on, we never try to turn off the panel fitter and leave it still attached to the pipe - which can cause blurry output elsewhere. Based on work by Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Tested-by:
Andreas Sturmlechner <andreas.sturmlechner@gmail.com> [danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny comment.] Signed-off-by:
-
Alan Stern authored
commit 0720a06a upstream. The utf8s_to_utf16s conversion routine needs to be improved. Unlike its utf16s_to_utf8s sibling, it doesn't accept arguments specifying the maximum length of the output buffer or the endianness of its 16-bit output. This patch (as1501) adds the two missing arguments, and adjusts the only two places in the kernel where the function is called. A follow-on patch will add a third caller that does utilize the new capabilities. The two conversion routines are still annoyingly inconsistent in the way they handle invalid byte combinations. But that's a subject for a different patch. Signed-off-by:
-
Dave Airlie authored
commit 9f23de52 upstream. While looking at plymouth on udl I noticed that plymouth was trying to use its fb plugin not its drm one, it was trying to drmOpen a driver called usb not udl, noticed that we actually had out driver pointing at the wrong device. Signed-off-by:
-
