Re: [PATCH 10/15] platform/x86: wmi: make device_type const

On Thu, Aug 31, 2017 at 12:53 AM, Andy Shevchenko wrote: > On Sat, Aug 19, 2017 at 11:22 AM, Bhumika Goyal wrote: >> Make these const as they are only stored in the type field of a device >> structure, which is const. >> Done using Coccinelle. >> >

Re: [PATCH 10/15] platform/x86: wmi: make device_type const

On Thu, Aug 31, 2017 at 12:53 AM, Andy Shevchenko wrote: > On Sat, Aug 19, 2017 at 11:22 AM, Bhumika Goyal wrote: >> Make these const as they are only stored in the type field of a device >> structure, which is const. >> Done using Coccinelle. >> > > Please, stop spamming so many people and MLs

[PATCH] arm64: dts: mediatek: Add cpuidle support for MT2712

Add CPU idle state nodes to enable C1/C2 idle states. Signed-off-by: James Liao --- This patch bases on latest Matthias v4.13-next/dts64 branch [1], add CPU idle states for MT2712. [1] https://github.com/mbgg/linux-mediatek.git

[PATCH] arm64: dts: mediatek: Add cpuidle support for MT2712

Add CPU idle state nodes to enable C1/C2 idle states. Signed-off-by: James Liao --- This patch bases on latest Matthias v4.13-next/dts64 branch [1], add CPU idle states for MT2712. [1] https://github.com/mbgg/linux-mediatek.git arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 25

Re: [PATCH] clk: versatile: make clk_ops const

On 08/22, Bhumika Goyal wrote: > Make this const as it is only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation

Re: [PATCH] clk: versatile: make clk_ops const

On 08/22, Bhumika Goyal wrote: > Make this const as it is only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH v4] ARC: clk: introduce HSDK pll driver

On 08/25, Eugeniy Paltsev wrote: > HSDK board manages its clocks using various PLLs. These PLL have same > dividers and corresponding control registers mapped to different addresses. > So we add one common driver for such PLLs. > > Each PLL on HSDK board consists of three dividers: IDIV, FBDIV

Re: [PATCH v4] ARC: clk: introduce HSDK pll driver

On 08/25, Eugeniy Paltsev wrote: > HSDK board manages its clocks using various PLLs. These PLL have same > dividers and corresponding control registers mapped to different addresses. > So we add one common driver for such PLLs. > > Each PLL on HSDK board consists of three dividers: IDIV, FBDIV

Re: [PATCH] mm, memory_hotplug: do not back off draining pcp free pages from kworker context

On Tue 29-08-17 13:28:23, Michal Hocko wrote: > On Tue 29-08-17 20:20:39, Tetsuo Handa wrote: > > On 2017/08/29 7:33, Andrew Morton wrote: > > > On Mon, 28 Aug 2017 11:33:41 +0200 Michal Hocko wrote: > > > > > >> drain_all_pages backs off when called from a kworker context

Re: [PATCH] mm, memory_hotplug: do not back off draining pcp free pages from kworker context

On Tue 29-08-17 13:28:23, Michal Hocko wrote: > On Tue 29-08-17 20:20:39, Tetsuo Handa wrote: > > On 2017/08/29 7:33, Andrew Morton wrote: > > > On Mon, 28 Aug 2017 11:33:41 +0200 Michal Hocko wrote: > > > > > >> drain_all_pages backs off when called from a kworker context since > > >>

Re: [PATCH 2/2] clk: zte: constify clk_div_table

On 08/28, Arvind Yadav wrote: > clk_div_table are not supposed to change at runtime. All functions > working with clk_div_table provided by work > with const clk_div_table. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav > --- Applied to

Re: [PATCH 2/2] clk: zte: constify clk_div_table

On 08/28, Arvind Yadav wrote: > clk_div_table are not supposed to change at runtime. All functions > working with clk_div_table provided by work > with const clk_div_table. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav > --- Applied to clk-next -- Qualcomm

Re: [PATCH 1/2] clk: imx: constify clk_div_table

On 08/28, Arvind Yadav wrote: > clk_div_table are not supposed to change at runtime. All functions > working with clk_div_table provided by work > with const clk_div_table. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav > --- Applied to

Re: [PATCH 1/2] clk: imx: constify clk_div_table

On 08/28, Arvind Yadav wrote: > clk_div_table are not supposed to change at runtime. All functions > working with clk_div_table provided by work > with const clk_div_table. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav > --- Applied to clk-next -- Qualcomm

Re: [PATCH] clk: uniphier: add ethernet clock control support

On 08/28, Kunihiko Hayashi wrote: > Add clock control for ethernet controller on Pro4, PXs2, LD11 and LD20. > > Signed-off-by: Kunihiko Hayashi > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation

Re: [PATCH] clk: uniphier: add ethernet clock control support

On 08/28, Kunihiko Hayashi wrote: > Add clock control for ethernet controller on Pro4, PXs2, LD11 and LD20. > > Signed-off-by: Kunihiko Hayashi > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [RFC PATCH] mm, oom_reaper: skip mm structs with mmu notifiers

On Wed 30-08-17 19:49:04, Andrea Arcangeli wrote: > Hello Michal, > > On Wed, Aug 30, 2017 at 10:46:00AM +0200, Michal Hocko wrote: > > +* TODO: we really want to get rid of this ugly hack and make sure that > > +* notifiers cannot block for unbounded amount of time and add > > +*

Re: [RFC PATCH] mm, oom_reaper: skip mm structs with mmu notifiers

On Wed 30-08-17 19:49:04, Andrea Arcangeli wrote: > Hello Michal, > > On Wed, Aug 30, 2017 at 10:46:00AM +0200, Michal Hocko wrote: > > +* TODO: we really want to get rid of this ugly hack and make sure that > > +* notifiers cannot block for unbounded amount of time and add > > +*

Re: [PATCH 1/3] clk: ux500: prcmu: constify clk_ops.

On 08/28, Arvind Yadav wrote: > clk_ops are not supposed to change at runtime. All functions > working with clk_ops provided by work > with const clk_ops. So mark the non-const clk_ops as const. > > Here, Function "clk_reg_prcmu" is used to initialized clk_init_data. > clk_init_data is working

Re: [PATCH 1/3] clk: ux500: prcmu: constify clk_ops.

On 08/28, Arvind Yadav wrote: > clk_ops are not supposed to change at runtime. All functions > working with clk_ops provided by work > with const clk_ops. So mark the non-const clk_ops as const. > > Here, Function "clk_reg_prcmu" is used to initialized clk_init_data. > clk_init_data is working

Re: [PATCH 2/3] clk: ux500: sysctrl: constify clk_ops.

On 08/28, Arvind Yadav wrote: > clk_ops are not supposed to change at runtime. All functions > working with clk_ops provided by work > with const clk_ops. So mark the non-const clk_ops as const. > > Here, Function "clk_reg_sysctrl" is used to initialized clk_init_data. > clk_init_data is working

Re: [PATCH 2/3] clk: ux500: sysctrl: constify clk_ops.

On 08/28, Arvind Yadav wrote: > clk_ops are not supposed to change at runtime. All functions > working with clk_ops provided by work > with const clk_ops. So mark the non-const clk_ops as const. > > Here, Function "clk_reg_sysctrl" is used to initialized clk_init_data. > clk_init_data is working

Re: [PATCH 3/3] clk: ux500: prcc: constify clk_ops.

On 08/28, Arvind Yadav wrote: > clk_ops are not supposed to change at runtime. All functions > working with clk_ops provided by work > with const clk_ops. So mark the non-const clk_ops as const. > > Here, Function "clk_reg_prcc" is used to initialized clk_init_data. > clk_init_data is working

Re: [PATCH 3/3] clk: ux500: prcc: constify clk_ops.

On 08/28, Arvind Yadav wrote: > clk_ops are not supposed to change at runtime. All functions > working with clk_ops provided by work > with const clk_ops. So mark the non-const clk_ops as const. > > Here, Function "clk_reg_prcc" is used to initialized clk_init_data. > clk_init_data is working

[PATCH] net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()

Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv() in net/dccp/ipv6.c, similar to the handling in net/ipv6/tcp_ipv6.c Signed-off-by: Andrii Vladyka --- diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c index 1b58eac..35c2edb 100644 --- a/net/dccp/ipv6.c +++ b/net/dccp/ipv6.c @@

[PATCH] net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()

Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv() in net/dccp/ipv6.c, similar to the handling in net/ipv6/tcp_ipv6.c Signed-off-by: Andrii Vladyka --- diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c index 1b58eac..35c2edb 100644 --- a/net/dccp/ipv6.c +++ b/net/dccp/ipv6.c @@ -16,6 +16,7 @@

Re: [PATCH] net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()

I'll fix and re-send. Thanks. On 8/31/2017 8:16 AM, David Miller wrote: From: Andrii Vladyka Date: Wed, 30 Aug 2017 09:04:35 +0300 + if (opt_skb) Trailing whitespace. @@ -653,6 +647,36 @@ static int dccp_v6_do_rcv(struct sock *sk, struct

Re: [PATCH] net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()

I'll fix and re-send. Thanks. On 8/31/2017 8:16 AM, David Miller wrote: From: Andrii Vladyka Date: Wed, 30 Aug 2017 09:04:35 +0300 + if (opt_skb) Trailing whitespace. @@ -653,6 +647,36 @@ static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)

linux-next: build failure after merge of the xen-tip tree

Hi all, After merging the xen-tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/xen/xen-asm_64.o: In function `xen_trace_page_fault': (.text+0x174): undefined reference to `trace_page_fault' Caused by commit ad5b8c4ba323 ("xen: get rid of paravirt op

linux-next: build failure after merge of the xen-tip tree

Hi all, After merging the xen-tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/xen/xen-asm_64.o: In function `xen_trace_page_fault': (.text+0x174): undefined reference to `trace_page_fault' Caused by commit ad5b8c4ba323 ("xen: get rid of paravirt op

Re: [PATCH 2/2] mm/slub: don't use reserved highatomic pageblock for optimistic try

On Thu 31-08-17 10:42:41, Joonsoo Kim wrote: > On Tue, Aug 29, 2017 at 09:33:44AM +0900, Joonsoo Kim wrote: > > On Mon, Aug 28, 2017 at 03:08:29PM +0200, Michal Hocko wrote: > > > On Mon 28-08-17 13:29:29, Vlastimil Babka wrote: > > > > On 08/28/2017 03:11 AM, js1...@gmail.com wrote: > > > > >

Re: [PATCH 2/2] mm/slub: don't use reserved highatomic pageblock for optimistic try

On Thu 31-08-17 10:42:41, Joonsoo Kim wrote: > On Tue, Aug 29, 2017 at 09:33:44AM +0900, Joonsoo Kim wrote: > > On Mon, Aug 28, 2017 at 03:08:29PM +0200, Michal Hocko wrote: > > > On Mon 28-08-17 13:29:29, Vlastimil Babka wrote: > > > > On 08/28/2017 03:11 AM, js1...@gmail.com wrote: > > > > >

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

On Thu, 2017-08-31 at 06:36 +0200, Greg Kroah-Hartman wrote: > On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote: > > Hello everyone, > > > > Recently Nathan March reported on centos-virt list he's getting frequent > > Linux kernel crashes with Linux 4.9 LTS kernel because of the

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

On Thu, 2017-08-31 at 06:36 +0200, Greg Kroah-Hartman wrote: > On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote: > > Hello everyone, > > > > Recently Nathan March reported on centos-virt list he's getting frequent > > Linux kernel crashes with Linux 4.9 LTS kernel because of the

Re: [PATCH v2 1/2] ARM: dts: sun7i: Fix A20-OLinuXino-MICRO dts for LAN8710

On 08/30/2017 05:37 PM, Maxime Ripard wrote: Hi, On Mon, Aug 28, 2017 at 09:32:42AM +0300, Stefan Mavrodiev wrote: From revision J the board uses new phy chip LAN8710. Compared with RTL8201, RA17 pin is TXERR. It has pullup which causes phy not to work. To fix this PA17 is muxed with GMAC

Re: [PATCH v2 1/2] ARM: dts: sun7i: Fix A20-OLinuXino-MICRO dts for LAN8710

On 08/30/2017 05:37 PM, Maxime Ripard wrote: Hi, On Mon, Aug 28, 2017 at 09:32:42AM +0300, Stefan Mavrodiev wrote: From revision J the board uses new phy chip LAN8710. Compared with RTL8201, RA17 pin is TXERR. It has pullup which causes phy not to work. To fix this PA17 is muxed with GMAC

Data shows that drastic weight loss is dangerous ?is there a way out?

Looking to lose weight fast in a healthy way? While it may be very tempting to turn to diet aid solutions that promise awesome weight loss, it's also important to be cautious about your health. Recent data show that most diet medicines, drinks and "organic" formulas are capable of causing a

Data shows that drastic weight loss is dangerous ?is there a way out?

Looking to lose weight fast in a healthy way? While it may be very tempting to turn to diet aid solutions that promise awesome weight loss, it's also important to be cautious about your health. Recent data show that most diet medicines, drinks and "organic" formulas are capable of causing a

Re: [PATCH] net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()

From: Andrii Vladyka Date: Wed, 30 Aug 2017 09:04:35 +0300 > + if (opt_skb) Trailing whitespace. > @@ -653,6 +647,36 @@ static int dccp_v6_do_rcv(struct sock *sk, struct > sk_buff *skb) > __kfree_skb(opt_skb); > kfree_skb(skb);

RE: [PATCH] arm64: dts: Add support for NXP's LX2160A SoC

>From: Rob Herring [mailto:r...@kernel.org] >Subject: Re: [PATCH] arm64: dts: Add support for NXP's LX2160A SoC > >On Fri, Aug 18, 2017 at 04:25:36PM +0530, Sriram Dash wrote: >> The QorIQ LX2160A processor is built in the 16FFC process on the >> Layerscape architecture combining sixteen ARM A72

Re: [PATCH] net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()

From: Andrii Vladyka Date: Wed, 30 Aug 2017 09:04:35 +0300 > + if (opt_skb) Trailing whitespace. > @@ -653,6 +647,36 @@ static int dccp_v6_do_rcv(struct sock *sk, struct > sk_buff *skb) > __kfree_skb(opt_skb); > kfree_skb(skb); > return

RE: [PATCH] arm64: dts: Add support for NXP's LX2160A SoC

>From: Rob Herring [mailto:r...@kernel.org] >Subject: Re: [PATCH] arm64: dts: Add support for NXP's LX2160A SoC > >On Fri, Aug 18, 2017 at 04:25:36PM +0530, Sriram Dash wrote: >> The QorIQ LX2160A processor is built in the 16FFC process on the >> Layerscape architecture combining sixteen ARM A72

Re: [PATCH] [stable] kvm: arm/arm64: Fix race in resetting stage2 PGD

On Wed, Aug 30, 2017 at 12:30:52PM +0100, Suzuki K Poulose wrote: > commit 6c0d706b563af732adb094c5bf807437e8963e84 upstream. > > In kvm_free_stage2_pgd() we check the stage2 PGD before holding > the lock and proceed to take the lock if it is valid. And we unmap > the page tables, followed by

Re: [PATCH] [stable] kvm: arm/arm64: Fix race in resetting stage2 PGD

On Wed, Aug 30, 2017 at 12:30:52PM +0100, Suzuki K Poulose wrote: > commit 6c0d706b563af732adb094c5bf807437e8963e84 upstream. > > In kvm_free_stage2_pgd() we check the stage2 PGD before holding > the lock and proceed to take the lock if it is valid. And we unmap > the page tables, followed by

Re: [PATCH v4 00/14] mpt3sas driver NVMe support:

Hi Martin, Replied inline. Thanks, Suganath Prabu S On Thu, Aug 31, 2017 at 8:35 AM, Martin K. Petersen wrote: > > Hi Suganath, > >> Theoretically we want to use h/w capability (to translate IEEE to PRP) >> for smaller IO size to leverage h/w capability. > > Nobody

Re: [PATCH v4 00/14] mpt3sas driver NVMe support:

Hi Martin, Replied inline. Thanks, Suganath Prabu S On Thu, Aug 31, 2017 at 8:35 AM, Martin K. Petersen wrote: > > Hi Suganath, > >> Theoretically we want to use h/w capability (to translate IEEE to PRP) >> for smaller IO size to leverage h/w capability. > > Nobody says we have to use the

Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

On Thu, Aug 31, 2017 at 6:51 AM, Xiong Zhou wrote: > hi, > > This happens on 4.13.0-rc7+ to commit 42ff72c Don't understand. Is this a regression? from which commit? > > After firing up the stress, touch a file in monitoring directory could > hang like forever. > > Pretty easy

Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

On Thu, Aug 31, 2017 at 6:51 AM, Xiong Zhou wrote: > hi, > > This happens on 4.13.0-rc7+ to commit 42ff72c Don't understand. Is this a regression? from which commit? > > After firing up the stress, touch a file in monitoring directory could > hang like forever. > > Pretty easy to hit. So are

[PATCH v6 2/3] dt-bindings: PCI iproc: Implement optional property prsnt-gpios

Add description for optional device tree property 'prsnt-gpios' for PCI hotplug feature. Signed-off-by: Oza Pawandeep Reviewed-by: Ray Jui Acked-by: Rob Herring diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt

[PATCH v6 2/3] dt-bindings: PCI iproc: Implement optional property prsnt-gpios

Add description for optional device tree property 'prsnt-gpios' for PCI hotplug feature. Signed-off-by: Oza Pawandeep Reviewed-by: Ray Jui Acked-by: Rob Herring diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt

[PATCH v6 1/3] dt-bindings: PCI: Add PCI hotplug property

Host drivers have the requirement of implementing PCI hotplug based on the how their SOC supports it. Couple of properties have been added. the one to enable the hotplug feature itself, and the other caters to the PCI hotplug implementation with the use of gpios. Signed-off-by: Oza Pawandeep

[PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support

This patch implements PCI hotplug support for iproc family chipsets. iproc based SOC (e.g. Stingray) does not have hotplug controller integrated. Hence, standard PCI hotplug framework hooks can-not be used. e.g. controlled power up/down of slot. The mechanism, for e.g. Stingray has adopted for

[PATCH v6 1/3] dt-bindings: PCI: Add PCI hotplug property

Host drivers have the requirement of implementing PCI hotplug based on the how their SOC supports it. Couple of properties have been added. the one to enable the hotplug feature itself, and the other caters to the PCI hotplug implementation with the use of gpios. Signed-off-by: Oza Pawandeep

[PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support

This patch implements PCI hotplug support for iproc family chipsets. iproc based SOC (e.g. Stingray) does not have hotplug controller integrated. Hence, standard PCI hotplug framework hooks can-not be used. e.g. controlled power up/down of slot. The mechanism, for e.g. Stingray has adopted for

[PATCH v6 0/3] PCI hotplug feature

These patches bring in PCI hotplug support for iproc family chipsets. It includes DT binding documentation and, the implementation in iproc pcie RC driver. Changes since v5: [RESEND] Changes since v4: Rebased to pci-next Added; Acked-by: Rob Herring Changes since v3: Resend.

[PATCH v6 0/3] PCI hotplug feature

These patches bring in PCI hotplug support for iproc family chipsets. It includes DT binding documentation and, the implementation in iproc pcie RC driver. Changes since v5: [RESEND] Changes since v4: Rebased to pci-next Added; Acked-by: Rob Herring Changes since v3: Resend. just to be in

Re: [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches

On 08/30/2017 08:42 AM, Gustavo A. R. Silva wrote: Refactor code in order to avoid identical code for different branches. This issue was detected with the help of Coccinelle. Addresses-Coverity-ID: 1226788 Signed-off-by: Gustavo A. R. Silva --- This issue was reported

Re: [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches

On 08/30/2017 08:42 AM, Gustavo A. R. Silva wrote: Refactor code in order to avoid identical code for different branches. This issue was detected with the help of Coccinelle. Addresses-Coverity-ID: 1226788 Signed-off-by: Gustavo A. R. Silva --- This issue was reported by Coverity and it was

[PATCH v3 1/6] remoteproc: qcom: mdt_loader: Make the firmware authentication optional

qcom_mdt_load function loads the mdt type firmware and initialises the secure memory as well. Make the initialisation only when requested by the caller, so that the function can be used by self-authenticating remoteproc as well. Signed-off-by: Sricharan R ---

[PATCH v3 5/6] remoteproc: qcom: Add support for q6v5-wcss pil

IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan (Lithium) IP. An mdt type single image format is used for the firmware. So the mdt_load function can be directly used to load the firmware. Also add the relevant resets required for this core. Signed-off-by: Sricharan R

[PATCH v3 1/6] remoteproc: qcom: mdt_loader: Make the firmware authentication optional

qcom_mdt_load function loads the mdt type firmware and initialises the secure memory as well. Make the initialisation only when requested by the caller, so that the function can be used by self-authenticating remoteproc as well. Signed-off-by: Sricharan R --- drivers/soc/qcom/mdt_loader.c

[PATCH v3 5/6] remoteproc: qcom: Add support for q6v5-wcss pil

IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan (Lithium) IP. An mdt type single image format is used for the firmware. So the mdt_load function can be directly used to load the firmware. Also add the relevant resets required for this core. Signed-off-by: Sricharan R ---

[PATCH v3 6/6] remoteproc: qcom: Add q6v5-wcss rproc ops

q6v5-wcss core's start function is mostly common with the q6v5 of msm8996. So reuse that and add the stop function. Signed-off-by: Sricharan R --- drivers/remoteproc/qcom_q6v5_pil.c | 212 + 1 file changed, 212 insertions(+) diff

[PATCH v3 6/6] remoteproc: qcom: Add q6v5-wcss rproc ops

q6v5-wcss core's start function is mostly common with the q6v5 of msm8996. So reuse that and add the stop function. Signed-off-by: Sricharan R --- drivers/remoteproc/qcom_q6v5_pil.c | 212 + 1 file changed, 212 insertions(+) diff --git

[PATCH v3 4/6] remoteproc: qcom: Split the head and tail of the q6v5-pil rproc start function

Most of the q6v5-pil start function is same for the q6v5-wcss rproc that will be added later. So split and move out the common pieces so that the same code can be reused. Signed-off-by: Sricharan R --- drivers/remoteproc/qcom_q6v5_pil.c | 166

[PATCH v3 4/6] remoteproc: qcom: Split the head and tail of the q6v5-pil rproc start function

Most of the q6v5-pil start function is same for the q6v5-wcss rproc that will be added later. So split and move out the common pieces so that the same code can be reused. Signed-off-by: Sricharan R --- drivers/remoteproc/qcom_q6v5_pil.c | 166 - 1 file

[PATCH v3 3/6] remoteproc: qcom: Push reset ops, fw ops, rproc ops in to of_match data

Instead of directly assigning reset, fw and rproc ops, put them in to of_match data and get from that. Currently same ops are used for all compatibles, but that will change when we add q6v5-wcss support. Signed-off-by: Sricharan R --- drivers/remoteproc/qcom_q6v5_pil.c

[PATCH v3 0/6] Add support for Hexagon q6v5-wcss integrated core

IPQ8074 has an integrated Hexagon dsp core Q6v5 and a wireless lan (Lithium) IP. This series adds the remoteproc driver to reset, load and boot Q6 firmware. The first patch is to make the mdt_loader authenticate the firmware only if required, so that the code can be reused for self-authenticating

[PATCH v3 2/6] remoteproc: Export rproc_elf_get_boot_addr

Export rproc_elf_get_boot_addr so that it can be used by any remoteproc to get the bootaddr of the elf type firmware images. This is used in the subsequent patch by the q6v5 based remoteproc while loading its elf based mdt type image. Signed-off-by: Sricharan R ---

[PATCH v3 2/6] remoteproc: Export rproc_elf_get_boot_addr

Export rproc_elf_get_boot_addr so that it can be used by any remoteproc to get the bootaddr of the elf type firmware images. This is used in the subsequent patch by the q6v5 based remoteproc while loading its elf based mdt type image. Signed-off-by: Sricharan R ---

[PATCH v3 3/6] remoteproc: qcom: Push reset ops, fw ops, rproc ops in to of_match data

Instead of directly assigning reset, fw and rproc ops, put them in to of_match data and get from that. Currently same ops are used for all compatibles, but that will change when we add q6v5-wcss support. Signed-off-by: Sricharan R --- drivers/remoteproc/qcom_q6v5_pil.c | 38

[PATCH v3 0/6] Add support for Hexagon q6v5-wcss integrated core

IPQ8074 has an integrated Hexagon dsp core Q6v5 and a wireless lan (Lithium) IP. This series adds the remoteproc driver to reset, load and boot Q6 firmware. The first patch is to make the mdt_loader authenticate the firmware only if required, so that the code can be reused for self-authenticating

Re: [GIT] Networking

David Miller writes: > From: Kalle Valo > Date: Wed, 30 Aug 2017 20:31:31 +0300 > >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug >> has been there for 7 years so waiting for a few more weeks should not >> hurt. > > As a

Re: [GIT] Networking

David Miller writes: > From: Kalle Valo > Date: Wed, 30 Aug 2017 20:31:31 +0300 > >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug >> has been there for 7 years so waiting for a few more weeks should not >> hurt. > > As a maintainer you have a right to handle bug

[PATCH v5 3/3] PCI: iproc: Implement PCI hotplug support

This patch implements PCI hotplug support for iproc family chipsets. iproc based SOC (e.g. Stingray) does not have hotplug controller integrated. Hence, standard PCI hotplug framework hooks can-not be used. e.g. controlled power up/down of slot. The mechanism, for e.g. Stingray has adopted for

[PATCH v5 2/3] dt-bindings: PCI iproc: Implement optional property prsnt-gpios

Add description for optional device tree property 'prsnt-gpios' for PCI hotplug feature. Signed-off-by: Oza Pawandeep Reviewed-by: Ray Jui Acked-by: Rob Herring diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt

[PATCH v5 3/3] PCI: iproc: Implement PCI hotplug support

This patch implements PCI hotplug support for iproc family chipsets. iproc based SOC (e.g. Stingray) does not have hotplug controller integrated. Hence, standard PCI hotplug framework hooks can-not be used. e.g. controlled power up/down of slot. The mechanism, for e.g. Stingray has adopted for

[PATCH v5 2/3] dt-bindings: PCI iproc: Implement optional property prsnt-gpios

Add description for optional device tree property 'prsnt-gpios' for PCI hotplug feature. Signed-off-by: Oza Pawandeep Reviewed-by: Ray Jui Acked-by: Rob Herring diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt

[PATCH v5 1/3] dt-bindings: PCI: Add PCI hotplug property

Host drivers have the requirement of implementing PCI hotplug based on the how their SOC supports it. Couple of properties have been added. the one to enable the hotplug feature itself, and the other caters to the PCI hotplug implementation with the use of gpios. Signed-off-by: Oza Pawandeep

[PATCH v5 0/3] PCI hotplug feature

These patches bring in PCI hotplug support for iproc family chipsets. It includes DT binding documentation and, the implementation in iproc pcie RC driver. Changes since v3: Rebased to pci-next Added; Acked-by: Rob Herring Changes since v3: Resend. just to be in sync previous

[PATCH v5 1/3] dt-bindings: PCI: Add PCI hotplug property

Host drivers have the requirement of implementing PCI hotplug based on the how their SOC supports it. Couple of properties have been added. the one to enable the hotplug feature itself, and the other caters to the PCI hotplug implementation with the use of gpios. Signed-off-by: Oza Pawandeep

[PATCH v5 0/3] PCI hotplug feature

These patches bring in PCI hotplug support for iproc family chipsets. It includes DT binding documentation and, the implementation in iproc pcie RC driver. Changes since v3: Rebased to pci-next Added; Acked-by: Rob Herring Changes since v3: Resend. just to be in sync previous in-flight

Re: [PATCH] rtlwifi: rtl8723be: fix duplicated code for different branches

On 08/30/2017 12:04 PM, Gustavo A. R. Silva wrote: Refactor code in order to avoid identical code for different branches. Addresses-Coverity-ID: 1248728 Signed-off-by: Gustavo A. R. Silva According to Realtek, this change is OK. Acked-by: Larry Finger

Re: [PATCH] rtlwifi: rtl8723be: fix duplicated code for different branches

On 08/30/2017 12:04 PM, Gustavo A. R. Silva wrote: Refactor code in order to avoid identical code for different branches. Addresses-Coverity-ID: 1248728 Signed-off-by: Gustavo A. R. Silva According to Realtek, this change is OK. Acked-by: Larry Finger Thanks, Larry --- This issue was

Re: [tip:x86/asm] objtool: Handle GCC stack pointer adjustment bug

On Wed, Aug 30, 2017 at 04:39:42PM -0700, H. Peter Anvin wrote: > On 08/30/17 13:14, Josh Poimboeuf wrote: > > On Wed, Aug 30, 2017 at 12:23:24PM -0700, H. Peter Anvin wrote: > >> On 08/30/17 02:43, tip-bot for Josh Poimboeuf wrote: > >>> > >>> Those warnings are caused by an unusual GCC

Re: [tip:x86/asm] objtool: Handle GCC stack pointer adjustment bug

On Wed, Aug 30, 2017 at 04:39:42PM -0700, H. Peter Anvin wrote: > On 08/30/17 13:14, Josh Poimboeuf wrote: > > On Wed, Aug 30, 2017 at 12:23:24PM -0700, H. Peter Anvin wrote: > >> On 08/30/17 02:43, tip-bot for Josh Poimboeuf wrote: > >>> > >>> Those warnings are caused by an unusual GCC

[PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

If 'clk_prepare_enable()' fails, we must release some resources before returning. Add a new label in the existing error handling path and 'goto' there. Fixes: 260ea95cc027 ("ASoC: atmel: ac97c: Handle return value of clk_prepare_enable.") Signed-off-by: Christophe JAILLET

[PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

If 'clk_prepare_enable()' fails, we must release some resources before returning. Add a new label in the existing error handling path and 'goto' there. Fixes: 260ea95cc027 ("ASoC: atmel: ac97c: Handle return value of clk_prepare_enable.") Signed-off-by: Christophe JAILLET ---

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote: > On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook wrote: > > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith wrote: > >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote: > >> > >>> Interesting! Can you try

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote: > On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook wrote: > > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith wrote: > >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote: > >> > >>> Interesting! Can you try with 633547973ffc3 ("net: convert > >>>

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/enlighten_pv.c between commit: 64b163fab684 ("x86/idt: Unify gate_struct handling for 32/64-bit kernels") from the tip tree and commit: ad5b8c4ba323 ("xen: get rid of paravirt op

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/enlighten_pv.c between commit: 64b163fab684 ("x86/idt: Unify gate_struct handling for 32/64-bit kernels") from the tip tree and commit: ad5b8c4ba323 ("xen: get rid of paravirt op

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote: > Hello everyone, > > Recently Nathan March reported on centos-virt list he's getting frequent > Linux kernel crashes with Linux 4.9 LTS kernel because of the missing patch > "tty: Fix ldisc crash on reopened tty". Crashes with

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote: > Hello everyone, > > Recently Nathan March reported on centos-virt list he's getting frequent > Linux kernel crashes with Linux 4.9 LTS kernel because of the missing patch > "tty: Fix ldisc crash on reopened tty". Crashes with

Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it

On Tue, Aug 29, 2017 at 11:32:58PM +0200, Ondrej Zary wrote: > On Tuesday 29 August 2017 01:42:08 David Miller wrote: > > From: Greg Kroah-Hartman > > Date: Sun, 27 Aug 2017 17:03:30 +0200 > > > > > The IRDA code has long been obsolete and broken. So, to keep people >

Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it

On Tue, Aug 29, 2017 at 11:32:58PM +0200, Ondrej Zary wrote: > On Tuesday 29 August 2017 01:42:08 David Miller wrote: > > From: Greg Kroah-Hartman > > Date: Sun, 27 Aug 2017 17:03:30 +0200 > > > > > The IRDA code has long been obsolete and broken. So, to keep people > > > from trying to use it,

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

On Wed, Aug 30, 2017 at 12:46:38PM -0700, Sherry Yang wrote: > On Tue, Aug 29, 2017 at 11:07 PM, Greg Kroah-Hartman > wrote: > > On Tue, Aug 29, 2017 at 05:46:57PM -0700, Sherry Yang wrote: > >> Use helper functions buffer_next and buffer_prev instead > >> of

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

On Wed, Aug 30, 2017 at 12:46:38PM -0700, Sherry Yang wrote: > On Tue, Aug 29, 2017 at 11:07 PM, Greg Kroah-Hartman > wrote: > > On Tue, Aug 29, 2017 at 05:46:57PM -0700, Sherry Yang wrote: > >> Use helper functions buffer_next and buffer_prev instead > >> of list_entry to get the next and

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/include/asm/traps.h between commit: 11a7ffb01703 ("x86/traps: Simplify pagefault tracing logic") from the tip tree and commit: ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame") from the

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/include/asm/traps.h between commit: 11a7ffb01703 ("x86/traps: Simplify pagefault tracing logic") from the tip tree and commit: ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame") from the

  1   2   3   4   5   6   7   8   9   10   >