Re: Enabling peer to peer device transactions for PCIe devices

Yes I agree it has to be started with the write transaction, according of PCIe standard all write transaction are address routed, and I agree with Logan: if in write transaction TLP the endpoint address written in header the TLP should not touch CPU, the PCIe Switch has to route it to endpoint.

Re: Enabling peer to peer device transactions for PCIe devices

Yes I agree it has to be started with the write transaction, according of PCIe standard all write transaction are address routed, and I agree with Logan: if in write transaction TLP the endpoint address written in header the TLP should not touch CPU, the PCIe Switch has to route it to endpoint.

Re: [PATCH 09/19] net: average: Kill off ACCESS_ONCE()

On Mon, 2017-10-23 at 21:07 +, Paul E. McKenney wrote: > From: Mark Rutland > > For several reasons, it is desirable to use {READ,WRITE}_ONCE() in > preference to ACCESS_ONCE(), and new code is expected to use one of the > former. So far, there's been no reason to

Re: [PATCH 09/19] net: average: Kill off ACCESS_ONCE()

On Mon, 2017-10-23 at 21:07 +, Paul E. McKenney wrote: > From: Mark Rutland > > For several reasons, it is desirable to use {READ,WRITE}_ONCE() in > preference to ACCESS_ONCE(), and new code is expected to use one of the > former. So far, there's been no reason to change most existing uses

Re: [PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

Hi Dave, On 10/24/17 at 01:31pm, Dave Young wrote: > The total memory size we get in kernel is usually slightly less than 2G with a > 2G memory module machine. The main reason is bios/firmware reserve some area > it will not export all memory as usable to Linux. > > 2G memory X86 kvm guest test

Re: [PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

Hi Dave, On 10/24/17 at 01:31pm, Dave Young wrote: > The total memory size we get in kernel is usually slightly less than 2G with a > 2G memory module machine. The main reason is bios/firmware reserve some area > it will not export all memory as usable to Linux. > > 2G memory X86 kvm guest test

[PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

Select ARCH_HAS_UBSAN_SANITIZE_ALL from arm confiuration to enable UBSAN on arm. Signed-off-by: Seung-Woo Kim --- arch/arm/Kconfig |1 + arch/arm/boot/compressed/Makefile |2 ++ arch/arm/vdso/Makefile|2 ++ 3 files changed, 5

[PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

Select ARCH_HAS_UBSAN_SANITIZE_ALL from arm confiuration to enable UBSAN on arm. Signed-off-by: Seung-Woo Kim --- arch/arm/Kconfig |1 + arch/arm/boot/compressed/Makefile |2 ++ arch/arm/vdso/Makefile|2 ++ 3 files changed, 5 insertions(+), 0

[PATCH v5 2/2] dma: sprd: Add Spreadtrum DMA driver

This patch adds the DMA controller driver for Spreadtrum SC9860 platform. Signed-off-by: Baolin Wang --- Changes since v4: - Correct lisence. - Rename SPRD_DMA_WAIT_BDONE macro to SPRD_DMA_WAIT_BDONE_OFFSET. - Optimize sprd_dma_chn_update() function. - Print

[PATCH v5 2/2] dma: sprd: Add Spreadtrum DMA driver

This patch adds the DMA controller driver for Spreadtrum SC9860 platform. Signed-off-by: Baolin Wang --- Changes since v4: - Correct lisence. - Rename SPRD_DMA_WAIT_BDONE macro to SPRD_DMA_WAIT_BDONE_OFFSET. - Optimize sprd_dma_chn_update() function. - Print warning when getting incorrect

[PATCH v5 1/2] dt-bindings: dma: Add Spreadtrum SC9860 DMA controller

This patch adds the binding documentation for Spreadtrum SC9860 DMA controller device. Signed-off-by: Baolin Wang Acked-by: Rob Herring --- Changes since v4: - No updates. Changes since v3: - No updates. Changes since v2: - No updates. Changes

[PATCH v5 1/2] dt-bindings: dma: Add Spreadtrum SC9860 DMA controller

This patch adds the binding documentation for Spreadtrum SC9860 DMA controller device. Signed-off-by: Baolin Wang Acked-by: Rob Herring --- Changes since v4: - No updates. Changes since v3: - No updates. Changes since v2: - No updates. Changes since v1: - Fix typos. ---

Re: [PATCH v5 5/6] input: Add MediaTek PMIC keys support

On Wed, Sep 27, 2017 at 06:44:07PM +0800, Chen Zhong wrote: > This patch add support to handle MediaTek PMIC MT6397/MT6323 key > interrupts including pwrkey and homekey, also add setting for > long press key shutdown behavior. > > Signed-off-by: Chen Zhong > --- >

Re: [PATCH v5 5/6] input: Add MediaTek PMIC keys support

On Wed, Sep 27, 2017 at 06:44:07PM +0800, Chen Zhong wrote: > This patch add support to handle MediaTek PMIC MT6397/MT6323 key > interrupts including pwrkey and homekey, also add setting for > long press key shutdown behavior. > > Signed-off-by: Chen Zhong > --- > drivers/input/keyboard/Kconfig

Re: [PATCH] of: Devices with pci_epf_bus_type require DMA configuration

Hi, On Monday 23 October 2017 06:35 PM, Robin Murphy wrote: > On 23/10/17 06:43, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Wednesday 11 October 2017 10:15 PM, Robin Murphy wrote: >>> On 11/10/17 09:00, Kishon Vijay Abraham I wrote: pci-epc-core.c invokes of_dma_configure in order to

Re: [PATCH] of: Devices with pci_epf_bus_type require DMA configuration

Hi, On Monday 23 October 2017 06:35 PM, Robin Murphy wrote: > On 23/10/17 06:43, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Wednesday 11 October 2017 10:15 PM, Robin Murphy wrote: >>> On 11/10/17 09:00, Kishon Vijay Abraham I wrote: pci-epc-core.c invokes of_dma_configure in order to

Re: [RFC PATCH] fs: fsnotify: account fsnotify metadata to kmemcg

On Tue, Oct 24, 2017 at 7:12 AM, Yang Shi wrote: > > > On 10/22/17 1:24 AM, Amir Goldstein wrote: >> >> On Sat, Oct 21, 2017 at 12:07 AM, Yang Shi wrote: >>> >>> >>> >>> On 10/19/17 8:14 PM, Amir Goldstein wrote: On Fri, Oct 20, 2017

Re: [RFC PATCH] fs: fsnotify: account fsnotify metadata to kmemcg

On Tue, Oct 24, 2017 at 7:12 AM, Yang Shi wrote: > > > On 10/22/17 1:24 AM, Amir Goldstein wrote: >> >> On Sat, Oct 21, 2017 at 12:07 AM, Yang Shi wrote: >>> >>> >>> >>> On 10/19/17 8:14 PM, Amir Goldstein wrote: On Fri, Oct 20, 2017 at 12:20 AM, Yang Shi wrote: > >

[PATCH 2/3] X86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

Now crashkernel=X will fail if there's not enough memory at low region (below 896M) when trying to reserve large memory size. One can use crashkernel=xM,high to reserve it at high region (>4G) but it is more convinient to improve crashkernel=X to: - First try to reserve X below 896M (for being

[PATCH 2/3] X86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

Now crashkernel=X will fail if there's not enough memory at low region (below 896M) when trying to reserve large memory size. One can use crashkernel=xM,high to reserve it at high region (>4G) but it is more convinient to improve crashkernel=X to: - First try to reserve X below 896M (for being

[PATCH 1/3] kdump: extend crashkernel=range:size to dynamically increase reservation size

crashkernel=range:size syntax allows to reserve specified size for system with total memory fall into the specified range. For example: crashkernel=2G-3G:128M,3G-:256M reserves 128M for system with memory >=2G and memory <3G, and reserves 256M for system with memory >= 3G In the above case 256M

[PATCH 1/3] kdump: extend crashkernel=range:size to dynamically increase reservation size

crashkernel=range:size syntax allows to reserve specified size for system with total memory fall into the specified range. For example: crashkernel=2G-3G:128M,3G-:256M reserves 128M for system with memory >=2G and memory <3G, and reserves 256M for system with memory >= 3G In the above case 256M

[PATCH 0/3] kdump: crashkernel parameter improvement

Hi, Here is a try to improve current crashkernel kernel parameter Patch 1/3 adds an extra functionality so that one can use like crashkernel=2G-:128M^12 to reserve 128M for 2G+ machine but also scale the size based on system memory, that means 128M + (total_mem - 128M) >> 12 Patch 2/3 is a

[PATCH 0/3] kdump: crashkernel parameter improvement

Hi, Here is a try to improve current crashkernel kernel parameter Patch 1/3 adds an extra functionality so that one can use like crashkernel=2G-:128M^12 to reserve 128M for 2G+ machine but also scale the size based on system memory, that means 128M + (total_mem - 128M) >> 12 Patch 2/3 is a

[PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

The total memory size we get in kernel is usually slightly less than 2G with a 2G memory module machine. The main reason is bios/firmware reserve some area it will not export all memory as usable to Linux. 2G memory X86 kvm guest test result of the total_mem value: UEFI boot with ovmf: 0x7ef1

[PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

The total memory size we get in kernel is usually slightly less than 2G with a 2G memory module machine. The main reason is bios/firmware reserve some area it will not export all memory as usable to Linux. 2G memory X86 kvm guest test result of the total_mem value: UEFI boot with ovmf: 0x7ef1

Re: [PATCH V8 00/14] mmc: Add Command Queue support

+ Bartlomiej [...] > So my conclusion is, let's start a as you suggested, by not completing > the request in ->done() as to maintain existing behavior. Then we can > address optimizations on top, which very likely will involve doing > changes to host drivers as well.

Re: [PATCH V8 00/14] mmc: Add Command Queue support

+ Bartlomiej [...] > So my conclusion is, let's start a as you suggested, by not completing > the request in ->done() as to maintain existing behavior. Then we can > address optimizations on top, which very likely will involve doing > changes to host drivers as well.

Re: usb/input/gtco: slab-out-of-bounds in parse_hid_report_descriptor

On Mon, Oct 23, 2017 at 01:24:23PM +0200, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+). > > parse_hid_report_descriptor() has a while (i < length) loop, which > only

Re: usb/input/gtco: slab-out-of-bounds in parse_hid_report_descriptor

On Mon, Oct 23, 2017 at 01:24:23PM +0200, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+). > > parse_hid_report_descriptor() has a while (i < length) loop, which > only

[PATCH 1/1] mpi: check for shift exponent greater than 31.

This patch check for shift exponent greater than 31, detected by UBSAN. 1)UBSAN: Undefined behaviour in lib/mpi/generic_mpih-lshift.c:57:22 shift exponent 32 is too large for 32-bit type 'long unsigned int' 2)UBSAN: Undefined behaviour in lib/mpi/generic_mpih-lshift.c:60:20 shift exponent 32 is

[PATCH 1/1] mpi: check for shift exponent greater than 31.

This patch check for shift exponent greater than 31, detected by UBSAN. 1)UBSAN: Undefined behaviour in lib/mpi/generic_mpih-lshift.c:57:22 shift exponent 32 is too large for 32-bit type 'long unsigned int' 2)UBSAN: Undefined behaviour in lib/mpi/generic_mpih-lshift.c:60:20 shift exponent 32 is

[PATCH] Input: gtco - fix potential out-of-bound access

parse_hid_report_descriptor() has a while (i < length) loop, which only guarantees that there's at least 1 byte in the buffer, but the loop body can read multiple bytes which causes out-of-bounds access. Reported-by: Andrey Konovalov Signed-off-by: Dmitry Torokhov

[PATCH] Input: gtco - fix potential out-of-bound access

parse_hid_report_descriptor() has a while (i < length) loop, which only guarantees that there's at least 1 byte in the buffer, but the loop body can read multiple bytes which causes out-of-bounds access. Reported-by: Andrey Konovalov Signed-off-by: Dmitry Torokhov ---

Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

On 10/20/17 at 01:52pm, Dave Young wrote: > Now crashkernel=X will fail if there's not enough memory at low region > (below 896M) when trying to reserve large memory size. One can use > crashkernel=xM,high to reserve it at high region (>4G) but it is more > convinient to improve crashkernel=X to:

Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

On 10/20/17 at 01:52pm, Dave Young wrote: > Now crashkernel=X will fail if there's not enough memory at low region > (below 896M) when trying to reserve large memory size. One can use > crashkernel=xM,high to reserve it at high region (>4G) but it is more > convinient to improve crashkernel=X to:

Re: [PATCH 04/12] PM / core: Add SMART_SUSPEND driver flag

On 16 October 2017 at 03:29, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Define and document a SMART_SUSPEND flag to instruct bus types and PM > domains that the system suspend callbacks provided by the driver can > cope with

Re: [PATCH 04/12] PM / core: Add SMART_SUSPEND driver flag

On 16 October 2017 at 03:29, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Define and document a SMART_SUSPEND flag to instruct bus types and PM > domains that the system suspend callbacks provided by the driver can > cope with runtime-suspended devices, so from the driver's perspective

Re: [RFC PATCH] kbuild: Allow specifying some base host CFLAGS

Hi Douglous 2017-10-20 14:06 GMT+09:00 Doug Anderson : > Hi, > > On Wed, Oct 18, 2017 at 9:45 AM, Masahiro Yamada > wrote: >> 2017-10-14 3:02 GMT+09:00 Douglas Anderson : >>> Right now there is a way to add some CFLAGS

Re: [RFC PATCH] kbuild: Allow specifying some base host CFLAGS

Hi Douglous 2017-10-20 14:06 GMT+09:00 Doug Anderson : > Hi, > > On Wed, Oct 18, 2017 at 9:45 AM, Masahiro Yamada > wrote: >> 2017-10-14 3:02 GMT+09:00 Douglas Anderson : >>> Right now there is a way to add some CFLAGS that affect target builds, >>> but no way to add CFLAGS that affect host

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

On Mon, Oct 23, 2017 at 10:10:09AM +0200, Michal Hocko wrote: > On Mon 23-10-17 14:23:09, Joonsoo Kim wrote: > > On Fri, Oct 20, 2017 at 09:02:20AM +0200, Michal Hocko wrote: > > > On Fri 20-10-17 15:50:14, Joonsoo Kim wrote: > > > > On Fri, Oct 20, 2017 at 07:59:22AM +0200, Michal Hocko wrote: >

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

On Mon, Oct 23, 2017 at 10:10:09AM +0200, Michal Hocko wrote: > On Mon 23-10-17 14:23:09, Joonsoo Kim wrote: > > On Fri, Oct 20, 2017 at 09:02:20AM +0200, Michal Hocko wrote: > > > On Fri 20-10-17 15:50:14, Joonsoo Kim wrote: > > > > On Fri, Oct 20, 2017 at 07:59:22AM +0200, Michal Hocko wrote: >

[PATCH 2/3] drivers: phy: broadcom: Add driver for Cygnus USB phy controller

Add driver for Broadcom's USB phy controller's used in Cygnus familyof SoC. Cygnus has three USB phy controller's, port 0, port 1 provides USB host functionality and port 2 can be configured for host/device role. Configuration of host/device role for port 2 is achieved based on the extcon events,

[PATCH 2/3] drivers: phy: broadcom: Add driver for Cygnus USB phy controller

Add driver for Broadcom's USB phy controller's used in Cygnus familyof SoC. Cygnus has three USB phy controller's, port 0, port 1 provides USB host functionality and port 2 can be configured for host/device role. Configuration of host/device role for port 2 is achieved based on the extcon events,

[PATCH 3/3] ARM: dts: Add dt node for Broadcom Cygnus USB phy

Add DT node for Broadcom's USB phy controller's used in Cygnus family of SoC. Signed-off-by: Raveendra Padasalagi --- arch/arm/boot/dts/bcm-cygnus.dtsi | 35 +++ 1 file changed, 35 insertions(+) diff --git

[PATCH 3/3] ARM: dts: Add dt node for Broadcom Cygnus USB phy

Add DT node for Broadcom's USB phy controller's used in Cygnus family of SoC. Signed-off-by: Raveendra Padasalagi --- arch/arm/boot/dts/bcm-cygnus.dtsi | 35 +++ 1 file changed, 35 insertions(+) diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi

[PATCH 1/3] Documentation: DT: Add Cygnus usb phy binding

Add devicetree binding document for broadcom's Cygnus SoC specific usb phy controller driver. Signed-off-by: Raveendra Padasalagi --- .../bindings/phy/brcm,cygnus-usb-phy.txt | 101 + 1 file changed, 101 insertions(+) create mode

[PATCH 0/3] Add driver for Broadcom Cygnus USB phy controller

Add driver for Broadcom's USB phy controller's used in Cygnus family of SoC and it's based on 4.14-rc3 tag. The patch set can be fetched from iproc-cyg-usb-v1 branch of https://github.com/Broadcom/arm64-linux.git Raveendra Padasalagi (3): Documentation: DT: Add Cygnus usb phy binding

[PATCH 1/3] Documentation: DT: Add Cygnus usb phy binding

Add devicetree binding document for broadcom's Cygnus SoC specific usb phy controller driver. Signed-off-by: Raveendra Padasalagi --- .../bindings/phy/brcm,cygnus-usb-phy.txt | 101 + 1 file changed, 101 insertions(+) create mode 100644

[PATCH 0/3] Add driver for Broadcom Cygnus USB phy controller

Add driver for Broadcom's USB phy controller's used in Cygnus family of SoC and it's based on 4.14-rc3 tag. The patch set can be fetched from iproc-cyg-usb-v1 branch of https://github.com/Broadcom/arm64-linux.git Raveendra Padasalagi (3): Documentation: DT: Add Cygnus usb phy binding

clock event device’s next_event

Hi Viresh and Thomas, In the functions tick_nohz_stop_sched_tick(), when expires = KTIME_MAX we are canceling the tick_sched_timer timer but we are not updating the clock event device’s next_event to KTIME_MAX. Due to that broadcast device’s next_event is not programmed properly and resulting

clock event device’s next_event

Hi Viresh and Thomas, In the functions tick_nohz_stop_sched_tick(), when expires = KTIME_MAX we are canceling the tick_sched_timer timer but we are not updating the clock event device’s next_event to KTIME_MAX. Due to that broadcast device’s next_event is not programmed properly and resulting

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Mon, Oct 23, 2017 at 09:01:46PM -0700, Alexei Starovoitov wrote: > > fwiw I had the same argument earlier: > https://lkml.org/lkml/2017/10/9/1139 Fair point on eliminating a branch. But I'd prefer something like bool cond; cond = code_that_does_something();

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Mon, Oct 23, 2017 at 09:01:46PM -0700, Alexei Starovoitov wrote: > > fwiw I had the same argument earlier: > https://lkml.org/lkml/2017/10/9/1139 Fair point on eliminating a branch. But I'd prefer something like bool cond; cond = code_that_does_something();

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

Quoting Herbert Xu : On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote: Quoting Herbert Xu : >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: >>Use BUG_ON instead of if condition followed by

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

Quoting Herbert Xu : On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote: Quoting Herbert Xu : >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: >>Use BUG_ON instead of if condition followed by BUG. >> >>This issue was detected with the help of

Re: [PATCH] kbuild: clang: fix build failures with sparse check

2017-10-21 6:09 GMT+09:00 David Lin : > We should avoid using the space character when passing arguments to > clang, because static code analysis check tool such as sparse may > misinterpret the arguments followed by spaces as build targets hence > cause the build to fail. > >

Re: [PATCH] kbuild: clang: fix build failures with sparse check

2017-10-21 6:09 GMT+09:00 David Lin : > We should avoid using the space character when passing arguments to > clang, because static code analysis check tool such as sparse may > misinterpret the arguments followed by spaces as build targets hence > cause the build to fail. > > Signed-off-by: David

Re: [RFC PATCH] fs: fsnotify: account fsnotify metadata to kmemcg

On 10/22/17 1:24 AM, Amir Goldstein wrote: On Sat, Oct 21, 2017 at 12:07 AM, Yang Shi wrote: On 10/19/17 8:14 PM, Amir Goldstein wrote: On Fri, Oct 20, 2017 at 12:20 AM, Yang Shi wrote: We observed some misbehaved user applications might

Re: [RFC PATCH] fs: fsnotify: account fsnotify metadata to kmemcg

On 10/22/17 1:24 AM, Amir Goldstein wrote: On Sat, Oct 21, 2017 at 12:07 AM, Yang Shi wrote: On 10/19/17 8:14 PM, Amir Goldstein wrote: On Fri, Oct 20, 2017 at 12:20 AM, Yang Shi wrote: We observed some misbehaved user applications might consume significant amount of fsnotify slabs

[PATCH] pinctrl: uniphier: remove eMMC hardware reset pin-mux

This is handled by the mmc-pwrseq-emmc driver, which controls an eMMC hardware reset via a GPIO line. Remove it from the function pin-mux settings. Signed-off-by: Masahiro Yamada --- drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 4 ++--

[PATCH] pinctrl: uniphier: remove eMMC hardware reset pin-mux

This is handled by the mmc-pwrseq-emmc driver, which controls an eMMC hardware reset via a GPIO line. Remove it from the function pin-mux settings. Signed-off-by: Masahiro Yamada --- drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 4 ++-- drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c |

Re: [PATCH v7 1/3] PCI: Add support for wake irq

Hi Brian, On 10/24/2017 07:02 AM, Brian Norris wrote: + PM folks Hi Jeffy, It's probably good if you send the whole thing to linux-pm@ in the future, if you're really trying to implement generic PCI/PM for device tree systems. ok On Thu, Oct 19, 2017 at 07:10:05PM +0800, Jeffy Chen wrote:

Re: [PATCH v7 1/3] PCI: Add support for wake irq

Hi Brian, On 10/24/2017 07:02 AM, Brian Norris wrote: + PM folks Hi Jeffy, It's probably good if you send the whole thing to linux-pm@ in the future, if you're really trying to implement generic PCI/PM for device tree systems. ok On Thu, Oct 19, 2017 at 07:10:05PM +0800, Jeffy Chen wrote:

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Tue, Oct 24, 2017 at 11:53:20AM +0800, Herbert Xu wrote: > On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote: > > > > Quoting Herbert Xu : > > > > >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: > > >>Use BUG_ON instead of

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Tue, Oct 24, 2017 at 11:53:20AM +0800, Herbert Xu wrote: > On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote: > > > > Quoting Herbert Xu : > > > > >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: > > >>Use BUG_ON instead of if condition followed by BUG.

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote: > > Quoting Herbert Xu : > > >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: > >>Use BUG_ON instead of if condition followed by BUG. > >> > >>This issue was detected with the

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote: > > Quoting Herbert Xu : > > >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: > >>Use BUG_ON instead of if condition followed by BUG. > >> > >>This issue was detected with the help of Coccinelle. > >> >

[PATCH] usb: gadget: f_tcm: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 703128 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/gadget/function/f_tcm.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] usb: gadget: f_tcm: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 703128 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/gadget/function/f_tcm.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

Quoting Herbert Xu : On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: Use BUG_ON instead of if condition followed by BUG. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva I

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

Quoting Herbert Xu : On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: Use BUG_ON instead of if condition followed by BUG. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva I think this patch is terrible. Why on earth is

[PATCH] usb: gadget: goku_udc: mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 145713 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/gadget/udc/goku_udc.c | 14 +- 1 file changed, 9 insertions(+), 5

[PATCH] usb: gadget: goku_udc: mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 145713 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/gadget/udc/goku_udc.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

[PATCH] usb: core: urb: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1162594 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/core/urb.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] usb: core: urb: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1162594 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/core/urb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/core/urb.c

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: > Use BUG_ON instead of if condition followed by BUG. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva I think this patch is terrible. Why on earth is

Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG

On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote: > Use BUG_ON instead of if condition followed by BUG. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva I think this patch is terrible. Why on earth is Coccinelle even warning

[PATCH] usb: phy: phy-msm-usb: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1222118 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/phy/phy-msm-usb.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] usb: phy: phy-msm-usb: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1222118 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/phy/phy-msm-usb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/phy/phy-msm-usb.c

Re: [PATCH v2 3/3] watchdog: hpwdt: add ioctl WDIOC_GETPRETIMEOUT

On 10/23/2017 03:46 PM, Jerry Hoemann wrote: Add support for WDIOC_GETPRETIMEOUT ioctl so that user applications can determine when the NMI should arrive. Signed-off-by: Jerry Hoemann I'll leave this for Wim to decide. My take is that we should not add functionality

Re: [PATCH v2 3/3] watchdog: hpwdt: add ioctl WDIOC_GETPRETIMEOUT

On 10/23/2017 03:46 PM, Jerry Hoemann wrote: Add support for WDIOC_GETPRETIMEOUT ioctl so that user applications can determine when the NMI should arrive. Signed-off-by: Jerry Hoemann I'll leave this for Wim to decide. My take is that we should not add functionality to old-style drivers and

Re: [PATCH v2 2/3] watchdog: hpwdt: Check source of NMI

On 10/23/2017 03:46 PM, Jerry Hoemann wrote: Do not claim the NMI (i.e. return NMI_DONE) if the source of the NMI isn't the iLO watchdog or debug. Signed-off-by: Jerry Hoemann Reviewed-by: Guenter Roeck --- drivers/watchdog/hpwdt.c | 10

Re: [PATCH v2 1/3] watchdog: hpwdt: SMBIOS check

On 10/23/2017 03:46 PM, Jerry Hoemann wrote: This corrects: commit cce78da76601 ("watchdog: hpwdt: Add check for UEFI bits") The test on HPE SMBIOS extension type 219 record "Misc Features" bits for UEFI support is incorrect. The definition of the Misc Features bits in the HPE SMBIOS OEM

Re: [PATCH v2 2/3] watchdog: hpwdt: Check source of NMI

On 10/23/2017 03:46 PM, Jerry Hoemann wrote: Do not claim the NMI (i.e. return NMI_DONE) if the source of the NMI isn't the iLO watchdog or debug. Signed-off-by: Jerry Hoemann Reviewed-by: Guenter Roeck --- drivers/watchdog/hpwdt.c | 10 ++ 1 file changed, 10 insertions(+)

Re: [PATCH v2 1/3] watchdog: hpwdt: SMBIOS check

On 10/23/2017 03:46 PM, Jerry Hoemann wrote: This corrects: commit cce78da76601 ("watchdog: hpwdt: Add check for UEFI bits") The test on HPE SMBIOS extension type 219 record "Misc Features" bits for UEFI support is incorrect. The definition of the Misc Features bits in the HPE SMBIOS OEM

[PATCH] usb: gadget: serial: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1350962 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/gadget/function/u_serial.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] usb: gadget: serial: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1350962 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/gadget/function/u_serial.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] usb: musb_core: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1397608 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/musb/musb_core.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] usb: musb_core: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1397608 Signed-off-by: Gustavo A. R. Silva --- drivers/usb/musb/musb_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb/musb_core.c

[PATCH] phy: phy-mtk-tphy: use auto instead of force to bypass utmi signals

When system is running, if usb2 phy is forced to bypass utmi signals, all PLL will be turned off, and it can't detect device connection anymore, so replace force mode with auto mode which can bypass utmi signals automatically if no device attached for normal flow. But keep the force mode to fix RX

[PATCH] phy: phy-mtk-tphy: use auto instead of force to bypass utmi signals

When system is running, if usb2 phy is forced to bypass utmi signals, all PLL will be turned off, and it can't detect device connection anymore, so replace force mode with auto mode which can bypass utmi signals automatically if no device attached for normal flow. But keep the force mode to fix RX

[PATCH] usb: image: mdc800: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva --- drivers/usb/image/mdc800.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/image/mdc800.c

[PATCH] usb: image: mdc800: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva --- drivers/usb/image/mdc800.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/image/mdc800.c b/drivers/usb/image/mdc800.c index

492b95e597 ("rcuperf: Set more user-friendly defaults"): WARNING: CPU: 0 PID: 1 at arch/x86/kernel/smp.c:128 native_smp_send_reschedule

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 492b95e59735998312f678d77a2d5fe20af6b0b9 Author: Paul E. McKenney AuthorDate: Fri Apr 21

492b95e597 ("rcuperf: Set more user-friendly defaults"): WARNING: CPU: 0 PID: 1 at arch/x86/kernel/smp.c:128 native_smp_send_reschedule

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 492b95e59735998312f678d77a2d5fe20af6b0b9 Author: Paul E. McKenney AuthorDate: Fri Apr 21 16:09:15 2017 -0700 Commit:

[PATCH -mm] mm, swap: Fix false error message in __swp_swapcount()

From: Ying Huang __swp_swapcount() is used in __read_swap_cache_async(). Where the invalid swap entry (offset > max) may be supplied during swap readahead. But __swp_swapcount() will print error message for these expected invalid swap entry as below, which will make the

[PATCH -mm] mm, swap: Fix false error message in __swp_swapcount()

From: Ying Huang __swp_swapcount() is used in __read_swap_cache_async(). Where the invalid swap entry (offset > max) may be supplied during swap readahead. But __swp_swapcount() will print error message for these expected invalid swap entry as below, which will make the users confusing.

ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

057 git bisect good dbf5855b11e4857696b24d9f621aaf1d4ad35dc2 # 18:04 G 10 00 0 Merge 'linux-review/SF-Markus-Elfring/gpio-adnp-Use-common-error-handling-code-in-adnp_gpio_dbg_show/20171023-043514' into devel-spot-201710231057 git bisect bad a0831a3f7f72d8ce846ffd2ff7ea73b88a59da17 # 1

ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

Markus-Elfring/gpio-adnp-Use-common-error-handling-code-in-adnp_gpio_dbg_show/20171023-043514' into devel-spot-201710231057 git bisect bad a0831a3f7f72d8ce846ffd2ff7ea73b88a59da17 # 18:42 B 0 11 24 0 Merge 'linux-review/SF-Markus-Elfring/dmaengine-ioat-Use-common-error-handlin

  1   2   3   4   5   6   7   8   9   10   >