Re: [PATCH] rtc: ds1302: remove redundant initializations of pointer bp

On 23/01/2018 at 10:17:27 +, Colin King wrote: > From: Colin Ian King > > Pointe bp is being initialized and this value is never read, it > is being updated to the same value later just before it is going to > be used. Remove the initialization as it is never read

Re: [PATCH] rtc: ds1302: remove redundant initializations of pointer bp

On 23/01/2018 at 10:17:27 +, Colin King wrote: > From: Colin Ian King > > Pointe bp is being initialized and this value is never read, it > is being updated to the same value later just before it is going to > be used. Remove the initialization as it is never read and keep > the setting of

Re: [tip:perf/core] perf/headers: Sync new perf_event.h with the tools/include/uapi version

* Alexei Starovoitov wrote: > On Tue, Feb 06, 2018 at 03:52:59AM -0800, tip-bot for Song Liu wrote: > > Commit-ID: 0d8dd67be013727ae57645ecd3ea2c36365d7da8 > > Gitweb: > > https://git.kernel.org/tip/0d8dd67be013727ae57645ecd3ea2c36365d7da8 > > Author:

Re: [tip:perf/core] perf/headers: Sync new perf_event.h with the tools/include/uapi version

* Alexei Starovoitov wrote: > On Tue, Feb 06, 2018 at 03:52:59AM -0800, tip-bot for Song Liu wrote: > > Commit-ID: 0d8dd67be013727ae57645ecd3ea2c36365d7da8 > > Gitweb: > > https://git.kernel.org/tip/0d8dd67be013727ae57645ecd3ea2c36365d7da8 > > Author: Song Liu > > AuthorDate: Wed, 6

Re: [PATCH] x86/entry/64: Fix CR3 restore order in paranoid_exit()

* Dave Hansen wrote: > On 02/13/2018 06:27 PM, Josh Poimboeuf wrote: > > --- a/arch/x86/entry/entry_64.S > > +++ b/arch/x86/entry/entry_64.S > > @@ -1167,10 +1167,10 @@ ENTRY(paranoid_exit) > > UNWIND_HINT_REGS > > DISABLE_INTERRUPTS(CLBR_ANY) > >

Re: [PATCH] x86/entry/64: Fix CR3 restore order in paranoid_exit()

* Dave Hansen wrote: > On 02/13/2018 06:27 PM, Josh Poimboeuf wrote: > > --- a/arch/x86/entry/entry_64.S > > +++ b/arch/x86/entry/entry_64.S > > @@ -1167,10 +1167,10 @@ ENTRY(paranoid_exit) > > UNWIND_HINT_REGS > > DISABLE_INTERRUPTS(CLBR_ANY) > > TRACE_IRQS_OFF_DEBUG > > +

Re: [PATCH 00/17] Add kexec_file_load support to s390

Hi Philipp, I added AKASHI in cc, he posted arm64 kexec_file series previously. I would like to read both series especially the general part, but maybe at the end of this month because of a holiday.. >From the patch log the cleanup looks nice, but still need read the details. On 02/12/18 at

Re: [PATCH 00/17] Add kexec_file_load support to s390

Hi Philipp, I added AKASHI in cc, he posted arm64 kexec_file series previously. I would like to read both series especially the general part, but maybe at the end of this month because of a holiday.. >From the patch log the cleanup looks nice, but still need read the details. On 02/12/18 at

Re: [PATCH] x86/entry/64: Fix CR3 restore order in paranoid_exit()

* Josh Poimboeuf wrote: > I haven't actually seen any real-world bugs caused by this, so I'm not > sure how theoretical it is. I just stumbled upon it in code review when > looking for another bug. I believe it's a real bug, but the fix is wrong with irq tracing or

Re: [PATCH] x86/entry/64: Fix CR3 restore order in paranoid_exit()

* Josh Poimboeuf wrote: > I haven't actually seen any real-world bugs caused by this, so I'm not > sure how theoretical it is. I just stumbled upon it in code review when > looking for another bug. I believe it's a real bug, but the fix is wrong with irq tracing or lockdep enabled as Dave

Re: [PATCH 08/12] Drivers: hv: vmbus: Implement Direct Mode for stimer0

On Wed, Feb 14, 2018 at 02:58:41AM +, Michael Kelley (EOSG) wrote: > > -Original Message- > > From: Dan Carpenter > > Sent: Monday, February 12, 2018 12:42 AM > > To: KY Srinivasan ; Stephen Hemminger > > > >

Re: [PATCH 08/12] Drivers: hv: vmbus: Implement Direct Mode for stimer0

On Wed, Feb 14, 2018 at 02:58:41AM +, Michael Kelley (EOSG) wrote: > > -Original Message- > > From: Dan Carpenter > > Sent: Monday, February 12, 2018 12:42 AM > > To: KY Srinivasan ; Stephen Hemminger > > > > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > >

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On Tue, 2018-02-13 at 22:57 -0600, Tom Lendacky wrote: > On 2/13/2018 10:21 PM, Kirill A. Shutemov wrote: > > On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: > > > On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > > > > AMD SME claims one bit from physical address to indicate > > > >

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On Tue, 2018-02-13 at 22:57 -0600, Tom Lendacky wrote: > On 2/13/2018 10:21 PM, Kirill A. Shutemov wrote: > > On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: > > > On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > > > > AMD SME claims one bit from physical address to indicate > > > >

FW: WWW-Nachricht.

Sehr geehrte Damen und Herren, nach unserem Besuch Ihrer Homepage möchten wir Ihnen ein Angebot von Produkten vorstellen, das Ihnen ermöglichen wird, den Verkauf Ihrer Produkte sowie Dienstleistungen deutlich zu erhöhen. Ich biete Ihnen den ganz neuen Adressenkatalog der Schweizer Unternehmen

FW: WWW-Nachricht.

Sehr geehrte Damen und Herren, nach unserem Besuch Ihrer Homepage möchten wir Ihnen ein Angebot von Produkten vorstellen, das Ihnen ermöglichen wird, den Verkauf Ihrer Produkte sowie Dienstleistungen deutlich zu erhöhen. Ich biete Ihnen den ganz neuen Adressenkatalog der Schweizer Unternehmen

Re: [PATCH] x86/spectre: fix an error message

On Wed, 2018-02-14 at 10:14 +0300, Dan Carpenter wrote: > If i == ARRAY_SIZE(mitigation_options) then we accidentally print > garbage from one space beyond the end of the mitigation_options[] array. > > Fixes: 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing") > Signed-off-by:

Re: [PATCH] x86/spectre: fix an error message

On Wed, 2018-02-14 at 10:14 +0300, Dan Carpenter wrote: > If i == ARRAY_SIZE(mitigation_options) then we accidentally print > garbage from one space beyond the end of the mitigation_options[] array. > > Fixes: 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing") > Signed-off-by:

[PATCH] x86/spectre: fix an error message

If i == ARRAY_SIZE(mitigation_options) then we accidentally print garbage from one space beyond the end of the mitigation_options[] array. Fixes: 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing") Signed-off-by: Dan Carpenter diff --git

[PATCH] x86/spectre: fix an error message

If i == ARRAY_SIZE(mitigation_options) then we accidentally print garbage from one space beyond the end of the mitigation_options[] array. Fixes: 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing") Signed-off-by: Dan Carpenter diff --git a/arch/x86/kernel/cpu/bugs.c

[PATCH] perf test: Fix test case inet_pton to accept inlines.

Using Fedora 27 and latest Linux kernel the test case trace+probe_libc_inet_pton.sh fails again on s390. This time is the inlining of functions which does not match. After an update of the glibc (from 2.26-16 to 2.26-24) the output is different The expected output is: __inet_pton

[PATCH] perf test: Fix test case inet_pton to accept inlines.

Using Fedora 27 and latest Linux kernel the test case trace+probe_libc_inet_pton.sh fails again on s390. This time is the inlining of functions which does not match. After an update of the glibc (from 2.26-16 to 2.26-24) the output is different The expected output is: __inet_pton

Re: [PATCH v3 1/5] ALSA: emu10k1: remove reserved_page

On Wed, 14 Feb 2018 00:04:58 +0100, Maciej S. Szmigiero wrote: > > The emu10k1-family chips need the first page (index 0) reserved in their > page tables for some reason (every emu10k1 driver I've checked does this > without much of an explanation). > Using the first page for normal samples

[RFT PATCH] drm/msm: Trigger fence completion from GPU

Interrupt commands causes the CP to trigger an interrupt as the command is processed, regardless of the GPU being done processing previous commands. This is seen by the interrupt being delivered before the fence is written on 8974 and is likely the cause of the additional CP_WAIT_FOR_IDLE

Re: [PATCH v3 1/5] ALSA: emu10k1: remove reserved_page

On Wed, 14 Feb 2018 00:04:58 +0100, Maciej S. Szmigiero wrote: > > The emu10k1-family chips need the first page (index 0) reserved in their > page tables for some reason (every emu10k1 driver I've checked does this > without much of an explanation). > Using the first page for normal samples

[RFT PATCH] drm/msm: Trigger fence completion from GPU

Interrupt commands causes the CP to trigger an interrupt as the command is processed, regardless of the GPU being done processing previous commands. This is seen by the interrupt being delivered before the fence is written on 8974 and is likely the cause of the additional CP_WAIT_FOR_IDLE

[PATCH -mm] proc: faster open/close of files without ->release hook

The whole point of code in fs/proc/inode.c is to make sure ->release hook is called either at close() or at rmmod time. All if it is unnecessary if there is no ->release hook. Save allocation+list manipulations under spinlock in that case. Signed-off-by: Alexey Dobriyan

[PATCH -mm] proc: faster open/close of files without ->release hook

The whole point of code in fs/proc/inode.c is to make sure ->release hook is called either at close() or at rmmod time. All if it is unnecessary if there is no ->release hook. Save allocation+list manipulations under spinlock in that case. Signed-off-by: Alexey Dobriyan --- fs/proc/inode.c |

[PATCH] x86/apic: Make setup_local_APIC() static

This function isn't used outside of apic.c, so let's mark it static. Signed-off-by: Dou Liyang --- arch/x86/include/asm/apic.h | 1 - arch/x86/kernel/apic/apic.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/include/asm/apic.h

[PATCH] x86/apic: Make setup_local_APIC() static

This function isn't used outside of apic.c, so let's mark it static. Signed-off-by: Dou Liyang --- arch/x86/include/asm/apic.h | 1 - arch/x86/kernel/apic/apic.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h index

[PATCH] x86/apic: Move pending intr check code into it's own function

the pending interrupt check code is mixed with the local APIC setup code, that looks messy. Extract the related code, move it into a new function named apic_pending_intr_clear(). Signed-off-by: Dou Liyang --- arch/x86/kernel/apic/apic.c | 98

[PATCH] x86/apic: Move pending intr check code into it's own function

the pending interrupt check code is mixed with the local APIC setup code, that looks messy. Extract the related code, move it into a new function named apic_pending_intr_clear(). Signed-off-by: Dou Liyang --- arch/x86/kernel/apic/apic.c | 98 - 1

HOPE TO HEAR FROM YOU

Hello dear how are you? Nice to meet you,my name is Miss Nadege Yann, can we become friends? hope to hear from you so that we can know each other very well, love matters mostly in life,i will also send you my pictures and tell you more about myself, my email address is(missnade...@gmail.com)

HOPE TO HEAR FROM YOU

Hello dear how are you? Nice to meet you,my name is Miss Nadege Yann, can we become friends? hope to hear from you so that we can know each other very well, love matters mostly in life,i will also send you my pictures and tell you more about myself, my email address is(missnade...@gmail.com)

[PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function

Not every object can be share its zspage with other objects, e.g. when the object is as big as zspage or nearly as big a zspage. For such objects zsmalloc has a so called huge class - every object which belongs to huge class consumes the entire zspage (which consists of a physical page). On

[PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function

Not every object can be share its zspage with other objects, e.g. when the object is as big as zspage or nearly as big a zspage. For such objects zsmalloc has a so called huge class - every object which belongs to huge class consumes the entire zspage (which consists of a physical page). On

Re: [PATCH v7 31/37] MAINTAINERS: Add nds32

2018-02-14 0:02 GMT+08:00 Joe Perches : > On Tue, 2018-02-13 at 17:09 +0800, Greentime Hu wrote: >> Add a maintainer information for the nds32(Andes) architecture. > [] >> diff --git a/MAINTAINERS b/MAINTAINERS > [] >> @@ -868,6 +868,17 @@ X: drivers/iio/*/adjd* >> F:

Re: [PATCH v7 31/37] MAINTAINERS: Add nds32

2018-02-14 0:02 GMT+08:00 Joe Perches : > On Tue, 2018-02-13 at 17:09 +0800, Greentime Hu wrote: >> Add a maintainer information for the nds32(Andes) architecture. > [] >> diff --git a/MAINTAINERS b/MAINTAINERS > [] >> @@ -868,6 +868,17 @@ X: drivers/iio/*/adjd* >> F:

Re: [PATCHv2 1/2] zsmalloc: introduce zs_huge_object() function

On (02/11/18 09:05), Mike Rapoport wrote: [..] > > +/** > > + * zs_huge_object() - Test if a compressed object's size is too big for > > normal > > + *zspool classes and it shall be stored in a huge > > class. > > I think "is should be stored" is more appropriate > > > + *

Re: [PATCHv2 1/2] zsmalloc: introduce zs_huge_object() function

On (02/11/18 09:05), Mike Rapoport wrote: [..] > > +/** > > + * zs_huge_object() - Test if a compressed object's size is too big for > > normal > > + *zspool classes and it shall be stored in a huge > > class. > > I think "is should be stored" is more appropriate > > > + *

[PATCH v5 5/6] x86/apic: Rename variable/function related to x86_io_apic_ops

The names of x86_io_apic_ops and its two member variables, are misleading. The .read member is to read IO_APIC reg, while .disable which hook native_disable_io_apic/irq_remapping_disable_io_apic is actually used to restore boot irq mode, not disable IO_APIC. So rename x86_io_apic_ops to

[PATCH v5 6/6] x86/apic: Set up through-local-APIC on boot CPU if 'noapic' specified

Currently kdump kernel becomes very slow if 'noapic' is specified. Normal kernel won't. Kernel parameter 'noapic' is used to disable IO-APIC in system for testing or special purpose. Here the root cause is that in kdump kernel LAPIC is disabled since commit 522e664644 ("x86/apic: Disable I/O APIC

[PATCH v5 5/6] x86/apic: Rename variable/function related to x86_io_apic_ops

The names of x86_io_apic_ops and its two member variables, are misleading. The .read member is to read IO_APIC reg, while .disable which hook native_disable_io_apic/irq_remapping_disable_io_apic is actually used to restore boot irq mode, not disable IO_APIC. So rename x86_io_apic_ops to

[PATCH v5 6/6] x86/apic: Set up through-local-APIC on boot CPU if 'noapic' specified

Currently kdump kernel becomes very slow if 'noapic' is specified. Normal kernel won't. Kernel parameter 'noapic' is used to disable IO-APIC in system for testing or special purpose. Here the root cause is that in kdump kernel LAPIC is disabled since commit 522e664644 ("x86/apic: Disable I/O APIC

[PATCH v5 3/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

This is a regression fix. Before, to fix erratum AVR31, commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC") moved lapic_shutdown() calling after disable_IO_APIC() in reboot and kexec/kdump code path. This introdued a regression. The root cause is that

[PATCH v5 0/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

This is v5 post. Newly added patch 0002 includes the change related to KEXEC_JUMP path. Patch 0003 only includes the regression fix. A regression bug was introduced in below commit. commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC") It caused the action to fail

[PATCH v5 3/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

This is a regression fix. Before, to fix erratum AVR31, commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC") moved lapic_shutdown() calling after disable_IO_APIC() in reboot and kexec/kdump code path. This introdued a regression. The root cause is that

[PATCH v5 0/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

This is v5 post. Newly added patch 0002 includes the change related to KEXEC_JUMP path. Patch 0003 only includes the regression fix. A regression bug was introduced in below commit. commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC") It caused the action to fail

[PATCH v5 4/6] x86/apic: Remove useless disable_IO_APIC

No one uses it anymore. Signed-off-by: Baoquan He --- arch/x86/include/asm/io_apic.h | 1 - arch/x86/kernel/apic/io_apic.c | 13 - arch/x86/kernel/machine_kexec_32.c | 5 ++--- arch/x86/kernel/machine_kexec_64.c | 5 ++--- 4 files changed, 4

[PATCH v5 4/6] x86/apic: Remove useless disable_IO_APIC

No one uses it anymore. Signed-off-by: Baoquan He --- arch/x86/include/asm/io_apic.h | 1 - arch/x86/kernel/apic/io_apic.c | 13 - arch/x86/kernel/machine_kexec_32.c | 5 ++--- arch/x86/kernel/machine_kexec_64.c | 5 ++--- 4 files changed, 4 insertions(+), 20 deletions(-)

[PATCH v5 2/6] x86/apic: Replace disable_IO_APIC for KEXEC_JUMP

Later disable_IO_APIC() will be broken down into clear_IO_APIC() and restore_boot_irq_mode(). These two functions will be called separately where they are needed to fix a regression introduced by commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC"). While

[PATCH v5 2/6] x86/apic: Replace disable_IO_APIC for KEXEC_JUMP

Later disable_IO_APIC() will be broken down into clear_IO_APIC() and restore_boot_irq_mode(). These two functions will be called separately where they are needed to fix a regression introduced by commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC"). While

[PATCH v5 1/6] x86/apic: Split out restore_boot_irq_mode from disable_IO_APIC

This is a preparation patch. Split out the code which restores boot irq mode from disable_IO_APIC() and wrap into a new function restore_boot_irq_mode(). No functional change. Signed-off-by: Baoquan He --- arch/x86/include/asm/io_apic.h | 1 + arch/x86/kernel/apic/io_apic.c | 5

[PATCH v5 1/6] x86/apic: Split out restore_boot_irq_mode from disable_IO_APIC

This is a preparation patch. Split out the code which restores boot irq mode from disable_IO_APIC() and wrap into a new function restore_boot_irq_mode(). No functional change. Signed-off-by: Baoquan He --- arch/x86/include/asm/io_apic.h | 1 + arch/x86/kernel/apic/io_apic.c | 5 + 2 files

Re: [2/2] powerpc/pseries: Declare optional dummy function for find_and_online_cpu_nid

On Mon, 2018-02-12 at 22:34:08 UTC, Guenter Roeck wrote: > Commit e67e02a544e9 ("powerpc/pseries: Fix cpu hotplug crash with > memoryless nodes") adds an unconditional call to find_and_online_cpu_nid(), > which is only declared if CONFIG_PPC_SPLPAR is enabled. This results in > the following build

Re: [2/2] powerpc/pseries: Declare optional dummy function for find_and_online_cpu_nid

On Mon, 2018-02-12 at 22:34:08 UTC, Guenter Roeck wrote: > Commit e67e02a544e9 ("powerpc/pseries: Fix cpu hotplug crash with > memoryless nodes") adds an unconditional call to find_and_online_cpu_nid(), > which is only declared if CONFIG_PPC_SPLPAR is enabled. This results in > the following build

Re: [1/2] powerpc/kdump: Add missing optional dummy functions

On Mon, 2018-02-12 at 22:34:07 UTC, Guenter Roeck wrote: > If KEXEC_CORE is not enabled, PowerNV builds fail as follows. > > arch/powerpc/platforms/powernv/smp.c: In function 'pnv_smp_cpu_kill_self': > arch/powerpc/platforms/powernv/smp.c:236:4: error: > implicit declaration of function

Re: [1/2] powerpc/kdump: Add missing optional dummy functions

On Mon, 2018-02-12 at 22:34:07 UTC, Guenter Roeck wrote: > If KEXEC_CORE is not enabled, PowerNV builds fail as follows. > > arch/powerpc/platforms/powernv/smp.c: In function 'pnv_smp_cpu_kill_self': > arch/powerpc/platforms/powernv/smp.c:236:4: error: > implicit declaration of function

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam wrote: > Hi Tomasz, > > On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote: >> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote: >>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam wrote: > Hi Tomasz, > > On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote: >> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote: >>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote: On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote: >

Re: [PATCH 2/4 v6] lib: debugobjects: add global free list and the counter

On 2/13/18 2:02 AM, Thomas Gleixner wrote: On Mon, 12 Feb 2018, Yang Shi wrote: On 2/12/18 8:25 AM, Thomas Gleixner wrote: On Tue, 6 Feb 2018, Yang Shi wrote: + /* +* Reuse objs from the global free list, they will be reinitialized +* when allocating +*/ +

Re: [PATCH 2/4 v6] lib: debugobjects: add global free list and the counter

On 2/13/18 2:02 AM, Thomas Gleixner wrote: On Mon, 12 Feb 2018, Yang Shi wrote: On 2/12/18 8:25 AM, Thomas Gleixner wrote: On Tue, 6 Feb 2018, Yang Shi wrote: + /* +* Reuse objs from the global free list, they will be reinitialized +* when allocating +*/ +

Re: [PATCH v7 5/9] dmtimer: Add timer ops to the platform data structure

On Tuesday 13 February 2018 08:16 AM, Suman Anna wrote: > On 01/09/2018 12:23 AM, J, KEERTHY wrote: >> Add timer ops to the platform data structure >> >> Signed-off-by: Keerthy >> Reviewed-by: Sebastian Reichel >> Tested-by: Ladislav Michl

Re: [PATCH v7 5/9] dmtimer: Add timer ops to the platform data structure

On Tuesday 13 February 2018 08:16 AM, Suman Anna wrote: > On 01/09/2018 12:23 AM, J, KEERTHY wrote: >> Add timer ops to the platform data structure >> >> Signed-off-by: Keerthy >> Reviewed-by: Sebastian Reichel >> Tested-by: Ladislav Michl >> --- >>

Re: [PATCH v7 4/9] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource

On Tuesday 13 February 2018 07:54 AM, Suman Anna wrote: > Hi Keerthy, > > On 01/09/2018 12:23 AM, J, KEERTHY wrote: >> Move the dmtimer driver out of plat-omap to clocksource. >> So that non-omap devices also could use this. > > What non-omap devices do you have in mind? I don't think this

Re: [PATCH v7 4/9] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource

On Tuesday 13 February 2018 07:54 AM, Suman Anna wrote: > Hi Keerthy, > > On 01/09/2018 12:23 AM, J, KEERTHY wrote: >> Move the dmtimer driver out of plat-omap to clocksource. >> So that non-omap devices also could use this. > > What non-omap devices do you have in mind? I don't think this

Re: [PATCH v3 1/1] mm: initialize pages on demand during boot

On (02/09/18 14:22), Pavel Tatashin wrote: [..] > +/* > + * If this zone has deferred pages, try to grow it by initializing enough > + * deferred pages to satisfy the allocation specified by order, rounded up to > + * the nearest PAGES_PER_SECTION boundary. So we're adding memory in > increments

Re: [PATCH v3 1/1] mm: initialize pages on demand during boot

On (02/09/18 14:22), Pavel Tatashin wrote: [..] > +/* > + * If this zone has deferred pages, try to grow it by initializing enough > + * deferred pages to satisfy the allocation specified by order, rounded up to > + * the nearest PAGES_PER_SECTION boundary. So we're adding memory in > increments

[PATCH] lib/scatterlist: Add SG_CHAIN and SG_EMARK macros for LSB encodings

This replaces scatterlist->page_link LSB encodings with SG_CHAIN and SG_EMARK definitions without any functional change. Signed-off-by: Anshuman Khandual --- include/linux/scatterlist.h | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-)

[PATCH] lib/scatterlist: Add SG_CHAIN and SG_EMARK macros for LSB encodings

This replaces scatterlist->page_link LSB encodings with SG_CHAIN and SG_EMARK definitions without any functional change. Signed-off-by: Anshuman Khandual --- include/linux/scatterlist.h | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On 2/13/2018 10:21 PM, Kirill A. Shutemov wrote: > On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: >> On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: >>> AMD SME claims one bit from physical address to indicate whether the >>> page is encrypted or not. To achieve that we clear out the

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On 2/13/2018 10:21 PM, Kirill A. Shutemov wrote: > On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: >> On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: >>> AMD SME claims one bit from physical address to indicate whether the >>> page is encrypted or not. To achieve that we clear out the

Re: plan9 semantics on Linux - mount namespaces

On 2018-02-14, Enrico Weigelt wrote: > On 13.02.2018 22:27, Aleksa Sarai wrote: > > > You can do this by creating a new user namespace (CLONE_NEWUSER), which > > then gives you the required permissions to create other namespaces > > (CLONE_NEWNS). This is how "rootless

Re: plan9 semantics on Linux - mount namespaces

On 2018-02-14, Enrico Weigelt wrote: > On 13.02.2018 22:27, Aleksa Sarai wrote: > > > You can do this by creating a new user namespace (CLONE_NEWUSER), which > > then gives you the required permissions to create other namespaces > > (CLONE_NEWNS). This is how "rootless containers" or

Re: [PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

On Tuesday 13 February 2018 07:36 AM, Suman Anna wrote: > Hi Keerthy, > > On 01/09/2018 12:23 AM, J, KEERTHY wrote: >> The header file is currently under plat-omap directory >> under arch/omap. Move this out to an accessible place. >> >> No Code changes done to the header file. >> >>

Re: [PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

On Tuesday 13 February 2018 07:36 AM, Suman Anna wrote: > Hi Keerthy, > > On 01/09/2018 12:23 AM, J, KEERTHY wrote: >> The header file is currently under plat-omap directory >> under arch/omap. Move this out to an accessible place. >> >> No Code changes done to the header file. >> >>

Re: [RFC PATCH 1/2] KVM: x86: Add a framework for supporting MSR-based features

On 2/13/2018 10:25 AM, Paolo Bonzini wrote: > On 08/02/2018 23:58, Tom Lendacky wrote: >> +bool kvm_valid_msr_feature(u32 msr, u64 data) >> +{ >> +unsigned int i; >> + >> +for (i = 0; i < num_msr_based_features; i++) { >> +struct kvm_msr_based_features *m = msr_based_features +

Re: [RFC PATCH 1/2] KVM: x86: Add a framework for supporting MSR-based features

On 2/13/2018 10:25 AM, Paolo Bonzini wrote: > On 08/02/2018 23:58, Tom Lendacky wrote: >> +bool kvm_valid_msr_feature(u32 msr, u64 data) >> +{ >> +unsigned int i; >> + >> +for (i = 0; i < num_msr_based_features; i++) { >> +struct kvm_msr_based_features *m = msr_based_features +

[no subject]

Good Day, I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central, Hong Kong. I have a business proposal of $ 38,980,369.00. All confirmable documents to back up the claims will be made available to you

[no subject]

Good Day, I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central, Hong Kong. I have a business proposal of $ 38,980,369.00. All confirmable documents to back up the claims will be made available to you

Re: [RFC PATCH 2/2] KVM: SVM: Add MSR feature support for serializing LFENCE

On 2/13/2018 10:22 AM, Paolo Bonzini wrote: > On 08/02/2018 23:58, Tom Lendacky wrote: >> Create an entry in the new MSR as a feature framework to allow a guest to >> recognize LFENCE as a serializing instruction on AMD processors. The MSR >> can only be set by the host, any write by the guest

Re: [RFC PATCH 2/2] KVM: SVM: Add MSR feature support for serializing LFENCE

On 2/13/2018 10:22 AM, Paolo Bonzini wrote: > On 08/02/2018 23:58, Tom Lendacky wrote: >> Create an entry in the new MSR as a feature framework to allow a guest to >> recognize LFENCE as a serializing instruction on AMD processors. The MSR >> can only be set by the host, any write by the guest

Re: [RFC PATCH 1/2] KVM: x86: Add a framework for supporting MSR-based features

On 2/13/2018 10:21 AM, Paolo Bonzini wrote: > On 08/02/2018 23:58, Tom Lendacky wrote: >> Provide a new KVM capability that allows bits within MSRs to be recognized >> as features. Two new ioctls are added to the VM ioctl routine to retrieve >> the list of these MSRs and their values. The MSR

Re: [RFC PATCH 1/2] KVM: x86: Add a framework for supporting MSR-based features

On 2/13/2018 10:21 AM, Paolo Bonzini wrote: > On 08/02/2018 23:58, Tom Lendacky wrote: >> Provide a new KVM capability that allows bits within MSRs to be recognized >> as features. Two new ioctls are added to the VM ioctl routine to retrieve >> the list of these MSRs and their values. The MSR

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: > On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > > AMD SME claims one bit from physical address to indicate whether the > > page is encrypted or not. To achieve that we clear out the bit from > > __PHYSICAL_MASK. > > I was actually

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: > On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > > AMD SME claims one bit from physical address to indicate whether the > > page is encrypted or not. To achieve that we clear out the bit from > > __PHYSICAL_MASK. > > I was actually

Re: [PATCH] x86/entry/64: Fix CR3 restore order in paranoid_exit()

On 02/13/2018 06:27 PM, Josh Poimboeuf wrote: > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -1167,10 +1167,10 @@ ENTRY(paranoid_exit) > UNWIND_HINT_REGS > DISABLE_INTERRUPTS(CLBR_ANY) > TRACE_IRQS_OFF_DEBUG > + RESTORE_CR3 scratch_reg=%r15

Re: [PATCH] x86/entry/64: Fix CR3 restore order in paranoid_exit()

On 02/13/2018 06:27 PM, Josh Poimboeuf wrote: > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -1167,10 +1167,10 @@ ENTRY(paranoid_exit) > UNWIND_HINT_REGS > DISABLE_INTERRUPTS(CLBR_ANY) > TRACE_IRQS_OFF_DEBUG > + RESTORE_CR3 scratch_reg=%r15

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

Hi Tomasz, On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote: > On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote: >> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote: >>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

Hi Tomasz, On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote: > On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote: >> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote: >>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote: On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote: > Hi

Re: [PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

On Tuesday 13 February 2018 08:39 PM, Tony Lindgren wrote: > * Suman Anna [180213 02:07]: >> On 01/09/2018 12:23 AM, J, KEERTHY wrote: >>> The header file is currently under plat-omap directory >>> under arch/omap. Move this out to an accessible place. >>> @@ -18,7 +18,7 @@ >>>

Re: [PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

On Tuesday 13 February 2018 08:39 PM, Tony Lindgren wrote: > * Suman Anna [180213 02:07]: >> On 01/09/2018 12:23 AM, J, KEERTHY wrote: >>> The header file is currently under plat-omap directory >>> under arch/omap. Move this out to an accessible place. >>> @@ -18,7 +18,7 @@ >>> #include >>>

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > AMD SME claims one bit from physical address to indicate whether the > page is encrypted or not. To achieve that we clear out the bit from > __PHYSICAL_MASK. I was actually working on a suggestion by Linus to use one of the software page table bits

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > AMD SME claims one bit from physical address to indicate whether the > page is encrypted or not. To achieve that we clear out the bit from > __PHYSICAL_MASK. I was actually working on a suggestion by Linus to use one of the software page table bits

Re: [PATCH v7 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops

On Tue, Feb 13, 2018 at 7:25 PM, Vivek Gautam wrote: >>> +static int arm_smmu_init_clks(struct arm_smmu_device *smmu) >>> +{ >>> + int i; >>> + int num = smmu->num_clks; >>> + const struct arm_smmu_match_data *data; >>> + >>> + if (num < 1) >>>

Re: [PATCH v7 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops

On Tue, Feb 13, 2018 at 7:25 PM, Vivek Gautam wrote: >>> +static int arm_smmu_init_clks(struct arm_smmu_device *smmu) >>> +{ >>> + int i; >>> + int num = smmu->num_clks; >>> + const struct arm_smmu_match_data *data; >>> + >>> + if (num < 1) >>> + return 0;

[PATCH RESEND v5 0/3] Add support for Hi3660 mailbox driver

Hi3660 mailbox controller is used to send message within multiple processors, MCU, HIFI, etc. This patch series is to implement an initial version for Hi3660 mailbox driver with "automatic acknowledge" mode. The patch set have been verified with Hi3660 stub clock driver, so we can send message to

[PATCH RESEND v5 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding

Introduce a binding for the Hi3660 mailbox controller, the mailbox is used within application processor (AP), communication processor (CP), HIFI and MCU, etc. Acked-by: Rob Herring Signed-off-by: Leo Yan --- .../bindings/mailbox/hisilicon,hi3660-mailbox.txt

[PATCH RESEND v5 0/3] Add support for Hi3660 mailbox driver

Hi3660 mailbox controller is used to send message within multiple processors, MCU, HIFI, etc. This patch series is to implement an initial version for Hi3660 mailbox driver with "automatic acknowledge" mode. The patch set have been verified with Hi3660 stub clock driver, so we can send message to

[PATCH RESEND v5 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding

Introduce a binding for the Hi3660 mailbox controller, the mailbox is used within application processor (AP), communication processor (CP), HIFI and MCU, etc. Acked-by: Rob Herring Signed-off-by: Leo Yan --- .../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 ++ 1 file

  1   2   3   4   5   6   7   8   9   10   >