答复: [PATCH] staging: rtsx: Add support for RTS5260

> On Fri, Oct 13, 2017 at 10:54:22AM +0100, Lee Jones wrote: > > On Fri, 13 Oct 2017, Greg KH wrote: > > > > > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_f...@realsil.com.cn wrote: > > > > From: rui_feng > > > > > > > > Add support for new chip rts5260. > > > > In

答复: [PATCH] staging: rtsx: Add support for RTS5260

> On Fri, Oct 13, 2017 at 10:54:22AM +0100, Lee Jones wrote: > > On Fri, 13 Oct 2017, Greg KH wrote: > > > > > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_f...@realsil.com.cn wrote: > > > > From: rui_feng > > > > > > > > Add support for new chip rts5260. > > > > In order to support rts5260，the

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

On Sun, 15 Oct 2017, Gang He wrote: > Hello Intel Kbuild team, > > You just upgrade GCC version when compiling the latest kernel? > Since these code looks a little old, I am sure that the related contributors > are still work on OCFS2 project. I'm not sure to understand the comment. The

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

On Sun, 15 Oct 2017, Gang He wrote: > Hello Intel Kbuild team, > > You just upgrade GCC version when compiling the latest kernel? > Since these code looks a little old, I am sure that the related contributors > are still work on OCFS2 project. I'm not sure to understand the comment. The

[tip:x86/asm 4/5] drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.o: warning: objtool: kiblnd_post_tx_locked()+0x94: stack state mismatch: cfa1=7+224 cfa2=7+208

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm head: fc72ae40e30327aa24eb88a24b9c7058f938bd36 commit: 11af847446ed0d131cf24d16a7ef3d5ea7a49554 [4/5] x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*' config: x86_64-randconfig-a0-10161235 (attached as

[tip:x86/asm 4/5] drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.o: warning: objtool: kiblnd_post_tx_locked()+0x94: stack state mismatch: cfa1=7+224 cfa2=7+208

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm head: fc72ae40e30327aa24eb88a24b9c7058f938bd36 commit: 11af847446ed0d131cf24d16a7ef3d5ea7a49554 [4/5] x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*' config: x86_64-randconfig-a0-10161235 (attached as

Re: [PATCH] scsi: qedi: Delete redundant variables

On 14/10/17 5:47 PM, "Christos Gkekas" wrote: >Remove redundant variables in quedi_fw.c that are set but not used. > >Signed-off-by: Christos Gkekas >--- > drivers/scsi/qedi/qedi_fw.c | 17 + > 1 file changed, 1 insertion(+), 16

Re: [PATCH] scsi: qedi: Delete redundant variables

On 14/10/17 5:47 PM, "Christos Gkekas" wrote: >Remove redundant variables in quedi_fw.c that are set but not used. > >Signed-off-by: Christos Gkekas >--- > drivers/scsi/qedi/qedi_fw.c | 17 + > 1 file changed, 1 insertion(+), 16 deletions(-) > >diff --git

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

On 2017/10/16 12:45, Mike Galbraith wrote: > On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote: >> >> I'll try to move quiet_vmstat() into the normal idle branch if this patch >> series >> are reasonable. Is fast_idle a good indication for it? > > see x86_tip 62cb1188ed86 sched/idle: Move

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

On 2017/10/16 12:45, Mike Galbraith wrote: > On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote: >> >> I'll try to move quiet_vmstat() into the normal idle branch if this patch >> series >> are reasonable. Is fast_idle a good indication for it? > > see x86_tip 62cb1188ed86 sched/idle: Move

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote: > + :c:func:`dev_pm_set_driver_flags` helper function.] If the first of > + tese flags is set, the PM core will not apply the direct-complete ^ these > + proceudre described above to the given device

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote: > + :c:func:`dev_pm_set_driver_flags` helper function.] If the first of > + tese flags is set, the PM core will not apply the direct-complete ^ these > + proceudre described above to the given device

[PATCH] dmaengine: rcar-dmac: read DMATCRB instead of DMATCR for residue

From: Kuninori Morimoto SYS/RT/Audio DMAC have both TCR/TCRB register. Its difference is transfer counter value of read (= TCR) or write (= TCRB). The relationship is like below. TCR TCRB [SOURCE] -> [DMAC] -> [DESTINATION] Thus, we want to

[PATCH] dmaengine: rcar-dmac: read DMATCRB instead of DMATCR for residue

From: Kuninori Morimoto SYS/RT/Audio DMAC have both TCR/TCRB register. Its difference is transfer counter value of read (= TCR) or write (= TCRB). The relationship is like below. TCR TCRB [SOURCE] -> [DMAC] -> [DESTINATION] Thus, we want to read TCRB instead of TCR for residue.

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

I am using 4.14-rc4 with a patch on top that includes arch/arm/include/asm/dma-mapping.h in a module. I have MMU enabled, so select DMA_NOOP_OPS if !MMU does nothing for me, and I get a compile error because dma_noop_ops is unknown. Maybe I should include linux/dma-mapping.h? Thanks for the

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

I am using 4.14-rc4 with a patch on top that includes arch/arm/include/asm/dma-mapping.h in a module. I have MMU enabled, so select DMA_NOOP_OPS if !MMU does nothing for me, and I get a compile error because dma_noop_ops is unknown. Maybe I should include linux/dma-mapping.h? Thanks for the

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

On 10 October 2017 at 14:22, Bin Liu wrote: > On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote: >> This fixes a kernel oops when unloading the driver due to usb_put_phy >> being called after usb_phy_generic_unregister when the device is >> detached. Calling

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

On 10 October 2017 at 14:22, Bin Liu wrote: > On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote: >> This fixes a kernel oops when unloading the driver due to usb_put_phy >> being called after usb_phy_generic_unregister when the device is >> detached. Calling usb_phy_generic_unregister

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote: > > I'll try to move quiet_vmstat() into the normal idle branch if this patch > series > are reasonable. Is fast_idle a good indication for it? see x86_tip 62cb1188ed86 sched/idle: Move quiet_vmstate() into the NOHZ code -Mike

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote: > > I'll try to move quiet_vmstat() into the normal idle branch if this patch > series > are reasonable. Is fast_idle a good indication for it? see x86_tip 62cb1188ed86 sched/idle: Move quiet_vmstate() into the NOHZ code -Mike

RE: [PATCH] of: dynamic: fix memory leak related to properties of __of_node_dup

Hi Rob and Frank, Thanks for your comments. Frank's description is exactly what I meant. I will changed the description as yours if you don't mind. We are using Linux v3.10.64 and a patch from https://lkml.org/lkml/2014/4/4/207. With this patch all properties are added dynamically to the

RE: [PATCH] of: dynamic: fix memory leak related to properties of __of_node_dup

Hi Rob and Frank, Thanks for your comments. Frank's description is exactly what I meant. I will changed the description as yours if you don't mind. We are using Linux v3.10.64 and a patch from https://lkml.org/lkml/2014/4/4/207. With this patch all properties are added dynamically to the

A issue about ptrace/SINGLESTEP on arm64

Hi I write demo use ptrace/SINGLESTEP to count the number of instructions executed by the process The parent process fork+exec a child process, and trace(SINGLESTEP) it, It works fine under the x86_64 architecture but has an exception under arm64. ```cpp //demo.c #include #include

A issue about ptrace/SINGLESTEP on arm64

Hi I write demo use ptrace/SINGLESTEP to count the number of instructions executed by the process The parent process fork+exec a child process, and trace(SINGLESTEP) it, It works fine under the x86_64 architecture but has an exception under arm64. ```cpp //demo.c #include #include

RE: [PATCH v2 2/5] dpaa_eth: move of_phy_connect() to the eth driver

> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Sunday, October 15, 2017 9:34 PM > To: Madalin-cristian Bucur > Cc: net...@vger.kernel.org; da...@davemloft.net; f.faine...@gmail.com; > vivien.dide...@savoirfairelinux.com; jun...@outlook.com;

RE: [PATCH v2 2/5] dpaa_eth: move of_phy_connect() to the eth driver

> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Sunday, October 15, 2017 9:34 PM > To: Madalin-cristian Bucur > Cc: net...@vger.kernel.org; da...@davemloft.net; f.faine...@gmail.com; > vivien.dide...@savoirfairelinux.com; jun...@outlook.com; linux- >

Re: [PATCH v3] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

Ping ?? -- Anup

Re: [PATCH v3] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

Ping ?? -- Anup

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

Ping ?? -- Anup

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

Ping ?? -- Anup

Re: [PATCH v5 11/16] perf report: properly handle branch count in match_chain

On Friday 13 October 2017 07:38 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Oct 13, 2017 at 10:39:03AM -0300, Arnaldo Carvalho de Melo escreveu: Em Mon, Oct 09, 2017 at 10:33:05PM +0200, Milian Wolff escreveu: Some of the code paths I introduced before returned too early without running the

Re: [PATCH v5 11/16] perf report: properly handle branch count in match_chain

On Friday 13 October 2017 07:38 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Oct 13, 2017 at 10:39:03AM -0300, Arnaldo Carvalho de Melo escreveu: Em Mon, Oct 09, 2017 at 10:33:05PM +0200, Milian Wolff escreveu: Some of the code paths I introduced before returned too early without running the

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

Hi Gang, On Sun, Oct 15, 2017 at 09:26:00PM -0600, Gang He wrote: Hello Intel Kbuild team, You just upgrade GCC version when compiling the latest kernel? This report comes from a pretty old gcc: config: tile-allyesconfig (attached as .config) compiler: tilegx-linux-gcc (GCC)

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

Hi Gang, On Sun, Oct 15, 2017 at 09:26:00PM -0600, Gang He wrote: Hello Intel Kbuild team, You just upgrade GCC version when compiling the latest kernel? This report comes from a pretty old gcc: config: tile-allyesconfig (attached as .config) compiler: tilegx-linux-gcc (GCC)

[PATCH] Makefile: Fix empty flag results for stackprotector _AUTO mode

If the compiler didn't support any stackprotector mode, the second empty test would still trip. This moves it to an "else" test for the non-AUTO modes. Reported-and-tested-by: Robert Jarzmik Signed-off-by: Kees Cook --- This is a separate fix from

[PATCH] Makefile: Fix empty flag results for stackprotector _AUTO mode

If the compiler didn't support any stackprotector mode, the second empty test would still trip. This moves it to an "else" test for the non-AUTO modes. Reported-and-tested-by: Robert Jarzmik Signed-off-by: Kees Cook --- This is a separate fix from the issue with gcc 4.4.4. Yay compilers. (Also,

[PATCH 1/5] arm64: dts: realtek: Factor out common RTD129x parts

Prepares for RTD1293 and RTD1296. Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/rtd1295.dtsi | 65 ++-- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 72 2 files changed, 76 insertions(+), 61 deletions(-)

[PATCH 1/5] arm64: dts: realtek: Factor out common RTD129x parts

Prepares for RTD1293 and RTD1296. Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/rtd1295.dtsi | 65 ++-- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 72 2 files changed, 76 insertions(+), 61 deletions(-) create mode 100644

[PATCH 2/5] dt-bindings: arm: realtek: Document RTD1293 and Synology DS418j

Define compatible strings for Realtek RTD1293 SoC and Synology DiskStation DS418j NAS. Cc: i...@synology.com Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH 2/5] dt-bindings: arm: realtek: Document RTD1293 and Synology DS418j

Define compatible strings for Realtek RTD1293 SoC and Synology DiskStation DS418j NAS. Cc: i...@synology.com Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH 4/5] dt-bindings: arm: realtek: Document RTD1296 and Synology DS418

Define compatible strings for Realtek RTD1296 SoC and Synology DiskStation DS418 NAS. Cc: i...@synology.com Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH 4/5] dt-bindings: arm: realtek: Document RTD1296 and Synology DS418

Define compatible strings for Realtek RTD1296 SoC and Synology DiskStation DS418 NAS. Cc: i...@synology.com Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH 0/5] arm64: dts: Initial RTD1293/RTD1296 and DS418j/DS418 support

Hello, This series adds Device Trees for the Realtek RTD1293 and RTD1296 SoCs and Synology DiskStation DS418j and DS418 NAS devices. To avoid too much duplication, a shared rtd129x.dtsi is introduced. More details at: https://en.opensuse.org/HCL:DS418j https://en.opensuse.org/HCL:DS418 Latest

[PATCH 5/5] arm64: dts: realtek: Add RTD1296 and Synology DS418

Add Device Trees for RTD1296 SoC and Synology DiskStation DS418. Cc: i...@synology.com Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/Makefile | 2 + arch/arm64/boot/dts/realtek/rtd1296-ds418.dts | 31 +++

[PATCH 0/5] arm64: dts: Initial RTD1293/RTD1296 and DS418j/DS418 support

Hello, This series adds Device Trees for the Realtek RTD1293 and RTD1296 SoCs and Synology DiskStation DS418j and DS418 NAS devices. To avoid too much duplication, a shared rtd129x.dtsi is introduced. More details at: https://en.opensuse.org/HCL:DS418j https://en.opensuse.org/HCL:DS418 Latest

[PATCH 5/5] arm64: dts: realtek: Add RTD1296 and Synology DS418

Add Device Trees for RTD1296 SoC and Synology DiskStation DS418. Cc: i...@synology.com Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/Makefile | 2 + arch/arm64/boot/dts/realtek/rtd1296-ds418.dts | 31 +++ arch/arm64/boot/dts/realtek/rtd1296.dtsi | 74

[PATCH 3/5] arm64: dts: realtek: Add RTD1293 and Synology DS418j

Add Device Trees for RTD1293 SoC and Synology DiskStation DS481j NAS. Cc: i...@synology.com Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/Makefile | 2 + arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts | 31 ++

[PATCH 3/5] arm64: dts: realtek: Add RTD1293 and Synology DS418j

Add Device Trees for RTD1293 SoC and Synology DiskStation DS481j NAS. Cc: i...@synology.com Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/Makefile | 2 + arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts | 31 ++ arch/arm64/boot/dts/realtek/rtd1293.dtsi

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

On 10/15/17 20:29, Randy Dunlap wrote: > On 10/15/17 20:27, Randy Dunlap wrote: >> On 10/15/17 19:27, Marian Mihailescu wrote: >>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops >>> are built only for architectures that use it. >>> >>> For ARM architecture, CONFIG_DMA_NOOP_OPS

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

On 10/15/17 20:29, Randy Dunlap wrote: > On 10/15/17 20:27, Randy Dunlap wrote: >> On 10/15/17 19:27, Marian Mihailescu wrote: >>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops >>> are built only for architectures that use it. >>> >>> For ARM architecture, CONFIG_DMA_NOOP_OPS

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

On Mon, Oct 16, 2017 at 02:00:33PM +1100, Michael Ellerman wrote: > Mathieu Desnoyers writes: > > > Implements two basic tests of RSEQ functionality, and one more > > exhaustive parameterizable test. > > > > The first, "basic_test" only asserts that RSEQ works

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

On Mon, Oct 16, 2017 at 02:00:33PM +1100, Michael Ellerman wrote: > Mathieu Desnoyers writes: > > > Implements two basic tests of RSEQ functionality, and one more > > exhaustive parameterizable test. > > > > The first, "basic_test" only asserts that RSEQ works moderately > > correctly. > > E.g.

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

Hello Intel Kbuild team, You just upgrade GCC version when compiling the latest kernel? Since these code looks a little old, I am sure that the related contributors are still work on OCFS2 project. Thanks Gang >>> > Hi Bhumika, > > [auto build test WARNING on linus/master] > [also build

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

Hello Intel Kbuild team, You just upgrade GCC version when compiling the latest kernel? Since these code looks a little old, I am sure that the related contributors are still work on OCFS2 project. Thanks Gang >>> > Hi Bhumika, > > [auto build test WARNING on linus/master] > [also build

Re: [f2fs-dev] [PATCH v2] f2fs: update dirty status for CURSEG as well

On 2017/10/14 20:53, Yunlong Song wrote: > Oh, yes it is. I found that problem in a kernel tree which does not have > commit > c6f82fe90d7458e5fa190a6820bfc24f96b0de4e (Revert "f2fs: put allocate_segment > after refresh_sit_entry"). In that kernel, the allocate_segment is still > behind >

Re: [f2fs-dev] [PATCH v2] f2fs: update dirty status for CURSEG as well

On 2017/10/14 20:53, Yunlong Song wrote: > Oh, yes it is. I found that problem in a kernel tree which does not have > commit > c6f82fe90d7458e5fa190a6820bfc24f96b0de4e (Revert "f2fs: put allocate_segment > after refresh_sit_entry"). In that kernel, the allocate_segment is still > behind >

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

Sean Paul writes: > Sphinx won't pick these up, and will issue warnings. Please update to @ > instead of \param > > If you want to try it out: > make htmldocs Yeah, I was attempting to emulate the existing style. I suggest that a general cleanup to fix the docstrings

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

Sean Paul writes: > Sphinx won't pick these up, and will issue warnings. Please update to @ > instead of \param > > If you want to try it out: > make htmldocs Yeah, I was attempting to emulate the existing style. I suggest that a general cleanup to fix the docstrings should be in a separate

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

On 10/15/17 20:27, Randy Dunlap wrote: > On 10/15/17 19:27, Marian Mihailescu wrote: >> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops >> are built only for architectures that use it. >> >> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot >> be selected.

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

On 10/15/17 20:27, Randy Dunlap wrote: > On 10/15/17 19:27, Marian Mihailescu wrote: >> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops >> are built only for architectures that use it. >> >> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot >> be selected.

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

On 10/15/17 19:27, Marian Mihailescu wrote: > After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops > are built only for architectures that use it. > > For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot > be selected. > > However,

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

On 10/15/17 19:27, Marian Mihailescu wrote: > After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops > are built only for architectures that use it. > > For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot > be selected. > > However,

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

On 2017/10/14 8:51, Rafael J. Wysocki wrote: > On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote: >> If the next idle is expected to be a fast idle, we should keep tick >> on before going into idle >> >> Signed-off-by: Aubrey Li > > This also can be

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

On 2017/10/14 8:51, Rafael J. Wysocki wrote: > On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote: >> If the next idle is expected to be a fast idle, we should keep tick >> on before going into idle >> >> Signed-off-by: Aubrey Li > > This also can be merged with the previous patch

Re: [f2fs-dev] [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

On 2017/10/14 20:34, Yunlong Song wrote: > Do you mean check out-of-space test? I have tried that but no bugon. Yes, test recent f2fs codes with kernel 4.13.0-rc1+ in VM, FYI: kernel BUG at gc.c:1034! invalid opcode: [#1] SMP Hardware name: Xen HVM domU, BIOS 4.1.2_115-900.260_ 11/06/2015

Re: [f2fs-dev] [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

On 2017/10/14 20:34, Yunlong Song wrote: > Do you mean check out-of-space test? I have tried that but no bugon. Yes, test recent f2fs codes with kernel 4.13.0-rc1+ in VM, FYI: kernel BUG at gc.c:1034! invalid opcode: [#1] SMP Hardware name: Xen HVM domU, BIOS 4.1.2_115-900.260_ 11/06/2015

Re: [PATCH v2 7/9] usb: host: modify description for MTK xHCI config

On Fri, 2017-10-13 at 13:32 +0300, Mathias Nyman wrote: > On 13.10.2017 11:26, Chunfeng Yun wrote: > > Due to all MediaTek SoCs with xHCI host controller use this > > driver, remove limitation for specific SoCs > > > > Signed-off-by: Chunfeng Yun > > --- > > xHCI parts

Re: [PATCH v2 7/9] usb: host: modify description for MTK xHCI config

On Fri, 2017-10-13 at 13:32 +0300, Mathias Nyman wrote: > On 13.10.2017 11:26, Chunfeng Yun wrote: > > Due to all MediaTek SoCs with xHCI host controller use this > > driver, remove limitation for specific SoCs > > > > Signed-off-by: Chunfeng Yun > > --- > > xHCI parts of series look good to me,

[PATCH v6 3/3] media: ov7670: Add the ov7670_s_power function

Add the ov7670_s_power function which is responsible for manipulating the power dowm mode through the PWDN pin and the reset operation through the RESET pin, and keep it powered at all times. Signed-off-by: Wenyou Yang --- Changes in v6: - Remove .s_power callback to

[PATCH v6 3/3] media: ov7670: Add the ov7670_s_power function

Add the ov7670_s_power function which is responsible for manipulating the power dowm mode through the PWDN pin and the reset operation through the RESET pin, and keep it powered at all times. Signed-off-by: Wenyou Yang --- Changes in v6: - Remove .s_power callback to keep the ov7670 powered at

[PATCH v6 2/3] media: ov7670: Add the get_fmt callback

Add the get_fmt callback, also enable V4L2_SUBDEV_FL_HAS_DEVNODE flag to make this subdev has device node. Signed-off-by: Wenyou Yang --- Changes in v6: None Changes in v5: - Fix the build warning on the declaration *mbus_fmt(ISO C90 forbids mixed). Changes in v4:

[PATCH v6 2/3] media: ov7670: Add the get_fmt callback

Add the get_fmt callback, also enable V4L2_SUBDEV_FL_HAS_DEVNODE flag to make this subdev has device node. Signed-off-by: Wenyou Yang --- Changes in v6: None Changes in v5: - Fix the build warning on the declaration *mbus_fmt(ISO C90 forbids mixed). Changes in v4: - Fix the build error when

[PATCH v6 0/3] media: ov7670: Add entity init and power operation

This patch set is to add the media entity pads initialization, the ov7670_s_power function and get_fmt callback support. Changes in v6: - Remove .s_power callback to keep the ov7670 powered at all times. - Update the commit log accordingly. Changes in v5: - Fix the build warning on the

[PATCH v6 1/3] media: ov7670: Add entity pads initialization

Add the media entity pads initialization. Signed-off-by: Wenyou Yang --- Changes in v6: None Changes in v5: None Changes in v4: - Fix the build error when not enabling Media Controller API option. Changes in v3: None Changes in v2: None drivers/media/i2c/ov7670.c

[PATCH v6 0/3] media: ov7670: Add entity init and power operation

This patch set is to add the media entity pads initialization, the ov7670_s_power function and get_fmt callback support. Changes in v6: - Remove .s_power callback to keep the ov7670 powered at all times. - Update the commit log accordingly. Changes in v5: - Fix the build warning on the

[PATCH v6 1/3] media: ov7670: Add entity pads initialization

Add the media entity pads initialization. Signed-off-by: Wenyou Yang --- Changes in v6: None Changes in v5: None Changes in v4: - Fix the build error when not enabling Media Controller API option. Changes in v3: None Changes in v2: None drivers/media/i2c/ov7670.c | 21 -

RE: [PATCH v2 5/5] fsl/fman: add dpaa in module names

> -Original Message- > From: Florian Fainelli [mailto:f.faine...@gmail.com] > Sent: Friday, October 13, 2017 8:39 PM > To: Madalin-cristian Bucur ; > net...@vger.kernel.org; da...@davemloft.net > Cc: and...@lunn.ch; vivien.dide...@savoirfairelinux.com; >

RE: [PATCH v2 5/5] fsl/fman: add dpaa in module names

> -Original Message- > From: Florian Fainelli [mailto:f.faine...@gmail.com] > Sent: Friday, October 13, 2017 8:39 PM > To: Madalin-cristian Bucur ; > net...@vger.kernel.org; da...@davemloft.net > Cc: and...@lunn.ch; vivien.dide...@savoirfairelinux.com; > jun...@outlook.com;

Re: [RFC PATCH v2 2/8] cpuidle: record the overhead of idle entry

On 2017/10/14 8:35, Rafael J. Wysocki wrote: > On Saturday, September 30, 2017 9:20:28 AM CEST Aubrey Li wrote: >> Record the overhead of idle entry in micro-second >> > > What is this needed for? We need to figure out how long of a idle is a short idle and recording the overhead is for this

Re: [RFC PATCH v2 2/8] cpuidle: record the overhead of idle entry

On 2017/10/14 8:35, Rafael J. Wysocki wrote: > On Saturday, September 30, 2017 9:20:28 AM CEST Aubrey Li wrote: >> Record the overhead of idle entry in micro-second >> > > What is this needed for? We need to figure out how long of a idle is a short idle and recording the overhead is for this

Re: [PATCH] f2fs: expose some sectors to user in inline data or dentry case

On 2017/10/14 1:31, Jaegeuk Kim wrote: > If there's some data written through inline data or dentry, we need to shouw > st_blocks. This fixes reporting zero blocks even though there is small written > data. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu

Re: [PATCH] f2fs: expose some sectors to user in inline data or dentry case

On 2017/10/14 1:31, Jaegeuk Kim wrote: > If there's some data written through inline data or dentry, we need to shouw > st_blocks. This fixes reporting zero blocks even though there is small written > data. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks, > --- > fs/f2fs/file.c |

[PATCH 3/3] arm64: dts: realtek: Add MeLE V9

Add an initial Device Tree for MeLE V9 Media Player. Cc: meleserv...@mele.cn Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/Makefile| 1 + arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts | 31 + 2 files changed, 32

[PATCH 3/3] arm64: dts: realtek: Add MeLE V9

Add an initial Device Tree for MeLE V9 Media Player. Cc: meleserv...@mele.cn Signed-off-by: Andreas Färber --- arch/arm64/boot/dts/realtek/Makefile| 1 + arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts | 31 + 2 files changed, 32 insertions(+) create mode

[PATCH 2/3] dt-bindings: arm: realtek: Document MeLE V9

Define a compatible string for MeLE V9 Media Player. Cc: meleserv...@mele.cn Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/realtek.txt

[PATCH 0/3] arm64: dts: Initial MeLE V9 support

Hello, This mini-series adds a Device Tree for the MeLE V9 Android Media Player. Same as with PROBOX2 AVA, serial (loady) was the only working way to boot a new kernel from the vendor's U-Boot on this TV box. More details at: https://en.opensuse.org/HCL:Mele_V9 @MeLE: Please review the

[PATCH 2/3] dt-bindings: arm: realtek: Document MeLE V9

Define a compatible string for MeLE V9 Media Player. Cc: meleserv...@mele.cn Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/realtek.txt

[PATCH 0/3] arm64: dts: Initial MeLE V9 support

Hello, This mini-series adds a Device Tree for the MeLE V9 Android Media Player. Same as with PROBOX2 AVA, serial (loady) was the only working way to boot a new kernel from the vendor's U-Boot on this TV box. More details at: https://en.opensuse.org/HCL:Mele_V9 @MeLE: Please review the

[PATCH 1/3] dt-bindings: Add vendor prefix for MeLE

MeLE is a Chinese manufacturer of TV boxes and Mini PCs. Cc: meleserv...@mele.cn Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt

[PATCH 1/3] dt-bindings: Add vendor prefix for MeLE

MeLE is a Chinese manufacturer of TV boxes and Mini PCs. Cc: meleserv...@mele.cn Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt

RE: [PATCH] EDAC, sb_edac: mark expected switch fall-through

Hi Silva, The actual intention of the code is NOT to fall through, though current code can work correctly. Thanks for this finding. If you don't mind, I'll submit a fix patch for it with the tag 'Reported-by:' by you. Thanks! - Qiuxu > From: linux-edac-ow...@vger.kernel.org

RE: [PATCH] EDAC, sb_edac: mark expected switch fall-through

Hi Silva, The actual intention of the code is NOT to fall through, though current code can work correctly. Thanks for this finding. If you don't mind, I'll submit a fix patch for it with the tag 'Reported-by:' by you. Thanks! - Qiuxu > From: linux-edac-ow...@vger.kernel.org

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

Mathieu Desnoyers writes: > Implements two basic tests of RSEQ functionality, and one more > exhaustive parameterizable test. > > The first, "basic_test" only asserts that RSEQ works moderately > correctly. > E.g. that: > - The CPUID pointer works > - Code

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

Mathieu Desnoyers writes: > Implements two basic tests of RSEQ functionality, and one more > exhaustive parameterizable test. > > The first, "basic_test" only asserts that RSEQ works moderately > correctly. > E.g. that: > - The CPUID pointer works > - Code infinitely looping within a critical

[PATCH] keys, trusted: fix missing support for TPM 2.0 in trusted_update()

Call tpm_seal_trusted() in trusted_update() for TPM 2.0 chips. Signed-off-by: Boshi Wang --- security/keys/trusted.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/security/keys/trusted.c b/security/keys/trusted.c index ddfaebf..563fe5f

[PATCH] keys, trusted: fix missing support for TPM 2.0 in trusted_update()

Call tpm_seal_trusted() in trusted_update() for TPM 2.0 chips. Signed-off-by: Boshi Wang --- security/keys/trusted.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/security/keys/trusted.c b/security/keys/trusted.c index ddfaebf..563fe5f 100644 ---

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

Mathieu Desnoyers writes: > Implements two basic tests of RSEQ functionality, and one more > exhaustive parameterizable test. > > The first, "basic_test" only asserts that RSEQ works moderately > correctly. > E.g. that: > - The CPUID pointer works > - Code

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

Mathieu Desnoyers writes: > Implements two basic tests of RSEQ functionality, and one more > exhaustive parameterizable test. > > The first, "basic_test" only asserts that RSEQ works moderately > correctly. > E.g. that: > - The CPUID pointer works > - Code infinitely looping within a critical

Re: [RFC PATCH v2 1/8] cpuidle: menu: extract prediction functionality

On 2017/10/14 8:26, Rafael J. Wysocki wrote: > On Saturday, September 30, 2017 9:20:27 AM CEST Aubrey Li wrote: >> There are several factors in the menu governor to predict the next >> idle interval: >> - the next timer >> - the recent idle interval history >> - the corrected idle interval pattern

Re: [RFC PATCH v2 1/8] cpuidle: menu: extract prediction functionality

On 2017/10/14 8:26, Rafael J. Wysocki wrote: > On Saturday, September 30, 2017 9:20:27 AM CEST Aubrey Li wrote: >> There are several factors in the menu governor to predict the next >> idle interval: >> - the next timer >> - the recent idle interval history >> - the corrected idle interval pattern

  1   2   3   4   5   >