Re: [PATCH v3 3/5] gpio: pca953x: refactor pca953x_read_regs()

2016-09-07 15:56 GMT+02:00 Andy Shevchenko : > On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: >> Avoid the unnecessary if-else in pca953x_read_regs() by spltting the >> routine into smaller, specialized functions and calling the right one >> via a function pointer held in struct

Re: [PATCH v3 1/1] x86/platform/intel-mid: Implement power off sequence

On Wed, 2016-09-07 at 15:39 +0300, Andy Shevchenko wrote: > +#define IPCMSG_COLD_OFF0x80/* Only for Tangier > */ Andy, I'm wondering are these magic numbers documented somewhere ? --- bod

Re: i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

On Mon, 29 Aug 2016, Meelis Roos wrote: > Tried 4.8-rc4 on my i5-2400 PC, got this warning: Fixed in drm-intel-fixes by commit fc2780b66b15092ac68272644a522c1624c48547 Author: Chris Wilson Date: Fri Aug 26 11:59:26 2016 +0100 drm/i915: Add

[PATCH v4 4/5] gpio: pca953x: remove an unused variable

The chip_type variable in struct pca953x_chip is no longer required. Remove it. Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko --- drivers/gpio/gpio-pca953x.c | 5 + 1 file changed, 1 insertion(+), 4

[PATCH v4 5/5] gpio: pca953x: coding style fixes

pca953x_gpio_set_multiple() has some coding style issues that make it harder to read. Tweak the code a bit. Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko --- drivers/gpio/gpio-pca953x.c | 22 --

Re: i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

On Mon, 29 Aug 2016, Meelis Roos wrote: > Tried 4.8-rc4 on my i5-2400 PC, got this warning: Fixed in drm-intel-fixes by commit fc2780b66b15092ac68272644a522c1624c48547 Author: Chris Wilson Date: Fri Aug 26 11:59:26 2016 +0100 drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE

[PATCH v4 4/5] gpio: pca953x: remove an unused variable

The chip_type variable in struct pca953x_chip is no longer required. Remove it. Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko --- drivers/gpio/gpio-pca953x.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpio/gpio-pca953x.c

[PATCH v4 5/5] gpio: pca953x: coding style fixes

pca953x_gpio_set_multiple() has some coding style issues that make it harder to read. Tweak the code a bit. Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko --- drivers/gpio/gpio-pca953x.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git

Re: [PATCH v3 4/8] gpio: dt-bindings: Add documentation for Aspeed GPIO controllers

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Signed-off-by: Andrew Jeffery > Acked-by: Joel Stanley Patch applied to the GPIO tree with Rob's ACK and moved the compatible to the first line in the process. Yours, Linus Walleij

Re: [PATCH v3 4/8] gpio: dt-bindings: Add documentation for Aspeed GPIO controllers

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Signed-off-by: Andrew Jeffery > Acked-by: Joel Stanley Patch applied to the GPIO tree with Rob's ACK and moved the compatible to the first line in the process. Yours, Linus Walleij

[PATCH 7/8] wbt: add general throttling mechanism

We can hook this up to the block layer, to help throttle buffered writes. Or NFS can tap into it, to accomplish the same. wbt registers a few trace points that can be used to track what is happening in the system: wbt_lat: 259:0: latency 2446318 wbt_stat: 259:0: rmean=2446318, rmin=2446318,

[PATCH 7/8] wbt: add general throttling mechanism

We can hook this up to the block layer, to help throttle buffered writes. Or NFS can tap into it, to accomplish the same. wbt registers a few trace points that can be used to track what is happening in the system: wbt_lat: 259:0: latency 2446318 wbt_stat: 259:0: rmean=2446318, rmin=2446318,

[PATCH 8/8] writeback: throttle buffered writeback

Test patch that throttles buffered writeback to make it a lot more smooth, and has way less impact on other system activity. Background writeback should be, by definition, background activity. The fact that we flush huge bundles of it at the time means that it potentially has heavy impacts on

[PATCH 8/8] writeback: throttle buffered writeback

Test patch that throttles buffered writeback to make it a lot more smooth, and has way less impact on other system activity. Background writeback should be, by definition, background activity. The fact that we flush huge bundles of it at the time means that it potentially has heavy impacts on

[PATCH 2/8] writeback: add wbc_to_write_flags()

Add wbc_to_write_flags(), which returns the write modifier flags to use, based on a struct writeback_control. No functional changes in this patch, but it prepares us for factoring other wbc fields for write type. Signed-off-by: Jens Axboe Reviewed-by: Jan Kara ---

[PATCH 4/8] writeback: track if we're sleeping on progress in balance_dirty_pages()

Note in the bdi_writeback structure whenever a task ends up sleeping waiting for progress. We can use that information in the lower layers to increase the priority of writes. Signed-off-by: Jens Axboe --- include/linux/backing-dev-defs.h | 2 ++ mm/backing-dev.c |

[PATCH 1/8] block: add WRITE_BG

This adds a new request flag, REQ_BG, that callers can use to tell the block layer that this is background (non-urgent) IO. Signed-off-by: Jens Axboe --- include/linux/blk_types.h | 4 +++- include/linux/fs.h| 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-) diff

[PATCH 2/8] writeback: add wbc_to_write_flags()

Add wbc_to_write_flags(), which returns the write modifier flags to use, based on a struct writeback_control. No functional changes in this patch, but it prepares us for factoring other wbc fields for write type. Signed-off-by: Jens Axboe Reviewed-by: Jan Kara --- fs/buffer.c | 2

[PATCH 4/8] writeback: track if we're sleeping on progress in balance_dirty_pages()

Note in the bdi_writeback structure whenever a task ends up sleeping waiting for progress. We can use that information in the lower layers to increase the priority of writes. Signed-off-by: Jens Axboe --- include/linux/backing-dev-defs.h | 2 ++ mm/backing-dev.c | 1 +

[PATCH 1/8] block: add WRITE_BG

This adds a new request flag, REQ_BG, that callers can use to tell the block layer that this is background (non-urgent) IO. Signed-off-by: Jens Axboe --- include/linux/blk_types.h | 4 +++- include/linux/fs.h| 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git

[patch v3] leds: add driver for Mellanox systems leds

From: Vadim Pasternak This makes it possible to create a set of LEDs for Mellanox systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100". Driver obtains led devices according to system configuration, provided through

[patch v3] leds: add driver for Mellanox systems leds

From: Vadim Pasternak This makes it possible to create a set of LEDs for Mellanox systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100". Driver obtains led devices according to system configuration, provided through system DMI data, like

Re: [PATCH v3 1/8] MAINTAINERS: Add glob for Aspeed devicetree bindings

On Wednesday, September 7, 2016 4:37:15 PM CEST Linus Walleij wrote: > On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > > > Signed-off-by: Andrew Jeffery > > Acked-by: Joel Stanley > > Acked-by: Linus Walleij

Re: [PATCH v3 1/8] MAINTAINERS: Add glob for Aspeed devicetree bindings

On Wednesday, September 7, 2016 4:37:15 PM CEST Linus Walleij wrote: > On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > > > Signed-off-by: Andrew Jeffery > > Acked-by: Joel Stanley > > Acked-by: Linus Walleij > > I guess some device tree maintainer or SoC tree should merge this

Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel

ebied...@xmission.com (Eric W. Biederman) writes: > Thiago Jung Bauermann writes: > >> Hello, >> >> The purpose of this new version of the series is to fix a small issue that >> I found, which is that the kernel doesn't remove the memory reservation >> for the

Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel

ebied...@xmission.com (Eric W. Biederman) writes: > Thiago Jung Bauermann writes: > >> Hello, >> >> The purpose of this new version of the series is to fix a small issue that >> I found, which is that the kernel doesn't remove the memory reservation >> for the hand-over buffer it received from

Re: [PATCH v3 3/8] pinctrl: dt-bindings: Add documentation for Aspeed pin controllers

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Outline expectations on the pin controller's relationship with the > System Control Unit (SCU) IP through syscon, and document the compatible > strings for 4th and 5th generation Aspeed SoC pin controllers. > >

Re: [PATCH v3 3/8] pinctrl: dt-bindings: Add documentation for Aspeed pin controllers

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Outline expectations on the pin controller's relationship with the > System Control Unit (SCU) IP through syscon, and document the compatible > strings for 4th and 5th generation Aspeed SoC pin controllers. > > Signed-off-by: Andrew

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Wednesday, September 7, 2016 4:04:52 PM CEST Roger Quadros wrote: > > The main use for it is to let you specify a MAC address for on-board > > ethernet devices that lack an EPROM, but any other information can be > > added that way too. > > > >> There is a bug in the USB core because of which

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Wednesday, September 7, 2016 4:04:52 PM CEST Roger Quadros wrote: > > The main use for it is to let you specify a MAC address for on-board > > ethernet devices that lack an EPROM, but any other information can be > > added that way too. > > > >> There is a bug in the USB core because of which

Re: [PATCH v3 2/8] syscon: dt-bindings: Add documentation for Aspeed system control units

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Signed-off-by: Andrew Jeffery > Acked-by: Rob Herring > Acked-by: Joel Stanley Acked-by: Linus Walleij I guess the MFD maintainer (Lee

Re: [PATCH v3 2/8] syscon: dt-bindings: Add documentation for Aspeed system control units

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Signed-off-by: Andrew Jeffery > Acked-by: Rob Herring > Acked-by: Joel Stanley Acked-by: Linus Walleij I guess the MFD maintainer (Lee Jones) should merge this? Why is he not on CC? Yours, Linus Walleij

[PATCH] serial: max310x: Set IRQF_TRIGGER_FALLING flag when dev.of_node is not NULL

When dev.of_node is not NULL, we also need to set IRQF_TRIGGER_FALLING flag, otherwise it may cause uncertain interrupts. Signed-off-by: Liu Xiang --- drivers/tty/serial/max310x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] serial: max310x: Set IRQF_TRIGGER_FALLING flag when dev.of_node is not NULL

When dev.of_node is not NULL, we also need to set IRQF_TRIGGER_FALLING flag, otherwise it may cause uncertain interrupts. Signed-off-by: Liu Xiang --- drivers/tty/serial/max310x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/max310x.c

Re: [PATCH v3 1/8] MAINTAINERS: Add glob for Aspeed devicetree bindings

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Signed-off-by: Andrew Jeffery > Acked-by: Joel Stanley Acked-by: Linus Walleij I guess some device tree maintainer or SoC tree should merge this patch. If you

Re: [PATCH v3 1/8] MAINTAINERS: Add glob for Aspeed devicetree bindings

On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > Signed-off-by: Andrew Jeffery > Acked-by: Joel Stanley Acked-by: Linus Walleij I guess some device tree maintainer or SoC tree should merge this patch. If you think it is proper to apply in the pinctrl or gpio tree, tell me. Yours,

Re: bcache vs bcachefs

On 2016-09-06 20:55, Kent Overstreet wrote: On Tue, Sep 06, 2016 at 11:46:28AM +0200, Harald Dunkel wrote: Hi folks, I am pretty hesitant replacing the rock-solid ext4 by bcachefs on my servers. Meaning no offense, but surely I would prefer to have ext4 with a thin "SSD caching layer" over a

Re: bcache vs bcachefs

On 2016-09-06 20:55, Kent Overstreet wrote: On Tue, Sep 06, 2016 at 11:46:28AM +0200, Harald Dunkel wrote: Hi folks, I am pretty hesitant replacing the rock-solid ext4 by bcachefs on my servers. Meaning no offense, but surely I would prefer to have ext4 with a thin "SSD caching layer" over a

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/06/2016 04:31 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/06/2016 04:31 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: Regulator probe

On Tue, 2016-09-06 at 11:24 +0100, Mark Brown wrote: >  > > > Anyway if that's the case then it should all be working already > > > then unless SFI goes down the ACPI code paths or someone changed > > > SFI since SFI won't flag as having full costraints and therefore > > > any missing regulator

Re: Regulator probe

On Tue, 2016-09-06 at 11:24 +0100, Mark Brown wrote: >  > > > Anyway if that's the case then it should all be working already > > > then unless SFI goes down the ACPI code paths or someone changed > > > SFI since SFI won't flag as having full costraints and therefore > > > any missing regulator

[PATCH] tools: spi: enable CROSS_COMPILE in Makefile

Signed-off-by: Jorge Ramirez-Ortiz --- tools/spi/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/tools/spi/Makefile b/tools/spi/Makefile index cd0db62..d1845b0 100644 --- a/tools/spi/Makefile +++ b/tools/spi/Makefile @@ -1,4 +1,8 @@ +CC =

[PATCH] tools: spi: enable CROSS_COMPILE in Makefile

Signed-off-by: Jorge Ramirez-Ortiz --- tools/spi/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/tools/spi/Makefile b/tools/spi/Makefile index cd0db62..d1845b0 100644 --- a/tools/spi/Makefile +++ b/tools/spi/Makefile @@ -1,4 +1,8 @@ +CC = $(CROSS_COMPILE)gcc + all: spidev_test

Re: [PATCH 15/21] mips: octeon: smp: Convert to hotplug state machine

On 2016-09-07 09:24:57 [+0100], Matt Redfearn wrote: > HI Sebastian, Hi Matt, > > --- a/include/linux/cpuhotplug.h > > +++ b/include/linux/cpuhotplug.h > > @@ -44,6 +44,7 @@ enum cpuhp_state { > > CPUHP_SH_SH3X_PREPARE, > > CPUHP_X86_MICRCODE_PREPARE, > > CPUHP_NOTF_ERR_INJ_PREPARE, >

Re: [PATCH 15/21] mips: octeon: smp: Convert to hotplug state machine

On 2016-09-07 09:24:57 [+0100], Matt Redfearn wrote: > HI Sebastian, Hi Matt, > > --- a/include/linux/cpuhotplug.h > > +++ b/include/linux/cpuhotplug.h > > @@ -44,6 +44,7 @@ enum cpuhp_state { > > CPUHP_SH_SH3X_PREPARE, > > CPUHP_X86_MICRCODE_PREPARE, > > CPUHP_NOTF_ERR_INJ_PREPARE, >

Re: [RFC PATCH v2 05/20] x86: Add the Secure Memory Encryption cpu feature

On 09/02/2016 09:09 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:22PM -0500, Tom Lendacky wrote: >> Update the cpu features to include identifying and reporting on the >> Secure Memory Encryption feature. >> >> Signed-off-by: Tom Lendacky >> --- >>

Re: [RFC PATCH v2 05/20] x86: Add the Secure Memory Encryption cpu feature

On 09/02/2016 09:09 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:22PM -0500, Tom Lendacky wrote: >> Update the cpu features to include identifying and reporting on the >> Secure Memory Encryption feature. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/include/asm/cpufeature.h

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/05/2016 03:48 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/05/2016 03:48 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/05/2016 10:22 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/05/2016 10:22 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: [PATCH 12/21] cpufreq: Convert to hotplug state machine

On 2016-09-06 23:27:46 [+0200], Rafael J. Wysocki wrote: > > + ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, > > "cpufreq:online", > > + cpufreq_online, > > + cpufreq_offline); > > + if (ret < 0) > > +

Re: [PATCH 12/21] cpufreq: Convert to hotplug state machine

On 2016-09-06 23:27:46 [+0200], Rafael J. Wysocki wrote: > > + ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, > > "cpufreq:online", > > + cpufreq_online, > > + cpufreq_offline); > > + if (ret < 0) > > +

Re: [PATCH V2 9/9] i2c: tegra: Add pinctrl support

On Fri, Aug 26, 2016 at 3:09 PM, Jon Hunter wrote: > On Tegra124/132 the pins for I2C6 are shared with the Display Port AUX > (DPAUX) channel and on Tegra210 the pins for I2C4 and I2C6 are shared > with DPAUX1 and DPAUX0, respectively. The multiplexing of the pins is >

Re: [PATCH V2 9/9] i2c: tegra: Add pinctrl support

On Fri, Aug 26, 2016 at 3:09 PM, Jon Hunter wrote: > On Tegra124/132 the pins for I2C6 are shared with the Display Port AUX > (DPAUX) channel and on Tegra210 the pins for I2C4 and I2C6 are shared > with DPAUX1 and DPAUX0, respectively. The multiplexing of the pins is > handled by a register in

Re: [PATCH 1/5] gpio: pca954x: fix undefined error code from remove

On Fri, Aug 26, 2016 at 5:25 PM, Arnd Bergmann wrote: > The recent addition of the regulator support has led to the pca953x_remove > function returning uninitialized data when no platform data pointer is > provided, as gcc warns when using -Wmaybe-uninitialized: > >

Re: [PATCH 1/5] gpio: pca954x: fix undefined error code from remove

On Fri, Aug 26, 2016 at 5:25 PM, Arnd Bergmann wrote: > The recent addition of the regulator support has led to the pca953x_remove > function returning uninitialized data when no platform data pointer is > provided, as gcc warns when using -Wmaybe-uninitialized: > > drivers/gpio/gpio-pca953x.c:

Re: [PATCH v2] arm64: Improve kprobes test for atomic sequence

On 09/07/2016 01:52 AM, Masami Hiramatsu wrote: On Tue, 6 Sep 2016 13:54:59 -0400 David Long wrote: From: "David A. Long" Kprobes searches backwards a finite number of instructions to determine if there is an attempt to probe a load/store

Re: [PATCH v2] arm64: Improve kprobes test for atomic sequence

On 09/07/2016 01:52 AM, Masami Hiramatsu wrote: On Tue, 6 Sep 2016 13:54:59 -0400 David Long wrote: From: "David A. Long" Kprobes searches backwards a finite number of instructions to determine if there is an attempt to probe a load/store exclusive sequence. It stops when it hits the

Re: [f2fs-dev] [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC

On 2016/9/3 2:36, Jaegeuk Kim wrote: > On Fri, Sep 02, 2016 at 03:33:33PM +0800, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2016/8/27 8:53, Jaegeuk Kim wrote: >>> This can avoid bio splits due to different op_flags. >> >> I thought about this, but I think this is not a good idea to increase merging >>

Re: [f2fs-dev] [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC

On 2016/9/3 2:36, Jaegeuk Kim wrote: > On Fri, Sep 02, 2016 at 03:33:33PM +0800, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2016/8/27 8:53, Jaegeuk Kim wrote: >>> This can avoid bio splits due to different op_flags. >> >> I thought about this, but I think this is not a good idea to increase merging >>

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/02/2016 01:14 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/02/2016 01:14 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >>

Re: [PATCH 11/21] ACPI: processor: Convert to hotplug state machine

On 2016-09-06 23:08:28 [+0200], Rafael J. Wysocki wrote: > This appears to be part of a series, but what if it goes in > separately? Would that be a problem? You would have to deal with conflicts in cpuhotplug.h. All other requirements are merged. > Thanks, > Rafael Sebastian

Re: [PATCH 11/21] ACPI: processor: Convert to hotplug state machine

On 2016-09-06 23:08:28 [+0200], Rafael J. Wysocki wrote: > This appears to be part of a series, but what if it goes in > separately? Would that be a problem? You would have to deal with conflicts in cpuhotplug.h. All other requirements are merged. > Thanks, > Rafael Sebastian

Re: [PATCH v3 5/5] gpio: pca953x: coding style fixes

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > pca953x_gpio_set_multiple() has some coding style issues that make it > harder to read. Tweak the code a bit. > > Signed-off-by: Bartosz Golaszewski > --- >  drivers/gpio/gpio-pca953x.c | 19

Re: [PATCH v3 5/5] gpio: pca953x: coding style fixes

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > pca953x_gpio_set_multiple() has some coding style issues that make it > harder to read. Tweak the code a bit. > > Signed-off-by: Bartosz Golaszewski > --- >  drivers/gpio/gpio-pca953x.c | 19 ++- >  1 file changed, 10

Re: pyc files in source dir with O=

>> Documentation/sphinx/rstFlatTable.pyc >>> $ >>> >>> This is with v4.8-rc5. >>> >>> With next-20160907, two more files appear: >>> >>> Documentation/sphinx/cdomain.pyc >>> Documentation/sphinx/load

Re: pyc files in source dir with O=

n the source tree instead of in the build tree: >>> >>> $ git ls-files -o >>> Documentation/sphinx/kernel-doc.pyc >>> Documentation/sphinx/kernel_include.pyc >>> Documentation/sphinx/rstFlatTable.pyc >>> $ >>> &

Re: [PATCH 2/6] pinctrl: sunxi: Add GR8 controller support

On Mon, Sep 05, 2016 at 08:49:55PM +0800, Chen-Yu Tsai wrote: > > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6), > > + SUNXI_FUNCTION(0x0, "gpio_in"), > > + SUNXI_FUNCTION(0x1, "gpio_out"), > > + SUNXI_FUNCTION(0x2, "lcd0"), /* D6 */ > > +

Re: [PATCH 2/6] pinctrl: sunxi: Add GR8 controller support

On Mon, Sep 05, 2016 at 08:49:55PM +0800, Chen-Yu Tsai wrote: > > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6), > > + SUNXI_FUNCTION(0x0, "gpio_in"), > > + SUNXI_FUNCTION(0x1, "gpio_out"), > > + SUNXI_FUNCTION(0x2, "lcd0"), /* D6 */ > > +

Re: [RFC PATCH v2 03/20] x86: Secure Memory Encryption (SME) build enablement

On 09/02/2016 06:03 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:35:59PM -0500, Tom Lendacky wrote: >> Provide the Kconfig support to build the SME support in the kernel. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/Kconfig |9 + >> 1 file

Re: [RFC PATCH v2 03/20] x86: Secure Memory Encryption (SME) build enablement

On 09/02/2016 06:03 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:35:59PM -0500, Tom Lendacky wrote: >> Provide the Kconfig support to build the SME support in the kernel. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/Kconfig |9 + >> 1 file changed, 9 insertions(+)

Re: [RFC PATCH v2 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)

On 09/02/2016 03:50 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:35:39PM -0500, Tom Lendacky wrote: >> This patch adds a Documenation entry to decribe the AMD Secure Memory >> Encryption (SME) feature. >> >> Signed-off-by: Tom Lendacky >> --- >>

Re: [RFC PATCH v2 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)

On 09/02/2016 03:50 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:35:39PM -0500, Tom Lendacky wrote: >> This patch adds a Documenation entry to decribe the AMD Secure Memory >> Encryption (SME) feature. >> >> Signed-off-by: Tom Lendacky >> --- >>

Re: [PATCH v3 0/5] gpio: pca953x: code refactoring

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > I'm working on converting the pca953x driver to using regmap, but > since > it's not a trivial task I figured I'd post a couple refactoring > patches > I did so far for 4.9. > > The first patch just fixes a couple coding style

Re: [PATCH v3 0/5] gpio: pca953x: code refactoring

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > I'm working on converting the pca953x driver to using regmap, but > since > it's not a trivial task I figured I'd post a couple refactoring > patches > I did so far for 4.9. > > The first patch just fixes a couple coding style

Re: [PATCH 02/21] ARM: shmobile: Convert to hotplug state machine

On 2016-09-06 20:05:37 [+0200], Geert Uytterhoeven wrote: > Hi Sebastian, Hi Geert, > Please describe why this is desirable. We have now an old and new infrastructure in place to handle hotplug notifications while a CPU goes up and/or down. We want to get rid of the old infrastructure and are

Re: [PATCH 02/21] ARM: shmobile: Convert to hotplug state machine

On 2016-09-06 20:05:37 [+0200], Geert Uytterhoeven wrote: > Hi Sebastian, Hi Geert, > Please describe why this is desirable. We have now an old and new infrastructure in place to handle hotplug notifications while a CPU goes up and/or down. We want to get rid of the old infrastructure and are

Re: [PATCH v3 4/5] gpio: pca953x: remove an unused variable

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > The chip_type variable in struct pca953x_chip is no longer required. > > Remove it. > > - chip->write_regs = chip->chip_type == PCA953X_TYPE ? > - pca953x_write_regs_16 : > -

Re: [PATCH v3 4/5] gpio: pca953x: remove an unused variable

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > The chip_type variable in struct pca953x_chip is no longer required. > > Remove it. > > - chip->write_regs = chip->chip_type == PCA953X_TYPE ? > - pca953x_write_regs_16 : > -

Re: Question on smp_mb__before_spinlock

On Wed, Sep 07, 2016 at 03:23:54PM +0200, Peter Zijlstra wrote: > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote: > > It seems okay, but why not make it a special sched-only function name > > to prevent it being used in generic code? > > > > I would not mind seeing responsibility

Re: Question on smp_mb__before_spinlock

On Wed, Sep 07, 2016 at 03:23:54PM +0200, Peter Zijlstra wrote: > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote: > > It seems okay, but why not make it a special sched-only function name > > to prevent it being used in generic code? > > > > I would not mind seeing responsibility

Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts

Hi all, may I *poke* you again? We're close to the release of 4.8, and this patch (b5c86b749 upstream) should still be reverted on mainline Ralf On 08/10/2016 10:46 PM, Arnd Bergmann wrote: > On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote: >> On Mon, Jul 18, 2016 at

Re: [PATCH net-next 0/3] r8152: configuration setting

[ CCing Oliver, who AFAIK still is the cdc_ether maintainer and should have the final word on this ] Hayes Wang writes: > Some people prefer to use ECM mode rather than vendor mode. Therefore, I add > CONFIG_RTL8152_CONFIG_VALUE in Kconfig. Then, the users could choose

Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts

Hi all, may I *poke* you again? We're close to the release of 4.8, and this patch (b5c86b749 upstream) should still be reverted on mainline Ralf On 08/10/2016 10:46 PM, Arnd Bergmann wrote: > On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote: >> On Mon, Jul 18, 2016 at

Re: [PATCH net-next 0/3] r8152: configuration setting

[ CCing Oliver, who AFAIK still is the cdc_ether maintainer and should have the final word on this ] Hayes Wang writes: > Some people prefer to use ECM mode rather than vendor mode. Therefore, I add > CONFIG_RTL8152_CONFIG_VALUE in Kconfig. Then, the users could choose the USB > configuration

Re: [PATCH v3 3/5] gpio: pca953x: refactor pca953x_read_regs()

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > Avoid the unnecessary if-else in pca953x_read_regs() by spltting the > routine into smaller, specialized functions and calling the right one > via a function pointer held in struct pca953x. > > Signed-off-by: Bartosz Golaszewski

Re: [PATCH v3 3/5] gpio: pca953x: refactor pca953x_read_regs()

On Wed, 2016-09-07 at 15:37 +0200, Bartosz Golaszewski wrote: > Avoid the unnecessary if-else in pca953x_read_regs() by spltting the > routine into smaller, specialized functions and calling the right one > via a function pointer held in struct pca953x. > > Signed-off-by: Bartosz Golaszewski >

Re: pyc files in source dir with O=

rce tree instead of in the build tree: >> >> $ git ls-files -o >> Documentation/sphinx/kernel-doc.pyc >> Documentation/sphinx/kernel_include.pyc >> Documentation/sphinx/rstFlatTable.pyc >> $ >> >> This is with v4.8-rc5. >&g

Re: pyc files in source dir with O=

-files -o >> Documentation/sphinx/kernel-doc.pyc >> Documentation/sphinx/kernel_include.pyc >> Documentation/sphinx/rstFlatTable.pyc >> $ >> >> This is with v4.8-rc5. >> >> With next-20160907, two more files appear: >> >>

Re: [PATCH] dma: qcom: Add initialization of axi and core clocks

Hi Iaroslav, Could you Cc linux-arm-msm ML next time. Cc: Stephen and linux-arm-msm Andy, Stephen probably we don't have conclusion about adding those two clocks in bam driver but do you have some better ideas? On 08/30/2016 06:42 PM, Iaroslav Gridin wrote: > From: Voker57

Re: [PATCH] dma: qcom: Add initialization of axi and core clocks

Hi Iaroslav, Could you Cc linux-arm-msm ML next time. Cc: Stephen and linux-arm-msm Andy, Stephen probably we don't have conclusion about adding those two clocks in bam driver but do you have some better ideas? On 08/30/2016 06:42 PM, Iaroslav Gridin wrote: > From: Voker57 > > These

Re: [patch 2/2] leds: add driver for Mellanox systems leds

On 09/07/2016 03:39 PM, Vadim Pasternak wrote: Hi Jacek, The patch 2/2 I sent after Dave's review. Now I have patch 1/2 and patch 2/2, produced with git format-patch -2 HEAD ... But 1/2 is re-work after your comments. Would it be OK if I produce now new patch with all fixes as [patch v1], and

Re: [patch 2/2] leds: add driver for Mellanox systems leds

On 09/07/2016 03:39 PM, Vadim Pasternak wrote: Hi Jacek, The patch 2/2 I sent after Dave's review. Now I have patch 1/2 and patch 2/2, produced with git format-patch -2 HEAD ... But 1/2 is re-work after your comments. Would it be OK if I produce now new patch with all fixes as [patch v1], and

Re: [PATCH] mfd: ucb1x00: remove NO_IRQ check

On Wed, Sep 07, 2016 at 01:48:18PM +0100, Lee Jones wrote: > On Wed, 07 Sep 2016, Russell King - ARM Linux wrote: > > > On Wed, Sep 07, 2016 at 11:27:37AM +0100, Lee Jones wrote: > > > The *only* logical reason you're making such a fuss now is because of > > > the discussion we had last week.

Re: [PATCH] mfd: ucb1x00: remove NO_IRQ check

On Wed, Sep 07, 2016 at 01:48:18PM +0100, Lee Jones wrote: > On Wed, 07 Sep 2016, Russell King - ARM Linux wrote: > > > On Wed, Sep 07, 2016 at 11:27:37AM +0100, Lee Jones wrote: > > > The *only* logical reason you're making such a fuss now is because of > > > the discussion we had last week.

Re: [PATCH 3/5] arm64: Handle TRAP_HWBRKPT for user mode as well

On Tue, Sep 06, 2016 at 05:36:18PM -0400, David Long wrote: > On 09/06/2016 12:11 PM, Catalin Marinas wrote: > > On Tue, Aug 02, 2016 at 11:00:07AM +0530, Pratyush Anand wrote: > > > --- a/arch/arm64/kernel/debug-monitors.c > > > +++ b/arch/arm64/kernel/debug-monitors.c > > > @@ -246,6 +246,8 @@

Re: [PATCH 3/5] arm64: Handle TRAP_HWBRKPT for user mode as well

On Tue, Sep 06, 2016 at 05:36:18PM -0400, David Long wrote: > On 09/06/2016 12:11 PM, Catalin Marinas wrote: > > On Tue, Aug 02, 2016 at 11:00:07AM +0530, Pratyush Anand wrote: > > > --- a/arch/arm64/kernel/debug-monitors.c > > > +++ b/arch/arm64/kernel/debug-monitors.c > > > @@ -246,6 +246,8 @@

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