On certain bios, resume hangs if cpus are allowed to enter idle states
during suspend [1].
This was fixed in apci idle driver [2].But intel_idle driver does not
have this fix. Thus instead of replicating the fix in both the idle
drivers, or in more platform specific idle drivers if needed, the
more general cpuidle infrastructure could handle this.
A suspend callback in cpuidle_driver could handle this fix. But
a cpuidle_driver provides only basic functionalities like platform idle
state detection capability and mechanisms to support entry and exit
into CPU idle states. All other cpuidle functions are found in the
cpuidle generic infrastructure for good reason that all cpuidle
drivers, irrepective of their platforms will support these functions.
One option therefore would be to register a suspend callback in cpuidle
which handles this fix. This could be called through a PM_SUSPEND_PREPARE
notifier. But this is too generic a notfier for a driver to handle.
Also, ideally the job of cpuidle is not to handle side effects of suspend.
It should expose the interfaces which "handle cpuidle 'during' suspend"
or any other operation, which the subsystems call during that respective
operation.
The fix demands that during suspend, no cpus should be allowed to enter
deep C-states. The interface cpuidle_uninstall_idle_handler() in cpuidle
ensures that. Not just that it also kicks all the cpus which are already
in idle out of their idle states which was being done during cpu hotplug
through a CPU_DYING_FROZEN callbacks.
Now the question arises about when during suspend should
cpuidle_uninstall_idle_handler() be called. Since we are dealing with
drivers it seems best to call this function during dpm_suspend().
Delaying the call till dpm_suspend_noirq() does no harm, as long as it is
before cpu_hotplug_begin() to avoid race conditions with cpu hotpulg
operations. In dpm_suspend_noirq(), it would be wise to place this call
before suspend_device_irqs() to avoid ugly interactions with the same.
Ananlogously, during resume.
References:
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674075.
[2] http://marc.info/?l=linux-pm&m=133958534231884&w=2
Reported-and-tested-by: Dave Hansen <dave@linux.vnet.ibm.com>
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
when the default irq quick handler is used then IRQF_ONESHOT must be set
otherwise the request fails and following error is displayed:
mei 0000:00:16.0: irq 48 for MSI/MSI-X
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 48
mei 0000:00:16.0: request_threaded_irq failed: irq = 48.
dpm_run_callback(): pci_pm_resume+0x0/0x140 returns -22
PM: Device 0000:00:16.0 failed to resume async: error -22
Reported-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Cc: stable <stable@vger.kernel.org> # 3.5
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The helper nfs_fs_mount() will always call nfs4_try_mount with the
mount_info->fill_super argument pointing to nfs_fill_super, which is
NFSv2/v3 only.
Fix is to have nfs4_try_mount replace it with nfs4_fill_super.
The regression was introduced by commit c40f8d1d (NFS: Create a common
fs_mount() function)
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Only the main UART and the memory node information are added.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch adds basic devicetree support for i.MX31 based SoCs.
Only the UART and interrupts bindings are added.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend. It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b612847 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.
It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working. Consequently
commit c2fb8a3fa2 (USB: add
NO_D3_DURING_SLEEP flag and revert 151b612847) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.
Now we know the actual cause of the problem. Thanks to AceLan Kao for
tracking it down.
According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows. When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS. Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state. If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so. This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3. The end result is
a system hang or memory corruption.
Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend. This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.
In theory we could do this for every PCI device. However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.
Finally the affected systems can suspend with USB wakeup working
properly.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Javier Marcet <jmarcet@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: stable <stable@vger.kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for the 15'' MacBook Pro Retina model (MacBookPro10,1).
Patch originally written by clipcarl (forums.opensuse.org).
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add support for the 15'' MacBook Pro Retina. The keyboard is
the same as recent models.
The patch needs to be synchronized with the bcm5974 patch for
the trackpad - as usual.
Patch originally written by clipcarl (forums.opensuse.org).
[rydberg@euromail.se: Amended mouse ignore lines]
Signed-off-by: Ryan Bourgeois <bluedragonx@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Recent change in the core driver to get the maximum voltage
is based on the (n_voltages -1) steps of voltage.
For the tps65910, the (n_voltages -1)th step voltage is
calculated based on the callback function list_voltage.
This function direct maps the datasheet and adjust the
first few steps for initial voltage as per datasheet,
and hence initialize the n_voltages based on datasheet.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
From Tony Lindgren <tony@atomide.com>:
This branch contains minimal support for omap5 to boot to a
console without clock framework support. This branch depends
on omap-cleanup-part2-for-v3.6.
* 'devel-omap5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: Kconfig update to support additional GPIOs in OMAP5
ARM: OMAP5: Add the build support
arm/dts: OMAP5: Add omap5 dts files
ARM: OMAP5: board-generic: Add device tree support
ARM: omap2+: board-generic: clean up the irq data from board file
ARM: OMAP5: Add SMP support
ARM: OMAP5: Add the WakeupGen IP updates
ARM: OMAP5: l3: Add l3 error handler support for omap5
ARM: OMAP5: gpmc: Update gpmc_init()
ARM: OMAP5: timer: Add clocksource, clockevent support
ARM: OMAP5: Add minimal support for OMAP5430 SOC
ARM: OMAP5: id: Add cpu id for ES versions
ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme
ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
it easier to support new omap SoCs, such as omap5 and am33xx.
This branch has dependencies to earlier clean-up in omap-cleanup-for-v3.6
and omap-devel-dmtimer-for-v3.6 branches, and also depends on the
omap-devel-am33xx-for-v3.6 branch, and are based on a merge of these
branches.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP+saxAAoJEBvUPslcq6VzObcP/1Wpa5qZC7y8hc/UbQOziD2M
NFpLOQal3mugSeFjvtNXxI6nw0fekLxlbvZ8kzYyHOdMPgkVHgJJo0H1E7olYEXK
gZ6L2cySmQBsyoIcRvNFSCqwN3ej96+fctFEiquvTOyupZnn0fLmh3TPX68ZEdNL
nrKR9O2xVSLuEwHL6z/BJYI1360KcoB6isDRW8udOo7lpb1jQSc1l9FyLIpwdBgl
qWRTQlQ+kNf6DGt3iwdt7ssqz1oBeCPNvPp1+tJ9t9aarA/KfQmxFW0gf5RFwX3y
P9kgF9SZI6HCmzbVDgqb1SA+udCND/4hxJZ3RKHwphx/MbMyIorjy6+OZ/0MJASG
bu6f4QBZ0TfGuf/uKQEl3P4HiHm57/FKC8WbrMkGwSCE0XgC8YVV/2EYrZa0JYBg
7f8wk5LJ15dcndvvUqn55DXU5XwglgJ/fUL+UDMUVGsIYuhdLhRKmgkDzGpQCpbO
c8Q2w4Rvz5Zf3OoB4C8Zxh6GDbiTevae/cU7nhKb1UoN+jlmNchKmHShTvzm5txo
zIK8Tb9W0eLr81Z7Z7m+Q3hFLuBTcmWD9Dnq/pVceP5qf8XzOQeW1Dy+lDYY+xIx
LPdKN34JGuqaBhNykXpsA9EfIgfJXadtnaudvv/oy8etEHHTGSGJAwdeXuIIAvkD
wN9gWFnKOE9cuFH/Hk0T
=6Zcd
-----END PGP SIGNATURE-----
Merge tag 'omap-cleanup-part2-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup2
From Tony Lindgren <tony@atomide.com>:
This branch contains more clean-up like changes and minor fixes for making
it easier to support new omap SoCs, such as omap5 and am33xx.
This branch has dependencies to earlier clean-up in omap-cleanup-for-v3.6
and omap-devel-dmtimer-for-v3.6 branches, and also depends on the
omap-devel-am33xx-for-v3.6 branch, and are based on a merge of these
branches.
* tag 'omap-cleanup-part2-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP: sdrc: Fix the build break for OMAP4 only builds
ARM: OMAP2+: dmtimer: cleanup fclk usage
ARM: OMAP2+: Fix mismerge for omap_hwmod_get_main_clk() API
ARM: OMAP2+: Remove unnecessary ifdef around __omap2_set_globals
ARM: OMAP2+: am33xx: Change cpu_is_am33xx to soc_is_am33xx
ARM: OMAP2+: am33xx: Make am33xx as a separate class
ARM: OMAP2+: Move omap3 dpll ops to dpll3xxx.c
ARM: OMAP2+: All OMAP2PLUS uses omap-device.o target so add one entry
ARM: OMAP: dmtimer: use devm_ API and do some cleanup in probe()
ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework
ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak
ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API
ARM: OMAP3+: dpll: optimize noncore dpll locking logic
ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL
ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status
ARM: OMAP4: clockdomain/CM code: Update supported transition modes
ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm
ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fix an interrupt handling issue with cp_intc which
was causing occasional spurious interrupts with DA850 EVM
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJP+rNtAAoJEGFBu2jqvgRNyHAP+QGQV+73+sBxmacM9jKdw+1v
7jBWVH7zDsbWedl02XTfaZFQF5a3ikB3uPMyzXTSslrzVyNzlTM3eeSclarAdr8u
TIkY8JJHSyB7Q8Qro8WMZQ/DgltfIZoIYoCwnQ1elUVuQR7Mha90am2oKhJZ/Z6E
+9qJPaPm3l8wSD/1BiXRsHWD1Fgb52dUaWHP4fY8MgWmsC6pbGKuC5tRVAP2uJus
uIA3bhERimmGZVcb3i4ZGvKr45CFXYLZZt1UtQtyMXk0fuL+OEczyHKF55lwrXZX
t/snUXroZnnmQXRUsLXBosng+3QUeOcXifmbEEmBmT4eZTDjGjbh2DYZzYivfp2f
AdKBtJqMj/Fi1XW2HX5B8EB/H4IwkHi9045gAmJ8uJicP6BbN9EsjjW5yzq+5c/F
piR8uCxVAvnEgsiLyqGurEIyTpgtWXVaqj+fAPw40QRDx6L9yePb74ziLIYpchBs
ozpcmGoDa2mPrPX8zrMAZi4ngOV4zrue9+JHTlxa8vYRx1V6/HjdcTamksp5r5G+
H0PCnACJc5itLbr5uBO/NLIp8EkgCjzDdEhTnX+LsZtnNdTMOOkoObQ/QE8KUdsU
XYzlFjl2kyttHuZW9S8I/IBC7/G2aoIvwDeC0YVW28hatrBjpehXb1Qr24z/t2SP
GSFgjjX5vejjlfxx+EW1
=3h/9
-----END PGP SIGNATURE-----
Merge tag 'davinci-v3.6-fixes' of git://gitorious.org/linux-davinci/linux-davinci into next/fixes-non-critical
DaVinci fixes for v3.6
Fix an interrupt handling issue with cp_intc which
was causing occasional spurious interrupts with DA850 EVM
* tag 'davinci-v3.6-fixes' of git://gitorious.org/linux-davinci/linux-davinci:
ARM: davinci: da8xx: fix interrupt handling
Add IRQ domain support for cp_intc and
runtime PM core support for DaVinci devices.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJP+q0LAAoJEGFBu2jqvgRNnncP/0MBAapuUIArmlY2cP9qZYsM
Hct5Qe5Ko0qO/hXlXabU/CWN0ezFoOcE+SMXRDkepyHhtJ86PMFTr0a/ASsGWV5D
gPUY8IRhRfv5HBuZx9N8PoTpfR6yHHjXl+Qtwkr/UMMvgD9a5gh3B04J9914U7Nr
lRJYBqU1byOHNEAwfe5j8ART1QHNDzg4tGAUaa/blyefhakftN4APk0f5sGybtcg
6VkYMAj2e8NSr4YwUp6KDiAY/1eeiyqR/hGDJPJURC07UsH32lTYNk3KlXaONIAJ
HappEfLXoQ9Dey5ie6cnK0YS9qcIw9cAWbOZXUis+BEuSzkT7dcYP+XmuXuD/aty
L+o3/tEOpkRXfd8Etx8EnApLk2KzdpUBi8AkWmGaewJS5erqQG9JFeWO8UCNpdLs
31otBYKrfTS3qmLRp3FHV3vXIq9mkt0vhjYMkFoAMJRTxbTy4NAIOYjvqgO7yENj
6f2I0KqAsIp2M/+v90KWE1eo5jgtq2pv2lPABnPJGVrL/vmNBFH8+fhNOjFnToA7
KnC39g0bi+55o3TVmzau7vUaliOJn1sfwFQu+Gc5+tZC2/MtrtAsKn54d1KkXjw7
cVHI64khgdWZtLfEqVrNjZtXj1jHEc/pQGkzLyFZNRUSvWpZ0tKL1USh9cEiym1+
xsRWe5N11iDoEkUV7+uX
=8+Mw
-----END PGP SIGNATURE-----
Merge tag 'davinci-v3.6-soc' of git://gitorious.org/linux-davinci/linux-davinci into next/soc
From Sekhar Nori <nsekhar@ti.com>:
DaVinci SoC updates for v3.6
Add IRQ domain support for cp_intc and
runtime PM core support for DaVinci devices.
* tag 'davinci-v3.6-soc' of git://gitorious.org/linux-davinci/linux-davinci:
ARM: davinci: add runtime PM support for clock management
ARM: davinci: cp_intc: Add irq domain support
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Remove some header files which were marked for removal. These files are
not used anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJP+nkHAAoJEGFBu2jqvgRN+qIP/0dVPhEaQd0xSwwYeXtqkkfF
P7IwNCYgekmV+JrsuJp3jzBWx6RP+04jOMFukjoAjG1wNZd/YZMz0Rm0Z8lfKZbO
+NR2ajGptkLhC6lDmIGj9kQs1fBUPLAzqmtaDSOITVmvU/bnJECmAE1rDT949G5W
ouoDTqZsSw6ETeplYqKUJ9yK57/rjOql6hxqMvkMy//UZCHb1Q21Z459P6y4tVhp
L0WIX3KMOt1JhudzY0fFCJP520Ci4qpwx1CANNiS8WBJsVaG46U4UxEELYPN59Bj
G5iDe12UT4lO1KQYlx4G0iWRLZZTG0hIpws+5DXZPq7rwrbOsDxZVi3wx0bqMZzM
eafAPe14+PWehR65IOWlGZ/+ci/sn0DYwIr7sVr75bozt1boPYarStmQgDEWeYSN
/4SSzirNc5L5s/JMCkJRygENB5Q3n9TWQEByJx/su3B8+zYLi8anO/FSzFbzEFDC
xTmO+buNuWmvHSkZuMkgKADbpzWWK+6rm1umggNXnNtWHUNf8gL40VGbmUlG1Pmr
SihDTBfRFD5yhxPW9rnlN3X1E7cuJgLEgPWE6RtyoSkvExUm/PL7Wp//OZguPmlt
wvk9+IYRyn3g5XTZjkbx2BCtrKqoP/OoSB+JiRAHwtm6O6IhSXPzC9N3xma9YXqU
XDcSUUWiEA0mVUkhaRgl
=NR2J
-----END PGP SIGNATURE-----
Merge tag 'davinci-v3.6-cleanup' of git://gitorious.org/linux-davinci/linux-davinci into next/cleanup
From: Sekhar Nori <nsekhar@ti.com>
DaVinci cleanups for v3.6
Remove some header files which were marked for removal. These files are
not used anymore.
* tag 'davinci-v3.6-cleanup' of git://gitorious.org/linux-davinci/linux-davinci:
ARM: davinci: remove dummy header files
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
echi-omap because the driver currently causes issues with PM.
This annoys Kevin as it makes it harder for him to validate that
PM is working. The proper fixes for the echi-omap are being
discussed, but looks like it will not be properly working with PM
until in v3.7.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP/C8tAAoJEBvUPslcq6Vz/CQQAMcyzBitcocXb9bkOz1I0eiy
Y9Cn4ZnSrNZbkNETgStcgTjK6krmz15yqNgQE+KffYCDQqQxhExI33XT8VCHySj7
S++3XcDPUrt3UPidzRDFASazgo+RyyeYfuF32V18TTjYLJCU8tbVcWvzvGPS13eb
5XjTLTholLFDItGy5MPGkdoZXlZqqS4r/cwMG/9io11SUIHfpRvqdV/r+LbXCGqH
GnvAkXIcaVaRmv20v0vYLVWFbbVh1QFHeuX2lnGbNBQC1XaIwmRQg9cJ7pz7HRaZ
YAMPc/N44/EqbfbgKoipy14aPAOfSa3kAFl90Gn2Cmz/Ee8mCO/SQz+FVwaF11Vi
pFpk0miidoAxDLnDiswip9k5EPbTgcZEqIjenIRWtST127YOpLmdCUPnRPv8TaLj
0uo68g7nXTOtUczmpxL+FxdwC+hzvuL0As0YoE+WqU5+Joo972Wxyj2iCle6jW5Z
etmYjYRq/tIX40DPTBT7cu6Oh+CH+FHsOCmfwaWSULf2UWyHeRZsJM6KZrTj1VAm
Baf21HAivJKJERQie8i7PEbtBccMVKRaqMqlitLtdZlYjNjj5IjuRBLyMUtwHNQn
tddM9ySQH/NQYFPXIwbwvfAwNOdwBYD+ofqsxKsVB15jzbgES7JC02W3vHHa7o3H
vv+6NdA5kibofq6R+WjT
=+Kkw
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-for-v3.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren <tony@atomide.com>:
Here is one PM regression fix and a defconfig change to disable
echi-omap because the driver currently causes issues with PM.
This annoys Kevin as it makes it harder for him to validate that
PM is working. The proper fixes for the echi-omap are being
discussed, but looks like it will not be properly working with PM
until in v3.7.
* tag 'omap-fixes-for-v3.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
You'll find in this patch set the nineth version of the initial
support for a new family of ARMv7-compatible Marvell SoCs.
As for the previous releases, both the Armada 370 and the Armada XP
SoCs are supported in this directory, and we are able to build a
single kernel image that boots on both SoCs. Both SoCs use the PJ4B
processor, a Marvell-developed ARM core that implements the ARMv7
instruction set. We are currently using Marvell evaluation boards for
both of those SoCs, and the support for those boards is added in this
patch set.
This patch set, and the support for those SoCs, started as a
collaborative effort from Marvell engineers (who have done the initial
development work) and Free Electrons engineers (who are reshaping the
code for mainline submission, adding device tree support, etc.). This
effort has also received contributions from Ben Dooks from Codethink.
* mvebu/newsoc:
ARM: mvebu: MPIC: read number of interrupts from control register
arm: mach-mvebu: add entry to MAINTAINERS
arm: mach-mvebu: add compilation/configuration change
arm: mach-mvebu: add defconfig
arm: mach-mvebu: add documentation for new device tree bindings
arm: mach-mvebu: add support for Armada 370 and Armada XP with DT
arm: mach-mvebu: add source files
arm: mach-mvebu: add header
clocksource: time-armada-370-xp: Marvell Armada 370/XP SoC timer driver
Changes from Arnd
* Pulled from git://github.com/Marvell-Semi/EBU_mainline_public.git mvebu_for-next-V9
* rebased onto v3.5-rc5 because it was originally based on
an old arm-soc/for-next branch
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Read the number of MPIC interrupts from the controller and only register
that many.
[gregory.clement@free-electrons.com: rename armada symbol name to fit
with new name: armada_370_xp]
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
The new mach-mvebu directory will be maintained by Andrew Lunn and
Jason Cooper (as the existing maintainers for previous Marvell EBU
SoCs) together with Grégory Clément for the Armada 370/XP SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
[ben.dooks@codethink.co.uk: ensure error check on of_property_read_u32]
[ben.dooks@codethink.co.uk: use mpic address instead of bus-unit's ]
[ben.dooks@codethink.co.uk: BUG_ON() if the of_iomap() fails for mpic]
[ben.dooks@codethink.co.uk: move mpic per-cpu register base ]
[ben.dooks@codethink.co.uk: number fetch should use irqd_to_hwirq()]
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Yehuda Yitschak <yehuday@marvell.com>
Tested-by: Lior Amsalem <alior@marvell.com>
Timer 0 is used as free-running clocksource, while timer 1 is used as
clock_event_device.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Yehuda Yitschak <yehuday@marvell.com>
Tested-by: Lior Amsalem <alior@marvell.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: John Stultz <johnstul@us.ibm.com>
From Kukjin Kim <kgene.kim@samsung.com>:
* 'next/board-samsung' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: S3C64XX: Add IRQ mapping for wm0010 on Cragganmore
ARM: S5PV210: Add HSOTG support to SMDKV210
ARM: EXYNOS: Update keypad entries for SMDK4X12
ARM: S3C64XX: Dynamically assign interrupts for CPU PMIC on Cragganmore
ARM: S3C64XX: Dynamically allocate the IRQ range for WM8994 on Cragganmore
ARM: S3C64XX: Add WM5102 EVM to Cragganmore modules
ARM: S3C64XX: Add module identification for Balblair Cragganmore module
ARM: EXYNOS: Add HSOTG support to SMDKV310
ARM: EXYNOS: Add HSOTG support to Origen
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From Kukjin Kim <kgene.kim@samsung.com>:
Here is updating DMA common operation for Samsung SoCs.
Since some DMA client driver such as spi needs to change the configuration
after dma_request() so this branch adds dma_config() can configure DMA
transmit option which is included in dma_request() after that.
Note, according to the changes, needs to update spi and ASoC drivers
for Samsung SoCs and only got the ack from Mark Brown not Grant Likely
and as I know, he is busy for moving. But I think, the spi change has
no problem and it is simple.
* 'next/devel-dma-ops' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: SAMSUNG: Fix compiler warning in dma-ops.c file
ASoC: follow the updated samsung DMA common operations
spi/s3c64xx: Add the use of DMA config operation
ARM: SAMSUNG: Add config() function in DMA common operations
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From Kukjin Kim <kgene.kim@samsung.com>:
Samsung cleanup patches for v3.6 and most of them are removing
useless codes
* 'next/cleanup-samsung' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Remove the L2 cache latency setting for EXYNOS5
ARM: EXYNOS: Remove leftovers of the Samsung specific power domain control
ARM: SAMSUNG: Remove unused variable 'running' on PWM
ARM: SAMSUNG: remove unused SPI clock headers
ARM: S3C24XX: remove unused header <mach/bast-pmu.h>
ARM: S3C24XX: Remove duplicate header file inclusion
ARM: SAMSUNG: Remove description corresponding to a deleted element
ARM: S5PC100: Remove unused variable in dma.c file
ARM: S5P64X0: Remove unused variable in dma.c file
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
udbg_init_debug_opal() should be udbg_init_debug_opal_raw() as
the caller in arch/powerpc/kernel/udbg.c expects
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Newer gcc are being a bit blind here (it's pretty obvious we don't
reach the code path using the array if we haven't initialized the
pointer) but none of that is performance critical so let's just
silence it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
There was a typo, checking for CONFIG_TRACE_IRQFLAG instead of
CONFIG_TRACE_IRQFLAGS causing some useful debug code to not be
built
This in turns causes a build error on BookE 64-bit due to incorrect
semicolons at the end of a couple of macros, so let's fix that too
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]
Looks like we still have issues with pSeries and Cell idle code
vs. the lazy irq state. In fact, the reset fixes that went upstream
are exposing the problem more by causing BUG_ON() to trigger (which
this patch turns into a WARN_ON instead).
We need to be careful when using a variant of low power state that
has the side effect of turning interrupts back on, to properly set
all the SW & lazy state to look as if everything is enabled before
we enter the low power state with MSR:EE off as we will return with
MSR:EE on. If not, we have a discrepancy of state which can cause
things to go very wrong later on.
This patch moves the logic into a helper and uses it from the
pseries and cell idle code. The power4/970 idle code already got
things right (in assembly even !) so I'm not touching it. The power7
"bare metal" idle code is subtly different and correct. Remains PA6T
and some hypervisor based Cell platforms which have questionable
code in there, but they are mostly dead platforms so I'll fix them
when I manage to get final answers from the respective maintainers
about how the low power state actually works on them.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]
high_width can be easily calculated in a single expression when
making use of __ffs64().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/4FF71053020000780008E1B5@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
With the variable operated on being of "unsigned long" type,
neither ffs() nor fls() are suitable to use on them, as those
truncate their arguments to 32 bits. Using __ffs() and __fls()
respectively at once eliminates the need to subtract 1 from their
results.
Additionally, with the alignment value subsequently used as a
shift count, it must be enforced to be less than BITS_PER_LONG
(and on 64-bit there's no need for it to be any smaller).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/4FF70D54020000780008E179@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Commit cb8ca5897 (ARM: omap3evm: enable VBUS switch for EHCI tranceiver)
added a new randconfig error if TWL4030_CORE is not selected:
arch/arm/mach-omap2/board-omap3evm.c:368: undefined reference to `twl_i2c_read_u8'
arch/arm/mach-omap2/board-omap3evm.c:370: undefined reference to `twl_i2c_write_u8'
Signed-off-by: Tony Lindgren <tony@atomide.com>
commit db83d136d7 (gianfar: Fix missing sock reference when
processing TX time stamps) added a potential sk_wmem_alloc imbalance
If the new skb has a different truesize than old one, we can get a
negative sk_wmem_alloc once new skb is orphaned at TX completion.
Now we no longer early orphan skbs in dev_hard_start_xmit(), this
probably can lead to fatal bugs.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Manfred Rudigier <manfred.rudigier@omicron.at>
Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
Cc: Jiajun Wu <b06378@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. There does not seem to be a meaningful value to
provide to netdev_warn. Replace with pr_warn, since pr_err is used
elsewhere.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. This seems to be a copy-paste bug from a previous
debugging message, and so the meaningless value is just deleted.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. The dereferences are just deleted from the
debugging statement.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
dev->priomap is allocated by extend_netdev_table() called from
update_netdev_tables().
And this is only called if write_priomap() is called.
But if write_priomap() is not called, it seems we can have out of bounds
accesses in cgrp_destroy(), read_priomap() & skb_update_prio()
With help from Gao Feng
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Gao feng <gaofeng@cn.fujitsu.com>
Acked-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The bonding debugfs support has been broken in the presence of network
namespaces since it has been added. The debugfs support does not handle
multiple bonding devices with the same name in different network
namespaces.
I haven't had any bug reports, and I'm not interested in getting any.
Disable the debugfs support when network namespaces are enabled.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It was recently reported that moving a bonding device between network
namespaces causes warnings from /proc. It turns out after the move we
were trying to add and to remove the /proc/net/bonding entries from the
wrong network namespace.
Move the bonding /proc registration code into the NETDEV_REGISTER and
NETDEV_UNREGISTER events where the proc registration and unregistration
will always happen at the right time.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the higher mtu sizes requiring the buffer size greater than 8192,
the buffers are sent or received using multiple dma descriptors/ same
descriptor with option of multi buffer handling.
It was observed during tests that the driver was missing on data
packets during the normal ping operations if the data buffers being used
catered to jumbo frame handling.
The memory barrriers are added in between preparation of dma descriptors
in the jumbo frame handling path to ensure all instructions before
enabling the dma are complete.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It was observed that during multiple reboots nfs hangs. The status of
receive descriptors shows that all the descriptors were in control of
CPU, and none were assigned to DMA.
Also the DMA status register confirmed that the Rx buffer is
unavailable.
This patch adds the fix for the same by adding the memory barriers to
ascertain that the all instructions before enabling the Rx or Tx DMA are
completed which involves the proper setting of the ownership bit in DMA
descriptors.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A smallish fix for a lock dependency issue which affects a bunch of
Qualcomm boards that do unusually complicated things with their
regulators, the API is unlikely to be called by any other system.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP9yyGAAoJEBus8iNuMP3dI24P/RXFIHH1dYck49uQ17moYDY+
vQBM7amuu23Q9MJxU5rGWaqwxXR8qT3iT76BlL9bt8u91GM4tDrccLRW09+GJXNZ
1tpFK96iOaH9ju/+FMc0nR9P385YqxRh91ZWDfyAqectBU8nFAtcl+7BakuR/9j/
2XbftG3T555EylCfwAaw1ikOALxE47ALgKa/Hglu8RDZTQSaWWZb2o20PTXfrkUk
Mt1Pzs9PMfmgE7VUC6Q04vEydX47L8/iwywanzcbMTKw00d3o5WXTwNqDzcPWGZv
S9pSGQaZ10JVMO7eu4337fsfIuhUEU0Ilbaow1eLi1RymgDFIamr0SUKcpC1sPDF
O95l1GZmEwiyDJITL4K1Ssf5TZCKmR9eMh9e1iPmOrtpK4tGHxwqO5+OHmfncISp
g4x4G7o+aK5M9c3+9r3G7S1ZrV4LAcFLVxN9LHo0PLIG/lT7tl8e6dAlWZjKSRIC
w18lJ7mdOCXgJqOt4UzIRbWpI0pZaXt0tk1mfU+/vfzhl9C5AVMVNGqgaiafHWGG
Kh01vjjSIGhfE3k83eOGlkYpTGvFsZBMVUMHif8hRfrBjiHj7RnvAfXqV0ULpa50
v0huqrPwB+384c2V6K1f6IbpyLXZQ10h4HwctxprKbO+cZZ5oYlxLlu8tkJFvNMD
QxLC8aDIumuprilMgryd
=x509
-----END PGP SIGNATURE-----
Merge tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"A smallish fix for a lock dependency issue which affects a bunch of
Qualcomm boards that do unusually complicated things with their
regulators, the API is unlikely to be called by any other system."
* tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix recursive mutex lockdep warning
Don't call v4l2_ctrl_g_ctrl on ctrls which the model cam in question
does not have.
Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[ Taken directly, since Mauro is on vacation ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
