ASoC: sh: fsi-da7210: fixup snd_soc_card name

it shouldn't contain space letters and
special letters like parentheses.

aplay will be "Segmentation fault" without this patch.
special thanks to Takashi.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
ASoC: sh: fsi-hdmi: fixup snd_soc_card name

it shouldn't contain space letters and
special letters like parentheses.

aplay will be "Segmentation fault" without this patch
special thanks to Takashi.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
firewire: ohci: reduce potential context_stop latency

Stopping an isochronous reception DMA context takes two loop iterations
in context_stop on several controllers (JMicron, NEC, VIA).  But there
is no extra delay necessary between these two reg_read trials; the MMIO
reads themselves are slow enough.  Hence bring back the behavior from
before commit dd6254e5c0efe01ad255188898cb3dadf98cb56d "firewire: ohci:
remove superfluous posted write flushes" on these controllers by means
of an "if (i)" condition.

Isochronous context stop is performed in preemptible contexts (and only
rarely), hence this change is of little impact.  (Besides, Agere and TI
controllers always, or almost always, have the context stopped already
at the first ContextControl read.)

More important is asynchronous transmit context stop, which is performed
while local interrupts are disabled (on the two AT DMAs in
bus_reset_tasklet, i.e. after a self-ID-complete event).  In my
experience with several controllers, tested with a usermode AT-request
transmitter as well as with FTP transmission over firewire-net, the AT
contexts were luckily already stopped at the first ContextControl read,
i.e. never required another MMIO read let alone mdelay.  A possible
explanation for this is that the controllers which I tested perhaps stop
AT DMA before they perform the self-ID reception DMA.

But we cannot be sure about that and should keep the interrupts-disabled
busy loop as short as possible.  Hence, query the ContextControl
register in 1000 udelay(10) intervals instead of 10 udelay(1000)
intervals.  I understand from an estimation by Clemens Ladisch that
stopping a busy DMA context should take microseconds or at worst tens of
microseconds, not milliseconds.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: ohci: add a comment on PHY reg access serialization

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: ohci: fix PHY reg access after card ejection

Detect and handle ejection of FireWire CardBus cards in PHY register
accesses:

  - The last attempt of firewire-core to reset the bus during shutdown
    caused a spurious "firewire_ohci: failed to write phy reg" error
    message in the log.  Skip this message as well as the prior retry
    loop that needlessly took 100 milliseconds.

  - In the unlikely case that a PHY register was read right after card
    ejection, a bogus value was obtained and possibly acted upon.
    Instead, fail the read attempt.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: ohci: skip soft reset retries after card ejection

The software reset in firewire-ohci's pci_remove does not have a great
prospect of success if the card was already physically removed at this
point.  So let's skip the 500 ms that were spent in retries here.

Also, replace a defined constant by its open-coded value.  This is not a
constant from a specification but an arbitrarily chosen retry limit.  It
was only used in this single place.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
cifs: move bdi_setup_and_register outside of CONFIG_CIFS_DFS_UPCALL

This needs to be done regardless of whether that KConfig option is set
or not.

Reported-by: Sven-Haegar Koch <haegar@sdinet.de>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
cifs: fix expand_dfs_referral

Regression introduced in commit 724d9f1cfba.

Prior to that, expand_dfs_referral would regenerate the mount data string
and then call cifs_parse_mount_options to re-parse it (klunky, but it
worked). The above commit moved cifs_parse_mount_options out of cifs_mount,
so the re-parsing of the new mount options no longer occurred. Fix it by
making expand_dfs_referral re-parse the mount options.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
tty/serial: Add devicetree support for nVidia Tegra serial ports

Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
ARM: mach-shmobile: sh7372: make sure that fsi is peripheral of spu2

FSI act as peripheral circuits of the SPU2.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ARM: mach-shmobile: sh7372 A4MP support

Add support for the sh7372 A4MP power domain
and hook up the FSI/SPU2 device.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ARM: mach-shmobile: sh7372 D4 support

Add support for the sh7372 D4 power domain. This power domain
contains the Coresight-ETM hardware block.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ARM: mach-shmobile: Runtime PM late init callback

Add a mach-shmobile specific callback for SoC-specific code
to hook into. By having the late_initcall() in a common place
we can have multi-SoC/board support in the same kernel binary.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ARM: mach-shmobile: sh7372 late pm domain off

Add sh7372 specific code to power down unused pm domains.

This should really be replaced by some generic PM core
code IMO, but until that happens this patch makes sure
we don't waste power by leaving unused power domains on.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
PM / Domains: Export pm_genpd_poweron() in header

Allow SoC-specific code to call pm_genpd_poweron().

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ARM: mach-shmobile: sh7372 A3RV requires A4LC

Add a power domain workaround for the VPU and A3RV on sh7372.

The sh7372 data sheet mentions that the VPU is located in the
A3RV power domain. The A3RV power domain is not related to A4LC
in any way, but testing shows that unless A3RV _and_ A4LC are
powered on the VPU test program will bomb out.

This issue may be caused by a more or less undocumented dependency
on the MERAM block that happens to be located in A4LC. So now we
know that the out-of-reset requirement of the VPU is that the MERAM
is powered on.

This patch adds a workaround for A3RV to make sure A4LC is powered
on - this so we can use the VPU even though the LCDCs are in blanking
state and A4LC is supposed to be off.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
firewire: ohci: do not bind to Pinnacle cards, avert panic

When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a
"Register access failure" is logged and an interrupt storm or a kernel
panic happens.  https://bugzilla.kernel.org/show_bug.cgi?id=36622

Until this is sorted out (if that is going to succeed at all), let's
just prevent firewire-ohci from touching these devices.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
skbuff: update struct sk_buff members comments

Rearrange struct sk_buff members comments to follow their
definition order. Also, add missing comments for ooo_okay
and dropcount members.

Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
natsemi: fix another dma-debug report

commit 2fb83cd618be34546fb526a9051eceaa95517026
Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date:   Sun Jul 3 22:34:29 2011 -0700

Above commit fixed previously reported warning, but I later
noticed another one at shutdown.  This commit fixes it.

------------[ cut here ]------------
WARNING: at /home/jimc/projects/lx/linux-2.6/lib/dma-debug.c:820 check_unmap+0x1fe/0x56c()
natsemi 0000:00:06.0: DMA-API: device driver frees DMA memory with different size [device address=0x0000000007356840] [map size=1538 bytes] [unmap size=1522 bytes]
Modules linked in: bridge stp llc x_tables ipv6 pc87360 hwmon_vid scx200_hrt pc8736x_gpio scx200_gpio nsc_gpio scx200_acb i2c_core arc4 rtl8180 mac80211 eeprom_93cx6 cfg80211 pcspkr scx200 rfkill ide_gd_mod ide_pci_generic ohci_hcd usbcore sc1200 ide_core [last unloaded: ebtables]
Pid: 3996, comm: ifconfig Not tainted 3.0.0-rc6-skc-dyndbg+ #104
Call Trace:
 [<c011ca97>] warn_slowpath_common+0x4a/0x5f
 [<c0261ca5>] ? check_unmap+0x1fe/0x56c
 [<c011cb10>] warn_slowpath_fmt+0x26/0x2a
 [<c0261ca5>] check_unmap+0x1fe/0x56c
 [<c0116505>] ? check_preempt_curr+0x5a/0x6a
 [<c0262186>] debug_dma_unmap_page+0x53/0x5b
 [<c02aaaf9>] pci_unmap_single+0x4d/0x57
 [<c02aab51>] drain_rx+0x4e/0x74
 [<c02acc6e>] netdev_close+0x103/0x1b8
 [<c02f097e>] ? spin_unlock_bh.clone.30+0x12/0x14
 [<c02f10aa>] ? dev_deactivate_many+0xc1/0xef
 [<c02e05e9>] __dev_close_many+0x69/0x86
 [<c02e0625>] __dev_close+0x1f/0x2c
 [<c02e3200>] __dev_change_flags+0x92/0x107
 [<c02e32db>] dev_change_flags+0x13/0x3f
 [<c031e7ea>] devinet_ioctl+0x248/0x4b3
 [<c02e3a9e>] ? dev_ioctl+0x50a/0x54c
 [<c031f509>] inet_ioctl+0x8e/0xa7
 [<c02d506f>] sock_ioctl+0x1b6/0x1da
 [<c02d4eb9>] ? sock_fasync+0x61/0x61
 [<c0183db4>] do_vfs_ioctl+0x44d/0x47f
 [<c0113cdb>] ? do_page_fault+0x268/0x299
 [<c01339d0>] ? __put_cred+0x34/0x36
 [<c0177d83>] ? sys_faccessat+0x13e/0x14b
 [<c0183e14>] sys_ioctl+0x2e/0x4a
 [<c035bc95>] syscall_call+0x7/0xb
---[ end trace 7013a1bdac403e56 ]---

Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[CPUFREQ] fix cpumask memory leak in acpi-cpufreq on cpu hotplug.

I came across a memory leak during a cyclic cpu-online-offline test.

Signed-off-by: Yu Luming <luming.yu@intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>