On Thu 05-04-18 00:29:06, Cyrill Gorcunov wrote:
> On Wed, Apr 04, 2018 at 01:53:08PM -0700, Randy Dunlap wrote:
[...]
> > Yeah, that one's wrong also. :)
>
> So, maybe just get rid of any warning message at all?
or simply do
pr_warn("PR_SET_MM_MAP has been removed. Use instead\n");
--
On Wed, Apr 04, 2018 at 01:18:36PM -0400, Peter Jones wrote:
> > On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> > > * Add the EFI Firmware Volume Protocol to include/linux/efi.h:
> > >
> > > https://www.intel.com/content/dam/doc/reference-guide/efi-firmware-file-volume-specifica
On 04/04/2018 19:35, Stefan Fritsch wrote:
> On Wednesday, 4 April 2018 19:24:20 CEST Paolo Bonzini wrote:
>> On 04/04/2018 19:10, Konrad Rzeszutek Wilk wrote:
>>> Should there be a corresponding test-case?
>>
>> Good point! Stefan, could you write one?
>
> Is there infrastructure for such tests?
LEROY Christophe writes:
> Mathieu Malaterre a écrit :
>
>> Add gcc attribute unused for two variables. Fix warnings treated as errors
>> with W=1:
>>
>> arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set
>> but not used [-Werror=unused-but-set-variable]
>>
>> Suggested-by: C
On Wed 04-04-18 21:49:54, Buddy Lumpkin wrote:
> v2:
> - Make update_kswapd_threads_node less racy
> - Handle locking for case where CONFIG_MEMORY_HOTPLUG=n
Please do not repost with such a small changes. It is much more
important to sort out the big picture first and only then deal with
minor imp
On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote:
> These comments answer all the questions I had for myself when
> implementing a driver using the GPU scheduler.
>
> Signed-off-by: Eric Anholt
Pulling all these comments into the generated kerneldoc would be
awesome, maybe as a new "GPU Schedu
On 07/03/18 16:11, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 07, 2018 at 10:06:50AM +0200, Adrian Hunter escreveu:
>> On 06/03/18 22:25, Arnaldo Carvalho de Melo wrote:
>>> Em Tue, Mar 06, 2018 at 11:13:17AM +0200, Adrian Hunter escreveu:
In preparation for supporting AUX area sampling buf
On 4 April 2018 at 21:56, Boris Brezillon wrote:
> On Wed, 04 Apr 2018 21:49:26 +0200
> Robert Jarzmik wrote:
>
>> Ulf Hansson writes:
>>
>> > On 2 April 2018 at 16:26, Robert Jarzmik wrote:
>> >> Hi,
>> >>
>> >> This serie is aimed at removing the dmaengine slave compat use, and
>> >> transfe
This patch removes a redundant store on regs->flags introduced
by commit:
71eb9ee9596d ("perf/x86/intel: Fix linear IP of PEBS real_ip on Haswell and
later CPUs")
We were clearing the PERF_EFLAGS_EXACT but it was overwritten by
regs->flags = pebs->flags later on.
The PERF_EFLAGS_EXACT is a soft
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
fs/dax.c
between commit:
fab6964f22b9 ("mm, fs, dax: handle layout changes to pinned dax mappings")
which was removed from the nvdimm tree today and patch:
"page cache: use xa_lock"
from the akpm tree.
I fixed it
On Wed, Apr 4, 2018 at 3:31 AM, Greg KH wrote:
> Lars-Peter Clausen (2):
> usb: gadget: ffs: Execute copy_to_user() with USER_DS set
https://git.kernel.org/linus/4058ebf33cb0be88ca516f968eda24ab7b6b93e4
Isn't there a better way to do this without the set_fs() usage? We've
been try to elimi
On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +)
> Merge tag 'ext4_for_linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> syzbot dash
On Tue, Mar 27, 2018 at 11:01 AM, Jagan Teki wrote:
> Like axp221, axp223, axp813 the axp803 is also supporting external
> regulator to drive the OTG VBus through N_VBUSEN PMIC pin.
>
> Add support for it.
>
> Signed-off-by: Jagan Teki
> Reviewed-by: Rob Herring
> Reviewed-by: Chen-Yu Tsai
> -
On Thu, Apr 05, 2018 at 12:11:39PM +0530, Jagan Teki wrote:
> On Tue, Mar 27, 2018 at 11:01 AM, Jagan Teki
> wrote:
> > Like axp221, axp223, axp813 the axp803 is also supporting external
> > regulator to drive the OTG VBus through N_VBUSEN PMIC pin.
> >
> > Add support for it.
> >
> > Signed-off
On Thu, 2018-04-05 at 09:11 +1000, Nicholas Piggin wrote:
> Hi,
>
> I'm seeing some pretty big latencies on a ~idle system when a CPU wakes
> out of a nohz idle. Looks like it's due to the taking a lot of remote
> locks and cache lines. irqoff trace:
>
> latency: 407 us, #608/608, CPU#3 | (M:serv
On Thu, Apr 5, 2018 at 8:29 AM, Ulf Hansson wrote:
> On 4 April 2018 at 21:56, Boris Brezillon wrote:
>> On Wed, 04 Apr 2018 21:49:26 +0200
>> Robert Jarzmik wrote:
>>
>>> Ulf Hansson writes:
>>>
>>> > On 2 April 2018 at 16:26, Robert Jarzmik wrote:
>>> >> Hi,
>>> >>
>>> >> This serie is aimed
Arnd Bergmann writes:
> I'm still unable to follow through that code, but I understand now that
> the device you pass to dma_request_slave_channel() is not the one
> we'd like it to be here.
>
> Where exactly does that call to dma_request_chan() happen? Is this
> the one in dmaengine_pcm_new()? C
901 - 917 of 917 matches
Mail list logo