- 28 Jan, 2010 26 commits
-
-
Karel Zak authored
commit 87038c2d upstream. The size of EFI GPT header is not static, but whole sector is allocated for the header. The HeaderSize field must be greater than 92 (= sizeof(struct gpt_header) and must be less than or equal to the logical block size. It means we have to read whole sector with the header, because the header crc32 checksum is calculated according to HeaderSize. For more details see UEFI standard (version 2.3, May 2009): - 5.3.1 GUID Format overview, page 93 - Table 13. GUID Partition Table Header, page 96 Signed-off-by:
Karel Zak <kzak@redhat.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Florian Westphal authored
commit 3a042929 upstream. commit d6d3f08b (netfilter: xtables: conntrack match revision 2) does break the v1 conntrack match iptables-save output in a subtle way. Problem is as follows: up = kmalloc(sizeof(*up), GFP_KERNEL); [..] /* * The strategy here is to minimize the overhead of v1 matching, * by prebuilding a v2 struct and putting the pointer into the * v1 dataspace. */ memcpy(up, info, offsetof(typeof(*info), state_mask)); [..] *(void **)info = up; As the v2 struct pointer is saved in the match data space, it clobbers the first structure member (->origsrc_addr). Because the _v1 match function grabs this pointer and does not actually look at the v1 origsrc, run time functionality does not break. But iptables -nvL (or iptables-save) cannot know that v1 origsrc_addr has been overloaded in this way: $ iptables -p tcp -A OUTPUT -m conntrack --ctorigsrc 10.0.0.1 -j ACCEPT $ iptables-save -A OUTPUT -p tcp -m conntrack --ctorigsrc 128.173.134.206 -j ACCEPT (128.173... is the address to the v2 match structure). To fix this, we take advantage of the fact that the v1 and v2 structures are identical with exception of the last two structure members (u8 in v1, u16 in v2). We extract them as early as possible and prevent the v2 matching function from looking at those two members directly. Previously reported by Michel Messerschmidt via Ben Hutchings, also see Debian Bug tracker #556587. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Patrick McHardy <kaber@trash.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Hutchings authored
commit 5bf58347 upstream. If docs are being built in a separate directory, xmlto and xsltproc can't find included sources. Make links back to the source directory. I would much prefer to have xmlto and xsltproc look in the source directory for included entities but couldn't see how to do that. This needs to be solved in some way for 2.6.32, even if this patch isn't the right way to do it. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Hutchings authored
commit 49b14650 upstream. The rule for %.html removes the output directory, so there is no point in copying images before building HTML. Documentation/DocBook/Makefile | 10 +++++----- Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jie Yang authored
commit 7c7afb08 upstream. For hardware limit to support TSOV6, just disable this feature Signed-off-by:
Jie Yang <jie.yang@atheros.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jie Yang authored
commit cb190546 upstream. use common_task instead of reset_task and link_chg_task, so it fix "call cancel_work_sync from the work itself". Signed-off-by:
Jie Yang <jie.yang@atheros.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Seth Heasley authored
commit 79e8941d upstream. Add the Intel Ibex Peak (PCH) Device IDs to iTCO_wdt.c. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Danny Wood authored
V4L/DVB (13168): Add support for Asus Europa Hybrid DVB-T card (SAA7134 SubVendor ID: 0x1043 Device ID: 0x4847) commit e3c6e1aa upstream. Adds the device IDs and driver linking to allow the Asus Europa DVB-T card to operate with these drivers. The device has a SAA7134 chipset with a TD1316 Hybrid Tuner. All inputs work on the card including switching between DVB-T and Analogue TV, there is also no IR with this card. [mchehab@redhat.com: CodingStyle fixes] Signed-off-by:
Danny Wood <danwood76@gmail.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Cliff Brake authored
commit a8cbd90a upstream. Reviewed-by:
John Pilles <jpilles@bb-elec.com> Signed-off-by:
Cliff Brake <cbrake@bec-systems.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Cliff Brake authored
commit acf509ae upstream. Reviewed-by:
John Pilles <jpilles@bb-elec.com> Signed-off-by:
Cliff Brake <cbrake@bec-systems.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Krufky authored
commit 20d15a20 upstream. Add support for five new Hauppauge Device USB IDs: 2040:b980 2040:b990 2040:c010 2040:c080 2040:c090 Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stefan Ringel authored
commit 6dd7dc76 upstream. Signed-off-by:
Stefan Ringel <stefan.ringel@arcor.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
commit 9329d1be upstream. Filesystem code usually destroys the option buffer while parsing it. This leads to errors when the same buffer is passed twice. In case we fill a new superblock do not call remount. This is needed to quite a warning that the debugfs code causes every boot. Cc: Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Heiko Carstens authored
commit f776c5ec upstream. On Mon, Jan 18, 2010 at 05:26:20PM +0530, Sachin Sant wrote: > Hello Heiko, > > Today while trying to boot next-20100118 i came across > the following Oops : > > Brought up 4 CPUs > Unable to handle kernel pointer dereference at virtual kernel address 0000000000 > 543000 > Oops: 0004 #1 SMP > Modules linked in: > CPU: 0 Not tainted 2.6.33-rc4-autotest-next-20100118-5-default #1 > Process swapper (pid: 1, task: 00000000fd792038, ksp: 00000000fd797a30) > Krnl PSW : 0704200180000000 00000000001eb0b8 (shmem_parse_options+0xc0/0x328) > R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 > Krnl GPRS: 000000000054388a 000000000000003d 0000000000543836 000000000000003d > 0000000000000000 0000000000483f28 0000000000536112 00000000fd797d00 > 00000000fd4ba100 0000000000000100 0000000000483978 0000000000543832 > 0000000000000000 0000000000465958 00000000001eb0b0 00000000fd797c58 > Krnl Code: 00000000001eb0aa: c0e5000994f1 brasl %r14,31da8c > 00000000001eb0b0: b9020022 ltgr %r2,%r2 > 00000000001eb0b4: a784010b brc 8,1eb2ca > >00000000001eb0b8: 92002000 mvi 0(%r2),0 > 00000000001eb0bc: a7080000 lhi %r0,0 > 00000000001eb0c0: 41902001 la %r9,1(%r2) > 00000000001eb0c4: b9040016 lgr %r1,%r6 > 00000000001eb0c8: b904002b lgr %r2,%r11 > Call Trace: > (<00000000fd797c50> 0xfd797c50) > <00000000001eb5da> shmem_fill_super+0x13a/0x25c > <0000000000228cfa> get_sb_single+0xbe/0xdc > <000000000034ffc0> dev_get_sb+0x2c/0x38 > <000000000066c602> devtmpfs_init+0x46/0xc0 > <000000000066c53e> driver_init+0x22/0x60 > <000000000064d40a> kernel_init+0x24e/0x3d0 > <000000000010a7ea> kernel_thread_starter+0x6/0xc > <000000000010a7e4> kernel_thread_starter+0x0/0xc > > I never tried to boot a kernel with DEVTMPFS enabled on a s390 box. > So am wondering if this is supported or not ? If you think this > is supported i will send a mail to community on this. There is nothing arch specific to devtmpfs. This part crashes because the kernel tries to modify the data read-only section which is write protected on s390. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
commit 03d673e6 upstream. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Cc: Mark Rosenstand <rosenstand@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sebastian Kapfer authored
commit 1d9f2626 upstream Properly handle version of the protocol where standard PS/2 packets from trackpoint are stuffed into middle (byte 3-6) of the standard ALPS packets when both the touchpad and trackpoint are used together. The patch is based on work done by Matthew Chapman and additional research done by David Kubicek and Erik Osterholm: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610 Many thanks to David Kubicek for his efforts in researching fine points of this new version of the protocol, especially interaction between pad and stick in these models. Cc: Andy Isaacson <adi@hexapodia.org> Signed-off-by:
Sebastian Kapfer <sebastian_kapfer@gmx.net> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Hemant Pedanekar authored
commit f63dd12d upstream. DM6467 silicon revisions 3.x have variant field in JTAGID register as '1'. This path adds entry for the same in dm646x_ids to be able to boot on boards with 3.x revision chips. Also modifies name for 'variant=0' (revisions 1.0, 1.1). Signed-off-by:
Hemant Pedanekar <hemantp@ti.com> Signed-off-by:
Kevin Hilman <khilman@deeprootsystems.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Hutchings authored
commit a3f62bd2 upstream by Kumar Gala <galak@kernel.crashing.org>. I have adjusted the patch context for 2.6.32. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Klute authored
commit 15295380 upstream. At least two revisions of the D-Link DWA 160 exist, called A1 and A2. A1 (USB-ID 07d1:3c10) is already listed in usb.c as D-Link DWA 160A. A2 (USB-ID 07d1:3a09) works if added to ar9170_usb_ids. I didn't do much testing until now, but I was able to connect to APs using WPA or WEP and transmit data. Summary: * Add model revision number to the comment for D-Link DWA 160 A1 (07d1:3c10) * Add support for D-Link DWA 160 A2 (07d1:3a09) Signed-off-by:
Thomas Klute <thomas2.klute@uni-dortmund.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kashyap, Desai authored
commit db27136a upstream. Added device ids range for { 0x80 - 87 } , modified mpi/mpi2_cnfg.h containing MPI2_MFGPAGE_DEVID_SAS2208_X. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by:
Eric Moore <Eric.moore@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ajit Khaparde authored
commit 59fd5d87 upstream. This patch adds the PCI IDs for the next generation chip to the PCI_DEVICE_ID table. Signed-off-by:
Ajit Khaparde <ajitk@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ajit Khaparde authored
commit 12d7ea2c upstream. Add new PCI ids to support next generation of BladeEngine device. Signed-off-by:
Ajit Khaparde <ajitk@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Neil Turton authored
commit a7ebd27a upstream. We need buffer->len to remain valid to work out the correct address to be unmapped. We therefore need to clear buffer->len after the unmap operation. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Xiaotian Feng authored
commit c084ca70 upstream. commit 8bd108d1 adds preemption point after each opcode parse, then a sleeping function called from invalid context bug was founded during suspend/resume stage. this was fixed in commit abe1dfab by don't cond_resched when irq_disabled. But recent commit 138d1569 changes the behaviour to don't cond_resched when in_atomic. This makes the sleeping function called from invalid context bug happen again, which is reported in http://lkml.org/lkml/2009/12/1/371. This patch also fixes http://bugzilla.kernel.org/show_bug.cgi?id=14483Reported-and-bisected-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-and-bisected-by:
Justin P. Mattock <justinmattock@gmail.com> Signed-off-by:
Xiaotian Feng <dfeng@redhat.com> Acked-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
H Hartley Sweeten authored
commit 8e1a928a upstream. Include "tick-internal.h" in order to pick up the extern function prototype for clockevents_shutdown(). This quiets the following sparse build noise: warning: symbol 'clockevents_shutdown' was not declared. Should it be static? Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> LKML-Reference: <BD79186B4FD85F4B8E60E381CAEE190901E24550@mi8nycmail19.Mi8.com> Reviewed-by:
Yong Zhang <yong.zhang0@gmail.com> Cc: johnstul@us.ibm.com Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Xiaotian Feng authored
commit ea9d8e3f upstream. Marc reported that the BUG_ON in clockevents_notify() triggers on his system. This happens because the kernel tries to remove an active clock event device (used for broadcasting) from the device list. The handling of devices which can be used as per cpu device and as a global broadcast device is suboptimal. The simplest solution for now (and for stable) is to check whether the device is used as global broadcast device, but this needs to be revisited. [ tglx: restored the cpuweight check and massaged the changelog ] Reported-by:
Marc Dionne <marc.c.dionne@gmail.com> Tested-by:
Marc Dionne <marc.c.dionne@gmail.com> Signed-off-by:
Xiaotian Feng <dfeng@redhat.com> LKML-Reference: <1262834564-13033-1-git-send-email-dfeng@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 25 Jan, 2010 14 commits
-
-
Greg Kroah-Hartman authored
-
Peter Zijlstra authored
commit 22e19085 upstream. Anton reported that perf record kept receiving events even after calling ioctl(PERF_EVENT_IOC_DISABLE). It turns out that FORK,COMM and MMAP events didn't respect the disabled state and kept flowing in. Reported-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Tested-by:
Anton Blanchard <anton@samba.org> LKML-Reference: <1263459187.4244.265.camel@laptop> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Peter Zijlstra authored
commit 5d27c23d upstream. Acme noticed that his FORK/MMAP numbers were inflated by about the same factor as his cpu-count. This led to the discovery of a few more sites that need to respect the event->cpu filter. Reported-by:
Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <20091217121830.215333434@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Arjan van de Ven authored
commit 8f06d7e6 upstream. A process that changes its comm field, does this on a per kernel task struct basis. The timechart tool used, incorrectly, the pid to track this, and should have used the tid instead... Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> LKML-Reference: <20100116125319.34ac3edd@infradead.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Yongseok Koh authored
commit 88f50044 upstream. In free_unmap_area_noflush(), va->flags is marked as VM_LAZY_FREE first, and then vmap_lazy_nr is increased atomically. But, in __purge_vmap_area_lazy(), while traversing of vmap_are_list, nr is counted by checking VM_LAZY_FREE is set to va->flags. After counting the variable nr, kernel reads vmap_lazy_nr atomically and checks a BUG_ON condition whether nr is greater than vmap_lazy_nr to prevent vmap_lazy_nr from being negative. The problem is that, if interrupted right after marking VM_LAZY_FREE, increment of vmap_lazy_nr can be delayed. Consequently, BUG_ON condition can be met because nr is counted more than vmap_lazy_nr. It is highly probable when vmalloc/vfree are called frequently. This scenario have been verified by adding delay between marking VM_LAZY_FREE and increasing vmap_lazy_nr in free_unmap_area_noflush(). Even the vmap_lazy_nr is for checking high watermark, it never be the strict watermark. Although the BUG_ON condition is to prevent vmap_lazy_nr from being negative, vmap_lazy_nr is signed variable. So, it could go down to negative value temporarily. Consequently, removing the BUG_ON condition is proper. A possible BUG_ON message is like the below. kernel BUG at mm/vmalloc.c:517! invalid opcode: 0000 [#1] SMP EIP: 0060:[<c04824a4>] EFLAGS: 00010297 CPU: 3 EIP is at __purge_vmap_area_lazy+0x144/0x150 EAX: ee8a8818 EBX: c08e77d4 ECX: e7c7ae40 EDX: c08e77ec ESI: 000081fe EDI: e7c7ae60 EBP: e7c7ae64 ESP: e7c7ae3c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Call Trace: [<c0482ad9>] free_unmap_vmap_area_noflush+0x69/0x70 [<c0482b02>] remove_vm_area+0x22/0x70 [<c0482c15>] __vunmap+0x45/0xe0 [<c04831ec>] vmalloc+0x2c/0x30 Code: 8d 59 e0 eb 04 66 90 89 cb 89 d0 e8 87 fe ff ff 8b 43 20 89 da 8d 48 e0 8d 43 20 3b 04 24 75 e7 fe 05 a8 a5 a3 c0 e9 78 ff ff ff <0f> 0b eb fe 90 8d b4 26 00 00 00 00 56 89 c6 b8 ac a5 a3 c0 31 EIP: [<c04824a4>] __purge_vmap_area_lazy+0x144/0x150 SS:ESP 0068:e7c7ae3c [ See also http://marc.info/?l=linux-kernel&m=126335856228090&w=2 ] Signed-off-by:
Yongseok Koh <yongseok.koh@samsung.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ryan May authored
commit 10d2cdb6 upstream. Resolves kernel.org bug 14914. Remove entry for 2770:915d (usb digital camera with mass storage support) from unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable). The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that this unusual_devs.h entry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work. Signed-off-by:
Ryan May <rmay31@gmail.com> Cc: Rohan Hart <rohan.hart17@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Suresh Siddha authored
commit 2992e545 upstream. Thomas Schlichter reported: > X.org uses libpciaccess which tries to mmap with write combining enabled via > /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the > kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded > mapping with write combining enabled and does not set up suited MTRR entries. > ;-( Instead of silently mapping pci mmap region as UC minus in the case of !pat_enabled and wc request, we can return error. Eric Anholt mentioned that caller (like X) typically follows up with UC minus pci mmap request and if there is a free mtrr slot, caller will manage adding WC mtrr. Jesse Barnes says: > Older versions of libpciaccess will behave better if we do it that way > (iirc it only allocates an MTRR if the resource_wc file doesn't exist or > fails to get mapped). Reported-by:
Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by:
Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Acked-by:
Eric Anholt <eric@anholt.net> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Martin K. Petersen authored
commit b27d7f16 upstream. Make DM use bdev_stack_limits() function so that partition offsets get taken into account when calculating alignment. Clarify stacking warnings. Also remove obsolete clearing of final alignment_offset and misalignment flag. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Cc: Alasdair G. Kergon <agk@redhat.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Martin K. Petersen authored
commit 17be8c24 upstream. DM does not want to know about partition offsets. Add a partition-aware wrapper that DM can use when stacking block devices. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Acked-by:
Mike Snitzer <snitzer@redhat.com> Reviewed-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Zhao Yakui authored
commit 7c3f0a27 upstream. There exist multiple DDC buses for the SDVO cards with multiple outputs. When we can't get the EDID by using the select DDC bus, we can try the other possible DDC bus to see whether the EDID can be obtained. https://bugs.freedesktop.org/show_bug.cgi?id=23842Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Tested-by:
Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Zhao Yakui authored
commit 6a304caf upstream. For some SDVO cards based on conexant chip, we can't read the EDID if we don't read the response after issuing SDVO DDC bus switch command. From the SDVO spec once when another I2C transaction is finished after completing the I2C transaction of issuing the bus switch command, it will be switched back to the SDVO internal state again. So we can't initiate a new I2C transaction to read the response after issuing the DDC bus switch command. Instead we should issue DDC bus switch command and read the response in the same I2C transaction. https://bugs.freedesktop.org/show_bug.cgi?id=23842 https://bugs.freedesktop.org/show_bug.cgi?id=24458 https://bugs.freedesktop.org/show_bug.cgi?id=24522 https://bugs.freedesktop.org/show_bug.cgi?id=24282Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Tested-by:
Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
James Bottomley authored
commit cc9b2e9f upstream. Based on patch originally by Jeff Mahoney <jeffm@suse.com> enclosure_status is expected to be a NULL terminated array of strings but isn't actually NULL terminated. When writing an invalid value to /sys/class/enclosure/.../.../status, it goes off the end of the array and Oopses. Fix by making the assumption true and adding NULL at the end. Reported-by:
Artur Wojcik <artur.wojcik@intel.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alexey Starikovskiy authored
commit 54070101 upstream. Merge of poll and irq modes accelerated EC transaction, so that keyboard starts to suffer again. Add msleep(1) into transaction path for the storm to allow keyboard controller to do its job. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: François Valenduc <francois.valenduc@tvcablenet.be> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alexey Starikovskiy authored
commit a62e8f19 upstream. Split EC query handling into acknowledge and execution phase. This allows much smaller pending query lattency and lowers chances of EC going "wild" and losing events. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: François Valenduc <francois.valenduc@tvcablenet.be> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-