Certain revisions of the vbios on DCE3.2 cards have a bug
in the transmitter control table which prevents duallink from
being enabled properly on some cards. The action switch statement
jumps to the wrong offset for the OUTPUT_ENABLE action. The fix
is to use the ENABLE action rather than the OUTPUT_ENABLE action
on the affected cards. In fixed version of the vbios, both
actions jump to the same offset, so the change should be safe.
Reported-and-tested-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Its illegal to dereference skb after dev_kfree_skb(skb)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Robin Holt <holt@sgi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As soon as skb is given to hardware and spinlock released, TX completion
can free skb under us. Therefore, we should update netdev stats before
spinlock release.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Otherwise we will not see the name of the slave dev in error
message:
[ 388.469446] (null): doesn't support polling, aborting.
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
MMC host drivers must be able to process interrupts during
mmc_remove_host().
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Provide a dummy value of NO_IRQ for architectures that don't support
it (such as MIPS). Fixes the build error for MIPS.
Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Chris Ball <cjb@laptop.org>
According to the data sheet for G4, AP4 and AG5 KEYSC MODE_6 is 8x8 keys.
Bump up MAXKEYS to 64 too.
Signed-off-by: Magnus Damm <damm@opensource.se>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Otherwise the updated evdev driver (commit cdda911c34,
"Input: evdev - only signal polls on full packets") no longer works on
top of omap-keypad.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
We should only wake waiters on the event device when we actually post
an EV_SYN/SYN_REPORT to the queue. Otherwise we end up making waiting
threads runnable only to go right back to sleep because the device
still isn't readable.
Reported-by: Jeffrey Brown <jeffbrown@android.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Call sysfs_attr_init() from atk_init_attribute() to handle sysfs attribute
initialization in a single function.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
pdev_entry.cpu and pdev_entry.cpu_core_id aren't used anywhere in the
driver code so we can drop these struct members.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
The DDX modifies DMA_SEMAPHORE on nv50 in order to implement sync-to-vblank,
things will go very wrong for cross-channel sync after this.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
While parsing the perf table, there is no check if
the num of entries read from the vbios is less than
the currently allocated number.
In case of a buggy vbios this will cause overwriting
of kernel memory, causing aditional problems.
Add a simple check in order to prevent the case
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] powernow-k8: Don't try to transition if the pstate is incorrect
[CPUFREQ] powernow-k8: Don't notify of successful transition if we failed (vid case).
[CPUFREQ] Don't set stat->last_index to -1 if the pol->cur has incorrect value.
The failure appeared in dmesg as:
[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
ring idle [waiting on 35064155, at 35064155], missed IRQ?
This works around that problem on by making the blitter command
streamer write interrupt state to the Hardware Status Page when a
MI_USER_INTERRUPT command is decoded, which appears to force the seqno
out to memory before the interrupt happens.
v1->v2: Moved to prior interrupt handler installation and RMW flags as
per feedback.
v2->v3: Removed RMW of flags (by anholt)
Cc: stable@kernel.org
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1]
Tested-by: Eric Anholt <eric@anholt.net> [v1,v3]
(incidence of the bug with a testcase went from avg 2/1000 to
0/12651 in the latest test run (plus more for v1))
Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394
Signed-off-by: Dave Airlie <airlied@redhat.com>
if_open() calls try_module_get(), and after an attempt to lock a mutex
the if_open() function may return -ERESTARTSYS without
putting the module. Then, when if_open() is executed again,
try_module_get() is called making the reference counter of THIS_MODULE
greater than one at successful exit from if_open(). The if_close()
function puts the module only once, and as a result it can't be
unloaded.
This patch adds module_put call before the return from if_open().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Pavel Shved <shved@ispras.ru>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
The fst_open() function, after a successful try_module_get() may return
an error code if hdlc_open() returns it. However, it does not put the
module on this error path.
This patch adds the necessary module_put() call.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Pavel Shved <shved@ispras.ru>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
The RIPTR and TIPTR (receive/transmit internal temporary data pointer),
used by microcode as a temporary buffer for data, must be 32-byte aligned
according to the RM for MPC8247.
Tested on mgcoge.
Signed-off-by: Clive Stubbings <clive.stubbings@xentech.co.uk>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
cc: Vitaly Bordug <vbordug@ru.mvista.com>
cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
Due to timing, it is possible for the LOS and DFE to remain on. This
is due to the link progressing to LinkUP prior to the driver getting
the first Status Changed interrupt. By expanding the conditions under
which LOS is turned off and DFE timeout is being set, timing is no
longer an issue.
Signed-off-by: Mitko Haralanov <mitko@qlogic.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@qlogic.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
- fix a race where the driver could end up sending a close_con_req
after an abort_rpl. In c4iw_ep_disconnect(), send abort or close
request with the ep mutex held.
- fix a hang where driver fails to wake up when a connection is reset
during a normal close. Wake up any waiters in the interrupt path,
and correctly cleanup after rdma_fini() failures.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Remove left-over code from T3 that limited MR sizes to 32b.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Memory allocated for user CQs gets rounded up to the next page
boundary. And after rounding, we recalculate the resulting IQ depth
and we need to make sure we don't exceed the HW limits.
This bug can result a much smaller CQ allocated than was expected if
the HW size field is exceeded, resulting in CQ overflow failures.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is
called. This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.
If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core. That means drivers will see urb->status as -EXDEV.
It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is. See
itd_complete() in ehci-sched.c:
} else {
/* URB was too late */
desc->status = -EXDEV;
}
}
/* handle completion now? */
if (likely ((urb_index + 1) != urb->number_of_packets))
goto done;
/* ASSERT: it's really the last itd for this urb
list_for_each_entry (itd, &stream->td_list, itd_list)
BUG_ON (itd->urb == urb);
*/
/* give urb back to the driver; completion often (re)submits */
dev = urb->dev;
ehci_urb_done(ehci, urb, 0);
ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.
It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value. They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.
Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.
This patch should be backported to kernels as old as 2.6.36
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: stable@kernel.org
The asrock p67 xhci controller completely dies on resume, add a
quirk for this, to bring the host back online after a suspend.
This should be backported to stable kernels as old as 2.6.37.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
It is one new TRB Completion Code for the xHCI spec v1.0.
Asserted if the xHC detects a problem with a device that does not allow it to
be successfully accessed, e.g. due to a device compliance or compatibility
problem. This error may be returned by any command or transfer, and is fatal
as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
of ISOC for transfer case. And return -ENODEV for configure endpoint command,
evaluate context command and address device command if there is an incompatible
Device Error. The error codes will be sent back to the USB core to decide how
to do. It's unnecessary for other commands because after the three commands run
successfully means that the device has been accepted.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* 'gpio/merge' of git://git.secretlab.ca/git/linux-2.6:
gpio: add GPIOF_ values regardless on kconfig settings
gpio: include linux/gpio.h where needed
gpio/omap4: Fix missing interrupts during device wakeup due to IOPAD.
* 'spi/merge' of git://git.secretlab.ca/git/linux-2.6:
spi/bfin_spi: fix handling of default bits per word setting
The default bits per word setting should be 8 bits, but since most of our
devices have been explicitly setting this up, we didn't notice when the
default stopped working.
At the moment, any default transfers without an explicit bit size setting
error out with:
bfin-spi bfin-spi.0: transfer: unsupported bits_per_word
So in the transfer logic, have a bits_per_word setting of 0 fall into the
8 bit transfer logic.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
The size of the desc array is not the size of the desc structure, so
when we try to free up things, we leak some parts.
Reported-by: Regis Dargent <rdargent@edevice.com>
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
Commit 8d8fc29d02 changed the behavior of slave
devices in regards to netpoll. Specifically it created a mutually exclusive
relationship between being a slave and a netpoll-capable device. This creates
problems for KVM because guests relied on needing netconsole active on a slave
device to a bridge. Ideally libvirtd could just attach netconsole to the bridge
device instead, but thats currently infeasible, because while the bridge device
supports netpoll, it requires that all slave interface also support it, but the
tun/tap driver currently does not. The most direct solution is to teach tun/tap
to support netpoll, which is implemented by the patch below.
I've not tested this yet, but its pretty straightforward.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Rik van Riel <riel@redhat.com>
CC: Rik van Riel <riel@redhat.com>
CC: Maxim Krasnyansky <maxk@qualcomm.com>
CC: Cong Wang <amwang@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
Reviewed-by: Rik van Riel <riel@redhat.com>
Tested-by: Rik van Riel <riel@redhat.com>
Reviewed-by: WANG Cong <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
The dp83640 PHY provides time stamp and other information via special
PHY status frames. Previously, the driver decoded the frames and then
let the network stack drop them. This works fine when the PTP messages
come over UDP.
However, when receiving PTP messages via L2 packets, this creates a
problem. The status frames use the official PTP destination MAC address,
and so they are delivered to user space along with the "real" frames,
causing confusion for applications.
This commit fixes the issue by simply dropping the PHY status frames
in the driver.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
If two eternal time stamp events occur at nearly the same time, the
phyter will add an extra word into the status frame. This commit fixes
the parsing code to recognize and skip over the extra word.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
This PHY is available integrated into BCM63xx series SOCs only.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
drivers/net/phy/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Acked-by: Florian Fainelli <ffainelli@freebox.fr>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
It has also an ACM interface that previous patches associates with the "option"
module. To access those interfaces, the modem must first be switched from modem
mode using a tool like usb_modeswitch.
As the proprietary protocol has been discovered by watching the MS Windows driver
behavior, there might be errors in the protocol handling, but stable and fast
connection has been established for hours with Norwegian operator NetCom that
distributes this modem with their LTE/4G subscription.
More and updated information about how to use this driver is available here:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms: use helper functions for fence read/write
drm/radeon/kms: set DP link config properly for DP bridges
drm/radeon/kms/atom: AdjustPixelClock fixes for DP bridges
drm/radeon/kms: fix handling of DP to LVDS bridges
drm/radeon/kms: issue blank/unblank commands for ext encoders
drm/radeon/kms: fix support for DDC on dp bridges
drm/radeon/kms: add support for load detection on dp bridges
drm/radeon/kms: add missing external encoder action
drm/radeon/kms: rework atombios_get_encoder_mode()
drm/radeon/kms: fix num crtcs for Cedar and Caicos
Revert "drm/i915: Enable GMBUS for post-gen2 chipsets"
drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit
drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.
drm: make debug levels match in edid failure code.
drm/radeon/kms: clear wb memory by default
drm/radeon/kms: be more pedantic about the g5 quirk (v2)
drm/radeon/kms: signed fix for evergreen thermal
drm: populate irq_by_busid-member for pci
The existing code assumed scratch registers in a number
of places while in most cases we are be using writeback
and events rather than scratch registers.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
DP clock and lanes were not set properly for DP bridges.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to set the external transmitter type properly in
AdjustPixelClock to get the properly output.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
They need to be treated like eDP rather than DP.
May fix:
https://bugzilla.kernel.org/show_bug.cgi?id=34822
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to set up the bridge for DDC prior to the
i2c over aux transaction.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This should give us more reliable results if the table
is called before an active device is set.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Revert commit 8f9a3f9b63. This fixes a
hang when loading the eeprom driver (see bug #35572.) GMBUS will be
re-enabled later, differently.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reported-by: Marek Otahal <markotahal@gmail.com>
Tested-by: Yermandu Patapitafious <yermandu.dev@gmail.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch augments the pstate transition code to error out
(instead of returning 0) when an incorrect pstate is provided.
Suggested-by: Borislav Petkov <bp@alien8.de>
CC: andre.przywara@amd.com
CC: Mark.Langsdorf@amd.com
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Before this patch if we failed the vid transition would still try to
submit the "new" frequencies to cpufreq.
That is incorrect - also we could submit a non-existing frequency value
which would cause cpufreq to crash. The ultimate fix is in cpufreq
to deal with incorrect values, but this patch improves the error
recovery in the AMD powernowk8 driver.
The failure that was reported was as follows:
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
powernow-k8: fid 0x2 (1000 MHz), vid 0x12
powernow-k8: fid 0xa (1800 MHz), vid 0xa
powernow-k8: fid 0xc (2000 MHz), vid 0x8
powernow-k8: fid 0xe (2200 MHz), vid 0x8
Marking TSC unstable due to cpufreq changes
powernow-k8: fid trans failed, fid 0x2, curr 0x0
BUG: unable to handle kernel paging request at ffff880807e07b78
IP: [<ffffffff81479163>] cpufreq_stats_update+0x46/0x5b
...
And transition fails and data->currfid ends up with 0. Since
the machine does not support 800Mhz value when the calculation is
done ('find_khz_freq_from_fid(data->currfid);') it reports the
new frequency as 800000 which is bogus. This patch fixes
the issue during target setting.
The patch however does not fix the issue in 'powernowk8_cpu_init'
where the pol->cur can also be set with the 800000 value:
pol->cur = find_khz_freq_from_fid(data->currfid);
dprintk("policy current frequency %d kHz\n", pol->cur);
/* min/max the cpu is capable of */
if (cpufreq_frequency_table_cpuinfo(pol, data->powernow_table)) {
The fix for that looks to update cpufreq_frequency_table_cpuinfo to
check pol->cur.... but that would cause an regression in how the
acpi-cpufreq driver works (it sets cpu->cur after calling
cpufreq_frequency_table_cpuinfo). Instead the fix will be to let
cpufreq gracefully handle bogus data (another patch).
Acked-by: Borislav Petkov <bp@alien8.de>
CC: andre.przywara@amd.com
CC: Mark.Langsdorf@amd.com
Reported-by: Tobias Diedrich <ranma+xen@tdiedrich.de>
Tested-by: Tobias Diedrich <ranma+xen@tdiedrich.de>
[v1: Rebased on v3.0-rc2, reduced patch to deal with vid case]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Jones <davej@redhat.com>
If the driver submitted an non-existing pol>cur value (say it
used the default initialized value of zero), when the cpufreq
stats tries to setup its initial values it incorrectly sets
stat->last_index to -1 (or 0xfffff...). And cpufreq_stats_update
tries to update at that index location and fails.
This can be caused by:
stat->last_index = freq_table_get_index(stat, policy->cur);
not finding the appropiate frequency in the table (b/c the policy->cur
is wrong) and we end up crashing. The fix however is
concentrated in the 'cpufreq_stats_update' as the last_index
(and old_index) are updated there. Which means it can reset
the last_index to -1 again and on the next iteration cause a crash.
Without this patch, the following crash is observed:
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
powernow-k8: fid 0x2 (1000 MHz), vid 0x12
powernow-k8: fid 0xa (1800 MHz), vid 0xa
powernow-k8: fid 0xc (2000 MHz), vid 0x8
powernow-k8: fid 0xe (2200 MHz), vid 0x8
Marking TSC unstable due to cpufreq changes
powernow-k8: fid trans failed, fid 0x2, curr 0x0
BUG: unable to handle kernel paging request at ffff880807e07b78
IP: [<ffffffff81479163>] cpufreq_stats_update+0x46/0x5b
.. snip..
Pid: 1, comm: swapper Not tainted 3.0.0-rc2 #45 MICRO-STAR INTERNATIONAL CO., LTD MS-7094/MS-7094
..snip..
Call Trace:
[<ffffffff81479248>] cpufreq_stat_notifier_trans+0x48/0x7c
[<ffffffff81095d68>] notifier_call_chain+0x32/0x5e
[<ffffffff81095e6b>] __srcu_notifier_call_chain+0x47/0x63
[<ffffffff81095e96>] srcu_notifier_call_chain+0xf/0x11
[<ffffffff81477e7a>] cpufreq_notify_transition+0x111/0x134
[<ffffffff8147b0d4>] powernowk8_target+0x53b/0x617
[<ffffffff8147723a>] __cpufreq_driver_target+0x2e/0x30
[<ffffffff8147a127>] cpufreq_governor_dbs+0x339/0x356
[<ffffffff81477394>] __cpufreq_governor+0xa8/0xe9
[<ffffffff81477525>] __cpufreq_set_policy+0x132/0x13e
[<ffffffff8147848d>] cpufreq_add_dev_interface+0x272/0x28c
Reported-by: Tobias Diedrich <ranma+xen@tdiedrich.de>
Tested-by: Tobias Diedrich <ranma+xen@tdiedrich.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Jones <davej@redhat.com>
This workaround aims to break the deadlock situation
which raises during continuous transfer of data for long
duration over uart with hardware flow control. It is
observed that CTS interrupt cannot be cleared in uart
interrupt register (ICR). Hence further transfer over
uart gets blocked.
It is seen that during such deadlock condition ICR
don't get cleared even on multiple write. This leads
pass_counter to decrease and finally reach zero. This
can be taken as trigger point to run this UART_BT_WA.
Workaround backups the register configuration, does soft
reset of UART using BIT-0 of PRCC_K_SOFTRST_SET/CLEAR
registers and restores the registers.
This patch also provides support for uart init and exit
function calls if present.
Signed-off-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
gsm_dlci_data_output_framed() was doing:
memcpy(dp, skb_pull(dlci->skb, len), len);
The problem is skb_pull() returns the post-increment data ptr
so the first chunk of dlci->skb->data is leaked.
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The modem status can be one or 2 octets and contains the V.24 signals
and in the 2 octet case also the break signal.
We were improperly decoding the break signal from the modem in the
2 octet case.
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix build by moving enum list outside of
#ifdef CONFIG_IIO_RING_BUFFER.
drivers/staging/iio/accel/adis16201_core.c:413: error: 'ADIS16201_SCAN_SUPPLY' undeclared here (not in a function)
drivers/staging/iio/accel/adis16201_core.c:417: error: 'ADIS16201_SCAN_TEMP' undeclared here (not in a function)
..
drivers/staging/iio/accel/adis16203_core.c:374: error: 'ADIS16203_SCAN_SUPPLY' undeclared here (not in a function)
drivers/staging/iio/accel/adis16203_core.c:378: error: 'ADIS16203_SCAN_AUX_ADC' undeclared here (not in a function)
..
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some files use GPIOF_ macros but don't include the header file
for them. These macros are being moved to <linux/gpio.h>, so add
includes for <linux/gpio.h> where needed.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
If gpio pins from bank[2-5] are marked as wakeup enable and if the wake is
through gpio IO pad wakeup, then that wakeup gpio interrupt is lost.
In the current implementation, GPIO driver stores the context of DATAIN of
all the gpio in the bank. During GPIO resuming, it checks DATAIN with wakeup
enabled pins of gpio bank. If there is status change, then manually toggle
GPIO_LEVELDETECT to generate pseudo interrupt.
Reported-by: Philippe Mazet <p-mazet@ti.com>
Tested-by: Philippe Mazet <p-mazet@ti.com>
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This reverts commit 23746a66d7.
It turned out that the actual reason for failure is not the device
firmware, but bug in Bluetooth stack, which will be fixed by
patch by Ville Tervo which corrects the mask handling for CSR 1.1
Dongles.
Reported-and-tested-by: Ed Tomlinson <edt@aei.ca>
Reported-and-tested-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Since printk_ratelimit() shouldn't be used anymore (see comment in
include/linux/printk.h), replace it with printk_ratelimited.
Signed-off-by: Christian Dietrich <christian.dietrich@informatik.uni-erlangen.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some RS690 chipsets seem to end up with floating connectors, either
a DVI connector isn't actually populated, or an add-in HDMI card
is available but not installed. In this case we seem to get a NULL byte
response for each byte of the i2c transaction, so we detect this
case and if we see it we don't do anymore DDC transactions on this
connector.
I've tested this on my RS690 without the HDMI card installed and
it seems to work fine.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
this puts the header and followup at the same loglevel as the
hex dump code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
I don't think Apple offered any other cards for
this mac, so I doubt this will be an issue, but just
to be on the safe side, check the pci ids as well.
v2: fix spelling in commit message
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Joachim Henke <j-o@users.sourceforge.net>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 8410ea (drm: rework PCI/platform driver interface) implemented
drm_pci_irq_by_busid() but forgot to make it available in the
drm_pci_bus-struct.
This caused a freeze on my Radeon9600-equipped laptop when executing glxgears.
Thanks to Michel for noticing the flaw.
[airlied: made function static also]
Reported-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
ARM: footbridge: fix clock event support
ARM: footbridge: fix debug macros
ARM: initrd: disable initrds outside of memory
ARM: extend Code: line by one 16-bit quantity for Thumb instructions
ARM: 6955/1: cmpxchg syscall should data abort if page not write
ARM: 6954/1: zImage: fix Thumb2 breakage
ARM: 6953/1: DT: don't try to access physical address zero
ARM: 6949/2: mach-u300: fix compilaton warning in IO accessors
Revert "ARM: 6944/1: mm: allow ASID 0 to be allocated to tasks"
Revert "ARM: 6943/1: mm: use TTBR1 instead of reserved context ID"
davinci: make PCM platform devices static
arm: davinci: Fix fallout from generic irq chip conversion
ARM: 6894/1: mmci: trigger card detect IRQs on falling and rising edges
ARM: 6952/1: fix lockdep warning of "unannotated irqs-off"
ARM: 6951/1: include .bss in memory layout information
ARM: 6948/1: Fix .size directives for __arm{7,9}tdmi_proc_info
ARM: 6947/2: mach-u300: fix compilation error in timer
ARM: 6946/1: vexpress: move v2m clock init to init_early
ARM: mx51/sdma: Check the chip revision in run-time
arm: mxs: include asm/processor.h for cpu_relax()
Fixes this warning:
drivers/misc/apds990x.c: At top level:
drivers/misc/apds990x.c:613: warning: `apds990x_chip_on' defined but not used
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Samu Onkalo <samu.p.onkalo@nokia.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If dmi_get_system_info() returns NULL, pch_uart_init_port() will
dereferencea a zero pointer.
This oops was observed on an Atom based board which has no BIOS, but
a bootloder which doesn't provide DMI data.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Greg KH <gregkh@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When interrupts are delayed due to interrupt masking or due to other
interrupts being serviced the HPET periodic-emuation would fail. This
happened because given an interval t and a time for the current interrupt
m we would compute the next time as t + m. This works until we are
delayed for > t, in which case we would be writing a new value which is in
fact in the past.
This can be solved by computing the next time instead as (k * t) + m where
k is large enough to be in the future. The exact computation of k is
described in a comment to the code.
More detail:
Assuming an interval of 5 between each expected interrupt we have a normal
case of
t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t5: interrupt, read t5 from comparator, set next interrupt t5 + 5
t10: interrupt, read t10 from comparator, set next interrupt t10 + 5
...
So, what happens when the interrupt is serviced too late?
t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t11: delayed interrupt serviced, read t5 from comparator, set next
interrupt t5 + 5, which is in the past!
... counter loops ...
t10: Much much later, get the next interrupt.
This can happen either because we have interrupts masked for too long
(some stupid driver goes on a printk rampage) or just because we are
pushing the limits of the interval (too small a period), or both most
probably.
My solution is to read the main counter as well and set the next interrupt
to occur at the right interval, for example:
t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t11: delayed interrupt serviced, read t5 from comparator, set next
interrupt t15 as t10 has been missed.
t15: back on track.
Signed-off-by: Nils Carlson <nils.carlson@ericsson.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Seems when a config option does not have a dependency of the menuconfig,
it messes the display of the rest configs, even if it's a hidden one.
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 4440673a95 ("leds: provide helper to register "leds-gpio"
devices") broke the display of the NEW_LEDS menu as it didn't depend on
NEW_LEDS and so made "LED drivers" and "LED Triggers" appear at the same
level as "LED Support" instead of below it as it was before 4440673a.
Moving LEDS_GPIO_REGISTER out of the menuconfig NEW_LEDS fixes this
unintended side effect.
Reported-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We call led_classdev_unregister/led_classdev_register in
asic3_led_remove/asic3_led_probe, thus make LEDS_ASIC3 depend on
LEDS_CLASS.
This patch fixes below build error if LEDS_CLASS is not configured.
LD .tmp_vmlinux1
drivers/built-in.o: In function `asic3_led_remove':
clkdev.c:(.devexit.text+0x1860): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `asic3_led_probe':
clkdev.c:(.devinit.text+0xcee8): undefined reference to `led_classdev_register'
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Paul Parsons <lost.distance@yahoo.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix the wrong `if' condition for the check if the requested timer is
available.
The bitmap avail is used to store if a timer is used already. test_bit()
is used to check if the requested timer is available. If a bit in the
avail bitmap is set it means that the timer is available.
The runtime effect would be that allocating a specific timer always fails
(versus telling cs5535_mfgpt_alloc_timer to allocate the first available
timer, which works).
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In the case of goto err_kzalloc, we should kfree target.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch (as1464) implements the recommended policy that most errors
during suspend or hibernation should not prevent the system from going
to sleep. In particular, failure to suspend a USB driver or a USB
device should not prevent the sleep from succeeding:
Failure to suspend a device won't matter, because the device will
automatically go into suspend mode when the USB bus stops carrying
packets. (This might be less true for USB-3.0 devices, but let's not
worry about them now.)
Failure of a driver to suspend might lead to trouble later on when the
system wakes up, but it isn't sufficient reason to prevent the system
from going to sleep.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1465) continues implementation of the policy that errors
during suspend or hibernation should not prevent the system from going
to sleep.
In this case, failure to turn on the Suspend feature for a hub port
shouldn't be reported as an error. There are situations where this
does actually occur (such as when the device plugged into that port
was disconnected in the recent past), and it turns out to be harmless.
There's no reason for it to prevent a system sleep.
Also, don't allow the hub driver to fail a system suspend if the
downstream ports aren't all suspended. This is also harmless (and
should never happen, given the change mentioned above); printing a
warning message in the kernel log is all we really need to do.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Following the loss of David Brownell, I volunteer to maintain the
ohci-hcd and ehci-hcd drivers. This patch (as1472) makes it official.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
FSE shall occur on the TD natural boundary. The software ep_ring dequeue pointer
exceed the hardware ep_ring dequeue pointer in these cases of Table-3. As a
result, the event_trb(pointed by hardware dequeue pointer) of the FSE can't be
found in the current TD(pointed by software dequeue pointer). What should we do
is to figured out the FSE case and skip over it.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed
Endpoint Companion descriptor is supposed to indicate how many packets a
SS device can handle before it needs to wait for an explicit handshake
from the host controller. A zero value means the device can only handle
one packet before it needs a handshake. Remove a warning in the xHCI
driver that implies this is an invalid value.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tanya ran into an issue when trying to switch a UAS device from the BOT
configuration to the UAS configuration via the bConfigurationValue sysfs
file. Before installing the UAS configuration, set_bConfigurationValue()
calls usb_disable_device(). That function is supposed to remove all host
controller resources associated with that device, but it leaves some state
in the xHCI host controller.
Commit 0791971ba8
usb: allow drivers to use allocated bandwidth until unbound
added a call to usb_disable_device() in usb_set_configuration(), before
the xHCI bandwidth functions were invoked. That commit fixed a bug, but
also introduced a bug that is triggered when a configured device is
switched to a new configuration.
usb_disable_device() goes through all the motions of unbinding the drivers
attached to active interfaces and removing the USB core structures
associated with those interfaces, but it doesn't actually remove the
endpoints from the internal xHCI host controller bandwidth structures.
When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
set to true, the entries in udev->ep_out and udev->ep_in will be set to
NULL. Usually, when the USB core installs a new configuration,
usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
and udev->ep_in before adding any new endpoints. However, when the new
UAS configuration was added, all those entries were null, so none of the
old endpoints in the BOT configuration were dropped.
The xHCI driver blindly added the UAS configuration endpoints, and some of
the endpoint addresses overlapped with the old BOT configuration
endpoints. This caused the xHCI host to reject the Configure Endpoint
command. Now that the xHCI driver code is cleaned up to reject a
double-add of active endpoints, we need to fix the USB core to properly
drop old endpoints in usb_disable_device().
If the host controller driver needs bandwidth checking support, make
usb_disable_device() call usb_disable_endpoint() with
reset_hardware set to false, drop the endpoints from the xHCI host
controller, and then call usb_disable_endpoint() again with
reset_hardware set to true.
The first call to usb_disable_endpoint() will cancel any pending URBs and
wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
pointers in udev->ep_out and udev->ep in intact. Then
usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
to drop.
The final call to usb_disable_endpoint() will do two things:
1. It will call usb_hcd_disable_endpoint() again, which should be harmless
since the ep->urb_list should be empty after the first call to
usb_disable_endpoint() returns.
2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
usb_hcd_disable_endpoint(). That call will have no effect, since the xHCI
driver doesn't set the endpoint_disable function pointer.
Note that usb_disable_device() will now need to be called with
hcd->bandwidth_mutex held.
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
Cc: ablay@codeaurora.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@kernel.org
While trying to switch a UAS device from the BOT configuration to the UAS
configuration via the bConfigurationValue file, Tanya ran into an issue in
the USB core. usb_disable_device() sets entries in udev->ep_out and
udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
functions to remove the BOT configuration endpoints from the xHCI host's
internal structures.
The USB core would then attempt to add endpoints for the UAS
configuration, and some of the endpoints had the same address as endpoints
in the BOT configuration. The xHCI driver blindly added the endpoints
again, but the xHCI host controller rejected the Configure Endpoint
command because active endpoints were added without being dropped.
Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
add active endpoints without first calling xhci_drop_endpoint().
This should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
Cc: stable@kernel.org
Post commit e4eefec73e, the stack is
not generating the CCMP header for us anymore. This broke the CCMP
functionality since firmware was not doing this either. Set a flag
to tell the firmware to generate the CCMP header
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Following OOPS was seen when booting with card inserted
BUG: unable to handle kernel NULL pointer dereference at 0000004c
IP: [<f8b7718c>] cfg80211_get_drvinfo+0x21/0x115 [cfg80211]
*pde = 00000000
Oops: 0000 [#1] SMP
Modules linked in: iwl3945 iwl_legacy mwifiex_sdio mac80211 11 sdhci_pci sdhci pl2303
'ethtool' on the mwifiex device returned this OOPS as
wiphy_dev() returned NULL.
Adding missing set_wiphy_dev() call to fix the problem.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A recent modification to the runtime PM code on mach-shmobile made a wrong
RTPM implementation in the sh_mobile_hdmi driver apparent, which broke
HDMI hotplug detection support on ap4evb. This patch does not implement a
proper dynamic RTPM support for sh_mobile_hdmi, instead it restores the
previous working state by statically enabling it. A more power-efficient
solution should be implemented for the next kernel version.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
If the size of the firmware exceeds TI_FIRMWARE_BUF_SIZE we'll leak 'fw_p'
by failing to call release_firmware().
This patch fixes the leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-greg' of master.kernel.org:/pub/scm/linux/kernel/git/balbi/usb:
usb: musb: gadget: clear TXPKTRDY flag when set FLUSHFIFO
usb: musb: host: compare status for negative error values
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: Compare only lower 32 bits of framebuffer map offsets
drm/i915: Don't leak in i915_gem_shmem_pread_slow()
drm/radeon/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit
drm/radeon/kms: fix mac g5 quirk
x86/uv/x2apic: update for change in pci bridge handling.
alpha, drm: Remove obsolete Alpha support in MGA DRM code
alpha/drm: Cleanup Alpha support in DRM generic code
savage: remove unnecessary if statement
drm/radeon: fix GUI idle IH debug statements
drm/radeon/kms: check modes against max pixel clock
drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
* 'for-linus' of git://neil.brown.name/md:
md/raid5: remove unusual use of bio_iovec_idx()
md/raid5: fix FUA request handling in ops_run_io()
md/raid5: fix raid5_set_bi_hw_segments
md:Documentation/md.txt - fix typo
md/bitmap: remove unused fields from struct bitmap
md/bitmap: use proper accessor macro
md: check ->hot_remove_disk when removing disk
md: Using poll /proc/mdstat can monitor the events of adding a spare disks
MD: use is_power_of_2 macro
MD: raid5 do not set fullsync
MD: support initial bitmap creation in-kernel
MD: add sync_super to mddev_t struct
MD: raid1 changes to allow use by device mapper
MD: move thread wakeups into resume
MD: possible typo
MD: no sync IO while suspended
MD: no integrity register if no gendisk
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] Remove cpufreq_stats sysfs entries on module unload.
MAINTAINERS: Update CPU FREQUENCY patterns
If CONFIG_FB_ATY_BACKLIGHT=y but CONFIG_PCI=n:
drivers/video/aty/atyfb_base.c:2272: warning: ‘aty_bl_exit’ defined but not used
If CONFIG_ATARI=y for a modular build:
drivers/video/aty/atyfb_base.c:2794: warning: ‘store_video_par’ defined but not
used
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
platform_device_unregister() needs to unregister the device, not the
driver.
Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Acked-by: Andy Lutomirski <luto@mit.edu>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Extend the SH / SH-Mobile ARM clock framework to only
resume clocks that have been enabled.
Without this fix divide-by-zero is triggering on sh7372
FSIDIV during system wide resume of Suspend-to-RAM.
Signed-off-by: Magnus Damm <damm@opensource.se>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Fix the recently added SH_DMAC_MAX_CHANNELS handling code in
300e5f9 dmaengine: shdma: Fix SH_DMAC_MAX_CHANNELS handling
Without this fix the shdma driver outputs silly messages in
case SH_DMAC_MAX_CHANNELS happens to match the platform data:
sh-dma-engine sh-dma-engine.0: Attempting to register 20 DMA channels when a max
imum of 20 are supported.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
In the bio_for_each_segment loop, bvl always points current
bio_vec, so the same as bio_iovec_idx(, i). Let's get rid of
it.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Commit e9c7469bb4 ("md: implment REQ_FLUSH/FUA support")
introduced R5_WantFUA flag and set rw to WRITE_FUA in that case.
However remaining code still checks whether rw is exactly same
as WRITE or not, so FUAed-write ends up with being treated as
READ. Fix it.
This bug has been present since 2.6.37 and the fix is suitable for any
-stable kernel since then. It is not clear why this has not caused
more problems.
Cc: Tejun Heo <tj@kernel.org>
Cc: stable@kernel.org
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The @bio->bi_phys_segments consists of active stripes count in the
lower 16 bits and processed stripes count in the upper 16 bits. So
logical-OR operator should be bitwise one.
This bug has been present since 2.6.27 and the fix is suitable for any
-stable kernel since then. Fortunately the bad code is only used on
error paths and is relatively unlikely to be hit.
Cc: stable@kernel.org
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Drivers using multiple framebuffers got broken by commit
41c2e75e60 which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real offsets could not always be handed over for comparison.
Instead of ignoring the offset we will compare the lower 32 bit. Drivers
using multiple framebuffers should just make sure that the lower 32 bit
are different. The existing drivers in question are practically limited
to 32-bit systems so that should be fine for them.
It is assumed that current drivers always specify a correct framebuffer
map offset, even if this offset was ignored since above commit. So this
patch should not change anything for drivers using only one framebuffer.
Drivers needing multiple framebuffers with 64-bit map offsets will need
to cook up something, for instance keeping an ID in the lower bit which
is to be aligned away when it comes to using the offset.
All of above applies to _DRM_REGISTERS as well.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It seems to me that we are leaking 'user_pages' in
drivers/gpu/drm/i915/i915_gem.c::i915_gem_shmem_pread_slow() if
read_cache_page_gfp() fails.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
To my knowledge, the limit is 16 on r300.
(the docs don't say what the limit is)
The lack of bounds checking can be abused to do all sorts of things
(from bypassing parts of the CS checker to crashing the kernel).
Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=36745
Cc: stable@kernel.org
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Apple uses the same subsystem pci ids for lots of
hardware much of which is wired up differently. In
this case, the G5 imac and the G5 tower.
Only apply the quirk configuration to G5 towers.
Reported-by: Joachim Henke <j-o@users.sourceforge.net>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Joachim Henke <j-o@users.sourceforge.net>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When I added 3448a19da4
I forgot about the special uv handling code for this, so this
patch fixes it up.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ingo Molnar
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove an obsolete Alpha adjustment in the drm for MGA on Alpha.
Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
Tested-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove an obsolete Alpha adjustment, and modify another,
to go with the current Alpha architecture support.
Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
Tested-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
the code always returns ret regardless, so if(ret) check is unnecessary.
v2: fixed up the spelling.
Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Reviewed-by: Nicolas Kaiser <nikai@nikai.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
WARNING: vmlinux.o(.devinit.text+0x253e): Section mismatch in reference from the function hplance_init_one() to the function .init.text:hplance_init()
The forward declaration had the correct attribute, but the actual function
definition hadn't.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
Fix broken IRQ autoprobing in 3c503 driver:
- improper IRQ freeing (does not free IRQs causes WARN)
- missing break when an working IRQ is found
The driver works with this patch.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
Return error on out of range cpsdvsr value.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Since the inclusion of eGalax devices in 2.6.39, I've got some
bug reports for 480d and other devices.
The problem lies in the reports descriptors: eGalax supports both
pen and fingers, and so the reports descriptors contained both.
But hid-multitouch relies on them to detect the last item in each
field to send the multitouch events. In 480d, the last item is not
Y as it should but Pressure. That means that the fields are not
aligned and X,Y are at 0,0 (the other touch coordinates of the report).
With this patch, the detection is made only when the field ContactID
has been detected inside the collection.
There is still a problem with the detections of the range as stylus
and fingers may not have the same min/max, but it's a start.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
cpufreq_stats leaves behind its sysfs entries, which causes a panic
when something stumbled across them.
(Discovered by unloading cpufreq_stats while powertop was loaded).
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: stable@kernel.org
* 'gpio/merge' of git://git.secretlab.ca/git/linux-2.6:
gpio/basic_mmio: add missing include of spinlock_types.h
gpio/nomadik: fix sleepmode for elder Nomadik
We leak the memory allocated to 'phi' when the variable goes out of scope
in hfcsusb_ph_info().
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King said:
>
> So, to summarize what its doing:
>
> 1. It allocates buffers for rx and tx.
> 2. It maps them with dma_map_single().
> This transfers ownership of the buffer to the DMA device.
> 3. In ep93xx_xmit,
> 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
> This violates the DMA buffer ownership rules - the CPU should
> not be writing to this buffer while it is (in principle) owned
> by the DMA device.
> 3b. It then calls dma_sync_single_for_cpu() for the buffer.
> This transfers ownership of the buffer to the CPU, which surely
> is the wrong direction.
> 4. In ep93xx_rx,
> 4a. It calls dma_sync_single_for_cpu() for the buffer.
> This at least transfers the DMA buffer ownership to the CPU
> before the CPU reads the buffer
> 4b. It then uses skb_copy_to_linear_data() to copy the data out.
> At no point does it transfer ownership back to the DMA device.
> 5. When the driver is removed, it dma_unmap_single()'s the buffer.
> This transfers ownership of the buffer to the CPU.
> 6. It frees the buffer.
>
> While it may work on ep93xx, it's not respecting the DMA API rules,
> and with DMA debugging enabled it will probably encounter quite a few
> warnings.
This patch fixes these violations.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Petr Stetiar <ynezz@true.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit a197b59ae6 (mm: fail GFP_DMA allocations when ZONE_DMA is not
configured) made page allocator to return NULL if GFP_DMA is set but
CONFIG_ZONE_DMA is disabled.
This causes ep93xx_eth to fail:
WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
Modules linked in:
[<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
[<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
[<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
[<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
[<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
[<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
[<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
[<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
[<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
[<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
[<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
[<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
[<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)
Since there is no restrictions for DMA on ep93xx, we can fix this by just
removing the GFP_DMA flag from the call.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Petr Stetiar <ynezz@true.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
We can use simply kmalloc() to allocate the buffers. This also simplifies the
code and allows us to perform DMA sync operations more easily.
Memory is allocated with only GFP_KERNEL since there are no DMA allocation
restrictions on this platform.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Petr Stetiar <ynezz@true.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
We shouldn't use NULL for any DMA API functions, unless we are dealing with
ISA or EISA device. So pass correct struct dev pointer to these functions.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix:
/tmp/ccvoZ6h8.s: Assembler messages:
/tmp/ccvoZ6h8.s:284: Warning: register range not in ascending order
/tmp/ccvoZ6h8.s:881: Warning: register range not in ascending order
/tmp/ccvoZ6h8.s:1087: Warning: register range not in ascending order
by ensuring that we have temporary variables placed into specific
registers. Reorder the code a bit to allow the resulting assembly
to be slightly more optimal.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
We were clearing out the multicast filter whenever the interface was
upped, and not setting the mode bits correctly. This can cause
problems if there are any multicast addresses already set at this
point, or if ALLMULTI was set.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Without this the compiler can (and does) optimize register reads away
from within loops, and other such optimizations.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
One of the legit warnings 'make W=3 drivers/ide/ide-cd.c'
generates is:
drivers/ide/ide-cd.c: In function ide_cd_do_request
drivers/ide/ide-cd.c:828:2: warning: conversion to int from \
unsigned int may change the sign of the result
drivers/ide/ide-cd.c:833:2: warning: conversion to int from \
unsigned int may change the sign of the result
nsectors is declared int, should be unsigned int.
blk_rq_sectors() returns unsigned int, and ide_complete_rq
expects unsigned int as well. Fixes both warnings.
Signed-off-by: Connor Hansen <cmdkhh@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
sparc32, leon: bugfix in LEON SMP interrupt init
sparc32, sun4m: bugfix in SMP IPI traphandler
sparc: Remove unnecessary semicolons
Add support for allocating irqs for bootbus devices
Do not skip interrupt sources in sun4d interrupt handler and acknowledge interrupts correctly
Restructure sun4d_build_device_irq so that timer interrupts can be allocated
sparc: PCIC_PCI needs SPARC32 dependency
sparc: Do not select GENERIC_HARDIRQS_NO_DEPRECATED
sparc32,leon: add GRPCI2 PCI Host driver
sparc32,leon: added LEON-common low-level PCI routines
sparc32: added CONFIG_PCIC_PCI Kconfig setting
The mach-nomadik machine did not compile properly due to bad
ux500-specific functions being called. Introduce new state
variables to fix this up.
Reported-by: Axel Lin <axel.lin@gmail.com>
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Prafulla Wadaskar <prafulla.wadaskar@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* 'staging-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6:
staging: iio: max517: Fix iio_info changes
Staging: mei: fix debug code
Staging: cx23885: fix include of altera.h
staging: iio: error case memory leak fix
staging: ath6kl: Fix a kernel panic during suspend/resume
staging: gma500: get control from firmware framebuffer if conflicts
staging: gma500: Skip bogus LVDS VBT mode and check for LVDS before adding backlight
staging: usbip: bugfix prevent driver unbind
staging: iio: industrialio-trigger: set iio_poll_func private_data
staging: rts_pstor: use bitwise operator instead of logical one
staging: fix ath6kl build when CFG80211 is not enabled
staging: brcm80211: fix for 'multiple definition of wl_msg_level' build err
staging: fix olpc_dcon build, needs BACKLIGHT_CLASS_DEVICE
Staging: remove STAGING_EXCLUDE_BUILD option
Staging: altera: move .h file to proper place
* 'stable/xen-swiotlb.bugfix' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6:
swiotlb: Export swioltb_nr_tbl and utilize it as appropiate.
struct iio_info introduced a bug where the second channel of a MAX518 can't be
used. This commit fixes the typo (using max518 instead of the max517 struct).
Signed-off-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
! has higher precedence than !=. H_RDY is 8 and since neither 0 nor
1 are equal to 8 the original condition was always true.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
int i is only needed if CONFIG_ACPI is set
so move it within a new ifdef so kernels without ACPI
don't allocate space for nothing. Fixes warning too.
Signed-off-by: Connor Hansen <cmdkhh@gmail.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
[v2: Fixed warning when CONFIG_ACPI was defined]
Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
Fixes mis-use of MUSB's hardware feature where it won't
flush FIFOs when TXPKTRDY flag was set before and we are
flushing setting both FLUSHFIFO and TXPKTRDY.
In other words, we need to ensure that when we try to
flush FIFOs, we don't accidentaly set TXPKTRDY bit too
due to a read-back of the register.
The MUSB Programming Guide says "May be set simultaneously
with TxPktRdy to abort the packet that is currently being
loaded into the FIFO". This is a situation where TXPKTRDY
hasn't been set yet, but some data already loaded into the
fifo. It looks, that if TXPKTRDY has been set before, and
there is no loading in progress, but we set FLUSHFIFO with
the TXPKTRDY, controller tries to use the same logic to
abort loading and as the result just does nothing (because
there is no packet been loaded currently)
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@nokia.com>
[ balbi@ti.com : fixed one whitespace git complained about
improved the commit log slightly ]
Signed-off-by: Felipe Balbi <balbi@ti.com>
Variable d is a struct usb_iso_packet_descriptor. The status filed is usually
negative when an error happens.
Signed-off-by: Márton Németh <nm127@freemail.hu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The patch moves rtc driver for PKUnity-v3 SoC from arch/unicore32/kernel/
to drivers/rtc/, with renaming it to rtc-puv3.c.
Also, Kconfig, Makefile, and MAINTAINERS are modified correspondingly.
Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Each eTSEC device should own localized filer table.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch moves enabling channel for window, because there should
be enabling channel before enabling window. If the sequence is
reversed, it makes the problem in displaying images to lcd panel.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch fixes mishandling in virtual resolution checking.
Previously, virtual resolution is changed to virtual_x and virtual_y
which mean the size for buffer allocation, when s3c_fb_check_var is
called by fb_check_var. However, it is meaningless, since virtual_x
and virtual_y are fixed and user cannot change virtual resolution.
Therefore, virtual resolution should be more than resolution
such as xres and yres.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
debug statement for GUI idle interrupt is wrong and incorrectly
reports CP EOP interrupt; trivial issue, but confusing for
someone trying to distinguish interrupt sources while debugging
... fixed
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Filter out modes that are higher than the max pixel
clock.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Get rid of ->syncchunk and ->counter_bits since they're never used.
Also discard COUNTER_BYTE_RATIO which is unused.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add check to determine if a device needs full resync or if partial resync will do
RAID 5 was assuming that if a device was not In_sync, it must undergo a full
resync. We add a check to see if 'saved_raid_disk' is the same as 'raid_disk'.
If it is, we can safely skip the full resync and rely on the bitmap for
partial recovery instead. This is the legitimate purpose of 'saved_raid_disk',
from md.h:
int saved_raid_disk; /* role that device used to have in the
* array and could again if we did a partial
* resync from the bitmap
*/
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add bitmap support to the device-mapper specific metadata area.
This patch allows the creation of the bitmap metadata area upon
initial array creation via device-mapper.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (28 commits)
MAINTAINERS: add a maintainer to Gadget Framework
USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driver
Revert "USB: option: add ID for ZTE MF 330"
drivers/usb/host/ohci-pxa27x.c: add missing clk_put
USB: CONFIG_USB_GADGET_DUALSPEED is not user-configurable
USB: dummy-hcd needs the has_tt flag
usb-storage: redo incorrect reads
usb/renesas_usbhs: free uep on removal
usb/s3c-hsudc: fix error path
usb/pxa25x_udc: cleanup the LUBBOCK err path
usb/mv_udc_core: fix compile
usb: gadget: include <linux/prefetch.h> to fix compiling error
USB: s3c-hsotg: Tone down debugging
usb: remove bad dput after dentry_unhash
USB: core: Tolerate protocol stall during hub and port status read
musb: fix prefetch build failure
USB: cdc-acm: Adding second ACM channel support for Nokia E7 and C7
usb-gadget: unlock data->lock mutex on error path in ep_write()
USB: option Add blacklist for ZTE K3765-Z (19d2:2002)
option: add Prolink PH300 modem IDs
...
One new offender detected by the recently increased type checking in
platform_get_drvdata():
drivers/rtc/rtc-m41t93.c: In function ‘m41t93_remove’:
drivers/rtc/rtc-m41t93.c:192: warning: passing argument 1 of ‘platform_get_drvdata’ from incompatible pointer type
Use spi_get_drvdata() instead of platform_get_drvdata(), cfr. commit
42fea15d6d ("spi/rtc-{ds1390,ds3234,m41t94}:
Use spi_get_drvdata() for SPI devices")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* 'stable/bug.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen: off by one errors in multicalls.c
xen: use the trigger info we already have to choose the irq handler
We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().
To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.
Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: stable@kernel.org [2.6.38+]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The cx23885 driver was including staging/altera.h, but that file has
moved back into the driver directory.
Why a non-staging driver was including a staging driver is beyond me,
but this fixes the build so everything is happy for now.
For the record, it's not ok for a non-staging driver to depend on a
staging one, as that implies that the non-staging one should also be in
the staging tree if that's needed.
Cc: Igor M. Liplianin <liplianin@netup.ru>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
[media] soc_camera: preserve const attribute
[media] uvc_entity: initialize return value
[media] media: Fix media device minor registration
[media] Make nchg variable signed because the code compares this variable against negative values
[media] omap3isp: fix compiler warning
[media] v4l: Fix media_entity_to_video_device macro argument name
[media] ivtv: Internally separate encoder & decoder standard setting
[media] ivtvfb: Add sanity check to ivtvfb_pan_display()
[media] ivtvfb: use display information in info not in var for panning
[media] ivtv: Make two ivtv_msleep_timeout calls uninterruptable
[media] anysee: return EOPNOTSUPP for unsupported I2C messages
[media] gspca - ov519: Set the default frame rate to 15 fps
[media] gspca - stv06xx: Set a lower default value of gain for hdcs sensors
[media] gspca: Remove coarse_expo_autogain.h
[media] gspca - ov519: Change the ovfx2 bulk transfer size
[media] gspca - ov519: Fix a regression for ovfx2 webcams
* 'drm-radeon-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms: disable hdmi audio by default
drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu
drm/radeon/kms: set family for use in parser.
The flush_to_ldisc() work entry has special logic to notice when it has
seen the original tail of the data queue, and it avoids continuing the
flush if it sees that _original_ tail rather than the current tail.
This logic can trigger in case somebody is constantly adding new data to
the tty while the flushing is active - and the intent is to avoid
excessive CPU usage while flushing the tty, especially as we used to do
this from a softirq context which made it non-preemptible.
However, since we no longer re-arm the work-queue from within itself
(because that causes other trouble: see commit a5660b41af "tty: fix
endless work loop when the buffer fills up"), this just leads to
possible hung tty's (most easily seen in SMP and with a test-program
that floods a pty with data - nobody seems to have reported this for any
real-life situation yet).
And since the workqueue isn't done from timers and softirq's any more,
it's doubtful whether the CPU useage issue is really relevant any more.
So just remove the logic entirely, and see if anybody ever notices.
Alternatively, we might want to re-introduce the "re-arm the work" for
just this case, but then we'd have to re-introduce the delayed work
model or some explicit timer, which really doesn't seem worth it for
this.
Reported-and-tested-by: Guillaume Chazarain <guichaz@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On my x86_64 system with >4GB of ram and swiotlb instead of
a hardware iommu (because I have a VIA chipset), the call
to pci_set_dma_mask (see below) with 40bits returns an error.
But it seems that the radeon driver is designed to have
need_dma32 = true exactly if pci_set_dma_mask is called
with 32 bits and false if it is called with 40 bits.
I have read somewhere that the default are 32 bits. So if the
call fails I suppose that need_dma32 should be set to true.
And indeed the patch fixes the problem I have had before
and which I had described here:
http://choon.net/forum/read.php?21,106131,115940
Acked-by: Alex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Wierdly the kms parser never initialised the family, it wasn't really used
much, but the fmt checker patch started using it and it fell over.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the 'sync_super' function pointer to MD array structure (struct mddev_s)
If device-mapper (dm-raid.c) is to define its own on-disk superblock and be
able to load it, there must still be a way for MD to initiate superblock
updates. The simplest way to make this happen is to provide a pointer in
the MD array structure that can be set by device-mapper (or other module)
with a function to do this. If the function has been set, it will be used;
otherwise, the method with be looked up via 'super_types' as usual.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
MD RAID1: Changes to allow RAID1 to be used by device-mapper (dm-raid.c)
Added the necessary congestion function and conditionalize calls requiring an
array 'queue' or 'gendisk'.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Move personality and sync/recovery thread starting outside md_run.
Moving the wakeup's of the personality and sync/recovery threads out of
md_run and into do_md_run and mddev_resume solves two issues:
1) It allows bitmap_load to be called before the sync_thread is run and
2) when MD personalities are used by device-mapper (dm-raid.c), the start-up
of the array is better alligned with device-mapper primatives
(CTR/resume/suspend/DTR). I/O - in this case, recovery operations - should
not happen until after a resume has taken place.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Make message a bit clearer by s/blocks/k/
I chose 'k' vs 'kiB' or 'kB' because it is what is used earlier in the
message. 'k' may be a bit ambigous, but I think it's better than "blocks"
which normally means 512, but means 1024 in MD.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Disallow resync I/O while the RAID array is suspended.
Recovery, resync, and metadata I/O should not be allowed while a device is
suspended.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Don't attempt md_integrity_register if there is no gendisk struct available.
When MD arrays are built via device-mapper, the gendisk structure is not
available via mddev.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Alex Deucher