[PATCH v4 6/9] scripts: add Linux .cocciconfig for coccinelle

Coccinelle supports reading .cocciconfig, the order of precedence for variables for .cocciconfig is as follows: o Your current user's home directory is processed first o Your directory from which spatch is called is processed next o The directory provided with the --dir option is processed

[PATCH v4 7/9] coccicheck: add support for requring a coccinelle version

Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On 6/29/2016 5:19 PM, Rafael J. Wysocki wrote: > On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: >> On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: >>> On Wed, Jun 29, 2016 at 10:27 AM, Sinan Kaya wrote: The change introduced in commit

[PATCH v4 6/9] scripts: add Linux .cocciconfig for coccinelle

Coccinelle supports reading .cocciconfig, the order of precedence for variables for .cocciconfig is as follows: o Your current user's home directory is processed first o Your directory from which spatch is called is processed next o The directory provided with the --dir option is processed

[PATCH v4 7/9] coccicheck: add support for requring a coccinelle version

Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On 6/29/2016 5:19 PM, Rafael J. Wysocki wrote: > On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: >> On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: >>> On Wed, Jun 29, 2016 at 10:27 AM, Sinan Kaya wrote: The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource

[RFC v4 7/9] coccicheck: add support for requring a coccinelle version

Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with

[RFC v4 7/9] coccicheck: add support for requring a coccinelle version

Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with

[RFC v4 9/9] scripts/coccinelle: require coccinelle >= 1.0.4 on device_node_continue.cocci

Make use of the new Requires: tag to be able to specify coccinelle binary version requirements. The cocci file device_node_continue.cocci requires at least coccinelle 1.0.4. Acked-by: Julia Lawall Acked-by: Nicolas Palix Signed-off-by: Luis R.

[RFC v4 9/9] scripts/coccinelle: require coccinelle >= 1.0.4 on device_node_continue.cocci

Make use of the new Requires: tag to be able to specify coccinelle binary version requirements. The cocci file device_node_continue.cocci requires at least coccinelle 1.0.4. Acked-by: Julia Lawall Acked-by: Nicolas Palix Signed-off-by: Luis R. Rodriguez ---

[RFC v4 8/9] coccicheck: refer to Documentation/coccinelle.txt and wiki

Refer to the Documentation/coccinelle.txt and supplemental documentation on the wiki: https://bottest.wiki.kernel.org/coccicheck This page shall always refer to the linux-next iteration of scripts/coccicheck. v4: only refer to the wiki as supplemental documentation, and also update

[RFC v4 8/9] coccicheck: refer to Documentation/coccinelle.txt and wiki

Refer to the Documentation/coccinelle.txt and supplemental documentation on the wiki: https://bottest.wiki.kernel.org/coccicheck This page shall always refer to the linux-next iteration of scripts/coccicheck. v4: only refer to the wiki as supplemental documentation, and also update

[RFC v4 6/9] scripts: add Linux .cocciconfig for coccinelle

Coccinelle supports reading .cocciconfig, the order of precedence for variables for .coccoconfig is as follows: o Your current user's home directory is processed first o Your directory from which spatch is called is processed next o The directory provided with the --dir option is processed

[RFC v4 1/9] coccicheck: move spatch binary check up

This has no functional changes. This is being done to enable us to later use spatch binary for some flag checking for certain features early on. Signed-off-by: Luis R. Rodriguez Acked-by: Nicolas Palix --- scripts/coccicheck | 10 +- 1 file

[RFC v4 1/9] coccicheck: move spatch binary check up

This has no functional changes. This is being done to enable us to later use spatch binary for some flag checking for certain features early on. Signed-off-by: Luis R. Rodriguez Acked-by: Nicolas Palix --- scripts/coccicheck | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)

[RFC v4 6/9] scripts: add Linux .cocciconfig for coccinelle

Coccinelle supports reading .cocciconfig, the order of precedence for variables for .coccoconfig is as follows: o Your current user's home directory is processed first o Your directory from which spatch is called is processed next o The directory provided with the --dir option is processed

[RFC v4 2/9] coccicheck: make SPFLAGS more useful

SPFLAGS is set early, it means that any heuristics done on coccicheck cannot be overridden currently. Move SPFLAGS after OPTIONS and set this at the end. This lets you override any heuristics as coccinelle treats conflicts by only listening to the last option that makes sense. v3: this patch was

[RFC v4 2/9] coccicheck: make SPFLAGS more useful

SPFLAGS is set early, it means that any heuristics done on coccicheck cannot be overridden currently. Move SPFLAGS after OPTIONS and set this at the end. This lets you override any heuristics as coccinelle treats conflicts by only listening to the last option that makes sense. v3: this patch was

[RFC v4 3/9] coccicheck: enable parmap support

Coccinelle has had parmap support since 1.0.2, this means it supports --jobs, enabling built-in multithreaded functionality, instead of needing one to script it out. Just look for --jobs in the help output to determine if this is supported and use it only if your number of processors detected is >

[RFC v4 4/9] coccicheck: add support for DEBUG_FILE

Enable to capture stderr via a DEBUG_FILE variable passed to coccicheck. You can now do: $ rm -f cocci.err $ export COCCI=scripts/coccinelle/free/kfree.cocci $ make coccicheck MODE=report DEBUG_FILE=cocci.err ... $ cat cocci.err This will be come more useful once we add support to use more

[RFC v4 3/9] coccicheck: enable parmap support

Coccinelle has had parmap support since 1.0.2, this means it supports --jobs, enabling built-in multithreaded functionality, instead of needing one to script it out. Just look for --jobs in the help output to determine if this is supported and use it only if your number of processors detected is >

[RFC v4 4/9] coccicheck: add support for DEBUG_FILE

Enable to capture stderr via a DEBUG_FILE variable passed to coccicheck. You can now do: $ rm -f cocci.err $ export COCCI=scripts/coccinelle/free/kfree.cocci $ make coccicheck MODE=report DEBUG_FILE=cocci.err ... $ cat cocci.err This will be come more useful once we add support to use more

[RFC v4 0/9] coccicheck: private review for modernization

Here's a v4 RFC, sending it privately to avoid bikeshedding in public. These are rebased on top of linux-next tag next-20160623. Luis R. Rodriguez (9): coccicheck: move spatch binary check up coccicheck: make SPFLAGS more useful coccicheck: enable parmap support coccicheck: add support

[RFC v4 5/9] coccicheck: replace --very-quiet with --quit when debugging

When debugging (using --profile or --show-trying) you want to avoid supressing output, use --quiet instead. While at it, extend documentation for SPFLAGS use. For instance one can use: $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci $ make coccicheck DEBUG_FILE="poo.err" MODE=report

[RFC v4 0/9] coccicheck: private review for modernization

Here's a v4 RFC, sending it privately to avoid bikeshedding in public. These are rebased on top of linux-next tag next-20160623. Luis R. Rodriguez (9): coccicheck: move spatch binary check up coccicheck: make SPFLAGS more useful coccicheck: enable parmap support coccicheck: add support

[RFC v4 5/9] coccicheck: replace --very-quiet with --quit when debugging

When debugging (using --profile or --show-trying) you want to avoid supressing output, use --quiet instead. While at it, extend documentation for SPFLAGS use. For instance one can use: $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci $ make coccicheck DEBUG_FILE="poo.err" MODE=report

Re: [PATCH v3 1/2] drm/panel: simple: Add support for Sharp LQ101K1LY04

Thierry, David, Can these patches be pulled in? Do I need anything additional? the Documentation bit has been Acked by Rob Herring. On 06/01/2016 08:35 AM, Joshua Clayton wrote: > Trivial patch to add Sharp LQ101K1LY04i to simple-panel > > Support the Sharp LQ101K1LY04i, a 10 inch WXGA (1280x800)

Re: [PATCH v3 1/2] drm/panel: simple: Add support for Sharp LQ101K1LY04

Thierry, David, Can these patches be pulled in? Do I need anything additional? the Documentation bit has been Acked by Rob Herring. On 06/01/2016 08:35 AM, Joshua Clayton wrote: > Trivial patch to add Sharp LQ101K1LY04i to simple-panel > > Support the Sharp LQ101K1LY04i, a 10 inch WXGA (1280x800)

Re: [PATCH 2/2] lib: kstrtox: _parse_integer: use hex_to_bin instead local conversion, and reduce branches

On Thu, Jun 30, 2016 at 12:22:13AM +0800, zengzhao...@163.com wrote: > --- a/lib/kstrtox.c > +++ b/lib/kstrtox.c > @@ -48,38 +48,26 @@ unsigned int _parse_integer(const char *s, unsigned int > base, unsigned long long > { > unsigned long long res; > unsigned int rv; > - int

Re: [PATCH 2/2] lib: kstrtox: _parse_integer: use hex_to_bin instead local conversion, and reduce branches

On Thu, Jun 30, 2016 at 12:22:13AM +0800, zengzhao...@163.com wrote: > --- a/lib/kstrtox.c > +++ b/lib/kstrtox.c > @@ -48,38 +48,26 @@ unsigned int _parse_integer(const char *s, unsigned int > base, unsigned long long > { > unsigned long long res; > unsigned int rv; > - int

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On Wed, Jun 29, 2016 at 2:43 PM, Paul Bolle wrote: > On wo, 2016-06-29 at 21:05 +0200, Luis R. Rodriguez wrote: >> I haven't seen any objections or questions, so just a friendly *poke*. > > At the end of the day, what matters most is whether a module is GPL v2 > compatible. So

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On Wed, Jun 29, 2016 at 2:43 PM, Paul Bolle wrote: > On wo, 2016-06-29 at 21:05 +0200, Luis R. Rodriguez wrote: >> I haven't seen any objections or questions, so just a friendly *poke*. > > At the end of the day, what matters most is whether a module is GPL v2 > compatible. So why are the

Re: [PATCH 4/7] reset: Supply *_shared variant calls when using *_optional APIs

Hi Lee, On Wed, Jun 29, 2016 at 10:37:34AM +0100, Lee Jones wrote: [...] > > > > If that is not the case, go ahead. Otherwise I could provide > > > > a tag at commit 2485394d9e0b ("reset: TRIVIAL: Add line break at same > > > > place for similar APIs") for you to merge. > > > > > > Yes please.

Re: [PATCH 4/7] reset: Supply *_shared variant calls when using *_optional APIs

Hi Lee, On Wed, Jun 29, 2016 at 10:37:34AM +0100, Lee Jones wrote: [...] > > > > If that is not the case, go ahead. Otherwise I could provide > > > > a tag at commit 2485394d9e0b ("reset: TRIVIAL: Add line break at same > > > > place for similar APIs") for you to merge. > > > > > > Yes please.

[patch for-4.7] mm, compaction: prevent VM_BUG_ON when terminating freeing scanner

It's possible to isolate some freepages in a pageblock and then fail split_free_page() due to the low watermark check. In this case, we hit VM_BUG_ON() because the freeing scanner terminated early without a contended lock or enough freepages. This should never have been a VM_BUG_ON() since

[patch for-4.7] mm, compaction: prevent VM_BUG_ON when terminating freeing scanner

It's possible to isolate some freepages in a pageblock and then fail split_free_page() due to the low watermark check. In this case, we hit VM_BUG_ON() because the freeing scanner terminated early without a contended lock or enough freepages. This should never have been a VM_BUG_ON() since

[PATCH] drm_aux-dev: fix error handling in drm_dp_aux_dev_init()

If class_create() fails, there is no need for class_destroy(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/gpu/drm/drm_dp_aux_dev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH] drm_aux-dev: fix error handling in drm_dp_aux_dev_init()

If class_create() fails, there is no need for class_destroy(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/gpu/drm/drm_dp_aux_dev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On wo, 2016-06-29 at 21:05 +0200, Luis R. Rodriguez wrote: > I haven't seen any objections or questions, so just a friendly *poke*. At the end of the day, what matters most is whether a module is GPL v2 compatible. So why are the specific license idents for the various GPL v2 compatible licenses

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On wo, 2016-06-29 at 21:05 +0200, Luis R. Rodriguez wrote: > I haven't seen any objections or questions, so just a friendly *poke*. At the end of the day, what matters most is whether a module is GPL v2 compatible. So why are the specific license idents for the various GPL v2 compatible licenses

Re: [PATCH V2 4/4] ACPI,PCI,IRQ: correct operator precedence

On Wed, Jun 29, 2016 at 11:19 PM, Sinan Kaya wrote: > On 6/29/2016 5:14 PM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 8:29 PM, Sinan Kaya wrote: >>> On 6/29/2016 9:16 AM, Rafael J. Wysocki wrote: > Signed-off-by: Sinan Kaya

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On Wed, Jun 29, 2016 at 11:21 PM, Sinan Kaya wrote: > On 6/29/2016 5:19 PM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: >>> On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: On Wed, Jun 29, 2016 at 10:27 AM, Sinan

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On Wed, Jun 29, 2016 at 11:21 PM, Sinan Kaya wrote: > On 6/29/2016 5:19 PM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: >>> On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: On Wed, Jun 29, 2016 at 10:27 AM, Sinan Kaya wrote: > The change introduced in

Re: [PATCH V2 4/4] ACPI,PCI,IRQ: correct operator precedence

On Wed, Jun 29, 2016 at 11:19 PM, Sinan Kaya wrote: > On 6/29/2016 5:14 PM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 8:29 PM, Sinan Kaya wrote: >>> On 6/29/2016 9:16 AM, Rafael J. Wysocki wrote: > Signed-off-by: Sinan Kaya Well, this is a rather obvious one, so I'm wondering

Re: [PATCH] drm: mediatek: fix prototypes after API change

Hi Arnd, On Wed, 29 Jun 2016 16:51:29 +0200 Arnd Bergmann wrote: > > The newly added mediatek HDMI driver clashes with an API change > for struct hdmi_codec_ops, causing an 'allmodconfig' build to fail: > > drivers/gpu/drm/mediatek/mtk_hdmi.c:1653:15: error: initialization from

Re: [PATCH] drm: mediatek: fix prototypes after API change

Hi Arnd, On Wed, 29 Jun 2016 16:51:29 +0200 Arnd Bergmann wrote: > > The newly added mediatek HDMI driver clashes with an API change > for struct hdmi_codec_ops, causing an 'allmodconfig' build to fail: > > drivers/gpu/drm/mediatek/mtk_hdmi.c:1653:15: error: initialization from > incompatible

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Wed, Jun 29, 2016 at 8:15 PM, wrote: > From: Fu Wei > > This patchset: > (1)Preparation for adding GTDT support in arm_arch_timer > 1. Move some enums and marcos to header file > 2. Add a new enum for spi type. > 3. Improve

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Wed, Jun 29, 2016 at 8:15 PM, wrote: > From: Fu Wei > > This patchset: > (1)Preparation for adding GTDT support in arm_arch_timer > 1. Move some enums and marcos to header file > 2. Add a new enum for spi type. > 3. Improve printk relevant code > >

Re: modules: add ro_after_init support

+++ Rusty Russell [29/06/16 10:38 +0930]: Jessica Yu writes: Add ro_after_init support for modules by adding a new page-aligned section in the module layout (after rodata) for ro_after_init data and enabling RO protection for that section after module init runs.

Re: modules: add ro_after_init support

+++ Rusty Russell [29/06/16 10:38 +0930]: Jessica Yu writes: Add ro_after_init support for modules by adding a new page-aligned section in the module layout (after rodata) for ro_after_init data and enabling RO protection for that section after module init runs. Signed-off-by: Jessica Yu I

[PATCH] nfit: fix format interface code byte order

Per JEDEC Annex L Release 3 the SPD data is: Bits 9~5 00 000 = Function Undefined 00 001 = Byte addressable energy backed 00 010 = Block addressed 00 011 = Byte addressable, no energy backed All other codes reserved Bits 4~0 0 = Proprietary interface

[PATCH] nfit: fix format interface code byte order

Per JEDEC Annex L Release 3 the SPD data is: Bits 9~5 00 000 = Function Undefined 00 001 = Byte addressable energy backed 00 010 = Block addressed 00 011 = Byte addressable, no energy backed All other codes reserved Bits 4~0 0 = Proprietary interface

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On Wed, Jun 29, 2016 at 11:21 PM, Sinan Kaya wrote: > On 6/29/2016 5:19 PM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: >>> On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: On Wed, Jun 29, 2016 at 10:27 AM, Sinan

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On Wed, Jun 29, 2016 at 11:21 PM, Sinan Kaya wrote: > On 6/29/2016 5:19 PM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: >>> On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: On Wed, Jun 29, 2016 at 10:27 AM, Sinan Kaya wrote: > The change introduced in

Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver

On Wed, Jun 29, 2016 at 8:15 PM, wrote: > From: Fu Wei No changelog? > Signed-off-by: Fu Wei Please combine this one with the [5-6/10]. Splitting them the way you did it is not very useful. Thanks, Rafael

Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver

On Wed, Jun 29, 2016 at 8:15 PM, wrote: > From: Fu Wei No changelog? > Signed-off-by: Fu Wei Please combine this one with the [5-6/10]. Splitting them the way you did it is not very useful. Thanks, Rafael

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: > On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 10:27 AM, Sinan Kaya wrote: >>> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce >>> resource

Re: [PATCH V2 1/4] ACPI,PCI,IRQ: factor in PCI possible

On Wed, Jun 29, 2016 at 8:47 PM, Sinan Kaya wrote: > On 6/29/2016 9:13 AM, Rafael J. Wysocki wrote: >> On Wed, Jun 29, 2016 at 10:27 AM, Sinan Kaya wrote: >>> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce >>> resource requirements") omitted the initially assigned POSSIBLE

0e80a5db05: WARNING: CPU: 1 PID: 0 at kernel/smp.c:416 smp_call_function_many+0xa7/0x2bb

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack commit 0e80a5db0584e9505a8dfaa94d4d72fbc8b0315f ("[DEBUG] forcibly free stacks immediately") in testcase: boot on test machine: 2 threads qemu-system-x86_64 -enable-kvm with

0e80a5db05: WARNING: CPU: 1 PID: 0 at kernel/smp.c:416 smp_call_function_many+0xa7/0x2bb

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack commit 0e80a5db0584e9505a8dfaa94d4d72fbc8b0315f ("[DEBUG] forcibly free stacks immediately") in testcase: boot on test machine: 2 threads qemu-system-x86_64 -enable-kvm with

Re: [PATCH V2 4/4] ACPI,PCI,IRQ: correct operator precedence

On 6/29/2016 5:14 PM, Rafael J. Wysocki wrote: > On Wed, Jun 29, 2016 at 8:29 PM, Sinan Kaya wrote: >> On 6/29/2016 9:16 AM, Rafael J. Wysocki wrote: Signed-off-by: Sinan Kaya >>> Well, this is a rather obvious one, so I'm wondering why it is the

Re: [PATCH V2 4/4] ACPI,PCI,IRQ: correct operator precedence

On 6/29/2016 5:14 PM, Rafael J. Wysocki wrote: > On Wed, Jun 29, 2016 at 8:29 PM, Sinan Kaya wrote: >> On 6/29/2016 9:16 AM, Rafael J. Wysocki wrote: Signed-off-by: Sinan Kaya >>> Well, this is a rather obvious one, so I'm wondering why it is the >>> last one in the series? >>> >> >> The

Re: [PATCH] power: qcom-smbb: add extcon dependency

On Wednesday, June 29, 2016 11:09:58 PM CEST Sebastian Reichel wrote: > On Wed, Jun 29, 2016 at 11:10:34AM -0700, Stephen Boyd wrote: > > On 06/29/2016 07:38 AM, Sebastian Reichel wrote: > > > On Wed, Jun 29, 2016 at 04:30:02PM +0200, Arnd Bergmann wrote: > > >> Building the smbb driver without

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

Am Mittwoch, 29 Juni 2016, 15:47:51 schrieb Dave Young: > On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > > index e8acb2b43dd9..e16d845d587f 100644 > > --- a/include/linux/kexec.h > > +++ b/include/linux/kexec.h > > @@ -146,7

Re: [PATCH] power: qcom-smbb: add extcon dependency

On Wednesday, June 29, 2016 11:09:58 PM CEST Sebastian Reichel wrote: > On Wed, Jun 29, 2016 at 11:10:34AM -0700, Stephen Boyd wrote: > > On 06/29/2016 07:38 AM, Sebastian Reichel wrote: > > > On Wed, Jun 29, 2016 at 04:30:02PM +0200, Arnd Bergmann wrote: > > >> Building the smbb driver without

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

Am Mittwoch, 29 Juni 2016, 15:47:51 schrieb Dave Young: > On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > > index e8acb2b43dd9..e16d845d587f 100644 > > --- a/include/linux/kexec.h > > +++ b/include/linux/kexec.h > > @@ -146,7

Re: [PATCH] acpi, apei: Add Boot Error Record Table (BERT) support

On Wed, Jun 29, 2016 at 10:04 PM, Luck, Tony wrote: > From: Huang Ying > > ACPI/APEI is designed to verifiy/report H/W errors, like Corrected > Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, > ERST, EINJ and BERT. The first three

RE: [PATCH] acpi, apei: Add Boot Error Record Table (BERT) support

>> but then it looks like it was forgotten again :-( > > Do you want me to take it? Yes please. -Tony

Re: [PATCH] acpi, apei: Add Boot Error Record Table (BERT) support

On Wed, Jun 29, 2016 at 10:04 PM, Luck, Tony wrote: > From: Huang Ying > > ACPI/APEI is designed to verifiy/report H/W errors, like Corrected > Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, > ERST, EINJ and BERT. The first three tables have been merged for > a long time,

RE: [PATCH] acpi, apei: Add Boot Error Record Table (BERT) support

>> but then it looks like it was forgotten again :-( > > Do you want me to take it? Yes please. -Tony

[PATCH V3 1/2] perf/x86/intel/uncore: Add support for Intel SKL client uncore

From: Kan Liang This patch addes full support for Intel SKL client uncore. - Add support for SKL client cpu uncore, which is similar to BDW client. There are some differences in CBOX number and uncore control MSR. - Add new support for SkyLake Mobile, include both

[PATCH V3 2/2] perf/x86/intel/uncore: add enable_box for client msr uncore

From: Kan Liang PERF_GLOBAL_CTL could be cleared after Package C7. This patch tries to workaround this issue by re-enable PERF_GLOBAL_CTL in enable_box. The workaround does not cover all cases. It helps for new events after returning from C7. There is no drawback in letting

Re: [PATCH V2 4/4] ACPI,PCI,IRQ: correct operator precedence

On Wed, Jun 29, 2016 at 8:29 PM, Sinan Kaya wrote: > On 6/29/2016 9:16 AM, Rafael J. Wysocki wrote: >>> Signed-off-by: Sinan Kaya >> Well, this is a rather obvious one, so I'm wondering why it is the >> last one in the series? >> > > The first three

[PATCH V3 1/2] perf/x86/intel/uncore: Add support for Intel SKL client uncore

From: Kan Liang This patch addes full support for Intel SKL client uncore. - Add support for SKL client cpu uncore, which is similar to BDW client. There are some differences in CBOX number and uncore control MSR. - Add new support for SkyLake Mobile, include both cpu and pci uncore

[PATCH V3 2/2] perf/x86/intel/uncore: add enable_box for client msr uncore

From: Kan Liang PERF_GLOBAL_CTL could be cleared after Package C7. This patch tries to workaround this issue by re-enable PERF_GLOBAL_CTL in enable_box. The workaround does not cover all cases. It helps for new events after returning from C7. There is no drawback in letting the thing enabled, so

Re: [PATCH V2 4/4] ACPI,PCI,IRQ: correct operator precedence

On Wed, Jun 29, 2016 at 8:29 PM, Sinan Kaya wrote: > On 6/29/2016 9:16 AM, Rafael J. Wysocki wrote: >>> Signed-off-by: Sinan Kaya >> Well, this is a rather obvious one, so I'm wondering why it is the >> last one in the series? >> > > The first three are more relevant to each other. It makes easy

Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

On 29.6.2016 22:45, Maxime Ripard wrote: > Hi, > > On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote: >> On 25.6.2016 09:02, Maxime Ripard wrote: >>> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote: On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman

Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

On 29.6.2016 22:45, Maxime Ripard wrote: > Hi, > > On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote: >> On 25.6.2016 09:02, Maxime Ripard wrote: >>> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote: On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman wrote: > Hello,

Re: [PATCH] power: qcom-smbb: add extcon dependency

Hi, On Wed, Jun 29, 2016 at 11:10:34AM -0700, Stephen Boyd wrote: > On 06/29/2016 07:38 AM, Sebastian Reichel wrote: > > On Wed, Jun 29, 2016 at 04:30:02PM +0200, Arnd Bergmann wrote: > >> Building the smbb driver without extcon results in a link failure: > >> > >> drivers/power/built-in.o: In

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

Am Mittwoch, 29 Juni 2016, 15:45:18 schrieb Dave Young: > On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > > Am Dienstag, 28 Juni 2016, 15:20:55 schrieb Dave Young: > > > On 06/27/16 at 04:21pm, Dave Young wrote: > > > Using one argument for both sounds more reasonable than using a > > >

Re: [PATCH] power: qcom-smbb: add extcon dependency

Hi, On Wed, Jun 29, 2016 at 11:10:34AM -0700, Stephen Boyd wrote: > On 06/29/2016 07:38 AM, Sebastian Reichel wrote: > > On Wed, Jun 29, 2016 at 04:30:02PM +0200, Arnd Bergmann wrote: > >> Building the smbb driver without extcon results in a link failure: > >> > >> drivers/power/built-in.o: In

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

Am Mittwoch, 29 Juni 2016, 15:45:18 schrieb Dave Young: > On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > > Am Dienstag, 28 Juni 2016, 15:20:55 schrieb Dave Young: > > > On 06/27/16 at 04:21pm, Dave Young wrote: > > > Using one argument for both sounds more reasonable than using a > > >

[GIT PULL] Please pull NFS client bugfixes for 4.7

Hi Linus, The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e: Linux 4.7-rc4 (2016-06-19 21:30:02 -0700) are available in the git repository at: git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.7-2 for you to fetch changes up to

[GIT PULL] Please pull NFS client bugfixes for 4.7

Hi Linus, The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e: Linux 4.7-rc4 (2016-06-19 21:30:02 -0700) are available in the git repository at: git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.7-2 for you to fetch changes up to

Re: [patch] mm, compaction: make sure freeing scanner isn't persistently expensive

On Wed, 29 Jun 2016, Vlastimil Babka wrote: > On 06/29/2016 03:39 AM, David Rientjes wrote: > > It's possible that the freeing scanner can be consistently expensive if > > memory is well compacted toward the end of the zone with few free pages > > available in that area. > > > > If all zone

Re: [patch] mm, compaction: make sure freeing scanner isn't persistently expensive

On Wed, 29 Jun 2016, Vlastimil Babka wrote: > On 06/29/2016 03:39 AM, David Rientjes wrote: > > It's possible that the freeing scanner can be consistently expensive if > > memory is well compacted toward the end of the zone with few free pages > > available in that area. > > > > If all zone

Re: [PATCH 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG in FS mode with internal PHY

On 6/29/2016 12:47 PM, Bruno Herrera wrote: > On Mon, Jun 27, 2016 at 7:51 PM, John Youn wrote: >> On 6/21/2016 7:26 PM, Bruno Herrera wrote: >>> Signed-off-by: Bruno Herrera >> >> Please add a commit message describing the purpose of your changes,

Re: [GIT PULL] doc: sphinx-4.8 DocBook to reST movement on Jon's docs-next

Em Wed, 29 Jun 2016 11:52:09 -0600 Jonathan Corbet escreveu: > > 2. What is the best way to ship these migrations > > > > or better I asked, what is your recommendation for a > > migration strategy. Jani says, that this better belongs > > to authors, but I have a doubt that we

Re: [PATCH 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG in FS mode with internal PHY

On 6/29/2016 12:47 PM, Bruno Herrera wrote: > On Mon, Jun 27, 2016 at 7:51 PM, John Youn wrote: >> On 6/21/2016 7:26 PM, Bruno Herrera wrote: >>> Signed-off-by: Bruno Herrera >> >> Please add a commit message describing the purpose of your changes, >> some information about the platform you're

Re: [GIT PULL] doc: sphinx-4.8 DocBook to reST movement on Jon's docs-next

Em Wed, 29 Jun 2016 11:52:09 -0600 Jonathan Corbet escreveu: > > 2. What is the best way to ship these migrations > > > > or better I asked, what is your recommendation for a > > migration strategy. Jani says, that this better belongs > > to authors, but I have a doubt that we end with the > >

Re: [PATCH] GenWQE: Change default access rights for device node

Frank Haverkamp writes: > Since it should always be ok for normal users to operate the accelerator, > it makes sense to change it in our driver, rather than adding udev rules > for all Linux distributions. > > Signed-off-by: Frank Haverkamp

Re: [PATCH] GenWQE: Change default access rights for device node

Frank Haverkamp writes: > Since it should always be ok for normal users to operate the accelerator, > it makes sense to change it in our driver, rather than adding udev rules > for all Linux distributions. > > Signed-off-by: Frank Haverkamp Reviewed-by: Gabriel Krisman Bertazi > --- >

Re: [PATCH v2 2/2] KVM: x86: fix underflow in TSC deadline calculation

On 29/06/2016 19:16, yunhong jiang wrote: >> > + start_sw_tscdeadline(apic); > IMHO, it's not good to start_sw_tscdeadline() on the start_hv_tscdeadline() > function. I think it's expected that the sw_timer is stopped when > start_hv_tscdeadline() returns successsfully, or sw_timer is

Re: [PATCH v2 2/2] KVM: x86: fix underflow in TSC deadline calculation

On 29/06/2016 19:16, yunhong jiang wrote: >> > + start_sw_tscdeadline(apic); > IMHO, it's not good to start_sw_tscdeadline() on the start_hv_tscdeadline() > function. I think it's expected that the sw_timer is stopped when > start_hv_tscdeadline() returns successsfully, or sw_timer is

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On di, 2016-06-14 at 11:35 -0700, Luis R. Rodriguez wrote: > copyleft-next [0] [1] is an openly evolved copyleft license, its an > effort to evolve copyleft without participation of the Church (TM) > or State (R), completley openly to the extend development and > discussion of copyleft-next by

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On di, 2016-06-14 at 11:35 -0700, Luis R. Rodriguez wrote: > copyleft-next [0] [1] is an openly evolved copyleft license, its an > effort to evolve copyleft without participation of the Church (TM) > or State (R), completley openly to the extend development and > discussion of copyleft-next by

Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

On 29/06/2016 19:25, Quentin Casasnovas wrote: > On Fri, Jun 24, 2016 at 03:10:03PM +0200, Paolo Bonzini wrote: >> On 24/06/2016 15:04, Quentin Casasnovas wrote: >>> On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote: On 18/06/2016 11:01, Quentin Casasnovas wrote: >

Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

On 29/06/2016 19:25, Quentin Casasnovas wrote: > On Fri, Jun 24, 2016 at 03:10:03PM +0200, Paolo Bonzini wrote: >> On 24/06/2016 15:04, Quentin Casasnovas wrote: >>> On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote: On 18/06/2016 11:01, Quentin Casasnovas wrote: >

Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

Hi, On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote: > On 25.6.2016 09:02, Maxime Ripard wrote: > > On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote: > >> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman wrote: > >>> Hello, > >>> > >>> comments below. >

Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

Hi, On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote: > On 25.6.2016 09:02, Maxime Ripard wrote: > > On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote: > >> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman wrote: > >>> Hello, > >>> > >>> comments below. > >>> > >>> On

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