Re: [PATCH] extcon: usb-gpio: Add VBUS detection support

On Tue, Sep 20, 2016 at 05:53:55PM +0300, Roger Quadros wrote: > Driver can now work with both ID and VBUS pins or either one of > them. > > There can be the following 3 cases > > 1) Both ID and VBUS GPIOs are available: > > ID = LOW -> USB_HOST active, USB inactive > ID = HIGH -> USB_HOST

Re: [PATCH] extcon: usb-gpio: Add VBUS detection support

On Tue, Sep 20, 2016 at 05:53:55PM +0300, Roger Quadros wrote: > Driver can now work with both ID and VBUS pins or either one of > them. > > There can be the following 3 cases > > 1) Both ID and VBUS GPIOs are available: > > ID = LOW -> USB_HOST active, USB inactive > ID = HIGH -> USB_HOST

Re: linux-next: build failure after merge of the rdma tree

Hi Christoph, On Tue, 27 Sep 2016 07:04:15 +0200 Christoph Hellwig wrote: > > On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote: > > Hi Doug, > > > > After merging the rdma tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > Please just

Re: linux-next: build failure after merge of the rdma tree

Hi Christoph, On Tue, 27 Sep 2016 07:04:15 +0200 Christoph Hellwig wrote: > > On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote: > > Hi Doug, > > > > After merging the rdma tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > Please just disable

RE: [v6,2/2] QE: remove PPCisms for QE

On Tue, Sep 27, 2016 at 7:12AM -0500, Scott Wood wrote: > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Tuesday, September 27, 2016 7:12 AM > To: Qiang Zhao > Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie >

RE: [v6,2/2] QE: remove PPCisms for QE

On Tue, Sep 27, 2016 at 7:12AM -0500, Scott Wood wrote: > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Tuesday, September 27, 2016 7:12 AM > To: Qiang Zhao > Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie > ; linux-kernel@vger.kernel.org >

Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

> When you need to make changes to patches that are part of a series, > you must resubmit the entire series, I imagine that will happen when the patch review time passed by a bit more as Paul Bolle requested it yesterday. > not just the things that are changes. Thanks for your reminder.

Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

> When you need to make changes to patches that are part of a series, > you must resubmit the entire series, I imagine that will happen when the patch review time passed by a bit more as Paul Bolle requested it yesterday. > not just the things that are changes. Thanks for your reminder.

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: >> Does (only) adding the >> >> pci_read_config_word(solo_dev->pdev, PCI_STATUS, ); >> >> in solo_reg_write() help? > > Yes. > I have posted a patch with this change few days ago, I thought you have > noticed it. Well, I think you haven't

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: >> Does (only) adding the >> >> pci_read_config_word(solo_dev->pdev, PCI_STATUS, ); >> >> in solo_reg_write() help? > > Yes. > I have posted a patch with this change few days ago, I thought you have > noticed it. Well, I think you haven't sent me a copy. Anyway, it

[PATCH 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM

These patches configure * the EEPROM * the LEDs (with some default triggers) * the USR1 gpio button for the OMAP5 UEVM board. H. Nikolaus Schaller (3): DT: EVM: add EEPROM DT: EVM: add LEDs DT: EVM: add USR1 button arch/arm/boot/dts/omap5-uevm.dts | 92

[PATCH 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM

These patches configure * the EEPROM * the LEDs (with some default triggers) * the USR1 gpio button for the OMAP5 UEVM board. H. Nikolaus Schaller (3): DT: EVM: add EEPROM DT: EVM: add LEDs DT: EVM: add USR1 button arch/arm/boot/dts/omap5-uevm.dts | 92

[PATCH 3/3] DT: EVM: add USR1 button

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 25 + 1 file changed, 25 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 19f5f0a..1b919f5 100644 ---

[PATCH 3/3] DT: EVM: add USR1 button

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 25 + 1 file changed, 25 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 19f5f0a..1b919f5 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++

[PATCH 1/3] DT: EVM: add EEPROM

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 36ff7c3..be659e8 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++

[PATCH 2/3] DT: EVM: add LEDs

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 60 1 file changed, 60 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index be659e8..19f5f0a 100644 ---

[PATCH 1/3] DT: EVM: add EEPROM

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 36ff7c3..be659e8 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++

[PATCH 2/3] DT: EVM: add LEDs

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 60 1 file changed, 60 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index be659e8..19f5f0a 100644 ---

Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

>> Memory was not released (as it would be expected) when one call >> of further resource reservations failed. > > This was the only thing in this series that triggered more than a, > very uninspired, "meh" on first read. Will it matter here if the function "kfree" will be called for the data

Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

>> Memory was not released (as it would be expected) when one call >> of further resource reservations failed. > > This was the only thing in this series that triggered more than a, > very uninspired, "meh" on first read. Will it matter here if the function "kfree" will be called for the data

Re: ISDN-Gigaset: Fine-tuning for three function implementations

>> Use kmalloc_array() in two functions >> Improve another size determination in gigaset_initcs() >> Delete an error message for a failed memory allocation >> Release memory in gigaset_initcs() after an allocation failure > > Which "static source code analysis" was used for that

Re: ISDN-Gigaset: Fine-tuning for three function implementations

>> Use kmalloc_array() in two functions >> Improve another size determination in gigaset_initcs() >> Delete an error message for a failed memory allocation >> Release memory in gigaset_initcs() after an allocation failure > > Which "static source code analysis" was used for that

RE: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.

-Original Message- From: Thomas Gleixner [mailto:t...@linutronix.de] Sent: Tuesday, September 27, 2016 3:01 AM To: Liav Rehana Cc: john.stu...@linaro.org; linux-kernel@vger.kernel.org; Elad Kanfi ; Noam Camus Subject: Re:

RE: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.

-Original Message- From: Thomas Gleixner [mailto:t...@linutronix.de] Sent: Tuesday, September 27, 2016 3:01 AM To: Liav Rehana Cc: john.stu...@linaro.org; linux-kernel@vger.kernel.org; Elad Kanfi ; Noam Camus Subject: Re: [PATCH] timekeeping: Change type of nsec variable to unsigned

linux-next: manual merge of the gpio tree with the arm-soc tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: arch/arm/mach-omap2/board-rx51-peripherals.c between commit: 9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900") from the arm-soc tree and commit: 9132ce450bd1 ("ARM: omap2: fix missing include") from the

linux-next: manual merge of the gpio tree with the arm-soc tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: arch/arm/mach-omap2/board-rx51-peripherals.c between commit: 9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900") from the arm-soc tree and commit: 9132ce450bd1 ("ARM: omap2: fix missing include") from the

[PATCH] Fix a issue that Alps Touchpad cursor does not work

fix Touchpad cursor does not work after touching Touchpad by 3 or more fingers. Issue reproduction procedure 1.Three or more fingers put on Touchpad. 2.release fingers from Touchpad. 3.move the cursor by one finger. 4.the cursor does not move. Cause This code does not notify multi fingers state

[PATCH] Fix a issue that Alps Touchpad cursor does not work

fix Touchpad cursor does not work after touching Touchpad by 3 or more fingers. Issue reproduction procedure 1.Three or more fingers put on Touchpad. 2.release fingers from Touchpad. 3.move the cursor by one finger. 4.the cursor does not move. Cause This code does not notify multi fingers state

Re: linux-next: build failure after merge of the rdma tree

On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote: > Hi Doug, > > After merging the rdma tree, today's linux-next build (x86_64 > allmodconfig) failed like this: Please just disable broken staging code like lustre for the linux-next builds. We had that discussion before, didn't

Re: linux-next: build failure after merge of the rdma tree

On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote: > Hi Doug, > > After merging the rdma tree, today's linux-next build (x86_64 > allmodconfig) failed like this: Please just disable broken staging code like lustre for the linux-next builds. We had that discussion before, didn't

linux-next: manual merge of the gpio tree with the i2c tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: drivers/gpio/gpio-pca953x.c between commit: 6212e1d6ed40 ("gpio: pca953x: variable 'id' was used twice") from the i2c tree and commit: e23efa30 ("gpio: pca954x: Add vcc regulator and enable it") from the gpio

linux-next: manual merge of the gpio tree with the i2c tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: drivers/gpio/gpio-pca953x.c between commit: 6212e1d6ed40 ("gpio: pca953x: variable 'id' was used twice") from the i2c tree and commit: e23efa30 ("gpio: pca954x: Add vcc regulator and enable it") from the gpio

Re: [PATCH v2 1/2] config: Add new CONFIG_PROVE_LOCKING_SMALL

Hi Babu. On Mon, Sep 26, 2016 at 03:31:37PM -0700, Babu Moger wrote: > Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc. > > This feature limits the space used for "Lock debugging: prove locking > correctness" by about 4MB. The current sparc systms have the limitation of >

Re: [PATCH v2 1/2] config: Add new CONFIG_PROVE_LOCKING_SMALL

Hi Babu. On Mon, Sep 26, 2016 at 03:31:37PM -0700, Babu Moger wrote: > Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc. > > This feature limits the space used for "Lock debugging: prove locking > correctness" by about 4MB. The current sparc systms have the limitation of >

Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

On Mon, Sep 26, 2016 at 11:44:50AM -0700, Stephen Boyd wrote: > Quoting Peter Chen (2016-09-25 20:29:27) > > On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote: > > > Quoting Peter Chen (2016-09-16 18:16:05) > > > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote: > > > > >

Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

On Mon, Sep 26, 2016 at 11:44:50AM -0700, Stephen Boyd wrote: > Quoting Peter Chen (2016-09-25 20:29:27) > > On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote: > > > Quoting Peter Chen (2016-09-16 18:16:05) > > > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote: > > > > >

Re: [PATCH v6 0/2] Add USB configuration for imx53

On Mon, Sep 26, 2016 at 01:14:18PM +0200, Fabien Lahoudere wrote: > Changes in V2: > - Patches sent to early with bad contents > Changes in V3: > - Change subject > - Split "configure imx for ULPI phy" for disable-oc code > Changes in V4: > - Fix "Change switch order"

Re: [PATCH v6 0/2] Add USB configuration for imx53

On Mon, Sep 26, 2016 at 01:14:18PM +0200, Fabien Lahoudere wrote: > Changes in V2: > - Patches sent to early with bad contents > Changes in V3: > - Change subject > - Split "configure imx for ULPI phy" for disable-oc code > Changes in V4: > - Fix "Change switch order"

Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support

Hi Ulf, On 9/23/2016 3:37 PM, Ulf Hansson wrote: [...] Is there anything else needed in msm sdhci driver so that the auto tuning is taken care of? I am not familiar with any other than sdhci-esdhc-imx which supports the SDHCI_TUNING_MODE_3. I may be wrong though. In the sdhci-esdhc-imx

Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support

Hi Ulf, On 9/23/2016 3:37 PM, Ulf Hansson wrote: [...] Is there anything else needed in msm sdhci driver so that the auto tuning is taken care of? I am not familiar with any other than sdhci-esdhc-imx which supports the SDHCI_TUNING_MODE_3. I may be wrong though. In the sdhci-esdhc-imx

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

Hello, Ping? - Sanchayan. On 16-09-19 10:41:51, Sanchayan Maity wrote: > Remove the use of DDC I2C bus bitbang to support reading of EDID > and rely on support from internal HDMI I2C master controller instead. > As a result remove the device tree property ddc-i2c-bus. > > Signed-off-by:

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

Hello, Ping? - Sanchayan. On 16-09-19 10:41:51, Sanchayan Maity wrote: > Remove the use of DDC I2C bus bitbang to support reading of EDID > and rely on support from internal HDMI I2C master controller instead. > As a result remove the device tree property ddc-i2c-bus. > > Signed-off-by:

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

Hello, Ping? - Sanchayan. On 16-09-21 16:54:38, Sanchayan Maity wrote: > Add support for Toradex Colibri iMX6 module. > > Signed-off-by: Sanchayan Maity > --- > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts |

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

Hello, Ping? - Sanchayan. On 16-09-21 16:54:38, Sanchayan Maity wrote: > Add support for Toradex Colibri iMX6 module. > > Signed-off-by: Sanchayan Maity > --- > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 >

Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework

Emilio López writes: > El 22/09/16 a las 06:43, Michael Ellerman escribió: >> Emilio López writes: >> >> Please don't include the *kernel* headers, they're really not meant to >> be used in userspace programs :) >> >>> +CFLAGS +=

Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework

Emilio López writes: > El 22/09/16 a las 06:43, Michael Ellerman escribió: >> Emilio López writes: >> >> Please don't include the *kernel* headers, they're really not meant to >> be used in userspace programs :) >> >>> +CFLAGS += -I../../../../usr/include/ >> >> That is the correct place to get

RE: [PATCH] scsi: be2iscsi: mark symbols static where possible

> -Original Message- > From: Baoyou Xie [mailto:baoyou@linaro.org] > Sent: Monday, September 26, 2016 5:31 PM > To: subbu.seethara...@broadcom.com; ketan.muka...@broadcom.com; > jitendra.bhiv...@broadcom.com; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com > Cc:

RE: [PATCH] scsi: be2iscsi: mark symbols static where possible

> -Original Message- > From: Baoyou Xie [mailto:baoyou@linaro.org] > Sent: Monday, September 26, 2016 5:31 PM > To: subbu.seethara...@broadcom.com; ketan.muka...@broadcom.com; > jitendra.bhiv...@broadcom.com; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com > Cc:

Re: [x86-tip] strange nr_cpus= boot regression

Mike Galbraith wrote: >Whew, no mythical creature infestation. Thanks, next encounter with >such an artifact should provide markedly less entertainment. Oh, no worries. Next time it'll be something else. There's no dull day with this this kernel thing ;-) -- Sent

Re: [x86-tip] strange nr_cpus= boot regression

Mike Galbraith wrote: >Whew, no mythical creature infestation. Thanks, next encounter with >such an artifact should provide markedly less entertainment. Oh, no worries. Next time it'll be something else. There's no dull day with this this kernel thing ;-) -- Sent from a small device:

Re: [PATCH 00/11] splice cleanups

On Wed, Sep 14, 2016 at 10:37:05AM +0200, Miklos Szeredi wrote: > This contains assorted cleanups in the splice area: > > - add helpers for pipe buf ops instead of directly calling them > > - page cache buf doesn't seem to need confirming (since ages) > > - generic_file_splice_read() and

Re: [PATCH 00/11] splice cleanups

On Wed, Sep 14, 2016 at 10:37:05AM +0200, Miklos Szeredi wrote: > This contains assorted cleanups in the splice area: > > - add helpers for pipe buf ops instead of directly calling them > > - page cache buf doesn't seem to need confirming (since ages) > > - generic_file_splice_read() and

linux-next: manual merge of the percpu tree with the asm-generic tree

Hi all, Today's linux-next merge of the percpu tree got a conflict in: include/asm-generic/percpu.h between commit: acbdf0e98066 ("percpu: make this_cpu_generic_read notrace") from the asm-generic tree and commit: 1b5ca1212742 ("percpu: improve generic percpu modify-return

linux-next: manual merge of the percpu tree with the asm-generic tree

Hi all, Today's linux-next merge of the percpu tree got a conflict in: include/asm-generic/percpu.h between commit: acbdf0e98066 ("percpu: make this_cpu_generic_read notrace") from the asm-generic tree and commit: 1b5ca1212742 ("percpu: improve generic percpu modify-return

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On 2016-09-26 04:07, Nikolay Borisov wrote: Not sure if that's expected behaviour or not. Why don't you sample the stacks of some of those kworker processes to see if they are all executing a parituclar piece of work. That might help you narrow down where they originate from. Cat multiple

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On 2016-09-26 04:07, Nikolay Borisov wrote: Not sure if that's expected behaviour or not. Why don't you sample the stacks of some of those kworker processes to see if they are all executing a parituclar piece of work. That might help you narrow down where they originate from. Cat multiple

[PATCH] igb: Realign bad indentation

Statements should start on tabstops. Use a single statement and test instead of multiple tests. Signed-off-by: Joe Perches --- drivers/net/ethernet/intel/igb/e1000_mac.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git

[PATCH] igb: Realign bad indentation

Statements should start on tabstops. Use a single statement and test instead of multiple tests. Signed-off-by: Joe Perches --- drivers/net/ethernet/intel/igb/e1000_mac.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git

linux-next: manual merge of the kvm-arm tree with the tip tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: arch/arm/include/asm/arch_gicv3.h between commit: 91ef84428a86 ("irqchip/gic-v3: Reset BPR during initialization") from the tip tree and commit: 3d9cd95f90b2 ("ARM: gic-v3: Work around definition of

linux-next: manual merge of the kvm-arm tree with the tip tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: arch/arm/include/asm/arch_gicv3.h between commit: 91ef84428a86 ("irqchip/gic-v3: Reset BPR during initialization") from the tip tree and commit: 3d9cd95f90b2 ("ARM: gic-v3: Work around definition of

Re: [PATCH 09/11] splice: use get_page_for_read()

On Wed, Sep 14, 2016 at 10:37:14AM +0200, Miklos Szeredi wrote: > What __generic_file_splice_read() does is get a series of uptodate pages > and put them into the pipe buffer. > > The get_page_for_read() helper can now be used to get the pages, > simplifying the code and making sure the splice(2)

Re: [PATCH 09/11] splice: use get_page_for_read()

On Wed, Sep 14, 2016 at 10:37:14AM +0200, Miklos Szeredi wrote: > What __generic_file_splice_read() does is get a series of uptodate pages > and put them into the pipe buffer. > > The get_page_for_read() helper can now be used to get the pages, > simplifying the code and making sure the splice(2)

Re: [PATCH 08/11] filemap: add get_page_for_read() helper

On Wed, Sep 14, 2016 at 10:37:13AM +0200, Miklos Szeredi wrote: > Getting the page for reading is pretty complicated. This functionality is > also duplicated between generic_file_read() generic_file_splice_read(). > > So first extract the common code from do_generic_file_read() into a > separate

Re: [PATCH 08/11] filemap: add get_page_for_read() helper

On Wed, Sep 14, 2016 at 10:37:13AM +0200, Miklos Szeredi wrote: > Getting the page for reading is pretty complicated. This functionality is > also duplicated between generic_file_read() generic_file_splice_read(). > > So first extract the common code from do_generic_file_read() into a > separate

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

On 2016년 09월 23일 01:53, bseg...@google.com wrote: > Jeehong Kim writes: > >>> Peter Zijlstra writes: >>> You forgot to Cc Ben, who gave you feedback on v1, which is rather poor style. Also, I don't see how kernel-janitors is relevant to

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

On 2016년 09월 23일 01:53, bseg...@google.com wrote: > Jeehong Kim writes: > >>> Peter Zijlstra writes: >>> You forgot to Cc Ben, who gave you feedback on v1, which is rather poor style. Also, I don't see how kernel-janitors is relevant to this patch. This is very much not a

Re: [PATCH 06/11] pipe: no need to confirm page cache buf

On Wed, Sep 14, 2016 at 10:37:11AM +0200, Miklos Szeredi wrote: > Things could happen to that page that make it not uptodate while sitting in > the pipe, but it's questionable whether we should care about that. > Checking for being uptodate in the face of such page state change is always > going

Re: [PATCH 06/11] pipe: no need to confirm page cache buf

On Wed, Sep 14, 2016 at 10:37:11AM +0200, Miklos Szeredi wrote: > Things could happen to that page that make it not uptodate while sitting in > the pipe, but it's questionable whether we should care about that. > Checking for being uptodate in the face of such page state change is always > going

Re: [PATCH 1/4] mm, compaction: more reliably increase direct compaction priority-fix

On Tuesday, September 27, 2016 12:20 AM Vlastimil Babka wrote > > When increasing the compaction priority, also reset retries. Otherwise we can > consume all retries on the lower priorities. Also pull the retries increment > into should_compact_retry() so it counts only the rounds where we

Re: [PATCH 1/4] mm, compaction: more reliably increase direct compaction priority-fix

On Tuesday, September 27, 2016 12:20 AM Vlastimil Babka wrote > > When increasing the compaction priority, also reset retries. Otherwise we can > consume all retries on the lower priorities. Also pull the retries increment > into should_compact_retry() so it counts only the rounds where we

[PATCH] i40e: Make struct i40e_stats const

Move some data to text $ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o* textdata bss dec hex filename 25012 0 32 2504461d4 drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new 228682120 32 2502061bc

[PATCH] i40e: Make struct i40e_stats const

Move some data to text $ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o* textdata bss dec hex filename 25012 0 32 2504461d4 drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new 228682120 32 2502061bc

[RFC][PATCH v2 0/2] Improve libsas hotplug

v1-v2: Fix memory allocation issue in interrupt context. Yijing Wang (2): libsas: Alloc dynamic work to avoid missing sas events libsas: Fix hotplug issue in libsas drivers/scsi/libsas/sas_ata.c | 34 ++--- drivers/scsi/libsas/sas_discover.c | 245

[RFC][PATCH v2 0/2] Improve libsas hotplug

v1-v2: Fix memory allocation issue in interrupt context. Yijing Wang (2): libsas: Alloc dynamic work to avoid missing sas events libsas: Fix hotplug issue in libsas drivers/scsi/libsas/sas_ata.c | 34 ++--- drivers/scsi/libsas/sas_discover.c | 245

[RFC][PATCH v2 1/2] libsas: Alloc dynamic work to avoid missing sas events

Now libsas hotplug work is static, LLDD driver queue the hotplug work into shost->work_q. If LLDD driver burst post lots hotplug event to libsas, the hotplug events may pending in the workqueue like shost->workq tail | PHYE_LOSS_OF_SIGNAL | PORTE_BYTES_DMAED | head In this case, if a new

[RFC][PATCH v2 1/2] libsas: Alloc dynamic work to avoid missing sas events

Now libsas hotplug work is static, LLDD driver queue the hotplug work into shost->work_q. If LLDD driver burst post lots hotplug event to libsas, the hotplug events may pending in the workqueue like shost->workq tail | PHYE_LOSS_OF_SIGNAL | PORTE_BYTES_DMAED | head In this case, if a new

Re: [PATCH] power: supply: bq24910_charger: reset first_time check

Hold off on this one. Currently reworking a patch series that won't need this change after all. On Thu, Sep 22, 2016 at 8:32 PM, Matt Ranostay wrote: > bq24190_register_reset() function needs to reset the bdi->first_time > condition every time to avoid spurious interrupts in

Re: [PATCH] power: supply: bq24910_charger: reset first_time check

Hold off on this one. Currently reworking a patch series that won't need this change after all. On Thu, Sep 22, 2016 at 8:32 PM, Matt Ranostay wrote: > bq24190_register_reset() function needs to reset the bdi->first_time > condition every time to avoid spurious interrupts in suspend/resume. > >

[RFC][PATCH v2 2/2] libsas: Fix hotplug issue in libsas

Now the libsas hotplug has some issues, Dan Williams report a similar bug here: https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html The root cause of the issues is we use one workqueue(shost->work_q) to process libsas event, and we divide a hot-on or hot-remove flow to several

[RFC][PATCH v2 2/2] libsas: Fix hotplug issue in libsas

Now the libsas hotplug has some issues, Dan Williams report a similar bug here: https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html The root cause of the issues is we use one workqueue(shost->work_q) to process libsas event, and we divide a hot-on or hot-remove flow to several

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 15:35 -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Thomas Gleixner wrote: > > Can you please provide your .config and the dmesg of a bad and a good run? > > Don't bother. I found it. > > It's a merge artifact. So git bisect pointing at the merge commit is > entirely

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 15:35 -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Thomas Gleixner wrote: > > Can you please provide your .config and the dmesg of a bad and a good run? > > Don't bother. I found it. > > It's a merge artifact. So git bisect pointing at the merge commit is > entirely

RE: Regression in 4.8 - CPU speed set very low

On 2016.09.26 18:31 Srinivas Pandruvada wrote: > On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: >> On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: >>> On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: >>> But for both we need a reproducer anyway. >> I do not have a reliable

RE: Regression in 4.8 - CPU speed set very low

On 2016.09.26 18:31 Srinivas Pandruvada wrote: > On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: >> On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: >>> On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: >>> But for both we need a reproducer anyway. >> I do not have a reliable

Re: [PATCH 00/17] clean up readlinks

On Mon, Sep 12, 2016 at 09:29:02PM +0200, Miklos Szeredi wrote: > The first patch is actually a bug fix, but I put it into this bunch for > simplicity... > > The rest are really cleanups as well as minor bugfixes that are byproducts > of the cleanups. > > This series builds on the fact that

Re: [PATCH 00/17] clean up readlinks

On Mon, Sep 12, 2016 at 09:29:02PM +0200, Miklos Szeredi wrote: > The first patch is actually a bug fix, but I put it into this bunch for > simplicity... > > The rest are really cleanups as well as minor bugfixes that are byproducts > of the cleanups. > > This series builds on the fact that

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

On Mon, Sep 26, 2016 at 02:43:17PM -0300, Marcelo Cerri wrote: > > Wouldn't be enough to provide a pair of import/export functions as the > padlock-sha driver does? I don't think that will help as ultimately you need to call the export function on the fallback and that's what requires the extra

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

On Mon, Sep 26, 2016 at 02:43:17PM -0300, Marcelo Cerri wrote: > > Wouldn't be enough to provide a pair of import/export functions as the > padlock-sha driver does? I don't think that will help as ultimately you need to call the export function on the fallback and that's what requires the extra

Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update

On Mon, Sep 26, 2016 at 10:30:56AM +0800, Johnny.Chuang wrote: > There is only one different which is adding a new empty line for coding > style. > > > if (!error) > > - error = elants_i2c_query_fw_id(ts); > > + error = error2; > > + > > if (!error) > >

Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update

On Mon, Sep 26, 2016 at 10:30:56AM +0800, Johnny.Chuang wrote: > There is only one different which is adding a new empty line for coding > style. > > > if (!error) > > - error = elants_i2c_query_fw_id(ts); > > + error = error2; > > + > > if (!error) > >

Re: Regression in 4.8 - CPU speed set very low

On 09/26/2016 08:30 PM, Srinivas Pandruvada wrote: On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote: On

Re: Regression in 4.8 - CPU speed set very low

On 09/26/2016 08:30 PM, Srinivas Pandruvada wrote: On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 12:09

Re: [PATCH] watchdog: hpwdt: add support for iLO5

On 09/26/2016 11:57 AM, Brian Boylston wrote: iLO5 will offer the same watchdog timer as previous generations, but the PCI subsystem vendor ID will be PCI_VENDOR_ID_HP_3PAR (0x1590) instead of PCI_VENDOR_ID_HP (0x103c). Add 0x1590 to the whitelist and be more specific when ignoring the

Re: [PATCH] watchdog: hpwdt: add support for iLO5

On 09/26/2016 11:57 AM, Brian Boylston wrote: iLO5 will offer the same watchdog timer as previous generations, but the PCI subsystem vendor ID will be PCI_VENDOR_ID_HP_3PAR (0x1590) instead of PCI_VENDOR_ID_HP (0x103c). Add 0x1590 to the whitelist and be more specific when ignoring the

Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages

On 2016/9/27 9:39, Jaegeuk Kim wrote: > On Tue, Sep 27, 2016 at 08:57:41AM +0800, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2016/9/27 2:33, Jaegeuk Kim wrote: >>> Hi Chao, >>> >>> On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote: From: Chao Yu In

Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages

On 2016/9/27 9:39, Jaegeuk Kim wrote: > On Tue, Sep 27, 2016 at 08:57:41AM +0800, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2016/9/27 2:33, Jaegeuk Kim wrote: >>> Hi Chao, >>> >>> On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote: From: Chao Yu In sync_node_pages, we won't check

Re: [x86-tip] strange nr_cpus= boot regression

Hi tglx, I'm sorry for the late reply. Awfully sorry that I could not do anything help. In fact, it's my fault. I should re-base my patches after the commit c291b0151585 in time. I learned a lot from it. Thank a lot, and once again my apologies. Thanks, Dou At 09/27/2016 01:36 AM, Thomas

Re: [x86-tip] strange nr_cpus= boot regression

Hi tglx, I'm sorry for the late reply. Awfully sorry that I could not do anything help. In fact, it's my fault. I should re-base my patches after the commit c291b0151585 in time. I learned a lot from it. Thank a lot, and once again my apologies. Thanks, Dou At 09/27/2016 01:36 AM, Thomas

[PATCH v2] f2fs: introduce get_checkpoint_version for cleanup

There exists almost same codes when get the value of pre_version and cur_version in function validate_checkpoint, this patch adds get_checkpoint_version to clean up redundant codes. Signed-off-by: Tiezhu Yang --- fs/f2fs/checkpoint.c | 63

[PATCH v2] f2fs: introduce get_checkpoint_version for cleanup

There exists almost same codes when get the value of pre_version and cur_version in function validate_checkpoint, this patch adds get_checkpoint_version to clean up redundant codes. Signed-off-by: Tiezhu Yang --- fs/f2fs/checkpoint.c | 63 ++-- 1

  1   2   3   4   5   6   7   8   9   10   >