08 Jan, 2011
40 commits
-
commit c6c14330717f9850b4b4c054b81424b9979cd07d upstream.
Signed-off-by: Jean-François Moine
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit b2272a49e7df37732d73988f00468ce31e1ebc92 upstream.
The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
value as other webcams with the same sensor. For now, only two webcams have
been so detected: the Microsoft's VX1000 and VX3000.Signed-off-by: Jean-François Moine
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 229bd792be0bad245b78ed8f119952733a4752e5 upstream.
The interrupt handler takes a lock - but since commit bcad6e80f3f this
lock goes through an indirection specified in the hermes_t structure.
We must therefore initialise the structure before setting up the
interrupt handler.Fix orinoco_cs and spectrum_cs
Bisected by: Matt Domsch
Signed-off by: David Kilroy
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit a757ee2216211278680dd8ac869aabe7b4a9970d upstream.
Drivers should append their name on exported symbols, to avoid
conflicts with allyesconfig:drivers/staging/built-in.o: In function `format_by_fourcc':
/home/v4l/work_trees/linus/drivers/staging/cx25821/cx25821-video.c:96: multiple definition of `format_by_fourcc'
drivers/media/built-in.o:/home/v4l/work_trees/linus/drivers/media/common/saa7146_video.c:88: first defined hereLet's rename both occurences with a small shellscript:
for i in drivers/staging/cx25821/*.[ch]; do sed s,format_by_fourcc,cx25821_format_by_fourcc,g a && mv a $i; done
for i in drivers/media/common/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g a && mv a $i; done
for i in include/media/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g a && mv a $i; doneSigned-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 42cc37fe20cc680fb58fe12ae5ba718d683b8ca2 upstream.
When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we get
the inverted behaviour.Signed-off-by: Baruch Siach
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit e0a70217107e6f9844628120412cb27bb4cea194 upstream.
posix-cpu-timers.c correctly assumes that the dying process does
posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD
timers from signal->cpu_timers list.But, it also assumes that timer->it.cpu.task is always the group
leader, and thus the dead ->task means the dead thread group.This is obviously not true after de_thread() changes the leader.
After that almost every posix_cpu_timer_ method has problems.It is not simple to fix this bug correctly. First of all, I think
that timer->it.cpu should use struct pid instead of task_struct.
Also, the locking should be reworked completely. In particular,
tasklist_lock should not be used at all. This all needs a lot of
nontrivial and hard-to-test changes.Change __exit_signal() to do posix_cpu_timers_exit_group() when
the old leader dies during exec. This is not the fix, just the
temporary hack to hide the problem for 2.6.37 and stable. IOW,
this is obviously wrong but this is what we currently have anyway:
cpu timers do not work after mt exec.In theory this change adds another race. The exiting leader can
detach the timers which were attached to the new leader. However,
the window between de_thread() and release_task() is small, we
can pretend that sys_timer_create() was called before de_thread().Signed-off-by: Oleg Nesterov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 5cdd2de0a76d0ac47f107c8a7b32d75d25768dc1 upstream.
In arch/x86/kernel/microcode_intel.c::generic_load_microcode()
we have this:while (leftover) {
...
if (get_ucode_data(mc, ucode_ptr, mc_size) ||
microcode_sanity_check(mc) < 0) {
vfree(mc);
break;
}
...
}if (mc)
vfree(mc);This will cause a double free of 'mc'. This patch fixes that by
just removing the vfree() call in the loop since 'mc' will be
freed nicely just after we break out of the loop.There's also a second change in the patch. I noticed a lot of
checks for pointers being NULL before passing them to vfree().
That's completely redundant since vfree() deals gracefully with
being passed a NULL pointer. Removing the redundant checks
yields a nice size decrease for the object file.Size before the patch:
text data bss dec hex filename
4578 240 1032 5850 16da arch/x86/kernel/microcode_intel.o
Size after the patch:
text data bss dec hex filename
4489 240 984 5713 1651 arch/x86/kernel/microcode_intel.oSigned-off-by: Jesper Juhl
Acked-by: Tigran Aivazian
Cc: Shaohua Li
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit e692cb668fdd5a712c6ed2a2d6f2a36ee83997b4 upstream.
When stacking devices, a request_queue is not always available. This
forced us to have a no_cluster flag in the queue_limits that could be
used as a carrier until the request_queue had been set up for a
metadevice.There were several problems with that approach. First of all it was up
to the stacking device to remember to set queue flag after stacking had
completed. Also, the queue flag and the queue limits had to be kept in
sync at all times. We got that wrong, which could lead to us issuing
commands that went beyond the max scatterlist limit set by the driver.The proper fix is to avoid having two flags for tracking the same thing.
We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the
block layer merging functions. The queue_limit 'no_cluster' is turned
into 'cluster' to avoid double negatives and to ease stacking.
Clustering defaults to being enabled as before. The queue flag logic is
removed from the stacking function, and explicitly setting the cluster
flag is no longer necessary in DM and MD.Reported-by: Ed Lin
Signed-off-by: Martin K. Petersen
Acked-by: Mike Snitzer
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit f26f9aff6aaf67e9a430d16c266f91b13a5bff64 upstream.
idle_balance() drops/retakes rq->lock, leaving the previous task
vulnerable to set_tsk_need_resched(). Clear it after we return
from balancing instead, and in setup_thread_stack() as well, so
no successfully descheduled or never scheduled task has it set.Need resched confused the skip_clock_update logic, which assumes
that the next call to update_rq_clock() will come nearly immediately
after being set. Make the optimization robust against the waking
a sleeper before it sucessfully deschedules case by checking that
the current task has not been dequeued before setting the flag,
since it is that useless clock update we're trying to save, and
clear unconditionally in schedule() proper instead of conditionally
in put_prev_task().Signed-off-by: Mike Galbraith
Reported-by: Bjoern B. Brandenburg
Tested-by: Yong Zhang
Signed-off-by: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit e03fa055bc126e536c7f65862e08a9b143138ea9 upstream.
Sjoerd Simons reports that, without using position_fix=1, recording
experiences overruns. Work around that by applying the LPIB quirk
for his hardware.Reported-and-tested-by: Sjoerd Simons
Signed-off-by: Daniel T Chen
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit b51aff057c9d0ef6c529dc25fd9f775faf7b6c63 upstream.
Under memory pressure, the mac80211 mesh code
may helpfully print a message that it failed
to clone a mesh frame and then will proceed
to crash trying to use it anyway. Fix that.Signed-off-by: Johannes Berg
Acked-by: Javier Cardona
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 687a993339c4f3a63654746230da3aab8bbdbffd upstream.
While separating out BMDMA irq handler from SFF, commit c3b28894
(libata-sff: separate out BMDMA irq handler) incorrectly made
__ata_sff_port_intr() consider an IRQ to be an idle one if the host
state was transitioned to HSM_ST_ERR by ata_bmdma_port_intr().This makes BMDMA drivers ignore IRQs reporting host bus error which
leads to timeouts instead of triggering EH immediately. Fix it by
making __ata_sff_port_intr() consider the IRQ to be an idle one iff
the state is HSM_ST_IDLE. This is equivalent to adding HSM_ST_ERR to
the "break"ing case but less error-prone.Signed-off-by: Tejun Heo
Reported-by: Antonio Toma
Signed-off-by: Jeff Garzik
Signed-off-by: Greg Kroah-Hartman -
commit 867c20265459d30a01b021a9c1e81fb4c5832aa9 upstream.
If security_filter_rule_init() doesn't return a rule, then not everything
is as fine as the return code implies.This bug only occurs when the LSM (eg. SELinux) is disabled at runtime.
Adding an empty LSM rule causes ima_match_rules() to always succeed,
ignoring any remaining rules.default IMA TCB policy:
# PROC_SUPER_MAGIC
dont_measure fsmagic=0x9fa0
# SYSFS_MAGIC
dont_measure fsmagic=0x62656572
# DEBUGFS_MAGIC
dont_measure fsmagic=0x64626720
# TMPFS_MAGIC
dont_measure fsmagic=0x01021994
# SECURITYFS_MAGIC
dont_measure fsmagic=0x73636673< LSM specific rule >
dont_measure obj_type=var_log_tmeasure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ uid=0Thus without the patch, with the boot parameters 'tcb selinux=0', adding
the above 'dont_measure obj_type=var_log_t' rule to the default IMA TCB
measurement policy, would result in nothing being measured. The patch
prevents the default TCB policy from being replaced.Signed-off-by: Mimi Zohar
Cc: James Morris
Acked-by: Serge Hallyn
Cc: David Safford
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 8333f65ef094e47020cd01452b4637e7daf5a77f upstream.
use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function
aquires the spin lock that needed to protect the drivers data.Signed-off-by: Saeed Bishara
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit 3ea3aa8cf67d3bbe00a19b6a4013d19efa7d0f41 upstream.
CPUID's OSXSAVE is a mirror of CR4.OSXSAVE bit. We need to update the CPUID
after migration.KVM-Stable-Tag.
Signed-off-by: Sheng Yang
Signed-off-by: Avi Kivity
Signed-off-by: Greg Kroah-Hartman -
commit 24d1b15f72abe3465e871d11cfc9dc34d1aab8b2 upstream.
To support xsave properly for the guest the SVM module need
software support for it. As long as this is not present do
not report the xsave as supported feature in cpuid.
As a side-effect this patch moves the bit() helper function
into the x86.h file so that it can be used in svm.c too.KVM-Stable-Tag.
Signed-off-by: Joerg Roedel
Signed-off-by: Avi Kivity
Signed-off-by: Greg Kroah-Hartman -
commit 73c1160ce377d8fc6d84cb630ebf9658808bec49 upstream.
Currently the number of CPUID leaves KVM handles is limited to 40.
My desktop machine (AthlonII) already has 35 and future CPUs will
expand this well beyond the limit. Extend the limit to 80 to make
room for future processors.KVM-Stable-Tag.
Signed-off-by: Andre Przywara
Signed-off-by: Avi Kivity
Signed-off-by: Greg Kroah-Hartman -
commit d81a12bc29ae4038770e05dce4ab7f26fd5880fb upstream.
The load_mixer_volumes() function, which can be triggered by
unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to
a buffer overflow. Because the provided "name" argument isn't
guaranteed to be NULL terminated at the expected 32 bytes, it's possible
to overflow past the end of the last element in the mixer_vols array.
Further exploitation can result in an arbitrary kernel write (via
subsequent calls to load_mixer_volumes()) leading to privilege
escalation, or arbitrary kernel reads via get_mixer_levels(). In
addition, the strcmp() may leak bytes beyond the mixer_vols array.Signed-off-by: Dan Rosenberg
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit ebb76ce16daf6908dc030dec1c00827d37129fe5 upstream.
At __mem_cgroup_try_charge(), VM_BUG_ON(!mm->owner) is checked.
But as commented in mem_cgroup_from_task(), mm->owner can be NULL
in some racy case. This check of VM_BUG_ON() is bad.A possible story to hit this is at swapoff()->try_to_unuse(). It passes
mm_struct to mem_cgroup_try_charge_swapin() while mm->owner is NULL. If we
can't get proper mem_cgroup from swap_cgroup information, mm->owner is used
as charge target and we see NULL.Cc: Daisuke Nishimura
Cc: KOSAKI Motohiro
Reported-by: Hugh Dickins
Reported-by: Thomas Meyer
Signed-off-by: KAMEZAWA Hiroyuki
Reviewed-by: Balbir Singh
Signed-off-by: Hugh Dickins
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 63ee41d794d9c555f84205517a68509848988760 upstream.
The IPS driver is designed to be able to run detached from i915 and
just not enable GPU turbo in that case, in order to avoid module
dependencies between the two drivers. This means that we don't know
what the load order between the two is going to be, and we had
previously only supported IPS after (optionally) i915, but not i915
after IPS. If the wrong order was chosen, you'd get no GPU turbo, and
something like half the possible graphics performance.Signed-off-by: Eric Anholt
Signed-off-by: Chris Wilson
Signed-off-by: Greg Kroah-Hartman -
commit 8316f33766a82907c694267ff911e45e256f09f9 upstream.
The DisplayPort standard (1.1a) states that:
The I2C-over-AUX Reply field is valid only when Native AUX CH Reply
field is AUX_ACK (00). When Native AUX CH Reply field is not 00, then,
I2C-over-AUX Reply field must be 00 and be ignored.This fixes broken EDID reading when using an active DisplayPort to
duallink DVI converter. If the AUX CH replier chooses to defer the
transaction, a short read occurs and erroneous data is returned as
the i2c reply due to a lack of length checking and failure to check
for AUX ACK.As a result, broken EDIDs can look like:
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: bc bc bc ff bc bc bc ff bc bc bc ac bc bc bc 45 ???.???.???????E
10: bc bc bc 10 bc bc bc 34 bc bc bc ee bc bc bc 4c ???????4???????L
20: bc bc bc 50 bc bc bc 00 bc bc bc 40 bc bc bc 00 ???P???.???@???.
30: bc bc bc 01 bc bc bc 01 bc bc bc a0 bc bc bc 40 ???????????????@
40: bc bc bc 00 bc bc bc 00 bc bc bc 00 bc bc bc 55 ???.???.???.???U
50: bc bc bc 35 bc bc bc 31 bc bc bc 20 bc bc bc fc ???5???1??? ????
60: bc bc bc 4c bc bc bc 34 bc bc bc 46 bc bc bc 00 ???L???4???F???.
70: bc bc bc 38 bc bc bc 11 bc bc bc 20 bc bc bc 20 ???8??????? ???
80: bc bc bc ff bc bc bc ff bc bc bc ff bc bc bc ff ???.???.???.???.
...which can lead to:
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
30 30 30 30 30 30 30 32 38 32 30 32 63 63 31 61 000000028202cc1a
28 00 02 8c 00 00 00 00 18 00 00 00 00 00 00 00 (...............
20 4c 61 73 74 20 62 65 61 63 6f 6e 3a 20 33 32 Last beacon: 32
32 30 6d 73 20 61 67 6f 46 00 05 8c 00 00 00 00 20ms agoF.......
36 00 00 00 00 00 00 00 00 0c 57 69 2d 46 69 20 6.........Wi-Fi
52 6f 75 74 65 72 01 08 82 84 8b 96 24 30 48 6c Router......$0Hl
03 01 01 06 02 00 00 2a 01 00 2f 01 00 32 04 0c .......*../..2..
12 18 60 dd 09 00 10 18 02 00 00 01 00 00 18 00 ..`.............Signed-off-by: David Flynn
[ickle: fix up some surrounding checkpatch warnings]
Signed-off-by: Chris Wilson
Signed-off-by: Greg Kroah-Hartman -
commit a93f344d3c04e4b84490c65f2a574387c593be40 upstream.
On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed. Re-program
the mode first, then reset the dpms state.This fixes the infamous atombios timeouts on resume.
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 9f0c4f9c2f835eee1bbb93f96bf9483d56f1892b upstream.
Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 86f5c9edbb3bac37cc8cee6528a929005ba72aad upstream.
This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit bd7c72ed18d719c1fb0fdf6ff9042d8ab78fdf71 upstream.
Without this the IRQ base will not be correctly configured for the
subdevices.Signed-off-by: Mark Brown
Signed-off-by: Samuel Ortiz
Signed-off-by: Greg Kroah-Hartman -
commit b93cef556162b0f33399bfe5f307c54f51554e09 upstream.
Some newer device revisions add a second parent ID. Support this in
the device validity checks done at startup.Signed-off-by: Mark Brown
Signed-off-by: Samuel Ortiz
Signed-off-by: Greg Kroah-Hartman -
commit c7c25802b39c443b3745cfa973dc49a97a3491f8 upstream.
Disable preemption in init_ibs(). The function only checks the
ibs capabilities and sets up pci devices (if necessary). It runs
only on one cpu but operates with the local APIC and some MSRs,
thus it is better to disable preemption.[ 7.034377] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/483
[ 7.034385] caller is setup_APIC_eilvt+0x155/0x180
[ 7.034389] Pid: 483, comm: modprobe Not tainted 2.6.37-rc1-20101110+ #1
[ 7.034392] Call Trace:
[ 7.034400] [] debug_smp_processor_id+0xd2/0xf0
[ 7.034404] [] setup_APIC_eilvt+0x155/0x180
[ ... ]Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22812
Reported-by:
Signed-off-by: Robert Richter
Cc: oprofile-list@lists.sourceforge.net
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Rafael J. Wysocki
Cc: Dan Carpenter
Cc: Andrew Morton
LKML-Reference:
[ small cleanups ]
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 551423748a4eba55f2eb0fc250d757986471f187 upstream.
The error message 'NMI watchdog failed to create perf event...'
does not make it clear that this is a fatal error for the
watchdog. It also currently prints the error value as a
pointer, rather than extracting the error code with PTR_ERR().
Fix that.Add a note to the description of the 'nowatchdog' kernel
parameter to associate it with this message.Reported-by: Cesare Leonardi
Signed-off-by: Ben Hutchings
Cc: 599368@bugs.debian.org
Cc: 608138@bugs.debian.org
Cc: Don Zickus
Cc: Frederic Weisbecker
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 3b3c1f24e96c411a95daabb6af9e09c5381f713b upstream.
rdc321x-wdt currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.Signed-off-by: Florian Fainelli
Signed-off-by: Samuel Ortiz
Signed-off-by: Greg Kroah-Hartman -
commit 1873bb8115e678ad9fd0aac9dbbc68383bc36e06 upstream.
The current code mis-calculates the ramoops header size, leading to an
overflow over the next record at best, or over a non-allocated region at
worst. Fix that calculation.Signed-off-by: Ahmed S. Darwish
Acked-by: Marco Stornelli
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 118364948fad7b6c0469ef2d3ddaee447d7a0b5f upstream.
Match the buffer size to the amount of initialized values. Before, it was
one too big and thus destroyed the neighbouring register causing the clock
to run at false speeds.Reported-by: Andre van Rooyen
Signed-off-by: Wolfram Sang
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 4ef9e11d6867f88951e30db910fa015300e31871 upstream.
When racing on adding into user cache, the new allocated from mm slab
is freed without putting user namespace.Since the user namespace is already operated by getting, putting has
to be issued.Signed-off-by: Hillf Danton
Acked-by: Serge Hallyn
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 274476f8fe0b6ac9bac542cc39de12c3dd0f43f6 upstream.
In the error-path where PM notifies PM_POST_RESTORE, the rescan-blockage
should be cleared as well. Otherwise it'll be never re-probed.Also, as a bonus, this fixes a bug in S4 with user-mode suspend in the
current code, as it sends PM_POST_RESTORE instead of
PM_POST_HIBERNATION wrongly.Signed-off-by: Takashi Iwai
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 2f1d791882d21a4002a719fb016a1ac21c8bd6b7 upstream.
Based on report made by Yauhen in:
"MMC: Fix multiblock SDIO transfers in AT91 MCI" patch,
I report those changes to the brother driver: atmel-mci.So, this patch sets SDIO transfer types: SDIO block and SDIO byte
transfers instead of using ordinary MMC block transfers.
It is checking opcode for SDIO CMD53 and setting transfer
type in MCI_CMDR register properly.Reported-by: Yauhen Kharuzhy
Signed-off-by: Nicolas Ferre
Acked-by: Jean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit a2255ff45143001fecbc5e5a4b58fcb999d393ae upstream.
The AT91 MCI has special SDIO transfer types: SDIO block and SDIO byte
transfers, but at91_mci driver doesn't use them and handles all SDIO
transfers as ordinary MMC block transfers. This causes problems for
multiple-block SDIO transfers (in particular for 256-bytes blocks).Fix this situation by checking the opcode for SDIO CMD53 and setting
the transfer type in the AT91_MCI_CMDR register properly.This patch was tested with libertas SDIO driver: problem with TX
timeouts on big packets was eliminated.Signed-off-by: Yauhen Kharuzhy
Signed-off-by: Nicolas Ferre
Acked-by: Jean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 44658a11f312fb9217674cb90b1a11cbe17fd18d upstream.
The default for non-READ_BACK GPIO regs is to have the clear bits set;
this means that our original errata fix was too simplistic. This
changes it to the following behavior:- when setting GPIOs, ignore the higher order bits (they're for
clearing, we don't need to care about them).- when clearing GPIOs, keep all the bits, but unset (via XOR) the
lower order bit that negates the clear bit that we care about. That
is, if we're clearing GPIO 26 (val = 0x04000000), we first XOR what's
currently in the register with 0x0400 (GPIO 26's SET bit), and then
OR that with the GPIO 26's CLEAR bit.Tested-by: Daniel Drake
Signed-off-by: Andres Salomon
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 001851659354cce436b749a793f3512a53394d80 upstream.
The edge detect status GPIOs function differently from the other atomic
model CS5536 GPIO registers; writing 1 to the high bits clears the GPIO,
but writing 1 to the lower bits also clears the bit.This means that read-modify-write doesn't actually work for it, so don't
apply the errata here. If a negative edge status gets lost after
resume.. well, we tried our best!Tested-by: Daniel Drake
Signed-off-by: Andres Salomon
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit fa6469cb5b2d16703464c344b943e2c025cb7858 upstream.
rdc321x-gpio currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.Signed-off-by: Florian Fainelli
Signed-off-by: Samuel Ortiz
Signed-off-by: Greg Kroah-Hartman -
commit f8bbeabc34aa945ab4275abc9a4dfde0aea798ca upstream.
Fix two bugs with the port array setup.
The first bug will only show up with broken xHCI hosts with Extended
Capabilities registers that have duplicate port speed entries for the same
port. The idea with the original code was to set the port_array entry to
-1 if the duplicate port speed entry said the port was a different speed
than the original port speed entry. That would mean that later, the port
would not be exposed to the USB core. Unfortunately, I forgot a continue
statement, and the port_array entry would just be overwritten in the next
line.The second bug would happen if there are conflicting port speed registers
(so that some entry in port_array is -1), or one of the hardware port
registers was not described in the port speed registers (so that some
entry in port_array is 0). The code that sets up the usb2_ports array
would accidentally claim those ports. That wouldn't really cause any
user-visible issues, but it is a bug.This patch should go into the stable trees that have the port array and
USB 3.0 port disabling prevention patches.Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman
