[PATCH] staging : rtl8188eu : remove void function return

kernel coding style doesn't allow the return statement in void function. Signed-off-by: Surender Polsani --- Changes for v2: corrected subject line as suggested Changes for v3: modified from line as suggested by Greg KH placed a semicolon in label for fixing build

[PATCH] staging : rtl8188eu : remove void function return

kernel coding style doesn't allow the return statement in void function. Signed-off-by: Surender Polsani --- Changes for v2: corrected subject line as suggested Changes for v3: modified from line as suggested by Greg KH placed a semicolon in label for fixing build error ---

linux-next: Tree for May 3

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170502: The kbuild tree gained a conflict against Linus' tree. The metag tree gained a conflict against Linus' tree. The nfs tree gained

linux-next: Tree for May 3

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170502: The kbuild tree gained a conflict against Linus' tree. The metag tree gained a conflict against Linus' tree. The nfs tree gained

Re: linux-next: build warning after merge of the devicetree tree

Hi Rob, On Fri, 28 Apr 2017 12:45:03 +1000 Stephen Rothwell wrote: > > After merging the devicetree tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/of/unittest.c: In function 'of_unittest': > drivers/of/unittest.c:2199:25:

Re: linux-next: build warning after merge of the devicetree tree

Hi Rob, On Fri, 28 Apr 2017 12:45:03 +1000 Stephen Rothwell wrote: > > After merging the devicetree tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/of/unittest.c: In function 'of_unittest': > drivers/of/unittest.c:2199:25: warning: 'last_sibling' may

Re: [RFC PATCH 8/9] debugfs: defer debugfs_fsdata allocation to first usage

On Tue, 2017-05-02 at 22:05 +0200, Nicolai Stange wrote: > > So either you could return some valid ops (perhaps > > debugfs_noop_file_operations although those don't have .name or > > .poll, so it doesn't cover everything), or you can just BUG_ON() > > here directly, saving the incomprehensible

Re: [RFC PATCH 8/9] debugfs: defer debugfs_fsdata allocation to first usage

On Tue, 2017-05-02 at 22:05 +0200, Nicolai Stange wrote: > > So either you could return some valid ops (perhaps > > debugfs_noop_file_operations although those don't have .name or > > .poll, so it doesn't cover everything), or you can just BUG_ON() > > here directly, saving the incomprehensible

Re: [PATCH v2] iio: adc: Add support for TI ADC1x8s102

On 2017-05-02 22:53, Andy Shevchenko wrote: > On Tue, May 2, 2017 at 11:02 PM, Jan Kiszka wrote: >> This is an upstream port of an IIO driver for the TI ADC108S102 and >> ADC128S102. The former can be found on the Intel Galileo Gen2 and the >> Siemens SIMATIC IOT2000. For

Re: [PATCH v2] iio: adc: Add support for TI ADC1x8s102

On 2017-05-02 22:53, Andy Shevchenko wrote: > On Tue, May 2, 2017 at 11:02 PM, Jan Kiszka wrote: >> This is an upstream port of an IIO driver for the TI ADC108S102 and >> ADC128S102. The former can be found on the Intel Galileo Gen2 and the >> Siemens SIMATIC IOT2000. For those boards, ACPI-based

[PATCH v3 4/4] rpmsg: Introduce Qualcomm RPM glink driver

This introduces a basic driver for communicating over "native glink" with the RPM found in Qualcomm platforms. Signed-off-by: Bjorn Andersson --- Changes since v2: - Replace syscon with apcs_ipc doorbell implementation Changes since v1: - Depend on HAS_IOMEM, for UM

[PATCH v3 3/4] soc: qcom: Add device tree binding for GLINK RPM

Add device tree binding documentation for the Qualcomm GLINK RPM, used for communication with the Resource Power Management subsystem in various Qualcomm SoCs. Signed-off-by: Bjorn Andersson --- Changes since v2: - Replace qcom,ipc syscon with a "doorbell" Changes

[PATCH v3 3/4] soc: qcom: Add device tree binding for GLINK RPM

Add device tree binding documentation for the Qualcomm GLINK RPM, used for communication with the Resource Power Management subsystem in various Qualcomm SoCs. Signed-off-by: Bjorn Andersson --- Changes since v2: - Replace qcom,ipc syscon with a "doorbell" Changes since v1: - None

[PATCH v3 4/4] rpmsg: Introduce Qualcomm RPM glink driver

This introduces a basic driver for communicating over "native glink" with the RPM found in Qualcomm platforms. Signed-off-by: Bjorn Andersson --- Changes since v2: - Replace syscon with apcs_ipc doorbell implementation Changes since v1: - Depend on HAS_IOMEM, for UM build failure - Wrap

[PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver

This implements a driver that exposes the IPC bits found in the APCS Global block in various Qualcomm platforms. The bits are used to signal inter-processor communication signals from the application CPU to other masters. The driver implements the "doorbell" binding and could be used as basis for

[PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver

This implements a driver that exposes the IPC bits found in the APCS Global block in various Qualcomm platforms. The bits are used to signal inter-processor communication signals from the application CPU to other masters. The driver implements the "doorbell" binding and could be used as basis for

[PATCH v3 1/4] dt-bindings: Introduce doorbell binding

Introduce the generic doorbell binding as well as a binding for the Qualcomm APCS Global block. This is used to expose doorbell-like devices in the system. Signed-off-by: Bjorn Andersson --- Changes since v2: - New binding

[PATCH v3 1/4] dt-bindings: Introduce doorbell binding

Introduce the generic doorbell binding as well as a binding for the Qualcomm APCS Global block. This is used to expose doorbell-like devices in the system. Signed-off-by: Bjorn Andersson --- Changes since v2: - New binding .../devicetree/bindings/doorbell/doorbell.txt | 31

Re: [PATCH] ia64: beatify build log for gate.so and gate-syms.o

2017-04-12 8:36 GMT+09:00 Masahiro Yamada : > Currently, the object path is not aligned in the build log: > > LDS arch/ia64/kernel/gate.lds > AS arch/ia64/kernel/gate.o > GATE arch/ia64/kernel/gate.so > AS arch/ia64/kernel/gate-data.o > >

Re: [PATCH] ia64: beatify build log for gate.so and gate-syms.o

2017-04-12 8:36 GMT+09:00 Masahiro Yamada : > Currently, the object path is not aligned in the build log: > > LDS arch/ia64/kernel/gate.lds > AS arch/ia64/kernel/gate.o > GATE arch/ia64/kernel/gate.so > AS arch/ia64/kernel/gate-data.o > > Signed-off-by: Masahiro Yamada > ---

Re: [PATCH 0/3] alpha: improvements of arch/alpha/lib/Makefile

2016-09-11 16:42 GMT+09:00 Masahiro Yamada : > While building for Alpha architecture, I noticed ugly long log > for division routines. So, I took a look at the Makefile. > Here is a series of build rule cleanups. > > > Masahiro Yamada (3): > alpha: add $(src)/

Re: [PATCH 0/3] alpha: improvements of arch/alpha/lib/Makefile

2016-09-11 16:42 GMT+09:00 Masahiro Yamada : > While building for Alpha architecture, I noticed ugly long log > for division routines. So, I took a look at the Makefile. > Here is a series of build rule cleanups. > > > Masahiro Yamada (3): > alpha: add $(src)/ rather than $(obj)/ to make source

Re: [PATCH] hexagon: Use raw_copy_to_user

On Tue, May 02, 2017 at 08:52:48PM -0700, Guenter Roeck wrote: > Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced > __copy_to_user_hexagon() with raw_copy_to_user(), but did not catch > all callers, resulting in the following build error. > > arch/hexagon/mm/uaccess.c: In

Re: [PATCH] hexagon: Use raw_copy_to_user

On Tue, May 02, 2017 at 08:52:48PM -0700, Guenter Roeck wrote: > Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced > __copy_to_user_hexagon() with raw_copy_to_user(), but did not catch > all callers, resulting in the following build error. > > arch/hexagon/mm/uaccess.c: In

Re: [PATCH v6 0/4] Broadcom SBA RAID support

On Wed, May 3, 2017 at 10:29 AM, Vinod Koul wrote: > On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote: >> Hi Vinod, >> >> The Broadcom FlexRM patchset have been >> merged in v4.11. >> >> I think you now can take this patchset in next >> merge window. Right?? > >

Re: [PATCH v6 0/4] Broadcom SBA RAID support

On Wed, May 3, 2017 at 10:29 AM, Vinod Koul wrote: > On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote: >> Hi Vinod, >> >> The Broadcom FlexRM patchset have been >> merged in v4.11. >> >> I think you now can take this patchset in next >> merge window. Right?? > > Sure, please rebase and

Re: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza

Re: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza

Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters

I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza

Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters

I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza

Re: [PATCH v6 0/4] Broadcom SBA RAID support

On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote: > Hi Vinod, > > The Broadcom FlexRM patchset have been > merged in v4.11. > > I think you now can take this patchset in next > merge window. Right?? Sure, please rebase and resend after -rc1 is out -- ~Vinod

Re: [PATCH v6 0/4] Broadcom SBA RAID support

On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote: > Hi Vinod, > > The Broadcom FlexRM patchset have been > merged in v4.11. > > I think you now can take this patchset in next > merge window. Right?? Sure, please rebase and resend after -rc1 is out -- ~Vinod

Re: I'd like to donate a MacBook Pro

2017-05-01 3:03 GMT-06:00 Lukas Wunner : > On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote: >> I am confident that this is a common problem because I have found >> various other users complaining about it: >> >> https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363 >>

Re: I'd like to donate a MacBook Pro

2017-05-01 3:03 GMT-06:00 Lukas Wunner : > On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote: >> I am confident that this is a common problem because I have found >> various other users complaining about it: >> >> https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363 >>

Re: [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters

On Mon, Apr 24, 2017 at 7:50 PM, Rob Herring wrote: > On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep wrote: >> current device frmework and of framework integration assumes dma-ranges >> in a way where memory-mapped devices define their dma-ranges. >>

Re: [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters

On Mon, Apr 24, 2017 at 7:50 PM, Rob Herring wrote: > On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep wrote: >> current device frmework and of framework integration assumes dma-ranges >> in a way where memory-mapped devices define their dma-ranges. >> dma-ranges: (child-bus-address,

Re: [PATCH] Makefile: evaluate LDFLAGS_BUILD_ID only once

2017-05-01 1:16 GMT+09:00 Rabin Vincent : > Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only > once instead of over and over. > > This provides a ~20% reduction in null build time with x86 allnoconfig: > > $ make allnoconfig && make -j8 > $ perf stat -r5 -e

Re: [PATCH] Makefile: evaluate LDFLAGS_BUILD_ID only once

2017-05-01 1:16 GMT+09:00 Rabin Vincent : > Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only > once instead of over and over. > > This provides a ~20% reduction in null build time with x86 allnoconfig: > > $ make allnoconfig && make -j8 > $ perf stat -r5 -e

Re: [PATCH] vmscan: scan pages until it founds eligible pages

On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote: > On Tue 02-05-17 23:51:50, Minchan Kim wrote: > > Hi Michal, > > > > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote: > > > On Tue 02-05-17 14:14:52, Minchan Kim wrote: > > > > Oops, forgot to add lkml and linux-mm. > > >

Re: [PATCH] vmscan: scan pages until it founds eligible pages

On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote: > On Tue 02-05-17 23:51:50, Minchan Kim wrote: > > Hi Michal, > > > > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote: > > > On Tue 02-05-17 14:14:52, Minchan Kim wrote: > > > > Oops, forgot to add lkml and linux-mm. > > >

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

On 02/05/17 19:23, Boris Ostrovsky wrote: > Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and > 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. > Since guest-type-neutral code refers to this variable this causes > build failures when CONFIG_XEN_PVHVM is not defined. >

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

On 02/05/17 19:23, Boris Ostrovsky wrote: > Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and > 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. > Since guest-type-neutral code refers to this variable this causes > build failures when CONFIG_XEN_PVHVM is not defined. >

[PATCH 2/3] iommu/pci: reserve iova for PCI masters

this patch reserves the iova for PCI masters. ARM64 based SOCs may have scattered memory banks. such as iproc based SOC has <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */ <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */ <0x0090 0x 0x4 0x>, /* 16G @ 576G */

[PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and of framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and of framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH 2/3] iommu/pci: reserve iova for PCI masters

this patch reserves the iova for PCI masters. ARM64 based SOCs may have scattered memory banks. such as iproc based SOC has <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */ <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */ <0x0090 0x 0x4 0x>, /* 16G @ 576G */

[PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and of framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and of framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

Re: [PATCH 1/1] objtool: make it visible in make V=1 output

2017-04-22 0:16 GMT+09:00 Jiri Slaby : > It is currently impossible to see what is going on with objtool when > building, so call echo-cmd to see the actions: > gcc -Wp,-MD,arch/x86/entry/.entry_64.o.d -nostdinc -isystem ... > ./tools/objtool/objtool check

Re: [PATCH 1/1] objtool: make it visible in make V=1 output

2017-04-22 0:16 GMT+09:00 Jiri Slaby : > It is currently impossible to see what is going on with objtool when > building, so call echo-cmd to see the actions: > gcc -Wp,-MD,arch/x86/entry/.entry_64.o.d -nostdinc -isystem ... > ./tools/objtool/objtool check "arch/x86/entry/entry_64.o"; > >

Re: [PATCH 1/2] kbuild: cleanup signing keys with mrproper

+CC David Woodhouse +CC David Howells 2017-04-15 6:54 GMT+09:00 Stephen Hemminger : > When 'make mrproper' is run it was supposed to remove the signing > keys in the certs directory, but only the filename is given > rather than the pathanme which is necessary to cause

Re: [PATCH 1/2] kbuild: cleanup signing keys with mrproper

+CC David Woodhouse +CC David Howells 2017-04-15 6:54 GMT+09:00 Stephen Hemminger : > When 'make mrproper' is run it was supposed to remove the signing > keys in the certs directory, but only the filename is given > rather than the pathanme which is necessary to cause cleanup. > > Signed-off-by:

Re: [PATCH 2/2] kbuild: remove initramfs cpio with mrproper

Hi Stephen, 2017-04-15 6:54 GMT+09:00 Stephen Hemminger : > When 'make mrproper' is done, it should also remove the initramfs cpio > file. I ran into this while doing test build on one machine, followed > by make mrproper and rsync to a target machine. The build on

Re: [PATCH 2/2] kbuild: remove initramfs cpio with mrproper

Hi Stephen, 2017-04-15 6:54 GMT+09:00 Stephen Hemminger : > When 'make mrproper' is done, it should also remove the initramfs cpio > file. I ran into this while doing test build on one machine, followed > by make mrproper and rsync to a target machine. The build on the target > machine would

Re: linux-next: manual merge of the net-next tree with Linus' tree

From: Stephen Rothwell Date: Wed, 3 May 2017 11:07:03 +1000 > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > arch/avr32/include/uapi/asm/socket.h > > between commit: > > 26202873bb51 ("avr32: remove support for AVR32 architecture")

Re: linux-next: manual merge of the net-next tree with Linus' tree

From: Stephen Rothwell Date: Wed, 3 May 2017 11:07:03 +1000 > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > arch/avr32/include/uapi/asm/socket.h > > between commit: > > 26202873bb51 ("avr32: remove support for AVR32 architecture") > > from Linus' tree

Re: [PATCH 2/7] perf config: Check list empty before showing configs

Hi Arnaldo, On 05/03/2017 12:12 AM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 26, 2017 at 09:21:03PM +0900, Taeung Song escreveu: If existent config files contains nothing, the sections list in config_set can be empty. So check not only NULL pointer of config_set but also the list in

Re: [PATCH 2/7] perf config: Check list empty before showing configs

Hi Arnaldo, On 05/03/2017 12:12 AM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 26, 2017 at 09:21:03PM +0900, Taeung Song escreveu: If existent config files contains nothing, the sections list in config_set can be empty. So check not only NULL pointer of config_set but also the list in

[PATCH] drivers/crypto/ccp: return NULL instead of 0

This change is to handle sparse warning. Return type of function is a pointer to the structure and it returns 0. Instead it should return NULL. Signed-off-by: Pushkar Jambhlekar --- drivers/crypto/ccp/ccp-platform.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH] drivers/crypto/ccp: return NULL instead of 0

This change is to handle sparse warning. Return type of function is a pointer to the structure and it returns 0. Instead it should return NULL. Signed-off-by: Pushkar Jambhlekar --- drivers/crypto/ccp/ccp-platform.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

On 02/05/17 19:23, Boris Ostrovsky wrote: > Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and > 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. > Since guest-type-neutral code refers to this variable this causes > build failures when CONFIG_XEN_PVHVM is not defined. >

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

On 02/05/17 19:23, Boris Ostrovsky wrote: > Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and > 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. > Since guest-type-neutral code refers to this variable this causes > build failures when CONFIG_XEN_PVHVM is not defined. >

[PATCH] hexagon: Use raw_copy_to_user

Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced __copy_to_user_hexagon() with raw_copy_to_user(), but did not catch all callers, resulting in the following build error. arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon': arch/hexagon/mm/uaccess.c:40:3: error:

[PATCH] hexagon: Use raw_copy_to_user

Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced __copy_to_user_hexagon() with raw_copy_to_user(), but did not catch all callers, resulting in the following build error. arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon': arch/hexagon/mm/uaccess.c:40:3: error:

RE: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors

> -Original Message- > From: Leonard Crestez [mailto:leonard.cres...@nxp.com] > Sent: Tuesday, May 02, 2017 10:46 PM > To: Shawn Guo > Cc: Leonard Crestez; Sascha Hauer; Jagan Teki; Fabio Estevam; Dong Aisheng; > linux-arm-ker...@lists.infradead.org; linux...@vger.kernel.org; linux- >

RE: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors

> -Original Message- > From: Leonard Crestez [mailto:leonard.cres...@nxp.com] > Sent: Tuesday, May 02, 2017 10:46 PM > To: Shawn Guo > Cc: Leonard Crestez; Sascha Hauer; Jagan Teki; Fabio Estevam; Dong Aisheng; > linux-arm-ker...@lists.infradead.org; linux...@vger.kernel.org; linux- >

Re: [PATCH v6 0/4] Broadcom SBA RAID support

Hi Vinod, The Broadcom FlexRM patchset have been merged in v4.11. I think you now can take this patchset in next merge window. Right?? Regards, Anup

Re: [PATCH v6 0/4] Broadcom SBA RAID support

Hi Vinod, The Broadcom FlexRM patchset have been merged in v4.11. I think you now can take this patchset in next merge window. Right?? Regards, Anup

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

On Tue, 2017-05-02 at 21:06 -0500, Mike Christie wrote: > On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote: > > From: Xiubo Li > > > > For the "struct tcmu_cmd_entry" in cmd area, the minimum size > > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

On Tue, 2017-05-02 at 21:06 -0500, Mike Christie wrote: > On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote: > > From: Xiubo Li > > > > For the "struct tcmu_cmd_entry" in cmd area, the minimum size > > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And it could > > fill about

Re: [PATCH] x86/intel_rdt: Fix two typos in Documentation

Sorry, please ignore this patch. The first typo in this patch has been already fixed by: a9cad3d4f046 ("Documentation, x86: Intel Memory bandwidth allocation") A new patch is submitted to address the other typo left over: https://lkml.org/lkml/2017/5/2/595 Best regards Xiaochen Shen On

Re: [PATCH] x86/intel_rdt: Fix two typos in Documentation

Sorry, please ignore this patch. The first typo in this patch has been already fixed by: a9cad3d4f046 ("Documentation, x86: Intel Memory bandwidth allocation") A new patch is submitted to address the other typo left over: https://lkml.org/lkml/2017/5/2/595 Best regards Xiaochen Shen On

[PATCH] staging: unisys: Solve sparse warning

The following commit fixes the following sparse report: drivers/staging//unisys/visorhba/visorhba_main.c:660:29: warning: cast to restricted __le64 by casting readq (which is unsigned long on x86) to u64, as expected by the seq_printf call. Signed-off-by: Marcos Paulo de Souza

[PATCH] staging: unisys: Solve sparse warning

The following commit fixes the following sparse report: drivers/staging//unisys/visorhba/visorhba_main.c:660:29: warning: cast to restricted __le64 by casting readq (which is unsigned long on x86) to u64, as expected by the seq_printf call. Signed-off-by: Marcos Paulo de Souza --- Just

Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > One of the possible output of the display pipeline, on the SoCs that have > it, is the HDMI controller. > > Add a binding for it. > > Signed-off-by: Maxime Ripard > --- >

Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > One of the possible output of the display pipeline, on the SoCs that have > it, is the HDMI controller. > > Add a binding for it. > > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 21

Re: [PATCH 03/13 V2] blk: make the bioset rescue_workqueue optional.

On Wed, May 3, 2017 at 6:34 AM, NeilBrown wrote: > From 09017acf74ec4df674b78ca66f0924187f10d8a4 Mon Sep 17 00:00:00 2001 > From: NeilBrown > Date: Fri, 10 Mar 2017 13:59:50 +1100 > Subject: [PATCH] blk: make the bioset rescue_workqueue optional. > > This patch

Re: [PATCH 03/13 V2] blk: make the bioset rescue_workqueue optional.

On Wed, May 3, 2017 at 6:34 AM, NeilBrown wrote: > From 09017acf74ec4df674b78ca66f0924187f10d8a4 Mon Sep 17 00:00:00 2001 > From: NeilBrown > Date: Fri, 10 Mar 2017 13:59:50 +1100 > Subject: [PATCH] blk: make the bioset rescue_workqueue optional. > > This patch converts bioset_create() to not

[PATCH] powerpc/powernv: Fix TCE kill on NVLink2

Commit 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2") forced all TCE kills to go via the OPAL call for NVLink2. However the PHB3 implementation of TCE kill was still being called directly from some functions which in some circumstances caused a machine check. This patch

[PATCH] powerpc/powernv: Fix TCE kill on NVLink2

Commit 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2") forced all TCE kills to go via the OPAL call for NVLink2. However the PHB3 implementation of TCE kill was still being called directly from some functions which in some circumstances caused a machine check. This patch

[PATCH v2 1/8] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU

The A83T clock control unit is a hybrid of some new style clock designs from the A80, and old style layout from the other Allwinner SoCs. Like the A80, the SoC does not have a low speed 32.768 kHz oscillator. Unlike the A80, there is no clock input either. The only low speed clock available is

[PATCH v2 6/8] ARM: sun8i: a83t: Add CCU device nodes

Now that we have support for the A83T CCU, add a device node for it, and replace any existing placeholder clock phandles with the correct ones. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-)

[PATCH v2 6/8] ARM: sun8i: a83t: Add CCU device nodes

Now that we have support for the A83T CCU, add a device node for it, and replace any existing placeholder clock phandles with the correct ones. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git

[PATCH v2 1/8] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU

The A83T clock control unit is a hybrid of some new style clock designs from the A80, and old style layout from the other Allwinner SoCs. Like the A80, the SoC does not have a low speed 32.768 kHz oscillator. Unlike the A80, there is no clock input either. The only low speed clock available is

Re: [PATCH 0/6] mailbox: arm_mhu: add support for subchannels

Hi Sudeep, On Tue, May 2, 2017 at 7:25 PM, Sudeep Holla wrote: > Hi Jassi, > > This series adds subchannel support to ARM MHU mailbox controller > driver. Since SCPI never used second slot, we were able to use the > existing driver as is. However, that's changing soon and

Re: [PATCH 0/6] mailbox: arm_mhu: add support for subchannels

Hi Sudeep, On Tue, May 2, 2017 at 7:25 PM, Sudeep Holla wrote: > Hi Jassi, > > This series adds subchannel support to ARM MHU mailbox controller > driver. Since SCPI never used second slot, we were able to use the > existing driver as is. However, that's changing soon and the new > SCMI protocol

[PATCH v2 8/8] ARM: sun8i: a83t: Switch to CCU device tree binding macros

Now that the CCU device tree binding headers have been merged, we can use the properly named macros in the device tree, instead of raw numbers. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff

[PATCH v2 7/8] ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator

The datasheets for Allwinner SoCs set strict requirements on the stability of the external crystal oscillators. Add the accuracy for the main 24MHz oscillator to the device tree. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 1 + 1 file changed, 1

[PATCH v2 5/8] clk: sunxi-ng: Add driver for A83T CCU

The A83T clock control unit is a hybrid of some new style clock designs from the A80, and old style layout from the other Allwinner SoCs. Like the A80, the SoC does not have a low speed 32.768 kHz oscillator. Unlike the A80, there is no clock input either. The only low speed clock available is

[PATCH v2 8/8] ARM: sun8i: a83t: Switch to CCU device tree binding macros

Now that the CCU device tree binding headers have been merged, we can use the properly named macros in the device tree, instead of raw numbers. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[PATCH v2 7/8] ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator

The datasheets for Allwinner SoCs set strict requirements on the stability of the external crystal oscillators. Add the accuracy for the main 24MHz oscillator to the device tree. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v2 5/8] clk: sunxi-ng: Add driver for A83T CCU

The A83T clock control unit is a hybrid of some new style clock designs from the A80, and old style layout from the other Allwinner SoCs. Like the A80, the SoC does not have a low speed 32.768 kHz oscillator. Unlike the A80, there is no clock input either. The only low speed clock available is

[PATCH v2 4/8] clk: sunxi-ng: Support multiple variable pre-dividers

On the A83T, the AHB1 clock has a shared pre-divider on the two PLL-PERIPH clock parents. To support such instances of shared pre-dividers, this patch extends the mux clock type to support multiple variable pre-dividers. As the pre-dividers are only used to calculate the rate, but do not

[PATCH v2 4/8] clk: sunxi-ng: Support multiple variable pre-dividers

On the A83T, the AHB1 clock has a shared pre-divider on the two PLL-PERIPH clock parents. To support such instances of shared pre-dividers, this patch extends the mux clock type to support multiple variable pre-dividers. As the pre-dividers are only used to calculate the rate, but do not

[PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

The MMC clocks on newer SoCs, such as the A83T and H3, support the "new timing mode". Under this mode, the output of the clock is divided by 2, and the clock delays no longer apply. Due to how the clock tree is modeled and setup, we need to model this function in two places, the master mmc clock

[PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

The MMC clocks on newer SoCs, such as the A83T and H3, support the "new timing mode". Under this mode, the output of the clock is divided by 2, and the clock delays no longer apply. Due to how the clock tree is modeled and setup, we need to model this function in two places, the master mmc clock

[PATCH v2 2/8] clk: Provide option to query hardware for clk phase

On some hardware, the clk phase is tied to the parent clk's rate and some clk delay programmed into the hardware. As the parent clk rate changes, so does the clk phase. Add a clk flag specifying not to use the cached clk phase, but always query the hardware for it. Signed-off-by: Chen-Yu Tsai

[PATCH v2 0/8] clk: sunxi-ng: Add support for A83T CCU

Hi everyone, (Resent with devicetree mailing list CC-ed.) This is v2 of my A83T CCU series. This is for 4.13. Changes since v1: - Dropped two patches that were merged - Added clk core flag to disable caching of clock phases - Added support for multiple variable pre-dividers - Merged

  1   2   3   4   5   6   7   8   9   10   >