The ttm_mem_evict_first function could theoretically drop the
lru lock without retrying if a reservation from off the LRU list
ended up waiting.
However, since currently there are no users that could cause a wait
in that situation so this is not suitable for stable
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Platform device drivers usually use the driver-private data for their
own purposes. Having it overwritten by drm_platform_init() is confusing
and error-prone.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's a relic of "drm: Convert proc files to seq_file and introduce debugfs",
which wrongly converted DRM_INFO + sprintf to 2 seq_printfs.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Gamari <bgamari@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The drm_gem_cma_create() function never returns NULL but rather an error
encoded in the return value using the ERR_PTR() macro. Callers therefore
need to check for errors using the IS_ERR() macro. This change allows
drivers to handle contiguous DMA allocation failures gracefully.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The debug message showing the resolution of a framebuffer to be
allocated is missing a closing parenthesis.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When system enters sleep, non-boot CPUs will be disabled.
Cpufreq stats sysfs is created when the CPU is up, but it is not
freed when the CPU is going down. This will cause memory leak.
Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
Signed-off-by: guifang tang <guifang.tang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit 24d7b40a60 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above commit, otherwise custom OPPs will be added to the wrong device.
Second, the board files OPP init is called from the its init_machine
method, and the generic CPU devices are not yet created when
init_machine is run. Therefore OPP initialization will fail. To fix,
use a device_initcall() for the board file's OPP customization, and
make the device_initcall board-specific by using a machine_is check.
Reported-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
If pm_genpd_attach_cpudidle failed we leak memory stored in 'cpu_data'.
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Memory is allocated with kzalloc() and assigned to
'physical_node'. Then 'physical_node->node_id' is initialized with a
call to 'find_first_zero_bit()', if that results in a value greater
than ACPI_MAX_PHYSICAL_NODE we'll end up jumping to the 'err:' label
and there leave the function and let 'physical_node' go out of scope
and leak the memory we allocated.
This patch fixes the leak by simply freeing the unused/unneeded memory
pointed to by 'physical_node' just before we jump to 'err:'.
[rjw: The problem has been introduced by commit 1033f90 (ACPI: Allow
ACPI binding with USB-3.0 hub), which is new in 3.7-rc.]
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ramster uses network interfaces that are only present when
CONFIG_NET is enabled, so it should depend on NET.
Fixes these build errors:
drivers/built-in.o: In function `sc_kref_release':
tcp.c:(.text+0x24b9af): undefined reference to `sock_release'
drivers/built-in.o: In function `r2net_open_listening_sock':
tcp.c:(.text+0x24ca2b): undefined reference to `sock_create'
tcp.c:(.text+0x24cb91): undefined reference to `sock_release'
drivers/built-in.o: In function `r2net_recv_tcp_msg':
tcp.c:(.text+0x24cdbd): undefined reference to `sock_recvmsg'
drivers/built-in.o: In function `r2net_send_tcp_msg':
tcp.c:(.text+0x24d341): undefined reference to `sock_sendmsg'
drivers/built-in.o: In function `r2net_start_connect':
tcp.c:(.text+0x24d8fa): undefined reference to `sock_create'
drivers/built-in.o: In function `r2net_shutdown_sc':
tcp.c:(.text+0x24e30c): undefined reference to `kernel_sock_shutdown'
drivers/built-in.o: In function `r2net_accept_one':
tcp.c:(.text+0x24f392): undefined reference to `sock_create_lite'
tcp.c:(.text+0x24f3c3): undefined reference to `sock_release'
drivers/built-in.o: In function `r2net_stop_listening':
(.text+0x250f63): undefined reference to `sock_release'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: konrad.wilk@oracle.com
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently if len argument in ext4_trim_fs() is smaller than one block,
the 'end' variable underflow. Avoid that by returning EINVAL if len is
smaller than file system block.
Also remove useless unlikely().
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Both these features have been around for a long time now, and haven't
had any recent issues brought up. So lets drop their experimental
status.
In any case, hotplugis selected by other non-experimental options
which then cause a Kconfig warning.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Change 130f315a (staging: zram: remove special handle of uncompressed page)
introduced a bug in the handling of incompressible pages which resulted in
memory allocation failure for such pages.
When a page expands on compression, say from 4K to 4K+30, we were trying to
do zsmalloc(pool, 4K+30). However, the maximum size which zsmalloc can
allocate is PAGE_SIZE (for obvious reasons), so such allocation requests
always return failure (0).
For a page that has compressed size larger than the original size (this may
happen with already compressed or random data), there is no point storing
the compressed version as that would take more space and would also require
time for decompression when needed again. So, the fix is to store any page,
whose compressed size exceeds a threshold (max_zpage_size), as-it-is i.e.
without compression. Memory required for storing this uncompressed page can
then be requested from zsmalloc which supports PAGE_SIZE sized allocations.
Lastly, the fix checks that we do not attempt to "decompress" the page which
we stored in the uncompressed form -- we just memcpy() out such pages.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Reported-by: viechweg@gmail.com
Reported-by: paerley@gmail.com
Reported-by: wu.tommy@gmail.com
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On n900 uart1 pins are not not used for uart, instead they are
used to connect to a cell modem over ssi. Looks like we're
currently missing these signal names for 3430 for some reason,
and only have some of them listed for 3630. Obviously the signals
are there for 3430 if n900 is using them and they are documented
in some TRMs.
Note that these will eventually be replaced by device tree
based pinctrl-single.c driver. But for now these are needed
to verify the SSI pins for devices like Nokia N900.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit 8f31cefe (ARM: OMAP2+: select PINCTRL in Kconfig)
added select PINCTRL, but accdentally added it to a wrong
location.
We want to select if for ARCH_OMAP2PLUS, not for
ARCH_OMAP2PLUS_TYPICAL.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Fixes the following errors:
[ 2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
[ 2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
Which is because we failed to link the sidetone hwmod for McBSP2/3. The
missing sidetone hwmod link will prevent omap_device_alloc() to append the
DMA resources since we - accidentally - end up having the same number of
resources provided from DT (IO/IRQ) as we have in hwmod for the McBSP ports
without the ST resources.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a "no idle" option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER
powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
unusable. This is erratum i582 in the OMAP36xx Silicon Errata
document.
This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.
This is not a complete workaround. For it to be complete:
1. the PER powerdomain's next power state must not be set to OSWR or
OFF if the CORE powerdomain's next power state is set to CSWR or
ON;
2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
PER went OFF while CORE stayed on. If loopback tests fail, then
those devices will be unusable until PER and CORE can undergo a
transition from ON to OSWR/OFF and back ON.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Struct usb_hub_descriptor.ss.DeviceRemovable has been defined as __le16
and (__force__ __u16) doesn't need.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When setting usb port's acpi power resource, there will be some xhci hub requests.
This will cause dead lock since xhci->lock has been held before setting acpi power
resource in the xhci_hub_control(). The usb_acpi_power_manageable() function might
fall into sleep so release xhci->lock before invoking it.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The default kernel mapping for the pages allocated for the binder
buffers is never used. Set the __GFP_HIGHMEM flag when allocating
these pages so we don't needlessly use low memory pages that may
be required elsewhere.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If a thread or process exited while a reply, one-way transaction or
death notification was pending, the struct holding the pending work
was leaked.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Kazantsev found 3.5 kernels and beyond were leaking memory,
and tracked the faulty commit to a1c7fff7e1 ("net:
netdev_alloc_skb() use build_skb()")
While this commit seems fine, it uncovered a bug introduced
in commit bad43ca832 ("net: introduce skb_try_coalesce()), in function
kfree_skb_partial()"):
If head is stolen, we free the sk_buff,
without removing references on secpath (skb->sp).
So IPsec + IP defrag/reassembly (using skb coalescing), or
TCP coalescing could leak secpath objects.
Fix this bug by calling skb_release_head_state(skb) to properly
release all possible references to linked objects.
Reported-by: Mike Kazantsev <mk.fraggod@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Bisected-by: Mike Kazantsev <mk.fraggod@gmail.com>
Tested-by: Mike Kazantsev <mk.fraggod@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Cc: Ron Mercer <ron.mercer@qlogic.com>
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a bit TCPI_OPT_SYN_DATA (32) to the socket option TCP_INFO:tcpi_options.
It's set if the data in SYN (sent or received) is acked by SYN-ACK. Server or
client application can use this information to check Fast Open success rate.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
`labpc_common_detach()` is called by the comedi core to clean up if
either `labpc_attach()` (including the one in the "ni_labpc_cs" module)
or `labpc_attach_pci()` returns an error. It assumes the `thisboard`
macro (expanding to `((struct labpc_board_struct *)dev->board_ptr)`) is
non-null. This is a valid assumption if `labpc_attach()` fails, but not
if `labpc_attach_pci()` fails, leading to a possible NULL pointer
dereference.
Check `thisboard` at the top of `labpc_common_detach()` and return early
if it is `NULL`. This is okay because the only other thing that could
have been allocated is `dev->private` and that is freed by the comedi
core, not by this function.
Cc: <stable@vger.kernel.org> # 3.6.x
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
`das08_detach()` is called by the comedi core to clean up if either
`das08_attach()` or `das08_attach_pci()` returns an error. It sets
`thisboard` to the return value of `comedi_board(dev)` and assumes it is
non-null. This is a valid assumption if `das08_attach()` fails, but not
if `das08_attach_pci()` fails, leading to a possible NULL pointer
dereference.
Check `thisboard` at the top of `das08_detach()` and return early if it
is `NULL`. This is okay because the only other thing that could have
been allocated is `dev->private` and that is freed by the comedi core,
not by this function.
Cc: <stable@vger.kernel.org> # 3.6.x
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
`pc263_detach()` is called by the comedi core to clean up if either
`pc263_attach()` or `pc263_attach_pci()` returns an error. It sets
`thisboard` to the return value of `comedi_board(dev)` and assumes it is
non-null. This is a valid assumption if `pc263_attach()` fails, but not
if `pc263_attach_pci()` fails, leading to a possible NULL pointer
dereference.
Check `thisboard` at the top of `pc263_detach()` and return early if it
is `NULL`. This is okay because no other resources need cleaning up in
this case.
Cc: <stable@vger.kernel.org> # 3.6.x
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
`pc236_detach()` is called by the comedi core to clean up if either
`pc236_attach()` or `pc236_attach_pci()` returns an error. It sets
`thisboard` to the return value of `comedi_board(dev)` and assumes it is
non-null. This is a valid assumption if `pc236_attach()` fails, but not
if `pc236_attach_pci()` fails, leading to a possible NULL pointer
dereference.
Check `thisboard` at the top of `pc236_detach()` and return early if it
is `NULL`. This is okay because the only other thing that could have
been allocated is `dev->private` and that is freed by the comedi core,
not by this function.
Cc: <stable@vger.kernel.org> # 3.6.x
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
`pc236_detach()` is called by the comedi core if it attempted to attach
a device and failed. `pc236_detach()` calls `pc236_intr_disable()` if
the comedi device private data pointer (`devpriv`) is non-null. This
test is insufficient as `pc236_intr_disable()` accesses hardware
registers and the attach routine may have failed before it has saved
their I/O base addresses.
Fix it by checking `dev->iobase` is non-zero before calling
`pc236_intr_disable()` as that means the I/O base addresses have been
saved and the hardware registers can be accessed. It also implies the
comedi device private data pointer is valid, so there is no need to
check it.
Cc: <stable@vger.kernel.org> # 3.5.x, 3.6.x
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
`dio200_detach()` is called by the comedi core to clean up if either
`dio200_attach()` or `dio200_attach_pci()` return an error. It assigns
`thisboard` to the return value of `comedi_board(dev)` and assumes it is
non-null. In the case of a previous call to `dio200_attach()` it won't
be `NULL` because the comedi core will have pointed it to one of the
elements of `dio200_boards[]`, but in the case of a previous call to
`dio200_attach_pci()` it could be `NULL`, leading to a null pointer
dereference.
Check that `thisboard` is valid at the top of `dio200_detach()` and
return early if it is `NULL`. This is okay because the only other thing
that could have been allocated is `dev->private` and that is freed by
the comedi core, not by this function.
Cc: <stable@vger.kernel.org> # 3.6.x
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
`pci_8255_detach()` will be called by the comedi core if
`pci_8255_attach_pci()` returns an error. It currently assumes that
both `board` (assigned from the return value of `comedi_board(dev)`) and
`devpriv` (assigned from `dev->private`) are non-null, but they might
be null, leading to a null pointer dereference.
`pci_8255_detach()` doesn't need to do anything if either `board` or
`devpriv` are null, so just return early in this case.
Cc: <stable@vger.kernel.org> # 3.6.x
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here is a small patch to fix a problem caused by a previous patch that
removed the callback function. The callback remove patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1de02225358988e8fd48d1dc3fd12336bbae258a
I finally booted my dev machine on the latest kernel (running Debian
here so it's still on 3.2 normally) to test the ni_daq_700 driver with
my test program and noticed this bug.
Shift the DIO_R read result to bits 8..15 Digital direction
configuration: channels 0-7 output, 8-15 input (8225 device emu as port
A output, port B input, port C N/A).
Cc: <stable@vger.kernel.org> # 3.6.x
Signed-off-by: Fred Brooks <nsaspook@nsaspook.com>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the error path of registering memory when there's a failure to
allocate a chunk from the memory pool, we try to free the same chunk
we just failed to allocate, which will BUG().
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
We can not directly call kvm_release_pfn_clean to release the pfn
since we can meet noslot pfn which is used to cache mmio info into
spte
Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Avi Kivity <avi@redhat.com>
Event parsing tests are broken by following commit:
perf tool: Precise mode requires exclude_guest
commit 1342798cc1
Author: David Ahern <dsahern@gmail.com>
Date: Thu Sep 13 14:59:13 2012 -0600
which enables 'exclude_guest' modifier any time the 'precise'
modifier is detected.
Fixing related tests and adding special comment.
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Tested-by: David Ahern <dsahern@gmail.com>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This fixes a long-standing bug caused by the lack of separate COMM and EXEC
record types, which makes "perf report" lose track of symbols when a process
renames itself.
With this fix (suggested by Stephane Eranian), a COMM (rename) no longer
flushes the maps, which is the correct behavior. An EXEC also no longer
flushes the maps, but this doesn't matter because as new mappings are created
(for the executable and the libraries) the old mappings are automatically
removed. This is not by accident: the functionality is necessary because DLLs
can be explicitly loaded at any time with dlopen(), possibly on top of existing
text, so "perf report" handles correctly the clobbering of new mappings on top
of old ones.
An alternative patch (which I proposed earlier) would be to introduce a
separate PERF_RECORD_EXEC type, but it is a much larger change (about 300
lines) and is not necessary.
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Stephane Eranian <eranian@google.com>
Acked-by: Stephane Eranian <eranian@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Olof Johansson <olofj@chromium.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Sonny Rao <sonnyrao@chromium.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Wilson <wilsons@start.ca>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vasiliy Kulikov <segoon@openwall.com>
Link: http://lkml.kernel.org/r/1345585940-6497-1-git-send-email-semenzato@chromium.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
async.c has provided synchronization mechanism on async_schedule_*,
so use async_synchronize_full_domain to sync caching firmware instead
of reinventing the wheel.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Firstly 'firmware_buf' is introduced to make all loading requests
to share one firmware kernel buffer, so firmware_buf should
be used in direct loading for saving memory and speedup firmware
loading.
Secondly, the commit below
abb139e75c2cdbb955e840d6331cb5863e409d0e(firmware:teach
the kernel to load firmware files directly from the filesystem)
introduces direct loading for fixing udev regression, but it
bypasses the firmware cache meachnism, so this patch enables
caching firmware for direct loading case since it is still needed
to solve drivers' dependency during system resume.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Several loading requests may be pending on one same
firmware buf, and this patch moves fw_map_pages_buf()
before complete_all(&fw_buf->completion) and let all
requests see the mapped 'buf->data' once the loading
is completed.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Under 'Opportunistic sleep' situation, system sleep might be
triggered very frequently, so the uncahce work may not be completed
before caching firmware during next suspend.
This patch cancels the uncache work before caching firmware to
fix the problem above.
Also this patch optimizes the cacheing firmware mechanism a bit by
only storing one firmware cache entry for one firmware image.
So if the firmware is still cached during suspend, it doesn't need
to be loaded from user space any more.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It seems that commit cc58482133 ("perf help: Remove use of die and
handle errors") caused the problem - it changed the initial value of
'help_format' from HELP_FORMAT_MAN to HELP_FORMAT_NONE.
This broke the --help option for all builtins, that would produce no
output, while 'man perf-top' would work it MANPATH is properly setup.
Reported-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: David Ahern <dsahern@gmail.com>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/87r4orj7zc.fsf@sejong.aot.lge.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The periodic mode is currently calculated by a simple division
but we should pay more attention to our integer arithmetics.
Also delete a comment that does not make any sense.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When booting a secondary CPU, the primary CPU hands two sets of page
tables via the secondary_data struct:
(1) swapper_pg_dir: a normal, cacheable, shared (if SMP) mapping
of the kernel image (i.e. the tables used by init_mm).
(2) idmap_pgd: an uncached mapping of the .idmap.text ELF
section.
The idmap is generally used when enabling and disabling the MMU, which
includes early CPU boot. In this case, the secondary CPU switches to
swapper as soon as it enters C code:
struct mm_struct *mm = &init_mm;
unsigned int cpu = smp_processor_id();
/*
* All kernel threads share the same mm context; grab a
* reference and switch to it.
*/
atomic_inc(&mm->mm_count);
current->active_mm = mm;
cpumask_set_cpu(cpu, mm_cpumask(mm));
cpu_switch_mm(mm->pgd, mm);
This causes a problem on ARMv7, where the identity mapping is treated as
strongly-ordered leading to architecturally UNPREDICTABLE behaviour of
exclusive accesses, such as those used by atomic_inc.
This patch re-orders the secondary_start_kernel function so that we
switch to swapper before performing any exclusive accesses.
Cc: <stable@vger.kernel.org>
Cc: David McKay <david.mckay@st.com>
Reported-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Thomas Hellstrom