[RESEND PATCH 2/6] Documentation: bindings: add dt doc for Rockchip USB Type-C PHY

This patch adds a binding that describes the Rockchip USB Type-C PHY for rk3399. Signed-off-by: Chris Zhong --- .../devicetree/bindings/phy/phy-rockchip-typec.txt | 55 ++ 1 file changed, 55 insertions(+) create mode 100644

[RESEND PATCH 2/6] Documentation: bindings: add dt doc for Rockchip USB Type-C PHY

This patch adds a binding that describes the Rockchip USB Type-C PHY for rk3399. Signed-off-by: Chris Zhong --- .../devicetree/bindings/phy/phy-rockchip-typec.txt | 55 ++ 1 file changed, 55 insertions(+) create mode 100644

[RESEND PATCH 6/6] ASoC: rockchip: Add machine driver for cdn dp codec

The driver is used for cdn dp codec embedded in rk3399 Signed-off-by: Chris Zhong --- .../bindings/sound/rockchip-cdn-dp-audio.txt | 12 ++ sound/soc/rockchip/Kconfig | 9 ++ sound/soc/rockchip/Makefile| 2 +

[RESEND PATCH 5/6] ASoC: cdn-dp: Add cdn DP codec driver

codec driver get some interfaces from cdn-dp driver, than using those to set DP audio formats, corresponding to alsa formats. Signed-off-by: Chris Zhong --- sound/soc/codecs/Kconfig| 3 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/cdn-dp-audio.c | 246

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Friday 27 May 2016 12:01:21 Thorsten Leemhuis wrote: > Pali Rohár wrote on 27.05.2016 11:47: > > […] > > I do not see any long taking SMM call here. Are you really sure > > that your machine freeze when loading or using dell-smm-hwmon? > > Uhh, sorry, it seems something got mixed up somewhere.

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Friday 27 May 2016 12:01:21 Thorsten Leemhuis wrote: > Pali Rohár wrote on 27.05.2016 11:47: > > […] > > I do not see any long taking SMM call here. Are you really sure > > that your machine freeze when loading or using dell-smm-hwmon? > > Uhh, sorry, it seems something got mixed up somewhere.

[RESEND PATCH 0/6] Rockchip Type-C and DispplayPort driver

Sorry, forgot a head file in patch 1, so resend. Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in

[RESEND PATCH 0/6] Rockchip Type-C and DispplayPort driver

Sorry, forgot a head file in patch 1, so resend. Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in

[PATCH RFC v2 kernel] balloon: speed up inflating/deflating process

The implementation of the current virtio-balloon is not very efficient, Bellow is test result of time spends on inflating the balloon to 3GB of a 4GB idle guest: a. allocating pages (6.5%, 103ms) b. sending PFNs to host (68.3%, 787ms) c. address translation (6.1%, 96ms) d. madvise (19%, 300ms)

[PATCH RFC v2 kernel] balloon: speed up inflating/deflating process

The implementation of the current virtio-balloon is not very efficient, Bellow is test result of time spends on inflating the balloon to 3GB of a 4GB idle guest: a. allocating pages (6.5%, 103ms) b. sending PFNs to host (68.3%, 787ms) c. address translation (6.1%, 96ms) d. madvise (19%, 300ms)

Re: [PATCH v3 5/6] pv-qspinlock: use cmpxchg_release in __pv_queued_spin_unlock

On 2016年05月27日 00:57, Peter Zijlstra wrote: On Thu, May 26, 2016 at 06:47:29PM +0200, Peter Zijlstra wrote: On Wed, May 25, 2016 at 04:18:08PM +0800, Pan Xinhui wrote: cmpxchg_release is light-wight than cmpxchg, we can gain a better performace then. On some arch like ppc, barrier impact the

Re: [PATCH v3 5/6] pv-qspinlock: use cmpxchg_release in __pv_queued_spin_unlock

On 2016年05月27日 00:57, Peter Zijlstra wrote: On Thu, May 26, 2016 at 06:47:29PM +0200, Peter Zijlstra wrote: On Wed, May 25, 2016 at 04:18:08PM +0800, Pan Xinhui wrote: cmpxchg_release is light-wight than cmpxchg, we can gain a better performace then. On some arch like ppc, barrier impact the

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

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 spurious_wakeup, and it fails to get the lock as there is lock stealing, then after a short spin, we need hash the lock again and enter pv_wait to yield. Currently after a

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

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 spurious_wakeup, and it fails to get the lock as there is lock stealing, then after a short spin, we need hash the lock again and enter pv_wait to yield. Currently after a

Re: [PATCH 2/2] pci: Add PCIe driver for Rockchip Soc

Hi, On 2016/5/27 15:13, Bharat Kumar Gogada wrote: + +static int rockchip_pcie_rd_other_conf(struct rockchip_pcie_port *pp, + struct pci_bus *bus, u32 devfn, + int where, int size, u32 *val) +{ + u32 busdev; + +

Re: [PATCH 2/2] pci: Add PCIe driver for Rockchip Soc

Hi, On 2016/5/27 15:13, Bharat Kumar Gogada wrote: + +static int rockchip_pcie_rd_other_conf(struct rockchip_pcie_port *pp, + struct pci_bus *bus, u32 devfn, + int where, int size, u32 *val) +{ + u32 busdev; + +

Re: [PATCH] arm64: defconfig: Enable cros-ec and battery driver

Hi Krzysztof, On 27/05/16 09:37, Krzysztof Kozlowski wrote: ... > Indeed I was struggling with similar issue in bq27x00_battery. The issue > was introduced by... me :( when moving the ownership of power supply > structure from driver to the core. However IMHO my change exposed the >

Re: [PATCH] arm64: defconfig: Enable cros-ec and battery driver

Hi Krzysztof, On 27/05/16 09:37, Krzysztof Kozlowski wrote: ... > Indeed I was struggling with similar issue in bq27x00_battery. The issue > was introduced by... me :( when moving the ownership of power supply > structure from driver to the core. However IMHO my change exposed the >

Re: Rcu synchronization of a list

On Fri, May 27, 2016 at 12:40:51PM +0300, Nikolay Borisov wrote: > Hello, > > I'm currently dealing with a synchronization scheme which utilizes RCU > but I'm observing a race condition. So I have an rcu-enabled list, which > contains various entries. The add/delete paths of the list are

Re: Rcu synchronization of a list

On Fri, May 27, 2016 at 12:40:51PM +0300, Nikolay Borisov wrote: > Hello, > > I'm currently dealing with a synchronization scheme which utilizes RCU > but I'm observing a race condition. So I have an rcu-enabled list, which > contains various entries. The add/delete paths of the list are

Re: [PATCH 2/2 V2] staging: dgnc: remove redundant null check in

On 27/05/16 02:43, Daeseok Youn wrote: > the "brd" was already checked for NULL before calling dgnc_do_remap(). > > the dgnc_do_remap() function was called only > from the dgnc_found_board() and the DGNC_BOARD_MAGIC value > was assigned to "brd->magic" in dgcn_found_board(). So it doesn't > need

Re: [PATCH 2/2 V2] staging: dgnc: remove redundant null check in

On 27/05/16 02:43, Daeseok Youn wrote: > the "brd" was already checked for NULL before calling dgnc_do_remap(). > > the dgnc_do_remap() function was called only > from the dgnc_found_board() and the DGNC_BOARD_MAGIC value > was assigned to "brd->magic" in dgcn_found_board(). So it doesn't > need

Re: [PATCH 1/2 v2] staging: dgnc: remove redundant NULL check for brd

On 27/05/16 02:42, Daeseok Youn wrote: > the "brd" value cannot be NULL in dgnc_finalize_board_init(). > Because "brd" as a parameter of this function was already > checked for NULL. > > the dgnc_finalize_board_init() as a static function was called > only from dgnc_found_board() function and

Re: [PATCH 1/2 v2] staging: dgnc: remove redundant NULL check for brd

On 27/05/16 02:42, Daeseok Youn wrote: > the "brd" value cannot be NULL in dgnc_finalize_board_init(). > Because "brd" as a parameter of this function was already > checked for NULL. > > the dgnc_finalize_board_init() as a static function was called > only from dgnc_found_board() function and

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

On 16-05-27 10:31:55, Arnd Bergmann wrote: > On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote: > > > > So if I understand correctly, the binding at the SoC level is fine. > > Keeping that but removing the additional made-up properties, viz. below > > > > rom-revision:

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

On 16-05-27 10:31:55, Arnd Bergmann wrote: > On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote: > > > > So if I understand correctly, the binding at the SoC level is fine. > > Keeping that but removing the additional made-up properties, viz. below > > > > rom-revision:

[PATCH v2 4/4] hwrng: bcm2835: Read as much data as available

Read the requested number of data from the fifo Signed-off-by: Yendapally Reddy Dhananjaya Reddy Reviewed-by: Eric Anholt --- drivers/char/hw_random/bcm2835-rng.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[PATCH v2 4/4] hwrng: bcm2835: Read as much data as available

Read the requested number of data from the fifo Signed-off-by: Yendapally Reddy Dhananjaya Reddy Reviewed-by: Eric Anholt --- drivers/char/hw_random/bcm2835-rng.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/bcm2835-rng.c

[PATCH v2 3/4] ARM: dts: nsp: Add rng device tree entry

Add support for the random number generator to the Northstar Plus SoC device tree. Signed-off-by: Yendapally Reddy Dhananjaya Reddy --- arch/arm/boot/dts/bcm-nsp.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi

[PATCH v2 3/4] ARM: dts: nsp: Add rng device tree entry

Add support for the random number generator to the Northstar Plus SoC device tree. Signed-off-by: Yendapally Reddy Dhananjaya Reddy --- arch/arm/boot/dts/bcm-nsp.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi index

[PATCH v2 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings

Document the bindings used by Northstar Plus(NSP) SoC random number generator. Signed-off-by: Yendapally Reddy Dhananjaya Reddy Acked-by: Eric Anholt --- Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 7 ++- 1 file changed, 6

[PATCH v2 2/4] hwrng: bcm2835: Support Broadcom NSP SoC rng

This supports the random number generator available in NSP SoC. Masks the rng interrupt for NSP. Signed-off-by: Yendapally Reddy Dhananjaya Reddy Acked-by: Eric Anholt --- drivers/char/hw_random/Kconfig | 2 +-

[PATCH v2 0/4] hw rng support for NSP SoC

This patchset contains the hw random number generator support for the Broadcom's NSP SoC. The block is similar to the block available in bcm2835 with different default interrupt mask value. Due to lack of documentation, I cannot confirm the interrupt mask register details in bcm2835. In an effort

[PATCH v2 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings

Document the bindings used by Northstar Plus(NSP) SoC random number generator. Signed-off-by: Yendapally Reddy Dhananjaya Reddy Acked-by: Eric Anholt --- Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git

[PATCH v2 2/4] hwrng: bcm2835: Support Broadcom NSP SoC rng

This supports the random number generator available in NSP SoC. Masks the rng interrupt for NSP. Signed-off-by: Yendapally Reddy Dhananjaya Reddy Acked-by: Eric Anholt --- drivers/char/hw_random/Kconfig | 2 +- drivers/char/hw_random/bcm2835-rng.c | 34 ++

[PATCH v2 0/4] hw rng support for NSP SoC

This patchset contains the hw random number generator support for the Broadcom's NSP SoC. The block is similar to the block available in bcm2835 with different default interrupt mask value. Due to lack of documentation, I cannot confirm the interrupt mask register details in bcm2835. In an effort

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Thu, May 26, 2016 at 12:43:44PM -0700, David Miller wrote: > From: Catalin Marinas > Date: Thu, 26 May 2016 15:20:58 +0100 > > > We can solve (a) by adding more __SC_WRAP annotations in the generic > > unistd.h. > ... > > I really think it's much more robust to

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Thu, May 26, 2016 at 12:43:44PM -0700, David Miller wrote: > From: Catalin Marinas > Date: Thu, 26 May 2016 15:20:58 +0100 > > > We can solve (a) by adding more __SC_WRAP annotations in the generic > > unistd.h. > ... > > I really think it's much more robust to clear the tops of the

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

Pali Rohár wrote on 27.05.2016 11:47: > On Friday 27 May 2016 10:00:05 Thorsten Leemhuis wrote: >> Pali Rohár wrote on 26.05.2016 17:51: >> > On Thursday 26 May 2016 17:39:57 Thorsten Leemhuis wrote: >> >> > I need to know if this patch fixes problem on Dell Studio XPS 8000 >> >> > and Dell Studio

[PATCH v2] perf tools: Add arch/*/include/generated/ to .gitignore

Commit 1b700c9975008615ad470cf79acc8455ce60a695 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") that automatically generate per-arch syscall table arrays e.g. arch/x86/include/generated/asm/syscalls_64.c So add this directory to .gitignore Cc: Namhyung Kim

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

Pali Rohár wrote on 27.05.2016 11:47: > On Friday 27 May 2016 10:00:05 Thorsten Leemhuis wrote: >> Pali Rohár wrote on 26.05.2016 17:51: >> > On Thursday 26 May 2016 17:39:57 Thorsten Leemhuis wrote: >> >> > I need to know if this patch fixes problem on Dell Studio XPS 8000 >> >> > and Dell Studio

[PATCH v2] perf tools: Add arch/*/include/generated/ to .gitignore

Commit 1b700c9975008615ad470cf79acc8455ce60a695 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") that automatically generate per-arch syscall table arrays e.g. arch/x86/include/generated/asm/syscalls_64.c So add this directory to .gitignore Cc: Namhyung Kim Cc:

Re: [RESEND PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

Hi, Wangnan Thank you !! I'll resend modified patch, now Thanks, Taeung On 05/27/2016 06:53 PM, Wangnan (F) wrote: On 2016/5/27 17:15, Taeung Song wrote: Hi, Arnaldo If you have a little time, could you check this simple patch ? This patch is minor but everytime I build tools/perf code,

Re: [RESEND PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

Hi, Wangnan Thank you !! I'll resend modified patch, now Thanks, Taeung On 05/27/2016 06:53 PM, Wangnan (F) wrote: On 2016/5/27 17:15, Taeung Song wrote: Hi, Arnaldo If you have a little time, could you check this simple patch ? This patch is minor but everytime I build tools/perf code,

Re: Re: [PATCH] usb: core: fix a double free in the usb driver

>On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote: >> There is a double free problem in the usb driver. > >Which driver? When I using the USB OTG Storage, this issue happened. When remove the OTG Storage, it reproduced sometimes. > >> This is caused by delayed deregister for scsi

Re: Re: [PATCH] usb: core: fix a double free in the usb driver

>On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote: >> There is a double free problem in the usb driver. > >Which driver? When I using the USB OTG Storage, this issue happened. When remove the OTG Storage, it reproduced sometimes. > >> This is caused by delayed deregister for scsi

Re: [RESEND PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

On 2016/5/27 17:15, Taeung Song wrote: Hi, Arnaldo If you have a little time, could you check this simple patch ? This patch is minor but everytime I build tools/perf code, untracked file(arch/*/include/generated/) is always generated.. like below taeung ~/git/linux-perf/tools/perf :> make

Re: [RESEND PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

On 2016/5/27 17:15, Taeung Song wrote: Hi, Arnaldo If you have a little time, could you check this simple patch ? This patch is minor but everytime I build tools/perf code, untracked file(arch/*/include/generated/) is always generated.. like below taeung ~/git/linux-perf/tools/perf :> make

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On 26/05/2016 22:33, yunhong jiang wrote: > On Thu, 26 May 2016 12:26:27 +0200 > Paolo Bonzini wrote: > >> >> >> On 25/05/2016 04:47, Wanpeng Li wrote: >>> From: Wanpeng Li >>> >>> If an emulated lapic timer will fire soon(in the scope of 10us the

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On 26/05/2016 22:33, yunhong jiang wrote: > On Thu, 26 May 2016 12:26:27 +0200 > Paolo Bonzini wrote: > >> >> >> On 25/05/2016 04:47, Wanpeng Li wrote: >>> From: Wanpeng Li >>> >>> If an emulated lapic timer will fire soon(in the scope of 10us the >>> base of dynamic halt-polling, lower-end

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Friday 27 May 2016 10:00:05 Thorsten Leemhuis wrote: > Pali Rohár wrote on 26.05.2016 17:51: > > On Thursday 26 May 2016 17:39:57 Thorsten Leemhuis wrote: > >> > I need to know if this patch fixes problem on Dell Studio XPS 8000 > >> > and Dell Studio XPS 8100 machines, so we can revert git

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Friday 27 May 2016 10:00:05 Thorsten Leemhuis wrote: > Pali Rohár wrote on 26.05.2016 17:51: > > On Thursday 26 May 2016 17:39:57 Thorsten Leemhuis wrote: > >> > I need to know if this patch fixes problem on Dell Studio XPS 8000 > >> > and Dell Studio XPS 8100 machines, so we can revert git

[PATCH v5] input: tablet: add Pegasus Notetaker tablet driver

This adds a driver for the Pegasus Notetaker Pen. When connected, this uses the Pen as an input tablet. This device was sold in various different brandings, for example "Pegasus Mobile Notetaker M210", "Genie e-note The Notetaker", "Staedtler Digital ballpoint pen 990 01",

[PATCH v5] input: tablet: add Pegasus Notetaker tablet driver

This adds a driver for the Pegasus Notetaker Pen. When connected, this uses the Pen as an input tablet. This device was sold in various different brandings, for example "Pegasus Mobile Notetaker M210", "Genie e-note The Notetaker", "Staedtler Digital ballpoint pen 990 01",

Rcu synchronization of a list

Hello, I'm currently dealing with a synchronization scheme which utilizes RCU but I'm observing a race condition. So I have an rcu-enabled list, which contains various entries. The add/delete paths of the list are protected by a single spin_lock. I'm observing the following thing happening: T1

Rcu synchronization of a list

Hello, I'm currently dealing with a synchronization scheme which utilizes RCU but I'm observing a race condition. So I have an rcu-enabled list, which contains various entries. The add/delete paths of the list are protected by a single spin_lock. I'm observing the following thing happening: T1

Re: [RFC v2 2/5] drm/mediatke: add support for Mediatek SoC MT2701

Hi YT Shen, There's a typo in the commit summary - s/mediatke/mediatek/. On 20 May 2016 at 16:05, wrote: > From: YT Shen > > This patch add support for the Mediatek MT2701 DISP subsystem. > There is only one OVL engine in MT2701. > As is you

Re: [RFC v2 2/5] drm/mediatke: add support for Mediatek SoC MT2701

Hi YT Shen, There's a typo in the commit summary - s/mediatke/mediatek/. On 20 May 2016 at 16:05, wrote: > From: YT Shen > > This patch add support for the Mediatek MT2701 DISP subsystem. > There is only one OVL engine in MT2701. > As is you introduce a broken driver only to fix it up with

[PATCH 3/6] crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU

This patchs enhances the IPSEC_ESP related functions for them to also supports the same operations with descriptor type HMAC_SNOOP_NO_AFEU. The differences between the two descriptor types are: * pointeurs 2 and 3 are swaped (Confidentiality key and Primary EU Context IN) * HMAC_SNOOP_NO_AFEU

[PATCH 3/6] crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU

This patchs enhances the IPSEC_ESP related functions for them to also supports the same operations with descriptor type HMAC_SNOOP_NO_AFEU. The differences between the two descriptor types are: * pointeurs 2 and 3 are swaped (Confidentiality key and Primary EU Context IN) * HMAC_SNOOP_NO_AFEU

[PATCH 5/6] crypto: talitos - implement cra_priority

SEC1 doesn't have IPSEC_ESP descriptor type but it is able to perform IPSEC using HMAC_SNOOP_NO_AFEU, which is also existing on SEC2 In order to be able to define descriptors templates for SEC1 without breaking SEC2+, we have to give lower priority to HMAC_SNOOP_NO_AFEU so that SEC2+ selects

[PATCH 5/6] crypto: talitos - implement cra_priority

SEC1 doesn't have IPSEC_ESP descriptor type but it is able to perform IPSEC using HMAC_SNOOP_NO_AFEU, which is also existing on SEC2 In order to be able to define descriptors templates for SEC1 without breaking SEC2+, we have to give lower priority to HMAC_SNOOP_NO_AFEU so that SEC2+ selects

[PATCH 0/6] crypto: talitos - implementation of AEAD for SEC1

This set of patches provides the implementation of AEAD for talitos SEC1. Christophe Leroy (6): crypto: talitos - using helpers for all talitos_ptr operations crypto: talitos - making mapping helpers more generic crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU crypto:

[PATCH 4/6] crypto: talitos - sg_to_link_tbl() not used anymore, remove it

Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index c17e6c9..fcdf83b 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@

[PATCH 1/6] crypto: talitos - using helpers for all talitos_ptr operations

Use helper for all modifications to talitos_ptr in preparation to the implementation of AEAD for SEC1 to_talitos_ptr_extent_clear() has been removed in favor of to_talitos_ptr_ext_set() to set any value and to_talitos_ptr_ext_or() to or the extent field with a value name has been shorten to help

[PATCH 6/6] crypto: talitos - templates for AEAD using HMAC_SNOOP_NO_AFEU

This will allow IPSEC on SEC1 Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 180 +++ 1 file changed, 180 insertions(+) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index b554f56..d3951e3

[PATCH 4/6] crypto: talitos - sg_to_link_tbl() not used anymore, remove it

Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index c17e6c9..fcdf83b 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -,14 +,6 @@ next:

[PATCH 1/6] crypto: talitos - using helpers for all talitos_ptr operations

Use helper for all modifications to talitos_ptr in preparation to the implementation of AEAD for SEC1 to_talitos_ptr_extent_clear() has been removed in favor of to_talitos_ptr_ext_set() to set any value and to_talitos_ptr_ext_or() to or the extent field with a value name has been shorten to help

[PATCH 6/6] crypto: talitos - templates for AEAD using HMAC_SNOOP_NO_AFEU

This will allow IPSEC on SEC1 Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 180 +++ 1 file changed, 180 insertions(+) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index b554f56..d3951e3 100644 ---

[PATCH 0/6] crypto: talitos - implementation of AEAD for SEC1

This set of patches provides the implementation of AEAD for talitos SEC1. Christophe Leroy (6): crypto: talitos - using helpers for all talitos_ptr operations crypto: talitos - making mapping helpers more generic crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU crypto:

[PATCH 2/6] crypto: talitos - making mapping helpers more generic

In preparation of IPSEC for SEC1, first step is to make the mapping helpers more generic so that they can also be used by AEAD functions. First, the functions are moved before IPSEC functions in talitos.c talitos_sg_unmap() and unmap_sg_talitos_ptr() are merged as they are quite similar, the

[PATCH 2/6] crypto: talitos - making mapping helpers more generic

In preparation of IPSEC for SEC1, first step is to make the mapping helpers more generic so that they can also be used by AEAD functions. First, the functions are moved before IPSEC functions in talitos.c talitos_sg_unmap() and unmap_sg_talitos_ptr() are merged as they are quite similar, the

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Fri, May 27, 2016 at 10:42:59AM +0200, Arnd Bergmann wrote: > On Friday, May 27, 2016 8:03:57 AM CEST Heiko Carstens wrote: > > > > > > Cost wise, this seems like it all cancels out in the end, but what > > > > > > do I know? > > > > > > > > > > I think you know something, and I also think

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Fri, May 27, 2016 at 10:42:59AM +0200, Arnd Bergmann wrote: > On Friday, May 27, 2016 8:03:57 AM CEST Heiko Carstens wrote: > > > > > > Cost wise, this seems like it all cancels out in the end, but what > > > > > > do I know? > > > > > > > > > > I think you know something, and I also think

Re: [RFC v2 1/5] drm/mediatek: rename macros, add chip suffix

On 20 May 2016 at 16:05, wrote: > From: YT Shen > > Add MT8173 suffix for hardware related macros. > Why suffix ? Pretty much everyone else uses prefix. -Emil

Re: BLKZEROOUT not zeroing md dev on VMDK

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 check `write_same_max_bytes` it has turned 0.

Re: [RFC v2 1/5] drm/mediatek: rename macros, add chip suffix

On 20 May 2016 at 16:05, wrote: > From: YT Shen > > Add MT8173 suffix for hardware related macros. > Why suffix ? Pretty much everyone else uses prefix. -Emil

Re: BLKZEROOUT not zeroing md dev on VMDK

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 check `write_same_max_bytes` it has turned 0.

Re: [RFC v2 3/5] drm/mediatek: add *driver_data for different hardware settings

On 27 May 2016 at 08:31, YT Shen wrote: > Hi CK, > > > On Mon, 2016-05-23 at 17:43 +0800, CK Hu wrote: >> Hi, YT: >> >> One comment below. >> >> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@mediatek.com wrote: >> > From: YT Shen >> > >> > There are some

Re: [RFC v2 3/5] drm/mediatek: add *driver_data for different hardware settings

On 27 May 2016 at 08:31, YT Shen wrote: > Hi CK, > > > On Mon, 2016-05-23 at 17:43 +0800, CK Hu wrote: >> Hi, YT: >> >> One comment below. >> >> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@mediatek.com wrote: >> > From: YT Shen >> > >> > There are some hardware settings changed, between MT8173 &

Re: [RFC PATCH 0/4] cgroup aware workqueues

> Tejun Heo wrote on 03/31/2016 08:14:35 PM: > > Hello, Michael. > > On Thu, Mar 31, 2016 at 08:17:13AM +0200, Michael Rapoport wrote: > > > There really shouldn't be any difference when using unbound > > > workqueues. workqueue becomes a convenience thing which manages > > >

Re: [RFC PATCH 0/4] cgroup aware workqueues

> Tejun Heo wrote on 03/31/2016 08:14:35 PM: > > Hello, Michael. > > On Thu, Mar 31, 2016 at 08:17:13AM +0200, Michael Rapoport wrote: > > > There really shouldn't be any difference when using unbound > > > workqueues. workqueue becomes a convenience thing which manages > > > worker pools and

Re: [PATCH] arm64: defconfig: Enable cros-ec and battery driver

On 05/27/2016 10:37 AM, Krzysztof Kozlowski wrote: >> And you might be completely correct, that is something that can only >> happen specifically with the bq27xxx driver. In which case, making the >> fix there should be the fix. I just know from the commit log (and some >> previous work with power

Re: [PATCH] arm64: defconfig: Enable cros-ec and battery driver

On 05/27/2016 10:37 AM, Krzysztof Kozlowski wrote: >> And you might be completely correct, that is something that can only >> happen specifically with the bq27xxx driver. In which case, making the >> fix there should be the fix. I just know from the commit log (and some >> previous work with power

Re: [RESEND PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

Hi, Arnaldo If you have a little time, could you check this simple patch ? This patch is minor but everytime I build tools/perf code, untracked file(arch/*/include/generated/) is always generated.. like below taeung ~/git/linux-perf/tools/perf :> make -j4 BUILD: Doing 'make -j4' parallel

Re: [RESEND PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

Hi, Arnaldo If you have a little time, could you check this simple patch ? This patch is minor but everytime I build tools/perf code, untracked file(arch/*/include/generated/) is always generated.. like below taeung ~/git/linux-perf/tools/perf :> make -j4 BUILD: Doing 'make -j4' parallel

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

Pwm config may sleep so defer it using a worker. On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0. Signed-off-by: Manfred Schlaegl

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

Pwm config may sleep so defer it using a worker. On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0. Signed-off-by: Manfred Schlaegl ---

Re: [PATCH v3 02/12] of: add J-Core cpu bindings

On Thu, May 26, 2016 at 11:33:23AM -0400, Rich Felker wrote: > On Thu, May 26, 2016 at 11:38:29AM +0100, Mark Rutland wrote: > > On Wed, May 25, 2016 at 07:04:08PM -0400, Rich Felker wrote: > > > On Wed, May 25, 2016 at 11:22:15AM +0100, Mark Rutland wrote: > > > > * How must the value be written?

Re: [PATCH v3 02/12] of: add J-Core cpu bindings

On Thu, May 26, 2016 at 11:33:23AM -0400, Rich Felker wrote: > On Thu, May 26, 2016 at 11:38:29AM +0100, Mark Rutland wrote: > > On Wed, May 25, 2016 at 07:04:08PM -0400, Rich Felker wrote: > > > On Wed, May 25, 2016 at 11:22:15AM +0100, Mark Rutland wrote: > > > > * How must the value be written?

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

On 2016-05-27 10:54, Manfred Schlaegl wrote: > > Ok. Thanks for clarification. > I will send a patch with the modifications you suggested before. > > The following patch will also have some slight modifications in line numbers > to make it apply after > cfae56f18 (input: misc: pwm-beeper:

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

On 2016-05-27 10:54, Manfred Schlaegl wrote: > > Ok. Thanks for clarification. > I will send a patch with the modifications you suggested before. > > The following patch will also have some slight modifications in line numbers > to make it apply after > cfae56f18 (input: misc: pwm-beeper:

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On Thu, May 26, 2016 at 05:10:36PM -0400, Chris Metcalf wrote: > On 5/26/2016 10:19 AM, Peter Zijlstra wrote: > >--- a/arch/tile/lib/spinlock_32.c > >+++ b/arch/tile/lib/spinlock_32.c > >@@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock > > if (next == curr) > > return;

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On Thu, May 26, 2016 at 05:10:36PM -0400, Chris Metcalf wrote: > On 5/26/2016 10:19 AM, Peter Zijlstra wrote: > >--- a/arch/tile/lib/spinlock_32.c > >+++ b/arch/tile/lib/spinlock_32.c > >@@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock > > if (next == curr) > > return;

Re: [PATCH 5/7] zram: use crypto api to check alg availability

On Fri, May 27, 2016 at 04:43:45PM +0800, Herbert Xu wrote: > On Fri, May 27, 2016 at 05:27:44PM +0900, Minchan Kim wrote: > > > > Yes, it might be trivial to adding new "string" into the backend array > > if we consider frequency of adding new compressoin algorithm in linux > > but it would be

Re: [PATCH 5/7] zram: use crypto api to check alg availability

On Fri, May 27, 2016 at 04:43:45PM +0800, Herbert Xu wrote: > On Fri, May 27, 2016 at 05:27:44PM +0900, Minchan Kim wrote: > > > > Yes, it might be trivial to adding new "string" into the backend array > > if we consider frequency of adding new compressoin algorithm in linux > > but it would be

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 27 May 2016 at 15:53, Milan Broz wrote: > On 05/27/2016 09:04 AM, Baolin Wang wrote: >> Hi Milan, >> >> On 27 May 2016 at 14:31, Milan Broz wrote: >>> On 05/25/2016 08:12 AM, Baolin Wang wrote: Now some cipher hardware engines prefer to handle

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 27 May 2016 at 15:53, Milan Broz wrote: > On 05/27/2016 09:04 AM, Baolin Wang wrote: >> Hi Milan, >> >> On 27 May 2016 at 14:31, Milan Broz wrote: >>> On 05/25/2016 08:12 AM, Baolin Wang wrote: Now some cipher hardware engines prefer to handle bulk block rather than one sector

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On Fri, May 27, 2016 at 08:46:49AM +0200, Martin Schwidefsky wrote: > > This fixes a number of spin_unlock_wait() users that (not > > unreasonably) rely on this. > > All that is missing is an smp_rmb(), no? Indeed. > > --- a/arch/s390/include/asm/spinlock.h > > +++

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On Fri, May 27, 2016 at 08:46:49AM +0200, Martin Schwidefsky wrote: > > This fixes a number of spin_unlock_wait() users that (not > > unreasonably) rely on this. > > All that is missing is an smp_rmb(), no? Indeed. > > --- a/arch/s390/include/asm/spinlock.h > > +++

<    4   5   6   7   8   9   10   11   12   >