[PATCH V3 2/2] vhost_net: conditionally enable tx polling

We always poll tx for socket, this is sub optimal since: - it will be only used when we exceed the sndbuf of the socket. - since we use two independent polls for tx and vq, this will slightly increase the waitqueue traversing time and more important, vhost could not benefit from commit

[PATCH V3 2/2] vhost_net: conditionally enable tx polling

We always poll tx for socket, this is sub optimal since: - it will be only used when we exceed the sndbuf of the socket. - since we use two independent polls for tx and vq, this will slightly increase the waitqueue traversing time and more important, vhost could not benefit from commit

[PATCH V3 1/2] vhost_net: stop polling socket during rx processing

We don't stop rx polling socket during rx processing, this will lead unnecessary wakeups from under layer net devices (E.g sock_def_readable() form tun). Rx will be slowed down in this way. This patch avoids this by stop polling socket during rx processing. A small drawback is that this introduces

[PATCH V3 1/2] vhost_net: stop polling socket during rx processing

We don't stop rx polling socket during rx processing, this will lead unnecessary wakeups from under layer net devices (E.g sock_def_readable() form tun). Rx will be slowed down in this way. This patch avoids this by stop polling socket during rx processing. A small drawback is that this introduces

[PATCH V3 0/2] vhost_net polling optimization

Hi: This series tries to optimize vhost_net polling at two points: - Stop rx polling for reduicng the unnecessary wakeups during handle_rx(). - Conditonally enable tx polling for reducing the unnecessary traversing and spinlock touching. Test shows about 17% improvement on rx pps. Please

[PATCH V3 0/2] vhost_net polling optimization

Hi: This series tries to optimize vhost_net polling at two points: - Stop rx polling for reduicng the unnecessary wakeups during handle_rx(). - Conditonally enable tx polling for reducing the unnecessary traversing and spinlock touching. Test shows about 17% improvement on rx pps. Please

Re: [PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup

On 2016年06月01日 02:13, Waiman Long wrote: On 05/30/2016 04:53 AM, xinhui wrote: On 2016年05月28日 11:41, Waiman Long wrote: On 05/27/2016 06:32 AM, xinhui wrote: On 2016年05月27日 02:31, Waiman Long wrote: On 05/25/2016 02:09 AM, Pan Xinhui wrote: In pv_wait_head_or_lock, if there is a

Re: [PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup

On 2016年06月01日 02:13, Waiman Long wrote: On 05/30/2016 04:53 AM, xinhui wrote: On 2016年05月28日 11:41, Waiman Long wrote: On 05/27/2016 06:32 AM, xinhui wrote: On 2016年05月27日 02:31, Waiman Long wrote: On 05/25/2016 02:09 AM, Pan Xinhui wrote: In pv_wait_head_or_lock, if there is a

Internal error xfs_trans_cancel

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 xfs_trans_cancel at line 984 of file fs/xfs/xfs_trans.c. Caller

Internal error xfs_trans_cancel

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 xfs_trans_cancel at line 984 of file fs/xfs/xfs_trans.c. Caller

Re: [PATCH 1/2] xen-blkfront: don't call talk_to_blkback when already connected to blkback

On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote: > On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrote: >> Sometimes blkfont may receive twice blkback_changed() notification after >> migration, then talk_to_blkback() will be called twice too and confused >> xen-blkback. > > Could you

Re: [PATCH 1/2] xen-blkfront: don't call talk_to_blkback when already connected to blkback

On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote: > On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrote: >> Sometimes blkfont may receive twice blkback_changed() notification after >> migration, then talk_to_blkback() will be called twice too and confused >> xen-blkback. > > Could you

Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs

On 05/31/2016 07:04 PM, Christoph Hellwig wrote: > On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote: >> The dma-mapping core and the implementations do not change the >> DMA attributes passed by pointer. Thus the pointer can point to const >> data. However the attributes do

Re: [PATCH 00/11] ALSA: Utilize the module_isa_driver macro

On Tue, 31 May 2016 17:54:16 +0200, William Breathitt Gray wrote: > > The module_isa_driver macro is a helper macro for ISA drivers which do > not do anything special in module init/exit. This patchset eliminates a > lot of ISA driver registration boilerplate code by utilizing >

Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs

On 05/31/2016 07:04 PM, Christoph Hellwig wrote: > On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote: >> The dma-mapping core and the implementations do not change the >> DMA attributes passed by pointer. Thus the pointer can point to const >> data. However the attributes do

Re: [PATCH 00/11] ALSA: Utilize the module_isa_driver macro

On Tue, 31 May 2016 17:54:16 +0200, William Breathitt Gray wrote: > > The module_isa_driver macro is a helper macro for ISA drivers which do > not do anything special in module init/exit. This patchset eliminates a > lot of ISA driver registration boilerplate code by utilizing >

Re: [PATCH 4.6 000/100] 4.6.1-stable review

On 05/30/2016 01:48 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.6.1 release. There are 100 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.6 000/100] 4.6.1-stable review

On 05/30/2016 01:48 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.6.1 release. There are 100 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.5 00/87] 4.5.6-stable review

On 05/30/2016 01:48 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.5.6 release. There are 87 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.5 00/87] 4.5.6-stable review

On 05/30/2016 01:48 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.5.6 release. There are 87 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 3.14 00/20] 3.14.71-stable review

On 05/30/2016 01:49 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.71 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 3.14 00/20] 3.14.71-stable review

On 05/30/2016 01:49 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.71 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

On 05/17/2016 05:10 AM, Huang Shijie wrote: On Wed, Apr 27, 2016 at 02:53:00PM -0400, David Long wrote: From: Sandeepa Prabhu + +static bool __kprobes aarch64_insn_is_steppable(u32 insn) Could we add more comment for this function? In the comment, we can tell

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

On 05/17/2016 05:10 AM, Huang Shijie wrote: On Wed, Apr 27, 2016 at 02:53:00PM -0400, David Long wrote: From: Sandeepa Prabhu + +static bool __kprobes aarch64_insn_is_steppable(u32 insn) Could we add more comment for this function? In the comment, we can tell that which type of instructions

RE: [PATCH] mmc: host: use pr_err for sdhci_dumpregs

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Tuesday, May 31, 2016 5:47 PM > To: Baranowska, BeataX > Cc: Hunter, Adrian ; Ulf Hansson > ; linux-...@vger.kernel.org;

RE: [PATCH] mmc: host: use pr_err for sdhci_dumpregs

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Tuesday, May 31, 2016 5:47 PM > To: Baranowska, BeataX > Cc: Hunter, Adrian ; Ulf Hansson > ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Dong, Chuanxiao ; > Jarosz, SebastianX >

Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE_WAKE flags in sched domain build-up

On Tue, 2016-05-31 at 09:31 +0800, Yuyang Du wrote: > On Tue, May 31, 2016 at 11:21:46AM +0200, Peter Zijlstra wrote: > > On Tue, May 31, 2016 at 09:11:37AM +0800, Yuyang Du wrote: > > > The SD_BALANCE_WAKE is irrelevant in the contexts of these two removals, > > > and in addition SD_BALANCE_WAKE

Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE_WAKE flags in sched domain build-up

On Tue, 2016-05-31 at 09:31 +0800, Yuyang Du wrote: > On Tue, May 31, 2016 at 11:21:46AM +0200, Peter Zijlstra wrote: > > On Tue, May 31, 2016 at 09:11:37AM +0800, Yuyang Du wrote: > > > The SD_BALANCE_WAKE is irrelevant in the contexts of these two removals, > > > and in addition SD_BALANCE_WAKE

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 10:30, Tom Yan wrote: > There seems to be some sort of race condition between > blkdev_issue_zeroout() and the scsi disk driver (disabling write same > after an illegal request). On my UAS drive, sometimes `blkdiscard -z > /dev/sdX` will return right away,

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 10:30, Tom Yan wrote: > There seems to be some sort of race condition between > blkdev_issue_zeroout() and the scsi disk driver (disabling write same > after an illegal request). On my UAS drive, sometimes `blkdiscard -z > /dev/sdX` will return right away, even though if I then

Re: [LKP] [lkp] [sched/fair] 53d3bc773e: hackbench.throughput -32.9% regression

Hi, Peter, Peter Zijlstra writes: > On Tue, May 31, 2016 at 04:34:36PM +0800, Huang, Ying wrote: >> Hi, Ingo, >> >> Part of the regression has been recovered in v4.7-rc1 from -32.9% to >> -9.8%. But there is still some regression. Is it possible for fully >> restore it?

Re: [LKP] [lkp] [sched/fair] 53d3bc773e: hackbench.throughput -32.9% regression

Hi, Peter, Peter Zijlstra writes: > On Tue, May 31, 2016 at 04:34:36PM +0800, Huang, Ying wrote: >> Hi, Ingo, >> >> Part of the regression has been recovered in v4.7-rc1 from -32.9% to >> -9.8%. But there is still some regression. Is it possible for fully >> restore it? > > after much

[RFC v3 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

Now some cipher hardware engines prefer to handle bulk block rather than one sector (512 bytes) created by dm-crypt, cause these cipher engines can handle the intermediate values (IV) by themselves in one bulk block. This means we can increase the size of the request by merging request rather than

[RFC v3 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

Now some cipher hardware engines prefer to handle bulk block rather than one sector (512 bytes) created by dm-crypt, cause these cipher engines can handle the intermediate values (IV) by themselves in one bulk block. This means we can increase the size of the request by merging request rather than

[RFC v3 1/4] block: Introduce blk_bio_map_sg() to map one bio

In dm-crypt, it need to map one bio to scatterlist for improving the hardware engine encryption efficiency. Thus this patch introduces the blk_bio_map_sg() function to map one bio with scatterlists. For avoiding the duplicated code in __blk_bios_map_sg() function, add one parameter to distinguish

[RFC v3 4/4] crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher

Since the ecb(aes) cipher does not need to handle the IV things for encryption or decryption, that means it can support for bulk block when handling data. Thus this patch adds the CRYPTO_ALG_BULK flag for ecb(aes) cipher to improve the hardware aes engine's efficiency. Signed-off-by: Baolin Wang

[RFC v3 3/4] md: dm-crypt: Introduce the bulk mode method when sending request

In now dm-crypt code, it is ineffective to map one segment (always one sector) of one bio with just only one scatterlist at one time for hardware crypto engine. Especially for some encryption mode (like ecb or xts mode) cooperating with the crypto engine, they just need one initial IV or null IV

[RFC v3 1/4] block: Introduce blk_bio_map_sg() to map one bio

In dm-crypt, it need to map one bio to scatterlist for improving the hardware engine encryption efficiency. Thus this patch introduces the blk_bio_map_sg() function to map one bio with scatterlists. For avoiding the duplicated code in __blk_bios_map_sg() function, add one parameter to distinguish

[RFC v3 4/4] crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher

Since the ecb(aes) cipher does not need to handle the IV things for encryption or decryption, that means it can support for bulk block when handling data. Thus this patch adds the CRYPTO_ALG_BULK flag for ecb(aes) cipher to improve the hardware aes engine's efficiency. Signed-off-by: Baolin Wang

[RFC v3 3/4] md: dm-crypt: Introduce the bulk mode method when sending request

In now dm-crypt code, it is ineffective to map one segment (always one sector) of one bio with just only one scatterlist at one time for hardware crypto engine. Especially for some encryption mode (like ecb or xts mode) cooperating with the crypto engine, they just need one initial IV or null IV

[RFC v3 0/4] Introduce the bulk mode method when sending request to crypto layer

This patchset will check if the cipher can support bulk mode, then dm-crypt will handle different ways to send requests to crypto layer according to cipher mode. For bulk mode, we can use sg table to map the whole bio and send all scatterlists of one bio to crypto engine to encrypt or decrypt,

[RFC v3 0/4] Introduce the bulk mode method when sending request to crypto layer

This patchset will check if the cipher can support bulk mode, then dm-crypt will handle different ways to send requests to crypto layer according to cipher mode. For bulk mode, we can use sg table to map the whole bio and send all scatterlists of one bio to crypto engine to encrypt or decrypt,

[PATCH v2 2/2] ARM: at91/dt: sama5d2: Use new compatible for ohci node

Use compatible "atmel,sama5d2-ohci" to be capable of suspending ports while sleep to save the power consumption. Signed-off-by: Wenyou Yang --- Changes in v2: - Use the new compatible for ohci-node. arch/arm/boot/dts/sama5d2.dtsi | 2 +- 1 file changed, 1 insertion(+),

[PATCH] x86: Report Intel platform_id in /proc/cpuinfo

From: Andi Kleen We have a need to distinguish systems based on their platform ID. For example this is useful to distinguish systems with L4 cache versus ones without. There is a 5 bit identifier (also called processor flags) in the IA32_PLATFORM_ID MSR that can give a

[PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

In order to the save power consumption, as a workaround, suspend forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt Configuration Register in the SFRs while OHCI USB suspend. This suspend operation must be done before the USB clock is disabled, resume after the USB clock

[PATCH v2 2/2] ARM: at91/dt: sama5d2: Use new compatible for ohci node

Use compatible "atmel,sama5d2-ohci" to be capable of suspending ports while sleep to save the power consumption. Signed-off-by: Wenyou Yang --- Changes in v2: - Use the new compatible for ohci-node. arch/arm/boot/dts/sama5d2.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] x86: Report Intel platform_id in /proc/cpuinfo

From: Andi Kleen We have a need to distinguish systems based on their platform ID. For example this is useful to distinguish systems with L4 cache versus ones without. There is a 5 bit identifier (also called processor flags) in the IA32_PLATFORM_ID MSR that can give a more fine grained

[PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

In order to the save power consumption, as a workaround, suspend forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt Configuration Register in the SFRs while OHCI USB suspend. This suspend operation must be done before the USB clock is disabled, resume after the USB clock

[PATCH v2 0/2] ARM: ohci-at91: Add support to forcibly suspend ports while sleep

To save the power consumption, add a new compatible to support forcibly suspend the USB PORTA/B/C via OHCI Interrupt Configuration SFR Register. Changes in v2: - Add compatible to support forcibly suspend the ports. - Add soc/at91/at91_sfr.h to accommodate the defines. - Add error checking for

[PATCH v2 0/2] ARM: ohci-at91: Add support to forcibly suspend ports while sleep

To save the power consumption, add a new compatible to support forcibly suspend the USB PORTA/B/C via OHCI Interrupt Configuration SFR Register. Changes in v2: - Add compatible to support forcibly suspend the ports. - Add soc/at91/at91_sfr.h to accommodate the defines. - Add error checking for

[PATCH] x86/microcode/intel: Quieten down microcode updates on large systems

From: Andi Kleen On large systems the microcode driver is very noisy, because it prints a line for each CPU. The lines are redundant because because usually all CPUs are updated to the same microcode revision. All other subsystems have been patched previously to not print

[PATCH] x86/microcode/intel: Quieten down microcode updates on large systems

From: Andi Kleen On large systems the microcode driver is very noisy, because it prints a line for each CPU. The lines are redundant because because usually all CPUs are updated to the same microcode revision. All other subsystems have been patched previously to not print a line for each CPU.

[PATCH v2 2/7] iio: adc: ad7791: claim direct mode when writing frequency

Driver was checking for direct mode and trying to lock it, but left a gap where mode could change before the desired operation. Use iio_device_claim_direct_mode() to guarantee device stays in direct mode. Refactor function to clarify look-up followed by lock sequence. Signed-off-by: Alison

[PATCH v2 2/7] iio: adc: ad7791: claim direct mode when writing frequency

Driver was checking for direct mode and trying to lock it, but left a gap where mode could change before the desired operation. Use iio_device_claim_direct_mode() to guarantee device stays in direct mode. Refactor function to clarify look-up followed by lock sequence. Signed-off-by: Alison

Re: issue when applying ICC profile to display after drm/i915 change

This one fixed my issue. did not try the other one. https://patchwork.freedesktop.org/series/5467/ thanks kui.z On Tue, May 31, 2016 at 3:04 AM, Lionel Landwerlin wrote: > This 2 patches should fix the issue : > > https://patchwork.freedesktop.org/series/5467/ >

Re: issue when applying ICC profile to display after drm/i915 change

This one fixed my issue. did not try the other one. https://patchwork.freedesktop.org/series/5467/ thanks kui.z On Tue, May 31, 2016 at 3:04 AM, Lionel Landwerlin wrote: > This 2 patches should fix the issue : > > https://patchwork.freedesktop.org/series/5467/ >

Re: [PATCH 8/8] mwifiex: use better message and error code when OF node doesn't match

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT > binding document lists the possible compatible strings that a SDIO child > node can have, so the driver checks if the

Re: [PATCH 8/8] mwifiex: use better message and error code when OF node doesn't match

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT > binding document lists the possible compatible strings that a SDIO child > node can have, so the driver checks if the defined in the node

Re: [PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT > binding document say that the "interrupts" property in the child node is > optional. So the property being missed

Re: [PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT > binding document say that the "interrupts" property in the child node is > optional. So the property being missed shouldn't be treated as an

Re: [PATCH 6/8] mwifiex: check if mwifiex_sdio_probe_of() fails and return error

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > The function can fail so the returned value should be checked > and the error propagated to the caller in case of a failure. > > Signed-off-by: Javier Martinez Canillas

Re: [PATCH 6/8] mwifiex: check if mwifiex_sdio_probe_of() fails and return error

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > The function can fail so the returned value should be checked > and the error propagated to the caller in case of a failure. > > Signed-off-by: Javier Martinez Canillas This looks sensible to me. Reviewed-by: Julian

Re: [PATCH 4/8] mwifiex: consolidate mwifiex_sdio_probe() error paths

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > Instead of duplicating part of the cleanups needed in case of an error > in .probe callback, have a single error path and use goto labels as is > common practice in the kernel. > > This also has

Re: [PATCH 4/8] mwifiex: consolidate mwifiex_sdio_probe() error paths

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > Instead of duplicating part of the cleanups needed in case of an error > in .probe callback, have a single error path and use goto labels as is > common practice in the kernel. > > This also has the nice side effect that

Re: [PATCH 3/8] mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > There's only a check if mwifiex_add_card() returned a nonzero value, but > the actual error code is neither stored nor propagated to the caller. So > instead of always returning -1 (which is

Re: [PATCH 3/8] mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > There's only a check if mwifiex_add_card() returned a nonzero value, but > the actual error code is neither stored nor propagated to the caller. So > instead of always returning -1 (which is -EPERM and not a suitable

Re: [PART1 V5 08/13] svm: Add interrupt injection via AVIC

Hi, Sorry for late response on this. On 5/10/16 09:50, Paolo Bonzini wrote: On 10/05/2016 11:19, Borislav Petkov wrote: This patch introduces a new mechanism to inject interrupt using AVIC. Since VINTR is not supported when enable AVIC, we need to inject "... is not supported when

Re: [PART1 V5 08/13] svm: Add interrupt injection via AVIC

Hi, Sorry for late response on this. On 5/10/16 09:50, Paolo Bonzini wrote: On 10/05/2016 11:19, Borislav Petkov wrote: This patch introduces a new mechanism to inject interrupt using AVIC. Since VINTR is not supported when enable AVIC, we need to inject "... is not supported when

[GIT] Sparc

Please pull to get these sparc64 mmu context allocation and trap return bug fixes, thanks. The following changes since commit ecc5fbd5ef472a4c659dc56a5739b3f041c0530c: Merge tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm (2016-05-25 10:40:15

[GIT] Sparc

Please pull to get these sparc64 mmu context allocation and trap return bug fixes, thanks. The following changes since commit ecc5fbd5ef472a4c659dc56a5739b3f041c0530c: Merge tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm (2016-05-25 10:40:15

Re: [PATCH 5/8] mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > It's better to have the device name prefixed in the error message. > > Signed-off-by: Javier Martinez Canillas This looks right to me. Reviewed-by: Julian Calaby

Re: [PATCH 5/8] mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > It's better to have the device name prefixed in the error message. > > Signed-off-by: Javier Martinez Canillas This looks right to me. Reviewed-by: Julian Calaby > --- > >

Re: [PATCH 2/8] mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > If the sdio_enable_func() function fails on .probe, the -EIO errno code > is always returned but that could make more difficult to debug and find > the cause of why the function actually failed. >

Re: [PATCH 2/8] mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > If the sdio_enable_func() function fails on .probe, the -EIO errno code > is always returned but that could make more difficult to debug and find > the cause of why the function actually failed. > > Since the

Re: [PATCH 1/8] mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > SDIO is an auto enumerable bus so the SDIO devices are matched using the > sdio_device_id table and not using compatible strings from a OF id table. > > However, commit ce4f6f0c353b ("mwifiex: add

Re: [PATCH 1/8] mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node

Hi All, On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas wrote: > SDIO is an auto enumerable bus so the SDIO devices are matched using the > sdio_device_id table and not using compatible strings from a OF id table. > > However, commit ce4f6f0c353b ("mwifiex: add platform specific

Re: [PATCH] Input: raydium_i2c_ts - do not ignore EPROBE_DEFER from gpiod_get_optional

On Tue, May 31, 2016 at 6:30 PM, Dmitry Torokhov wrote: > We should not be ignoring -EPROBE_DEFER reported by > devm_gpiod_get_optional(), but report it as any other error to the upper > layers. While we are at it simplify check for the presence of reset GPIO > and

Re: [PATCH] Input: raydium_i2c_ts - do not ignore EPROBE_DEFER from gpiod_get_optional

On Tue, May 31, 2016 at 6:30 PM, Dmitry Torokhov wrote: > We should not be ignoring -EPROBE_DEFER reported by > devm_gpiod_get_optional(), but report it as any other error to the upper > layers. While we are at it simplify check for the presence of reset GPIO > and instead of using IS_ERR_OR_NULL

Re: [PATCH 00/15] thermal: sysfs: add locking

On Tuesday 31 May 2016 12:01 PM, Eduardo Valentin wrote: Hello, Several thermal sysfs entries are currently being called from userspace without locking. Data and calls to ops are accessed deliberated without any care for locking. This patch series attempts to fix this. Now that sysfs

Re: [PATCH 00/15] thermal: sysfs: add locking

On Tuesday 31 May 2016 12:01 PM, Eduardo Valentin wrote: Hello, Several thermal sysfs entries are currently being called from userspace without locking. Data and calls to ops are accessed deliberated without any care for locking. This patch series attempts to fix this. Now that sysfs

Re: [PATCH v2 06/10] drm/rockchip: analogix_dp: make panel detect to an optional action

On 2016年05月24日 13:02, Yakir Yang wrote: Some boards don't need to declare a panel device node, like the display interface is DP monitors, so it's necessary to make the panel detect to an optional action. Signed-off-by: Yakir Yang --- Looks for me, So: Acked-by: Mark Yao

Re: [PATCH v2 06/10] drm/rockchip: analogix_dp: make panel detect to an optional action

On 2016年05月24日 13:02, Yakir Yang wrote: Some boards don't need to declare a panel device node, like the display interface is DP monitors, so it's necessary to make the panel detect to an optional action. Signed-off-by: Yakir Yang --- Looks for me, So: Acked-by: Mark Yao -- Ｍark Yao

Re: [PATCH v2 08/10] drm/rockchip: analogix_dp: correct the connector display color format and bpc

On 2016年05月24日 13:02, Yakir Yang wrote: Rockchip VOP couldn't output YUV video format for eDP controller, so when driver detect connector support YUV video format, we need to hack it down to RGB888. Signed-off-by: Yakir Yang --- Changes in v2: None

Re: [PATCH v2 08/10] drm/rockchip: analogix_dp: correct the connector display color format and bpc

On 2016年05月24日 13:02, Yakir Yang wrote: Rockchip VOP couldn't output YUV video format for eDP controller, so when driver detect connector support YUV video format, we need to hack it down to RGB888. Signed-off-by: Yakir Yang --- Changes in v2: None

Re: [PATCH v2 09/10] drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode

On 2016年05月24日 13:02, Yakir Yang wrote: The hardware IC designed that VOP must output the RGB10 video format to eDP contoller, and if eDP panel only support RGB8, then eDP contoller should cut down the video data, not via VOP contoller, that's why we need to hardcode the VOP output mode to RGA10

Re: [PATCH v2 09/10] drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode

On 2016年05月24日 13:02, Yakir Yang wrote: The hardware IC designed that VOP must output the RGB10 video format to eDP contoller, and if eDP panel only support RGB8, then eDP contoller should cut down the video data, not via VOP contoller, that's why we need to hardcode the VOP output mode to RGA10

[GIT] Networking

1) Fix negative error code usage in ATM layer, from Stefan Hajnoczi. 2) If CONFIG_SYSCTL is disabled, the default TTL is not initialized properly. From Ezequiel Garcia. 3) Missing spinlock init in mvneta driver, from Gregory CLEMENT. 4) Missing unlocks in hwmb error paths, also from

[GIT] Networking

1) Fix negative error code usage in ATM layer, from Stefan Hajnoczi. 2) If CONFIG_SYSCTL is disabled, the default TTL is not initialized properly. From Ezequiel Garcia. 3) Missing spinlock init in mvneta driver, from Gregory CLEMENT. 4) Missing unlocks in hwmb error paths, also from

[PATCH] vfio/pci: Allow VPD short read

The size of the VPD area is not necessarily 4-byte aligned, so a pci_vpd_read() might return less than 4 bytes. Zero our buffer and accept anything other than an error. Intel X710 NICs exercise this. Fixes: 4e1a635552d3 ("vfio/pci: Use kernel VPD access functions") Signed-off-by: Alex

[PATCH] vfio/pci: Allow VPD short read

The size of the VPD area is not necessarily 4-byte aligned, so a pci_vpd_read() might return less than 4 bytes. Zero our buffer and accept anything other than an error. Intel X710 NICs exercise this. Fixes: 4e1a635552d3 ("vfio/pci: Use kernel VPD access functions") Signed-off-by: Alex

Re: [PATCH v2 4/8] zram: use crypto api to check alg availability

On (06/01/16 11:27), Minchan Kim wrote: [..] > > > So, if we do 'cat /sys/block/zram0/comp_algorithm", every crypto modules > > > in the backend array are loaded in memory and not unloaded until admin > > > executes rmmod? Right? > > > > yes, I think so. > > It scares me. Common case, except one

Re: [PATCH v2 4/8] zram: use crypto api to check alg availability

On (06/01/16 11:27), Minchan Kim wrote: [..] > > > So, if we do 'cat /sys/block/zram0/comp_algorithm", every crypto modules > > > in the backend array are loaded in memory and not unloaded until admin > > > executes rmmod? Right? > > > > yes, I think so. > > It scares me. Common case, except one

Re: [PATCH v4 09/10] cpuidle/powernv: Add support for POWER ISA v3 idle states

On Tue, 2016-05-31 at 19:20 +0530, Shreyas B Prabhu wrote: > On 05/30/2016 07:56 PM, Daniel Lezcano wrote: > > On 05/24/2016 03:15 PM, Shreyas B. Prabhu wrote: > > > +psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val), > > > +GFP_KERNEL); > > > +rc =

Re: [PATCH v4 09/10] cpuidle/powernv: Add support for POWER ISA v3 idle states

On Tue, 2016-05-31 at 19:20 +0530, Shreyas B Prabhu wrote: > On 05/30/2016 07:56 PM, Daniel Lezcano wrote: > > On 05/24/2016 03:15 PM, Shreyas B. Prabhu wrote: > > > +psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val), > > > +GFP_KERNEL); > > > +rc =

linux-next: Tree for Jun 1

Hi all, Changes since 20160531: My fixes tree contains: of: silence warnings due to max() usage The arm tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 1100 936 files changed, 38159 insertions(+), 17475 deletions

linux-next: Tree for Jun 1

Hi all, Changes since 20160531: My fixes tree contains: of: silence warnings due to max() usage The arm tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 1100 936 files changed, 38159 insertions(+), 17475 deletions

Re: [PATCH] mm/hugetlb: fix huge page reserve accounting for private mappings

> > When creating a private mapping of a hugetlbfs file, it is possible to > unmap pages via ftruncate or fallocate hole punch. If subsequent faults > repopulate these mappings, the reserve counts will go negative. This > is because the code currently assumes all faults to private mappings will

[PATCH] dt: bindings: fix documentation for MARVELL's bt-sd8xxx wireless device

The property marvell,wakeup-pin and marvell,wakeup-gap-ms are read as u16 in the driver. Fix documentation and example accordingly. Signed-off-by: Wei-Ning Huang --- Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt | 8 1 file changed, 4 insertions(+),

Re: [PATCH] mm/hugetlb: fix huge page reserve accounting for private mappings

> > When creating a private mapping of a hugetlbfs file, it is possible to > unmap pages via ftruncate or fallocate hole punch. If subsequent faults > repopulate these mappings, the reserve counts will go negative. This > is because the code currently assumes all faults to private mappings will

[PATCH] dt: bindings: fix documentation for MARVELL's bt-sd8xxx wireless device

The property marvell,wakeup-pin and marvell,wakeup-gap-ms are read as u16 in the driver. Fix documentation and example accordingly. Signed-off-by: Wei-Ning Huang --- Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff

  1   2   3   4   5   6   7   8   9   10   >