Commit 70264367a2 ("ARM: 7653/2: do not scale loops_per_jiffy when
using a constant delay clock") fixed a problem with our timer-based
delay loop, where loops_per_jiffy is scaled by cpufreq yet used directly
by the timer delay ops.
This patch fixes the problem in a more elegant way by keeping a private
ticks_per_jiffy field in the delay ops, independent of loops_per_jiffy
and therefore not subject to scaling. The loop-based delay continues to
use loops_per_jiffy directly, as it should.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:
1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
return code already).
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit b8db6b8 (ARM: 7547/4: cache-l2x0: add support for Aurora L2 cache
ctrl) moved the masking of the part ID which caused the RTL version to be
lost. Commit 6248d06 (ARM: 7545/1: cache-l2x0: make outer_cache_fns a
field of l2x0_of_data) changed how .set_debug is initialized. Both commits
break commit 74ddcdb (ARM: 7608/1: l2x0: Only set .set_debug
on PL310 r3p0 and earlier) which uses the RTL version to conditionally set
.set_debug function pointer. Commit b8db6b8 also caused the printed cache
ID to be missing the version information.
Fix this by reverting how the part number is masked so the RTL version
info is maintained. The cache-id-part DT property does not set the RTL
bits so masking them should have no effect. Also, re-arrange the order
of the function pointer init so the .set_debug function can be overridden.
Reported-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Jason Cooper reports these build errors:
arch/arm/kernel/built-in.o: In function `iwmmxt_do':
/.../arch/arm/kernel/pj4-cp0.c:36: undefined reference to `iwmmxt_task_release'
/.../arch/arm/kernel/pj4-cp0.c:40: undefined reference to `iwmmxt_task_switch'
make: *** [vmlinux] Error 1
This is caused because the PJ4 code explicitly references the iWMMXt
code, but doesn't require it to be built. Fix this by ensuring that
iWMMXt is always enabled with PJ4.
Reported-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The C-Media CM6631 USB receiver doesn't respond to changes in sample rate
while the interface is active. The same behavior is observed in other UAC2
hardware like the VIA VT1731.
Reset the interface after setting the sampling frequency on sample rate
changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is
used. Otherwise, the device will try to use the sample rate of the previous
stream, causing distorted sound on sample rate changes.
The reset is performed for all UAC2 devices, as it should not affect a
standards compliant device, but it is only necessary for C-Media CM6631,
VIA VT1731 and possibly others.
Failure to read sample rate from the device is not handled as an error in
set_sample_rate_v2(), as (permanent or intermittent) failure to read sample
rate isn't essential for a successful sample rate set.
Signed-off-by: Torstein Hegge <hegge@resisty.net>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fengguang Wu's 0-Day kernel build testing backend found the
following build error for an allmodconfig build on ia64:
drivers/built-in.o: In function `show_yoffset':
>> bgrt.c:(.text+0xe5a71): undefined reference to `bgrt_tab'
>> bgrt.c:(.text+0xe5a91): undefined reference to `bgrt_tab'
drivers/built-in.o: In function `show_xoffset':
>> bgrt.c:(.text+0xe5b51): undefined reference to `bgrt_tab'
>> bgrt.c:(.text+0xe5b71): undefined reference to `bgrt_tab'
drivers/built-in.o: In function `show_type':
>> bgrt.c:(.text+0xe5c31): undefined reference to `bgrt_tab'
drivers/built-in.o:bgrt.c:(.text+0xe5c51): more undefined references to `bgrt_tab' follow
drivers/built-in.o: In function `bgrt_init':
bgrt.c:(.init.text+0x8931): undefined reference to `bgrt_image'
bgrt.c:(.init.text+0x8932): undefined reference to `bgrt_image_size'
bgrt.c:(.init.text+0x8950): undefined reference to `bgrt_image'
bgrt.c:(.init.text+0x8960): undefined reference to `bgrt_image_size'
The problem is that all these undefined names are provided by
arch/x86/platform/efi/efi-bgrt.c - which is obviously not available
to the ia64 build.
It doesn't seem useful to provide the BGRT support for Itanium
(many systems are headless and have no graphics at all). So
just don't let users configure this driver on non-X86 machines.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The bitmask used for the prefix mangling was being calculated
incorrectly, leading to the wrong part of the address being replaced
when the prefix length wasn't a multiple of 32.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Pull networking fixes from David Miller:
1) Fix VSOCK layer handling of context ID changes, from Reilly Grant.
2) Now that we have a synchronize_net() in netdev_rx_handler_unregister(),
we can't let any call sites hold locks. Unfortunately bonding does,
so we have to drop the rwlock there a little bit earlier, fix from
Veaceslav Falico.
3) MAC address setting loop exits one iteration too early in mlx4
driver, from Yan Burman.
4) Restore ipv6 routes properly upon ifdown/ifup of loopback, from
Balakumaran Kannan.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
VSOCK: Handle changes to the VMCI context ID.
net IPv6 : Fix broken IPv6 routing table after loopback down-up
cbq: incorrect processing of high limits
net/mlx4_en: Fix setting initial MAC address
bonding: get netdev_rx_handler_unregister out of locks
A small collection of fixes. The most important ones are those from
Stephen and Lars-Peter both of which fix cache issues that have been
lurking for a while but not manifesting noticably enough for anyone to
report them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRWLjSAAoJELSic+t+oim9fHgP/i3g9zqKJM8n4vG/pAi4NJEl
zUgKn5sdHinIqbTZ6712MvMTtiOZtGmarPKHhR63G1Z6jJFFukWuLW4P+KJiIKI/
Gen/gEOt6NEed/Q5es9SRzoP1Nz8EMmht7G7JJ3e1u0+ZRjmdTjNALmr/BV6FwGq
Oul2PpF/O2F08eLl8GtD7wbqbKAq8qOnBjjjTdeJRX7zinDef8PqaCRIASYY5B1Q
i05oREcQt4IaJj5IV7OdXCfuiw2+N2E9gmEYFWOXHpSXmABmgiEYJ5OYjUkPQUHm
Nzf9pRhRgcWFZ/LtKZYZ1o8Vl7SehXUNxWx8QUcm4qohO1Wk/MO7ln+blqpDxuSS
D0DpFS09+o4yB2UR0agX5LyYNyQN8e9kLIf7GfaRyxWERs1g7f2hPehuyz2Pb3AU
L5EvuTl9QXbaNefIJuxaigXo3kK0WUkPEQwJFafQjhmFpa/LJJn2YA4P5zx6ovps
1eby5ssCOANVAASoUIbWqP1xZ1/A3KP6B5okxmSFSruOYaG7AiEW30B1n2dNOZKq
X0ZWwWx+qswQltvqTYcgkMRxiyL69d1MHHSEq4R82e8ZvgCSCb73ImCsy6C3nIQk
aEX6ZiUbLCXO+0mEc7e8airamEG24Y7sMW0kVQ1M3J3XDJdEpX7656IXM6JvVXFm
x4+HNj5yua4yccNZN9KX
=QF+V
-----END PGP SIGNATURE-----
Merge tag 'regmap-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"A small collection of fixes. The most important ones are those from
Stephen and Lars-Peter both of which fix cache issues that have been
lurking for a while but not manifesting noticably enough for anyone to
report them."
* tag 'regmap-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: async: Add missing return
regmap: don't corrupt work buffer in _regmap_raw_write()
regmap: cache Fix regcache-rbtree sync
regmap: Initialize `map->debugfs' before regcache
Pull DRM fixes from Dave Airlie:
"Two core fixes, both regressions, along with some intel and some
nouveau fixes for regressions and oopses"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm: correctly restore mappings if drm_open fails
drm/nouveau: fix NULL ptr dereference from nv50_disp_intr()
drm/nouveau: fix handling empty channel list in ioctl's
drm: don't unlock in the addfb error paths
drm/i915: Fix build failure
drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)
drm/i915: duct-tape locking when eDP init fails
Pull MIPS fixes from Ralf Baechle:
"A collection of fixes pretty much across the MIPS code. Even the
change to include/linux/signal.h by David Howells' 2a1486981c ("Fix
breakage in MIPS siginfo handling") should be considered MIPS-specific
as it touches an ifdefed segment that is only relevant to MIPS and
which unfortunately can't be made to go away entirely."
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
Fix breakage in MIPS siginfo handling
Revert "MIPS: BCM63XX: Call board_register_device from device_initcall()"
MIPS: BCM63XX: Make nvram checksum failure non fatal
MIPS: Fix code generation for non-DSP capable CPUs
MIPS: Fix inconsistent formatting inside /proc/cpuinfo
MIPS: SEAD3: Enable LL/SC.
MIPS: Get rid of CONFIG_CPU_HAS_LLSC again
MIPS: Add dependencies for HAVE_ARCH_TRANSPARENT_HUGEPAGE
MIPS: VR4133: Fix probe for LL/SC.
MIPS: Fix logic errors in bitops.c
MIPS: Use CONFIG_CPU_MIPSR2 in csum_partial.S
MIPS: compat: Return same error ENOSYS as native for invalid operation.
This is a fix for commit 7897e60227 ("PCI: Disable Bus Master
unconditionally in pci_device_shutdown()"). Vivek reported that
with this commit, kexec failed because none of his SATA disks
came up.
A ->shutdown() callback might put the device in D3cold, which means config
space is no longer available.
[bhelgaas: changelog]
Link: https://lkml.org/lkml/2013/3/12/529
Reported-and-Tested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This reverts commit 8c33f51df4.
Conflicts:
drivers/acpi/pci_root.c
This commit broke some pre-1.1 PCIe devices by leaving them with
ASPM enabled. Previously, we had disabled ASPM on these devices
because many of them don't implement it correctly (per 149e1637).
Requesting _OSC control early means that aspm_disabled may be set
before we scan the PCI bus and configure link ASPM state. But the
ASPM configuration currently skips the check for pre-PCIe 1.1 devices
when aspm_disabled is set, like this:
acpi_pci_root_add
acpi_pci_osc_support
if (flags != base_flags)
pcie_no_aspm
aspm_disabled = 1
pci_acpi_scan_root
...
pcie_aspm_init_link_state
pcie_aspm_sanity_check
if (!aspm_disabled)
/* check for pre-PCIe 1.1 device */
Therefore, setting aspm_disabled early means that we leave ASPM enabled
on these pre-PCIe 1.1 devices, which is a regression for some devices.
The best fix would be to clean up the ASPM init so we can evaluate
_OSC before scanning the bug (that way boot-time and hot-add discovery
will work the same), but that requires significant rework.
For now, we'll just revert the _OSC change as the lowest-risk fix.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=55211
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.8+
Commit fca460f95e simplified the x32
implementation by creating a syscall bitmask, equal to 0x40000000, that
could be applied to x32 syscalls such that the masked syscall number
would be the same as a x86_64 syscall. While that patch was a nice
way to simplify the code, it went a bit too far by adding the mask to
syscall_get_nr(); returning the masked syscall numbers can cause
confusion with callers that expect syscall numbers matching the x32
ABI, e.g. unmasked syscall numbers.
This patch fixes this by simply removing the mask from syscall_get_nr()
while preserving the other changes from the original commit. While
there are several syscall_get_nr() callers in the kernel, most simply
check that the syscall number is greater than zero, in this case this
patch will have no effect. Of those remaining callers, they appear
to be few, seccomp and ftrace, and from my testing of seccomp without
this patch the original commit definitely breaks things; the seccomp
filter does not correctly filter the syscalls due to the difference in
syscall numbers in the BPF filter and the value from syscall_get_nr().
Applying this patch restores the seccomp BPF filter functionality on
x32.
I've tested this patch with the seccomp BPF filters as well as ftrace
and everything looks reasonable to me; needless to say general usage
seemed fine as well.
Signed-off-by: Paul Moore <pmoore@redhat.com>
Link: http://lkml.kernel.org/r/20130215172143.12549.10292.stgit@localhost
Cc: <stable@vger.kernel.org>
Cc: Will Drewry <wad@chromium.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850
(thanks to Michal Hocko for investigating investigating and
finding the root cause of the bug)
Reference:
http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html
v2: Use one variable to store file and inode mapping
since they are the same at the function entry.
Fix spelling mistakes in commit message.
v3: Add reference to the original bug report.
Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>
Tested-by: Marco Munderloh <munderl@tnt.uni-hannover.de>
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
One locking regression fix, and a couple of other i915 ones.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm: don't unlock in the addfb error paths
drm/i915: Fix build failure
drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)
drm/i915: duct-tape locking when eDP init fails
The VMCI context ID of a virtual machine may change at any time. There
is a VMCI event which signals this but datagrams may be processed before
this is handled. It is therefore necessary to be flexible about the
destination context ID of any datagrams received. (It can be assumed to
be correct because it is provided by the hypervisor.) The context ID on
existing sockets should be updated to reflect how the hypervisor is
currently referring to the system.
Signed-off-by: Reilly Grant <grantr@vmware.com>
Acked-by: Andy King <acking@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
IPv6 Routing table becomes broken once we do ifdown, ifup of the loopback(lo)
interface. After down-up, routes of other interface's IPv6 addresses through
'lo' are lost.
IPv6 addresses assigned to all interfaces are routed through 'lo' for internal
communication. Once 'lo' is down, those routing entries are removed from routing
table. But those removed entries are not being re-created properly when 'lo' is
brought up. So IPv6 addresses of other interfaces becomes unreachable from the
same machine. Also this breaks communication with other machines because of
NDISC packet processing failure.
This patch fixes this issue by reading all interface's IPv6 addresses and adding
them to IPv6 routing table while bringing up 'lo'.
==Testing==
Before applying the patch:
$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
2000::20/128 :: Un 0 1 0 lo
fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$ sudo ifdown lo
$ sudo ifup lo
$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$
After applying the patch:
$ route -A inet6
Kernel IPv6 routing
table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
2000::20/128 :: Un 0 1 0 lo
fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$ sudo ifdown lo
$ sudo ifup lo
$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
2000::20/128 :: Un 0 1 0 lo
fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$
Signed-off-by: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
Signed-off-by: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
currently cbq works incorrectly for limits > 10% real link bandwidth,
and practically does not work for limits > 50% real link bandwidth.
Below are results of experiments taken on 1 Gbit link
In shaper | Actual Result
-----------+---------------
100M | 108 Mbps
200M | 244 Mbps
300M | 412 Mbps
500M | 893 Mbps
This happen because of q->now changes incorrectly in cbq_dequeue():
when it is called before real end of packet transmitting,
L2T is greater than real time delay, q_now gets an extra boost
but never compensate it.
To fix this problem we prevent change of q->now until its synchronization
with real time.
Signed-off-by: Vasily Averin <vvs@openvz.org>
Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure that msg pointer is set back to error value in case of
MSG_COPY flag is set and desired message to copy wasn't found. This
garantees that msg is either a error pointer or a copy address.
Otherwise the last message in queue will be freed without unlinking from
the queue (which leads to memory corruption) and the dummy allocated
copy won't be released.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 6bbb6d9 "net/mlx4_en: Optimize Rx fast path filter checks" introduced a regression
under which the MAC address read from the card was not converted correctly
(the most significant byte was not handled), fix that.
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Yan Burman <yanb@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that netdev_rx_handler_unregister contains synchronize_net(), we need
to call it outside of bond->lock, cause it might sleep. Also, remove the
already unneded synchronize_net().
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After a quiet set of fixes for 3.9-rc4, a lot of people woke up and sent
urgent fixes for 3.9. I pushed back on a number of them that got
deferred to 3.10, but these are the ones that seemed important.
Regression in 3.9:
- Multiple regressions in OMAP2+ clock cleanup
- SH-Mobile frame buffer bug fix that merged here because of maintainer MIA
- ux500 prcmu changes broke DT booting
- MMCI duplicated regulator setup on ux500
- New ux500 clock driver broke ethernet on snowball
- Local interrupt driver for mvebu broke ethernet
- MVEBU GPIO driver did not get set up right on Orion DT
- incorrect interrupt number on Orion crypto for DT
Long-standing bugs, including candidates for stable:
- Kirkwood MMC needs to disable invalid card detect pins
- MV SDIO pinmux was wrong on Mirabox
- GoFlex Net board file needs to set NAND chip delay
- MSM timer restart race
- ep93xx early debug code broke in 3.7
- i.MX CPU hotplug race
- Incorrect clock setup for OMAP1 USB
- Workaround for bad clock setup by some old OMAP4 boot loaders
- Static I/O mappings on cns3xxx since 3.2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUVrxWGCrR//JCVInAQLsoQ/+IQKk3v3xOhsvLaPxYjpO1dZqwxmWHwCz
ujmpnsUabYwuVfVL982k3RTSry5brgOB75CdztOyYsnckF1ZJ3zPjBN+TQM7G/aF
1lpfUTdCEQFgWFb69G6Lr5ZIDk7co3nRJk1GFS/xi/EAlnmUY/tC1Epco2Y0z0g4
dWz34sor22lxwWkUTdgXKwynoxmmjBzZIJOhtSOeednVPxN2qUe9IDAy9qk43U3a
Xg8j4OQT59TTmAZgAB7DLlJ3BGpFvTFAeZ4sDwrCCnibmB5E9LiaYwS9vrk9SQB1
D8CYIUqcP+cGKnftCCIzgjXHYvJw8fa7NKBUw9CzusIuk+c5AbE28KZRIL4D24Oq
ImlFV4Neec3Iab6IWfD0+PQK6PkwqnvPd5IBSFO4zUv2adafl7sTASlMnNPZtWbo
gV+GNVlCyab3l1KYBPo+CQGup3UpIAs5trQoCUh7BRf4HEsL+HILr/SFRQk3GQ6H
B+3HgSleiipT8n81VDFiWY1o5KuXmjUd2qpbc0a45VtM6EFBONwqBaKew93NkDYa
oIhI6yS8aIMYPXC6ZP5R2OvKUuL+mypKKXlt9BMCnDG9mrGMks8BLumcHco+Jmkt
9p6DChibxsaH6QArAi16shFPm0VqFUI6cidgTUcY024bZSiXpBMF52mIu6SEf0/S
agIwGxpuXFg=
=oQbL
-----END PGP SIGNATURE-----
Merge tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC bug fixes from Arnd Bergmann:
"After a quiet set of fixes for 3.9-rc4, a lot of people woke up and
sent urgent fixes for 3.9. I pushed back on a number of them that got
deferred to 3.10, but these are the ones that seemed important.
Regression in 3.9:
- Multiple regressions in OMAP2+ clock cleanup
- SH-Mobile frame buffer bug fix that merged here because of
maintainer MIA
- ux500 prcmu changes broke DT booting
- MMCI duplicated regulator setup on ux500
- New ux500 clock driver broke ethernet on snowball
- Local interrupt driver for mvebu broke ethernet
- MVEBU GPIO driver did not get set up right on Orion DT
- incorrect interrupt number on Orion crypto for DT
Long-standing bugs, including candidates for stable:
- Kirkwood MMC needs to disable invalid card detect pins
- MV SDIO pinmux was wrong on Mirabox
- GoFlex Net board file needs to set NAND chip delay
- MSM timer restart race
- ep93xx early debug code broke in 3.7
- i.MX CPU hotplug race
- Incorrect clock setup for OMAP1 USB
- Workaround for bad clock setup by some old OMAP4 boot loaders
- Static I/O mappings on cns3xxx since 3.2"
* tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: cns3xxx: fix mapping of private memory region
arm: mvebu: Fix pinctrl for Armada 370 Mirabox SDIO port.
arm: orion5x: correct IRQ used in dtsi for mv_cesa
arm: orion5x: fix orion5x.dtsi gpio parameters
ARM: Kirkwood: fix unused mvsdio gpio pins
arm: mvebu: Use local interrupt only for the timer 0
ARM: kirkwood: Fix chip-delay for GoFlex Net
ARM: ux500: Enable the clock controlling Ethernet on Snowball
ARM: ux500: Stop passing ios_handler() as an MMCI power controlling call-back
ARM: ux500: Apply the TCPM and TCDM locations and sizes to dbx5x0 DT
fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized
ARM: imx: fix sync issue between imx_cpu_die and imx_cpu_kill
ARM: msm: Stop counting before reprogramming clockevent
ARM: ep93xx: Fix wait for UART FIFO to be empty
ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup
ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb
ARM: OMAP4: clock data: lock USB DPLL on boot
ARM: OMAP1: fix USB host on 1710
From Anton Vorontsov <anton@enomsg.org>:
This tag includes Mac Lin's work to revive CNS3xxx booting:
"Since commit 0536bdf33f (ARM: move iotable mappings within the vmalloc
region), [...] the pre-defined iotable mappings is not in the vmalloc
region. [...] move the iotable mappings into the vmalloc region, and
merge the MPCore private memory region (containing the SCU, the GIC and
the TWD) as a single region."
Plus there is a small cosmetic fix, also from Mac Lin.
* tag 'v3.9-rc1_cns3xxx_fixes' of git://git.infradead.org/users/cbou/linux-cns3xxx:
ARM: cns3xxx: fix mapping of private memory region
[arnd: dropped the cosmetic fix from the merge as it is not needed for 3.9]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Commit ac3ebafa81 "ACPI / idle: remove usage of the statedata"
changed the percpu processor cstate to a unified cstate in ACPI idle.
That caused all our NHM boxes to boot hang or panic.
2178751 Task dump for CPU 1:
2178752 swapper/1 R running task 6736 0 1 0x00000000
2178753 ffff8801e8029dc8 ffffffff8101cf96 ffff8801e8029e28 ffffffff813d294b
2178754 0000000000000f99 0000000000000003 00000000003cf654 0000000025c17d03
2178755 ffff8801e8029e38 ffff8801e74fc000 00000002590dc5c4 ffffffff8163cdb0
2178756 Call Trace:
2178757 [<ffffffff8101cf96>] ? acpi_processor_ffh_cstate_enter+0x2d/0x2f
2178758 [<ffffffff813d294b>] acpi_idle_enter_bm+0x1b1/0x236
2178759 [<ffffffff8163cdb0>] ? disable_cpuidle+0x10/0x10
2178760 [<ffffffff8163cdc2>] cpuidle_enter+0x12/0x14
2178761 [<ffffffff8163d286>] cpuidle_wrap_enter+0x2f/0x6d
2178762 [<ffffffff8163d2d4>] cpuidle_enter_tk+0x10/0x12
2178763 [<ffffffff8163cdd6>] cpuidle_enter_state+0x12/0x3a
2178764 [<ffffffff8163d4a7>] cpuidle_idle_call+0xe8/0x161
2178765 [<ffffffff81008d99>] cpu_idle+0x5e/0xa4
2178766 [<ffffffff8174c6c1>] start_secondary+0x1a9/0x1ad
2178767 Task dump for CPU 2:
In fact, the ACPI idle is based on the assumption of difference percpu
cstate structures that are necessary for the implementation to work
cprrectly. A unique acpi_processor_cx is not sifficient by far.
This patch is just a quick fix re-introducing the percpu cstates.
If someone really wants to unify the ACPI cstates, please make sure
that the whole software infrastructure is changed and take hardware
as well as many different kinds of BIOS settings into account.
[rjw: Changelog]
Reported-by: LKP project <lkp@linux.intel.com>
Reported-by: Xie ChanglongX <changlongx.xie@intel.com>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI handle of struct i2c_adapter's dev member should not be
set, because this causes that struct i2c_adapter to be associated
with the ACPI device node corresponding to its parent as the
second "physical_device", which is incorrect (this happens during
the registration of struct i2c_adapter). Consequently,
acpi_i2c_register_devices() should use the ACPI handle of the
parent of the struct i2c_adapter it is called for rather than the
struct i2c_adapter's ACPI handle (which should be NULL).
Make that happen and modify the i2c-designware-platdrv driver,
which currently is the only driver for ACPI-enumerated I2C
controller chips, not to set the ACPI handle for the
struct i2c_adapter it creates.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
It should be "governor".
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
platform_device_alloc could failed and return NULL,
we should check this before call platform_device_put.
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This patch let ELD debug message show 'pin_eld->monitor_present' which reflects
the real pin response to verb GET_PIN_SENSE.
'eld->monitor_present' should not be used here because 'eld' is a temp
structure now and so its "monitor_present" is not set.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Acked-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0.
Otherwise it will be returned uninitialized as non-zero after ELD info is got
successfully. Thus hdmi_present_sense() will always assume ELD info is invalid
by mistake, and /proc file system cannot show the proper ELD info.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Cc: stable@vger.kernel.org
Acked-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A few more fixes here and there, including quite a few nasty driver
specific ones, but nothing that has a major general impact.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRUawIAAoJELSic+t+oim9RqsP/RGgUqjX68ewq4Ub9BbhsYGa
Xz4dCN6LACQVXvgNlMhR/TypaJ+vJ3xjlgb/WXNDRYPnEoffoqzDhZOwIaJH8rPR
wGvZGs+UZNuPeIwZ3TF3o0Ct3XYPzzPZPmLnZKL+ZWVgggbHgqGJmkK7smB1koNU
ppnqhPaid6DIlTcSP3jHsUCxcahtCUDUMNPqIzQx7k1QquucUXvs7HWWXaboqyh3
aci3NtDtaMJwM/qheBz0rxv0bk7FrtrukSdN0muSKmcd2Fy8VuwZWIXdB467gXUs
I46ZEOxV2XM+/Tq7HfzLiTu35cgCwXv3z7ayr6Z5ZXjn8B1FnDmqanh3XaawwKbr
Bx53x1X1ga83ms61z+S9QOZ8K74EcJcL6wE77QxsnuaOkgHZYdoZNC7u8i5+cHhN
Lr9ymozK52dH1uJo0/kWvYmK/3SFeHDOMVGiBVVeRQw81PKEPrPZid7veL10UUoG
WX224U1HeuH+0+3scFkaomd4mzhPoj//seIM+806OF4dzsiTLHC7SFU4i3HY23Fx
OH9LJUGvr3FygNqgbdsuO3jEu5N5lXn6zY/Dumi7dLga75vtn0llhXqgM6ec1CLF
jvlHN5UUN8hnxam4SBme5AcX2+rUbEXjD8VA82Y2NOtRWbkiYI5KYINj+SKR0lt+
uRfo30zqYhhaUwmCfXcI
=rovv
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.9
A few more fixes here and there, including quite a few nasty driver
specific ones, but nothing that has a major general impact.
All architectures need to provide a check_pgt_cache() function. The s390 one
got lost somewhere.
So reintroduce it to prevent future compile errors e.g. if Thomas Gleixner's
idle loop rework patches get merged.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
When translating user space addresses to kernel addresses the follow_table()
function had two bugs:
- PROT_NONE mappings could be read accessed via the kernel mapping. That is
e.g. putting a filename into a user page, then protecting the page with
PROT_NONE and afterwards issuing the "open" syscall with a pointer to
the filename would incorrectly succeed.
- when walking the page tables it used the pgd/pud/pmd/pte primitives which
with dynamic page tables give no indication which real level of page tables
is being walked (region2, region3, segment or page table). So in case of an
exception the translation exception code passed to __handle_fault() is not
necessarily correct.
This is not really an issue since __handle_fault() doesn't evaluate the code.
Only in case of e.g. a SIGBUS this code gets passed to user space. If user
space can do something sane with the value is a different question though.
To fix these issues don't use any Linux primitives. Only walk the page tables
like the hardware would do it, however we leave quite some checks away since
we know that we only have full size page tables and each index is within bounds.
In theory this should fix all issues...
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The ACPI handle of struct spi_master's dev member should not be
set, because this causes that struct spi_master to be associated
with the ACPI device node corresponding to its parent as the
second "physical_device", which is incorrect (this happens during
the registration of struct spi_master). Consequently,
acpi_register_spi_devices() should use the ACPI handle of the
parent of the struct spi_master it is called for rather than that
struct spi_master's ACPI handle (which should be NULL).
Make that happen and modify the spi-pxa2xx driver, which currently is
the only driver for ACPI-enumerated SPI controller chips, not to set
the ACPI handle for the struct spi_master it creates.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Fix compiler warnings generated when devfreq is not enabled
(CONFIG_PM_DEVFREQ is not set).
Signed-off-by: Rajagopal Venkat <rajagopal.venkat@linaro.org>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit b81ea1b (PM / QoS: Fix concurrency issues and memory leaks in
device PM QoS) put calls to pm_qos_sysfs_add_latency(),
pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and
pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which was a
mistake, because it may lead to deadlocks in some situations.
For example, if pm_qos_remote_wakeup_store() is run in parallel
with dev_pm_qos_constraints_destroy(), they may deadlock in the
following way:
======================================================
[ INFO: possible circular locking dependency detected ]
3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: G W
-------------------------------------------------------
trinity-child6/12371 is trying to acquire lock:
(s_active#54){++++.+}, at: [<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60
but task is already holding lock:
(dev_pm_qos_mtx){+.+.+.}, at: [<ffffffff81f07cc3>] dev_pm_qos_constraints_destroy+0x23/0x250
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (dev_pm_qos_mtx){+.+.+.}:
[<ffffffff811811da>] lock_acquire+0x1aa/0x240
[<ffffffff83dab809>] __mutex_lock_common+0x59/0x5e0
[<ffffffff83dabebf>] mutex_lock_nested+0x3f/0x50
[<ffffffff81f07f2f>] dev_pm_qos_update_flags+0x3f/0xc0
[<ffffffff81f05f4f>] pm_qos_remote_wakeup_store+0x3f/0x70
[<ffffffff81efbb43>] dev_attr_store+0x13/0x20
[<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150
[<ffffffff8127f2c1>] __kernel_write+0x81/0x150
[<ffffffff812afc2d>] write_pipe_buf+0x4d/0x80
[<ffffffff812af57c>] splice_from_pipe_feed+0x7c/0x120
[<ffffffff812afa25>] __splice_from_pipe+0x45/0x80
[<ffffffff812b14fc>] splice_from_pipe+0x4c/0x70
[<ffffffff812b1538>] default_file_splice_write+0x18/0x30
[<ffffffff812afae3>] do_splice_from+0x83/0xb0
[<ffffffff812afb2e>] direct_splice_actor+0x1e/0x20
[<ffffffff812b0277>] splice_direct_to_actor+0xe7/0x200
[<ffffffff812b15bc>] do_splice_direct+0x4c/0x70
[<ffffffff8127eda9>] do_sendfile+0x169/0x300
[<ffffffff8127ff94>] SyS_sendfile64+0x64/0xb0
[<ffffffff83db7d18>] tracesys+0xe1/0xe6
-> #0 (s_active#54){++++.+}:
[<ffffffff811800cf>] __lock_acquire+0x15bf/0x1e50
[<ffffffff811811da>] lock_acquire+0x1aa/0x240
[<ffffffff81300aa2>] sysfs_deactivate+0x122/0x1a0
[<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60
[<ffffffff812ff77f>] sysfs_hash_and_remove+0x7f/0xb0
[<ffffffff813035a1>] sysfs_unmerge_group+0x51/0x70
[<ffffffff81f068f4>] pm_qos_sysfs_remove_flags+0x14/0x20
[<ffffffff81f07490>] __dev_pm_qos_hide_flags+0x30/0x70
[<ffffffff81f07cd5>] dev_pm_qos_constraints_destroy+0x35/0x250
[<ffffffff81f06931>] dpm_sysfs_remove+0x11/0x50
[<ffffffff81efcf6f>] device_del+0x3f/0x1b0
[<ffffffff81efd128>] device_unregister+0x48/0x60
[<ffffffff82d4083c>] usb_hub_remove_port_device+0x1c/0x20
[<ffffffff82d2a9cd>] hub_disconnect+0xdd/0x160
[<ffffffff82d36ab7>] usb_unbind_interface+0x67/0x170
[<ffffffff81f001a7>] __device_release_driver+0x87/0xe0
[<ffffffff81f00559>] device_release_driver+0x29/0x40
[<ffffffff81effc58>] bus_remove_device+0x148/0x160
[<ffffffff81efd07f>] device_del+0x14f/0x1b0
[<ffffffff82d344f9>] usb_disable_device+0xf9/0x280
[<ffffffff82d34ff8>] usb_set_configuration+0x268/0x840
[<ffffffff82d3a7fc>] usb_remove_store+0x4c/0x80
[<ffffffff81efbb43>] dev_attr_store+0x13/0x20
[<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150
[<ffffffff8127f71d>] do_loop_readv_writev+0x4d/0x90
[<ffffffff8127f999>] do_readv_writev+0xf9/0x1e0
[<ffffffff8127faba>] vfs_writev+0x3a/0x60
[<ffffffff8127fc60>] SyS_writev+0x50/0xd0
[<ffffffff83db7d18>] tracesys+0xe1/0xe6
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(dev_pm_qos_mtx);
lock(s_active#54);
lock(dev_pm_qos_mtx);
lock(s_active#54);
*** DEADLOCK ***
To avoid that, remove the calls to functions mentioned above from
under dev_pm_qos_mtx and introduce a separate lock to prevent races
between functions that add or remove device PM QoS sysfs attributes
from happening.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb
"usb: Add driver/usb/core/(port.c,hub.h) files", from
usb_port_device_release(), because (1) it is completely unnecessary
(the flags have been removed already by the PM core during the
unregistration of the device object) and (2) it triggers a NULL
pointer dereference in sysfs_find_dirent() (dev->kobj.sd is NULL at
this point).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* pci/mjg-rom:
radeon: Attempt to use platform-provided ROM image
nouveau: Attempt to use platform-provided ROM image
PCI: Add PCI ROM helper for platform-provided ROM images
struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
block_device allocated first time we access /dev/loopXX and deallocated on
bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
we want that block_device stay alive until we destroy the loop device
with "losetup -d".
But because we do not hold /dev/loopXX inode its counter goes 0, and
inode/bdev can be destroyed at any moment. Usually it happens at memory
pressure or when user drops inode cache (like in the test below). When later in
loop_clr_fd() we want to use bdev we have use-after-free error with following
stack:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000280
bd_set_size+0x10/0xa0
loop_clr_fd+0x1f8/0x420 [loop]
lo_ioctl+0x200/0x7e0 [loop]
lo_compat_ioctl+0x47/0xe0 [loop]
compat_blkdev_ioctl+0x341/0x1290
do_filp_open+0x42/0xa0
compat_sys_ioctl+0xc1/0xf20
do_sys_open+0x16e/0x1d0
sysenter_dispatch+0x7/0x1a
To prevent use-after-free we need to grab the device in loop_set_fd()
and put it later in loop_clr_fd().
The issue is reprodusible on current Linus head and v3.3. Here is the test:
dd if=/dev/zero of=loop.file bs=1M count=1
while [ true ]; do
losetup /dev/loop0 loop.file
echo 2 > /proc/sys/vm/drop_caches
losetup -d /dev/loop0
done
[ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
time we call loop_set_fd() we check that loop_device->lo_state is
Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
it will get EBUSY. And if we try to loop_clr_fd() on unbound loop
device we'll get ENXIO.
loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
loop_device->lo_ctl_mutex. ]
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
PCIe. On some devices this means that Ethernet will go uninitialized
and other devices will fail. This pull request fixes it with a single
patch to pass the proper base address in the Tegra clock driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJRWfJOAAoJEDqPOy9afJhJWnkP/i2zWVD+0r7eyr6LSQzcp/NI
4KKANm/numhqUb+gijmI1z5iL05bSV7xsg9loiM89uJmgFh6FUL8/LPMX3jVQ1fp
wPoxf913D2PSVHOyonOgPqEQjLwdC4rADjAQsDOXBbJMBPlm8mrRZuB0ZIQw6MCR
9tfGyqSN2WSabJgTzb+NY6odc5mZUA7u1IqJ2gmu2SRrIvgyeplMjX7rPvXJiifd
6zhIhPyrFv8HvrX+Jex4YyGiumtrCj7uTvGqHsVG+0Iiv8CVFc9NgEXCmym1+ssw
JnqjdnBSq8UbDO0DyL54j6pXWfDtVGstw2oUe0uUW4QrCCojvC3tPXOGi/OG6gTF
e3/18WIHj6U6XtDiMNLk5ZyGkUjxVNBXrZ2VNXWGd7uKu02AlzZ67Mh3v5oPRE2L
JtpJg6dH0Xv9h6dVAE9/t3U2YO+XBwRJp6rTrzEs/f8dnGEt6C4WJPUQcJtnLrKf
OldqSZZmRNjHRKH8hF8bbTqCKzobyhYDMgW9lJ7SQt2qcw9ddZeLS5VJGW0uCZrL
XWwG29TVXosjjRR8v+i+XHg+HjCc08QQeSLHLB+ZwJQ90k3DiYkd3tuSgdDYPiY8
mggOnBJMb6d5gogKKR6m+q+qo381tgW6lVMdGEXQkgr5Ix6JuQaXBrd0SZXQE6/Z
bUxw6/GJec1W0RuT4R8J
=WU9c
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux
Pull tegra clock driver fix from Mike Turquette:
"Missing base address in Tegra clock driver results in non-operational
PCIe. On some devices this means that Ethernet will go uninitialized
and other devices will fail. This pull request fixes it with a single
patch to pass the proper base address in the Tegra clock driver."
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux:
clk: tegra: Allow PLLE training to succeed
Some platforms only provide their PCI ROM via a platform-specific interface.
Fall back to attempting that if all other sources fail.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Some platforms only provide their PCI ROM via a platform-specific interface.
Fall back to attempting that if all other sources fail.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Limit the channel number in scan request, or the driver scan
config structure memory will be overflowed.
Cc: <stable@vger.kernel.org> # 3.5+
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
