| Age | Commit message (Collapse) | Author |
|---|
|
When turning on adaptive_rx under adaptive moderation, the CQ's moderation
count wasn't updated according to rx_frames which resulted in too many
interrupts and bandwidth drop.
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Second round of IIO fixes for the 3.10 cycle.
A couple of little bits and pieces, some delayed due to traveling.
1) A memory leak fix in the callback buffer.
2) Wrong exit path due to a return when it should have been a goto.
3) Bug in a mask value in ad4350
4) Reading the wrong value in raw to processed utility function.
|
|
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The code uses
return foo;
goto err_type;
when instead the form should have been
ret = foo;
goto err_type;
Here this causes a useful iio_device_put to be skipped.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
If we pass an invalid clock type then "ts" is never set. We need to
check for errors earlier, otherwise we end up passing uninitialized
stack data to userspace.
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Reported-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The register access to enable hardware flow control depends on the
device port number and not the port minor number.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove the no longer used endpoint-array access completely.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The outcont_endpoints array was indexed using the port minor number
(which can be greater than the array size) rather than the device port
number.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove bogus port-number check in open and close, which prevented this
driver from being used with a minor number different from zero.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
And make the lines easier to read.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
In summary, the symptom is intermittent key events lost after resume
on some machines with synaptics touchpad (seems this is synaptics _only_),
and key events loss is due to serio port reconnect after psmouse sync lost.
Removing psmouse and inserting it back during the suspend/resume process
is able to work around the issue, so the difference between psmouse_connect()
and psmouse_reconnect() is the key to the root cause of this problem.
After comparing the two different paths, synaptics driver has its own
implementation of synaptics_reconnect(), and the missing psmouse_probe()
seems significant, the patch below added psmouse_probe() to the reconnect
process, and has been verified many times that the issue could not be reliably
reproduced.
There are two PS/2 commands in psmouse_probe():
1. PSMOUSE_CMD_GETID
2. PSMOUSE_CMD_RESET_DIS
Only the PSMOUSE_CMD_GETID seems to be significant. The
PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
several times. So we have only implemented this patch to issue
the PSMOUSE_CMD_GETID so far.
Tested-by: Daniel Manrique <daniel.manrique@canonical.com>
Signed-off-by: James M Leddy <james.leddy@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
for DDC. Thus the code will always have to rely on a LVDS panel
mode supplied by VBT.
In most cases this succeeds, so this didn't get detected for quite
a while.
This regression seems to have been introduced in
commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
Signed-off-by: Egbert Eich <eich@suse.de>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about which commit likely introduced this issue.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The USB_OVCn pins are alternate options for USB over-current detection
when using a 3.3V USB interface. As they're not mandatory they can be
used independently of the USB PENC pins. Don't group the USB_OVCn and
PENC pins to avoid conflicts when the USB_OVCn pins are used by another
function.
Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A few small fixes for v3.10, documentation things in the core and a
few driver bugs."
* tag 'regulator-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: palmas: Fix "enable_reg" to point to the correct reg for SMPS10
regulator: palmas: Fix incorrect condition
regulator: core: Correct spelling mistake in comment
regulator: dbx500: Make local symbol static
regulator: Fix kernel-doc generation warnings.
|
|
Smatch complains that if we pass an invalid clock type then "ts" is
never set. We need to check for errors earlier, otherwise we end up
passing uninitialized stack data to userspace.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Option GTM681W uses a qualcomm chip and can be
served by the qcserial device driver.
Signed-off-by: Richard Weinberger <richard@nod.at>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The patch adds a new HIDCOM device and does not affect other devices
driven by the cypress_M8 module. Changes are:
- add VendorID ProductID to device tables
- skip unstable speed check because FRWD uses 115200bps
- skip reset at probe which is an issue workaround for this
particular device.
Signed-off-by: Robert Butora <robert.butora.fi@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit cfcec52e9781f08948c6eb98198d65c45be75a70.
This regresses a longstanding behaviour on X86 systems, which end up with
PCI serial ports moving between ttyS4 and ttyS0 when you bisect to opposite
sides of this commit, resulting in the need to constantly modify the console
setting in order to bisect across it.
Please revert, we can work on solving this for ARM platforms in a less
disruptive way.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Cc: Karthik Manamcheri <karthik.manamcheri@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Ensure that the uart controller clock is enabled prior to writing to the
interrupt mask and pending registers in the s3c24xx_serial_init_port
function.
Signed-off-by: Chander Kashyap <chander.kashyap@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We only want to enable hardware flow control if RTS/CTS pins
are connected.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The mxs interrupt controller does not support polling for interrupts,
but the driver still does it, which is a relict from
pre-MULTI_IRQ_HANDLER times.
The existing code assumes that 0x7f means no interrupt, but this value
is an actually valid irq number, namely gpio bank 0's irq. This results
in the driver not detecting when irq 0x7f is active which makes the
machine effectively dead lock.
This patch removes the interrupt poll loop and allows usage of gpio0
interrupt without an infinite loop.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
|
|
It's not supported yet. Fixes display issues when
users force it on.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
v2: fix trailing whitespace
Signed-off-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The current radeon driver initialization routines, when using KMS, are written
so that the IRQ installation routine is called before initializing the WB buffer
and the CP rings. With some ASICs, though, the IRQ routine tries to access the
GFX_INDEX ring causing a call to RREG32 with the value of -1 in
radeon_fence_read. This, in turn causes the system to completely hang with some
cards, requiring a hard reset.
A call stack that can cause such a hang looks like this (using rv515 ASIC for the
example here):
* rv515_init (rv515.c)
* radeon_irq_kms_init (radeon_irq_kms.c)
* drm_irq_install (drm_irq.c)
* radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
* rs600_irq_process (rs600.c)
* radeon_fence_process - due to SW interrupt (radeon_fence.c)
* radeon_fence_read (radeon_fence.c)
* hang due to RREG32(-1)
The patch moves the IRQ installation to the card startup routine, after the ring
has been initialized, but before the IRQ has been set. This fixes the issue, but
requires a check to see if the IRQ is already installed, as is the case in the
system resume codepath.
I have tested the patch on three machines using the rv515, the rv770 and the
evergreen ASIC. They worked without issues.
This seems to be a known issue and has been reported on several bug tracking
sites by various distributions (see links below). Most of reports recommend
booting the system with KMS disabled and then enabling KMS by reloading the
radeon module. For some reason, this was indeed a usable workaround, however,
UMS is now deprecated and disabled by default.
Bug reports:
https://bugzilla.redhat.com/show_bug.cgi?id=845745
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789
https://bbs.archlinux.org/viewtopic.php?id=156964
Signed-off-by: Adis Hamzić <adis@hamzadis.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Last year, a patch was made for the "HP t5740e Thin Client" (see
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
This device reports an lvds panel, but does not really have one.
The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.
Signed-off-by: Ben Mesman <ben@bnc.nl>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
If we always force the pipe A to on we can't use the hw state to
decide whether it should be on. Hence quirk the quirk.
The problem is that crtc->active tracks the state of the entire
display pipe, i.e. including planes, encoders and all. But our hw
state readout simply looks at the pipe. But with the pipe A quirk we
force-enable that (together with it's pll). To fix that mismatch we
have two options:
- Quirk the checked state to match what our sw tracking states if the
pipe A quirk is in effect.
- Improve the hw state readout to not get fooled by the pipe A quirk.
Since we already have similar state clamping in e.g. assert_pipe I've
opted for the first variant. Also note that we don't really loose any
state checking: Individual pieces of the abstract crtc pipe are
checked in the enable/disable functions with the various asssert_*
checks we have, and the hw state check code doesn't check anything if
the pipe is off anyway.
v2: Pimp commit message after discussion with Chris and only apply the
quirk for the quirk if we're checking pipe A. Otherwise we'll miss
state checking for pipe B on i830M ...
v3: Make the code comment consistent with the improved commit message,
too (Chris).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64764
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-Tested-by: mlsemon35@gmail.com (v1)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Chris Wilson noticed that since
commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Nov 15 17:17:22 2012 +0100
drm/i915: clear up wedged transitions
X can again get -EIO when it does not expect it. And even worse score
a SIGBUS when accessing gtt mmaps. The established ABI is that we
_only_ return an -EIO from execbuf - all other ioctls should just
work. And since the reset code moves all bos out of gpu domains and
clears out all the last_seqno/ring tracking there really shouldn't be
any reason for non-execbuf code to ever touch the hw and see an -EIO.
After some extensive discussions we've noticed that these spurios -EIO
are caused by i915_gem_wait_for_error:
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html
That is easy to fix by returning 0 instead of -EIO, since grabbing the
dev->struct_mutex does not yet mean that we actually want to touch the
hw. And so there is no reason at all to fail with -EIO.
But that's not the entire since, since often (at least it's easily
googleable) dmesg indicates that the reset fails and we declare the
gpu wedged. Then, quite a bit later X wakes up with the "Timed out
waiting for the gpu reset to complete" DRM_ERROR message in
wait_for_errror and brings down the desktop with an -EIO/SIGBUS.
So clearly we're missing a wakeup somewhere, since the gpu reset just
doesn't take 10 seconds to complete. And indeed we're do handle the
terminally wedged state wrong.
Fix this all up.
References: https://bugs.freedesktop.org/show_bug.cgi?id=63921
References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
smatch reports the following warnings:
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:514 pcan_usb_pro_drv_loaded() error: doing dma on the stack (buffer)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:878 pcan_usb_pro_init() error: doing dma on the stack (&fi)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:889 pcan_usb_pro_init() error: doing dma on the stack (&bi)
See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"
Cc: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
smatch reports the following warnings:
drivers/net/can/usb/esd_usb2.c:640 esd_usb2_start() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:846 esd_usb2_close() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:855 esd_usb2_close() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:923 esd_usb2_set_bittiming() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:1047 esd_usb2_probe() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:1053 esd_usb2_probe() error: doing dma on the stack (&msg)
See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
hardware.
Unlike Kvaser Leaf light devices, some other Kvaser devices (like USBcan
Pro, USBcan R) receive CAN messages in CMD_LOG_MESSAGE frames. This
patch adds support for it.
Cc: linux-stable <stable@vger.kernel.org> # >= v3.8
Signed-off-by: Jonas Peterson <jonas.peterson@gmail.com>
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This is a bug fix for some versions of g200se cards while doing
mode-setting.
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
|
|
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
|
|
The dependecies for BACKLIGHT_CLASS_DEVICE are defined a bit
strange, but it seems one has to always select both BACKLIGHT_CLASS_DEVICE
and BACKLIGHT_LCD_SUPPORT to avoid this error:
drivers/gpu/drm/tilcdc/tilcdc_panel.c:396:
undefined reference to `of_find_backlight_by_node'
Cc: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
|
|
When GPU acceleration is disabled, drm_vblank_cleanup() will free the
vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
But we found that drm_vblank_post_modeset() may be called after the
cleanup, which use vblank_refcount and vblank_inmodeset. And this will
cause a kernel panic.
Fix this by return immediately if dev->num_crtcs is zero. This is the
same thing that drm_vblank_pre_modeset() does.
Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
[ 62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4
[ 62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174
[ 62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38
[ 62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc
[ 62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988
[ 62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104
[ 62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c
[ 62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118
[ 62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384
[ 62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc
[ 62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94
[ 62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68
[ 62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260
[ 62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314
[ 62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234
[ 62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4
[ 62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18
[ 62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c
[ 62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238
[ 62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0
[ 62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30
[ 62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc
[ 62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44
[ 62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4
[ 62.628906] [<ffffffff802497a8>] kthread+0x88/0x90
[ 62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Binbin Zhou <zhoubb@lemote.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Dave Airlie <airlied@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
"Recent bug fixes, one of them touches a common code file.
It adds two #ifndef/#endif pairs to asm-generic/io.h to be able to
override xlate_dev_kmem_ptr and xlate_dev_mem_ptr."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/pgtable: Fix gmap notifier address
s390/dasd: fix handling of gone paths
s390/pgtable: Fix check for pgste/storage key handling
arch: s390: appldata: using strncpy() and strnlen() instead of sprintf()
s390/smp: lost IPIs on cpu hotplug
kernel: Fix s390 absolute memory access for /dev/mem
s390/dma: do not call debug_dma after free
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
Pull libata changes from Tejun Heo:
"Nothing too interesting. PCI ID additions, some sata_rcar fixes and a
fringe bug fix for DMADIR handling which shouldn't affect any device
remotely modern."
* 'for-3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
sata_rcar: fix interrupt handling
ahci: add an observed PCI ID for Marvell 88se9172 SATA controller
sata_rcar: clear STOP bit in bmdma_start() method
libata: make ata_exec_internal_sg honor DMADIR
ata_piix: add PCI IDs for Intel BayTail
libata: update "Maintained by:" tags
|
|
The driver's interrupt handling code is too picky in deciding whether it should
handle an interrupt or not which causes completely unneeded spurious interrupts.
Thus make sata_rcar_{ata|serr}_interrupt() *void*; add ATA status register read
to sata_rcar_ata_interrupt() to clear an unexpected ATA interrupt -- it doesn't
get cleared by writing to the SATAINTSTAT register in the interrupt mode we use.
Also, in sata_rcar_ata_interrupt() we should check SATAINTSTAT register only for
enabled interrupts and we should clear only those interrupts that we have read
as active first time around, because else we have a race and risk clearing an
interrupt that can occur between read and write of the SATAINTSTAT register
and never registering it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
|
|
This patch addresses kernel bug 56661. BIOS reports an incorrect
backlight value, causing the driver to switch off the backlight
completely during startup. This patch ignores the incorrect value from
BIOS.
References: https://bugzilla.kernel.org/show_bug.cgi?id=56661
Signed-off-by: Ash Willis <ashwillis@programmer.net>
Cc: All <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
On HP m4 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.
References: https://bugs.launchpad.net/bugs/1184501
Cc: All <stable@vger.kernel.org>
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
HP wmi platform driver fails to initialize GPS and causes poweroff
failure in HP Elitebook 6930p.
Call Trace:
[<ffffffffa088d25a>] hp_wmi_bios_setup+0x25a/0x3a0 [hp_wmi]
[<ffffffff8135978c>] platform_drv_probe+0x3c/0x70
[<ffffffff81356d6a>] ? driver_sysfs_add+0x7a/0xb0
[<ffffffff81357407>] driver_probe_device+0x87/0x3a0
[<ffffffff813577f3>] __driver_attach+0x93/0xa0
[<ffffffff81357760>] ? __device_attach+0x40/0x40
[<ffffffff81355403>] bus_for_each_dev+0x63/0xa0
[<ffffffff81356e8e>] driver_attach+0x1e/0x20
[<ffffffff81356a28>] bus_add_driver+0x1f8/0x2b0
[<ffffffff81357e81>] driver_register+0x71/0x150
[<ffffffff813594e6>] platform_driver_register+0x46/0x50
[<ffffffff813595ab>] platform_driver_probe+0x1b/0xa0
[<ffffffffa088d55e>] hp_wmi_init+0x1be/0x1fb [hp_wmi]
[<ffffffffa088d3a0>] ? hp_wmi_bios_setup+0x3a0/0x3a0 [hp_wmi]
[<ffffffff8100210a>] do_one_initcall+0x10a/0x160
[<ffffffff810bdac6>] load_module+0x1b46/0x2640
[<ffffffff8128da20>] ? ddebug_proc_write+0xf0/0xf0
[<ffffffff810be662>] sys_init_module+0xa2/0xf0
[<ffffffff814d975d>] system_call_fastpath+0x1a/0x1f
Code: 48 ff ff ff 80 7b 24 00 74 d2 41 83 e5 01 45 38 ec 74 c9 48 8d bb a0 03 00 00 e8 ed fb aa e0 5b 41 5c 41 5d 44 89 f0 41 5e 5d c3 <0f> 0b 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66
RIP [<ffffffffa05c57af>] rfkill_set_hw_state+0x9f/0xb0 [rfkill]
RSP <ffff880071523b60>
Check code and find this error is caused by misusing variable bluetooth_rfkill
where gps_rfkill should be.
Reported-and-tested-by: Iru Cai <mytbk920423@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=58401
Cc: All <stable@vger.kernel.org>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fixes from Helge Deller:
"This patcheset includes fixes for:
- the PCI/LBA which brings back the stifb graphics framebuffer
console
- possible memory overflows in parisc kernel init code
- parport support on older GSC machines
- avoids that users by mistake enable PARPORT_PC_SUPERIO on parisc
- MAINTAINERS file list updates for parisc."
* 'for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: parport0: fix this legacy no-device port driver!
parport_pc: disable PARPORT_PC_SUPERIO on parisc architecture
parisc/PCI: lba: fix: convert to pci_create_root_bus() for correct root bus resources (v2)
parisc/PCI: Set type for LBA bus_num resource
MAINTAINERS: update parisc architecture file list
parisc: kernel: using strlcpy() instead of strcpy()
parisc: rename "CONFIG_PA7100" to "CONFIG_PA7000"
parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50
parisc: memory overflow, 'name' length is too short for using
|
|
Fix the above kernel error from parport_announce_port() on 32bit GSC
machines (e.g. B160L). The parport driver requires now a pointer to the
device struct.
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
If enabled, CONFIG_PARPORT_PC_SUPERIO scans on PC-like hardware for
various super-io chips by accessing i/o ports in a range which will
crash any parisc hardware at once.
In addition, parisc has it's own incompatible superio chip
(CONFIG_SUPERIO), so if we disable PARPORT_PC_SUPERIO completely for
parisc we can avoid that people by accident enable the parport_pc
superio option too.
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
resources (v2)
commit dc7dce280a
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Fri Oct 28 16:27:27 2011 -0600
parisc/PCI: lba: convert to pci_create_root_bus() for correct root bus
resources
Supply root bus resources to pci_create_root_bus() so they're correct
immediately. This fixes the problem of "early" and "header" quirks seeing
incorrect root bus resources.
added tests for elmmio_space.start while it should use
elmmio_space.flags. This for example led to incorrect resource
assignments and a non-working stifb framebuffer on most parisc machines.
LBA 10:1: PCI host bridge to bus 0000:01
pci_bus 0000:01: root bus resource [io 0x12000-0x13fff] (bus address [0x2000-0x3fff])
pci_bus 0000:01: root bus resource [mem 0xfffffffffa000000-0xfffffffffbffffff] (bus address [0xfa000000-0xfbffffff])
pci_bus 0000:01: root bus resource [mem 0xfffffffff4800000-0xfffffffff4ffffff] (bus address [0xf4800000-0xf4ffffff])
pci_bus 0000:01: root bus resource [??? 0x00000001 flags 0x0]
Signed-off-by: Helge Deller <deller@gmx.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The non-PAT resource probing code failed to set the type of the LBA bus_num
resource (30aa80da43 "parisc/PCI: register busn_res for root buses" did
the corresponding thing for the PAT case).
This causes incorrect resource assignments and a non-working stifb
framebuffer on most parisc machines.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Pull scsi target fixes from Nicholas Bellinger:
"The highlights include:
- Re-instate sess->wait_list in target_wait_for_sess_cmds() for
active I/O shutdown handling in fabrics using se_cmd->cmd_kref
- Make ib_srpt call target_sess_cmd_list_set_waiting() during session
shutdown
- Fix FILEIO off-by-one READ_CAPACITY bug for !S_ISBLK export
- Fix iscsi-target login error heap buffer overflow (Kees)
- Fix iscsi-target active I/O shutdown handling regression in
v3.10-rc1
A big thanks to Kees Cook for fixing a long standing login error
buffer overflow bug.
All patches are CC'ed to stable with the exception of the v3.10-rc1
specific regression + other minor target cleanup."
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
iscsi-target: Fix iscsit_free_cmd() se_cmd->cmd_kref shutdown handling
target: Propigate up ->cmd_kref put return via transport_generic_free_cmd
iscsi-target: fix heap buffer overflow on error
target/file: Fix off-by-one READ_CAPACITY bug for !S_ISBLK export
ib_srpt: Call target_sess_cmd_list_set_waiting during shutdown_session
target: Re-instate sess_wait_list for target_wait_for_sess_cmds
target: Remove unused wait_for_tasks bit in target_wait_for_sess_cmds
|
|
Pull clock subsystem fixes from Mike Turquette:
"A mix of small fixes affecting mostly ARM platforms as well as a
discrete clock expander chip. Most fixes are corrections to lousy
clock data of one form or another."
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux:
clk: mxs: Include clk mxs header file
clk: vt8500: Fix unbalanced spinlock in vt8500_dclk_set_rate()
clk: si5351: Set initial clkout rate when defined in platform data.
clk: si5351: Fix clkout rate computation.
clk: samsung: Add CLK_IGNORE_UNUSED flag for the sysreg clocks
clk: ux500: clk-sysctrl: handle clocks with no parents
clk: ux500: Provide device enumeration number suffix for SMSC911x
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev
Pull fbdev fixes from Jean-Christophe PLAGNIOL-VILLARD:
"This contains some small fixes
- Atmel LCDC: fix blank the backlight on remove
- ps3fb: fix compile warning
- OMAPDSS: Fix crash with DT boot"
* tag 'fbdev-for-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev:
atmel_lcdfb: blank the backlight on remove
trivial: atmel_lcdfb: add missing error message
OMAPDSS: Fix crash with DT boot
fbdev/ps3fb: fix compile warning
|
