Hi Janusz,
On Fri, 12 Oct 2018 22:41:00 +0200
Janusz Krzysztofik wrote:
> Each controller driver with access to NAND R/B pin over GPIO would have
> to reimplement the polling loop otherwise.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> Changelog:
> v2:
> New patch - v1 consisted of only one
Hi Janusz,
On Fri, 12 Oct 2018 22:41:00 +0200
Janusz Krzysztofik wrote:
> Each controller driver with access to NAND R/B pin over GPIO would have
> to reimplement the polling loop otherwise.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> Changelog:
> v2:
> New patch - v1 consisted of only one
On Thu, Oct 11, 2018 at 07:58:28PM +0200, Geert Uytterhoeven wrote:
> drivers/tty/amiserial.c:1076:3: error: 'retval' undeclared (first use
> in this function)
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/13544535/
> http://kisskb.ellerman.id.au/kisskb/buildresult/13544413/
Fixed and
On Thu, Oct 11, 2018 at 07:58:28PM +0200, Geert Uytterhoeven wrote:
> drivers/tty/amiserial.c:1076:3: error: 'retval' undeclared (first use
> in this function)
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/13544535/
> http://kisskb.ellerman.id.au/kisskb/buildresult/13544413/
Fixed and
The UIO file mask in MAINTAINERS was incorrectly directing UIOVEC
(include/linux/uio.h) patches to Greg.
Tag Al as the UIOVEC maintainer as Ingo and others have explicitly
required his ack before taking architecture patches that touch
lib/iov_iter.c.
Cc: Al Viro
Reported-by: Greg Kroah-Hartman
The UIO file mask in MAINTAINERS was incorrectly directing UIOVEC
(include/linux/uio.h) patches to Greg.
Tag Al as the UIOVEC maintainer as Ingo and others have explicitly
required his ack before taking architecture patches that touch
lib/iov_iter.c.
Cc: Al Viro
Reported-by: Greg Kroah-Hartman
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.
Mixed printk() output makes it hard to interpret. Assuming that we will go
to a direction that we allow
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.
Mixed printk() output makes it hard to interpret. Assuming that we will go
to a direction that we allow
On Mon, Oct 08, 2018 at 11:50:09AM -0700, Dan Williams wrote:
> The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
> (include/linux/uio.h) patches to Greg.
>
> Tag Al as the UACCESS maintainer as Ingo and others have explicitly
> required his ack before taking architecture patches
On Mon, Oct 08, 2018 at 11:50:09AM -0700, Dan Williams wrote:
> The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
> (include/linux/uio.h) patches to Greg.
>
> Tag Al as the UACCESS maintainer as Ingo and others have explicitly
> required his ack before taking architecture patches
On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Add two struct page fields that, combined, are unioned with
> struct page->lru. There is no change in the size of
> struct page. These new fields are for type safety and clarity.
>
> Also add page
On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Add two struct page fields that, combined, are unioned with
> struct page->lru. There is no change in the size of
> struct page. These new fields are for type safety and clarity.
>
> Also add page
inux-next.
drivers/gpio/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20181012.orig/drivers/gpio/Kconfig
+++ linux-next-20181012/drivers/gpio/Kconfig
@@ -439,7 +439,7 @@ config GPIO_SIOX
config GPIO_SNPS_CREG
bool "Synopsys GPIO via CREG (Cont
inux-next.
drivers/gpio/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20181012.orig/drivers/gpio/Kconfig
+++ linux-next-20181012/drivers/gpio/Kconfig
@@ -439,7 +439,7 @@ config GPIO_SIOX
config GPIO_SNPS_CREG
bool "Synopsys GPIO via CREG (Cont
On Sat, Oct 13, 2018 at 4:23 AM Maxime Ripard wrote:
>
> On Fri, Oct 12, 2018 at 04:39:14PM +0300, Aleksandr Aleksandrov wrote:
> > Hi Andreas,
> >
> > Thanks for your feedback!
> >
> > > > + *
> > > > + * Copyright (C) 2018 Aleksandr Aleksandrov
> > > >
> > > > + */
> > > > +
> > > >
On Sat, Oct 13, 2018 at 4:23 AM Maxime Ripard wrote:
>
> On Fri, Oct 12, 2018 at 04:39:14PM +0300, Aleksandr Aleksandrov wrote:
> > Hi Andreas,
> >
> > Thanks for your feedback!
> >
> > > > + *
> > > > + * Copyright (C) 2018 Aleksandr Aleksandrov
> > > >
> > > > + */
> > > > +
> > > >
On Saturday, October 13, 2018 12:31 AM, Andi Kleen wrote:
> > 4. Results
> > - Without this optimization, the guest pmi handling time is
> > ~450 ns, and the max sampling rate is reduced to 250.
> > - With this optimization, the guest pmi handling time is ~9000 ns
> > (i.e.
On Saturday, October 13, 2018 12:31 AM, Andi Kleen wrote:
> > 4. Results
> > - Without this optimization, the guest pmi handling time is
> > ~450 ns, and the max sampling rate is reduced to 250.
> > - With this optimization, the guest pmi handling time is ~9000 ns
> > (i.e.
From: Steven Rostedt (VMware)
Now that ftracetest has over 80 tests, it is difficult to simply scroll
up the console window to find the failed tests when it reports just two
tests have failed. In order to make this stand out better, have the
color of the word "PASS" be green, "FAIL" and "XFAIL"
From: Steven Rostedt (VMware)
Now that ftracetest has over 80 tests, it is difficult to simply scroll
up the console window to find the failed tests when it reports just two
tests have failed. In order to make this stand out better, have the
color of the word "PASS" be green, "FAIL" and "XFAIL"
The mm-of-the-moment snapshot 2018-10-12-19-18 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2018-10-12-19-18 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
Hi Mathieu,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.19-rc7 next-20181012]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Mathieu,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.19-rc7 next-20181012]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Fri, Oct 12, 2018 at 8:12 PM Bridgers, Vince
wrote:
>
>
>
> -Original Message-
> From: Thor Thayer
> Sent: Friday, October 12, 2018 3:49 PM
> To: Greg KH
> Cc: geert+rene...@glider.be; jho...@kernel.org; at...@kernel.org;
> bhelg...@google.com; james.hart...@sondrel.com;
On Fri, Oct 12, 2018 at 8:12 PM Bridgers, Vince
wrote:
>
>
>
> -Original Message-
> From: Thor Thayer
> Sent: Friday, October 12, 2018 3:49 PM
> To: Greg KH
> Cc: geert+rene...@glider.be; jho...@kernel.org; at...@kernel.org;
> bhelg...@google.com; james.hart...@sondrel.com;
On Sat, 13 Oct 2018 10:30:57 +0900
Masanari Iida wrote:
> This patch fixes some spelling typos.
>
> Signed-off-by: Masanari Iida
> ---
> Documentation/trace/histogram.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/trace/histogram.rst
>
On Sat, 13 Oct 2018 10:30:57 +0900
Masanari Iida wrote:
> This patch fixes some spelling typos.
>
> Signed-off-by: Masanari Iida
> ---
> Documentation/trace/histogram.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/trace/histogram.rst
>
Hi,
Linux 4.19-rc7, x86_64 laptop.
I don't have an ubifs filesystem. When I just modprobe ubifs and then
rmmod ubifs, I get 2 WARNINGs from these 2 lines:
static void __exit ubifs_exit(void)
{
WARN_ON(list_empty(_infos));
WARN_ON(atomic_long_read(_clean_zn_cnt) == 0);
Is this
Hi,
Linux 4.19-rc7, x86_64 laptop.
I don't have an ubifs filesystem. When I just modprobe ubifs and then
rmmod ubifs, I get 2 WARNINGs from these 2 lines:
static void __exit ubifs_exit(void)
{
WARN_ON(list_empty(_infos));
WARN_ON(atomic_long_read(_clean_zn_cnt) == 0);
Is this
On 10/12/18 6:30 PM, Masanari Iida wrote:
> This patch fixes some spelling typos.
>
> Signed-off-by: Masanari Iida
> ---
> Documentation/trace/histogram.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Randy Dunlap
thanks.
--
~Randy
On 10/12/18 6:30 PM, Masanari Iida wrote:
> This patch fixes some spelling typos.
>
> Signed-off-by: Masanari Iida
> ---
> Documentation/trace/histogram.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Randy Dunlap
thanks.
--
~Randy
This patch fixes some spelling typos.
Signed-off-by: Masanari Iida
---
Documentation/trace/histogram.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/trace/histogram.rst
b/Documentation/trace/histogram.rst
index 5ac724baea7d..7dda76503127 100644
---
This patch fixes some spelling typos.
Signed-off-by: Masanari Iida
---
Documentation/trace/histogram.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/trace/histogram.rst
b/Documentation/trace/histogram.rst
index 5ac724baea7d..7dda76503127 100644
---
When compiling the kernel with Clang, this warning appears even though
it is disabled for the whole kernel because this folder has its own set
of KBUILD_CFLAGS. It was disabled before the beginning of git history.
In file included from arch/x86/boot/compressed/kaslr.c:29:
In file included from
The core driver, esp_scsi, does not use the ESP_CONFIG2_FENAB bit, so
the chip's Transfer Counter register is only 16 bits wide (not 24).
A larger transfer cannot work and will theoretically result in a failed
command and a "DMA length is zero" error.
Fixes: 3109e5ae0311
Signed-off-by: Finn Thain
If a target disconnects during a PIO data transfer the command may
fail when the target reconnects:
scsi host1: DMA length is zero!
scsi host1: cur adr[0438] len[]
The scsi bus is then reset. This happens because the residual reached
zero before the transfer was completed.
The usual
-Original Message-
From: Thor Thayer
Sent: Friday, October 12, 2018 3:49 PM
To: Greg KH
Cc: geert+rene...@glider.be; jho...@kernel.org; at...@kernel.org;
bhelg...@google.com; james.hart...@sondrel.com; linux-kernel@vger.kernel.org;
Bridgers, Vince
Subject: Re: [PATCH] MAINTAINERS:
As a temporary measure, the code to implement PIO transfers was
duplicated in zorro_esp and mac_esp. Now that this code has stabilized,
move it into the core driver to eliminate the duplication.
This replaces the inline assembler with more portable writesb() calls.
Optimizing the m68k writesb()
When compiling the kernel with Clang, this warning appears even though
it is disabled for the whole kernel because this folder has its own set
of KBUILD_CFLAGS. It was disabled before the beginning of git history.
In file included from arch/x86/boot/compressed/kaslr.c:29:
In file included from
The core driver, esp_scsi, does not use the ESP_CONFIG2_FENAB bit, so
the chip's Transfer Counter register is only 16 bits wide (not 24).
A larger transfer cannot work and will theoretically result in a failed
command and a "DMA length is zero" error.
Fixes: 3109e5ae0311
Signed-off-by: Finn Thain
If a target disconnects during a PIO data transfer the command may
fail when the target reconnects:
scsi host1: DMA length is zero!
scsi host1: cur adr[0438] len[]
The scsi bus is then reset. This happens because the residual reached
zero before the transfer was completed.
The usual
-Original Message-
From: Thor Thayer
Sent: Friday, October 12, 2018 3:49 PM
To: Greg KH
Cc: geert+rene...@glider.be; jho...@kernel.org; at...@kernel.org;
bhelg...@google.com; james.hart...@sondrel.com; linux-kernel@vger.kernel.org;
Bridgers, Vince
Subject: Re: [PATCH] MAINTAINERS:
As a temporary measure, the code to implement PIO transfers was
duplicated in zorro_esp and mac_esp. Now that this code has stabilized,
move it into the core driver to eliminate the duplication.
This replaces the inline assembler with more portable writesb() calls.
Optimizing the m68k writesb()
Unroll the raw_outsb() loop using the optimized assembler code from
raw_outsw(). That code is copied and pasted, with movew changed to moveb.
This improves the performance of sequential write transfers using mac_esp
in PIO mode by 5% or 10%. (The DMA controller on the 840av/660av models is
still
Unroll the raw_outsb() loop using the optimized assembler code from
raw_outsw(). That code is copied and pasted, with movew changed to moveb.
This improves the performance of sequential write transfers using mac_esp
in PIO mode by 5% or 10%. (The DMA controller on the 840av/660av models is
still
Clang warns that the declaration of jiffies in include/linux/jiffies.h
doesn't match the definition in arch/x86/time/kernel.c:
arch/x86/kernel/time.c:29:42: warning: section does not match previous
declaration [-Wsection]
__visible volatile unsigned long jiffies __cacheline_aligned =
Clang warns that the declaration of jiffies in include/linux/jiffies.h
doesn't match the definition in arch/x86/time/kernel.c:
arch/x86/kernel/time.c:29:42: warning: section does not match previous
declaration [-Wsection]
__visible volatile unsigned long jiffies __cacheline_aligned =
From: Du Changbin
Currently, the pci_size() function actually return 'size-1'.
Make it return real size to avoid confusing.
Signed-off-by: Du Changbin
---
drivers/pci/probe.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
From: Du Changbin
Currently, the pci_size() function actually return 'size-1'.
Make it return real size to avoid confusing.
Signed-off-by: Du Changbin
---
drivers/pci/probe.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
For simplicity and consistency, this patch provides an implementation
for signal-based fault notification prior to the coredump of a child
process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
be used by an application to express its interest and to specify the
signal (SIGCHLD or
For simplicity and consistency, this patch provides an implementation
for signal-based fault notification prior to the coredump of a child
process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
be used by an application to express its interest and to specify the
signal (SIGCHLD or
On 10/12/18 4:07 AM, Balbir Singh wrote:
> On Thu, Oct 11, 2018 at 11:00:14PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>> +static int pin_page_for_dma(struct page *page)
>> +{
>> +int ret = 0;
>> +struct zone *zone;
>> +
>> +page = compound_head(page);
>> +
On 10/12/18 4:07 AM, Balbir Singh wrote:
> On Thu, Oct 11, 2018 at 11:00:14PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>> +static int pin_page_for_dma(struct page *page)
>> +{
>> +int ret = 0;
>> +struct zone *zone;
>> +
>> +page = compound_head(page);
>> +
On 10/12/18 3:56 AM, Balbir Singh wrote:
> On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>> + * Because page->dma_pinned_flags is unioned with page->lru, any page that
>> + * uses these flags must NOT be on an LRU. That's partly enforced by
>>
On 10/12/18 3:56 AM, Balbir Singh wrote:
> On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>> + * Because page->dma_pinned_flags is unioned with page->lru, any page that
>> + * uses these flags must NOT be on an LRU. That's partly enforced by
>>
On Sat, Oct 13, 2018 at 2:04 AM Edgecombe, Rick P
wrote:
> On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> > On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> > wrote:
> > > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > > Why all the rbtree stuff instead of stashing a pointer
On Sat, Oct 13, 2018 at 2:04 AM Edgecombe, Rick P
wrote:
> On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> > On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> > wrote:
> > > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > > Why all the rbtree stuff instead of stashing a pointer
kernel test robot writes:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> siginfo-next
>
This is an odd one. This is the first time I recall the lkp test robot
emailing
kernel test robot writes:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> siginfo-next
>
This is an odd one. This is the first time I recall the lkp test robot
emailing
On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or something like that?
> >
> > Since
On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or something like that?
> >
> > Since
On Wed, 10 Oct 2018 23:49:45 +0200 Sebastian Andrzej Siewior
wrote:
> On 2018-10-10 11:57:41 [+0200], Dmitry Vyukov wrote:
> > Yes. Clark's patch looks good to me. Probably would be useful to add a
> > comment as to why raw spinlock is used (otherwise somebody may
> > refactor it back later).
>
On Wed, 10 Oct 2018 23:49:45 +0200 Sebastian Andrzej Siewior
wrote:
> On 2018-10-10 11:57:41 [+0200], Dmitry Vyukov wrote:
> > Yes. Clark's patch looks good to me. Probably would be useful to add a
> > comment as to why raw spinlock is used (otherwise somebody may
> > refactor it back later).
>
On Fri, 12 Oct 2018, Andrew Morton wrote:
> > The slab allocator has a heuristic that checks whether the internal
> > fragmentation is satisfactory and, if not, increases cachep->gfporder to
> > try to improve this.
> >
> > If the amount of waste is the same at higher cachep->gfporder values,
>
On Fri, 12 Oct 2018, Andrew Morton wrote:
> > The slab allocator has a heuristic that checks whether the internal
> > fragmentation is satisfactory and, if not, increases cachep->gfporder to
> > try to improve this.
> >
> > If the amount of waste is the same at higher cachep->gfporder values,
>
> Why would the cpu topology report 0 cpus? I added a debug entry to
> cpu_usage_stat and /proc/stat showed it as an extra column. Then
> fscanf parsing in for_all_cpus() failed, causing the SIGFPE.
>
> This is not an issue. Thanks.
Yes, it is true that turbostat doesn't check for systems with
> Why would the cpu topology report 0 cpus? I added a debug entry to
> cpu_usage_stat and /proc/stat showed it as an extra column. Then
> fscanf parsing in for_all_cpus() failed, causing the SIGFPE.
>
> This is not an issue. Thanks.
Yes, it is true that turbostat doesn't check for systems with
On Fri, 2018-10-12 at 22:01 +, Edgecombe, Rick P wrote:
> On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> > +++ Dave Hansen [11/10/18 16:47 -0700]:
> > > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > > + if (check_inc_mod_rlimit(size))
> > > > + return NULL;
>
On Fri, 2018-10-12 at 22:01 +, Edgecombe, Rick P wrote:
> On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> > +++ Dave Hansen [11/10/18 16:47 -0700]:
> > > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > > + if (check_inc_mod_rlimit(size))
> > > > + return NULL;
>
From: Jithu Joseph
When the last CPU in an rdt_domain goes offline, its rdt_domain struct
gets freed. Current pseudo-locking code is unaware of this scenario
and tries to dereference the freed structure in a few places.
Add checks to prevent pseudo-locking code from doing this.
While further
From: Jithu Joseph
When the last CPU in an rdt_domain goes offline, its rdt_domain struct
gets freed. Current pseudo-locking code is unaware of this scenario
and tries to dereference the freed structure in a few places.
Add checks to prevent pseudo-locking code from doing this.
While further
On 10/11/18 11:30 PM, Balbir Singh wrote:
On Thu, Oct 11, 2018 at 11:00:09PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.
In preparation for that, consolidate the error
On 10/11/18 11:30 PM, Balbir Singh wrote:
On Thu, Oct 11, 2018 at 11:00:09PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.
In preparation for that, consolidate the error
From: Colin Ian King
Trivial fix to spelling mistake in RT_TRACE message text.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
From: Colin Ian King
Trivial fix to spelling mistake in RT_TRACE message text.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
On 10/12/18 12:35 AM, Balbir Singh wrote:
On Thu, Oct 11, 2018 at 11:00:10PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
[...]>> +/*
+ * put_user_pages_dirty() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ *
On 10/12/18 12:35 AM, Balbir Singh wrote:
On Thu, Oct 11, 2018 at 11:00:10PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
[...]>> +/*
+ * put_user_pages_dirty() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ *
On Fri, Oct 12, 2018 at 11:26:30AM -0700, Solio Sarabia wrote:
> Hi --
>
> turbostat 17.06.23 is throwing an exception on a custom linux-4.16.12
> kernel, on Xeon E5-2699 v4 Broadwell EP, 2S, 22C/S, 44C total, HT off,
> VTx off.
>
> Initially the system had 4.4.0-137. Then I built and installed
> -Original Message-
> From: Stephen Hemminger
> Sent: Friday, October 12, 2018 6:21 PM
> To: Haiyang Zhang
> Cc: Haiyang Zhang ; da...@davemloft.net;
> net...@vger.kernel.org; o...@aepfle.de; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; vkuznets
> Subject: Re:
On Fri, Oct 12, 2018 at 11:26:30AM -0700, Solio Sarabia wrote:
> Hi --
>
> turbostat 17.06.23 is throwing an exception on a custom linux-4.16.12
> kernel, on Xeon E5-2699 v4 Broadwell EP, 2S, 22C/S, 44C total, HT off,
> VTx off.
>
> Initially the system had 4.4.0-137. Then I built and installed
> -Original Message-
> From: Stephen Hemminger
> Sent: Friday, October 12, 2018 6:21 PM
> To: Haiyang Zhang
> Cc: Haiyang Zhang ; da...@davemloft.net;
> net...@vger.kernel.org; o...@aepfle.de; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; vkuznets
> Subject: Re:
On Fri, 12 Oct 2018 14:24:57 -0700 (PDT) David Rientjes
wrote:
> The slab allocator has a heuristic that checks whether the internal
> fragmentation is satisfactory and, if not, increases cachep->gfporder to
> try to improve this.
>
> If the amount of waste is the same at higher
On Fri, 12 Oct 2018 14:24:57 -0700 (PDT) David Rientjes
wrote:
> The slab allocator has a heuristic that checks whether the internal
> fragmentation is satisfactory and, if not, increases cachep->gfporder to
> try to improve this.
>
> If the amount of waste is the same at higher
On Mon, Oct 08, 2018 at 02:25:38PM +0100, Charles Keepax wrote:
> Lochnagar is an evaluation and development board for Cirrus
> Logic Smart CODEC and Amp devices. It allows the connection of
> most Cirrus Logic devices on mini-cards, as well as allowing
> connection of various application
Quoting Ricardo Salveti (2018-09-14 11:53:02)
> On Thu, Jun 14, 2018 at 6:55 PM wrote:
> >
> > From: Ilia Lin
> >
> > Use devm_clk_hw_register instead of clk_hw_register
> > to simplify the usage of this API. This way drivers that call
> > the clk_hw_register_fixed_factor won't need to maintain
On Mon, Oct 08, 2018 at 02:25:38PM +0100, Charles Keepax wrote:
> Lochnagar is an evaluation and development board for Cirrus
> Logic Smart CODEC and Amp devices. It allows the connection of
> most Cirrus Logic devices on mini-cards, as well as allowing
> connection of various application
Quoting Ricardo Salveti (2018-09-14 11:53:02)
> On Thu, Jun 14, 2018 at 6:55 PM wrote:
> >
> > From: Ilia Lin
> >
> > Use devm_clk_hw_register instead of clk_hw_register
> > to simplify the usage of this API. This way drivers that call
> > the clk_hw_register_fixed_factor won't need to maintain
On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> +++ Dave Hansen [11/10/18 16:47 -0700]:
> > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > + if (check_inc_mod_rlimit(size))
> > > + return NULL;
> > > +
> > > p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> >
On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> +++ Dave Hansen [11/10/18 16:47 -0700]:
> > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > + if (check_inc_mod_rlimit(size))
> > > + return NULL;
> > > +
> > > p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> >
Remove the duplicated lock_class_ops percpu array that is not used
anywhere.
Fixes: 8ca2b56cd7da ("locking/lockdep: Make class->ops a percpu counter
and move it under CONFIG_DEBUG_LOCKDEP=y")
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 1 -
1 file changed, 1 deletion(-)
diff
Remove the duplicated lock_class_ops percpu array that is not used
anywhere.
Fixes: 8ca2b56cd7da ("locking/lockdep: Make class->ops a percpu counter
and move it under CONFIG_DEBUG_LOCKDEP=y")
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 1 -
1 file changed, 1 deletion(-)
diff
If you look at the bindings for the UFS Host Controller it says:
- compatible: must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may
also list one or more of the following:
"qcom,msm8994-ufshc"
"qcom,msm8996-ufshc"
"qcom,ufshc"
My
If you look at the bindings for the UFS Host Controller it says:
- compatible: must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may
also list one or more of the following:
"qcom,msm8994-ufshc"
"qcom,msm8996-ufshc"
"qcom,ufshc"
My
Digging through the "phy-qcom-qmp" showed me many inconsistencies
between the bindings and the reality of the driver. Let's fix them
all.
* In commit 2d66eab18375 ("dt-bindings: phy: qmp: Add support for QMP
phy in IPQ8074") we probably should have explicitly listed that
there are no clocks
Digging through the "phy-qcom-qmp" showed me many inconsistencies
between the bindings and the reality of the driver. Let's fix them
all.
* In commit 2d66eab18375 ("dt-bindings: phy: qmp: Add support for QMP
phy in IPQ8074") we probably should have explicitly listed that
there are no clocks
Hi,
I am running into a perf stat issue with the -p option which allows you
to attach to a running process. If that process happens to terminate
while under monitoring
perf hangs in there and never terminates. The proper behavior would be to stop.
I can see the issue in that the attached process
Hi,
I am running into a perf stat issue with the -p option which allows you
to attach to a running process. If that process happens to terminate
while under monitoring
perf hangs in there and never terminates. The proper behavior would be to stop.
I can see the issue in that the attached process
The slab allocator has a heuristic that checks whether the internal
fragmentation is satisfactory and, if not, increases cachep->gfporder to
try to improve this.
If the amount of waste is the same at higher cachep->gfporder values,
there is no significant benefit to allocating higher order
The slab allocator has a heuristic that checks whether the internal
fragmentation is satisfactory and, if not, increases cachep->gfporder to
try to improve this.
If the amount of waste is the same at higher cachep->gfporder values,
there is no significant benefit to allocating higher order
1 - 100 of 1114 matches
Mail list logo
