Re: [PATCH v2] cpuidle: poll_state: Add time limit to poll_idle()

On Wed, 2018-03-14 at 13:04 +0100, Peter Zijlstra wrote: > On x86 we don't have to use that time_check_counter thing, > sched_clock() > is really cheap, not sure if it makes sense on other platforms. Are you sure? I saw a 5-10% increase in CPU use, for a constant query rate to a memcache style

Re: [PATCH v2] cpuidle: poll_state: Add time limit to poll_idle()

On Wed, 2018-03-14 at 13:04 +0100, Peter Zijlstra wrote: > On x86 we don't have to use that time_check_counter thing, > sched_clock() > is really cheap, not sure if it makes sense on other platforms. Are you sure? I saw a 5-10% increase in CPU use, for a constant query rate to a memcache style

[PATCH v6] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

Code includes wmb() followed by writel() in multiple places. writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to

[PATCH v6] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

Code includes wmb() followed by writel() in multiple places. writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 22/03/2018 17:13, Matthew Wilcox wrote: > On Thu, Mar 22, 2018 at 09:06:14AM -0700, Yang Shi wrote: >> On 3/22/18 2:10 AM, Michal Hocko wrote: >>> On Wed 21-03-18 15:36:12, Yang Shi wrote: On 3/21/18 2:23 PM, Michal Hocko wrote: > On Wed 21-03-18 10:16:41, Yang Shi wrote: >>

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 22/03/2018 17:13, Matthew Wilcox wrote: > On Thu, Mar 22, 2018 at 09:06:14AM -0700, Yang Shi wrote: >> On 3/22/18 2:10 AM, Michal Hocko wrote: >>> On Wed 21-03-18 15:36:12, Yang Shi wrote: On 3/21/18 2:23 PM, Michal Hocko wrote: > On Wed 21-03-18 10:16:41, Yang Shi wrote: >>

Re: [PATCH v7 14/14] xfs, dax: introduce xfs_break_dax_layouts()

On Thu, Mar 22, 2018 at 12:43 AM, Christoph Hellwig wrote: > On Wed, Mar 21, 2018 at 03:58:31PM -0700, Dan Williams wrote: >> xfs_break_dax_layouts(), similar to xfs_break_leased_layouts(), scans >> for busy / pinned dax pages and waits for those pages to go idle before >> any

Re: [PATCH v7 14/14] xfs, dax: introduce xfs_break_dax_layouts()

On Thu, Mar 22, 2018 at 12:43 AM, Christoph Hellwig wrote: > On Wed, Mar 21, 2018 at 03:58:31PM -0700, Dan Williams wrote: >> xfs_break_dax_layouts(), similar to xfs_break_leased_layouts(), scans >> for busy / pinned dax pages and waits for those pages to go idle before >> any potential extent

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

Hi, On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann wrote: > > From: Quentin Perret > > In case an energy model is available, waking tasks are re-routed into a > new energy-aware placement algorithm. The eligible CPUs to be used in the >

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

Hi, On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann wrote: > > From: Quentin Perret > > In case an energy model is available, waking tasks are re-routed into a > new energy-aware placement algorithm. The eligible CPUs to be used in the > energy-aware wakeup path are restricted to the highest

[PATCH v5 3/3] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

Code includes wmb() followed by writel() in multiple places. writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to

[PATCH v5 3/3] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

Code includes wmb() followed by writel() in multiple places. writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to

[PATCH v5 1/3] RDMA/bnxt_re: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to writel_relaxed().

[PATCH v5 2/3] RDMA/i40iw: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Create a new wrapper function with relaxed write operator. Use the new wrapper when a write is

[PATCH v5 1/3] RDMA/bnxt_re: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to writel_relaxed().

[PATCH v5 2/3] RDMA/i40iw: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Create a new wrapper function with relaxed write operator. Use the new wrapper when a write is

Re: [PATCH v5 7/7] iommu/dma: Move PCI window region reservation back into dma specific path.

On Thu, 15 Mar 2018 16:35:09 + Shameer Kolothum wrote: > This pretty much reverts commit 273df9635385 ("iommu/dma: Make PCI > window reservation generic") by moving the PCI window region > reservation back into the dma specific path so that these

Re: [PATCH v5 7/7] iommu/dma: Move PCI window region reservation back into dma specific path.

On Thu, 15 Mar 2018 16:35:09 + Shameer Kolothum wrote: > This pretty much reverts commit 273df9635385 ("iommu/dma: Make PCI > window reservation generic") by moving the PCI window region > reservation back into the dma specific path so that these regions > doesn't get exposed via the IOMMU

Re: [PATCH 03/10] drm/sun4i: Don't pretend to handle ARGB8888 with the frontend

Hi, On Thu, 2018-03-22 at 17:12 +0100, Maxime Ripard wrote: > Hi, > > Beside the discussion with Chen-Yu, > > On Wed, Mar 21, 2018 at 04:28:57PM +0100, Paul Kocialkowski wrote: > > It turns out that the frontend is not capable of preserving the > > alpha > > component (that is always set to

Re: [PATCH 03/10] drm/sun4i: Don't pretend to handle ARGB8888 with the frontend

Hi, On Thu, 2018-03-22 at 17:12 +0100, Maxime Ripard wrote: > Hi, > > Beside the discussion with Chen-Yu, > > On Wed, Mar 21, 2018 at 04:28:57PM +0100, Paul Kocialkowski wrote: > > It turns out that the frontend is not capable of preserving the > > alpha > > component (that is always set to

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 22/03/2018 17:05, Matthew Wilcox wrote: > On Thu, Mar 22, 2018 at 04:54:52PM +0100, Laurent Dufour wrote: >> On 22/03/2018 16:40, Matthew Wilcox wrote: >>> On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: Regarding the page fault, why not relying on the PTE locking ?

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 22/03/2018 17:05, Matthew Wilcox wrote: > On Thu, Mar 22, 2018 at 04:54:52PM +0100, Laurent Dufour wrote: >> On 22/03/2018 16:40, Matthew Wilcox wrote: >>> On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: Regarding the page fault, why not relying on the PTE locking ?

Re: [PATCH v1 2/3] perf report: extend raw dump (-D) out with switch out event type

On 21.03.2018 19:41, Jiri Olsa wrote: > On Tue, Mar 20, 2018 at 04:05:17PM +0300, Alexey Budankov wrote: >> Print additional 'yield' tag for PERF_RECORD_SWITCH[_CPU_WIDE] OUT records >> when >> event header misc field contains PERF_RECORD_MISC_SWITCH_OUT_YIELD bit set >> designating

Re: [PATCH v1 2/3] perf report: extend raw dump (-D) out with switch out event type

On 21.03.2018 19:41, Jiri Olsa wrote: > On Tue, Mar 20, 2018 at 04:05:17PM +0300, Alexey Budankov wrote: >> Print additional 'yield' tag for PERF_RECORD_SWITCH[_CPU_WIDE] OUT records >> when >> event header misc field contains PERF_RECORD_MISC_SWITCH_OUT_YIELD bit set >> designating

[PATCH v2 3/3] perf script: extend misc field decoding with switch out event type

Append 'y' sign to 'S' tag designating the type of context switch out event so 'S' means preemption context switch and 'Sy' means synchronization context switch. Documentation is extended to cover new presentation changes. perf script --show-switch-events -F +misc -I -i system-wide.perf:

[PATCH v2 3/3] perf script: extend misc field decoding with switch out event type

Append 'y' sign to 'S' tag designating the type of context switch out event so 'S' means preemption context switch and 'Sy' means synchronization context switch. Documentation is extended to cover new presentation changes. perf script --show-switch-events -F +misc -I -i system-wide.perf:

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu, Mar 22, 2018 at 09:06:14AM -0700, Yang Shi wrote: > On 3/22/18 2:10 AM, Michal Hocko wrote: > > On Wed 21-03-18 15:36:12, Yang Shi wrote: > > > On 3/21/18 2:23 PM, Michal Hocko wrote: > > > > On Wed 21-03-18 10:16:41, Yang Shi wrote: > > > > > proc_pid_cmdline_read(), it calls

[PATCH v1 2/3] perf report: extend raw dump (-D) out with switch out event type

Print additional 'yield' tag for PERF_RECORD_SWITCH[_CPU_WIDE] OUT records when event header misc field contains PERF_RECORD_MISC_SWITCH_OUT_YIELD bit set designating synchronization context switch out event: perf report -D -i system-wide.perf | grep _SWITCH: 1 113807080924003 0x26db26

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu, Mar 22, 2018 at 09:06:14AM -0700, Yang Shi wrote: > On 3/22/18 2:10 AM, Michal Hocko wrote: > > On Wed 21-03-18 15:36:12, Yang Shi wrote: > > > On 3/21/18 2:23 PM, Michal Hocko wrote: > > > > On Wed 21-03-18 10:16:41, Yang Shi wrote: > > > > > proc_pid_cmdline_read(), it calls

[PATCH v1 2/3] perf report: extend raw dump (-D) out with switch out event type

Print additional 'yield' tag for PERF_RECORD_SWITCH[_CPU_WIDE] OUT records when event header misc field contains PERF_RECORD_MISC_SWITCH_OUT_YIELD bit set designating synchronization context switch out event: perf report -D -i system-wide.perf | grep _SWITCH: 1 113807080924003 0x26db26

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu 22-03-18 09:06:14, Yang Shi wrote: > > > On 3/22/18 2:10 AM, Michal Hocko wrote: > > On Wed 21-03-18 15:36:12, Yang Shi wrote: > > > > > > On 3/21/18 2:23 PM, Michal Hocko wrote: [...] > > > > pages and that is quite easy to move out of the write lock. That would > > > > be an

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu 22-03-18 09:06:14, Yang Shi wrote: > > > On 3/22/18 2:10 AM, Michal Hocko wrote: > > On Wed 21-03-18 15:36:12, Yang Shi wrote: > > > > > > On 3/21/18 2:23 PM, Michal Hocko wrote: [...] > > > > pages and that is quite easy to move out of the write lock. That would > > > > be an

Re: [PATCH v4 06/10] x86/microcode/AMD: Check patch size in verify_and_add_patch()

On Fri, Mar 16, 2018 at 12:08:17AM +0100, Maciej S. Szmigiero wrote: > @@ -505,7 +505,7 @@ static unsigned int verify_patch_size(u8 family, u32 > patch_size, > break; > } > > - if (patch_size > min_t(u32, size, max_size)) { > + if (patch_size > min_t(size_t, size,

Re: [PATCH 03/10] drm/sun4i: Don't pretend to handle ARGB8888 with the frontend

Hi, Beside the discussion with Chen-Yu, On Wed, Mar 21, 2018 at 04:28:57PM +0100, Paul Kocialkowski wrote: > It turns out that the frontend is not capable of preserving the alpha > component (that is always set to 0xff), so only support XRGB > instead. > > Signed-off-by: Paul Kocialkowski

Re: [PATCH v4 06/10] x86/microcode/AMD: Check patch size in verify_and_add_patch()

On Fri, Mar 16, 2018 at 12:08:17AM +0100, Maciej S. Szmigiero wrote: > @@ -505,7 +505,7 @@ static unsigned int verify_patch_size(u8 family, u32 > patch_size, > break; > } > > - if (patch_size > min_t(u32, size, max_size)) { > + if (patch_size > min_t(size_t, size,

Re: [PATCH 03/10] drm/sun4i: Don't pretend to handle ARGB8888 with the frontend

Hi, Beside the discussion with Chen-Yu, On Wed, Mar 21, 2018 at 04:28:57PM +0100, Paul Kocialkowski wrote: > It turns out that the frontend is not capable of preserving the alpha > component (that is always set to 0xff), so only support XRGB > instead. > > Signed-off-by: Paul Kocialkowski

[PATCH v2 1/3] perf/core: store context switch out type into Perf trace

Store thread context-switch-out event type into Perf trace as a part of PERF_RECORD_SWITCH[_CPU_WIDE] records. Introduced types of switch-out events assumed to be a) preempt: task->state == TASK_RUNNING and b) yield: !preempt; New yield event type is encoded using special

[PATCH v2 1/3] perf/core: store context switch out type into Perf trace

Store thread context-switch-out event type into Perf trace as a part of PERF_RECORD_SWITCH[_CPU_WIDE] records. Introduced types of switch-out events assumed to be a) preempt: task->state == TASK_RUNNING and b) yield: !preempt; New yield event type is encoded using special

[PATCH] mm, vmscan, tracing: Use pointer to reclaim_stat struct in trace event

The trace event trace_mm_vmscan_lru_shrink_inactive() currently has 12 parameters! Seven of them are from the reclaim_stat structure. This structure is currently local to mm/vmscan.c. By moving it to the global vmstat.h header, we can also reference it from the vmscan tracepoints. In moving it,

[PATCH] mm, vmscan, tracing: Use pointer to reclaim_stat struct in trace event

The trace event trace_mm_vmscan_lru_shrink_inactive() currently has 12 parameters! Seven of them are from the reclaim_stat structure. This structure is currently local to mm/vmscan.c. By moving it to the global vmstat.h header, we can also reference it from the vmscan tracepoints. In moving it,

[PATCH v2 0/3] perf/core: expose thread context switch out event type to user space

Implementation of exposing context-switch-out type event as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record. Introduced types of events assumed to be: a) preempt: when task->state == TASK_RUNNING b) yield: !preempt, encoding is done using new bit PERF_RECORD_MISC_SWITCH_OUT_YIELD like this:

Re: [PATCH 1/2] bpf: Remove struct bpf_verifier_env argument from print_bpf_insn

On 03/22/2018 04:57 PM, Jiri Olsa wrote: > On Thu, Mar 22, 2018 at 03:35:42PM +, Quentin Monnet wrote: >> 2018-03-22 14:32 UTC+0100 ~ Jiri Olsa >>> On Thu, Mar 22, 2018 at 10:34:18AM +0100, Daniel Borkmann wrote: On 03/21/2018 07:37 PM, Jiri Olsa wrote: > On Wed,

Re: [PATCH 1/2] bpf: Remove struct bpf_verifier_env argument from print_bpf_insn

On 03/22/2018 04:57 PM, Jiri Olsa wrote: > On Thu, Mar 22, 2018 at 03:35:42PM +, Quentin Monnet wrote: >> 2018-03-22 14:32 UTC+0100 ~ Jiri Olsa >>> On Thu, Mar 22, 2018 at 10:34:18AM +0100, Daniel Borkmann wrote: On 03/21/2018 07:37 PM, Jiri Olsa wrote: > On Wed, Mar 21, 2018 at

[PATCH v2 0/3] perf/core: expose thread context switch out event type to user space

Implementation of exposing context-switch-out type event as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record. Introduced types of events assumed to be: a) preempt: when task->state == TASK_RUNNING b) yield: !preempt, encoding is done using new bit PERF_RECORD_MISC_SWITCH_OUT_YIELD like this:

Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer

On Thu, Mar 22, 2018 at 3:45 PM, Bae, Chang Seok wrote: > On 3/21/18, 18:41, "Andy Lutomirski" wrote: >> mov to gs changes GSBASE even if GS was unchanged. > In GDB, ptrace (syscall) doesn't happen when FS/GS unchanged as > its (context) cache seems to

Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer

On Thu, Mar 22, 2018 at 3:45 PM, Bae, Chang Seok wrote: > On 3/21/18, 18:41, "Andy Lutomirski" wrote: >> mov to gs changes GSBASE even if GS was unchanged. > In GDB, ptrace (syscall) doesn't happen when FS/GS unchanged as > its (context) cache seems to be first checked. This does not allow to >

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 3/22/18 2:10 AM, Michal Hocko wrote: On Wed 21-03-18 15:36:12, Yang Shi wrote: On 3/21/18 2:23 PM, Michal Hocko wrote: On Wed 21-03-18 10:16:41, Yang Shi wrote: On 3/21/18 9:50 AM, Yang Shi wrote: On 3/21/18 6:14 AM, Michal Hocko wrote: On Wed 21-03-18 05:31:19, Yang Shi wrote: When

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 3/22/18 2:10 AM, Michal Hocko wrote: On Wed 21-03-18 15:36:12, Yang Shi wrote: On 3/21/18 2:23 PM, Michal Hocko wrote: On Wed 21-03-18 10:16:41, Yang Shi wrote: On 3/21/18 9:50 AM, Yang Shi wrote: On 3/21/18 6:14 AM, Michal Hocko wrote: On Wed 21-03-18 05:31:19, Yang Shi wrote: When

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu, Mar 22, 2018 at 04:54:52PM +0100, Laurent Dufour wrote: > On 22/03/2018 16:40, Matthew Wilcox wrote: > > On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: > >> Regarding the page fault, why not relying on the PTE locking ? > >> > >> When munmap() will unset the PTE it will

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu, Mar 22, 2018 at 04:54:52PM +0100, Laurent Dufour wrote: > On 22/03/2018 16:40, Matthew Wilcox wrote: > > On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: > >> Regarding the page fault, why not relying on the PTE locking ? > >> > >> When munmap() will unset the PTE it will

Re: [RFC, PATCH 08/22] mm: Introduce __GFP_ENCRYPT

"Kirill A. Shutemov" writes: > The patch adds new gfp flag to indicate that we're allocating encrypted > page. > > Architectural code may need to do special preparation for encrypted > pages such as flushing cache to avoid aliasing. > > Signed-off-by: Kirill A.

Re: [RFC, PATCH 08/22] mm: Introduce __GFP_ENCRYPT

"Kirill A. Shutemov" writes: > The patch adds new gfp flag to indicate that we're allocating encrypted > page. > > Architectural code may need to do special preparation for encrypted > pages such as flushing cache to avoid aliasing. > > Signed-off-by: Kirill A. Shutemov > --- >

Re: linux-next: build warning after merge of the nvdimm tree

[ adding kbuild robot folks ] On Thu, Mar 22, 2018 at 12:07 AM, Stephen Rothwell wrote: > Hi Dan, > > After merging the nvdimm tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/xfs/xfs_file.c: In function 'xfs_break_layouts': >

Re: linux-next: build warning after merge of the nvdimm tree

[ adding kbuild robot folks ] On Thu, Mar 22, 2018 at 12:07 AM, Stephen Rothwell wrote: > Hi Dan, > > After merging the nvdimm tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/xfs/xfs_file.c: In function 'xfs_break_layouts': > fs/xfs/xfs_file.c:759:20:

Re: [PATCH 1/2] bpf: Remove struct bpf_verifier_env argument from print_bpf_insn

On Thu, Mar 22, 2018 at 03:35:42PM +, Quentin Monnet wrote: > 2018-03-22 14:32 UTC+0100 ~ Jiri Olsa > > On Thu, Mar 22, 2018 at 10:34:18AM +0100, Daniel Borkmann wrote: > >> On 03/21/2018 07:37 PM, Jiri Olsa wrote: > >>> On Wed, Mar 21, 2018 at 05:25:33PM +, Quentin

Re: [PATCH 1/2] bpf: Remove struct bpf_verifier_env argument from print_bpf_insn

On Thu, Mar 22, 2018 at 03:35:42PM +, Quentin Monnet wrote: > 2018-03-22 14:32 UTC+0100 ~ Jiri Olsa > > On Thu, Mar 22, 2018 at 10:34:18AM +0100, Daniel Borkmann wrote: > >> On 03/21/2018 07:37 PM, Jiri Olsa wrote: > >>> On Wed, Mar 21, 2018 at 05:25:33PM +, Quentin Monnet wrote: >

Re: [RFC, PATCH 07/22] x86/mm: Mask out KeyID bits from page table entry pfn

Hi Kirill, A flyby comment below. "Kirill A. Shutemov" writes: > MKTME claims several upper bits of the physical address in a page table > entry to encode KeyID. It effectively shrinks number of bits for > physical address. We should exclude KeyID bits from

Re: [RFC, PATCH 07/22] x86/mm: Mask out KeyID bits from page table entry pfn

Hi Kirill, A flyby comment below. "Kirill A. Shutemov" writes: > MKTME claims several upper bits of the physical address in a page table > entry to encode KeyID. It effectively shrinks number of bits for > physical address. We should exclude KeyID bits from physical addresses. > > For

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 22/03/2018 16:40, Matthew Wilcox wrote: > On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: >> On 21/03/2018 23:46, Matthew Wilcox wrote: >>> On Wed, Mar 21, 2018 at 02:45:44PM -0700, Yang Shi wrote: Marking vma as deleted sounds good. The problem for my current approach is

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On 22/03/2018 16:40, Matthew Wilcox wrote: > On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: >> On 21/03/2018 23:46, Matthew Wilcox wrote: >>> On Wed, Mar 21, 2018 at 02:45:44PM -0700, Yang Shi wrote: Marking vma as deleted sounds good. The problem for my current approach is

[PATCH v6 1/6] typec: tcpm: Add core support for sink side PPS

This commit adds code to handle requesting of PPS APDOs. Switching between standard PDOs and APDOs, and re-requesting an APDO to modify operating voltage/current will be triggered by an external call into TCPM. Signed-off-by: Adam Thomson Acked-by: Heikki

[PATCH v6 2/6] Documentation: power: Initial effort to document power_supply ABI

This commit adds generic ABI information regarding power_supply properties. This is an initial attempt to try and align the usage of these properties between drivers. As part of this commit, common Battery and USB related properties have been listed. Signed-off-by: Adam Thomson

[PATCH v6 1/6] typec: tcpm: Add core support for sink side PPS

This commit adds code to handle requesting of PPS APDOs. Switching between standard PDOs and APDOs, and re-requesting an APDO to modify operating voltage/current will be triggered by an external call into TCPM. Signed-off-by: Adam Thomson Acked-by: Heikki Krogerus --- drivers/usb/typec/tcpm.c

[PATCH v6 2/6] Documentation: power: Initial effort to document power_supply ABI

This commit adds generic ABI information regarding power_supply properties. This is an initial attempt to try and align the usage of these properties between drivers. As part of this commit, common Battery and USB related properties have been listed. Signed-off-by: Adam Thomson ---

[PATCH v6 3/6] power: supply: Add error checking of psy desc during registration

Currently there's no error checking of this parameter in the registration function and it's blindly added to psy class and subsequently used as is. For example if this is NULL the call to psy_register_thermal() will try to dereference the pointer thus causing a kernel dump. This commit updates

[PATCH v6 3/6] power: supply: Add error checking of psy desc during registration

Currently there's no error checking of this parameter in the registration function and it's blindly added to psy class and subsequently used as is. For example if this is NULL the call to psy_register_thermal() will try to dereference the pointer thus causing a kernel dump. This commit updates

[PATCH v6 5/6] typec: tcpm: Represent source supply through power_supply

This commit adds a power_supply class instance to represent a PD source's voltage and current properties. This provides an interface for reading these properties from user-space or other drivers. For PPS enabled Sources, this also provides write access to set the current and voltage and allows

[PATCH v6 5/6] typec: tcpm: Represent source supply through power_supply

This commit adds a power_supply class instance to represent a PD source's voltage and current properties. This provides an interface for reading these properties from user-space or other drivers. For PPS enabled Sources, this also provides write access to set the current and voltage and allows

[PATCH v6 0/6] typec: tcpm: Add sink side support for PPS

This patch set adds sink side support for the PPS feature introduced in the USB PD 3.0 specification. The source PPS supply is represented using the Power Supply framework to provide access and control APIs for dealing with it's operating voltage and current, and switching between a standard PDO

[PATCH v6 0/6] typec: tcpm: Add sink side support for PPS

This patch set adds sink side support for the PPS feature introduced in the USB PD 3.0 specification. The source PPS supply is represented using the Power Supply framework to provide access and control APIs for dealing with it's operating voltage and current, and switching between a standard PDO

[PATCH v6 6/6] typec: tcpm: Add support for sink PPS related messages

This commit adds sink side support for Get_Status, Status, Get_PPS_Status and PPS_Status handling. As there's the potential for a partner to respond with Not_Supported, handling of this message is also added. Sending of Not_Supported is added to handle messagescreceived but not yet handled.

[PATCH v6 4/6] power: supply: Add 'usb_type' property and supporting code

This commit adds the 'usb_type' property to represent USB supplies which can report a number of different types based on a connection event. Examples of this already exist in drivers whereby the existing 'type' property is updated, based on an event, to represent what was connected (e.g. USB,

[PATCH v6 6/6] typec: tcpm: Add support for sink PPS related messages

This commit adds sink side support for Get_Status, Status, Get_PPS_Status and PPS_Status handling. As there's the potential for a partner to respond with Not_Supported, handling of this message is also added. Sending of Not_Supported is added to handle messagescreceived but not yet handled.

[PATCH v6 4/6] power: supply: Add 'usb_type' property and supporting code

This commit adds the 'usb_type' property to represent USB supplies which can report a number of different types based on a connection event. Examples of this already exist in drivers whereby the existing 'type' property is updated, based on an event, to represent what was connected (e.g. USB,

Re: [PATCH v3] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

On 22/03/18 01:58, Shanker Donthineni wrote: > The definition of the GICR_CTLR.RWP control bit was expanded to indicate > status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress > or completed. Software must observe GICR_CTLR.RWP==0 after clearing > GICR_CTLR.EnableLPI from 1 to 0

Re: [PATCH v3] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

On 22/03/18 01:58, Shanker Donthineni wrote: > The definition of the GICR_CTLR.RWP control bit was expanded to indicate > status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress > or completed. Software must observe GICR_CTLR.RWP==0 after clearing > GICR_CTLR.EnableLPI from 1 to 0

Re: [PATCH v7 13/14] xfs: prepare xfs_break_layouts() for another layout type

On Thu, Mar 22, 2018 at 12:27 AM, Christoph Hellwig wrote: >> + ASSERT(xfs_isilocked(ip, XFS_IOLOCK_SHARED | XFS_IOLOCK_EXCL >> + | (reason == BREAK_UNMAPI >> + ? XFS_MMAPLOCK_EXCL : 0))); > > please split the

Re: [PATCH v7 13/14] xfs: prepare xfs_break_layouts() for another layout type

On Thu, Mar 22, 2018 at 12:27 AM, Christoph Hellwig wrote: >> + ASSERT(xfs_isilocked(ip, XFS_IOLOCK_SHARED | XFS_IOLOCK_EXCL >> + | (reason == BREAK_UNMAPI >> + ? XFS_MMAPLOCK_EXCL : 0))); > > please split the assert, e.g.: > >

Re: [PATCH] x86/speculation: Fill the RSB on context switch also on non-IBPB CPUs

On 03/21/2018 05:09 PM, Maciej S. Szmigiero wrote: > As far as I understand the issue this should provide a good protection > for userspace processes that were recompiled with retpolines as they > won't have any indirect jumps and calls. Instead of saying "good protection", let's just say that it

Re: [PATCH] x86/speculation: Fill the RSB on context switch also on non-IBPB CPUs

On 03/21/2018 05:09 PM, Maciej S. Szmigiero wrote: > As far as I understand the issue this should provide a good protection > for userspace processes that were recompiled with retpolines as they > won't have any indirect jumps and calls. Instead of saying "good protection", let's just say that it

Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer

On 3/21/18, 18:41, "Andy Lutomirski" wrote: > mov to gs changes GSBASE even if GS was unchanged. In GDB, ptrace (syscall) doesn't happen when FS/GS unchanged as its (context) cache seems to be first checked. This does not allow to preserve GSBASE as you know. > But it's not

Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer

On 3/21/18, 18:41, "Andy Lutomirski" wrote: > mov to gs changes GSBASE even if GS was unchanged. In GDB, ptrace (syscall) doesn't happen when FS/GS unchanged as its (context) cache seems to be first checked. This does not allow to preserve GSBASE as you know. > But it's not clear to me that

Re: [PATCH][next] drm/amdgpu: fix spelling mistake: "asssert" -> "assert"

Am 22.03.2018 um 16:41 schrieb Colin King: From: Colin Ian King Trivial fix to spelling mistake in pr_err error message text Signed-off-by: Colin Ian King Acked-by: Christian König ---

Re: [PATCH][next] drm/amdgpu: fix spelling mistake: "asssert" -> "assert"

Am 22.03.2018 um 16:41 schrieb Colin King: From: Colin Ian King Trivial fix to spelling mistake in pr_err error message text Signed-off-by: Colin Ian King Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH v10 06/10] livepatch: Add atomic replace

On Tue 2018-03-20 16:26:19, Josh Poimboeuf wrote: > On Tue, Mar 20, 2018 at 03:35:01PM +0100, Petr Mladek wrote: > > On Tue 2018-03-13 17:48:04, Josh Poimboeuf wrote: > > > On Wed, Mar 07, 2018 at 09:20:35AM +0100, Petr Mladek wrote: > > > > This patch adds a new "replace" flag to struct

[PATCH v5 2/2] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel() in multiple places. writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to

Re: [PATCH v10 06/10] livepatch: Add atomic replace

On Tue 2018-03-20 16:26:19, Josh Poimboeuf wrote: > On Tue, Mar 20, 2018 at 03:35:01PM +0100, Petr Mladek wrote: > > On Tue 2018-03-13 17:48:04, Josh Poimboeuf wrote: > > > On Wed, Mar 07, 2018 at 09:20:35AM +0100, Petr Mladek wrote: > > > > This patch adds a new "replace" flag to struct

[PATCH v5 2/2] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel() in multiple places. writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to

[PATCH v5 1/2] ixgbevf: keep writel() closer to wmb()

Remove ixgbevf_write_tail() in favor of moving writel() close to wmb(). Signed-off-by: Sinan Kaya --- drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 5 - drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 +++--- 2 files changed, 3 insertions(+), 8 deletions(-)

[PATCH v5 1/2] ixgbevf: keep writel() closer to wmb()

Remove ixgbevf_write_tail() in favor of moving writel() close to wmb(). Signed-off-by: Sinan Kaya --- drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 5 - drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 +++--- 2 files changed, 3 insertions(+), 8 deletions(-) diff --git

RE: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018.03.21 23:25 Doug Smythies wrote: > On 2018.03.21 15:15 Rafael J. Wysocki wrote: >> On Wed, Mar 21, 2018 at 6:59 PM, Thomas Ilsche wrote: >>> On 2018-03-21 15:36, Rafael J. Wysocki wrote: So please disregard this one entirely and take the v7.2 replacement instead of

RE: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018.03.21 23:25 Doug Smythies wrote: > On 2018.03.21 15:15 Rafael J. Wysocki wrote: >> On Wed, Mar 21, 2018 at 6:59 PM, Thomas Ilsche wrote: >>> On 2018-03-21 15:36, Rafael J. Wysocki wrote: So please disregard this one entirely and take the v7.2 replacement instead of

[PATCH][next] drm/amdgpu: fix spelling mistake: "asssert" -> "assert"

From: Colin Ian King Trivial fix to spelling mistake in pr_err error message text Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH][next] drm/amdgpu: fix spelling mistake: "asssert" -> "assert"

From: Colin Ian King Trivial fix to spelling mistake in pr_err error message text Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: > On 21/03/2018 23:46, Matthew Wilcox wrote: > > On Wed, Mar 21, 2018 at 02:45:44PM -0700, Yang Shi wrote: > >> Marking vma as deleted sounds good. The problem for my current approach is > >> the concurrent page fault may succeed if

Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section

On Thu, Mar 22, 2018 at 04:32:00PM +0100, Laurent Dufour wrote: > On 21/03/2018 23:46, Matthew Wilcox wrote: > > On Wed, Mar 21, 2018 at 02:45:44PM -0700, Yang Shi wrote: > >> Marking vma as deleted sounds good. The problem for my current approach is > >> the concurrent page fault may succeed if

Re: [PATCH 1/2] bpf: Remove struct bpf_verifier_env argument from print_bpf_insn

2018-03-22 14:32 UTC+0100 ~ Jiri Olsa > On Thu, Mar 22, 2018 at 10:34:18AM +0100, Daniel Borkmann wrote: >> On 03/21/2018 07:37 PM, Jiri Olsa wrote: >>> On Wed, Mar 21, 2018 at 05:25:33PM +, Quentin Monnet wrote: 2018-03-21 16:02 UTC+0100 ~ Jiri Olsa

Re: [PATCH 1/2] bpf: Remove struct bpf_verifier_env argument from print_bpf_insn

2018-03-22 14:32 UTC+0100 ~ Jiri Olsa > On Thu, Mar 22, 2018 at 10:34:18AM +0100, Daniel Borkmann wrote: >> On 03/21/2018 07:37 PM, Jiri Olsa wrote: >>> On Wed, Mar 21, 2018 at 05:25:33PM +, Quentin Monnet wrote: 2018-03-21 16:02 UTC+0100 ~ Jiri Olsa > We use print_bpf_insn in user

Re: [PATCH v3 2/2] irqchip: Add a driver for the Microsemi Ocelot controller

On 22/03/18 15:15, Alexandre Belloni wrote: > The Microsemi Ocelot SoC has a pretty simple IRQ controller in its ICPU > block. Add a driver for it. > > Signed-off-by: Alexandre Belloni > --- > Changes in v3: > - moved parent irq parsing to the top of init > -

Re: [PATCH v3 2/2] irqchip: Add a driver for the Microsemi Ocelot controller

On 22/03/18 15:15, Alexandre Belloni wrote: > The Microsemi Ocelot SoC has a pretty simple IRQ controller in its ICPU > block. Add a driver for it. > > Signed-off-by: Alexandre Belloni > --- > Changes in v3: > - moved parent irq parsing to the top of init > - reworked error path > > >

<    4   5   6   7   8   9   10   11   12   13   >