| Age | Commit message (Collapse) | Author |
|---|
|
If a bitmap is added while the array is active, it is possible
for bitmap_daemon_work to run while the bitmap is being
initialised.
This is particularly a problem if bitmap_daemon_work sees
bitmap->filemap as non-NULL before it has been filled in properly.
So hold bitmap_info.mutex while filling in ->filemap
to prevent problems.
This patch is suitable for any -stable kernel, though it might not
apply cleanly before about 3.1.
Cc: stable@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
If r1bio->sectors % 8 != 0,then the memcmp and a later
memcpy will omit the last bio_vec.
This is suitable for any stable kernel since 3.1 when bad-block
management was introduced.
Cc: stable@vger.kernel.org
Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
bitmap_new_disk_sb() would still create V3 bitmap superblock
with host-endian layout.
Perhaps I'm confused, but shouldn't bitmap_new_disk_sb() be
creating a V4 bitmap superblock instead, that is portable,
as per comment in bitmap.h?
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
The struct exynos_drm_manager has to exist for exynos drm sub driver
using encoder and connector. If it isn't NULL to member of struct
exynos_drm_subdrv, will create encoder and connector else will not. And
the is_local member also doesn't need.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The mixer driver and hdmi driver have each operation callback functions
and they is registered to hdmi common driver. Their struct names in hdmi
common driver include display, manager and overlay. It confuses to
appear whose operation and two driver cannot register same operation
callback functions at the same time. Use their struct names to driver
name.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The default_win member in struct mixer_context isn't change its value
after initialized to 0, so it's better using to define.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
HDMI_OVERLAY_NUMBER is specific of mixer driver and be used "windows
layer" term in exynos user manaual, so rename it.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Some members in struct mixer_context aren't used and the define
HDMI_OVERLAY_NUMBER is unused in hdmi driver, remove them.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
When the void pointer type variable is assigned to the specific pointer
type variable, don't need to do type conversion.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
If, in drivers/input/misc/da9052_onkey.c::da9052_onkey_probe(), the
call to either kzalloc() or input_allocate_device() fails then we will
return -ENOMEM from the function without freeing the other allocation
that may have succeeded, thus we leak either the memory allocated for
'onkey' or the memory allocated for 'input_dev' if one succeeds and
the other fails.
Fix that by jumping to the 'err_free_mem' label at the end of the
function that properly cleans up rather than returning directly.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
This reverts commit b519508298e0292e1771eecf14aaf67755adc39d.
The reason for this revert is that making the frequency verification
preemptible and interruptible is not working reliably. Michaels
machine failed to use PM-timer with the message:
PM-Timer running at invalid rate: 113% of normal - aborting.
That's not a surprise as the frequency verification does rely on
interrupts being disabled. With a async scheduled thread there is no
guarantee to achieve the same result. Also some driver might fiddle
with the CTC channel 2 during the verification period, which makes the
result even more random and unpredictable.
This can be solved by using the same mechanism as we use in the
deferred TSC validation code, but that only will work if we verified a
working HPET _BEFORE_ trying to do the PM-Timer lazy validation.
So for now reverting is the safe option.
Bisected-by: Michael Witten <mfwitten@gmail.com>
Cc: Arjan van de Ven <arjanvandeven@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Len Brown <lenb@kernel.org>
LKML-Reference: <alpine.LFD.2.02.1204112303270.2542@ionos>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
Pull infiniband fixes from Roland Dreier:
"Fix a regression in the /sys/class/infiniband/.../rate attribute --
old kernels used to just return something, even if the underlying
value was out-of-bounds, while 3.4-rc1 returned EINVAL to userspace.
This breaks some applications that check for the error, so go back to
the old behavior."
* tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/core: Don't return EINVAL from sysfs rate attribute for invalid speeds
IB/mlx4: Don't return an invalid speed when a port is down
|
|
People have been getting confused and thinking this is a runtime control.
Cc: stable@vger.kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
In https://bugzilla.kernel.org/show_bug.cgi?id=42976, a system with driver
rtl8192se used as an AP suffers from "Out of SW-IOMMU space" errors. These
are caused by the DMA buffers used for beacons never being unmapped.
This bug was also reported at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961618
Reported-and-Tested-by: Da Xue <da@lessconfused.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
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>
Cc: Stable <stable@vger.kernel.org> [This version good for 3.3+ - different patch for 3.2 - 2.6.39]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
- dvb core: there is a regression found when used with xine. For
whatever unknown reason, xine (and xine-lib clients) wants that the
frontend to tell what frequency he is using even before the PLL lock
(or at least, it expects a non-zero frequency).
On DVB, the frequency is only actually known after a frequency
zig-zag seek, done by the DVB core. Anyway, the fix was trivial.
That solves Fedora BZ#808871.
- ivtv: fix a regression when selecting the language channel
- uvc: fix a race-related crash
- it913x: fixes firmware loading
- two trivial patches (a dependency issue at a radio driver at sound
Kconfig, and a warning fix on dvb).
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] uvcvideo: Fix race-related crash in uvc_video_clock_update()
[media] Drivers/media/radio: Fix build error
[media] dvb_frontend: fix compiler warning
[media] it913x: fix firmware loading errors
[media] ivtv: Fix AUDIO_(BILINGUAL_)CHANNEL_SELECT regression
[media] dvb_frontend: regression fix: userspace ABI broken for xine
|
|
Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
|
|
The caller is allowed to specify the GFP flags for these functions.
We should prefer their flags unless we have good reason. For
example, if we take a spin_lock ourselves we'd need to use
GFP_ATOMIC. But in this case it's safe to use the callers GFP
flags.
The callers all pass GFP_ATOMIC here, so this change doesn't affect
how the kernel behaves but we may add other callers later and this
is a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
The suspend operation of VIA xHCI host have some issues and
hibernate operation works fine, so The XHCI_RESET_ON_RESUME
quirk is added for it.
This patch should base on "xHCI: Don't write zeroed pointer
to xHC registers" that is released by Sarah. Otherwise, the
host system error will ocurr in the hibernate operation
process.
This should be backported to stable kernels as old as 2.6.37,
that contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9
"xhci: Add reset on resume quirk for asrock p67 host".
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
|
|
When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.
The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09
But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40
The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.
This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.
This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore:
refine warm reset logic".
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Acked-by: Andiry Xu <Andiry.Xu@amd.com>
Acked-by: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
|
|
The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering
that the xHCI registers are saved and restored in. It moves the
interrupt pending (IMAN) and interrupt control (IMOD) registers to be
saved and restored last. I believe that's because the host controller
may attempt to fetch the event ring table when interrupts are
re-enabled. Therefore we need to restore the event ring registers
before we re-enable interrupts.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
|
|
The xhci_save_registers() function saved the event ring dequeue pointer
in the s3 register structure, but xhci_restore_registers() never
restored it. No other code in the xHCI successful resume path would
ever restore it either. Fix that.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
|
|
When xhci_mem_cleanup() is called, we can't be sure if the xHC is
actually halted. We can ask the xHC to halt by writing to the RUN bit
in the command register, but that might timeout due to a HW hang.
If the host controller is still running, we should not write zeroed
values to the event ring dequeue pointers or base tables, the DCBAA
pointers, or the command ring pointers. Eric Fu reports his VIA VL800
host accesses the event ring pointers after a failed register restore on
resume from suspend. The hypothesis is that the host never actually
halted before the register write to change the event ring pointer to
zero.
Remove all writes of zeroed values to pointer registers in
xhci_mem_cleanup(). Instead, make all callers of the function reset the
host controller first, which will reset those registers to zero.
xhci_mem_init() is the only caller that doesn't first halt and reset the
host controller before calling xhci_mem_cleanup().
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: stable@vger.kernel.org
|
|
Eric Fu reports a problem with his VIA host controller fetching a zeroed
event ring pointer on resume from suspend. The host should have been
halted, but we can't be sure because that code ignores the return value
from xhci_halt(). Print a warning when the host controller refuses to
halt within XHCI_MAX_HALT_USEC (currently 16 seconds).
(Update: it turns out that the VIA host controller is reporting a halted
state when it fetches the zeroed event ring pointer. However, we still
need this warning for other host controllers.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
While we're at that, define IMAN bitfield to aid readability.
The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it. Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit. Before that commit, we were blindly writing 0x3 to
the register.
This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a36165dbc78b380846b254017a548b9de5 "USB:
xhci: Reduce reads and writes of interrupter registers".
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
|
|
According to an internal workaround master list, we need to set bit 5
of register 9400 to avoid issues with color blits.
Testing shows that this seems to fix the blitter hangs when fbc is
enabled on snb, thanks to Chris Wilson for figuring this out.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Michael "brot" Groh <michael.groh@minad.de>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The 845g shares the errata with i830 whereby executing a command
within 2 cachelines of the end of the ringbuffer may cause a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This reverts commit c3dfefa0a6d235bd465309e12f4c56ea16e71111.
gmbus in 3.4 has simply too many known issues:
- gmbus is too noisy, we need to rework the logging:
https://bugs.freedesktop.org/show_bug.cgi?id=48248
- zero-length writes cause an OOPS, and they are
userspace-triggerable:
https://lkml.org/lkml/2012/3/30/176
- same for zero-length reads:
https://bugs.freedesktop.org/show_bug.cgi?id=48269
We can try again for 3.5.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It seems it can corrupt the monitor EDID in certain cases on certain
boards when running sensors detect. It's rarely used anyway outside
of AIW boards.
http://lists.lm-sensors.org/pipermail/lm-sensors/2012-April/035847.html
http://lists.freedesktop.org/archives/xorg/2011-January/052239.html
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
When no platform_data is present and either 'spi-num-chipselects' is
not defined in the DT or 'cs-gpios' has less entries than
'spi-num-chipselects' specifies, the NULL platform_data pointer is
being dereferenced.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Fixes the following warning when "SAMSUNG EXYNOS5" is not selected:
warning: ‘exynos5_gpios_1’ defined but not used [-Wunused-variable]
warning: ‘exynos5_gpios_2’ defined but not used [-Wunused-variable]
warning: ‘exynos5_gpios_3’ defined but not used [-Wunused-variable]
warning: ‘exynos5_gpios_4’ defined but not used [-Wunused-variable]
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine
Pull dmaengine fixes from Dan Williams:
1/ regression fix for Xen as it now trips over a broken assumption
about the dma address size on 32-bit builds
2/ new quirk for netdma to ignore dma channels that cannot meet
netdma alignment requirements
3/ fixes for two long standing issues in ioatdma (ring size overflow)
and iop-adma (potential stack corruption)
* tag 'dmaengine-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine:
netdma: adding alignment check for NETDMA ops
ioatdma: DMA copy alignment needed to address IOAT DMA silicon errata
ioat: ring size variables need to be 32bit to avoid overflow
iop-adma: Corrected array overflow in RAID6 Xscale(R) test.
ioat: fix size of 'completion' for Xen
|
|
xhci_unregister_pci() is called in xhci_hcd_init().
Signed-off-by: Gerard Snitselaar <dev@snitselaar.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
Correct the print of HSEE of USBCMD in xhci-dbg.c.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
Fix race between probe and open by making sure that the disconnected
flag is not cleared until all ports have been registered.
A call to tty_open while probe is running may get a reference to the
serial structure in serial_install before its ports have been
registered. This may lead to usb_serial_core calling driver open before
port is fully initialised.
With ftdi_sio this result in the following NULL-pointer dereference as
the private data has not been initialised at open:
[ 199.698286] IP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio]
[ 199.698297] *pde = 00000000
[ 199.698303] Oops: 0000 [#1] PREEMPT SMP
[ 199.698313] Modules linked in: ftdi_sio usbserial
[ 199.698323]
[ 199.698327] Pid: 1146, comm: ftdi_open Not tainted 3.2.11 #70 Dell Inc. Vostro 1520/0T816J
[ 199.698339] EIP: 0060:[<f811a089>] EFLAGS: 00010286 CPU: 0
[ 199.698344] EIP is at ftdi_open+0x59/0xe0 [ftdi_sio]
[ 199.698348] EAX: 0000003e EBX: f5067000 ECX: 00000000 EDX: 80000600
[ 199.698352] ESI: f48d8800 EDI: 00000001 EBP: f515dd54 ESP: f515dcfc
[ 199.698356] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 199.698361] Process ftdi_open (pid: 1146, ti=f515c000 task=f481e040 task.ti=f515c000)
[ 199.698364] Stack:
[ 199.698368] f811a9fe f811a9e0 f811b3ef 00000000 00000000 00001388 00000000 f4a86800
[ 199.698387] 00000002 00000000 f806e68e 00000000 f532765c f481e040 00000246 22222222
[ 199.698479] 22222222 22222222 22222222 f5067004 f5327600 f5327638 f515dd74 f806e6ab
[ 199.698496] Call Trace:
[ 199.698504] [<f806e68e>] ? serial_activate+0x2e/0x70 [usbserial]
[ 199.698511] [<f806e6ab>] serial_activate+0x4b/0x70 [usbserial]
[ 199.698521] [<c126380c>] tty_port_open+0x7c/0xd0
[ 199.698527] [<f806e660>] ? serial_set_termios+0xa0/0xa0 [usbserial]
[ 199.698534] [<f806e76f>] serial_open+0x2f/0x70 [usbserial]
[ 199.698540] [<c125d07c>] tty_open+0x20c/0x510
[ 199.698546] [<c10e9eb7>] chrdev_open+0xe7/0x230
[ 199.698553] [<c10e48f2>] __dentry_open+0x1f2/0x390
[ 199.698559] [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[ 199.698565] [<c10e4b76>] nameidata_to_filp+0x66/0x80
[ 199.698570] [<c10e9dd0>] ? cdev_put+0x20/0x20
[ 199.698576] [<c10f3e08>] do_last+0x198/0x730
[ 199.698581] [<c10f4440>] path_openat+0xa0/0x350
[ 199.698587] [<c10f47d5>] do_filp_open+0x35/0x80
[ 199.698593] [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[ 199.698599] [<c10ff110>] ? alloc_fd+0xc0/0x100
[ 199.698605] [<c10f0b72>] ? getname_flags+0x72/0x120
[ 199.698611] [<c10e4450>] do_sys_open+0xf0/0x1c0
[ 199.698617] [<c11fcc08>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 199.698623] [<c10e458e>] sys_open+0x2e/0x40
[ 199.698628] [<c144c990>] sysenter_do_call+0x12/0x36
[ 199.698632] Code: 85 89 00 00 00 8b 16 8b 4d c0 c1 e2 08 c7 44 24 14 88 13 00 00 81 ca 00 00 00 80 c7 44 24 10 00 00 00 00 c7 44 24 0c 00 00 00 00 <0f> b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[ 199.698884] EIP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio] SS:ESP 0068:f515dcfc
[ 199.698893] CR2: 0000000000000078
[ 199.698925] ---[ end trace 77c43ec023940cff ]---
Reported-and-tested-by: Ken Huang <csuhgw@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
of_gpio_simple_xlate() has an off-by-one bug where it checks to see if
args[0] is > ngpio instead of >=. args[0] must always be less than
ngpio because it is a zero-based enumeration.
Signed-off-by: Roland Stigge <stigge@antcom.de>
[grant.likely: beef up commit text]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The variable 'bit' is uninitialized in the first iteration of for
loop. Fix it.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The irqdomain api changed significantly in v3.4 which caused a build
failure for this driver.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Hans J. Koch <hjk@linutronix.de>
Cc: Torben Hohn <torbenh@linutronix.de>
|
|
This reverts commit c1afdaff90538ef085b756454f12b29575411214.
Users have reported connection failures in 3.3.1 and suspend/resume
failures in 3.4-rcX. Revert this commit for now - PS IDLE can be
fixed in a clean manner later on.
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Move rt2x00rfkill_register(rt2x00dev) to rt2x00lib_probe_dev
function. It fixes of starting rfkill_poll function at the
right time if sets hard rfkill block and reboot. rt2x00mac_rfkill_poll
should be starting before bringing up the wireless interface.
Signed-off-by: Chen, Chien-Chia <machen@suse.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
CC: Kevin Chou <kevin.chou@mediatek.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The following is seen during allmodconfig builds for MIPS:
drivers/bcma/driver_pci_host.c:518:2: error: implicit declaration
of function 'pcibios_enable_device' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/bcma/driver_pci_host.o] Error 1
Most likey introduced by commit 49dc9577155576b10ff79f0c1486c816b01f58bf
"bcma: add PCIe host controller"
Add the header instead of implicitly assuming it will be present.
Sounds like a good idea, but that alone doesn't fix anything.
The real problem is that the Kconfig has settings related to whether
PCI is possible, i.e.
config BCMA_HOST_PCI_POSSIBLE
bool
depends on BCMA && PCI = y
default y
config BCMA_HOST_PCI
bool "Support for BCMA on PCI-host bus"
depends on BCMA_HOST_PCI_POSSIBLE
...but what is missing is that BCMA_DRIVER_PCI_HOSTMODE doesn't
have any dependencies on the above. Add one.
CC: Hauke Mehrtens <hauke@hauke-m.de>
CC: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull a regulator build fix from Mark Brown:
"Fix a build warning in the anatop driver for 3.4
This is a trivial rename to stop the build system complaining that
we're referencing things we shouldn't be."
* tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: anatop: fix 'anatop_regulator' name collision
|
|
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Chris Wilson pointed out that we still get things wrong for bpp > 24,
but that should be fixed in another patch (and it'll be easier because
this patch consolidates the logic).
The likely culprit for this regression is
commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2
Author: Keith Packard <keithp@keithp.com>
Date: Wed Jan 25 08:16:25 2012 -0800
drm/i915: Force explicit bpp selection for intel_dp_link_required
v2: Fix indentation and tune down the too bold claim that this should
fix the world. Both noticed by Chris Wilson.
v3: Try to really git add things.
Reported-and-tested-by: Brice Goglin <Brice.Goglin@ens-lyon.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170
Cc: stable@kernel.org
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Image on Z11m cards was totally garbled due to wrong memory being
selected. Add a special handling for Z11m cards. Tested on PCIe Z11 and
Z11m cards.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If gpio_request fails, we need to free all allocated resources.
Current code uses wrong array index to access gpio_data array.
So current code actually frees gpio_data[i].gpio by j times.
This patch moves the error handling code to err_out and thus improves
readability.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
m68k doesn't have memblock_reserve, which causes a build failure
with allmodconfig. Make PERSISTENT_RAM and RAM_CONSOLE depend on
HAVE_MEMBLOCK.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
i2c client data set is of type struct indio_dev pointer and hence the
pointer returned from i2c_get_clientdata() should be assigned to
an object of type struct indio_dev and not to an object of type
struct ak8975_data.
Also in ak8975_probe() client data should be set first
before calling ak8975_setup() as it references the client data.
Signed-off-by: Preetham Chandru R <pchandru@nvidia.com>
CC: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Not sure what triggered the change in behavior, but seems to
result in recursively acquiring a mutex and hanging on boot. But
omap_drm_init() seems a much more sane place to register the
driver for the DMM sub-device.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This patch fixes a memory leak in zsmalloc where the first
subpage of each zspage is leaked when the zspage is freed.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Acked-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
I already fixed the other similar for loop in this file. I'm not sure
how I missed this one. We use seg_no+1 inside the loop so we can't go
right up to the end of the loop.
Also if we don't break out of the loop then we end up past the end of
the array, but with this fix we end up on the last element.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
