[RFC PATCH 0/9] soc: samsung: Add support of suspend-to-RAM on Exynos5433

In the mainline, there is no case to support the suspend-to-RAM for Samsung Exynos SoC. This patchset support the suspend-to-RAM for 64bit Exynos SoC. For 32bit, arch/arm/mach-exynos/* directoy contains the suspend-related codes such as suspend.c/exynos.c. But, 64bit Exynos should contain the

[RFC PATCH 0/9] soc: samsung: Add support of suspend-to-RAM on Exynos5433

In the mainline, there is no case to support the suspend-to-RAM for Samsung Exynos SoC. This patchset support the suspend-to-RAM for 64bit Exynos SoC. For 32bit, arch/arm/mach-exynos/* directoy contains the suspend-related codes such as suspend.c/exynos.c. But, 64bit Exynos should contain the

[PATCH 7/9] arm64: dts: exynos: Use power key as a wakeup source on TM2/TM2E board

This patch uses the power-key as a wakeup source from suspend/freeze state. Signed-off-by: Chanwoo Choi --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi

[PATCH 7/9] arm64: dts: exynos: Use power key as a wakeup source on TM2/TM2E board

This patch uses the power-key as a wakeup source from suspend/freeze state. Signed-off-by: Chanwoo Choi --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi

Re: [lkp-robot] [sched/fair] a4c3c04974: unixbench.score -4.3% regression

Hi, On 8 January 2018 at 10:34, Vincent Guittot wrote: > Hi Xiaolong, > > On 25 December 2017 at 07:07, kernel test robot wrote: >> >> Greeting, >> >> FYI, we noticed a -4.3% regression of unixbench.score due to commit: >> >> >> commit:

Re: [lkp-robot] [sched/fair] a4c3c04974: unixbench.score -4.3% regression

Hi, On 8 January 2018 at 10:34, Vincent Guittot wrote: > Hi Xiaolong, > > On 25 December 2017 at 07:07, kernel test robot wrote: >> >> Greeting, >> >> FYI, we noticed a -4.3% regression of unixbench.score due to commit: >> >> >> commit: a4c3c04974d648ee6e1a09ef4131eb32a02ab494 ("sched/fair:

[mkp-scsi:for-next 237/263] drivers/scsi/libsas/sas_discover.c:364:6: sparse: symbol 'sas_destruct_ports' was not declared. Should it be static?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next head: f7c3d0667404295422c9a5d71fd87ca20c770f49 commit: 99cfdc04c12ea1bc5719bff15f24dae8b5b90da9 [237/263] scsi: libsas: direct call probe and destruct reproduce: # apt-get install sparse git checkout

[mkp-scsi:for-next 237/263] drivers/scsi/libsas/sas_discover.c:364:6: sparse: symbol 'sas_destruct_ports' was not declared. Should it be static?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next head: f7c3d0667404295422c9a5d71fd87ca20c770f49 commit: 99cfdc04c12ea1bc5719bff15f24dae8b5b90da9 [237/263] scsi: libsas: direct call probe and destruct reproduce: # apt-get install sparse git checkout

[RFC PATCH mkp-scsi] scsi: libsas: sas_destruct_ports() can be static

Fixes: 99cfdc04c12e ("scsi: libsas: direct call probe and destruct") Signed-off-by: Fengguang Wu --- sas_discover.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c index

[RFC PATCH mkp-scsi] scsi: libsas: sas_destruct_ports() can be static

Fixes: 99cfdc04c12e ("scsi: libsas: direct call probe and destruct") Signed-off-by: Fengguang Wu --- sas_discover.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c index 190108e..e4fd078 100644 ---

Re: [PATCH v6 2/3] fs: fat: Add volume label entry method function

ChenGuanqiao writes: > +static int fat_get_volume_label_entry(struct inode *dir, loff_t *pos, > +struct buffer_head **bh, > +struct msdos_dir_entry **de) > +{ > + while (fat_get_entry(dir, pos, bh, de) >= 0)

Re: [PATCH v6 2/3] fs: fat: Add volume label entry method function

ChenGuanqiao writes: > +static int fat_get_volume_label_entry(struct inode *dir, loff_t *pos, > +struct buffer_head **bh, > +struct msdos_dir_entry **de) > +{ > + while (fat_get_entry(dir, pos, bh, de) >= 0) { > + if

HELLO

-- Hello Dear Friend, Greetings and how are you doing? I want to know if you are keen to be my partner in claiming the fortune $12.8 Million USD left by a late client. If you're interested Revert for more details. Awaiting your reply Hamza Kabore

HELLO

-- Hello Dear Friend, Greetings and how are you doing? I want to know if you are keen to be my partner in claiming the fortune $12.8 Million USD left by a late client. If you're interested Revert for more details. Awaiting your reply Hamza Kabore

Re: [PATCH v3 24/27] staging: ccree: use a consistent file naming convention

On Mon, Jan 8, 2018 at 5:28 PM, Greg Kroah-Hartman wrote: > On Sun, Jan 07, 2018 at 12:14:35PM +, Gilad Ben-Yossef wrote: >> The ccree driver source files were using an inconsistent >> naming convention stemming from what the company was called >> when they were

Re: [PATCH v3 24/27] staging: ccree: use a consistent file naming convention

On Mon, Jan 8, 2018 at 5:28 PM, Greg Kroah-Hartman wrote: > On Sun, Jan 07, 2018 at 12:14:35PM +, Gilad Ben-Yossef wrote: >> The ccree driver source files were using an inconsistent >> naming convention stemming from what the company was called >> when they were added. >> >> Move to a single

Re: [PATCH] crypto: clear htmldocs build warnings for crypto/hash

On Mon, Jan 08, 2018 at 05:43:18PM +0100, Kamil Konieczny wrote: > Is it mandatory for both async hash and shash ? > > in crypto/ahash.c in function > > static int crypto_ahash_init_tfm(struct crypto_tfm *tfm) > > there is: > > hash->export = ahash_no_export; > hash->import =

Re: [PATCH] crypto: clear htmldocs build warnings for crypto/hash

On Mon, Jan 08, 2018 at 05:43:18PM +0100, Kamil Konieczny wrote: > Is it mandatory for both async hash and shash ? > > in crypto/ahash.c in function > > static int crypto_ahash_init_tfm(struct crypto_tfm *tfm) > > there is: > > hash->export = ahash_no_export; > hash->import =

RE: [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly

Hi, Thanks for the review... >On Tue, Jan 09, 2018 at 04:48:10AM +, Appana Durga Kedareswara Rao >wrote: >> Hi, >> >> >On Mon, Jan 08, 2018 at 05:25:01PM +, Appana Durga Kedareswara >> >Rao >> >wrote: >> >> Hi, >> >> >> >> >> >> >> >> + xdev->common.dst_addr_widths =

RE: [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly

Hi, Thanks for the review... >On Tue, Jan 09, 2018 at 04:48:10AM +, Appana Durga Kedareswara Rao >wrote: >> Hi, >> >> >On Mon, Jan 08, 2018 at 05:25:01PM +, Appana Durga Kedareswara >> >Rao >> >wrote: >> >> Hi, >> >> >> >> >> >> >> >> + xdev->common.dst_addr_widths =

Re: [PATCH v2] v4l: doc: Clarify v4l2_mbus_fmt height definition

On 01/08/2018 06:55 PM, Kieran Bingham wrote: > The v4l2_mbus_fmt width and height corresponds directly with the > v4l2_pix_format definitions, yet the differences in documentation make > it ambiguous what to do in the event of field heights. > > Clarify this using the same text as is provided

Re: [PATCH v2] v4l: doc: Clarify v4l2_mbus_fmt height definition

On 01/08/2018 06:55 PM, Kieran Bingham wrote: > The v4l2_mbus_fmt width and height corresponds directly with the > v4l2_pix_format definitions, yet the differences in documentation make > it ambiguous what to do in the event of field heights. > > Clarify this using the same text as is provided

Re: [PATCH] ath9k: add a quirk to set use_msi automatically

AceLan Kao writes: > Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI > for WLAN device. So adding a quirk to list those machines and set > use_msi automatically. > Adding the following platforms to the quirk. >Dell Inspiron 24-3460 >Dell

Re: [PATCH] ath9k: add a quirk to set use_msi automatically

AceLan Kao writes: > Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI > for WLAN device. So adding a quirk to list those machines and set > use_msi automatically. > Adding the following platforms to the quirk. >Dell Inspiron 24-3460 >Dell Inspiron 3472 >Dell

Re: [PATCH v2] media: i2c: adv748x: fix HDMI field heights

On 01/08/2018 07:14 PM, Kieran Bingham wrote: > The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field > types. The correct specification for the height on the mbus is the > image height, in this instance, the field height. > > The AFE component already correctly adjusts the

Re: [PATCH v2] media: i2c: adv748x: fix HDMI field heights

On 01/08/2018 07:14 PM, Kieran Bingham wrote: > The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field > types. The correct specification for the height on the mbus is the > image height, in this instance, the field height. > > The AFE component already correctly adjusts the

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/09/18 at 01:41pm, Baoquan He wrote: > On 01/09/18 at 09:09am, Dave Young wrote: > > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > >

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/09/18 at 01:41pm, Baoquan He wrote: > On 01/09/18 at 09:09am, Dave Young wrote: > > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > >

Re: [lkp-robot] [mm/cma] 2b0f904a5a: fio.read_bw_MBps -16.1% regression

On Sat, Jan 06, 2018 at 05:26:31PM +0800, Ye Xiaolong wrote: > Hi, > > On 01/03, Joonsoo Kim wrote: > >Hello! > > > >On Tue, Jan 02, 2018 at 02:35:28PM +0800, kernel test robot wrote: > >> > >> Greeting, > >> > >> FYI, we noticed a -16.1% regression of fio.read_bw_MBps due to commit: > >> > >>

Re: [lkp-robot] [mm/cma] 2b0f904a5a: fio.read_bw_MBps -16.1% regression

On Sat, Jan 06, 2018 at 05:26:31PM +0800, Ye Xiaolong wrote: > Hi, > > On 01/03, Joonsoo Kim wrote: > >Hello! > > > >On Tue, Jan 02, 2018 at 02:35:28PM +0800, kernel test robot wrote: > >> > >> Greeting, > >> > >> FYI, we noticed a -16.1% regression of fio.read_bw_MBps due to commit: > >> > >>

Re: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

Hi, On Thu, Jan 04, 2018 at 02:00:03PM +, Liang, Kan wrote: > > Hi Kan, > > > > On Wed, Jan 03, 2018 at 02:15:38PM +, Liang, Kan wrote: > > > > Hello, > > > > > > > > On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote: > > > > > From: Kan Liang > >

Re: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

Hi, On Thu, Jan 04, 2018 at 02:00:03PM +, Liang, Kan wrote: > > Hi Kan, > > > > On Wed, Jan 03, 2018 at 02:15:38PM +, Liang, Kan wrote: > > > > Hello, > > > > > > > > On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote: > > > > > From: Kan Liang > > > > > > > > > > The

Re: Feedback on 4.9 performance after PTI fixes

Hi again, updating the table after Yves-Alexis' comment on PCID. Rerunning the test with -cpu=Haswell to enable PCID gave me much better numbers : On Sun, Jan 07, 2018 at 11:18:56AM +0100, Willy Tarreau wrote: > Hi, > > I managed to take a bit of time to run some more tests on PTI both > native

Re: Feedback on 4.9 performance after PTI fixes

Hi again, updating the table after Yves-Alexis' comment on PCID. Rerunning the test with -cpu=Haswell to enable PCID gave me much better numbers : On Sun, Jan 07, 2018 at 11:18:56AM +0100, Willy Tarreau wrote: > Hi, > > I managed to take a bit of time to run some more tests on PTI both > native

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

On 01/08/2018 08:15 PM, Tejun Heo wrote: > Currently, blk-mq protects only the issue path with RCU. This patch > puts the completion path under the same RCU protection. This will be > used to synchronize issue/completion against timeout by later patches, > which will also add the comments. > >

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

On 01/08/2018 08:15 PM, Tejun Heo wrote: > Currently, blk-mq protects only the issue path with RCU. This patch > puts the completion path under the same RCU protection. This will be > used to synchronize issue/completion against timeout by later patches, > which will also add the comments. > >

Re: [PATCH 07/11] powerpc/64s: Add support for RFI flush of L1-D cache

On Mon, Jan 8, 2018 at 8:54 AM, Michael Ellerman wrote: > On some CPUs we can prevent the Meltdown vulnerability by flushing the > L1-D cache on exit from kernel to user mode, and from hypervisor to > guest. Super minor nitpicks below. Don't let this hold up your work. >

Re: [PATCH 07/11] powerpc/64s: Add support for RFI flush of L1-D cache

On Mon, Jan 8, 2018 at 8:54 AM, Michael Ellerman wrote: > On some CPUs we can prevent the Meltdown vulnerability by flushing the > L1-D cache on exit from kernel to user mode, and from hypervisor to > guest. Super minor nitpicks below. Don't let this hold up your work. > ---

[PATCH] usb: f_fs: Prevent gadget unbind if it is already unbound

From: Hemant Kumar Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration.

[PATCH] usb: f_fs: Prevent gadget unbind if it is already unbound

From: Hemant Kumar Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by

[PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst() clobber memory, tell it what it clobbers: * dcbz(), dcbi() and dcbf() clobbers one cacheline as output * dcbf() and dcbst() clobbers one cacheline as input Signed-off-by: Christophe Leroy ---

[PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst() clobber memory, tell it what it clobbers: * dcbz(), dcbi() and dcbf() clobbers one cacheline as output * dcbf() and dcbst() clobbers one cacheline as input Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/cache.h |

Re: Applied "ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update" to the asoc tree

Hi Jiada, On Jan 9 2018 14:42, Jiada Wang wrote: Only the first patch in https://www.spinics.net/lists/alsa-devel/msg71021.html was applied, but the second patch "ASoC: rsnd: ssi: remove unnesessary period_pos" was missed Could you please have a look I can see all of them were applied to

Re: Applied "ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update" to the asoc tree

Hi Jiada, On Jan 9 2018 14:42, Jiada Wang wrote: Only the first patch in https://www.spinics.net/lists/alsa-devel/msg71021.html was applied, but the second patch "ASoC: rsnd: ssi: remove unnesessary period_pos" was missed Could you please have a look I can see all of them were applied to

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

Hi, On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote: > On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote: > > Hi Olsa, > > What about this fix now? Thanks! > > > > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote: > > > From: Changbin Du

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

Hi, On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote: > On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote: > > Hi Olsa, > > What about this fix now? Thanks! > > > > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote: > > > From: Changbin Du > > > > > >

[PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

Hi, This patches introduces new process_vmsplice system call that combines functionality of process_vm_read and vmsplice. It allows to map the memory of another process into a pipe, similarly to what vmsplice does for its own address space. The patch 2/4 ("vm: add a syscall to map a process

[PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

Hi, This patches introduces new process_vmsplice system call that combines functionality of process_vm_read and vmsplice. It allows to map the memory of another process into a pipe, similarly to what vmsplice does for its own address space. The patch 2/4 ("vm: add a syscall to map a process

[PATCH v5 4/4] test: add a test for the process_vmsplice syscall

From: Andrei Vagin This test checks that process_vmsplice() can splice pages from a remote process and returns EFAULT, if process_vmsplice() tries to splice pages by an unaccessiable address. Signed-off-by: Andrei Vagin Signed-off-by: Mike Rapoport

[PATCH v5 4/4] test: add a test for the process_vmsplice syscall

From: Andrei Vagin This test checks that process_vmsplice() can splice pages from a remote process and returns EFAULT, if process_vmsplice() tries to splice pages by an unaccessiable address. Signed-off-by: Andrei Vagin Signed-off-by: Mike Rapoport ---

[PATCH v5 1/4] fs/splice: introduce pages_to_pipe helper

Signed-off-by: Mike Rapoport --- fs/splice.c | 57 - 1 file changed, 36 insertions(+), 21 deletions(-) diff --git a/fs/splice.c b/fs/splice.c index 39e2dc01ac12..7f1ffc50ff1d 100644 --- a/fs/splice.c +++

[PATCH v5 1/4] fs/splice: introduce pages_to_pipe helper

Signed-off-by: Mike Rapoport --- fs/splice.c | 57 - 1 file changed, 36 insertions(+), 21 deletions(-) diff --git a/fs/splice.c b/fs/splice.c index 39e2dc01ac12..7f1ffc50ff1d 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -1185,6 +1185,36

[PATCH v5 3/4] x86: wire up the process_vmsplice syscall

From: Andrei Vagin Signed-off-by: Andrei Vagin --- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/x86/entry/syscalls/syscall_32.tbl

[PATCH v5 2/4] vm: add a syscall to map a process memory into a pipe

From: Andrei Vagin It is a hybrid of process_vm_readv() and vmsplice(). vmsplice can map memory from a current address space into a pipe. process_vm_readv can read memory of another process. A new system call can map memory of another process into a pipe. ssize_t

[PATCH v5 3/4] x86: wire up the process_vmsplice syscall

From: Andrei Vagin Signed-off-by: Andrei Vagin --- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index

[PATCH v5 2/4] vm: add a syscall to map a process memory into a pipe

From: Andrei Vagin It is a hybrid of process_vm_readv() and vmsplice(). vmsplice can map memory from a current address space into a pipe. process_vm_readv can read memory of another process. A new system call can map memory of another process into a pipe. ssize_t process_vmsplice(pid_t pid,

[PATCH v7 5/9] dmtimer: Add timer ops to the platform data structure

Add timer ops to the platform data structure Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- include/linux/platform_data/dmtimer-omap.h | 38 ++ 1 file

[PATCH v7 5/9] dmtimer: Add timer ops to the platform data structure

Add timer ops to the platform data structure Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- include/linux/platform_data/dmtimer-omap.h | 38 ++ 1 file changed, 38 insertions(+) diff --git

[PATCH v7 4/9] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource

Move the dmtimer driver out of plat-omap to clocksource. So that non-omap devices also could use this. No Code changes done to the driver file only renamed to timer-dm.c. Also removed the config dependencies for OMAP_DM_TIMER. Signed-off-by: Keerthy Reviewed-by: Sebastian

[PATCH v7 4/9] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource

Move the dmtimer driver out of plat-omap to clocksource. So that non-omap devices also could use this. No Code changes done to the driver file only renamed to timer-dm.c. Also removed the config dependencies for OMAP_DM_TIMER. Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by:

[PATCH v7 6/9] clocksource: dmtimer: Populate the timer ops to the pdata

Add the timer ops to the platform data Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- drivers/clocksource/timer-dm.c | 25 + 1 file changed, 25 insertions(+)

[PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

The header file is currently under plat-omap directory under arch/omap. Move this out to an accessible place. No Code changes done to the header file. Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl

[PATCH v7 6/9] clocksource: dmtimer: Populate the timer ops to the pdata

Add the timer ops to the platform data Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- drivers/clocksource/timer-dm.c | 25 + 1 file changed, 25 insertions(+) diff --git a/drivers/clocksource/timer-dm.c

[PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

The header file is currently under plat-omap directory under arch/omap. Move this out to an accessible place. No Code changes done to the header file. Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- arch/arm/mach-omap1/pm.c

[PATCH v7 9/9] arm: omap: pdata-quirks: Remove unused timer pdata

Remove unused timer pdata. Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- arch/arm/mach-omap2/pdata-quirks.c | 32 1 file changed, 32 deletions(-)

[PATCH v7 8/9] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks. Signed-off-by: Keerthy Acked-by: Neil Armstrong Reviewed-by: Claudiu Beznea --- drivers/pwm/pwm-omap-dmtimer.c | 68

[PATCH v7 9/9] arm: omap: pdata-quirks: Remove unused timer pdata

Remove unused timer pdata. Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- arch/arm/mach-omap2/pdata-quirks.c | 32 1 file changed, 32 deletions(-) diff --git a/arch/arm/mach-omap2/pdata-quirks.c

[PATCH v7 8/9] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks. Signed-off-by: Keerthy Acked-by: Neil Armstrong Reviewed-by: Claudiu Beznea --- drivers/pwm/pwm-omap-dmtimer.c | 68 ++ 1 file changed, 43 insertions(+), 25 deletions(-) diff --git

[PATCH v7 0/9] omap: dmtimer: Move driver out of plat-omap

The series moves dmtimer out of plat-omap to drivers/clocksource. The series also does a bunch of changes to pwm-omap-dmtimer code to adapt to the driver migration and clean up plat specific pdata-quirks and use the dmtimer platform data. Boot tested on DRA7-EVM and AM437X-GP-EVM. Compile tested

[PATCH v7 1/9] clocksource: dmtimer: Remove all the exports

Remove all the unwanted exports from the driver Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- arch/arm/plat-omap/dmtimer.c | 27 --- 1 file changed, 27

[PATCH v7 2/9] arm: omap: timer: Wrap the inline functions under OMAP2PLUS define

Wrap the inline functions under OMAP2PLUS/OMAP1 defines. Signed-off-by: Keerthy Tested-by: Ladislav Michl --- arch/arm/plat-omap/include/plat/dmtimer.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[PATCH v7 1/9] clocksource: dmtimer: Remove all the exports

Remove all the unwanted exports from the driver Signed-off-by: Keerthy Reviewed-by: Sebastian Reichel Tested-by: Ladislav Michl --- arch/arm/plat-omap/dmtimer.c | 27 --- 1 file changed, 27 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c

[PATCH v7 0/9] omap: dmtimer: Move driver out of plat-omap

The series moves dmtimer out of plat-omap to drivers/clocksource. The series also does a bunch of changes to pwm-omap-dmtimer code to adapt to the driver migration and clean up plat specific pdata-quirks and use the dmtimer platform data. Boot tested on DRA7-EVM and AM437X-GP-EVM. Compile tested

[PATCH v7 2/9] arm: omap: timer: Wrap the inline functions under OMAP2PLUS define

Wrap the inline functions under OMAP2PLUS/OMAP1 defines. Signed-off-by: Keerthy Tested-by: Ladislav Michl --- arch/arm/plat-omap/include/plat/dmtimer.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h

[PATCH v7 7/9] clocksource: timer-dm: Hook device platform data if not already assigned

From: Ladislav Michl In the case of device tree boot the device platform data is usually NULL so hook the platform data obtained from the match. As part of un-constify the platform_data pointer. Signed-off-by: Ladislav Michl Signed-off-by: Keerthy

[PATCH v7 7/9] clocksource: timer-dm: Hook device platform data if not already assigned

From: Ladislav Michl In the case of device tree boot the device platform data is usually NULL so hook the platform data obtained from the match. As part of un-constify the platform_data pointer. Signed-off-by: Ladislav Michl Signed-off-by: Keerthy --- drivers/clocksource/timer-dm.c | 10

[PATCH net-next 1/2] Revert "net: hns3: Add packet statistics of netdev"

This reverts commit 8491000754796c838a0081c267f9dd54ad2ccba3. It is duplicate to add statistics of netdev for ethtool -S. Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 80 +- 1 file changed, 1 insertion(+), 79

[PATCH net-next 2/2] net: hns3: report the function type the same line with hns3_nic_get_stats64

The function type should be on the same line with the function name, or it may cause display error if a patch edit the function. There is am example following: https://www.spinics.net/lists/netdev/msg476141.html Signed-off-by: Peng Li ---

[PATCH net-next 1/2] Revert "net: hns3: Add packet statistics of netdev"

This reverts commit 8491000754796c838a0081c267f9dd54ad2ccba3. It is duplicate to add statistics of netdev for ethtool -S. Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 80 +- 1 file changed, 1 insertion(+), 79 deletions(-) diff --git

[PATCH net-next 2/2] net: hns3: report the function type the same line with hns3_nic_get_stats64

The function type should be on the same line with the function name, or it may cause display error if a patch edit the function. There is am example following: https://www.spinics.net/lists/netdev/msg476141.html Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ++--

[PATCH net-next 0/2] code improvements in HNS3 driver

This patchset fixes 2 comments for community review. [patch 1/2] reverts "net: hns3: Add packet statistics of netdev" reported by Jakub Kicinski and David Miller. [patch 2/2] reports the function type the same line with hns3_nic_get_stats64, reported by Andrew Lunn. Peng Li (2): Revert "net:

[PATCH net-next 0/2] code improvements in HNS3 driver

This patchset fixes 2 comments for community review. [patch 1/2] reverts "net: hns3: Add packet statistics of netdev" reported by Jakub Kicinski and David Miller. [patch 2/2] reports the function type the same line with hns3_nic_get_stats64, reported by Andrew Lunn. Peng Li (2): Revert "net:

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

On 01/08/18 19:13, shufan_lee(李書帆) wrote: > From: ShuFan Lee > > Richtek RT1711H Type-C chip driver that works with > Type-C Port Controller Manager to provide USB PD and > USB Type-C functionalities. > > Signed-off-by: ShuFan Lee > ---​ > >

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On 01/06/18 at 02:00am, Jiri Bohac wrote: > Hi Baoquan, > > thank you very much for your review! > > On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > > > 1) If 'iommu=off' is specified in 1st kernel but not in kdump kernel, it > > > > will ignore the ram we need dump. > > > > > >

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

On 01/08/18 19:13, shufan_lee(李書帆) wrote: > From: ShuFan Lee > > Richtek RT1711H Type-C chip driver that works with > Type-C Port Controller Manager to provide USB PD and > USB Type-C functionalities. > > Signed-off-by: ShuFan Lee > ---​ > >

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On 01/06/18 at 02:00am, Jiri Bohac wrote: > Hi Baoquan, > > thank you very much for your review! > > On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > > > 1) If 'iommu=off' is specified in 1st kernel but not in kdump kernel, it > > > > will ignore the ram we need dump. > > > > > >

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote: > On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote: > > Hi Olsa, > > What about this fix now? Thanks! > > > > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote: > > > From: Changbin Du

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote: > On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote: > > Hi Olsa, > > What about this fix now? Thanks! > > > > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote: > > > From: Changbin Du > > > > > > The

Re: [PATCH V2 1/5] bindings: regulator: added support for suspend states

On 8 January 2018 at 20:35, Mark Brown wrote: > On Mon, Jan 08, 2018 at 02:36:36PM +0800, Chunyan Zhang wrote: >> On 6 January 2018 at 03:18, Mark Brown wrote: > >> > No, it means that the software has permission to use those changes to >> > those

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On 3 January 2018 at 12:06, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > One of the limitations of pm_runtime_force_suspend/resume() is that > if a parent driver wants to use these functions, all of its child > drivers have to do that too

Re: [PATCH V2 1/5] bindings: regulator: added support for suspend states

On 8 January 2018 at 20:35, Mark Brown wrote: > On Mon, Jan 08, 2018 at 02:36:36PM +0800, Chunyan Zhang wrote: >> On 6 January 2018 at 03:18, Mark Brown wrote: > >> > No, it means that the software has permission to use those changes to >> > those registers - we only want to be changing things

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On 3 January 2018 at 12:06, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > One of the limitations of pm_runtime_force_suspend/resume() is that > if a parent driver wants to use these functions, all of its child > drivers have to do that too because of the parent usage counter >

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

On 01/08/2018 05:09 PM, Michael Ellerman wrote: > Thomas Gleixner writes: > >> On Tue, 9 Jan 2018, Michael Ellerman wrote: >> >> Sorry, I wasn't aware about your efforts and did not cc you. I've just >> queued a more generic sysfs interface for this whole mess: > > No

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

On 01/08/2018 05:09 PM, Michael Ellerman wrote: > Thomas Gleixner writes: > >> On Tue, 9 Jan 2018, Michael Ellerman wrote: >> >> Sorry, I wasn't aware about your efforts and did not cc you. I've just >> queued a more generic sysfs interface for this whole mess: > > No worries. > >>

[RESEND PATCH] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.

Pin function can not be match correctly when SUNXI_PIN describe with mutiple variant and same function. such as: on pinctrl-sun4i-a10.c SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"),

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

Hi tejun Many thanks for your kindly response. On 01/09/2018 11:37 AM, Tejun Heo wrote: > Hello, > > On Tue, Jan 09, 2018 at 11:08:04AM +0800, jianchao.wang wrote: >>> But what'd prevent the completion reinitializing the request and then >>> the actual completion path coming in and completing

[RESEND PATCH] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.

Pin function can not be match correctly when SUNXI_PIN describe with mutiple variant and same function. such as: on pinctrl-sun4i-a10.c SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"),

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

Hi tejun Many thanks for your kindly response. On 01/09/2018 11:37 AM, Tejun Heo wrote: > Hello, > > On Tue, Jan 09, 2018 at 11:08:04AM +0800, jianchao.wang wrote: >>> But what'd prevent the completion reinitializing the request and then >>> the actual completion path coming in and completing

Re: WARNING: held lock freed!

On Mon, Jan 8, 2018 at 8:09 PM, Marcelo Ricardo Leitner wrote: > On Mon, Jan 08, 2018 at 06:01:14PM +0800, Xin Long wrote: >> On Mon, Jan 8, 2018 at 6:58 AM, syzbot >> wrote: >> > Hello, >> > >> > syzkaller hit the

Re: WARNING: held lock freed!

On Mon, Jan 8, 2018 at 8:09 PM, Marcelo Ricardo Leitner wrote: > On Mon, Jan 08, 2018 at 06:01:14PM +0800, Xin Long wrote: >> On Mon, Jan 8, 2018 at 6:58 AM, syzbot >> wrote: >> > Hello, >> > >> > syzkaller hit the following crash on >> > 3219e264b984ec0a13923aa66385819c2e98d582 >> >

  1   2   3   4   5   6   7   8   9   10   >