- Nov 20, 2008
-
-
Greg Kroah-Hartman authored
-
Alexey Starikovskiy authored
commit 8517934e upstream. Referencies: http://bugzilla.kernel.org/show_bug.cgi?id=12004 Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alexey Starikovskiy authored
commit 06cf7d3c upstream. http://bugzilla.kernel.org/show_bug.cgi?id=11892 Signed-off-by:
-
Alexey Starikovskiy authored
commit a2f93aea upstream. Restart current transaction if we recieved unexpected GPEs instead of needed ones. http://bugzilla.kernel.org/show_bug.cgi?id=11896 Signed-off-by:
-
Alexey Starikovskiy authored
commit dd15f8c4 upstream. There is a possibility that EC might break if next command is issued within 1 us after write or burst-disable command. Suggestd-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
-
Alexey Starikovskiy authored
commit 1cfe62c8 upstream. With the better solution for EC interrupt storm issue, there is no need to use msleep over udelay. References: http://bugzilla.kernel.org/show_bug.cgi?id=11810 http://bugzilla.kernel.org/show_bug.cgi?id=10724 Signed-off-by:
-
Alan Stern authored
commit 352d0263 upstream. This patch (as1155) fixes a bug in usbcore. When interfaces are deleted, either because the device was disconnected or because of a configuration change, the extra attribute files and child endpoint devices may get left behind. This is because the core removes them before calling device_del(). But during device_del(), after the driver is unbound the core will reinstall altsetting 0 and recreate those extra attributes and children. The patch prevents this by adding a flag to record when the interface is in the midst of being unregistered. When the flag is set, the attribute files and child devices will not be created. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 67b2e029 upstream. This patch (as1165) makes a few small changes in the logic used by ehci-hcd when it encounters a controller error: Instead of printing out the masked status, it prints the original status as read directly from the hardware. It doesn't check for the STS_HALT status bit before taking action. The mere fact that the STS_FATAL bit is set means that something bad has happened and the controller needs to be reset. With the old code this test could never succeed because the STS_HALT bit was masked out from the status. I anticipate that this will prevent the occasional "irq X: nobody cared" problem people encounter when their EHCI controllers die. Signed-off-by:
-
Alan Stern authored
commit 372dd6e8 upstream. This patch (as1164) fixes a bug in the EHCI scheduler. The interval value it uses is already in linear format, not logarithmically coded. The existing code can sometimes crash the system by trying to divide by zero. Signed-off-by:
-
Brandon Philips authored
commit ad0b65ef upstream. Fixes an obvious bug in cdc-acm by avoiding a recursive lock on acm_start_wb()'s error path. Should apply towards 2.6.27 stable and 2.6.28. ============================================= [ INFO: possible recursive locking detected ] 2.6.27-2-pae #109 --------------------------------------------- python/31449 is trying to acquire lock: (&acm->write_lock){++..}, at: [<f89a0348>] acm_start_wb+0x5c/0x7b [cdc_acm] but task is already holding lock: (&acm->write_lock){++..}, at: [<f89a04fb>] acm_tty_write+0xe1/0x167 [cdc_acm] other info that might help us debug this: 2 locks held by python/31449: #0: (&tty->atomic_write_lock){--..}, at: [<c0260fae>] tty_write_lock+0x14/0x3b #1: (&acm->write_lock){++..}, at: [<f89a04fb>] acm_tty_write+0xe1/0x167 [cdc_acm] stack backtrace: Pid: 31449, comm: python Not tainted 2.6.27-2-pae #109 [<c030f42f>] ? printk+0xf/0x18 [<c0149f33>] __lock_acquire+0xc7b/0x1316 [<c014a63e>] lock_acquire+0x70/0x97 [<f89a0348>] ? acm_start_wb+0x5c/0x7b [cdc_acm] [<c0312109>] _spin_lock_irqsave+0x37/0x47 [<f89a0348>] ? acm_start_wb+0x5c/0x7b [cdc_acm] [<f89a0348>] acm_start_wb+0x5c/0x7b [cdc_acm] [<f89a055d>] acm_tty_write+0x143/0x167 [cdc_acm] [<c0262a98>] write_chan+0x1cd/0x297 [<c012527e>] ? default_wake_function+0x0/0xd [<c026111e>] tty_write+0x149/0x1b9 [<c02628cb>] ? write_chan+0x0/0x297 [<c01912c5>] ? rw_verify_area+0x76/0x98 [<c0260fd5>] ? tty_write+0x0/0x1b9 [<c01919ba>] vfs_write+0x8c/0x136 [<c0191afd>] sys_write+0x3b/0x60 [<c0103beb>] sysenter_do_call+0x12/0x3f ======================= Signed-off-by:
Brandon Philips <bphilips@suse.de> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Geoff Levand authored
commit ddcb01ff upstream. Add ehci_shutdown() or ohci_shutdown() calls to the USB PS3 bus glue. ehci_shutdown() and ohci_shutdown() do some controller specific cleanups not done by usb_remove_hcd(). Fixes errors on shutdown or reboot similar to these: ps3-ehci-driver sb_07: HC died; cleaning up irq 51: nobody cared (try booting with the "irqpoll" option) Related bugzilla reports: http://bugzilla.kernel.org/show_bug.cgi?id=11819 http://bugzilla.terrasoftsolutions.com/show_bug.cgi?id=317 Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by:
-
Alan Stern authored
commit 8010e06c upstream. This patch (as1162) adds an unusual_devs entry for Argosy's USB-IDE interface. This fixes Bugzilla #11843. Signed-off-by:
Luciano Rocha <luciano@eurotux.com> Signed-off-by:
-
David Brownell authored
commit e50ae572 upstream. This fixes a deadlock appearing with some USB peripheral drivers when running CDC ACM gadget code. The newish (2.6.27) CDC ACM event notification mechanism sends messages (IN to the host) which are short enough to fit in most FIFOs. That means that with some peripheral controller drivers (evidently not the ones used to verify the notification code!!) the completion callback can be issued before queue() returns. The deadlock would come because the completion callback and the event-issuing code shared a spinlock. Fix is trivial: drop that lock while queueing the message. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit ff30bf1c upstream. Roland Reported the following: | kmem_cache_create: duplicate cache isp1760_qtd | Pid: 461, comm: modprobe Tainted: G W 2.6.28-rc2-git3-default #4 | Call Trace: | [<c017540e>] kmem_cache_create+0xc9/0x3a3 | [<c0159a8d>] free_pages_bulk+0x16c/0x1c9 | [<f165c05f>] isp1760_init+0x0/0xb [isp1760] | [<f165c018>] init_kmem_once+0x18/0x5f [isp1760] | [<f165c064>] isp1760_init+0x5/0xb [isp1760] | [<c010113d>] _stext+0x4d/0x148 | [<c0142936>] load_module+0x12cd/0x142e | [<c01743c4>] kmem_cache_destroy+0x0/0xd7 | [<c0142b1e>] sys_init_module+0x87/0x176 | [<c01039eb>] sysenter_do_call+0x12/0x2f The reason, is that ret is initialized with ENODEV instead of 0 _or_ the kmem cache is not freed in error case with no bus binding. The difference between OF+PCI and OF only is | 15148 804 32 15984 3e70 isp1760-of-pci.o | 13748 676 8 14432 3860 isp1760-of.o about 1.5 KiB. Until there is a checkbox where the user *must* select atleast one item, and may select multiple entries I don't make it selectable anymore. Having a driver which can't be used under any circumstances is broken anyway and I've seen distros shipping it that way. Reported-by:
Roland Kletzing <devzero@web.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Mikulas Patocka authored
commit 18776c73 upstream. We queue work on keventd queue --- so this queue must be flushed in the destructor. Otherwise, keventd could access mirror_set after it was freed. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Miquel van Smoorenburg authored
commit df81d237 upstream. dpt_i2o.c::adpt_i2o_to_scsi() reads the value at (reply+5) which should contain the length in bytes of the transferred data. This would be correct if reply was a u32 *. However it is a void * here, so we need to read the value at (reply+20) instead. The value at (reply+5) is usually 0xff0000, which is apparently 'large enough' and didn't cause any trouble until 2.6.27 where commit 427e59f0 Author: James Bottomley <James.Bottomley@HansenPartnership.com> Date: Sat Mar 8 18:24:17 2008 -0600 [SCSI] make use of the residue value caused this to become visible through e.g. iostat -x . Signed-off-by:
Miquel van Smoorenburg <mikevs@xs4all.net> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Lalit Chandivade authored
commit 821b3996 upstream. Use correct block size (4K) for erase command 0x20 for Atmel Flash. Use dword addresses for determining sector boundary. Signed-off-by:
Lalit Chandivade <lalit.chandivade@qlogic.com> Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Shyam Sundar authored
commit 680d7db8 upstream. For 23XX ISPs, max_vports may return an invalid value. Do not honour it. Signed-off-by:
-
Michael Reed authored
commit 5bff55db upstream. Mike Reed noted (https://bugzilla.novell.com/show_bug.cgi?id=421330 ) that the driver was incorrectly returning a SUCCESS status if the driver's request to the firmware to abort a command failed. By doing so, the mid-layer believed, incorrectly, that the command has completed and has been returned (ultimately clearing scsi_cmnd.request_buffer) yet the driver still has the command. What should correctly happen is a mid-layer escalation (device-reset, etc.) of recovery during which the driver will eventually return the outstanding commands to the mid-layer. Signed-off-by:
-
Geert Uytterhoeven authored
commit 27123cbc upstream. commit 69961c37 ("[PATCH] m68k/Atari: Interrupt updates") added a BUG_ON() with an incorrect upper bound comparison, which causes an early crash on VME boards, where IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. Reported-by:
Stephen N Chivers <schivers@csc.com.au> Tested-by:
Kars de Jong <jongk@linux-m68k.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Zhao Yakui authored
commit 39a0ad87 upstream. According to ACPI spec when the status of some device is not present but functional, the device is valid and the children of this device should be enumerated. It means that the device should be added to linux acpi device tree. But the device driver for this device should not be loaded. The detailed info can be found in the section 6.3.7 of ACPI 3.0b spec. _STA may return bit 0 clear (not present) with bit 3 set (device is functional). This case is used to indicate a valid device for which no device driver should be loaded (for example, a bridge device.). Children of this device may be present and valid. OS should continue enumeration below a device whose _STA returns this bit combination http://bugzilla.kernel.org/show_bug.cgi?id=3358 Signed-off-by:
Li Shaohua <shaohua.li@intel.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Heiko Carstens authored
commit 74af2831 upstream. cpu_coregroup_map used to grab a mutex on s390 since it was only called from process context. Since c7c22e4d "block: add support for IO CPU affinity" this is not true anymore. It now also gets called from softirq context. To prevent possible deadlocks change this in architecture code and use a spinlock instead of a mutex. Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 01a1a3cc upstream. This bug were supposed to be fixed by 5ba2f67a, where a call to NULL happens. Not all tvaudio chips allow controlling bass/treble. So, the driver has a table with a flag to indicate if the chip does support it. Unfortunately, the handling of this logic were broken for a very long time (probably since the first module version). Due to that, an OOPS were generated for devices that don't support bass/treble. This were the resulting OOPS message before the patch, with debug messages enabled: tvaudio' 1-005b: VIDIOC_S_CTRL BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<00000000>] *pde = 22fda067 *pte = 00000000 Oops: 0000 [#1] SMP Modules linked in: snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_hwdep snd soundcore tuner_simple tuner_types tea5767 tuner tvaudio bttv bridgebnep rfcomm l2cap bluetooth it87 hwmon_vid hwmon fuse sunrpc ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 dm_mirrordm_multipath dm_mod configfs videodev v4l1_compat ir_common 8139cp compat_ioctl32 v4l2_common 8139too videobuf_dma_sg videobuf_core mii btcx_risc tveeprom i915 button snd_page_alloc serio_raw drm pcspkr i2c_algo_bit i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support sr_mod cdrom sg ata_generic pata_acpi ata_piix libata sd_mod scsi_mod ext3 jbdmbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: soundcore] Pid: 15413, comm: qv4l2 Not tainted (2.6.25.14-108.fc9.i686 #1) EIP: 0060:[<00000000>] EFLAGS: 00210246 CPU: 0 EIP is at 0x0 EAX: 00008000 EBX: ebd21600 ECX: e2fd9ec4 EDX: 00200046 ESI: f8c0f0c4 EDI: f8c0f0c4 EBP: e2fd9d50 ESP: e2fd9d2c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process qv4l2 (pid: 15413, ti=e2fd9000 task=ebe44000 task.ti=e2fd9000) Stack: f8c0c6ae e2ff2a00 00000d00 e2fd9ec4 ebc4e000 e2fd9d5c f8c0c448 00000000 f899c12a e2fd9d5c f899c154 e2fd9d68 e2fd9d80 c0560185 e2fd9d88 f8f3e1d8 f8f3e1dc ebc4e034 f8f3e18c e2fd9ec4 00000000 e2fd9d90 f899c286 c008561c Call Trace: [<f8c0c6ae>] ? chip_command+0x266/0x4b6 [tvaudio] [<f8c0c448>] ? chip_command+0x0/0x4b6 [tvaudio] [<f899c12a>] ? i2c_cmd+0x0/0x2f [i2c_core] [<f899c154>] ? i2c_cmd+0x2a/0x2f [i2c_core] [<c0560185>] ? device_for_each_child+0x21/0x49 [<f899c286>] ? i2c_clients_command+0x1c/0x1e [i2c_core] [<f8f283d8>] ? bttv_call_i2c_clients+0x14/0x16 [bttv] [<f8f23601>] ? bttv_s_ctrl+0x1bc/0x313 [bttv] [<f8f23445>] ? bttv_s_ctrl+0x0/0x313 [bttv] [<f8b6096d>] ? __video_do_ioctl+0x1f84/0x3726 [videodev] [<c05abb4e>] ? sock_aio_write+0x100/0x10d [<c041b23e>] ? kmap_atomic_prot+0x1dd/0x1df [<c043a0c9>] ? enqueue_hrtimer+0xc2/0xcd [<c04f4fa4>] ? copy_from_user+0x39/0x121 [<f8b622b9>] ? __video_ioctl2+0x1aa/0x24a [videodev] [<c04054fd>] ? do_notify_resume+0x768/0x795 [<c043c0f7>] ? getnstimeofday+0x34/0xd1 [<c0437b77>] ? autoremove_wake_function+0x0/0x33 [<f8b62368>] ? video_ioctl2+0xf/0x13 [videodev] [<c048c6f0>] ? vfs_ioctl+0x50/0x69 [<c048c942>] ? do_vfs_ioctl+0x239/0x24c [<c048c995>] ? sys_ioctl+0x40/0x5b [<c0405bf2>] ? syscall_call+0x7/0xb [<c0620000>] ? cpuid4_cache_sysfs_exit+0x3d/0x69 ======================= Code: Bad EIP value. EIP: [<00000000>] 0x0 SS:ESP 0068:e2fd9d2c Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Al Viro authored
commit 5c06fe77 upstream. D'oh... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Reported-and-tested-by:
Peter Palfrader <peter@palfrader.org> Signed-off-by:
-
Eric Dumazet authored
commit b971e7ac upstream. icmpmsg_put() can happily corrupt kernel memory, using a static table and forgetting to reset an array index in a loop. Remove the static array since its not safe without proper locking. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Matthew Garrett authored
commit 6158d3a2 upstream. At least the Vaio VGN-Z540N doesn't have this method, so let's not fail to suspend just because it doesn't exist. Signed-off-by:
Adam Jackson <ajax@redhat.com> Acked-by:
Mattia Dongili <malattia@linux.it> Cc: Len Brown <lenb@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Francois Romieu authored
commit b7372492 upstream. drivers/built-in.o: In function `rtl8169_gset_xmii': r8169.c:(.text+0x82259): undefined reference to `mii_ethtool_gset' Signed-off-by:
Hugh Dickins <hugh@veritas.com> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Gerald Schaefer authored
commit a70dcb96 upstream. My last bugfix here (adding zone->lock) introduced a new problem: Using page_zone(pfn_to_page(pfn)) to get the zone after the for() loop is wrong. pfn will then be >= end_pfn, which may be in a different zone or not present at all. This may lead to an addressing exception in page_zone() or spin_lock_irqsave(). Now I use __first_valid_page() again after the loop to find a valid page for page_zone(). Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Acked-by:
Nathan Fontenot <nfont@austin.ibm.com> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Elvis Pranskevichus authored
commit 0d46ed1c upstream. Signed-off-by:
Elvis Pranskevichus <el@prans.net> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Kumar Gala authored
commit 3c10c9c4 upstream. The Freescale implementation of MPIC only allows a single CPU destination for non-IPI interrupts. We add a flag to the mpic_init to distinquish these variants of MPIC. We pull in the irq_choose_cpu from sparc64 to select a single CPU as the destination of the interrupt. This is to deal with the fact that the default smp affinity was changed by commit 18404756 ("genirq: Expose default irq affinity mask (take 3)") to be all CPUs. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
FUJITA Tomonori authored
commit 86771427 upstream backported by Nikanth Karthikesan <knikanth@suse.de> to the 2.6.27.y tree. block: fix nr_phys_segments miscalculation bug This fixes the bug reported by Nikanth Karthikesan <knikanth@suse.de>: http://lkml.org/lkml/2008/10/2/203 The root cause of the bug is that blk_phys_contig_segment miscalculates q->max_segment_size. blk_phys_contig_segment checks: req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size But blk_recalc_rq_segments might expect that req->biotail and the previous bio in the req are supposed be merged into one segment. blk_recalc_rq_segments might also expect that next_req->bio and the next bio in the next_req are supposed be merged into one segment. In such case, we merge two requests that can't be merged here. Later, blk_rq_map_sg gives more segments than it should. We need to keep track of segment size in blk_recalc_rq_segments and use it to see if two requests can be merged. This patch implements it in the similar way that we used to do for hw merging (virtual merging). Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Cc: Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
-
Jonathan McDowell authored
commit bf1b3644 upstream. The below is a simplistic fix for "make deb-pkg"; it splits the firmware out to a linux-firmware-image package and adds an (unversioned) Suggests to the linux package for this firmware. Signed-Off-By:
Jonathan McDowell <noodles@earth.li> Acked-by:
Frans Pop <elendil@planet.nl> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Bob Jolliffe authored
commit f3c76918 upstream. the Sitecom 0001 v4 with product id 0x0df6:0028, uses Realtek's RTL8187B and work fine with new 2.6.27 driver. Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Ivan Kuten authored
commit 8f7c41d4 upstream. Signed-off-by:
Ivan Kuten <ivan.kuten@promwad.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Adam Litke authored
commit 7526674d upstream. Oops. Part of the hugetlb private reservation code was not fully converted to use hstates. When a huge page must be unmapped from VMAs due to a failed COW, HPAGE_SIZE is used in the call to unmap_hugepage_range() regardless of the page size being used. This works if the VMA is using the default huge page size. Otherwise we might unmap too much, too little, or trigger a BUG_ON. Rare but serious -- fix it. Signed-off-by:
Adam Litke <agl@us.ibm.com> Cc: Jon Tollefson <kniht@linux.vnet.ibm.com> Cc: Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
Alan Jenkins authored
commit f8248434 upstream. Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards. http://bugzilla.kernel.org/show_bug.cgi?id=11841 "plenty of line "ACPI: EC: non-query interrupt received, switching to interrupt mode" in dmesg" Signed-off-by:
Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by:
-
Peter Gruber authored
commit 4feba70a upstream. Since commit bc45b1d3 acpi tables are allowed to have an empty signature and /sys/firmware/acpi/tables uses the signature as filename. Applications using naive recursion through /sys loop forever. A possible solution would be: (replacing the zero length filename with the string "NULL") http://bugzilla.kernel.org/show_bug.cgi?id=11539 Acked-by:
-
Johannes Berg authored
commit f7cd1686 upstream. Like mac80211 did, this driver makes 'clever' use of skb->cb to pass information along with an skb as it is requeued from the virtual device to the physical wireless device. Unfortunately, that trick no longer works... Unlike mac80211, code complexity and driver apathy makes this hack the best option we have in the short run. Hopefully someone will eventually be motivated to code a proper fix before all the effected hardware dies. (Above text by me. Johannes officially disavows all knowledge of this hack. -- JWL) Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Darrick J. Wong authored
commit fe2d5ffc upstream. It turns out that if one registers a struct platform_device, the platform device code expects that platform_device.device->driver points to a struct driver inside a struct platform_driver. This is not the case with the ipmi-si, ipmi-msghandler and ibmaem drivers, which causes the suspend/resume hook functions to jump off into nowhere, causing a crash. Make this assumption hold true for these three drivers. Signed-off-by:
Darrick J. Wong <djwong@us.ibm.com> Acked-by:
Corey Minyard <cminyard@mvista.com> Cc: Jean Delvare <khali@linux-fr.org> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
-
Nicolas Pitre authored
commit 72bc2b1a upstream. Same fix as commit c7cf72dc: when 'start' and 'end' are less than a cacheline apart and 'start' is unaligned we are done after cleaning and invalidating the first cacheline. Signed-off-by:
Nicolas Pitre <nico@marvell.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
