On Fri, Jul 11, 2014 at 06:11:41PM +0300, Tuomas Tynkkynen wrote:
> On 11/07/14 17:57, Thierry Reding wrote:
>
> >>I don't think that's going to work? The voltage scaling is handled in hw.
> >
> >Do we have to handle it in hardware or can we opt to do it in software,
> >too?
> >
>
> With the
On Fri, Jul 11, 2014 at 12:11:13AM +0800, Lai Jiangshan wrote:
> Subsitute the get_work_pwq(work) to pwq since it is calculated.
>
> Signed-off-by: Lai Jiangshan
Applied to libata/for-3.17 w/ updated patch description.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line
On 11 July 2014 16:51, Peter Zijlstra wrote:
> On Thu, Jul 10, 2014 at 04:03:51PM +0200, Vincent Guittot wrote:
>> On 10 July 2014 13:18, Peter Zijlstra wrote:
>> > On Mon, Jun 30, 2014 at 06:05:39PM +0200, Vincent Guittot wrote:
>> >> + /*
>> >> + * If the CPUs share
On Fri, 11 Jul 2014, Frederic Weisbecker wrote:
> > Converted what? We still need to keep a cpumask around that tells us which
> > processor have vmstat running and which do not.
> >
>
> Converted to cpumask_var_t.
>
> I mean we spent dozens emails on that...
Oh there is this outstanding fix,
On Fri, Jul 11, 2014 at 10:17:41AM -0500, Christoph Lameter wrote:
> On Fri, 11 Jul 2014, Frederic Weisbecker wrote:
>
> > > Converted what? We still need to keep a cpumask around that tells us which
> > > processor have vmstat running and which do not.
> > >
> >
> > Converted to cpumask_var_t.
>
Hello,
On Fri, Jul 11, 2014 at 10:13:57AM -0500, Christoph Lameter wrote:
> Allocators typically fall back but they wont in some cases if you say
> that you want memory from a particular node. A GFP_THISNODE would force a
> failure of the alloc. In other cases it should fall back. I am not sure
>
Hi, Dan
2014-07-11 22:20 GMT+09:00, Dan Carpenter :
> Looks good to me. You should be CC'ing Mark as well. He's in
> MAINTAINERS now.
I'd added Mark to cc list. All of maintainers including open mailing
lists from get_maintainer.pl were added in my patches. :-)
>
> I wish the two of you would
On Fri, 11 Jul 2014, Frederic Weisbecker wrote:
> Maybe just merge both? The whole looks good.
I hope so. Andrew?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Fri, Jul 11, 2014 at 5:34 AM, Simon Horman wrote:
> On Fri, Jul 04, 2014 at 12:34:58AM -0400, Nick Krause wrote:
>> While searching for FIX ME messages when using cscope on the latest kernels I
>> get a message on 68 of this file and was wondering what I need to define
>> SMFRAM
>> as in
> -Original Message-
> From: Sitsofe Wheeler [mailto:sits...@gmail.com]
> Sent: Friday, July 11, 2014 1:53 AM
> To: Haiyang Zhang
> Cc: KY Srinivasan; David S. Miller; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re:
On Fri, Jul 11, 2014 at 03:47:37PM +0200, Frederic Weisbecker wrote:
> On Fri, Jul 11, 2014 at 06:35:03AM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney"
> >
> > Enabling NO_HZ_FULL currently has the side effect of enabling callback
> > offloading on all CPUs. This results in lots
On 11/07/14 18:15, Thierry Reding wrote:
* PGP Signed by an unknown key
On Fri, Jul 11, 2014 at 06:11:41PM +0300, Tuomas Tynkkynen wrote:
On 11/07/14 17:57, Thierry Reding wrote:
I don't think that's going to work? The voltage scaling is handled in hw.
Do we have to handle it in hardware
On Fri, 11 Jul 2014 08:12:40 -0700
"Paul E. McKenney" wrote:
> On Fri, Jul 11, 2014 at 01:38:12PM +0200, Ard Biesheuvel wrote:
> > Commit f7f7bac9cb1c ("rcu: Have the RCU tracepoints use the
> > tracepoint_string
> > infrastructure") unconditionally populates the __tracepoint_str input
> >
From: Thierry Reding
This patch implements generic versions of readsb(), readsw(), readsl(),
readsq(), writesb(), writesw(), writesl() and writesq(). Variants of
these string functions for I/O accesses (ins*() and outs*() as well as
ioread*_rep() and iowrite*_rep()) are now implemented in terms
From: Thierry Reding
Include the generic I/O header file so that duplicate implementations
can be removed. This will also help to establish consistency across more
architectures regarding which accessors they support.
Acked-by: Catalin Marinas
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Include the generic I/O header file so that duplicate implementations
can be removed. This will also help to establish consistency across more
architectures regarding which accessors they support.
Signed-off-by: Thierry Reding
---
arch/arm/include/asm/io.h | 52
Quoting Tuomas Tynkkynen (2014-07-10 14:42:36)
> This series implements the DFLL/CL-DVFS clock source for the fast CPU
> cluster on Tegra124, and a cpufreq driver that uses the DFLL for
> clocking the CPU. Most of this is based on Paul Walmsley's public patch
> set from December 2013, which is
On Fri, Jul 11, 2014 at 10:29:56AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 11, 2014 at 03:37:17PM +0800, Jiang Liu wrote:
> > Any comments are welcomed!
>
> Why would anybody _ever_ have a memoryless node? That's ridiculous.
I'm with Peter here, why would this be a situation that we should
On Fri, Jul 11, 2014 at 11:21:56AM -0400, Tejun Heo wrote:
> Even if that's the case, there's no reason to burden everyone with
> this distinction. Most users just wanna say "I'm on this node.
> Please allocate considering that". There's nothing wrong with using
> numa_node_id() for that.
Also,
Em Fri, Jul 11, 2014 at 05:36:41PM +0300, Adrian Hunter escreveu:
> There are many perf tools patches and it would be helpful to start
> considering how to get them into mainline. Many need to wait for
> the driver, but others could be taken sooner.
We can go on looking at each of the patches to
On Fri, Jul 11, 2014 at 03:38:30PM +0100, Ian Abbott wrote:
> From: Andrey Utkin
>
> From: Andrey Utkin
>
> The issue was discovered with static analysis and has two instances in
> this file. The code looks like this
> if (x < 65536000) {
> ...
> } else if (x < 65536) {
> ...
>
On Thu, Jul 10, 2014 at 03:45:22PM -0700, Havard Skinnemoen wrote:
> I'm not arguing that's a _sensible_ value, just that there's no point
> in seting it to anything lower than that.
Ok,
right now, during the CMCI interrupt, we increment the count of how
many times we fire. If during one
On Fri, Jul 11, 2014 at 05:36:41PM +0300, Adrian Hunter wrote:
> Hi
>
> Alexander Shishkin is working on the Intel PT driver for perf
> and has included a driver for Intel BTS. I have taken that and
There is already a BTS driver, although I've not used it ever, since
there's no useful tool for
On Sat, Jul 12, 2014 at 12:23:16AM +0900, DaeSeok Youn wrote:
> Can I modify the MAINTAINERS file for adding myself?
Yes. Just send a patch to add yourself.
git log -p MAINTAINERS
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 11 July 2014 17:30, Steven Rostedt wrote:
> On Fri, 11 Jul 2014 08:12:40 -0700
> "Paul E. McKenney" wrote:
>
>> On Fri, Jul 11, 2014 at 01:38:12PM +0200, Ard Biesheuvel wrote:
>> > Commit f7f7bac9cb1c ("rcu: Have the RCU tracepoints use the
>> > tracepoint_string
>> > infrastructure")
On Fri, Jul 11, 2014 at 12:47:26AM +0300, Oded Gabbay wrote:
> This patch enables the KFD to retrieve the kfd_process
> object from the process's mm_struct. This is needed because kfd_process
> lifespan is bound to the process's mm_struct lifespan.
>
> When KFD is notified about an mm_struct
2014-07-12 0:37 GMT+09:00, Dan Carpenter :
> On Sat, Jul 12, 2014 at 12:23:16AM +0900, DaeSeok Youn wrote:
>> Can I modify the MAINTAINERS file for adding myself?
>
> Yes. Just send a patch to add yourself.
OK. I will.
Thanks.
Regards,
Daeseok Youn.
>
> git log -p MAINTAINERS
>
> regards,
> dan
On Fri, Jul 11, 2014 at 06:56:26PM +0530, Amit Shah wrote:
> On (Wed) 09 Jul 2014 [12:07:25], Jason Cooper wrote:
> > Amit, Kees,
>
> (snip)
>
> > I'm cooling to the idea of the init function for virtio-rng, and it
> > might be best just to admit that there's no way to seed the entropy pool
> >
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this
On Fri, Jul 11, 2014 at 11:24:12AM -0400, Nick Krause wrote:
> On Fri, Jul 11, 2014 at 5:34 AM, Simon Horman wrote:
> > On Fri, Jul 04, 2014 at 12:34:58AM -0400, Nick Krause wrote:
> >> While searching for FIX ME messages when using cscope on the latest
> >> kernels I
> >> get a message on 68 of
i2c tuner and demod are unregisetred in .fini before fe detach.
dvb_unregister_frontend() and dvb_frontend_detach() invoke tuner
sleep() and release() interfaces. Change to unregister i2c tuner
and demod from em28xx_unregister_dvb() after unregistering dvb
and detaching fe.
Signed-off-by: Shuah
On Fri, Jul 11, 2014 at 11:44 AM, Simon Horman wrote:
> On Fri, Jul 11, 2014 at 11:24:12AM -0400, Nick Krause wrote:
>> On Fri, Jul 11, 2014 at 5:34 AM, Simon Horman wrote:
>> > On Fri, Jul 04, 2014 at 12:34:58AM -0400, Nick Krause wrote:
>> >> While searching for FIX ME messages when using
On Fri, 11 Jul 2014, Tejun Heo wrote:
> On Fri, Jul 11, 2014 at 11:21:56AM -0400, Tejun Heo wrote:
> > Even if that's the case, there's no reason to burden everyone with
> > this distinction. Most users just wanna say "I'm on this node.
> > Please allocate considering that". There's nothing
Signed-off-by: Geert Uytterhoeven
---
v2:
- New
---
Documentation/dmaengine.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/dmaengine.txt b/Documentation/dmaengine.txt
index 879b6e31e2da..87d3f192e160 100644
--- a/Documentation/dmaengine.txt
+++
To function correctly in the presence of an IOMMU, the DMA buffers must be
mapped using the DMA channel's device instead of the MSIOF platform
device's device.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Use "dma_chan.device->dev" instead of "dma_chan.dev->device",
- Also fix calls to
On Fri, Jul 11, 2014 at 10:55:59AM -0500, Christoph Lameter wrote:
> > Where X is the memless node. num_mem_id() on X would return either B
> > or C, right? If B or C can't satisfy the allocation, the allocator
> > would fallback to A from B and D for C, both of which aren't optimal.
> > It
On Fri, 11 Jul 2014, Tejun Heo wrote:
> Hello,
>
> On Fri, Jul 11, 2014 at 10:13:57AM -0500, Christoph Lameter wrote:
> > Allocators typically fall back but they wont in some cases if you say
> > that you want memory from a particular node. A GFP_THISNODE would force a
> > failure of the alloc.
On Fri, Jul 11, 2014 at 07:55:50AM -0700, Hugh Dickins wrote:
> On Fri, 11 Jul 2014, Sasha Levin wrote:
> >
> > There's no easy way to see whether a given task is actually holding a lock
> > or
> > is just blocking on it without going through all those tasks one by one and
> > looking at their
When SIGNATURE=y but depends on CRYPTO=m, it selects MPILIB as module
producing build break. This patch makes digsig to select crypto for
correcting dependency.
Signed-off-by: Dmitry Kasatkin
---
lib/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig
On 07/11/2014 05:51 PM, Thierry Reding wrote:
On Fri, Jul 11, 2014 at 05:18:30PM +0300, Mikko Perttunen wrote:
Add binding documentation for the nvidia,tegra124-emc device tree
node.
Signed-off-by: Mikko Perttunen
---
.../bindings/memory-controllers/tegra-emc.txt | 42
I got a message from random config robot that he found a build break...
It happens because certain modules which are compiled as builtin depends
on CRYPTO=m and select required components as modules instead of making
them builtin. Here is couple of patches to fix it.
config:
On Fri, Jul 11, 2014 at 10:58:52AM -0500, Christoph Lameter wrote:
> > But, GFP_THISNODE + numa_mem_id() is identical to numa_node_id() +
> > nearest node with memory fallback. Is there any case where the user
> > would actually want to always fail if it's on the memless node?
>
> GFP_THISNODE
As typically a shmobile SoC has less DMA channels than devices that can use
DMA, we may want to prioritize access to the DMA channels in the future.
This means that dmaengine_prep_slave_sg() may start failing arbitrarily.
Handle dmaengine_prep_slave_sg() failures gracefully by falling back to
As typically a shmobile SoC has less DMA channels than devices that can use
DMA, we may want to prioritize access to the DMA channels in the future.
This means that dmaengine_prep_slave_single() may start failing
arbitrarily.
Handle dmaengine_prep_slave_single() failures gracefully by falling
When ASYMMETRIC_KEYS=y, but depends on CRYPTO=m, selections will be also
modules.
In random config case OID_REGISTRY, MPILIB and ASN1 became modules producing
build
break. This patch removes asymmetric keys dependency from CRYPTO, but instead
selects CRYPTO and CRYPTO_HASH as they are needed.
On Fri, 11 Jul 2014, Tejun Heo wrote:
> On Fri, Jul 11, 2014 at 10:55:59AM -0500, Christoph Lameter wrote:
> > > Where X is the memless node. num_mem_id() on X would return either B
> > > or C, right? If B or C can't satisfy the allocation, the allocator
> > > would fallback to A from B and D
On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
> To support HSA on KV, we need to limit the number of vmids and pipes
> that are available for radeon's use with KV.
>
> This patch reserves VMIDs 8-15 for KFD (so radeon can only use VMIDs
> 0-7) and also makes radeon thinks that KV
If dmaengine_prep_slave_sg() or dmaengine_submit() fail, we may leak
unused DMA descriptors.
As per Documentation/dmaengine.txt, once a DMA descriptor has been
obtained, it must be submitted. Hence:
- First prepare and submit all DMA descriptors,
- Prepare the SPI controller for DMA,
-
If dmaengine_prep_slave_sg() or dmaengine_submit() fail, we may leak
unused DMA descriptors.
As per Documentation/dmaengine.txt, once a DMA descriptor has been
obtained, it must be submitted. Hence:
- First prepare and submit all DMA descriptors,
- Prepare the SPI controller for DMA,
-
On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
> Incidentally: do seccomp users know that on an x86-64 system you can
> recevie system calls from any of the x86 architectures, regardless of
> how the program is invoked? (This is unusual, so normally denying those
> "alien" calls is
On Fri, Jul 11, 2014 at 04:08:23PM +0100, Liviu Dudau wrote:
> On Fri, Jul 11, 2014 at 03:11:16PM +0100, Catalin Marinas wrote:
> > On Thu, Jul 10, 2014 at 11:36:10PM +0100, Bjorn Helgaas wrote:
> > > Most of the rest of the v7 discussion was about "Introduce a domain
> > > number for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/2014 11:51 PM, Mike Galbraith wrote:
> On Wed, 2014-07-02 at 10:47 -0400, Rik van Riel wrote:
>> On 07/01/2014 04:38 AM, Michael wang wrote:
>>> On 07/01/2014 04:20 PM, Peter Zijlstra wrote: [snip]
>
> Just wondering could we make
On Fri, Jul 11, 2014 at 08:51:06AM +0100, Vincent Guittot wrote:
> On 10 July 2014 15:16, Peter Zijlstra wrote:
> > On Mon, Jun 30, 2014 at 06:05:40PM +0200, Vincent Guittot wrote:
> >> This reverts commit f5f9739d7a0ccbdcf913a0b3604b134129d14f7e.
> >>
> >> We are going to use runnable_avg_sum
Commit 16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave:
introduce inline wrappers") changed the code to use the new API, but forgot
to update the error messages.
Signed-off-by: Geert Uytterhoeven
Cc: Mark Brown
Cc: Jiri Kosina
Cc: linux-...@vger.kernel.org
--
v2:
- New
---
And once with lkml added :/
--
Subject: Remove soon to be dead email address
My Red Hat email address will soon cease to be; remove it from the
tree in order to save the interweb some bounces.
Cc: Andrew Morton
Cc: Linus Torvalds
Signed-off-by: Peter Zijlstra
---
Commit 7e933d3b1e25b250b58b827ef455a1b489c84157 ("crypto: ux500: use
dmaengine_prep_slave_sg API") changed the code to use the new API, but
forgot to update an error message.
Signed-off-by: Geert Uytterhoeven
Cc: Herbert Xu
Cc: Jiri Kosina
Cc: linux-cry...@vger.kernel.org
--
v2:
- New
---
Commit 16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave:
introduce inline wrappers") changed the code to use the new API, but forgot
to update a comment.
Signed-off-by: Geert Uytterhoeven
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: Jiri Kosina
Cc:
Use the inline wrapper introduced by commit
16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave: introduce
inline wrappers").
Signed-off-by: Geert Uytterhoeven
Cc: Mark Brown
Cc: linux-...@vger.kernel.org
--
v2:
- New
---
drivers/spi/spi-atmel.c | 18 ++
1 file
On 07/11/2014 09:11 AM, Paul Moore wrote:
> On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
>> Incidentally: do seccomp users know that on an x86-64 system you can
>> recevie system calls from any of the x86 architectures, regardless of
>> how the program is invoked? (This is
During the last few years, several inline wrappers for DMA operations have
been introduced:
- commit 16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave:
introduce inline wrappers"),
- commit a14acb4ac2a1486f6633c55eb7f7ded07f3ec9fc ("DMAEngine: add
Commit 16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave:
introduce inline wrappers") changed the code to use the new API, but forgot
to update an error message.
Signed-off-by: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Cc: Jiri Kosina
Cc: linux-ser...@vger.kernel.org
--
v2:
-
On Fri, Jul 11, 2014 at 12:50:03AM +0300, Oded Gabbay wrote:
> Radeon and KFD share the doorbell aperture.
> Radeon sets it up, takes the doorbells required for its own rings
> and reports the setup to KFD.
> Radeon reserved doorbells are at the start of the doorbell aperture.
>
> Signed-off-by:
On Thursday, July 10, 2014 11:38:12 PM Richard Guy Briggs wrote:
> Add a definition for 32-bit native system calls under 64-bit x86
> architectures. This is distict from 32-bit emulation under 64-bit x86
> architectures.
>
> Cc: Paul Moore
> Cc: Eric Paris
> Cc: Al Viro
> Cc: Will Drewry
>
On 06/16/2014 09:17 AM, Peter Hurley wrote:
The tty_ldisc_flush() after port hardware shutdown is unnecessary;
the ldisc flush was just performed before the hardware shutdown
in tty_port_close_start() and the ldisc will be released when
uart_close() returns (because the last port close implies
On Fri, 2014-07-11 at 12:11 -0400, Paul Moore wrote:
> On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
> > Incidentally: do seccomp users know that on an x86-64 system you can
> > recevie system calls from any of the x86 architectures, regardless of
> > how the program is invoked?
On Fri, Jul 11, 2014 at 6:13 PM, Peter Zijlstra wrote:
> My Red Hat email address will soon cease to be; remove it from the
> tree in order to save the interweb some bounces.
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -4,8 +4,8 @@
> /*
> * Jump label support
>
As of commit commit f04cd40701deace2efb9edd7120e59366bda2118 ("fsldma: fix
controller lockups"), its last (and only ever) user is gone.
Signed-off-by: Geert Uytterhoeven
---
include/linux/dmaengine.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/dmaengine.h
On Fri, Jul 11, 2014 at 04:31:10PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> This patch implements generic versions of readsb(), readsw(), readsl(),
> readsq(), writesb(), writesw(), writesl() and writesq(). Variants of
> these string functions for I/O accesses (ins*() and outs*()
On Fri, 11 Jul 2014, Tejun Heo wrote:
> On Fri, Jul 11, 2014 at 10:58:52AM -0500, Christoph Lameter wrote:
> > > But, GFP_THISNODE + numa_mem_id() is identical to numa_node_id() +
> > > nearest node with memory fallback. Is there any case where the user
> > > would actually want to always fail
Hey Steven,
I having been testing what builds are still failing from Steven
Rothwell's tests and there seem to be two failing
still for blackfin. I am tracing the issues to make it easier for you
as a maintainer. BF561-ACVILON_defconfig
is failing in acvlion.c due to BFIN_NAND_PLAT_READY not
Am 11.07.2014 18:05, schrieb Jerome Glisse:
On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
To support HSA on KV, we need to limit the number of vmids and pipes
that are available for radeon's use with KV.
This patch reserves VMIDs 8-15 for KFD (so radeon can only use VMIDs
0-7)
On Friday, July 11, 2014 12:16:47 PM Eric Paris wrote:
> On Fri, 2014-07-11 at 12:11 -0400, Paul Moore wrote:
> > On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
> > > Incidentally: do seccomp users know that on an x86-64 system you can
> > > recevie system calls from any of the x86
On Fri, Jul 11, 2014 at 06:17:31PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jul 11, 2014 at 6:13 PM, Peter Zijlstra wrote:
> > My Red Hat email address will soon cease to be; remove it from the
> > tree in order to save the interweb some bounces.
>
> > --- a/include/linux/jump_label.h
> > +++
On 06/18/2014 02:44 AM, Qiaowei Ren wrote:
> + bt_addr = mpx_mmap(MPX_BT_SIZE_BYTES);
> + if (IS_ERR((void *)bt_addr)) {
> + pr_err("Bounds table allocation failed at entry addr %p\n",
> + bd_entry);
> + return bt_addr;
> + }
Don't
On Fri, Jul 11, 2014 at 12:18 PM, Christian König
wrote:
> Am 11.07.2014 18:05, schrieb Jerome Glisse:
>
>> On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
>>>
>>> To support HSA on KV, we need to limit the number of vmids and pipes
>>> that are available for radeon's use with KV.
On Fri, 2014-07-11 at 12:21 -0400, Paul Moore wrote:
> On Friday, July 11, 2014 12:16:47 PM Eric Paris wrote:
> > On Fri, 2014-07-11 at 12:11 -0400, Paul Moore wrote:
> > > On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
> > > > Incidentally: do seccomp users know that on an x86-64
On Fri, Jul 11, 2014 at 04:31:11PM +0100, Thierry Reding wrote:
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index a78562f21aab..ef54f5c8a7ae 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
[...]
> -#define iowrite16be(v,p) ({ __iowmb();
On Thu, Jul 10, 2014 at 03:38:33PM -0700, Joe Perches wrote:
> On Fri, 2014-07-11 at 00:50 +0300, Oded Gabbay wrote:
> > This patch adds the interface between the radeon driver and the kfd
> > driver. The interface implementation is contained in
> > radeon_kfd.c and radeon_kfd.h.
> []
> >
Hi Peter,
On Fri, Jul 11, 2014 at 6:21 PM, Peter Zijlstra wrote:
> On Fri, Jul 11, 2014 at 06:17:31PM +0200, Geert Uytterhoeven wrote:
>> On Fri, Jul 11, 2014 at 6:13 PM, Peter Zijlstra wrote:
>> > My Red Hat email address will soon cease to be; remove it from the
>> > tree in order to save the
On Fri, Jul 11, 2014 at 11:19:14AM -0500, Christoph Lameter wrote:
> Yes that works. But if we want a consistent node to allocate from (and
> avoid the fallbacks) then we need this patch. I think this is up to those
> needing memoryless nodes to figure out what semantics they need.
I'm not
Adds "Daeseok Youn" to maintainers list for dgap driver.
Signed-off-by: Daeseok Youn
Suggested-by: Dan Carpenter
Cc: Greg Kroah-Hartman
---
MAINTAINERS |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e3a5176..053ac24 100644
---
On Wed, Jul 02, 2014 at 03:32:59PM +0200, Joerg Roedel wrote:
> Hi David,
>
> On Wed, Apr 30, 2014 at 11:49:33AM +0100, David Woodhouse wrote:
> > There could be all kinds of existing mappings in the DMA page tables,
> > and I'm not sure it's safe to preserve them. What prevents the crashdump
> >
On Fri, Jul 11, 2014 at 12:50:05AM +0300, Oded Gabbay wrote:
> This patch adds a new interface to kfd2kgd_calls structure so that
> the kfd driver could get the virtual ram size of a specific
> radeon device.
>
> Signed-off-by: Oded Gabbay
What is vmem_size ? This need to be documented. I
On Thu, Jul 10, 2014 at 2:42 PM, Tuomas Tynkkynen wrote:
> The DFLL is the main clocksource for the fast CPU cluster on Tegra124
> and also provides automatic CPU rail voltage scaling as well. The DFLL
> is a separate IP block from the usual Tegra124 clock-and-reset
> controller, so it gets its
The x86_64 signal code claims to save and restore CS, FS, and GS,
and it further claims that this is the minimal set that's needed.
Neither of these claims is true. The code does not, and AFAICT
never has, saved or restored FS and GS, nor does it need to. On the
other hand, all 64-bit syscalls
The comment in the signal code says that apps can save/restore other
segments on their own. It's true that apps can *save* SS on their
own, but there's no way for apps to restore it: SYSCALL effectively
resets SS to __USER_DS, so any value that user code tries to load
into SS gets lost on entry
As far as I can tell, these fields have been set to zero on save and
ignored on restore since Linux was imported into git. Rename them
'__pad1' and '__pad2' to avoid confusion and to allow them to be
recycled some day.
I'm intentionally avoiding calling either of them __pad0: the field
formerly
On 07/11/2014 09:23 AM, Eric Paris wrote:
>>
>> You're not going to hear me ever say that I like how the x32 ABI was done,
>> it
>> is a real mess from a seccomp filter point of view and we have to do some
>> nasty stuff in libseccomp to make it all work correctly (see my comments on
>> the
Add decoding logic for new Fam15h model 60h.
Tested using mce_amd_inj module and works fine.
Signed-off-by: Aravind Gopalakrishnan
---
drivers/edac/mce_amd.c | 59 ++
1 file changed, 55 insertions(+), 4 deletions(-)
diff --git
On Friday, July 11, 2014 12:23:33 PM Eric Paris wrote:
> On Fri, 2014-07-11 at 12:21 -0400, Paul Moore wrote:
> > On Friday, July 11, 2014 12:16:47 PM Eric Paris wrote:
> > > On Fri, 2014-07-11 at 12:11 -0400, Paul Moore wrote:
> > > > On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
>
"Serge E. Hallyn" writes:
> Quoting chenhanx...@cn.fujitsu.com (chenhanx...@cn.fujitsu.com):
>> Hello,
>>
>> How to reproduce:
>> 1. Prepare a container, enable userns and disable netns
>> 2. use libvirt-lxc to start a container
>> 3. libvirt could not mount sysfs then failed to start.
>>
>>
On Fri, Jul 11, 2014 at 12:50:06AM +0300, Oded Gabbay wrote:
> This patch adds new interfaces to kfd2kgd_calls structure.
>
> The new interfaces allow the kfd driver to :
>
> 1. Allocated video memory through the radeon driver
> 2. Map and unmap video memory with GPUVM through the radeon driver
On Fri, Jul 11, 2014 at 8:29 AM, Tuomas Tynkkynen wrote:
>
> On the hardware level, the two I2C controllers sharing the same pins
> have knowledge of each other and won't start transmitting if the bus
> is busy (something different from the usual I2C arbitration, that is).
> I guess on the kernel
On Fri, Jul 11, 2014 at 12:50:07AM +0300, Oded Gabbay wrote:
> This patch adds a new interface to kfd2kgd_calls structure, which
> allows the kfd to lock and unlock the srbm_gfx_cntl register
Why does kfd needs to lock this register if kfd can not access
any of those register ? This sounds broken
From: Bo Shen
Add clocks for usb device, or else switch to CCF, the gadget
won't work.
Reported-by: Jiri Prchal
Signed-off-by: Bo Shen
Acked-by: Alexandre Belloni
Tested-by: Jiri Prchal
Signed-off-by: Nicolas Ferre
---
Arnd, Olof, Kevin,
This fix is the only one that I have for 3.16-rc
On Thursday, July 10, 2014 11:38:13 PM Richard Guy Briggs wrote:
> Commit
> fca460f h...@zytor.com 2012-02-19 07:56:26 -0800
> x32: Handle the x32 system call flag
>
> provided a method to multiplex architecture with the syscall number for X32
> calls.
>
> Commit
> 8b4b9f2
On Fri, Jul 11, 2014 at 12:50:08AM +0300, Oded Gabbay wrote:
> The KFD driver should be loaded when the radeon driver is loaded and
> should be finalized when the radeon driver is removed.
>
> This patch adds a function call to initialize kfd from radeon_init
> and a function call to finalize kfd
On Fri, 2014-07-11 at 18:17 +0200, Geert Uytterhoeven wrote:
> On Fri, Jul 11, 2014 at 6:13 PM, Peter Zijlstra wrote:
> > My Red Hat email address will soon cease to be; remove it from the
> > tree in order to save the interweb some bounces.
> > --- a/include/linux/jump_label.h
[]
> > - *
On Fri, Jul 11, 2014 at 7:18 AM, Mikko Perttunen wrote:
> Add binding documentation for the nvidia,tegra124-emc device tree
> node.
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
> b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
>
On 07/11/2014 09:36 AM, Paul Moore wrote:
>
> Arguably audit is broken anyway by not correctly treating syscall numbers as
> 32 bit integers like everyone else.
>
That is really the root cause of the problem. x86 is not the only
architecture with a sparse syscall numbering scheme (in fact the
501 - 600 of 1880 matches
Mail list logo
