- 02 Aug, 2010 40 commits
-
-
Bob Copeland authored
commit b6855772 upstream. ath5k assumes ah_current_channel is always a valid pointer in several places, but a newly created interface may not have a channel. To avoid null pointer dereferences, set it up to point to the first available channel until later reconfigured. This fixes the following oops: $ rmmod ath5k $ insmod ath5k $ iw phy0 set distance 11000 BUG: unable to handle kernel NULL pointer dereference at 00000006 IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] *pde = 00000000 Oops: 0000 [#1] last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90 scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci 8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc Pid: 1597, comm: iw Not tainted (2.6.32.14 #8) EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0 EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080 ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000) Stack: d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0 <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7 <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000 Call Trace: [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k] [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211] [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211] [<c10f5db9>] ? nla_parse+0x59/0xc0 [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0 [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0 [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90 [<c11c9649>] ? genl_rcv+0x19/0x30 [<c11c7c03>] ? netlink_unicast+0x1b3/0x220 [<c11c893e>] ? netlink_sendmsg+0x26e/0x290 [<c11a409e>] ? sock_sendmsg+0xbe/0xf0 [<c1032780>] ? autoremove_wake_function+0x0/0x50 [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530 [<c1074933>] ? do_lookup+0x53/0x1b0 [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0 [<c11acab0>] ? verify_iovec+0x50/0x90 [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270 [<c1048e50>] ? find_get_page+0x10/0x50 [<c104a96f>] ? filemap_fault+0x5f/0x370 [<c1059159>] ? __do_fault+0x319/0x370 [<c11a55b4>] ? sys_socketcall+0x244/0x290 [<c101962c>] ? do_page_fault+0x1ec/0x270 [<c1019440>] ? do_page_fault+0x0/0x270 [<c1002ae5>] ? syscall_call+0x7/0xb Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24 0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7 43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2 EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP 0068:cfa09bf4 CR2: 0000000000000006 ---[ end trace 54f73d6b10ceb87b ]--- Reported-by:
Steve Brown <sbrown@cortland.com> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
commit 3d61510f upstream. This patch (as1365) enables remote wakeup by default for USB keyboard devices. Keyboards in general are supposed to be wakeup devices, but the correct place to enable it depends on the device's bus; no single approach will work for all keyboard devices. In particular, this covers only USB keyboards (and then only those supporting the boot protocol). Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Bruno Randolf authored
commit 98a0f86a upstream. This patch fixes a regression introduced by commit "MIPS: Alchemy: MTX-1: Use linux gpio api." (bb706b28 ) which broke PCI bus operation. The problem is caused by alchemy_gpio2_enable() which resets the GPIO2 block. Two PCI signals (PCI_SERR and PCI_RST) are connected to GPIO2 and they obviously do not to like the reset. Since GPIO2 is correctly initialized by the boot monitor (YAMON) it is not necessary to call this function, so just remove it. Also replace gpio_set_value() with alchemy_gpio_set_value() to avoid problems in case gpiolib gets initialized after PCI. And since alchemy gpio_set_value() calls au_sync() we don't have to au_sync() again later. Signed-off-by:
Bruno Randolf <br1@einfach.org> To: linux-mips@linux-mips.org To: manuel.lauss@googlemail.com Patchwork: https://patchwork.linux-mips.org/patch/1448/ Tested-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dominik Brodowski authored
commit e4f1ac21 upstream. The "present" flag was initialized too late -- possibly, a card was already registered at this time, so re-setting the flag to 0 caused pcmcia_dev_present() to fail. Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andre Osterhues authored
commit a6f80fb7 upstream. The function ecryptfs_uid_hash wrongly assumes that the second parameter to hash_long() is the number of hash buckets instead of the number of hash bits. This patch fixes that and renames the variable ecryptfs_hash_buckets to ecryptfs_hash_bits to make it clearer. Fixes: CVE-2010-2492 Signed-off-by:
Andre Osterhues <aosterhues@escrypt.com> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tony Luck authored
commit b70f4e85 upstream. Typo in down_spin() meant it only read the low 32 bits of the "serve" value, instead of the full 64 bits. This results in the system hanging when the values in ticket/serve get larger than 32-bits. A big enough system running the right test can hit this in a just a few hours. Broken since 883a3acf [IA64] Re-implement spinaphores using ticket lock concepts Reported via IRC by Bjorn Helgaas Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rafael J. Wysocki authored
commit 9d3c752d upstream. The sysfs interface allowing user space to disable/enable GPEs doesn't work correctly, because a GPE disabled this way will be re-enabled shortly by acpi_ev_asynch_enable_gpe() if it was previosuly enabled by acpi_enable_gpe() (in which case the corresponding bit in its enable register's enable_for_run mask is set). To address this issue make the sysfs GPE interface use acpi_enable_gpe() and acpi_disable_gpe() instead of acpi_set_gpe() so that GPE reference counters are modified by it along with the values of GPE enable registers. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rafael J. Wysocki authored
commit ce43ace0 upstream. While developing the GPE reference counting code we overlooked the fact that acpi_ev_update_gpes() could have enabled GPEs before acpi_ev_initialize_gpe_block() was called. As a result, some GPEs are enabled twice during the initialization. To fix this issue avoid calling acpi_enable_gpe() from acpi_ev_initialize_gpe_block() for the GPEs that have nonzero runtime reference counters. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Len Brown <len.brown@intel.com>
-
Rafael J. Wysocki authored
commit c9a8bbb7 upstream. ACPICA uses acpi_hw_write_gpe_enable_reg() to re-enable a GPE after an event signaled by it has been handled. However, this function writes the entire GPE enable mask to the GPE's enable register which may not be correct. Namely, if one of the other GPEs in the same register was previously enabled by acpi_enable_gpe() and subsequently disabled using acpi_set_gpe(), acpi_hw_write_gpe_enable_reg() will re-enable it along with the target GPE. To fix this issue rework acpi_hw_write_gpe_enable_reg() so that it calls acpi_hw_low_set_gpe() with a special action value, ACPI_GPE_COND_ENABLE, that will make it only enable the GPE if the corresponding bit in its register's enable_for_run mask is set. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rafael J. Wysocki authored
commit fd247447 upstream. ACPICA uses acpi_ev_enable_gpe() for enabling GPEs at the low level, which is incorrect, because this function only enables the GPE if the corresponding bit in its enable register's enable_for_run mask is set. This causes acpi_set_gpe() to work incorrectly if used for enabling GPEs that were not previously enabled with acpi_enable_gpe(). As a result, among other things, wakeup-only GPEs are never enabled by acpi_enable_wakeup_device(), so the devices that use them are unable to wake up the system. To fix this issue remove acpi_ev_enable_gpe() and its counterpart acpi_ev_disable_gpe() and replace acpi_hw_low_disable_gpe() with acpi_hw_low_set_gpe() that will be used instead to manipulate GPE enable bits at the low level. Make the users of acpi_ev_enable_gpe() and acpi_ev_disable_gpe() call acpi_hw_low_set_gpe() instead and make sure that GPE enable masks are only updated by acpi_enable_gpe() and acpi_disable_gpe() when GPE reference counters change from 0 to 1 and from 1 to 0, respectively. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rafael J. Wysocki authored
commit e4e9a735 upstream. In quite a few places ACPICA needs to compute a GPE enable mask with only one bit, corresponding to a given GPE, set. Currently, that computation is always open coded which leads to unnecessary code duplication. Fix this by introducing a helper function for computing one-bit GPE enable masks and using it where appropriate. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Krzysztof Halasa authored
commit 1c938663 upstream. Alan <alan@clueserver.org> writes: > program: /home/alan/GitTrees/linux-2.6-mid-ref/scripts/mod/modpost -o > Module.symvers -S vmlinux.o > > Program received signal SIGSEGV, Segmentation fault. It just hit me. It's the offset calculation in reloc_location() which overflows: return (void *)elf->hdr + sechdrs[section].sh_offset + (r->r_offset - sechdrs[section].sh_addr); E.g. for the first rodata r entry: r->r_offset < sechdrs[section].sh_addr and the expression in the parenthesis produces 0xFFFFFFE0 or something equally wise. Reported-by:
Alan <alan@clueserver.org> Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl> Tested-by:
Alan <alan@clueserver.org> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Reinette Chatre authored
commit a6866ac9 upstream. We learn from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and https://bugzilla.redhat.com/show_bug.cgi?id=589777 that 3945 can also suffer from a stuck command queue. Enable stuck queue detection for iwl3945 to enable recovery in this case. Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wey-Yi Guy authored
commit b74e31a9 upstream. Monitors the internal TX queues periodically. When a queue is stuck for some unknown conditions causing the throughput to drop and the transfer is stop, the driver will force firmware reload and bring the system back to normal operational state. The iwlwifi devices behave differently in this regard so this feature is made part of the ops infrastructure so we can have more control on how to monitor and recover from tx queue stall case per device. Signed-off-by:
Trieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Shanyu Zhao authored
commit b561e827 upstream. The flow id (scd_flow) in a compressed BA packet should match the txq_id of the queue from which the aggregated packets were sent. However, in some hardware like the 1000 series, sometimes the flow id is 0 for the txq_id (10 to 19). This can cause the annoying message: [ 2213.306191] iwlagn 0000:01:00.0: Received BA when not expected [ 2213.310178] iwlagn 0000:01:00.0: Read index for DMA queue txq id (0), index 5, is out of range [0-256] 7 7. And even worse, if agg->wait_for_ba is true when the bad BA is arriving, this can cause system hang due to NULL pointer dereference because the code is operating in a wrong tx queue! Signed-off-by:
Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by:
Pradeep Kulkarni <pradeepx.kulkarni@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tao Ma authored
commit 1b99973f upstream. In submit_bio, we count vm events by check READ/WRITE. But actually DISCARD_NOBARRIER also has the WRITE flag set. It looks as if in blkdev_issue_discard, we also add a page as the payload and the bio_has_data check isn't enough. So add another check for discard bio. Signed-off-by:
Tao Ma <tao.ma@oracle.com> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Laurent Pinchart authored
commit 61421206 upstream. The Miricle 307K (17dc:0202) camera reports a 16-bit greyscale format, support it in the driver. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Laurent Pinchart authored
commit f129b03b upstream. The camera requires the STREAM_NO_FID quirk. Add a corresponding entry in the device IDs list. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Laurent Pinchart authored
commit 1e4d05bc upstream. The camera requires the PROBE_DEF quirk. Add a corresponding entry in the device IDs list. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Rosenberg authored
commit 1817176a upstream. This patch prevents user "foo" from using the SWAPEXT ioctl to swap a write-only file owned by user "bar" into a file owned by "foo" and subsequently reading it. It does so by checking that the file descriptors passed to the ioctl are also opened for reading. Signed-off-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Chan authored
commit f048fa9c upstream. The regression is caused by: commit 4327ba43 bnx2: Fix netpoll crash. If ->open() and ->close() are called multiple times, the same napi structs will be added to dev->napi_list multiple times, corrupting the dev->napi_list. This causes free_netdev() to hang during rmmod. We fix this by calling netif_napi_del() during ->close(). Also, bnx2_init_napi() must not be in the __devinit section since it is called by ->open(). Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
Benjamin Li <benli@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stanislaw Gruszka authored
commit 76f27364 upstream. If AP do not provide us supported rates before assiociation, send all rates we are supporting instead of empty information element. v1 -> v2: Add comment. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Hutchings authored
commit b0cf4dfb upstream. The driver attempts to select an IRQ for the NIC automatically by testing which of the supported IRQs are available and then probing each available IRQ with probe_irq_{on,off}(). There are obvious race conditions here, besides which: 1. The test for availability is done by passing a NULL handler, which now always returns -EINVAL, thus the device cannot be opened: <http://bugs.debian.org/566522> 2. probe_irq_off() will report only the first ISA IRQ handled, potentially leading to a false negative. There was another bug that meant it ignored all error codes from request_irq() except -EBUSY, so it would 'succeed' despite this (possibly causing conflicts with other ISA devices). This was fixed by ab08999d 'WARNING: some request_irq() failures ignored in el2_open()', which exposed bug 1. This patch: 1. Replaces the use of probe_irq_{on,off}() with a real interrupt handler 2. Adds a delay before checking the interrupt-seen flag 3. Disables interrupts on all failure paths 4. Distinguishes error codes from the second request_irq() call, consistently with the first Compile-tested only. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Hutchings authored
commit d46b36e7 upstream. Update the Kconfig selections to match the code. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
commit 806b07c2 upstream. IR support on FusionHDTV cards is broken since kernel 2.6.31. One side effect of the switch to the standard binding model for IR I2C devices was to let i2c-core do the probing instead of the ir-kbd-i2c driver. There is a slight difference between the two probe methods: i2c-core uses 0-byte writes, while the ir-kbd-i2c was using 0-byte reads. As some IR I2C devices only support reads, the new probe method fails to detect them. For now, revert to letting the driver do the probe, using 0-byte reads. In the future, i2c-core will be extended to let callers of i2c_new_probed_device() provide a custom probing function. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
"Timothy D. Lenz" <tlenz@vorgon.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ang Way Chuang authored
commit 5c331fc8 upstream. Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. Signed-off-by:
Ang Way Chuang <wcang@nav6.org> Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andrej Gelenberg authored
commit accd8466 upstream. 395913d0 ("[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)") is not needed, because there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative anymore. Lock should not be released until the work done. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=1594 Signed-off-by:
Andrej Gelenberg <andrej.gelenberg@udo.edu> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Woodhouse authored
commit dd336c55 upstream. fix memory leak introduced by the patch 6e03a201 : firmware: speed up request_firmware() 1. vfree won't release pages there were allocated explicitly and mapped using vmap. The memory has to be vunmap-ed and the pages needs to be freed explicitly 2. page array is moved into the 'struct firmware' so that we can free it from release_firmware() and not only in fw_dev_release() The fix doesn't break the firmware load speed. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Singed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wolfram Sang authored
commit 28ade0f2 upstream. Unlike real i2c-devices which get detached from the driver, dummy-devices get truly unregistered. So, there has never been a need to clear the clientdata because the device will go away anyhow. For the occasions fixed here, clearing clientdata was even dangerous as the structure was freed already. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Baruch Siach authored
commit 380fefb2 upstream. dm9000_set_rx_csum and dm9000_hash_table are called from atomic context (in dm9000_init_dm9000), and from non-atomic context (via ethtool_ops and net_device_ops respectively). This causes a spinlock recursion BUG. Fix this by renaming these functions to *_unlocked for the atomic context, and make the original functions locking wrappers for use in the non-atomic context. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel Mack authored
commit 8a64c0f6 upstream. When operating in 1-bit mode, SDAT1 is used as dedicated interrupt line. However, the 8686 will only drive this line when the ECSI bit is set in the CCCR_IF register. Thanks to Alagu Sankar for pointing me in the right direction. Signed-off-by:
Daniel Mack <daniel@caiaq.de> Cc: Alagu Sankar <alagusankar@embwise.com> Cc: Volker Ernst <volker.ernst@txtr.com> Cc: Dan Williams <dcbw@redhat.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Holger Schurig <hs4233@mail.mn-solutions.de> Cc: Bing Zhao <bzhao@marvell.com> Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@vger.kernel.org Cc: linux-mmc@vger.kernel.org Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Matthew Garrett authored
commit b6dacf63 upstream. The ACPI spec tells us that the firmware will reenable SCI_EN on resume. Reality disagrees in some cases. The ACPI spec tells us that the only way to set SCI_EN is via an SMM call. https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so may break machines. Tracing the ACPI calls made by Windows shows that it unconditionally sets SCI_EN on resume with a direct register write, and therefore the overwhelming probability is that everything is fine with this behaviour. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Tested-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rafael J. Wysocki authored
commit cb1cb178 upstream. After commit 9630bdd9 (ACPI: Use GPE reference counting to support shared GPEs) the wakeup enable mask bits of GPEs are set as soon as the GPEs are enabled to wake up the system. Unfortunately, this leads to a regression reported by Michal Hocko, where a system is woken up from ACPI S5 by a device that is not supposed to do that, because the wakeup enable mask bit of this device's GPE is always set when acpi_enter_sleep_state() calls acpi_hw_enable_all_wakeup_gpes(), although it should only be set if the device is supposed to wake up the system from the target state. To work around this issue, rework the ACPI power management code so that GPEs are not enabled to wake up the system upfront, but only during a system state transition when the target state of the system is known. [Of course, this means that the reference counting of "wakeup" GPEs doesn't really make sense and it is sufficient to set/unset the wakeup mask bits for them during system sleep transitions. This will allow us to simplify the GPE handling code quite a bit, but that change is too intrusive for 2.6.35.] Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15951 Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by:
Michal Hocko <mhocko@suse.cz> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Len Brown authored
commit 718be4aa upstream. It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not. Linux has been unconditionally checking BM_STS. If the chip-set is configured to enable BM_STS, it can retard or completely prevent entry into deep C-states -- as illustrated by turbostat: http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/ ref: Intel Processor Vendor-Specific ACPI Interface Specification table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state https://bugzilla.kernel.org/show_bug.cgi?id=15886 Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tilman Schmidt authored
commit 1b4843c5 upstream. CAPI applications can handle several connections in parallel, so one connection state per application isn't sufficient. Store the connection state in the channel structure instead. Impact: bugfix Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tilman Schmidt authored
commit 1ce368ff upstream. Adapt to buggy device firmware which accepts setting HLC only in the same command line as BC, by encoding HLC and BC in a single command if both are specified, and rejecting HLC without BC. Impact: bugfix Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tilman Schmidt authored
commit 23b36778 upstream. The Gigaset CAPI driver handled all DATA_B3_REQ messages as if the Delivery Confirmation flag bit was set, delaying the emission of the DATA_B3_CONF reply until the data was actually transmitted. Some CAPI applications (notably Asterisk) aren't happy with that behaviour. Change it to actually evaluate the Delivery Confirmation flag as described the CAPI specification. Impact: bugfix Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tilman Schmidt authored
commit 278a5829 upstream. Make the Gigaset CAPI driver select L2_VOICE (AT^SBPR=2) as the layer 2 encoding for transparent connections, like the ISDN4Linux variant. L2_BITSYNC (AT^SBPR=0) mutes internal connections and distorts external ones. Impact: bugfix Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tilman Schmidt authored
commit e7752ee2 upstream. Fix the Gigaset CAPI driver to limit the length of a connection's payload data receive buffers to the corresponding CAPI application's data buffer size, as some real-life CAPI applications tend to be rather unhappy if they receive bigger data blocks than requested. Impact: bugfix Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tilman Schmidt authored
commit e487639d upstream. Dummy implementations for the optional CAPI controller operations load_firmware and reset_ctr can cause userspace callers to hang indefinitely. It's better not to implement them at all. Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Acked-by:
Karsten Keil <isdn@linux-pingi.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-