Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

On Mon, Dec 18, 2017 at 12:19:21PM -0800, Kees Cook wrote: > Andrew, can you s/MAP_FIXED_SAFE/MAP_FIXED_NOREPLACE/g in the series? +1

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

On Mon, Dec 18, 2017 at 12:19:21PM -0800, Kees Cook wrote: > Andrew, can you s/MAP_FIXED_SAFE/MAP_FIXED_NOREPLACE/g in the series? +1

Re: [PATCH v5 2/3] i2c: core: add device-managed version of i2c_new_dummy

> @Wolfram: if you're ok with these changes, I think they should go > through my tree. Let me know if you agree. Frankly, adding 115 lines to i2c-core should go through my tree, I think. Still need to look at the latest revision, though. signature.asc Description: PGP signature

Re: [PATCH v5 2/3] i2c: core: add device-managed version of i2c_new_dummy

> @Wolfram: if you're ok with these changes, I think they should go > through my tree. Let me know if you agree. Frankly, adding 115 lines to i2c-core should go through my tree, I think. Still need to look at the latest revision, though. signature.asc Description: PGP signature

Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

Hi, can you see if this makes you Surface boot? I tested it on my IVB by making has_legacy_pic() return unconditional true. [0.024000] tsc: Unable to calibrate against PIT [0.025000] tsc: using HPET reference calibration [0.026000] tsc: Detected 2792.451 MHz processor --- diff

Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

Hi, can you see if this makes you Surface boot? I tested it on my IVB by making has_legacy_pic() return unconditional true. [0.024000] tsc: Unable to calibrate against PIT [0.025000] tsc: using HPET reference calibration [0.026000] tsc: Detected 2792.451 MHz processor --- diff

Re: [PATCH 4.4 000/115] 4.4.107-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.107 release. > There are 115 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 000/115] 4.4.107-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.107 release. > There are 115 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/69] 3.18.89-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.89 release. > There are 69 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/69] 3.18.89-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.89 release. > There are 69 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 000/178] 4.14.8-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.8 release. > There are 178 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 000/178] 4.14.8-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.8 release. > There are 178 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

[PATCH v5 1/6] dt: bindings: lp8860: Update bindings for lp8860

Update the lp8860 bindings to fix various issues found. Rename enable-gpio to enable-gpios, update the node name to the device name and indent the node example. Reviewed-by: Rob Herring Signed-off-by: Dan Murphy --- v5 - Update commit message to remove address

[PATCH v5 1/6] dt: bindings: lp8860: Update bindings for lp8860

Update the lp8860 bindings to fix various issues found. Rename enable-gpio to enable-gpios, update the node name to the device name and indent the node example. Reviewed-by: Rob Herring Signed-off-by: Dan Murphy --- v5 - Update commit message to remove address and size cells -

Re: [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > This patch prepares the STM32 machine for the integration of Cortex-A > based microprocessor (MPU), on top of the existing Cortex-M > microcontroller family (MCU). Since

Re: [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > This patch prepares the STM32 machine for the integration of Cortex-A > based microprocessor (MPU), on top of the existing Cortex-M > microcontroller family (MCU). Since both MCUs and MPUs are sharing > common

Re: [PATCH 4.9 000/177] 4.9.71-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.71 release. > There are 177 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 000/177] 4.9.71-stable review

On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.71 release. > There are 177 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [lustre-devel] [PATCH 04/16] staging: lustre: use wait_event_timeout() where appropriate.

Same thing as the other one, ll_statahead_thread should not contribute to load. IMO, mgc_process_log should not contribute to load in the case where it¹s waiting for an import to recover, that¹s likely to be a pretty long wait and doesn¹t really represent load. It¹s waiting for network recovery,

Re: [lustre-devel] [PATCH 04/16] staging: lustre: use wait_event_timeout() where appropriate.

Same thing as the other one, ll_statahead_thread should not contribute to load. IMO, mgc_process_log should not contribute to load in the case where it¹s waiting for an import to recover, that¹s likely to be a pretty long wait and doesn¹t really represent load. It¹s waiting for network recovery,

[PATCH v5 6/6] leds: lp8860: Various fixes to align with LED framework

Update the driver to conform with the LED framework. Use devm_led_classdev_register Destroy mutex on exit Remove dependency on CONFIG_OF in the driver and move to the Kconfig Update the MODULE_LICENSE to GPL v2 Remove setting of MAX brightness as the LED framework does this. Signed-off-by: Dan

[PATCH v5 6/6] leds: lp8860: Various fixes to align with LED framework

Update the driver to conform with the LED framework. Use devm_led_classdev_register Destroy mutex on exit Remove dependency on CONFIG_OF in the driver and move to the Kconfig Update the MODULE_LICENSE to GPL v2 Remove setting of MAX brightness as the LED framework does this. Signed-off-by: Dan

[PATCH v5 5/6] leds: lp8860: Add DT parsing to retrieve the trigger node

Add the ability to parse the DT and set the default trigger mode for the LED. Signed-off-by: Dan Murphy --- v5 - No changes v4 - No changes v3 - no changes - https://patchwork.kernel.org/patch/10093751/ v2 - no changes drivers/leds/leds-lp8860.c | 4 1 file changed, 4

[PATCH v5 5/6] leds: lp8860: Add DT parsing to retrieve the trigger node

Add the ability to parse the DT and set the default trigger mode for the LED. Signed-off-by: Dan Murphy --- v5 - No changes v4 - No changes v3 - no changes - https://patchwork.kernel.org/patch/10093751/ v2 - no changes drivers/leds/leds-lp8860.c | 4 1 file changed, 4 insertions(+)

[PATCH v5 3/6] leds: lp8860: Update the dt parsing for LED labeling

Update the DT parsing for the label node so that the label is retrieved from the device child as opposed to being part of the parent. This will align this driver with the LED binding documentation Documentation/devicetree/bindings/leds/common.txt Signed-off-by: Dan Murphy ---

[PATCH v5 4/6] dt: bindings: lp8860: Add trigger binding to the lp8860

Add a default trigger optional node to the child node. This will allow the driver to set the trigger for a backlight. Signed-off-by: Dan Murphy --- v5 - No changes v4 - No changes v3 - Removed optional and rebased - https://patchwork.kernel.org/patch/10093755/ v2 - Moved

[PATCH v5 3/6] leds: lp8860: Update the dt parsing for LED labeling

Update the DT parsing for the label node so that the label is retrieved from the device child as opposed to being part of the parent. This will align this driver with the LED binding documentation Documentation/devicetree/bindings/leds/common.txt Signed-off-by: Dan Murphy --- v5 - no changes

[PATCH v5 4/6] dt: bindings: lp8860: Add trigger binding to the lp8860

Add a default trigger optional node to the child node. This will allow the driver to set the trigger for a backlight. Signed-off-by: Dan Murphy --- v5 - No changes v4 - No changes v3 - Removed optional and rebased - https://patchwork.kernel.org/patch/10093755/ v2 - Moved binding changes to

[PATCH v5 2/6] dt: bindings: lp8860: Update DT label binding

Update the lp8860 label binding to the LED standard as documented in Documentation/devicetree/bindings/leds/common.txt Signed-off-by: Dan Murphy --- v5 - Renamed label to just white:backlight - https://patchwork.kernel.org/patch/10108361 Comment was made on patch 4

[PATCH v5 2/6] dt: bindings: lp8860: Update DT label binding

Update the lp8860 label binding to the LED standard as documented in Documentation/devicetree/bindings/leds/common.txt Signed-off-by: Dan Murphy --- v5 - Renamed label to just white:backlight - https://patchwork.kernel.org/patch/10108361 Comment was made on patch 4

Re: [PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V enlightened VMCS

Yikes! This breaks migration to/from older versions of kvm. Will you be submitting another change to handle dynamic conversion between formats? On Mon, Dec 18, 2017 at 9:17 AM, Vitaly Kuznetsov wrote: > From: Ladi Prosek > > Reorders existing fields and

Re: [PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V enlightened VMCS

Yikes! This breaks migration to/from older versions of kvm. Will you be submitting another change to handle dynamic conversion between formats? On Mon, Dec 18, 2017 at 9:17 AM, Vitaly Kuznetsov wrote: > From: Ladi Prosek > > Reorders existing fields and adds fields specific to Hyper-V. The

Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.

On Mon, Dec 18, 2017 at 08:46:09AM -0800, Doug Anderson wrote: > Hi, > > On Mon, Dec 18, 2017 at 5:31 AM, Daniel Thompson > wrote: > > I think two different values on the userspace side should always map to > > different values on the kernel side. > > This is what I

Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.

On Mon, Dec 18, 2017 at 08:46:09AM -0800, Doug Anderson wrote: > Hi, > > On Mon, Dec 18, 2017 at 5:31 AM, Daniel Thompson > wrote: > > I think two different values on the userspace side should always map to > > different values on the kernel side. > > This is what I thought originally, but I

Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: = > + > +/ { > + model = "STMicroelectronics STM32MP157C eval daughter"; > + compatible = "st,stm32mp157c-ed1", "st,stm32mp157"; > + > + chosen { > + bootargs = "earlyprintk

Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: = > + > +/ { > + model = "STMicroelectronics STM32MP157C eval daughter"; > + compatible = "st,stm32mp157c-ed1", "st,stm32mp157"; > + > + chosen { > + bootargs = "earlyprintk console=ttySTM3,115200

Re: block: oopses on 4.13.*, 4.14.* and 4.15-rc2 (bisected)

On Mon, 18 Dec 2017 15:46:36 +0800 Ming Lei wrote: > On Sat, Dec 9, 2017 at 7:27 AM, Michele Ballabio > wrote: > > On Fri, 8 Dec 2017 13:08:37 -0700 > > Jens Axboe wrote: > > > >> On 12/08/2017 08:38 AM, Michele Ballabio wrote:

Re: block: oopses on 4.13.*, 4.14.* and 4.15-rc2 (bisected)

On Mon, 18 Dec 2017 15:46:36 +0800 Ming Lei wrote: > On Sat, Dec 9, 2017 at 7:27 AM, Michele Ballabio > wrote: > > On Fri, 8 Dec 2017 13:08:37 -0700 > > Jens Axboe wrote: > > > >> On 12/08/2017 08:38 AM, Michele Ballabio wrote: > >> > Hi, > >> > kernels 4.13.*, 4.14.* 4.15-rc2 crash on

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

On Mon, Dec 18, 2017 at 11:12 AM, Michael Kerrisk (man-pages) wrote: > Hello Kees, > > I'm late to the party, and only just caught up with the fuss :-). No worries! > On 12/14/2017 12:19 AM, Kees Cook wrote: >> On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

On Mon, Dec 18, 2017 at 11:12 AM, Michael Kerrisk (man-pages) wrote: > Hello Kees, > > I'm late to the party, and only just caught up with the fuss :-). No worries! > On 12/14/2017 12:19 AM, Kees Cook wrote: >> On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis wrote: >>> Hi! You selected

Re: [PATCH v6] atmel_flexcom: Support resuming after a chip reset

On 12/12/2017 at 17:21:19 +0100, Romain Izard wrote: > The controller used by a flexcom module is configured at boot, and left > alone after this. In the suspend mode called "backup with self-refresh" > available on SAMA5D2, the chip will resume with most of its registers > reset. In this case, we

Re: [PATCH v6] atmel_flexcom: Support resuming after a chip reset

On 12/12/2017 at 17:21:19 +0100, Romain Izard wrote: > The controller used by a flexcom module is configured at boot, and left > alone after this. In the suspend mode called "backup with self-refresh" > available on SAMA5D2, the chip will resume with most of its registers > reset. In this case, we

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

On Mon, Dec 18, 2017 at 07:34:29PM +, Shaikh, Azhar wrote: > >IIUC, if CLKRUN_EN is enabled, then all the devices attached to the > >LPC bus have to support the CLKRUN protocol. My guess is that on > >some Braswell systems LPC power management is enabled but the TPM > >device doesn't have

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

On Mon, Dec 18, 2017 at 07:34:29PM +, Shaikh, Azhar wrote: > >IIUC, if CLKRUN_EN is enabled, then all the devices attached to the > >LPC bus have to support the CLKRUN protocol. My guess is that on > >some Braswell systems LPC power management is enabled but the TPM > >device doesn't have

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

On Mon, Dec 18, 2017 at 08:29:30PM +0100, Javier Martinez Canillas wrote: > My knowledge of LPC is near to non-existent so I please forgive me if I'm > wrong, > but my understanding is that it's the opposite of what you said. > > When CLKRUN_EN is SET, power management is ENABLED on the LPC bus

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

On Mon, Dec 18, 2017 at 08:29:30PM +0100, Javier Martinez Canillas wrote: > My knowledge of LPC is near to non-existent so I please forgive me if I'm > wrong, > but my understanding is that it's the opposite of what you said. > > When CLKRUN_EN is SET, power management is ENABLED on the LPC bus

Re: [PATCH] clk: check ops pointer on clock register

Hi Jerome & Stephen, On Mon, Dec 18, 2017 at 12:06 PM, Jerome Brunet wrote: > On Mon, 2017-12-18 at 11:03 -0800, Stephen Boyd wrote: >> On 12/18, Jerome Brunet wrote: >> > Nothing really prevents a provider from (trying to) register a clock >> > without providing the clock

Re: [PATCH] clk: check ops pointer on clock register

Hi Jerome & Stephen, On Mon, Dec 18, 2017 at 12:06 PM, Jerome Brunet wrote: > On Mon, 2017-12-18 at 11:03 -0800, Stephen Boyd wrote: >> On 12/18, Jerome Brunet wrote: >> > Nothing really prevents a provider from (trying to) register a clock >> > without providing the clock ops structure. >> > >>

Re: [PATCH] net: phy: xgene: disable clk on error paths

From: Alexey Khoroshilov Date: Sat, 16 Dec 2017 00:52:39 +0300 > There are several error paths in xgene_mdio_probe(), > where clk is left undisabled. The patch fixes them. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey

Re: [PATCH] net: phy: xgene: disable clk on error paths

From: Alexey Khoroshilov Date: Sat, 16 Dec 2017 00:52:39 +0300 > There are several error paths in xgene_mdio_probe(), > where clk is left undisabled. The patch fixes them. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Applied, thank

Re: [alsa-devel][PATCH v6] ASoC: TSCS42xx: Support Tempo Semiconductor's TSCS42xx audio CODECs

On Mon, Dec 18, 2017 at 09:50:48AM +, Charles Keepax wrote: > Is this unused? I apologize I missed this. These were going to be mux controls for two differential inputs. There are two inputs, but only one can be used at a time. We have never seen anybody use the second input, so I will

Re: [alsa-devel][PATCH v6] ASoC: TSCS42xx: Support Tempo Semiconductor's TSCS42xx audio CODECs

On Mon, Dec 18, 2017 at 09:50:48AM +, Charles Keepax wrote: > Is this unused? I apologize I missed this. These were going to be mux controls for two differential inputs. There are two inputs, but only one can be used at a time. We have never seen anybody use the second input, so I will

Re: [PATCH v16 3/4] hinic: Replace PCI pool old API

From: Romain Perier Date: Fri, 15 Dec 2017 20:31:22 +0100 > From: Romain Perier > > The PCI pool API is deprecated. This commit replaces the PCI pool old > API by the appropriate function with the DMA pool API. > > Signed-off-by: Romain

Re: [PATCH v16 3/4] hinic: Replace PCI pool old API

From: Romain Perier Date: Fri, 15 Dec 2017 20:31:22 +0100 > From: Romain Perier > > The PCI pool API is deprecated. This commit replaces the PCI pool old > API by the appropriate function with the DMA pool API. > > Signed-off-by: Romain Perier Acked-by: David S. Miller

Re: [PATCH v16 2/4] net: e100: Replace PCI pool old API

From: Romain Perier Date: Fri, 15 Dec 2017 20:31:21 +0100 > From: Romain Perier > > The PCI pool API is deprecated. This commit replaces the PCI pool old > API by the appropriate function with the DMA pool API. > > Signed-off-by: Romain

Re: [PATCH v16 2/4] net: e100: Replace PCI pool old API

From: Romain Perier Date: Fri, 15 Dec 2017 20:31:21 +0100 > From: Romain Perier > > The PCI pool API is deprecated. This commit replaces the PCI pool old > API by the appropriate function with the DMA pool API. > > Signed-off-by: Romain Perier > Acked-by: Peter Senna Tschudin > Acked-by:

Re: [PATCH] clk: check ops pointer on clock register

On Mon, 2017-12-18 at 11:03 -0800, Stephen Boyd wrote: > On 12/18, Jerome Brunet wrote: > > Nothing really prevents a provider from (trying to) register a clock > > without providing the clock ops structure. > > > > We do check the individual fields before using them, but not the > > structure

Re: [PATCH] clk: check ops pointer on clock register

On Mon, 2017-12-18 at 11:03 -0800, Stephen Boyd wrote: > On 12/18, Jerome Brunet wrote: > > Nothing really prevents a provider from (trying to) register a clock > > without providing the clock ops structure. > > > > We do check the individual fields before using them, but not the > > structure

Re: [PATCH] kobject: fix suppressing modalias in uevents delivered over netlink

By the way, Komali just reported another bug internally where instantiating an SR-IOV Virtual Function causes cxgb4vf to be automatically loaded, which is normal behavior. But then when she attempts to unload cxgb4vf, it simply gets reloaded again. This is with: [root@t5nic linux]# git

Re: [PATCH] kobject: fix suppressing modalias in uevents delivered over netlink

By the way, Komali just reported another bug internally where instantiating an SR-IOV Virtual Function causes cxgb4vf to be automatically loaded, which is normal behavior. But then when she attempts to unload cxgb4vf, it simply gets reloaded again. This is with: [root@t5nic linux]# git

RE: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

>-Original Message- >From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity- >ow...@vger.kernel.org] On Behalf Of Shaikh, Azhar >Sent: Monday, December 18, 2017 11:34 AM >To: Javier Martinez Canillas ; Jason Gunthorpe > >Cc: Jarkko Sakkinen

RE: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

>-Original Message- >From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity- >ow...@vger.kernel.org] On Behalf Of Shaikh, Azhar >Sent: Monday, December 18, 2017 11:34 AM >To: Javier Martinez Canillas ; Jason Gunthorpe > >Cc: Jarkko Sakkinen ; James Ettle >;

Re: [PATCH 0/4 v3] mtd: onenand: samsung: Simplify code and fix leaks in error handling paths

On Thu, 14 Dec 2017 07:03:48 +0100 Christophe JAILLET wrote: > The first patch converts 's3c_onenand_probe()' to devm_ functions. > This fixes a leak in one path (line 872). > This also free_irq which was not handled at all. ( I hope I'm correct :) ) > > The 2nd

Re: [PATCH 1/4 v3] mtd: onenand: samsung: use devm_ function to simplify code and fix some leaks

On Thu, 14 Dec 2017 07:03:49 +0100 Christophe JAILLET wrote: > Convert all error handling code in 's3c_onenand_probe()' to > resource-managed alternatives in order to simplify code. > > This fixes a resource leak if 'platform_get_resource()' fails at line 872. >

Re: [PATCH 0/4 v3] mtd: onenand: samsung: Simplify code and fix leaks in error handling paths

On Thu, 14 Dec 2017 07:03:48 +0100 Christophe JAILLET wrote: > The first patch converts 's3c_onenand_probe()' to devm_ functions. > This fixes a leak in one path (line 872). > This also free_irq which was not handled at all. ( I hope I'm correct :) ) > > The 2nd patch is about an un-handled

Re: [PATCH 1/4 v3] mtd: onenand: samsung: use devm_ function to simplify code and fix some leaks

On Thu, 14 Dec 2017 07:03:49 +0100 Christophe JAILLET wrote: > Convert all error handling code in 's3c_onenand_probe()' to > resource-managed alternatives in order to simplify code. > > This fixes a resource leak if 'platform_get_resource()' fails at line 872. > > The 'request_irq()' at line

Re: [PATCH 3/4 v3] mtd: onenand: samsung: Remove a useless include

Don't know how you generated the patch series, but this one should be 4/4 and not 3/4. On Thu, 14 Dec 2017 07:03:52 +0100 Christophe JAILLET wrote: > This include is not needed, so remove it. > > Signed-off-by: Christophe JAILLET >

Re: [PATCH 3/4 v3] mtd: onenand: samsung: Remove a useless include

Don't know how you generated the patch series, but this one should be 4/4 and not 3/4. On Thu, 14 Dec 2017 07:03:52 +0100 Christophe JAILLET wrote: > This include is not needed, so remove it. > > Signed-off-by: Christophe JAILLET > --- > Cross-compiled tested-only > > v3: new patch in the

Re: PROBLEM: NULL pointer dereference in kernel 4.14.6

On 17/12/2017 23:24, vcap...@pengaru.com wrote: On Sun, Dec 17, 2017 at 05:49:44PM +, Bronek Kozicki wrote: I just upgraded to 4.14.7 and tried to reproduce this error, this time under strace. As you can see this happens when systemctl tries to read a specific entry under /sys/fs . In

Re: PROBLEM: NULL pointer dereference in kernel 4.14.6

On 17/12/2017 23:24, vcap...@pengaru.com wrote: On Sun, Dec 17, 2017 at 05:49:44PM +, Bronek Kozicki wrote: I just upgraded to 4.14.7 and tried to reproduce this error, this time under strace. As you can see this happens when systemctl tries to read a specific entry under /sys/fs . In

Re: [PATCH] media: dvb_usb_pctv452e: module refcount changes were unbalanced

On Tue, Nov 28, 2017 at 12:33 PM, Wolfgang Rohdewald wrote: > @@ -913,6 +913,14 @@ static int pctv452e_frontend_attach(struct > dvb_usb_adapter *a) > >dev->i2c_adap); > if (!a->fe_adap[0].fe) > return

Re: [PATCH] media: dvb_usb_pctv452e: module refcount changes were unbalanced

On Tue, Nov 28, 2017 at 12:33 PM, Wolfgang Rohdewald wrote: > @@ -913,6 +913,14 @@ static int pctv452e_frontend_attach(struct > dvb_usb_adapter *a) > >dev->i2c_adap); > if (!a->fe_adap[0].fe) > return -ENODEV; > + > +

Re: [PATCH] net: arc_emac: restart stalled EMAC

From: Alexander Kochetkov Date: Fri, 15 Dec 2017 14:12:51 +0300 > Under certain conditions EMAC stop reception of incoming packets and > continuously increment R_MISS register instead of saving data into > provided buffer. The commit implement workaround for such situation.

Re: [PATCH] net: arc_emac: restart stalled EMAC

From: Alexander Kochetkov Date: Fri, 15 Dec 2017 14:12:51 +0300 > Under certain conditions EMAC stop reception of incoming packets and > continuously increment R_MISS register instead of saving data into > provided buffer. The commit implement workaround for such situation. > Then the stall

Re: [PATCH net-next] net/ncsi: Don't take any action on HNCDSC AEN

From: Samuel Mendoza-Jonas Date: Fri, 15 Dec 2017 16:16:40 +1100 > The current HNCDSC handler takes the status flag from the AEN packet and > will update or change the current channel based on this flag and the > current channel status. > > However the flag from the

Re: [PATCH net-next] net/ncsi: Don't take any action on HNCDSC AEN

From: Samuel Mendoza-Jonas Date: Fri, 15 Dec 2017 16:16:40 +1100 > The current HNCDSC handler takes the status flag from the AEN packet and > will update or change the current channel based on this flag and the > current channel status. > > However the flag from the HNCDSC packet merely

[PATCH 1/4] perf/x86/intel: pass auto-reload information to event update

From: Kan Liang There is auto-reload mechanism enabled for PEBS events in fixed period mode. When calculating the event->count, the reload value also need to be taken into account. Pass the auto-reload value and times to event update. They will be used later. No

[PATCH 1/4] perf/x86/intel: pass auto-reload information to event update

From: Kan Liang There is auto-reload mechanism enabled for PEBS events in fixed period mode. When calculating the event->count, the reload value also need to be taken into account. Pass the auto-reload value and times to event update. They will be used later. No functional change.

[PATCH 3/4] perf/x86: introduce read function for x86_pmu

From: Kan Liang Large PEBS need to be specially handled in event count read. Signed-off-by: Kan Liang --- arch/x86/events/core.c | 3 +++ arch/x86/events/perf_event.h | 1 + 2 files changed, 4 insertions(+) diff --git

[PATCH 3/4] perf/x86: introduce read function for x86_pmu

From: Kan Liang Large PEBS need to be specially handled in event count read. Signed-off-by: Kan Liang --- arch/x86/events/core.c | 3 +++ arch/x86/events/perf_event.h | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index

Re: [PATCH v4 0/9] drm/i915: Implement HDCP

On Thu, Dec 7, 2017 at 5:38 AM, Jose Abreu wrote: > Hi Sean, > > On 07-12-2017 00:00, Sean Paul wrote: >> Welcome to version 4 of the patchset. I think we're nearing the finish line >> (hopefully) now. This set addresses the review feedback from v3. I applied >> some >>

Re: [PATCH v4 0/9] drm/i915: Implement HDCP

On Thu, Dec 7, 2017 at 5:38 AM, Jose Abreu wrote: > Hi Sean, > > On 07-12-2017 00:00, Sean Paul wrote: >> Welcome to version 4 of the patchset. I think we're nearing the finish line >> (hopefully) now. This set addresses the review feedback from v3. I applied >> some >> R-b's from v3 review, and

[PATCH 4/4] perf/x86/intel: drain PEBS buffer in event read

From: Kan Liang When the PEBS interrupt threshold is larger than one, there is no way to get exact auto-reload times and value needed for event update unless flush the PEBS buffer. Drain the PEBS buffer in event read when large PEBS is enabled. For the threshold is

[PATCH 4/4] perf/x86/intel: drain PEBS buffer in event read

From: Kan Liang When the PEBS interrupt threshold is larger than one, there is no way to get exact auto-reload times and value needed for event update unless flush the PEBS buffer. Drain the PEBS buffer in event read when large PEBS is enabled. For the threshold is one, even auto-reload is

[PATCH 2/4] perf/x86/intel: fix event update for auto-reload

From: Kan Liang There is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 There is auto-reload mechanism enabled for PEBS events in fixed period mode. But

[PATCH 2/4] perf/x86/intel: fix event update for auto-reload

From: Kan Liang There is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 There is auto-reload mechanism enabled for PEBS events in fixed period mode. But the calculation of

[PATCH 0/4] bug fix mmap read in large PEBS

From: Kan Liang There is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 The bug is caused by two issues. - In x86_perf_event_update, the calculation of

[PATCH 0/4] bug fix mmap read in large PEBS

From: Kan Liang There is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 The bug is caused by two issues. - In x86_perf_event_update, the calculation of event->count does not take

Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection

On Fri, 15 Dec 2017 11:32:42 + Mark Rutland wrote: > Hi, > > On Wed, Dec 13, 2017 at 07:53:11PM +0100, Alexandre Belloni wrote: > > The clocksource and clockevent timer are probed early in the boot process. > > At that time it is difficult for linux to know whether a

Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection

On Fri, 15 Dec 2017 11:32:42 + Mark Rutland wrote: > Hi, > > On Wed, Dec 13, 2017 at 07:53:11PM +0100, Alexandre Belloni wrote: > > The clocksource and clockevent timer are probed early in the boot process. > > At that time it is difficult for linux to know whether a particular timer > >

Re: [PATCH] kobject: fix suppressing modalias in uevents delivered over netlink

/ From: Casey Leedom | Date: Friday, December 15, 2017 11:17 PST | | | From: Dmitry Torokhov | | Sent: Friday, December 15, 2017 10:53 AM | | | | Hmm, can she collect output of 'udevadm monitor -p' at the time you | | assign the adapter to the

Re: [PATCH] kobject: fix suppressing modalias in uevents delivered over netlink

/ From: Casey Leedom | Date: Friday, December 15, 2017 11:17 PST | | | From: Dmitry Torokhov | | Sent: Friday, December 15, 2017 10:53 AM | | | | Hmm, can she collect output of 'udevadm monitor -p' at the time you | | assign the adapter to the VM? | | Sure. I'll have Komali report on that.

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On 12/16/2017 6:02 PM, Knut Omang wrote: On Sat, 2017-12-16 at 12:00 -0800, santosh.shilim...@oracle.com wrote: On 12/16/17 10:24 AM, Joe Perches wrote: [...] Most of these existing messages from checkpatch should probably be inspected and corrected where possible to minimize the style

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On 12/16/2017 6:02 PM, Knut Omang wrote: On Sat, 2017-12-16 at 12:00 -0800, santosh.shilim...@oracle.com wrote: On 12/16/17 10:24 AM, Joe Perches wrote: [...] Most of these existing messages from checkpatch should probably be inspected and corrected where possible to minimize the style

Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)

From: "John W. Linville" Date: Thu, 14 Dec 2017 16:07:56 -0500 > Even without considering the ioctl problesms, the current ethtool > API seems a bit crufty. It has been a catch-all, "where else would it > go?" dumping ground for a long time, and it has accrued a number of

Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)

From: "John W. Linville" Date: Thu, 14 Dec 2017 16:07:56 -0500 > Even without considering the ioctl problesms, the current ethtool > API seems a bit crufty. It has been a catch-all, "where else would it > go?" dumping ground for a long time, and it has accrued a number of > not-entirely-related

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

On Mon, Dec 18 2017 at 2:32pm -0500, Mike Snitzer wrote: > On Mon, Dec 18 2017 at 1:52pm -0500, > Scott Bauer wrote: > > > > > > > +config DM_UN_STRIPE > > > > + tristate "Transpose IO to individual drives on a raid device" > > > > +

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

On Mon, Dec 18 2017 at 2:32pm -0500, Mike Snitzer wrote: > On Mon, Dec 18 2017 at 1:52pm -0500, > Scott Bauer wrote: > > > > > > > +config DM_UN_STRIPE > > > > + tristate "Transpose IO to individual drives on a raid device" > > > > + depends on BLK_DEV_DM > > > > +

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, 2017-12-18 at 12:36 -0500, J. Bruce Fields wrote: > On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote: > > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > > static inline bool > > > > inode_maybe_inc_iversion(struct

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, 2017-12-18 at 12:36 -0500, J. Bruce Fields wrote: > On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote: > > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > > static inline bool > > > > inode_maybe_inc_iversion(struct

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