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

[Bhumika Goyal]

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 with no relation to the 
> subsystem!
>

Sorry, for the inconvenience.

> Now, resend with reduced Cc (see headers) and don't forget to include
> Andy Lutomirski
>

Yes.

Thanks,
Bhumika

>
> --
> With Best Regards,
> Andy Shevchenko

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

[Bhumika Goyal]

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 with no relation to the 
> subsystem!
>

Sorry, for the inconvenience.

> Now, resend with reduced Cc (see headers) and don't forget to include
> Andy Lutomirski
>

Yes.

Thanks,
Bhumika

>
> --
> With Best Regards,
> Andy Shevchenko

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

[James Liao]

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 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 57d0396..5d4e406 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -39,6 +39,7 @@
device_type = "cpu";
compatible = "arm,cortex-a35";
reg = <0x000>;
+   cpu-idle-states = <_SLEEP_0 _SLEEP_0>;
};
 
cpu1: cpu@1 {
@@ -46,6 +47,7 @@
compatible = "arm,cortex-a35";
reg = <0x001>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0 _SLEEP_0>;
};
 
cpu2: cpu@200 {
@@ -53,6 +55,29 @@
compatible = "arm,cortex-a72";
reg = <0x200>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0 _SLEEP_0>;
+   };
+
+   idle-states {
+   entry-method = "arm,psci";
+
+   CPU_SLEEP_0: cpu-sleep-0 {
+   compatible = "arm,idle-state";
+   local-timer-stop;
+   entry-latency-us = <100>;
+   exit-latency-us = <80>;
+   min-residency-us = <2000>;
+   arm,psci-suspend-param = <0x001>;
+   };
+
+   CLUSTER_SLEEP_0: cluster-sleep-0 {
+   compatible = "arm,idle-state";
+   local-timer-stop;
+   entry-latency-us = <350>;
+   exit-latency-us = <80>;
+   min-residency-us = <3000>;
+   arm,psci-suspend-param = <0x101>;
+   };
};
};
 
-- 
1.9.1

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

[James Liao]

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 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 57d0396..5d4e406 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -39,6 +39,7 @@
device_type = "cpu";
compatible = "arm,cortex-a35";
reg = <0x000>;
+   cpu-idle-states = <_SLEEP_0 _SLEEP_0>;
};
 
cpu1: cpu@1 {
@@ -46,6 +47,7 @@
compatible = "arm,cortex-a35";
reg = <0x001>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0 _SLEEP_0>;
};
 
cpu2: cpu@200 {
@@ -53,6 +55,29 @@
compatible = "arm,cortex-a72";
reg = <0x200>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0 _SLEEP_0>;
+   };
+
+   idle-states {
+   entry-method = "arm,psci";
+
+   CPU_SLEEP_0: cpu-sleep-0 {
+   compatible = "arm,idle-state";
+   local-timer-stop;
+   entry-latency-us = <100>;
+   exit-latency-us = <80>;
+   min-residency-us = <2000>;
+   arm,psci-suspend-param = <0x001>;
+   };
+
+   CLUSTER_SLEEP_0: cluster-sleep-0 {
+   compatible = "arm,idle-state";
+   local-timer-stop;
+   entry-latency-us = <350>;
+   exit-latency-us = <80>;
+   min-residency-us = <3000>;
+   arm,psci-suspend-param = <0x101>;
+   };
};
};
 
-- 
1.9.1

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

[Stephen Boyd]

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] clk: versatile: make clk_ops const

[Stephen Boyd]

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

[Stephen Boyd]

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 and
> ODIV. Output clock value is managed using these dividers.
> 
> We add pre-defined tables with supported rate values and appropriate
> configurations of IDIV, FBDIV and ODIV for each value.
> 
> As of today we add support for PLLs that generate clock for the
> HSDK arc cpus, system, ddr, AXI tunnel and hdmi.
> 
> By this patch we add support for several plls (arc cpus pll and others),
> so we had to use two different init types: CLK_OF_DECLARE for arc cpus pll
> and regular probing for others plls.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---

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

[Stephen Boyd]

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 and
> ODIV. Output clock value is managed using these dividers.
> 
> We add pre-defined tables with supported rate values and appropriate
> configurations of IDIV, FBDIV and ODIV for each value.
> 
> As of today we add support for PLLs that generate clock for the
> HSDK arc cpus, system, ddr, AXI tunnel and hdmi.
> 
> By this patch we add support for several plls (arc cpus pll and others),
> so we had to use two different init types: CLK_OF_DECLARE for arc cpus pll
> and regular probing for others plls.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Michal Hocko]

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
> > >> 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue
> > >> context") because the original IPI based pcp draining has been replaced
> > >> by a WQ based one and the check wanted to prevent from recursion and
> > >> inter workers dependencies. This has made some sense at the time
> > >> because the system WQ has been used and one worker holding the lock
> > >> could be blocked while waiting for new workers to emerge which can be a
> > >> problem under OOM conditions.
> > >>
> > >> Since then ce612879ddc7 ("mm: move pcp and lru-pcp draining into single
> > >> wq") has moved draining to a dedicated (mm_percpu_wq) WQ with a rescuer
> > >> so we shouldn't depend on any other WQ activity to make a forward
> > >> progress so calling drain_all_pages from a worker context is safe as
> > >> long as this doesn't happen from mm_percpu_wq itself which is not the
> > >> case because all workers are required to _not_ depend on any MM locks.
> > >>
> > >> Why is this a problem in the first place? ACPI driven memory hot-remove
> > >> (acpi_device_hotplug) is executed from the worker context. We end
> > >> up calling __offline_pages to free all the pages and that requires
> > >> both lru_add_drain_all_cpuslocked and drain_all_pages to do their job
> > >> otherwise we can have dangling pages on pcp lists and fail the offline
> > >> operation (__test_page_isolated_in_pageblock would see a page with 0
> > >> ref. count but without PageBuddy set).
> > >>
> > >> Fix the issue by removing the worker check in drain_all_pages.
> > >> lru_add_drain_all_cpuslocked doesn't have this restriction so it works
> > >> as expected.
> > >>
> > >> Fixes: 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from 
> > >> workqueue context")
> > >> Signed-off-by: Michal Hocko 
> > > 
> > > No cc:stable?
> > > 
> > 
> > Michal, are you sure that this patch does not cause deadlock?
> > 
> > As shown in "[PATCH] mm: Use WQ_HIGHPRI for mm_percpu_wq." thread, 
> > currently work
> > items on mm_percpu_wq seem to be blocked by other work items not on 
> > mm_percpu_wq.
> 
> But we have a rescuer so we should make a forward progress eventually.
> Or am I missing something. Tejun, could you have a look please?

ping... I would really appreaciate if you could double check my thinking
Tejun. This is a tricky area and I would like to prevent further subtle
issues here.
-- 
Michal Hocko
SUSE Labs

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

[Michal Hocko]

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
> > >> 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue
> > >> context") because the original IPI based pcp draining has been replaced
> > >> by a WQ based one and the check wanted to prevent from recursion and
> > >> inter workers dependencies. This has made some sense at the time
> > >> because the system WQ has been used and one worker holding the lock
> > >> could be blocked while waiting for new workers to emerge which can be a
> > >> problem under OOM conditions.
> > >>
> > >> Since then ce612879ddc7 ("mm: move pcp and lru-pcp draining into single
> > >> wq") has moved draining to a dedicated (mm_percpu_wq) WQ with a rescuer
> > >> so we shouldn't depend on any other WQ activity to make a forward
> > >> progress so calling drain_all_pages from a worker context is safe as
> > >> long as this doesn't happen from mm_percpu_wq itself which is not the
> > >> case because all workers are required to _not_ depend on any MM locks.
> > >>
> > >> Why is this a problem in the first place? ACPI driven memory hot-remove
> > >> (acpi_device_hotplug) is executed from the worker context. We end
> > >> up calling __offline_pages to free all the pages and that requires
> > >> both lru_add_drain_all_cpuslocked and drain_all_pages to do their job
> > >> otherwise we can have dangling pages on pcp lists and fail the offline
> > >> operation (__test_page_isolated_in_pageblock would see a page with 0
> > >> ref. count but without PageBuddy set).
> > >>
> > >> Fix the issue by removing the worker check in drain_all_pages.
> > >> lru_add_drain_all_cpuslocked doesn't have this restriction so it works
> > >> as expected.
> > >>
> > >> Fixes: 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from 
> > >> workqueue context")
> > >> Signed-off-by: Michal Hocko 
> > > 
> > > No cc:stable?
> > > 
> > 
> > Michal, are you sure that this patch does not cause deadlock?
> > 
> > As shown in "[PATCH] mm: Use WQ_HIGHPRI for mm_percpu_wq." thread, 
> > currently work
> > items on mm_percpu_wq seem to be blocked by other work items not on 
> > mm_percpu_wq.
> 
> But we have a rescuer so we should make a forward progress eventually.
> Or am I missing something. Tejun, could you have a look please?

ping... I would really appreaciate if you could double check my thinking
Tejun. This is a tricky area and I would like to prevent further subtle
issues here.
-- 
Michal Hocko
SUSE Labs

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

[Stephen Boyd]

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 Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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: [PATCH] clk: uniphier: add ethernet clock control support

[Stephen Boyd]

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

[Michal Hocko]

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
> > +* mmu_notifier_invalidate_range_{start,end} around unmap_page_range
> 
> KVM already should be ok in that respect. However the major reason to
> prefer mmu_notifier_invalidate_range_start/end is those can block and
> schedule waiting for stuff happening behind the PCI bus easily. So I'm
> not sure if the TODO is good idea to keep.

Long term, I was thinking about a flag to reflect that all registered
notifiers are oom safe (aka they do not depend on memory allocations
or any locks which depend on an allocation) and then we can call into
notifiers. So the check would end up
if (!mm_has_safe_notifiers(mm))
...
 
> > +*/
> > +   if (mm_has_notifiers(mm)) {
> > +   schedule_timeout_idle(HZ);
> 
> Why the schedule_timeout? What's the difference with the OOM
> reaper going to sleep again in the main loop instead?

Well, this is what I had initially - basically to return false here
and rely on oom_reap_task to retry. But my current understanding is that
mm_has_notifiers is likely to be a semi-permanent state (once set it
won't likely go away) so I figured it would be better to simply wait
here and fail right away. If my assumption is not correct then I will
simply return false here.

> 
> > +   goto unlock_oom;
> > +   }
> 
> mm_has_notifiers stops changing after obtaining the mmap_sem for
> reading. See the do_mmu_notifier_register. So it's better to put the
> mm_has_notifiers check immediately after the below:
> 
> > if (!down_read_trylock(>mmap_sem)) {
> > ret = false;
> > trace_skip_task_reaping(tsk->pid);
> 
> If we succeed taking the mmap_sem for reading then we read a stable
> value out of mm_has_notifiers and be sure it won't be set from under
> us.

OK, I will move it.

Thanks!
-- 
Michal Hocko
SUSE Labs

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

[Michal Hocko]

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
> > +* mmu_notifier_invalidate_range_{start,end} around unmap_page_range
> 
> KVM already should be ok in that respect. However the major reason to
> prefer mmu_notifier_invalidate_range_start/end is those can block and
> schedule waiting for stuff happening behind the PCI bus easily. So I'm
> not sure if the TODO is good idea to keep.

Long term, I was thinking about a flag to reflect that all registered
notifiers are oom safe (aka they do not depend on memory allocations
or any locks which depend on an allocation) and then we can call into
notifiers. So the check would end up
if (!mm_has_safe_notifiers(mm))
...
 
> > +*/
> > +   if (mm_has_notifiers(mm)) {
> > +   schedule_timeout_idle(HZ);
> 
> Why the schedule_timeout? What's the difference with the OOM
> reaper going to sleep again in the main loop instead?

Well, this is what I had initially - basically to return false here
and rely on oom_reap_task to retry. But my current understanding is that
mm_has_notifiers is likely to be a semi-permanent state (once set it
won't likely go away) so I figured it would be better to simply wait
here and fail right away. If my assumption is not correct then I will
simply return false here.

> 
> > +   goto unlock_oom;
> > +   }
> 
> mm_has_notifiers stops changing after obtaining the mmap_sem for
> reading. See the do_mmu_notifier_register. So it's better to put the
> mm_has_notifiers check immediately after the below:
> 
> > if (!down_read_trylock(>mmap_sem)) {
> > ret = false;
> > trace_skip_task_reaping(tsk->pid);
> 
> If we succeed taking the mmap_sem for reading then we read a stable
> value out of mm_has_notifiers and be sure it won't be set from under
> us.

OK, I will move it.

Thanks!
-- 
Michal Hocko
SUSE Labs

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

[Stephen Boyd]

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 with const clk_ops. So make clk_reg_prcmu
> non-const clk_ops argument as const.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 with const clk_ops. So make clk_reg_prcmu
> non-const clk_ops argument as const.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 with const clk_ops. So make clk_reg_sysctrl
> non-const clk_ops argument as const.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 with const clk_ops. So make clk_reg_sysctrl
> non-const clk_ops argument as const.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 with const clk_ops. So make clk_reg_prcc
> non-const clk_ops argument as const.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

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 with const clk_ops. So make clk_reg_prcc
> non-const clk_ops argument as const.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Andrii]

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 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -30,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dccp.h"
 #include "ipv6.h"
@@ -597,19 +599,13 @@ static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff 
*skb)
   --ANK (980728)
 */
if (np->rxopt.all)
-   /*
-* FIXME: Add handling of IPV6_PKTOPTIONS skb. See the comments below
-*(wrt ipv6_pktopions) and net/ipv6/tcp_ipv6.c for an example.
-*/
opt_skb = skb_clone(skb, GFP_ATOMIC);
 
if (sk->sk_state == DCCP_OPEN) { /* Fast path */
if (dccp_rcv_established(sk, skb, dccp_hdr(skb), skb->len))
goto reset;
-   if (opt_skb) {
-   /* XXX This is where we would goto ipv6_pktoptions. */
-   __kfree_skb(opt_skb);
-   }
+   if (opt_skb)
+   goto ipv6_pktoptions;
return 0;
}
 
@@ -640,10 +636,8 @@ static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff 
*skb)
 
if (dccp_rcv_state_process(sk, skb, dccp_hdr(skb), skb->len))
goto reset;
-   if (opt_skb) {
-   /* XXX This is where we would goto ipv6_pktoptions. */
-   __kfree_skb(opt_skb);
-   }
+   if (opt_skb)
+   goto ipv6_pktoptions;
return 0;
 
 reset:
@@ -653,6 +647,35 @@ static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff 
*skb)
__kfree_skb(opt_skb);
kfree_skb(skb);
return 0;
+
+/* Handling IPV6_PKTOPTIONS skb the similar
+ * way it's done for net/ipv6/tcp_ipv6.c
+ */
+ipv6_pktoptions:
+   if (!((1 << sk->sk_state) & (DCCPF_CLOSED | DCCPF_LISTEN))) {
+   if (np->rxopt.bits.rxinfo || np->rxopt.bits.rxoinfo)
+   np->mcast_oif = inet6_iif(opt_skb);
+   if (np->rxopt.bits.rxhlim || np->rxopt.bits.rxohlim)
+   np->mcast_hops = ipv6_hdr(opt_skb)->hop_limit;
+   if (np->rxopt.bits.rxflow || np->rxopt.bits.rxtclass)
+   np->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(opt_skb));
+   if (np->repflow)
+   np->flow_label = ip6_flowlabel(ipv6_hdr(opt_skb));
+   if (ipv6_opt_accepted(sk, opt_skb,
+ _SKB_CB(opt_skb)->header.h6)) {
+   skb_set_owner_r(opt_skb, sk);
+   memmove(IP6CB(opt_skb),
+   _SKB_CB(opt_skb)->header.h6,
+   sizeof(struct inet6_skb_parm));
+   opt_skb = xchg(>pktoptions, opt_skb);
+   } else {
+   __kfree_skb(opt_skb);
+   opt_skb = xchg(>pktoptions, NULL);
+   }
+   }
+
+   kfree_skb(opt_skb);
+   return 0;
 }
 
 static int dccp_v6_rcv(struct sk_buff *skb)

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

[Andrii]

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 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -30,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dccp.h"
 #include "ipv6.h"
@@ -597,19 +599,13 @@ static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff 
*skb)
   --ANK (980728)
 */
if (np->rxopt.all)
-   /*
-* FIXME: Add handling of IPV6_PKTOPTIONS skb. See the comments below
-*(wrt ipv6_pktopions) and net/ipv6/tcp_ipv6.c for an example.
-*/
opt_skb = skb_clone(skb, GFP_ATOMIC);
 
if (sk->sk_state == DCCP_OPEN) { /* Fast path */
if (dccp_rcv_established(sk, skb, dccp_hdr(skb), skb->len))
goto reset;
-   if (opt_skb) {
-   /* XXX This is where we would goto ipv6_pktoptions. */
-   __kfree_skb(opt_skb);
-   }
+   if (opt_skb)
+   goto ipv6_pktoptions;
return 0;
}
 
@@ -640,10 +636,8 @@ static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff 
*skb)
 
if (dccp_rcv_state_process(sk, skb, dccp_hdr(skb), skb->len))
goto reset;
-   if (opt_skb) {
-   /* XXX This is where we would goto ipv6_pktoptions. */
-   __kfree_skb(opt_skb);
-   }
+   if (opt_skb)
+   goto ipv6_pktoptions;
return 0;
 
 reset:
@@ -653,6 +647,35 @@ static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff 
*skb)
__kfree_skb(opt_skb);
kfree_skb(skb);
return 0;
+
+/* Handling IPV6_PKTOPTIONS skb the similar
+ * way it's done for net/ipv6/tcp_ipv6.c
+ */
+ipv6_pktoptions:
+   if (!((1 << sk->sk_state) & (DCCPF_CLOSED | DCCPF_LISTEN))) {
+   if (np->rxopt.bits.rxinfo || np->rxopt.bits.rxoinfo)
+   np->mcast_oif = inet6_iif(opt_skb);
+   if (np->rxopt.bits.rxhlim || np->rxopt.bits.rxohlim)
+   np->mcast_hops = ipv6_hdr(opt_skb)->hop_limit;
+   if (np->rxopt.bits.rxflow || np->rxopt.bits.rxtclass)
+   np->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(opt_skb));
+   if (np->repflow)
+   np->flow_label = ip6_flowlabel(ipv6_hdr(opt_skb));
+   if (ipv6_opt_accepted(sk, opt_skb,
+ _SKB_CB(opt_skb)->header.h6)) {
+   skb_set_owner_r(opt_skb, sk);
+   memmove(IP6CB(opt_skb),
+   _SKB_CB(opt_skb)->header.h6,
+   sizeof(struct inet6_skb_parm));
+   opt_skb = xchg(>pktoptions, opt_skb);
+   } else {
+   __kfree_skb(opt_skb);
+   opt_skb = xchg(>pktoptions, NULL);
+   }
+   }
+
+   kfree_skb(opt_skb);
+   return 0;
 }
 
 static int dccp_v6_rcv(struct sk_buff *skb)

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

[Andrii]

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)
__kfree_skb(opt_skb);
kfree_skb(skb);
return 0;
+   

^^^

Likewise.

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

[Andrii]

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)
__kfree_skb(opt_skb);
kfree_skb(skb);
return 0;
+   

^^^

Likewise.

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

[Stephen Rothwell]

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 adjust_exception_frame")

interacting with commit

  11a7ffb01703 ("x86/traps: Simplify pagefault tracing logic")

from the tip tree.

I am not sure how to fix up this, so I have just applied the following
patch for today.  A better solution would be appreciated.

From: Stephen Rothwell 
Date: Thu, 31 Aug 2017 15:06:10 +1000
Subject: [PATCH] xen: fix for "x86/traps: Simplify pagefault tracing logic"

Signed-off-by: Stephen Rothwell 
---
 arch/x86/xen/enlighten_pv.c | 2 +-
 arch/x86/xen/xen-asm_64.S   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index b18d9b9f84c2..6ea983a9016d 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -618,7 +618,7 @@ static struct {
{ alignment_check, xen_alignment_check, false },
{ simd_coprocessor_error, xen_simd_coprocessor_error, false },
 #ifdef CONFIG_TRACING
-   { trace_page_fault, xen_trace_page_fault, false },
+// { trace_page_fault, xen_trace_page_fault, false },
 #endif
 };
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 4ebac091a0e8..1c7a3df3e5a5 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -52,7 +52,7 @@ xen_pv_trap simd_coprocessor_error
 xen_pv_trap entry_INT80_compat
 #endif
 #ifdef CONFIG_TRACING
-xen_pv_trap trace_page_fault
+/* xen_pv_trap trace_page_fault */
 #endif
 xen_pv_trap hypervisor_callback
 
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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 adjust_exception_frame")

interacting with commit

  11a7ffb01703 ("x86/traps: Simplify pagefault tracing logic")

from the tip tree.

I am not sure how to fix up this, so I have just applied the following
patch for today.  A better solution would be appreciated.

From: Stephen Rothwell 
Date: Thu, 31 Aug 2017 15:06:10 +1000
Subject: [PATCH] xen: fix for "x86/traps: Simplify pagefault tracing logic"

Signed-off-by: Stephen Rothwell 
---
 arch/x86/xen/enlighten_pv.c | 2 +-
 arch/x86/xen/xen-asm_64.S   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index b18d9b9f84c2..6ea983a9016d 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -618,7 +618,7 @@ static struct {
{ alignment_check, xen_alignment_check, false },
{ simd_coprocessor_error, xen_simd_coprocessor_error, false },
 #ifdef CONFIG_TRACING
-   { trace_page_fault, xen_trace_page_fault, false },
+// { trace_page_fault, xen_trace_page_fault, false },
 #endif
 };
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 4ebac091a0e8..1c7a3df3e5a5 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -52,7 +52,7 @@ xen_pv_trap simd_coprocessor_error
 xen_pv_trap entry_INT80_compat
 #endif
 #ifdef CONFIG_TRACING
-xen_pv_trap trace_page_fault
+/* xen_pv_trap trace_page_fault */
 #endif
 xen_pv_trap hypervisor_callback
 
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

[Michal Hocko]

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:
> > > > > From: Joonsoo Kim 
> > > > > 
> > > > > High-order atomic allocation is difficult to succeed since we cannot
> > > > > reclaim anything in this context. So, we reserves the pageblock for
> > > > > this kind of request.
> > > > > 
> > > > > In slub, we try to allocate higher-order page more than it actually
> > > > > needs in order to get the best performance. If this optimistic try is
> > > > > used with GFP_ATOMIC, alloc_flags will be set as ALLOC_HARDER and
> > > > > the pageblock reserved for high-order atomic allocation would be used.
> > > > > Moreover, this request would reserve the MIGRATE_HIGHATOMIC pageblock
> > > > > ,if succeed, to prepare further request. It would not be good to use
> > > > > MIGRATE_HIGHATOMIC pageblock in terms of fragmentation management
> > > > > since it unconditionally set a migratetype to request's migratetype
> > > > > when unreserving the pageblock without considering the migratetype of
> > > > > used pages in the pageblock.
> > > > > 
> > > > > This is not what we don't intend so fix it by unconditionally setting
> > > > > __GFP_NOMEMALLOC in order to not set ALLOC_HARDER.
> > > > 
> > > > I wonder if it would be more robust to strip GFP_ATOMIC from alloc_gfp.
> > > > E.g. __GFP_NOMEMALLOC does seem to prevent ALLOC_HARDER, but not
> > > > ALLOC_HIGH. Or maybe we should adjust __GFP_NOMEMALLOC implementation
> > > > and document it more thoroughly? CC Michal Hocko
> > > 
> > > Yeah, __GFP_NOMEMALLOC is rather inconsistent. It has been added to
> > > override __GFP_MEMALLOC resp. PF_MEMALLOC AFAIK. In this particular
> > > case I would agree that dropping __GFP_HIGH and __GFP_ATOMIC would
> > > be more precise. I am not sure we want to touch the existing semantic of
> > > __GFP_NOMEMALLOC though. This would require auditing all the existing
> > > users (something tells me that quite some of those will be incorrect...)
> > 
> > Hmm... now I realize that there is another reason that we need to use
> > __GFP_NOMEMALLOC. Even if this allocation comes from PF_MEMALLOC user,
> > this optimistic try should not use the reserved memory below the
> > watermark. That is, it should not use ALLOC_NO_WATERMARKS. It can
> > only be accomplished by using __GFP_NOMEMALLOC.
> 
> Michal, Vlastimil, Any thought?

Hmm, I would go with a helper like below and use it in slub

gfp_t gfp_drop_reserves(gfp_t mask)
{
mask &= ~(__GFP_HIGH|__GFP_ATOMIC)
mask |= __GFP_NOMEMALLOC;

return mask;
}
-- 
Michal Hocko
SUSE Labs

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

[Michal Hocko]

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:
> > > > > From: Joonsoo Kim 
> > > > > 
> > > > > High-order atomic allocation is difficult to succeed since we cannot
> > > > > reclaim anything in this context. So, we reserves the pageblock for
> > > > > this kind of request.
> > > > > 
> > > > > In slub, we try to allocate higher-order page more than it actually
> > > > > needs in order to get the best performance. If this optimistic try is
> > > > > used with GFP_ATOMIC, alloc_flags will be set as ALLOC_HARDER and
> > > > > the pageblock reserved for high-order atomic allocation would be used.
> > > > > Moreover, this request would reserve the MIGRATE_HIGHATOMIC pageblock
> > > > > ,if succeed, to prepare further request. It would not be good to use
> > > > > MIGRATE_HIGHATOMIC pageblock in terms of fragmentation management
> > > > > since it unconditionally set a migratetype to request's migratetype
> > > > > when unreserving the pageblock without considering the migratetype of
> > > > > used pages in the pageblock.
> > > > > 
> > > > > This is not what we don't intend so fix it by unconditionally setting
> > > > > __GFP_NOMEMALLOC in order to not set ALLOC_HARDER.
> > > > 
> > > > I wonder if it would be more robust to strip GFP_ATOMIC from alloc_gfp.
> > > > E.g. __GFP_NOMEMALLOC does seem to prevent ALLOC_HARDER, but not
> > > > ALLOC_HIGH. Or maybe we should adjust __GFP_NOMEMALLOC implementation
> > > > and document it more thoroughly? CC Michal Hocko
> > > 
> > > Yeah, __GFP_NOMEMALLOC is rather inconsistent. It has been added to
> > > override __GFP_MEMALLOC resp. PF_MEMALLOC AFAIK. In this particular
> > > case I would agree that dropping __GFP_HIGH and __GFP_ATOMIC would
> > > be more precise. I am not sure we want to touch the existing semantic of
> > > __GFP_NOMEMALLOC though. This would require auditing all the existing
> > > users (something tells me that quite some of those will be incorrect...)
> > 
> > Hmm... now I realize that there is another reason that we need to use
> > __GFP_NOMEMALLOC. Even if this allocation comes from PF_MEMALLOC user,
> > this optimistic try should not use the reserved memory below the
> > watermark. That is, it should not use ALLOC_NO_WATERMARKS. It can
> > only be accomplished by using __GFP_NOMEMALLOC.
> 
> Michal, Vlastimil, Any thought?

Hmm, I would go with a helper like below and use it in slub

gfp_t gfp_drop_reserves(gfp_t mask)
{
mask &= ~(__GFP_HIGH|__GFP_ATOMIC)
mask |= __GFP_NOMEMALLOC;

return mask;
}
-- 
Michal Hocko
SUSE Labs

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

[Michael Neuling]

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 missing patch
> > "tty: Fix ldisc crash on reopened tty".
> 
> Crashes with "normal" operation, or crashes when running a fuzzer or
> other type of program?

For me it crashed on boot.

> 
> > The patch was already merged upstream here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=71472fa9c52b1da27663c275d416d8654b905f05
> > 
> > but then reverted here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=896d81fefe5d1919537db2c2150ab6384e4a6610
> > 
> > Nathan confirmed if he applies the patch from
> > 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the
> > bug/problem goes away, so the patch (or similar fix) is still needed, at
> > least for 4.9 LTS kernel.
> > 
> > 
> > Mikulas reported he's able to trigger the same crash on Linux 4.10:
> > https://www.spinics.net/lists/kernel/msg2440637.html
> > https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#26
> > 64604
> > 
> > Michael Neuling reported he's able to trigger the bug on PowerPC:
> > https://lkml.org/lkml/2017/3/10/1582
> > 
> > 
> > So now the question is.. is anyone currently working on getting this patch
> > fixed and applied upstream? I think one of the problems earlier was being
> > able to reliable reproduce the crash.. Nathan says he's able to reproduce it
> > many times per week on his environment on x86_64.
> 
> I don't know of anyone working on it, want to do it yourself?

I'm not anymore. We found it was only triggered on a bogus CONFIG option
combination.  Once we removed that, it no longer happened.

The underlying bug was still there though.

Mikey

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

[Michael Neuling]

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 missing patch
> > "tty: Fix ldisc crash on reopened tty".
> 
> Crashes with "normal" operation, or crashes when running a fuzzer or
> other type of program?

For me it crashed on boot.

> 
> > The patch was already merged upstream here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=71472fa9c52b1da27663c275d416d8654b905f05
> > 
> > but then reverted here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=896d81fefe5d1919537db2c2150ab6384e4a6610
> > 
> > Nathan confirmed if he applies the patch from
> > 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the
> > bug/problem goes away, so the patch (or similar fix) is still needed, at
> > least for 4.9 LTS kernel.
> > 
> > 
> > Mikulas reported he's able to trigger the same crash on Linux 4.10:
> > https://www.spinics.net/lists/kernel/msg2440637.html
> > https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#26
> > 64604
> > 
> > Michael Neuling reported he's able to trigger the bug on PowerPC:
> > https://lkml.org/lkml/2017/3/10/1582
> > 
> > 
> > So now the question is.. is anyone currently working on getting this patch
> > fixed and applied upstream? I think one of the problems earlier was being
> > able to reliable reproduce the crash.. Nathan says he's able to reproduce it
> > many times per week on his environment on x86_64.
> 
> I don't know of anyone working on it, want to do it yourself?

I'm not anymore. We found it was only triggered on a bogus CONFIG option
combination.  Once we removed that, it no longer happened.

The underlying bug was still there though.

Mikey

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

[Stefan Mavrodiev]

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 function. This
makes the pin output-low.

This patch is compatible with earlier board revisions, since this
pin wasn't connected to phy.

Signed-off-by: Stefan Mavrodiev 
---
  arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 0b7403e..cb1b081 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -102,7 +102,7 @@
  
   {

pinctrl-names = "default";
-   pinctrl-0 = <_pins_mii_a>;
+   pinctrl-0 = <_pins_mii_a>,<_txerr>;
phy = <>;
phy-mode = "mii";
status = "okay";
@@ -229,6 +229,11 @@
  };
  
   {

+   gmac_txerr: gmac_txerr@0 {
+   pins = "PA17";
+   function = "gmac";
+   };
+

The patch looks fine, I still have one question though.

Can a PHY operate without this signal? My real question is, would it
make sense to mux that pin for all the users, or is it an optional
signal that each board designer can choose to use or not?

Thanks!
Maxime


This phy (LAN8710) cannot work without this pin. Part of the problem is in that 
we've replaced
without paying attention to this signal.

RTL8201 has no TXERR pin. The pin PA17 is used as reset signal and therefore is 
pulled up with
resistor. However on old revisions this option (there is jumper pad between SOC 
and PHY).

As I said, LAN8710 cannot work without this signal. In the datasheet is written:
...
The controller drives TXER high when a transmit error is detected.
...

In the current variant of the dts, all data is threated as error.

So to answer you question. This is feature only on our board and highly depends 
on the chosen PHY.
I don't think this should be muxed for all users.



Best regards,
Stefan Mavrodiev,
Olimex Ltd.

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

[Stefan Mavrodiev]

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 function. This
makes the pin output-low.

This patch is compatible with earlier board revisions, since this
pin wasn't connected to phy.

Signed-off-by: Stefan Mavrodiev 
---
  arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 0b7403e..cb1b081 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -102,7 +102,7 @@
  
   {

pinctrl-names = "default";
-   pinctrl-0 = <_pins_mii_a>;
+   pinctrl-0 = <_pins_mii_a>,<_txerr>;
phy = <>;
phy-mode = "mii";
status = "okay";
@@ -229,6 +229,11 @@
  };
  
   {

+   gmac_txerr: gmac_txerr@0 {
+   pins = "PA17";
+   function = "gmac";
+   };
+

The patch looks fine, I still have one question though.

Can a PHY operate without this signal? My real question is, would it
make sense to mux that pin for all the users, or is it an optional
signal that each board designer can choose to use or not?

Thanks!
Maxime


This phy (LAN8710) cannot work without this pin. Part of the problem is in that 
we've replaced
without paying attention to this signal.

RTL8201 has no TXERR pin. The pin PA17 is used as reset signal and therefore is 
pulled up with
resistor. However on old revisions this option (there is jumper pad between SOC 
and PHY).

As I said, LAN8710 cannot work without this signal. In the datasheet is written:
...
The controller drives TXER high when a transmit error is detected.
...

In the current variant of the dts, all data is threated as error.

So to answer you question. This is feature only on our board and highly depends 
on the chosen PHY.
I don't think this should be muxed for all users.



Best regards,
Stefan Mavrodiev,
Olimex Ltd.

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

[tmarguin]

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 range of unforeseen side-effects and interactions, such as 
nausea, megrim, anxiety, heartburn and trouble sleeping.
Some even can lead to health complications including heart disease and coronary 
thrombosis.
Is it worth the risk?
Definitely not.
If you need a weight reduction product that does not pose the same dangers, you 
should read more thorough info by following this official link down below.
Here

http://fjjhmx.cliftonwinery.xyz/OC8zMS8yMDE3OzA3OjE5OjI4

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

[tmarguin]

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 range of unforeseen side-effects and interactions, such as 
nausea, megrim, anxiety, heartburn and trouble sleeping.
Some even can lead to health complications including heart disease and coronary 
thrombosis.
Is it worth the risk?
Definitely not.
If you need a weight reduction product that does not pose the same dangers, you 
should read more thorough info by following this official link down below.
Here

http://fjjhmx.cliftonwinery.xyz/OC8zMS8yMDE3OzA3OjE5OjI4

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

[David Miller]

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 0;
> + 
   ^^^

Likewise.

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

[Sriram Dash]

>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 processor cores with
>> advanced, high-performance datapath acceleration and network,
>> peripheral interfaces required for networking, wireless
>> infrastructure, storage, and general-purpose embedded applications.
>>
>> Features summary:
>> - Sixteen 32-bit / 64-bit ARM v8 A72 CPUs
>> - Cache Coherent Interconnect Fabric (CCN508 aka “Eliot”)
>> - Two 64-bit 3.2GT/s DDR4 SDRAM memory controllers with ECC.
>> - Data path acceleration architecture (DPAA2)
>> - 24 Serdes lanes at up to 25 GHz
>> - Ethernet interfaces
>>   Single WRIOP tile supporting 130Gbps using 18 MACs
>>   Support for 10G-SXGMII (aka USXGMII).
>>   Support for SGMII (and 1000Base-KX)
>>   Support for XFI (and 10GBase-KR)
>>   Support for CAUI4 (100G); CAUI2 (50G) and 25G-AUI(25G).
>>   Support for XLAUI4 (and 40GBase-KR4) for 40G.
>>   Support for two RGMII parallel interfaces.
>>   Energy efficient Ethernet support (802.3az)
>>   IEEE 1588 support.
>> - High-speed peripheral interfaces
>>   Two PCIe Gen 4.0 8-lane controllers supporting SR-IOV,
>>   Four PCIe Gen 4.0 4-lane controllers.
>>   Four serial ATA (SATA 3.0) controllers.
>>   Two USB 3.0 controllers with integrated PHY
>>   Two Enhanced secure digital host controllers
>>   Two Controller Area Network (CAN) modules
>>   Flexible Serial peripheral interface (FlexSPI) controller.
>>   Three Serial peripheral interface (SPI) controllers.
>>   Nine I2C Controllers.
>>   Four UARTs supporting two 4-pin UART ports or four 2-pin UART ports.
>>   General Purpose IO (GPIO)
>> - Support for hardware virtualization and partitioning (ARM MMU-500)
>> - Support for GIC (ARM GIC-500)
>> - QorIQ platform Trust Architecture 3.0
>> - One Secure WatchDog timer and one Non-Secure Watchdog timer.
>> - ARM Generic Timer
>> - Two Flextimers
>> - Debug supporting run control, data acquisition, high-speed trace,
>>   performance/event monitoring
>> - Thermal Monitor Unit (TMU) with +/- 2C accuracy
>> - Support for Voltage ID (VID) for yield improvement
>>
>> Signed-off-by: Sriram Dash 
>> ---
>>  Documentation/devicetree/bindings/arm/fsl.txt  |   8 +
>>  arch/arm64/boot/dts/freescale/Makefile |   1 +
>>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 240
>> +
>> arch/arm64/boot/dts/freescale/fsl-lx2qds1.dts  |  54 ++
>>  4 files changed, 303 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2qds1.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
>> b/Documentation/devicetree/bindings/arm/fsl.txt
>> index cdb9dd7..6069434 100644
>> --- a/Documentation/devicetree/bindings/arm/fsl.txt
>> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
>> @@ -218,3 +218,11 @@ Required root node properties:
>>  LS2088A ARMv8 based RDB Board
>>  Required root node properties:
>>  - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a";
>> +
>> +LX2160A SoC
>> +Required root node properties:
>> +- compatible = "fsl,lx2160a";
>> +
>> +LX2160A ARMv8 based QDS Board
>> +Required root node properties:
>> +- compatible = "fsl,lx2qds1", "fsl,lx2160a";
>> diff --git a/arch/arm64/boot/dts/freescale/Makefile
>> b/arch/arm64/boot/dts/freescale/Makefile
>> index 72c4b52..634f6d4 100644
>> --- a/arch/arm64/boot/dts/freescale/Makefile
>> +++ b/arch/arm64/boot/dts/freescale/Makefile
>> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
>> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2qds1.dtb
>>
>>  always  := $(dtb-y)
>>  subdir-y:= $(dts-dirs)
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> new file mode 100644
>> index 000..48874cf
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> @@ -0,0 +1,240 @@
>> +/*
>> + * Device Tree Include file for Layerscape-LX2160A family SoC.
>> + *
>> + * Copyright 2017 NXP
>> + *
>> + * Sriram Dash 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPLv2 or the X11 license, at your option. Note that this
>> +dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General 

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

[David Miller]

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 0;
> + 
   ^^^

Likewise.

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

[Sriram Dash]

>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 processor cores with
>> advanced, high-performance datapath acceleration and network,
>> peripheral interfaces required for networking, wireless
>> infrastructure, storage, and general-purpose embedded applications.
>>
>> Features summary:
>> - Sixteen 32-bit / 64-bit ARM v8 A72 CPUs
>> - Cache Coherent Interconnect Fabric (CCN508 aka “Eliot”)
>> - Two 64-bit 3.2GT/s DDR4 SDRAM memory controllers with ECC.
>> - Data path acceleration architecture (DPAA2)
>> - 24 Serdes lanes at up to 25 GHz
>> - Ethernet interfaces
>>   Single WRIOP tile supporting 130Gbps using 18 MACs
>>   Support for 10G-SXGMII (aka USXGMII).
>>   Support for SGMII (and 1000Base-KX)
>>   Support for XFI (and 10GBase-KR)
>>   Support for CAUI4 (100G); CAUI2 (50G) and 25G-AUI(25G).
>>   Support for XLAUI4 (and 40GBase-KR4) for 40G.
>>   Support for two RGMII parallel interfaces.
>>   Energy efficient Ethernet support (802.3az)
>>   IEEE 1588 support.
>> - High-speed peripheral interfaces
>>   Two PCIe Gen 4.0 8-lane controllers supporting SR-IOV,
>>   Four PCIe Gen 4.0 4-lane controllers.
>>   Four serial ATA (SATA 3.0) controllers.
>>   Two USB 3.0 controllers with integrated PHY
>>   Two Enhanced secure digital host controllers
>>   Two Controller Area Network (CAN) modules
>>   Flexible Serial peripheral interface (FlexSPI) controller.
>>   Three Serial peripheral interface (SPI) controllers.
>>   Nine I2C Controllers.
>>   Four UARTs supporting two 4-pin UART ports or four 2-pin UART ports.
>>   General Purpose IO (GPIO)
>> - Support for hardware virtualization and partitioning (ARM MMU-500)
>> - Support for GIC (ARM GIC-500)
>> - QorIQ platform Trust Architecture 3.0
>> - One Secure WatchDog timer and one Non-Secure Watchdog timer.
>> - ARM Generic Timer
>> - Two Flextimers
>> - Debug supporting run control, data acquisition, high-speed trace,
>>   performance/event monitoring
>> - Thermal Monitor Unit (TMU) with +/- 2C accuracy
>> - Support for Voltage ID (VID) for yield improvement
>>
>> Signed-off-by: Sriram Dash 
>> ---
>>  Documentation/devicetree/bindings/arm/fsl.txt  |   8 +
>>  arch/arm64/boot/dts/freescale/Makefile |   1 +
>>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 240
>> +
>> arch/arm64/boot/dts/freescale/fsl-lx2qds1.dts  |  54 ++
>>  4 files changed, 303 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2qds1.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
>> b/Documentation/devicetree/bindings/arm/fsl.txt
>> index cdb9dd7..6069434 100644
>> --- a/Documentation/devicetree/bindings/arm/fsl.txt
>> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
>> @@ -218,3 +218,11 @@ Required root node properties:
>>  LS2088A ARMv8 based RDB Board
>>  Required root node properties:
>>  - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a";
>> +
>> +LX2160A SoC
>> +Required root node properties:
>> +- compatible = "fsl,lx2160a";
>> +
>> +LX2160A ARMv8 based QDS Board
>> +Required root node properties:
>> +- compatible = "fsl,lx2qds1", "fsl,lx2160a";
>> diff --git a/arch/arm64/boot/dts/freescale/Makefile
>> b/arch/arm64/boot/dts/freescale/Makefile
>> index 72c4b52..634f6d4 100644
>> --- a/arch/arm64/boot/dts/freescale/Makefile
>> +++ b/arch/arm64/boot/dts/freescale/Makefile
>> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
>> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2qds1.dtb
>>
>>  always  := $(dtb-y)
>>  subdir-y:= $(dts-dirs)
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> new file mode 100644
>> index 000..48874cf
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> @@ -0,0 +1,240 @@
>> +/*
>> + * Device Tree Include file for Layerscape-LX2160A family SoC.
>> + *
>> + * Copyright 2017 NXP
>> + *
>> + * Sriram Dash 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPLv2 or the X11 license, at your option. Note that this
>> +dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the 

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

[Greg KH]

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 releasing the lock. We reset the PGD
> only after dropping this lock, which could cause a race condition
> where another thread waiting on or even holding the lock, could
> potentially see that the PGD is still valid and proceed to perform
> a stage2 operation and later encounter a NULL PGD.
> 
> [223090.242280] Unable to handle kernel NULL pointer dereference at
> virtual address 0040
> [223090.262330] PC is at unmap_stage2_range+0x8c/0x428
> [223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
> [223090.262531] Call trace:
> [223090.262533] [] unmap_stage2_range+0x8c/0x428
> [223090.262535] [] kvm_unmap_hva_handler+0x2c/0x3c
> [223090.262537] [] handle_hva_to_gpa+0xb0/0x104
> [223090.262539] [] kvm_unmap_hva+0x5c/0xbc
> [223090.262543] [] 
> kvm_mmu_notifier_invalidate_page+0x50/0x8c
> [223090.262547] [] __mmu_notifier_invalidate_page+0x5c/0x84
> [223090.262551] [] try_to_unmap_one+0x1d0/0x4a0
> [223090.262553] [] rmap_walk+0x1cc/0x2e0
> [223090.262555] [] try_to_unmap+0x74/0xa4
> [223090.262557] [] migrate_pages+0x31c/0x5ac
> [223090.262561] [] compact_zone+0x3fc/0x7ac
> [223090.262563] [] compact_zone_order+0x94/0xb0
> [223090.262564] [] try_to_compact_pages+0x108/0x290
> [223090.262569] [] __alloc_pages_direct_compact+0x70/0x1ac
> [223090.262571] [] __alloc_pages_nodemask+0x434/0x9f4
> [223090.262572] [] alloc_pages_vma+0x230/0x254
> [223090.262574] [] do_huge_pmd_anonymous_page+0x114/0x538
> [223090.262576] [] handle_mm_fault+0xd40/0x17a4
> [223090.262577] [] __get_user_pages+0x12c/0x36c
> [223090.262578] [] get_user_pages_unlocked+0xa4/0x1b8
> [223090.262579] [] __gfn_to_pfn_memslot+0x280/0x31c
> [223090.262580] [] gfn_to_pfn_prot+0x4c/0x5c
> [223090.262582] [] kvm_handle_guest_abort+0x240/0x774
> [223090.262584] [] handle_exit+0x11c/0x1ac
> [223090.262586] [] kvm_arch_vcpu_ioctl_run+0x31c/0x648
> [223090.262587] [] kvm_vcpu_ioctl+0x378/0x768
> [223090.262590] [] do_vfs_ioctl+0x324/0x5a4
> [223090.262591] [] SyS_ioctl+0x90/0xa4
> [223090.262595] [] el0_svc_naked+0x38/0x3c
> 
> This patch moves the stage2 PGD manipulation under the lock.
> 
> Reported-by: Alexander Graf 
> Cc: Mark Rutland 
> Cc: Marc Zyngier 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: sta...@vger.kernel.org # 4.10.x and earlier
> Reviewed-by: Christoffer Dall 
> Reviewed-by: Marc Zyngier 
> Signed-off-by: Suzuki K Poulose 
> Signed-off-by: Christoffer Dall 
> 
> ---
> 
> Hi,
> 
> Looks like we missed sending this to stable. Please apply for 4.10.x and
> earlier. 4.11.y and later versions have it already.

Only applied to 4.9-stable, can you please provide a backport for 4.4
and 3.18 if you want it there?

thanks,

greg k-h

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

[Greg KH]

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 releasing the lock. We reset the PGD
> only after dropping this lock, which could cause a race condition
> where another thread waiting on or even holding the lock, could
> potentially see that the PGD is still valid and proceed to perform
> a stage2 operation and later encounter a NULL PGD.
> 
> [223090.242280] Unable to handle kernel NULL pointer dereference at
> virtual address 0040
> [223090.262330] PC is at unmap_stage2_range+0x8c/0x428
> [223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
> [223090.262531] Call trace:
> [223090.262533] [] unmap_stage2_range+0x8c/0x428
> [223090.262535] [] kvm_unmap_hva_handler+0x2c/0x3c
> [223090.262537] [] handle_hva_to_gpa+0xb0/0x104
> [223090.262539] [] kvm_unmap_hva+0x5c/0xbc
> [223090.262543] [] 
> kvm_mmu_notifier_invalidate_page+0x50/0x8c
> [223090.262547] [] __mmu_notifier_invalidate_page+0x5c/0x84
> [223090.262551] [] try_to_unmap_one+0x1d0/0x4a0
> [223090.262553] [] rmap_walk+0x1cc/0x2e0
> [223090.262555] [] try_to_unmap+0x74/0xa4
> [223090.262557] [] migrate_pages+0x31c/0x5ac
> [223090.262561] [] compact_zone+0x3fc/0x7ac
> [223090.262563] [] compact_zone_order+0x94/0xb0
> [223090.262564] [] try_to_compact_pages+0x108/0x290
> [223090.262569] [] __alloc_pages_direct_compact+0x70/0x1ac
> [223090.262571] [] __alloc_pages_nodemask+0x434/0x9f4
> [223090.262572] [] alloc_pages_vma+0x230/0x254
> [223090.262574] [] do_huge_pmd_anonymous_page+0x114/0x538
> [223090.262576] [] handle_mm_fault+0xd40/0x17a4
> [223090.262577] [] __get_user_pages+0x12c/0x36c
> [223090.262578] [] get_user_pages_unlocked+0xa4/0x1b8
> [223090.262579] [] __gfn_to_pfn_memslot+0x280/0x31c
> [223090.262580] [] gfn_to_pfn_prot+0x4c/0x5c
> [223090.262582] [] kvm_handle_guest_abort+0x240/0x774
> [223090.262584] [] handle_exit+0x11c/0x1ac
> [223090.262586] [] kvm_arch_vcpu_ioctl_run+0x31c/0x648
> [223090.262587] [] kvm_vcpu_ioctl+0x378/0x768
> [223090.262590] [] do_vfs_ioctl+0x324/0x5a4
> [223090.262591] [] SyS_ioctl+0x90/0xa4
> [223090.262595] [] el0_svc_naked+0x38/0x3c
> 
> This patch moves the stage2 PGD manipulation under the lock.
> 
> Reported-by: Alexander Graf 
> Cc: Mark Rutland 
> Cc: Marc Zyngier 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: sta...@vger.kernel.org # 4.10.x and earlier
> Reviewed-by: Christoffer Dall 
> Reviewed-by: Marc Zyngier 
> Signed-off-by: Suzuki K Poulose 
> Signed-off-by: Christoffer Dall 
> 
> ---
> 
> Hi,
> 
> Looks like we missed sending this to stable. Please apply for 4.10.x and
> earlier. 4.11.y and later versions have it already.

Only applied to 4.9-stable, can you please provide a backport for 4.4
and 3.18 if you want it there?

thanks,

greg k-h

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

[Suganath Prabu Subramani]

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 capability just because the hardware has
> it.
>
> Unlike some other operating systems, Linux will only submit I/Os to the
> driver that conform to the reported underlying constraints of the
> hardware.

 In general, h/w constraints are handled. What we missed is
Fast Path h/w
which is not exposed to OS.

> I fail to understand how letting the HBA firmware translate an
> SGL to a PRP for a subset of I/Os could do anything but add latency.

 Let me explain - NVME device fast path is possible in two ways.
IEEE SGL and PRP SGL. Due to h/w constraint we choose IEEE SGL only for
smaller IO size.
Both above is true h/w Fast Path and no firmware involvement.

> Plus complexity in the hot path of the driver.

 Agree with you. We are planning to see if we can keep only
simple Fast
Path using only PRP. It will take some time to finalize as we have to
engage h/w and f/w team.  BTW - This area is h/w dependent and we do not
see further changes in this area.

>
>> - If the unmap translation in firmware is slow, why don't you translate
>>   WRITE SAME/w UNMAP set to DSM DEALLOCATE without requiring
>>   applications to do encapsulated passthrough?
>
>> => As of now, current FW supports UNMAP command but not WRITE_SAME for
>> NVME drive. We did some experiment to convert UMAP command in driver,
>> but that is not really giving any performance improvement.
>
> It is imperative that the common use case, Linux' discard
> infrastructure, is working correctly and is as performant as any
> application-driven passthrough workaround.
>
> Unlike SCSI-to-SATA translation you have the benefit of a 1:1 mapping
> between UNMAP and DEALLOCATE. I'm not even sure why there would be a
> significant performance penalty in the firmware?

 I agree. Currently there is no performance issue for UNMAP
translation in
FW.


>> We would like to continue with UNMAP (and all other non-read/write
>> commands) to be handled in FW.
>
> And yet patch 4 circumvents that statement by adding support for
> encapsulated commands to bypass the FW translation...

 This path is not due to performance reason. User wants to
interact with
NVME drive in native NVME command for management.

>
> --
> Martin K. Petersen  Oracle Linux Engineering

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

[Suganath Prabu Subramani]

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 capability just because the hardware has
> it.
>
> Unlike some other operating systems, Linux will only submit I/Os to the
> driver that conform to the reported underlying constraints of the
> hardware.

 In general, h/w constraints are handled. What we missed is
Fast Path h/w
which is not exposed to OS.

> I fail to understand how letting the HBA firmware translate an
> SGL to a PRP for a subset of I/Os could do anything but add latency.

 Let me explain - NVME device fast path is possible in two ways.
IEEE SGL and PRP SGL. Due to h/w constraint we choose IEEE SGL only for
smaller IO size.
Both above is true h/w Fast Path and no firmware involvement.

> Plus complexity in the hot path of the driver.

 Agree with you. We are planning to see if we can keep only
simple Fast
Path using only PRP. It will take some time to finalize as we have to
engage h/w and f/w team.  BTW - This area is h/w dependent and we do not
see further changes in this area.

>
>> - If the unmap translation in firmware is slow, why don't you translate
>>   WRITE SAME/w UNMAP set to DSM DEALLOCATE without requiring
>>   applications to do encapsulated passthrough?
>
>> => As of now, current FW supports UNMAP command but not WRITE_SAME for
>> NVME drive. We did some experiment to convert UMAP command in driver,
>> but that is not really giving any performance improvement.
>
> It is imperative that the common use case, Linux' discard
> infrastructure, is working correctly and is as performant as any
> application-driven passthrough workaround.
>
> Unlike SCSI-to-SATA translation you have the benefit of a 1:1 mapping
> between UNMAP and DEALLOCATE. I'm not even sure why there would be a
> significant performance penalty in the firmware?

 I agree. Currently there is no performance issue for UNMAP
translation in
FW.


>> We would like to continue with UNMAP (and all other non-read/write
>> commands) to be handled in FW.
>
> And yet patch 4 circumvents that statement by adding support for
> encapsulated commands to bypass the FW translation...

 This path is not due to performance reason. User wants to
interact with
NVME drive in native NVME command for management.

>
> --
> Martin K. Petersen  Oracle Linux Engineering

Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

[Amir Goldstein]

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 running 3 processes that constantly ask to be notified
blocking on file system events and then they never read those
events. Even tough the marks are also destroyed, odd are that
at least one mark will be alive at any given time.

Why is it surprising that touching a file in monitored directory
hangs forever?

I am very happy to see someone is writing stress tests for
fanotify, I am just not sure this test is tuned correctly.
Have you been trying to reproduce a reported bug?

Amir.

>
> Thanks,
> Xiong
>
> [  492.060879] INFO: task touch:2259 blocked for more than 120 seconds.
> [  492.093497]   Not tainted 4.13.0-rc7-master-42ff72c+ #9
> [  492.121049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  492.156289] touch   D0  2259   2233 0x0080
> [  492.180880] Call Trace:
> [  492.191813]  __schedule+0x28d/0x890
> [  492.207440]  schedule+0x36/0x80
> [  492.221529]  fanotify_handle_event+0x2a1/0x2f0
> [  492.241542]  ? remove_wait_queue+0x60/0x60
> [  492.260150]  fsnotify+0x2d3/0x4f0
> [  492.275055]  ? security_inode_init_security+0xd2/0x190
> [  492.298097]  security_file_open+0x89/0x90
> [  492.316038]  do_dentry_open+0x139/0x330
> [  492.333216]  vfs_open+0x4f/0x70
> [  492.347225]  ? may_open+0x5a/0x100
> [  492.362481]  path_openat+0x548/0x13b0
> [  492.378958]  do_filp_open+0x91/0x100
> [  492.394969]  ? __alloc_fd+0x46/0x170
> [  492.410930]  do_sys_open+0x124/0x210
> [  492.426927]  SyS_open+0x1e/0x20
> [  492.440963]  do_syscall_64+0x67/0x150
> [  492.457367]  entry_SYSCALL64_slow_path+0x25/0x25
> [  492.478251] RIP: 0033:0x7fe877f8e5a0
> [  492.495755] RSP: 002b:7ffe57120318 EFLAGS: 0246 ORIG_RAX: 
> 0002
> [  492.529911] RAX: ffda RBX: 7ffe57120578 RCX: 
> 7fe877f8e5a0
> [  492.561508] RDX: 01b6 RSI: 0941 RDI: 
> 7ffe5712268c
> [  492.595577] RBP:  R08:  R09: 
> 
> [  492.631144] R10: 7ffe57120030 R11: 0246 R12: 
> 7ffe5712268c
> [  492.664970] R13: 7fe8782612a0 R14: 0001 R15: 
> 
>
>
> 
> $ cat test.sh
>
> #!/bin/bash -x
>
> fallocate -l 2G test.img
> mkfs.xfs -fq test.img
> mkdir -p testdir
> mount -o loop test.img testdir || exit
>
> SCRATCH_MNT=$(readlink -f testdir)
>
> function clean ()
> {
> while ps -eo comm | grep -q -e fanotify ; do
> killall fanotify_flush_stress
> done
>
> umount -d $SCRATCH_MNT
> rm -rf test.img scrc $SCRATCH_MNT fanotify_flush_stress
> }
>
> trap "clean; exit;" 2
>
> cc fanotify_flush_stress.c -o fanotify_flush_stress
>
> ./fanotify_flush_stress $SCRATCH_MNT &
> ./fanotify_flush_stress $SCRATCH_MNT &
> ./fanotify_flush_stress $SCRATCH_MNT &
>
> ps jf | grep fanotify
>
> touch $SCRATCH_MNT/1  # hang
>
> clean
>
> 
> $ cat fanotify_flush_stress.c
>
> #define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main(int argc, char *argv[])
> {
> char buf;
> int fd;
>
> /* Check mount point is supplied */
> if (argc != 2) {
> fprintf(stderr, "Usage: %s MOUNT\n", argv[0]);
> exit(EXIT_FAILURE);
> }
>
> printf("%s on %s\n", argv[0], argv[1]);
> /* Create the file descriptor for accessing the fanotify API */
> fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK,
>O_RDWR | O_LARGEFILE);
> if (fd == -1) {
> perror("fanotify_init");
> exit(EXIT_FAILURE);
> }
>
> /* Loop marking all kinds of events and flush */
> while (1) {
>
> #if 1
> if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
>   FAN_ACCESS | FAN_MODIFY | FAN_OPEN_PERM | FAN_CLOSE 
> |
>   FAN_OPEN | FAN_ACCESS_PERM | FAN_ONDIR |
>   FAN_EVENT_ON_CHILD, -1, argv[1]) == -1)
>
> perror("fanotify_mark add");
>
> if (fanotify_mark(fd, FAN_MARK_FLUSH | FAN_MARK_MOUNT,
> 0, -1, argv[1]) == -1)
> perror("fanotify_mark flush mount");
> #else
> if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
>   FAN_ACCESS | FAN_MODIFY | FAN_OPEN_PERM | FAN_CLOSE 
> |
>   FAN_OPEN | FAN_ACCESS_PERM | 

Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

[Amir Goldstein]

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 running 3 processes that constantly ask to be notified
blocking on file system events and then they never read those
events. Even tough the marks are also destroyed, odd are that
at least one mark will be alive at any given time.

Why is it surprising that touching a file in monitored directory
hangs forever?

I am very happy to see someone is writing stress tests for
fanotify, I am just not sure this test is tuned correctly.
Have you been trying to reproduce a reported bug?

Amir.

>
> Thanks,
> Xiong
>
> [  492.060879] INFO: task touch:2259 blocked for more than 120 seconds.
> [  492.093497]   Not tainted 4.13.0-rc7-master-42ff72c+ #9
> [  492.121049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  492.156289] touch   D0  2259   2233 0x0080
> [  492.180880] Call Trace:
> [  492.191813]  __schedule+0x28d/0x890
> [  492.207440]  schedule+0x36/0x80
> [  492.221529]  fanotify_handle_event+0x2a1/0x2f0
> [  492.241542]  ? remove_wait_queue+0x60/0x60
> [  492.260150]  fsnotify+0x2d3/0x4f0
> [  492.275055]  ? security_inode_init_security+0xd2/0x190
> [  492.298097]  security_file_open+0x89/0x90
> [  492.316038]  do_dentry_open+0x139/0x330
> [  492.333216]  vfs_open+0x4f/0x70
> [  492.347225]  ? may_open+0x5a/0x100
> [  492.362481]  path_openat+0x548/0x13b0
> [  492.378958]  do_filp_open+0x91/0x100
> [  492.394969]  ? __alloc_fd+0x46/0x170
> [  492.410930]  do_sys_open+0x124/0x210
> [  492.426927]  SyS_open+0x1e/0x20
> [  492.440963]  do_syscall_64+0x67/0x150
> [  492.457367]  entry_SYSCALL64_slow_path+0x25/0x25
> [  492.478251] RIP: 0033:0x7fe877f8e5a0
> [  492.495755] RSP: 002b:7ffe57120318 EFLAGS: 0246 ORIG_RAX: 
> 0002
> [  492.529911] RAX: ffda RBX: 7ffe57120578 RCX: 
> 7fe877f8e5a0
> [  492.561508] RDX: 01b6 RSI: 0941 RDI: 
> 7ffe5712268c
> [  492.595577] RBP:  R08:  R09: 
> 
> [  492.631144] R10: 7ffe57120030 R11: 0246 R12: 
> 7ffe5712268c
> [  492.664970] R13: 7fe8782612a0 R14: 0001 R15: 
> 
>
>
> 
> $ cat test.sh
>
> #!/bin/bash -x
>
> fallocate -l 2G test.img
> mkfs.xfs -fq test.img
> mkdir -p testdir
> mount -o loop test.img testdir || exit
>
> SCRATCH_MNT=$(readlink -f testdir)
>
> function clean ()
> {
> while ps -eo comm | grep -q -e fanotify ; do
> killall fanotify_flush_stress
> done
>
> umount -d $SCRATCH_MNT
> rm -rf test.img scrc $SCRATCH_MNT fanotify_flush_stress
> }
>
> trap "clean; exit;" 2
>
> cc fanotify_flush_stress.c -o fanotify_flush_stress
>
> ./fanotify_flush_stress $SCRATCH_MNT &
> ./fanotify_flush_stress $SCRATCH_MNT &
> ./fanotify_flush_stress $SCRATCH_MNT &
>
> ps jf | grep fanotify
>
> touch $SCRATCH_MNT/1  # hang
>
> clean
>
> 
> $ cat fanotify_flush_stress.c
>
> #define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main(int argc, char *argv[])
> {
> char buf;
> int fd;
>
> /* Check mount point is supplied */
> if (argc != 2) {
> fprintf(stderr, "Usage: %s MOUNT\n", argv[0]);
> exit(EXIT_FAILURE);
> }
>
> printf("%s on %s\n", argv[0], argv[1]);
> /* Create the file descriptor for accessing the fanotify API */
> fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK,
>O_RDWR | O_LARGEFILE);
> if (fd == -1) {
> perror("fanotify_init");
> exit(EXIT_FAILURE);
> }
>
> /* Loop marking all kinds of events and flush */
> while (1) {
>
> #if 1
> if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
>   FAN_ACCESS | FAN_MODIFY | FAN_OPEN_PERM | FAN_CLOSE 
> |
>   FAN_OPEN | FAN_ACCESS_PERM | FAN_ONDIR |
>   FAN_EVENT_ON_CHILD, -1, argv[1]) == -1)
>
> perror("fanotify_mark add");
>
> if (fanotify_mark(fd, FAN_MARK_FLUSH | FAN_MARK_MOUNT,
> 0, -1, argv[1]) == -1)
> perror("fanotify_mark flush mount");
> #else
> if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
>   FAN_ACCESS | FAN_MODIFY | FAN_OPEN_PERM | FAN_CLOSE 
> |
>   FAN_OPEN | FAN_ACCESS_PERM | FAN_ONDIR |
>

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

[Oza Pawandeep]

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
index b8e48b4..0c5f631 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,20 @@ Optional properties:
 - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
 require the interrupt enable registers to be set explicitly to enable MSI
 
+Optional properties:
+- slot-pluggable: PCI hotplug feature is supported.
+- prsnt-gpios: Array of gpios, needs to be present if Hotplug is supported.
+
+Refer to the following binding documents for more detailed description on
+the use of 'slot-pluggable' and 'prsnt-gpios'.
+  Documentation/devicetree/bindings/pci/pci.txt
+
+Example:
+prsnt-gpios: < 32 1>, < 33 1>;
+This is x4 connector: monitoring max 2 present lines.
+prsnt-gpios: < 32 1>, < 33 1>, < 34 1>;
+This is x8 connector: monitoring max 3 present lines.
+
 Example:
pcie0: pcie@18012000 {
compatible = "brcm,iproc-pcie";
-- 
1.9.1

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

[Oza Pawandeep]

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
index b8e48b4..0c5f631 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,20 @@ Optional properties:
 - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
 require the interrupt enable registers to be set explicitly to enable MSI
 
+Optional properties:
+- slot-pluggable: PCI hotplug feature is supported.
+- prsnt-gpios: Array of gpios, needs to be present if Hotplug is supported.
+
+Refer to the following binding documents for more detailed description on
+the use of 'slot-pluggable' and 'prsnt-gpios'.
+  Documentation/devicetree/bindings/pci/pci.txt
+
+Example:
+prsnt-gpios: < 32 1>, < 33 1>;
+This is x4 connector: monitoring max 2 present lines.
+prsnt-gpios: < 32 1>, < 33 1>, < 34 1>;
+This is x8 connector: monitoring max 3 present lines.
+
 Example:
pcie0: pcie@18012000 {
compatible = "brcm,iproc-pcie";
-- 
1.9.1

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

[Oza Pawandeep]

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 
Acked-by: Rob Herring 

diff --git a/Documentation/devicetree/bindings/pci/pci.txt 
b/Documentation/devicetree/bindings/pci/pci.txt
index 50f9e2c..0bf25a1 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -24,3 +24,18 @@ driver implementation may support the following properties:
unsupported link speed, for instance, trying to do training for
unsupported link speed, etc.  Must be '4' for gen4, '3' for gen3, '2'
for gen2, and '1' for gen1. Any other values are invalid.
+
+- slot-pluggable:
+   PCI hotplug feature is supported.
+   PCI hotplug implementation is SOC/Board specific, and also it depends on
+   how add-in card is designed (e.g. how many present pins are implemented).
+   If the slot-pluggable property is present, the following propertey could
+   become effective.
+   - prsnt-gpios:
+  Array of gpios, could be present if hotplug is supported.
+  This property defines gpio based hotplug implementation.
+  Example:
+  If x8 card is connected, then it might be possible that all the
+  3 present pins could go low, or at least one pin goes low.
+  If x4 card is connected, then it might be possible that 2 present
+  pins go low, or at least one pin goes low.
-- 
1.9.1

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

[Oza Pawandeep]

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 PCI hotplug is as follows:
PCI present lines are input to GPIOs depending on the type of
connector (x2, x4, x8).

GPIO array needs to be present if hotplug is supported.
HW implementation is SOC/Board specific, and also it depends on how
add-in card is designed
(e.g. how many present pins are implemented).

If x8 card is connected, then it might be possible that all the
3 present pins could go low, or at least one pin goes low.
If x4 card is connected, then it might be possible that 2 present
pins go low, or at least one pin goes low.

The implementation essentially takes care of following:
> Initializing hotplug irq thread.
> Detecting the endpoint device based on link state.
> Handling PERST and detecting the plugged devices.
> Ordered Hot plug-out, where User is expected
  to write 1 to /sys/bus/pci/devices//remove
> Handling spurious interrupt
> Handling multiple interrupts and makes sure that card is
  enumerated only once.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index a5073a9..6287a43 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device 
*pdev)
pcie->need_ob_cfg = true;
}
 
+   if (of_property_read_bool(np, "slot-pluggable"))
+   pcie->enable_hotplug = true;
+
/* PHY use is optional */
pcie->phy = devm_phy_get(dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 8bd5e54..2b4d830 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pcie-iproc.h"
 
@@ -65,6 +66,17 @@
 #define PCIE_DL_ACTIVE_SHIFT 2
 #define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define CFG_RC_LTSSM 0x1cf8
+#define CFG_RC_PHY_CTL   0x1804
+#define CFG_RC_LTSSM_TIMEOUT 1000
+#define CFG_RC_LTSSM_STATE_MASK  0xff
+#define CFG_RC_LTSSM_STATE_L10x1
+
+#define CFG_RC_CLR_LTSSM_HIST_SHIFT  29
+#define CFG_RC_CLR_LTSSM_HIST_MASK   BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)
+#define CFG_RC_CLR_RECOV_HIST_SHIFT  31
+#define CFG_RC_CLR_RECOV_HIST_MASK   BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)
+
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
@@ -1354,13 +1366,107 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
return 0;
 }
 
+static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)
+{
+   struct pci_bus *bus = pcie->root_bus;
+   u32 val, timeout = CFG_RC_LTSSM_TIMEOUT;
+
+   /* Clear LTSSM history. */
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_PHY_CTL, );
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,
+  val | CFG_RC_CLR_RECOV_HIST_MASK |
+  CFG_RC_CLR_LTSSM_HIST_MASK);
+   /* write back the origional value. */
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);
+
+   do {
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_LTSSM, );
+   /* check link state to see if link moved to L1 state. */
+   if ((val & CFG_RC_LTSSM_STATE_MASK) ==
+CFG_RC_LTSSM_STATE_L1)
+   return true;
+   timeout--;
+   usleep_range(500, 1000);
+   } while (timeout);
+
+   return false;
+}
+
+static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)
+{
+   struct iproc_pcie *pcie = data;
+   struct pci_bus *bus = pcie->root_bus, *child;
+   bool link_status;
+
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
+
+   link_status = iproc_pci_hp_check_ltssm(pcie);
+
+   if (link_status &&
+   !iproc_pcie_check_link(pcie) &&
+   !pcie->ep_is_present) {
+   pci_rescan_bus(bus);
+   list_for_each_entry(child, >children, node)
+   pcie_bus_configure_settings(child);
+   pcie->ep_is_present = true;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   } else if (link_status && pcie->ep_is_present)
+   /*
+* ep_is_present makes sure, enumuration done only once.
+* So it can handle spurious intrrupts, and also if we
+* get 

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

[Oza Pawandeep]

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 
Acked-by: Rob Herring 

diff --git a/Documentation/devicetree/bindings/pci/pci.txt 
b/Documentation/devicetree/bindings/pci/pci.txt
index 50f9e2c..0bf25a1 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -24,3 +24,18 @@ driver implementation may support the following properties:
unsupported link speed, for instance, trying to do training for
unsupported link speed, etc.  Must be '4' for gen4, '3' for gen3, '2'
for gen2, and '1' for gen1. Any other values are invalid.
+
+- slot-pluggable:
+   PCI hotplug feature is supported.
+   PCI hotplug implementation is SOC/Board specific, and also it depends on
+   how add-in card is designed (e.g. how many present pins are implemented).
+   If the slot-pluggable property is present, the following propertey could
+   become effective.
+   - prsnt-gpios:
+  Array of gpios, could be present if hotplug is supported.
+  This property defines gpio based hotplug implementation.
+  Example:
+  If x8 card is connected, then it might be possible that all the
+  3 present pins could go low, or at least one pin goes low.
+  If x4 card is connected, then it might be possible that 2 present
+  pins go low, or at least one pin goes low.
-- 
1.9.1

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

[Oza Pawandeep]

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 PCI hotplug is as follows:
PCI present lines are input to GPIOs depending on the type of
connector (x2, x4, x8).

GPIO array needs to be present if hotplug is supported.
HW implementation is SOC/Board specific, and also it depends on how
add-in card is designed
(e.g. how many present pins are implemented).

If x8 card is connected, then it might be possible that all the
3 present pins could go low, or at least one pin goes low.
If x4 card is connected, then it might be possible that 2 present
pins go low, or at least one pin goes low.

The implementation essentially takes care of following:
> Initializing hotplug irq thread.
> Detecting the endpoint device based on link state.
> Handling PERST and detecting the plugged devices.
> Ordered Hot plug-out, where User is expected
  to write 1 to /sys/bus/pci/devices//remove
> Handling spurious interrupt
> Handling multiple interrupts and makes sure that card is
  enumerated only once.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index a5073a9..6287a43 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device 
*pdev)
pcie->need_ob_cfg = true;
}
 
+   if (of_property_read_bool(np, "slot-pluggable"))
+   pcie->enable_hotplug = true;
+
/* PHY use is optional */
pcie->phy = devm_phy_get(dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 8bd5e54..2b4d830 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pcie-iproc.h"
 
@@ -65,6 +66,17 @@
 #define PCIE_DL_ACTIVE_SHIFT 2
 #define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define CFG_RC_LTSSM 0x1cf8
+#define CFG_RC_PHY_CTL   0x1804
+#define CFG_RC_LTSSM_TIMEOUT 1000
+#define CFG_RC_LTSSM_STATE_MASK  0xff
+#define CFG_RC_LTSSM_STATE_L10x1
+
+#define CFG_RC_CLR_LTSSM_HIST_SHIFT  29
+#define CFG_RC_CLR_LTSSM_HIST_MASK   BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)
+#define CFG_RC_CLR_RECOV_HIST_SHIFT  31
+#define CFG_RC_CLR_RECOV_HIST_MASK   BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)
+
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
@@ -1354,13 +1366,107 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
return 0;
 }
 
+static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)
+{
+   struct pci_bus *bus = pcie->root_bus;
+   u32 val, timeout = CFG_RC_LTSSM_TIMEOUT;
+
+   /* Clear LTSSM history. */
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_PHY_CTL, );
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,
+  val | CFG_RC_CLR_RECOV_HIST_MASK |
+  CFG_RC_CLR_LTSSM_HIST_MASK);
+   /* write back the origional value. */
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);
+
+   do {
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_LTSSM, );
+   /* check link state to see if link moved to L1 state. */
+   if ((val & CFG_RC_LTSSM_STATE_MASK) ==
+CFG_RC_LTSSM_STATE_L1)
+   return true;
+   timeout--;
+   usleep_range(500, 1000);
+   } while (timeout);
+
+   return false;
+}
+
+static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)
+{
+   struct iproc_pcie *pcie = data;
+   struct pci_bus *bus = pcie->root_bus, *child;
+   bool link_status;
+
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
+
+   link_status = iproc_pci_hp_check_ltssm(pcie);
+
+   if (link_status &&
+   !iproc_pcie_check_link(pcie) &&
+   !pcie->ep_is_present) {
+   pci_rescan_bus(bus);
+   list_for_each_entry(child, >children, node)
+   pcie_bus_configure_settings(child);
+   pcie->ep_is_present = true;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   } else if (link_status && pcie->ep_is_present)
+   /*
+* ep_is_present makes sure, enumuration done only once.
+* So it can handle spurious intrrupts, and also if we
+* get multiple interrupts for all the implemented 

[PATCH v6 0/3] PCI hotplug feature

[Oza Pawandeep]

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 sync previous in-flight patches.

Changes since v2:
Addressed Rob Herring's comments.
Changed subject to "dt-bindings: PCI:..."
Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'
Rebased the patches on top of Lorenzo's patches.

Oza Pawandeep (3):
  dt-bindings: PCI: Add PCI hotplug property
  dt-bindings: PCI iproc: Implement optional property prsnt-gpios
  PCI: iproc: Implement PCI hotplug support

 .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  14 ++
 Documentation/devicetree/bindings/pci/pci.txt  |  15 ++
 drivers/pci/host/pcie-iproc-platform.c |   3 +
 drivers/pci/host/pcie-iproc.c  | 166 ++---
 drivers/pci/host/pcie-iproc.h  |   7 +
 5 files changed, 187 insertions(+), 18 deletions(-)

-- 
1.9.1

[PATCH v6 0/3] PCI hotplug feature

[Oza Pawandeep]

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 sync previous in-flight patches.

Changes since v2:
Addressed Rob Herring's comments.
Changed subject to "dt-bindings: PCI:..."
Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'
Rebased the patches on top of Lorenzo's patches.

Oza Pawandeep (3):
  dt-bindings: PCI: Add PCI hotplug property
  dt-bindings: PCI iproc: Implement optional property prsnt-gpios
  PCI: iproc: Implement PCI hotplug support

 .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  14 ++
 Documentation/devicetree/bindings/pci/pci.txt  |  15 ++
 drivers/pci/host/pcie-iproc-platform.c |   3 +
 drivers/pci/host/pcie-iproc.c  | 166 ++---
 drivers/pci/host/pcie-iproc.h  |   7 +
 5 files changed, 187 insertions(+), 18 deletions(-)

-- 
1.9.1

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

[Larry Finger]

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 tested by compilation only.
I'm suspicious this may be a copy/paste error. Please, verify.

  .../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c   | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)


This change is not correct. When bt_link_info->sco_exist is true, the call 
should be

halbtc8723b1ant_limited_rx(btcoexist,
   NORMAL_EXEC, true,
   false, 0x5);

NACK

I will push the correct patch.

Larry

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

[Larry Finger]

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 tested by compilation only.
I'm suspicious this may be a copy/paste error. Please, verify.

  .../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c   | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)


This change is not correct. When bt_link_info->sco_exist is true, the call 
should be

halbtc8723b1ant_limited_rx(btcoexist,
   NORMAL_EXEC, true,
   false, 0x5);

NACK

I will push the correct patch.

Larry

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

[Sricharan R]

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   | 70 +++--
 include/linux/soc/qcom/mdt_loader.h |  3 ++
 2 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index bd63df0..851f5d7 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -86,9 +86,9 @@ ssize_t qcom_mdt_get_size(const struct firmware *fw)
  *
  * Returns 0 on success, negative errno otherwise.
  */
-int qcom_mdt_load(struct device *dev, const struct firmware *fw,
- const char *firmware, int pas_id, void *mem_region,
- phys_addr_t mem_phys, size_t mem_size)
+static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
+  const char *firmware, int pas_id, void *mem_region,
+  phys_addr_t mem_phys, size_t mem_size, bool pas_init)
 {
const struct elf32_phdr *phdrs;
const struct elf32_phdr *phdr;
@@ -119,10 +119,12 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
if (!fw_name)
return -ENOMEM;
 
-   ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
-   if (ret) {
-   dev_err(dev, "invalid firmware metadata\n");
-   goto out;
+   if (pas_init) {
+   ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
+   if (ret) {
+   dev_err(dev, "invalid firmware metadata\n");
+   goto out;
+   }
}
 
for (i = 0; i < ehdr->e_phnum; i++) {
@@ -142,10 +144,13 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
}
 
if (relocate) {
-   ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - 
min_addr);
-   if (ret) {
-   dev_err(dev, "unable to setup relocation\n");
-   goto out;
+   if (pas_init) {
+   ret = qcom_scm_pas_mem_setup(pas_id, mem_phys,
+max_addr - min_addr);
+   if (ret) {
+   dev_err(dev, "unable to setup relocation\n");
+   goto out;
+   }
}
 
/*
@@ -198,7 +203,50 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
 
return ret;
 }
+
+/**
+ * qcom_mdt_load() - sets up the secure memory for the firmware and
+loads the firmware
+ * @dev:   device handle to associate resources with
+ * @fw:firmware object for the mdt file
+ * @firmware:  name of the firmware, for construction of segment file names
+ * @pas_id:PAS identifier
+ * @mem_region:allocated memory region to load firmware into
+ * @mem_phys:  physical address of allocated memory region
+ * @mem_size:  size of the allocated memory region
+ *
+ * Returns 0 on success, negative errno otherwise.
+ */
+int qcom_mdt_load(struct device *dev, const struct firmware *fw,
+ const char *firmware, int pas_id, void *mem_region,
+ phys_addr_t mem_phys, size_t mem_size)
+{
+   return __qcom_mdt_load(dev, fw, firmware, pas_id, mem_region, mem_phys,
+  mem_size, true);
+}
 EXPORT_SYMBOL_GPL(qcom_mdt_load);
 
+/**
+ * qcom_mdt_load_no_init() - load the firmware which header is loaded as fw
+ * @dev:   device handle to associate resources with
+ * @fw:firmware object for the mdt file
+ * @firmware:  name of the firmware, for construction of segment file names
+ * @pas_id:PAS identifier
+ * @mem_region:allocated memory region to load firmware into
+ * @mem_phys:  physical address of allocated memory region
+ * @mem_size:  size of the allocated memory region
+ *
+ * Returns 0 on success, negative errno otherwise.
+ */
+int qcom_mdt_load_no_init(struct device *dev, const struct firmware *fw,
+ const char *firmware, int pas_id,
+ void *mem_region, phys_addr_t mem_phys,
+ size_t mem_size)
+{
+   return __qcom_mdt_load(dev, fw, firmware, pas_id, mem_region, mem_phys,
+  mem_size, false);
+}
+EXPORT_SYMBOL_GPL(qcom_mdt_load_no_init);
+
 MODULE_DESCRIPTION("Firmware parser for Qualcomm MDT format");
 MODULE_LICENSE("GPL v2");
diff --git a/include/linux/soc/qcom/mdt_loader.h 
b/include/linux/soc/qcom/mdt_loader.h
index f423001..228053a 100644
--- a/include/linux/soc/qcom/mdt_loader.h
+++ b/include/linux/soc/qcom/mdt_loader.h
@@ -15,4 +15,7 @@ int 

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

[Sricharan R]

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 
---
 .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |  7 ++-
 drivers/remoteproc/Kconfig |  1 +
 drivers/remoteproc/qcom_q6v5_pil.c | 53 +-
 3 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index 87a8e51..a0a9ad3 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -12,6 +12,7 @@ on the Qualcomm Hexagon core.
"qcom,msm8974-mss-pil"
 
"qcom,msm8996-mss-pil"
+   "qcom,ipq8074-wcss-pil"
 - reg:
Usage: required
Value type: 
@@ -49,11 +50,15 @@ on the Qualcomm Hexagon core.
Usage: required
Value type: 
Definition: reference to the reset-controller for the modem sub-system
+   reference to the list of 3 reset-controllers for the
+   wcss sub-system
 
 - reset-names:
Usage: required
Value type: 
-   Definition: must be "mss_restart"
+   Definition: must be "mss_restart" for the modem sub-system
+   Definition: must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset"
+   for the wcss syb-system
 
 - cx-supply:
 - mss-supply:
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 8891a8e..99930a4 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -102,6 +102,7 @@ config QCOM_Q6V5_PIL
select MFD_SYSCON
select QCOM_RPROC_COMMON
select QCOM_SCM
+   select QCOM_MDT_LOADER
help
  Say y here to support the Qualcomm Peripherial Image Loader for the
  Hexagon V5 based remote processors.
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 19f453f..284fb12 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -129,6 +129,9 @@ struct q6v5 {
u32 halt_nc;
 
struct reset_control *mss_restart;
+   struct reset_control *wcss_aon_reset;
+   struct reset_control *wcss_reset;
+   struct reset_control *wcss_q6_reset;
 
struct qcom_smem_state *state;
unsigned stop_bit;
@@ -180,6 +183,7 @@ enum {
MSS_MSM8916,
MSS_MSM8974,
MSS_MSM8996,
+   WCSS_IPQ8074,
 };
 
 static int q6v5_regulator_init(struct device *dev, struct reg_info *regs,
@@ -354,6 +358,21 @@ static int q6v5_load(struct rproc *rproc, const struct 
firmware *fw)
return 0;
 }
 
+static int q6v5_wcss_load(struct rproc *rproc, const struct firmware *fw)
+{
+   struct q6v5 *qproc = rproc->priv;
+
+   return qcom_mdt_load_no_init(qproc->dev, fw, rproc->firmware,
+0, qproc->mba_region, qproc->mba_phys,
+qproc->mba_size);
+}
+
+static const struct rproc_fw_ops q6v5_wcss_fw_ops = {
+   .find_rsc_table = q6v5_find_rsc_table,
+   .load = q6v5_wcss_load,
+   .get_boot_addr = rproc_elf_get_boot_addr,
+};
+
 static const struct rproc_fw_ops q6v5_fw_ops = {
.find_rsc_table = q6v5_find_rsc_table,
.load = q6v5_load,
@@ -1055,6 +1074,26 @@ static int q6v5_init_clocks(struct device *dev, struct 
clk **clks,
return i;
 }
 
+static int q6v5_wcss_init_reset(struct q6v5 *qproc)
+{
+   qproc->wcss_aon_reset = devm_reset_control_get(qproc->dev,
+  "wcss_aon_reset");
+   if (IS_ERR(qproc->wcss_aon_reset))
+   return PTR_ERR(qproc->wcss_aon_reset);
+
+   qproc->wcss_reset = devm_reset_control_get(qproc->dev,
+  "wcss_reset");
+   if (IS_ERR(qproc->wcss_reset))
+   return PTR_ERR(qproc->wcss_reset);
+
+   qproc->wcss_q6_reset = devm_reset_control_get(qproc->dev,
+ "wcss_q6_reset");
+   if (IS_ERR(qproc->wcss_q6_reset))
+   return PTR_ERR(qproc->wcss_q6_reset);
+
+   return 0;
+}
+
 static int q6v5_init_reset(struct q6v5 *qproc)
 {
qproc->mss_restart = devm_reset_control_get(qproc->dev, NULL);
@@ -1113,6 +1152,9 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
return -EBUSY;
}
 
+   if (qproc->version == WCSS_IPQ8074)
+   return 0;
+
child = of_get_child_by_name(qproc->dev->of_node, "mpss");
node = of_parse_phandle(child, "memory-region", 0);
ret = of_address_to_resource(node, 0, );
@@ 

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

[Sricharan R]

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   | 70 +++--
 include/linux/soc/qcom/mdt_loader.h |  3 ++
 2 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index bd63df0..851f5d7 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -86,9 +86,9 @@ ssize_t qcom_mdt_get_size(const struct firmware *fw)
  *
  * Returns 0 on success, negative errno otherwise.
  */
-int qcom_mdt_load(struct device *dev, const struct firmware *fw,
- const char *firmware, int pas_id, void *mem_region,
- phys_addr_t mem_phys, size_t mem_size)
+static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
+  const char *firmware, int pas_id, void *mem_region,
+  phys_addr_t mem_phys, size_t mem_size, bool pas_init)
 {
const struct elf32_phdr *phdrs;
const struct elf32_phdr *phdr;
@@ -119,10 +119,12 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
if (!fw_name)
return -ENOMEM;
 
-   ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
-   if (ret) {
-   dev_err(dev, "invalid firmware metadata\n");
-   goto out;
+   if (pas_init) {
+   ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
+   if (ret) {
+   dev_err(dev, "invalid firmware metadata\n");
+   goto out;
+   }
}
 
for (i = 0; i < ehdr->e_phnum; i++) {
@@ -142,10 +144,13 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
}
 
if (relocate) {
-   ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - 
min_addr);
-   if (ret) {
-   dev_err(dev, "unable to setup relocation\n");
-   goto out;
+   if (pas_init) {
+   ret = qcom_scm_pas_mem_setup(pas_id, mem_phys,
+max_addr - min_addr);
+   if (ret) {
+   dev_err(dev, "unable to setup relocation\n");
+   goto out;
+   }
}
 
/*
@@ -198,7 +203,50 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
 
return ret;
 }
+
+/**
+ * qcom_mdt_load() - sets up the secure memory for the firmware and
+loads the firmware
+ * @dev:   device handle to associate resources with
+ * @fw:firmware object for the mdt file
+ * @firmware:  name of the firmware, for construction of segment file names
+ * @pas_id:PAS identifier
+ * @mem_region:allocated memory region to load firmware into
+ * @mem_phys:  physical address of allocated memory region
+ * @mem_size:  size of the allocated memory region
+ *
+ * Returns 0 on success, negative errno otherwise.
+ */
+int qcom_mdt_load(struct device *dev, const struct firmware *fw,
+ const char *firmware, int pas_id, void *mem_region,
+ phys_addr_t mem_phys, size_t mem_size)
+{
+   return __qcom_mdt_load(dev, fw, firmware, pas_id, mem_region, mem_phys,
+  mem_size, true);
+}
 EXPORT_SYMBOL_GPL(qcom_mdt_load);
 
+/**
+ * qcom_mdt_load_no_init() - load the firmware which header is loaded as fw
+ * @dev:   device handle to associate resources with
+ * @fw:firmware object for the mdt file
+ * @firmware:  name of the firmware, for construction of segment file names
+ * @pas_id:PAS identifier
+ * @mem_region:allocated memory region to load firmware into
+ * @mem_phys:  physical address of allocated memory region
+ * @mem_size:  size of the allocated memory region
+ *
+ * Returns 0 on success, negative errno otherwise.
+ */
+int qcom_mdt_load_no_init(struct device *dev, const struct firmware *fw,
+ const char *firmware, int pas_id,
+ void *mem_region, phys_addr_t mem_phys,
+ size_t mem_size)
+{
+   return __qcom_mdt_load(dev, fw, firmware, pas_id, mem_region, mem_phys,
+  mem_size, false);
+}
+EXPORT_SYMBOL_GPL(qcom_mdt_load_no_init);
+
 MODULE_DESCRIPTION("Firmware parser for Qualcomm MDT format");
 MODULE_LICENSE("GPL v2");
diff --git a/include/linux/soc/qcom/mdt_loader.h 
b/include/linux/soc/qcom/mdt_loader.h
index f423001..228053a 100644
--- a/include/linux/soc/qcom/mdt_loader.h
+++ b/include/linux/soc/qcom/mdt_loader.h
@@ -15,4 +15,7 @@ int qcom_mdt_load(struct device *dev, 

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

[Sricharan R]

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 
---
 .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |  7 ++-
 drivers/remoteproc/Kconfig |  1 +
 drivers/remoteproc/qcom_q6v5_pil.c | 53 +-
 3 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index 87a8e51..a0a9ad3 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -12,6 +12,7 @@ on the Qualcomm Hexagon core.
"qcom,msm8974-mss-pil"
 
"qcom,msm8996-mss-pil"
+   "qcom,ipq8074-wcss-pil"
 - reg:
Usage: required
Value type: 
@@ -49,11 +50,15 @@ on the Qualcomm Hexagon core.
Usage: required
Value type: 
Definition: reference to the reset-controller for the modem sub-system
+   reference to the list of 3 reset-controllers for the
+   wcss sub-system
 
 - reset-names:
Usage: required
Value type: 
-   Definition: must be "mss_restart"
+   Definition: must be "mss_restart" for the modem sub-system
+   Definition: must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset"
+   for the wcss syb-system
 
 - cx-supply:
 - mss-supply:
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 8891a8e..99930a4 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -102,6 +102,7 @@ config QCOM_Q6V5_PIL
select MFD_SYSCON
select QCOM_RPROC_COMMON
select QCOM_SCM
+   select QCOM_MDT_LOADER
help
  Say y here to support the Qualcomm Peripherial Image Loader for the
  Hexagon V5 based remote processors.
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 19f453f..284fb12 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -129,6 +129,9 @@ struct q6v5 {
u32 halt_nc;
 
struct reset_control *mss_restart;
+   struct reset_control *wcss_aon_reset;
+   struct reset_control *wcss_reset;
+   struct reset_control *wcss_q6_reset;
 
struct qcom_smem_state *state;
unsigned stop_bit;
@@ -180,6 +183,7 @@ enum {
MSS_MSM8916,
MSS_MSM8974,
MSS_MSM8996,
+   WCSS_IPQ8074,
 };
 
 static int q6v5_regulator_init(struct device *dev, struct reg_info *regs,
@@ -354,6 +358,21 @@ static int q6v5_load(struct rproc *rproc, const struct 
firmware *fw)
return 0;
 }
 
+static int q6v5_wcss_load(struct rproc *rproc, const struct firmware *fw)
+{
+   struct q6v5 *qproc = rproc->priv;
+
+   return qcom_mdt_load_no_init(qproc->dev, fw, rproc->firmware,
+0, qproc->mba_region, qproc->mba_phys,
+qproc->mba_size);
+}
+
+static const struct rproc_fw_ops q6v5_wcss_fw_ops = {
+   .find_rsc_table = q6v5_find_rsc_table,
+   .load = q6v5_wcss_load,
+   .get_boot_addr = rproc_elf_get_boot_addr,
+};
+
 static const struct rproc_fw_ops q6v5_fw_ops = {
.find_rsc_table = q6v5_find_rsc_table,
.load = q6v5_load,
@@ -1055,6 +1074,26 @@ static int q6v5_init_clocks(struct device *dev, struct 
clk **clks,
return i;
 }
 
+static int q6v5_wcss_init_reset(struct q6v5 *qproc)
+{
+   qproc->wcss_aon_reset = devm_reset_control_get(qproc->dev,
+  "wcss_aon_reset");
+   if (IS_ERR(qproc->wcss_aon_reset))
+   return PTR_ERR(qproc->wcss_aon_reset);
+
+   qproc->wcss_reset = devm_reset_control_get(qproc->dev,
+  "wcss_reset");
+   if (IS_ERR(qproc->wcss_reset))
+   return PTR_ERR(qproc->wcss_reset);
+
+   qproc->wcss_q6_reset = devm_reset_control_get(qproc->dev,
+ "wcss_q6_reset");
+   if (IS_ERR(qproc->wcss_q6_reset))
+   return PTR_ERR(qproc->wcss_q6_reset);
+
+   return 0;
+}
+
 static int q6v5_init_reset(struct q6v5 *qproc)
 {
qproc->mss_restart = devm_reset_control_get(qproc->dev, NULL);
@@ -1113,6 +1152,9 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
return -EBUSY;
}
 
+   if (qproc->version == WCSS_IPQ8074)
+   return 0;
+
child = of_get_child_by_name(qproc->dev->of_node, "mpss");
node = of_parse_phandle(child, "memory-region", 0);
ret = of_address_to_resource(node, 0, );
@@ -1156,6 +1198,7 @@ static int 

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

[Sricharan R]

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 a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 284fb12..df8f6f0 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -104,6 +104,17 @@
 #define QDSP6SS_XO_CBCR0x0038
 #define QDSP6SS_ACC_OVERRIDE_VAL   0x20
 
+/* QDSP6v5-WCSS config/status registers */
+#define TCSR_GLOBAL_CFG0   0x0
+#define TCSR_GLOBAL_CFG1   0x4
+#define SSCAON_CONFIG  0x8
+#define SSCAON_STATUS  0xc
+#define QDSP6SS_BHS_STATUS 0x78
+#define QDSP6SS_RST_EVB0x10
+
+#define BHS_EN_REST_ACKBIT(0)
+#define SSCAON_ENABLE  BIT(13)
+
 struct reg_info {
struct regulator *reg;
int uV;
@@ -770,6 +781,61 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
return ret < 0 ? ret : 0;
 }
 
+static int q6v5_wcss_start(struct rproc *rproc)
+{
+   struct q6v5 *qproc = rproc->priv;
+   int ret = 0;
+
+   ret = q6v5_clk_enable(qproc->dev, qproc->active_clks,
+ qproc->active_clk_count);
+   if (ret) {
+   dev_err(qproc->dev, "failed to enable clocks\n");
+   return ret;
+   }
+
+   /* Release Q6 and WCSS reset */
+   ret = reset_control_deassert(qproc->wcss_reset);
+   if (ret)
+   dev_err(qproc->dev, "wcss_reset failed\n");
+
+   ret = reset_control_deassert(qproc->wcss_q6_reset);
+   if (ret)
+   dev_err(qproc->dev, "wcss_q6_reset failed\n");
+
+   /* Lithium configuration - clock gating and bus arbitration */
+   ret = regmap_update_bits(qproc->halt_map,
+qproc->halt_nc + TCSR_GLOBAL_CFG0,
+0x1F, 0x14);
+   if (ret)
+   return ret;
+
+   ret = regmap_update_bits(qproc->halt_map,
+qproc->halt_nc + TCSR_GLOBAL_CFG1,
+1, 0);
+   if (ret)
+   return ret;
+
+   /* Write bootaddr to EVB so that Q6WCSS will jump there after reset */
+   writel(rproc->bootaddr >> 4, qproc->reg_base + QDSP6SS_RST_EVB);
+
+   ret = q6v5_reset(qproc);
+   if (ret)
+   return ret;
+
+   q6v5_reset_rest(qproc);
+
+   ret = wait_for_completion_timeout(>start_done,
+ msecs_to_jiffies(5000));
+   if (ret == 0) {
+   dev_err(qproc->dev, "start timed out\n");
+   return -ETIMEDOUT;
+   }
+
+   qproc->running = true;
+
+   return 0;
+}
+
 static int q6v5_start(struct rproc *rproc)
 {
struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
@@ -893,6 +959,146 @@ static int q6v5_start(struct rproc *rproc)
return ret;
 }
 
+static int q6v5_wcss_powerdown(struct q6v5 *qproc)
+{
+   unsigned int val = 0;
+   int ret;
+
+   /* 1 - Assert WCSS/Q6 HALTREQ */
+   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
+
+   /* 2 - Enable WCSSAON_CONFIG */
+   val = readl(qproc->rmb_base + SSCAON_CONFIG);
+   val |= SSCAON_ENABLE;
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 3 - Set SSCAON_CONFIG */
+   val |= BIT(15);
+   val &= ~BIT(16);
+   val &= ~BIT(17);
+   val &= ~BIT(18);
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 4 - SSCAON_CONFIG 1 */
+   val |= BIT(1);
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 5 - wait for SSCAON_STATUS */
+   ret = readl_poll_timeout(qproc->rmb_base + SSCAON_STATUS,
+val, (val & 0x) == 0x400, 1000,
+HALT_CHECK_MAX_LOOPS);
+   if (ret) {
+   dev_err(qproc->dev,
+   "can't get SSCAON_STATUS rc:%d)\n", ret);
+   }
+
+   /* 6 - De-assert WCSS_AON reset */
+   reset_control_assert(qproc->wcss_aon_reset);
+
+   /* 7 - Disable WCSSAON_CONFIG 13 */
+   val = readl(qproc->rmb_base + SSCAON_CONFIG);
+   val &= ~SSCAON_ENABLE;
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 8 - De-assert WCSS/Q6 HALTREQ */
+   reset_control_assert(qproc->wcss_reset);
+
+   return ret;
+}
+
+static int q6v5_q6_powerdown(struct q6v5 *qproc)
+{
+   int i = 0, ret;
+   unsigned int val = 0;
+
+   /* 1 - Halt Q6 bus interface */
+   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
+
+   /* 2 - Disable Q6 Core clock */
+   val = readl(qproc->reg_base + QDSP6SS_GFMUX_CTL_REG);
+   val &= ~Q6SS_CLK_ENABLE;
+   writel(val, qproc->reg_base + QDSP6SS_GFMUX_CTL_REG);
+
+   /* 3 - Clamp 

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

[Sricharan R]

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 a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 284fb12..df8f6f0 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -104,6 +104,17 @@
 #define QDSP6SS_XO_CBCR0x0038
 #define QDSP6SS_ACC_OVERRIDE_VAL   0x20
 
+/* QDSP6v5-WCSS config/status registers */
+#define TCSR_GLOBAL_CFG0   0x0
+#define TCSR_GLOBAL_CFG1   0x4
+#define SSCAON_CONFIG  0x8
+#define SSCAON_STATUS  0xc
+#define QDSP6SS_BHS_STATUS 0x78
+#define QDSP6SS_RST_EVB0x10
+
+#define BHS_EN_REST_ACKBIT(0)
+#define SSCAON_ENABLE  BIT(13)
+
 struct reg_info {
struct regulator *reg;
int uV;
@@ -770,6 +781,61 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
return ret < 0 ? ret : 0;
 }
 
+static int q6v5_wcss_start(struct rproc *rproc)
+{
+   struct q6v5 *qproc = rproc->priv;
+   int ret = 0;
+
+   ret = q6v5_clk_enable(qproc->dev, qproc->active_clks,
+ qproc->active_clk_count);
+   if (ret) {
+   dev_err(qproc->dev, "failed to enable clocks\n");
+   return ret;
+   }
+
+   /* Release Q6 and WCSS reset */
+   ret = reset_control_deassert(qproc->wcss_reset);
+   if (ret)
+   dev_err(qproc->dev, "wcss_reset failed\n");
+
+   ret = reset_control_deassert(qproc->wcss_q6_reset);
+   if (ret)
+   dev_err(qproc->dev, "wcss_q6_reset failed\n");
+
+   /* Lithium configuration - clock gating and bus arbitration */
+   ret = regmap_update_bits(qproc->halt_map,
+qproc->halt_nc + TCSR_GLOBAL_CFG0,
+0x1F, 0x14);
+   if (ret)
+   return ret;
+
+   ret = regmap_update_bits(qproc->halt_map,
+qproc->halt_nc + TCSR_GLOBAL_CFG1,
+1, 0);
+   if (ret)
+   return ret;
+
+   /* Write bootaddr to EVB so that Q6WCSS will jump there after reset */
+   writel(rproc->bootaddr >> 4, qproc->reg_base + QDSP6SS_RST_EVB);
+
+   ret = q6v5_reset(qproc);
+   if (ret)
+   return ret;
+
+   q6v5_reset_rest(qproc);
+
+   ret = wait_for_completion_timeout(>start_done,
+ msecs_to_jiffies(5000));
+   if (ret == 0) {
+   dev_err(qproc->dev, "start timed out\n");
+   return -ETIMEDOUT;
+   }
+
+   qproc->running = true;
+
+   return 0;
+}
+
 static int q6v5_start(struct rproc *rproc)
 {
struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
@@ -893,6 +959,146 @@ static int q6v5_start(struct rproc *rproc)
return ret;
 }
 
+static int q6v5_wcss_powerdown(struct q6v5 *qproc)
+{
+   unsigned int val = 0;
+   int ret;
+
+   /* 1 - Assert WCSS/Q6 HALTREQ */
+   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
+
+   /* 2 - Enable WCSSAON_CONFIG */
+   val = readl(qproc->rmb_base + SSCAON_CONFIG);
+   val |= SSCAON_ENABLE;
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 3 - Set SSCAON_CONFIG */
+   val |= BIT(15);
+   val &= ~BIT(16);
+   val &= ~BIT(17);
+   val &= ~BIT(18);
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 4 - SSCAON_CONFIG 1 */
+   val |= BIT(1);
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 5 - wait for SSCAON_STATUS */
+   ret = readl_poll_timeout(qproc->rmb_base + SSCAON_STATUS,
+val, (val & 0x) == 0x400, 1000,
+HALT_CHECK_MAX_LOOPS);
+   if (ret) {
+   dev_err(qproc->dev,
+   "can't get SSCAON_STATUS rc:%d)\n", ret);
+   }
+
+   /* 6 - De-assert WCSS_AON reset */
+   reset_control_assert(qproc->wcss_aon_reset);
+
+   /* 7 - Disable WCSSAON_CONFIG 13 */
+   val = readl(qproc->rmb_base + SSCAON_CONFIG);
+   val &= ~SSCAON_ENABLE;
+   writel(val, qproc->rmb_base + SSCAON_CONFIG);
+
+   /* 8 - De-assert WCSS/Q6 HALTREQ */
+   reset_control_assert(qproc->wcss_reset);
+
+   return ret;
+}
+
+static int q6v5_q6_powerdown(struct q6v5 *qproc)
+{
+   int i = 0, ret;
+   unsigned int val = 0;
+
+   /* 1 - Halt Q6 bus interface */
+   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
+
+   /* 2 - Disable Q6 Core clock */
+   val = readl(qproc->reg_base + QDSP6SS_GFMUX_CTL_REG);
+   val &= ~Q6SS_CLK_ENABLE;
+   writel(val, qproc->reg_base + QDSP6SS_GFMUX_CTL_REG);
+
+   /* 3 - Clamp I/O */
+   val = 

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

[Sricharan R]

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 changed, 91 insertions(+), 75 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 5b5811d..19f453f 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -405,75 +405,107 @@ static int q6v5_rmb_mba_wait(struct q6v5 *qproc, u32 
status, int ms)
return val;
 }
 
-static int q6v5proc_reset(struct q6v5 *qproc)
+static int q6v5_reset(struct q6v5 *qproc)
 {
-   u32 val;
-   int ret;
-   int i;
+   u32 ret;
+   int val, i;
 
+   /* Assert resets, stop core */
+   val = readl(qproc->reg_base + QDSP6SS_RESET_REG);
+   val |= Q6SS_CORE_ARES | Q6SS_BUS_ARES_ENABLE | Q6SS_STOP_CORE;
+   writel(val, qproc->reg_base + QDSP6SS_RESET_REG);
 
-   if (qproc->version == MSS_MSM8996) {
-   /* Override the ACC value if required */
-   writel(QDSP6SS_ACC_OVERRIDE_VAL,
-  qproc->reg_base + QDSP6SS_STRAP_ACC);
+   /* BHS require xo cbcr to be enabled */
+   val = readl(qproc->reg_base + QDSP6SS_XO_CBCR);
+   val |= 0x1;
+   writel(val, qproc->reg_base + QDSP6SS_XO_CBCR);
 
-   /* Assert resets, stop core */
-   val = readl(qproc->reg_base + QDSP6SS_RESET_REG);
-   val |= Q6SS_CORE_ARES | Q6SS_BUS_ARES_ENABLE | Q6SS_STOP_CORE;
-   writel(val, qproc->reg_base + QDSP6SS_RESET_REG);
+   /* Read CLKOFF bit to go low indicating CLK is enabled */
+   ret = readl_poll_timeout(qproc->reg_base + QDSP6SS_XO_CBCR,
+val, !(val & BIT(31)), 1,
+HALT_CHECK_MAX_LOOPS);
+   if (ret) {
+   dev_err(qproc->dev,
+   "xo cbcr enabling timed out (rc:%d)\n", ret);
+   return ret;
+   }
+   /* Enable power block headswitch and wait for it to stabilize */
+   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val |= QDSP6v56_BHS_ON;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val |= readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   udelay(1);
 
-   /* BHS require xo cbcr to be enabled */
-   val = readl(qproc->reg_base + QDSP6SS_XO_CBCR);
-   val |= 0x1;
-   writel(val, qproc->reg_base + QDSP6SS_XO_CBCR);
+   /* Put LDO in bypass mode */
+   val |= QDSP6v56_LDO_BYP;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
 
-   /* Read CLKOFF bit to go low indicating CLK is enabled */
-   ret = readl_poll_timeout(qproc->reg_base + QDSP6SS_XO_CBCR,
-val, !(val & BIT(31)), 1,
-HALT_CHECK_MAX_LOOPS);
-   if (ret) {
-   dev_err(qproc->dev,
-   "xo cbcr enabling timed out (rc:%d)\n", ret);
-   return ret;
-   }
-   /* Enable power block headswitch and wait for it to stabilize */
-   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
-   val |= QDSP6v56_BHS_ON;
-   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
-   val |= readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   /* Deassert QDSP6 compiler memory clamp */
+   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val &= ~QDSP6v56_CLAMP_QMC_MEM;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+
+   /* Deassert memory peripheral sleep and L2 memory standby */
+   val |= Q6SS_L2DATA_STBY_N | Q6SS_SLP_RET_N;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+
+   /* Turn on L1, L2, ETB and JU memories 1 at a time */
+   val = readl(qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
+   for (i = 19; i >= 0; i--) {
+   val |= BIT(i);
+   writel(val, qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
+   /*
+* Read back value to ensure the write is done then
+* wait for 1us for both memory peripheral and data
+* array to turn on.
+*/
+   val |= readl(qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
udelay(1);
+   }
+   /* Remove word line clamp */
+   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val &= ~QDSP6v56_CLAMP_WL;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
 
-   /* Put LDO in bypass mode */
-   val |= QDSP6v56_LDO_BYP;
-   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   return 0;
+}
 
-   /* Deassert QDSP6 compiler 

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

[Sricharan R]

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 changed, 91 insertions(+), 75 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 5b5811d..19f453f 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -405,75 +405,107 @@ static int q6v5_rmb_mba_wait(struct q6v5 *qproc, u32 
status, int ms)
return val;
 }
 
-static int q6v5proc_reset(struct q6v5 *qproc)
+static int q6v5_reset(struct q6v5 *qproc)
 {
-   u32 val;
-   int ret;
-   int i;
+   u32 ret;
+   int val, i;
 
+   /* Assert resets, stop core */
+   val = readl(qproc->reg_base + QDSP6SS_RESET_REG);
+   val |= Q6SS_CORE_ARES | Q6SS_BUS_ARES_ENABLE | Q6SS_STOP_CORE;
+   writel(val, qproc->reg_base + QDSP6SS_RESET_REG);
 
-   if (qproc->version == MSS_MSM8996) {
-   /* Override the ACC value if required */
-   writel(QDSP6SS_ACC_OVERRIDE_VAL,
-  qproc->reg_base + QDSP6SS_STRAP_ACC);
+   /* BHS require xo cbcr to be enabled */
+   val = readl(qproc->reg_base + QDSP6SS_XO_CBCR);
+   val |= 0x1;
+   writel(val, qproc->reg_base + QDSP6SS_XO_CBCR);
 
-   /* Assert resets, stop core */
-   val = readl(qproc->reg_base + QDSP6SS_RESET_REG);
-   val |= Q6SS_CORE_ARES | Q6SS_BUS_ARES_ENABLE | Q6SS_STOP_CORE;
-   writel(val, qproc->reg_base + QDSP6SS_RESET_REG);
+   /* Read CLKOFF bit to go low indicating CLK is enabled */
+   ret = readl_poll_timeout(qproc->reg_base + QDSP6SS_XO_CBCR,
+val, !(val & BIT(31)), 1,
+HALT_CHECK_MAX_LOOPS);
+   if (ret) {
+   dev_err(qproc->dev,
+   "xo cbcr enabling timed out (rc:%d)\n", ret);
+   return ret;
+   }
+   /* Enable power block headswitch and wait for it to stabilize */
+   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val |= QDSP6v56_BHS_ON;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val |= readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   udelay(1);
 
-   /* BHS require xo cbcr to be enabled */
-   val = readl(qproc->reg_base + QDSP6SS_XO_CBCR);
-   val |= 0x1;
-   writel(val, qproc->reg_base + QDSP6SS_XO_CBCR);
+   /* Put LDO in bypass mode */
+   val |= QDSP6v56_LDO_BYP;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
 
-   /* Read CLKOFF bit to go low indicating CLK is enabled */
-   ret = readl_poll_timeout(qproc->reg_base + QDSP6SS_XO_CBCR,
-val, !(val & BIT(31)), 1,
-HALT_CHECK_MAX_LOOPS);
-   if (ret) {
-   dev_err(qproc->dev,
-   "xo cbcr enabling timed out (rc:%d)\n", ret);
-   return ret;
-   }
-   /* Enable power block headswitch and wait for it to stabilize */
-   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
-   val |= QDSP6v56_BHS_ON;
-   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
-   val |= readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   /* Deassert QDSP6 compiler memory clamp */
+   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val &= ~QDSP6v56_CLAMP_QMC_MEM;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+
+   /* Deassert memory peripheral sleep and L2 memory standby */
+   val |= Q6SS_L2DATA_STBY_N | Q6SS_SLP_RET_N;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+
+   /* Turn on L1, L2, ETB and JU memories 1 at a time */
+   val = readl(qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
+   for (i = 19; i >= 0; i--) {
+   val |= BIT(i);
+   writel(val, qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
+   /*
+* Read back value to ensure the write is done then
+* wait for 1us for both memory peripheral and data
+* array to turn on.
+*/
+   val |= readl(qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
udelay(1);
+   }
+   /* Remove word line clamp */
+   val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   val &= ~QDSP6v56_CLAMP_WL;
+   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
 
-   /* Put LDO in bypass mode */
-   val |= QDSP6v56_LDO_BYP;
-   writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+   return 0;
+}
 
-   /* Deassert QDSP6 compiler memory clamp */
-   

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

[Sricharan R]

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 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 808ee45..5b5811d 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -116,16 +116,6 @@ struct qcom_mss_reg_res {
int uA;
 };
 
-struct rproc_hexagon_res {
-   const char *hexagon_mba_image;
-   struct qcom_mss_reg_res *proxy_supply;
-   struct qcom_mss_reg_res *active_supply;
-   char **proxy_clk_names;
-   char **active_clk_names;
-   int version;
-   bool need_mem_protection;
-};
-
 struct q6v5 {
struct device *dev;
struct rproc *rproc;
@@ -173,6 +163,19 @@ struct q6v5 {
int version;
 };
 
+struct rproc_hexagon_res {
+   const char *hexagon_mba_image;
+   struct qcom_mss_reg_res *proxy_supply;
+   struct qcom_mss_reg_res *active_supply;
+   char **proxy_clk_names;
+   char **active_clk_names;
+   int version;
+   bool need_mem_protection;
+   int (*init_reset)(struct q6v5 *qproc);
+   const struct rproc_fw_ops *fw_ops;
+   const struct rproc_ops *ops;
+};
+
 enum {
MSS_MSM8916,
MSS_MSM8974,
@@ -1125,14 +1128,14 @@ static int q6v5_probe(struct platform_device *pdev)
if (!desc)
return -EINVAL;
 
-   rproc = rproc_alloc(>dev, pdev->name, _ops,
+   rproc = rproc_alloc(>dev, pdev->name, desc->ops,
desc->hexagon_mba_image, sizeof(*qproc));
if (!rproc) {
dev_err(>dev, "failed to allocate rproc\n");
return -ENOMEM;
}
 
-   rproc->fw_ops = _fw_ops;
+   rproc->fw_ops = desc->fw_ops;
 
qproc = (struct q6v5 *)rproc->priv;
qproc->dev = >dev;
@@ -1182,7 +1185,7 @@ static int q6v5_probe(struct platform_device *pdev)
}
qproc->active_reg_count = ret;
 
-   ret = q6v5_init_reset(qproc);
+   ret = desc->init_reset(qproc);
if (ret)
goto free_rproc;
 
@@ -1253,6 +1256,9 @@ static int q6v5_remove(struct platform_device *pdev)
},
.need_mem_protection = true,
.version = MSS_MSM8996,
+   .init_reset = q6v5_init_reset,
+   .fw_ops = _fw_ops,
+   .ops = _ops,
 };
 
 static const struct rproc_hexagon_res msm8916_mss = {
@@ -1284,6 +1290,9 @@ static int q6v5_remove(struct platform_device *pdev)
},
.need_mem_protection = false,
.version = MSS_MSM8916,
+   .init_reset = q6v5_init_reset,
+   .fw_ops = _fw_ops,
+   .ops = _ops,
 };
 
 static const struct rproc_hexagon_res msm8974_mss = {
@@ -1323,6 +1332,9 @@ static int q6v5_remove(struct platform_device *pdev)
},
.need_mem_protection = false,
.version = MSS_MSM8974,
+   .init_reset = q6v5_init_reset,
+   .fw_ops = _fw_ops,
+   .ops = _ops,
 };
 
 static const struct of_device_id q6v5_of_match[] = {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

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

[Sricharan R]

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 firmware like the Q6v5 core in IPQ8074. The second
patch exports the elf header's get_boot_addr helper to reuse it.
The next couple of patches arranges the code in the original q6v5-mpss
rproc to add q6v5-wcss later. The last couple of patches add the relevant
bits for the q6v5-wcss core.

This is done on top of Avaneesh's msm8996 rproc support [1]

[1] https://lkml.org/lkml/2017/7/21/217

V3:
Rebased on top of latest remoteproc next

V2:
Last time introduced this a new rproc driver, but there is lot
of code that can be shared if it is added to the q6v5-mpss pil
driver.

Sricharan R (6):
  remoteproc: qcom: mdt_loader: Make the firmware authentication
optional
  remoteproc: Export rproc_elf_get_boot_addr
  remoteproc: qcom: Push reset ops, fw ops, rproc ops in to of_match
data
  remoteproc: qcom: Split the head and tail of the  q6v5-pil rproc
start function
  remoteproc: qcom: Add support for q6v5-wcss pil
  remoteproc: qcom: Add q6v5-wcss rproc ops

 .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |   7 +-
 drivers/remoteproc/Kconfig |   1 +
 drivers/remoteproc/qcom_q6v5_pil.c | 469 +
 drivers/remoteproc/remoteproc_elf_loader.c |   2 +-
 drivers/remoteproc/remoteproc_internal.h   |   3 +
 drivers/soc/qcom/mdt_loader.c  |  70 ++-
 include/linux/soc/qcom/mdt_loader.h|   3 +
 7 files changed, 453 insertions(+), 102 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v3 2/6] remoteproc: Export rproc_elf_get_boot_addr

[Sricharan R]

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 
---
 drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
 drivers/remoteproc/remoteproc_internal.h   | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_elf_loader.c 
b/drivers/remoteproc/remoteproc_elf_loader.c
index c523983..f6d07d9 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -110,13 +110,13 @@
  * Note that the boot address is not a configurable property of all remote
  * processors. Some will always boot at a specific hard-coded address.
  */
-static
 u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
 {
struct elf32_hdr *ehdr  = (struct elf32_hdr *)fw->data;
 
return ehdr->e_entry;
 }
+EXPORT_SYMBOL(rproc_elf_get_boot_addr);
 
 /**
  * rproc_elf_load_segments() - load firmware segments to memory
diff --git a/drivers/remoteproc/remoteproc_internal.h 
b/drivers/remoteproc/remoteproc_internal.h
index 1e9e5b3..b898510 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -125,4 +125,7 @@ struct resource_table *rproc_find_loaded_rsc_table(struct 
rproc *rproc,
 
 extern const struct rproc_fw_ops rproc_elf_fw_ops;
 
+/* from remoteproc_elf_loader.c */
+u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
+
 #endif /* REMOTEPROC_INTERNAL_H */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v3 2/6] remoteproc: Export rproc_elf_get_boot_addr

[Sricharan R]

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 
---
 drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
 drivers/remoteproc/remoteproc_internal.h   | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_elf_loader.c 
b/drivers/remoteproc/remoteproc_elf_loader.c
index c523983..f6d07d9 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -110,13 +110,13 @@
  * Note that the boot address is not a configurable property of all remote
  * processors. Some will always boot at a specific hard-coded address.
  */
-static
 u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
 {
struct elf32_hdr *ehdr  = (struct elf32_hdr *)fw->data;
 
return ehdr->e_entry;
 }
+EXPORT_SYMBOL(rproc_elf_get_boot_addr);
 
 /**
  * rproc_elf_load_segments() - load firmware segments to memory
diff --git a/drivers/remoteproc/remoteproc_internal.h 
b/drivers/remoteproc/remoteproc_internal.h
index 1e9e5b3..b898510 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -125,4 +125,7 @@ struct resource_table *rproc_find_loaded_rsc_table(struct 
rproc *rproc,
 
 extern const struct rproc_fw_ops rproc_elf_fw_ops;
 
+/* from remoteproc_elf_loader.c */
+u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
+
 #endif /* REMOTEPROC_INTERNAL_H */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

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

[Sricharan R]

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 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 808ee45..5b5811d 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -116,16 +116,6 @@ struct qcom_mss_reg_res {
int uA;
 };
 
-struct rproc_hexagon_res {
-   const char *hexagon_mba_image;
-   struct qcom_mss_reg_res *proxy_supply;
-   struct qcom_mss_reg_res *active_supply;
-   char **proxy_clk_names;
-   char **active_clk_names;
-   int version;
-   bool need_mem_protection;
-};
-
 struct q6v5 {
struct device *dev;
struct rproc *rproc;
@@ -173,6 +163,19 @@ struct q6v5 {
int version;
 };
 
+struct rproc_hexagon_res {
+   const char *hexagon_mba_image;
+   struct qcom_mss_reg_res *proxy_supply;
+   struct qcom_mss_reg_res *active_supply;
+   char **proxy_clk_names;
+   char **active_clk_names;
+   int version;
+   bool need_mem_protection;
+   int (*init_reset)(struct q6v5 *qproc);
+   const struct rproc_fw_ops *fw_ops;
+   const struct rproc_ops *ops;
+};
+
 enum {
MSS_MSM8916,
MSS_MSM8974,
@@ -1125,14 +1128,14 @@ static int q6v5_probe(struct platform_device *pdev)
if (!desc)
return -EINVAL;
 
-   rproc = rproc_alloc(>dev, pdev->name, _ops,
+   rproc = rproc_alloc(>dev, pdev->name, desc->ops,
desc->hexagon_mba_image, sizeof(*qproc));
if (!rproc) {
dev_err(>dev, "failed to allocate rproc\n");
return -ENOMEM;
}
 
-   rproc->fw_ops = _fw_ops;
+   rproc->fw_ops = desc->fw_ops;
 
qproc = (struct q6v5 *)rproc->priv;
qproc->dev = >dev;
@@ -1182,7 +1185,7 @@ static int q6v5_probe(struct platform_device *pdev)
}
qproc->active_reg_count = ret;
 
-   ret = q6v5_init_reset(qproc);
+   ret = desc->init_reset(qproc);
if (ret)
goto free_rproc;
 
@@ -1253,6 +1256,9 @@ static int q6v5_remove(struct platform_device *pdev)
},
.need_mem_protection = true,
.version = MSS_MSM8996,
+   .init_reset = q6v5_init_reset,
+   .fw_ops = _fw_ops,
+   .ops = _ops,
 };
 
 static const struct rproc_hexagon_res msm8916_mss = {
@@ -1284,6 +1290,9 @@ static int q6v5_remove(struct platform_device *pdev)
},
.need_mem_protection = false,
.version = MSS_MSM8916,
+   .init_reset = q6v5_init_reset,
+   .fw_ops = _fw_ops,
+   .ops = _ops,
 };
 
 static const struct rproc_hexagon_res msm8974_mss = {
@@ -1323,6 +1332,9 @@ static int q6v5_remove(struct platform_device *pdev)
},
.need_mem_protection = false,
.version = MSS_MSM8974,
+   .init_reset = q6v5_init_reset,
+   .fw_ops = _fw_ops,
+   .ops = _ops,
 };
 
 static const struct of_device_id q6v5_of_match[] = {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

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

[Sricharan R]

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 firmware like the Q6v5 core in IPQ8074. The second
patch exports the elf header's get_boot_addr helper to reuse it.
The next couple of patches arranges the code in the original q6v5-mpss
rproc to add q6v5-wcss later. The last couple of patches add the relevant
bits for the q6v5-wcss core.

This is done on top of Avaneesh's msm8996 rproc support [1]

[1] https://lkml.org/lkml/2017/7/21/217

V3:
Rebased on top of latest remoteproc next

V2:
Last time introduced this a new rproc driver, but there is lot
of code that can be shared if it is added to the q6v5-mpss pil
driver.

Sricharan R (6):
  remoteproc: qcom: mdt_loader: Make the firmware authentication
optional
  remoteproc: Export rproc_elf_get_boot_addr
  remoteproc: qcom: Push reset ops, fw ops, rproc ops in to of_match
data
  remoteproc: qcom: Split the head and tail of the  q6v5-pil rproc
start function
  remoteproc: qcom: Add support for q6v5-wcss pil
  remoteproc: qcom: Add q6v5-wcss rproc ops

 .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |   7 +-
 drivers/remoteproc/Kconfig |   1 +
 drivers/remoteproc/qcom_q6v5_pil.c | 469 +
 drivers/remoteproc/remoteproc_elf_loader.c |   2 +-
 drivers/remoteproc/remoteproc_internal.h   |   3 +
 drivers/soc/qcom/mdt_loader.c  |  70 ++-
 include/linux/soc/qcom/mdt_loader.h|   3 +
 7 files changed, 453 insertions(+), 102 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [GIT] Networking

[Kalle Valo]

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 fixing in that way, but
> certainly that is not how I would handle this.
>
> It's easy to validate this fix, it's extremely unlikely to cause
> a regression, and fixes a problem someone actually was able to
> trigger.
>
> Deferring to -next only has the side effect of making people wait
> longer for the fix.

Yeah, you are right there. I did actually ponder which I tree should
commit it back in July but due to various reasons decided differently.

-- 
Kalle Valo

Re: [GIT] Networking

[Kalle Valo]

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 fixing in that way, but
> certainly that is not how I would handle this.
>
> It's easy to validate this fix, it's extremely unlikely to cause
> a regression, and fixes a problem someone actually was able to
> trigger.
>
> Deferring to -next only has the side effect of making people wait
> longer for the fix.

Yeah, you are right there. I did actually ponder which I tree should
commit it back in July but due to various reasons decided differently.

-- 
Kalle Valo

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

[Oza Pawandeep]

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 PCI hotplug is as follows:
PCI present lines are input to GPIOs depending on the type of
connector (x2, x4, x8).

GPIO array needs to be present if hotplug is supported.
HW implementation is SOC/Board specific, and also it depends on how
add-in card is designed
(e.g. how many present pins are implemented).

If x8 card is connected, then it might be possible that all the
3 present pins could go low, or at least one pin goes low.
If x4 card is connected, then it might be possible that 2 present
pins go low, or at least one pin goes low.

The implementation essentially takes care of following:
> Initializing hotplug irq thread.
> Detecting the endpoint device based on link state.
> Handling PERST and detecting the plugged devices.
> Ordered Hot plug-out, where User is expected
  to write 1 to /sys/bus/pci/devices//remove
> Handling spurious interrupt
> Handling multiple interrupts and makes sure that card is
  enumerated only once.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index a5073a9..6287a43 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device 
*pdev)
pcie->need_ob_cfg = true;
}
 
+   if (of_property_read_bool(np, "slot-pluggable"))
+   pcie->enable_hotplug = true;
+
/* PHY use is optional */
pcie->phy = devm_phy_get(dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 8bd5e54..2b4d830 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pcie-iproc.h"
 
@@ -65,6 +66,17 @@
 #define PCIE_DL_ACTIVE_SHIFT 2
 #define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define CFG_RC_LTSSM 0x1cf8
+#define CFG_RC_PHY_CTL   0x1804
+#define CFG_RC_LTSSM_TIMEOUT 1000
+#define CFG_RC_LTSSM_STATE_MASK  0xff
+#define CFG_RC_LTSSM_STATE_L10x1
+
+#define CFG_RC_CLR_LTSSM_HIST_SHIFT  29
+#define CFG_RC_CLR_LTSSM_HIST_MASK   BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)
+#define CFG_RC_CLR_RECOV_HIST_SHIFT  31
+#define CFG_RC_CLR_RECOV_HIST_MASK   BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)
+
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
@@ -1354,13 +1366,107 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
return 0;
 }
 
+static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)
+{
+   struct pci_bus *bus = pcie->root_bus;
+   u32 val, timeout = CFG_RC_LTSSM_TIMEOUT;
+
+   /* Clear LTSSM history. */
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_PHY_CTL, );
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,
+  val | CFG_RC_CLR_RECOV_HIST_MASK |
+  CFG_RC_CLR_LTSSM_HIST_MASK);
+   /* write back the origional value. */
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);
+
+   do {
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_LTSSM, );
+   /* check link state to see if link moved to L1 state. */
+   if ((val & CFG_RC_LTSSM_STATE_MASK) ==
+CFG_RC_LTSSM_STATE_L1)
+   return true;
+   timeout--;
+   usleep_range(500, 1000);
+   } while (timeout);
+
+   return false;
+}
+
+static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)
+{
+   struct iproc_pcie *pcie = data;
+   struct pci_bus *bus = pcie->root_bus, *child;
+   bool link_status;
+
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
+
+   link_status = iproc_pci_hp_check_ltssm(pcie);
+
+   if (link_status &&
+   !iproc_pcie_check_link(pcie) &&
+   !pcie->ep_is_present) {
+   pci_rescan_bus(bus);
+   list_for_each_entry(child, >children, node)
+   pcie_bus_configure_settings(child);
+   pcie->ep_is_present = true;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   } else if (link_status && pcie->ep_is_present)
+   /*
+* ep_is_present makes sure, enumuration done only once.
+* So it can handle spurious intrrupts, and also if we
+* get 

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

[Oza Pawandeep]

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
index b8e48b4..0c5f631 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,20 @@ Optional properties:
 - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
 require the interrupt enable registers to be set explicitly to enable MSI
 
+Optional properties:
+- slot-pluggable: PCI hotplug feature is supported.
+- prsnt-gpios: Array of gpios, needs to be present if Hotplug is supported.
+
+Refer to the following binding documents for more detailed description on
+the use of 'slot-pluggable' and 'prsnt-gpios'.
+  Documentation/devicetree/bindings/pci/pci.txt
+
+Example:
+prsnt-gpios: < 32 1>, < 33 1>;
+This is x4 connector: monitoring max 2 present lines.
+prsnt-gpios: < 32 1>, < 33 1>, < 34 1>;
+This is x8 connector: monitoring max 3 present lines.
+
 Example:
pcie0: pcie@18012000 {
compatible = "brcm,iproc-pcie";
-- 
1.9.1

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

[Oza Pawandeep]

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 PCI hotplug is as follows:
PCI present lines are input to GPIOs depending on the type of
connector (x2, x4, x8).

GPIO array needs to be present if hotplug is supported.
HW implementation is SOC/Board specific, and also it depends on how
add-in card is designed
(e.g. how many present pins are implemented).

If x8 card is connected, then it might be possible that all the
3 present pins could go low, or at least one pin goes low.
If x4 card is connected, then it might be possible that 2 present
pins go low, or at least one pin goes low.

The implementation essentially takes care of following:
> Initializing hotplug irq thread.
> Detecting the endpoint device based on link state.
> Handling PERST and detecting the plugged devices.
> Ordered Hot plug-out, where User is expected
  to write 1 to /sys/bus/pci/devices//remove
> Handling spurious interrupt
> Handling multiple interrupts and makes sure that card is
  enumerated only once.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index a5073a9..6287a43 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device 
*pdev)
pcie->need_ob_cfg = true;
}
 
+   if (of_property_read_bool(np, "slot-pluggable"))
+   pcie->enable_hotplug = true;
+
/* PHY use is optional */
pcie->phy = devm_phy_get(dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 8bd5e54..2b4d830 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pcie-iproc.h"
 
@@ -65,6 +66,17 @@
 #define PCIE_DL_ACTIVE_SHIFT 2
 #define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define CFG_RC_LTSSM 0x1cf8
+#define CFG_RC_PHY_CTL   0x1804
+#define CFG_RC_LTSSM_TIMEOUT 1000
+#define CFG_RC_LTSSM_STATE_MASK  0xff
+#define CFG_RC_LTSSM_STATE_L10x1
+
+#define CFG_RC_CLR_LTSSM_HIST_SHIFT  29
+#define CFG_RC_CLR_LTSSM_HIST_MASK   BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)
+#define CFG_RC_CLR_RECOV_HIST_SHIFT  31
+#define CFG_RC_CLR_RECOV_HIST_MASK   BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)
+
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
@@ -1354,13 +1366,107 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
return 0;
 }
 
+static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)
+{
+   struct pci_bus *bus = pcie->root_bus;
+   u32 val, timeout = CFG_RC_LTSSM_TIMEOUT;
+
+   /* Clear LTSSM history. */
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_PHY_CTL, );
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,
+  val | CFG_RC_CLR_RECOV_HIST_MASK |
+  CFG_RC_CLR_LTSSM_HIST_MASK);
+   /* write back the origional value. */
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);
+
+   do {
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_LTSSM, );
+   /* check link state to see if link moved to L1 state. */
+   if ((val & CFG_RC_LTSSM_STATE_MASK) ==
+CFG_RC_LTSSM_STATE_L1)
+   return true;
+   timeout--;
+   usleep_range(500, 1000);
+   } while (timeout);
+
+   return false;
+}
+
+static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)
+{
+   struct iproc_pcie *pcie = data;
+   struct pci_bus *bus = pcie->root_bus, *child;
+   bool link_status;
+
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
+
+   link_status = iproc_pci_hp_check_ltssm(pcie);
+
+   if (link_status &&
+   !iproc_pcie_check_link(pcie) &&
+   !pcie->ep_is_present) {
+   pci_rescan_bus(bus);
+   list_for_each_entry(child, >children, node)
+   pcie_bus_configure_settings(child);
+   pcie->ep_is_present = true;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   } else if (link_status && pcie->ep_is_present)
+   /*
+* ep_is_present makes sure, enumuration done only once.
+* So it can handle spurious intrrupts, and also if we
+* get multiple interrupts for all the implemented 

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

[Oza Pawandeep]

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
index b8e48b4..0c5f631 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,20 @@ Optional properties:
 - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
 require the interrupt enable registers to be set explicitly to enable MSI
 
+Optional properties:
+- slot-pluggable: PCI hotplug feature is supported.
+- prsnt-gpios: Array of gpios, needs to be present if Hotplug is supported.
+
+Refer to the following binding documents for more detailed description on
+the use of 'slot-pluggable' and 'prsnt-gpios'.
+  Documentation/devicetree/bindings/pci/pci.txt
+
+Example:
+prsnt-gpios: < 32 1>, < 33 1>;
+This is x4 connector: monitoring max 2 present lines.
+prsnt-gpios: < 32 1>, < 33 1>, < 34 1>;
+This is x8 connector: monitoring max 3 present lines.
+
 Example:
pcie0: pcie@18012000 {
compatible = "brcm,iproc-pcie";
-- 
1.9.1

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

[Oza Pawandeep]

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 
Acked-by: Rob Herring 

diff --git a/Documentation/devicetree/bindings/pci/pci.txt 
b/Documentation/devicetree/bindings/pci/pci.txt
index 50f9e2c..0bf25a1 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -24,3 +24,18 @@ driver implementation may support the following properties:
unsupported link speed, for instance, trying to do training for
unsupported link speed, etc.  Must be '4' for gen4, '3' for gen3, '2'
for gen2, and '1' for gen1. Any other values are invalid.
+
+- slot-pluggable:
+   PCI hotplug feature is supported.
+   PCI hotplug implementation is SOC/Board specific, and also it depends on
+   how add-in card is designed (e.g. how many present pins are implemented).
+   If the slot-pluggable property is present, the following propertey could
+   become effective.
+   - prsnt-gpios:
+  Array of gpios, could be present if hotplug is supported.
+  This property defines gpio based hotplug implementation.
+  Example:
+  If x8 card is connected, then it might be possible that all the
+  3 present pins could go low, or at least one pin goes low.
+  If x4 card is connected, then it might be possible that 2 present
+  pins go low, or at least one pin goes low.
-- 
1.9.1

[PATCH v5 0/3] PCI hotplug feature

[Oza Pawandeep]

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 patches.

Changes since v2:
Addressed Rob Herring's comments.
Changed subject to "dt-bindings: PCI:..."
Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'
Rebased the patches on top of Lorenzo's patches.

Oza Pawandeep (3):
  dt-bindings: PCI: Add PCI hotplug property
  dt-bindings: PCI iproc: Implement optional property prsnt-gpios
  PCI: iproc: Implement PCI hotplug support

 .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  14 ++
 Documentation/devicetree/bindings/pci/pci.txt  |  15 ++
 drivers/pci/host/pcie-iproc-platform.c |   3 +
 drivers/pci/host/pcie-iproc.c  | 166 ++---
 drivers/pci/host/pcie-iproc.h  |   7 +
 5 files changed, 187 insertions(+), 18 deletions(-)

-- 
1.9.1

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

[Oza Pawandeep]

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 
Acked-by: Rob Herring 

diff --git a/Documentation/devicetree/bindings/pci/pci.txt 
b/Documentation/devicetree/bindings/pci/pci.txt
index 50f9e2c..0bf25a1 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -24,3 +24,18 @@ driver implementation may support the following properties:
unsupported link speed, for instance, trying to do training for
unsupported link speed, etc.  Must be '4' for gen4, '3' for gen3, '2'
for gen2, and '1' for gen1. Any other values are invalid.
+
+- slot-pluggable:
+   PCI hotplug feature is supported.
+   PCI hotplug implementation is SOC/Board specific, and also it depends on
+   how add-in card is designed (e.g. how many present pins are implemented).
+   If the slot-pluggable property is present, the following propertey could
+   become effective.
+   - prsnt-gpios:
+  Array of gpios, could be present if hotplug is supported.
+  This property defines gpio based hotplug implementation.
+  Example:
+  If x8 card is connected, then it might be possible that all the
+  3 present pins could go low, or at least one pin goes low.
+  If x4 card is connected, then it might be possible that 2 present
+  pins go low, or at least one pin goes low.
-- 
1.9.1

[PATCH v5 0/3] PCI hotplug feature

[Oza Pawandeep]

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 patches.

Changes since v2:
Addressed Rob Herring's comments.
Changed subject to "dt-bindings: PCI:..."
Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'
Rebased the patches on top of Lorenzo's patches.

Oza Pawandeep (3):
  dt-bindings: PCI: Add PCI hotplug property
  dt-bindings: PCI iproc: Implement optional property prsnt-gpios
  PCI: iproc: Implement PCI hotplug support

 .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  14 ++
 Documentation/devicetree/bindings/pci/pci.txt  |  15 ++
 drivers/pci/host/pcie-iproc-platform.c |   3 +
 drivers/pci/host/pcie-iproc.c  | 166 ++---
 drivers/pci/host/pcie-iproc.h  |   7 +
 5 files changed, 187 insertions(+), 18 deletions(-)

-- 
1.9.1

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

[Larry Finger]

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 reported by Coverity and it was tested by compilation only.
Please, verify if this is not a copy/paste error.
Also, notice this code has been there since 2014.

  drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
index 131c0d1..15c117e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
@@ -883,12 +883,8 @@ static void 
rtl8723be_dm_txpower_tracking_callback_thermalmeter(
if ((rtldm->power_index_offset[RF90_PATH_A] != 0) &&
(rtldm->txpower_track_control)) {
rtldm->done_txpower = true;
-   if (thermalvalue > rtlefuse->eeprom_thermalmeter)
-   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
-index_for_channel);
-   else
-   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
-index_for_channel);
+   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
+ index_for_channel);
  
  		rtldm->swing_idx_cck_base = rtldm->swing_idx_cck;

rtldm->swing_idx_ofdm_base[RF90_PATH_A] =

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

[Larry Finger]

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 reported by Coverity and it was tested by compilation only.
Please, verify if this is not a copy/paste error.
Also, notice this code has been there since 2014.

  drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
index 131c0d1..15c117e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
@@ -883,12 +883,8 @@ static void 
rtl8723be_dm_txpower_tracking_callback_thermalmeter(
if ((rtldm->power_index_offset[RF90_PATH_A] != 0) &&
(rtldm->txpower_track_control)) {
rtldm->done_txpower = true;
-   if (thermalvalue > rtlefuse->eeprom_thermalmeter)
-   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
-index_for_channel);
-   else
-   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
-index_for_channel);
+   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
+ index_for_channel);
  
  		rtldm->swing_idx_cck_base = rtldm->swing_idx_cck;

rtldm->swing_idx_ofdm_base[RF90_PATH_A] =

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

[Josh Poimboeuf]

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 non-optimization where it
> >>> uses an intermediate register to adjust the stack pointer.  It does:
> >>>
> >>>   lea0x8(%rsp), %rcx
> >>>   ...
> >>>   mov%rcx, %rsp
> >>>
> >>> Instead of the obvious:
> >>>
> >>>   add$0x8, %rsp
> >>>
> >>> It makes no sense to use an intermediate register, so I opened a GCC bug
> >>> to track it:
> >>>
> >>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81813
> >>>
> >>> But it's not exactly a high-priority bug and it looks like we'll be
> >>> stuck with this issue for a while.  So for now we have to track register
> >>> values when they're loaded with stack pointer offsets.
> >>>
> >>
> >> This seems like a good reason to try to extract this information from
> >> the DWARF data *if available*?
> > 
> > Well, I haven't ruled that out for the future, but in this case,
> > integrating DWARF would be a lot more work than this relatively simple
> > patch.
> > 
> > If we did go that route, it could be tricky deciding when to trust
> > DWARF vs. when to trust objtool's reverse engineering.
> > 
> > Another (vague) idea I'm thinking about is to write a GCC plugin which
> > annotates the object files in a way that would help objtool become more
> > GCC-ignorant.  If it worked, this approach would be more powerful and
> > less error-prone than relying on DWARF.
> > 
> > Depending on how much work we can offload to the plugin, it might also
> > help make it easier to port objtool to other arches and compilers (e.g.,
> > clang).
> > 
> > I'm not 100% sold on that idea either, because it still requires objtool
> > to trust the compiler to some extent.  But I think it would be worth it
> > because it would make the objtool code simpler, more portable, more
> > robust, and easier to maintain (so I don't always have to stay on top of
> > all of GCC's latest optimizations).
> > 
> > In the meantime, objtool's current design is working fine (for now).  I
> > haven't found any issues it can't handle (yet).
> > 
> 
> Reverse engineering this way is at least NP-complete, and quite possibly
> undecidable.

Well, in practice, the reverse engineering already works very well.
Much to my complete surprise, admittedly.  And there are ways to "prove"
its accuracy over time with runtime sanity checks.

But I think we can agree that it would be wise to improve the current
approach.

> A gcc plugin would tie the kernel *way* harder to gcc than it is now

Actually, I would expect that moving GCC-specific pieces to a GCC plugin
would *decouple* the kernel from GCC, because there would then be a
compiler-independent interface to objtool.  A similar plugin could be
written for clang.  (all with the usual disclaimer: "if it works", of
course)

And I would hope/expect that the plugin would be less affected by new
and unusual GCC optimizations than objtool currently is, because it
would be much easier for the plugin to understand those changes by just
reading the RTL, instead of us trying to blindly decipher each new
pattern we find in the object code.

> and it seems incredibly unlikely that you would come up with something
> simpler and more reliable than a DWARF parser.

I'm not so sure about that.  I think it's just a matter of reading RTL
from a GCC plugin and providing some hints in a special section.  Of
course, the devil's in the details.

> What you *can* do, of course, is cross-correlate the two, and *way*
> more importantly, you cover assembly.

But how do you decide when to trust DWARF and when not?  We can't just
say "trust DWARF in everything but inline asm" because there's no way to
delineate inline asm just by reading the object code.

And I've heard some talk of buggy DWARF output in various versions of
GCC, of which we would could do nothing about if we blindly trusted
DWARF.  I don't know if those reports are accurate, but we would be at
the mercy of tooling bugs.  And in my experience, GCC doesn't seem to
prioritize the fixing of such "minor" issues (with the above patch being
an example).

There are also some control flow quirks which objtool struggles with,
for which a GCC plugin would be *so* much nicer.  Examples: noreturn
functions, switch statement jump tables, DRAP stack alignments, sibling
calls, KASAN/UBSAN/gcov issues, unreachable instructions, cold/unlikely
subfunctions, unusual stack pointer update patterns.  Those are the
things that keep me up at night.

-- 
Josh

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

[Josh Poimboeuf]

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 non-optimization where it
> >>> uses an intermediate register to adjust the stack pointer.  It does:
> >>>
> >>>   lea0x8(%rsp), %rcx
> >>>   ...
> >>>   mov%rcx, %rsp
> >>>
> >>> Instead of the obvious:
> >>>
> >>>   add$0x8, %rsp
> >>>
> >>> It makes no sense to use an intermediate register, so I opened a GCC bug
> >>> to track it:
> >>>
> >>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81813
> >>>
> >>> But it's not exactly a high-priority bug and it looks like we'll be
> >>> stuck with this issue for a while.  So for now we have to track register
> >>> values when they're loaded with stack pointer offsets.
> >>>
> >>
> >> This seems like a good reason to try to extract this information from
> >> the DWARF data *if available*?
> > 
> > Well, I haven't ruled that out for the future, but in this case,
> > integrating DWARF would be a lot more work than this relatively simple
> > patch.
> > 
> > If we did go that route, it could be tricky deciding when to trust
> > DWARF vs. when to trust objtool's reverse engineering.
> > 
> > Another (vague) idea I'm thinking about is to write a GCC plugin which
> > annotates the object files in a way that would help objtool become more
> > GCC-ignorant.  If it worked, this approach would be more powerful and
> > less error-prone than relying on DWARF.
> > 
> > Depending on how much work we can offload to the plugin, it might also
> > help make it easier to port objtool to other arches and compilers (e.g.,
> > clang).
> > 
> > I'm not 100% sold on that idea either, because it still requires objtool
> > to trust the compiler to some extent.  But I think it would be worth it
> > because it would make the objtool code simpler, more portable, more
> > robust, and easier to maintain (so I don't always have to stay on top of
> > all of GCC's latest optimizations).
> > 
> > In the meantime, objtool's current design is working fine (for now).  I
> > haven't found any issues it can't handle (yet).
> > 
> 
> Reverse engineering this way is at least NP-complete, and quite possibly
> undecidable.

Well, in practice, the reverse engineering already works very well.
Much to my complete surprise, admittedly.  And there are ways to "prove"
its accuracy over time with runtime sanity checks.

But I think we can agree that it would be wise to improve the current
approach.

> A gcc plugin would tie the kernel *way* harder to gcc than it is now

Actually, I would expect that moving GCC-specific pieces to a GCC plugin
would *decouple* the kernel from GCC, because there would then be a
compiler-independent interface to objtool.  A similar plugin could be
written for clang.  (all with the usual disclaimer: "if it works", of
course)

And I would hope/expect that the plugin would be less affected by new
and unusual GCC optimizations than objtool currently is, because it
would be much easier for the plugin to understand those changes by just
reading the RTL, instead of us trying to blindly decipher each new
pattern we find in the object code.

> and it seems incredibly unlikely that you would come up with something
> simpler and more reliable than a DWARF parser.

I'm not so sure about that.  I think it's just a matter of reading RTL
from a GCC plugin and providing some hints in a special section.  Of
course, the devil's in the details.

> What you *can* do, of course, is cross-correlate the two, and *way*
> more importantly, you cover assembly.

But how do you decide when to trust DWARF and when not?  We can't just
say "trust DWARF in everything but inline asm" because there's no way to
delineate inline asm just by reading the object code.

And I've heard some talk of buggy DWARF output in various versions of
GCC, of which we would could do nothing about if we blindly trusted
DWARF.  I don't know if those reports are accurate, but we would be at
the mercy of tooling bugs.  And in my experience, GCC doesn't seem to
prioritize the fixing of such "minor" issues (with the above patch being
an example).

There are also some control flow quirks which objtool struggles with,
for which a GCC plugin would be *so* much nicer.  Examples: noreturn
functions, switch statement jump tables, DRAP stack alignments, sibling
calls, KASAN/UBSAN/gcov issues, unreachable instructions, cold/unlikely
subfunctions, unusual stack pointer update patterns.  Those are the
things that keep me up at night.

-- 
Josh

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

[Christophe JAILLET]

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 
---
 sound/atmel/ac97c.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c
index 30c64ab210d9..5ffefac2fa8f 100644
--- a/sound/atmel/ac97c.c
+++ b/sound/atmel/ac97c.c
@@ -785,7 +785,7 @@ static int atmel_ac97c_probe(struct platform_device *pdev)
}
retval = clk_prepare_enable(pclk);
if (retval)
-   return retval;
+   goto err_prepare_enable;
 
retval = snd_card_new(>dev, SNDRV_DEFAULT_IDX1,
  SNDRV_DEFAULT_STR1, THIS_MODULE,
@@ -881,6 +881,7 @@ static int atmel_ac97c_probe(struct platform_device *pdev)
snd_card_free(card);
 err_snd_card_new:
clk_disable_unprepare(pclk);
+err_prepare_enable:
clk_put(pclk);
return retval;
 }
-- 
2.11.0

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

[Christophe JAILLET]

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 
---
 sound/atmel/ac97c.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c
index 30c64ab210d9..5ffefac2fa8f 100644
--- a/sound/atmel/ac97c.c
+++ b/sound/atmel/ac97c.c
@@ -785,7 +785,7 @@ static int atmel_ac97c_probe(struct platform_device *pdev)
}
retval = clk_prepare_enable(pclk);
if (retval)
-   return retval;
+   goto err_prepare_enable;
 
retval = snd_card_new(>dev, SNDRV_DEFAULT_IDX1,
  SNDRV_DEFAULT_STR1, THIS_MODULE,
@@ -881,6 +881,7 @@ static int atmel_ac97c_probe(struct platform_device *pdev)
snd_card_free(card);
 err_snd_card_new:
clk_disable_unprepare(pclk);
+err_prepare_enable:
clk_put(pclk);
return retval;
 }
-- 
2.11.0

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

[Mike Galbraith]

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
> >>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
> >>> running haveged will help me trigger this on my system...
> >>
> >> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.
> >
> > Wonderful! Thank you so much for helping track this down.
> >
> > So, it seems that sk_buff.users will need some more special attention
> > before we can convert it to refcount.
> >
> > x86-refcount will saturate with refcount_dec_and_test() if the result
> > is negative. But that would mean at least starting at 0. FULL should
> > have WARNed in this case, so I remain slightly confused why it was
> > missed by FULL.
> 
> Actually, if this is a race condition it's possible that FULL is slow
> enough to miss it...
> 
> I bet something briefly takes the refcount negative, and with
> unchecked atomics, it come back up positive again during the race.
> FULL may miss the race, and x86-refcount will catch it and saturate...

Hm, I'll go have a stare.. not that that's likely to turn anything up,
memory ordering stares usually inducing a zombie like state.

-Mike

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

[Mike Galbraith]

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
> >>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
> >>> running haveged will help me trigger this on my system...
> >>
> >> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.
> >
> > Wonderful! Thank you so much for helping track this down.
> >
> > So, it seems that sk_buff.users will need some more special attention
> > before we can convert it to refcount.
> >
> > x86-refcount will saturate with refcount_dec_and_test() if the result
> > is negative. But that would mean at least starting at 0. FULL should
> > have WARNed in this case, so I remain slightly confused why it was
> > missed by FULL.
> 
> Actually, if this is a race condition it's possible that FULL is slow
> enough to miss it...
> 
> I bet something briefly takes the refcount negative, and with
> unchecked atomics, it come back up positive again during the race.
> FULL may miss the race, and x86-refcount will catch it and saturate...

Hm, I'll go have a stare.. not that that's likely to turn anything up,
memory ordering stares usually inducing a zombie like state.

-Mike

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

[Stephen Rothwell]

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 adjust_exception_frame")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/xen/enlighten_pv.c
index c76f5ff4d0d7,148527c4e48a..
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@@ -596,42 -651,10 +658,10 @@@ static int cvt_gate_to_trap(int vector
  
info->vector = vector;
  
 -  addr = gate_offset(*val);
 +  addr = gate_offset(val);
  #ifdef CONFIG_X86_64
-   /*
-* Look for known traps using IST, and substitute them
-* appropriately.  The debugger ones are the only ones we care
-* about.  Xen will handle faults like double_fault,
-* so we should never see them.  Warn if
-* there's an unexpected IST-using fault handler.
-*/
-   if (addr == (unsigned long)debug)
-   addr = (unsigned long)xen_debug;
-   else if (addr == (unsigned long)int3)
-   addr = (unsigned long)xen_int3;
-   else if (addr == (unsigned long)stack_segment)
-   addr = (unsigned long)xen_stack_segment;
-   else if (addr == (unsigned long)double_fault) {
-   /* Don't need to handle these */
 -  if (!get_trap_addr(, val->ist))
++  if (!get_trap_addr(, val->bits.ist))
return 0;
- #ifdef CONFIG_X86_MCE
-   } else if (addr == (unsigned long)machine_check) {
-   /*
-* when xen hypervisor inject vMCE to guest,
-* use native mce handler to handle it
-*/
-   ;
- #endif
-   } else if (addr == (unsigned long)nmi)
-   /*
-* Use the native version as well.
-*/
-   ;
-   else {
-   /* Some other trap using IST? */
-   if (WARN_ON(val->bits.ist != 0))
-   return 0;
-   }
  #endif/* CONFIG_X86_64 */
info->address = addr;
  

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

[Stephen Rothwell]

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 adjust_exception_frame")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/xen/enlighten_pv.c
index c76f5ff4d0d7,148527c4e48a..
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@@ -596,42 -651,10 +658,10 @@@ static int cvt_gate_to_trap(int vector
  
info->vector = vector;
  
 -  addr = gate_offset(*val);
 +  addr = gate_offset(val);
  #ifdef CONFIG_X86_64
-   /*
-* Look for known traps using IST, and substitute them
-* appropriately.  The debugger ones are the only ones we care
-* about.  Xen will handle faults like double_fault,
-* so we should never see them.  Warn if
-* there's an unexpected IST-using fault handler.
-*/
-   if (addr == (unsigned long)debug)
-   addr = (unsigned long)xen_debug;
-   else if (addr == (unsigned long)int3)
-   addr = (unsigned long)xen_int3;
-   else if (addr == (unsigned long)stack_segment)
-   addr = (unsigned long)xen_stack_segment;
-   else if (addr == (unsigned long)double_fault) {
-   /* Don't need to handle these */
 -  if (!get_trap_addr(, val->ist))
++  if (!get_trap_addr(, val->bits.ist))
return 0;
- #ifdef CONFIG_X86_MCE
-   } else if (addr == (unsigned long)machine_check) {
-   /*
-* when xen hypervisor inject vMCE to guest,
-* use native mce handler to handle it
-*/
-   ;
- #endif
-   } else if (addr == (unsigned long)nmi)
-   /*
-* Use the native version as well.
-*/
-   ;
-   else {
-   /* Some other trap using IST? */
-   if (WARN_ON(val->bits.ist != 0))
-   return 0;
-   }
  #endif/* CONFIG_X86_64 */
info->address = addr;
  

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

[Greg Kroah-Hartman]

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 "normal" operation, or crashes when running a fuzzer or
other type of program?

> The patch was already merged upstream here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05
> 
> but then reverted here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=896d81fefe5d1919537db2c2150ab6384e4a6610
> 
> Nathan confirmed if he applies the patch from 
> 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the 
> bug/problem goes away, so the patch (or similar fix) is still needed, at 
> least for 4.9 LTS kernel.
> 
> 
> Mikulas reported he's able to trigger the same crash on Linux 4.10:
> https://www.spinics.net/lists/kernel/msg2440637.html
> https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#2664604
> 
> Michael Neuling reported he's able to trigger the bug on PowerPC:
> https://lkml.org/lkml/2017/3/10/1582
> 
> 
> So now the question is.. is anyone currently working on getting this patch 
> fixed and applied upstream? I think one of the problems earlier was being 
> able to reliable reproduce the crash.. Nathan says he's able to reproduce it 
> many times per week on his environment on x86_64.

I don't know of anyone working on it, want to do it yourself?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 "normal" operation, or crashes when running a fuzzer or
other type of program?

> The patch was already merged upstream here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05
> 
> but then reverted here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=896d81fefe5d1919537db2c2150ab6384e4a6610
> 
> Nathan confirmed if he applies the patch from 
> 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the 
> bug/problem goes away, so the patch (or similar fix) is still needed, at 
> least for 4.9 LTS kernel.
> 
> 
> Mikulas reported he's able to trigger the same crash on Linux 4.10:
> https://www.spinics.net/lists/kernel/msg2440637.html
> https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#2664604
> 
> Michael Neuling reported he's able to trigger the bug on PowerPC:
> https://lkml.org/lkml/2017/3/10/1582
> 
> 
> So now the question is.. is anyone currently working on getting this patch 
> fixed and applied upstream? I think one of the problems earlier was being 
> able to reliable reproduce the crash.. Nathan says he's able to reproduce it 
> many times per week on his environment on x86_64.

I don't know of anyone working on it, want to do it yourself?

thanks,

greg k-h

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

[Greg KH]

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, and to prevent people from having to maintain it,
> > > let's move it to drivers/staging/ so that we can delete it entirely from
> > > the kernel in a few releases.
> >
> > No objection, I'll apply this to net-next, thanks Greg.
> 
> IRDA works fine in Debian 9 (kernel 4.9) and I use it for simple file 
> transfer. Hope I'm not the only one...
> 
> # irattach /dev/ttyS0 -d tekram -s
> # irdadump
> 21:28:52.830350 xid:cmd aed8eb79 >  S=6 s=0 (14)
> 21:28:52.922368 xid:cmd aed8eb79 >  S=6 s=1 (14)
> 21:28:53.014350 xid:cmd aed8eb79 >  S=6 s=2 (14)
> 21:28:53.106338 xid:cmd aed8eb79 >  S=6 s=3 (14)
> 21:28:53.190276 xid:rsp aed8eb79 < 35d1 S=6 s=3 Nokia 6230i hint=b125 [ 
> PnP Modem Fax Telephony IrCOMM IrOBEX ] (28)
> 21:28:53.198384 xid:cmd aed8eb79 >  S=6 s=4 (14)
> 21:28:53.290382 xid:cmd aed8eb79 >  S=6 s=5 (14)
> 21:28:53.382341 xid:cmd aed8eb79 >  S=6 s=* pentium hint=0400 [ 
> Computer ] (23)
> ^C
> 8 packets received by filter
> 
> $ obexftp -i -l MMC
> Connecting..\done
> Receiving "MMC".../
>   [  ]>
> 
> 
>  user-perm="RWD"/>
>  user-perm="RWD"/>
>  user-perm="RWD"/>
> 
> $ obexftp -i -c MMC -g Image004.jpg
> Connecting..\done
> Sending "MMC"...|done
> Receiving "Image004.jpg"...-done
> Disconnecting..\done

Odd, and is this just a ir device connected to a "real" serial port, or
a specific IRDA device?

thanks,

greg k-h

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

[Greg KH]

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, and to prevent people from having to maintain it,
> > > let's move it to drivers/staging/ so that we can delete it entirely from
> > > the kernel in a few releases.
> >
> > No objection, I'll apply this to net-next, thanks Greg.
> 
> IRDA works fine in Debian 9 (kernel 4.9) and I use it for simple file 
> transfer. Hope I'm not the only one...
> 
> # irattach /dev/ttyS0 -d tekram -s
> # irdadump
> 21:28:52.830350 xid:cmd aed8eb79 >  S=6 s=0 (14)
> 21:28:52.922368 xid:cmd aed8eb79 >  S=6 s=1 (14)
> 21:28:53.014350 xid:cmd aed8eb79 >  S=6 s=2 (14)
> 21:28:53.106338 xid:cmd aed8eb79 >  S=6 s=3 (14)
> 21:28:53.190276 xid:rsp aed8eb79 < 35d1 S=6 s=3 Nokia 6230i hint=b125 [ 
> PnP Modem Fax Telephony IrCOMM IrOBEX ] (28)
> 21:28:53.198384 xid:cmd aed8eb79 >  S=6 s=4 (14)
> 21:28:53.290382 xid:cmd aed8eb79 >  S=6 s=5 (14)
> 21:28:53.382341 xid:cmd aed8eb79 >  S=6 s=* pentium hint=0400 [ 
> Computer ] (23)
> ^C
> 8 packets received by filter
> 
> $ obexftp -i -l MMC
> Connecting..\done
> Receiving "MMC".../
>   [  ]>
> 
> 
>  user-perm="RWD"/>
>  user-perm="RWD"/>
>  user-perm="RWD"/>
> 
> $ obexftp -i -c MMC -g Image004.jpg
> Connecting..\done
> Sending "MMC"...|done
> Receiving "Image004.jpg"...-done
> Disconnecting..\done

Odd, and is this just a ir device connected to a "real" serial port, or
a specific IRDA device?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 previous buffers.
> >>
> >> Signed-off-by: Sherry Yang 
> >> ---
> >>  drivers/android/binder_alloc.c | 24 +++-
> >>  1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > What changed from the previous version?
> 
> This specific patch didn't change. The change is only in [patch v3
> 3/6] (crash fix) and in [patch v3 6/6] (new patch that add stats).

I need to know that :)

> > Always put the changes below the --- line.  Like the documentation says
> > to do so.
> 
> Do you mean I should use --annotate to git send-email to specify what
> has changed across versions for each patch? I used --compose and put
> what changed from v2 to v3 in the introductory message [patch 0/6].

I never got a patch 0/6 here, and honestly, almost always ignore them as
patches should be self-obvious :)

> > Also, don't I already have these patches in my tree?  Do you want me to
> > revert the existing ones and use the new ones, or what about a fixup
> > patch for any differences?
> 
> I got a message saying a test failed on [patch 3/5]. I resubmitted the
> entire thread because I wasn't sure if you would drop the failing
> patch set. If the entire failing patch set is dropped, then v3 can be
> used as a replacement.

Do you want me to revert all of these?  I can not "drop" them as my tree
can not rebase.  If it's just a simple fix, I'll gladly take that
instead.

> If you prefer a fixup patch, I can post another patch set (the crash
> fix and the new patch) on top of what you already applied, but it
> might be easier to do what's described in the previous paragraph (drop
> v2 and apply v3).

Ok, exactly what git commit ids should I revert from the tree?  But
really, a fix would be easier at this point :)

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 previous buffers.
> >>
> >> Signed-off-by: Sherry Yang 
> >> ---
> >>  drivers/android/binder_alloc.c | 24 +++-
> >>  1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > What changed from the previous version?
> 
> This specific patch didn't change. The change is only in [patch v3
> 3/6] (crash fix) and in [patch v3 6/6] (new patch that add stats).

I need to know that :)

> > Always put the changes below the --- line.  Like the documentation says
> > to do so.
> 
> Do you mean I should use --annotate to git send-email to specify what
> has changed across versions for each patch? I used --compose and put
> what changed from v2 to v3 in the introductory message [patch 0/6].

I never got a patch 0/6 here, and honestly, almost always ignore them as
patches should be self-obvious :)

> > Also, don't I already have these patches in my tree?  Do you want me to
> > revert the existing ones and use the new ones, or what about a fixup
> > patch for any differences?
> 
> I got a message saying a test failed on [patch 3/5]. I resubmitted the
> entire thread because I wasn't sure if you would drop the failing
> patch set. If the entire failing patch set is dropped, then v3 can be
> used as a replacement.

Do you want me to revert all of these?  I can not "drop" them as my tree
can not rebase.  If it's just a simple fix, I'll gladly take that
instead.

> If you prefer a fixup patch, I can post another patch set (the crash
> fix and the new patch) on top of what you already applied, but it
> might be easier to do what's described in the previous paragraph (drop
> v2 and apply v3).

Ok, exactly what git commit ids should I revert from the tree?  But
really, a fix would be easier at this point :)

thanks,

greg k-h

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

[Stephen Rothwell]

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 xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/traps.h
index b4f322d6c95f,935709829a4e..
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@@ -38,7 -35,34 +35,33 @@@ asmlinkage void machine_check(void)
  #endif /* CONFIG_X86_MCE */
  asmlinkage void simd_coprocessor_error(void);
  
+ #if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+ asmlinkage void xen_divide_error(void);
+ asmlinkage void xen_xendebug(void);
+ asmlinkage void xen_xenint3(void);
+ asmlinkage void xen_nmi(void);
+ asmlinkage void xen_overflow(void);
+ asmlinkage void xen_bounds(void);
+ asmlinkage void xen_invalid_op(void);
+ asmlinkage void xen_device_not_available(void);
+ asmlinkage void xen_double_fault(void);
+ asmlinkage void xen_coprocessor_segment_overrun(void);
+ asmlinkage void xen_invalid_TSS(void);
+ asmlinkage void xen_segment_not_present(void);
+ asmlinkage void xen_stack_segment(void);
+ asmlinkage void xen_general_protection(void);
+ asmlinkage void xen_page_fault(void);
+ asmlinkage void xen_async_page_fault(void);
+ asmlinkage void xen_spurious_interrupt_bug(void);
+ asmlinkage void xen_coprocessor_error(void);
+ asmlinkage void xen_alignment_check(void);
+ #ifdef CONFIG_X86_MCE
+ asmlinkage void xen_machine_check(void);
+ #endif /* CONFIG_X86_MCE */
+ asmlinkage void xen_simd_coprocessor_error(void);
+ #endif
+ 
  #ifdef CONFIG_TRACING
 -asmlinkage void trace_page_fault(void);
  #define trace_stack_segment stack_segment
  #define trace_divide_error divide_error
  #define trace_bounds bounds
@@@ -53,7 -77,10 +76,11 @@@
  #define trace_alignment_check alignment_check
  #define trace_simd_coprocessor_error simd_coprocessor_error
  #define trace_async_page_fault async_page_fault
 +#define trace_page_fault page_fault
+ 
+ #if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+ asmlinkage void xen_trace_page_fault(void);
+ #endif
  #endif
  
  dotraplinkage void do_divide_error(struct pt_regs *, long);

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

[Stephen Rothwell]

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 xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/traps.h
index b4f322d6c95f,935709829a4e..
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@@ -38,7 -35,34 +35,33 @@@ asmlinkage void machine_check(void)
  #endif /* CONFIG_X86_MCE */
  asmlinkage void simd_coprocessor_error(void);
  
+ #if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+ asmlinkage void xen_divide_error(void);
+ asmlinkage void xen_xendebug(void);
+ asmlinkage void xen_xenint3(void);
+ asmlinkage void xen_nmi(void);
+ asmlinkage void xen_overflow(void);
+ asmlinkage void xen_bounds(void);
+ asmlinkage void xen_invalid_op(void);
+ asmlinkage void xen_device_not_available(void);
+ asmlinkage void xen_double_fault(void);
+ asmlinkage void xen_coprocessor_segment_overrun(void);
+ asmlinkage void xen_invalid_TSS(void);
+ asmlinkage void xen_segment_not_present(void);
+ asmlinkage void xen_stack_segment(void);
+ asmlinkage void xen_general_protection(void);
+ asmlinkage void xen_page_fault(void);
+ asmlinkage void xen_async_page_fault(void);
+ asmlinkage void xen_spurious_interrupt_bug(void);
+ asmlinkage void xen_coprocessor_error(void);
+ asmlinkage void xen_alignment_check(void);
+ #ifdef CONFIG_X86_MCE
+ asmlinkage void xen_machine_check(void);
+ #endif /* CONFIG_X86_MCE */
+ asmlinkage void xen_simd_coprocessor_error(void);
+ #endif
+ 
  #ifdef CONFIG_TRACING
 -asmlinkage void trace_page_fault(void);
  #define trace_stack_segment stack_segment
  #define trace_divide_error divide_error
  #define trace_bounds bounds
@@@ -53,7 -77,10 +76,11 @@@
  #define trace_alignment_check alignment_check
  #define trace_simd_coprocessor_error simd_coprocessor_error
  #define trace_async_page_fault async_page_fault
 +#define trace_page_fault page_fault
+ 
+ #if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+ asmlinkage void xen_trace_page_fault(void);
+ #endif
  #endif
  
  dotraplinkage void do_divide_error(struct pt_regs *, long);