MIPS: cpu-features.h: s/MIPS53/MIPS64/

No support for MIPS53 processors yet.

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5876/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
udf: Fortify LVID loading

A user has reported an oops in udf_statfs() that was caused by
numOfPartitions entry in LVID structure being corrupted. Fix the problem
by verifying whether numOfPartitions makes sense at least to the extent
that LVID fits into a single block as it should.

Reported-by: Juergen Weigert <jw@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>
reiserfs: remove useless flush_old_journal_lists

Commit a3172027 introduced test_transaction as a requirement for
flushing old lists -- but it can never return 1 unless the transaction
has already been flushed.

As a result, we have a routine that iterates the j_realblocks list but
doesn't actually do anything. Since it's been this way since 2006 and
the latency numbers were what Chris expected, let's just rip it out.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>
reiserfs: fix race with flush_used_journal_lists and flush_journal_list

There are two locks involved in managing the journal lists. The general
reiserfs_write_lock and the journal->j_flush_mutex.

While flush_journal_list is sleeping to acquire the j_flush_mutex or to
submit a block for write, it will drop the write lock. This allows
another thread to acquire the write lock and ultimately call
flush_used_journal_lists to traverse the list of journal lists and
select one for flushing. It can select the journal_list that has just
had flush_journal_list called on it in the original thread and call it
again with the same journal_list.

The second thread then drops the write lock to acquire j_flush_mutex and
the first thread reacquires it and continues execution and eventually
clears and frees the journal list before dropping j_flush_mutex and
returning.

The second thread acquires j_flush_mutex and ends up operating on a
journal_list that has already been released. If the memory hasn't
been reused, we'll soon after hit a BUG_ON because the transaction id
has already been cleared. If it's been reused, we'll crash in other
fun ways.

Since flush_journal_list will synchronize on j_flush_mutex, we can fix
the race by taking a proper reference in flush_used_journal_lists
and checking to see if it's still valid after the mutex is taken. It's
safe to iterate the list of journal lists and pick a list with
just the write lock as long as a reference is taken on the journal list
before we drop the lock. We already have code to handle whether a
transaction has been flushed already so we can use that to handle the
race and get rid of the trans_id BUG_ON.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ASoC: fsl: fsl_ssi: Fix simultaneous capture and playback

When doing simultaneous capture and playback on a mx6 board we get the following
error:

$ arecord -f cd  | aplay -f cd
imx-sgtl5000 sound.13: set sample size in capture stream first
fsl-ssi-dai 2028000.ssi: ASoC: can't open interface 2028000.ssi: -11
ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_
open) unable to open slave
aplay: main:660: audio open error: Device or resource busy
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

The 'arecord -f cd  | aplay -f cd' always trigger cause the
'if (!first_runtime->sample_bits)' block to be true which returns an error.

Adjust the logic inside fsl_ssi_startup(), so that we do not always hit the
error when playing  'arecord | aplay' line for the first time.

Reported-by: Chris Clepper <cgclepper@gmail.com>
Suggested-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: rcar: remove unnecessary mach/clock.h

${LINUX}/sound/soc/sh driver can be compiled from
SuperH and ARM.
but, ${LINUX}/sound/soc/sh/rcar driver included
SH-ARM specific header.
This patch removes it

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: max98088: Fix indentation

Tested-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: max98088: Use table based control init

Tested-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: max98088: Convert to direct regmap API usage

This saves code and moves us towards removing the redundant register I/O
implementation in ASoC.

Tested-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into iommu/fixes
MAINTAINERS: add overall IOMMU section

I believe that Joerg Roedel is at least the path through which
drivers/iommu changes should be merged. Add a MAINTAINERS entry to
make this clear, so that he's Cd'd on all relevant patches. This is
relevant for non-AMD/Intel IOMMUs, where get_maintainers.pl doesn't
currently remind anyone to Cc Joerg on patches.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
ASoC: ab8500: Explicitly set I/O up

We do some I/O in probe so we need to ensure the I/O operations are fully
set up then.

Reported-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Mark Brown <broonie@linaro.org>
x86/iommu: correct ICS register offset

According to Intel Vt-D specs, the offset of Invalidation complete
status register should be 0x9C, not 0x98.

See Intel's VT-d spec, Revision 1.3, Chapter 10.4, Page 98;

Signed-off-by: Li, Zhen-Hua <zhen-hual@hp.com>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
net: udp: do not report ICMP redirects to user space

Redirect isn't an error condition, it should leave
the error handler without touching the socket.

Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: raw: do not report ICMP redirects to user space

Redirect isn't an error condition, it should leave
the error handler without touching the socket.

Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
skge: fix invalid value passed to pci_unmap_sigle

In my patch c194992cbe71c20bb3623a566af8d11b0bfaa721 ("skge: fix
broken driver") I didn't fix the skge bug correctly. The value of the
new mapping (not old) was passed to pci_unmap_single.

If we enable CONFIG_DMA_API_DEBUG, it results in this warning:
WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:986 check_sync+0x4c4/0x580()
skge 0000:02:07.0: DMA-API: device driver tries to sync DMA memory it has
not allocated [device address=0x000000023a0096c0] [size=1536 bytes]

This patch makes the skge driver pass the correct value to
pci_unmap_single and fixes the warning. It copies the old descriptor to
on-stack variable "ee" and unmaps it if mapping of the new descriptor
succeeded.

This patch should be backported to 3.11-stable.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reported-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drm/radeon: add missing hdmi callbacks for rv6xx

When dpm was merged, I added a new asic struct for
rv6xx, but it never got properly updated when the
hdmi callbacks were added due to the two patch sets
being developed in parallel.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
drm/radeon/cik: fix overflow in vram fetch

Missing ULL when calculating the amount of vram
leads to an overflow when the amount of vram is >= 4G.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
qlge: call ql_core_dump() only if dump memory was allocated.

Also changed a log message to indicate that memory was not allocated
instead of memory not available!

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ipv6: udp packets following an UFO enqueued packet need also be handled by UFO

In the following scenario the socket is corked:
If the first UDP packet is larger then the mtu we try to append it to the
write queue via ip6_ufo_append_data. A following packet, which is smaller
than the mtu would be appended to the already queued up gso-skb via
plain ip6_append_data. This causes random memory corruptions.

In ip6_ufo_append_data we also have to be careful to not queue up the
same skb multiple times. So setup the gso frame only when no first skb
is available.

This also fixes a shortcoming where we add the current packet's length to
cork->length but return early because of a packet > mtu with dontfrag set
(instead of sutracting it again).

Found with trinity.

Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>