Re: [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions (aliased with Winbond)

[Brian Norris]

Hi Cyrille,

On Mon, Apr 04, 2016 at 05:33:30PM +0200, Cyrille Pitchen wrote:
> Le 01/04/2016 22:27, Brian Norris a écrit :
> > On Wed, Mar 30, 2016 at 02:47:48PM +0200, Cyrille Pitchen wrote:
> >> Just a general remark: maybe reading the JEDEC ID is not a so reliable 
> >> mean to
> >> discover SPI flash hardware capabilities at runtime.
[...]

> >> Hence the JEDEC ID only provides information about the memory size and all
> >> SPI NOR memories of a given size actually share the same JEDEC ID.
> > 
[...] 
> Then, it seems you're right when you propose to more rely on the DT compatible
> string and add specific entries in the spi_nor_ids[] table with flags to
> declare the supported hardware capabilities.
> 
> I've tried this approach in v5 of my series for support of 4byte address op
> codes.

One note about this: I think this is something that Rafal (and I, to
some extent) was really trying to avoid: having to specify the exact
part number in every board file / DTS file -- as that makes it much more
difficult to support a lot of small variations to the same board. For
example, I believe some production lines like to swap out one or more
flash even on the same product, due to supply or other reasons.

That's not to say we can't do this (it's necessary to do *something*
more than just ID-based detection); but perhaps there's something we can
still do to minimize the damage? I don't have a lot of brilliant ideas
right now...

(Maybe this line of discussion should be carried to your other patch
thread.)

> >> Similar cases can also be found with other manufacturers: Micron, Winbond,
> >> Spansion... 
> >>
> >> Also the Macronix engineers asked us how software applications drive the 
> >> (Q)SPI
> >> memories. I answered them that Linux or u-boot use a static table indexed 
> >> by
> >> the JEDEC ID, which provides the hardware capabilities. I guess they didn't
> >> expect software developers to use the JEDEC ID for this purpose.
> >> Well, it's just a feeling.
> >>
> >> Then the Macronix engineers proposed to use the Serial Flash Discoverable
> >> Parameter (SFDP) tables to make the difference between memories sharing the
> >> same JEDEC ID. This might help us in some cases.
> >> However we should be cautious when using this standard: last year, I've 
> >> tried
> >> to discover hardware parameters through these tables when I was working 
> >> with
> >> Spansion and Micron memories. I found out the Parameter Table Pointers 
> >> inside
> >> the SFDP Header were expressed as byte offset with one memory and as dword
> >> offset with the other.
> > 
> > Yeah, I noticed this. And I think one or more of them noticed their
> > error and fixed it in later revs, so you can't depend on a manufacturer
> > always having the same broken interpretation consistently.
> > 
> 
> Maybe some flags in specific entries to declare some implementation quirks ?

Perhaps, if we can figure out which ones are broken, and we know that
*all* flash with that ID are broken in the same way. (It'd really suck
if the same ID had two different SFDP implementation...)

> >> So I gave up using these tables since some memories diverged from the 
> >> standard,
> >> which was "work in progress" at that time.
> >>
> >> Anyway if we cannot completely rely on the SFDP tables we could still use
> >> DT properties but we should no longer expect to guess all hardware 
> >> parameters
> >> from the JEDEC ID alone.
> > 
> > In your conversations, did the vendors actually suggest a practical
> > method to differentiate flash? Since they've all screwed up SFDP, that's
> > not going to fly, unless we (e.g.) blacklist certain flash. Anyway, I'd
> > love to have some basic support for SFDP, even if we have to be
> > conservative at first. For one, I think it'd be fair to add another
> > compatible property "jedec,sfdp-vXXX", and then we only use that on
> > flash that support the actual spec.
> > 
> 
> Indeed Macronix suggested us to use the SFDP tables. I guess all manufacturers
> tend to implement the latest version of the SFDP standard even if it breaks
> compatibility with implementations of older memories.

Then maybe it's time we finally bite the bullet and try to phase in some
level of SFDP support. We probably don't want to (and can't) rely on it
unconditionally, but maybe we can start flagging off some entries which
should/shouldn't support SFDP (ideally, I'd like to flag those that
*don't* support the standard properly, as we can reasonably expect new
flash to get it correct now).

> To differentiate the MX25L25635E and MX25L25673G, they told us to combine

Why did you want to differentiate these? (I feel like I'm missing an
unstated detail here.)

> info read from both the SFDP tables and the Status Register: on 73G the
> Quad Enable bit is always set and cannot be cleared whereas this bit is 
> cleared
> as a default factory setting.
> However we pointed out that this bit is non-volatile and will be set to 1
> during the very first boot so still 

Re: [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions (aliased with Winbond)

[Brian Norris]

Hi Cyrille,

On Mon, Apr 04, 2016 at 05:33:30PM +0200, Cyrille Pitchen wrote:
> Le 01/04/2016 22:27, Brian Norris a écrit :
> > On Wed, Mar 30, 2016 at 02:47:48PM +0200, Cyrille Pitchen wrote:
> >> Just a general remark: maybe reading the JEDEC ID is not a so reliable 
> >> mean to
> >> discover SPI flash hardware capabilities at runtime.
[...]

> >> Hence the JEDEC ID only provides information about the memory size and all
> >> SPI NOR memories of a given size actually share the same JEDEC ID.
> > 
[...] 
> Then, it seems you're right when you propose to more rely on the DT compatible
> string and add specific entries in the spi_nor_ids[] table with flags to
> declare the supported hardware capabilities.
> 
> I've tried this approach in v5 of my series for support of 4byte address op
> codes.

One note about this: I think this is something that Rafal (and I, to
some extent) was really trying to avoid: having to specify the exact
part number in every board file / DTS file -- as that makes it much more
difficult to support a lot of small variations to the same board. For
example, I believe some production lines like to swap out one or more
flash even on the same product, due to supply or other reasons.

That's not to say we can't do this (it's necessary to do *something*
more than just ID-based detection); but perhaps there's something we can
still do to minimize the damage? I don't have a lot of brilliant ideas
right now...

(Maybe this line of discussion should be carried to your other patch
thread.)

> >> Similar cases can also be found with other manufacturers: Micron, Winbond,
> >> Spansion... 
> >>
> >> Also the Macronix engineers asked us how software applications drive the 
> >> (Q)SPI
> >> memories. I answered them that Linux or u-boot use a static table indexed 
> >> by
> >> the JEDEC ID, which provides the hardware capabilities. I guess they didn't
> >> expect software developers to use the JEDEC ID for this purpose.
> >> Well, it's just a feeling.
> >>
> >> Then the Macronix engineers proposed to use the Serial Flash Discoverable
> >> Parameter (SFDP) tables to make the difference between memories sharing the
> >> same JEDEC ID. This might help us in some cases.
> >> However we should be cautious when using this standard: last year, I've 
> >> tried
> >> to discover hardware parameters through these tables when I was working 
> >> with
> >> Spansion and Micron memories. I found out the Parameter Table Pointers 
> >> inside
> >> the SFDP Header were expressed as byte offset with one memory and as dword
> >> offset with the other.
> > 
> > Yeah, I noticed this. And I think one or more of them noticed their
> > error and fixed it in later revs, so you can't depend on a manufacturer
> > always having the same broken interpretation consistently.
> > 
> 
> Maybe some flags in specific entries to declare some implementation quirks ?

Perhaps, if we can figure out which ones are broken, and we know that
*all* flash with that ID are broken in the same way. (It'd really suck
if the same ID had two different SFDP implementation...)

> >> So I gave up using these tables since some memories diverged from the 
> >> standard,
> >> which was "work in progress" at that time.
> >>
> >> Anyway if we cannot completely rely on the SFDP tables we could still use
> >> DT properties but we should no longer expect to guess all hardware 
> >> parameters
> >> from the JEDEC ID alone.
> > 
> > In your conversations, did the vendors actually suggest a practical
> > method to differentiate flash? Since they've all screwed up SFDP, that's
> > not going to fly, unless we (e.g.) blacklist certain flash. Anyway, I'd
> > love to have some basic support for SFDP, even if we have to be
> > conservative at first. For one, I think it'd be fair to add another
> > compatible property "jedec,sfdp-vXXX", and then we only use that on
> > flash that support the actual spec.
> > 
> 
> Indeed Macronix suggested us to use the SFDP tables. I guess all manufacturers
> tend to implement the latest version of the SFDP standard even if it breaks
> compatibility with implementations of older memories.

Then maybe it's time we finally bite the bullet and try to phase in some
level of SFDP support. We probably don't want to (and can't) rely on it
unconditionally, but maybe we can start flagging off some entries which
should/shouldn't support SFDP (ideally, I'd like to flag those that
*don't* support the standard properly, as we can reasonably expect new
flash to get it correct now).

> To differentiate the MX25L25635E and MX25L25673G, they told us to combine

Why did you want to differentiate these? (I feel like I'm missing an
unstated detail here.)

> info read from both the SFDP tables and the Status Register: on 73G the
> Quad Enable bit is always set and cannot be cleared whereas this bit is 
> cleared
> as a default factory setting.
> However we pointed out that this bit is non-volatile and will be set to 1
> during the very first boot so still 

Re: [PATCH 3/3] mtd: brcmnand: respect ECC algorithm set by NAND subsystem

[Brian Norris]

On Fri, Apr 22, 2016 at 01:23:15PM +0200, Rafał Miłecki wrote:
> It's more reliable than guessing based on ECC strength. It allows using
> NAND on devices with BCH-1 (e.g. D-Link DIR-885L).
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index c3331ff..dcb22dc 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1927,7 +1927,7 @@ static int brcmnand_setup_dev(struct brcmnand_host 
> *host)
>  
>   switch (chip->ecc.size) {
>   case 512:
> - if (chip->ecc.strength == 1) /* Hamming */
> + if (chip->ecc.algo == NAND_ECC_HAMMING)

This doesn't handle most of the problems I noted on the early version of
this series. (But thank you for following through on the algorithm
selection refactoring!)

Particularly, this change will
(a) break any existing DTs which used to have 'nand-ecc-size = <1>', and
would assume this gets Hamming ECC; and
(b) allows DTs to specify Hamming ECC for unsupported modes, like 1024B
sectors, or ecc_level != 1. None of these are supported in HW.

>   cfg->ecc_level = 15;
>   else
>   cfg->ecc_level = chip->ecc.strength;

Something like the following probably works better (not tested):

---8<---

From: Brian Norris 
Date: Mon, 25 Apr 2016 20:48:02 -0700
Subject: [PATCH] mtd: brcmnand: respect ECC algorithm set by the NAND
 subsystem

This is more obvious than guessing based on ECC strength. It allows
using NAND on devices with BCH-1 (e.g. D-Link DIR-885L).

This maintains DT backward compatibility by defaulting to Hamming if a
1-bit ECC algorithm is specified without a corresponding algorithm
selection. i.e., to use BCH-1, you must specify:

  nand-ecc-strength = <1>;
  nand-ecc-step-size = <512>;
  nand-ecc-algo = "bch";

Also adds a check to ensure we haven't allowed someone to get by with SW
ECC. If we want to support SW ECC, we need to refactor some other pieces
of this driver.

Signed-off-by: Brian Norris 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index c3331ffcaffd..b76ad7c0144f 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1925,9 +1925,31 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
cfg->col_adr_bytes = 2;
cfg->blk_adr_bytes = get_blk_adr_bytes(mtd->size, mtd->writesize);
 
+   if (chip->ecc.mode != NAND_ECC_HW) {
+   dev_err(ctrl->dev, "only HW ECC supported; selected: %d\n",
+   chip->ecc.mode);
+   return -EINVAL;
+   }
+
+   if (chip->ecc.algo == NAND_ECC_UNKNOWN) {
+   if (chip->ecc.strength == 1 && chip->ecc.size == 512)
+   /* Default to Hamming for 1-bit ECC, if unspecified */
+   chip->ecc.algo = NAND_ECC_HAMMING;
+   else
+   /* Otherwise, BCH */
+   chip->ecc.algo = NAND_ECC_BCH;
+   }
+
+   if (chip->ecc.algo == NAND_ECC_HAMMING && (chip->ecc.strength != 1 ||
+  chip->ecc.size != 512)) {
+   dev_err(ctrl->dev, "invalid Hamming params: %d bits per %d 
bytes\n",
+   chip->ecc.strength, chip->ecc.size);
+   return -EINVAL;
+   }
+
switch (chip->ecc.size) {
case 512:
-   if (chip->ecc.strength == 1) /* Hamming */
+   if (chip->ecc.algo == NAND_ECC_HAMMING)
cfg->ecc_level = 15;
else
cfg->ecc_level = chip->ecc.strength;
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH 3/3] mtd: brcmnand: respect ECC algorithm set by NAND subsystem

[Brian Norris]

On Fri, Apr 22, 2016 at 01:23:15PM +0200, Rafał Miłecki wrote:
> It's more reliable than guessing based on ECC strength. It allows using
> NAND on devices with BCH-1 (e.g. D-Link DIR-885L).
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index c3331ff..dcb22dc 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1927,7 +1927,7 @@ static int brcmnand_setup_dev(struct brcmnand_host 
> *host)
>  
>   switch (chip->ecc.size) {
>   case 512:
> - if (chip->ecc.strength == 1) /* Hamming */
> + if (chip->ecc.algo == NAND_ECC_HAMMING)

This doesn't handle most of the problems I noted on the early version of
this series. (But thank you for following through on the algorithm
selection refactoring!)

Particularly, this change will
(a) break any existing DTs which used to have 'nand-ecc-size = <1>', and
would assume this gets Hamming ECC; and
(b) allows DTs to specify Hamming ECC for unsupported modes, like 1024B
sectors, or ecc_level != 1. None of these are supported in HW.

>   cfg->ecc_level = 15;
>   else
>   cfg->ecc_level = chip->ecc.strength;

Something like the following probably works better (not tested):

---8<---

From: Brian Norris 
Date: Mon, 25 Apr 2016 20:48:02 -0700
Subject: [PATCH] mtd: brcmnand: respect ECC algorithm set by the NAND
 subsystem

This is more obvious than guessing based on ECC strength. It allows
using NAND on devices with BCH-1 (e.g. D-Link DIR-885L).

This maintains DT backward compatibility by defaulting to Hamming if a
1-bit ECC algorithm is specified without a corresponding algorithm
selection. i.e., to use BCH-1, you must specify:

  nand-ecc-strength = <1>;
  nand-ecc-step-size = <512>;
  nand-ecc-algo = "bch";

Also adds a check to ensure we haven't allowed someone to get by with SW
ECC. If we want to support SW ECC, we need to refactor some other pieces
of this driver.

Signed-off-by: Brian Norris 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index c3331ffcaffd..b76ad7c0144f 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1925,9 +1925,31 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
cfg->col_adr_bytes = 2;
cfg->blk_adr_bytes = get_blk_adr_bytes(mtd->size, mtd->writesize);
 
+   if (chip->ecc.mode != NAND_ECC_HW) {
+   dev_err(ctrl->dev, "only HW ECC supported; selected: %d\n",
+   chip->ecc.mode);
+   return -EINVAL;
+   }
+
+   if (chip->ecc.algo == NAND_ECC_UNKNOWN) {
+   if (chip->ecc.strength == 1 && chip->ecc.size == 512)
+   /* Default to Hamming for 1-bit ECC, if unspecified */
+   chip->ecc.algo = NAND_ECC_HAMMING;
+   else
+   /* Otherwise, BCH */
+   chip->ecc.algo = NAND_ECC_BCH;
+   }
+
+   if (chip->ecc.algo == NAND_ECC_HAMMING && (chip->ecc.strength != 1 ||
+  chip->ecc.size != 512)) {
+   dev_err(ctrl->dev, "invalid Hamming params: %d bits per %d 
bytes\n",
+   chip->ecc.strength, chip->ecc.size);
+   return -EINVAL;
+   }
+
switch (chip->ecc.size) {
case 512:
-   if (chip->ecc.strength == 1) /* Hamming */
+   if (chip->ecc.algo == NAND_ECC_HAMMING)
cfg->ecc_level = 15;
else
cfg->ecc_level = chip->ecc.strength;
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH v7 05/15] i2c: octeon: Enable High-Level Controller

[Jan Glauber]

On Mon, Apr 25, 2016 at 11:44:29PM +0200, Wolfram Sang wrote:
> On Mon, Apr 25, 2016 at 04:33:34PM +0200, Jan Glauber wrote:
> > From: David Daney 
> > 
> > Use High-Level Controller (HLC) when possible. The HLC can read/write
> > up to 8 bytes and is completely optional. The most important difference
> > of the HLC is that it only requires one interrupt for a transfer
> > (up to 8 bytes) where the low-level read/write requires 2 interrupts
> > plus one interrupt per transferred byte. Since the interrupts are costly
> > using the HLC improves the performance. Also, the HLC provides improved
> > error handling.
> > 
> > Signed-off-by: David Daney 
> > Signed-off-by: Jan Glauber 
> 
> Applied to for-next, thanks!
> 
> I can recommend using --strict with checkpatch. It found some issues:

I thought checkpatch is always strict, but seriously, I didn't know that
option. Thanks for fixing that!

Jan

> total: 0 errors, 0 warnings, 18 checks, 427 lines checked
> 
> CHECK: No space is necessary after a cast
> #327: FILE: drivers/i2c/busses/i2c-octeon.c:563:
> + ext |= (u64) msgs[0].buf[0] << SW_TWSI_IA_SHIFT;
> 
> I fixed all 14 of those.
> 
> CHECK: braces {} should be used on all arms of this statement
> #325: FILE: drivers/i2c/busses/i2c-octeon.c:561:
> + if (msgs[0].len == 2) {
> [...]
> + } else
> [...]
> 
> and 2 of those.
> 

Re: [PATCH v7 05/15] i2c: octeon: Enable High-Level Controller

[Jan Glauber]

On Mon, Apr 25, 2016 at 11:44:29PM +0200, Wolfram Sang wrote:
> On Mon, Apr 25, 2016 at 04:33:34PM +0200, Jan Glauber wrote:
> > From: David Daney 
> > 
> > Use High-Level Controller (HLC) when possible. The HLC can read/write
> > up to 8 bytes and is completely optional. The most important difference
> > of the HLC is that it only requires one interrupt for a transfer
> > (up to 8 bytes) where the low-level read/write requires 2 interrupts
> > plus one interrupt per transferred byte. Since the interrupts are costly
> > using the HLC improves the performance. Also, the HLC provides improved
> > error handling.
> > 
> > Signed-off-by: David Daney 
> > Signed-off-by: Jan Glauber 
> 
> Applied to for-next, thanks!
> 
> I can recommend using --strict with checkpatch. It found some issues:

I thought checkpatch is always strict, but seriously, I didn't know that
option. Thanks for fixing that!

Jan

> total: 0 errors, 0 warnings, 18 checks, 427 lines checked
> 
> CHECK: No space is necessary after a cast
> #327: FILE: drivers/i2c/busses/i2c-octeon.c:563:
> + ext |= (u64) msgs[0].buf[0] << SW_TWSI_IA_SHIFT;
> 
> I fixed all 14 of those.
> 
> CHECK: braces {} should be used on all arms of this statement
> #325: FILE: drivers/i2c/busses/i2c-octeon.c:561:
> + if (msgs[0].len == 2) {
> [...]
> + } else
> [...]
> 
> and 2 of those.
> 

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

[Dong Aisheng]

Hi Shawn,

On Tue, Apr 26, 2016 at 9:23 AM, Shawn Guo  wrote:
> On Thu, Apr 21, 2016 at 11:45:20AM +0800, Dong Aisheng wrote:
>> On Fri, Jan 29, 2016 at 02:49:23PM -0800, Stefan Agner wrote:
>> > If a clock gets enabled early during boot time, it can lead to a PLL
>> > startup. The wait_lock function makes sure that the PLL is really
>> > stareted up before it gets used. However, the function sleeps which
>> > leads to scheduling and an error:
>> > bad: scheduling from the idle thread!
>> > ...
>> >
>> > Use udelay in case IRQ's are still disabled.
>> >
>> > Signed-off-by: Stefan Agner 
>> > ---
>> >  drivers/clk/imx/clk-pllv3.c | 5 -
>> >  1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> > index c05c43d..b5ff561 100644
>> > --- a/drivers/clk/imx/clk-pllv3.c
>> > +++ b/drivers/clk/imx/clk-pllv3.c
>> > @@ -63,7 +63,10 @@ static int clk_pllv3_wait_lock(struct clk_pllv3 *pll)
>> > break;
>> > if (time_after(jiffies, timeout))
>> > break;
>> > -   usleep_range(50, 500);
>> > +   if (unlikely(irqs_disabled()))
>>
>> This causes a bit confusion that clk_pllv3_prepare is sleepable.
>> But this line indicates it's possible to be called in irq context.
>> Although it's only happened during kernel boot phase where irq is
>> still not enabled.
>> It seems schedule_debug() somehow did not catch it during early boot
>> phase. Maybe schedule guys can help explain.
>>
>> My question is if it's really worthy to introduce this confusion
>> to fix the issue since the delay is minor?
>
> I do not understand why it's confusing.  The code already obviously
> indicates this is a special handling for cases where irq is still not
> enabled, rather than for irq context.
>

The code itself has nothing telling it's a special handling for the
case where irq is
still not enabled.
Even it tells, it may still cause confusing by adding complexity in
clk_pllv3_prepare()
which actually should be called in non-atomic context as it could sleep.

> The patch is to fix the "bad: scheduling from the idle thread!" warning
> rather than minimize the delay.  Do you have an opinion on how to fix
> the warning?
>

I just wonder maybe we could simply just using udelay(50) instead of
usleep_range(50, 500) to eliminate the confusing since it's minor cast.
What do you think of it?

>> Furthermore, shouldn't it be udelay(500)?
>
> 500 is for the worst case of sleep, and 50 is good enough for delay.
>

Yes, you''re right.
We have a loop, so 50ns one time should be good.

> Shawn

Regards
Dong Aisheng

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

[Dong Aisheng]

Hi Shawn,

On Tue, Apr 26, 2016 at 9:23 AM, Shawn Guo  wrote:
> On Thu, Apr 21, 2016 at 11:45:20AM +0800, Dong Aisheng wrote:
>> On Fri, Jan 29, 2016 at 02:49:23PM -0800, Stefan Agner wrote:
>> > If a clock gets enabled early during boot time, it can lead to a PLL
>> > startup. The wait_lock function makes sure that the PLL is really
>> > stareted up before it gets used. However, the function sleeps which
>> > leads to scheduling and an error:
>> > bad: scheduling from the idle thread!
>> > ...
>> >
>> > Use udelay in case IRQ's are still disabled.
>> >
>> > Signed-off-by: Stefan Agner 
>> > ---
>> >  drivers/clk/imx/clk-pllv3.c | 5 -
>> >  1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> > index c05c43d..b5ff561 100644
>> > --- a/drivers/clk/imx/clk-pllv3.c
>> > +++ b/drivers/clk/imx/clk-pllv3.c
>> > @@ -63,7 +63,10 @@ static int clk_pllv3_wait_lock(struct clk_pllv3 *pll)
>> > break;
>> > if (time_after(jiffies, timeout))
>> > break;
>> > -   usleep_range(50, 500);
>> > +   if (unlikely(irqs_disabled()))
>>
>> This causes a bit confusion that clk_pllv3_prepare is sleepable.
>> But this line indicates it's possible to be called in irq context.
>> Although it's only happened during kernel boot phase where irq is
>> still not enabled.
>> It seems schedule_debug() somehow did not catch it during early boot
>> phase. Maybe schedule guys can help explain.
>>
>> My question is if it's really worthy to introduce this confusion
>> to fix the issue since the delay is minor?
>
> I do not understand why it's confusing.  The code already obviously
> indicates this is a special handling for cases where irq is still not
> enabled, rather than for irq context.
>

The code itself has nothing telling it's a special handling for the
case where irq is
still not enabled.
Even it tells, it may still cause confusing by adding complexity in
clk_pllv3_prepare()
which actually should be called in non-atomic context as it could sleep.

> The patch is to fix the "bad: scheduling from the idle thread!" warning
> rather than minimize the delay.  Do you have an opinion on how to fix
> the warning?
>

I just wonder maybe we could simply just using udelay(50) instead of
usleep_range(50, 500) to eliminate the confusing since it's minor cast.
What do you think of it?

>> Furthermore, shouldn't it be udelay(500)?
>
> 500 is for the worst case of sleep, and 50 is good enough for delay.
>

Yes, you''re right.
We have a loop, so 50ns one time should be good.

> Shawn

Regards
Dong Aisheng

Re: [RESEND PATCH v3 1/2] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

[Krzysztof Kozlowski]

On 04/25/2016 06:51 PM, Javier Martinez Canillas wrote:
> There are a bunch of media platform drivers under drivers/media/platform/
> that are for Samsung SoCs but are not being built with exynos_defconfig.
> 
> This patch enables them as a module to improve build coverage for these
> drivers and also to allow people use them with proper hardware if modules
> are installed. The S5P MFC driver wasn't enabled since it fails to probe.
> 
> Only the boolean Kconfig symbols are enabled as built-in, since drivers
> are not critical and also to keep the kernel binary image size as small
> as possible.
> 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes in v3:
> - Added Krzysztof Kozlowski's reviewed by tag.
> 
> Changes in v2:
> - Remove S5P G2D and GSC symbols since overlaps with Exynos DRM functionality.
>   Suggested by Tobias Jakobi
> 
>  arch/arm/configs/exynos_defconfig | 10 ++
>  1 file changed, 10 insertions(+)

Still nothing... did not reach any of the mailing lists... I think you
need to check your setup or check for any bounces.

Best regards,
Krzysztof

Re: [RESEND PATCH v3 1/2] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

[Krzysztof Kozlowski]

On 04/25/2016 06:51 PM, Javier Martinez Canillas wrote:
> There are a bunch of media platform drivers under drivers/media/platform/
> that are for Samsung SoCs but are not being built with exynos_defconfig.
> 
> This patch enables them as a module to improve build coverage for these
> drivers and also to allow people use them with proper hardware if modules
> are installed. The S5P MFC driver wasn't enabled since it fails to probe.
> 
> Only the boolean Kconfig symbols are enabled as built-in, since drivers
> are not critical and also to keep the kernel binary image size as small
> as possible.
> 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes in v3:
> - Added Krzysztof Kozlowski's reviewed by tag.
> 
> Changes in v2:
> - Remove S5P G2D and GSC symbols since overlaps with Exynos DRM functionality.
>   Suggested by Tobias Jakobi
> 
>  arch/arm/configs/exynos_defconfig | 10 ++
>  1 file changed, 10 insertions(+)

Still nothing... did not reach any of the mailing lists... I think you
need to check your setup or check for any bounces.

Best regards,
Krzysztof

Re: [RFC v6 04/10] PCI: Add support for enforcing all MMIO BARs to be page aligned

[Alexey Kardashevskiy]

On 04/18/2016 08:56 PM, Yongji Xie wrote:

When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.

This is because vfio will not allow to passthrough one BAR's
mmio page which may be shared with other BARs. Otherwise,
there will be a backdoor that guest can use to access BARs
of other guest.

To solve this issue, this patch modifies resource_alignment
to support syntax where multiple devices get the same
alignment. So we can use something like
"pci=resource_alignment=*:*:*.*:noresize" to enforce the
alignment of all MMIO BARs to be at least PAGE_SIZE so that
one BAR's mmio page would not be shared with other BARs.

And we also define a macro PCIBIOS_MIN_ALIGNMENT to enable this
automatically on PPC64 platform which can easily hit this issue
because its PAGE_SIZE is 64KB.

Signed-off-by: Yongji Xie 
---
  Documentation/kernel-parameters.txt |2 ++
  arch/powerpc/include/asm/pci.h  |2 ++
  drivers/pci/pci.c   |   64 +--
  3 files changed, 57 insertions(+), 11 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index d8b29ab..542be4a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2918,6 +2918,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
aligned memory resources.
If  is not specified,
PAGE_SIZE is used as alignment.
+   , ,  and  can be set to
+   "*" which means match all values.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
noresize: Don't change the resources' sizes when
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6f8065a..78f230f 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -30,6 +30,8 @@
  #define PCIBIOS_MIN_IO0x1000
  #define PCIBIOS_MIN_MEM   0x1000

+#define PCIBIOS_MIN_ALIGNMENT  PAGE_SIZE
+
  struct pci_dev;

  /* Values for the `which' argument to sys_pciconfig_iobase syscall.  */
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7564ccc..0381c28 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4605,7 +4605,12 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
char *p;
+   bool invalid = false;

+#ifdef PCIBIOS_MIN_ALIGNMENT
+   align = PCIBIOS_MIN_ALIGNMENT;
+   *resize = false;
+#endif
spin_lock(_alignment_lock);
p = resource_alignment_param;
while (*p) {
@@ -4622,16 +4627,49 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
} else {
align_order = -1;
}
-   if (sscanf(p, "%x:%x:%x.%x%n",
-   , , , , ) != 4) {



I'd replace the above lines with:

char segstr[5] = "*", busstr[3] = "*";
char slotstr[3] = "*", funstr[2] = "*";

if (sscanf(p, "%4[^:]:%2[^:]:%2[^.].%1s%n",
, , , , ) != 4) {


and add some wrapper like:

static bool glob_match_hex(char const *pat, int val)
{
char valstr[5]; /* 5 should be enough for PCI */
snprintf(valstr, sizeof(valstr) - 1, "%4x", val);
return glob_match(pat, valstr);
}

and then use glob_match_hex() (or make a wrapper like above on top of 
fnmatch()), this would enable better mask handling.


If anyone finds this useful (which I am not sure about).





+   if (p[0] == '*' && p[1] == ':') {
+   seg = -1;
+   count = 1;
+   } else if (sscanf(p, "%x%n", , ) != 1 ||
+   p[count] != ':') {
+   invalid = true;
+   break;
+   }
+   p += count + 1;
+   if (*p == '*') {
+   bus = -1;
+   count = 1;
+   } else if (sscanf(p, "%x%n", , ) != 1) {
+   invalid = true;
+   break;
+   }
+   p += count;
+   if (*p == '.') {
+   slot = bus;
+   bus = seg;
seg = 0;
-   if (sscanf(p, "%x:%x.%x%n",
-   , , , ) != 3) {
-   /* Invalid format */
-   printk(KERN_ERR "PCI: Can't parse resource_alignment 
parameter: %s\n",
-   

Re: [RFC v6 04/10] PCI: Add support for enforcing all MMIO BARs to be page aligned

[Alexey Kardashevskiy]

On 04/18/2016 08:56 PM, Yongji Xie wrote:

When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.

This is because vfio will not allow to passthrough one BAR's
mmio page which may be shared with other BARs. Otherwise,
there will be a backdoor that guest can use to access BARs
of other guest.

To solve this issue, this patch modifies resource_alignment
to support syntax where multiple devices get the same
alignment. So we can use something like
"pci=resource_alignment=*:*:*.*:noresize" to enforce the
alignment of all MMIO BARs to be at least PAGE_SIZE so that
one BAR's mmio page would not be shared with other BARs.

And we also define a macro PCIBIOS_MIN_ALIGNMENT to enable this
automatically on PPC64 platform which can easily hit this issue
because its PAGE_SIZE is 64KB.

Signed-off-by: Yongji Xie 
---
  Documentation/kernel-parameters.txt |2 ++
  arch/powerpc/include/asm/pci.h  |2 ++
  drivers/pci/pci.c   |   64 +--
  3 files changed, 57 insertions(+), 11 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index d8b29ab..542be4a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2918,6 +2918,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
aligned memory resources.
If  is not specified,
PAGE_SIZE is used as alignment.
+   , ,  and  can be set to
+   "*" which means match all values.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
noresize: Don't change the resources' sizes when
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6f8065a..78f230f 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -30,6 +30,8 @@
  #define PCIBIOS_MIN_IO0x1000
  #define PCIBIOS_MIN_MEM   0x1000

+#define PCIBIOS_MIN_ALIGNMENT  PAGE_SIZE
+
  struct pci_dev;

  /* Values for the `which' argument to sys_pciconfig_iobase syscall.  */
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7564ccc..0381c28 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4605,7 +4605,12 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
char *p;
+   bool invalid = false;

+#ifdef PCIBIOS_MIN_ALIGNMENT
+   align = PCIBIOS_MIN_ALIGNMENT;
+   *resize = false;
+#endif
spin_lock(_alignment_lock);
p = resource_alignment_param;
while (*p) {
@@ -4622,16 +4627,49 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
} else {
align_order = -1;
}
-   if (sscanf(p, "%x:%x:%x.%x%n",
-   , , , , ) != 4) {



I'd replace the above lines with:

char segstr[5] = "*", busstr[3] = "*";
char slotstr[3] = "*", funstr[2] = "*";

if (sscanf(p, "%4[^:]:%2[^:]:%2[^.].%1s%n",
, , , , ) != 4) {


and add some wrapper like:

static bool glob_match_hex(char const *pat, int val)
{
char valstr[5]; /* 5 should be enough for PCI */
snprintf(valstr, sizeof(valstr) - 1, "%4x", val);
return glob_match(pat, valstr);
}

and then use glob_match_hex() (or make a wrapper like above on top of 
fnmatch()), this would enable better mask handling.


If anyone finds this useful (which I am not sure about).





+   if (p[0] == '*' && p[1] == ':') {
+   seg = -1;
+   count = 1;
+   } else if (sscanf(p, "%x%n", , ) != 1 ||
+   p[count] != ':') {
+   invalid = true;
+   break;
+   }
+   p += count + 1;
+   if (*p == '*') {
+   bus = -1;
+   count = 1;
+   } else if (sscanf(p, "%x%n", , ) != 1) {
+   invalid = true;
+   break;
+   }
+   p += count;
+   if (*p == '.') {
+   slot = bus;
+   bus = seg;
seg = 0;
-   if (sscanf(p, "%x:%x.%x%n",
-   , , , ) != 3) {
-   /* Invalid format */
-   printk(KERN_ERR "PCI: Can't parse resource_alignment 
parameter: %s\n",
-   p);
+   

Re: [PATCH v2] printk: Add kernel parameter to disable writes to /dev/kmsg

[Ingo Molnar]

* Steven Rostedt  wrote:

> On Mon, 25 Apr 2016 12:28:30 -0700
> Linus Torvalds  wrote:
> 
> > On Mon, Apr 25, 2016 at 12:06 PM, Peter Zijlstra  
> > wrote:
> > 
> > I think it should be a tristate with "yes/no/ratelimit", and let's
> > default to ratelimit.
> > 
> 
> Also note that ratelimit wouldn't have solved my issue either. It
> wasn't that systemd was rapidly spewing into the kernel buffers. It was
> doing it gradually, for every connection that I made to the box (lots
> of automated connections were also being logged). I believe something
> happened on Friday but due to all the unnecessary logging over the
> weekend, I lost it.
> 
> To make matters worse, I lost my /var/log/syslog data from then.
> logrotate was a bit more destructive than I expected.

I have similar problems with systemd logging. For test kernels I always use the 
'debug' option on the boot command line:

 BOOT_IMAGE=/boot/bzImage root=/dev/sda2 ro rd.md=0 rd.lvm=0 rd.dm=0 
 earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty 
 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 debug
  ^

... to increase the default loglevel to the max, but in this case systemd 
decides 
that it wants to be very chatty, and note how it even mentions this in the 
comment 
(from the latest systemd source code):

 static int parse_proc_cmdline_item(const char *key, const char *value) {

/*
 * The systemd.log_xyz= settings are parsed by all tools, and
 * so is "debug".
 *
 * However, "quiet" is only parsed by PID 1, and only turns of
 * status output to /dev/console, but does not alter the log
 * level.
 */

if (streq(key, "debug") && !value)
log_set_max_level(LOG_DEBUG);

else if (streq(key, "systemd.log_target") && value) {

Why systemd does this fully knowing that other software (such as the kernel) 
already uses 'debug', while systemd already has the 'system.*' parameter 
namespace 
is left up to the reader...

Thanks,

Ingo

Re: [PATCH v2] printk: Add kernel parameter to disable writes to /dev/kmsg

[Ingo Molnar]

* Steven Rostedt  wrote:

> On Mon, 25 Apr 2016 12:28:30 -0700
> Linus Torvalds  wrote:
> 
> > On Mon, Apr 25, 2016 at 12:06 PM, Peter Zijlstra  
> > wrote:
> > 
> > I think it should be a tristate with "yes/no/ratelimit", and let's
> > default to ratelimit.
> > 
> 
> Also note that ratelimit wouldn't have solved my issue either. It
> wasn't that systemd was rapidly spewing into the kernel buffers. It was
> doing it gradually, for every connection that I made to the box (lots
> of automated connections were also being logged). I believe something
> happened on Friday but due to all the unnecessary logging over the
> weekend, I lost it.
> 
> To make matters worse, I lost my /var/log/syslog data from then.
> logrotate was a bit more destructive than I expected.

I have similar problems with systemd logging. For test kernels I always use the 
'debug' option on the boot command line:

 BOOT_IMAGE=/boot/bzImage root=/dev/sda2 ro rd.md=0 rd.lvm=0 rd.dm=0 
 earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty 
 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 debug
  ^

... to increase the default loglevel to the max, but in this case systemd 
decides 
that it wants to be very chatty, and note how it even mentions this in the 
comment 
(from the latest systemd source code):

 static int parse_proc_cmdline_item(const char *key, const char *value) {

/*
 * The systemd.log_xyz= settings are parsed by all tools, and
 * so is "debug".
 *
 * However, "quiet" is only parsed by PID 1, and only turns of
 * status output to /dev/console, but does not alter the log
 * level.
 */

if (streq(key, "debug") && !value)
log_set_max_level(LOG_DEBUG);

else if (streq(key, "systemd.log_target") && value) {

Why systemd does this fully knowing that other software (such as the kernel) 
already uses 'debug', while systemd already has the 'system.*' parameter 
namespace 
is left up to the reader...

Thanks,

Ingo

Re: [PATCH v5 00/14] ACPI NUMA support for ARM64

[Hanjun Guo]

Hi Will, David,

On 2016/4/26 0:47, David Daney wrote:

On 04/25/2016 04:13 AM, Will Deacon wrote:

Hi David,

On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote:

From: David Daney 

Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
set introduce the ACPI based configuration to provide NUMA
information.

ACPI 5.1 already introduced NUMA support for ARM64, which can get the
NUMA domain information from SRAT and SLIT table, so parse those two
tables to get mappings from cpu/mem to numa node configuration and
system locality.


Whilst I've queued the main NUMA series for arm64, I'd really like to
see more movement on the generic header file cleanups that you posted
separately:

http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.c...@gmail.com



FWIW:  Those patches should still apply.  I am carrying them in my
development trees, and have not changed them in any way.



Given that this ACPI series already requires some significant cross-arch
interaction (which is actually good!), perhaps extending the clean-up
patches to encompass some of the ACPI bits might make sense, and we can
get that queued as a pre-requisite.


The cleanup patches you mention above are really independent of the ACPI
things.  I have applied them both before and after the ACPI patches, and
both seem to work.  With a quick perusal of the ACPI patches nothing
jumps out at me as being a candidate for inclusion in the header file
cleanup series.


I agree. My patch set is ACPI related enablement, cleanups and
consolidations, it would be good to merge as a single patch set
as it's self-contained.

Thanks
Hanjun

Re: [PATCH v5 00/14] ACPI NUMA support for ARM64

[Hanjun Guo]

Hi Will, David,

On 2016/4/26 0:47, David Daney wrote:

On 04/25/2016 04:13 AM, Will Deacon wrote:

Hi David,

On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote:

From: David Daney 

Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
set introduce the ACPI based configuration to provide NUMA
information.

ACPI 5.1 already introduced NUMA support for ARM64, which can get the
NUMA domain information from SRAT and SLIT table, so parse those two
tables to get mappings from cpu/mem to numa node configuration and
system locality.


Whilst I've queued the main NUMA series for arm64, I'd really like to
see more movement on the generic header file cleanups that you posted
separately:

http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.c...@gmail.com



FWIW:  Those patches should still apply.  I am carrying them in my
development trees, and have not changed them in any way.



Given that this ACPI series already requires some significant cross-arch
interaction (which is actually good!), perhaps extending the clean-up
patches to encompass some of the ACPI bits might make sense, and we can
get that queued as a pre-requisite.


The cleanup patches you mention above are really independent of the ACPI
things.  I have applied them both before and after the ACPI patches, and
both seem to work.  With a quick perusal of the ACPI patches nothing
jumps out at me as being a candidate for inclusion in the header file
cleanup series.


I agree. My patch set is ACPI related enablement, cleanups and
consolidations, it would be good to merge as a single patch set
as it's self-contained.

Thanks
Hanjun

Re: [PATCH] watchdog: trivial fix of spelling mistake on "allocate"

[Joe Perches]

On Mon, 2016-04-25 at 20:19 +0100, Colin King wrote:
> fix spelling mistake, alloacate -> allocate
[]
> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
[]
> @@ -161,7 +161,7 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
>   drvdata = devm_kzalloc(>dev, sizeof(struct jz4740_wdt_drvdata),
>      GFP_KERNEL);
>   if (!drvdata) {
> - dev_err(>dev, "Unable to alloacate watchdog device\n");
> + dev_err(>dev, "Unable to allocate watchdog device\n");

Might as well delete this line instead.

Re: [PATCH] watchdog: trivial fix of spelling mistake on "allocate"

[Joe Perches]

On Mon, 2016-04-25 at 20:19 +0100, Colin King wrote:
> fix spelling mistake, alloacate -> allocate
[]
> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
[]
> @@ -161,7 +161,7 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
>   drvdata = devm_kzalloc(>dev, sizeof(struct jz4740_wdt_drvdata),
>      GFP_KERNEL);
>   if (!drvdata) {
> - dev_err(>dev, "Unable to alloacate watchdog device\n");
> + dev_err(>dev, "Unable to allocate watchdog device\n");

Might as well delete this line instead.

Re: [PATCH v5 04/14] acpi, numa: Move acpi_numa_arch_fixup() to ia64 only

[Hanjun Guo]

On 2016/4/20 9:40, David Daney wrote:

From: Robert Richter 

Since acpi_numa_arch_fixup() is only used in arch ia64, move it there
to make a generic interface easier. This avoids empty function stubs
or some complex kconfig options for x86 and arm64.

Signed-off-by: Robert Richter 
Signed-off-by: David Daney 
---
  arch/ia64/include/asm/acpi.h | 3 +++
  arch/ia64/kernel/acpi.c  | 2 +-
  arch/ia64/kernel/setup.c | 1 +
  arch/x86/mm/srat.c   | 2 --
  drivers/acpi/numa.c  | 2 --
  include/linux/acpi.h | 1 -
  6 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index aa0fdf1..a3d0211 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -140,6 +140,9 @@ static inline void per_cpu_scan_finalize(int min_cpus, int 
reserve_cpus)
}
}
  }
+
+extern void acpi_numa_fixup(void);
+
  #endif /* CONFIG_ACPI_NUMA */

  #endif /*__KERNEL__*/
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index b1698bc..92b7bc9 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -524,7 +524,7 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
return 0;
  }

-void __init acpi_numa_arch_fixup(void)
+void __init acpi_numa_fixup(void)
  {
int i, j, node_from, node_to;

diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 2029a38..afddb3e 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -552,6 +552,7 @@ setup_arch (char **cmdline_p)
early_acpi_boot_init();
  # ifdef CONFIG_ACPI_NUMA
acpi_numa_init();
+   acpi_numa_fixup();
  #  ifdef CONFIG_ACPI_HOTPLUG_CPU
prefill_possible_map();
  #  endif
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index b5f8218..90b6ed9 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -212,8 +212,6 @@ out_err:
return -1;
  }

-void __init acpi_numa_arch_fixup(void) {}
-
  int __init x86_acpi_numa_init(void)
  {
int ret;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 2de6068..f41f06b 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -316,8 +316,6 @@ int __init acpi_numa_init(void)
/* SLIT: System Locality Information Table */
acpi_table_parse(ACPI_SIG_SLIT, acpi_parse_slit);

-   acpi_numa_arch_fixup();
-
if (cnt < 0)
return cnt;
else if (!parsed_numa_memblks)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..ab6fd96 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -244,7 +244,6 @@ void acpi_numa_slit_init (struct acpi_table_slit *slit);
  void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
  void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
  int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
-void acpi_numa_arch_fixup(void);

  #ifndef PHYS_CPUID_INVALID
  typedef u32 phys_cpuid_t;


Reviewed-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH v5 04/14] acpi, numa: Move acpi_numa_arch_fixup() to ia64 only

[Hanjun Guo]

On 2016/4/20 9:40, David Daney wrote:

From: Robert Richter 

Since acpi_numa_arch_fixup() is only used in arch ia64, move it there
to make a generic interface easier. This avoids empty function stubs
or some complex kconfig options for x86 and arm64.

Signed-off-by: Robert Richter 
Signed-off-by: David Daney 
---
  arch/ia64/include/asm/acpi.h | 3 +++
  arch/ia64/kernel/acpi.c  | 2 +-
  arch/ia64/kernel/setup.c | 1 +
  arch/x86/mm/srat.c   | 2 --
  drivers/acpi/numa.c  | 2 --
  include/linux/acpi.h | 1 -
  6 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index aa0fdf1..a3d0211 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -140,6 +140,9 @@ static inline void per_cpu_scan_finalize(int min_cpus, int 
reserve_cpus)
}
}
  }
+
+extern void acpi_numa_fixup(void);
+
  #endif /* CONFIG_ACPI_NUMA */

  #endif /*__KERNEL__*/
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index b1698bc..92b7bc9 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -524,7 +524,7 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
return 0;
  }

-void __init acpi_numa_arch_fixup(void)
+void __init acpi_numa_fixup(void)
  {
int i, j, node_from, node_to;

diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 2029a38..afddb3e 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -552,6 +552,7 @@ setup_arch (char **cmdline_p)
early_acpi_boot_init();
  # ifdef CONFIG_ACPI_NUMA
acpi_numa_init();
+   acpi_numa_fixup();
  #  ifdef CONFIG_ACPI_HOTPLUG_CPU
prefill_possible_map();
  #  endif
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index b5f8218..90b6ed9 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -212,8 +212,6 @@ out_err:
return -1;
  }

-void __init acpi_numa_arch_fixup(void) {}
-
  int __init x86_acpi_numa_init(void)
  {
int ret;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 2de6068..f41f06b 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -316,8 +316,6 @@ int __init acpi_numa_init(void)
/* SLIT: System Locality Information Table */
acpi_table_parse(ACPI_SIG_SLIT, acpi_parse_slit);

-   acpi_numa_arch_fixup();
-
if (cnt < 0)
return cnt;
else if (!parsed_numa_memblks)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..ab6fd96 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -244,7 +244,6 @@ void acpi_numa_slit_init (struct acpi_table_slit *slit);
  void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
  void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
  int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
-void acpi_numa_arch_fixup(void);

  #ifndef PHYS_CPUID_INVALID
  typedef u32 phys_cpuid_t;


Reviewed-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH] net: tsi108: use NULL for pointer-typed argument

[David Miller]

From: Julia Lawall 
Date: Sat, 23 Apr 2016 11:07:02 +0200

> The first argument of pci_free_consistent has type struct pci_dev *, so use
> NULL instead of 0.
> 
> The semantic patch that performs this transformation is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> @@
> pci_free_consistent(
> - 0
> + NULL
>   , ...)
> // 
> 
> Signed-off-by: Julia Lawall 

Applied.

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Tuesday, April 26, 2016 11:47 AM
> To: Jun Li 
> Cc: Roger Quadros ; st...@rowland.harvard.edu;
> ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com;
> dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> 
> On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > > +struct usb_otg *usb_otg_register(struct device *dev,
> > > +  struct usb_otg_config *config) {
> > > + struct usb_otg *otg;
> > > + struct otg_wait_data *wait;
> > > + int ret = 0;
> > > +
> > > + if (!dev || !config || !config->fsm_ops)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + /* already in list? */
> > > + mutex_lock(_list_mutex);
> > > + if (usb_otg_get_data(dev)) {
> > > + dev_err(dev, "otg: %s: device already in otg list\n",
> > > + __func__);
> > > + ret = -EINVAL;
> > > + goto unlock;
> > > + }
> > > +
> > > + /* allocate and add to list */
> > > + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > > + if (!otg) {
> > > + ret = -ENOMEM;
> > > + goto unlock;
> > > + }
> > > +
> > > + otg->dev = dev;
> > > + otg->caps = config->otg_caps;
> > > +
> > > + if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > > +  otg->caps->adp_support) && !config->otg_work)
> > > + dev_info(dev, "otg: limiting to dual-role\n");
> >
> > dev_err, this should be an error.
> 
> The condition may be wrong, but it is an information to show that current
> OTG is dual-role.

This should not happen in any correct design, I even doubt if we
should try to continue by "downgrade" it to be duel role, currently
the only example user is dual role, so doing like this can't be
tested by real case, this downgrade is not so easy like we image,
at least for chipidea otg driver, simply replace a queue worker may
not work, as we have much more difference between the 2 configs.

Li Jun
 
> 
> Peter
> >
> > > +
> > > + if (config->otg_work)   /* custom otg_work ? */
> > > + INIT_WORK(>work, config->otg_work);
> > > + else
> > > + INIT_WORK(>work, usb_otg_work);
> > > +
> > > + otg->wq = create_singlethread_workqueue("usb_otg");
> > > + if (!otg->wq) {
> > > + dev_err(dev, "otg: %s: can't create workqueue\n",
> > > + __func__);
> > > + ret = -ENOMEM;
> > > + goto err_wq;
> > > + }
> > > +
> > > + /* set otg ops */
> > > + otg->fsm.ops = config->fsm_ops;
> > > +
> > > + mutex_init(>fsm.lock);
> > > +
> > > + list_add_tail(>list, _list);
> > > + mutex_unlock(_list_mutex);
> > > +
> > > + /* were we in wait list? */
> > > + mutex_lock(_list_mutex);
> > > + wait = usb_otg_get_wait(dev);
> > > + mutex_unlock(_list_mutex);
> > > + if (wait) {
> > > + /* register pending host/gadget and flush from list */
> > > + usb_otg_flush_wait(dev);
> > > + }
> > > +
> > > + return otg;
> > > +
> > > +err_wq:
> > > + kfree(otg);
> > > +unlock:
> > > + mutex_unlock(_list_mutex);
> > > + return ERR_PTR(ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(usb_otg_register);
> > > +
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> Best Regards,
> Peter Chen

Re: [PATCH] net: tsi108: use NULL for pointer-typed argument

[David Miller]

From: Julia Lawall 
Date: Sat, 23 Apr 2016 11:07:02 +0200

> The first argument of pci_free_consistent has type struct pci_dev *, so use
> NULL instead of 0.
> 
> The semantic patch that performs this transformation is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> @@
> pci_free_consistent(
> - 0
> + NULL
>   , ...)
> // 
> 
> Signed-off-by: Julia Lawall 

Applied.

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Tuesday, April 26, 2016 11:47 AM
> To: Jun Li 
> Cc: Roger Quadros ; st...@rowland.harvard.edu;
> ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com;
> dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> 
> On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > > +struct usb_otg *usb_otg_register(struct device *dev,
> > > +  struct usb_otg_config *config) {
> > > + struct usb_otg *otg;
> > > + struct otg_wait_data *wait;
> > > + int ret = 0;
> > > +
> > > + if (!dev || !config || !config->fsm_ops)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + /* already in list? */
> > > + mutex_lock(_list_mutex);
> > > + if (usb_otg_get_data(dev)) {
> > > + dev_err(dev, "otg: %s: device already in otg list\n",
> > > + __func__);
> > > + ret = -EINVAL;
> > > + goto unlock;
> > > + }
> > > +
> > > + /* allocate and add to list */
> > > + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > > + if (!otg) {
> > > + ret = -ENOMEM;
> > > + goto unlock;
> > > + }
> > > +
> > > + otg->dev = dev;
> > > + otg->caps = config->otg_caps;
> > > +
> > > + if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > > +  otg->caps->adp_support) && !config->otg_work)
> > > + dev_info(dev, "otg: limiting to dual-role\n");
> >
> > dev_err, this should be an error.
> 
> The condition may be wrong, but it is an information to show that current
> OTG is dual-role.

This should not happen in any correct design, I even doubt if we
should try to continue by "downgrade" it to be duel role, currently
the only example user is dual role, so doing like this can't be
tested by real case, this downgrade is not so easy like we image,
at least for chipidea otg driver, simply replace a queue worker may
not work, as we have much more difference between the 2 configs.

Li Jun
 
> 
> Peter
> >
> > > +
> > > + if (config->otg_work)   /* custom otg_work ? */
> > > + INIT_WORK(>work, config->otg_work);
> > > + else
> > > + INIT_WORK(>work, usb_otg_work);
> > > +
> > > + otg->wq = create_singlethread_workqueue("usb_otg");
> > > + if (!otg->wq) {
> > > + dev_err(dev, "otg: %s: can't create workqueue\n",
> > > + __func__);
> > > + ret = -ENOMEM;
> > > + goto err_wq;
> > > + }
> > > +
> > > + /* set otg ops */
> > > + otg->fsm.ops = config->fsm_ops;
> > > +
> > > + mutex_init(>fsm.lock);
> > > +
> > > + list_add_tail(>list, _list);
> > > + mutex_unlock(_list_mutex);
> > > +
> > > + /* were we in wait list? */
> > > + mutex_lock(_list_mutex);
> > > + wait = usb_otg_get_wait(dev);
> > > + mutex_unlock(_list_mutex);
> > > + if (wait) {
> > > + /* register pending host/gadget and flush from list */
> > > + usb_otg_flush_wait(dev);
> > > + }
> > > +
> > > + return otg;
> > > +
> > > +err_wq:
> > > + kfree(otg);
> > > +unlock:
> > > + mutex_unlock(_list_mutex);
> > > + return ERR_PTR(ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(usb_otg_register);
> > > +
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> Best Regards,
> Peter Chen

[PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return

[Mario Limonciello]

Before this commit both code paths (hotplug and not-hotplug as determined
by FW_OPT_UEVENT)  would block on an interruptible completion, but the
hotplugscenario also would wait until timeout and then abort.  The non
hotplugscenario (which dell-rbu followed) would block indefinitely until
interrupted.

After this commit both scenarios block on an interruptible condition but
the hotplug scenario follows the value of firmware_loading_timeout to end.
This changed the situation for the non hotplug scenario to instead wait
for MAX_JIFFY_OFFSET.  This should have the same result, but dell-rbu was
failing with negative values returned from
wait_for_completion_interruptible_timeout after completion occurred.

This shouldn't be possible, but it was happening because the return is a
long but the value it was being saved to was an int.  When completion
occurs quickly wait_for_completion_interruptible_timeout returns how much
time was left (which happens to be a very big number since the timeout was
MAX_JIFFY_OFFSET) One test run of mine returned 4611686018427368747.

Other parts of the kernel with this type of return don't have problems
because they use smaller timeouts.

So to fix this: change the test to not store the value to an int, but
rather directly compare against what
wait_for_completion_interruptible_timeout can return.

Fixes: 68ff2a00dbf59 (firmware_loader: handle timeout via 
wait_for_completion_interruptible_timeout())
CC: sta...@vger.kernel.org
CC: stuart_ha...@dell.com
Signed-off-by: Mario Limonciello 
---
 drivers/base/firmware_class.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 773fc30..223af70 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -917,14 +917,11 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv,
timeout = MAX_JIFFY_OFFSET;
}
 
-   retval = wait_for_completion_interruptible_timeout(>completion,
-   timeout);
-   if (retval == -ERESTARTSYS || !retval) {
+   if (wait_for_completion_interruptible_timeout(>completion,
+   timeout) <= 0) {
mutex_lock(_lock);
fw_load_abort(fw_priv);
mutex_unlock(_lock);
-   } else if (retval > 0) {
-   retval = 0;
}
 
if (is_fw_load_aborted(buf))
-- 
2.7.4

[PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return

[Mario Limonciello]

Before this commit both code paths (hotplug and not-hotplug as determined
by FW_OPT_UEVENT)  would block on an interruptible completion, but the
hotplugscenario also would wait until timeout and then abort.  The non
hotplugscenario (which dell-rbu followed) would block indefinitely until
interrupted.

After this commit both scenarios block on an interruptible condition but
the hotplug scenario follows the value of firmware_loading_timeout to end.
This changed the situation for the non hotplug scenario to instead wait
for MAX_JIFFY_OFFSET.  This should have the same result, but dell-rbu was
failing with negative values returned from
wait_for_completion_interruptible_timeout after completion occurred.

This shouldn't be possible, but it was happening because the return is a
long but the value it was being saved to was an int.  When completion
occurs quickly wait_for_completion_interruptible_timeout returns how much
time was left (which happens to be a very big number since the timeout was
MAX_JIFFY_OFFSET) One test run of mine returned 4611686018427368747.

Other parts of the kernel with this type of return don't have problems
because they use smaller timeouts.

So to fix this: change the test to not store the value to an int, but
rather directly compare against what
wait_for_completion_interruptible_timeout can return.

Fixes: 68ff2a00dbf59 (firmware_loader: handle timeout via 
wait_for_completion_interruptible_timeout())
CC: sta...@vger.kernel.org
CC: stuart_ha...@dell.com
Signed-off-by: Mario Limonciello 
---
 drivers/base/firmware_class.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 773fc30..223af70 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -917,14 +917,11 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv,
timeout = MAX_JIFFY_OFFSET;
}
 
-   retval = wait_for_completion_interruptible_timeout(>completion,
-   timeout);
-   if (retval == -ERESTARTSYS || !retval) {
+   if (wait_for_completion_interruptible_timeout(>completion,
+   timeout) <= 0) {
mutex_lock(_lock);
fw_load_abort(fw_priv);
mutex_unlock(_lock);
-   } else if (retval > 0) {
-   retval = 0;
}
 
if (is_fw_load_aborted(buf))
-- 
2.7.4

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/arm64/kernel/setup.c

between commit:

  3194ac6e66cc ("arm64: Move unflatten_device_tree() call earlier.")

from the arm64 tree and commit:

  3915fea959b6 ("ARM: XEN: Move xen_early_init() before efi_init()")

from the xen-tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/kernel/setup.c
index 65f515949baa,7cf992fe6684..
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@@ -277,13 -336,13 +278,11 @@@ void __init setup_arch(char **cmdline_p
  
early_ioremap_reset();
  
 -  if (acpi_disabled) {
 -  unflatten_device_tree();
 +  if (acpi_disabled)
psci_dt_init();
 -  } else {
 +  else
psci_acpi_init();
 -  }
  
-   xen_early_init();
- 
cpu_read_bootcpu_ops();
smp_init_cpus();
smp_build_mpidr_hash();

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/arm64/kernel/setup.c

between commit:

  3194ac6e66cc ("arm64: Move unflatten_device_tree() call earlier.")

from the arm64 tree and commit:

  3915fea959b6 ("ARM: XEN: Move xen_early_init() before efi_init()")

from the xen-tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/kernel/setup.c
index 65f515949baa,7cf992fe6684..
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@@ -277,13 -336,13 +278,11 @@@ void __init setup_arch(char **cmdline_p
  
early_ioremap_reset();
  
 -  if (acpi_disabled) {
 -  unflatten_device_tree();
 +  if (acpi_disabled)
psci_dt_init();
 -  } else {
 +  else
psci_acpi_init();
 -  }
  
-   xen_early_init();
- 
cpu_read_bootcpu_ops();
smp_init_cpus();
smp_build_mpidr_hash();

Re: [PATCH 0/4] OMAP Mailbox legacy platform device support removal

[Jassi Brar]

On Wed, Apr 6, 2016 at 6:37 PM, Suman Anna  wrote:
> Hi Jassi,
>
> This series cleans up the OMAP Mailbox driver dropping the
> support for legacy non-DT platform devices. The infrastructure
> for creating any such devices has all been cleaned up from the
> mach-omap2 layers.
>
> The removal from the driver is accomplished in patch 1, while the
> remaining patches do some minor checkpatch fixes.
>
> Patches baselined on 4.6-rc2.
>
Applied this and the next patchset, with a trivial cleanup

- #define MBOX_INTR_CFG_TYPE1(0)
- #define MBOX_INTR_CFG_TYPE2(1)
+ #define MBOX_INTR_CFG_TYPE10
+ #define MBOX_INTR_CFG_TYPE21

Thanks.

Re: [PATCH 0/4] OMAP Mailbox legacy platform device support removal

[Jassi Brar]

On Wed, Apr 6, 2016 at 6:37 PM, Suman Anna  wrote:
> Hi Jassi,
>
> This series cleans up the OMAP Mailbox driver dropping the
> support for legacy non-DT platform devices. The infrastructure
> for creating any such devices has all been cleaned up from the
> mach-omap2 layers.
>
> The removal from the driver is accomplished in patch 1, while the
> remaining patches do some minor checkpatch fixes.
>
> Patches baselined on 4.6-rc2.
>
Applied this and the next patchset, with a trivial cleanup

- #define MBOX_INTR_CFG_TYPE1(0)
- #define MBOX_INTR_CFG_TYPE2(1)
+ #define MBOX_INTR_CFG_TYPE10
+ #define MBOX_INTR_CFG_TYPE21

Thanks.

Re: stable-security kernel updates

[Willy Tarreau]

On Tue, Apr 26, 2016 at 01:14:13AM +0200, Ben Hutchings wrote:
> On Thu, 2016-04-21 at 16:33 +0200, Willy Tarreau wrote:
> > On Thu, Apr 21, 2016 at 10:27:46AM -0400, Sasha Levin wrote:
> > > 
> > > This means that missing CVE fixes are quite common with stable
> > > trees?
> > Until someone reports they are missing :-)
> 
> Or they are unfixed upstream (there are a good few of those).
> 
> Debian has a public list of all unembargoed kernel security issues that
> have CVEs (and a few that don't), with references to any upstream
> commits and fixed stable versions - but only for the stable branches
> that our stable releases follow.
> 
> The mapping of CVE IDs to commits may be useful to other stable
> maintainers, even if the rest isn't.
> 
> svn co svn://scm.alioth.debian.org/svn/kernel-sec/

Thanks for sharing this Ben, it can indeed be helpful sometimes and it's
well organized!

Willy

Re: stable-security kernel updates

[Willy Tarreau]

On Tue, Apr 26, 2016 at 01:14:13AM +0200, Ben Hutchings wrote:
> On Thu, 2016-04-21 at 16:33 +0200, Willy Tarreau wrote:
> > On Thu, Apr 21, 2016 at 10:27:46AM -0400, Sasha Levin wrote:
> > > 
> > > This means that missing CVE fixes are quite common with stable
> > > trees?
> > Until someone reports they are missing :-)
> 
> Or they are unfixed upstream (there are a good few of those).
> 
> Debian has a public list of all unembargoed kernel security issues that
> have CVEs (and a few that don't), with references to any upstream
> commits and fixed stable versions - but only for the stable branches
> that our stable releases follow.
> 
> The mapping of CVE IDs to commits may be useful to other stable
> maintainers, even if the rest isn't.
> 
> svn co svn://scm.alioth.debian.org/svn/kernel-sec/

Thanks for sharing this Ben, it can indeed be helpful sometimes and it's
well organized!

Willy

Re: [PATCH 1/2] drm/dsi: Implement DCS get display mode

[Vinay Simha]

HI,

I have not got response from maintainers. Did i miss anything?

On Mon, Apr 18, 2016 at 2:52 PM, Vinay Simha BN  wrote:
> Provide a small convenience wrapper that transmits
> a DCS get_display_mode command.
>
> Signed-off-by: Vinay Simha BN 
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 24 
>  include/drm/drm_mipi_dsi.h |  1 +
>  2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index f5d8083..2e032ea 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -792,6 +792,30 @@ int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device 
> *dsi, u8 *mode)
>  EXPORT_SYMBOL(mipi_dsi_dcs_get_power_mode);
>
>  /**
> + * mipi_dsi_dcs_get_display_mode() - query the display module's image mode
> + * @dsi: DSI peripheral device
> + * @mode: return location for the display image mode
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode)
> +{
> +   ssize_t err;
> +
> +   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_MODE, mode,
> +   sizeof(*mode));
> +   if (err <= 0) {
> +   if (err == 0)
> +   err = -ENODATA;
> +
> +   return err;
> +   }
> +
> +   return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_get_display_mode);
> +
> +/**
>   * mipi_dsi_dcs_get_pixel_format() - gets the pixel format for the RGB image
>   *data used by the interface
>   * @dsi: DSI peripheral device
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 7a9840f..48fcd65 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -254,6 +254,7 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 
> cmd, void *data,
>  int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
> +int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode);
>  int mipi_dsi_dcs_get_pixel_format(struct mipi_dsi_device *dsi, u8 *format);
>  int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
> --
> 2.1.2
>



-- 
Regards,

Vinay Simha.B.N.

Re: [PATCH 1/2] drm/dsi: Implement DCS get display mode

[Vinay Simha]

HI,

I have not got response from maintainers. Did i miss anything?

On Mon, Apr 18, 2016 at 2:52 PM, Vinay Simha BN  wrote:
> Provide a small convenience wrapper that transmits
> a DCS get_display_mode command.
>
> Signed-off-by: Vinay Simha BN 
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 24 
>  include/drm/drm_mipi_dsi.h |  1 +
>  2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index f5d8083..2e032ea 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -792,6 +792,30 @@ int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device 
> *dsi, u8 *mode)
>  EXPORT_SYMBOL(mipi_dsi_dcs_get_power_mode);
>
>  /**
> + * mipi_dsi_dcs_get_display_mode() - query the display module's image mode
> + * @dsi: DSI peripheral device
> + * @mode: return location for the display image mode
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode)
> +{
> +   ssize_t err;
> +
> +   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_MODE, mode,
> +   sizeof(*mode));
> +   if (err <= 0) {
> +   if (err == 0)
> +   err = -ENODATA;
> +
> +   return err;
> +   }
> +
> +   return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_get_display_mode);
> +
> +/**
>   * mipi_dsi_dcs_get_pixel_format() - gets the pixel format for the RGB image
>   *data used by the interface
>   * @dsi: DSI peripheral device
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 7a9840f..48fcd65 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -254,6 +254,7 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 
> cmd, void *data,
>  int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
> +int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode);
>  int mipi_dsi_dcs_get_pixel_format(struct mipi_dsi_device *dsi, u8 *format);
>  int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
> --
> 2.1.2
>



-- 
Regards,

Vinay Simha.B.N.

Re: [PATCH 2/2] drm/dsi: Implement DCS get display self diagnostic

[Vinay Simha]

HI,

I have not got response from maintainers. Did i miss anything?

On Mon, Apr 18, 2016 at 2:52 PM, Vinay Simha BN  wrote:
> Provide a small convenience wrapper that transmits
> a DCS get_diagnostic_result command.
>
> Signed-off-by: Vinay Simha BN 
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 25 +
>  include/drm/drm_mipi_dsi.h |  1 +
>  2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 2e032ea..e49b346 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -816,6 +816,31 @@ int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device 
> *dsi, u8 *mode)
>  EXPORT_SYMBOL(mipi_dsi_dcs_get_display_mode);
>
>  /**
> + * mipi_dsi_dcs_get_diagnostic_result() - query the display module's 
> diagnostic
> + *result
> + * @dsi: DSI peripheral device
> + * @mode: return location for the display self diagnostic result
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_get_diagnostic_result(struct mipi_dsi_device *dsi, u8 *mode)
> +{
> +   ssize_t err;
> +
> +   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DIAGNOSTIC_RESULT, mode,
> +   sizeof(*mode));
> +   if (err <= 0) {
> +   if (err == 0)
> +   err = -ENODATA;
> +
> +   return err;
> +   }
> +
> +   return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_get_diagnostic_result);
> +
> +/**
>   * mipi_dsi_dcs_get_pixel_format() - gets the pixel format for the RGB image
>   *data used by the interface
>   * @dsi: DSI peripheral device
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 48fcd65..61c375b 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -255,6 +255,7 @@ int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
>  int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode);
> +int mipi_dsi_dcs_get_diagnostic_result(struct mipi_dsi_device *dsi, u8 
> *mode);
>  int mipi_dsi_dcs_get_pixel_format(struct mipi_dsi_device *dsi, u8 *format);
>  int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
> --
> 2.1.2
>



-- 
Regards,

Vinay Simha.B.N.

Re: [PATCH 2/2] drm/dsi: Implement DCS get display self diagnostic

[Vinay Simha]

HI,

I have not got response from maintainers. Did i miss anything?

On Mon, Apr 18, 2016 at 2:52 PM, Vinay Simha BN  wrote:
> Provide a small convenience wrapper that transmits
> a DCS get_diagnostic_result command.
>
> Signed-off-by: Vinay Simha BN 
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 25 +
>  include/drm/drm_mipi_dsi.h |  1 +
>  2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 2e032ea..e49b346 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -816,6 +816,31 @@ int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device 
> *dsi, u8 *mode)
>  EXPORT_SYMBOL(mipi_dsi_dcs_get_display_mode);
>
>  /**
> + * mipi_dsi_dcs_get_diagnostic_result() - query the display module's 
> diagnostic
> + *result
> + * @dsi: DSI peripheral device
> + * @mode: return location for the display self diagnostic result
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_get_diagnostic_result(struct mipi_dsi_device *dsi, u8 *mode)
> +{
> +   ssize_t err;
> +
> +   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DIAGNOSTIC_RESULT, mode,
> +   sizeof(*mode));
> +   if (err <= 0) {
> +   if (err == 0)
> +   err = -ENODATA;
> +
> +   return err;
> +   }
> +
> +   return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_get_diagnostic_result);
> +
> +/**
>   * mipi_dsi_dcs_get_pixel_format() - gets the pixel format for the RGB image
>   *data used by the interface
>   * @dsi: DSI peripheral device
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 48fcd65..61c375b 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -255,6 +255,7 @@ int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
>  int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode);
> +int mipi_dsi_dcs_get_diagnostic_result(struct mipi_dsi_device *dsi, u8 
> *mode);
>  int mipi_dsi_dcs_get_pixel_format(struct mipi_dsi_device *dsi, u8 *format);
>  int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
> --
> 2.1.2
>



-- 
Regards,

Vinay Simha.B.N.

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[Dan Williams]

On Mon, Apr 25, 2016 at 7:56 PM, Dave Chinner  wrote:
> On Mon, Apr 25, 2016 at 06:45:08PM -0700, Dan Williams wrote:
[..]
>> Otherwise, if an application wants to use DAX then it might
>> need to be prepared to handle media errors itself same as the
>> un-RAIDed disk case.  Yes, at an administrative level without
>> reverse-mapping support from a filesystem there's presently no way to
>> ask "which files on this fs are impacted by media errors", and we're
>> aware that reverse-mapping capabilities are nascent for current
>> DAX-aware filesystems.
>
> Precisely my point - suggestions are being proposed which assume
> use of infrastructure that *does not exist yet* and has not been
> discussed or documented. If we're expecting such infrastructure to
> be implemented in the filesystems and block device drivers, then we
> need to determine that the error model actually works first...

These patches only assume the clear-error-on write-model, and that
*maybe* the sysfs bad blocks list is useful if the filesystem has a
reverse-map, or if the application can compare the list against the
results of fiemap().  Beyond that, this is the same perennial "we
should really have better error coordination between block device and
filesystems" discussions that we have at LSF.

>
>> The forward lookup path, as impractical as it
>> is for large numbers of files, is available if an application wanted
>> to know if a specific file was impacted.  We've discussed possibly
>> extending fiemap() to return bad blocks in a file rather than
>> consulting sysfs, or extending lseek() with something like SEEK_ERROR
>> to return offsets of bad areas in a file.
>
> Via what infrastructure will the filesystem use for finding out
> whether a file has bad blocks in it? And if the file does have bad
> blocks, what are you expecting the filesystem to do with that
> information?

We currently have no expectation that the filesystem does anything
with the bad blocks list.  However, if a filesystem had btrfs-like
capabilities to recover data from a redundant location we'd be looking
to plug into that infrastructure.

>> > I haven't seen any design/documentation for infrastructure at the
>> > application layer to handle redundant data and correctly
>> > transparently so I don't have any idea what the technical
>> > requirements this different IO stack places on filesystems may be.
>> > Hence I'm asking for some kind of architecture/design documentation
>> > that I can read to understand exactly what is being proposed here...
>>
>> I think this is a discussion for a solution that would build on top of
>> this basic "here are the errors, re-write them with good data if you
>> can; otherwise, best of luck" foundation.  Something like a DAX-aware
>> device mapper layer that duplicates data tagged with REQ_META so at
>> least we have a recovery path when a sector error lands in critical
>> filesystem-metadata.
>
> Filesytsem metadata is not the topic of discussion here - it's
> user data that throws an error on a DAX load/store that is the
> issue.

Which is not a new problem since volatile DRAM in the non-DAX case can
throw the exact same error.  The current recovery model there is crash
the kernel (without MCE recovery), or crash the application and hope
the kernel maps out the page or the application knows how to restart
after SIGBUS.  Memory mirroring is meant to make this a bit less
harsh, but there's no mechanism to make this available outside the
kernel.

>> However, anything we come up with to make NVDIMM
>> errors more survivable should be directly applicable to traditional
>> disk storage as well.
>
> I'm not sure it does. DAX implies that traditional block layer RAID
> infrastructure is not possible, nor are data CRCs, nor are any other
> sort of data transformations that are needed for redundancy at the
> device layers. Anything that relies on copying/modifying/stable data to
> provide redundancies needs to do such work at a place where it can
> stall userspace page faults.
>
> This is where pmem native filesystem designs like NOVA take over
> from traditional block based filesystems - they are designed around
> the ability to do atomic page-based operations for data protection
> and recovery operations. It is this mechanism that allows stable
> pages to be committed to permanent storage and as such, allow
> redundancy operations such as mirroring to be performed before
> operations are marked as "stable".
>
> I'm missing the bigger picture that is being aimed at here - what's the
> point of DAX if we have to turn it off if we want any sort of
> failure protection? What's the big plan for fully enabling DAX with
> robust error correction? Where is this all supposed to be leading
> to?
>

NOVA and other solutions are free and encouraged to do a coherent
bottoms-up rethink of error handling on top of persistent memory
devices, in the meantime applications can only expect the legacy
SIGBUS and -EIO mechanisms are 

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[Dan Williams]

On Mon, Apr 25, 2016 at 7:56 PM, Dave Chinner  wrote:
> On Mon, Apr 25, 2016 at 06:45:08PM -0700, Dan Williams wrote:
[..]
>> Otherwise, if an application wants to use DAX then it might
>> need to be prepared to handle media errors itself same as the
>> un-RAIDed disk case.  Yes, at an administrative level without
>> reverse-mapping support from a filesystem there's presently no way to
>> ask "which files on this fs are impacted by media errors", and we're
>> aware that reverse-mapping capabilities are nascent for current
>> DAX-aware filesystems.
>
> Precisely my point - suggestions are being proposed which assume
> use of infrastructure that *does not exist yet* and has not been
> discussed or documented. If we're expecting such infrastructure to
> be implemented in the filesystems and block device drivers, then we
> need to determine that the error model actually works first...

These patches only assume the clear-error-on write-model, and that
*maybe* the sysfs bad blocks list is useful if the filesystem has a
reverse-map, or if the application can compare the list against the
results of fiemap().  Beyond that, this is the same perennial "we
should really have better error coordination between block device and
filesystems" discussions that we have at LSF.

>
>> The forward lookup path, as impractical as it
>> is for large numbers of files, is available if an application wanted
>> to know if a specific file was impacted.  We've discussed possibly
>> extending fiemap() to return bad blocks in a file rather than
>> consulting sysfs, or extending lseek() with something like SEEK_ERROR
>> to return offsets of bad areas in a file.
>
> Via what infrastructure will the filesystem use for finding out
> whether a file has bad blocks in it? And if the file does have bad
> blocks, what are you expecting the filesystem to do with that
> information?

We currently have no expectation that the filesystem does anything
with the bad blocks list.  However, if a filesystem had btrfs-like
capabilities to recover data from a redundant location we'd be looking
to plug into that infrastructure.

>> > I haven't seen any design/documentation for infrastructure at the
>> > application layer to handle redundant data and correctly
>> > transparently so I don't have any idea what the technical
>> > requirements this different IO stack places on filesystems may be.
>> > Hence I'm asking for some kind of architecture/design documentation
>> > that I can read to understand exactly what is being proposed here...
>>
>> I think this is a discussion for a solution that would build on top of
>> this basic "here are the errors, re-write them with good data if you
>> can; otherwise, best of luck" foundation.  Something like a DAX-aware
>> device mapper layer that duplicates data tagged with REQ_META so at
>> least we have a recovery path when a sector error lands in critical
>> filesystem-metadata.
>
> Filesytsem metadata is not the topic of discussion here - it's
> user data that throws an error on a DAX load/store that is the
> issue.

Which is not a new problem since volatile DRAM in the non-DAX case can
throw the exact same error.  The current recovery model there is crash
the kernel (without MCE recovery), or crash the application and hope
the kernel maps out the page or the application knows how to restart
after SIGBUS.  Memory mirroring is meant to make this a bit less
harsh, but there's no mechanism to make this available outside the
kernel.

>> However, anything we come up with to make NVDIMM
>> errors more survivable should be directly applicable to traditional
>> disk storage as well.
>
> I'm not sure it does. DAX implies that traditional block layer RAID
> infrastructure is not possible, nor are data CRCs, nor are any other
> sort of data transformations that are needed for redundancy at the
> device layers. Anything that relies on copying/modifying/stable data to
> provide redundancies needs to do such work at a place where it can
> stall userspace page faults.
>
> This is where pmem native filesystem designs like NOVA take over
> from traditional block based filesystems - they are designed around
> the ability to do atomic page-based operations for data protection
> and recovery operations. It is this mechanism that allows stable
> pages to be committed to permanent storage and as such, allow
> redundancy operations such as mirroring to be performed before
> operations are marked as "stable".
>
> I'm missing the bigger picture that is being aimed at here - what's the
> point of DAX if we have to turn it off if we want any sort of
> failure protection? What's the big plan for fully enabling DAX with
> robust error correction? Where is this all supposed to be leading
> to?
>

NOVA and other solutions are free and encouraged to do a coherent
bottoms-up rethink of error handling on top of persistent memory
devices, in the meantime applications can only expect the legacy
SIGBUS and -EIO mechanisms are available.  So I'm still 

[PATCH] panic: lockdep: correct lock debugging state check

[Yang Shi]

When kernel oops happens, lock debugging is turned off by debug_locks_off()
in oops_enter() via calling __debug_locks_off() which set debug_locks to 0
via xchg(). But, calling to __debug_locks_off() to check lock debugging state
in add_taint() called by oops_end() will always return false since xchg()
returns the old value of debug_locks which is cleared in oops_enter() already.

This prevents add_taint() from printing out lock debugging disable information
although LOCKDEP_NOW_UNRELIABLE is passed to it.

Check lock debugging state via !debug_locks to fix this. Although
!__debug_locks_off() could do the same thing, it may look confusing.

Before the fix, oops output looks like:
RIP  [] release_freepages+0x18/0xa0
 RSP 
CR2: 
[ end trace 2e96d09e0ba6342f ]

Aftere the fix, it looks like:
RIP  [] release_freepages+0x18/0xa0
 RSP 
CR2: 
Disabling lock debugging due to kernel taint
[ end trace 2e96d09e0ba6342f ]

And, fix a trivial typo in the comment of add_taint().

Signed-off-by: Yang Shi 
---
 kernel/panic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index 535c965..859499d 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -346,11 +346,11 @@ unsigned long get_taint(void)
  * @lockdep_ok: whether lock debugging is still OK.
  *
  * If something bad has gone wrong, you'll want @lockdebug_ok = false, but for
- * some notewortht-but-not-corrupting cases, it can be set to true.
+ * some noteworthy-but-not-corrupting cases, it can be set to true.
  */
 void add_taint(unsigned flag, enum lockdep_ok lockdep_ok)
 {
-   if (lockdep_ok == LOCKDEP_NOW_UNRELIABLE && __debug_locks_off())
+   if (lockdep_ok == LOCKDEP_NOW_UNRELIABLE && !debug_locks)
pr_warn("Disabling lock debugging due to kernel taint\n");
 
set_bit(flag, _mask);
-- 
2.0.2

[PATCH] panic: lockdep: correct lock debugging state check

[Yang Shi]

When kernel oops happens, lock debugging is turned off by debug_locks_off()
in oops_enter() via calling __debug_locks_off() which set debug_locks to 0
via xchg(). But, calling to __debug_locks_off() to check lock debugging state
in add_taint() called by oops_end() will always return false since xchg()
returns the old value of debug_locks which is cleared in oops_enter() already.

This prevents add_taint() from printing out lock debugging disable information
although LOCKDEP_NOW_UNRELIABLE is passed to it.

Check lock debugging state via !debug_locks to fix this. Although
!__debug_locks_off() could do the same thing, it may look confusing.

Before the fix, oops output looks like:
RIP  [] release_freepages+0x18/0xa0
 RSP 
CR2: 
[ end trace 2e96d09e0ba6342f ]

Aftere the fix, it looks like:
RIP  [] release_freepages+0x18/0xa0
 RSP 
CR2: 
Disabling lock debugging due to kernel taint
[ end trace 2e96d09e0ba6342f ]

And, fix a trivial typo in the comment of add_taint().

Signed-off-by: Yang Shi 
---
 kernel/panic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index 535c965..859499d 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -346,11 +346,11 @@ unsigned long get_taint(void)
  * @lockdep_ok: whether lock debugging is still OK.
  *
  * If something bad has gone wrong, you'll want @lockdebug_ok = false, but for
- * some notewortht-but-not-corrupting cases, it can be set to true.
+ * some noteworthy-but-not-corrupting cases, it can be set to true.
  */
 void add_taint(unsigned flag, enum lockdep_ok lockdep_ok)
 {
-   if (lockdep_ok == LOCKDEP_NOW_UNRELIABLE && __debug_locks_off())
+   if (lockdep_ok == LOCKDEP_NOW_UNRELIABLE && !debug_locks)
pr_warn("Disabling lock debugging due to kernel taint\n");
 
set_bit(flag, _mask);
-- 
2.0.2

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > +struct usb_otg *usb_otg_register(struct device *dev,
> > +struct usb_otg_config *config)
> > +{
> > +   struct usb_otg *otg;
> > +   struct otg_wait_data *wait;
> > +   int ret = 0;
> > +
> > +   if (!dev || !config || !config->fsm_ops)
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   /* already in list? */
> > +   mutex_lock(_list_mutex);
> > +   if (usb_otg_get_data(dev)) {
> > +   dev_err(dev, "otg: %s: device already in otg list\n",
> > +   __func__);
> > +   ret = -EINVAL;
> > +   goto unlock;
> > +   }
> > +
> > +   /* allocate and add to list */
> > +   otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > +   if (!otg) {
> > +   ret = -ENOMEM;
> > +   goto unlock;
> > +   }
> > +
> > +   otg->dev = dev;
> > +   otg->caps = config->otg_caps;
> > +
> > +   if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > +otg->caps->adp_support) && !config->otg_work)
> > +   dev_info(dev, "otg: limiting to dual-role\n");
> 
> dev_err, this should be an error.

The condition may be wrong, but it is an information to show
that current OTG is dual-role.

Peter
> 
> > +
> > +   if (config->otg_work)   /* custom otg_work ? */
> > +   INIT_WORK(>work, config->otg_work);
> > +   else
> > +   INIT_WORK(>work, usb_otg_work);
> > +
> > +   otg->wq = create_singlethread_workqueue("usb_otg");
> > +   if (!otg->wq) {
> > +   dev_err(dev, "otg: %s: can't create workqueue\n",
> > +   __func__);
> > +   ret = -ENOMEM;
> > +   goto err_wq;
> > +   }
> > +
> > +   /* set otg ops */
> > +   otg->fsm.ops = config->fsm_ops;
> > +
> > +   mutex_init(>fsm.lock);
> > +
> > +   list_add_tail(>list, _list);
> > +   mutex_unlock(_list_mutex);
> > +
> > +   /* were we in wait list? */
> > +   mutex_lock(_list_mutex);
> > +   wait = usb_otg_get_wait(dev);
> > +   mutex_unlock(_list_mutex);
> > +   if (wait) {
> > +   /* register pending host/gadget and flush from list */
> > +   usb_otg_flush_wait(dev);
> > +   }
> > +
> > +   return otg;
> > +
> > +err_wq:
> > +   kfree(otg);
> > +unlock:
> > +   mutex_unlock(_list_mutex);
> > +   return ERR_PTR(ret);
> > +}
> > +EXPORT_SYMBOL_GPL(usb_otg_register);
> > +
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Best Regards,
Peter Chen

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > +struct usb_otg *usb_otg_register(struct device *dev,
> > +struct usb_otg_config *config)
> > +{
> > +   struct usb_otg *otg;
> > +   struct otg_wait_data *wait;
> > +   int ret = 0;
> > +
> > +   if (!dev || !config || !config->fsm_ops)
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   /* already in list? */
> > +   mutex_lock(_list_mutex);
> > +   if (usb_otg_get_data(dev)) {
> > +   dev_err(dev, "otg: %s: device already in otg list\n",
> > +   __func__);
> > +   ret = -EINVAL;
> > +   goto unlock;
> > +   }
> > +
> > +   /* allocate and add to list */
> > +   otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > +   if (!otg) {
> > +   ret = -ENOMEM;
> > +   goto unlock;
> > +   }
> > +
> > +   otg->dev = dev;
> > +   otg->caps = config->otg_caps;
> > +
> > +   if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > +otg->caps->adp_support) && !config->otg_work)
> > +   dev_info(dev, "otg: limiting to dual-role\n");
> 
> dev_err, this should be an error.

The condition may be wrong, but it is an information to show
that current OTG is dual-role.

Peter
> 
> > +
> > +   if (config->otg_work)   /* custom otg_work ? */
> > +   INIT_WORK(>work, config->otg_work);
> > +   else
> > +   INIT_WORK(>work, usb_otg_work);
> > +
> > +   otg->wq = create_singlethread_workqueue("usb_otg");
> > +   if (!otg->wq) {
> > +   dev_err(dev, "otg: %s: can't create workqueue\n",
> > +   __func__);
> > +   ret = -ENOMEM;
> > +   goto err_wq;
> > +   }
> > +
> > +   /* set otg ops */
> > +   otg->fsm.ops = config->fsm_ops;
> > +
> > +   mutex_init(>fsm.lock);
> > +
> > +   list_add_tail(>list, _list);
> > +   mutex_unlock(_list_mutex);
> > +
> > +   /* were we in wait list? */
> > +   mutex_lock(_list_mutex);
> > +   wait = usb_otg_get_wait(dev);
> > +   mutex_unlock(_list_mutex);
> > +   if (wait) {
> > +   /* register pending host/gadget and flush from list */
> > +   usb_otg_flush_wait(dev);
> > +   }
> > +
> > +   return otg;
> > +
> > +err_wq:
> > +   kfree(otg);
> > +unlock:
> > +   mutex_unlock(_list_mutex);
> > +   return ERR_PTR(ret);
> > +}
> > +EXPORT_SYMBOL_GPL(usb_otg_register);
> > +
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Best Regards,
Peter Chen

linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Nicolas,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!

Caused by commit

  089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")

from the kbuild-pite tree.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Nicolas,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!

Caused by commit

  089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")

from the kbuild-pite tree.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

[James Bottomley]

On Mon, 2016-04-25 at 22:40 -0400, Martin K. Petersen wrote:
> > > > > > "Josh" == Josh Poimboeuf  writes:
> 
> Josh> Can you merge this patch for 4.6?
> 
> I am really not a big fan of working around compiler bugs in a device
> driver.

Me neither

> Are we sure there are no other get_unaligned_be64() calls in the
> kernel that suffer the same fate?

Agree, plus, as I've said before, we have 3-4 weeks before we go final,
so we still have some time before a decision has to be made.  It looks
like the gcc people already have a patch for the compiler, so the
distributions could just push that out through channels.

James

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

[James Bottomley]

On Mon, 2016-04-25 at 22:40 -0400, Martin K. Petersen wrote:
> > > > > > "Josh" == Josh Poimboeuf  writes:
> 
> Josh> Can you merge this patch for 4.6?
> 
> I am really not a big fan of working around compiler bugs in a device
> driver.

Me neither

> Are we sure there are no other get_unaligned_be64() calls in the
> kernel that suffer the same fate?

Agree, plus, as I've said before, we have 3-4 weeks before we go final,
so we still have some time before a decision has to be made.  It looks
like the gcc people already have a patch for the compiler, so the
distributions could just push that out through channels.

James

Re: [PATCH V9 RESEND 13/14] arm64: tegra: add soctherm node for Tegra210

[Wei Ni]

Hi Thierry,

Do you know who can take these patch 13 and 14?
The corresponding driver was merged to linux-next several weeks ago.
Does I need to send these two patches again?

Thanks.
Wei.

On 2016年04月12日 16:53, Wei Ni wrote:
> Could anyone take a look this patch?
> 
> On 2016年04月01日 15:01, Wei Ni wrote:
>> Patches 1 to 12 in this series were accepted by Eduardo.
>> Patches 13 and 14 need to go via platform or dt tree.
>>
>> Used get_maintainer.pl to get maintainers and open list, add them in To: and 
>> Cc:
>> list.
>>
>> To:
>> Rob Herring 
>> Pawel Moll 
>> Mark Rutland 
>> Ian Campbell 
>> Kumar Gala 
>>
>> Cc:
>> devicet...@vger.kernel.org
>>
>> On 2016年03月29日 23:16, Eduardo Valentin wrote:
>>> On Tue, Mar 29, 2016 at 06:29:23PM +0800, Wei Ni wrote:
 Adds soctherm node for Tegra210, and add cpu,
 gpu, mem, pllx as thermal-zones. Set critical
 trip temperatures for them.

 Signed-off-by: Wei Ni 
>>>
>>> Acked-by: Eduardo Valentin 
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH V9 RESEND 13/14] arm64: tegra: add soctherm node for Tegra210

[Wei Ni]

Hi Thierry,

Do you know who can take these patch 13 and 14?
The corresponding driver was merged to linux-next several weeks ago.
Does I need to send these two patches again?

Thanks.
Wei.

On 2016年04月12日 16:53, Wei Ni wrote:
> Could anyone take a look this patch?
> 
> On 2016年04月01日 15:01, Wei Ni wrote:
>> Patches 1 to 12 in this series were accepted by Eduardo.
>> Patches 13 and 14 need to go via platform or dt tree.
>>
>> Used get_maintainer.pl to get maintainers and open list, add them in To: and 
>> Cc:
>> list.
>>
>> To:
>> Rob Herring 
>> Pawel Moll 
>> Mark Rutland 
>> Ian Campbell 
>> Kumar Gala 
>>
>> Cc:
>> devicet...@vger.kernel.org
>>
>> On 2016年03月29日 23:16, Eduardo Valentin wrote:
>>> On Tue, Mar 29, 2016 at 06:29:23PM +0800, Wei Ni wrote:
 Adds soctherm node for Tegra210, and add cpu,
 gpu, mem, pllx as thermal-zones. Set critical
 trip temperatures for them.

 Signed-off-by: Wei Ni 
>>>
>>> Acked-by: Eduardo Valentin 
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v3 5/5] arm64: dts: marvell: add XOR node for Armada 3700 SoC

[Vinod Koul]

On Thu, Apr 14, 2016 at 06:53:38PM +0200, Gregory CLEMENT wrote:
> From: Marcin Wojtas 
> 
> Armada 3700 SoC comprise one dual-channel XOR engine and this
> patch adds its according representation.

This need an ACK from ARM folks..

> 
> Signed-off-by: Marcin Wojtas 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index ba9df7ff2a72..932783d82ea9 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -112,6 +112,19 @@
>   status = "disabled";
>   };
>  
> + xor@60900 {
> + compatible = "marvell,armada-3700-xor";
> + reg = <0x60900 0x100
> +0x60b00 0x100>;
> +
> + xor10 {
> + interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> + };
> + xor11 {
> + interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
>   sata@e {
>   compatible = "marvell,armada-3700-ahci";
>   reg = <0xe 0x2000>;
> -- 
> 2.5.0
> 

-- 
~Vinod

Re: [PATCH 0/6] drm/fsl-dcu: unload fixes

[Stefan Agner]

Applied patchset to my fsl-dcu tree.

--
Stefan

On 2016-04-16 22:25, Stefan Agner wrote:
> Hi all,
> 
> This patchset fixes several issues around unloading/unbinding
> the driver. There is still one WARNING when unloading the driver
> while vblank interrupts are enabled. I am not sure what/who
> should make sure that vblank interrupts get disabled before
> unloading the driver:
> 
> root@colibri-vf:~# echo 40058000.dcu > 
> /sys/bus/platform/drivers/fsl-dcu/unbind
> [   37.209656] Console: switching to colour dummy device 80x30
> [   37.224954] [ cut here ]
> [   37.245375] WARNING: CPU: 0 PID: 170 at
> drivers/gpu/drm/drm_irq.c:380 drm_vblank_cleanup+0x5c/0x8c
> ...
> 
> Hints welcome...
> 
> Stefan Agner (6):
>   drm/fsl-dcu: detach panel on destroy
>   drm/fsl-dcu: handle missing panel gracefully
>   drm/fsl-dcu: use variable name dev for struct drm_device
>   drm/fsl-dcu: deallocate fbdev CMA on unload
>   drm/fsl-dcu: disable output polling on driver unload
>   drm/fsl-dcu: implement lastclose callback
> 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 50 
> +--
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 23 +-
>  2 files changed, 50 insertions(+), 23 deletions(-)

Re: [PATCH v3 5/5] arm64: dts: marvell: add XOR node for Armada 3700 SoC

[Vinod Koul]

On Thu, Apr 14, 2016 at 06:53:38PM +0200, Gregory CLEMENT wrote:
> From: Marcin Wojtas 
> 
> Armada 3700 SoC comprise one dual-channel XOR engine and this
> patch adds its according representation.

This need an ACK from ARM folks..

> 
> Signed-off-by: Marcin Wojtas 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index ba9df7ff2a72..932783d82ea9 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -112,6 +112,19 @@
>   status = "disabled";
>   };
>  
> + xor@60900 {
> + compatible = "marvell,armada-3700-xor";
> + reg = <0x60900 0x100
> +0x60b00 0x100>;
> +
> + xor10 {
> + interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> + };
> + xor11 {
> + interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
>   sata@e {
>   compatible = "marvell,armada-3700-ahci";
>   reg = <0xe 0x2000>;
> -- 
> 2.5.0
> 

-- 
~Vinod

Re: [PATCH 0/6] drm/fsl-dcu: unload fixes

[Stefan Agner]

Applied patchset to my fsl-dcu tree.

--
Stefan

On 2016-04-16 22:25, Stefan Agner wrote:
> Hi all,
> 
> This patchset fixes several issues around unloading/unbinding
> the driver. There is still one WARNING when unloading the driver
> while vblank interrupts are enabled. I am not sure what/who
> should make sure that vblank interrupts get disabled before
> unloading the driver:
> 
> root@colibri-vf:~# echo 40058000.dcu > 
> /sys/bus/platform/drivers/fsl-dcu/unbind
> [   37.209656] Console: switching to colour dummy device 80x30
> [   37.224954] [ cut here ]
> [   37.245375] WARNING: CPU: 0 PID: 170 at
> drivers/gpu/drm/drm_irq.c:380 drm_vblank_cleanup+0x5c/0x8c
> ...
> 
> Hints welcome...
> 
> Stefan Agner (6):
>   drm/fsl-dcu: detach panel on destroy
>   drm/fsl-dcu: handle missing panel gracefully
>   drm/fsl-dcu: use variable name dev for struct drm_device
>   drm/fsl-dcu: deallocate fbdev CMA on unload
>   drm/fsl-dcu: disable output polling on driver unload
>   drm/fsl-dcu: implement lastclose callback
> 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 50 
> +--
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 23 +-
>  2 files changed, 50 insertions(+), 23 deletions(-)

Re: [PATCH] dmaengine: pxa: handle bus errors

[Vinod Koul]

On Mon, Mar 28, 2016 at 11:32:24PM +0200, Robert Jarzmik wrote:
> In the current state, upon bus error the driver will spin endlessly,
> relaunching the last tx, which will fail again and again :
>  - a bus error happens
>  - pxad_chan_handler() is called
>  - as PXA_DCSR_STOPSTATE is true, the last non-terminated transaction is
>lauched, which is the one triggering the bus error, as it didn't
>terminate
>  - moreover, the STOP interrupt fires a new, as the STOPIRQEN is still
>active
> 
> Break this logic by stopping the automatic relaunch of a dma channel
> upon a bus error, even if there are still pending issued requests on it.
> 
> As dma_cookie_status() seems unable to return DMA_ERROR in its current
> form, ie. there seems no way to mark a DMA_ERROR on a per-async-tx
> basis, it is chosen in this patch to remember on the channel which
> transaction failed, and report it in pxad_tx_status().
> 
> It's a bit misleading because if T1, T2, T3 and T4 were queued, and T1
> was completed while T2 causes a bus error, the status of T3 and T4 will
> be reported as DMA_IN_PROGRESS, while the channel is actually stopped.

Applied, thanks

-- 
~Vinod

RE: [PATCH 0/2] Add Opal unlock support to NVMe.

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: linux-block-ow...@vger.kernel.org [mailto:linux-block-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Monday, April 25, 2016 3:24 AM
> To: Rafael Antognolli 
> Cc: linux-n...@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-bl...@vger.kernel.org
> Subject: Re: [PATCH 0/2] Add Opal unlock support to NVMe.
> 
> On Fri, Apr 22, 2016 at 04:12:10PM -0700, Rafael Antognolli wrote:
> > This patch series implement a small set of the Opal protocol for
> > self encrypting devices. It's implemented only what is needed for
> > saving a password and unlocking a given "locking range". The
> > password is saved on the driver and replayed back to the device
> > on resume from suspend to RAM. It is specifically supporting
> > the single user mode.

Passwords stored in memory are subject to cold boot attacks.

Could you tie this into the keyring infrastructure, so it would
least be no worse than other kernel modules?  This would allow
support for TPM-based keys (if present) to resist more attacks.
If register-based key storage or other techniques prove viable,
they would probably show up there first.

> > It is not planned to implement the full Opal protocol (at least
> > not for now).
> 
> I think the OPAL code should be a generic library outside the NVMe
> code so that we can use it for SATA and SAS as well, just with a
> little glue code for the Security Send / Receive commands to wire
> it up to NVMe.

NVDIMMs would benefit from that as well.

Re: [PATCH] dmaengine: pxa: handle bus errors

[Vinod Koul]

On Mon, Mar 28, 2016 at 11:32:24PM +0200, Robert Jarzmik wrote:
> In the current state, upon bus error the driver will spin endlessly,
> relaunching the last tx, which will fail again and again :
>  - a bus error happens
>  - pxad_chan_handler() is called
>  - as PXA_DCSR_STOPSTATE is true, the last non-terminated transaction is
>lauched, which is the one triggering the bus error, as it didn't
>terminate
>  - moreover, the STOP interrupt fires a new, as the STOPIRQEN is still
>active
> 
> Break this logic by stopping the automatic relaunch of a dma channel
> upon a bus error, even if there are still pending issued requests on it.
> 
> As dma_cookie_status() seems unable to return DMA_ERROR in its current
> form, ie. there seems no way to mark a DMA_ERROR on a per-async-tx
> basis, it is chosen in this patch to remember on the channel which
> transaction failed, and report it in pxad_tx_status().
> 
> It's a bit misleading because if T1, T2, T3 and T4 were queued, and T1
> was completed while T2 causes a bus error, the status of T3 and T4 will
> be reported as DMA_IN_PROGRESS, while the channel is actually stopped.

Applied, thanks

-- 
~Vinod

RE: [PATCH 0/2] Add Opal unlock support to NVMe.

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: linux-block-ow...@vger.kernel.org [mailto:linux-block-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Monday, April 25, 2016 3:24 AM
> To: Rafael Antognolli 
> Cc: linux-n...@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-bl...@vger.kernel.org
> Subject: Re: [PATCH 0/2] Add Opal unlock support to NVMe.
> 
> On Fri, Apr 22, 2016 at 04:12:10PM -0700, Rafael Antognolli wrote:
> > This patch series implement a small set of the Opal protocol for
> > self encrypting devices. It's implemented only what is needed for
> > saving a password and unlocking a given "locking range". The
> > password is saved on the driver and replayed back to the device
> > on resume from suspend to RAM. It is specifically supporting
> > the single user mode.

Passwords stored in memory are subject to cold boot attacks.

Could you tie this into the keyring infrastructure, so it would
least be no worse than other kernel modules?  This would allow
support for TPM-based keys (if present) to resist more attacks.
If register-based key storage or other techniques prove viable,
they would probably show up there first.

> > It is not planned to implement the full Opal protocol (at least
> > not for now).
> 
> I think the OPAL code should be a generic library outside the NVMe
> code so that we can use it for SATA and SAS as well, just with a
> little glue code for the Security Send / Receive commands to wire
> it up to NVMe.

NVDIMMs would benefit from that as well.

RE: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver

[Yangbo Lu]

Hi Scott and Leo,


> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Saturday, April 23, 2016 7:23 AM
> To: Yangbo Lu; linux-...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: ulf.hans...@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma;
> Scott Wood; Claudiu Manoil; Kumar Gala; Yang-Leo Li; Xiaobo Xie; Michael
> Ellerman
> Subject: Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific
> driver
> 
> On Fri, 2016-04-22 at 14:27 +0800, Yangbo Lu wrote:
> > Add maintainer entry for Freescale SoC specific driver including the
> > QE library and the GUTS driver. Also add entry for GUTS driver and add
> > maintainer for QE library.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> > Changes for v8:
> > - Added this patch
> > ---
> >  MAINTAINERS | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..d20aeb6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4622,13 +4622,27 @@ F:  drivers/net/ethernet/freescale/fec_ptp.c
> >  F: drivers/net/ethernet/freescale/fec.h
> >  F: Documentation/devicetree/bindings/net/fsl-fec.txt
> >
> > +FREESCALE SOC SPECIFIC DRIVER
> 
> FREESCALE SOC DRIVERS

[Lu Yangbo-B47093] Ok, will change it to 'FREESCALE SOC DRIVERS'.

> 
> > +M: Scott Wood 
> 
> Please CC me at this address, not the NXP address that you sent this to...

[Lu Yangbo-B47093] Sorry for mistaking your email. Will send the one you said.

> 
> > +L: linuxppc-...@lists.ozlabs.org
> > +S: Maintained
> > +F: drivers/soc/fsl/
> > +F: include/linux/fsl/
> 
> This directory will contain drivers that work on PPC and ARM... I'm not
> sure what to put here in terms of mailing lists (we could put both, but
> people probably shouldn't spam both lists if only one arch is relevant to
> the patch), and whom to make pull requests to.

[Lu Yangbo-B47093] But sooner or later we need to do this for files in fsl/ ...
:)

Hi Leo, do you have any idea?


> 
> > +FREESCALE GUTS DRIVER
> > +M: Yangbo Lu 
> > +L: linuxppc-...@lists.ozlabs.org
> > +S: Maintained
> > +F: drivers/soc/fsl/guts.c
> 
> What about the header?
> 
> Does guts really need a separate maintainer from drivers/soc/fsl?

[Lu Yangbo-B47093] I was hesitating to add the maintainer...
And I was not so familiar with it. Let me leave it to the fsl/ directory and 
remove this...

> 
> -Scott
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver

[Yangbo Lu]

Hi Scott and Leo,


> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Saturday, April 23, 2016 7:23 AM
> To: Yangbo Lu; linux-...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: ulf.hans...@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma;
> Scott Wood; Claudiu Manoil; Kumar Gala; Yang-Leo Li; Xiaobo Xie; Michael
> Ellerman
> Subject: Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific
> driver
> 
> On Fri, 2016-04-22 at 14:27 +0800, Yangbo Lu wrote:
> > Add maintainer entry for Freescale SoC specific driver including the
> > QE library and the GUTS driver. Also add entry for GUTS driver and add
> > maintainer for QE library.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> > Changes for v8:
> > - Added this patch
> > ---
> >  MAINTAINERS | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..d20aeb6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4622,13 +4622,27 @@ F:  drivers/net/ethernet/freescale/fec_ptp.c
> >  F: drivers/net/ethernet/freescale/fec.h
> >  F: Documentation/devicetree/bindings/net/fsl-fec.txt
> >
> > +FREESCALE SOC SPECIFIC DRIVER
> 
> FREESCALE SOC DRIVERS

[Lu Yangbo-B47093] Ok, will change it to 'FREESCALE SOC DRIVERS'.

> 
> > +M: Scott Wood 
> 
> Please CC me at this address, not the NXP address that you sent this to...

[Lu Yangbo-B47093] Sorry for mistaking your email. Will send the one you said.

> 
> > +L: linuxppc-...@lists.ozlabs.org
> > +S: Maintained
> > +F: drivers/soc/fsl/
> > +F: include/linux/fsl/
> 
> This directory will contain drivers that work on PPC and ARM... I'm not
> sure what to put here in terms of mailing lists (we could put both, but
> people probably shouldn't spam both lists if only one arch is relevant to
> the patch), and whom to make pull requests to.

[Lu Yangbo-B47093] But sooner or later we need to do this for files in fsl/ ...
:)

Hi Leo, do you have any idea?


> 
> > +FREESCALE GUTS DRIVER
> > +M: Yangbo Lu 
> > +L: linuxppc-...@lists.ozlabs.org
> > +S: Maintained
> > +F: drivers/soc/fsl/guts.c
> 
> What about the header?
> 
> Does guts really need a separate maintainer from drivers/soc/fsl?

[Lu Yangbo-B47093] I was hesitating to add the maintainer...
And I was not so familiar with it. Let me leave it to the fsl/ directory and 
remove this...

> 
> -Scott
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2 v3] fsl-mc binding and device tree updates

[Shawn Guo]

On Tue, Apr 19, 2016 at 04:43:27PM -0500, Stuart Yoder wrote:
> Stuart Yoder (2):
>   Documentation: fsl-mc: binding updates for MSIs, ranges, PHYs
>   arm64: dts: ls2080a: fsl-mc dt node updates

Applied both, thanks.

Re: [PATCH 0/2 v3] fsl-mc binding and device tree updates

[Shawn Guo]

On Tue, Apr 19, 2016 at 04:43:27PM -0500, Stuart Yoder wrote:
> Stuart Yoder (2):
>   Documentation: fsl-mc: binding updates for MSIs, ranges, PHYs
>   arm64: dts: ls2080a: fsl-mc dt node updates

Applied both, thanks.

Re: [PATCH V17 2/3] dmaengine: qcom_hidma: add debugfs hooks

[Vinod Koul]

On Mon, Apr 11, 2016 at 10:21:12AM -0400, Sinan Kaya wrote:

> +static int hidma_chan_stats(struct seq_file *s, void *unused)
> +{
> + struct hidma_chan *mchan = s->private;
> + struct hidma_desc *mdesc;
> + struct hidma_dev *dmadev = mchan->dmadev;
> +
> + pm_runtime_get_sync(dmadev->ddev.dev);

debug shouldn't power up device, why do you want to do that

-- 
~Vinod

Re: [PATCH V17 2/3] dmaengine: qcom_hidma: add debugfs hooks

[Vinod Koul]

On Mon, Apr 11, 2016 at 10:21:12AM -0400, Sinan Kaya wrote:

> +static int hidma_chan_stats(struct seq_file *s, void *unused)
> +{
> + struct hidma_chan *mchan = s->private;
> + struct hidma_desc *mdesc;
> + struct hidma_dev *dmadev = mchan->dmadev;
> +
> + pm_runtime_get_sync(dmadev->ddev.dev);

debug shouldn't power up device, why do you want to do that

-- 
~Vinod

Re: [PATCH V17 1/3] dmaengine: qcom_hidma: implement lower level hardware interface

[Vinod Koul]

On Mon, Apr 11, 2016 at 10:21:11AM -0400, Sinan Kaya wrote:

> + * HIDMA is not aware of IOMMU presence since it follows the DMA API. All
> + * IOMMU latency will be built into the data movement time. By the time
> + * interrupt happens, IOMMU lookups + data movement has already taken place.

Do you mean dmaengine API or dma mapping API here? Where is you IOMMU
located wrt to dma controller?

> + *
> + * While the first read in a typical PCI endpoint ISR flushes all outstanding
> + * requests traditionally to the destination, this concept does not apply
> + * here for this HW.
> + */
> +static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev)
> +{
> + u32 status;
> + u32 enable;
> + u32 cause;
> +
> + /*
> +  * Fine tuned for this HW...
> +  *
> +  * This ISR has been designed for this particular hardware. Relaxed
> +  * read and write accessors are used for performance reasons due to
> +  * interrupt delivery guarantees. Do not copy this code blindly and
> +  * expect that to work.
> +  */
> + status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
> + enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
> + cause = status & enable;
> +
> + while (cause) {
> + if ((cause & BIT(HIDMA_IRQ_TR_CH_INVALID_TRE_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_EV_CH_WR_RESP_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_TR_CH_DATA_RD_ER_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_TR_CH_DATA_WR_ER_BIT_POS))) {

Switch please

> + u8 err_code = HIDMA_EVRE_STATUS_ERROR;
> + u8 err_info = 0xFF;
> +
> + /* Clear out pending interrupts */
> + writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
> +
> + dev_err(lldev->dev, "error 0x%x, resetting...\n",
> + cause);
> +
> + hidma_cleanup_pending_tre(lldev, err_info, err_code);
> +
> + /* reset the channel for recovery */
> + if (hidma_ll_setup(lldev)) {

should this be done in ISR?

> +int hidma_ll_resume(struct hidma_lldev *lldev)
> +{
> + return hidma_ll_enable(lldev);
> +}

why do we need this empty function, use hidma_ll_enable.

> +bool hidma_ll_isenabled(struct hidma_lldev *lldev)
> +{
> + u32 val;
> +
> + val = readl(lldev->trca + HIDMA_TRCA_CTRLSTS_REG);
> + lldev->trch_state = HIDMA_CH_STATE(val);
> + val = readl(lldev->evca + HIDMA_EVCA_CTRLSTS_REG);
> + lldev->evch_state = HIDMA_CH_STATE(val);
> +
> + /* both channels have to be enabled before calling this function */
> + if (((lldev->trch_state == HIDMA_CH_ENABLED) ||
> +  (lldev->trch_state == HIDMA_CH_RUNNING)) &&
> + ((lldev->evch_state == HIDMA_CH_ENABLED) ||
> +  (lldev->evch_state == HIDMA_CH_RUNNING)))
> + return true;

hmmm this looks hard to read, why not do:

is_chan_enabled(state)
{
switch (state) {
case HIDMA_CH_ENABLED:
case HIDMA_CH_RUNNING:
return true;
default:
return false;
}

and then :

if (is_chan_enabled(lldev->trch_state) &&
is_chan_enabled(lldev->evch_state))


> +void hidma_ll_start(struct hidma_lldev *lldev)
> +{
> + hidma_ll_hw_start(lldev);
> +}

Another dummy :(

> +/*
> + * Note that even though we stop this channel
> + * if there is a pending transaction in flight
> + * it will complete and follow the callback.
> + * This request will prevent further requests
> + * to be made.

Why the odd formating?

> +int hidma_ll_uninit(struct hidma_lldev *lldev)
> +{
> + int rc = 0;
> + u32 val;
> +
> + if (!lldev)
> + return -ENODEV;
> +
> + if (lldev->initialized) {
> + u32 required_bytes;
> +
> + lldev->initialized = 0;
> +
> + required_bytes = sizeof(struct hidma_tre) * lldev->nr_tres;
> + tasklet_kill(>task);
> + memset(lldev->trepool, 0, required_bytes);
> + lldev->trepool = NULL;
> + lldev->pending_tre_count = 0;
> + lldev->tre_write_offset = 0;
> +
> + rc = hidma_ll_reset(lldev);
> +
> + /*
> +  * Clear all pending interrupts again.
> +  * Otherwise, we observe reset complete interrupts.
> +  */
> + val = readl(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
> + writel(val, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
> + hidma_ll_enable_irq(lldev, 0);

uninit enables irq?

-- 
~Vinod

Re: [PATCH V17 1/3] dmaengine: qcom_hidma: implement lower level hardware interface

[Vinod Koul]

On Mon, Apr 11, 2016 at 10:21:11AM -0400, Sinan Kaya wrote:

> + * HIDMA is not aware of IOMMU presence since it follows the DMA API. All
> + * IOMMU latency will be built into the data movement time. By the time
> + * interrupt happens, IOMMU lookups + data movement has already taken place.

Do you mean dmaengine API or dma mapping API here? Where is you IOMMU
located wrt to dma controller?

> + *
> + * While the first read in a typical PCI endpoint ISR flushes all outstanding
> + * requests traditionally to the destination, this concept does not apply
> + * here for this HW.
> + */
> +static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev)
> +{
> + u32 status;
> + u32 enable;
> + u32 cause;
> +
> + /*
> +  * Fine tuned for this HW...
> +  *
> +  * This ISR has been designed for this particular hardware. Relaxed
> +  * read and write accessors are used for performance reasons due to
> +  * interrupt delivery guarantees. Do not copy this code blindly and
> +  * expect that to work.
> +  */
> + status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
> + enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
> + cause = status & enable;
> +
> + while (cause) {
> + if ((cause & BIT(HIDMA_IRQ_TR_CH_INVALID_TRE_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_EV_CH_WR_RESP_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_TR_CH_DATA_RD_ER_BIT_POS)) ||
> + (cause & BIT(HIDMA_IRQ_TR_CH_DATA_WR_ER_BIT_POS))) {

Switch please

> + u8 err_code = HIDMA_EVRE_STATUS_ERROR;
> + u8 err_info = 0xFF;
> +
> + /* Clear out pending interrupts */
> + writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
> +
> + dev_err(lldev->dev, "error 0x%x, resetting...\n",
> + cause);
> +
> + hidma_cleanup_pending_tre(lldev, err_info, err_code);
> +
> + /* reset the channel for recovery */
> + if (hidma_ll_setup(lldev)) {

should this be done in ISR?

> +int hidma_ll_resume(struct hidma_lldev *lldev)
> +{
> + return hidma_ll_enable(lldev);
> +}

why do we need this empty function, use hidma_ll_enable.

> +bool hidma_ll_isenabled(struct hidma_lldev *lldev)
> +{
> + u32 val;
> +
> + val = readl(lldev->trca + HIDMA_TRCA_CTRLSTS_REG);
> + lldev->trch_state = HIDMA_CH_STATE(val);
> + val = readl(lldev->evca + HIDMA_EVCA_CTRLSTS_REG);
> + lldev->evch_state = HIDMA_CH_STATE(val);
> +
> + /* both channels have to be enabled before calling this function */
> + if (((lldev->trch_state == HIDMA_CH_ENABLED) ||
> +  (lldev->trch_state == HIDMA_CH_RUNNING)) &&
> + ((lldev->evch_state == HIDMA_CH_ENABLED) ||
> +  (lldev->evch_state == HIDMA_CH_RUNNING)))
> + return true;

hmmm this looks hard to read, why not do:

is_chan_enabled(state)
{
switch (state) {
case HIDMA_CH_ENABLED:
case HIDMA_CH_RUNNING:
return true;
default:
return false;
}

and then :

if (is_chan_enabled(lldev->trch_state) &&
is_chan_enabled(lldev->evch_state))


> +void hidma_ll_start(struct hidma_lldev *lldev)
> +{
> + hidma_ll_hw_start(lldev);
> +}

Another dummy :(

> +/*
> + * Note that even though we stop this channel
> + * if there is a pending transaction in flight
> + * it will complete and follow the callback.
> + * This request will prevent further requests
> + * to be made.

Why the odd formating?

> +int hidma_ll_uninit(struct hidma_lldev *lldev)
> +{
> + int rc = 0;
> + u32 val;
> +
> + if (!lldev)
> + return -ENODEV;
> +
> + if (lldev->initialized) {
> + u32 required_bytes;
> +
> + lldev->initialized = 0;
> +
> + required_bytes = sizeof(struct hidma_tre) * lldev->nr_tres;
> + tasklet_kill(>task);
> + memset(lldev->trepool, 0, required_bytes);
> + lldev->trepool = NULL;
> + lldev->pending_tre_count = 0;
> + lldev->tre_write_offset = 0;
> +
> + rc = hidma_ll_reset(lldev);
> +
> + /*
> +  * Clear all pending interrupts again.
> +  * Otherwise, we observe reset complete interrupts.
> +  */
> + val = readl(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
> + writel(val, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
> + hidma_ll_enable_irq(lldev, 0);

uninit enables irq?

-- 
~Vinod

RE: [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap

[Li, Liang Z]

> On Mon, Apr 25, 2016 at 03:11:05AM +, Li, Liang Z wrote:
> > > On Fri, Apr 22, 2016 at 10:48:38AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > > > On Tue, Apr 19, 2016 at 03:02:09PM +, Li, Liang Z wrote:
> > > > > > > On Tue, 2016-04-19 at 22:34 +0800, Liang Li wrote:
> > > > > > > > The free page bitmap will be sent to QEMU through virtio
> > > > > > > > interface and used for live migration optimization.
> > > > > > > > Drop the cache before building the free page bitmap can
> > > > > > > > get more free pages. Whether dropping the cache is decided by
> user.
> > > > > > > >
> > > > > > >
> > > > > > > How do you prevent the guest from using those recently-freed
> > > > > > > pages for something else, between when you build the bitmap
> > > > > > > and the live migration completes?
> > > > > >
> > > > > > Because the dirty page logging is enabled before building the
> > > > > > bitmap, there is no need to prevent the guest from using the
> > > > > > recently-
> > > freed pages ...
> > > > > >
> > > > > > Liang
> > > > >
> > > > > Well one point of telling host that page is free is so that it
> > > > > can mark it clean even if it was dirty previously.
> > > > > So I think you must pass the pages to guest under the lock.
> > > > > This will allow host optimizations such as marking these pages
> > > > > MADV_DONTNEED or MADV_FREE.
> > > > > Otherwise it's all too tied up to a specific usecase - you
> > > > > aren't telling host that a page is free, you are telling it that
> > > > > a page was free in the past.
> > > >
> > > > But doing it under lock sounds pretty expensive, especially given
> > > > how long the userspace side is going to take to work through the
> > > > bitmap and device what to do.
> > > >
> > > > Dave
> > >
> > > We need to make it as fast as we can since the VCPU is stopped on
> > > exit anyway. This just means e.g. sizing the bitmap reasonably -
> > > don't always try to fit all memory in a single bitmap.
> >
> > Then we should pause the whole VM when using the bitmap, too
> expensive?
> 
> Why should we? I don't get it. Just make sure that at the point when you give
> a page to host, it's not in use. Host can clear the dirty bitmap, discard the
> page, or whatever.
> 
I did not know you mean to put the page into balloon. 
There is no need to pause the VM if you do in that way.

> > > Really, if the page can in fact be in use when you tell host it's
> > > free, then it's rather hard to explain what does it mean from
> > > host/guest interface point of view.
> > >
> >
> > How about rename the interface to a more appropriate name other than
> 'free page' ?
> >
> > Liang.
> 
> Maybe. But start with a description.
> 
> The way I figured is passing a page to host meant putting it in the balloon 
> and
> immediately taking it out again. this allows things like discarding it since 
> while
> page is in the balloon, it is owned by the balloon.
> 
> This aligns well with how balloon works today.
>
 > 
> If not that, then what can it actually mean?
> 
> Without a lock, the only thing we can make it mean is that the page is in the
> balloon at some point after the report is requested and before it's passed to
> balloon.
> 
> This happens to work if you only have one page in the balloon, but to make it
> asynchronous you really have to pass in a request ID, and then return it back
> with the bitmap. This way we can say "this page was free sometime after
> host sent request with this ID and before it received response with the same
> ID".
> 
> And then, what host is supposed to do for pre-copy, copy the dirty bitmap
> before sending request, then on response we clear bit in this bitmap copy,
> then we set bits received from kvm (or another backend) afterwards.
> 
> Of course just not retrieving the bitmap from kvm until we get a response
> also works (this is what your patches did) and then you do not need a copy,
> but that's inelegant because this means guest can defer completing
> migration.

My RFC version patch did like this, but this version I changed the behavior,
now there is no waiting before starting live migration.

> 
> So this works for migration but not for discarding pages.
> 
> For this reason I think as a first step, we should focus on the simpler
> approach where we keep the lock.  Then add a feature bit that allows
> dropping the lock.
> 
> 

I got you this time,  but I still don't think put the free page in the balloon 
is a good
idea for live migration optimization. There is no need to do extra things which 
increases
the guest's overhead, it's not worth the candle.

We can do something this to optimize the current virtio-balloon's performance. 
but not for live migration, the efficiency should be the first thing we consider
about, or we run the risk of blocking user from using this new feature.
 
Liang
> 
> 
> > > It probably can be defined but the interface seems very complex.
> > >
> > > Let's start with a simple 

RE: [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap

[Li, Liang Z]

> On Mon, Apr 25, 2016 at 03:11:05AM +, Li, Liang Z wrote:
> > > On Fri, Apr 22, 2016 at 10:48:38AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > > > On Tue, Apr 19, 2016 at 03:02:09PM +, Li, Liang Z wrote:
> > > > > > > On Tue, 2016-04-19 at 22:34 +0800, Liang Li wrote:
> > > > > > > > The free page bitmap will be sent to QEMU through virtio
> > > > > > > > interface and used for live migration optimization.
> > > > > > > > Drop the cache before building the free page bitmap can
> > > > > > > > get more free pages. Whether dropping the cache is decided by
> user.
> > > > > > > >
> > > > > > >
> > > > > > > How do you prevent the guest from using those recently-freed
> > > > > > > pages for something else, between when you build the bitmap
> > > > > > > and the live migration completes?
> > > > > >
> > > > > > Because the dirty page logging is enabled before building the
> > > > > > bitmap, there is no need to prevent the guest from using the
> > > > > > recently-
> > > freed pages ...
> > > > > >
> > > > > > Liang
> > > > >
> > > > > Well one point of telling host that page is free is so that it
> > > > > can mark it clean even if it was dirty previously.
> > > > > So I think you must pass the pages to guest under the lock.
> > > > > This will allow host optimizations such as marking these pages
> > > > > MADV_DONTNEED or MADV_FREE.
> > > > > Otherwise it's all too tied up to a specific usecase - you
> > > > > aren't telling host that a page is free, you are telling it that
> > > > > a page was free in the past.
> > > >
> > > > But doing it under lock sounds pretty expensive, especially given
> > > > how long the userspace side is going to take to work through the
> > > > bitmap and device what to do.
> > > >
> > > > Dave
> > >
> > > We need to make it as fast as we can since the VCPU is stopped on
> > > exit anyway. This just means e.g. sizing the bitmap reasonably -
> > > don't always try to fit all memory in a single bitmap.
> >
> > Then we should pause the whole VM when using the bitmap, too
> expensive?
> 
> Why should we? I don't get it. Just make sure that at the point when you give
> a page to host, it's not in use. Host can clear the dirty bitmap, discard the
> page, or whatever.
> 
I did not know you mean to put the page into balloon. 
There is no need to pause the VM if you do in that way.

> > > Really, if the page can in fact be in use when you tell host it's
> > > free, then it's rather hard to explain what does it mean from
> > > host/guest interface point of view.
> > >
> >
> > How about rename the interface to a more appropriate name other than
> 'free page' ?
> >
> > Liang.
> 
> Maybe. But start with a description.
> 
> The way I figured is passing a page to host meant putting it in the balloon 
> and
> immediately taking it out again. this allows things like discarding it since 
> while
> page is in the balloon, it is owned by the balloon.
> 
> This aligns well with how balloon works today.
>
 > 
> If not that, then what can it actually mean?
> 
> Without a lock, the only thing we can make it mean is that the page is in the
> balloon at some point after the report is requested and before it's passed to
> balloon.
> 
> This happens to work if you only have one page in the balloon, but to make it
> asynchronous you really have to pass in a request ID, and then return it back
> with the bitmap. This way we can say "this page was free sometime after
> host sent request with this ID and before it received response with the same
> ID".
> 
> And then, what host is supposed to do for pre-copy, copy the dirty bitmap
> before sending request, then on response we clear bit in this bitmap copy,
> then we set bits received from kvm (or another backend) afterwards.
> 
> Of course just not retrieving the bitmap from kvm until we get a response
> also works (this is what your patches did) and then you do not need a copy,
> but that's inelegant because this means guest can defer completing
> migration.

My RFC version patch did like this, but this version I changed the behavior,
now there is no waiting before starting live migration.

> 
> So this works for migration but not for discarding pages.
> 
> For this reason I think as a first step, we should focus on the simpler
> approach where we keep the lock.  Then add a feature bit that allows
> dropping the lock.
> 
> 

I got you this time,  but I still don't think put the free page in the balloon 
is a good
idea for live migration optimization. There is no need to do extra things which 
increases
the guest's overhead, it's not worth the candle.

We can do something this to optimize the current virtio-balloon's performance. 
but not for live migration, the efficiency should be the first thing we consider
about, or we run the risk of blocking user from using this new feature.
 
Liang
> 
> 
> > > It probably can be defined but the interface seems very complex.
> > >
> > > Let's start with a simple 

[PATCH net-next V2] tuntap: calculate rps hash only when needed

[Jason Wang]

There's no need to calculate rps hash if it was not enabled. So this
patch export rps_needed and check it before trying to get rps
hash. Tests (using pktgen to inject packets to guest) shows this can
improve pps about 13% (when rps is disabled).

Before:
~115 pps
After:
~130 pps

Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

Changes from V1:
- Fix build when CONFIG_RPS is not set
---
 drivers/net/tun.c | 4 +++-
 net/core/dev.c| 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index afdf950..8df9e23 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -819,7 +819,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct 
net_device *dev)
if (txq >= numqueues)
goto drop;
 
-   if (numqueues == 1) {
+#ifdef CONFIG_RPS
+   if (numqueues == 1 && static_key_false(_needed)) {
/* Select queue was not called for the skbuff, so we extract the
 * RPS hash and save it into the flow_table here.
 */
@@ -834,6 +835,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct 
net_device *dev)
tun_flow_save_rps_rxhash(e, rxhash);
}
}
+#endif
 
tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
 
diff --git a/net/core/dev.c b/net/core/dev.c
index b9bcbe7..d4ba936 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3428,6 +3428,7 @@ u32 rps_cpu_mask __read_mostly;
 EXPORT_SYMBOL(rps_cpu_mask);
 
 struct static_key rps_needed __read_mostly;
+EXPORT_SYMBOL(rps_needed);
 
 static struct rps_dev_flow *
 set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
-- 
1.8.3.1

[PATCH net-next V2] tuntap: calculate rps hash only when needed

[Jason Wang]

There's no need to calculate rps hash if it was not enabled. So this
patch export rps_needed and check it before trying to get rps
hash. Tests (using pktgen to inject packets to guest) shows this can
improve pps about 13% (when rps is disabled).

Before:
~115 pps
After:
~130 pps

Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

Changes from V1:
- Fix build when CONFIG_RPS is not set
---
 drivers/net/tun.c | 4 +++-
 net/core/dev.c| 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index afdf950..8df9e23 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -819,7 +819,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct 
net_device *dev)
if (txq >= numqueues)
goto drop;
 
-   if (numqueues == 1) {
+#ifdef CONFIG_RPS
+   if (numqueues == 1 && static_key_false(_needed)) {
/* Select queue was not called for the skbuff, so we extract the
 * RPS hash and save it into the flow_table here.
 */
@@ -834,6 +835,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct 
net_device *dev)
tun_flow_save_rps_rxhash(e, rxhash);
}
}
+#endif
 
tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
 
diff --git a/net/core/dev.c b/net/core/dev.c
index b9bcbe7..d4ba936 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3428,6 +3428,7 @@ u32 rps_cpu_mask __read_mostly;
 EXPORT_SYMBOL(rps_cpu_mask);
 
 struct static_key rps_needed __read_mostly;
+EXPORT_SYMBOL(rps_needed);
 
 static struct rps_dev_flow *
 set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
-- 
1.8.3.1

Re: [PATCH net-next] tuntap: calculate rps hash only when needed

[Jason Wang]

On 04/26/2016 09:55 AM, Jason Wang wrote:
> There's no need to calculate rps hash if it was not enabled. So this
> patch export rps_needed and check it before trying to get rps
> hash. Tests (using pktgen to inject packets to guest) shows this can
> improve pps about 13% (when rps is disabled).
>
> Before:
> ~115 pps
> After:
> ~130 pps
>
> Cc: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 
> ---
>  drivers/net/tun.c | 2 +-
>  net/core/dev.c| 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index afdf950..746877f 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -819,7 +819,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, 
> struct net_device *dev)
>   if (txq >= numqueues)
>   goto drop;
>  
> - if (numqueues == 1) {
> + if (numqueues == 1 && static_key_false(_needed)) {
>   /* Select queue was not called for the skbuff, so we extract the
>* RPS hash and save it into the flow_table here.
>*/
> diff --git a/net/core/dev.c b/net/core/dev.c
> index b9bcbe7..d4ba936 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3428,6 +3428,7 @@ u32 rps_cpu_mask __read_mostly;
>  EXPORT_SYMBOL(rps_cpu_mask);
>  
>  struct static_key rps_needed __read_mostly;
> +EXPORT_SYMBOL(rps_needed);
>  
>  static struct rps_dev_flow *
>  set_rps_cpu(struct net_device *dev, struct sk_buff *skb,

Kbuild bot reports an error when !CONFIG_RPS. Will send V2 to fix this.

Re: next: suspicious RCU usage message since commit 'rcu: Remove superfluous versions of rcu_read_lock_sched_held()'

[Guenter Roeck]

On 04/25/2016 01:49 PM, Paul E. McKenney wrote:

On Mon, Apr 25, 2016 at 01:25:10PM -0700, Guenter Roeck wrote:

On Mon, Apr 25, 2016 at 10:12:39AM -0700, Paul E. McKenney wrote:

On Sun, Apr 24, 2016 at 11:26:41PM -0700, Guenter Roeck wrote:

On 04/24/2016 10:49 PM, Paul E. McKenney wrote:

On Sun, Apr 24, 2016 at 10:37:25PM -0700, Guenter Roeck wrote:

On 04/24/2016 10:28 PM, Paul E. McKenney wrote:

On Sun, Apr 24, 2016 at 04:56:38PM -0700, Guenter Roeck wrote:


[ . . . ]


After making the same change in _pwrdm_state_switch(), the traceback is gone

>from my tests (beagle, beagle-xm, and overo-tobi).

Very good!

(And yes, you normally find these one at a time...)


Are you going to submit a formal patch ?


I can, but please feel free to send mine along with yours, if you wish.


I think it would be best if you send a single patch which fixes both calls.


Like this one?

If so, could you please run it to make sure that it actually fixes the
problem?  And if it does, would you be willing to give me a Tested-by?


It does. Tested-by: inline below.


Got it, thank you!

If the ARM guys are willing to take this, it might hit the next merge
window, or perhaps they will take it as an exception.  If I push it
up my usual route, it will be a bit later.

I just now sent it out, so hopefully they will grab it.  ;-)


Hi Paul,

Either it fixes a zero-day bug which was exposed by 'rcu: Remove superfluous
versions ...", or it fixes a problem with that commit, so I would hope that
_someone_ will pick it up.

Anyway, thanks a lot for looking into it, and for the patch!

Guenter

Re: [PATCH net-next] tuntap: calculate rps hash only when needed

[Jason Wang]

On 04/26/2016 09:55 AM, Jason Wang wrote:
> There's no need to calculate rps hash if it was not enabled. So this
> patch export rps_needed and check it before trying to get rps
> hash. Tests (using pktgen to inject packets to guest) shows this can
> improve pps about 13% (when rps is disabled).
>
> Before:
> ~115 pps
> After:
> ~130 pps
>
> Cc: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 
> ---
>  drivers/net/tun.c | 2 +-
>  net/core/dev.c| 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index afdf950..746877f 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -819,7 +819,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, 
> struct net_device *dev)
>   if (txq >= numqueues)
>   goto drop;
>  
> - if (numqueues == 1) {
> + if (numqueues == 1 && static_key_false(_needed)) {
>   /* Select queue was not called for the skbuff, so we extract the
>* RPS hash and save it into the flow_table here.
>*/
> diff --git a/net/core/dev.c b/net/core/dev.c
> index b9bcbe7..d4ba936 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3428,6 +3428,7 @@ u32 rps_cpu_mask __read_mostly;
>  EXPORT_SYMBOL(rps_cpu_mask);
>  
>  struct static_key rps_needed __read_mostly;
> +EXPORT_SYMBOL(rps_needed);
>  
>  static struct rps_dev_flow *
>  set_rps_cpu(struct net_device *dev, struct sk_buff *skb,

Kbuild bot reports an error when !CONFIG_RPS. Will send V2 to fix this.

Re: next: suspicious RCU usage message since commit 'rcu: Remove superfluous versions of rcu_read_lock_sched_held()'

[Guenter Roeck]

On 04/25/2016 01:49 PM, Paul E. McKenney wrote:

On Mon, Apr 25, 2016 at 01:25:10PM -0700, Guenter Roeck wrote:

On Mon, Apr 25, 2016 at 10:12:39AM -0700, Paul E. McKenney wrote:

On Sun, Apr 24, 2016 at 11:26:41PM -0700, Guenter Roeck wrote:

On 04/24/2016 10:49 PM, Paul E. McKenney wrote:

On Sun, Apr 24, 2016 at 10:37:25PM -0700, Guenter Roeck wrote:

On 04/24/2016 10:28 PM, Paul E. McKenney wrote:

On Sun, Apr 24, 2016 at 04:56:38PM -0700, Guenter Roeck wrote:


[ . . . ]


After making the same change in _pwrdm_state_switch(), the traceback is gone

>from my tests (beagle, beagle-xm, and overo-tobi).

Very good!

(And yes, you normally find these one at a time...)


Are you going to submit a formal patch ?


I can, but please feel free to send mine along with yours, if you wish.


I think it would be best if you send a single patch which fixes both calls.


Like this one?

If so, could you please run it to make sure that it actually fixes the
problem?  And if it does, would you be willing to give me a Tested-by?


It does. Tested-by: inline below.


Got it, thank you!

If the ARM guys are willing to take this, it might hit the next merge
window, or perhaps they will take it as an exception.  If I push it
up my usual route, it will be a bit later.

I just now sent it out, so hopefully they will grab it.  ;-)


Hi Paul,

Either it fixes a zero-day bug which was exposed by 'rcu: Remove superfluous
versions ...", or it fixes a problem with that commit, so I would hope that
_someone_ will pick it up.

Anyway, thanks a lot for looking into it, and for the patch!

Guenter

Re: random(4) changes

[Theodore Ts'o]

On Sun, Apr 24, 2016 at 10:03:45AM +0200, Stephan Mueller wrote:
> 
> I agree here. The only challenge with the current implementation is the time 
> the fast_pool is to be mixed into an entropy pool. This requires a lock and 
> quite some code afterwards.

This only happens no more than once every 64 interrupts, and we don't
actually block waiting for the lock (we use a spin_trylock, and we
skip mixing to the next interrupt if it is locked).  I've done a lot
of careful benchmarking of the cycles used.

> When dropping the add_disk_randomness function in the legacy /dev/random, I 
> would assume that without changes to add_input_randomness and 
> add_interrupt_randomness, we become even more entropy-starved.

Sure, but your system isn't doing anything magical here.  The main
difference is that you assume you can get almost a full bit of entropy
out of each interrupt timing, where I'm much more conservative and
assume we can only get 1/64th of a bit out of each interrupt timing.
(e.g., that each interrupt event may have some complex correlation
that is more sophisticated than what a "stuck bit" detector might be
able to detect.)

Part of the reason why I've been very conservative here is because not
all ARM CPU's provide access to a high speed counter.  Using the IP
and other CPU registers as a stop-gap is not great, but it is better
than just using jiffies (which you seem to assume the /dev/random
driver is doing; this is not true, and this is one of the ways in
which the current system is better than your proposed LRNG, and why
I'm not really fond of major "rip and replace" patches --- it's likely
such a approach will end up making things worse for some systems, and
I don't true the ARM SOC or embedded/mobile vendors to chose the
kernel configuration sanely in terms of "should I use random number
generator 'A' or 'B' for my system?).


The other big difference is you aren't allowing anyone to extract from
the primary entropy pool (/dev/random) until it is has a chance to
fully initialize the /dev/urandom pool, which is a good thing to do,
and something that's not hard to do without doing a complete rip and
replace of the RNG.  So I'll look at adding that to the /dev/random driver.

Yet another difference which I've noticed as I've been going over the
patches is that that since it relies on CRYPTO_DRBG, it drags in a
fairly large portion of the crypto subsystem, and requires it to be
compiled into the kernel (instead of being loaded as needed as a
module).  So the people who are worrying about keeping the kernel on a
diet aren't going to be particularly happy about this.

I've thought about using a CRNG for the secondary pool, which would be
a lot smaller and faster as far as random number extraction.  But the
concern I have is that I don't want to drag in the whole generalized
crypto subsystem just for /dev/random.  If we make it too heavyweight,
then there will be pressure to make /dev/random optional, which would
mean that application programs can't depend on it and some device
manufacturers might be tempted to make it disappear for their kernels.

So my preference if we want to go down this path is to use a CRNG
based on something like Twofish, which is modern, still unbroken, and
is designed to be implemented efficiently in software in a small
amount (both in terms of text and data segments).  This would then
make it realtively efficient to use per-CPU CRNG's, in order to to
satisfy Andi Kleen's concern about making /dev/urandom efficient for
crazy programs that are trying to extract a huge amounts of data out
of /dev/urandom on a big multi-socket system.  And I would do this
with a hard-wired system that avoids dragging in the crypto system to
to keep the Linux tinification folks happy.

Cheers,

- Ted

Re: random(4) changes

[Theodore Ts'o]

On Sun, Apr 24, 2016 at 10:03:45AM +0200, Stephan Mueller wrote:
> 
> I agree here. The only challenge with the current implementation is the time 
> the fast_pool is to be mixed into an entropy pool. This requires a lock and 
> quite some code afterwards.

This only happens no more than once every 64 interrupts, and we don't
actually block waiting for the lock (we use a spin_trylock, and we
skip mixing to the next interrupt if it is locked).  I've done a lot
of careful benchmarking of the cycles used.

> When dropping the add_disk_randomness function in the legacy /dev/random, I 
> would assume that without changes to add_input_randomness and 
> add_interrupt_randomness, we become even more entropy-starved.

Sure, but your system isn't doing anything magical here.  The main
difference is that you assume you can get almost a full bit of entropy
out of each interrupt timing, where I'm much more conservative and
assume we can only get 1/64th of a bit out of each interrupt timing.
(e.g., that each interrupt event may have some complex correlation
that is more sophisticated than what a "stuck bit" detector might be
able to detect.)

Part of the reason why I've been very conservative here is because not
all ARM CPU's provide access to a high speed counter.  Using the IP
and other CPU registers as a stop-gap is not great, but it is better
than just using jiffies (which you seem to assume the /dev/random
driver is doing; this is not true, and this is one of the ways in
which the current system is better than your proposed LRNG, and why
I'm not really fond of major "rip and replace" patches --- it's likely
such a approach will end up making things worse for some systems, and
I don't true the ARM SOC or embedded/mobile vendors to chose the
kernel configuration sanely in terms of "should I use random number
generator 'A' or 'B' for my system?).


The other big difference is you aren't allowing anyone to extract from
the primary entropy pool (/dev/random) until it is has a chance to
fully initialize the /dev/urandom pool, which is a good thing to do,
and something that's not hard to do without doing a complete rip and
replace of the RNG.  So I'll look at adding that to the /dev/random driver.

Yet another difference which I've noticed as I've been going over the
patches is that that since it relies on CRYPTO_DRBG, it drags in a
fairly large portion of the crypto subsystem, and requires it to be
compiled into the kernel (instead of being loaded as needed as a
module).  So the people who are worrying about keeping the kernel on a
diet aren't going to be particularly happy about this.

I've thought about using a CRNG for the secondary pool, which would be
a lot smaller and faster as far as random number extraction.  But the
concern I have is that I don't want to drag in the whole generalized
crypto subsystem just for /dev/random.  If we make it too heavyweight,
then there will be pressure to make /dev/random optional, which would
mean that application programs can't depend on it and some device
manufacturers might be tempted to make it disappear for their kernels.

So my preference if we want to go down this path is to use a CRNG
based on something like Twofish, which is modern, still unbroken, and
is designed to be implemented efficiently in software in a small
amount (both in terms of text and data segments).  This would then
make it realtively efficient to use per-CPU CRNG's, in order to to
satisfy Andi Kleen's concern about making /dev/urandom efficient for
crazy programs that are trying to extract a huge amounts of data out
of /dev/urandom on a big multi-socket system.  And I would do this
with a hard-wired system that avoids dragging in the crypto system to
to keep the Linux tinification folks happy.

Cheers,

- Ted

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[Dave Chinner]

On Mon, Apr 25, 2016 at 06:45:08PM -0700, Dan Williams wrote:
> On Mon, Apr 25, 2016 at 5:11 PM, Dave Chinner  wrote:
> > On Mon, Apr 25, 2016 at 04:43:14PM -0700, Dan Williams wrote:
> [..]
> >> Maybe I missed something, but all these assumptions are already
> >> present for typical block devices, i.e. sectors may go bad and a write
> >> may make the sector usable again.
> >
> > The assumption we make about sectors going bad on SSDs or SRDs is
> > that the device is about to die and needs replacing ASAP.
> 
> Similar assumptions here.  Storage media is experiencing errors and
> past a certain threshold it may be time to decommission the device.
> 
> You can see definitions for SMART / media health commands from various
> vendors at these links, and yes, hopefully these are standardized /
> unified at some point down the road:
> 
> http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
> https://github.com/HewlettPackard/hpe-nvm/blob/master/Documentation/NFIT_DSM_DDR4_NVDIMM-N_v84s.pdf
> https://msdn.microsoft.com/en-us/library/windows/hardware/mt604717(v=vs.85).aspx
> 
> 
> > Then
> > RAID takes care of the rebuild completely transparently. i.e.
> > handling and correcting bad sectors is typically done completely
> > transparently /below/ the filesytem like so:
> 
> Again, same for an NVDIMM.  Use the pmem block-device as a RAID-member device.

Which means we're not using DAX and so the existing storage model
applies. I understand how this works.

What I'm asking about the redundancy/error correction model /when
using DAX/ and a userspace DAX load/store throws the MCE.

> > And somehow all the error information from the hardware layer needs
> > to be propagated up to the application layer, along with all the
> > mapping information from the filesystem and block layers for the
> > application to make sense of the hardware reported errors.
> >
> > I see assumptions this this "just works" but we don't have any of
> > the relevant APIs or infrastructure to enable the application to do
> > the hardware error->file+offset namespace mapping (i.e. filesystem
> > reverse mapping for for file offsets and directory paths, and
> > reverse mapping for the the block layer remapping drivers).
> 
> If an application expects errors to be handled beneath the filesystem
> then it should forgo DAX and arrange for the NVDIMM devices to be
> RAIDed.

See above: I'm asking about the DAX-enabled error handling model,
not the traditional error handling model.

> Otherwise, if an application wants to use DAX then it might
> need to be prepared to handle media errors itself same as the
> un-RAIDed disk case.  Yes, at an administrative level without
> reverse-mapping support from a filesystem there's presently no way to
> ask "which files on this fs are impacted by media errors", and we're
> aware that reverse-mapping capabilities are nascent for current
> DAX-aware filesystems.

Precisely my point - suggestions are being proposed which assume
use of infrastructure that *does not exist yet* and has not been
discussed or documented. If we're expecting such infrastructure to
be implemented in the filesystems and block device drivers, then we
need to determine that the error model actually works first...

> The forward lookup path, as impractical as it
> is for large numbers of files, is available if an application wanted
> to know if a specific file was impacted.  We've discussed possibly
> extending fiemap() to return bad blocks in a file rather than
> consulting sysfs, or extending lseek() with something like SEEK_ERROR
> to return offsets of bad areas in a file.

Via what infrastructure will the filesystem use for finding out
whether a file has bad blocks in it? And if the file does have bad
blocks, what are you expecting the filesystem to do with that
information?

> > I haven't seen any design/documentation for infrastructure at the
> > application layer to handle redundant data and correctly
> > transparently so I don't have any idea what the technical
> > requirements this different IO stack places on filesystems may be.
> > Hence I'm asking for some kind of architecture/design documentation
> > that I can read to understand exactly what is being proposed here...
> 
> I think this is a discussion for a solution that would build on top of
> this basic "here are the errors, re-write them with good data if you
> can; otherwise, best of luck" foundation.  Something like a DAX-aware
> device mapper layer that duplicates data tagged with REQ_META so at
> least we have a recovery path when a sector error lands in critical
> filesystem-metadata. 

Filesytsem metadata is not the topic of discussion here - it's
user data that throws an error on a DAX load/store that is the
issue.

> However, anything we come up with to make NVDIMM
> errors more survivable should be directly applicable to traditional
> disk storage as well.

I'm not sure it does. DAX implies that traditional block layer RAID
infrastructure is not 

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[Dave Chinner]

On Mon, Apr 25, 2016 at 06:45:08PM -0700, Dan Williams wrote:
> On Mon, Apr 25, 2016 at 5:11 PM, Dave Chinner  wrote:
> > On Mon, Apr 25, 2016 at 04:43:14PM -0700, Dan Williams wrote:
> [..]
> >> Maybe I missed something, but all these assumptions are already
> >> present for typical block devices, i.e. sectors may go bad and a write
> >> may make the sector usable again.
> >
> > The assumption we make about sectors going bad on SSDs or SRDs is
> > that the device is about to die and needs replacing ASAP.
> 
> Similar assumptions here.  Storage media is experiencing errors and
> past a certain threshold it may be time to decommission the device.
> 
> You can see definitions for SMART / media health commands from various
> vendors at these links, and yes, hopefully these are standardized /
> unified at some point down the road:
> 
> http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
> https://github.com/HewlettPackard/hpe-nvm/blob/master/Documentation/NFIT_DSM_DDR4_NVDIMM-N_v84s.pdf
> https://msdn.microsoft.com/en-us/library/windows/hardware/mt604717(v=vs.85).aspx
> 
> 
> > Then
> > RAID takes care of the rebuild completely transparently. i.e.
> > handling and correcting bad sectors is typically done completely
> > transparently /below/ the filesytem like so:
> 
> Again, same for an NVDIMM.  Use the pmem block-device as a RAID-member device.

Which means we're not using DAX and so the existing storage model
applies. I understand how this works.

What I'm asking about the redundancy/error correction model /when
using DAX/ and a userspace DAX load/store throws the MCE.

> > And somehow all the error information from the hardware layer needs
> > to be propagated up to the application layer, along with all the
> > mapping information from the filesystem and block layers for the
> > application to make sense of the hardware reported errors.
> >
> > I see assumptions this this "just works" but we don't have any of
> > the relevant APIs or infrastructure to enable the application to do
> > the hardware error->file+offset namespace mapping (i.e. filesystem
> > reverse mapping for for file offsets and directory paths, and
> > reverse mapping for the the block layer remapping drivers).
> 
> If an application expects errors to be handled beneath the filesystem
> then it should forgo DAX and arrange for the NVDIMM devices to be
> RAIDed.

See above: I'm asking about the DAX-enabled error handling model,
not the traditional error handling model.

> Otherwise, if an application wants to use DAX then it might
> need to be prepared to handle media errors itself same as the
> un-RAIDed disk case.  Yes, at an administrative level without
> reverse-mapping support from a filesystem there's presently no way to
> ask "which files on this fs are impacted by media errors", and we're
> aware that reverse-mapping capabilities are nascent for current
> DAX-aware filesystems.

Precisely my point - suggestions are being proposed which assume
use of infrastructure that *does not exist yet* and has not been
discussed or documented. If we're expecting such infrastructure to
be implemented in the filesystems and block device drivers, then we
need to determine that the error model actually works first...

> The forward lookup path, as impractical as it
> is for large numbers of files, is available if an application wanted
> to know if a specific file was impacted.  We've discussed possibly
> extending fiemap() to return bad blocks in a file rather than
> consulting sysfs, or extending lseek() with something like SEEK_ERROR
> to return offsets of bad areas in a file.

Via what infrastructure will the filesystem use for finding out
whether a file has bad blocks in it? And if the file does have bad
blocks, what are you expecting the filesystem to do with that
information?

> > I haven't seen any design/documentation for infrastructure at the
> > application layer to handle redundant data and correctly
> > transparently so I don't have any idea what the technical
> > requirements this different IO stack places on filesystems may be.
> > Hence I'm asking for some kind of architecture/design documentation
> > that I can read to understand exactly what is being proposed here...
> 
> I think this is a discussion for a solution that would build on top of
> this basic "here are the errors, re-write them with good data if you
> can; otherwise, best of luck" foundation.  Something like a DAX-aware
> device mapper layer that duplicates data tagged with REQ_META so at
> least we have a recovery path when a sector error lands in critical
> filesystem-metadata. 

Filesytsem metadata is not the topic of discussion here - it's
user data that throws an error on a DAX load/store that is the
issue.

> However, anything we come up with to make NVDIMM
> errors more survivable should be directly applicable to traditional
> disk storage as well.

I'm not sure it does. DAX implies that traditional block layer RAID
infrastructure is not possible, nor are 

[PATCH] drivers/input: Macros with complex values should be enclosed in parentheses

[Rui Teng]

The bitwise shift operator has lower priority than plus operator. So the values 
on macros
should be enclosed in parentheses.

For example, "(1 << 4 + 1)" means "(1 << (4 + 1))", but it is not expected by 
the macros.

And also fix other two coding style problems reported by scripts/checkpatch.pl.

Signed-off-by: Rui Teng 
---
 drivers/input/keyboard/twl4030_keypad.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/input/keyboard/twl4030_keypad.c 
b/drivers/input/keyboard/twl4030_keypad.c
index bbcccd6..8d061c0 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -61,9 +61,9 @@ struct twl4030_keypad {
unsigned short  keymap[TWL4030_KEYMAP_SIZE];
u16 kp_state[TWL4030_MAX_ROWS];
boolautorepeat;
-   unsignedn_rows;
-   unsignedn_cols;
-   unsignedirq;
+   unsigned intn_rows;
+   unsigned intn_cols;
+   unsigned intirq;
 
struct device *dbg_dev;
struct input_dev *input;
@@ -110,7 +110,7 @@ struct twl4030_keypad {
 #define KEYP_CTRL_KBD_ON   BIT(6)
 
 /* KEYP_DEB, KEYP_LONG_KEY, KEYP_TIMEOUT_x*/
-#define KEYP_PERIOD_US(t, prescale)((t) / (31 << (prescale + 1)) - 1)
+#define KEYP_PERIOD_US(t, prescale)((t) / (31 << ((prescale) + 1)) - 1)
 
 /* KEYP_LK_PTV_REG Fields */
 #define KEYP_LK_PTV_PTV_SHIFT  5
@@ -263,7 +263,8 @@ static irqreturn_t do_kp_irq(int irq, void *_kp)
ret = twl4030_kpread(kp, , KEYP_ISR1, 1);
 
/* Release all keys if I2C has gone bad or
-* the KEYP has gone to idle state */
+* the KEYP has gone to idle state
+*/
if (ret >= 0 && (reg & KEYP_IMR1_KP))
twl4030_kp_scan(kp, false);
else
-- 
2.5.0

[PATCH] drivers/input: Macros with complex values should be enclosed in parentheses

[Rui Teng]

The bitwise shift operator has lower priority than plus operator. So the values 
on macros
should be enclosed in parentheses.

For example, "(1 << 4 + 1)" means "(1 << (4 + 1))", but it is not expected by 
the macros.

And also fix other two coding style problems reported by scripts/checkpatch.pl.

Signed-off-by: Rui Teng 
---
 drivers/input/keyboard/twl4030_keypad.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/input/keyboard/twl4030_keypad.c 
b/drivers/input/keyboard/twl4030_keypad.c
index bbcccd6..8d061c0 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -61,9 +61,9 @@ struct twl4030_keypad {
unsigned short  keymap[TWL4030_KEYMAP_SIZE];
u16 kp_state[TWL4030_MAX_ROWS];
boolautorepeat;
-   unsignedn_rows;
-   unsignedn_cols;
-   unsignedirq;
+   unsigned intn_rows;
+   unsigned intn_cols;
+   unsigned intirq;
 
struct device *dbg_dev;
struct input_dev *input;
@@ -110,7 +110,7 @@ struct twl4030_keypad {
 #define KEYP_CTRL_KBD_ON   BIT(6)
 
 /* KEYP_DEB, KEYP_LONG_KEY, KEYP_TIMEOUT_x*/
-#define KEYP_PERIOD_US(t, prescale)((t) / (31 << (prescale + 1)) - 1)
+#define KEYP_PERIOD_US(t, prescale)((t) / (31 << ((prescale) + 1)) - 1)
 
 /* KEYP_LK_PTV_REG Fields */
 #define KEYP_LK_PTV_PTV_SHIFT  5
@@ -263,7 +263,8 @@ static irqreturn_t do_kp_irq(int irq, void *_kp)
ret = twl4030_kpread(kp, , KEYP_ISR1, 1);
 
/* Release all keys if I2C has gone bad or
-* the KEYP has gone to idle state */
+* the KEYP has gone to idle state
+*/
if (ret >= 0 && (reg & KEYP_IMR1_KP))
twl4030_kp_scan(kp, false);
else
-- 
2.5.0

Re: [PATCH v2 7/7] f2fs: should check the remaining dentry bits

[Jaegeuk Kim]

Change log from v1:
 o remove wron f2fs_bug_on()

>From 545c0c9055b0d8dc5d134d9340b3cd80eeecdafa Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Mon, 25 Apr 2016 14:24:44 -0700
Subject: [PATCH] f2fs: should check the remaining dentry bits

Let's consider a race condition between f2fs_add_regular_entry and
find_target_dentry.

1.
- f2fs_add_regular_entry updated len: 24 first.
   |
Bits:  0 0 0 1
Lens: 24 0 0 3 (name: foo)
   |->
- find_target_dentry checks the first bit to find "foo", then ++pointer.

2.
- f2fs_add_regular_entry updates bits.
   |>|>|
Bits:  1 1 1 1
Lens: 24 0 0 3 (name: foo)
 |
- find_target_dentry is checking second bit, but it's len is zero, which
makes the process being terminated.

In this case, user can add additional dentry named "foo" accordingly.
This patch enables to check the remaining bits.

Signed-off-by: He YunLei 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/dir.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index e90380d..0ad7b9a 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -100,12 +100,6 @@ static struct f2fs_dir_entry *find_in_block(struct page 
*dentry_page,
*res_page = dentry_page;
else
kunmap(dentry_page);
-
-   /*
-* For the most part, it should be a bug when name_len is zero.
-* We stop here for figuring out where the bugs has occurred.
-*/
-   f2fs_bug_on(F2FS_P_SB(dentry_page), d.max < 0);
return de;
 }
 
@@ -149,9 +143,9 @@ struct f2fs_dir_entry *find_target_dentry(struct 
fscrypt_name *fname,
 
/* remain bug on condition */
if (unlikely(!de->name_len))
-   d->max = -1;
-
-   bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
+   bit_pos++;
+   else
+   bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
}
 
de = NULL;
-- 
2.6.3

Re: [PATCH v2 7/7] f2fs: should check the remaining dentry bits

[Jaegeuk Kim]

Change log from v1:
 o remove wron f2fs_bug_on()

>From 545c0c9055b0d8dc5d134d9340b3cd80eeecdafa Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Mon, 25 Apr 2016 14:24:44 -0700
Subject: [PATCH] f2fs: should check the remaining dentry bits

Let's consider a race condition between f2fs_add_regular_entry and
find_target_dentry.

1.
- f2fs_add_regular_entry updated len: 24 first.
   |
Bits:  0 0 0 1
Lens: 24 0 0 3 (name: foo)
   |->
- find_target_dentry checks the first bit to find "foo", then ++pointer.

2.
- f2fs_add_regular_entry updates bits.
   |>|>|
Bits:  1 1 1 1
Lens: 24 0 0 3 (name: foo)
 |
- find_target_dentry is checking second bit, but it's len is zero, which
makes the process being terminated.

In this case, user can add additional dentry named "foo" accordingly.
This patch enables to check the remaining bits.

Signed-off-by: He YunLei 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/dir.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index e90380d..0ad7b9a 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -100,12 +100,6 @@ static struct f2fs_dir_entry *find_in_block(struct page 
*dentry_page,
*res_page = dentry_page;
else
kunmap(dentry_page);
-
-   /*
-* For the most part, it should be a bug when name_len is zero.
-* We stop here for figuring out where the bugs has occurred.
-*/
-   f2fs_bug_on(F2FS_P_SB(dentry_page), d.max < 0);
return de;
 }
 
@@ -149,9 +143,9 @@ struct f2fs_dir_entry *find_target_dentry(struct 
fscrypt_name *fname,
 
/* remain bug on condition */
if (unlikely(!de->name_len))
-   d->max = -1;
-
-   bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
+   bit_pos++;
+   else
+   bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
}
 
de = NULL;
-- 
2.6.3

RE: [v8, 1/7] Documentation: DT: update Freescale DCFG compatible

[Yangbo Lu]

Hi Mark,


> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Friday, April 22, 2016 9:12 PM
> To: Yangbo Lu
> Cc: linux-...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> i...@vger.kernel.org; io...@lists.linux-foundation.org;
> net...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Zhao Qiang; Kumar Gala; Santosh Shilimkar; Yang-Leo Li; Xiaobo
> Xie
> Subject: Re: [v8, 1/7] Documentation: DT: update Freescale DCFG
> compatible
> 
> On Fri, Apr 22, 2016 at 02:27:38PM +0800, Yangbo Lu wrote:
> > Update Freescale DCFG compatible with 'fsl,-dcfg' instead of
> > 'fsl,ls1021a-dcfg' to include more chips.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> > Changes for v8:
> > - Added this patch
> > ---
> >  Documentation/devicetree/bindings/arm/fsl.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
> > b/Documentation/devicetree/bindings/arm/fsl.txt
> > index 752a685..1d5f512 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.txt
> > +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> > @@ -119,7 +119,7 @@ Freescale DCFG
> >  configuration and status for the device. Such as setting the
> > secondary  core start address and release the secondary core from
> holdoff and startup.
> >Required properties:
> > -  - compatible: should be "fsl,ls1021a-dcfg"
> > +  - compatible: should be "fsl,-dcfg"
> 
> Please list specific values expected for , while jusy saying 
> may be more generic, it makes it practically impossible to search for the
> correct binding given a compatible string, and it's vague as to exaclty
> what  should be.

[Lu Yangbo-B47093] Thanks for your comment. I will list the possible chips.

> 
> Thanks,
> Mark.
> 
> 
> 
> >- reg : should contain base address and length of DCFG
> > memory-mapped registers
> >
> >  Example:
> > --
> > 2.1.0.27.g96db324
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >

RE: [v8, 1/7] Documentation: DT: update Freescale DCFG compatible

[Yangbo Lu]

Hi Mark,


> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Friday, April 22, 2016 9:12 PM
> To: Yangbo Lu
> Cc: linux-...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> i...@vger.kernel.org; io...@lists.linux-foundation.org;
> net...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Zhao Qiang; Kumar Gala; Santosh Shilimkar; Yang-Leo Li; Xiaobo
> Xie
> Subject: Re: [v8, 1/7] Documentation: DT: update Freescale DCFG
> compatible
> 
> On Fri, Apr 22, 2016 at 02:27:38PM +0800, Yangbo Lu wrote:
> > Update Freescale DCFG compatible with 'fsl,-dcfg' instead of
> > 'fsl,ls1021a-dcfg' to include more chips.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> > Changes for v8:
> > - Added this patch
> > ---
> >  Documentation/devicetree/bindings/arm/fsl.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
> > b/Documentation/devicetree/bindings/arm/fsl.txt
> > index 752a685..1d5f512 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.txt
> > +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> > @@ -119,7 +119,7 @@ Freescale DCFG
> >  configuration and status for the device. Such as setting the
> > secondary  core start address and release the secondary core from
> holdoff and startup.
> >Required properties:
> > -  - compatible: should be "fsl,ls1021a-dcfg"
> > +  - compatible: should be "fsl,-dcfg"
> 
> Please list specific values expected for , while jusy saying 
> may be more generic, it makes it practically impossible to search for the
> correct binding given a compatible string, and it's vague as to exaclty
> what  should be.

[Lu Yangbo-B47093] Thanks for your comment. I will list the possible chips.

> 
> Thanks,
> Mark.
> 
> 
> 
> >- reg : should contain base address and length of DCFG
> > memory-mapped registers
> >
> >  Example:
> > --
> > 2.1.0.27.g96db324
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >

Re: [PATCH 2/2] mountinfo: implement show_path for kernfs and cgroup

[Serge E. Hallyn]

Quoting Serge E. Hallyn (se...@hallyn.com):
> Quoting Serge E. Hallyn (se...@hallyn.com):
> > Quoting Eric W. Biederman (ebied...@xmission.com):
> > > "Serge E. Hallyn"  writes:
> > > 
> > > >> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> > > >> index 671dc05..9a0d7b3 100644
> > > >> --- a/kernel/cgroup.c
> > > >> +++ b/kernel/cgroup.c
> > > >> @@ -1593,6 +1593,40 @@ static int rebind_subsystems(struct cgroup_root 
> > > >> *dst_root, u16 ss_mask)
> > > >>return 0;
> > > >>  }
> > > >>  
> > > >> +static int cgroup_show_path(struct seq_file *sf, struct kernfs_node 
> > > >> *kf_node,
> > > >> +  struct kernfs_root *kf_root)
> > > >> +{
> > > >> +  int len = 0, ret = 0;
> > > >> +  char *buf = NULL;
> > > >> +  struct cgroup_namespace *ns = current->nsproxy->cgroup_ns;
> > > >> +  struct cgroup_root *kf_cgroot = cgroup_root_from_kf(kf_root);
> > > >> +  struct cgroup *ns_cgroup;
> > > >> +
> > > >> +  mutex_lock(_mutex);
> > > >
> > > > Hm, I can't grab the cgroup mutex here because I already have the
> > > > namespace_sem.  But that's required by cset_cgroup_from_root().  Can
> > > > I just call that under rcu_read_lock() instead?  (Not without
> > > > changing the lockdep_assert_help()).  Is there another way to get the
> > > > info needed here?
> > > 
> > > Do we need the current cgroup namespace information at all?
> > > 
> > > Could we not get the relevant cgroup namespace from the mount of
> > > cgroupfs?
> > 
> > I don't think so.  That was my first inclination.  But at show_path()
> > all we have is the vfsmunt->mnt_root.  Since all cgroup namespaces
> > for a hierarchy share the same dentry tree and superblock, there's
> > no way to tell where the mount's namespace root is supposed to be.
> > 
> > whether we did
> > 
> > # enter new cgroup namespace rooted at cgroup /user.slice/user-1000.slice
> > mount -t cgroup -o freezer freezer /mnt
> > 
> > or
> > 
> > mount --bind /sys/fs/cgroup/freezer/user.slice/user-1000.slice /mnt
> > 
> > the mountinfo entry will be the same.
> > 
> > > In general the better path is not to have the contents of files depend on
> > > who is reading the file.
> 
> And actually, while as i said above this was my first inclination, I now
> think that's wrong.  /proc/$$/cgroup is virtualized per the reader.  The
> point of this patch is to make mountinfo virtualized analogously to
> /proc/$$/cgroup, so that we can be certain how a particular cgroup dentry
> relates to a task's actual cgroup.  So the mountinfo dentry root path
> should in fact depend on the reader.
> 
> Looking at it another way...  The value we're talking about shows us
> the path of the root dentry of a cgroup mount.  If a task in cgns2
> rooted at /a/b/c mounts a cgroupfs, it will see '/' as the root dentry.
> If a task in cgns1 rooted at /a/b looks at that mountinfo, '/' would
> be misleading.  It really should be '/c'.

So I think that for cgroup mount entries in mountinfo to be useful (i.e.
to criu) we either need the root dentry path to be given as relative to
the reader's cgroup namespace (as I have it in this patchset), or else
we need to add another piece of information in the mountinfo entry, such
as the nsfd inode number of the cgroup namespace in which it was
mounted.

-serge

Re: [PATCH 2/2] mountinfo: implement show_path for kernfs and cgroup

[Serge E. Hallyn]

Quoting Serge E. Hallyn (se...@hallyn.com):
> Quoting Serge E. Hallyn (se...@hallyn.com):
> > Quoting Eric W. Biederman (ebied...@xmission.com):
> > > "Serge E. Hallyn"  writes:
> > > 
> > > >> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> > > >> index 671dc05..9a0d7b3 100644
> > > >> --- a/kernel/cgroup.c
> > > >> +++ b/kernel/cgroup.c
> > > >> @@ -1593,6 +1593,40 @@ static int rebind_subsystems(struct cgroup_root 
> > > >> *dst_root, u16 ss_mask)
> > > >>return 0;
> > > >>  }
> > > >>  
> > > >> +static int cgroup_show_path(struct seq_file *sf, struct kernfs_node 
> > > >> *kf_node,
> > > >> +  struct kernfs_root *kf_root)
> > > >> +{
> > > >> +  int len = 0, ret = 0;
> > > >> +  char *buf = NULL;
> > > >> +  struct cgroup_namespace *ns = current->nsproxy->cgroup_ns;
> > > >> +  struct cgroup_root *kf_cgroot = cgroup_root_from_kf(kf_root);
> > > >> +  struct cgroup *ns_cgroup;
> > > >> +
> > > >> +  mutex_lock(_mutex);
> > > >
> > > > Hm, I can't grab the cgroup mutex here because I already have the
> > > > namespace_sem.  But that's required by cset_cgroup_from_root().  Can
> > > > I just call that under rcu_read_lock() instead?  (Not without
> > > > changing the lockdep_assert_help()).  Is there another way to get the
> > > > info needed here?
> > > 
> > > Do we need the current cgroup namespace information at all?
> > > 
> > > Could we not get the relevant cgroup namespace from the mount of
> > > cgroupfs?
> > 
> > I don't think so.  That was my first inclination.  But at show_path()
> > all we have is the vfsmunt->mnt_root.  Since all cgroup namespaces
> > for a hierarchy share the same dentry tree and superblock, there's
> > no way to tell where the mount's namespace root is supposed to be.
> > 
> > whether we did
> > 
> > # enter new cgroup namespace rooted at cgroup /user.slice/user-1000.slice
> > mount -t cgroup -o freezer freezer /mnt
> > 
> > or
> > 
> > mount --bind /sys/fs/cgroup/freezer/user.slice/user-1000.slice /mnt
> > 
> > the mountinfo entry will be the same.
> > 
> > > In general the better path is not to have the contents of files depend on
> > > who is reading the file.
> 
> And actually, while as i said above this was my first inclination, I now
> think that's wrong.  /proc/$$/cgroup is virtualized per the reader.  The
> point of this patch is to make mountinfo virtualized analogously to
> /proc/$$/cgroup, so that we can be certain how a particular cgroup dentry
> relates to a task's actual cgroup.  So the mountinfo dentry root path
> should in fact depend on the reader.
> 
> Looking at it another way...  The value we're talking about shows us
> the path of the root dentry of a cgroup mount.  If a task in cgns2
> rooted at /a/b/c mounts a cgroupfs, it will see '/' as the root dentry.
> If a task in cgns1 rooted at /a/b looks at that mountinfo, '/' would
> be misleading.  It really should be '/c'.

So I think that for cgroup mount entries in mountinfo to be useful (i.e.
to criu) we either need the root dentry path to be given as relative to
the reader's cgroup namespace (as I have it in this patchset), or else
we need to add another piece of information in the mountinfo entry, such
as the nsfd inode number of the cgroup namespace in which it was
mounted.

-serge

[PATCH v3 0/4] ARM64: dts: rockchip: add support for RK3399

[Jianqun Xu]

Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb.

To make patch more easily to be reviewed, some nodes have been removed
temporarily, after this base file been applied, more patches will be
upstreamed independently.

Jianqun Xu (3):
  ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
  Documentation: devicetree: rockchip: Document rk3399-evb
  ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Shawn Lin (1):
  Documentation: rockchip-dw-mshc: add description for rk3399

 Documentation/devicetree/bindings/arm/rockchip.txt |6 +-
 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |1 +
 arch/arm64/boot/dts/rockchip/Makefile  |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts|  125 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 1022 
 5 files changed, 1154 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

--
changes in v3:
- modify title for patch 3/4 (Brian)
- add more compatible for evb dts (Doug)

changes in v2:
- split into more patches. (Heiko)
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- add rockchip-dw-mshc binding patch
- add rockchip,rk3399-evb binding patch
- fix codingstyle issues

1.9.1

Re: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU

[Andrew Morton]

On Mon, 25 Apr 2016 20:47:45 -0400 Rich Felker  wrote:

> On Mon, Apr 25, 2016 at 08:41:24PM -0400, Rich Felker wrote:
> > On Mon, Apr 25, 2016 at 05:09:09PM -0700, Andrew Morton wrote:
> > > On Fri, 22 Apr 2016 18:19:44 -0400 Rich Felker  wrote:
> > > 
> > > > Subject: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU
> > > 
> > > I take it that "ramfs" was intended here.
> > 
> > They're two names for the same thing; I'm not sure which should be
> > preferred.
> 
> Or maybe not... the relationship seems more complex, at least
> hisorically, but the ramfs code here is what seems to provide the
> backing for tmpfs (and maybe more?). Sorry for the quick and imprecise
> reply.

I am a simple soul.

Subject: tmpfs/ramfs: fix VM_MAYSHARE mappings for NOMMU

[PATCH 3/4] Documentation: devicetree: rockchip: Document rk3399-evb

[Jianqun Xu]

Use "rockchip,rk3399-evb" compatible string for Rockchip RK3399
evaluation board.

Acked-by: Rob Herring 
Signed-off-by: Jianqun Xu 
---
changes in v3:
- modify title (Rob)

 Documentation/devicetree/bindings/arm/rockchip.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 2549519..6491b56 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -101,4 +101,8 @@ Rockchip platforms device tree bindings
 
 - Rockchip RK3228 Evaluation board:
 Required root node properties:
-  - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+ - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+
+- Rockchip RK3399 evb:
+Required root node properties:
+  - compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
-- 
1.9.1

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

[Martin K. Petersen]

> "Josh" == Josh Poimboeuf  writes:

Josh> Can you merge this patch for 4.6?

I am really not a big fan of working around compiler bugs in a device
driver.

Are we sure there are no other get_unaligned_be64() calls in the kernel
that suffer the same fate?

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

[Martin K. Petersen]

> "Josh" == Josh Poimboeuf  writes:

Josh> Can you merge this patch for 4.6?

I am really not a big fan of working around compiler bugs in a device
driver.

Are we sure there are no other get_unaligned_be64() calls in the kernel
that suffer the same fate?

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v3 0/4] ARM64: dts: rockchip: add support for RK3399

[Jianqun Xu]

Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb.

To make patch more easily to be reviewed, some nodes have been removed
temporarily, after this base file been applied, more patches will be
upstreamed independently.

Jianqun Xu (3):
  ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
  Documentation: devicetree: rockchip: Document rk3399-evb
  ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Shawn Lin (1):
  Documentation: rockchip-dw-mshc: add description for rk3399

 Documentation/devicetree/bindings/arm/rockchip.txt |6 +-
 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |1 +
 arch/arm64/boot/dts/rockchip/Makefile  |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts|  125 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 1022 
 5 files changed, 1154 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

--
changes in v3:
- modify title for patch 3/4 (Brian)
- add more compatible for evb dts (Doug)

changes in v2:
- split into more patches. (Heiko)
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- add rockchip-dw-mshc binding patch
- add rockchip,rk3399-evb binding patch
- fix codingstyle issues

1.9.1

Re: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU

[Andrew Morton]

On Mon, 25 Apr 2016 20:47:45 -0400 Rich Felker  wrote:

> On Mon, Apr 25, 2016 at 08:41:24PM -0400, Rich Felker wrote:
> > On Mon, Apr 25, 2016 at 05:09:09PM -0700, Andrew Morton wrote:
> > > On Fri, 22 Apr 2016 18:19:44 -0400 Rich Felker  wrote:
> > > 
> > > > Subject: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU
> > > 
> > > I take it that "ramfs" was intended here.
> > 
> > They're two names for the same thing; I'm not sure which should be
> > preferred.
> 
> Or maybe not... the relationship seems more complex, at least
> hisorically, but the ramfs code here is what seems to provide the
> backing for tmpfs (and maybe more?). Sorry for the quick and imprecise
> reply.

I am a simple soul.

Subject: tmpfs/ramfs: fix VM_MAYSHARE mappings for NOMMU

[PATCH 3/4] Documentation: devicetree: rockchip: Document rk3399-evb

[Jianqun Xu]

Use "rockchip,rk3399-evb" compatible string for Rockchip RK3399
evaluation board.

Acked-by: Rob Herring 
Signed-off-by: Jianqun Xu 
---
changes in v3:
- modify title (Rob)

 Documentation/devicetree/bindings/arm/rockchip.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 2549519..6491b56 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -101,4 +101,8 @@ Rockchip platforms device tree bindings
 
 - Rockchip RK3228 Evaluation board:
 Required root node properties:
-  - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+ - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+
+- Rockchip RK3399 evb:
+Required root node properties:
+  - compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
-- 
1.9.1

[PATCH 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

[Jianqun Xu]

This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v3:
- add more compatible (Doug)
- add modle

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 125 
 2 files changed, 126 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..c3370bd
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,125 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Evaluation Board";
+   compatible = "rockchip,rk3399-evb", "rockchip,rk3399",
+"google,rk3399evb-rev2", google,rk3399evb-rev1",
+"google,rk3399evb-rev0" ;
+
+   vdd_center: vdd-center {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_center";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   status = "okay";
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host0_ohci {
+   status = "okay";
+};
+
+_host1_ehci {
+   status = "okay";
+};
+
+_host1_ohci {
+   status = "okay";
+};
+
+ {
+   pmic {
+   pmic_int_l: pmic-int-l {
+   rockchip,pins =
+   <1 21 RK_FUNC_GPIO _pull_up>;
+   };
+
+   pmic_dvs2: pmic-dvs2 {
+   rockchip,pins =
+

[PATCH v3 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for Rockchip RK3399 SoCs.

The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.

Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182

and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition

And it has been tested on RK3399 evb and works well.

Tested-by: Brian Norris 
Signed-off-by: Jianqun Xu 
---
changes in v3:
- tested irq/percpu-partition patches and worked well (huangtao)
- tested by Brian

changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
 1 file changed, 1022 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   

[PATCH 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

[Jianqun Xu]

This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v3:
- add more compatible (Doug)
- add modle

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 125 
 2 files changed, 126 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..c3370bd
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,125 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Evaluation Board";
+   compatible = "rockchip,rk3399-evb", "rockchip,rk3399",
+"google,rk3399evb-rev2", google,rk3399evb-rev1",
+"google,rk3399evb-rev0" ;
+
+   vdd_center: vdd-center {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_center";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   status = "okay";
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host0_ohci {
+   status = "okay";
+};
+
+_host1_ehci {
+   status = "okay";
+};
+
+_host1_ohci {
+   status = "okay";
+};
+
+ {
+   pmic {
+   pmic_int_l: pmic-int-l {
+   rockchip,pins =
+   <1 21 RK_FUNC_GPIO _pull_up>;
+   };
+
+   pmic_dvs2: pmic-dvs2 {
+   rockchip,pins =
+   <1 18 

[PATCH v3 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for Rockchip RK3399 SoCs.

The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.

Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182

and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition

And it has been tested on RK3399 evb and works well.

Tested-by: Brian Norris 
Signed-off-by: Jianqun Xu 
---
changes in v3:
- tested irq/percpu-partition patches and worked well (huangtao)
- tested by Brian

changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
 1 file changed, 1022 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+

[PATCH v3 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

[Jianqun Xu]

From: Shawn Lin 

Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for
dwmmc on rk3399 platform.

Acked-by: Rob Herring 
Signed-off-by: Shawn Lin 
Signed-off-by: Jianqun Xu 
---
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index ea5614b..07184e8 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -15,6 +15,7 @@ Required Properties:
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3368
+   - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3399
 
 Optional Properties:
 * clocks: from common clock binding: if ciu_drive and ciu_sample are
-- 
1.9.1

[PATCH v3 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

[Jianqun Xu]

From: Shawn Lin 

Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for
dwmmc on rk3399 platform.

Acked-by: Rob Herring 
Signed-off-by: Shawn Lin 
Signed-off-by: Jianqun Xu 
---
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index ea5614b..07184e8 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -15,6 +15,7 @@ Required Properties:
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3368
+   - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3399
 
 Optional Properties:
 * clocks: from common clock binding: if ciu_drive and ciu_sample are
-- 
1.9.1

[PATCH] ps3_gelic: fix memcpy parameter

[Christophe JAILLET]

The size allocated for target->hwinfo and the number of bytes copied in it
should be consistent.

Signed-off-by: Christophe JAILLET 
---
Untested

 drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c 
b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
index 13214a6..743b182 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
@@ -1622,7 +1622,7 @@ static void gelic_wl_scan_complete_event(struct 
gelic_wl_info *wl)
continue;
 
/* copy hw scan info */
-   memcpy(target->hwinfo, scan_info, scan_info->size);
+   memcpy(target->hwinfo, scan_info, be16_to_cpu(scan_info->size));
target->essid_len = strnlen(scan_info->essid,
sizeof(scan_info->essid));
target->rate_len = 0;
-- 
2.7.4

[PATCH] ps3_gelic: fix memcpy parameter

[Christophe JAILLET]

The size allocated for target->hwinfo and the number of bytes copied in it
should be consistent.

Signed-off-by: Christophe JAILLET 
---
Untested

 drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c 
b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
index 13214a6..743b182 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
@@ -1622,7 +1622,7 @@ static void gelic_wl_scan_complete_event(struct 
gelic_wl_info *wl)
continue;
 
/* copy hw scan info */
-   memcpy(target->hwinfo, scan_info, scan_info->size);
+   memcpy(target->hwinfo, scan_info, be16_to_cpu(scan_info->size));
target->essid_len = strnlen(scan_info->essid,
sizeof(scan_info->essid));
target->rate_len = 0;
-- 
2.7.4