Re: [PATCH 2/2] mmc: dw_mmc: add resets support to dw_mmc

[Jaehoon Chung]

On 03/29/2016 11:22 AM, Shawn Lin wrote:
> 在 2016/3/25 13:35, Guodong Xu 写道:
>> Hi, Shawn
>>
>> Sorry I replied late. I added comments below.
>>
>> On 6 March 2016 at 22:16, Shawn Lin > > wrote:
>>
>> On 2016/3/6 16:47, Guodong Xu wrote:
>>
>> mmc registers may in abnormal state if mmc is used in bootloader,
>> eg. to support booting from eMMC. So we need reset mmc registers
>> when kernel boots up, instead of assuming mmc is in clean state.
>>
>> With this patch, user can add a 'resets' property into dw_mmc dts
>> node. When driver parse_dt and probe, it calls reset API to
>> deassert the 'reset' of dw_mmc host controller. When probe error or
>> remove, it calls reset API to assert it.
>>
>> Please also refer to
>> Documentation/devicetree/bindings/reset/reset.txt
>>
>> Signed-off-by: Guodong Xu > >
>> Signed-off-by: Xinwei Kong > >
>> Signed-off-by: Zhangfei Gao > >
>>
>>
>> Really should V2 and add the changelog.
>>
>>
>> Yes, will do. next version I sent will be labelled as V3.
>>
>>
>>
>> ---
>>drivers/mmc/host/dw_mmc.c | 22 +-
>>1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 242f9a0..281ea9c 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2878,6 +2878,14 @@ static struct dw_mci_board
>> *dw_mci_parse_dt(struct dw_mci *host)
>>  if (!pdata)
>>  return ERR_PTR(-ENOMEM);
>>
>> +   /* find reset controller when exist */
>> +   pdata->rstc = devm_reset_control_get_optional(dev, NULL);
>> +   if (IS_ERR(pdata->rstc)) {
>> +   if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
>> +   return ERR_PTR(-EPROBE_DEFER);
>> +   pdata->rstc = NULL;
>>
>>
>> maybe we can remove "pdata->rstc = NULL", and directly
>> use IS_ERR(..) for the following "if (host->pdata->rstc != NULL)"
>> statement
>>
>>
>> Yes, will do.
>> I see your point, other lines in this file are using IS_ERR(!..), I will
>> use this style too.
>>
>> +   }
>> +
>>  /* find out number of slots supported */
>>  of_property_read_u32(np, "num-slots", >num_slots);
>>
>> @@ -2949,7 +2957,9 @@ int dw_mci_probe(struct dw_mci *host)
>>
>>  if (!host->pdata) {
>>  host->pdata = dw_mci_parse_dt(host);
>> -   if (IS_ERR(host->pdata)) {
>> +   if (PTR_ERR(host->pdata) == -EPROBE_DEFER)
>> +   return -EPROBE_DEFER;
>>
>>
>> please fix the coding style here.
>>
>>
>> Do you mean to add additional {} for this 'if' , like this?
>>
>> +   if (PTR_ERR(host->pdata) == -EPROBE_DEFER) {
>> +   return -EPROBE_DEFER;
>>
>> +}
>>
>> I will add {}.
>>
>>
>>
>> +   else if (IS_ERR(host->pdata)) {
>>  dev_err(host->dev, "platform data not
>> available\n");
>>  return -EINVAL;
>>  }
>> @@ -3012,6 +3022,9 @@ int dw_mci_probe(struct dw_mci *host)
>>  }
>>  }
>>
>> +   if (host->pdata->rstc != NULL)
>> +   reset_control_deassert(host->pdata->rstc);
>> +
>>
>>
>> sorry, I can't follow your intention here. Shouldn't it be something
>> like "assert mmc -> may need delay -> deassert mmc". As your current
>> code, nothing happend right?
>>
>>
>> The chip exits from bootloader with this bit asserted. And when entering
>> kernel, we only need to deassert.
>>
>> In my current code, the driver deassert mmc in _probe(), and assert mmc
>> in _remove().
> 
> I catch your point. From the previous discussion, we add it to make sure
> dw_mmc in good state after leaving bootloader to kernel. But My real question 
> is that you can assert it in  bootloader, so you can also
> dessert it in bootloaer to make sure dw_mmc work fine when probing
> in kernel. In that way, we don't need this patch?

Doesn't dw_mci_hw_reset work fine? I think that card should be reset with 
MMC_CAP_HW_RESET.
Could you check this?

Best Regards,
Jaehoon Chung

> 
> More to think, Is it ok to match the behaviour of bootloader stage?
> My bootloader doesn't assert the reset pin of dw_mmc, so it seams if
> I want to fix you issue on kernel stage, I need a new 

Re: [PATCH 2/2] mmc: dw_mmc: add resets support to dw_mmc

[Jaehoon Chung]

On 03/29/2016 11:22 AM, Shawn Lin wrote:
> 在 2016/3/25 13:35, Guodong Xu 写道:
>> Hi, Shawn
>>
>> Sorry I replied late. I added comments below.
>>
>> On 6 March 2016 at 22:16, Shawn Lin > > wrote:
>>
>> On 2016/3/6 16:47, Guodong Xu wrote:
>>
>> mmc registers may in abnormal state if mmc is used in bootloader,
>> eg. to support booting from eMMC. So we need reset mmc registers
>> when kernel boots up, instead of assuming mmc is in clean state.
>>
>> With this patch, user can add a 'resets' property into dw_mmc dts
>> node. When driver parse_dt and probe, it calls reset API to
>> deassert the 'reset' of dw_mmc host controller. When probe error or
>> remove, it calls reset API to assert it.
>>
>> Please also refer to
>> Documentation/devicetree/bindings/reset/reset.txt
>>
>> Signed-off-by: Guodong Xu > >
>> Signed-off-by: Xinwei Kong > >
>> Signed-off-by: Zhangfei Gao > >
>>
>>
>> Really should V2 and add the changelog.
>>
>>
>> Yes, will do. next version I sent will be labelled as V3.
>>
>>
>>
>> ---
>>drivers/mmc/host/dw_mmc.c | 22 +-
>>1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 242f9a0..281ea9c 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2878,6 +2878,14 @@ static struct dw_mci_board
>> *dw_mci_parse_dt(struct dw_mci *host)
>>  if (!pdata)
>>  return ERR_PTR(-ENOMEM);
>>
>> +   /* find reset controller when exist */
>> +   pdata->rstc = devm_reset_control_get_optional(dev, NULL);
>> +   if (IS_ERR(pdata->rstc)) {
>> +   if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
>> +   return ERR_PTR(-EPROBE_DEFER);
>> +   pdata->rstc = NULL;
>>
>>
>> maybe we can remove "pdata->rstc = NULL", and directly
>> use IS_ERR(..) for the following "if (host->pdata->rstc != NULL)"
>> statement
>>
>>
>> Yes, will do.
>> I see your point, other lines in this file are using IS_ERR(!..), I will
>> use this style too.
>>
>> +   }
>> +
>>  /* find out number of slots supported */
>>  of_property_read_u32(np, "num-slots", >num_slots);
>>
>> @@ -2949,7 +2957,9 @@ int dw_mci_probe(struct dw_mci *host)
>>
>>  if (!host->pdata) {
>>  host->pdata = dw_mci_parse_dt(host);
>> -   if (IS_ERR(host->pdata)) {
>> +   if (PTR_ERR(host->pdata) == -EPROBE_DEFER)
>> +   return -EPROBE_DEFER;
>>
>>
>> please fix the coding style here.
>>
>>
>> Do you mean to add additional {} for this 'if' , like this?
>>
>> +   if (PTR_ERR(host->pdata) == -EPROBE_DEFER) {
>> +   return -EPROBE_DEFER;
>>
>> +}
>>
>> I will add {}.
>>
>>
>>
>> +   else if (IS_ERR(host->pdata)) {
>>  dev_err(host->dev, "platform data not
>> available\n");
>>  return -EINVAL;
>>  }
>> @@ -3012,6 +3022,9 @@ int dw_mci_probe(struct dw_mci *host)
>>  }
>>  }
>>
>> +   if (host->pdata->rstc != NULL)
>> +   reset_control_deassert(host->pdata->rstc);
>> +
>>
>>
>> sorry, I can't follow your intention here. Shouldn't it be something
>> like "assert mmc -> may need delay -> deassert mmc". As your current
>> code, nothing happend right?
>>
>>
>> The chip exits from bootloader with this bit asserted. And when entering
>> kernel, we only need to deassert.
>>
>> In my current code, the driver deassert mmc in _probe(), and assert mmc
>> in _remove().
> 
> I catch your point. From the previous discussion, we add it to make sure
> dw_mmc in good state after leaving bootloader to kernel. But My real question 
> is that you can assert it in  bootloader, so you can also
> dessert it in bootloaer to make sure dw_mmc work fine when probing
> in kernel. In that way, we don't need this patch?

Doesn't dw_mci_hw_reset work fine? I think that card should be reset with 
MMC_CAP_HW_RESET.
Could you check this?

Best Regards,
Jaehoon Chung

> 
> More to think, Is it ok to match the behaviour of bootloader stage?
> My bootloader doesn't assert the reset pin of dw_mmc, so it seams if
> I want to fix you issue on kernel stage, I need a new round of
> assert->delay->deassert.
> 
> 
>>
>>
>>
>>  setup_timer(>cmd11_timer,
>> 

Re: [LKP] [lkp] [futex] 65d8fc777f: +25.6% will-it-scale.per_process_ops

[Huang, Ying]

Darren Hart  writes:

> On Tue, Mar 29, 2016 at 09:12:56AM +0800, Huang, Ying wrote:
>> Darren Hart  writes:
>> 
>> > On Mon, Mar 21, 2016 at 04:42:47PM +0800, Huang, Ying wrote:
>> >> Thomas Gleixner  writes:
>> >> 
>> >> > On Mon, 21 Mar 2016, Huang, Ying wrote:
>> >> >> >  FYI, we noticed 25.6% performance improvement due to commit
>> >> >> >
>> >> >> >65d8fc777f6d "futex: Remove requirement for lock_page() in 
>> >> >> > get_futex_key()"
>> >> >> >
>> >> >> >  in the will-it-scale.per_process_ops test.
>> >> >> >
>> >> >> >  will-it-scale.per_process_ops tests the futex operations for 
>> >> >> > process shared
>> >> >> >  futexes (Or whatever that test really does).
>> >> >> 
>> >> >> There is a futex sub test case for will-it-scale test suite.  But I 
>> >> >> got your
>> >> >> point, we need some description for the test case.  If email is not too
>> >> >> limited for the full description, we will put it in some web site and
>> >> >> include short description and link to the full description in email.
>> >> >
>> >> > Ok. Just make sure the short description gives enough information for 
>> >> > the
>> >> > casual reader.
>> >> >  
>> >> >> >  The commit has no significant impact on any other test in the test 
>> >> >> > suite.
>> >> >> 
>> >> >> Sorry, we have no enough machine power to test all test cases for each
>> >> >> bisect result.  So we will have no such information until we find a way
>> >> >> to do that.
>> >> >
>> >> > Well, then I really have to ask how I should interpret the data here:
>> >> >
>> >> >5076304 .  0% +25.6%6374220 .  0%  
>> >> > will-it-scale.per_process_ops
>> >> >
>> >> >^^^ That's the reason why you sent the mail in the first place
>> >> >
>> >> >1194117 .  0% +14.4%1366153 .  1%  
>> >> > will-it-scale.per_thread_ops
>> >> >   0.58 .  0%  -2.0%   0.57 .  0%  will-it-scale.scalability
>> >> >   6820 .  0% -19.6%   5483 . 15%  meminfo.AnonHugePages
>> >> >   2652 .  5% -10.4%   2375 .  2%  vmstat.system.cs
>> >> >   2848 . 32%+141.2%   6870 . 65%  
>> >> > numa-meminfo.node1.Active(anon)
>> >> >   2832 . 31% +57.6%   4465 . 27%  
>> >> > numa-meminfo.node1.AnonPages
>> >> >  15018 . 12% -23.3%  11515 . 15%  
>> >> > numa-meminfo.node2.AnonPages
>> >> >   1214 . 14% -22.8% 936.75 . 20%  
>> >> > numa-meminfo.node3.PageTables
>> >> > 712.25 . 32%+141.2%   1718 . 65%  
>> >> > numa-vmstat.node1.nr_active_anon
>> >> > 708.25 . 31% +57.7%   1116 . 27%  
>> >> > numa-vmstat.node1.nr_anon_pages
>> >> >
>> >> > How is this related and what should I do about this information? 
>> >> 
>> >> For each will-it-scale sub test case, it will be run in both process
>> >> mode and thread mode, and task number will change from 1 to CPU number.
>> >> will-it-scale.per_thread_ops shows thread mode main result.
>> >> will-it-scale.scalability is calculated to measure how per_process_ops
>> >> and per_thread_ops scaled along with the task number.  These are default
>> >> behavior of will-it-scale test suite.
>> >> 
>> >> Others are monitors output.  That is, other information collected during
>> >> test.  For example, meminfo is a monitor to sampling /proc/meminfo
>> >> contents,  AnonHugePages is a line in it.  meminfo.AnonHugePages is for
>> >> the average value of AnonHugePages line of /proc/meminfo.  Similarly
>> >> vmstat.system.cs is the average value of cs column of system column
>> >> group of /usr/bin/vmstat.
>> >> 
>> >> We hope these information are helpful for root causing the regression.
>> >> 
>> >> >  If it's important then I have to admit, that I fail to understand why.
>> >> >
>> >> >  If it's not important then I have to ask why is this included.
>> >> >
>> >> >> > So that allows me to reproduce that test more or less with no 
>> >> >> > effort. And
>> >> >> > that's the really important part.
>> >> >> 
>> >> >> For reproducing, now we use lkp-tests tool, which includes scripts to
>> >> >> build the test case, run the test, collect various information, compare
>> >> >> the test result, with the job file attached with the report email.  
>> >> >> That
>> >> >> is not the easiest way, we will continuously improve it.
>> >> >
>> >> > I know and lkp-tests is a pain to work with. So please look into a way 
>> >> > to
>> >> > extract the relevant binaries, so it's simple for developers to 
>> >> > reproduce.
>> >> 
>> >> OK.  We will try to improve on this side.  But it is not an easy task
>> >> for us to provided easy to use simple binaries.  Do you think something
>> >> like Docker image is easy to use?
>> >
>> > Thomas, I presume you are interested in binaries to be positive we're
>> > reproducing with exactly the same bits? I agree that's good to have. I'd 
>> > also
>> > want to have or be pointed to the sources with a straight forward way to
>> > rebuild and to inspect 

Re: [LKP] [lkp] [futex] 65d8fc777f: +25.6% will-it-scale.per_process_ops

[Huang, Ying]

Darren Hart  writes:

> On Tue, Mar 29, 2016 at 09:12:56AM +0800, Huang, Ying wrote:
>> Darren Hart  writes:
>> 
>> > On Mon, Mar 21, 2016 at 04:42:47PM +0800, Huang, Ying wrote:
>> >> Thomas Gleixner  writes:
>> >> 
>> >> > On Mon, 21 Mar 2016, Huang, Ying wrote:
>> >> >> >  FYI, we noticed 25.6% performance improvement due to commit
>> >> >> >
>> >> >> >65d8fc777f6d "futex: Remove requirement for lock_page() in 
>> >> >> > get_futex_key()"
>> >> >> >
>> >> >> >  in the will-it-scale.per_process_ops test.
>> >> >> >
>> >> >> >  will-it-scale.per_process_ops tests the futex operations for 
>> >> >> > process shared
>> >> >> >  futexes (Or whatever that test really does).
>> >> >> 
>> >> >> There is a futex sub test case for will-it-scale test suite.  But I 
>> >> >> got your
>> >> >> point, we need some description for the test case.  If email is not too
>> >> >> limited for the full description, we will put it in some web site and
>> >> >> include short description and link to the full description in email.
>> >> >
>> >> > Ok. Just make sure the short description gives enough information for 
>> >> > the
>> >> > casual reader.
>> >> >  
>> >> >> >  The commit has no significant impact on any other test in the test 
>> >> >> > suite.
>> >> >> 
>> >> >> Sorry, we have no enough machine power to test all test cases for each
>> >> >> bisect result.  So we will have no such information until we find a way
>> >> >> to do that.
>> >> >
>> >> > Well, then I really have to ask how I should interpret the data here:
>> >> >
>> >> >5076304 .  0% +25.6%6374220 .  0%  
>> >> > will-it-scale.per_process_ops
>> >> >
>> >> >^^^ That's the reason why you sent the mail in the first place
>> >> >
>> >> >1194117 .  0% +14.4%1366153 .  1%  
>> >> > will-it-scale.per_thread_ops
>> >> >   0.58 .  0%  -2.0%   0.57 .  0%  will-it-scale.scalability
>> >> >   6820 .  0% -19.6%   5483 . 15%  meminfo.AnonHugePages
>> >> >   2652 .  5% -10.4%   2375 .  2%  vmstat.system.cs
>> >> >   2848 . 32%+141.2%   6870 . 65%  
>> >> > numa-meminfo.node1.Active(anon)
>> >> >   2832 . 31% +57.6%   4465 . 27%  
>> >> > numa-meminfo.node1.AnonPages
>> >> >  15018 . 12% -23.3%  11515 . 15%  
>> >> > numa-meminfo.node2.AnonPages
>> >> >   1214 . 14% -22.8% 936.75 . 20%  
>> >> > numa-meminfo.node3.PageTables
>> >> > 712.25 . 32%+141.2%   1718 . 65%  
>> >> > numa-vmstat.node1.nr_active_anon
>> >> > 708.25 . 31% +57.7%   1116 . 27%  
>> >> > numa-vmstat.node1.nr_anon_pages
>> >> >
>> >> > How is this related and what should I do about this information? 
>> >> 
>> >> For each will-it-scale sub test case, it will be run in both process
>> >> mode and thread mode, and task number will change from 1 to CPU number.
>> >> will-it-scale.per_thread_ops shows thread mode main result.
>> >> will-it-scale.scalability is calculated to measure how per_process_ops
>> >> and per_thread_ops scaled along with the task number.  These are default
>> >> behavior of will-it-scale test suite.
>> >> 
>> >> Others are monitors output.  That is, other information collected during
>> >> test.  For example, meminfo is a monitor to sampling /proc/meminfo
>> >> contents,  AnonHugePages is a line in it.  meminfo.AnonHugePages is for
>> >> the average value of AnonHugePages line of /proc/meminfo.  Similarly
>> >> vmstat.system.cs is the average value of cs column of system column
>> >> group of /usr/bin/vmstat.
>> >> 
>> >> We hope these information are helpful for root causing the regression.
>> >> 
>> >> >  If it's important then I have to admit, that I fail to understand why.
>> >> >
>> >> >  If it's not important then I have to ask why is this included.
>> >> >
>> >> >> > So that allows me to reproduce that test more or less with no 
>> >> >> > effort. And
>> >> >> > that's the really important part.
>> >> >> 
>> >> >> For reproducing, now we use lkp-tests tool, which includes scripts to
>> >> >> build the test case, run the test, collect various information, compare
>> >> >> the test result, with the job file attached with the report email.  
>> >> >> That
>> >> >> is not the easiest way, we will continuously improve it.
>> >> >
>> >> > I know and lkp-tests is a pain to work with. So please look into a way 
>> >> > to
>> >> > extract the relevant binaries, so it's simple for developers to 
>> >> > reproduce.
>> >> 
>> >> OK.  We will try to improve on this side.  But it is not an easy task
>> >> for us to provided easy to use simple binaries.  Do you think something
>> >> like Docker image is easy to use?
>> >
>> > Thomas, I presume you are interested in binaries to be positive we're
>> > reproducing with exactly the same bits? I agree that's good to have. I'd 
>> > also
>> > want to have or be pointed to the sources with a straight forward way to
>> > rebuild and to inspect what exactly the test is doing. (I assume this is
>> > implied, but 

Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

[Joe Perches]

On Tue, 2016-03-29 at 05:37 +, Zheng, Lv wrote:
> Hi,

Hi again.
> > No, I disagree.  _I_ don't need to.  You need to.
> [Lv Zheng] 
> Then you don't have to provide the solution as you are not the one executing 
> the process.
> I can fix it myself:
> https://github.com/acpica/acpica/pull/129 
> It would be merged by the ACPICA upstream in the near future.

Excellent, thank you.

For this: 
https://github.com/acpica/acpica/pull/129/commits/b2294cae776f5a66a7697414b21949d307e6856f

Maybe you could use \w+ instead of [_a-zA-Z0-9]+

> I'll show you the difficulties of "process" later.

ok, appreciate your time.

> > You shouldn't have a process that generates defective patches
> > and then sends them to the list.
> [Lv Zheng] 
> You are not the one executing this process, so you don't know what's 
> happening here.

True.

> Actually the Linux repo should be synced to the state of the ACPICA repo.

That's more doubtful, but then again I don't maintain
ACPICA and you do.

cheers, Joe

Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

[Joe Perches]

On Tue, 2016-03-29 at 05:37 +, Zheng, Lv wrote:
> Hi,

Hi again.
> > No, I disagree.  _I_ don't need to.  You need to.
> [Lv Zheng] 
> Then you don't have to provide the solution as you are not the one executing 
> the process.
> I can fix it myself:
> https://github.com/acpica/acpica/pull/129 
> It would be merged by the ACPICA upstream in the near future.

Excellent, thank you.

For this: 
https://github.com/acpica/acpica/pull/129/commits/b2294cae776f5a66a7697414b21949d307e6856f

Maybe you could use \w+ instead of [_a-zA-Z0-9]+

> I'll show you the difficulties of "process" later.

ok, appreciate your time.

> > You shouldn't have a process that generates defective patches
> > and then sends them to the list.
> [Lv Zheng] 
> You are not the one executing this process, so you don't know what's 
> happening here.

True.

> Actually the Linux repo should be synced to the state of the ACPICA repo.

That's more doubtful, but then again I don't maintain
ACPICA and you do.

cheers, Joe

RE: [PATCH v2 3/6] Documentation: DT: vdma: update binding doc for AXI DMA

[Appana Durga Kedareswara Rao]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, March 29, 2016 2:23 AM
> To: Appana Durga Kedareswara Rao
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek; Soren
> Brinkmann; vinod.k...@intel.com; dan.j.willi...@intel.com; Anurag Kumar
> Vulisha; Appana Durga Kedareswara Rao; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> Vemula; Anirudha Sarangi; dmaeng...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v2 3/6] Documentation: DT: vdma: update binding doc for
> AXI DMA
> 
> On Sun, Mar 27, 2016 at 11:36:05PM +0530, Kedareswara rao Appana wrote:
> > This patch updates the device-tree binding doc for adding support for
> > AXI DMA.
> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v2:
> > ---> Modified commit message as suggested by Vinod.
> > ---> Moved the patch to forward in the series as suggested by vinod.
> >
> >  .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 22
> > +-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > index a86737c..5841421 100644
> > --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > @@ -3,8 +3,13 @@ It can be configured to have one channel or two
> > channels. If configured  as two channels, one is to transmit to the
> > video device and another is  to receive from the video device.
> >
> > +Xilinx AXI DMA engine, it does transfers between memory and AXI4
> > +stream target devices. It can be configured to have one channel or two
> channels.
> > +If configured as two channels, one is to transmit to the device and
> > +another is to receive from the device.
> > +
> >  Required properties:
> > -- compatible: Should be "xlnx,axi-vdma-1.00.a"
> > +- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
> 
> Why the new compatible string? This is 2 different IP blocks? If so, is there 
> really
> much shared?

The support for the AXI DMA IP also added to the existing VDMA Linux driver
In this series of patches.

> 
> >  - #dma-cells: Should be <1>, see "dmas" property below
> >  - reg: Should contain VDMA registers location and length.
> >  - xlnx,num-fstores: Should be the number of framebuffers as configured in
> h/w.
> > @@ -59,6 +64,21 @@ axi_vdma_0: axivdma@4003 {
> > } ;
> >  } ;
> >
> > +axi_dma_0: axidma@4040 {
> 
> dma@4040

Ok will fix in the next version 

Thanks,
Kedar.

> 
> > +   compatible = "xlnx,axi-dma-1.00.a";
> > +   #dma-cells = <1>;
> > +   reg = < 0x4040 0x1 >;
> > +   dma-channel@4040 {
> > +   compatible = "xlnx,axi-dma-mm2s-channel";
> > +   interrupts = < 0 59 4 >;
> > +   xlnx,datawidth = <0x40>;
> > +   } ;
> > +   dma-channel@40400030 {
> > +   compatible = "xlnx,axi-dma-s2mm-channel";
> > +   interrupts = < 0 58 4 >;
> > +   xlnx,datawidth = <0x40>;
> > +   } ;
> > +} ;
> >
> >  * DMA client
> >
> > --
> > 2.1.2
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v2 3/6] Documentation: DT: vdma: update binding doc for AXI DMA

[Appana Durga Kedareswara Rao]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, March 29, 2016 2:23 AM
> To: Appana Durga Kedareswara Rao
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek; Soren
> Brinkmann; vinod.k...@intel.com; dan.j.willi...@intel.com; Anurag Kumar
> Vulisha; Appana Durga Kedareswara Rao; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> Vemula; Anirudha Sarangi; dmaeng...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v2 3/6] Documentation: DT: vdma: update binding doc for
> AXI DMA
> 
> On Sun, Mar 27, 2016 at 11:36:05PM +0530, Kedareswara rao Appana wrote:
> > This patch updates the device-tree binding doc for adding support for
> > AXI DMA.
> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v2:
> > ---> Modified commit message as suggested by Vinod.
> > ---> Moved the patch to forward in the series as suggested by vinod.
> >
> >  .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 22
> > +-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > index a86737c..5841421 100644
> > --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > @@ -3,8 +3,13 @@ It can be configured to have one channel or two
> > channels. If configured  as two channels, one is to transmit to the
> > video device and another is  to receive from the video device.
> >
> > +Xilinx AXI DMA engine, it does transfers between memory and AXI4
> > +stream target devices. It can be configured to have one channel or two
> channels.
> > +If configured as two channels, one is to transmit to the device and
> > +another is to receive from the device.
> > +
> >  Required properties:
> > -- compatible: Should be "xlnx,axi-vdma-1.00.a"
> > +- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
> 
> Why the new compatible string? This is 2 different IP blocks? If so, is there 
> really
> much shared?

The support for the AXI DMA IP also added to the existing VDMA Linux driver
In this series of patches.

> 
> >  - #dma-cells: Should be <1>, see "dmas" property below
> >  - reg: Should contain VDMA registers location and length.
> >  - xlnx,num-fstores: Should be the number of framebuffers as configured in
> h/w.
> > @@ -59,6 +64,21 @@ axi_vdma_0: axivdma@4003 {
> > } ;
> >  } ;
> >
> > +axi_dma_0: axidma@4040 {
> 
> dma@4040

Ok will fix in the next version 

Thanks,
Kedar.

> 
> > +   compatible = "xlnx,axi-dma-1.00.a";
> > +   #dma-cells = <1>;
> > +   reg = < 0x4040 0x1 >;
> > +   dma-channel@4040 {
> > +   compatible = "xlnx,axi-dma-mm2s-channel";
> > +   interrupts = < 0 59 4 >;
> > +   xlnx,datawidth = <0x40>;
> > +   } ;
> > +   dma-channel@40400030 {
> > +   compatible = "xlnx,axi-dma-s2mm-channel";
> > +   interrupts = < 0 58 4 >;
> > +   xlnx,datawidth = <0x40>;
> > +   } ;
> > +} ;
> >
> >  * DMA client
> >
> > --
> > 2.1.2
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v2 5/6] Documentation: DT: vdma: update binding doc for AXI CDMA

[Appana Durga Kedareswara Rao]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, March 29, 2016 2:26 AM
> To: Appana Durga Kedareswara Rao
> Cc: Soren Brinkmann; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek;
> vinod.k...@intel.com; dan.j.willi...@intel.com; Anurag Kumar Vulisha;
> moritz.fisc...@ettus.com; laurent.pinch...@ideasonboard.com;
> l...@debethencourt.com; Srikanth Vemula; Anirudha Sarangi;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; dmaeng...@vger.kernel.org
> Subject: Re: [PATCH v2 5/6] Documentation: DT: vdma: update binding doc for
> AXI CDMA
> 
> On Mon, Mar 28, 2016 at 05:27:01AM +, Appana Durga Kedareswara Rao
> wrote:
> > Hi Soren,
> >
> > > -Original Message-
> > > From: Sören Brinkmann [mailto:soren.brinkm...@xilinx.com]
> > > Sent: Monday, March 28, 2016 12:58 AM
> > > To: Appana Durga Kedareswara Rao
> > > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> > > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek;
> > > vinod.k...@intel.com; dan.j.willi...@intel.com; Anurag Kumar
> > > Vulisha; Appana Durga Kedareswara Rao; moritz.fisc...@ettus.com;
> > > laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> > > Vemula; Anirudha Sarangi; devicet...@vger.kernel.org; linux-arm-
> > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > dmaeng...@vger.kernel.org
> > > Subject: Re: [PATCH v2 5/6] Documentation: DT: vdma: update binding
> > > doc for AXI CDMA
> > >
> > > On Sun, 2016-03-27 at 23:36:06 +0530, Kedareswara rao Appana wrote:
> > > > This patch updates the device-tree binding doc for adding support
> > > > for AXI CDMA.
> > > >
> > > > Signed-off-by: Kedareswara rao Appana 
> > > > ---
> > > > ---> Modified commit message as suggested by Vinod.
> > > > ---> Moved the patch to forward in the series as suggested by vinod.
> > > >
> > > >  .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 18
> > > +-
> > > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > index 5841421..2b0c12b 100644
> > > > --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > @@ -8,8 +8,12 @@ target devices. It can be configured to have one
> > > > channel
> > > or two channels.
> > > >  If configured as two channels, one is to transmit to the device
> > > > and another  is to receive from the device.
> > > >
> > > > +Xilinx AXI CDMA engine, it does transfers between memory-mapped
> > > > +source address and a memory-mapped destination address.
> > > > +
> > > >  Required properties:
> > > > -- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
> > > > +- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
> or
> > > > + "xlnx,axi-cdma-1.00.a""
> > > >  - #dma-cells: Should be <1>, see "dmas" property below
> > > >  - reg: Should contain VDMA registers location and length.
> > > >  - xlnx,num-fstores: Should be the number of framebuffers as
> > > > configured in
> > > h/w.
> > > > @@ -80,6 +84,18 @@ axi_dma_0: axidma@4040 {
> > > > } ;
> > > >  } ;
> > > >
> > > > +axi_cdma_0: axicdma@7e20 {
> > > > +   compatible = "xlnx,axi-cdma-1.00.a";
> > > > +   #dma-cells = <1>;
> > > > +   reg = < 0x7e20 0x1 >;
> > > > +   xlnx,addrwidth = <0x20>;
> > > > +   dma-channel@7e20 {
> > > > +   compatible = "xlnx,axi-dma-mm2s-channel";
> > > > +   interrupts = < 0 55 4 >;
> > > > +   xlnx,datawidth = <0x40>;
> > > > +   } ;
> > > > +} ;
> > >
> > > As in the other patch, the node name should be 'dma-controller@...'
> > > and the inconsistend spacing could be fixed.
> >
> > Ok will fix...
> >
> > >
> > > Also, it seems this adds pretty much identical examples that just
> > > differ in the compat string. Is that really needed?
> >
> > Most of the properties are same across the three DMA's For AXI VDMA
> > there are few required properties that are not required for AXI DMA/CDMA.
> > That's why added example for the other IP's as well I mean for AXI DMA and
> CDMA.
> 
> It needs to be clear what properties are required/valid for each compatible
> string rather than relying on examples. I should be able to write or validate 
> the
> examples based on the rest of the text.

Ok will fix it in the next version of the patch.

Regards,
Kedar.

> 
> Rob

RE: [PATCH v2 5/6] Documentation: DT: vdma: update binding doc for AXI CDMA

[Appana Durga Kedareswara Rao]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, March 29, 2016 2:26 AM
> To: Appana Durga Kedareswara Rao
> Cc: Soren Brinkmann; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek;
> vinod.k...@intel.com; dan.j.willi...@intel.com; Anurag Kumar Vulisha;
> moritz.fisc...@ettus.com; laurent.pinch...@ideasonboard.com;
> l...@debethencourt.com; Srikanth Vemula; Anirudha Sarangi;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; dmaeng...@vger.kernel.org
> Subject: Re: [PATCH v2 5/6] Documentation: DT: vdma: update binding doc for
> AXI CDMA
> 
> On Mon, Mar 28, 2016 at 05:27:01AM +, Appana Durga Kedareswara Rao
> wrote:
> > Hi Soren,
> >
> > > -Original Message-
> > > From: Sören Brinkmann [mailto:soren.brinkm...@xilinx.com]
> > > Sent: Monday, March 28, 2016 12:58 AM
> > > To: Appana Durga Kedareswara Rao
> > > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> > > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek;
> > > vinod.k...@intel.com; dan.j.willi...@intel.com; Anurag Kumar
> > > Vulisha; Appana Durga Kedareswara Rao; moritz.fisc...@ettus.com;
> > > laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> > > Vemula; Anirudha Sarangi; devicet...@vger.kernel.org; linux-arm-
> > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > dmaeng...@vger.kernel.org
> > > Subject: Re: [PATCH v2 5/6] Documentation: DT: vdma: update binding
> > > doc for AXI CDMA
> > >
> > > On Sun, 2016-03-27 at 23:36:06 +0530, Kedareswara rao Appana wrote:
> > > > This patch updates the device-tree binding doc for adding support
> > > > for AXI CDMA.
> > > >
> > > > Signed-off-by: Kedareswara rao Appana 
> > > > ---
> > > > ---> Modified commit message as suggested by Vinod.
> > > > ---> Moved the patch to forward in the series as suggested by vinod.
> > > >
> > > >  .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 18
> > > +-
> > > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > index 5841421..2b0c12b 100644
> > > > --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > @@ -8,8 +8,12 @@ target devices. It can be configured to have one
> > > > channel
> > > or two channels.
> > > >  If configured as two channels, one is to transmit to the device
> > > > and another  is to receive from the device.
> > > >
> > > > +Xilinx AXI CDMA engine, it does transfers between memory-mapped
> > > > +source address and a memory-mapped destination address.
> > > > +
> > > >  Required properties:
> > > > -- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
> > > > +- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
> or
> > > > + "xlnx,axi-cdma-1.00.a""
> > > >  - #dma-cells: Should be <1>, see "dmas" property below
> > > >  - reg: Should contain VDMA registers location and length.
> > > >  - xlnx,num-fstores: Should be the number of framebuffers as
> > > > configured in
> > > h/w.
> > > > @@ -80,6 +84,18 @@ axi_dma_0: axidma@4040 {
> > > > } ;
> > > >  } ;
> > > >
> > > > +axi_cdma_0: axicdma@7e20 {
> > > > +   compatible = "xlnx,axi-cdma-1.00.a";
> > > > +   #dma-cells = <1>;
> > > > +   reg = < 0x7e20 0x1 >;
> > > > +   xlnx,addrwidth = <0x20>;
> > > > +   dma-channel@7e20 {
> > > > +   compatible = "xlnx,axi-dma-mm2s-channel";
> > > > +   interrupts = < 0 55 4 >;
> > > > +   xlnx,datawidth = <0x40>;
> > > > +   } ;
> > > > +} ;
> > >
> > > As in the other patch, the node name should be 'dma-controller@...'
> > > and the inconsistend spacing could be fixed.
> >
> > Ok will fix...
> >
> > >
> > > Also, it seems this adds pretty much identical examples that just
> > > differ in the compat string. Is that really needed?
> >
> > Most of the properties are same across the three DMA's For AXI VDMA
> > there are few required properties that are not required for AXI DMA/CDMA.
> > That's why added example for the other IP's as well I mean for AXI DMA and
> CDMA.
> 
> It needs to be clear what properties are required/valid for each compatible
> string rather than relying on examples. I should be able to write or validate 
> the
> examples based on the rest of the text.

Ok will fix it in the next version of the patch.

Regards,
Kedar.

> 
> Rob

[RESEND][PATCH] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Certain SPI controllers may provide accelerated hardware interface to
read from m25p80 type flash devices in order to provide better read
performance. SPI core supports such devices with spi_flash_read() API.
Call spi_flash_read(), if supported, to make use of such interface.

Signed-off-by: Vignesh R 
---

Resend v5:
Rebased on top of v4.6-rc1
v5: http://www.spinics.net/lists/devicetree/msg106696.html

 drivers/mtd/devices/m25p80.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index c9c3b7fa3051..7730e633d7d3 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, 
size_t len,
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
 
+   if (spi_flash_read_supported(spi)) {
+   struct spi_flash_read_message msg;
+   int ret;
+
+   msg.buf = buf;
+   msg.from = from;
+   msg.len = len;
+   msg.read_opcode = nor->read_opcode;
+   msg.addr_width = nor->addr_width;
+   msg.dummy_bytes = dummy;
+   /* TODO: Support other combinations */
+   msg.opcode_nbits = SPI_NBITS_SINGLE;
+   msg.addr_nbits = SPI_NBITS_SINGLE;
+   msg.data_nbits = m25p80_rx_nbits(nor);
+
+   ret = spi_flash_read(spi, );
+   *retlen = msg.retlen;
+   return ret;
+   }
+
spi_message_init();
memset(t, 0, (sizeof t));
 
-- 
2.7.4

[RESEND][PATCH] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Certain SPI controllers may provide accelerated hardware interface to
read from m25p80 type flash devices in order to provide better read
performance. SPI core supports such devices with spi_flash_read() API.
Call spi_flash_read(), if supported, to make use of such interface.

Signed-off-by: Vignesh R 
---

Resend v5:
Rebased on top of v4.6-rc1
v5: http://www.spinics.net/lists/devicetree/msg106696.html

 drivers/mtd/devices/m25p80.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index c9c3b7fa3051..7730e633d7d3 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, 
size_t len,
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
 
+   if (spi_flash_read_supported(spi)) {
+   struct spi_flash_read_message msg;
+   int ret;
+
+   msg.buf = buf;
+   msg.from = from;
+   msg.len = len;
+   msg.read_opcode = nor->read_opcode;
+   msg.addr_width = nor->addr_width;
+   msg.dummy_bytes = dummy;
+   /* TODO: Support other combinations */
+   msg.opcode_nbits = SPI_NBITS_SINGLE;
+   msg.addr_nbits = SPI_NBITS_SINGLE;
+   msg.data_nbits = m25p80_rx_nbits(nor);
+
+   ret = spi_flash_read(spi, );
+   *retlen = msg.retlen;
+   return ret;
+   }
+
spi_message_init();
memset(t, 0, (sizeof t));
 
-- 
2.7.4

Re: [PATCH 5/6] powerpc/livepatch: Add livepatch stack to struct thread_info

[Balbir Singh]

>> At this point ti->livepatch_sp points to the next CPUs thread_info for 
>> softirq_ctx?
> Sorry I'm not sure what you mean.
>
> None of this relates to the current CPUs thread info.
Oh! I meant that klp_init_thread_info points to the end of (struct thread_info 
{} + 1) in the stack of the thread/task, but with the irq_contexts they are a 
separate array and not on stack
>>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>>> index 3807fb05b6de..1b6cabb8e715 100644
>>> --- a/arch/powerpc/kernel/setup_64.c
>>> +++ b/arch/powerpc/kernel/setup_64.c
>>> @@ -69,6 +69,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #ifdef DEBUG
>>>  #define DBG(fmt...) udbg_printf(fmt)
>>> @@ -667,16 +668,16 @@ static void __init emergency_stack_init(void)
>>> limit = min(safe_stack_limit(), ppc64_rma_size);
>>>  
>>> for_each_possible_cpu(i) {
>>> -   unsigned long sp;
>>> -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
>>> -   sp += THREAD_SIZE;
>>> -   paca[i].emergency_sp = __va(sp);
>>> +   struct thread_info *ti;
>>> +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
>>> +   klp_init_thread_info(ti);
>>> +   paca[i].emergency_sp = (void *)ti + THREAD_SIZE;
>>  
>> Does emergency_sp still end up 128 byte aligned after this?
> It should end up THREAD_SIZE aligned as before, due to the 
> memblock_alloc_base().
Yep.. I missed it.. so where is the space for ti? The stack is going to go grow 
downwards from ti+THREAD_SIZE
>>>  #ifdef CONFIG_PPC_BOOK3S_64
>>> /* emergency stack for machine check exception handling. */
>>> -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
>>> -   sp += THREAD_SIZE;
>>> -   paca[i].mc_emergency_sp = __va(sp);
>>> +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
>>> +   klp_init_thread_info(ti);
>> Do we care about live-patching in this context? Are we mixing per-thread and 
>> per-cpu contexts?
> Well we probably don't want to be doing live patching when we're on the
> emergency stacks. But we have no control over whether that happens so we have
> to support it.
>

OK.. I was wondering if the code will even work.. I wonder if the ftrace data 
structures will work in real mode, including the hash/etc.

Balbir

Re: [PATCH 5/6] powerpc/livepatch: Add livepatch stack to struct thread_info

[Balbir Singh]

>> At this point ti->livepatch_sp points to the next CPUs thread_info for 
>> softirq_ctx?
> Sorry I'm not sure what you mean.
>
> None of this relates to the current CPUs thread info.
Oh! I meant that klp_init_thread_info points to the end of (struct thread_info 
{} + 1) in the stack of the thread/task, but with the irq_contexts they are a 
separate array and not on stack
>>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>>> index 3807fb05b6de..1b6cabb8e715 100644
>>> --- a/arch/powerpc/kernel/setup_64.c
>>> +++ b/arch/powerpc/kernel/setup_64.c
>>> @@ -69,6 +69,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #ifdef DEBUG
>>>  #define DBG(fmt...) udbg_printf(fmt)
>>> @@ -667,16 +668,16 @@ static void __init emergency_stack_init(void)
>>> limit = min(safe_stack_limit(), ppc64_rma_size);
>>>  
>>> for_each_possible_cpu(i) {
>>> -   unsigned long sp;
>>> -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
>>> -   sp += THREAD_SIZE;
>>> -   paca[i].emergency_sp = __va(sp);
>>> +   struct thread_info *ti;
>>> +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
>>> +   klp_init_thread_info(ti);
>>> +   paca[i].emergency_sp = (void *)ti + THREAD_SIZE;
>>  
>> Does emergency_sp still end up 128 byte aligned after this?
> It should end up THREAD_SIZE aligned as before, due to the 
> memblock_alloc_base().
Yep.. I missed it.. so where is the space for ti? The stack is going to go grow 
downwards from ti+THREAD_SIZE
>>>  #ifdef CONFIG_PPC_BOOK3S_64
>>> /* emergency stack for machine check exception handling. */
>>> -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
>>> -   sp += THREAD_SIZE;
>>> -   paca[i].mc_emergency_sp = __va(sp);
>>> +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
>>> +   klp_init_thread_info(ti);
>> Do we care about live-patching in this context? Are we mixing per-thread and 
>> per-cpu contexts?
> Well we probably don't want to be doing live patching when we're on the
> emergency stacks. But we have no control over whether that happens so we have
> to support it.
>

OK.. I was wondering if the code will even work.. I wonder if the ftrace data 
structures will work in real mode, including the hash/etc.

Balbir

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

> OTOH, we should fix it some day, making sure the DTS files are fixed
> first:
>
> imx6qdl-apf6dev.dtsi:   reset-gpio = < 2 GPIO_ACTIVE_HIGH>;
> imx6qdl-aristainetos2.dtsi: reset-gpio = < 16 GPIO_ACTIVE_HIGH>;
> imx6qdl-hummingboard.dtsi:  reset-gpio = < 4 0>; (I think RMK already 
> handles this)
> imx6qdl-phytec-pfla02.dtsi: reset-gpio = < 17 0>;
> imx6qdl-sabresd.dtsi:   reset-gpio = < 12 0>;
> imx6q-dmo-edmqmx6.dts:  reset-gpio = < 8 0>;
> imx6q-novena.dts:   reset-gpio = < 29 GPIO_ACTIVE_HIGH>;
> imx6q-tbs2910.dts:  reset-gpio = < 12 GPIO_ACTIVE_HIGH>;

Or maybe we should simply change these to *_LOW, add that short patch
from me, and forget about it.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

> OTOH, we should fix it some day, making sure the DTS files are fixed
> first:
>
> imx6qdl-apf6dev.dtsi:   reset-gpio = < 2 GPIO_ACTIVE_HIGH>;
> imx6qdl-aristainetos2.dtsi: reset-gpio = < 16 GPIO_ACTIVE_HIGH>;
> imx6qdl-hummingboard.dtsi:  reset-gpio = < 4 0>; (I think RMK already 
> handles this)
> imx6qdl-phytec-pfla02.dtsi: reset-gpio = < 17 0>;
> imx6qdl-sabresd.dtsi:   reset-gpio = < 12 0>;
> imx6q-dmo-edmqmx6.dts:  reset-gpio = < 8 0>;
> imx6q-novena.dts:   reset-gpio = < 29 GPIO_ACTIVE_HIGH>;
> imx6q-tbs2910.dts:  reset-gpio = < 12 GPIO_ACTIVE_HIGH>;

Or maybe we should simply change these to *_LOW, add that short patch
from me, and forget about it.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

Fabio Estevam  writes:

> In order to keep old dtb's working we should simply ignore the GPIO
> flags passed in the 'reset-gpio' property.
>
> That's why we need a revert. Just sent a v2, BTW.

OTOH, we should fix it some day, making sure the DTS files are fixed
first:

imx6qdl-apf6dev.dtsi:   reset-gpio = < 2 GPIO_ACTIVE_HIGH>;
imx6qdl-aristainetos2.dtsi: reset-gpio = < 16 GPIO_ACTIVE_HIGH>;
imx6qdl-hummingboard.dtsi:  reset-gpio = < 4 0>; (I think RMK already 
handles this)
imx6qdl-phytec-pfla02.dtsi: reset-gpio = < 17 0>;
imx6qdl-sabresd.dtsi:   reset-gpio = < 12 0>;
imx6q-dmo-edmqmx6.dts:  reset-gpio = < 8 0>;
imx6q-novena.dts:   reset-gpio = < 29 GPIO_ACTIVE_HIGH>;
imx6q-tbs2910.dts:  reset-gpio = < 12 GPIO_ACTIVE_HIGH>;

The original patch was a bad implementation of a good idea.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

Fabio Estevam  writes:

> In order to keep old dtb's working we should simply ignore the GPIO
> flags passed in the 'reset-gpio' property.
>
> That's why we need a revert. Just sent a v2, BTW.

OTOH, we should fix it some day, making sure the DTS files are fixed
first:

imx6qdl-apf6dev.dtsi:   reset-gpio = < 2 GPIO_ACTIVE_HIGH>;
imx6qdl-aristainetos2.dtsi: reset-gpio = < 16 GPIO_ACTIVE_HIGH>;
imx6qdl-hummingboard.dtsi:  reset-gpio = < 4 0>; (I think RMK already 
handles this)
imx6qdl-phytec-pfla02.dtsi: reset-gpio = < 17 0>;
imx6qdl-sabresd.dtsi:   reset-gpio = < 12 0>;
imx6q-dmo-edmqmx6.dts:  reset-gpio = < 8 0>;
imx6q-novena.dts:   reset-gpio = < 29 GPIO_ACTIVE_HIGH>;
imx6q-tbs2910.dts:  reset-gpio = < 12 GPIO_ACTIVE_HIGH>;

The original patch was a bad implementation of a good idea.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

[James Cameron]

On Tue, Mar 29, 2016 at 12:47:20PM +0800, Wei-Ning Huang wrote:
> "single skb allocation failure" happens when system is under heavy
> memory pressure.  Add __GFP_REPEAT to skb allocation call so kernel
> attempts to reclaim pages and retry the allocation.

Oh, that's interesting, we're back to this symptom again.

Nice to see this fix.

Heavy memory pressure on 3.5 caused dev_alloc_skb failure in this
driver.  Tracked at OLPC as #12694.

-- 
James Cameron
http://quozl.netrek.org/

Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

[James Cameron]

On Tue, Mar 29, 2016 at 12:47:20PM +0800, Wei-Ning Huang wrote:
> "single skb allocation failure" happens when system is under heavy
> memory pressure.  Add __GFP_REPEAT to skb allocation call so kernel
> attempts to reclaim pages and retry the allocation.

Oh, that's interesting, we're back to this symptom again.

Nice to see this fix.

Heavy memory pressure on 3.5 caused dev_alloc_skb failure in this
driver.  Tracked at OLPC as #12694.

-- 
James Cameron
http://quozl.netrek.org/

RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

[Zheng, Lv]

Hi,

> From: Joe Perches [mailto:j...@perches.com]
> Subject: Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212
> release
> 
> On Mon, 2016-03-28 at 03:02 +, Zheng, Lv wrote:
> > Hi,
> 
> Hello.
> 
> > > So why not fix the process script first?
> > > Maybe add something like:
> > > $ grep -E "^typedef\s+\w+\s*\*?\s*acpi_\w+" include/acpi/actypes.h | \
> > >   grep -Eoh "\bacpi_\w+"
> > >
> > > to the acpi_types variable in the lindent_single function
> > [Lv Zheng]
> > I don't think this can work given:
> > 1. we are not only dealing with typedefs, but structs, struct xxx will be
> converted into types during the release process.
> > 2. we have only upper cased type names in ACPICA upstream, but have the
> lower cased type names in Linux, and this doesn't solve that.
> > So I guess you didn't test your idea.
> 
> Good guess.
> 
> The "maybe add something like" should give you a clue.
> 
> > You need to pull ACPICA repo and do the followings to confirm if this is
> working:
> 
> No, I disagree.  _I_ don't need to.  You need to.
[Lv Zheng] 
Then you don't have to provide the solution as you are not the one executing 
the process.
I can fix it myself:
https://github.com/acpica/acpica/pull/129 
It would be merged by the ACPICA upstream in the near future.

I'll show you the difficulties of "process" later.

> 
> You shouldn't have a process that generates defective patches
> and then sends them to the list.
[Lv Zheng] 
You are not the one executing this process, so you don't know what's happening 
here.

Actually the Linux repo should be synced to the state of the ACPICA repo.
The defective patch is used for "syncing repo state", not for "fixing 
indentation problem" or something else.
So if we merged a "process fixing commit" into ACPICA upstream, you'll still 
have to see such kind of defective patches before this commit because of the 
state synchronization requirement.

There have already been many such indentation conflicts between Linux and 
ACPICA.
My current rule on the existing unsynced Linux side code conflict is based on 
the "syncing repo state" purpose:
I'll ignore them as long as no new linuxized ACPICA commits complain merge 
conflicts.
But if I saw merge conflict to a new linuxized commit, I'll revert the Linux 
side code to the __wrong__ but synced state in a separate patch.
That's why you can see this commit.

As a conclusion, the defective patch is because of the purpose - syncing repo 
state.
Then why do I use a separate patch?

The separated defective patch is the only patch we need to maintain manually, 
and all other linuxized ACPICA results needn't be maintained manually.
So you can imagine that we can do the recursive development/testing in the 
ACPICA upstream again and again.
And the linuxizing result should always require no human intervention as long 
as they can appear after the defective patch.

I have several situations for you to know my work flow.
1. ACPICA release
If this is not separated, then I should merge part of the defective patch into 
the new linuxized ACPICA commit that generates the merge conflict.
This is a kind of so called "human intervention".
Then if a bug was found after the release testing work (may take several days) 
was done, I would have to linuxize the whole series again after fixing the bug 
from the ACPICA upstream.
This results in a redo of the "human intervention". And this kind of "human 
intervention" may spread to all commits after the fixed one.
Furthermore, the "human intervention" could happen again and again during the 
recursive release testing process.

There are similar cases:
2. Fast path ACPICA commits
We have something that can't be confirmed from ACPICA development environment, 
and they need to go Linux repo first.
Such kind of patch series also contain such a separated defective patch.
If this is not separated, then since the series need to be rebased again and 
again during the development process (because of bug fixing or Linux upstream 
sync).
Then the "human intervention" need to be performed again and again.

3. The "process fixing commit"
If this problem is fixed, I need the Linux side correction to happen only when 
this commit is about to enter linux repo.
Otherwise, all commits between the merge point of this commit and the current 
repo head need "human interventions".
Sometimes, these commits need to be linuxized and posted on the 
Bugzilla/community to have users to test them.
As the working kernel of the reporters or the developers are different, the 
"human interventions" have to be performed again and again for them.
And there will be many different versions of such kind of linuxized ACPICA 
patch series. 
It's not convenient for everyone.

So you can sense, the workload of the "human intervention" depends on the 
following 2 facts:
1. How worse the "unsynced state" is in the current Linux repo, and this also 
depends on how big the linuxized "process fixing commit" will be.
2. The merge timing of 

RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

[Zheng, Lv]

Hi,

> From: Joe Perches [mailto:j...@perches.com]
> Subject: Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212
> release
> 
> On Mon, 2016-03-28 at 03:02 +, Zheng, Lv wrote:
> > Hi,
> 
> Hello.
> 
> > > So why not fix the process script first?
> > > Maybe add something like:
> > > $ grep -E "^typedef\s+\w+\s*\*?\s*acpi_\w+" include/acpi/actypes.h | \
> > >   grep -Eoh "\bacpi_\w+"
> > >
> > > to the acpi_types variable in the lindent_single function
> > [Lv Zheng]
> > I don't think this can work given:
> > 1. we are not only dealing with typedefs, but structs, struct xxx will be
> converted into types during the release process.
> > 2. we have only upper cased type names in ACPICA upstream, but have the
> lower cased type names in Linux, and this doesn't solve that.
> > So I guess you didn't test your idea.
> 
> Good guess.
> 
> The "maybe add something like" should give you a clue.
> 
> > You need to pull ACPICA repo and do the followings to confirm if this is
> working:
> 
> No, I disagree.  _I_ don't need to.  You need to.
[Lv Zheng] 
Then you don't have to provide the solution as you are not the one executing 
the process.
I can fix it myself:
https://github.com/acpica/acpica/pull/129 
It would be merged by the ACPICA upstream in the near future.

I'll show you the difficulties of "process" later.

> 
> You shouldn't have a process that generates defective patches
> and then sends them to the list.
[Lv Zheng] 
You are not the one executing this process, so you don't know what's happening 
here.

Actually the Linux repo should be synced to the state of the ACPICA repo.
The defective patch is used for "syncing repo state", not for "fixing 
indentation problem" or something else.
So if we merged a "process fixing commit" into ACPICA upstream, you'll still 
have to see such kind of defective patches before this commit because of the 
state synchronization requirement.

There have already been many such indentation conflicts between Linux and 
ACPICA.
My current rule on the existing unsynced Linux side code conflict is based on 
the "syncing repo state" purpose:
I'll ignore them as long as no new linuxized ACPICA commits complain merge 
conflicts.
But if I saw merge conflict to a new linuxized commit, I'll revert the Linux 
side code to the __wrong__ but synced state in a separate patch.
That's why you can see this commit.

As a conclusion, the defective patch is because of the purpose - syncing repo 
state.
Then why do I use a separate patch?

The separated defective patch is the only patch we need to maintain manually, 
and all other linuxized ACPICA results needn't be maintained manually.
So you can imagine that we can do the recursive development/testing in the 
ACPICA upstream again and again.
And the linuxizing result should always require no human intervention as long 
as they can appear after the defective patch.

I have several situations for you to know my work flow.
1. ACPICA release
If this is not separated, then I should merge part of the defective patch into 
the new linuxized ACPICA commit that generates the merge conflict.
This is a kind of so called "human intervention".
Then if a bug was found after the release testing work (may take several days) 
was done, I would have to linuxize the whole series again after fixing the bug 
from the ACPICA upstream.
This results in a redo of the "human intervention". And this kind of "human 
intervention" may spread to all commits after the fixed one.
Furthermore, the "human intervention" could happen again and again during the 
recursive release testing process.

There are similar cases:
2. Fast path ACPICA commits
We have something that can't be confirmed from ACPICA development environment, 
and they need to go Linux repo first.
Such kind of patch series also contain such a separated defective patch.
If this is not separated, then since the series need to be rebased again and 
again during the development process (because of bug fixing or Linux upstream 
sync).
Then the "human intervention" need to be performed again and again.

3. The "process fixing commit"
If this problem is fixed, I need the Linux side correction to happen only when 
this commit is about to enter linux repo.
Otherwise, all commits between the merge point of this commit and the current 
repo head need "human interventions".
Sometimes, these commits need to be linuxized and posted on the 
Bugzilla/community to have users to test them.
As the working kernel of the reporters or the developers are different, the 
"human interventions" have to be performed again and again for them.
And there will be many different versions of such kind of linuxized ACPICA 
patch series. 
It's not convenient for everyone.

So you can sense, the workload of the "human intervention" depends on the 
following 2 facts:
1. How worse the "unsynced state" is in the current Linux repo, and this also 
depends on how big the linuxized "process fixing commit" will be.
2. The merge timing of 

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

Tim Harvey  writes:

> It's not too easy to tell how many IMX6 boards incorrectly specify
> their reset-gpio polarity. I don't know what the best way to determine
> what boards use the IMX6 pcie host controller. Is there a dtc usage
> that will display the compiled dtb's then we grep out 'compatible =
> "fsl,imx6q-pcie"' to at least get the list of boards to inspect? I'm
> curious if its just one or two boards that incorrectly specify the
> polarity of their PCI reset.

I guess, maybe 8 of them. Not counting those with out-of-tree DTS/DTB
files.

Something like:
$ grep reset-gpio arch/arm/boot/dts/imx6* | grep -v phy-reset

> I figured out it was the change to enable CONFIG_PCI_MSI in v4.5 that
> is causing interrupts to fail for me.

Right, a long standing issue. MSI never worked for me on i.MX6.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

Tim Harvey  writes:

> It's not too easy to tell how many IMX6 boards incorrectly specify
> their reset-gpio polarity. I don't know what the best way to determine
> what boards use the IMX6 pcie host controller. Is there a dtc usage
> that will display the compiled dtb's then we grep out 'compatible =
> "fsl,imx6q-pcie"' to at least get the list of boards to inspect? I'm
> curious if its just one or two boards that incorrectly specify the
> polarity of their PCI reset.

I guess, maybe 8 of them. Not counting those with out-of-tree DTS/DTB
files.

Something like:
$ grep reset-gpio arch/arm/boot/dts/imx6* | grep -v phy-reset

> I figured out it was the change to enable CONFIG_PCI_MSI in v4.5 that
> is causing interrupts to fail for me.

Right, a long standing issue. MSI never worked for me on i.MX6.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH 6/6] powerpc/livepatch: Add live patching support on ppc64le

[Michael Ellerman]

On Thu, 2016-03-24 at 14:42 +0100, Torsten Duwe wrote:

> On Thu, Mar 24, 2016 at 10:04:05PM +1100, Michael Ellerman wrote:

> > +livepatch_handler:
> > +   CURRENT_THREAD_INFO(r12, r1)
> [...]

> > +   /* Put ctr in r12 for global entry and branch there */
> > +   mfctr   r12
> > +   bctrl
> ^
> I like this piece. No need to fiddle out the return helper address.

Good.

> > +   /*
> > +* Now we are returning from the patched function to the original
> > +* caller A. We are free to use r0 and r12, and we can use r2 until we
> > +* restore it.
> > +*/
> > +
> > +   CURRENT_THREAD_INFO(r12, r1)
> > +
> > +   /* Save stack pointer into r0 */
> > +   mr  r0, r1
> > +
> > +   ld  r1, TI_livepatch_sp(r12)
> > +
> > +   /* Check stack marker hasn't been trashed */
> > +   lis r2,  STACK_END_MAGIC@h
> > +   ori r2,  r2, STACK_END_MAGIC@l
> > +   ld  r12, -8(r1)
> > +1: tdner12, r2
> > +   EMIT_BUG_ENTRY 1b, __FILE__, __LINE__ - 1, 0
> 
> This however worries me a bit. Sure, in the end, a stack overflow is
> a stack overflow, and if all the information does not fit there,
> there's little you can do.

Yeah stack overflow in the kernel is very very fatal.

> But wouldn't it be better to kmalloc that area and realloc in
> klp_arch_set_pc when it's full? Maybe along with a warning message?

You can't realloc in klp_arch_set_pc(), you might be patching sl*b and holding
one of its locks. You might also recurse.

We could allocate a larger buffer as a "klp stack" for each task when the first
live patch is installed, and for every task created afterward. But that
potentially significantly increases memory usage on live patched kernels :)

> That way a live patched kernel will not run into stack size problems
> any earlier than an unpatched kernel would.

Yeah that's true. I'm not sure what the best trade off is.

cheers

Re: [PATCH 6/6] powerpc/livepatch: Add live patching support on ppc64le

[Michael Ellerman]

On Thu, 2016-03-24 at 14:42 +0100, Torsten Duwe wrote:

> On Thu, Mar 24, 2016 at 10:04:05PM +1100, Michael Ellerman wrote:

> > +livepatch_handler:
> > +   CURRENT_THREAD_INFO(r12, r1)
> [...]

> > +   /* Put ctr in r12 for global entry and branch there */
> > +   mfctr   r12
> > +   bctrl
> ^
> I like this piece. No need to fiddle out the return helper address.

Good.

> > +   /*
> > +* Now we are returning from the patched function to the original
> > +* caller A. We are free to use r0 and r12, and we can use r2 until we
> > +* restore it.
> > +*/
> > +
> > +   CURRENT_THREAD_INFO(r12, r1)
> > +
> > +   /* Save stack pointer into r0 */
> > +   mr  r0, r1
> > +
> > +   ld  r1, TI_livepatch_sp(r12)
> > +
> > +   /* Check stack marker hasn't been trashed */
> > +   lis r2,  STACK_END_MAGIC@h
> > +   ori r2,  r2, STACK_END_MAGIC@l
> > +   ld  r12, -8(r1)
> > +1: tdner12, r2
> > +   EMIT_BUG_ENTRY 1b, __FILE__, __LINE__ - 1, 0
> 
> This however worries me a bit. Sure, in the end, a stack overflow is
> a stack overflow, and if all the information does not fit there,
> there's little you can do.

Yeah stack overflow in the kernel is very very fatal.

> But wouldn't it be better to kmalloc that area and realloc in
> klp_arch_set_pc when it's full? Maybe along with a warning message?

You can't realloc in klp_arch_set_pc(), you might be patching sl*b and holding
one of its locks. You might also recurse.

We could allocate a larger buffer as a "klp stack" for each task when the first
live patch is installed, and for every task created afterward. But that
potentially significantly increases memory usage on live patched kernels :)

> That way a live patched kernel will not run into stack size problems
> any earlier than an unpatched kernel would.

Yeah that's true. I'm not sure what the best trade off is.

cheers

Re: [PART1 RFC v3 02/12] KVM: x86: Introducing kvm_x86_ops VM init/uninit hooks

[Suravee Suthikulpanit]

Hi Paolo,

On 3/18/16 17:11, Paolo Bonzini wrote:


On 18/03/2016 07:09, Suravee Suthikulpanit wrote:

>Adding function pointers in struct kvm_x86_ops for processor-specific
>layer to provide hooks for when KVM initialize and un-initialize VM.

This is not the only thing your patch is doing, and the "other" change
definitely needs a lot more explanation about why you did it and how you
audited the code to ensure that it is safe.

Paolo



Sorry, for not mentioning this earlier. I am moving the 
kvm_arch_init_vm() call mainly to go after mutex_init(>slots_lock) 
since I am calling the x86_set_memory_region() (which uses slots_lock) 
in the vm_init() hooks (for AVIC initialization).


Lemme re-check if this would be safe for other code.

Thanks,
Suravee

Re: [PART1 RFC v3 02/12] KVM: x86: Introducing kvm_x86_ops VM init/uninit hooks

[Suravee Suthikulpanit]

Hi Paolo,

On 3/18/16 17:11, Paolo Bonzini wrote:


On 18/03/2016 07:09, Suravee Suthikulpanit wrote:

>Adding function pointers in struct kvm_x86_ops for processor-specific
>layer to provide hooks for when KVM initialize and un-initialize VM.

This is not the only thing your patch is doing, and the "other" change
definitely needs a lot more explanation about why you did it and how you
audited the code to ensure that it is safe.

Paolo



Sorry, for not mentioning this earlier. I am moving the 
kvm_arch_init_vm() call mainly to go after mutex_init(>slots_lock) 
since I am calling the x86_set_memory_region() (which uses slots_lock) 
in the vm_init() hooks (for AVIC initialization).


Lemme re-check if this would be safe for other code.

Thanks,
Suravee

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

[Darren Hart]

On Mon, Mar 28, 2016 at 09:41:09PM +0200, Gabriele Mazzotta wrote:
> 2016-03-28 20:56 GMT+02:00 Darren Hart :
> > On Mon, Mar 28, 2016 at 07:58:09PM +0200, Gabriele Mazzotta wrote:
> >> 2016-03-28 19:33 GMT+02:00 Darren Hart :
> >> > On Thu, Mar 24, 2016 at 12:24:56PM +0100, Gabriele Mazzotta wrote:
> >> >> 2016-03-24 10:39 GMT+01:00 Pali Rohár :
> >> >> > On Monday 21 March 2016 16:13:34 Gabriele Mazzotta wrote:
> >> >> >> 2016-03-21 13:17 GMT+01:00 Pali Rohár :
> >> >> >> > On Friday 18 March 2016 23:44:23 Gabriele Mazzotta wrote:
> >> >> >> >> +#ifdef CONFIG_PM_SLEEP
> >> >> >> >> +static void ACPI_SYSTEM_XFACE rbtn_acpi_clear_flag(void *context)
> >> >> >> >> +{
> >> >> >> >> + struct rbtn_data *rbtn_data = context;
> >> >> >> >> +
> >> >> >> >> + rbtn_data->suspended = false;
> >> >> >> >> +}
> >> >> >> >> +
> >> >> >> >> +static int rbtn_suspend(struct device *dev)
> >> >> >> >> +{
> >> >> >> >> + struct acpi_device *device = to_acpi_device(dev);
> >> >> >> >> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> >> >> >> >> +
> >> >> >> >> + rbtn_data->suspended = true;
> >> >> >> >> +
> >> >> >> >> + return 0;
> >> >> >> >> +}
> >> >> >> >> +
> >> >> >> >> +static int rbtn_resume(struct device *dev)
> >> >> >> >> +{
> >> >> >> >> + struct acpi_device *device = to_acpi_device(dev);
> >> >> >> >> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> >> >> >> >> + acpi_status status;
> >> >> >> >> +
> >> >> >> >> + /*
> >> >> >> >> +  * Clear the flag only after we received the extra
> >> >> >> >> +  * ACPI notification.
> >> >> >> >> +  */
> >> >> >> >> + status = acpi_os_execute(OSL_NOTIFY_HANDLER,
> >> >> >> >> +  rbtn_acpi_clear_flag, rbtn_data);
> >> >> >> >> + if (ACPI_FAILURE(status))
> >> >> >> >> + rbtn_data->suspended = false;
> >> >> >> >
> >> >> >> > I case when acpi_os_execute success it calls rbtn_acpi_clear_flag,
> >> >> >> > right? And that will set suspended to false. When acpi_os_execute 
> >> >> >> > fails,
> >> >> >> > then it set suspended too to false... Then whole acpi_os_execute 
> >> >> >> > doing
> >> >> >> > just "barrier" after which suspended flag can be set to false. So I
> >> >> >> > think rbtn_acpi_clear_flag function is not needed here.
> >> >> >> >
> >> >> >> > Cannot you pass NULL or empty function pointer as callback? Or 
> >> >> >> > what was
> >> >> >> > reason to do that flag clearing at "two places"?
> >> >> >>
> >> >> >> acpi_os_execute doesn't wait for the callback to be executed, so
> >> >> >> I can't clear the flag from rbtn_resume.
> >> >> >
> >> >> > acpi_os_execute calls callback asynchronously later? Or what exactly 
> >> >> > do it?
> >> >>
> >> >> In this case, it adds the callback to the kacpi_notify_wq workqueue
> >> >> for deferred execution.
> >> >
> >> > +Rafael for context/advice on the use of acpi_os_execute here.
> >> >
> >> > This is true, but a quick scan through that call path doesn't tell me 
> >> > why we
> >> > would need to call it here instead of just setting rbtn_data->suspended 
> >> > = false.
> >> > The comment suggests waiting for the event, but is that what this is 
> >> > doing? It
> >> > appears to me to be immediately scheduling the function to a work queue, 
> >> > not
> >> > waiting for the event notifier.
> >> >
> >> > Also, since there is no indication to the user that a failure occurs, 
> >> > this
> >> > function is basically equivalent in the success and failure case (the 
> >> > success
> >> > case is just slower).
> >> >
> >> > Am I missing something critical here?
> >>
> >> Maybe saying that we are waiting for the extra event is not really
> >> correct. Since the extra ACPI notification is processed by means
> >> of kacpi_notify_wq, or at least that's my understanding, our callback
> >> is likely going to be executed after we received the extra ACPI
> >> notification. This was suggested by Rafael [2].
> >
> > I see, the workqueue is run after the event is issued. If that's the case, 
> > how
> > are we ensured that it will get cleared? Isn't it only some systems that 
> > have
> > this problem?
> >
> > What happens to the systems that do not send this event at resume? Does the
> > suspended flag remain set?
> 
> The callback should be executed as long as acpi_os_execute doesn't
> return an error. If the BIOS doesn't send the extra notification,
> we uselessly wait for whatever was queued before our callback.
> 
> On my laptop, the interval between the call to acpi_os_execute and
> the callback execution is ~200ms (rough existimation using a couple
> of printks), so not really noticeable. It might be more on some other
> systems, but I doubt anyone would notice.

And what triggers the callback then? Some unrelated event triggering the
workqueue I presume? I don't care to tie the masking of these events to
unrelated ones. What 

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

[Darren Hart]

On Mon, Mar 28, 2016 at 09:41:09PM +0200, Gabriele Mazzotta wrote:
> 2016-03-28 20:56 GMT+02:00 Darren Hart :
> > On Mon, Mar 28, 2016 at 07:58:09PM +0200, Gabriele Mazzotta wrote:
> >> 2016-03-28 19:33 GMT+02:00 Darren Hart :
> >> > On Thu, Mar 24, 2016 at 12:24:56PM +0100, Gabriele Mazzotta wrote:
> >> >> 2016-03-24 10:39 GMT+01:00 Pali Rohár :
> >> >> > On Monday 21 March 2016 16:13:34 Gabriele Mazzotta wrote:
> >> >> >> 2016-03-21 13:17 GMT+01:00 Pali Rohár :
> >> >> >> > On Friday 18 March 2016 23:44:23 Gabriele Mazzotta wrote:
> >> >> >> >> +#ifdef CONFIG_PM_SLEEP
> >> >> >> >> +static void ACPI_SYSTEM_XFACE rbtn_acpi_clear_flag(void *context)
> >> >> >> >> +{
> >> >> >> >> + struct rbtn_data *rbtn_data = context;
> >> >> >> >> +
> >> >> >> >> + rbtn_data->suspended = false;
> >> >> >> >> +}
> >> >> >> >> +
> >> >> >> >> +static int rbtn_suspend(struct device *dev)
> >> >> >> >> +{
> >> >> >> >> + struct acpi_device *device = to_acpi_device(dev);
> >> >> >> >> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> >> >> >> >> +
> >> >> >> >> + rbtn_data->suspended = true;
> >> >> >> >> +
> >> >> >> >> + return 0;
> >> >> >> >> +}
> >> >> >> >> +
> >> >> >> >> +static int rbtn_resume(struct device *dev)
> >> >> >> >> +{
> >> >> >> >> + struct acpi_device *device = to_acpi_device(dev);
> >> >> >> >> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> >> >> >> >> + acpi_status status;
> >> >> >> >> +
> >> >> >> >> + /*
> >> >> >> >> +  * Clear the flag only after we received the extra
> >> >> >> >> +  * ACPI notification.
> >> >> >> >> +  */
> >> >> >> >> + status = acpi_os_execute(OSL_NOTIFY_HANDLER,
> >> >> >> >> +  rbtn_acpi_clear_flag, rbtn_data);
> >> >> >> >> + if (ACPI_FAILURE(status))
> >> >> >> >> + rbtn_data->suspended = false;
> >> >> >> >
> >> >> >> > I case when acpi_os_execute success it calls rbtn_acpi_clear_flag,
> >> >> >> > right? And that will set suspended to false. When acpi_os_execute 
> >> >> >> > fails,
> >> >> >> > then it set suspended too to false... Then whole acpi_os_execute 
> >> >> >> > doing
> >> >> >> > just "barrier" after which suspended flag can be set to false. So I
> >> >> >> > think rbtn_acpi_clear_flag function is not needed here.
> >> >> >> >
> >> >> >> > Cannot you pass NULL or empty function pointer as callback? Or 
> >> >> >> > what was
> >> >> >> > reason to do that flag clearing at "two places"?
> >> >> >>
> >> >> >> acpi_os_execute doesn't wait for the callback to be executed, so
> >> >> >> I can't clear the flag from rbtn_resume.
> >> >> >
> >> >> > acpi_os_execute calls callback asynchronously later? Or what exactly 
> >> >> > do it?
> >> >>
> >> >> In this case, it adds the callback to the kacpi_notify_wq workqueue
> >> >> for deferred execution.
> >> >
> >> > +Rafael for context/advice on the use of acpi_os_execute here.
> >> >
> >> > This is true, but a quick scan through that call path doesn't tell me 
> >> > why we
> >> > would need to call it here instead of just setting rbtn_data->suspended 
> >> > = false.
> >> > The comment suggests waiting for the event, but is that what this is 
> >> > doing? It
> >> > appears to me to be immediately scheduling the function to a work queue, 
> >> > not
> >> > waiting for the event notifier.
> >> >
> >> > Also, since there is no indication to the user that a failure occurs, 
> >> > this
> >> > function is basically equivalent in the success and failure case (the 
> >> > success
> >> > case is just slower).
> >> >
> >> > Am I missing something critical here?
> >>
> >> Maybe saying that we are waiting for the extra event is not really
> >> correct. Since the extra ACPI notification is processed by means
> >> of kacpi_notify_wq, or at least that's my understanding, our callback
> >> is likely going to be executed after we received the extra ACPI
> >> notification. This was suggested by Rafael [2].
> >
> > I see, the workqueue is run after the event is issued. If that's the case, 
> > how
> > are we ensured that it will get cleared? Isn't it only some systems that 
> > have
> > this problem?
> >
> > What happens to the systems that do not send this event at resume? Does the
> > suspended flag remain set?
> 
> The callback should be executed as long as acpi_os_execute doesn't
> return an error. If the BIOS doesn't send the extra notification,
> we uselessly wait for whatever was queued before our callback.
> 
> On my laptop, the interval between the call to acpi_os_execute and
> the callback execution is ~200ms (rough existimation using a couple
> of printks), so not really noticeable. It might be more on some other
> systems, but I doubt anyone would notice.

And what triggers the callback then? Some unrelated event triggering the
workqueue I presume? I don't care to tie the masking of these events to
unrelated ones. What guarantee do we have that they will fire? Is it possible
for that workqueue to be otherwise 

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

Tim Harvey  writes:

> ok - I'll respond there as I agree with the patch but not the wording
> of the commit (It's Gateworks 'Ventana' using IMX6 not Laguna and we
> do define the polarity properly as active-low in Ventana dt's).

Right, it's Ventana of course (I had been working with Laguna boards
recently).

> However, there seems to be another regression in 4.5 that's keeping
> PCI working for me and I'm still bisecting that (using 802.11n access
> points to test). Can you confirm that PCI works in v4.5 on IMX6 boards
> with only 5c5fb40de8f14391a1238db05cef88754faf9229 reverted?

I will check with my frame buffer and wifi cards.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

[Krzysztof Hałasa]

Tim Harvey  writes:

> ok - I'll respond there as I agree with the patch but not the wording
> of the commit (It's Gateworks 'Ventana' using IMX6 not Laguna and we
> do define the polarity properly as active-low in Ventana dt's).

Right, it's Ventana of course (I had been working with Laguna boards
recently).

> However, there seems to be another regression in 4.5 that's keeping
> PCI working for me and I'm still bisecting that (using 802.11n access
> points to test). Can you confirm that PCI works in v4.5 on IMX6 boards
> with only 5c5fb40de8f14391a1238db05cef88754faf9229 reverted?

I will check with my frame buffer and wifi cards.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH 5/6] powerpc/livepatch: Add livepatch stack to struct thread_info

[Michael Ellerman]

On Tue, 2016-03-29 at 10:58 +1100, Balbir Singh wrote:
> On 24/03/16 22:04, Michael Ellerman wrote:
> > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> > index 290559df1e8b..3cb46a3b1de7 100644
> > --- a/arch/powerpc/kernel/irq.c
> > +++ b/arch/powerpc/kernel/irq.c
> > @@ -66,6 +66,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef CONFIG_PPC64
> >  #include 
> > @@ -607,10 +608,12 @@ void irq_ctx_init(void)
> > memset((void *)softirq_ctx[i], 0, THREAD_SIZE);
> > tp = softirq_ctx[i];
> > tp->cpu = i;
> > +   klp_init_thread_info(tp);

> At this point ti->livepatch_sp points to the next CPUs thread_info for 
> softirq_ctx?

Sorry I'm not sure what you mean.

None of this relates to the current CPUs thread info.

> > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> > index 3807fb05b6de..1b6cabb8e715 100644
> > --- a/arch/powerpc/kernel/setup_64.c
> > +++ b/arch/powerpc/kernel/setup_64.c
> > @@ -69,6 +69,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef DEBUG
> >  #define DBG(fmt...) udbg_printf(fmt)
> > @@ -667,16 +668,16 @@ static void __init emergency_stack_init(void)
> > limit = min(safe_stack_limit(), ppc64_rma_size);
> >  
> > for_each_possible_cpu(i) {
> > -   unsigned long sp;
> > -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
> > -   sp += THREAD_SIZE;
> > -   paca[i].emergency_sp = __va(sp);
> > +   struct thread_info *ti;
> > +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
> > +   klp_init_thread_info(ti);
> > +   paca[i].emergency_sp = (void *)ti + THREAD_SIZE;
>  
> Does emergency_sp still end up 128 byte aligned after this?

It should end up THREAD_SIZE aligned as before, due to the 
memblock_alloc_base().

> >  #ifdef CONFIG_PPC_BOOK3S_64
> > /* emergency stack for machine check exception handling. */
> > -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
> > -   sp += THREAD_SIZE;
> > -   paca[i].mc_emergency_sp = __va(sp);
> > +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
> > +   klp_init_thread_info(ti);

> Do we care about live-patching in this context? Are we mixing per-thread and 
> per-cpu contexts?

Well we probably don't want to be doing live patching when we're on the
emergency stacks. But we have no control over whether that happens so we have
to support it.

cheers

Re: [PATCH 5/6] powerpc/livepatch: Add livepatch stack to struct thread_info

[Michael Ellerman]

On Tue, 2016-03-29 at 10:58 +1100, Balbir Singh wrote:
> On 24/03/16 22:04, Michael Ellerman wrote:
> > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> > index 290559df1e8b..3cb46a3b1de7 100644
> > --- a/arch/powerpc/kernel/irq.c
> > +++ b/arch/powerpc/kernel/irq.c
> > @@ -66,6 +66,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef CONFIG_PPC64
> >  #include 
> > @@ -607,10 +608,12 @@ void irq_ctx_init(void)
> > memset((void *)softirq_ctx[i], 0, THREAD_SIZE);
> > tp = softirq_ctx[i];
> > tp->cpu = i;
> > +   klp_init_thread_info(tp);

> At this point ti->livepatch_sp points to the next CPUs thread_info for 
> softirq_ctx?

Sorry I'm not sure what you mean.

None of this relates to the current CPUs thread info.

> > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> > index 3807fb05b6de..1b6cabb8e715 100644
> > --- a/arch/powerpc/kernel/setup_64.c
> > +++ b/arch/powerpc/kernel/setup_64.c
> > @@ -69,6 +69,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef DEBUG
> >  #define DBG(fmt...) udbg_printf(fmt)
> > @@ -667,16 +668,16 @@ static void __init emergency_stack_init(void)
> > limit = min(safe_stack_limit(), ppc64_rma_size);
> >  
> > for_each_possible_cpu(i) {
> > -   unsigned long sp;
> > -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
> > -   sp += THREAD_SIZE;
> > -   paca[i].emergency_sp = __va(sp);
> > +   struct thread_info *ti;
> > +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
> > +   klp_init_thread_info(ti);
> > +   paca[i].emergency_sp = (void *)ti + THREAD_SIZE;
>  
> Does emergency_sp still end up 128 byte aligned after this?

It should end up THREAD_SIZE aligned as before, due to the 
memblock_alloc_base().

> >  #ifdef CONFIG_PPC_BOOK3S_64
> > /* emergency stack for machine check exception handling. */
> > -   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
> > -   sp += THREAD_SIZE;
> > -   paca[i].mc_emergency_sp = __va(sp);
> > +   ti = __va(memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit));
> > +   klp_init_thread_info(ti);

> Do we care about live-patching in this context? Are we mixing per-thread and 
> per-cpu contexts?

Well we probably don't want to be doing live patching when we're on the
emergency stacks. But we have no control over whether that happens so we have
to support it.

cheers

Re: [LKP] [lkp] [futex] 65d8fc777f: +25.6% will-it-scale.per_process_ops

[Darren Hart]

On Tue, Mar 29, 2016 at 09:12:56AM +0800, Huang, Ying wrote:
> Darren Hart  writes:
> 
> > On Mon, Mar 21, 2016 at 04:42:47PM +0800, Huang, Ying wrote:
> >> Thomas Gleixner  writes:
> >> 
> >> > On Mon, 21 Mar 2016, Huang, Ying wrote:
> >> >> >  FYI, we noticed 25.6% performance improvement due to commit
> >> >> >
> >> >> >65d8fc777f6d "futex: Remove requirement for lock_page() in 
> >> >> > get_futex_key()"
> >> >> >
> >> >> >  in the will-it-scale.per_process_ops test.
> >> >> >
> >> >> >  will-it-scale.per_process_ops tests the futex operations for process 
> >> >> > shared
> >> >> >  futexes (Or whatever that test really does).
> >> >> 
> >> >> There is a futex sub test case for will-it-scale test suite.  But I got 
> >> >> your
> >> >> point, we need some description for the test case.  If email is not too
> >> >> limited for the full description, we will put it in some web site and
> >> >> include short description and link to the full description in email.
> >> >
> >> > Ok. Just make sure the short description gives enough information for the
> >> > casual reader.
> >> >  
> >> >> >  The commit has no significant impact on any other test in the test 
> >> >> > suite.
> >> >> 
> >> >> Sorry, we have no enough machine power to test all test cases for each
> >> >> bisect result.  So we will have no such information until we find a way
> >> >> to do that.
> >> >
> >> > Well, then I really have to ask how I should interpret the data here:
> >> >
> >> >5076304 .  0% +25.6%6374220 .  0%  
> >> > will-it-scale.per_process_ops
> >> >
> >> >^^^ That's the reason why you sent the mail in the first place
> >> >
> >> >1194117 .  0% +14.4%1366153 .  1%  
> >> > will-it-scale.per_thread_ops
> >> >   0.58 .  0%  -2.0%   0.57 .  0%  will-it-scale.scalability
> >> >   6820 .  0% -19.6%   5483 . 15%  meminfo.AnonHugePages
> >> >   2652 .  5% -10.4%   2375 .  2%  vmstat.system.cs
> >> >   2848 . 32%+141.2%   6870 . 65%  
> >> > numa-meminfo.node1.Active(anon)
> >> >   2832 . 31% +57.6%   4465 . 27%  
> >> > numa-meminfo.node1.AnonPages
> >> >  15018 . 12% -23.3%  11515 . 15%  
> >> > numa-meminfo.node2.AnonPages
> >> >   1214 . 14% -22.8% 936.75 . 20%  
> >> > numa-meminfo.node3.PageTables
> >> > 712.25 . 32%+141.2%   1718 . 65%  
> >> > numa-vmstat.node1.nr_active_anon
> >> > 708.25 . 31% +57.7%   1116 . 27%  
> >> > numa-vmstat.node1.nr_anon_pages
> >> >
> >> > How is this related and what should I do about this information? 
> >> 
> >> For each will-it-scale sub test case, it will be run in both process
> >> mode and thread mode, and task number will change from 1 to CPU number.
> >> will-it-scale.per_thread_ops shows thread mode main result.
> >> will-it-scale.scalability is calculated to measure how per_process_ops
> >> and per_thread_ops scaled along with the task number.  These are default
> >> behavior of will-it-scale test suite.
> >> 
> >> Others are monitors output.  That is, other information collected during
> >> test.  For example, meminfo is a monitor to sampling /proc/meminfo
> >> contents,  AnonHugePages is a line in it.  meminfo.AnonHugePages is for
> >> the average value of AnonHugePages line of /proc/meminfo.  Similarly
> >> vmstat.system.cs is the average value of cs column of system column
> >> group of /usr/bin/vmstat.
> >> 
> >> We hope these information are helpful for root causing the regression.
> >> 
> >> >  If it's important then I have to admit, that I fail to understand why.
> >> >
> >> >  If it's not important then I have to ask why is this included.
> >> >
> >> >> > So that allows me to reproduce that test more or less with no effort. 
> >> >> > And
> >> >> > that's the really important part.
> >> >> 
> >> >> For reproducing, now we use lkp-tests tool, which includes scripts to
> >> >> build the test case, run the test, collect various information, compare
> >> >> the test result, with the job file attached with the report email.  That
> >> >> is not the easiest way, we will continuously improve it.
> >> >
> >> > I know and lkp-tests is a pain to work with. So please look into a way to
> >> > extract the relevant binaries, so it's simple for developers to 
> >> > reproduce.
> >> 
> >> OK.  We will try to improve on this side.  But it is not an easy task
> >> for us to provided easy to use simple binaries.  Do you think something
> >> like Docker image is easy to use?
> >
> > Thomas, I presume you are interested in binaries to be positive we're
> > reproducing with exactly the same bits? I agree that's good to have. I'd 
> > also
> > want to have or be pointed to the sources with a straight forward way to
> > rebuild and to inspect what exactly the test is doing. (I assume this is
> > implied, but just to make sure it's stated).
> 
> lkp-tests has the scripts to download the source, apply some patch, and
> 

Re: [LKP] [lkp] [futex] 65d8fc777f: +25.6% will-it-scale.per_process_ops

[Darren Hart]

On Tue, Mar 29, 2016 at 09:12:56AM +0800, Huang, Ying wrote:
> Darren Hart  writes:
> 
> > On Mon, Mar 21, 2016 at 04:42:47PM +0800, Huang, Ying wrote:
> >> Thomas Gleixner  writes:
> >> 
> >> > On Mon, 21 Mar 2016, Huang, Ying wrote:
> >> >> >  FYI, we noticed 25.6% performance improvement due to commit
> >> >> >
> >> >> >65d8fc777f6d "futex: Remove requirement for lock_page() in 
> >> >> > get_futex_key()"
> >> >> >
> >> >> >  in the will-it-scale.per_process_ops test.
> >> >> >
> >> >> >  will-it-scale.per_process_ops tests the futex operations for process 
> >> >> > shared
> >> >> >  futexes (Or whatever that test really does).
> >> >> 
> >> >> There is a futex sub test case for will-it-scale test suite.  But I got 
> >> >> your
> >> >> point, we need some description for the test case.  If email is not too
> >> >> limited for the full description, we will put it in some web site and
> >> >> include short description and link to the full description in email.
> >> >
> >> > Ok. Just make sure the short description gives enough information for the
> >> > casual reader.
> >> >  
> >> >> >  The commit has no significant impact on any other test in the test 
> >> >> > suite.
> >> >> 
> >> >> Sorry, we have no enough machine power to test all test cases for each
> >> >> bisect result.  So we will have no such information until we find a way
> >> >> to do that.
> >> >
> >> > Well, then I really have to ask how I should interpret the data here:
> >> >
> >> >5076304 .  0% +25.6%6374220 .  0%  
> >> > will-it-scale.per_process_ops
> >> >
> >> >^^^ That's the reason why you sent the mail in the first place
> >> >
> >> >1194117 .  0% +14.4%1366153 .  1%  
> >> > will-it-scale.per_thread_ops
> >> >   0.58 .  0%  -2.0%   0.57 .  0%  will-it-scale.scalability
> >> >   6820 .  0% -19.6%   5483 . 15%  meminfo.AnonHugePages
> >> >   2652 .  5% -10.4%   2375 .  2%  vmstat.system.cs
> >> >   2848 . 32%+141.2%   6870 . 65%  
> >> > numa-meminfo.node1.Active(anon)
> >> >   2832 . 31% +57.6%   4465 . 27%  
> >> > numa-meminfo.node1.AnonPages
> >> >  15018 . 12% -23.3%  11515 . 15%  
> >> > numa-meminfo.node2.AnonPages
> >> >   1214 . 14% -22.8% 936.75 . 20%  
> >> > numa-meminfo.node3.PageTables
> >> > 712.25 . 32%+141.2%   1718 . 65%  
> >> > numa-vmstat.node1.nr_active_anon
> >> > 708.25 . 31% +57.7%   1116 . 27%  
> >> > numa-vmstat.node1.nr_anon_pages
> >> >
> >> > How is this related and what should I do about this information? 
> >> 
> >> For each will-it-scale sub test case, it will be run in both process
> >> mode and thread mode, and task number will change from 1 to CPU number.
> >> will-it-scale.per_thread_ops shows thread mode main result.
> >> will-it-scale.scalability is calculated to measure how per_process_ops
> >> and per_thread_ops scaled along with the task number.  These are default
> >> behavior of will-it-scale test suite.
> >> 
> >> Others are monitors output.  That is, other information collected during
> >> test.  For example, meminfo is a monitor to sampling /proc/meminfo
> >> contents,  AnonHugePages is a line in it.  meminfo.AnonHugePages is for
> >> the average value of AnonHugePages line of /proc/meminfo.  Similarly
> >> vmstat.system.cs is the average value of cs column of system column
> >> group of /usr/bin/vmstat.
> >> 
> >> We hope these information are helpful for root causing the regression.
> >> 
> >> >  If it's important then I have to admit, that I fail to understand why.
> >> >
> >> >  If it's not important then I have to ask why is this included.
> >> >
> >> >> > So that allows me to reproduce that test more or less with no effort. 
> >> >> > And
> >> >> > that's the really important part.
> >> >> 
> >> >> For reproducing, now we use lkp-tests tool, which includes scripts to
> >> >> build the test case, run the test, collect various information, compare
> >> >> the test result, with the job file attached with the report email.  That
> >> >> is not the easiest way, we will continuously improve it.
> >> >
> >> > I know and lkp-tests is a pain to work with. So please look into a way to
> >> > extract the relevant binaries, so it's simple for developers to 
> >> > reproduce.
> >> 
> >> OK.  We will try to improve on this side.  But it is not an easy task
> >> for us to provided easy to use simple binaries.  Do you think something
> >> like Docker image is easy to use?
> >
> > Thomas, I presume you are interested in binaries to be positive we're
> > reproducing with exactly the same bits? I agree that's good to have. I'd 
> > also
> > want to have or be pointed to the sources with a straight forward way to
> > rebuild and to inspect what exactly the test is doing. (I assume this is
> > implied, but just to make sure it's stated).
> 
> lkp-tests has the scripts to download the source, apply some patch, and
> build the binary.  It is not a very 

Re: fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH]

[Dave Chinner]

On Mon, Mar 28, 2016 at 08:25:46PM -0800, Kent Overstreet wrote:
> Bit of previous discussion:
> http://thread.gmane.org/gmane.linux.file-systems/101201/
> 
> The underlying issue is that we have no mechanism for invalidating a range of
> the pagecache and then _keeping it invalidated_ while we Do Stuff. 
> 
> The fallocate INSERT_RANGE/COLLAPSE_RANGE situation seems likely to be worse
> than I initially thought. I've been digging into this in the course of 
> bcachefs
> testing - I was hitting assertions that meant state hanging off the page cache
> (in this case, allocation information, i.e. whether we needed to reserve space
> on write) was inconsistent with the btree in writepages().
> 
> Well, bcachefs isn't the only filesystem that hangs additional state off the
> pagecache, and the situation today is that an unpriviliged user can cause
> inconsistencies there by just doing buffered reads concurrently with
> INSERT_RANGE/COLLAPSE_RANGE. I highly highly doubt this is an issue of just
> "oops, you corrupted your file because you were doing stupid stuff" - who 
> knows
> what internal invariants are getting broken here, and I don't particularly 
> care
> to find out.

I'd like to see a test case for this. Concurrent IO and/or page
faults should not run at the same as fallocate on XFS. Hence I'd
like to see the test cases that demonstrate buffered reads are
causing corruption during insert/collapse range operations. We use
the same locking strategy for fallocate as we use for truncate and
all the other internal extent manipulation operations, so if there's
something wrong, we need to fix it.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH]

[Dave Chinner]

On Mon, Mar 28, 2016 at 08:25:46PM -0800, Kent Overstreet wrote:
> Bit of previous discussion:
> http://thread.gmane.org/gmane.linux.file-systems/101201/
> 
> The underlying issue is that we have no mechanism for invalidating a range of
> the pagecache and then _keeping it invalidated_ while we Do Stuff. 
> 
> The fallocate INSERT_RANGE/COLLAPSE_RANGE situation seems likely to be worse
> than I initially thought. I've been digging into this in the course of 
> bcachefs
> testing - I was hitting assertions that meant state hanging off the page cache
> (in this case, allocation information, i.e. whether we needed to reserve space
> on write) was inconsistent with the btree in writepages().
> 
> Well, bcachefs isn't the only filesystem that hangs additional state off the
> pagecache, and the situation today is that an unpriviliged user can cause
> inconsistencies there by just doing buffered reads concurrently with
> INSERT_RANGE/COLLAPSE_RANGE. I highly highly doubt this is an issue of just
> "oops, you corrupted your file because you were doing stupid stuff" - who 
> knows
> what internal invariants are getting broken here, and I don't particularly 
> care
> to find out.

I'd like to see a test case for this. Concurrent IO and/or page
faults should not run at the same as fallocate on XFS. Hence I'd
like to see the test cases that demonstrate buffered reads are
causing corruption during insert/collapse range operations. We use
the same locking strategy for fallocate as we use for truncate and
all the other internal extent manipulation operations, so if there's
something wrong, we need to fix it.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

[PATCH] thermal: fix thermal_power_allocator trace event

[Ricky Liang]

Fix the dynamic array length in printing the thermal_power_allocator
trace event.

CC: Javi Merino 
CC: Daniel Kurtz 
Signed-off-by: Ricky Liang 
---
 include/trace/events/thermal_power_allocator.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/thermal_power_allocator.h 
b/include/trace/events/thermal_power_allocator.h
index 5afae8f..85e5391 100644
--- a/include/trace/events/thermal_power_allocator.h
+++ b/include/trace/events/thermal_power_allocator.h
@@ -45,10 +45,10 @@ TRACE_EVENT(thermal_power_allocator,
TP_printk("thermal_zone_id=%d req_power={%s} total_req_power=%u 
granted_power={%s} total_granted_power=%u power_range=%u 
max_allocatable_power=%u current_temperature=%d delta_temperature=%d",
__entry->tz_id,
__print_array(__get_dynamic_array(req_power),
-  __entry->num_actors, 4),
+  __get_dynamic_array_len(req_power), 4),
__entry->total_req_power,
__print_array(__get_dynamic_array(granted_power),
-  __entry->num_actors, 4),
+  __get_dynamic_array_len(granted_power), 4),
__entry->total_granted_power, __entry->power_range,
__entry->max_allocatable_power, __entry->current_temp,
__entry->delta_temp)
-- 
2.1.2

[PATCH] thermal: fix thermal_power_allocator trace event

[Ricky Liang]

Fix the dynamic array length in printing the thermal_power_allocator
trace event.

CC: Javi Merino 
CC: Daniel Kurtz 
Signed-off-by: Ricky Liang 
---
 include/trace/events/thermal_power_allocator.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/thermal_power_allocator.h 
b/include/trace/events/thermal_power_allocator.h
index 5afae8f..85e5391 100644
--- a/include/trace/events/thermal_power_allocator.h
+++ b/include/trace/events/thermal_power_allocator.h
@@ -45,10 +45,10 @@ TRACE_EVENT(thermal_power_allocator,
TP_printk("thermal_zone_id=%d req_power={%s} total_req_power=%u 
granted_power={%s} total_granted_power=%u power_range=%u 
max_allocatable_power=%u current_temperature=%d delta_temperature=%d",
__entry->tz_id,
__print_array(__get_dynamic_array(req_power),
-  __entry->num_actors, 4),
+  __get_dynamic_array_len(req_power), 4),
__entry->total_req_power,
__print_array(__get_dynamic_array(granted_power),
-  __entry->num_actors, 4),
+  __get_dynamic_array_len(granted_power), 4),
__entry->total_granted_power, __entry->power_range,
__entry->max_allocatable_power, __entry->current_temp,
__entry->delta_temp)
-- 
2.1.2

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

[Alexei Starovoitov]

On Tue, Mar 29, 2016 at 10:01:24AM +0800, Wangnan (F) wrote:
> 
> 
> On 2016/3/28 14:41, Wang Nan wrote:
> 
> [SNIP]
> 
> >
> >To prevent this problem, we need to find a way to ensure the ring buffer
> >is stable during reading. ioctl(PERF_EVENT_IOC_PAUSE_OUTPUT) is
> >suggested because its overhead is lower than
> >ioctl(PERF_EVENT_IOC_ENABLE).
> >
> 
> Add comment:
> 
> By carefully verifying 'header' pointer, reader can avoid pausing the
> ring-buffer. For example:
> 
> /* A union of all possible events */
> union perf_event event;
> 
> p = head = perf_mmap__read_head();
> while (true) {
> /* copy header of next event */
> fetch(, p, sizeof(event.header));
> 
> /* read 'head' pointer */
> head = perf_mmap__read_head();
> 
> /* check overwritten: is the header good? */
> if (!verify(sizeof(event.header), p, head))
> break;
> 
> /* copy the whole event */
> fetch(, p, event.header.size);
> 
> /* read 'head' pointer again */
> head = perf_mmap__read_head();
> 
> /* is the whole event good? */
> if (!verify(event.header.size, p, head))
> break;
> p += event.header.size;
> }
> 
> However, the overhead is high because:
> 
>  a) In-place decoding is unsafe. Copy-verifying-decode is required.
>  b) Fetching 'head' pointer requires additional synchronization.

Such trick may work, but pause is needed for more than stability
of reading. When we collect the events into overwrite buffer
we're waiting for some other trigger (like all cpu utilization
spike or just one cpu running and all others are idle) and when
it happens the buffer has valuable info from the past. At this
point new events are no longer interesting and buffer should
be paused, events read and unpaused until next trigger comes.

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

[Alexei Starovoitov]

On Tue, Mar 29, 2016 at 10:01:24AM +0800, Wangnan (F) wrote:
> 
> 
> On 2016/3/28 14:41, Wang Nan wrote:
> 
> [SNIP]
> 
> >
> >To prevent this problem, we need to find a way to ensure the ring buffer
> >is stable during reading. ioctl(PERF_EVENT_IOC_PAUSE_OUTPUT) is
> >suggested because its overhead is lower than
> >ioctl(PERF_EVENT_IOC_ENABLE).
> >
> 
> Add comment:
> 
> By carefully verifying 'header' pointer, reader can avoid pausing the
> ring-buffer. For example:
> 
> /* A union of all possible events */
> union perf_event event;
> 
> p = head = perf_mmap__read_head();
> while (true) {
> /* copy header of next event */
> fetch(, p, sizeof(event.header));
> 
> /* read 'head' pointer */
> head = perf_mmap__read_head();
> 
> /* check overwritten: is the header good? */
> if (!verify(sizeof(event.header), p, head))
> break;
> 
> /* copy the whole event */
> fetch(, p, event.header.size);
> 
> /* read 'head' pointer again */
> head = perf_mmap__read_head();
> 
> /* is the whole event good? */
> if (!verify(event.header.size, p, head))
> break;
> p += event.header.size;
> }
> 
> However, the overhead is high because:
> 
>  a) In-place decoding is unsafe. Copy-verifying-decode is required.
>  b) Fetching 'head' pointer requires additional synchronization.

Such trick may work, but pause is needed for more than stability
of reading. When we collect the events into overwrite buffer
we're waiting for some other trigger (like all cpu utilization
spike or just one cpu running and all others are idle) and when
it happens the buffer has valuable info from the past. At this
point new events are no longer interesting and buffer should
be paused, events read and unpaused until next trigger comes.

Re: [PATCH V8 00/14] Add T210 support in Tegra soctherm

[Wei Ni]

On 2016年03月29日 11:04, Eduardo Valentin wrote:
> On Fri, Mar 25, 2016 at 01:37:17PM +0800, Wei Ni wrote:
>> Hi, Eduardo
>> Will you take this series, it seems no more comments.
> 
> Yeah, I am taking a look at it. Something is fishy about it. Patch 04
> does not apply cleanly. Also, why did you split the patches into two
> email threads, one which is 1-4 and another one is 5-14?

Sorry, what do you mean "split the patches into two email threads"? And what's
the 1-4 and 5-14?
I think I didn't split my patches into two email thread.

Thanks.
Wei.

> 
> I have ammended patch 04 at my side, but you need to validate your
> series is one piece (please check my tree and linux-next).
> 
> BR,
> 
> Eduardo Valentin
> 
>>

Re: [PATCH V8 00/14] Add T210 support in Tegra soctherm

[Wei Ni]

On 2016年03月29日 11:04, Eduardo Valentin wrote:
> On Fri, Mar 25, 2016 at 01:37:17PM +0800, Wei Ni wrote:
>> Hi, Eduardo
>> Will you take this series, it seems no more comments.
> 
> Yeah, I am taking a look at it. Something is fishy about it. Patch 04
> does not apply cleanly. Also, why did you split the patches into two
> email threads, one which is 1-4 and another one is 5-14?

Sorry, what do you mean "split the patches into two email threads"? And what's
the 1-4 and 5-14?
I think I didn't split my patches into two email thread.

Thanks.
Wei.

> 
> I have ammended patch 04 at my side, but you need to validate your
> series is one piece (please check my tree and linux-next).
> 
> BR,
> 
> Eduardo Valentin
> 
>>

[PATCH 3/3] staging: dgnc: fix Logical continuations.

[Daeseok Youn]

fix checkpatch.pl warning about
'Logical continuations should be on the previous line'

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 9412d25..3e490de 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1811,9 +1811,9 @@ static void neo_vpd(struct dgnc_board *brd)
 * 0x10 : long resource name tage (PCI-66 files)
 * 0x7F : small resource end tag
 */
-   if  (((brd->vpd[0x08] != 0x82)
-   &&  (brd->vpd[0x10] != 0x82))
-   ||  (brd->vpd[0x7F] != 0x78)) {
+   if  (((brd->vpd[0x08] != 0x82) &&
+ (brd->vpd[0x10] != 0x82)) ||
+(brd->vpd[0x7F] != 0x78)) {
 
memset(brd->vpd, '\0', NEO_VPD_IMAGESIZE);
} else {
-- 
1.9.1

[PATCH 2/3] staging: dgnc: fix 'line over 80 characters'

[Daeseok Youn]

fix checkpatch.pl warning about 'line over 80 characters'.
I just moved all line comment to above if statement.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index c3bb1b4..9412d25 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1805,9 +1805,15 @@ static void neo_vpd(struct dgnc_board *brd)
brd->vpd[(i * 2) + 1] = (a >> 8) & 0xff;
}
 
-   if  (((brd->vpd[0x08] != 0x82) /* long resource name tag */
-   &&  (brd->vpd[0x10] != 0x82))   /* long resource name tag 
(PCI-66 files)*/
-   ||  (brd->vpd[0x7F] != 0x78)) { /* small resource end tag */
+   /*
+* brd->vpd has different name tags by below index.
+* 0x08 : long resource name tag
+* 0x10 : long resource name tage (PCI-66 files)
+* 0x7F : small resource end tag
+*/
+   if  (((brd->vpd[0x08] != 0x82)
+   &&  (brd->vpd[0x10] != 0x82))
+   ||  (brd->vpd[0x7F] != 0x78)) {
 
memset(brd->vpd, '\0', NEO_VPD_IMAGESIZE);
} else {
-- 
1.9.1

[PATCH 3/3] staging: dgnc: fix Logical continuations.

[Daeseok Youn]

fix checkpatch.pl warning about
'Logical continuations should be on the previous line'

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 9412d25..3e490de 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1811,9 +1811,9 @@ static void neo_vpd(struct dgnc_board *brd)
 * 0x10 : long resource name tage (PCI-66 files)
 * 0x7F : small resource end tag
 */
-   if  (((brd->vpd[0x08] != 0x82)
-   &&  (brd->vpd[0x10] != 0x82))
-   ||  (brd->vpd[0x7F] != 0x78)) {
+   if  (((brd->vpd[0x08] != 0x82) &&
+ (brd->vpd[0x10] != 0x82)) ||
+(brd->vpd[0x7F] != 0x78)) {
 
memset(brd->vpd, '\0', NEO_VPD_IMAGESIZE);
} else {
-- 
1.9.1

[PATCH 2/3] staging: dgnc: fix 'line over 80 characters'

[Daeseok Youn]

fix checkpatch.pl warning about 'line over 80 characters'.
I just moved all line comment to above if statement.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index c3bb1b4..9412d25 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1805,9 +1805,15 @@ static void neo_vpd(struct dgnc_board *brd)
brd->vpd[(i * 2) + 1] = (a >> 8) & 0xff;
}
 
-   if  (((brd->vpd[0x08] != 0x82) /* long resource name tag */
-   &&  (brd->vpd[0x10] != 0x82))   /* long resource name tag 
(PCI-66 files)*/
-   ||  (brd->vpd[0x7F] != 0x78)) { /* small resource end tag */
+   /*
+* brd->vpd has different name tags by below index.
+* 0x08 : long resource name tag
+* 0x10 : long resource name tage (PCI-66 files)
+* 0x7F : small resource end tag
+*/
+   if  (((brd->vpd[0x08] != 0x82)
+   &&  (brd->vpd[0x10] != 0x82))
+   ||  (brd->vpd[0x7F] != 0x78)) {
 
memset(brd->vpd, '\0', NEO_VPD_IMAGESIZE);
} else {
-- 
1.9.1

[PATCH 1/3] staging: dgnc: remove parenthesis around the CONST |

[Daeseok Youn]

remove parenthesis around the CONST | CONST.
It will be also fixed checkpatch.pl warning about
"Alignment should match open parenthesis" becasue
parenthesis were removed by this patch.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index d732e6e..c3bb1b4 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -117,8 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY,
+  >ch_neo_uart->fctr);
 
/* Feed the UART our trigger levels */
writeb(8, >ch_neo_uart->tfifo);
@@ -152,8 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY,
+  >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
writeb(32, >ch_neo_uart->rfifo);
@@ -190,7 +190,7 @@ static inline void neo_set_ixon_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
   >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
@@ -229,8 +229,8 @@ static inline void neo_set_ixoff_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
+  >ch_neo_uart->fctr);
 
writeb(8, >ch_neo_uart->tfifo);
ch->ch_t_tlevel = 8;
@@ -270,8 +270,8 @@ static inline void neo_set_no_input_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
+  >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -308,8 +308,8 @@ static inline void neo_set_no_output_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
+  >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -1373,7 +1373,7 @@ static void neo_flush_uart_read(struct channel_t *ch)
if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
return;
 
-   writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR),
+   writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR,
   >ch_neo_uart->isr_fcr);
neo_pci_posting_flush(ch->ch_bd);
 
@@ -1648,7 +1648,7 @@ static void neo_uart_init(struct channel_t *ch)
 
/* Clear out UART and FIFO */
readb(>ch_neo_uart->txrx);
-   writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | 
UART_FCR_CLEAR_XMIT),
+   writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
   >ch_neo_uart->isr_fcr);
readb(>ch_neo_uart->lsr);
readb(>ch_neo_uart->msr);
-- 
1.9.1

[PATCH 1/3] staging: dgnc: remove parenthesis around the CONST |

[Daeseok Youn]

remove parenthesis around the CONST | CONST.
It will be also fixed checkpatch.pl warning about
"Alignment should match open parenthesis" becasue
parenthesis were removed by this patch.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index d732e6e..c3bb1b4 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -117,8 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY,
+  >ch_neo_uart->fctr);
 
/* Feed the UART our trigger levels */
writeb(8, >ch_neo_uart->tfifo);
@@ -152,8 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY,
+  >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
writeb(32, >ch_neo_uart->rfifo);
@@ -190,7 +190,7 @@ static inline void neo_set_ixon_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
   >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
@@ -229,8 +229,8 @@ static inline void neo_set_ixoff_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
+  >ch_neo_uart->fctr);
 
writeb(8, >ch_neo_uart->tfifo);
ch->ch_t_tlevel = 8;
@@ -270,8 +270,8 @@ static inline void neo_set_no_input_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
+  >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -308,8 +308,8 @@ static inline void neo_set_no_output_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
-   >ch_neo_uart->fctr);
+   writeb(UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY,
+  >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -1373,7 +1373,7 @@ static void neo_flush_uart_read(struct channel_t *ch)
if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
return;
 
-   writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR),
+   writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR,
   >ch_neo_uart->isr_fcr);
neo_pci_posting_flush(ch->ch_bd);
 
@@ -1648,7 +1648,7 @@ static void neo_uart_init(struct channel_t *ch)
 
/* Clear out UART and FIFO */
readb(>ch_neo_uart->txrx);
-   writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | 
UART_FCR_CLEAR_XMIT),
+   writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
   >ch_neo_uart->isr_fcr);
readb(>ch_neo_uart->lsr);
readb(>ch_neo_uart->msr);
-- 
1.9.1

[PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

[Wei-Ning Huang]

"single skb allocation failure" happens when system is under heavy
memory pressure.  Add __GFP_REPEAT to skb allocation call so kernel
attempts to reclaim pages and retry the allocation.

Signed-off-by: Wei-Ning Huang 
---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index b2c839a..c64989c 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1124,7 +1124,8 @@ static void mwifiex_deaggr_sdio_pkt(struct 
mwifiex_adapter *adapter,
break;
}
skb_deaggr = mwifiex_alloc_dma_align_buf(pkt_len,
-GFP_KERNEL | GFP_DMA);
+GFP_KERNEL | GFP_DMA |
+__GFP_REPEAT);
if (!skb_deaggr)
break;
skb_put(skb_deaggr, pkt_len);
@@ -1374,7 +1375,8 @@ static int mwifiex_sdio_card_to_host_mp_aggr(struct 
mwifiex_adapter *adapter,
/* copy pkt to deaggr buf */
skb_deaggr = mwifiex_alloc_dma_align_buf(len_arr[pind],
 GFP_KERNEL |
-GFP_DMA);
+GFP_DMA |
+__GFP_REPEAT);
if (!skb_deaggr) {
mwifiex_dbg(adapter, ERROR, "skb allocation 
failure\t"
"drop pkt len=%d type=%d\n",
@@ -1416,7 +1418,8 @@ rx_curr_single:
mwifiex_dbg(adapter, INFO, "info: RX: port: %d, rx_len: %d\n",
port, rx_len);
 
-   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA);
+   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA |
+ __GFP_REPEAT);
if (!skb) {
mwifiex_dbg(adapter, ERROR,
"single skb allocated fail,\t"
@@ -1521,7 +1524,8 @@ static int mwifiex_process_int_status(struct 
mwifiex_adapter *adapter)
rx_len = (u16) (rx_blocks * MWIFIEX_SDIO_BLOCK_SIZE);
mwifiex_dbg(adapter, INFO, "info: rx_len = %d\n", rx_len);
 
-   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA);
+   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA |
+ __GFP_REPEAT);
if (!skb)
return -1;
 
-- 
2.8.0.rc3.226.g39d4020

[PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

[Wei-Ning Huang]

"single skb allocation failure" happens when system is under heavy
memory pressure.  Add __GFP_REPEAT to skb allocation call so kernel
attempts to reclaim pages and retry the allocation.

Signed-off-by: Wei-Ning Huang 
---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index b2c839a..c64989c 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1124,7 +1124,8 @@ static void mwifiex_deaggr_sdio_pkt(struct 
mwifiex_adapter *adapter,
break;
}
skb_deaggr = mwifiex_alloc_dma_align_buf(pkt_len,
-GFP_KERNEL | GFP_DMA);
+GFP_KERNEL | GFP_DMA |
+__GFP_REPEAT);
if (!skb_deaggr)
break;
skb_put(skb_deaggr, pkt_len);
@@ -1374,7 +1375,8 @@ static int mwifiex_sdio_card_to_host_mp_aggr(struct 
mwifiex_adapter *adapter,
/* copy pkt to deaggr buf */
skb_deaggr = mwifiex_alloc_dma_align_buf(len_arr[pind],
 GFP_KERNEL |
-GFP_DMA);
+GFP_DMA |
+__GFP_REPEAT);
if (!skb_deaggr) {
mwifiex_dbg(adapter, ERROR, "skb allocation 
failure\t"
"drop pkt len=%d type=%d\n",
@@ -1416,7 +1418,8 @@ rx_curr_single:
mwifiex_dbg(adapter, INFO, "info: RX: port: %d, rx_len: %d\n",
port, rx_len);
 
-   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA);
+   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA |
+ __GFP_REPEAT);
if (!skb) {
mwifiex_dbg(adapter, ERROR,
"single skb allocated fail,\t"
@@ -1521,7 +1524,8 @@ static int mwifiex_process_int_status(struct 
mwifiex_adapter *adapter)
rx_len = (u16) (rx_blocks * MWIFIEX_SDIO_BLOCK_SIZE);
mwifiex_dbg(adapter, INFO, "info: rx_len = %d\n", rx_len);
 
-   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA);
+   skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA |
+ __GFP_REPEAT);
if (!skb)
return -1;
 
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Krzysztof Kozlowski]

On 29.03.2016 13:19, Viresh Kumar wrote:
> On 29-03-16, 09:48, Viresh Kumar wrote:
>> On 29-03-16, 13:10, Krzysztof Kozlowski wrote:
>>> On 24.03.2016 15:40, Viresh Kumar wrote:
 The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
 device now, reuse that and remove similar code from platform code.

 Signed-off-by: Viresh Kumar 
 ---
  arch/arm/mach-exynos/exynos.c| 25 -
  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
  2 files changed, 5 insertions(+), 25 deletions(-)
>>>
>>> Looks fine to me... except that it is a little bit outdated. Please
>>> rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.
>>
>> Yeah, I know. I already have the updated version.
> 
> Here it is:
> 
> From: Viresh Kumar 
> Date: Thu, 24 Mar 2016 12:04:10 +0530
> Subject: [PATCH] cpufreq: exynos: Use generic platdev driver
> 
> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> device now, reuse that and remove similar code from platform code.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  arch/arm/mach-exynos/exynos.c| 29 -
>  drivers/cpufreq/cpufreq-dt-platdev.c |  9 +
>  2 files changed, 9 insertions(+), 29 deletions(-)

Reviewed-by: Krzysztof Kozlowski 



Best regards,

Krzysztof

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Krzysztof Kozlowski]

On 29.03.2016 13:19, Viresh Kumar wrote:
> On 29-03-16, 09:48, Viresh Kumar wrote:
>> On 29-03-16, 13:10, Krzysztof Kozlowski wrote:
>>> On 24.03.2016 15:40, Viresh Kumar wrote:
 The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
 device now, reuse that and remove similar code from platform code.

 Signed-off-by: Viresh Kumar 
 ---
  arch/arm/mach-exynos/exynos.c| 25 -
  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
  2 files changed, 5 insertions(+), 25 deletions(-)
>>>
>>> Looks fine to me... except that it is a little bit outdated. Please
>>> rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.
>>
>> Yeah, I know. I already have the updated version.
> 
> Here it is:
> 
> From: Viresh Kumar 
> Date: Thu, 24 Mar 2016 12:04:10 +0530
> Subject: [PATCH] cpufreq: exynos: Use generic platdev driver
> 
> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> device now, reuse that and remove similar code from platform code.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  arch/arm/mach-exynos/exynos.c| 29 -
>  drivers/cpufreq/cpufreq-dt-platdev.c |  9 +
>  2 files changed, 9 insertions(+), 29 deletions(-)

Reviewed-by: Krzysztof Kozlowski 



Best regards,

Krzysztof

Re: [PATCH 1/4 fix] perf core: Introduce new ioctl options to pause and resume ring buffer

[Alexei Starovoitov]

On Tue, Mar 29, 2016 at 02:05:07AM +, Wang Nan wrote:
> Add new ioctl() to pause/resume ring-buffer output.
> 
> In some situations we want to read from ring buffer only when we
> ensure nothing can write to the ring buffer during reading. Without
> this patch we have to turn off all events attached to this ring buffer
> to achieve this.
> 
> This patch is for supporting overwrite ring buffer. Following
> commits will introduce new methods support reading from overwrite ring
> buffer. Before reading, caller must ensure the ring buffer is frozen, or
> the reading is unreliable.
> 
> Signed-off-by: Wang Nan 
> Cc: He Kuang 
> Cc: Alexei Starovoitov 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Brendan Gregg 
> Cc: Jiri Olsa 
> Cc: Masami Hiramatsu 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Zefan Li 
> Cc: pi3or...@163.com
> ---
>  include/uapi/linux/perf_event.h |  1 +
>  kernel/events/core.c| 13 +
>  kernel/events/internal.h| 11 +++
>  kernel/events/ring_buffer.c |  7 ++-
>  4 files changed, 31 insertions(+), 1 deletion(-)

Acked-by: Alexei Starovoitov 

Re: [PATCH 1/4 fix] perf core: Introduce new ioctl options to pause and resume ring buffer

[Alexei Starovoitov]

On Tue, Mar 29, 2016 at 02:05:07AM +, Wang Nan wrote:
> Add new ioctl() to pause/resume ring-buffer output.
> 
> In some situations we want to read from ring buffer only when we
> ensure nothing can write to the ring buffer during reading. Without
> this patch we have to turn off all events attached to this ring buffer
> to achieve this.
> 
> This patch is for supporting overwrite ring buffer. Following
> commits will introduce new methods support reading from overwrite ring
> buffer. Before reading, caller must ensure the ring buffer is frozen, or
> the reading is unreliable.
> 
> Signed-off-by: Wang Nan 
> Cc: He Kuang 
> Cc: Alexei Starovoitov 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Brendan Gregg 
> Cc: Jiri Olsa 
> Cc: Masami Hiramatsu 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Zefan Li 
> Cc: pi3or...@163.com
> ---
>  include/uapi/linux/perf_event.h |  1 +
>  kernel/events/core.c| 13 +
>  kernel/events/internal.h| 11 +++
>  kernel/events/ring_buffer.c |  7 ++-
>  4 files changed, 31 insertions(+), 1 deletion(-)

Acked-by: Alexei Starovoitov 

Re: [PATCH 3/4] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Mon, Jan 11, 2016 at 1:02 AM, Eugene Krasnikov  wrote:
> Better late than never! Looks good to me.
>

Unfortunately I ran into an issue with ordering of operations between
the WiFi driver and the wcnss_ctrl driver. So an updated series is on
the way, but this depends on changes to the wcnss_ctrl driver, which
are being reviewed right now.

Regards,
Bjorn

> 2015-12-28 1:34 GMT+00:00 Bjorn Andersson :
>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>> channel, as such it should be a SMD client. This patch makes this
>> transition, now that we have the necessary frameworks available.
>>
>> Signed-off-by: Bjorn Andersson 
>> ---
>>  drivers/net/wireless/ath/wcn36xx/Kconfig   |   2 +-
>>  drivers/net/wireless/ath/wcn36xx/dxe.c |  16 +++--
>>  drivers/net/wireless/ath/wcn36xx/main.c| 111 
>> +
>>  drivers/net/wireless/ath/wcn36xx/smd.c |  26 ---
>>  drivers/net/wireless/ath/wcn36xx/smd.h |   4 ++
>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  21 ++
>>  6 files changed, 99 insertions(+), 81 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/Kconfig 
>> b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> index 591ebaea8265..394fe5b77c90 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
>> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> @@ -1,6 +1,6 @@
>>  config WCN36XX
>> tristate "Qualcomm Atheros WCN3660/3680 support"
>> -   depends on MAC80211 && HAS_DMA
>> +   depends on MAC80211 && HAS_DMA && QCOM_SMD
>> ---help---
>>   This module adds support for wireless adapters based on
>>   Qualcomm Atheros WCN3660 and WCN3680 mobile chipsets.
>> diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
>> b/drivers/net/wireless/ath/wcn36xx/dxe.c
>> index f8dfa05b290a..47f3937a7ab9 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/dxe.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
>> @@ -23,6 +23,7 @@
>>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>
>>  #include 
>> +#include 
>>  #include "wcn36xx.h"
>>  #include "txrx.h"
>>
>> @@ -150,9 +151,12 @@ int wcn36xx_dxe_alloc_ctl_blks(struct wcn36xx *wcn)
>> goto out_err;
>>
>> /* Initialize SMSM state  Clear TX Enable RING EMPTY STATE */
>> -   ret = wcn->ctrl_ops->smsm_change_state(
>> -   WCN36XX_SMSM_WLAN_TX_ENABLE,
>> -   WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
>> +   ret = qcom_smem_state_update_bits(wcn->tx_enable_state,
>> + WCN36XX_SMSM_WLAN_TX_ENABLE |
>> + WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY,
>> + WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
>> +   if (ret)
>> +   goto out_err;
>>
>> return 0;
>>
>> @@ -676,9 +680,9 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
>>  * notify chip about new frame through SMSM bus.
>>  */
>> if (is_low &&  vif_priv->pw_state == WCN36XX_BMPS) {
>> -   wcn->ctrl_ops->smsm_change_state(
>> - 0,
>> - WCN36XX_SMSM_WLAN_TX_ENABLE);
>> +   qcom_smem_state_update_bits(wcn->tx_rings_empty_state,
>> +   WCN36XX_SMSM_WLAN_TX_ENABLE,
>> +   WCN36XX_SMSM_WLAN_TX_ENABLE);
>> } else {
>> /* indicate End Of Packet and generate interrupt on 
>> descriptor
>>  * done.
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
>> b/drivers/net/wireless/ath/wcn36xx/main.c
>> index 7c169abdbafe..8659e3f997d2 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -19,6 +19,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>>  #include "wcn36xx.h"
>>
>>  unsigned int wcn36xx_dbg_mask;
>> @@ -981,48 +984,63 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>>  }
>>
>>  static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
>> - struct platform_device *pdev)
>> + struct device *dev)
>>  {
>> -   struct resource *res;
>> +   u32 mmio[2];
>> +   int ret;
>> +
>> /* Set TX IRQ */
>> -   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
>> -  "wcnss_wlantx_irq");
>> -   if (!res) {
>> +   wcn->tx_irq = irq_of_parse_and_map(dev->of_node, 0);
>> +   if (!wcn->tx_irq) {
>> wcn36xx_err("failed to get tx_irq\n");
>> return -ENOENT;
>> }
>> -   wcn->tx_irq = res->start;
>>
>> /* Set RX IRQ */
>> -   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
>> -  "wcnss_wlanrx_irq");
>> -   

Re: [PATCH 3/4] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Mon, Jan 11, 2016 at 1:02 AM, Eugene Krasnikov  wrote:
> Better late than never! Looks good to me.
>

Unfortunately I ran into an issue with ordering of operations between
the WiFi driver and the wcnss_ctrl driver. So an updated series is on
the way, but this depends on changes to the wcnss_ctrl driver, which
are being reviewed right now.

Regards,
Bjorn

> 2015-12-28 1:34 GMT+00:00 Bjorn Andersson :
>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>> channel, as such it should be a SMD client. This patch makes this
>> transition, now that we have the necessary frameworks available.
>>
>> Signed-off-by: Bjorn Andersson 
>> ---
>>  drivers/net/wireless/ath/wcn36xx/Kconfig   |   2 +-
>>  drivers/net/wireless/ath/wcn36xx/dxe.c |  16 +++--
>>  drivers/net/wireless/ath/wcn36xx/main.c| 111 
>> +
>>  drivers/net/wireless/ath/wcn36xx/smd.c |  26 ---
>>  drivers/net/wireless/ath/wcn36xx/smd.h |   4 ++
>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  21 ++
>>  6 files changed, 99 insertions(+), 81 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/Kconfig 
>> b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> index 591ebaea8265..394fe5b77c90 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
>> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> @@ -1,6 +1,6 @@
>>  config WCN36XX
>> tristate "Qualcomm Atheros WCN3660/3680 support"
>> -   depends on MAC80211 && HAS_DMA
>> +   depends on MAC80211 && HAS_DMA && QCOM_SMD
>> ---help---
>>   This module adds support for wireless adapters based on
>>   Qualcomm Atheros WCN3660 and WCN3680 mobile chipsets.
>> diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
>> b/drivers/net/wireless/ath/wcn36xx/dxe.c
>> index f8dfa05b290a..47f3937a7ab9 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/dxe.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
>> @@ -23,6 +23,7 @@
>>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>
>>  #include 
>> +#include 
>>  #include "wcn36xx.h"
>>  #include "txrx.h"
>>
>> @@ -150,9 +151,12 @@ int wcn36xx_dxe_alloc_ctl_blks(struct wcn36xx *wcn)
>> goto out_err;
>>
>> /* Initialize SMSM state  Clear TX Enable RING EMPTY STATE */
>> -   ret = wcn->ctrl_ops->smsm_change_state(
>> -   WCN36XX_SMSM_WLAN_TX_ENABLE,
>> -   WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
>> +   ret = qcom_smem_state_update_bits(wcn->tx_enable_state,
>> + WCN36XX_SMSM_WLAN_TX_ENABLE |
>> + WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY,
>> + WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
>> +   if (ret)
>> +   goto out_err;
>>
>> return 0;
>>
>> @@ -676,9 +680,9 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
>>  * notify chip about new frame through SMSM bus.
>>  */
>> if (is_low &&  vif_priv->pw_state == WCN36XX_BMPS) {
>> -   wcn->ctrl_ops->smsm_change_state(
>> - 0,
>> - WCN36XX_SMSM_WLAN_TX_ENABLE);
>> +   qcom_smem_state_update_bits(wcn->tx_rings_empty_state,
>> +   WCN36XX_SMSM_WLAN_TX_ENABLE,
>> +   WCN36XX_SMSM_WLAN_TX_ENABLE);
>> } else {
>> /* indicate End Of Packet and generate interrupt on 
>> descriptor
>>  * done.
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
>> b/drivers/net/wireless/ath/wcn36xx/main.c
>> index 7c169abdbafe..8659e3f997d2 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -19,6 +19,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>>  #include "wcn36xx.h"
>>
>>  unsigned int wcn36xx_dbg_mask;
>> @@ -981,48 +984,63 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>>  }
>>
>>  static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
>> - struct platform_device *pdev)
>> + struct device *dev)
>>  {
>> -   struct resource *res;
>> +   u32 mmio[2];
>> +   int ret;
>> +
>> /* Set TX IRQ */
>> -   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
>> -  "wcnss_wlantx_irq");
>> -   if (!res) {
>> +   wcn->tx_irq = irq_of_parse_and_map(dev->of_node, 0);
>> +   if (!wcn->tx_irq) {
>> wcn36xx_err("failed to get tx_irq\n");
>> return -ENOENT;
>> }
>> -   wcn->tx_irq = res->start;
>>
>> /* Set RX IRQ */
>> -   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
>> -  "wcnss_wlanrx_irq");
>> -   if (!res) {
>> +   wcn->rx_irq = 

[PATCH 3/5] dt-binding: Add Qualcomm WCNSS control binding

[Bjorn Andersson]

This binding describes the control interface for the Qualcomm WCNSS.

Signed-off-by: Bjorn Andersson 
---

Got a reviewed-by from Andy and acked-by from Rob on the WiFi part of this
binding. But during futher testing I spotted a timing issue, where the
wcnss_ctrl driver must finish the uploading of NV to the core os of the wcnss
before the wifi driver can initiate any communication with the wifi part
(although available from the get-go).

The sanest way I could figure to model this is to describe the core part as
parent of the wifi and bt pieces.

 .../devicetree/bindings/soc/qcom/qcom,wcnss.txt| 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
new file mode 100644
index ..5488904b6185
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
@@ -0,0 +1,104 @@
+Qualcomm WCNSS Binding
+
+This binding describes the Qualcomm WCNSS hardware. It consists of control
+block and a BT, WiFi and FM radio block, all useing SMD as command channels.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be: "qcom,wcnss",
+
+- qcom,smd-channel:
+   Usage: required
+   Value type: 
+   Definition: standard SMD property specifying the SMD channel used for
+   communication with the WiFi firmware
+
+= SUBNODES
+The subnodes of the wcnss node are optional and describe the individual blocks 
in
+the WCNSS.
+
+== Bluetooth
+The following properties are defined to the bluetooth node:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be: "qcom,btqcomsmd"
+
+== WiFi
+The following properties are defined to the WiFi node:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,wcn3620-wlan",
+   "qcom,wcn3660-wlan",
+   "qcom,wcn3680-wlan"
+
+- qcom,wcnss-mmio:
+   Usage: required
+   Value type: 
+   Definition: should specify base address and size of the WiFi related
+   registers of WCNSS
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the "rx" and "tx" interrupts
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: must contain "rx" and "tx"
+
+- qcom,state:
+   Usage: required
+   Value type: 
+   Definition: should reference the tx-enable and tx-rings-empty SMEM 
states
+
+- qcom,state-names:
+   Usage: required
+   Value type: 
+   Definition: must contain "tx-enable" and "tx-rings-empty"
+
+= EXAMPLE
+The following example represents a SMD node, with one edge representing the
+"pronto" subsystem, with the wcnss device and its wcn3680 BT and WiFi blocks
+described; as found on the 8974 platform.
+
+smd {
+   compatible = "qcom,smd";
+
+   pronto {
+   interrupts = <0 142 1>;
+
+   qcom,ipc = < 8 17>;
+   qcom,smd-edge = <6>;
+
+   wcnss {
+   compatible = "qcom,wcnss";
+   qcom,smd-channels = "WCNSS_CTRL";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   bt {
+   compatible = "qcom,btqcomsmd";
+   };
+
+   wifi {
+   compatible = "qcom,wcn3680-wlan";
+
+   qcom,wcnss-mmio = <0xfb00 0x21b000>;
+
+   interrupts = <0 145 0>, <0 146 0>;
+   interrupt-names = "tx", "rx";
+
+   qcom,state = <_smsm 10>, <_smsm 9>;
+   qcom,state-names = "tx-enable", 
"tx-rings-empty";
+   };
+   };
+   };
+};
-- 
2.5.0

[PATCH 3/5] dt-binding: Add Qualcomm WCNSS control binding

[Bjorn Andersson]

This binding describes the control interface for the Qualcomm WCNSS.

Signed-off-by: Bjorn Andersson 
---

Got a reviewed-by from Andy and acked-by from Rob on the WiFi part of this
binding. But during futher testing I spotted a timing issue, where the
wcnss_ctrl driver must finish the uploading of NV to the core os of the wcnss
before the wifi driver can initiate any communication with the wifi part
(although available from the get-go).

The sanest way I could figure to model this is to describe the core part as
parent of the wifi and bt pieces.

 .../devicetree/bindings/soc/qcom/qcom,wcnss.txt| 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
new file mode 100644
index ..5488904b6185
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
@@ -0,0 +1,104 @@
+Qualcomm WCNSS Binding
+
+This binding describes the Qualcomm WCNSS hardware. It consists of control
+block and a BT, WiFi and FM radio block, all useing SMD as command channels.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be: "qcom,wcnss",
+
+- qcom,smd-channel:
+   Usage: required
+   Value type: 
+   Definition: standard SMD property specifying the SMD channel used for
+   communication with the WiFi firmware
+
+= SUBNODES
+The subnodes of the wcnss node are optional and describe the individual blocks 
in
+the WCNSS.
+
+== Bluetooth
+The following properties are defined to the bluetooth node:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be: "qcom,btqcomsmd"
+
+== WiFi
+The following properties are defined to the WiFi node:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,wcn3620-wlan",
+   "qcom,wcn3660-wlan",
+   "qcom,wcn3680-wlan"
+
+- qcom,wcnss-mmio:
+   Usage: required
+   Value type: 
+   Definition: should specify base address and size of the WiFi related
+   registers of WCNSS
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the "rx" and "tx" interrupts
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: must contain "rx" and "tx"
+
+- qcom,state:
+   Usage: required
+   Value type: 
+   Definition: should reference the tx-enable and tx-rings-empty SMEM 
states
+
+- qcom,state-names:
+   Usage: required
+   Value type: 
+   Definition: must contain "tx-enable" and "tx-rings-empty"
+
+= EXAMPLE
+The following example represents a SMD node, with one edge representing the
+"pronto" subsystem, with the wcnss device and its wcn3680 BT and WiFi blocks
+described; as found on the 8974 platform.
+
+smd {
+   compatible = "qcom,smd";
+
+   pronto {
+   interrupts = <0 142 1>;
+
+   qcom,ipc = < 8 17>;
+   qcom,smd-edge = <6>;
+
+   wcnss {
+   compatible = "qcom,wcnss";
+   qcom,smd-channels = "WCNSS_CTRL";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   bt {
+   compatible = "qcom,btqcomsmd";
+   };
+
+   wifi {
+   compatible = "qcom,wcn3680-wlan";
+
+   qcom,wcnss-mmio = <0xfb00 0x21b000>;
+
+   interrupts = <0 145 0>, <0 146 0>;
+   interrupt-names = "tx", "rx";
+
+   qcom,state = <_smsm 10>, <_smsm 9>;
+   qcom,state-names = "tx-enable", 
"tx-rings-empty";
+   };
+   };
+   };
+};
-- 
2.5.0

[PATCH 4/5] soc: qcom: wcnss_ctrl: Make wcnss_ctrl parent the other components

[Bjorn Andersson]

We need the signal from wcnss_ctrl indicating that the firmware is up
and running before we can communicate with the other components of the
chip. So make these other components children of the wcnss_ctrl device,
so they can be probed in order.

The process seems to take between 1/2-5 seconds, so this is done in a
worker, instead of holding up the probe.

Also adding the wait for a cbc completion if the firmware indicates this is
needed - like on 8016.

Signed-off-by: Bjorn Andersson 
---
 drivers/soc/qcom/wcnss_ctrl.c   | 117 ++--
 include/linux/soc/qcom/wcnss_ctrl.h |   8 +++
 2 files changed, 108 insertions(+), 17 deletions(-)
 create mode 100644 include/linux/soc/qcom/wcnss_ctrl.h

diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
index c544f3d2c6ee..80bea66889a2 100644
--- a/drivers/soc/qcom/wcnss_ctrl.c
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (c) 2016, Linaro Ltd.
  * Copyright (c) 2015, Sony Mobile Communications Inc.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -14,8 +15,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #define WCNSS_REQUEST_TIMEOUT  (5 * HZ)
+#define WCNSS_CBC_TIMEOUT  (10 * HZ)
 
 #define NV_FRAGMENT_SIZE   3072
 #define NVBIN_FILE "wlan/prima/WCNSS_qcom_wlan_nv.bin"
@@ -25,17 +31,19 @@
  * @dev:   device handle
  * @channel:   SMD channel handle
  * @ack:   completion for outstanding requests
+ * @cbc:   completion for cbc complete indication
  * @ack_status:status of the outstanding request
- * @download_nv_work: worker for uploading nv binary
+ * @probe_work: worker for uploading nv binary
  */
 struct wcnss_ctrl {
struct device *dev;
struct qcom_smd_channel *channel;
 
struct completion ack;
+   struct completion cbc;
int ack_status;
 
-   struct work_struct download_nv_work;
+   struct work_struct probe_work;
 };
 
 /* message types */
@@ -48,6 +56,11 @@ enum {
WCNSS_UPLOAD_CAL_RESP,
WCNSS_DOWNLOAD_CAL_REQ,
WCNSS_DOWNLOAD_CAL_RESP,
+   WCNSS_VBAT_LEVEL_IND,
+   WCNSS_BUILD_VERSION_REQ,
+   WCNSS_BUILD_VERSION_RESP,
+   WCNSS_PM_CONFIG_REQ,
+   WCNSS_CBC_COMPLETE_IND,
 };
 
 /**
@@ -128,7 +141,7 @@ static int wcnss_ctrl_smd_callback(struct qcom_smd_channel 
*channel,
 version->major, version->minor,
 version->version, version->revision);
 
-   schedule_work(>download_nv_work);
+   complete(>ack);
break;
case WCNSS_DOWNLOAD_NV_RESP:
if (count != sizeof(*nvresp)) {
@@ -141,6 +154,10 @@ static int wcnss_ctrl_smd_callback(struct qcom_smd_channel 
*channel,
wcnss->ack_status = nvresp->status;
complete(>ack);
break;
+   case WCNSS_CBC_COMPLETE_IND:
+   dev_dbg(wcnss->dev, "WCNSS booted\n");
+   complete(>cbc);
+   break;
default:
dev_info(wcnss->dev, "unknown message type %d\n", hdr->type);
break;
@@ -156,20 +173,32 @@ static int wcnss_ctrl_smd_callback(struct 
qcom_smd_channel *channel,
 static int wcnss_request_version(struct wcnss_ctrl *wcnss)
 {
struct wcnss_msg_hdr msg;
+   int ret;
 
msg.type = WCNSS_VERSION_REQ;
msg.len = sizeof(msg);
+   ret = qcom_smd_send(wcnss->channel, , sizeof(msg));
+   if (ret < 0)
+   return ret;
+
+   ret = wait_for_completion_timeout(>ack, WCNSS_CBC_TIMEOUT);
+   if (!ret) {
+   dev_err(wcnss->dev, "timeout waiting for version response\n");
+   return -ETIMEDOUT;
+   }
 
-   return qcom_smd_send(wcnss->channel, , sizeof(msg));
+   return 0;
 }
 
 /**
  * wcnss_download_nv() - send nv binary to WCNSS
- * @work:  work struct to acquire wcnss context
+ * @wcnss: wcnss_ctrl state handle
+ *
+ * Returns 1 on success or 2 to indicate upcoming cbc completion. Negative
+ * errno on failure.
  */
-static void wcnss_download_nv(struct work_struct *work)
+static int wcnss_download_nv(struct wcnss_ctrl *wcnss)
 {
-   struct wcnss_ctrl *wcnss = container_of(work, struct wcnss_ctrl, 
download_nv_work);
struct wcnss_download_nv_req *req;
const struct firmware *fw;
const void *data;
@@ -178,7 +207,7 @@ static void wcnss_download_nv(struct work_struct *work)
 
req = kzalloc(sizeof(*req) + NV_FRAGMENT_SIZE, GFP_KERNEL);
if (!req)
-   return;
+   return -ENOMEM;
 
ret = request_firmware(, NVBIN_FILE, wcnss->dev);
if (ret) {
@@ -220,16 +249,56 @@ static void wcnss_download_nv(struct work_struct *work)
} while (left > 0);
 
ret = wait_for_completion_timeout(>ack, WCNSS_REQUEST_TIMEOUT);
-   if (!ret)
+   if (!ret) {

[PATCH 4/5] soc: qcom: wcnss_ctrl: Make wcnss_ctrl parent the other components

[Bjorn Andersson]

We need the signal from wcnss_ctrl indicating that the firmware is up
and running before we can communicate with the other components of the
chip. So make these other components children of the wcnss_ctrl device,
so they can be probed in order.

The process seems to take between 1/2-5 seconds, so this is done in a
worker, instead of holding up the probe.

Also adding the wait for a cbc completion if the firmware indicates this is
needed - like on 8016.

Signed-off-by: Bjorn Andersson 
---
 drivers/soc/qcom/wcnss_ctrl.c   | 117 ++--
 include/linux/soc/qcom/wcnss_ctrl.h |   8 +++
 2 files changed, 108 insertions(+), 17 deletions(-)
 create mode 100644 include/linux/soc/qcom/wcnss_ctrl.h

diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
index c544f3d2c6ee..80bea66889a2 100644
--- a/drivers/soc/qcom/wcnss_ctrl.c
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (c) 2016, Linaro Ltd.
  * Copyright (c) 2015, Sony Mobile Communications Inc.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -14,8 +15,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #define WCNSS_REQUEST_TIMEOUT  (5 * HZ)
+#define WCNSS_CBC_TIMEOUT  (10 * HZ)
 
 #define NV_FRAGMENT_SIZE   3072
 #define NVBIN_FILE "wlan/prima/WCNSS_qcom_wlan_nv.bin"
@@ -25,17 +31,19 @@
  * @dev:   device handle
  * @channel:   SMD channel handle
  * @ack:   completion for outstanding requests
+ * @cbc:   completion for cbc complete indication
  * @ack_status:status of the outstanding request
- * @download_nv_work: worker for uploading nv binary
+ * @probe_work: worker for uploading nv binary
  */
 struct wcnss_ctrl {
struct device *dev;
struct qcom_smd_channel *channel;
 
struct completion ack;
+   struct completion cbc;
int ack_status;
 
-   struct work_struct download_nv_work;
+   struct work_struct probe_work;
 };
 
 /* message types */
@@ -48,6 +56,11 @@ enum {
WCNSS_UPLOAD_CAL_RESP,
WCNSS_DOWNLOAD_CAL_REQ,
WCNSS_DOWNLOAD_CAL_RESP,
+   WCNSS_VBAT_LEVEL_IND,
+   WCNSS_BUILD_VERSION_REQ,
+   WCNSS_BUILD_VERSION_RESP,
+   WCNSS_PM_CONFIG_REQ,
+   WCNSS_CBC_COMPLETE_IND,
 };
 
 /**
@@ -128,7 +141,7 @@ static int wcnss_ctrl_smd_callback(struct qcom_smd_channel 
*channel,
 version->major, version->minor,
 version->version, version->revision);
 
-   schedule_work(>download_nv_work);
+   complete(>ack);
break;
case WCNSS_DOWNLOAD_NV_RESP:
if (count != sizeof(*nvresp)) {
@@ -141,6 +154,10 @@ static int wcnss_ctrl_smd_callback(struct qcom_smd_channel 
*channel,
wcnss->ack_status = nvresp->status;
complete(>ack);
break;
+   case WCNSS_CBC_COMPLETE_IND:
+   dev_dbg(wcnss->dev, "WCNSS booted\n");
+   complete(>cbc);
+   break;
default:
dev_info(wcnss->dev, "unknown message type %d\n", hdr->type);
break;
@@ -156,20 +173,32 @@ static int wcnss_ctrl_smd_callback(struct 
qcom_smd_channel *channel,
 static int wcnss_request_version(struct wcnss_ctrl *wcnss)
 {
struct wcnss_msg_hdr msg;
+   int ret;
 
msg.type = WCNSS_VERSION_REQ;
msg.len = sizeof(msg);
+   ret = qcom_smd_send(wcnss->channel, , sizeof(msg));
+   if (ret < 0)
+   return ret;
+
+   ret = wait_for_completion_timeout(>ack, WCNSS_CBC_TIMEOUT);
+   if (!ret) {
+   dev_err(wcnss->dev, "timeout waiting for version response\n");
+   return -ETIMEDOUT;
+   }
 
-   return qcom_smd_send(wcnss->channel, , sizeof(msg));
+   return 0;
 }
 
 /**
  * wcnss_download_nv() - send nv binary to WCNSS
- * @work:  work struct to acquire wcnss context
+ * @wcnss: wcnss_ctrl state handle
+ *
+ * Returns 1 on success or 2 to indicate upcoming cbc completion. Negative
+ * errno on failure.
  */
-static void wcnss_download_nv(struct work_struct *work)
+static int wcnss_download_nv(struct wcnss_ctrl *wcnss)
 {
-   struct wcnss_ctrl *wcnss = container_of(work, struct wcnss_ctrl, 
download_nv_work);
struct wcnss_download_nv_req *req;
const struct firmware *fw;
const void *data;
@@ -178,7 +207,7 @@ static void wcnss_download_nv(struct work_struct *work)
 
req = kzalloc(sizeof(*req) + NV_FRAGMENT_SIZE, GFP_KERNEL);
if (!req)
-   return;
+   return -ENOMEM;
 
ret = request_firmware(, NVBIN_FILE, wcnss->dev);
if (ret) {
@@ -220,16 +249,56 @@ static void wcnss_download_nv(struct work_struct *work)
} while (left > 0);
 
ret = wait_for_completion_timeout(>ack, WCNSS_REQUEST_TIMEOUT);
-   if (!ret)
+   if (!ret) {

[PATCH 1/5] soc: qcom: smd: Make callback pass channel reference

[Bjorn Andersson]

By passing the smd channel reference to the callback, rather than the
smd device, we can open additional smd channels from sub-devices of smd
devices.

Also updates the two smd clients today found in mainline.

Signed-off-by: Bjorn Andersson 
---
 drivers/soc/qcom/smd-rpm.c|  9 ++---
 drivers/soc/qcom/smd.c| 22 ++
 drivers/soc/qcom/wcnss_ctrl.c |  8 
 include/linux/soc/qcom/smd.h  |  7 +--
 4 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index 731fa066f712..6609d7e0edb0 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -33,6 +33,7 @@
  */
 struct qcom_smd_rpm {
struct qcom_smd_channel *rpm_channel;
+   struct device *dev;
 
struct completion ack;
struct mutex lock;
@@ -149,14 +150,14 @@ out:
 }
 EXPORT_SYMBOL(qcom_rpm_smd_write);
 
-static int qcom_smd_rpm_callback(struct qcom_smd_device *qsdev,
+static int qcom_smd_rpm_callback(struct qcom_smd_channel *channel,
 const void *data,
 size_t count)
 {
const struct qcom_rpm_header *hdr = data;
size_t hdr_length = le32_to_cpu(hdr->length);
const struct qcom_rpm_message *msg;
-   struct qcom_smd_rpm *rpm = dev_get_drvdata(>dev);
+   struct qcom_smd_rpm *rpm = qcom_smd_get_drvdata(channel);
const u8 *buf = data + sizeof(struct qcom_rpm_header);
const u8 *end = buf + hdr_length;
char msgbuf[32];
@@ -165,7 +166,7 @@ static int qcom_smd_rpm_callback(struct qcom_smd_device 
*qsdev,
 
if (le32_to_cpu(hdr->service_type) != RPM_SERVICE_TYPE_REQUEST ||
hdr_length < sizeof(struct qcom_rpm_message)) {
-   dev_err(>dev, "invalid request\n");
+   dev_err(rpm->dev, "invalid request\n");
return 0;
}
 
@@ -206,7 +207,9 @@ static int qcom_smd_rpm_probe(struct qcom_smd_device *sdev)
mutex_init(>lock);
init_completion(>ack);
 
+   rpm->dev = >dev;
rpm->rpm_channel = sdev->channel;
+   qcom_smd_set_drvdata(sdev->channel, rpm);
 
dev_set_drvdata(>dev, rpm);
 
diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index b6434c4be86a..ac1957dfdf24 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -194,6 +194,8 @@ struct qcom_smd_channel {
 
int pkt_size;
 
+   void *drvdata;
+
struct list_head list;
struct list_head dev_list;
 };
@@ -513,7 +515,6 @@ static void qcom_smd_channel_advance(struct 
qcom_smd_channel *channel,
  */
 static int qcom_smd_channel_recv_single(struct qcom_smd_channel *channel)
 {
-   struct qcom_smd_device *qsdev = channel->qsdev;
unsigned tail;
size_t len;
void *ptr;
@@ -533,7 +534,7 @@ static int qcom_smd_channel_recv_single(struct 
qcom_smd_channel *channel)
len = channel->pkt_size;
}
 
-   ret = channel->cb(qsdev, ptr, len);
+   ret = channel->cb(channel, ptr, len);
if (ret < 0)
return ret;
 
@@ -1034,6 +1035,18 @@ int qcom_smd_driver_register(struct qcom_smd_driver 
*qsdrv)
 }
 EXPORT_SYMBOL(qcom_smd_driver_register);
 
+void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel)
+{
+   return channel->drvdata;
+}
+EXPORT_SYMBOL(qcom_smd_get_drvdata);
+
+void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void *data)
+{
+   channel->drvdata = data;
+}
+EXPORT_SYMBOL(qcom_smd_set_drvdata);
+
 /**
  * qcom_smd_driver_unregister - unregister a smd driver
  * @qsdrv: qcom_smd_driver struct
@@ -1079,12 +1092,13 @@ qcom_smd_find_channel(struct qcom_smd_edge *edge, const 
char *name)
  * Returns a channel handle on success, or -EPROBE_DEFER if the channel isn't
  * ready.
  */
-struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_channel *parent,
   const char *name,
   qcom_smd_cb_t cb)
 {
struct qcom_smd_channel *channel;
-   struct qcom_smd_edge *edge = sdev->channel->edge;
+   struct qcom_smd_device *sdev = parent->qsdev;
+   struct qcom_smd_edge *edge = parent->edge;
int ret;
 
/* Wait up to HZ for the channel to appear */
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
index 7a986f881d5c..c544f3d2c6ee 100644
--- a/drivers/soc/qcom/wcnss_ctrl.c
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -100,17 +100,17 @@ struct wcnss_download_nv_resp {
 
 /**
  * wcnss_ctrl_smd_callback() - handler from SMD responses
- * @qsdev: smd device handle
+ * @channel:   smd channel handle
  * @data:  pointer to the incoming data packet
  * @count: size of the incoming data packet
  *
  * Handles any incoming packets from the remote WCNSS_CTRL service.
  */
-static 

[PATCH 1/5] soc: qcom: smd: Make callback pass channel reference

[Bjorn Andersson]

By passing the smd channel reference to the callback, rather than the
smd device, we can open additional smd channels from sub-devices of smd
devices.

Also updates the two smd clients today found in mainline.

Signed-off-by: Bjorn Andersson 
---
 drivers/soc/qcom/smd-rpm.c|  9 ++---
 drivers/soc/qcom/smd.c| 22 ++
 drivers/soc/qcom/wcnss_ctrl.c |  8 
 include/linux/soc/qcom/smd.h  |  7 +--
 4 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index 731fa066f712..6609d7e0edb0 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -33,6 +33,7 @@
  */
 struct qcom_smd_rpm {
struct qcom_smd_channel *rpm_channel;
+   struct device *dev;
 
struct completion ack;
struct mutex lock;
@@ -149,14 +150,14 @@ out:
 }
 EXPORT_SYMBOL(qcom_rpm_smd_write);
 
-static int qcom_smd_rpm_callback(struct qcom_smd_device *qsdev,
+static int qcom_smd_rpm_callback(struct qcom_smd_channel *channel,
 const void *data,
 size_t count)
 {
const struct qcom_rpm_header *hdr = data;
size_t hdr_length = le32_to_cpu(hdr->length);
const struct qcom_rpm_message *msg;
-   struct qcom_smd_rpm *rpm = dev_get_drvdata(>dev);
+   struct qcom_smd_rpm *rpm = qcom_smd_get_drvdata(channel);
const u8 *buf = data + sizeof(struct qcom_rpm_header);
const u8 *end = buf + hdr_length;
char msgbuf[32];
@@ -165,7 +166,7 @@ static int qcom_smd_rpm_callback(struct qcom_smd_device 
*qsdev,
 
if (le32_to_cpu(hdr->service_type) != RPM_SERVICE_TYPE_REQUEST ||
hdr_length < sizeof(struct qcom_rpm_message)) {
-   dev_err(>dev, "invalid request\n");
+   dev_err(rpm->dev, "invalid request\n");
return 0;
}
 
@@ -206,7 +207,9 @@ static int qcom_smd_rpm_probe(struct qcom_smd_device *sdev)
mutex_init(>lock);
init_completion(>ack);
 
+   rpm->dev = >dev;
rpm->rpm_channel = sdev->channel;
+   qcom_smd_set_drvdata(sdev->channel, rpm);
 
dev_set_drvdata(>dev, rpm);
 
diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index b6434c4be86a..ac1957dfdf24 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -194,6 +194,8 @@ struct qcom_smd_channel {
 
int pkt_size;
 
+   void *drvdata;
+
struct list_head list;
struct list_head dev_list;
 };
@@ -513,7 +515,6 @@ static void qcom_smd_channel_advance(struct 
qcom_smd_channel *channel,
  */
 static int qcom_smd_channel_recv_single(struct qcom_smd_channel *channel)
 {
-   struct qcom_smd_device *qsdev = channel->qsdev;
unsigned tail;
size_t len;
void *ptr;
@@ -533,7 +534,7 @@ static int qcom_smd_channel_recv_single(struct 
qcom_smd_channel *channel)
len = channel->pkt_size;
}
 
-   ret = channel->cb(qsdev, ptr, len);
+   ret = channel->cb(channel, ptr, len);
if (ret < 0)
return ret;
 
@@ -1034,6 +1035,18 @@ int qcom_smd_driver_register(struct qcom_smd_driver 
*qsdrv)
 }
 EXPORT_SYMBOL(qcom_smd_driver_register);
 
+void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel)
+{
+   return channel->drvdata;
+}
+EXPORT_SYMBOL(qcom_smd_get_drvdata);
+
+void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void *data)
+{
+   channel->drvdata = data;
+}
+EXPORT_SYMBOL(qcom_smd_set_drvdata);
+
 /**
  * qcom_smd_driver_unregister - unregister a smd driver
  * @qsdrv: qcom_smd_driver struct
@@ -1079,12 +1092,13 @@ qcom_smd_find_channel(struct qcom_smd_edge *edge, const 
char *name)
  * Returns a channel handle on success, or -EPROBE_DEFER if the channel isn't
  * ready.
  */
-struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_channel *parent,
   const char *name,
   qcom_smd_cb_t cb)
 {
struct qcom_smd_channel *channel;
-   struct qcom_smd_edge *edge = sdev->channel->edge;
+   struct qcom_smd_device *sdev = parent->qsdev;
+   struct qcom_smd_edge *edge = parent->edge;
int ret;
 
/* Wait up to HZ for the channel to appear */
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
index 7a986f881d5c..c544f3d2c6ee 100644
--- a/drivers/soc/qcom/wcnss_ctrl.c
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -100,17 +100,17 @@ struct wcnss_download_nv_resp {
 
 /**
  * wcnss_ctrl_smd_callback() - handler from SMD responses
- * @qsdev: smd device handle
+ * @channel:   smd channel handle
  * @data:  pointer to the incoming data packet
  * @count: size of the incoming data packet
  *
  * Handles any incoming packets from the remote WCNSS_CTRL service.
  */
-static int 

[PATCH 5/5] ARM: dts: qcom: msm8974: Introduce pronto node

[Bjorn Andersson]

From: Bjorn Andersson 

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   |  4 +++
 arch/arm/boot/dts/qcom-msm8974.dtsi| 29 ++
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index a0398b69f4f2..e4e1ff6b0d98 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -59,6 +59,10 @@
};
 
smd {
+   pronto {
+   status = "ok";
+   };
+
rpm {
rpm_requests {
pm8841-regulators {
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index ef5330578431..b67963695e95 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -494,6 +494,35 @@
smd {
compatible = "qcom,smd";
 
+   pronto {
+   status = "disabled";
+   interrupts = <0 142 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 17>;
+   qcom,smd-edge = <6>;
+
+   wcnss {
+   compatible = "qcom,wcnss";
+   qcom,smd-channels = "WCNSS_CTRL";
+
+   bt {
+   compatible = "qcom,btqcomsmd";
+   };
+
+   wifi {
+   compatible = "qcom,wcn3680-wlan";
+
+   interrupts = <0 145 0>, <0 146 0>;
+   interrupt-names = "tx", "rx";
+
+   qcom,wcnss-mmio = <0xfb00 0x21b000>;
+
+   qcom,state = <_smsm 10>, 
<_smsm 9>;
+   qcom,state-names = "tx-enable", 
"tx-rings-empty";
+   };
+   };
+   };
+
rpm {
interrupts = <0 168 1>;
qcom,ipc = < 8 0>;
-- 
2.5.0

[PATCH 5/5] ARM: dts: qcom: msm8974: Introduce pronto node

[Bjorn Andersson]

From: Bjorn Andersson 

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   |  4 +++
 arch/arm/boot/dts/qcom-msm8974.dtsi| 29 ++
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index a0398b69f4f2..e4e1ff6b0d98 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -59,6 +59,10 @@
};
 
smd {
+   pronto {
+   status = "ok";
+   };
+
rpm {
rpm_requests {
pm8841-regulators {
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index ef5330578431..b67963695e95 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -494,6 +494,35 @@
smd {
compatible = "qcom,smd";
 
+   pronto {
+   status = "disabled";
+   interrupts = <0 142 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 17>;
+   qcom,smd-edge = <6>;
+
+   wcnss {
+   compatible = "qcom,wcnss";
+   qcom,smd-channels = "WCNSS_CTRL";
+
+   bt {
+   compatible = "qcom,btqcomsmd";
+   };
+
+   wifi {
+   compatible = "qcom,wcn3680-wlan";
+
+   interrupts = <0 145 0>, <0 146 0>;
+   interrupt-names = "tx", "rx";
+
+   qcom,wcnss-mmio = <0xfb00 0x21b000>;
+
+   qcom,state = <_smsm 10>, 
<_smsm 9>;
+   qcom,state-names = "tx-enable", 
"tx-rings-empty";
+   };
+   };
+   };
+
rpm {
interrupts = <0 168 1>;
qcom,ipc = < 8 0>;
-- 
2.5.0

[PATCH 2/5] soc: qcom: smem: Use write-combine remap for SMEM

[Bjorn Andersson]

Mapping the SMEM region as write combine makes the contiguous writes
in SMD perform better and also allows us to do unaligned read and writes
on ARM64.

Signed-off-by: Bjorn Andersson 
---
 drivers/soc/qcom/smem.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 19019aa092e8..2e1aa9f130f4 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -684,8 +684,7 @@ static int qcom_smem_map_memory(struct qcom_smem *smem, 
struct device *dev,
 
smem->regions[i].aux_base = (u32)r.start;
smem->regions[i].size = resource_size();
-   smem->regions[i].virt_base = devm_ioremap_nocache(dev, r.start,
- resource_size());
+   smem->regions[i].virt_base = devm_ioremap_wc(dev, r.start, 
resource_size());
if (!smem->regions[i].virt_base)
return -ENOMEM;
 
-- 
2.5.0

[PATCH 2/5] soc: qcom: smem: Use write-combine remap for SMEM

[Bjorn Andersson]

Mapping the SMEM region as write combine makes the contiguous writes
in SMD perform better and also allows us to do unaligned read and writes
on ARM64.

Signed-off-by: Bjorn Andersson 
---
 drivers/soc/qcom/smem.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 19019aa092e8..2e1aa9f130f4 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -684,8 +684,7 @@ static int qcom_smem_map_memory(struct qcom_smem *smem, 
struct device *dev,
 
smem->regions[i].aux_base = (u32)r.start;
smem->regions[i].size = resource_size();
-   smem->regions[i].virt_base = devm_ioremap_nocache(dev, r.start,
- resource_size());
+   smem->regions[i].virt_base = devm_ioremap_wc(dev, r.start, 
resource_size());
if (!smem->regions[i].virt_base)
return -ENOMEM;
 
-- 
2.5.0

Re: [PATCH V8 00/14] Add T210 support in Tegra soctherm

[Wei Ni]

On 2016年03月29日 11:29, Eduardo Valentin wrote:
> On Mon, Mar 28, 2016 at 08:04:41PM -0700, Eduardo Valentin wrote:
>> On Fri, Mar 25, 2016 at 01:37:17PM +0800, Wei Ni wrote:
>>> Hi, Eduardo
>>> Will you take this series, it seems no more comments.
>>
>> Yeah, I am taking a look at it. Something is fishy about it. Patch 04
>> does not apply cleanly. Also, why did you split the patches into two
>> email threads, one which is 1-4 and another one is 5-14?
>>
>> I have ammended patch 04 at my side, but you need to validate your
>> series is one piece (please check my tree and linux-next).
> 
> This didn't quite work. Please refresh your series on top of my fixes
> branch so I can apply your series cleanly.

Yes, I will do it.

> 
>>
>> BR,
>>
>> Eduardo Valentin
>>
>>>

Re: [PATCH V8 00/14] Add T210 support in Tegra soctherm

[Wei Ni]

On 2016年03月29日 11:29, Eduardo Valentin wrote:
> On Mon, Mar 28, 2016 at 08:04:41PM -0700, Eduardo Valentin wrote:
>> On Fri, Mar 25, 2016 at 01:37:17PM +0800, Wei Ni wrote:
>>> Hi, Eduardo
>>> Will you take this series, it seems no more comments.
>>
>> Yeah, I am taking a look at it. Something is fishy about it. Patch 04
>> does not apply cleanly. Also, why did you split the patches into two
>> email threads, one which is 1-4 and another one is 5-14?
>>
>> I have ammended patch 04 at my side, but you need to validate your
>> series is one piece (please check my tree and linux-next).
> 
> This didn't quite work. Please refresh your series on top of my fixes
> branch so I can apply your series cleanly.

Yes, I will do it.

> 
>>
>> BR,
>>
>> Eduardo Valentin
>>
>>>

fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH]

[Kent Overstreet]

Bit of previous discussion:
http://thread.gmane.org/gmane.linux.file-systems/101201/

The underlying issue is that we have no mechanism for invalidating a range of
the pagecache and then _keeping it invalidated_ while we Do Stuff. 

The fallocate INSERT_RANGE/COLLAPSE_RANGE situation seems likely to be worse
than I initially thought. I've been digging into this in the course of bcachefs
testing - I was hitting assertions that meant state hanging off the page cache
(in this case, allocation information, i.e. whether we needed to reserve space
on write) was inconsistent with the btree in writepages().

Well, bcachefs isn't the only filesystem that hangs additional state off the
pagecache, and the situation today is that an unpriviliged user can cause
inconsistencies there by just doing buffered reads concurrently with
INSERT_RANGE/COLLAPSE_RANGE. I highly highly doubt this is an issue of just
"oops, you corrupted your file because you were doing stupid stuff" - who knows
what internal invariants are getting broken here, and I don't particularly care
to find out.

I'm pretty certain that ext4 and xfs are both broken here - I haven't dug into
the btrfs code. The impression I get from reading the code is that whoever wrote
it was cripping off of truncate - except that truncate relies on the i_size
change to work; without that there's no way this code can possibly work.

That's the bad news. Good news is, I think it's fixable.

My solution is just to add a lock (per address_space) around adding pages to the
pagecache - it's got some funny semantics so as to be usable for dio writes, but
it's just a lock. (It's got two states like an rwlock, except that both states
are shared and only exclusive with the other states; dio writes don't block
other dio writes, buffered IO adding pages to the pagecache does't block other
pages being added).

The only tricky bit is the recursion Dave noted in the dio write path -
get_user_pages() -> fault(). My solution is to just keep track of what address
space we have locked (blocking page adds) in task_struct, then A) don't deadlock
in __add_to_page_cache_locked(), and B) don't do readahead in filemap_fault()
(which means we can delete another hack from the dio write code).

I don't particularly care for where the add side of the lock is taken - it
works, but it means we can't distinguish accidental recursion from intentional.
I'm open to ideas there. Also, we made better use of the add side of the lock we
could probably delete a lot of fragile code for synchronization with truncate.

Patch below is reliably passing xfstests for me (where previously I was hitting
the aforementioned pagecache inconsistency assertions). I've only hooked up
bcachefs so far, other filesystems should be pretty trivial (but it does need
individual filesystems to be converted).

One issue I haven't dealt with is that dio writes can starve buffered IO/mmapped
IO with this lock - not sure if that's worth dealing with.

Patch below includes bcachefs changes, but is otherwise on 4.5. Available in my
usual git repo:

https://evilpiepirate.org/git/linux-bcache.git/log/?h=bcache-dev-pagecache-lock

-- >8 --
Subject: [PATCH] mm: pagecache add lock

Add a per address space lock around adding pages to the pagecache - making it
possible for fallocate INSERT_RANGE/COLLAPSE_RANGE to work correctly, and also
hopefully making truncate and dio a bit saner.

Signed-off-by: Kent Overstreet 
---
 drivers/md/bcache/fs-io.c | 197 +-
 fs/inode.c|   1 +
 include/linux/fs.h|  23 ++
 include/linux/init_task.h |   1 +
 include/linux/sched.h |   4 +
 mm/filemap.c  |  85 ++--
 6 files changed, 217 insertions(+), 94 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 69b8b526c1..617c61e070 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -345,6 +345,7 @@ void address_space_init_once(struct address_space *mapping)
 {
memset(mapping, 0, sizeof(*mapping));
INIT_RADIX_TREE(>page_tree, GFP_ATOMIC);
+   pagecache_lock_init(>add_lock);
spin_lock_init(>tree_lock);
init_rwsem(>i_mmap_rwsem);
INIT_LIST_HEAD(>private_list);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index ae68100210..a806c09c21 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -424,9 +424,32 @@ int pagecache_write_end(struct file *, struct 
address_space *mapping,
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata);
 
+/*
+ * Two-state lock - can be taken for add or block - both states are shared,
+ * like read side of rwsem, but conflict with other state:
+ */
+struct pagecache_lock {
+   atomic_long_t   v;
+   wait_queue_head_t   wait;
+};
+
+static inline void pagecache_lock_init(struct pagecache_lock *lock)
+{
+   atomic_long_set(>v, 0);
+   

fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH]

[Kent Overstreet]

Bit of previous discussion:
http://thread.gmane.org/gmane.linux.file-systems/101201/

The underlying issue is that we have no mechanism for invalidating a range of
the pagecache and then _keeping it invalidated_ while we Do Stuff. 

The fallocate INSERT_RANGE/COLLAPSE_RANGE situation seems likely to be worse
than I initially thought. I've been digging into this in the course of bcachefs
testing - I was hitting assertions that meant state hanging off the page cache
(in this case, allocation information, i.e. whether we needed to reserve space
on write) was inconsistent with the btree in writepages().

Well, bcachefs isn't the only filesystem that hangs additional state off the
pagecache, and the situation today is that an unpriviliged user can cause
inconsistencies there by just doing buffered reads concurrently with
INSERT_RANGE/COLLAPSE_RANGE. I highly highly doubt this is an issue of just
"oops, you corrupted your file because you were doing stupid stuff" - who knows
what internal invariants are getting broken here, and I don't particularly care
to find out.

I'm pretty certain that ext4 and xfs are both broken here - I haven't dug into
the btrfs code. The impression I get from reading the code is that whoever wrote
it was cripping off of truncate - except that truncate relies on the i_size
change to work; without that there's no way this code can possibly work.

That's the bad news. Good news is, I think it's fixable.

My solution is just to add a lock (per address_space) around adding pages to the
pagecache - it's got some funny semantics so as to be usable for dio writes, but
it's just a lock. (It's got two states like an rwlock, except that both states
are shared and only exclusive with the other states; dio writes don't block
other dio writes, buffered IO adding pages to the pagecache does't block other
pages being added).

The only tricky bit is the recursion Dave noted in the dio write path -
get_user_pages() -> fault(). My solution is to just keep track of what address
space we have locked (blocking page adds) in task_struct, then A) don't deadlock
in __add_to_page_cache_locked(), and B) don't do readahead in filemap_fault()
(which means we can delete another hack from the dio write code).

I don't particularly care for where the add side of the lock is taken - it
works, but it means we can't distinguish accidental recursion from intentional.
I'm open to ideas there. Also, we made better use of the add side of the lock we
could probably delete a lot of fragile code for synchronization with truncate.

Patch below is reliably passing xfstests for me (where previously I was hitting
the aforementioned pagecache inconsistency assertions). I've only hooked up
bcachefs so far, other filesystems should be pretty trivial (but it does need
individual filesystems to be converted).

One issue I haven't dealt with is that dio writes can starve buffered IO/mmapped
IO with this lock - not sure if that's worth dealing with.

Patch below includes bcachefs changes, but is otherwise on 4.5. Available in my
usual git repo:

https://evilpiepirate.org/git/linux-bcache.git/log/?h=bcache-dev-pagecache-lock

-- >8 --
Subject: [PATCH] mm: pagecache add lock

Add a per address space lock around adding pages to the pagecache - making it
possible for fallocate INSERT_RANGE/COLLAPSE_RANGE to work correctly, and also
hopefully making truncate and dio a bit saner.

Signed-off-by: Kent Overstreet 
---
 drivers/md/bcache/fs-io.c | 197 +-
 fs/inode.c|   1 +
 include/linux/fs.h|  23 ++
 include/linux/init_task.h |   1 +
 include/linux/sched.h |   4 +
 mm/filemap.c  |  85 ++--
 6 files changed, 217 insertions(+), 94 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 69b8b526c1..617c61e070 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -345,6 +345,7 @@ void address_space_init_once(struct address_space *mapping)
 {
memset(mapping, 0, sizeof(*mapping));
INIT_RADIX_TREE(>page_tree, GFP_ATOMIC);
+   pagecache_lock_init(>add_lock);
spin_lock_init(>tree_lock);
init_rwsem(>i_mmap_rwsem);
INIT_LIST_HEAD(>private_list);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index ae68100210..a806c09c21 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -424,9 +424,32 @@ int pagecache_write_end(struct file *, struct 
address_space *mapping,
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata);
 
+/*
+ * Two-state lock - can be taken for add or block - both states are shared,
+ * like read side of rwsem, but conflict with other state:
+ */
+struct pagecache_lock {
+   atomic_long_t   v;
+   wait_queue_head_t   wait;
+};
+
+static inline void pagecache_lock_init(struct pagecache_lock *lock)
+{
+   atomic_long_set(>v, 0);
+   init_waitqueue_head(>wait);
+}
+
+void 

Re: [PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Seung-Woo Kim]

Hello Javier,

On 2016년 03월 29일 11:41, Javier Martinez Canillas wrote:
> Hello Seung-Woo,
> 
> Thanks a lot for your feedback.
> 
> On 03/28/2016 09:46 PM, Seung-Woo Kim wrote:
>> Hi Javier,
>>
>> On 2016년 03월 29일 10:28, Javier Martinez Canillas wrote:
>>> Hello Inki,
>>>
>>> This patch series contains some fixes for the Kconfig symbol dependencies
>>> of the Exynos DRM driver. They make sure that the Exynos DRM components
>>> and the media platform drivers that makes use of the same HW IP block are
>>> not enabled at the same time.
>>>
>>> Best regards,
>>> Javier
>>>
>>>
>>> Javier Martinez Canillas (3):
>>>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>>>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>>>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
>>
>> In G2D case, there is only one instance, but for the other cases, there
>> are several instances and in my environment, I enable both drivers on
>> v4l2 and drm FIMC/GSC.
>>
>> So, IMHO, the not-enabled v4l2 dependency is not really required for drm
>> fimc and drm gsc.
>>
> 
> I'm confused, it was you who added the depends on !VIDEO_SAMSUNG_EXYNOS_GSC
> for DRM_EXYNOS_GSC in commit aeefb36832e5 ("drm/exynos: gsc: add device tree
> support and remove usage of static mappings").

Yes, you are right. Originally, my goal on the GSC was bringing optional
flag for setting isp mode or wb mode like FIMC in tizen.org git tree.

https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blobdiff;f=Documentation/devicetree/bindings/media/exynos5-gsc.txt;h=d526777a3abd04d244c46fdd729e3df93bb86917;hp=0604d42f38d1941526d47ad11a958a2a83797f97;hb=751cd6d88d9620c83042641b52fdd244408a3947;hpb=7c7ab44f86d64ba6a6733da8f201a26a6c0e807f

But only devicetree part of GSC was upstreamed and simultaneous enabling
both v4l2 gsc and drm gsc driver is removed. The only reason I set both
driver simultaneously was enabling video codec, exynos-mfc with gsc to
convert RGB plane.

I know Marek already has plan to integrate yuv plane feature of GSC to
DRM KMS. Also, for GSC, simultaneous setup is alredy remove, so your
patch seems better.

> 
>>From the commit message "The driver cannot be used simultaneously with V4L2
> Mem2Mem GScaller driver thought". Did that assumption changed and the depend
> should be removed then? or maybe I misunderstood what you meant.
> 
> Now, I'm not really sure about FIMC either, it was feedback I got from this
> patch [0]. Could you please take a look to that and let me know if enabling
> these drivers simultaneously makes sense then?

About FIMC, there is still simultaneous setup for both v4l2 and drm
driver with devicetree binding flags, samsung,isp-wb and samsung,lcd-wb.

If on the FIMC instance of dt node, samsung,lcd-wb is set, then drm
driver is probed, otherwise v4l2 driver is probed.

Simultaneous FIMC driver is also only for RGB converting of video codec
planes like GSC at least to me.

Marek, do you have any idea about the simultaneous setup for fimc and gsc?

Best Regards,
- Seung-Woo Kim

> 
>> Best Regards,
>> - Seung-Woo Kim
>>
>>>
>>>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>
> 
> [0]: https://lkml.org/lkml/2016/3/23/292
> 
> Best regards,
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

Re: [PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Seung-Woo Kim]

Hello Javier,

On 2016년 03월 29일 11:41, Javier Martinez Canillas wrote:
> Hello Seung-Woo,
> 
> Thanks a lot for your feedback.
> 
> On 03/28/2016 09:46 PM, Seung-Woo Kim wrote:
>> Hi Javier,
>>
>> On 2016년 03월 29일 10:28, Javier Martinez Canillas wrote:
>>> Hello Inki,
>>>
>>> This patch series contains some fixes for the Kconfig symbol dependencies
>>> of the Exynos DRM driver. They make sure that the Exynos DRM components
>>> and the media platform drivers that makes use of the same HW IP block are
>>> not enabled at the same time.
>>>
>>> Best regards,
>>> Javier
>>>
>>>
>>> Javier Martinez Canillas (3):
>>>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>>>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>>>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
>>
>> In G2D case, there is only one instance, but for the other cases, there
>> are several instances and in my environment, I enable both drivers on
>> v4l2 and drm FIMC/GSC.
>>
>> So, IMHO, the not-enabled v4l2 dependency is not really required for drm
>> fimc and drm gsc.
>>
> 
> I'm confused, it was you who added the depends on !VIDEO_SAMSUNG_EXYNOS_GSC
> for DRM_EXYNOS_GSC in commit aeefb36832e5 ("drm/exynos: gsc: add device tree
> support and remove usage of static mappings").

Yes, you are right. Originally, my goal on the GSC was bringing optional
flag for setting isp mode or wb mode like FIMC in tizen.org git tree.

https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blobdiff;f=Documentation/devicetree/bindings/media/exynos5-gsc.txt;h=d526777a3abd04d244c46fdd729e3df93bb86917;hp=0604d42f38d1941526d47ad11a958a2a83797f97;hb=751cd6d88d9620c83042641b52fdd244408a3947;hpb=7c7ab44f86d64ba6a6733da8f201a26a6c0e807f

But only devicetree part of GSC was upstreamed and simultaneous enabling
both v4l2 gsc and drm gsc driver is removed. The only reason I set both
driver simultaneously was enabling video codec, exynos-mfc with gsc to
convert RGB plane.

I know Marek already has plan to integrate yuv plane feature of GSC to
DRM KMS. Also, for GSC, simultaneous setup is alredy remove, so your
patch seems better.

> 
>>From the commit message "The driver cannot be used simultaneously with V4L2
> Mem2Mem GScaller driver thought". Did that assumption changed and the depend
> should be removed then? or maybe I misunderstood what you meant.
> 
> Now, I'm not really sure about FIMC either, it was feedback I got from this
> patch [0]. Could you please take a look to that and let me know if enabling
> these drivers simultaneously makes sense then?

About FIMC, there is still simultaneous setup for both v4l2 and drm
driver with devicetree binding flags, samsung,isp-wb and samsung,lcd-wb.

If on the FIMC instance of dt node, samsung,lcd-wb is set, then drm
driver is probed, otherwise v4l2 driver is probed.

Simultaneous FIMC driver is also only for RGB converting of video codec
planes like GSC at least to me.

Marek, do you have any idea about the simultaneous setup for fimc and gsc?

Best Regards,
- Seung-Woo Kim

> 
>> Best Regards,
>> - Seung-Woo Kim
>>
>>>
>>>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>
> 
> [0]: https://lkml.org/lkml/2016/3/23/292
> 
> Best regards,
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

[PATCH] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi

[fu . wei]

From: Fu Wei 

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Fu Wei 
Reviewed-by: Guenter Roeck 
---
Changelog:
v1 :Re-upstream it, since this patch was missed when we upstreamed it with
the driver patchset: https://lkml.org/lkml/2016/3/28/226

 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi 
b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index bd3adea..9798fd0 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -106,6 +106,14 @@
clock-names = "uartclk", "apb_pclk";
};
 
+   watchdog0: watchdog@e0bb {
+   compatible = "arm,sbsa-gwdt";
+   reg = <0x0 0xe0bc 0 0x1000>,
+   <0x0 0xe0bb 0 0x1000>;
+   interrupts = <0 337 4>;
+   timeout-sec = <15>;
+   };
+
spi0: ssp@e102 {
status = "disabled";
compatible = "arm,pl022", "arm,primecell";
-- 
2.5.0

[PATCH] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi

[fu . wei]

From: Fu Wei 

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Fu Wei 
Reviewed-by: Guenter Roeck 
---
Changelog:
v1 :Re-upstream it, since this patch was missed when we upstreamed it with
the driver patchset: https://lkml.org/lkml/2016/3/28/226

 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi 
b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index bd3adea..9798fd0 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -106,6 +106,14 @@
clock-names = "uartclk", "apb_pclk";
};
 
+   watchdog0: watchdog@e0bb {
+   compatible = "arm,sbsa-gwdt";
+   reg = <0x0 0xe0bc 0 0x1000>,
+   <0x0 0xe0bb 0 0x1000>;
+   interrupts = <0 337 4>;
+   timeout-sec = <15>;
+   };
+
spi0: ssp@e102 {
status = "disabled";
compatible = "arm,pl022", "arm,primecell";
-- 
2.5.0

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Viresh Kumar]

On 29-03-16, 09:48, Viresh Kumar wrote:
> On 29-03-16, 13:10, Krzysztof Kozlowski wrote:
> > On 24.03.2016 15:40, Viresh Kumar wrote:
> > > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> > > device now, reuse that and remove similar code from platform code.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > > ---
> > >  arch/arm/mach-exynos/exynos.c| 25 -
> > >  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
> > >  2 files changed, 5 insertions(+), 25 deletions(-)
> > 
> > Looks fine to me... except that it is a little bit outdated. Please
> > rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.
> 
> Yeah, I know. I already have the updated version.

Here it is:

From: Viresh Kumar 
Date: Thu, 24 Mar 2016 12:04:10 +0530
Subject: [PATCH] cpufreq: exynos: Use generic platdev driver

The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
device now, reuse that and remove similar code from platform code.

Signed-off-by: Viresh Kumar 
---
 arch/arm/mach-exynos/exynos.c| 29 -
 drivers/cpufreq/cpufreq-dt-platdev.c |  9 +
 2 files changed, 9 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index bbf51a46f772..4d3b056fd786 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -213,33 +213,6 @@ static void __init exynos_init_irq(void)
exynos_map_pmu();
 }
 
-static const struct of_device_id exynos_cpufreq_matches[] = {
-   { .compatible = "samsung,exynos3250", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos4210", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
-#ifndef CONFIG_BL_SWITCHER
-   { .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos5800", .data = "cpufreq-dt" },
-#endif
-   { /* sentinel */ }
-};
-
-static void __init exynos_cpufreq_init(void)
-{
-   struct device_node *root = of_find_node_by_path("/");
-   const struct of_device_id *match;
-
-   match = of_match_node(exynos_cpufreq_matches, root);
-   if (!match) {
-   platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
-   return;
-   }
-
-   platform_device_register_simple(match->data, -1, NULL, 0);
-}
-
 static void __init exynos_dt_machine_init(void)
 {
/*
@@ -262,8 +235,6 @@ static void __init exynos_dt_machine_init(void)
of_machine_is_compatible("samsung,exynos5250"))
platform_device_register(_cpuidle);
 
-   exynos_cpufreq_init();
-
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 18b81724ca0b..f85d1ab5d621 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -20,6 +20,15 @@ struct cpufreq_dt_compat {
 };
 
 static struct cpufreq_dt_compat compat[] = {
+   { "samsung,exynos3250", NULL,   0 },
+   { "samsung,exynos4210", NULL,   0 },
+   { "samsung,exynos4212", NULL,   0 },
+   { "samsung,exynos4412", NULL,   0 },
+   { "samsung,exynos5250", NULL,   0 },
+#ifndef CONFIG_BL_SWITCHER
+   { "samsung,exynos5420", NULL,   0 },
+   { "samsung,exynos5800", NULL,   0 },
+#endif
 };
 
 static int __init cpufreq_dt_platdev_init(void)


-- 
viresh

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Viresh Kumar]

On 29-03-16, 09:48, Viresh Kumar wrote:
> On 29-03-16, 13:10, Krzysztof Kozlowski wrote:
> > On 24.03.2016 15:40, Viresh Kumar wrote:
> > > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> > > device now, reuse that and remove similar code from platform code.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > > ---
> > >  arch/arm/mach-exynos/exynos.c| 25 -
> > >  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
> > >  2 files changed, 5 insertions(+), 25 deletions(-)
> > 
> > Looks fine to me... except that it is a little bit outdated. Please
> > rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.
> 
> Yeah, I know. I already have the updated version.

Here it is:

From: Viresh Kumar 
Date: Thu, 24 Mar 2016 12:04:10 +0530
Subject: [PATCH] cpufreq: exynos: Use generic platdev driver

The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
device now, reuse that and remove similar code from platform code.

Signed-off-by: Viresh Kumar 
---
 arch/arm/mach-exynos/exynos.c| 29 -
 drivers/cpufreq/cpufreq-dt-platdev.c |  9 +
 2 files changed, 9 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index bbf51a46f772..4d3b056fd786 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -213,33 +213,6 @@ static void __init exynos_init_irq(void)
exynos_map_pmu();
 }
 
-static const struct of_device_id exynos_cpufreq_matches[] = {
-   { .compatible = "samsung,exynos3250", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos4210", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
-#ifndef CONFIG_BL_SWITCHER
-   { .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
-   { .compatible = "samsung,exynos5800", .data = "cpufreq-dt" },
-#endif
-   { /* sentinel */ }
-};
-
-static void __init exynos_cpufreq_init(void)
-{
-   struct device_node *root = of_find_node_by_path("/");
-   const struct of_device_id *match;
-
-   match = of_match_node(exynos_cpufreq_matches, root);
-   if (!match) {
-   platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
-   return;
-   }
-
-   platform_device_register_simple(match->data, -1, NULL, 0);
-}
-
 static void __init exynos_dt_machine_init(void)
 {
/*
@@ -262,8 +235,6 @@ static void __init exynos_dt_machine_init(void)
of_machine_is_compatible("samsung,exynos5250"))
platform_device_register(_cpuidle);
 
-   exynos_cpufreq_init();
-
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 18b81724ca0b..f85d1ab5d621 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -20,6 +20,15 @@ struct cpufreq_dt_compat {
 };
 
 static struct cpufreq_dt_compat compat[] = {
+   { "samsung,exynos3250", NULL,   0 },
+   { "samsung,exynos4210", NULL,   0 },
+   { "samsung,exynos4212", NULL,   0 },
+   { "samsung,exynos4412", NULL,   0 },
+   { "samsung,exynos5250", NULL,   0 },
+#ifndef CONFIG_BL_SWITCHER
+   { "samsung,exynos5420", NULL,   0 },
+   { "samsung,exynos5800", NULL,   0 },
+#endif
 };
 
 static int __init cpufreq_dt_platdev_init(void)


-- 
viresh

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Viresh Kumar]

On 29-03-16, 13:10, Krzysztof Kozlowski wrote:
> On 24.03.2016 15:40, Viresh Kumar wrote:
> > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> > device now, reuse that and remove similar code from platform code.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  arch/arm/mach-exynos/exynos.c| 25 -
> >  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
> >  2 files changed, 5 insertions(+), 25 deletions(-)
> 
> Looks fine to me... except that it is a little bit outdated. Please
> rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.

Yeah, I know. I already have the updated version.

-- 
viresh

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Viresh Kumar]

On 29-03-16, 13:10, Krzysztof Kozlowski wrote:
> On 24.03.2016 15:40, Viresh Kumar wrote:
> > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> > device now, reuse that and remove similar code from platform code.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  arch/arm/mach-exynos/exynos.c| 25 -
> >  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
> >  2 files changed, 5 insertions(+), 25 deletions(-)
> 
> Looks fine to me... except that it is a little bit outdated. Please
> rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.

Yeah, I know. I already have the updated version.

-- 
viresh

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Krzysztof Kozlowski]

On 24.03.2016 15:40, Viresh Kumar wrote:
> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> device now, reuse that and remove similar code from platform code.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  arch/arm/mach-exynos/exynos.c| 25 -
>  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
>  2 files changed, 5 insertions(+), 25 deletions(-)

Looks fine to me... except that it is a little bit outdated. Please
rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.

Best regards,

Krzysztof

Re: [PATCH 3/3] cpufreq: exynos: Use generic platdev driver

[Krzysztof Kozlowski]

On 24.03.2016 15:40, Viresh Kumar wrote:
> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> device now, reuse that and remove similar code from platform code.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  arch/arm/mach-exynos/exynos.c| 25 -
>  drivers/cpufreq/cpufreq-dt-platdev.c |  5 +
>  2 files changed, 5 insertions(+), 25 deletions(-)

Looks fine to me... except that it is a little bit outdated. Please
rebase on v4.6-rc1 because Bartlomiej added support for cpufreq @Exynos542x.

Best regards,

Krzysztof

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

[Mike Galbraith]

On Fri, 2016-03-25 at 17:24 +0100, Mike Galbraith wrote:
> On Fri, 2016-03-25 at 10:13 +0100, Mike Galbraith wrote:
> > On Fri, 2016-03-25 at 09:52 +0100, Thomas Gleixner wrote:
> > > On Fri, 25 Mar 2016, Mike Galbraith wrote:
> > > > On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> > > > > On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> > > > > >  
> > > > > > > On the bright side, with the busted migrate enable business 
> > > > > > > reverted,
> > > > > > > plus one dinky change from me [1], master-rt.today has completed 
> > > > > > > 100
> > > > > > > iterations of Steven's hotplug stress script along side endless
> > > > > > > futexstress, and is happily doing another 900 as I write this, so 
> > > > > > > the
> > > > > > > next -rt should finally be hotplug deadlock free.
> > > > > > > 
> > > > > > > Thomas's state machinery seems to work wonders.  'course this 
> > > > > > > being
> > > > > > > hotplug, the other shoe will likely apply itself to my backside 
> > > > > > > soon.
> > > > > > 
> > > > > > That's a given :)
> > > > > 
> > > > > blk-mq applied it shortly after I was satisfied enough to poke xmit.
> > > > 
> > > > The other shoe is that notifiers can depend upon RCU grace periods, so
> > > > when pin_current_cpu() snags rcu_sched, the hotplug game is over.
> > > > 
> > > > blk_mq_queue_reinit_notify:
> > > > /*
> > > >  * We need to freeze and reinit all existing queues.  Freezing
> > > >  * involves synchronous wait for an RCU grace period and doing 
> > > > it
> > > >  * one by one may take a long time.  Start freezing all queues 
> > > > in
> > > >  * one swoop and then wait for the completions so that freezing 
> > > > can
> > > >  * take place in parallel.
> > > >  */
> > > > list_for_each_entry(q, _q_list, all_q_node)
> > > > blk_mq_freeze_queue_start(q);
> > > > list_for_each_entry(q, _q_list, all_q_node) {
> > > > blk_mq_freeze_queue_wait(q);
> > > 
> > > Yeah, I stumbled over that already when analysing all the hotplug notifier
> > > sites. That's definitely a horrible one.
> > >  
> > > > Hohum (sharpens rock), next.
> > > 
> > > /me recommends frozen sharks
> > 
> > With the sharp rock below and the one I'll follow up with, master-rt on
> > my DL980 just passed 3 hours of endless hotplug stress concurrent with
> > endless tbench 8, stockfish and futextest.  It has never survived this
> > long with this load by a long shot.
> 
> I knew it was unlikely to surrender that quickly.  Oh well, on the
> bright side it seems to be running low on deadlocks.

The immunize rcu_sched rock did that btw.  Having accidentally whacked
the dump, I got to reproduce (took 30.03 hours) so I could analyze it.

Hohum, notifier woes definitely require somewhat sharper rocks.

I could make rcu_sched dodge the migration thread, but think I'll apply
frozen shark to blk-mq instead.

-Mike

(a clever person would wait for Sir Thomas, remaining blissfully
ignorant of the gory dragon slaying details, but whatever, premature
testing and rt mole whacking may turn up something interesting, ya
never know)

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

[Mike Galbraith]

On Fri, 2016-03-25 at 17:24 +0100, Mike Galbraith wrote:
> On Fri, 2016-03-25 at 10:13 +0100, Mike Galbraith wrote:
> > On Fri, 2016-03-25 at 09:52 +0100, Thomas Gleixner wrote:
> > > On Fri, 25 Mar 2016, Mike Galbraith wrote:
> > > > On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> > > > > On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> > > > > >  
> > > > > > > On the bright side, with the busted migrate enable business 
> > > > > > > reverted,
> > > > > > > plus one dinky change from me [1], master-rt.today has completed 
> > > > > > > 100
> > > > > > > iterations of Steven's hotplug stress script along side endless
> > > > > > > futexstress, and is happily doing another 900 as I write this, so 
> > > > > > > the
> > > > > > > next -rt should finally be hotplug deadlock free.
> > > > > > > 
> > > > > > > Thomas's state machinery seems to work wonders.  'course this 
> > > > > > > being
> > > > > > > hotplug, the other shoe will likely apply itself to my backside 
> > > > > > > soon.
> > > > > > 
> > > > > > That's a given :)
> > > > > 
> > > > > blk-mq applied it shortly after I was satisfied enough to poke xmit.
> > > > 
> > > > The other shoe is that notifiers can depend upon RCU grace periods, so
> > > > when pin_current_cpu() snags rcu_sched, the hotplug game is over.
> > > > 
> > > > blk_mq_queue_reinit_notify:
> > > > /*
> > > >  * We need to freeze and reinit all existing queues.  Freezing
> > > >  * involves synchronous wait for an RCU grace period and doing 
> > > > it
> > > >  * one by one may take a long time.  Start freezing all queues 
> > > > in
> > > >  * one swoop and then wait for the completions so that freezing 
> > > > can
> > > >  * take place in parallel.
> > > >  */
> > > > list_for_each_entry(q, _q_list, all_q_node)
> > > > blk_mq_freeze_queue_start(q);
> > > > list_for_each_entry(q, _q_list, all_q_node) {
> > > > blk_mq_freeze_queue_wait(q);
> > > 
> > > Yeah, I stumbled over that already when analysing all the hotplug notifier
> > > sites. That's definitely a horrible one.
> > >  
> > > > Hohum (sharpens rock), next.
> > > 
> > > /me recommends frozen sharks
> > 
> > With the sharp rock below and the one I'll follow up with, master-rt on
> > my DL980 just passed 3 hours of endless hotplug stress concurrent with
> > endless tbench 8, stockfish and futextest.  It has never survived this
> > long with this load by a long shot.
> 
> I knew it was unlikely to surrender that quickly.  Oh well, on the
> bright side it seems to be running low on deadlocks.

The immunize rcu_sched rock did that btw.  Having accidentally whacked
the dump, I got to reproduce (took 30.03 hours) so I could analyze it.

Hohum, notifier woes definitely require somewhat sharper rocks.

I could make rcu_sched dodge the migration thread, but think I'll apply
frozen shark to blk-mq instead.

-Mike

(a clever person would wait for Sir Thomas, remaining blissfully
ignorant of the gory dragon slaying details, but whatever, premature
testing and rt mole whacking may turn up something interesting, ya
never know)

Re: [PATCH 2/3] cpufreq: dt: Add generic platform-device creation support

[Krzysztof Kozlowski]

On 24.03.2016 15:40, Viresh Kumar wrote:
> Multiple platforms are using the generic cpufreq-dt driver now, and all
> of them are required to create a platform device with name "cpufreq-dt",
> in order to get the cpufreq-dt probed.
> 
> Many of them do it from platform code, others have special drivers just
> to do that.
> 
> It would be more sensible to do this at a generic place, where all such
> platform can mark their entries.
> 
> This patch adds a separate file to get this device created. Currently
> the compat list of platforms that we support is empty, and will be
> filled in as and when we move platforms to use it.
> 
> It always compiles as part of the kernel and so doesn't need a
> module-exit operation.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/Kconfig  | 11 +
>  drivers/cpufreq/Makefile |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c | 48 
> 
>  3 files changed, 60 insertions(+)
>  create mode 100644 drivers/cpufreq/cpufreq-dt-platdev.c

Reviewed-by: Krzysztof Kozlowski 



Best regards,

Krzysztof

Re: [PATCH 2/3] cpufreq: dt: Add generic platform-device creation support

[Krzysztof Kozlowski]

On 24.03.2016 15:40, Viresh Kumar wrote:
> Multiple platforms are using the generic cpufreq-dt driver now, and all
> of them are required to create a platform device with name "cpufreq-dt",
> in order to get the cpufreq-dt probed.
> 
> Many of them do it from platform code, others have special drivers just
> to do that.
> 
> It would be more sensible to do this at a generic place, where all such
> platform can mark their entries.
> 
> This patch adds a separate file to get this device created. Currently
> the compat list of platforms that we support is empty, and will be
> filled in as and when we move platforms to use it.
> 
> It always compiles as part of the kernel and so doesn't need a
> module-exit operation.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/Kconfig  | 11 +
>  drivers/cpufreq/Makefile |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c | 48 
> 
>  3 files changed, 60 insertions(+)
>  create mode 100644 drivers/cpufreq/cpufreq-dt-platdev.c

Reviewed-by: Krzysztof Kozlowski 



Best regards,

Krzysztof

Re: [RFC PATCH 1/2] mm/hugetlbfs: Attempt PUD_SIZE mapping alignment if PMD sharing enabled

[Hillf Danton]

> 
> When creating a hugetlb mapping, attempt PUD_SIZE alignment if the
> following conditions are met:
> - Address passed to mmap or shmat is NULL
> - The mapping is flaged as shared
> - The mapping is at least PUD_SIZE in length
> If a PUD_SIZE aligned mapping can not be created, then fall back to a
> huge page size mapping.
> 
> Signed-off-by: Mike Kravetz 
> ---
>  fs/hugetlbfs/inode.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 540ddc9..22b2e38 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -175,6 +175,17 @@ hugetlb_get_unmapped_area(struct file *file, unsigned 
> long addr,
>   struct vm_area_struct *vma;
>   struct hstate *h = hstate_file(file);
>   struct vm_unmapped_area_info info;
> + bool pud_size_align = false;
> + unsigned long ret_addr;
> +
> + /*
> +  * If PMD sharing is enabled, align to PUD_SIZE to facilitate
> +  * sharing.  Only attempt alignment if no address was passed in,
> +  * flags indicate sharing and size is big enough.
> +  */
> + if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
> + !addr && flags & MAP_SHARED && len >= PUD_SIZE)
> + pud_size_align = true;
> 
>   if (len & ~huge_page_mask(h))
>   return -EINVAL;
> @@ -199,9 +210,23 @@ hugetlb_get_unmapped_area(struct file *file, unsigned 
> long addr,
>   info.length = len;
>   info.low_limit = TASK_UNMAPPED_BASE;
>   info.high_limit = TASK_SIZE;
> - info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + if (pud_size_align)
> + info.align_mask = PAGE_MASK & (PUD_SIZE - 1);
> + else
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
>   info.align_offset = 0;
> - return vm_unmapped_area();
> + ret_addr = vm_unmapped_area();
> +
> + /*
> +  * If failed with PUD_SIZE alignment, try again with huge page
> +  * size alignment.
> +  */

Can we avoid going another round as long as it is a file with
the PUD page size?

Hillf
> + if ((ret_addr & ~PAGE_MASK) && pud_size_align) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + ret_addr = vm_unmapped_area();
> + }
> +
> + return ret_addr;
>  }
>  #endif
> 
> --
> 2.4.3

Re: [RFC PATCH 1/2] mm/hugetlbfs: Attempt PUD_SIZE mapping alignment if PMD sharing enabled

[Hillf Danton]

> 
> When creating a hugetlb mapping, attempt PUD_SIZE alignment if the
> following conditions are met:
> - Address passed to mmap or shmat is NULL
> - The mapping is flaged as shared
> - The mapping is at least PUD_SIZE in length
> If a PUD_SIZE aligned mapping can not be created, then fall back to a
> huge page size mapping.
> 
> Signed-off-by: Mike Kravetz 
> ---
>  fs/hugetlbfs/inode.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 540ddc9..22b2e38 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -175,6 +175,17 @@ hugetlb_get_unmapped_area(struct file *file, unsigned 
> long addr,
>   struct vm_area_struct *vma;
>   struct hstate *h = hstate_file(file);
>   struct vm_unmapped_area_info info;
> + bool pud_size_align = false;
> + unsigned long ret_addr;
> +
> + /*
> +  * If PMD sharing is enabled, align to PUD_SIZE to facilitate
> +  * sharing.  Only attempt alignment if no address was passed in,
> +  * flags indicate sharing and size is big enough.
> +  */
> + if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
> + !addr && flags & MAP_SHARED && len >= PUD_SIZE)
> + pud_size_align = true;
> 
>   if (len & ~huge_page_mask(h))
>   return -EINVAL;
> @@ -199,9 +210,23 @@ hugetlb_get_unmapped_area(struct file *file, unsigned 
> long addr,
>   info.length = len;
>   info.low_limit = TASK_UNMAPPED_BASE;
>   info.high_limit = TASK_SIZE;
> - info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + if (pud_size_align)
> + info.align_mask = PAGE_MASK & (PUD_SIZE - 1);
> + else
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
>   info.align_offset = 0;
> - return vm_unmapped_area();
> + ret_addr = vm_unmapped_area();
> +
> + /*
> +  * If failed with PUD_SIZE alignment, try again with huge page
> +  * size alignment.
> +  */

Can we avoid going another round as long as it is a file with
the PUD page size?

Hillf
> + if ((ret_addr & ~PAGE_MASK) && pud_size_align) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + ret_addr = vm_unmapped_area();
> + }
> +
> + return ret_addr;
>  }
>  #endif
> 
> --
> 2.4.3

Re: [PATCH 1/4] ARM: dts: qcom: msm8974: Add USB gadget nodes

[kbuild test robot]

Hi Bjorn,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160329]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Bjorn-Andersson/ARM-dts-qcom-msm8974-Add-USB-gadget-nodes/20160329-093758
config: arm-multi_v7_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/qcom-msm8974.dtsi:510.19-20 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 1/4] ARM: dts: qcom: msm8974: Add USB gadget nodes

[kbuild test robot]

Hi Bjorn,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160329]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Bjorn-Andersson/ARM-dts-qcom-msm8974-Add-USB-gadget-nodes/20160329-093758
config: arm-multi_v7_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/qcom-msm8974.dtsi:510.19-20 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2 2/9] remoteproc: core: Make the loaded resource table optional

[Bjorn Andersson]

From: Bjorn Andersson 

Remote processors like the ones found in the Qualcomm SoCs does not have
a resource table passed to them, so make it optional by only populating
it if it does exist.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- None

 drivers/remoteproc/remoteproc_core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 3d7d58a109d8..c04a786dc051 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -856,12 +856,8 @@ static int rproc_fw_boot(struct rproc *rproc, const struct 
firmware *fw)
 * copy this information to device memory.
 */
loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
-   if (!loaded_table) {
-   ret = -EINVAL;
-   goto clean_up;
-   }
-
-   memcpy(loaded_table, rproc->cached_table, tablesz);
+   if (loaded_table)
+   memcpy(loaded_table, rproc->cached_table, tablesz);
 
/* power up the remote processor */
ret = rproc->ops->start(rproc);
-- 
2.5.0

[PATCH v2 2/9] remoteproc: core: Make the loaded resource table optional

[Bjorn Andersson]

From: Bjorn Andersson 

Remote processors like the ones found in the Qualcomm SoCs does not have
a resource table passed to them, so make it optional by only populating
it if it does exist.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- None

 drivers/remoteproc/remoteproc_core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 3d7d58a109d8..c04a786dc051 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -856,12 +856,8 @@ static int rproc_fw_boot(struct rproc *rproc, const struct 
firmware *fw)
 * copy this information to device memory.
 */
loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
-   if (!loaded_table) {
-   ret = -EINVAL;
-   goto clean_up;
-   }
-
-   memcpy(loaded_table, rproc->cached_table, tablesz);
+   if (loaded_table)
+   memcpy(loaded_table, rproc->cached_table, tablesz);
 
/* power up the remote processor */
ret = rproc->ops->start(rproc);
-- 
2.5.0

[PATCH v2 8/9] ARM: dts: qcom: apq8064: Add smd node and all edges

[Bjorn Andersson]

Signed-off-by: Bjorn Andersson 
---

Andy, this is only here for context, please apply separately.

Changes since v1:
- Added dts patches

 arch/arm/boot/dts/qcom-apq8064.dtsi | 40 +
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 5a9d68287840..ad7bc3c2aad1 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -124,6 +124,46 @@
hwlocks = <_mutex 3>;
};
 
+   smd {
+   compatible = "qcom,smd";
+
+   modem@0 {
+   interrupts = <0 37 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 3>;
+   qcom,smd-edge = <0>;
+
+   status = "disabled";
+   };
+
+   q6@1 {
+   interrupts = <0 90 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 15>;
+   qcom,smd-edge = <1>;
+
+   status = "disabled";
+   };
+
+   dsps@3 {
+   interrupts = <0 138 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = <_non_secure 0x4080 0>;
+   qcom,smd-edge = <3>;
+
+   status = "disabled";
+   };
+
+   riva@6 {
+   interrupts = <0 198 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 25>;
+   qcom,smd-edge = <6>;
+
+   status = "disabled";
+   };
+   };
+
smsm {
compatible = "qcom,smsm";
 
-- 
2.5.0

[PATCH v2 3/9] remoteproc: Add additional crash reasons

[Bjorn Andersson]

From: Bjorn Andersson 

The Qualcomm WCNSS can crash by watchdog or a fatal software error. Add
these types to the list of remoteproc crash reasons.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- None

 drivers/remoteproc/remoteproc_core.c | 2 ++
 include/linux/remoteproc.h   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index c04a786dc051..19a906716abd 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -57,6 +57,8 @@ static DEFINE_IDA(rproc_dev_index);
 
 static const char * const rproc_crash_names[] = {
[RPROC_MMUFAULT]= "mmufault",
+   [RPROC_WATCHDOG]= "watchdog",
+   [RPROC_FATAL_ERROR] = "fatal error",
 };
 
 /* translate rproc_crash_type to string */
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9c4e1384f636..1c457a8dd5a6 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -365,6 +365,8 @@ enum rproc_state {
 /**
  * enum rproc_crash_type - remote processor crash types
  * @RPROC_MMUFAULT:iommu fault
+ * @RPROC_WATCHDOG:watchdog bite
+ * @RPROC_FATAL_ERROR  fatal error
  *
  * Each element of the enum is used as an array index. So that, the value of
  * the elements should be always something sane.
@@ -373,6 +375,8 @@ enum rproc_state {
  */
 enum rproc_crash_type {
RPROC_MMUFAULT,
+   RPROC_WATCHDOG,
+   RPROC_FATAL_ERROR,
 };
 
 /**
-- 
2.5.0

[PATCH v2 0/9] Qualcomm WCNSS remoteproc

[Bjorn Andersson]

This series introduces the remoteproc driver for controlling the Qualcomm
Wireless Connectivity Subsystem (WCNSS). The WCNSS is a builtin ARM9 inside the
Qualcomm SoC with an externally connected RF module (iris).

Supports booting and shutting down wcnss on 8064, 8974 and 8016. The driver
will call the crash handler in remoteproc, but further work is needed in the
framework for this not to bring down the kernel.

Changes since v1:
- Split iris definition into separate driver/dt-node
- Move constants from DT to code
- Make stop-state and some of interrupts optional to properly work on 8064
- Cleaned up and made mdt loader support relocation, which is needed on 8016.
- Add dts patches

Bjorn Andersson (9):
  dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding
  remoteproc: core: Make the loaded resource table optional
  remoteproc: Add additional crash reasons
  remoteproc: Introduce Qualcomm WCNSS firmware loader
  ARM: dts: qcom: msm8974: Introduce the wcnss remoteproc node
  ARM: dts: qcom: apq8064: Add syscon for sic-non-secure
  ARM: dts: qcom: apq8064: Add complete smsm node
  ARM: dts: qcom: apq8064: Add smd node and all edges
  ARM: dts: qcom: apq8064: Introduce wcnss remoteproc

 .../bindings/remoteproc/qcom,wcnss-pil.txt | 117 +
 .../arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts |   4 +
 arch/arm/boot/dts/qcom-apq8064.dtsi| 151 ++
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   |  32 ++
 arch/arm/boot/dts/qcom-msm8974.dtsi|  36 +-
 drivers/remoteproc/Kconfig |  12 +
 drivers/remoteproc/Makefile|   2 +
 drivers/remoteproc/qcom_mdt_loader.c   | 172 ++
 drivers/remoteproc/qcom_mdt_loader.h   |   7 +
 drivers/remoteproc/qcom_wcnss.c| 579 +
 drivers/remoteproc/qcom_wcnss.h|  22 +
 drivers/remoteproc/qcom_wcnss_iris.c   | 185 +++
 drivers/remoteproc/remoteproc_core.c   |  10 +-
 include/linux/remoteproc.h |   4 +
 14 files changed, 1326 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.c
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.h
 create mode 100644 drivers/remoteproc/qcom_wcnss.c
 create mode 100644 drivers/remoteproc/qcom_wcnss.h
 create mode 100644 drivers/remoteproc/qcom_wcnss_iris.c

-- 
2.5.0

[PATCH v2 4/9] remoteproc: Introduce Qualcomm WCNSS firmware loader

[Bjorn Andersson]

From: Bjorn Andersson 

This introduces the peripheral image loader, for loading WCNSS firmware
and boot the core on e.g. MSM8974. The firmware is verified and booted
with the help of the Peripheral Authentication System (PAS) in
TrustZone.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Split iris definition into separate driver/dt-node
- Move constants from DT to code
- Make stop-state and some of interrupts optional to properly work on 8064
- Cleaned up and made mdt loader support relocation, which is needed on 8016.

 drivers/remoteproc/Kconfig   |  12 +
 drivers/remoteproc/Makefile  |   2 +
 drivers/remoteproc/qcom_mdt_loader.c | 172 +++
 drivers/remoteproc/qcom_mdt_loader.h |   7 +
 drivers/remoteproc/qcom_wcnss.c  | 579 +++
 drivers/remoteproc/qcom_wcnss.h  |  22 ++
 drivers/remoteproc/qcom_wcnss_iris.c | 185 +++
 7 files changed, 979 insertions(+)
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.c
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.h
 create mode 100644 drivers/remoteproc/qcom_wcnss.c
 create mode 100644 drivers/remoteproc/qcom_wcnss.h
 create mode 100644 drivers/remoteproc/qcom_wcnss_iris.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 72e97d7a5209..7290c46fff9d 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -86,4 +86,16 @@ config ST_REMOTEPROC
  processor framework.
  This can be either built-in or a loadable module.
 
+config QCOM_MDT_LOADER
+   tristate
+
+config QCOM_WCNSS_PIL
+   tristate "Qualcomm WCNSS Peripheral Image Loader"
+   depends on OF && ARCH_QCOM
+   select REMOTEPROC
+   select QCOM_MDT_LOADER
+   select QCOM_SCM
+   help
+ Peripherial Image Loader for the WCNSS block.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 279cb2edc880..97e6ddbe17ea 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -12,3 +12,5 @@ obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
 obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
+obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
+obj-$(CONFIG_QCOM_WCNSS_PIL)   += qcom_wcnss.o qcom_wcnss_iris.o
diff --git a/drivers/remoteproc/qcom_mdt_loader.c 
b/drivers/remoteproc/qcom_mdt_loader.c
new file mode 100644
index ..a8195093d640
--- /dev/null
+++ b/drivers/remoteproc/qcom_mdt_loader.c
@@ -0,0 +1,172 @@
+/*
+ * Qualcomm Peripheral Image Loader
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ * Copyright (C) 2015 Sony Mobile Communications Inc
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define QCOM_MDT_TYPE_MASK (7 << 24)
+#define QCOM_MDT_TYPE_HASH (2 << 24)
+#define QCOM_MDT_RELOCATABLE   BIT(27)
+
+/**
+ * qcom_mdt_find_rsc_table() - provide dummy resource table for remoteproc
+ * @rproc: remoteproc handle
+ * @fw:firmware header
+ * @tablesz:   outgoing size of the table
+ *
+ * Returns a dummy table.
+ */
+struct resource_table *qcom_mdt_find_rsc_table(struct rproc *rproc,
+  const struct firmware *fw,
+  int *tablesz)
+{
+   static struct resource_table table = { .ver = 1, };
+
+   *tablesz = sizeof(table);
+   return 
+}
+EXPORT_SYMBOL_GPL(qcom_mdt_find_rsc_table);
+
+/**
+ * qcom_mdt_load() - load the firmware which header is defined in fw
+ * @rproc: rproc handle
+ * @pas_id:PAS identifier to load this firmware into
+ * @fw:frimware object for the header
+ * @mem_phys:  physical address of reserved memory region for the firmware
+ * @mem_region:pointer to a mapping of the reserved memory region
+ * @mem_size:  size of the reserved memory region
+ *
+ * Returns 0 on success, negative errno otherwise.
+ */
+int qcom_mdt_load(struct rproc *rproc,
+ unsigned int pas_id,
+ const struct firmware *fw,
+ phys_addr_t mem_phys,
+ void *mem_region,
+ size_t mem_size)
+{
+   

[PATCH v2 9/9] ARM: dts: qcom: apq8064: Introduce wcnss remoteproc

[Bjorn Andersson]

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Added dts patches

 .../arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts |  4 ++
 arch/arm/boot/dts/qcom-apq8064.dtsi| 57 ++
 2 files changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts 
b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
index 06b3c76c3e41..276f529383e8 100644
--- a/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
@@ -432,5 +432,9 @@
pinctrl-0 = <_pin_a>, <_cd_pin_a>;
};
};
+
+   wcnss@3204000 {
+   status = "okay";
+   };
};
 };
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index ad7bc3c2aad1..2c213ce80acc 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -20,6 +20,11 @@
reg = <0x8000 0x20>;
no-map;
};
+
+   wcnss_mem: wcnss@8f00 {
+   reg = <0x8f00 0x70>;
+   no-map;
+   };
};
 
cpus {
@@ -231,6 +236,26 @@
 
pinctrl-names = "default";
pinctrl-0 = <_hold>;
+
+   wcnss_pin_a: wcnss-pins-active {
+   fm {
+   pins = "gpio14", "gpio15";
+   function = "riva_fm";
+   };
+
+   bt {
+   pins = "gpio16", "gpio17";
+   function = "riva_bt";
+   };
+
+   wlan {
+   pins = "gpio64", "gpio65", "gpio66", 
"gpio67", "gpio68";
+   function = "riva_wlan";
+
+   drive-strength = <6>;
+   bias-pull-down;
+   };
+   };
};
 
sfpb_wrapper_mutex: syscon@120 {
@@ -916,6 +941,38 @@
reset-names = "axi", "ahb", "por", "pci", "phy";
status = "disabled";
};
+
+   wcnss@3204000 {
+   compatible = "qcom,riva-pil";
+   reg = <0x03204000 0x100>;
+
+   interrupts-extended = < 0 199 
IRQ_TYPE_EDGE_RISING>,
+ <_smsm 6 
IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal";
+
+   memory-region = <_mem>;
+
+   vddcx-supply = <_s3>;
+   vddmx-supply = <_lvs7>;
+   vddpx-supply = <_s4>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>;
+
+   status = "disabled";
+
+   iris {
+   compatible = "qcom,wcn3660";
+
+   clocks = < 2>;
+   clock-names = "xo";
+
+   vddxo-supply = <_l4>;
+   vddrfa-supply = <_s2>;
+   vddpa-supply = <_l10>;
+   vdddig-supply = <_lvs2>;
+   };
+   };
};
 };
 #include "qcom-apq8064-pins.dtsi"
-- 
2.5.0

[PATCH v2 8/9] ARM: dts: qcom: apq8064: Add smd node and all edges

[Bjorn Andersson]

Signed-off-by: Bjorn Andersson 
---

Andy, this is only here for context, please apply separately.

Changes since v1:
- Added dts patches

 arch/arm/boot/dts/qcom-apq8064.dtsi | 40 +
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 5a9d68287840..ad7bc3c2aad1 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -124,6 +124,46 @@
hwlocks = <_mutex 3>;
};
 
+   smd {
+   compatible = "qcom,smd";
+
+   modem@0 {
+   interrupts = <0 37 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 3>;
+   qcom,smd-edge = <0>;
+
+   status = "disabled";
+   };
+
+   q6@1 {
+   interrupts = <0 90 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 15>;
+   qcom,smd-edge = <1>;
+
+   status = "disabled";
+   };
+
+   dsps@3 {
+   interrupts = <0 138 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = <_non_secure 0x4080 0>;
+   qcom,smd-edge = <3>;
+
+   status = "disabled";
+   };
+
+   riva@6 {
+   interrupts = <0 198 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 25>;
+   qcom,smd-edge = <6>;
+
+   status = "disabled";
+   };
+   };
+
smsm {
compatible = "qcom,smsm";
 
-- 
2.5.0

[PATCH v2 3/9] remoteproc: Add additional crash reasons

[Bjorn Andersson]

From: Bjorn Andersson 

The Qualcomm WCNSS can crash by watchdog or a fatal software error. Add
these types to the list of remoteproc crash reasons.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- None

 drivers/remoteproc/remoteproc_core.c | 2 ++
 include/linux/remoteproc.h   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index c04a786dc051..19a906716abd 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -57,6 +57,8 @@ static DEFINE_IDA(rproc_dev_index);
 
 static const char * const rproc_crash_names[] = {
[RPROC_MMUFAULT]= "mmufault",
+   [RPROC_WATCHDOG]= "watchdog",
+   [RPROC_FATAL_ERROR] = "fatal error",
 };
 
 /* translate rproc_crash_type to string */
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9c4e1384f636..1c457a8dd5a6 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -365,6 +365,8 @@ enum rproc_state {
 /**
  * enum rproc_crash_type - remote processor crash types
  * @RPROC_MMUFAULT:iommu fault
+ * @RPROC_WATCHDOG:watchdog bite
+ * @RPROC_FATAL_ERROR  fatal error
  *
  * Each element of the enum is used as an array index. So that, the value of
  * the elements should be always something sane.
@@ -373,6 +375,8 @@ enum rproc_state {
  */
 enum rproc_crash_type {
RPROC_MMUFAULT,
+   RPROC_WATCHDOG,
+   RPROC_FATAL_ERROR,
 };
 
 /**
-- 
2.5.0

[PATCH v2 0/9] Qualcomm WCNSS remoteproc

[Bjorn Andersson]

This series introduces the remoteproc driver for controlling the Qualcomm
Wireless Connectivity Subsystem (WCNSS). The WCNSS is a builtin ARM9 inside the
Qualcomm SoC with an externally connected RF module (iris).

Supports booting and shutting down wcnss on 8064, 8974 and 8016. The driver
will call the crash handler in remoteproc, but further work is needed in the
framework for this not to bring down the kernel.

Changes since v1:
- Split iris definition into separate driver/dt-node
- Move constants from DT to code
- Make stop-state and some of interrupts optional to properly work on 8064
- Cleaned up and made mdt loader support relocation, which is needed on 8016.
- Add dts patches

Bjorn Andersson (9):
  dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding
  remoteproc: core: Make the loaded resource table optional
  remoteproc: Add additional crash reasons
  remoteproc: Introduce Qualcomm WCNSS firmware loader
  ARM: dts: qcom: msm8974: Introduce the wcnss remoteproc node
  ARM: dts: qcom: apq8064: Add syscon for sic-non-secure
  ARM: dts: qcom: apq8064: Add complete smsm node
  ARM: dts: qcom: apq8064: Add smd node and all edges
  ARM: dts: qcom: apq8064: Introduce wcnss remoteproc

 .../bindings/remoteproc/qcom,wcnss-pil.txt | 117 +
 .../arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts |   4 +
 arch/arm/boot/dts/qcom-apq8064.dtsi| 151 ++
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   |  32 ++
 arch/arm/boot/dts/qcom-msm8974.dtsi|  36 +-
 drivers/remoteproc/Kconfig |  12 +
 drivers/remoteproc/Makefile|   2 +
 drivers/remoteproc/qcom_mdt_loader.c   | 172 ++
 drivers/remoteproc/qcom_mdt_loader.h   |   7 +
 drivers/remoteproc/qcom_wcnss.c| 579 +
 drivers/remoteproc/qcom_wcnss.h|  22 +
 drivers/remoteproc/qcom_wcnss_iris.c   | 185 +++
 drivers/remoteproc/remoteproc_core.c   |  10 +-
 include/linux/remoteproc.h |   4 +
 14 files changed, 1326 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.c
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.h
 create mode 100644 drivers/remoteproc/qcom_wcnss.c
 create mode 100644 drivers/remoteproc/qcom_wcnss.h
 create mode 100644 drivers/remoteproc/qcom_wcnss_iris.c

-- 
2.5.0