[PATCH 3/5] kconfig.h: use already defined macros for IS_REACHABLE() define

For the same reason as commit 02d699f1f464 ("include/linux/kconfig.h: ese macros which are already defined"), it is better to use macros IS_BUILTIN() and IS_MODULE() for defining IS_REACHABLE(). Signed-off-by: Masahiro Yamada --- include/linux/kconfig.h | 4 ++--

[PATCH 3/5] kconfig.h: use already defined macros for IS_REACHABLE() define

For the same reason as commit 02d699f1f464 ("include/linux/kconfig.h: ese macros which are already defined"), it is better to use macros IS_BUILTIN() and IS_MODULE() for defining IS_REACHABLE(). Signed-off-by: Masahiro Yamada --- include/linux/kconfig.h | 4 ++-- 1 file changed, 2

[PATCH 1/5] kconfig.h: use __is_defined() to check if MODULE is defined

The macro MODULE is not a config option, it is a per-file build option. So, config_enabled(MODULE) is not sensible. (There is another case in include/linux/export.h, where config_enabled() is used against a non-config option.) This commit renames some macros in include/linux/kconfig.h for the

[PATCH 4/5] kconfig.h: allow to use IS_{ENABLE,REACHABLE} in macro expansion

The typical usage of IS_ENABLED() is if (IS_ENABLED(CONFIG_FOO)) { ... } or #if IS_ENABLED(CONFIG_FOO) ... #endif The current implementation of IS_ENABLED() includes "||" operator, which works well in those expressions like above. However, there is a

[PATCH 2/5] export.h: use __is_defined() to check if __KSYM_* is defined

Here the need is for a macro that checks whether the given symbol is defined or not, which has nothing to do with config. The new macro __is_defined() is a better fit for this case. Signed-off-by: Masahiro Yamada --- include/linux/export.h | 2 +- 1 file

[PATCH 1/5] kconfig.h: use __is_defined() to check if MODULE is defined

The macro MODULE is not a config option, it is a per-file build option. So, config_enabled(MODULE) is not sensible. (There is another case in include/linux/export.h, where config_enabled() is used against a non-config option.) This commit renames some macros in include/linux/kconfig.h for the

[PATCH 4/5] kconfig.h: allow to use IS_{ENABLE,REACHABLE} in macro expansion

The typical usage of IS_ENABLED() is if (IS_ENABLED(CONFIG_FOO)) { ... } or #if IS_ENABLED(CONFIG_FOO) ... #endif The current implementation of IS_ENABLED() includes "||" operator, which works well in those expressions like above. However, there is a

[PATCH 2/5] export.h: use __is_defined() to check if __KSYM_* is defined

Here the need is for a macro that checks whether the given symbol is defined or not, which has nothing to do with config. The new macro __is_defined() is a better fit for this case. Signed-off-by: Masahiro Yamada --- include/linux/export.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [Intel-gfx] [PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()

On Mon, Jun 13, 2016 at 11:42:00PM +, weiyj...@163.com wrote: > From: Wei Yongjun > > Add the missing unlock before return from function i915_ppgtt_info() > in the error handling case. > > Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex) >

Re: [Intel-gfx] [PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()

On Mon, Jun 13, 2016 at 11:42:00PM +, weiyj...@163.com wrote: > From: Wei Yongjun > > Add the missing unlock before return from function i915_ppgtt_info() > in the error handling case. > > Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex) > Signed-off-by: Wei Yongjun

Re: [PATCH net-next v3 6/7] vmxnet3: introduce command to register memory region

On Tue, Jun 14, 2016 at 4:50 AM, Shrikrishna Khare wrote: > +++ b/drivers/net/vmxnet3/vmxnet3_defs.h > @@ -81,6 +81,7 @@ enum { > VMXNET3_CMD_RESERVED2, > VMXNET3_CMD_RESERVED3, > VMXNET3_CMD_SET_COALESCE, > + VMXNET3_CMD_REGISTER_MEMREGS, > >

Re: [PATCH net-next v3 6/7] vmxnet3: introduce command to register memory region

On Tue, Jun 14, 2016 at 4:50 AM, Shrikrishna Khare wrote: > +++ b/drivers/net/vmxnet3/vmxnet3_defs.h > @@ -81,6 +81,7 @@ enum { > VMXNET3_CMD_RESERVED2, > VMXNET3_CMD_RESERVED3, > VMXNET3_CMD_SET_COALESCE, > + VMXNET3_CMD_REGISTER_MEMREGS, > >

[PATCH v2 1/1] Staging: comedi: dmm32at: fix BIT macro issue.

This Replace all occurences of (1< --- Changes V1 -> V2: - BIT

[PATCH v2 1/1] Staging: comedi: dmm32at: fix BIT macro issue.

This Replace all occurences of (1< --- Changes V1 -> V2: - BIT macros added(suggested by Ian Abbott) -i.e.DMM32AT_AI_CFG_SCINT(x), DMM32AT_CTRL_PAGE(x) --- drivers/staging/comedi/drivers/dmm32at.c | 98 1 file changed, 50 insertions(+), 48

Re: [PATCH net-next v3 0/7] vmxnet3: upgrade to version 3

On Tue, Jun 14, 2016 at 4:50 AM, Shrikrishna Khare wrote: > This patchset upgrades vmxnet3 to version 3. Except for one patch, all the rest lack change-log, which makes it somehow needlessly harder to review and maintain > Shrikrishna Khare (7): > vmxnet3: prepare for

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

Hi Duc 在 2016/6/14 4:57, Duc Dang 写道: On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington wrote: Hi Dongdong, On 06/13/2016 09:02 AM, Dongdong Liu wrote: diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c index d3c3e85..49612b3 100644 ---

Re: [PATCH net-next v3 0/7] vmxnet3: upgrade to version 3

On Tue, Jun 14, 2016 at 4:50 AM, Shrikrishna Khare wrote: > This patchset upgrades vmxnet3 to version 3. Except for one patch, all the rest lack change-log, which makes it somehow needlessly harder to review and maintain > Shrikrishna Khare (7): > vmxnet3: prepare for version 3 changes >

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

Hi Duc 在 2016/6/14 4:57, Duc Dang 写道: On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington wrote: Hi Dongdong, On 06/13/2016 09:02 AM, Dongdong Liu wrote: diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c index d3c3e85..49612b3 100644 --- a/drivers/acpi/pci_mcfg.c +++

Re: [GIT PULL] SCSI fixes for 4.7-rc2

On Mon, Jun 13, 2016 at 12:04 AM, Hannes Reinecke wrote: > > And we have been running the very patch in SLES for over a year now, > without a single issue being reported. Oh, ok. So it's not "all qemu kvm instances are broken", it was a very unusual issue, and the patch has

Re: [GIT PULL] SCSI fixes for 4.7-rc2

On Mon, Jun 13, 2016 at 12:04 AM, Hannes Reinecke wrote: > > And we have been running the very patch in SLES for over a year now, > without a single issue being reported. Oh, ok. So it's not "all qemu kvm instances are broken", it was a very unusual issue, and the patch has actually gotten wider

Re: [PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock

On Mon, Jun 13, 2016 at 04:31:15PM -0400, Sasha Levin wrote: > On 05/25/2016 10:37 PM, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > We don't need to split freepages with holding the zone lock. It will cause > > more contention on zone lock so not desirable. > >

Re: [PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock

On Mon, Jun 13, 2016 at 04:31:15PM -0400, Sasha Levin wrote: > On 05/25/2016 10:37 PM, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > We don't need to split freepages with holding the zone lock. It will cause > > more contention on zone lock so not desirable. > > > > Signed-off-by:

Re: [PATCH] locking/qspinlock: Use atomic_sub_return_release in queued_spin_unlock

On Mon, Jun 13, 2016 at 12:45:23PM -0700, Davidlohr Bueso wrote: > On Fri, 03 Jun 2016, Pan Xinhui wrote: > > > The existing version uses a heavy barrier while only release semantics > > is required. So use atomic_sub_return_release instead. > > > > Suggested-by: Peter Zijlstra (Intel)

Re: [PATCH] locking/qspinlock: Use atomic_sub_return_release in queued_spin_unlock

On Mon, Jun 13, 2016 at 12:45:23PM -0700, Davidlohr Bueso wrote: > On Fri, 03 Jun 2016, Pan Xinhui wrote: > > > The existing version uses a heavy barrier while only release semantics > > is required. So use atomic_sub_return_release instead. > > > > Suggested-by: Peter Zijlstra (Intel) > >

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hi Michal, On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek wrote: > On 14 June 2016 at 06:47, Julian Calaby wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote: >>> Hello, >>> >>> On 14 June 2016 at

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hi Michal, On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek wrote: > On 14 June 2016 at 06:47, Julian Calaby wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote: >>> Hello, >>> >>> On 14 June 2016 at 01:43, Julian Calaby wrote: Hi Michal, On Tue,

Re: [PATCH 1/2] drm/mediatek: Add gamma correction

On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote: > Apply gamma function to correct brightness values. > It applies arbitrary mapping curve to compensate the > incorrect transfer function of the panel. > > Signed-off-by: Bibby Hsieh I think it would be much

Re: [PATCH 1/2] drm/mediatek: Add gamma correction

On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote: > Apply gamma function to correct brightness values. > It applies arbitrary mapping curve to compensate the > incorrect transfer function of the panel. > > Signed-off-by: Bibby Hsieh I think it would be much better to use the new

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote: > Heiko, > > On 09.06.16 11:00:56, Heiko Carstens wrote: > > However I'm wondering if we shouldn't simply remove at least the s390 > > specific hwswampler code from the oprofile module. This would still leave > > the common code

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote: > Heiko, > > On 09.06.16 11:00:56, Heiko Carstens wrote: > > However I'm wondering if we shouldn't simply remove at least the s390 > > specific hwswampler code from the oprofile module. This would still leave > > the common code

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

On 14 June 2016 at 06:47, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote: >> Hello, >> >> On 14 June 2016 at 01:43, Julian Calaby wrote: >>> Hi Michal, >>> >>> On Tue, Jun 14,

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

On 14 June 2016 at 06:47, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote: >> Hello, >> >> On 14 June 2016 at 01:43, Julian Calaby wrote: >>> Hi Michal, >>> >>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: The drivers are very

Re: [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > On Mon, Jun 13, 2016 at 09:50:15PM +0200, Julia Lawall wrote: > > > > > > On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > > > > > On Fri, Jun 10, 2016 at 11:21:28PM +0200, Julia Lawall wrote: > > > > > > > > > > > > On Fri, 10 Jun 2016, Luis

Re: [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > On Mon, Jun 13, 2016 at 09:50:15PM +0200, Julia Lawall wrote: > > > > > > On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > > > > > On Fri, Jun 10, 2016 at 11:21:28PM +0200, Julia Lawall wrote: > > > > > > > > > > > > On Fri, 10 Jun 2016, Luis

Re: [PATCH v2 1/5] nbd: fix might_sleep warning on socket shutdown.

Hello, On Thu, Jun 9, 2016 at 3:33 PM, Pranay Srivastava wrote: > > Hello > > > On Thu, Jun 2, 2016 at 3:54 PM, Pranay Kr. Srivastava > wrote: > > spinlocked ranges should be small and not contain calls into huge > > subfunctions. Fix my mistake and just

Re: [PATCH v2 1/5] nbd: fix might_sleep warning on socket shutdown.

Hello, On Thu, Jun 9, 2016 at 3:33 PM, Pranay Srivastava wrote: > > Hello > > > On Thu, Jun 2, 2016 at 3:54 PM, Pranay Kr. Srivastava > wrote: > > spinlocked ranges should be small and not contain calls into huge > > subfunctions. Fix my mistake and just get the pointer to the socket > >

806ebc1465: BUG: tried to access memory at 0x7ff6afd3 while not in USER_DS

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/uaccess commit 806ebc146567cb0030460ebf34ebecfb7c67eb76 ("[DEBUG] force CONFIG_DEBUG_UACCESS") on test machine: vm-lkp-wsx03-openwrt-i386: 1 threads qemu-system-i386 -enable-kvm with

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 00:16:11 schrieb Andrew Zaborowski: Hi Andrew, > Hi, > > On 8 June 2016 at 21:14, Mat Martineau > > wrote: > > On Wed, 8 Jun 2016, Stephan Mueller wrote: > >> What is your concern? > > > > Userspace must allocate larger buffers

806ebc1465: BUG: tried to access memory at 0x7ff6afd3 while not in USER_DS

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/uaccess commit 806ebc146567cb0030460ebf34ebecfb7c67eb76 ("[DEBUG] force CONFIG_DEBUG_UACCESS") on test machine: vm-lkp-wsx03-openwrt-i386: 1 threads qemu-system-i386 -enable-kvm with

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 00:16:11 schrieb Andrew Zaborowski: Hi Andrew, > Hi, > > On 8 June 2016 at 21:14, Mat Martineau > > wrote: > > On Wed, 8 Jun 2016, Stephan Mueller wrote: > >> What is your concern? > > > > Userspace must allocate larger buffers than it knows are necessary for > >

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > On Mon, Jun 13, 2016 at 09:48:30PM +0200, Julia Lawall wrote: > > > > > > On Mon, 13 Jun 2016, Wolfram Sang wrote: > > > > > > > > > Is there another scripts/coccinelle/ file I can use to test against to > > > > demo > > > > against

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > On Mon, Jun 13, 2016 at 09:48:30PM +0200, Julia Lawall wrote: > > > > > > On Mon, 13 Jun 2016, Wolfram Sang wrote: > > > > > > > > > Is there another scripts/coccinelle/ file I can use to test against to > > > > demo > > > > against

linux-next: manual merge of the staging tree with the block tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/lloop.c between commit: 95fe6c1a209e ("block, fs, mm, drivers: use bio set/get op accessors") from the block tree and commit: 67b1a24e883c ("staging: lustre: llite: remove lloop

linux-next: manual merge of the staging tree with the block tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/lloop.c between commit: 95fe6c1a209e ("block, fs, mm, drivers: use bio set/get op accessors") from the block tree and commit: 67b1a24e883c ("staging: lustre: llite: remove lloop

Re: [PATCH 2/2] dmaengine: bcm2835: Avoid splitting periods into very small chunks

Matthias Reichl writes: > The current cyclic DMA period splitting implementation can generate > very small chunks at the end of each period. For example a 65536 byte > period will be split into a 65532 byte chunk and a 4 byte chunk on > the "lite" DMA channels. > > This increases

Re: [PATCH 2/2] dmaengine: bcm2835: Avoid splitting periods into very small chunks

Matthias Reichl writes: > The current cyclic DMA period splitting implementation can generate > very small chunks at the end of each period. For example a 65536 byte > period will be split into a 65532 byte chunk and a 4 byte chunk on > the "lite" DMA channels. > > This increases pressure on the

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/iio/industrialio-trigger.c between commit: 995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func") from the staging.current tree and commit: ef2d71d6b7fb ("iio: triggers: Make trigger ops

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/iio/industrialio-trigger.c between commit: 995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func") from the staging.current tree and commit: ef2d71d6b7fb ("iio: triggers: Make trigger ops

Re: [PATCH v2 3/3] ARM64: dts: meson-gxbb: Add Hardware Random Generator node

On 06/14/2016 12:09 AM, Kevin Hilman wrote: > Hi Neil, > > Neil Armstrong writes: > >> Signed-off-by: Neil Armstrong >> --- >> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git

Re: [PATCH v2 3/3] ARM64: dts: meson-gxbb: Add Hardware Random Generator node

On 06/14/2016 12:09 AM, Kevin Hilman wrote: > Hi Neil, > > Neil Armstrong writes: > >> Signed-off-by: Neil Armstrong >> --- >> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi >>

Re: [RESEND PATCH v11] mtd: spi-nor: add hisilicon spi-nor flash controller driver

-controller-driver/20160613-163520 base: git://git.infradead.org/linux-mtd.git master config: m32r-allmodconfig (attached as .config) compiler: m32r-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin

Re: [RESEND PATCH v11] mtd: spi-nor: add hisilicon spi-nor flash controller driver

-controller-driver/20160613-163520 base: git://git.infradead.org/linux-mtd.git master config: m32r-allmodconfig (attached as .config) compiler: m32r-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

On Tue, Jun 14, 2016 at 02:51:17PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the kvms390 tree got a conflict in: > > arch/s390/hypfs/hypfs_diag.c > > between commit: > > 6c22c9863760 ("s390: avoid extable collisions") > > from the s390 tree and commit: > >

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

On Tue, Jun 14, 2016 at 02:51:17PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the kvms390 tree got a conflict in: > > arch/s390/hypfs/hypfs_diag.c > > between commit: > > 6c22c9863760 ("s390: avoid extable collisions") > > from the s390 tree and commit: > >

linux-next: manual merge of the kvms390 tree with the s390 tree

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: arch/s390/hypfs/hypfs_diag.c between commit: 6c22c9863760 ("s390: avoid extable collisions") from the s390 tree and commit: e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions") from the

linux-next: manual merge of the kvms390 tree with the s390 tree

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: arch/s390/hypfs/hypfs_diag.c between commit: 6c22c9863760 ("s390: avoid extable collisions") from the s390 tree and commit: e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions") from the

Re: [PATCH v3 00/13] sunxi spi fixes

Hello, On 13 June 2016 at 21:57, Maxime Ripard wrote: > On Mon, Jun 13, 2016 at 05:46:48PM -, Michal Suchanek wrote: >> Hello, >> >> This is update of the sunxi spi patches that should give full-featured SPI >> driver. >> >> First three patches fix issues

Re: [PATCH v3 00/13] sunxi spi fixes

Hello, On 13 June 2016 at 21:57, Maxime Ripard wrote: > On Mon, Jun 13, 2016 at 05:46:48PM -, Michal Suchanek wrote: >> Hello, >> >> This is update of the sunxi spi patches that should give full-featured SPI >> driver. >> >> First three patches fix issues with the current driver and can be

Re: [PATCH 1/2] dmaengine: bcm2835: Fix cyclic DMA period splitting

Matthias Reichl writes: > The code responsible for splitting periods into chunks that > can be handled by the DMA controller missed to update total_len, > the number of bytes processed in the current period, when there > are more chunks to follow. > > Therefore total_len was

Re: [PATCH 1/2] dmaengine: bcm2835: Fix cyclic DMA period splitting

Matthias Reichl writes: > The code responsible for splitting periods into chunks that > can be handled by the DMA controller missed to update total_len, > the number of bytes processed in the current period, when there > are more chunks to follow. > > Therefore total_len was stuck at 0 and the

Re: [linux-sunxi] [PATCH v3 11/13] dt: spi: sun4i: merge sun4i and sun6i binding doc

Hi Michal, On Tue, Jun 14, 2016 at 2:40 PM, Michal Suchanek wrote: > On 14 June 2016 at 01:45, Julian Calaby wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >>> Signed-off-by: Michal Suchanek

Re: [linux-sunxi] [PATCH v3 11/13] dt: spi: sun4i: merge sun4i and sun6i binding doc

Hi Michal, On Tue, Jun 14, 2016 at 2:40 PM, Michal Suchanek wrote: > On 14 June 2016 at 01:45, Julian Calaby wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >>> Signed-off-by: Michal Suchanek >>> --- >>> .../devicetree/bindings/spi/spi-sun4i.txt |

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hi Michal, On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote: > Hello, > > On 14 June 2016 at 01:43, Julian Calaby wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >>> The drivers are very

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hi Michal, On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote: > Hello, > > On 14 June 2016 at 01:43, Julian Calaby wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >>> The drivers are very similar and share multiple flaws which needed >>> separate fixes

Re: [linux-sunxi] [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i

Hello, On 14 June 2016 at 01:31, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >> SUNXI_CTL_ -> SUNXI_TFR_CTL_ >> SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS > > I don't know these abbreviations, are they

Re: [linux-sunxi] [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i

Hello, On 14 June 2016 at 01:31, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >> SUNXI_CTL_ -> SUNXI_TFR_CTL_ >> SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS > > I don't know these abbreviations, are they both referring to the same thing? > >>

Re: [linux-sunxi] [PATCH v3 11/13] dt: spi: sun4i: merge sun4i and sun6i binding doc

On 14 June 2016 at 01:45, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >> Signed-off-by: Michal Suchanek >> --- >> .../devicetree/bindings/spi/spi-sun4i.txt | 21

Re: [linux-sunxi] [PATCH v3 11/13] dt: spi: sun4i: merge sun4i and sun6i binding doc

On 14 June 2016 at 01:45, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >> Signed-off-by: Michal Suchanek >> --- >> .../devicetree/bindings/spi/spi-sun4i.txt | 21 ++- >> .../devicetree/bindings/spi/spi-sun6i.txt

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hello, On 14 June 2016 at 01:43, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >> The drivers are very similar and share multiple flaws which needed >> separate fixes for both drivers. >> >>

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hello, On 14 June 2016 at 01:43, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >> The drivers are very similar and share multiple flaws which needed >> separate fixes for both drivers. >> >> Signed-off-by: Michal Suchanek >> --- >>

Re: [PATCH] crypto : async implementation for sha1-mb

On Mon, Jun 13, 2016 at 07:10:26PM +, Dey, Megha wrote: > > > In the current implementation, the inner algorithm is called directly, and > > we use the outer algorithm's callback. We do not use the callback in inner > > algorithm. We are actually calling the child functions directly and the

Re: [PATCH] crypto : async implementation for sha1-mb

On Mon, Jun 13, 2016 at 07:10:26PM +, Dey, Megha wrote: > > > In the current implementation, the inner algorithm is called directly, and > > we use the outer algorithm's callback. We do not use the callback in inner > > algorithm. We are actually calling the child functions directly and the

Re: linux-next: duplicate patches in the kspp and kbuild trees

Hi Kees, On Mon, 13 Jun 2016 16:57:15 -0700 Kees Cook wrote: > > On Mon, Jun 13, 2016 at 4:53 PM, Kees Cook wrote: > > > > Strange, I pulled these directly from linux-next. Michal had an > > auto-responder saying he was going to be out-of-office, so I

Re: linux-next: duplicate patches in the kspp and kbuild trees

Hi Kees, On Mon, 13 Jun 2016 16:57:15 -0700 Kees Cook wrote: > > On Mon, Jun 13, 2016 at 4:53 PM, Kees Cook wrote: > > > > Strange, I pulled these directly from linux-next. Michal had an > > auto-responder saying he was going to be out-of-office, so I wanted to > > make sure the !COMPILE_TEST

Re: Internal error xfs_trans_cancel

On Wed, Jun 01, 2016 at 07:52:31AM +0200, Daniel Wagner wrote: > Hi, > > I got the error message below while compiling a kernel > on that system. I can't really say if I did something > which made the file system unhappy before the crash. > > > [Jun 1 07:41] XFS (sde1): Internal error

Re: Internal error xfs_trans_cancel

On Wed, Jun 01, 2016 at 07:52:31AM +0200, Daniel Wagner wrote: > Hi, > > I got the error message below while compiling a kernel > on that system. I can't really say if I did something > which made the file system unhappy before the crash. > > > [Jun 1 07:41] XFS (sde1): Internal error

Re: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399

Hi Daniel: On 2016年06月13日 21:06, Daniel Lezcano wrote: > On Tue, Jun 07, 2016 at 12:54:29PM +0800, Caesar Wang wrote: >> This series patches had been tested on rockchip inside kernel. >> In order to support the rk3399 SoC timer and turn off interrupts and IPIs to >> save power in idle. > > For my

Re: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399

Hi Daniel: On 2016年06月13日 21:06, Daniel Lezcano wrote: > On Tue, Jun 07, 2016 at 12:54:29PM +0800, Caesar Wang wrote: >> This series patches had been tested on rockchip inside kernel. >> In order to support the rk3399 SoC timer and turn off interrupts and IPIs to >> save power in idle. > > For my

linux-next: manual merge of the md tree with the block tree

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/raid1.c between commit: 796a5cf083c2 ("md: use bio op accessors") from the block tree and commit: 707a6a420ccf ("md/raid1: add rcu protection to rdev in fix_read_error") from the md tree. I fixed it up

linux-next: manual merge of the md tree with the block tree

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/raid1.c between commit: 796a5cf083c2 ("md: use bio op accessors") from the block tree and commit: 707a6a420ccf ("md/raid1: add rcu protection to rdev in fix_read_error") from the md tree. I fixed it up

linux-next: manual merge of the md tree with the block tree

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/raid10.c between commit: 796a5cf083c2 ("md: use bio op accessors") from the block tree and commits: f90145f317ef ("md/raid10: add rcu protection to rdev access in raid10_sync_request." d094d6860b66

linux-next: manual merge of the md tree with the block tree

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/raid10.c between commit: 796a5cf083c2 ("md: use bio op accessors") from the block tree and commits: f90145f317ef ("md/raid10: add rcu protection to rdev access in raid10_sync_request." d094d6860b66

Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399

Hi, On Mon, Jun 13, 2016 at 8:02 PM, Xing Zheng wrote: > Hi Doug, > > On 2016年06月14日 07:46, Doug Anderson wrote: >> >> >> Even if it's not much power, it seems like we should still turn it off >> and on in the right place. Unless I'm mistaken it should be such a >>

Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399

Hi, On Mon, Jun 13, 2016 at 8:02 PM, Xing Zheng wrote: > Hi Doug, > > On 2016年06月14日 07:46, Doug Anderson wrote: >> >> >> Even if it's not much power, it seems like we should still turn it off >> and on in the right place. Unless I'm mistaken it should be such a >> simple patch provide the

Re: [PATCH 2/2] perf annotate: add powerpc support

On Fri, 2016-06-10 at 20:08 +0530, Naveen N. Rao wrote: > On 2016/06/10 10:36AM, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 10, 2016 at 06:32:51PM +0530, Naveen N. Rao escreveu: > > > Convert ins__find() to a __weak function for generic functionality, > > > while adding a powerpc-specific

Re: [PATCH 2/2] perf annotate: add powerpc support

On Fri, 2016-06-10 at 20:08 +0530, Naveen N. Rao wrote: > On 2016/06/10 10:36AM, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 10, 2016 at 06:32:51PM +0530, Naveen N. Rao escreveu: > > > Convert ins__find() to a __weak function for generic functionality, > > > while adding a powerpc-specific

Re: [PATCH 4/5] ipvs: Lock socket before setting SK_CAN_REUSE

On Mon, 2016-06-13 at 20:12 -0700, Eric Dumazet wrote: > > Have you tested this patch ? Hmm, please ignore this question ;)

Re: [PATCH 4/5] ipvs: Lock socket before setting SK_CAN_REUSE

On Mon, 2016-06-13 at 20:12 -0700, Eric Dumazet wrote: > > Have you tested this patch ? Hmm, please ignore this question ;)

Re: [PATCH v2] iommu/amd: Set AMD iommu callbacks for platform bus driver

2016-05-10 21:21 GMT+08:00 Wan Zongshun : > From: Wan Zongshun > > AMD has more drivers will use ACPI to platform bus driver later, > all those devices need iommu support, for example: eMMC driver. > > For latest AMD eMMC controller, it will utilize

Re: [PATCH v2] iommu/amd: Set AMD iommu callbacks for platform bus driver

2016-05-10 21:21 GMT+08:00 Wan Zongshun : > From: Wan Zongshun > > AMD has more drivers will use ACPI to platform bus driver later, > all those devices need iommu support, for example: eMMC driver. > > For latest AMD eMMC controller, it will utilize sdhci-acpi.c driver, > which will rely on

Re: [PATCH 4/5] ipvs: Lock socket before setting SK_CAN_REUSE

On Tue, 2016-06-14 at 02:43 +0100, Quentin Armitage wrote: > When other settings are changed in the socket it is locked, so > lock the socket before setting SK_CAN_REUSE. > > Signed-off-by: Quentin Armitage > --- > net/netfilter/ipvs/ip_vs_sync.c |2 ++ > 1 files

Re: [PATCH 4/5] ipvs: Lock socket before setting SK_CAN_REUSE

On Tue, 2016-06-14 at 02:43 +0100, Quentin Armitage wrote: > When other settings are changed in the socket it is locked, so > lock the socket before setting SK_CAN_REUSE. > > Signed-off-by: Quentin Armitage > --- > net/netfilter/ipvs/ip_vs_sync.c |2 ++ > 1 files changed, 2 insertions(+), 0

Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

On 13 June 2016 at 20:45, Will Deacon wrote: > On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: >> The PCIe ACS capability will affect the layout of iommu groups. >> Generally speaking, if the path from root port to the PCIe device >> is ACS enabled, the iommu will

Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

On 13 June 2016 at 20:45, Will Deacon wrote: > On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: >> The PCIe ACS capability will affect the layout of iommu groups. >> Generally speaking, if the path from root port to the PCIe device >> is ACS enabled, the iommu will create a single iommu

Re: [RFC PATCH] sys_read: add a compat_sys_read for 64bit system

On 2016/6/10 1:08, Andy Lutomirski wrote: > On Tue, Jun 7, 2016 at 7:14 PM, Zhangjian (Bamvor) > wrote: >> Hi, >> >> On 2016/6/8 9:33, Weidong Wang wrote: >>> >>> Test 32 progress and 64 progress on the 64bit system with >>> this progress: >>> >>> int main(int argc,

Re: [RFC PATCH] sys_read: add a compat_sys_read for 64bit system

On 2016/6/10 1:08, Andy Lutomirski wrote: > On Tue, Jun 7, 2016 at 7:14 PM, Zhangjian (Bamvor) > wrote: >> Hi, >> >> On 2016/6/8 9:33, Weidong Wang wrote: >>> >>> Test 32 progress and 64 progress on the 64bit system with >>> this progress: >>> >>> int main(int argc, char **argv) >>> { >>>

[PATCH 1/3] arm64: dts: uniphier: add SoC-Glue node to UniPhier 64bit SoCs

This node consists of various system-level configuration registers. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git

[PATCH 1/3] arm64: dts: uniphier: add SoC-Glue node to UniPhier 64bit SoCs

This node consists of various system-level configuration registers. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi

Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399

Hi Doug, On 2016年06月14日 07:46, Doug Anderson wrote: Even if it's not much power, it seems like we should still turn it off and on in the right place. Unless I'm mistaken it should be such a simple patch provide the clock to the right driver and then get the clock when appropriate. Yes, I

Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399

Hi Doug, On 2016年06月14日 07:46, Doug Anderson wrote: Even if it's not much power, it seems like we should still turn it off and on in the right place. Unless I'm mistaken it should be such a simple patch provide the clock to the right driver and then get the clock when appropriate. Yes, I

  1   2   3   4   5   6   7   8   9   10   >