Re: [RFC 0/5] drivers: Add boot constraints core

On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar wrote: > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> AFAIK regulator constraints are supposed to satisfy all users of it. > > Right. > >> >> >Let me try with an example. A regulator is shared between LCD and DMA >> >>

Re: [RFC 0/5] drivers: Add boot constraints core

On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar wrote: > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> AFAIK regulator constraints are supposed to satisfy all users of it. > > Right. > >> >> >Let me try with an example. A regulator is shared between LCD and DMA >> >> >controller. >> >> > >> >>

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 12:15 PM, Marcelo Tosatti wrote: > On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote: >> >> swait uses special locking and has odd semantics that are not at all >> the same as the default wait queue ones. It should not be used without >>

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 12:15 PM, Marcelo Tosatti wrote: > On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote: >> >> swait uses special locking and has odd semantics that are not at all >> the same as the default wait queue ones. It should not be used without >> very strong reasons

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Fri, Jun 30, 2017 at 10:51:26AM +0800, Boqun Feng wrote: > On Thu, Jun 29, 2017 at 11:11:26AM -0700, Paul E. McKenney wrote: > > On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > > > On Thu, 29 Jun 2017, Will Deacon wrote: > > > > > > > [turns out I've not been on cc for this

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Fri, Jun 30, 2017 at 10:51:26AM +0800, Boqun Feng wrote: > On Thu, Jun 29, 2017 at 11:11:26AM -0700, Paul E. McKenney wrote: > > On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > > > On Thu, 29 Jun 2017, Will Deacon wrote: > > > > > > > [turns out I've not been on cc for this

linux-next: build warning after merge of the drivers-x86 tree

Hi Darren, After merging the drivers-x86 tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/platform/x86/sony-laptop.c: In function 'sony_laptop_setup_input': drivers/platform/x86/sony-laptop.c:494:19: warning: assignment discards 'const' qualifier from pointer

linux-next: build warning after merge of the drivers-x86 tree

Hi Darren, After merging the drivers-x86 tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/platform/x86/sony-laptop.c: In function 'sony_laptop_setup_input': drivers/platform/x86/sony-laptop.c:494:19: warning: assignment discards 'const' qualifier from pointer

[PATCH v3] staging: lustre: lnet: remove dead code and crc32_le() wrapper

After removing code which was premanently disabled with ifdefs, the function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove this useless wrapper and instead call crc32_le() directly. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING:

[PATCH v3] staging: lustre: lnet: remove dead code and crc32_le() wrapper

After removing code which was premanently disabled with ifdefs, the function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove this useless wrapper and instead call crc32_le() directly. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING:

Re: [PATCH] cpufreq: Find transition latency dynamically

On 29-06-17, 22:34, Rafael J. Wysocki wrote: > Shouldn't drivers do that really? Well they can, but the we will have some sort of code duplication then. Or else we can provide a helper for them to find this value dynamically and that would be fine too. And maybe we can add a callback for the

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

On Thu, Jun 29, 2017 at 7:42 PM, Li Kun wrote: > > > on 2017/6/30 6:05, Kees Cook wrote: >> >> On Wed, Jun 28, 2017 at 9:13 PM, Li Kun wrote: >>> >>> 在 2017/5/31 5:39, Kees Cook 写道: +bool ex_handler_refcount(const struct exception_table_entry

Re: [PATCH] cpufreq: Find transition latency dynamically

On 29-06-17, 22:34, Rafael J. Wysocki wrote: > Shouldn't drivers do that really? Well they can, but the we will have some sort of code duplication then. Or else we can provide a helper for them to find this value dynamically and that would be fine too. And maybe we can add a callback for the

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

On Thu, Jun 29, 2017 at 7:42 PM, Li Kun wrote: > > > on 2017/6/30 6:05, Kees Cook wrote: >> >> On Wed, Jun 28, 2017 at 9:13 PM, Li Kun wrote: >>> >>> 在 2017/5/31 5:39, Kees Cook 写道: +bool ex_handler_refcount(const struct exception_table_entry *fixup, +

Re: [RFC 0/5] drivers: Add boot constraints core

On 30-06-17, 11:33, Chen-Yu Tsai wrote: > AFAIK regulator constraints are supposed to satisfy all users of it. Right. > >> >Let me try with an example. A regulator is shared between LCD and DMA > >> >controller. > >> > > >> >Operable ranges of the regulator: 1.8 - 3.0 V > >> >Range required by

Re: [RFC 0/5] drivers: Add boot constraints core

On 30-06-17, 11:33, Chen-Yu Tsai wrote: > AFAIK regulator constraints are supposed to satisfy all users of it. Right. > >> >Let me try with an example. A regulator is shared between LCD and DMA > >> >controller. > >> > > >> >Operable ranges of the regulator: 1.8 - 3.0 V > >> >Range required by

Re: [PATCH v2] staging: lustre: lnet: remove dead code and crc32_le() wrapper

On 06/30/2017, Joe Perches wrote: Please use checkpatch on your proposed patches before sending them. Whoops! Sorry about that. Fixed and re-sent.

Re: [PATCH v2] staging: lustre: lnet: remove dead code and crc32_le() wrapper

On 06/30/2017, Joe Perches wrote: Please use checkpatch on your proposed patches before sending them. Whoops! Sorry about that. Fixed and re-sent.

Re: [PATCH] uvesafb: use pr_cont when printing multiple parameters on the same line

On Thu, 2017-06-29 at 22:16 -0400, Mikulas Patocka wrote: > The kernel automatically inserts newlines between printk calls unless > pr_cont is used. This patch changes the uvesafb log message from: Should be fixed in -next already. commit a8feae091106 ("uvesafb: Fix continuation printks without

Re: [PATCH] uvesafb: use pr_cont when printing multiple parameters on the same line

On Thu, 2017-06-29 at 22:16 -0400, Mikulas Patocka wrote: > The kernel automatically inserts newlines between printk calls unless > pr_cont is used. This patch changes the uvesafb log message from: Should be fixed in -next already. commit a8feae091106 ("uvesafb: Fix continuation printks without

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

"Rafael J. Wysocki" writes: > On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman > wrote: >> On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: >>> local_irq_enable can cause interrupts to be taken which could >>> take significant

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

"Rafael J. Wysocki" writes: > On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman > wrote: >> On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: >>> local_irq_enable can cause interrupts to be taken which could >>> take significant amount of processing time. The idle process >>> should

[PATCH] regulator: core: Fix size limit of supply_map

Now the debugfs file supply_map has a size limit PAGE_SIZE and the user can not see the whole content of regulator_map_list when it is larger than this limit. This patch uses seq_file instead to make sure supply_map shows the full information of regulator_map_list. Signed-off-by: Haishan Zhou

[PATCH] regulator: core: Fix size limit of supply_map

Now the debugfs file supply_map has a size limit PAGE_SIZE and the user can not see the whole content of regulator_map_list when it is larger than this limit. This patch uses seq_file instead to make sure supply_map shows the full information of regulator_map_list. Signed-off-by: Haishan Zhou

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

On Fri, Jun 30, 2017 at 5:19 AM, Rob Herring wrote: > On Tue, Jun 27, 2017 at 07:07:34PM +0800, Yong Deng wrote: >> Add binding documentation for Allwinner CSI. > > For the subject: > > dt-bindings: media: Add Allwinner Camera Sensor Interface (CSI) > > "binding documentation" is

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

On Fri, Jun 30, 2017 at 5:19 AM, Rob Herring wrote: > On Tue, Jun 27, 2017 at 07:07:34PM +0800, Yong Deng wrote: >> Add binding documentation for Allwinner CSI. > > For the subject: > > dt-bindings: media: Add Allwinner Camera Sensor Interface (CSI) > > "binding documentation" is redundant. > >>

Re: 4.12.0-rc6: kernel BUG at arch/x86/mm/init_64.c:128!

On Thu, Jun 29, 2017 at 03:45:18PM -0400, YASUAKI ISHIMATSU wrote: > The I hit the following kernel panic while hot-adding memory. > > [ cut here ] > kernel BUG at arch/x86/mm/init_64.c:128! Could you check if this works:

Re: 4.12.0-rc6: kernel BUG at arch/x86/mm/init_64.c:128!

On Thu, Jun 29, 2017 at 03:45:18PM -0400, YASUAKI ISHIMATSU wrote: > The I hit the following kernel panic while hot-adding memory. > > [ cut here ] > kernel BUG at arch/x86/mm/init_64.c:128! Could you check if this works:

Re: [PATCH v2] staging: lustre: lnet: remove dead code and crc32_le() wrapper

On Fri, 2017-06-30 at 03:29 +, Dmitriy Cherkasov wrote: > After removing code which was premanently disabled with ifdefs, the > function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove > this useless wrapper and instead call crc32_le() directly. > > This also resolves the

Re: [PATCH v2] staging: lustre: lnet: remove dead code and crc32_le() wrapper

On Fri, 2017-06-30 at 03:29 +, Dmitriy Cherkasov wrote: > After removing code which was premanently disabled with ifdefs, the > function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove > this useless wrapper and instead call crc32_le() directly. > > This also resolves the

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On 29-06-17, 20:01, Dominik Brodowski wrote: > On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > > The cpufreq core and governors aren't supposed to set a limit on how > > fast we want to try changing the frequency. This is currently done for > > the legacy governors with help of

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On 29-06-17, 20:01, Dominik Brodowski wrote: > On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > > The cpufreq core and governors aren't supposed to set a limit on how > > fast we want to try changing the frequency. This is currently done for > > the legacy governors with help of

Re: [RFC 0/5] drivers: Add boot constraints core

On Fri, Jun 30, 2017 at 11:16 AM, Viresh Kumar wrote: > On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: >> On 29.06.2017 14:47, Viresh Kumar wrote: >> >> >No. Drivers are registered to the kernel (randomly, though we can know >> >their order) and devices are

Re: [RFC 0/5] drivers: Add boot constraints core

On Fri, Jun 30, 2017 at 11:16 AM, Viresh Kumar wrote: > On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: >> On 29.06.2017 14:47, Viresh Kumar wrote: >> >> >No. Drivers are registered to the kernel (randomly, though we can know >> >their order) and devices are registered separately

[PATCH v2] staging: lustre: lnet: remove dead code and crc32_le() wrapper

After removing code which was premanently disabled with ifdefs, the function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove this useless wrapper and instead call crc32_le() directly. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING:

Re: [PATCH] thp, mm: Fix crash due race in MADV_FREE handling

On Thu, Jun 29, 2017 at 01:50:51PM -0700, Andrew Morton wrote: > On Wed, 28 Jun 2017 13:15:50 +0300 "Kirill A. Shutemov" > wrote: > > > > Signed-off-by: Kirill A. Shutemov > > > Reported-by: Reinette Chatre > >

[PATCH v2] staging: lustre: lnet: remove dead code and crc32_le() wrapper

After removing code which was premanently disabled with ifdefs, the function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove this useless wrapper and instead call crc32_le() directly. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING:

Re: [PATCH] thp, mm: Fix crash due race in MADV_FREE handling

On Thu, Jun 29, 2017 at 01:50:51PM -0700, Andrew Morton wrote: > On Wed, 28 Jun 2017 13:15:50 +0300 "Kirill A. Shutemov" > wrote: > > > > Signed-off-by: Kirill A. Shutemov > > > Reported-by: Reinette Chatre > > > Fixes: 9818b8cde622 ("madvise_free, thp: fix madvise_free_huge_pmd return > > >

Re: [PATCH V2 3/4] intel_pstate: Ignore scheduler cpufreq callbacks on remote CPUs

On 29-06-17, 14:23, Srinivas Pandruvada wrote: > On Thu, 2017-06-29 at 10:56 +0530, Viresh Kumar wrote: > > From: Steve Muckle > > > > In preparation for the scheduler cpufreq callback happening on remote > > CPUs, check for this case in intel_pstate which currently

Re: [PATCH V2 3/4] intel_pstate: Ignore scheduler cpufreq callbacks on remote CPUs

On 29-06-17, 14:23, Srinivas Pandruvada wrote: > On Thu, 2017-06-29 at 10:56 +0530, Viresh Kumar wrote: > > From: Steve Muckle > > > > In preparation for the scheduler cpufreq callback happening on remote > > CPUs, check for this case in intel_pstate which currently requires > > the > > callback

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Thu, Jun 29, 2017 at 12:41:07PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. zstd at its > fastest level compresses almost as well as zlib, while offering much > faster compression and decompression, approaching lzo speeds. > +static int

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Thu, Jun 29, 2017 at 12:41:07PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. zstd at its > fastest level compresses almost as well as zlib, while offering much > faster compression and decompression, approaching lzo speeds. > +static int

Re: [PATCH V2 0/4] sched: cpufreq: Allow remote callbacks

On 29-06-17, 22:30, Rafael J. Wysocki wrote: > There is no way I could consider this for inclusion into 4.13, so I'm > not sure why you chose this specific timing. Sure, I don't aim at getting it merged for 4.13. I sent it now to get some early feedback, so that it is ready for inclusion for the

Re: [PATCH V2 0/4] sched: cpufreq: Allow remote callbacks

On 29-06-17, 22:30, Rafael J. Wysocki wrote: > There is no way I could consider this for inclusion into 4.13, so I'm > not sure why you chose this specific timing. Sure, I don't aim at getting it merged for 4.13. I sent it now to get some early feedback, so that it is ready for inclusion for the

Re: [tip:x86/platform] x86/PCI/mmcfg: Switch to ECAM config mode if possible

> Hi Thomas, > > Would this patch actually void the commit: Yes it does. My origina; patches were opt-in for this reason, but Thomas doesn't believe in historical or other people's experience. But MCFG problems were a long time ago and noone uses these systems anymore, so perhaps he is right.

Re: [tip:x86/platform] x86/PCI/mmcfg: Switch to ECAM config mode if possible

> Hi Thomas, > > Would this patch actually void the commit: Yes it does. My origina; patches were opt-in for this reason, but Thomas doesn't believe in historical or other people's experience. But MCFG problems were a long time ago and noone uses these systems anymore, so perhaps he is right.

Re: [PATCH v4 2/2] fs/dcache.c: fix spin lockup issue on nlru->lock

On 6/30/2017 4:18 AM, Andrew Morton wrote: --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1133,11 +1133,12 @@ void shrink_dcache_sb(struct super_block *sb) LIST_HEAD(dispose); freed = list_lru_walk(>s_dentry_lru, - dentry_lru_isolate_shrink, , UINT_MAX);

Re: [PATCH v4 2/2] fs/dcache.c: fix spin lockup issue on nlru->lock

On 6/30/2017 4:18 AM, Andrew Morton wrote: --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1133,11 +1133,12 @@ void shrink_dcache_sb(struct super_block *sb) LIST_HEAD(dispose); freed = list_lru_walk(>s_dentry_lru, - dentry_lru_isolate_shrink, , UINT_MAX);

Re: [PATCH v5] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

On Fri, Jun 30, 2017 at 6:22 AM, Jonathan Liu wrote: > Hi Maxime, > > On 30 June 2017 at 01:56, Maxime Ripard > wrote: >> On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote: >>> >> + u32 int_status; >>> >> + u32 fifo_status;

Re: [RFC 0/5] drivers: Add boot constraints core

On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: > On 29.06.2017 14:47, Viresh Kumar wrote: > > >No. Drivers are registered to the kernel (randomly, though we can know > >their order) and devices are registered separately (platform/amba > >devices get registered automatically with DT,

Re: [PATCH v5] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

On Fri, Jun 30, 2017 at 6:22 AM, Jonathan Liu wrote: > Hi Maxime, > > On 30 June 2017 at 01:56, Maxime Ripard > wrote: >> On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote: >>> >> + u32 int_status; >>> >> + u32 fifo_status; >>> >> + /* Read needs empty flag unset, write

Re: [RFC 0/5] drivers: Add boot constraints core

On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: > On 29.06.2017 14:47, Viresh Kumar wrote: > > >No. Drivers are registered to the kernel (randomly, though we can know > >their order) and devices are registered separately (platform/amba > >devices get registered automatically with DT,

Re: Inconsistency in scripts/checkpatch.pl

On Thu, 2017-06-29 at 20:26 -0500, Larry Finger wrote: > Andy and Joe, > > In some new rtlwifi code, I get the following for one of the new macros: > > CHECK: Macro argument '__h2c' may be better as '(__h2c)' to avoid precedence > issues > #45005: FILE: >

Re: Inconsistency in scripts/checkpatch.pl

On Thu, 2017-06-29 at 20:26 -0500, Larry Finger wrote: > Andy and Joe, > > In some new rtlwifi code, I get the following for one of the new macros: > > CHECK: Macro argument '__h2c' may be better as '(__h2c)' to avoid precedence > issues > #45005: FILE: >

Re: wake_wide mechanism clarification

On Thu, 2017-06-29 at 20:49 -0400, Josef Bacik wrote: > On Thu, Jun 29, 2017 at 05:19:14PM -0700, Joel Fernandes wrote: > > > Why are wanting the master's flip frequency to be higher than the > > slaves by the factor? > > (Responding from my personal email as my work email is outlook shit and >

Re: wake_wide mechanism clarification

On Thu, 2017-06-29 at 20:49 -0400, Josef Bacik wrote: > On Thu, Jun 29, 2017 at 05:19:14PM -0700, Joel Fernandes wrote: > > > Why are wanting the master's flip frequency to be higher than the > > slaves by the factor? > > (Responding from my personal email as my work email is outlook shit and >

Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions

On Thu, Jun 29, 2017 at 3:35 PM, Michal Hocko wrote: > From: Michal Hocko > Michal, I love the idea very much. > Historically we have enforced that any kernel zone (e.g ZONE_NORMAL) has > to precede the Movable zone in the physical memory range. The purpose

Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions

On Thu, Jun 29, 2017 at 3:35 PM, Michal Hocko wrote: > From: Michal Hocko > Michal, I love the idea very much. > Historically we have enforced that any kernel zone (e.g ZONE_NORMAL) has > to precede the Movable zone in the physical memory range. The purpose of > the movable zone is, however,

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

Hi Bjorn, On Thu, Jun 29, 2017 at 09:39:31PM -0500, Bjorn Helgaas wrote: > On Thu, Jun 29, 2017 at 02:19:26PM -0500, Bjorn Helgaas wrote: > > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote: > > > People reported that they can not do a poweroff nor a > > > suspend to ram on their Mac Pro

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

Hi Bjorn, On Thu, Jun 29, 2017 at 09:39:31PM -0500, Bjorn Helgaas wrote: > On Thu, Jun 29, 2017 at 02:19:26PM -0500, Bjorn Helgaas wrote: > > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote: > > > People reported that they can not do a poweroff nor a > > > suspend to ram on their Mac Pro

Re: wake_wide mechanism clarification

Hi Josef, Thanks a lot for your reply, :-) On Thu, Jun 29, 2017 at 5:49 PM, Josef Bacik wrote: > Because we are trying to detect the case that the master is waking many > different processes, and the 'slave' processes are only waking up the > master/some other specific

Re: wake_wide mechanism clarification

Hi Josef, Thanks a lot for your reply, :-) On Thu, Jun 29, 2017 at 5:49 PM, Josef Bacik wrote: > Because we are trying to detect the case that the master is waking many > different processes, and the 'slave' processes are only waking up the > master/some other specific processes to determine if

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni wrote: > Hi Shanker, > > On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni > wrote: >> The NUMA node information is visible to ITS driver but not being used >> other than handling errata. This

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni wrote: > Hi Shanker, > > On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni > wrote: >> The NUMA node information is visible to ITS driver but not being used >> other than handling errata. This patch allocates the memory for ITS >> tables

[PATCH v4] acpi/nfit: Issue Start ARS to retrieve existing records

ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start ARS with Flags Bit [1] set upon receiving the 0x81 notification. Upon receiving the notification, the OSPM may decide to issue a Start ARS with Flags Bit [1] set to prepare for the retrieval of existing records and issue

[PATCH v4] acpi/nfit: Issue Start ARS to retrieve existing records

ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start ARS with Flags Bit [1] set upon receiving the 0x81 notification. Upon receiving the notification, the OSPM may decide to issue a Start ARS with Flags Bit [1] set to prepare for the retrieval of existing records and issue

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

on 2017/6/30 6:05, Kees Cook wrote: On Wed, Jun 28, 2017 at 9:13 PM, Li Kun wrote: 在 2017/5/31 5:39, Kees Cook 写道: +bool ex_handler_refcount(const struct exception_table_entry *fixup, +struct pt_regs *regs, int trapnr) +{ + int reset; + +

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

on 2017/6/30 6:05, Kees Cook wrote: On Wed, Jun 28, 2017 at 9:13 PM, Li Kun wrote: 在 2017/5/31 5:39, Kees Cook 写道: +bool ex_handler_refcount(const struct exception_table_entry *fixup, +struct pt_regs *regs, int trapnr) +{ + int reset; + + /* +* If

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 11:11:26AM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > > On Thu, 29 Jun 2017, Will Deacon wrote: > > > > > [turns out I've not been on cc for this thread, but Jade pointed me to it > > > and I see my name came up at some

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 11:11:26AM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > > On Thu, 29 Jun 2017, Will Deacon wrote: > > > > > [turns out I've not been on cc for this thread, but Jade pointed me to it > > > and I see my name came up at some

Re: [patch 1/5] pinctrl: samsung: Remove bogus irq_[un]mask from resource management

Hi Thomas, 2017-06-30 6:33 GMT+09:00 Thomas Gleixner : > The irq chip callbacks irq_request/release_resources() have absolutely no > business with masking and unmasking the irq. > > The core code unmasks the interrupt after complete setup and masks it > before invoking

Re: [patch 1/5] pinctrl: samsung: Remove bogus irq_[un]mask from resource management

Hi Thomas, 2017-06-30 6:33 GMT+09:00 Thomas Gleixner : > The irq chip callbacks irq_request/release_resources() have absolutely no > business with masking and unmasking the irq. > > The core code unmasks the interrupt after complete setup and masks it > before invoking irq_release_resources(). >

[PATCH v2] kbuild: improve comments on KBUILD_SRC

Original comments is confusing on "OBJ directory", make it clear. Bonus: move comments close to what it wants to comment. Signed-off-by: Cao jin --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index

[PATCH v2] kbuild: improve comments on KBUILD_SRC

Original comments is confusing on "OBJ directory", make it clear. Bonus: move comments close to what it wants to comment. Signed-off-by: Cao jin --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 57df756..7b60fb3 100644 ---

Re: [PATCH v2 1/2] acpi: thermal: update thermal_zone after enable the driver.

On Thu, 2017-06-29 at 18:50 +0200, Enric Balletbo i Serra wrote: > Use thermal_set_mode instead of just set the tz_enable variable when > enabling the ACPI thermal driver. The purpose of this change is > trigger > a thermal_zone_device_update when driver switches from disabled to > enabled mode so

Re: [PATCH v2 1/2] acpi: thermal: update thermal_zone after enable the driver.

On Thu, 2017-06-29 at 18:50 +0200, Enric Balletbo i Serra wrote: > Use thermal_set_mode instead of just set the tz_enable variable when > enabling the ACPI thermal driver. The purpose of this change is > trigger > a thermal_zone_device_update when driver switches from disabled to > enabled mode so

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

On Thu, Jun 29, 2017 at 02:19:26PM -0500, Bjorn Helgaas wrote: > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote: > > People reported that they can not do a poweroff nor a > > suspend to ram on their Mac Pro 11. After some investigations > > it was found that, once the PCI bridge

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

On Thu, Jun 29, 2017 at 02:19:26PM -0500, Bjorn Helgaas wrote: > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote: > > People reported that they can not do a poweroff nor a > > suspend to ram on their Mac Pro 11. After some investigations > > it was found that, once the PCI bridge

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 6:46 AM, Thomas Gleixner wrote: > > On Thu, 29 Jun 2017, Greg KH wrote: > >> On Thu, Jun 29, 2017 at 03:05:26PM +0200, Thomas Gleixner wrote: > >> > > >> > And who defined that it should

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 6:46 AM, Thomas Gleixner wrote: > > On Thu, 29 Jun 2017, Greg KH wrote: > >> On Thu, Jun 29, 2017 at 03:05:26PM +0200, Thomas Gleixner wrote: > >> > > >> > And who defined that it should not be used in real

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

Hi Shanker, On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni wrote: > The NUMA node information is visible to ITS driver but not being used > other than handling errata. This patch allocates the memory for ITS > tables from the corresponding NUMA node using the

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

Hi Shanker, On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni wrote: > The NUMA node information is visible to ITS driver but not being used > other than handling errata. This patch allocates the memory for ITS > tables from the corresponding NUMA node using the appropriate NUMA > aware

[PATCH V3 1/2] dmaengine: qcom_hidma: introduce memset support

HIDMA HW supports memset operation in addition to memcpy. Since the memset API is present on the kernel now, bring the memset feature into life. The descriptor format is the same for both memcpy and memset. Type of the descriptor is 4 when memset is requested. The lowest 8 bits of the source DMA

[PATCH V3 1/2] dmaengine: qcom_hidma: introduce memset support

HIDMA HW supports memset operation in addition to memcpy. Since the memset API is present on the kernel now, bring the memset feature into life. The descriptor format is the same for both memcpy and memset. Type of the descriptor is 4 when memset is requested. The lowest 8 bits of the source DMA

[PATCH V3 2/2] dmaengine: dmatest: add support for memset test

Introducing memset test into dmatest. This change allows us to test memset capable HW using the dmatest test procedure. The new dmatest value for memset is 2 and it is not the default value. Memset support patch shares the same code path as the other dmatest code to reuse as much as we can. The

[PATCH V3 2/2] dmaengine: dmatest: add support for memset test

Introducing memset test into dmatest. This change allows us to test memset capable HW using the dmatest test procedure. The new dmatest value for memset is 2 and it is not the default value. Memset support patch shares the same code path as the other dmatest code to reuse as much as we can. The

Re: [PATCH] kbuild: improve comments on KBUILD_SRC

On 06/29/2017 11:14 PM, Masahiro Yamada wrote: > 2017-06-23 16:31 GMT+09:00 Cao jin : >> Original comments is confusing on "OBJ directory", make it clear. >> >> Bonus: move comments close to what it want to comment. >> Signed-off-by: Cao jin

Re: [PATCH] kbuild: improve comments on KBUILD_SRC

On 06/29/2017 11:14 PM, Masahiro Yamada wrote: > 2017-06-23 16:31 GMT+09:00 Cao jin : >> Original comments is confusing on "OBJ directory", make it clear. >> >> Bonus: move comments close to what it want to comment. >> Signed-off-by: Cao jin >> --- >> Makefile | 7 --- >> 1 file changed, 4

Re: [PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead

Hi Huang, Ccing Johannes: I don't read this patch yet but I remember Johannes tried VMA-based readahead approach long time ago so he might have good comment. On Fri, Jun 30, 2017 at 09:44:37AM +0800, Huang, Ying wrote: > The swap readahead is an important mechanism to reduce the swap in >

Re: [PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead

Hi Huang, Ccing Johannes: I don't read this patch yet but I remember Johannes tried VMA-based readahead approach long time ago so he might have good comment. On Fri, Jun 30, 2017 at 09:44:37AM +0800, Huang, Ying wrote: > The swap readahead is an important mechanism to reduce the swap in >

[PATCH] vmalloc: respect the GFP_NOIO and GFP_NOFS flags

The __vmalloc function has a parameter gfp_mask with the allocation flags, however it doesn't fully respect the GFP_NOIO and GFP_NOFS flags. The pages are allocated with the specified gfp flags, but the pagetables are always allocated with GFP_KERNEL. This allocation can cause unexpected recursion

[PATCH] vmalloc: respect the GFP_NOIO and GFP_NOFS flags

The __vmalloc function has a parameter gfp_mask with the allocation flags, however it doesn't fully respect the GFP_NOIO and GFP_NOFS flags. The pages are allocated with the specified gfp flags, but the pagetables are always allocated with GFP_KERNEL. This allocation can cause unexpected recursion

Re: [PATCH 1/1] selftests: gpio: use pkg-config to determine libmount CFLAGS/LDLIBS

On 29 June 2017 at 19:39, Fathi Boudra wrote: > On 29 June 2017 at 12:01, Michael Ellerman wrote: >> Fathi Boudra writes: >> >>> Fix hardcoded and misplaced libmount headers. Use pkg-config instead to >>> figure out

Re: [PATCH 1/1] selftests: gpio: use pkg-config to determine libmount CFLAGS/LDLIBS

On 29 June 2017 at 19:39, Fathi Boudra wrote: > On 29 June 2017 at 12:01, Michael Ellerman wrote: >> Fathi Boudra writes: >> >>> Fix hardcoded and misplaced libmount headers. Use pkg-config instead to >>> figure out CFLAGS/LDLIBS, fixing also their value for cross-compilation. >> >> Can you

[PATCH] uvesafb: use pr_cont when printing multiple parameters on the same line

The kernel automatically inserts newlines between printk calls unless pr_cont is used. This patch changes the uvesafb log message from: [5.263290] uvesafb: [5.263292] SeaBIOS Developers, [5.263293] SeaBIOS VBE Adapter, [5.263294] Rev. 1, [5.263294] OEM: SeaBIOS VBE(C) 2011, [

[PATCH] uvesafb: use pr_cont when printing multiple parameters on the same line

The kernel automatically inserts newlines between printk calls unless pr_cont is used. This patch changes the uvesafb log message from: [5.263290] uvesafb: [5.263292] SeaBIOS Developers, [5.263293] SeaBIOS VBE Adapter, [5.263294] Rev. 1, [5.263294] OEM: SeaBIOS VBE(C) 2011, [

Re: [PATCH] mm: convert three more cases to kvmalloc

On Thu, 29 Jun 2017, Michal Hocko wrote: > On Wed 28-06-17 23:24:10, Mikulas Patocka wrote: > [...] > > From: Mikulas Patocka > > > > The patch a7c3e901 ("mm: introduce kv[mz]alloc helpers") converted a lot > > of kernel code to kvmalloc. This patch converts three more

Re: [PATCH] mm: convert three more cases to kvmalloc

On Thu, 29 Jun 2017, Michal Hocko wrote: > On Wed 28-06-17 23:24:10, Mikulas Patocka wrote: > [...] > > From: Mikulas Patocka > > > > The patch a7c3e901 ("mm: introduce kv[mz]alloc helpers") converted a lot > > of kernel code to kvmalloc. This patch converts three more forgotten > > cases.

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 03:59:04PM -0700, Andy Lutomirski wrote: > > On Jun 29, 2017, at 2:41 PM, Josh Poimboeuf wrote: > >> On Thu, Jun 29, 2017 at 02:09:54PM -0700, Andy Lutomirski wrote: > >>> On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf > >>>

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 03:59:04PM -0700, Andy Lutomirski wrote: > > On Jun 29, 2017, at 2:41 PM, Josh Poimboeuf wrote: > >> On Thu, Jun 29, 2017 at 02:09:54PM -0700, Andy Lutomirski wrote: > >>> On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf > >>> wrote: > On Thu, Jun 29, 2017 at

<    1   2   3   4   5   6   7   8   9   10   >