- 06 Jan, 2012 33 commits
-
-
Dave Kleikamp authored
commit e6f67b8c upstream. lockdep reports a deadlock in jfs because a special inode's rw semaphore is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used when __read_cache_page() calls add_to_page_cache_lru(). Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by:
Hugh Dickins <hughd@google.com> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ilya Yanok authored
commit 8653be1a upstream. Check inuse variable before trying to access twl_map to prevent dereferencing of uninitialized variable. Signed-off-by:
Ilya Yanok <yanok@emcraft.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Mandeep Singh Baines authored
commit e0197aae upstream. There is a BUG when migrating a PF_EXITING proc. Since css_set_prefetch() is not called for the PF_EXITING case, find_existing_css_set() will return NULL inside cgroup_task_migrate() causing a BUG. This bug is easy to reproduce. Create a zombie and echo its pid to cgroup.procs. $ cat zombie.c \#include <unistd.h> int main() { if (fork()) pause(); return 0; } $ We are hitting this bug pretty regularly on ChromeOS. This bug is already fixed by Tejun Heo's cgroup patchset which is targetted for the next merge window: https://lkml.org/lkml/2011/11/1/356 I've create a smaller patch here which just fixes this bug so that a fix can be merged into the current release and stable. Signed-off-by:
Mandeep Singh Baines <msb@chromium.org> Downstream-Bug-Report: http://crosbug.com/23953Reviewed-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: containers@lists.linux-foundation.org Cc: cgroups@vger.kernel.org Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Paul Menage <paul@paulmenage.org> Cc: Olof Johansson <olofj@chromium.org> Signed-off-by:
-
Rusty Russell authored
commit 61074287 upstream. You didn't mean this to be a bool. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Acked-by:
Tony Olech <tony.olech@elandigitalsystems.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Thomas Meyer authored
commit 695c60f2 upstream. commit 828b1c50 ("nilfs2: add compat ioctl") incidentally broke all other NILFS compat ioctls. Make them work again. Signed-off-by:
Thomas Meyer <thomas@m3y3r.de> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Gary Thomas authored
commit d1ee8878 upstream. This patch is against the mainline v3.1 release (c3b92c87) and fixes a compile error when building for OMAP3+DSS+VOUT Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Gary Thomas <gary@mlbassoc.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
David Howells authored
commit 50345f1e upstream. Fix the following bug in sel_netport_insert() where rcu_dereference() should be rcu_dereference_protected() as sel_netport_lock is held. =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/selinux/netport.c:127 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by ossec-rootcheck/3323: #0: (sel_netport_lock){+.....}, at: [<ffffffff8117d775>] sel_netport_sid+0xbb/0x226 stack backtrace: Pid: 3323, comm: ossec-rootcheck Not tainted 3.1.0-rc8-fsdevel+ #1095 Call Trace: [<ffffffff8105cfb7>] lockdep_rcu_dereference+0xa7/0xb0 [<ffffffff8117d871>] sel_netport_sid+0x1b7/0x226 [<ffffffff8117d6ba>] ? sel_netport_avc_callback+0xbc/0xbc [<ffffffff8117556c>] selinux_socket_bind+0x115/0x230 [<ffffffff810a5388>] ? might_fault+0x4e/0x9e [<ffffffff810a53d1>] ? might_fault+0x97/0x9e [<ffffffff81171cf4>] security_socket_bind+0x11/0x13 [<ffffffff812ba967>] sys_bind+0x56/0x95 [<ffffffff81380dac>] ? sysret_check+0x27/0x62 [<ffffffff8105b767>] ? trace_hardirqs_on_caller+0x11e/0x155 [<ffffffff81076fcd>] ? audit_syscall_entry+0x17b/0x1ae [<ffffffff811b5eae>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81380d7b>] system_call_fastpath+0x16/0x1b Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Paul Moore <paul@paul-moore.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Trond Myklebust authored
commit 111d489f upstream. Currently, the code assumes that the SEQUENCE status bits are mutually exclusive. They are not... Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit 6c529617 upstream. After commit 06222e49 (fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek) the behaviour of llseek() was changed so that it always revalidates the file size. The bug appears to be due to a logic error in the afore-mentioned commit, which always evaluates to 'true'. Reported-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
Trond Myklebust authored
commit c25573b5 upstream. Whenever we free a slot, we know that the resulting xprt->num_reqs will be less than xprt->max_reqs, so we know that we can release at least one backlogged rpc_task. Signed-off-by:
-
Robert Richter authored
commit 913050b9 upstream. If oprofilefs_ulong_from_user() is called with count equals zero, *val remains unchanged. Depending on the implementation it might be uninitialized. Change oprofilefs_ulong_from_user()'s interface to return count on success. Thus, we are able to return early if count equals zero which avoids using *val uninitialized. Fixing all users of oprofilefs_ulong_ from_user(). This follows write syscall implementation when count is zero: "If count is zero ... [and if] no errors are detected, 0 will be returned without causing any other effect." (man 2 write) Reported-By:
Mike Waychison <mikew@google.com> Signed-off-by:
Robert Richter <robert.richter@amd.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: oprofile-list <oprofile-list@lists.sourceforge.net> Link: http://lkml.kernel.org/r/20111219153830.GH16765@erda.amd.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Frantisek Hrbata authored
commit ff05b6f7 upstream. An integer overflow will happen on 64bit archs if task's sum of rss, swapents and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit f755a042 oom: use pte pages in OOM score where the oom score computation was divided into several steps and it's no longer computed as one expression in unsigned long(rss, swapents, nr_pte are unsigned long), where the result value assigned to points(int) is in range(1..1000). So there could be an int overflow while computing 176 points *= 1000; and points may have negative value. Meaning the oom score for a mem hog task will be one. 196 if (points <= 0) 197 return 1; For example: [ 3366] 0 3366 35390480 24303939 5 0 0 oom01 Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical memory, but it's oom score is one. In this situation the mem hog task is skipped and oom killer kills another and most probably innocent task with oom score greater than one. The points variable should be of type long instead of int to prevent the int overflow. Signed-off-by:
Frantisek Hrbata <fhrbata@redhat.com> Acked-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
Michel Lespinasse authored
commit 3d3c8f93 upstream. binary_sysctl() calls sysctl_getname() which allocates from names_cache slab usin __getname() The matching function to free the name is __putname(), and not putname() which should be used only to match getname() allocations. This is because when auditing is enabled, putname() calls audit_putname *instead* (not in addition) to __putname(). Then, if a syscall is in progress, audit_putname does not release the name - instead, it expects the name to get released when the syscall completes, but that will happen only if audit_getname() was called previously, i.e. if the name was allocated with getname() rather than the naked __getname(). So, __getname() followed by putname() ends up leaking memory. Signed-off-by:
Michel Lespinasse <walken@google.com> Acked-by:
-
Roland Dreier authored
commit 4af3ce0d upstream. Commit cfcde11c ("IB/mlx4: Use flow counters on IBoE ports") added code that sets elements of counters[] to -1 if no counter is allocated, but then goes ahead and passes every entry to mlx4_counter_free() on shutdown. This is a bad idea, especially if MLX4_DEV_CAP_FLAG_COUNTERS isn't set so there isn't even an underlying bitmap to free from. Tested-by:
Sean Hefty <sean.hefty@intel.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Eugene Surovegin authored
commit 9f57bd4d upstream. per_cpu_ptr_to_phys() incorrectly rounds up its result for non-kmalloc case to the page boundary, which is bogus for any non-page-aligned address. This affects the only in-tree user of this function - sysfs handler for per-cpu 'crash_notes' physical address. The trouble is that the crash_notes per-cpu variable is not page-aligned: crash_notes = 0xc08e8ed4 PER-CPU OFFSET VALUES: CPU 0: 3711f000 CPU 1: 37129000 CPU 2: 37133000 CPU 3: 3713d000 So, the per-cpu addresses are: crash_notes on CPU 0: f7a07ed4 => phys 36b57ed4 crash_notes on CPU 1: f7a11ed4 => phys 36b4ded4 crash_notes on CPU 2: f7a1bed4 => phys 36b43ed4 crash_notes on CPU 3: f7a25ed4 => phys 36b39ed4 However, /sys/devices/system/cpu/cpu*/crash_notes says: /sys/devices/system/cpu/cpu0/crash_notes: 36b57000 /sys/devices/system/cpu/cpu1/crash_notes: 36b4d000 /sys/devices/system/cpu/cpu2/crash_notes: 36b43000 /sys/devices/system/cpu/cpu3/crash_notes: 36b39000 As you can see, all values are rounded down to a page boundary. Consequently, this is where kexec sets up the NOTE segments, and thus where the secondary kernel is looking for them. However, when the first kernel crashes, it saves the notes to the unaligned addresses, where they are not found. Fix it by adding offset_in_page() to the translated page address. -tj: Combined Eugene's and Petr's commit messages. Signed-off-by:
Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
Petr Tesarik <ptesarik@suse.cz> Signed-off-by:
-
Dmitry Torokhov authored
commit 8521478f upstream. Synaptics touchpads on several Dell laptops, particularly Vostro V13 systems, may not respond properly to PS/2 commands and queries immediately after resuming from suspend to RAM. This leads to unresponsive touchpad after suspend/resume cycle. Adding a 1-second delay after resetting the device allows touchpad to finish initializing (calibrating?) and start reacting properly. Reported-by:
Daniel Manrique <daniel.manrique@canonical.com> Tested-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Jason Chen authored
commit c0d96aed upstream. Signed-off-by:
Jason Chen <jason.chen@linaro.org> Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Philipp Dreimann authored
commit 91ddff8a upstream. In drivers rtl8192ce, rtl8192cu, rtl8192se, and rtl8192de, break statements would allow ppsc->rfpwr_state to be changed to ERFSLEEP even though the device is actually in ERFOFF. Signed-off-by:
Philipp Dreimann <philipp@dreimann.net> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Chaoming Li <chaoming_li@realsil.com.cn> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Hauke Mehrtens authored
commit 329456d1 upstream. This fixes a Data bus error on some SoCs. The first fix for this problem did not solve it on all devices. commit 6ae8ec27 Author: Rafał Miłecki <zajec5@gmail.com> Date: Tue Jul 5 17:25:32 2011 +0200 ssb: fix init regression of hostmode PCI core In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is accessed, but the sprom only exists when the ssb bus is connected over a PCI bus to the rest of the system and not when the SSB Bus is the main system bus. SoCs sometimes have a PCI host controller and there this code will not be executed, but there are some old SoCs with an PCI controller in client mode around and ssb_pcicore_fix_sprom_core_index() should not be called on these devices too. The PCI controller on these devices are unused, but without this fix it results in an Data bus error when it gets initialized. Cc: Michael Buesch <m@bues.ch> Cc: Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Mike Snitzer authored
commit 5151412d upstream. struct request_queue is allocated with __GFP_ZERO so its "node" field is zero before initialization. This causes an oops if node 0 is offline in the page allocator because its zonelists are not initialized. From Dave Young's dmesg: SRAT: Node 1 PXM 2 0-d0000000 SRAT: Node 1 PXM 2 100000000-330000000 SRAT: Node 0 PXM 1 330000000-630000000 Initmem setup node 1 0000000000000000-000000000affb000 ... Built 1 zonelists in Node order, mobility grouping on. ... BUG: unable to handle kernel paging request at 0000000000001c08 IP: [<ffffffff8111c355>] __alloc_pages_nodemask+0xb5/0x870 and __alloc_pages_nodemask+0xb5 translates to a NULL pointer on zonelist->_zonerefs. The fix is to initialize q->node at the time of allocation so the correct node is passed to the slab allocator later. Since blk_init_allocated_queue_node() is no longer needed, merge it with blk_init_allocated_queue(). [rientjes@google.com: changelog, initializing q->node] Reported-by:
Dave Young <dyoung@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Mark Brown authored
commit 37d5993c upstream. Record the clock after the divider as that is what all SYSCLK users see. Without this the other clock configuration in the device comes out at half rate. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Johannes Berg authored
commit 15062e6a upstream. Emmanuel noticed that when mac80211 stops the queues for aggregation that can leave a packet pending. This packet will be given to the driver after the AMPDU callback, but as a non-aggregated packet which messes up the sequence number etc. I also noticed by looking at the code that if packets are being processed while we clear the WANT_START bit, they might see it cleared already and queue up on tid_tx->pending. If the driver then rejects the new aggregation session we leak the packet. Fix both of these issues by changing this code to not stop the queues at all. Instead, let packets queue up on the tid_tx->pending queue instead of letting them get to the driver, and add code to recover properly in case the driver rejects the session. (The patch looks large because it has to move two functions to before their new use.) Reported-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Thomas Gleixner authored
commit 7e1e7ead upstream. The error exit path leaks preempt count. Add the missing put_cpu(). Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Yi Zou <yi.zou@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Anton Blanchard authored
commit f6a290b4 upstream. _scsih_smart_predicted_fault is called in an interrupt and therefore must allocate memory using GFP_ATOMIC. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Steffen Maier authored
commit 44f747ff upstream. zfcp_scsi_slave_destroy erroneously always tried to finish its task even if the corresponding previous zfcp_scsi_slave_alloc returned early. This can lead to kernel page faults on accessing uninitialized fields of struct zfcp_scsi_dev in zfcp_erp_lun_shutdown_wait. Take the port field of the struct to determine if slave_alloc returned early. This zfcp bug is exposed by 4e6c82b3 (in turn fixing f7c9c6bb to be compatible with 21208ae5) which can call slave_destroy for a corresponding previous slave_alloc that did not finish. This patch is based on James Bottomley's fix suggestion in http://www.spinics.net/lists/linux-scsi/msg55449.html. Signed-off-by:
Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by:
-
Yasuaki Ishimatsu authored
commit 5eb46851 upstream. cfq_cic_link() has race condition. When some processes which shared ioc issue I/O to same block device simultaneously, cfq_cic_link() returns -EEXIST sometimes. The race condition might stop I/O by following steps: step 1: Process A: Issue an I/O to /dev/sda step 2: Process A: Get an ioc (iocA here) in get_io_context() which does not linked with a cic for the device step 3: Process A: Get a new cic for the device (cicA here) in cfq_alloc_io_context() step 4: Process B: Issue an I/O to /dev/sda step 5: Process B: Get iocA in get_io_context() since process A and B share the same ioc step 6: Process B: Get a new cic for the device (cicB here) in cfq_alloc_io_context() since iocA has not been linked with a cic for the device yet step 7: Process A: Link cicA to iocA in cfq_cic_link() step 8: Process A: Dispatch I/O to driver and finish it step 9: Process B: Try to link cicB to iocA in cfq_cic_link() But it fails with showing "cfq: cic link failed!" kernel message, since iocA has already linked with cicA at step 7. step 10: Process B: Wait for finishig I/O in get_request_wait() The function does not wake up, when there is no I/O to the device. When cfq_cic_link() returns -EEXIST, it means ioc has already linked with cic. So when cfq_cic_link() return -EEXIST, retry cfq_cic_lookup(). Signed-off-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by:
-
majianpeng authored
commit 2984ff38 upstream. If we fail allocating the blkpg stats, we free cfqd and cfgq. But we need to free the IDA cfqd->cic_index as well. Signed-off-by:
majianpeng <majianpeng@gmail.com> Signed-off-by:
-
Eugeni Dodonov authored
commit 4ed0b577 upstream. This prevents an in-kernel division by zero which happens when we are asking for i915_chipset_val too quickly, or within a race condition between the power monitoring thread and userspace accesses via debugfs. The issue can be reproduced easily via the following command: while ``; do cat /sys/kernel/debug/dri/0/i915_emon_status; done This is particularly dangerous because it can be triggered by a non-privileged user by just reading the debugfs entry. This issue was also found independently by Konstantin Belousov <kostikbel@gmail.com>, who proposed a similar patch. Reported-by:
Konstantin Belousov <kostikbel@gmail.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
Paulo Zanoni authored
commit 3573c410 upstream. v2: add a CPT-specific macro, make code cleaner v3: fix commit message Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41272Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
David Henningsson authored
commit 1c89fe3b upstream. For the Asus 1101HA, reporting position by reading the DMA position buffer map seems unstable and often wrong. The reporter says that position_fix=LPIB works much better (although not 100%, but this is probably due to other issues). The controller chip is an Intel Poulsbo 8086:811b (rev 07) controller, and complete alsa-info is available here: https://launchpadlibrarian.net/86691768/alsa-info.txt.1TNwyE5Ea7 BugLink: http://bugs.launchpad.net/bugs/825709 Tested-by: Stefano Lodi Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
John Stultz authored
commit c3b79770 upstream. The m41t80 driver can read and set the alarm, but it doesn't seem to have a functional alarm irq. This causes failures when the generic core sees alarm functions, but then cannot use them properly for things like UIE mode. Disabling the alarm functions allows proper error reporting, and possible fallback to emulated modes. Once someone fixes the alarm irq functionality, this can be restored. CC: Matt Turner <mattst88@gmail.com> CC: Nico Macrionitis <acrux@cruxppc.org> CC: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Reported-by:
Matt Turner <mattst88@gmail.com> Reported-by:
Nico Macrionitis <acrux@cruxppc.org> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Ted Feng authored
commit 72b36015 upstream. Same fix as 731abb9c for ipip and sit tunnel. Commit 1c5cae81 removed an explicit call to dev_alloc_name in ipip_tunnel_locate and ipip6_tunnel_locate, because register_netdevice will now create a valid name, however the tunnel keeps a copy of the name in the private parms structure. Fix this by copying the name back after register_netdevice has successfully returned. This shows up if you do a simple tunnel add, followed by a tunnel show: $ sudo ip tunnel add mode ipip remote 10.2.20.211 $ ip tunnel tunl0: ip/ip remote any local any ttl inherit nopmtudisc tunl%d: ip/ip remote 10.2.20.211 local any ttl inherit $ sudo ip tunnel add mode sit remote 10.2.20.212 $ ip tunnel sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16 sit%d: ioctl 89f8 failed: No such device sit%d: ipv6/ip remote 10.2.20.212 local any ttl inherit Signed-off-by:
Ted Feng <artisdom@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Felipe Contreras authored
commit e5fe29c7 upstream. Commit 10299e2e (ARM: RX-51: Enable isp1704 power on/off) added power management for isp1704. However, the transceiver should be powered on by default, otherwise USB doesn't work at all for networking during boot. All kernels after v3.0 are affected. Signed-off-by:
Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by:
Sebastian Reichel <sre@debian.org> [tony@atomide.com: updated comments] Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
- 03 Jan, 2012 2 commits
-
-
Greg Kroah-Hartman authored
-
Linus Torvalds authored
commit 3b87487a upstream. This reverts commit de28f25e. It results in resume problems for various people. See for example http://thread.gmane.org/gmane.linux.kernel/1233033 http://thread.gmane.org/gmane.linux.kernel/1233389 http://thread.gmane.org/gmane.linux.kernel/1233159 http://thread.gmane.org/gmane.linux.kernel/1227868/focus=1230877 and the fedora and ubuntu bug reports https://bugzilla.redhat.com/show_bug.cgi?id=767248 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569 which got bisected down to the stable version of this commit. Reported-by:
Jonathan Nieder <jrnieder@gmail.com> Reported-by:
Phil Miller <mille121@illinois.edu> Reported-by:
Philip Langdale <philipl@overt.org> Reported-by:
Tim Gardner <tim.gardner@canonical.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 21 Dec, 2011 5 commits
-
-
Greg Kroah-Hartman authored
-
Bjørn Mork authored
commit 02a551c9 upstream. Huawei use the product code HUAWEI_PRODUCT_E353 (0x1506) for a number of different devices, which each can appear with a number of different descriptor sets. Different types of interfaces can be identified by looking at the subclass and protocol fields Subclass 1 protocol 8 is actually the data interface of a CDC ECM set, with subclass 1 protocol 9 as the control interface. Neither support serial data communcation, and cannot therefore be supported by this driver. At the same time, add a few other sets which appear if the device is configured in "Windows mode" using this modeswitch message: 55534243000000000000000000000011060000000100000000000000000000 Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Alex Hermann authored
commit 414b591f upstream. This patch adds the controlling interfaces for the Huawei E398. Thanks to Bjørn Mork <bjorn@mork.no> for extracting the interface numbers from the windows driver. Signed-off-by:
Alex Hermann <alex@wenlex.nl> Signed-off-by:
-
Krzysztof Hałasa authored
commit 6abff5dc upstream. Add USB IDs for Motorola H24 HSPA USB module. Signed-off-by:
Krzysztof Hałasa <khalasa@piap.pl> Acked-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Yinghai Lu authored
commit 935a9fee upstream. Found one system with UEFI/iBFT, kernel does not detect the iBFT during iscsi_ibft module loading. Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier - specifically in setup_arch() before ACPI is enabled. Try to split acpi checking code out and call that later At that time ACPI iBFT already get permanent mapped with ioremap. So isa_virt_to_bus() will get wrong phys from right virt address. We could just skip that phys address printing. For legacy one, print the found address early. -v2: update comments and description according to Konrad. -v3: fix problem about module use case that is found by Konrad. -v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again.. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Konrad Rzeszutek Wilk <konrad@kernel.org> Signed-off-by:
-
