Re: [PATCH v2] mm/swap.c: make functions and their kernel-doc agree

On Tue, Jan 30, 2018 at 01:34:00PM +0100, Michal Hocko wrote: > On Mon 29-01-18 16:43:55, Randy Dunlap wrote: > > - for function pagevec_lookup_entries(), change the function parameter > > name from nr_pages to nr_entries since that is more descriptive of > > what the parameter actually is and

Re: [PATCH v2] mm/swap.c: make functions and their kernel-doc agree

On Tue, Jan 30, 2018 at 01:34:00PM +0100, Michal Hocko wrote: > On Mon 29-01-18 16:43:55, Randy Dunlap wrote: > > - for function pagevec_lookup_entries(), change the function parameter > > name from nr_pages to nr_entries since that is more descriptive of > > what the parameter actually is and

Re: [RFC] mm/migrate: Add new migration reason MR_HUGETLB

On Wed 31-01-18 07:55:05, Anshuman Khandual wrote: > On 01/30/2018 01:29 PM, Michal Hocko wrote: > > On Tue 30-01-18 08:37:14, Anshuman Khandual wrote: > >> alloc_contig_range() initiates compaction and eventual migration for > >> the purpose of either CMA or HugeTLB allocation. At present, reason

Re: [RFC] mm/migrate: Add new migration reason MR_HUGETLB

On Wed 31-01-18 07:55:05, Anshuman Khandual wrote: > On 01/30/2018 01:29 PM, Michal Hocko wrote: > > On Tue 30-01-18 08:37:14, Anshuman Khandual wrote: > >> alloc_contig_range() initiates compaction and eventual migration for > >> the purpose of either CMA or HugeTLB allocation. At present, reason

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

On Wed, 31 Jan 2018, Meelis Roos wrote: > > > Your supply of vintage hardware is amazing. > > :-) > > > Does the patch below fix the issue for you? > > CC kernel/irq/autoprobe.o > kernel/irq/autoprobe.c: In function ‘probe_irq_on’: > kernel/irq/autoprobe.c:74:8: error: void value not

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

On Wed, 31 Jan 2018, Meelis Roos wrote: > > > Your supply of vintage hardware is amazing. > > :-) > > > Does the patch below fix the issue for you? > > CC kernel/irq/autoprobe.o > kernel/irq/autoprobe.c: In function ‘probe_irq_on’: > kernel/irq/autoprobe.c:74:8: error: void value not

[PATCH] powerpc/epapr: Move register keyword at the beginning of declaration

Fix warning for all register unsigned long (0,3-12) that appear during W=1 compilation: ./arch/powerpc/include/asm/epapr_hcalls.h:479:2: warning: ‘register’ is not at beginning of declaration [-Wold-style-declaration] unsigned long register r[\d] asm("r[\d]"); Signed-off-by: Mathieu Malaterre

[PATCH] powerpc/epapr: Move register keyword at the beginning of declaration

Fix warning for all register unsigned long (0,3-12) that appear during W=1 compilation: ./arch/powerpc/include/asm/epapr_hcalls.h:479:2: warning: ‘register’ is not at beginning of declaration [-Wold-style-declaration] unsigned long register r[\d] asm("r[\d]"); Signed-off-by: Mathieu Malaterre

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Rob, On Wed, Jan 31, 2018 at 2:05 AM, Rob Herring wrote: > On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote: >> From: Tomasz Figa >> >> Current code relies on master driver enabling necessary clocks before >> IOMMU is accessed, however there are

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Rob, On Wed, Jan 31, 2018 at 2:05 AM, Rob Herring wrote: > On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote: >> From: Tomasz Figa >> >> Current code relies on master driver enabling necessary clocks before >> IOMMU is accessed, however there are cases when the IOMMU should be >>

Re: [RFC PATCH 0/8] [media] Request API, take three

On 01/30/2018 07:31 AM, Alexandre Courbot wrote: > Hi Hans, > > On Mon, Jan 29, 2018 at 8:21 PM, Hans Verkuil wrote: >> On 01/26/2018 07:02 AM, Alexandre Courbot wrote: >>> Howdy. Here is your bi-weekly request API redesign! ;) >>> >>> Again, this is a simple version that

Re: [RFC PATCH 0/8] [media] Request API, take three

On 01/30/2018 07:31 AM, Alexandre Courbot wrote: > Hi Hans, > > On Mon, Jan 29, 2018 at 8:21 PM, Hans Verkuil wrote: >> On 01/26/2018 07:02 AM, Alexandre Courbot wrote: >>> Howdy. Here is your bi-weekly request API redesign! ;) >>> >>> Again, this is a simple version that only implements the

Re: [PATCH v2] MIPS: fix incorrect mem=X@Y handling

Hi Marcin, Since it's been a week, could you confirm the patch is ok as-is or do you think some comment(s) from James should be incorporated ? On Tue, Jan 23, 2018 at 3:17 PM, James Hogan wrote: > On Thu, Dec 21, 2017 at 10:00:59PM +0100, Mathieu Malaterre wrote: >> From:

Re: [PATCH v2] MIPS: fix incorrect mem=X@Y handling

Hi Marcin, Since it's been a week, could you confirm the patch is ok as-is or do you think some comment(s) from James should be incorporated ? On Tue, Jan 23, 2018 at 3:17 PM, James Hogan wrote: > On Thu, Dec 21, 2017 at 10:00:59PM +0100, Mathieu Malaterre wrote: >> From: Marcin Nowakowski >>

[PATCH v2 2/5] clk: mediatek: modify MT7622 audsys to adapt MFD device

As the new MFD parent is in place, switch probing method to adapt it. Signed-off-by: Ryder Lee --- drivers/clk/mediatek/clk-mt7622-aud.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c

[PATCH v2 2/5] clk: mediatek: modify MT7622 audsys to adapt MFD device

As the new MFD parent is in place, switch probing method to adapt it. Signed-off-by: Ryder Lee --- drivers/clk/mediatek/clk-mt7622-aud.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c b/drivers/clk/mediatek/clk-mt7622-aud.c index

[PATCH v2 0/5] add MFD support for MediaTek audio subsystem

Hi, This is the 2nd version of the patch sets which modify clock driver to adapt audio subsystem. I still keeping 'simple-mfd' in the binding for discussion. Rob, let me know if there is any problem with this. changes since v2: - Drop useless changes in clk-mt7622-aud.c. - Revise binding

[PATCH v2 0/5] add MFD support for MediaTek audio subsystem

Hi, This is the 2nd version of the patch sets which modify clock driver to adapt audio subsystem. I still keeping 'simple-mfd' in the binding for discussion. Rob, let me know if there is any problem with this. changes since v2: - Drop useless changes in clk-mt7622-aud.c. - Revise binding

[PATCH v2 1/5] clk: mediatek: update missing clock data for MT7622 audsys

Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys. Signed-off-by: Ryder Lee --- drivers/clk/mediatek/clk-mt7622-aud.c | 1 + include/dt-bindings/clock/mt7622-clk.h | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v2 1/5] clk: mediatek: update missing clock data for MT7622 audsys

Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys. Signed-off-by: Ryder Lee --- drivers/clk/mediatek/clk-mt7622-aud.c | 1 + include/dt-bindings/clock/mt7622-clk.h | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c

[PATCH v4] Fix loading of module radeonfb on PowerMac

When the linux kernel is build with (typical kernel ship with Debian installer): CONFIG_FB_OF=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_FB_RADEON=m The offb driver takes precedence over module radeonfb. It is then impossible to load the module, error reported is: [ 96.551486] radeonfb

[PATCH v4] Fix loading of module radeonfb on PowerMac

When the linux kernel is build with (typical kernel ship with Debian installer): CONFIG_FB_OF=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_FB_RADEON=m The offb driver takes precedence over module radeonfb. It is then impossible to load the module, error reported is: [ 96.551486] radeonfb

[PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device

As the MediaTek audio hardware block that expose functionalities that are handled by separate subsystems in the kernel, and there are registers that are shared between related drivers. Switch the current device to an MFD device, add more descriptions about the subsystem and modify example

[PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device

As the MediaTek audio hardware block that expose functionalities that are handled by separate subsystems in the kernel, and there are registers that are shared between related drivers. Switch the current device to an MFD device, add more descriptions about the subsystem and modify example

[PATCH v2 3/5] clk: mediatek: add audsys support for MT2701

Add clock driver support for MT2701 audsys. Signed-off-by: Ryder Lee --- drivers/clk/mediatek/Kconfig | 6 ++ drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt2701-aud.c | 175 ++ 3 files changed, 182

[PATCH v2 3/5] clk: mediatek: add audsys support for MT2701

Add clock driver support for MT2701 audsys. Signed-off-by: Ryder Lee --- drivers/clk/mediatek/Kconfig | 6 ++ drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt2701-aud.c | 175 ++ 3 files changed, 182 insertions(+) create mode

[PATCH v2 5/5] arm: dts: mediatek: add audio-subsystem node for both MT2701 and MT7623

Add audio-subsystem node and its clock support for both MT2701/MT7623. Then modify afe node to adapt it. Signed-off-by: Ryder Lee --- arch/arm/boot/dts/mt2701.dtsi | 192 - arch/arm/boot/dts/mt7623.dtsi | 193

[PATCH v2 5/5] arm: dts: mediatek: add audio-subsystem node for both MT2701 and MT7623

Add audio-subsystem node and its clock support for both MT2701/MT7623. Then modify afe node to adapt it. Signed-off-by: Ryder Lee --- arch/arm/boot/dts/mt2701.dtsi | 192 - arch/arm/boot/dts/mt7623.dtsi | 193 +- 2

Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi Liviu, On Wed, Jan 31, 2018 at 03:08:08AM +, Liviu Dudau wrote: > On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote: > > Hi Maxime, > > > > On Fri, 26 Jan 2018 09:46:58 +0800 > > Yong wrote: > > > > > Hi Maxime, > > > > > > Do you have any experience in

Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi Liviu, On Wed, Jan 31, 2018 at 03:08:08AM +, Liviu Dudau wrote: > On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote: > > Hi Maxime, > > > > On Fri, 26 Jan 2018 09:46:58 +0800 > > Yong wrote: > > > > > Hi Maxime, > > > > > > Do you have any experience in solving this problem? > > >

[PATCH 2/2] dt-bindings: PCI: MediaTek: Correct the interrupt-map properties

Move the interrupt-map properties from the child nodes to the root node and update each entry accordingly. Signed-off-by: Ryder Lee --- .../devicetree/bindings/pci/mediatek-pcie.txt | 28 -- 1 file changed, 15 insertions(+), 13 deletions(-) diff

[PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

A root complex usually consist of a host bridge and multiple P2P bridges, and someone may express that in the form of a root node with many subnodes and list all four interrupts for each slot (child node) in the root node like this: pcie-controller { ...

[PATCH 2/2] dt-bindings: PCI: MediaTek: Correct the interrupt-map properties

Move the interrupt-map properties from the child nodes to the root node and update each entry accordingly. Signed-off-by: Ryder Lee --- .../devicetree/bindings/pci/mediatek-pcie.txt | 28 -- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git

[PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

A root complex usually consist of a host bridge and multiple P2P bridges, and someone may express that in the form of a root node with many subnodes and list all four interrupts for each slot (child node) in the root node like this: pcie-controller { ...

RE: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

Hi, Can you elaborate how this can even happen? Isn't the interrupt aggregation capability should attend for those cases? Thanks, Avri > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Asutosh Das > Sent: Tuesday,

RE: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

Hi, Can you elaborate how this can even happen? Isn't the interrupt aggregation capability should attend for those cases? Thanks, Avri > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Asutosh Das > Sent: Tuesday,

Re: [PATCH v6 4/6] media: i2c: Add TDA1997x HDMI receiver driver

On 01/31/2018 05:51 AM, Tim Harvey wrote: > On Mon, Jan 29, 2018 at 4:00 AM, Hans Verkuil wrote: >> On 01/25/2018 05:15 PM, Tim Harvey wrote: > Hmm. This receiver supports multiple output formats, but you advertise only one. That looks wrong. If nothing

Re: Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

Hi, Vinod On Wed, 2018-01-31 at 13:04 +0530, Vinod Koul wrote: > On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote: > > > > Existing option noverify disables both random src/dst address > > offset > > setup and data verification. Sometimes, we need to control random > > src/dst

Re: [PATCH v6 4/6] media: i2c: Add TDA1997x HDMI receiver driver

On 01/31/2018 05:51 AM, Tim Harvey wrote: > On Mon, Jan 29, 2018 at 4:00 AM, Hans Verkuil wrote: >> On 01/25/2018 05:15 PM, Tim Harvey wrote: > Hmm. This receiver supports multiple output formats, but you advertise only one. That looks wrong. If nothing else, you should be

Re: Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

Hi, Vinod On Wed, 2018-01-31 at 13:04 +0530, Vinod Koul wrote: > On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote: > > > > Existing option noverify disables both random src/dst address > > offset > > setup and data verification. Sometimes, we need to control random > > src/dst

Re: [PATCH 4.14 00/71] 4.14.16-stable review

> This is the start of the stable review cycle for the 4.14.16 release. > There are 71 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. The "futex Fix OWNER_DEAD fixup" patch still isn't in ?

Re: [PATCH 7/8] Input: mms114 - add SPDX identifier

Hi Andy, On Wed, Jan 31, 2018 at 03:07:26PM +0900, Andi Shyti wrote: > Hi Dmitry, > > > > -/* > > > - * Copyright (C) 2012 Samsung Electronics Co.Ltd > > > - * Author: Joonyoung Shim > > > - * > > > - * This program is free software; you can redistribute it and/or

Re: [PATCH 4.14 00/71] 4.14.16-stable review

> This is the start of the stable review cycle for the 4.14.16 release. > There are 71 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. The "futex Fix OWNER_DEAD fixup" patch still isn't in ?

Re: [PATCH 7/8] Input: mms114 - add SPDX identifier

Hi Andy, On Wed, Jan 31, 2018 at 03:07:26PM +0900, Andi Shyti wrote: > Hi Dmitry, > > > > -/* > > > - * Copyright (C) 2012 Samsung Electronics Co.Ltd > > > - * Author: Joonyoung Shim > > > - * > > > - * This program is free software; you can redistribute it and/or modify > > > - * it under the

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

On 2018/01/30 11:46, Alexander Duyck wrote: > On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier wrote: > > It was reported that emulated e1000e devices in vmware esxi 6.5 Build > > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver > > overrun interrupt

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

On 2018/01/30 11:46, Alexander Duyck wrote: > On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier wrote: > > It was reported that emulated e1000e devices in vmware esxi 6.5 Build > > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver > > overrun interrupt bursts",

Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote: > Existing option noverify disables both random src/dst address offset > setup and data verification. Sometimes, we need to control random > src/dst address setup and verification separately, such as disabling > random to make sure

Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote: > Existing option noverify disables both random src/dst address offset > setup and data verification. Sometimes, we need to control random > src/dst address setup and verification separately, such as disabling > random to make sure

[PATCH v21 4/4] soc: mediatek: Add Mediatek CMDQ helper

From: "hs.l...@mediatek.com" Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code. Signed-off-by: Houlong Wei Signed-off-by: HS Liao --- drivers/soc/mediatek/Kconfig | 12 ++

[PATCH v21 4/4] soc: mediatek: Add Mediatek CMDQ helper

From: "hs.l...@mediatek.com" Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code. Signed-off-by: Houlong Wei Signed-off-by: HS Liao --- drivers/soc/mediatek/Kconfig | 12 ++ drivers/soc/mediatek/Makefile |1 +

[PATCH v21 3/4] arm64: dts: mt8173: Add GCE node

From: "hs.l...@mediatek.com" This patch adds the device node of the GCE hardware for CMDQ module. Signed-off-by: Houlong Wei Signed-off-by: HS Liao --- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++ 1 file

[PATCH v21 3/4] arm64: dts: mt8173: Add GCE node

From: "hs.l...@mediatek.com" This patch adds the device node of the GCE hardware for CMDQ module. Signed-off-by: Houlong Wei Signed-off-by: HS Liao --- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH v21 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

From: "hs.l...@mediatek.com" This patch is first version of Mediatek Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE)

[PATCH v21 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

From: "hs.l...@mediatek.com" This patch is first version of Mediatek Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this

Re: [PATCH v2 2/2] ARM: dts: imx25-pinfunc: Always set SION for eSDHC CMD

Hello Benoît, On Wed, Jan 31, 2018 at 01:05:14AM +0100, Benoît Thébaudeau wrote: > The eSDHC does not work properly if the SION bit is not set for the > bidirectional CMD signal, whatever the eSDHC instance and the selected > pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do >

Re: [PATCH v2 2/2] ARM: dts: imx25-pinfunc: Always set SION for eSDHC CMD

Hello Benoît, On Wed, Jan 31, 2018 at 01:05:14AM +0100, Benoît Thébaudeau wrote: > The eSDHC does not work properly if the SION bit is not set for the > bidirectional CMD signal, whatever the eSDHC instance and the selected > pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do >

[PATCH v21 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

From: "hs.l...@mediatek.com" This adds documentation for the MediaTek Global Command Engine (GCE) unit found in MT8173 SoCs. Signed-off-by: Houlong Wei Signed-off-by: HS Liao Acked-by: Rob Herring ---

[PATCH v21 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

From: "hs.l...@mediatek.com" This adds documentation for the MediaTek Global Command Engine (GCE) unit found in MT8173 SoCs. Signed-off-by: Houlong Wei Signed-off-by: HS Liao Acked-by: Rob Herring --- .../devicetree/bindings/mailbox/mtk-gce.txt| 43 1 file

[PATCH v21 0/4] Mediatek MT8173 CMDQ support

Hi, This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this requirement. Changes since v20: -rebase to

Re: [PATCH v6 0/4] x86, kasan: add KASAN checks to atomic operations

* Will Deacon wrote: > Hi Dmitry, > > On Mon, Jan 29, 2018 at 06:26:03PM +0100, Dmitry Vyukov wrote: > > KASAN uses compiler instrumentation to intercept all memory accesses. > > But it does not see memory accesses done in assembly code. > > One notable user of assembly

[PATCH v21 0/4] Mediatek MT8173 CMDQ support

Hi, This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this requirement. Changes since v20: -rebase to

Re: [PATCH v6 0/4] x86, kasan: add KASAN checks to atomic operations

* Will Deacon wrote: > Hi Dmitry, > > On Mon, Jan 29, 2018 at 06:26:03PM +0100, Dmitry Vyukov wrote: > > KASAN uses compiler instrumentation to intercept all memory accesses. > > But it does not see memory accesses done in assembly code. > > One notable user of assembly code is atomic

Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi Thierry, On Tue, Jan 30, 2018 at 11:01:50AM +0100, Thierry Reding wrote: > On Tue, Jan 30, 2018 at 10:59:16AM +0100, Thierry Reding wrote: > > On Tue, Jan 30, 2018 at 10:24:48AM +0100, Arnd Bergmann wrote: > > > On Tue, Jan 30, 2018 at 8:54 AM, Maxime Ripard > > >

Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi Thierry, On Tue, Jan 30, 2018 at 11:01:50AM +0100, Thierry Reding wrote: > On Tue, Jan 30, 2018 at 10:59:16AM +0100, Thierry Reding wrote: > > On Tue, Jan 30, 2018 at 10:24:48AM +0100, Arnd Bergmann wrote: > > > On Tue, Jan 30, 2018 at 8:54 AM, Maxime Ripard > > > wrote: > > > > On Mon, Jan

Re: WARNING in refcount_inc (2)

On Tue, Dec 19, 2017 at 11:26:01AM -0800, syzbot wrote: > syzkaller has found reproducer for the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw

Re: WARNING in refcount_inc (2)

On Tue, Dec 19, 2017 at 11:26:01AM -0800, syzbot wrote: > syzkaller has found reproducer for the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw

Re: [PATCH v2 1/2] ARM: dts: imx25-pinfunc: Use consistent naming for eSDHC

Hello, On Wed, Jan 31, 2018 at 01:05:13AM +0100, Benoît Thébaudeau wrote: > This file had several naming inconsistencies for eSDHC: > - the instances were named sometimes SDn, sometimes SDHCn, whereas they >are named ESDHCn in the reference manual, e.g.: > MX25_PAD_SD1_CMD__SD1_CMD >

Re: [PATCH v2 1/2] ARM: dts: imx25-pinfunc: Use consistent naming for eSDHC

Hello, On Wed, Jan 31, 2018 at 01:05:13AM +0100, Benoît Thébaudeau wrote: > This file had several naming inconsistencies for eSDHC: > - the instances were named sometimes SDn, sometimes SDHCn, whereas they >are named ESDHCn in the reference manual, e.g.: > MX25_PAD_SD1_CMD__SD1_CMD >

[PATCH net] e1000e: Remove Other from EIAC.

It was reported that emulated e1000e devices in vmware esxi 6.5 Build 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts", v4.15-rc1). Some tracing shows that after e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other() on

[PATCH net] e1000e: Remove Other from EIAC.

It was reported that emulated e1000e devices in vmware esxi 6.5 Build 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts", v4.15-rc1). Some tracing shows that after e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other() on

Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free

On Tue, Jan 30, 2018 at 03:03:50PM -0800, Eric Biggers wrote: > On Fri, Dec 22, 2017 at 01:31:26PM +0800, Xin Long wrote: > > On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner > > wrote: > > > On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote: > > > > > >

Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free

On Tue, Jan 30, 2018 at 03:03:50PM -0800, Eric Biggers wrote: > On Fri, Dec 22, 2017 at 01:31:26PM +0800, Xin Long wrote: > > On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner > > wrote: > > > On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote: > > > > > > from the log: > > > [

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

> > Your supply of vintage hardware is amazing. :-) > Does the patch below fix the issue for you? CC kernel/irq/autoprobe.o kernel/irq/autoprobe.c: In function ‘probe_irq_on’: kernel/irq/autoprobe.c:74:8: error: void value not ignored as it ought to be if

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

> > Your supply of vintage hardware is amazing. :-) > Does the patch below fix the issue for you? CC kernel/irq/autoprobe.o kernel/irq/autoprobe.c: In function ‘probe_irq_on’: kernel/irq/autoprobe.c:74:8: error: void value not ignored as it ought to be if

Re: [PATCH] Documentation/process: kernel maintainer PGP guide

On Tue, 30 Jan 2018, Konstantin Ryabitsev wrote: > This guide is an adapted version of the more general "Protecting Code > Integrity" guide written and maintained by The Linux Foundation IT for > use with open-source projects. It provides the oft-lacking guidance

Re: [PATCH] Documentation/process: kernel maintainer PGP guide

On Tue, 30 Jan 2018, Konstantin Ryabitsev wrote: > This guide is an adapted version of the more general "Protecting Code > Integrity" guide written and maintained by The Linux Foundation IT for > use with open-source projects. It provides the oft-lacking guidance on > the following topics: > > -

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Hi Roger, I think this patch isn't need at all. You can directly read total_swap_pages variable in TTM. See the comment: /* protected with swap_lock. reading in vm_swap_full() doesn't need lock */ long total_swap_pages; there are many places using it directly, you just couldn't change its

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Hi Roger, I think this patch isn't need at all. You can directly read total_swap_pages variable in TTM. See the comment: /* protected with swap_lock. reading in vm_swap_full() doesn't need lock */ long total_swap_pages; there are many places using it directly, you just couldn't change its

Re: [PATCH 2/2] f2fs: support {d,id,did,x}node checksum

On 2018/1/31 10:02, Jaegeuk Kim wrote: > What if we want to add more entries in addition to node_checksum? Do we have > to add a new feature flag at every time? How about adding a layout value > instead Hmm.. for previous implementation, IMO, we'd better add a new feature flag at every time,

Re: [PATCH 2/2] f2fs: support {d,id,did,x}node checksum

On 2018/1/31 10:02, Jaegeuk Kim wrote: > What if we want to add more entries in addition to node_checksum? Do we have > to add a new feature flag at every time? How about adding a layout value > instead Hmm.. for previous implementation, IMO, we'd better add a new feature flag at every time,

[PATCH] binder: check for binder_thread allocation failure in binder_poll()

From: Eric Biggers If the kzalloc() in binder_get_thread() fails, binder_poll() dereferences the resulting NULL pointer. Fix it by returning POLLERR if the memory allocation failed. This bug was found by syzkaller using fault injection. Reported-by: syzbot

[PATCH] binder: check for binder_thread allocation failure in binder_poll()

From: Eric Biggers If the kzalloc() in binder_get_thread() fails, binder_poll() dereferences the resulting NULL pointer. Fix it by returning POLLERR if the memory allocation failed. This bug was found by syzkaller using fault injection. Reported-by: syzbot Fixes: 457b9a6f09f0 ("Staging:

Re: [PATCH v11 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

* Ram Pai wrote: > This patch series provides arch-neutral enhancements to > enable memory-keys on new architecutes, and the corresponding > changes in x86 and powerpc specific code to support that. > > a) Provides ability to support upto 32 keys. PowerPC > can

Re: [PATCH v11 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

* Ram Pai wrote: > This patch series provides arch-neutral enhancements to > enable memory-keys on new architecutes, and the corresponding > changes in x86 and powerpc specific code to support that. > > a) Provides ability to support upto 32 keys. PowerPC > can handle 32 keys and hence

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Tue, Jan 30, 2018 at 02:39:45PM -0800, tip-bot for Tim Chen wrote: > Commit-ID: 18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 > Gitweb: > https://git.kernel.org/tip/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 > Author: Tim Chen > AuthorDate: Mon, 29 Jan 2018

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Tue, Jan 30, 2018 at 02:39:45PM -0800, tip-bot for Tim Chen wrote: > Commit-ID: 18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 > Gitweb: > https://git.kernel.org/tip/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 > Author: Tim Chen > AuthorDate: Mon, 29 Jan 2018 22:04:47 + > Committer:

Re: [PATCH 1/8] thermal/drivers/cpu_cooling: Fixup the header and copyright

On 31/01/2018 06:17, Viresh Kumar wrote: > On 23-01-18, 16:34, Daniel Lezcano wrote: >> The copyright format does not conform to the format requested by >> Linaro: https://wiki.linaro.org/Copyright >> >> Fix it. >> >> Signed-off-by: Daniel Lezcano >> --- >>

Re: [PATCH 1/8] thermal/drivers/cpu_cooling: Fixup the header and copyright

On 31/01/2018 06:17, Viresh Kumar wrote: > On 23-01-18, 16:34, Daniel Lezcano wrote: >> The copyright format does not conform to the format requested by >> Linaro: https://wiki.linaro.org/Copyright >> >> Fix it. >> >> Signed-off-by: Daniel Lezcano >> --- >> drivers/thermal/cpu_cooling.c | 6

Re: BUG: unable to handle kernel NULL pointer dereference in binder_poll

On Mon, Dec 18, 2017 at 08:23:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: BUG: unable to handle kernel NULL pointer dereference in binder_poll

On Mon, Dec 18, 2017 at 08:23:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

[PATCH] kbuild/gcc-plugin: drop randomize_layout_hash.h from targets

randomize_layout_hash.h is not used in plugin compilation, but locates in include/generated/ Signed-off-by: Cao jin --- scripts/gcc-plugins/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/gcc-plugins/Makefile

[PATCH] kbuild/gcc-plugin: drop randomize_layout_hash.h from targets

randomize_layout_hash.h is not used in plugin compilation, but locates in include/generated/ Signed-off-by: Cao jin --- scripts/gcc-plugins/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile index

Re: [PATCH v3 0/4] KVM: Expose speculation control feature to guests

On 01/30/2018 04:16 PM, Paolo Bonzini wrote: > On 30/01/2018 18:48, Raj, Ashok wrote: >>> Certainly not every vmexit! But doing it on every userspace vmexit and >>> every sched_out would not be *that* bad. >> Right.. agreed. We discussed the different scenarios that doing IBPB >> on VMexit would

Re: [PATCH v3 0/4] KVM: Expose speculation control feature to guests

On 01/30/2018 04:16 PM, Paolo Bonzini wrote: > On 30/01/2018 18:48, Raj, Ashok wrote: >>> Certainly not every vmexit! But doing it on every userspace vmexit and >>> every sched_out would not be *that* bad. >> Right.. agreed. We discussed the different scenarios that doing IBPB >> on VMexit would

[GIT PULL] s390 patches for the 4.15 merge window

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Bug fixes, small improvements and one notable change: * The system call table and the unistd.h header are now generated

[GIT PULL] s390 patches for the 4.15 merge window

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Bug fixes, small improvements and one notable change: * The system call table and the unistd.h header are now generated

Re: KASAN: use-after-free Read in map_lookup_elem

On Fri, Jan 12, 2018 at 02:58:02PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 4147d50978df60f34d444c647dde9e5b34a4315e > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C

Re: KASAN: use-after-free Read in map_lookup_elem

On Fri, Jan 12, 2018 at 02:58:02PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 4147d50978df60f34d444c647dde9e5b34a4315e > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C

Re: [GIT pull] Timer core updates for 4.16

* Linus Torvalds wrote: > On Mon, Jan 29, 2018 at 10:30 PM, Ingo Molnar wrote: > > > > These are in cases significant driver simplifications, but they also enable > > the > > real deal, the elimination of the hrtimer tasklet: > > > > softirq:

Re: [GIT pull] Timer core updates for 4.16

* Linus Torvalds wrote: > On Mon, Jan 29, 2018 at 10:30 PM, Ingo Molnar wrote: > > > > These are in cases significant driver simplifications, but they also enable > > the > > real deal, the elimination of the hrtimer tasklet: > > > > softirq: Remove tasklet_hrtimer > > > >

  1   2   3   4   5   6   7   8   9   10   >