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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
>
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
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
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
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
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
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
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
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
> -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;
> -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
>
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
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
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,
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
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?
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
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
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
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
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
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
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
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
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
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,
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,
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(+),
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
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
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
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
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
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
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
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
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.
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
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
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/
>
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/
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> ---
>
>
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.
>
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
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
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
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
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
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
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
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
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
--
Mark Yao
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
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
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
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
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
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
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
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
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
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
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 =
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 =
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
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
>
> 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
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(+),
>
> 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
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 - 100 of 2138 matches
Mail list logo