- 10 Jun, 2012 12 commits
-
-
Marc Gariepy authored
commit f5b8a7ed upstream. Add a no_lvds quirk for the HP t5745 and HP st5747 thin clients dmidecode for those thin clients are attached in thoses bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920Signed-off-by:
Marc Gariepy <mgariepy@ubuntu.com> Acked-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: adjust context because these quirk entries aren't consistently cc'd to stable and are now being applied out of order] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Joel Sass authored
commit 44306ab3 upstream. Signed-off-by:
Joel Sass <jsass@disklessworkstations.com> Reviewed-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Daniel Vetter authored
commit 6cb49835 upstream. We have one bug report from a validation team that we get the eDP panel sequencing still somewhat wrong: We need to enable VDD while switching off the panel and backlight. Unfortunately that reporter seems to have fallen off the earth :( For another reporter this actually fixes a black panel issue because without this the backlight/panel gets confused and doesn't light up again. v2: I've forgotten to remove the vdd_off call in panel_off which is now bogus. This essentially reverts commit 17038de5 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 16 22:43:42 2012 +0100 drm/i915/dp: Flush any outstanding work to turn the VDD off v3: the current panel_off code forces off the vdd power, too. Which is bogus and resulted in some funny warnings later on when we've tried to do aux channel communications with just the vdd forced on. Fix this, too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163Tested-by:
Vincent Frentzel <zcecc22@gmail.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by:
-
Daniel Vetter authored
commit 59d92bfa upstream. We've simply ignored this, which isn't too great. With this, interlaced 1080i works on my HDMI screen connected through sdvo. For no apparent reason anything else still doesn't work as it should. While at it, give these magic numbers in the dtd proper names and add a comment that they match with EDID detailed timings. v2: Actually use the right bit for interlaced. Tested-by:
Peter Ross <pross@xvid.org> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by:
-
Richard Cochran authored
commit 9dde0ae3 upstream. Once again, ixp4xx no longer even compiles. This patch fixes the issue by converting over to gpiolib. This patch was first made by Imre and posted by Marc, and I added in Russell's suggestion to empty the gpio header file. This fix should also go for 3.1, 3.2, 3.3, and 3.4. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Jun'ichi Nomura authored
commit b7e94a16 upstream. block congestion control doesn't have any concept of fairness across multiple queues. This means that if SCSI reports the host as busy in the queue congestion control it can result in an unfair starvation situation in dm-mp if there are multiple multipath devices on the same host. For example: http://www.redhat.com/archives/dm-devel/2012-May/msg00123.html The fix for this is to report only the sdev busy state (and ignore the host busy state) in the block congestion control call back. The host is still congested, but the SCSI subsystem will sort out the congestion in a fair way because it knows the relation between the queues and the host. [jejb: fixed up trailing whitespace] Reported-by:
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Tested-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Shirish Pargaonkar authored
commit 2c0c2a08 upstream. While traversing the linked list of open file handles, if the identfied file handle is invalid, a reopen is attempted and if it fails, we resume traversing where we stopped and cifs can oops while accessing invalid next element, for list might have changed. So mark the invalid file handle and attempt reopen if no valid file handle is found in rest of the list. If reopen fails, move the invalid file handle to the end of the list and start traversing the list again from the begining. Repeat this four times before giving up and returning an error if file reopen keeps failing. Signed-off-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Boaz Harrosh authored
commit 6abe4a87 upstream. If at exofs_fill_super() we had an early termination do to any error, like an IO error while reading the super-block. We would crash inside exofs_free_sbi(). This is because sbi->oc.numdevs was set to 1, before we actually have a device table at all. Fix it by moving the sbi->oc.numdevs = 1 to after the allocation of the device table. Reported-by:
Johannes Schild <JSchild@gmx.de> Stable: This is a bug since v3.2.0 Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Trond Myklebust authored
commit 1afeaf5c upstream. xprt_alloc_slot will call rpc_delay() to make the task wait a bit before retrying when it gets back an -ENOMEM error from xprt_dynamic_alloc_slot. The problem is that rpc_delay will clear the task->tk_status, causing call_reserveresult to abort the task. The solution is simply to let call_reserveresult handle the ENOMEM error directly. Reported-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Shirish Pargaonkar authored
commit 2608bee7 upstream. As observed and suggested by Tushar Gosavi... --------- readdir calls these function to send TRANS2_FIND_FIRST and TRANS2_FIND_NEXT command to the server. The current cifs module is not specifying CIFS_SEARCH_BACKUP_SEARCH flag while sending these command when backupuid/backupgid is specified. This can be resolved by specifying CIFS_SEARCH_BACKUP_SEARCH flag. --------- Reported-and-Tested-by:
Tushar Gosavi <tugosavi@in.ibm.com> Signed-off-by:
-
Jonas Gorski authored
commit 442209f3 upstream. bcm63xx_gpio.h uses macros defined in bcm63xx_cpu.h without including it, leading to the following build failure: CC [M] drivers/mmc/core/cd-gpio.o In file included from arch/mips/include/asm/mach-bcm63xx/gpio.h:4:0, from arch/mips/include/asm/gpio.h:4, from include/linux/gpio.h:30, from drivers/mmc/core/cd-gpio.c:12: arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h: In function 'bcm63xx_gpio_count': arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h:10:2: error: implicit declaration of function 'bcm63xx_get_cpu_id' arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h:11:7: error: 'BCM6358_CPU_ID' undeclared (first use in this function) arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h:11:7: note: each undeclared identifier is reported only once for each function it appears in arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h:13:7: error: 'BCM6338_CPU_ID' undeclared (first use in this function) arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h:15:7: error: 'BCM6345_CPU_ID' undeclared (first use in this function) arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h:17:7: error: 'BCM6368_CPU_ID' undeclared (first use in this function) arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h:19:7: error: 'BCM6348_CPU_ID' undeclared (first use in this function) make[7]: *** [drivers/mmc/core/cd-gpio.o] Error 1 Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Cc: linux-mips@linux-mips.org Cc: Maxime Bizon <mbizon@freebox.fr> Cc: Florian Fainelli <florian@openwrt.org> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Joerg Roedel authored
commit 3d06fca8 upstream. Due to a recent erratum it can happen that the head pointer of the event-log is updated before the actual event-log entry is written. This patch implements the recommended workaround. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
- 30 May, 2012 28 commits
-
-
Ben Hutchings authored
-
H. Peter Anvin authored
commit ea17e741 upstream. The symbol jiffies is created in the linker script as an alias to jiffies_64. Unfortunately this is done outside any section, and apparently GNU ld 2.21 doesn't carry the section with it, so we end up with an absolute symbol and therefore a broken kernel. Add jiffies and jiffies_64 to the whitelist. The most disturbing bit with this discovery is that it shows that we have had multiple linker bugs in this area crossing multiple generations, and have been silently building bad kernels for some time. Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.auReported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
H. Peter Anvin authored
commit fd952815 upstream. As noted in checkin: a3e854d9 x86, relocs: Workaround for binutils 2.22.52.0.1 section bug ld version 2.22.52.0.[12] can incorrectly promote relative symbols to absolute, if the output section they appear in is otherwise empty. Since checkin: 6520fe55 x86, realmode: 16-bit real-mode code support for relocs tool we actually check for this and error out rather than silently creating a kernel which will malfunction if relocated. Ingo found a configuration in which __start_builtin_fw triggered the warning. Go through the linker script sources and look for more symbols that could plausibly get bogusly promoted to absolute, and add them to the whitelist. In general, if the following error triggers: Invalid absolute R_386_32 relocation: <symbol> ... then we should verify that <symbol> is really meant to be relocated, and add it and any related symbols manually to the S_REL regexp. Please note that 6520fe55 does not introduce the error, only the check for the error -- without 6520fe55 this version of ld will simply produce a corrupt kernel if CONFIG_RELOCATABLE is set on x86-32. Reported-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jarkko Sakkinen authored
commit b2d668da upstream. relocs was not cleaned up when "make clean" is issued. This patch fixes the issue. Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@intel.com> Link: http://lkml.kernel.org/r/1337622684-6834-1-git-send-email-jarkko.sakkinen@intel.comSigned-off-by:
-
H. Peter Anvin authored
commit 24ab82bd upstream. When the relocs tool throws an error, let the error message say if it is an absolute or relative symbol. This should make it a lot more clear what action the programmer needs to take and should help us find the reason if additional symbol bugs show up. Signed-off-by:
-
H. Peter Anvin authored
commit a3e854d9 upstream. GNU ld 2.22.52.0.1 has a bug that it blindly changes symbols from section-relative to absolute if they are in a section of zero length. This turns the symbols __init_begin and __init_end into absolute symbols. Let the relocs program know that those should be treated as relative symbols. Reported-by:
-
H. Peter Anvin authored
commit 6520fe55 upstream. A new option is added to the relocs tool called '--realmode'. This option causes the generation of 16-bit segment relocations and 32-bit linear relocations for the real-mode code. When the real-mode code is moved to the low-memory during kernel initialization, these relocation entries can be used to relocate the code properly. In the assembly code 16-bit segment relocations must be relative to the 'real_mode_seg' absolute symbol. Linear relocations must be relative to a symbol prefixed with 'pa_'. 16-bit segment relocation is used to load cs:ip in 16-bit code. Linear relocations are used in the 32-bit code for relocatable data references. They are declared in the linker script of the real-mode code. The relocs tool is moved to arch/x86/tools/relocs.c, and added new target archscripts that can be used to build scripts needed building an architecture. be compiled before building the arch/x86 tree. [ hpa: accelerating this because it detects invalid absolute relocations, a serious bug in binutils 2.22.52.0.x which currently produces bad kernels. ] Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.comSigned-off-by:
-
Marcus Folkesson authored
commit 9868a060 upstream. The freed IRQ is not necessary the one requested in probe. Even if it was, with two or more i2c-controllers it will fails anyway. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
-
Laxman Dewangan authored
commit c889e91d upstream. The notification of the transfer complete by calling complete() should be done after clearing all interrupt status. This avoids the race condition of misconfigure the i2c controller in multi-core environment. Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Acked-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
-
Sachin Prabhu authored
commit 5794d21e upstream. When attempting to cache ACLs returned from the server, if the bitmap size + the ACL size is greater than a PAGE_SIZE but the ACL size itself is smaller than a PAGE_SIZE, we can read past the buffer page boundary. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Reported-by:
Jian Li <jiali@redhat.com> Signed-off-by:
-
Sachin Prabhu authored
commit 5a006899 upstream. Bug noticed in commit bf118a34 When calling GETACL, if the size of the bitmap array, the length attribute and the acl returned by the server is greater than the allocated buffer(args.acl_len), we can Oops with a General Protection fault at _copy_from_pages() when we attempt to read past the pages allocated. This patch allocates an extra PAGE for the bitmap and checks to see that the bitmap + attribute_length + ACLs don't exceed the buffer space allocated to it. Signed-off-by:
-
Peng Tao authored
commit de040bec upstream. compile in nfs-for-3.3 branch shows following warnings. Fix it here. fs/nfs/nfs4proc.c: In function ‘__nfs4_get_acl_uncached’: fs/nfs/nfs4proc.c:3589: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘size_t’ fs/nfs/nfs4proc.c:3589: warning: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘size_t’ Signed-off-by:
Peng Tao <peng_tao@emc.com> Signed-off-by:
-
Larry Finger authored
commit a7959c13 upstream. The current version of rtlwifi for USB operations uses kmalloc to acquire a 32-bit buffer for each read of the device. When _usb_read_sync() is called with the rcu_lock held, the result is a "sleeping function called from invalid context" BUG. This is reported for two cases in https://bugzilla.kernel.org/show_bug.cgi?id=42775. The first case has the lock originating from within rtlwifi and could be fixed by rearranging the locking; however, the second originates from within mac80211. The kmalloc() call is removed from _usb_read_sync() by creating a ring buffer pointer in the private area and allocating the buffer data in the probe routine. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> [This version will apply to 3.2 and earlier. - Larry] Signed-off-by:
-
Rajkumar Kasirajan authored
commit c0a5f4a0 upstream. The reset date of the ST Micro version of PL031 is 2000-01-01. The correct weekday for 2000-01-01 is saturday, but pl031 is initialized to sunday. This may lead to alarm malfunction, so configure the correct wday if RTC_DR indicates reset. Signed-off-by:
Rajkumar Kasirajan <rajkumar.kasirajan@stericsson.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: Mattias Wallin <mattias.wallin@stericsson.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jeff Moyer authored
commit 080399aa upstream. Hi, We have a bug report open where a squashfs image mounted on ppc64 would exhibit errors due to trying to read beyond the end of the disk. It can easily be reproduced by doing the following: [root@ibm-p750e-02-lp3 ~]# ls -l install.img -rw-r--r-- 1 root root 142032896 Apr 30 16:46 install.img [root@ibm-p750e-02-lp3 ~]# mount -o loop ./install.img /mnt/test [root@ibm-p750e-02-lp3 ~]# dd if=/dev/loop0 of=/dev/null dd: reading `/dev/loop0': Input/output error 277376+0 records in 277376+0 records out 142016512 bytes (142 MB) copied, 0.9465 s, 150 MB/s In dmesg, you'll find the following: squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 43.106012] attempt to access beyond end of device [ 43.106029] loop0: rw=0, want=277410, limit=277408 [ 43.106039] Buffer I/O error on device loop0, logical block 138704 [ 43.106053] attempt to access beyond end of device [ 43.106057] loop0: rw=0, want=277412, limit=277408 [ 43.106061] Buffer I/O error on device loop0, logical block 138705 [ 43.106066] attempt to access beyond end of device [ 43.106070] loop0: rw=0, want=277414, limit=277408 [ 43.106073] Buffer I/O error on device loop0, logical block 138706 [ 43.106078] attempt to access beyond end of device [ 43.106081] loop0: rw=0, want=277416, limit=277408 [ 43.106085] Buffer I/O error on device loop0, logical block 138707 [ 43.106089] attempt to access beyond end of device [ 43.106093] loop0: rw=0, want=277418, limit=277408 [ 43.106096] Buffer I/O error on device loop0, logical block 138708 [ 43.106101] attempt to access beyond end of device [ 43.106104] loop0: rw=0, want=277420, limit=277408 [ 43.106108] Buffer I/O error on device loop0, logical block 138709 [ 43.106112] attempt to access beyond end of device [ 43.106116] loop0: rw=0, want=277422, limit=277408 [ 43.106120] Buffer I/O error on device loop0, logical block 138710 [ 43.106124] attempt to access beyond end of device [ 43.106128] loop0: rw=0, want=277424, limit=277408 [ 43.106131] Buffer I/O error on device loop0, logical block 138711 [ 43.106135] attempt to access beyond end of device [ 43.106139] loop0: rw=0, want=277426, limit=277408 [ 43.106143] Buffer I/O error on device loop0, logical block 138712 [ 43.106147] attempt to access beyond end of device [ 43.106151] loop0: rw=0, want=277428, limit=277408 [ 43.106154] Buffer I/O error on device loop0, logical block 138713 [ 43.106158] attempt to access beyond end of device [ 43.106162] loop0: rw=0, want=277430, limit=277408 [ 43.106166] attempt to access beyond end of device [ 43.106169] loop0: rw=0, want=277432, limit=277408 ... [ 43.106307] attempt to access beyond end of device [ 43.106311] loop0: rw=0, want=277470, limit=2774 Squashfs manages to read in the end block(s) of the disk during the mount operation. Then, when dd reads the block device, it leads to block_read_full_page being called with buffers that are beyond end of disk, but are marked as mapped. Thus, it would end up submitting read I/O against them, resulting in the errors mentioned above. I fixed the problem by modifying init_page_buffers to only set the buffer mapped if it fell inside of i_size. Cheers, Jeff Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Acked-by:
Nick Piggin <npiggin@kernel.dk> -- Changes from v1->v2: re-used max_block, as suggested by Nick Piggin. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Ben Hutchings authored
commit 786f5281 upstream. The parameters for ETHTOOL_FLASHDEV include a filename, which ought to be null-terminated. Currently the only driver that implements ethtool_ops::flash_device attempts to add a null terminator if necessary, but does it wrongly. Do it in the ethtool core instead. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Woodhouse authored
commit e2ad23d0 upstream. Add device info into list before doing context mapping, because device info will be used by iommu_enable_dev_iotlb(). Without it, ATS won't get enabled as it should be. ATS, while a dubious decision from a security point of view, can be very important for performance. Signed-off-by:
Xudong Hao <xudong.hao@intel.com> Signed-off-by:
Xiantao Zhang <xiantao.zhang@intel.com> Acked-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Chris Metcalf authored
commit 9f1d62be upstream. This is because __builtin_clz(0) returns 64 for the "undefined" case of 0, since the builtin just does a right-shift 32 and "clz" instruction. So, use the alpha approach of casting to u32 and using __builtin_clzll(). Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Tony Luck authored
commit 875e2664 upstream. Linus pointed out that there was no value is checking whether m->ip was zero - because zero is a legimate value. If we have a reliable (or faked in the VM86 case) "m->cs" we can use it to tell whether we were in user mode or kernelwhen the machine check hit. Reported-by:
Linus Torvalds <torvalds@linuxfoundation.org> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Andi Kleen authored
commit a129a7c8 upstream. When running on 32bit the mce handler could misinterpret vm86 mode as ring 0. This can affect whether it does recovery or not; it was possible to panic when recovery was actually possible. Fix this by always forcing vm86 to look like ring 3. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Dave Airlie authored
commit c284815d upstream. This seems to be wrong to me, spotted while thinking about dma-buf. Reviewed-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Stefano Stabellini authored
commit 68c2c39a upstream. PV on HVM guests map GSIs into event channels. At restore time the event channels are resumed by restore_pirqs. Device drivers might try to register the same GSI again through ACPI at restore time, but the GSI has already been mapped and bound by restore_pirqs. This patch detects these situations and avoids mapping the same GSI multiple times. Without this patch we get: (XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped and waste a pirq. Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 067aa481 upstream. Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed spi device initialization of dev.parent pointer to be the master's device pointer instead of his parent. This introduced a bug in spi-fsl-spi, since its usage of spi device pointer was not updated accordingly. This was later fixed by commit 5039a869, "spi/mpc83xx: fix NULL pdata dereference bug", but it missed another spot on fsl_spi_cs_control function where we also need to update usage of spi device pointer. This change address that. Signed-off-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Acked-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Daniel Vetter authored
commit a9dcf84b upstream. ... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in commit f47166d2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 22 15:00:50 2012 +0000 drm/i915: Sanitize BIOS debugging bits from PIPECONF Spotted by staring at debug output of an (as it turns out) totally unrelated bug. v2: I've totally failed to do the s/pipe/i/ correctly, spotted by Chris Wilson. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
-
Thomas Gleixner authored
commit d6de85e8 upstream. commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO driver) added an unconditional call of chip->irq_eoi() to the demux handler. This leads to a NULL pointer derefernce on MPC512x platforms which use this driver as well. Make it conditional. Reported-by:
Thomas Wucher <thwucher@linutronix.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Felix Radensky <felix@embedded-sol.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Larry Finger authored
commit 8f4b2038 upstream. There is a dummy read of a PCI MMIO register that occurs before the SSB bus has been powered, which is an error. This bug has not been seen earlier, but was apparently exposed when udev was updated to version 182. Signed-off-by:
-
Chris Wilson authored
commit 9adab8b5 upstream. Currently the code re-reads PCH_IIR during the hotplug interrupt processing. Not only is this a wasted read, but introduces a potential for handling a spurious interrupt as we then may not clear all the interrupts processed (since the re-read IIR may contains more interrupts asserted than we clear using the result of the original read). Signed-off-by:
-
Laurent Pinchart authored
commit 31c5f0c5 upstream. Properly validate the user-supplied index against the number of inputs. The code used the pin local variable instead of the index by mistake. Reported-by:
Jozef Vesely <vesely@gjh.sk> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
