Re: [RESEND PATCH v4 3/8] gpio: 104-dio-48e: Utilize for_each_set_clump macro

On Tue, Oct 02, 2018 at 09:00:45AM +0200, Rasmus Villemoes wrote: > On 2018-10-02 03:14, William Breathitt Gray wrote: > > /* clear bits array to a clean slate */ > > bitmap_zero(bits, chip->ngpio); > > > > - /* get bits are evaluated a gpio port register at a time */ > > - for (i =

Re: [RESEND PATCH v4 3/8] gpio: 104-dio-48e: Utilize for_each_set_clump macro

On Tue, Oct 02, 2018 at 09:00:45AM +0200, Rasmus Villemoes wrote: > On 2018-10-02 03:14, William Breathitt Gray wrote: > > /* clear bits array to a clean slate */ > > bitmap_zero(bits, chip->ngpio); > > > > - /* get bits are evaluated a gpio port register at a time */ > > - for (i =

Re: [PATCH] watchdog: ts4800: release syscon device node in ts4800_wdt_probe()

On 10/13/2018 01:51 PM, Alexey Khoroshilov wrote: Put syscon device node when it is not needed anymore. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Reviewed-by: Guenter Roeck --- drivers/watchdog/ts4800_wdt.c | 1 + 1 file changed,

Re: [PATCH] watchdog: ts4800: release syscon device node in ts4800_wdt_probe()

On 10/13/2018 01:51 PM, Alexey Khoroshilov wrote: Put syscon device node when it is not needed anymore. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Reviewed-by: Guenter Roeck --- drivers/watchdog/ts4800_wdt.c | 1 + 1 file changed,

What is the expected date of release for 4.19

Hello I would like to know the expected date of release of 4.19 kernel. Thanks ~S

What is the expected date of release for 4.19

Hello I would like to know the expected date of release of 4.19 kernel. Thanks ~S

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Urgent,

Hello i need your help to invest in your region, please can you assist me?

Re: [PATCH] selftests/vm: Add a test for MAP_FIXED_NOREPLACE

On Sat, Oct 13, 2018 at 6:39 AM, Michael Ellerman wrote: > Add a test for MAP_FIXED_NOREPLACE, based on some code originally by > Jann Horn. This would have caught the overlap bug reported by Daniel Micay. > > I originally suggested to Michal that we create MAP_FIXED_NOREPLACE, but > instead of

Re: [PATCH] selftests/vm: Add a test for MAP_FIXED_NOREPLACE

On Sat, Oct 13, 2018 at 6:39 AM, Michael Ellerman wrote: > Add a test for MAP_FIXED_NOREPLACE, based on some code originally by > Jann Horn. This would have caught the overlap bug reported by Daniel Micay. > > I originally suggested to Michal that we create MAP_FIXED_NOREPLACE, but > instead of

Kannst du mir helfen?

Lieber geliebter, Bitte lesen Sie dies langsam und sorgfältig, da es eine der wichtigsten E-Mails sein kann, die Sie jemals bekommen.Ich bin Frau Michelle Richard, ich war mit dem verstorbenen Robert Richard verheiratet.Er arbeitete früher mit Shell Petroleum Development Company London und war

Kannst du mir helfen?

Lieber geliebter, Bitte lesen Sie dies langsam und sorgfältig, da es eine der wichtigsten E-Mails sein kann, die Sie jemals bekommen.Ich bin Frau Michelle Richard, ich war mit dem verstorbenen Robert Richard verheiratet.Er arbeitete früher mit Shell Petroleum Development Company London und war

Re: WARNING in cgroup_apply_control_enable

syzbot has found a reproducer for the following crash on: HEAD commit:1ae80cf31938 bpf: wait for running BPF programs when updat.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=12b8273540 kernel config:

Re: WARNING in cgroup_apply_control_enable

syzbot has found a reproducer for the following crash on: HEAD commit:1ae80cf31938 bpf: wait for running BPF programs when updat.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=12b8273540 kernel config:

Re: [PATCH v8 3/5] Cleanup ISA string setting

Hi, On Tue, Oct 09, 2018 at 10:18:32AM +0800, Alan Kao wrote: > This patch cleanup the MARCH string passing to both compiler and > assembler. Note that the CFLAGS should not contain "fd" before we > have mechnisms like kernel_fpu_begin/end in other architectures. > > Signed-off-by: Alan Kao >

Re: [PATCH v8 3/5] Cleanup ISA string setting

Hi, On Tue, Oct 09, 2018 at 10:18:32AM +0800, Alan Kao wrote: > This patch cleanup the MARCH string passing to both compiler and > assembler. Note that the CFLAGS should not contain "fd" before we > have mechnisms like kernel_fpu_begin/end in other architectures. > > Signed-off-by: Alan Kao >

Re: [rcu:dev.2018.10.03a 44/73] kernel/rcu/tree.c:2704:5: warning: 'max_cpu' may be used uninitialized in this function

On Mon, Oct 08, 2018 at 07:25:58PM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > dev.2018.10.03a > head: ef44a26c8418f97e5d7b3f8e4f8c0decd248 > commit: 813f47a94e3b61439bba90340b532f3a6319d4f5 [44/73] rcu: Print per-CPU >

Re: [rcu:dev.2018.10.03a 44/73] kernel/rcu/tree.c:2704:5: warning: 'max_cpu' may be used uninitialized in this function

On Mon, Oct 08, 2018 at 07:25:58PM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > dev.2018.10.03a > head: ef44a26c8418f97e5d7b3f8e4f8c0decd248 > commit: 813f47a94e3b61439bba90340b532f3a6319d4f5 [44/73] rcu: Print per-CPU >

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

On Sat, Oct 13, 2018 at 2:45 AM Alan Jenkins wrote: > > On 13/10/2018 07:11, Al Viro wrote: > > On Fri, Oct 12, 2018 at 03:49:50PM +0100, Alan Jenkins wrote: > >>> +SYSCALL_DEFINE3(fspick, int, dfd, const char __user *, path, unsigned > >>> int, flags) > >>> +{ > >>> + struct fs_context *fc; >

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

On Sat, Oct 13, 2018 at 2:45 AM Alan Jenkins wrote: > > On 13/10/2018 07:11, Al Viro wrote: > > On Fri, Oct 12, 2018 at 03:49:50PM +0100, Alan Jenkins wrote: > >>> +SYSCALL_DEFINE3(fspick, int, dfd, const char __user *, path, unsigned > >>> int, flags) > >>> +{ > >>> + struct fs_context *fc; >

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

On Sat, Oct 13, 2018 at 12:34:12AM -0700, John Hubbard wrote: > On 10/12/18 8:55 PM, Dave Chinner wrote: > > On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote: > >> From: John Hubbard > [...] > >> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > >> index

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

On Sat, Oct 13, 2018 at 12:34:12AM -0700, John Hubbard wrote: > On 10/12/18 8:55 PM, Dave Chinner wrote: > > On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote: > >> From: John Hubbard > [...] > >> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > >> index

UNITED NATIONS INTERNATIONAL CHARITY FUND

UNITED NATIONS INTERNATIONAL CHARITY FUND PAYMENT, THE DESK OF CHARITY WELFARE ORGANIZATION UNITED KINGDOM. OUR REF: UNICF27832/2018 Attention! Lucille We are the Board of Directors, Members and Committee of the United Nation International Charity Funds are saying Congratulations to you for

UNITED NATIONS INTERNATIONAL CHARITY FUND

UNITED NATIONS INTERNATIONAL CHARITY FUND PAYMENT, THE DESK OF CHARITY WELFARE ORGANIZATION UNITED KINGDOM. OUR REF: UNICF27832/2018 Attention! Lucille We are the Board of Directors, Members and Committee of the United Nation International Charity Funds are saying Congratulations to you for

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

On 10/13/18 9:47 AM, Christoph Hellwig wrote: > On Sat, Oct 13, 2018 at 12:34:12AM -0700, John Hubbard wrote: >> In patch 6/6, pin_page_for_dma(), which is called at the end of >> get_user_pages(), >> unceremoniously rips the pages out of the LRU, as a prerequisite to using >> either of the

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

On 10/13/18 9:47 AM, Christoph Hellwig wrote: > On Sat, Oct 13, 2018 at 12:34:12AM -0700, John Hubbard wrote: >> In patch 6/6, pin_page_for_dma(), which is called at the end of >> get_user_pages(), >> unceremoniously rips the pages out of the LRU, as a prerequisite to using >> either of the

mfd: syscon: syscon_node_to_regmap() and device_node refcounting

Hello, Could you please clarify why it is safe to store device_node pointer in of_syscon_register()? Who is responsible to make sure that it is not disappear? static struct syscon *of_syscon_register(struct device_node *np) { ... syscon->np = np; } -- Thank you, Alexey Khoroshilov

mfd: syscon: syscon_node_to_regmap() and device_node refcounting

Hello, Could you please clarify why it is safe to store device_node pointer in of_syscon_register()? Who is responsible to make sure that it is not disappear? static struct syscon *of_syscon_register(struct device_node *np) { ... syscon->np = np; } -- Thank you, Alexey Khoroshilov

Re: [PATCH] clocksource/timer-vt8500: remove duplicate function name

On 13/10/2018 12:22, Dan Carpenter wrote: > We print the function name twice in a row in the error message so I've > removed one. > > Signed-off-by: Dan Carpenter > Applied, thanks. -- Daniel -- Linaro.org │ Open source software for ARM SoCs Follow Linaro:

Re: [PATCH] clocksource/timer-vt8500: remove duplicate function name

On 13/10/2018 12:22, Dan Carpenter wrote: > We print the function name twice in a row in the error message so I've > removed one. > > Signed-off-by: Dan Carpenter > Applied, thanks. -- Daniel -- Linaro.org │ Open source software for ARM SoCs Follow Linaro:

[PATCH] watchdog: ts4800: release syscon device node in ts4800_wdt_probe()

Put syscon device node when it is not needed anymore. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/watchdog/ts4800_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/ts4800_wdt.c

[PATCH] watchdog: ts4800: release syscon device node in ts4800_wdt_probe()

Put syscon device node when it is not needed anymore. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/watchdog/ts4800_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/ts4800_wdt.c

Re: [PATCH V12 0/8] C-SKY(csky) Linux Kernel Driver

On 12/10/2018 14:02, Guo Ren wrote: > This is about 12th patchset for C-SKY linux drivers and it should pair > with 8th kernel patchset. Guo, I'm willing to take your timer related patches but you have to put a proper description. -- Daniel > Changelog: > - Remove the set_irq_createmapping

Re: [PATCH V12 0/8] C-SKY(csky) Linux Kernel Driver

On 12/10/2018 14:02, Guo Ren wrote: > This is about 12th patchset for C-SKY linux drivers and it should pair > with 8th kernel patchset. Guo, I'm willing to take your timer related patches but you have to put a proper description. -- Daniel > Changelog: > - Remove the set_irq_createmapping

Re: [PATCH] thermal: qoriq: add multiple sensors support

Hi Yuantian, On 27/09/2018 04:42, andy.t...@nxp.com wrote: > From: Yuantian Tang > > There is only one sensor supported in current driver. > Multiple sensors are existing on Layscape socs. To support them, > covert this driver to support multiple sensors. s/covert/convert/ What about the

Re: [PATCH] thermal: qoriq: add multiple sensors support

Hi Yuantian, On 27/09/2018 04:42, andy.t...@nxp.com wrote: > From: Yuantian Tang > > There is only one sensor supported in current driver. > Multiple sensors are existing on Layscape socs. To support them, > covert this driver to support multiple sensors. s/covert/convert/ What about the

systemtap 4.0 release

The SystemTap team announces release 4.0! prometheus exporter network service; ebpf support extensions including strings and implementation of traditional log(), sprintf() functions; rebuilt rich tapset coverage for 4.17+ syscalls and for tracepoint-based syscalls; script language tweaks for

systemtap 4.0 release

The SystemTap team announces release 4.0! prometheus exporter network service; ebpf support extensions including strings and implementation of traditional log(), sprintf() functions; rebuilt rich tapset coverage for 4.17+ syscalls and for tracepoint-based syscalls; script language tweaks for

Re: [RFC v2 2/7] dt-binding: interrupt-controller: Document RTL8186 SoC DT bindings

On Fri, 2018-10-12 at 15:13 -0500, Rob Herring wrote: > On Mon, Oct 01, 2018 at 01:29:47PM +0300, Yasha Cherikovsky wrote: > > This patch adds device tree binding doc for the > > Realtek RTL8186 SoC interrupt controller. > > > > Signed-off-by: Yasha Cherikovsky > > Cc: Rob Herring > > Cc: Mark

Re: [RFC v2 2/7] dt-binding: interrupt-controller: Document RTL8186 SoC DT bindings

On Fri, 2018-10-12 at 15:13 -0500, Rob Herring wrote: > On Mon, Oct 01, 2018 at 01:29:47PM +0300, Yasha Cherikovsky wrote: > > This patch adds device tree binding doc for the > > Realtek RTL8186 SoC interrupt controller. > > > > Signed-off-by: Yasha Cherikovsky > > Cc: Rob Herring > > Cc: Mark

[PATCH for 4.19] tracepoint: Fix: tracepoint array element size mismatch

commit 46e0c9be206f ("kernel: tracepoints: add support for relative references") changes the layout of the __tracepoint_ptrs section on architectures supporting relative references. However, it does so without turning struct tracepoint * const into const int elsewhere in the tracepoint code, which

[PATCH for 4.19] tracepoint: Fix: tracepoint array element size mismatch

commit 46e0c9be206f ("kernel: tracepoints: add support for relative references") changes the layout of the __tracepoint_ptrs section on architectures supporting relative references. However, it does so without turning struct tracepoint * const into const int elsewhere in the tracepoint code, which

Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration

- On Oct 13, 2018, at 2:34 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Oct 13, 2018, at 11:24 AM, Ard Biesheuvel ard.biesheu...@linaro.org > wrote: > >> On 12 October 2018 at 23:07, Ard Biesheuvel >> wrote: >>> Hi Mathieu, >>> >>> On 12 October 2018 at 22:05,

Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration

- On Oct 13, 2018, at 2:34 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Oct 13, 2018, at 11:24 AM, Ard Biesheuvel ard.biesheu...@linaro.org > wrote: > >> On 12 October 2018 at 23:07, Ard Biesheuvel >> wrote: >>> Hi Mathieu, >>> >>> On 12 October 2018 at 22:05,

Re: [PATCH v3 2/9] dt-bindings: ti-lmu: Remove LM3697

On 10/12/2018 08:03 PM, Pavel Machek wrote: > Hi! > >> Signed-off-by: Dan Murphy > > NAK. Thanks for the NAK. This NAK was NAK'd by other maintainer in the V2 RFC patchset https://lore.kernel.org/patchwork/patch/993171/ >>> >>> I confirm. LM3697 is a

Re: [PATCH v3 2/9] dt-bindings: ti-lmu: Remove LM3697

On 10/12/2018 08:03 PM, Pavel Machek wrote: > Hi! > >> Signed-off-by: Dan Murphy > > NAK. Thanks for the NAK. This NAK was NAK'd by other maintainer in the V2 RFC patchset https://lore.kernel.org/patchwork/patch/993171/ >>> >>> I confirm. LM3697 is a

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

For the test system I had I was initializing 384GB of RAM per node, the average time per node dropped from 1.8s to 1.1s after this patch. In the case of the persistent memory on the system the initialization time for 3TB per node dropped from 24.8s to 23.8s on average. I saw similar results on my

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

For the test system I had I was initializing 384GB of RAM per node, the average time per node dropped from 1.8s to 1.1s after this patch. In the case of the persistent memory on the system the initialization time for 3TB per node dropped from 24.8s to 23.8s on average. I saw similar results on my

Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration

- On Oct 13, 2018, at 11:24 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: > On 12 October 2018 at 23:07, Ard Biesheuvel wrote: >> Hi Mathieu, >> >> On 12 October 2018 at 22:05, Mathieu Desnoyers >> wrote: >>> commit 46e0c9be206f ("kernel: tracepoints: add support for relative >>>

Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration

- On Oct 13, 2018, at 11:24 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: > On 12 October 2018 at 23:07, Ard Biesheuvel wrote: >> Hi Mathieu, >> >> On 12 October 2018 at 22:05, Mathieu Desnoyers >> wrote: >>> commit 46e0c9be206f ("kernel: tracepoints: add support for relative >>>

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

On Sat, Oct 13, 2018 at 2:33 AM Enke Chen wrote: > 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

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

On Sat, Oct 13, 2018 at 2:33 AM Enke Chen wrote: > 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

test_kmod: BUG on module removal

4.19-rc7, on x86_64: modprobe test_kmod; rmmod test_kmod [ 199.033143] calling test_kmod_init+0x0/0x1000 [test_kmod] @ 1704 [ 199.034636] misc test_kmod0: interface ready [ 199.035468] initcall test_kmod_init+0x0/0x1000 [test_kmod] returned 0 after 1210 usecs [ 206.597737] misc test_kmod0:

test_kmod: BUG on module removal

4.19-rc7, on x86_64: modprobe test_kmod; rmmod test_kmod [ 199.033143] calling test_kmod_init+0x0/0x1000 [test_kmod] @ 1704 [ 199.034636] misc test_kmod0: interface ready [ 199.035468] initcall test_kmod_init+0x0/0x1000 [test_kmod] returned 0 after 1210 usecs [ 206.597737] misc test_kmod0:

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

Still, lets get some real data, please provide Intel data before vs after. I could test on an ARM processor. Pavel On Sat, Oct 13, 2018 at 1:18 PM Alexander Duyck wrote: > > Well in the case of x86 the call to memset is expensive as well. In > most cases it is 16 cycles plus 1 cycle per 16

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

Still, lets get some real data, please provide Intel data before vs after. I could test on an ARM processor. Pavel On Sat, Oct 13, 2018 at 1:18 PM Alexander Duyck wrote: > > Well in the case of x86 the call to memset is expensive as well. In > most cases it is 16 cycles plus 1 cycle per 16

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

Well in the case of x86 the call to memset is expensive as well. In most cases it is 16 cycles plus 1 cycle per 16 bytes if I recall correctly. So for example in the case of skbuff which was a little over 192 bytes I know Jesper Brouer and myself were going back and forth with the idea of if we

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

Well in the case of x86 the call to memset is expensive as well. In most cases it is 16 cycles plus 1 cycle per 16 bytes if I recall correctly. So for example in the case of skbuff which was a little over 192 bytes I know Jesper Brouer and myself were going back and forth with the idea of if we

[PATCH] input: touchscreen: fix wm97xx-ts exit path

From: Randy Dunlap Loading then unloading wm97xx-ts.ko when CONFIG_AC97_BUS=m causes a WARNING: from drivers/base/driver.c: Unexpected driver unregister! WARNING: CPU: 0 PID: 1709 at ../drivers/base/driver.c:193 driver_unregister+0x30/0x40 Fix this by only calling driver_unregister() with the

[PATCH] input: touchscreen: fix wm97xx-ts exit path

From: Randy Dunlap Loading then unloading wm97xx-ts.ko when CONFIG_AC97_BUS=m causes a WARNING: from drivers/base/driver.c: Unexpected driver unregister! WARNING: CPU: 0 PID: 1709 at ../drivers/base/driver.c:193 driver_unregister+0x30/0x40 Fix this by only calling driver_unregister() with the

Re: [PATCH] mm/sparse: remove a check that compare if unsigned variable is negative

This is incorrect: next_present_section_nr() returns "int" and -1 no next section, this change would lead to infinite loop. On Sat, Oct 13, 2018 at 12:16 PM Peng Hao wrote: > > > From: Peng Hao > > In all use locations for for_each_present_section_nr, variable > section_nr is unsigned. It is

Re: [PATCH] mm/sparse: remove a check that compare if unsigned variable is negative

This is incorrect: next_present_section_nr() returns "int" and -1 no next section, this change would lead to infinite loop. On Sat, Oct 13, 2018 at 12:16 PM Peng Hao wrote: > > > From: Peng Hao > > In all use locations for for_each_present_section_nr, variable > section_nr is unsigned. It is

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

I am worried about this change. I added SPARC optimized mm_zero_struct_page() specifically to SPARC because it has a poor performance with small memset()s, since it uses STBI instructions. However, other architectures might not suffer with small memset()s, and have hardware optimized memset

Re: [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

I am worried about this change. I added SPARC optimized mm_zero_struct_page() specifically to SPARC because it has a poor performance with small memset()s, since it uses STBI instructions. However, other architectures might not suffer with small memset()s, and have hardware optimized memset

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

On Sat, Oct 13, 2018 at 12:34:12AM -0700, John Hubbard wrote: > In patch 6/6, pin_page_for_dma(), which is called at the end of > get_user_pages(), > unceremoniously rips the pages out of the LRU, as a prerequisite to using > either of the page->dma_pinned_* fields. > > The idea is that LRU is

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

On Sat, Oct 13, 2018 at 12:34:12AM -0700, John Hubbard wrote: > In patch 6/6, pin_page_for_dma(), which is called at the end of > get_user_pages(), > unceremoniously rips the pages out of the LRU, as a prerequisite to using > either of the page->dma_pinned_* fields. > > The idea is that LRU is

Re: Bug introduced in the of_get_named_gpiod_flags function.

On Sat, Oct 13, 2018 at 5:53 PM wzabo...@elektron.elka.pw.edu.pl wrote: > The question is, if there may be any other in-tree GPIO controller > driver that does not initialize those flags? So as I said, I looked over them and they all initialize their flags. > Anyway the current situation is

Re: Bug introduced in the of_get_named_gpiod_flags function.

On Sat, Oct 13, 2018 at 5:53 PM wzabo...@elektron.elka.pw.edu.pl wrote: > The question is, if there may be any other in-tree GPIO controller > driver that does not initialize those flags? So as I said, I looked over them and they all initialize their flags. > Anyway the current situation is

Re: [PATCH] ubifs: Fix WARN_ON logic in exit path

On 10/13/18 1:18 AM, Richard Weinberger wrote: > ubifs_assert() is not WARN_ON(), so we have to invert > the checks. > Randy faced this warning with UBIFS being a module, since > most users use UBIFS as builtin because UBIFS is the rootfs > nobody noticed so far. :-( > Including me. > >

Re: [PATCH] ubifs: Fix WARN_ON logic in exit path

On 10/13/18 1:18 AM, Richard Weinberger wrote: > ubifs_assert() is not WARN_ON(), so we have to invert > the checks. > Randy faced this warning with UBIFS being a module, since > most users use UBIFS as builtin because UBIFS is the rootfs > nobody noticed so far. :-( > Including me. > >

[PULL REQUEST] i2c for 4.19

Greg, I2C has one documentation bugfix for something we changed during the v4.19 cycle. Please pull. Thanks, Wolfram The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21: Linux 4.19-rc7 (2018-10-07 17:26:02 +0200) are available in the Git repository at:

[PULL REQUEST] i2c for 4.19

Greg, I2C has one documentation bugfix for something we changed during the v4.19 cycle. Please pull. Thanks, Wolfram The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21: Linux 4.19-rc7 (2018-10-07 17:26:02 +0200) are available in the Git repository at:

[PATCH] mm/sparse: remove a check that compare if unsigned variable is negative

From: Peng Hao In all use locations for for_each_present_section_nr, variable section_nr is unsigned. It is unnecessary to test if it is negative. Signed-off-by: Peng Hao --- mm/sparse.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/sparse.c b/mm/sparse.c index

[PATCH] mm/sparse: remove a check that compare if unsigned variable is negative

From: Peng Hao In all use locations for for_each_present_section_nr, variable section_nr is unsigned. It is unnecessary to test if it is negative. Signed-off-by: Peng Hao --- mm/sparse.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/sparse.c b/mm/sparse.c index

Re: [PATCH] clk: meson-gxbb: set fclk_div3 as CLK_IS_CRITICAL

Quoting Christian Hewitt (2018-10-13 12:04:46) > On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems > with reboot; e.g. a ~60 second delay between issuing reboot and the > board power cycling (and in some OS configurations reboot will fail > and require manual power cycling). >

Re: [PATCH] clk: meson-gxbb: set fclk_div3 as CLK_IS_CRITICAL

Quoting Christian Hewitt (2018-10-13 12:04:46) > On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems > with reboot; e.g. a ~60 second delay between issuing reboot and the > board power cycling (and in some OS configurations reboot will fail > and require manual power cycling). >

Re: Bug introduced in the of_get_named_gpiod_flags function.

On 10/12/18 10:54 AM, Michal Simek wrote: > Hi, > > On 11.10.2018 10:27, Linus Walleij wrote: >> Hi Wojciech, >> >> (Thanks also Randy for forwarding this!) >> >> On Wed, Oct 10, 2018 at 6:32 PM wzab wrote: >> >>> The function of_get_named_gpiod_flags in older versions of the kernel >>> (up to

Re: Bug introduced in the of_get_named_gpiod_flags function.

On 10/12/18 10:54 AM, Michal Simek wrote: > Hi, > > On 11.10.2018 10:27, Linus Walleij wrote: >> Hi Wojciech, >> >> (Thanks also Randy for forwarding this!) >> >> On Wed, Oct 10, 2018 at 6:32 PM wzab wrote: >> >>> The function of_get_named_gpiod_flags in older versions of the kernel >>> (up to

[PATCH] ASoC: wm8904: fix spelling mistake "Inveting" -> "Inverting"

From: Colin Ian King Trivial fix to spelling mistake in sound control text Signed-off-by: Colin Ian King --- sound/soc/codecs/wm8904.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c index 2a3e5fbd04e4..ef83dae6e5ae

Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period constraint [Resend in plain text...]

On Sat, 13 Oct 2018 17:00:32 +0200, Mike Brady wrote: > > Hi Takashi. My apologies — t turns out I was wrong. My measurements were > systematically wrong due to integer truncation going from 64 bit to 32 bit > representation. That relieved me ;) I thought of starting checking in the next

[PATCH] ASoC: wm8904: fix spelling mistake "Inveting" -> "Inverting"

From: Colin Ian King Trivial fix to spelling mistake in sound control text Signed-off-by: Colin Ian King --- sound/soc/codecs/wm8904.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c index 2a3e5fbd04e4..ef83dae6e5ae

Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period constraint [Resend in plain text...]

On Sat, 13 Oct 2018 17:00:32 +0200, Mike Brady wrote: > > Hi Takashi. My apologies — t turns out I was wrong. My measurements were > systematically wrong due to integer truncation going from 64 bit to 32 bit > representation. That relieved me ;) I thought of starting checking in the next

[PATCH] kvm: selftests: fix spelling mistake "Insufficent" -> "Insufficient"

From: Colin Ian King Trivial fix to spelling mistake in TEST_ASSERT message text Signed-off-by: Colin Ian King --- tools/testing/selftests/kvm/lib/kvm_util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c

[PATCH] kvm: selftests: fix spelling mistake "Insufficent" -> "Insufficient"

From: Colin Ian King Trivial fix to spelling mistake in TEST_ASSERT message text Signed-off-by: Colin Ian King --- tools/testing/selftests/kvm/lib/kvm_util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c

Re: [PATCH] power: supply: fix spelling mistake "Gauage" -> "Guage"

On 13/10/2018 16:27, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in MODULE_DESCRIPTION text > > Signed-off-by: Colin Ian King > --- > drivers/power/supply/ds2780_battery.c | 2 +- > drivers/power/supply/ds2781_battery.c | 2 +- >

Re: [PATCH] power: supply: fix spelling mistake "Gauage" -> "Guage"

On 13/10/2018 16:27, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in MODULE_DESCRIPTION text > > Signed-off-by: Colin Ian King > --- > drivers/power/supply/ds2780_battery.c | 2 +- > drivers/power/supply/ds2781_battery.c | 2 +- >

[PATCH] power: supply: fix spelling mistake "Gauage" -> "Guage"

From: Colin Ian King Trivial fix to spelling mistake in MODULE_DESCRIPTION text Signed-off-by: Colin Ian King --- drivers/power/supply/ds2780_battery.c | 2 +- drivers/power/supply/ds2781_battery.c | 2 +- drivers/power/supply/ds2782_battery.c | 2 +- 3 files changed, 3 insertions(+), 3

[PATCH] power: supply: fix spelling mistake "Gauage" -> "Guage"

From: Colin Ian King Trivial fix to spelling mistake in MODULE_DESCRIPTION text Signed-off-by: Colin Ian King --- drivers/power/supply/ds2780_battery.c | 2 +- drivers/power/supply/ds2781_battery.c | 2 +- drivers/power/supply/ds2782_battery.c | 2 +- 3 files changed, 3 insertions(+), 3

Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration

On 12 October 2018 at 23:07, Ard Biesheuvel wrote: > Hi Mathieu, > > On 12 October 2018 at 22:05, Mathieu Desnoyers > wrote: >> commit 46e0c9be206f ("kernel: tracepoints: add support for relative >> references") changes the layout of the __tracepoint_ptrs section on >> architectures supporting

Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration

On 12 October 2018 at 23:07, Ard Biesheuvel wrote: > Hi Mathieu, > > On 12 October 2018 at 22:05, Mathieu Desnoyers > wrote: >> commit 46e0c9be206f ("kernel: tracepoints: add support for relative >> references") changes the layout of the __tracepoint_ptrs section on >> architectures supporting

  1   2   3   4   >