Re: [RFC PATCH] kbuild: Fix asm-offset generation to work with clang

[Masahiro Yamada]

Hi Matthias,


2017-04-14 9:37 GMT+09:00 Matthias Kaehlcke :
> El Tue, Apr 11, 2017 at 11:03:54AM -0700 Matthias Kaehlcke ha dit:
>
>> El Tue, Apr 11, 2017 at 09:01:41PM +0900 Masahiro Yamada ha dit:
>>
>> > 2017-04-04 6:25 GMT+09:00 Matthias Kaehlcke :
>> > > When using clang with -no-integerated-as clang will use the gnu
>> > > assembler instead of the integrated assembler. However clang will
>> > > still perform asm error checking before sending the inline assembly
>> > > language to gas.
>> > >
>> > > The generation of asm-offsets from within C code is dependent on gcc's
>> > > blind passing of whatever is in asm() through to gas. Arbirary text is
>> > > passed through which is then modified by a sed script into the
>> > > appropriate .h and .S code. Since the arbitrary text is not valid
>> > > assembly language, clang fails.
>> > >
>> > > This can be fixed by making the arbitrary text into an ASM comment and
>> > > then updating the sed scripts accordingly to work as expected.
>> > >
>> > > This solution works for both gcc and clang.
>> > >
>> > > Based-on-patch-from: Behan Webster 
>> > > Signed-off-by: Matthias Kaehlcke 
>> >
>> >
>> >
>> > Could you check Jeroen Hofstee's work for U-Boot?
>> >
>> > http://patchwork.ozlabs.org/patch/375026/
>>
>> No I didn't come across it, thanks for the pointer!
>>
>> > His idea is to use .ascii string
>> > in order to handle this in arch-agnostic way.
>>
>> Looks good, way cleaner than my proposed solution :)
>>
>> > If you are happy about this idea,
>> > I can forward his patch (with a little bit adjustment).
>>
>> With forward you mean you plan to port it? Otherwise I'm also happy to
>> give it a go, just let me know.
>>
>> > We may want to refactor the patch because
>> > the double mark ".ascii" and "->" seem redundant,
>> > but it is just a detail.
>>
>> Agree, since we are already touching this part we might as well remove
>> the "->".
>
> Thinking about it a bit more it seems safer to keep the "->" since
> the input file might contain actual ".ascii" directives.


I am not sure about this, but I do not have a strong option, either.

OK. I am keeping both .ascii and -> just in case.

https://patchwork.kernel.org/patch/9680709/


-- 
Best Regards
Masahiro Yamada

Re: [RFC PATCH] kbuild: Fix asm-offset generation to work with clang

[Masahiro Yamada]

Hi Matthias,


2017-04-14 9:37 GMT+09:00 Matthias Kaehlcke :
> El Tue, Apr 11, 2017 at 11:03:54AM -0700 Matthias Kaehlcke ha dit:
>
>> El Tue, Apr 11, 2017 at 09:01:41PM +0900 Masahiro Yamada ha dit:
>>
>> > 2017-04-04 6:25 GMT+09:00 Matthias Kaehlcke :
>> > > When using clang with -no-integerated-as clang will use the gnu
>> > > assembler instead of the integrated assembler. However clang will
>> > > still perform asm error checking before sending the inline assembly
>> > > language to gas.
>> > >
>> > > The generation of asm-offsets from within C code is dependent on gcc's
>> > > blind passing of whatever is in asm() through to gas. Arbirary text is
>> > > passed through which is then modified by a sed script into the
>> > > appropriate .h and .S code. Since the arbitrary text is not valid
>> > > assembly language, clang fails.
>> > >
>> > > This can be fixed by making the arbitrary text into an ASM comment and
>> > > then updating the sed scripts accordingly to work as expected.
>> > >
>> > > This solution works for both gcc and clang.
>> > >
>> > > Based-on-patch-from: Behan Webster 
>> > > Signed-off-by: Matthias Kaehlcke 
>> >
>> >
>> >
>> > Could you check Jeroen Hofstee's work for U-Boot?
>> >
>> > http://patchwork.ozlabs.org/patch/375026/
>>
>> No I didn't come across it, thanks for the pointer!
>>
>> > His idea is to use .ascii string
>> > in order to handle this in arch-agnostic way.
>>
>> Looks good, way cleaner than my proposed solution :)
>>
>> > If you are happy about this idea,
>> > I can forward his patch (with a little bit adjustment).
>>
>> With forward you mean you plan to port it? Otherwise I'm also happy to
>> give it a go, just let me know.
>>
>> > We may want to refactor the patch because
>> > the double mark ".ascii" and "->" seem redundant,
>> > but it is just a detail.
>>
>> Agree, since we are already touching this part we might as well remove
>> the "->".
>
> Thinking about it a bit more it seems safer to keep the "->" since
> the input file might contain actual ".ascii" directives.


I am not sure about this, but I do not have a strong option, either.

OK. I am keeping both .ascii and -> just in case.

https://patchwork.kernel.org/patch/9680709/


-- 
Best Regards
Masahiro Yamada

[PATCH 2/2] kbuild: fix asm-offset generation to work with clang

[Masahiro Yamada]

From: Jeroen Hofstee 

KBuild abuses the asm statement to write to a file and
clang chokes about these invalid asm statements. Hack it
even more by fooling this is actual valid asm code.

Signed-off-by: Jeroen Hofstee 
[masahiro:
 Import Jeroen's work for U-Boot:
 http://patchwork.ozlabs.org/patch/375026/
 Tweak sed script a little to drop garbage '#' for GCC case, like
 #define NR_PAGEFLAGS 23 /* __NR_PAGEFLAGS   # */ ]
Signed-off-by: Masahiro Yamada 

---

 include/linux/kbuild.h | 6 +++---
 scripts/Makefile.lib   | 5 +++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/kbuild.h b/include/linux/kbuild.h
index 22a7219..4e80f3a 100644
--- a/include/linux/kbuild.h
+++ b/include/linux/kbuild.h
@@ -2,14 +2,14 @@
 #define __LINUX_KBUILD_H
 
 #define DEFINE(sym, val) \
-asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+   asm volatile("\n.ascii \"->" #sym " %0 " #val "\"" : : "i" (val))
 
-#define BLANK() asm volatile("\n->" : : )
+#define BLANK() asm volatile("\n.ascii \"->\"" : : )
 
 #define OFFSET(sym, str, mem) \
DEFINE(sym, offsetof(struct str, mem))
 
 #define COMMENT(x) \
-   asm volatile("\n->#" x)
+   asm volatile("\n.ascii \"->#" x "\"")
 
 #endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9c20690..a050859 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -414,9 +414,10 @@ cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
 
 # Default sed regexp - multiline due to syntax constraints
 define sed-offsets
-   "/^->/{s:->#\(.*\):/* \1 */:; \
+   's:^\.ascii *"\(.*\)".*:\1:; \
+   /^->/{s:->#\(.*\):/* \1 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
-   s:->::; p;}"
+   s:->::; p;}'
 endef
 
 # Use filechk to avoid rebuilds when a header changes, but the resulting file
-- 
2.7.4

[PATCH 2/2] kbuild: fix asm-offset generation to work with clang

[Masahiro Yamada]

From: Jeroen Hofstee 

KBuild abuses the asm statement to write to a file and
clang chokes about these invalid asm statements. Hack it
even more by fooling this is actual valid asm code.

Signed-off-by: Jeroen Hofstee 
[masahiro:
 Import Jeroen's work for U-Boot:
 http://patchwork.ozlabs.org/patch/375026/
 Tweak sed script a little to drop garbage '#' for GCC case, like
 #define NR_PAGEFLAGS 23 /* __NR_PAGEFLAGS   # */ ]
Signed-off-by: Masahiro Yamada 

---

 include/linux/kbuild.h | 6 +++---
 scripts/Makefile.lib   | 5 +++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/kbuild.h b/include/linux/kbuild.h
index 22a7219..4e80f3a 100644
--- a/include/linux/kbuild.h
+++ b/include/linux/kbuild.h
@@ -2,14 +2,14 @@
 #define __LINUX_KBUILD_H
 
 #define DEFINE(sym, val) \
-asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+   asm volatile("\n.ascii \"->" #sym " %0 " #val "\"" : : "i" (val))
 
-#define BLANK() asm volatile("\n->" : : )
+#define BLANK() asm volatile("\n.ascii \"->\"" : : )
 
 #define OFFSET(sym, str, mem) \
DEFINE(sym, offsetof(struct str, mem))
 
 #define COMMENT(x) \
-   asm volatile("\n->#" x)
+   asm volatile("\n.ascii \"->#" x "\"")
 
 #endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9c20690..a050859 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -414,9 +414,10 @@ cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
 
 # Default sed regexp - multiline due to syntax constraints
 define sed-offsets
-   "/^->/{s:->#\(.*\):/* \1 */:; \
+   's:^\.ascii *"\(.*\)".*:\1:; \
+   /^->/{s:->#\(.*\):/* \1 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
-   s:->::; p;}"
+   s:->::; p;}'
 endef
 
 # Use filechk to avoid rebuilds when a header changes, but the resulting file
-- 
2.7.4

[PATCH 0/2] kbuild: cleanup asm-offset generation, and make it work with clang

[Masahiro Yamada]

1/2 is a trivial cleanup of sed script
2/2 imports clang work-around from U-Boot.


Jeroen Hofstee (1):
  kbuild: fix asm-offset generation to work with clang

Masahiro Yamada (1):
  kbuild: consolidate redundant sed script ASM offset generation

 include/linux/kbuild.h | 6 +++---
 scripts/Makefile.lib   | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH 1/2] kbuild: consolidate redundant sed script ASM offset generation

[Masahiro Yamada]

This part ended up in redundant code after touched by multiple
people.

[1] Commit 3234282f33b2 ("x86, asm: Fix CFI macro invocations to
deal with shortcomings in gas") added parentheses for defined
expressions to support old gas for x86.

[2] Commit a22dcdb0032c ("x86, asm: Fix ancient-GAS workaround")
split the pattern into two to avoid parentheses for non-numeric
expressions.

[3] Commit 95a2f6f72d37 ("Partially revert patch that encloses
asm-offset.h numbers in brackets") removed parentheses from numeric
expressions as well because parentheses in MN10300 assembly have a
special meaning (pointer access).

Apparently, there is a conflict between [1] and [3].  After all,
[3] took precedence, and a long time has passed since then.

Now, merge the two patterns again because the first one is covered
by the other.

Signed-off-by: Masahiro Yamada 
---

 scripts/Makefile.lib | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index e36427a..9c20690 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -415,7 +415,6 @@ cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
 # Default sed regexp - multiline due to syntax constraints
 define sed-offsets
"/^->/{s:->#\(.*\):/* \1 */:; \
-   s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}"
 endef
-- 
2.7.4

[PATCH 0/2] kbuild: cleanup asm-offset generation, and make it work with clang

[Masahiro Yamada]

1/2 is a trivial cleanup of sed script
2/2 imports clang work-around from U-Boot.


Jeroen Hofstee (1):
  kbuild: fix asm-offset generation to work with clang

Masahiro Yamada (1):
  kbuild: consolidate redundant sed script ASM offset generation

 include/linux/kbuild.h | 6 +++---
 scripts/Makefile.lib   | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH 1/2] kbuild: consolidate redundant sed script ASM offset generation

[Masahiro Yamada]

This part ended up in redundant code after touched by multiple
people.

[1] Commit 3234282f33b2 ("x86, asm: Fix CFI macro invocations to
deal with shortcomings in gas") added parentheses for defined
expressions to support old gas for x86.

[2] Commit a22dcdb0032c ("x86, asm: Fix ancient-GAS workaround")
split the pattern into two to avoid parentheses for non-numeric
expressions.

[3] Commit 95a2f6f72d37 ("Partially revert patch that encloses
asm-offset.h numbers in brackets") removed parentheses from numeric
expressions as well because parentheses in MN10300 assembly have a
special meaning (pointer access).

Apparently, there is a conflict between [1] and [3].  After all,
[3] took precedence, and a long time has passed since then.

Now, merge the two patterns again because the first one is covered
by the other.

Signed-off-by: Masahiro Yamada 
---

 scripts/Makefile.lib | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index e36427a..9c20690 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -415,7 +415,6 @@ cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
 # Default sed regexp - multiline due to syntax constraints
 define sed-offsets
"/^->/{s:->#\(.*\):/* \1 */:; \
-   s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}"
 endef
-- 
2.7.4

Re: [PATCH] Input: ar1021 - do not force raising edge IRQ trigger

[Martin Kepplinger]

On 2017-04-14 01:49, Dmitry Torokhov wrote:
> We should not be forcing edge triggered interrupt, but rather let platform
> decide the kind of trigger it needs to use. Also, the driver is not quite
> safe with regard to edge-triggered interrupts as it does not try to kick
> the controller after requesting/enabling IRQ.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/touchscreen/ar1021_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
> b/drivers/input/touchscreen/ar1021_i2c.c
> index 6797e123925a..6c3c79b7ff51 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -109,7 +109,7 @@ static int ar1021_i2c_probe(struct i2c_client *client,
>  
>   error = devm_request_threaded_irq(>dev, client->irq,
> NULL, ar1021_i2c_irq,
> -   IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> +   IRQF_ONESHOT,
> "ar1021_i2c", ar1021);
>   if (error) {
>   dev_err(>dev,
> 

makes sense, if users have to expect that this default can change. it works.

Tested-by: Martin Kepplinger 

 martin

Re: [PATCH] Input: ar1021 - do not force raising edge IRQ trigger

[Martin Kepplinger]

On 2017-04-14 01:49, Dmitry Torokhov wrote:
> We should not be forcing edge triggered interrupt, but rather let platform
> decide the kind of trigger it needs to use. Also, the driver is not quite
> safe with regard to edge-triggered interrupts as it does not try to kick
> the controller after requesting/enabling IRQ.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/touchscreen/ar1021_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
> b/drivers/input/touchscreen/ar1021_i2c.c
> index 6797e123925a..6c3c79b7ff51 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -109,7 +109,7 @@ static int ar1021_i2c_probe(struct i2c_client *client,
>  
>   error = devm_request_threaded_irq(>dev, client->irq,
> NULL, ar1021_i2c_irq,
> -   IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> +   IRQF_ONESHOT,
> "ar1021_i2c", ar1021);
>   if (error) {
>   dev_err(>dev,
> 

makes sense, if users have to expect that this default can change. it works.

Tested-by: Martin Kepplinger 

 martin

[PATCH v2] powerpc/mm: Fix missing page attributes in page table dump

[Christophe Leroy]

On some targets, _PAGE_RW is 0 and this is _PAGE_RO which is used.
There is also _PAGE_SHARED that is missing.

Signed-off-by: Christophe Leroy 
---
 v2: Unlike the 3 other pgtable.h, arch/powerpc/include/asm/book3s/64/pgtable.h
 doesn't include pte-common.h . Therefore, _PAGE_SHARED has to be defined
 explicitly there, just like _PAGE_RO is. (build issue reported by kbuild robot)

 arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
 arch/powerpc/mm/dump_linuxpagetables.c   | 9 +
 2 files changed, 10 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index fb72ff6b98e6..fc9dc57a787b 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -13,6 +13,7 @@
 #define _PAGE_BIT_SWAP_TYPE0
 
 #define _PAGE_RO   0
+#define _PAGE_SHARED   0
 
 #define _PAGE_EXEC 0x1 /* execute permission */
 #define _PAGE_WRITE0x2 /* write access allowed */
diff --git a/arch/powerpc/mm/dump_linuxpagetables.c 
b/arch/powerpc/mm/dump_linuxpagetables.c
index 05109d7fa027..22d243f5 100644
--- a/arch/powerpc/mm/dump_linuxpagetables.c
+++ b/arch/powerpc/mm/dump_linuxpagetables.c
@@ -119,8 +119,13 @@ static const struct flag_info flag_array[] = {
.set= "user",
.clear  = "",
}, {
+#if _PAGE_RO == 0
.mask   = _PAGE_RW,
.val= _PAGE_RW,
+#else
+   .mask   = _PAGE_RO,
+   .val= 0,
+#endif
.set= "rw",
.clear  = "ro",
}, {
@@ -207,6 +212,10 @@ static const struct flag_info flag_array[] = {
.mask   = _PAGE_SPECIAL,
.val= _PAGE_SPECIAL,
.set= "special",
+   }, {
+   .mask   = _PAGE_SHARED,
+   .val= _PAGE_SHARED,
+   .set= "shared",
}
 };
 
-- 
2.12.0

[PATCH v2] powerpc/mm: Fix missing page attributes in page table dump

[Christophe Leroy]

On some targets, _PAGE_RW is 0 and this is _PAGE_RO which is used.
There is also _PAGE_SHARED that is missing.

Signed-off-by: Christophe Leroy 
---
 v2: Unlike the 3 other pgtable.h, arch/powerpc/include/asm/book3s/64/pgtable.h
 doesn't include pte-common.h . Therefore, _PAGE_SHARED has to be defined
 explicitly there, just like _PAGE_RO is. (build issue reported by kbuild robot)

 arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
 arch/powerpc/mm/dump_linuxpagetables.c   | 9 +
 2 files changed, 10 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index fb72ff6b98e6..fc9dc57a787b 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -13,6 +13,7 @@
 #define _PAGE_BIT_SWAP_TYPE0
 
 #define _PAGE_RO   0
+#define _PAGE_SHARED   0
 
 #define _PAGE_EXEC 0x1 /* execute permission */
 #define _PAGE_WRITE0x2 /* write access allowed */
diff --git a/arch/powerpc/mm/dump_linuxpagetables.c 
b/arch/powerpc/mm/dump_linuxpagetables.c
index 05109d7fa027..22d243f5 100644
--- a/arch/powerpc/mm/dump_linuxpagetables.c
+++ b/arch/powerpc/mm/dump_linuxpagetables.c
@@ -119,8 +119,13 @@ static const struct flag_info flag_array[] = {
.set= "user",
.clear  = "",
}, {
+#if _PAGE_RO == 0
.mask   = _PAGE_RW,
.val= _PAGE_RW,
+#else
+   .mask   = _PAGE_RO,
+   .val= 0,
+#endif
.set= "rw",
.clear  = "ro",
}, {
@@ -207,6 +212,10 @@ static const struct flag_info flag_array[] = {
.mask   = _PAGE_SPECIAL,
.val= _PAGE_SPECIAL,
.set= "special",
+   }, {
+   .mask   = _PAGE_SHARED,
+   .val= _PAGE_SHARED,
+   .set= "shared",
}
 };
 
-- 
2.12.0

Re: [PATCH 2/3] zram: do not use copy_page with non-page alinged address

[Sergey Senozhatsky]

Hello,

On (04/13/17 09:17), Minchan Kim wrote:
> The copy_page is optimized memcpy for page-alinged address.
> If it is used with non-page aligned address, it can corrupt memory which
> means system corruption. With zram, it can happen with
> 
> 1. 64K architecture
> 2. partial IO
> 3. slub debug
> 
> Partial IO need to allocate a page and zram allocates it via kmalloc.
> With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
> address. And finally, copy_page(mem, cmem) corrupts memory.

which would be the case for many other copy_page() calls in the kernel.
right? if so - should the fix be in copy_page() then?

-ss

Re: [PATCH 2/3] zram: do not use copy_page with non-page alinged address

[Sergey Senozhatsky]

Hello,

On (04/13/17 09:17), Minchan Kim wrote:
> The copy_page is optimized memcpy for page-alinged address.
> If it is used with non-page aligned address, it can corrupt memory which
> means system corruption. With zram, it can happen with
> 
> 1. 64K architecture
> 2. partial IO
> 3. slub debug
> 
> Partial IO need to allocate a page and zram allocates it via kmalloc.
> With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
> address. And finally, copy_page(mem, cmem) corrupts memory.

which would be the case for many other copy_page() calls in the kernel.
right? if so - should the fix be in copy_page() then?

-ss

Re: [PATCH v2] Input: ar1021-i2c - fix too long name in driver's device table

[Christian Gmeiner]

2017-04-14 1:32 GMT+02:00 Dmitry Torokhov :
> The name field in structure i2c_device_id is 20 characters, and we expect
> it to be NULL-terminated, however we are trying to stuff it with 21 bytes
> and thus NULL-terminator is lost. This causes issues when one creates
> device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C",
> and automatic module loading by alias does not work as result.
>
> The -I2C suffix in the device name is superfluous, we know what bus we are
> dealing with, so let's drop it. Also, no other driver uses capitals, and
> the manufacturer name is normally not included, except in very rare cases
> of incompatible name collisions.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen")
> Signed-off-by: Dmitry Torokhov 
Reviewed-By: Christian Gmeiner 

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner

Re: [PATCH v2] Input: ar1021-i2c - fix too long name in driver's device table

[Christian Gmeiner]

2017-04-14 1:32 GMT+02:00 Dmitry Torokhov :
> The name field in structure i2c_device_id is 20 characters, and we expect
> it to be NULL-terminated, however we are trying to stuff it with 21 bytes
> and thus NULL-terminator is lost. This causes issues when one creates
> device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C",
> and automatic module loading by alias does not work as result.
>
> The -I2C suffix in the device name is superfluous, we know what bus we are
> dealing with, so let's drop it. Also, no other driver uses capitals, and
> the manufacturer name is normally not included, except in very rare cases
> of incompatible name collisions.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen")
> Signed-off-by: Dmitry Torokhov 
Reviewed-By: Christian Gmeiner 

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner

Re: [PATCH RFC 0/5] *** SPI Slave mode support ***

[Jiada Wang]

Hello Geert

On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:

On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown  wrote:

On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

v1:
   add Slave mode support in SPI core
   spidev create slave device when SPI controller work in slave mode
   spi-imx support to work in slave mode

Adding Geert who also had a series doing this in progress that was
getting very near to being merged.

Thank you!

Actually my plan is to fix the last remaining issues and resubmit for v4.13.

I noticed your patch set for SPI slave support,
(I am sure you can find out some of the change
in this patch set is based on your work).
we have similar requirement to add slave mode support to ecspi IP on 
imx6 Soc.


Our use case is to use spidev as an interface to communicate with 
external SPI master devices.
meanwhile the SPI bus controller can also act as master device to send 
data to other

SPI slave devices on the board.

I found in your implementation, SPI bus controller is limited to either 
work in master mode or
slave mode, is there any reasoning to not configure SPI mode based on 
SPI devices use case?



Thanks,
Jiada


References:
   - v2: https://lkml.org/lkml/2016/9/12/1065
   - v1: https://lkml.org/lkml/2016/6/22/423

BTW Jiada, what's your use case? Just spidev?

Thx!

Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds

Re: [PATCH RFC 0/5] *** SPI Slave mode support ***

[Jiada Wang]

Hello Geert

On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:

On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown  wrote:

On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

v1:
   add Slave mode support in SPI core
   spidev create slave device when SPI controller work in slave mode
   spi-imx support to work in slave mode

Adding Geert who also had a series doing this in progress that was
getting very near to being merged.

Thank you!

Actually my plan is to fix the last remaining issues and resubmit for v4.13.

I noticed your patch set for SPI slave support,
(I am sure you can find out some of the change
in this patch set is based on your work).
we have similar requirement to add slave mode support to ecspi IP on 
imx6 Soc.


Our use case is to use spidev as an interface to communicate with 
external SPI master devices.
meanwhile the SPI bus controller can also act as master device to send 
data to other

SPI slave devices on the board.

I found in your implementation, SPI bus controller is limited to either 
work in master mode or
slave mode, is there any reasoning to not configure SPI mode based on 
SPI devices use case?



Thanks,
Jiada


References:
   - v2: https://lkml.org/lkml/2016/9/12/1065
   - v1: https://lkml.org/lkml/2016/6/22/423

BTW Jiada, what's your use case? Just spidev?

Thx!

Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds

Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

[hpa]

On April 13, 2017 5:23:35 PM PDT, Matthias Kaehlcke  wrote:
>El Thu, Apr 13, 2017 at 04:55:00PM -0700 H. Peter Anvin ha dit:
>
>> On 04/13/17 16:14, Matthias Kaehlcke wrote:
>> > El Mon, Apr 03, 2017 at 04:01:58PM -0700 Matthias Kaehlcke ha dit:
>> > 
>> >> El Fri, Mar 17, 2017 at 04:50:19PM -0700 h...@zytor.com ha dit:
>> >>
>> >>> On March 16, 2017 5:15:16 PM PDT, Michael Davidson
> wrote:
>>  Suppress clang warnings about potential unaliged accesses
>>  to members in packed structs. This gets rid of almost 10,000
>>  warnings about accesses to the ring 0 stack pointer in the TSS.
>> 
>>  Signed-off-by: Michael Davidson 
>>  ---
>>  arch/x86/Makefile | 5 +
>>  1 file changed, 5 insertions(+)
>> 
>>  diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>>  index 894a8d18bf97..7f21703c475d 100644
>>  --- a/arch/x86/Makefile
>>  +++ b/arch/x86/Makefile
>>  @@ -128,6 +128,11 @@ endif
>>  KBUILD_CFLAGS += $(call
>cc-option,-maccumulate-outgoing-args)
>>  endif
>> 
>>  +ifeq ($(cc-name),clang)
>>  +# Suppress clang warnings about potential unaligned accesses.
>>  +KBUILD_CFLAGS += $(call cc-disable-warning,
>address-of-packed-member)
>>  +endif
>>  +
>>  ifdef CONFIG_X86_X32
>>  x32_ld_ok := $(call try-run,\
>>  /bin/echo -e '1: .quad 1b' | \
>> >>>
>> >>> Why conditional on clang?
>> >>
>> >> My understanding is that this warning is clang specific, it is not
>> >> listed on https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
>> > 
>> > Actually this warning affects other platforms besides x86
>> > (e.g. arm64), I'll submit a patch that disables the warning on all
>> > platforms.
>> > 
>> 
>> Drop the ifeq ($(cc-name),clang).
>> 
>> You should assume that if you have to add one of those ifeq's then
>you
>> are doing something fundamentally wrong.
>
>Thanks, however in the case of the global Makefile it seems we should
>put it inside the already existing clang section:
>
>http://lxr.free-electrons.com/source/Makefile#L692
>
>Cheers
>
>Matthias

We shouldn't, unless it will actively break non-clang builds...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

[hpa]

On April 13, 2017 5:23:35 PM PDT, Matthias Kaehlcke  wrote:
>El Thu, Apr 13, 2017 at 04:55:00PM -0700 H. Peter Anvin ha dit:
>
>> On 04/13/17 16:14, Matthias Kaehlcke wrote:
>> > El Mon, Apr 03, 2017 at 04:01:58PM -0700 Matthias Kaehlcke ha dit:
>> > 
>> >> El Fri, Mar 17, 2017 at 04:50:19PM -0700 h...@zytor.com ha dit:
>> >>
>> >>> On March 16, 2017 5:15:16 PM PDT, Michael Davidson
> wrote:
>>  Suppress clang warnings about potential unaliged accesses
>>  to members in packed structs. This gets rid of almost 10,000
>>  warnings about accesses to the ring 0 stack pointer in the TSS.
>> 
>>  Signed-off-by: Michael Davidson 
>>  ---
>>  arch/x86/Makefile | 5 +
>>  1 file changed, 5 insertions(+)
>> 
>>  diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>>  index 894a8d18bf97..7f21703c475d 100644
>>  --- a/arch/x86/Makefile
>>  +++ b/arch/x86/Makefile
>>  @@ -128,6 +128,11 @@ endif
>>  KBUILD_CFLAGS += $(call
>cc-option,-maccumulate-outgoing-args)
>>  endif
>> 
>>  +ifeq ($(cc-name),clang)
>>  +# Suppress clang warnings about potential unaligned accesses.
>>  +KBUILD_CFLAGS += $(call cc-disable-warning,
>address-of-packed-member)
>>  +endif
>>  +
>>  ifdef CONFIG_X86_X32
>>  x32_ld_ok := $(call try-run,\
>>  /bin/echo -e '1: .quad 1b' | \
>> >>>
>> >>> Why conditional on clang?
>> >>
>> >> My understanding is that this warning is clang specific, it is not
>> >> listed on https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
>> > 
>> > Actually this warning affects other platforms besides x86
>> > (e.g. arm64), I'll submit a patch that disables the warning on all
>> > platforms.
>> > 
>> 
>> Drop the ifeq ($(cc-name),clang).
>> 
>> You should assume that if you have to add one of those ifeq's then
>you
>> are doing something fundamentally wrong.
>
>Thanks, however in the case of the global Makefile it seems we should
>put it inside the already existing clang section:
>
>http://lxr.free-electrons.com/source/Makefile#L692
>
>Cheers
>
>Matthias

We shouldn't, unless it will actively break non-clang builds...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PATCH 1/3] dt-bindings: Add support for samsung s6e3ha2 edge panel binding

[Hoegeun Kwon]

The Samsung s6e3ha2 edge is a 5.65" 1600x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
new file mode 100644
index 000..09c65f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.65" 1600x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2-e"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

[PATCH 1/3] dt-bindings: Add support for samsung s6e3ha2 edge panel binding

[Hoegeun Kwon]

The Samsung s6e3ha2 edge is a 5.65" 1600x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
new file mode 100644
index 000..09c65f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.65" 1600x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2-e"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

[hpa]

On April 13, 2017 8:51:19 PM PDT, Gary Lin  wrote:
>On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote:
>> On April 11, 2017 3:20:41 AM PDT, Gary Lin  wrote:
>> >This commit adds the new config options to allow the user to modify
>the
>> >following fields in the PE-COFF header.
>> >
>> >UINT16 MajorOperatingSystemVersion
>> >UINT16 MinorOperatingSystemVersion
>> >UINT16 MajorImageVersion
>> >UINT16 MinorImageVersion
>> >
>> >Those fields are mainly for the executables or libraries in Windows
>NT
>> >or higher to specify the minimum supported Windows version and the
>> >version of the image itself.
>> >
>> >Given the fact that those fields are ignored in UEFI, we can safely
>> >reuse
>> >those fields for other purposes, e.g. Security Version(*).
>> >
>> >(*) https://github.com/lcp/shim/wiki/Security-Version
>> >
>> >Cc: Thomas Gleixner 
>> >Cc: Ingo Molnar 
>> >Cc: "H. Peter Anvin" 
>> >Cc: Masahiro Yamada 
>> >Cc: Michal Marek 
>> >Cc: Matt Fleming 
>> >Cc: Ard Biesheuvel 
>> >Cc: Joey Lee 
>> >Cc: Vojtech Pavlik 
>> >Signed-off-by: Gary Lin 
>> >Tested-by: Joey Lee 
>> >---
>[snip]
>> 
>> Reusing PECOFF fields seems doubleplusunsafe: we don't own those
>fields, the UEFI forum does.  It would make a lot more sense to add
>these fields to the bzImage header directly or indirectly (via a
>pointer), the latter would be more economical since the bzImage header
>size is bounded.
>> 
>> We could even define it as a pointer to a "security information
>header" with its own size field, so it can be grown in the future as
>needed.
>Reusing PE-COFF simplifies the implementation since shim can parse the
>header directly. I can raise the issue to the UEFI forum to clarify the
>usage of those fields.
>
>Meanwhile, I'll also look into the bzImage header in case the PE-COFF
>header is really a NO-GO.
>
>Thanks,
>
>Gary Lin

If we are going to use the PE-COFF hear then you need to write a proposal and 
get the UEFI forum to sign off on it.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

[hpa]

On April 13, 2017 8:51:19 PM PDT, Gary Lin  wrote:
>On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote:
>> On April 11, 2017 3:20:41 AM PDT, Gary Lin  wrote:
>> >This commit adds the new config options to allow the user to modify
>the
>> >following fields in the PE-COFF header.
>> >
>> >UINT16 MajorOperatingSystemVersion
>> >UINT16 MinorOperatingSystemVersion
>> >UINT16 MajorImageVersion
>> >UINT16 MinorImageVersion
>> >
>> >Those fields are mainly for the executables or libraries in Windows
>NT
>> >or higher to specify the minimum supported Windows version and the
>> >version of the image itself.
>> >
>> >Given the fact that those fields are ignored in UEFI, we can safely
>> >reuse
>> >those fields for other purposes, e.g. Security Version(*).
>> >
>> >(*) https://github.com/lcp/shim/wiki/Security-Version
>> >
>> >Cc: Thomas Gleixner 
>> >Cc: Ingo Molnar 
>> >Cc: "H. Peter Anvin" 
>> >Cc: Masahiro Yamada 
>> >Cc: Michal Marek 
>> >Cc: Matt Fleming 
>> >Cc: Ard Biesheuvel 
>> >Cc: Joey Lee 
>> >Cc: Vojtech Pavlik 
>> >Signed-off-by: Gary Lin 
>> >Tested-by: Joey Lee 
>> >---
>[snip]
>> 
>> Reusing PECOFF fields seems doubleplusunsafe: we don't own those
>fields, the UEFI forum does.  It would make a lot more sense to add
>these fields to the bzImage header directly or indirectly (via a
>pointer), the latter would be more economical since the bzImage header
>size is bounded.
>> 
>> We could even define it as a pointer to a "security information
>header" with its own size field, so it can be grown in the future as
>needed.
>Reusing PE-COFF simplifies the implementation since shim can parse the
>header directly. I can raise the issue to the UEFI forum to clarify the
>usage of those fields.
>
>Meanwhile, I'll also look into the bzImage header in case the PE-COFF
>header is really a NO-GO.
>
>Thanks,
>
>Gary Lin

If we are going to use the PE-COFF hear then you need to write a proposal and 
get the UEFI forum to sign off on it.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PATCH 0/3] Add support for the S6E3HA2 edge panel on TM2e board

[Hoegeun Kwon]

The purpose of this patch is add support for S6E3HA2 edge AMOLED panel
on the TM2e board. The panel has 1600x2560 resolution in 5.65"
physical panel in the TM2e device.

The S6E3HA2 edge panel(5.65") is simliar to the previous S6E3HA2
panel(5.7"), but resolution and some command message are different. So
it can be distinguished as a compatiblitiy string.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e3ha2 edge panel binding
  drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board
  arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e
board

 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 62 +++---
 3 files changed, 96 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

-- 
1.9.1

[PATCH 0/3] Add support for the S6E3HA2 edge panel on TM2e board

[Hoegeun Kwon]

The purpose of this patch is add support for S6E3HA2 edge AMOLED panel
on the TM2e board. The panel has 1600x2560 resolution in 5.65"
physical panel in the TM2e device.

The S6E3HA2 edge panel(5.65") is simliar to the previous S6E3HA2
panel(5.7"), but resolution and some command message are different. So
it can be distinguished as a compatiblitiy string.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e3ha2 edge panel binding
  drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board
  arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e
board

 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 62 +++---
 3 files changed, 96 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

-- 
1.9.1

[PATCH 3/3] arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e board

[Hoegeun Kwon]

This patch add the panel device tree node for S6E3HA2 edge display
controller to TM2e dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..79f22f7 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <27800>, <4>;
 };
 
+ {
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 _reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <180>;
-- 
1.9.1

[PATCH 2/3] drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board

[Hoegeun Kwon]

This patch considers edge type of panel on TM2e board and The panel
has 1600x2560 resolution in 5.65" physical panel in the TM2e device.

This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for default
compatibility and edge type and select the drm_display_mode of default
and edge type.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 62 ---
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 4cc08d7..b4a064a 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define S6E3HA2_MIN_BRIGHTNESS 0
@@ -218,6 +219,16 @@
0x1d, 0x1e, 0x1f, 0x20, 0x21
 };
 
+enum s6e3ha2_type {
+   DEFAULT_TYPE,
+   EDGE_TYPE,
+};
+
+struct s6e3ha2_panel_desc {
+   const struct drm_display_mode *mode;
+   enum s6e3ha2_type type;
+};
+
 struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
@@ -226,6 +237,8 @@ struct s6e3ha2 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+
+   const struct s6e3ha2_panel_desc *desc;
 };
 
 static int s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
@@ -283,11 +296,19 @@ static int s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
 static int s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
 {
s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+   if (ctx->desc->type == EDGE_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67, 0x40, 0xc5);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
-   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62, 0x40,
-   0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
+   if (ctx->desc->type == DEFAULT_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+   else
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x14, 0x6d,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
return 0;
 }
 
@@ -597,16 +618,41 @@ static int s6e3ha2_enable(struct drm_panel *panel)
.flags = 0,
 };
 
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2 = {
+   .mode = _mode,
+   .type = DEFAULT_TYPE,
+};
+
+static const struct drm_display_mode edge_mode = {
+   .clock = 247856,
+   .hdisplay = 1600,
+   .hsync_start = 1600 + 1,
+   .hsync_end = 1600 + 1 + 1,
+   .htotal = 1600 + 1 + 1 + 1,
+   .vdisplay = 2560,
+   .vsync_start = 2560 + 1,
+   .vsync_end = 2560 + 1 + 1,
+   .vtotal = 2560 + 1 + 1 + 15,
+   .vrefresh = 60,
+   .flags = 0,
+};
+
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2e = {
+   .mode = _mode,
+   .type = EDGE_TYPE,
+};
+
 static int s6e3ha2_get_modes(struct drm_panel *panel)
 {
struct drm_connector *connector = panel->connector;
+   struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = drm_mode_duplicate(panel->drm, ctx->desc->mode);
if (!mode) {
DRM_ERROR("failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
+   ctx->desc->mode->vrefresh);
return -ENOMEM;
}
 
@@ -642,6 +688,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
 
ctx->dev = dev;
+   ctx->desc = of_device_get_match_data(dev);
 
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
@@ -717,7 +764,10 @@ static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
 }
 
 static const struct of_device_id s6e3ha2_of_match[] = {
-   { .compatible = "samsung,s6e3ha2" },
+   { .compatible = "samsung,s6e3ha2",
+ .data = _s6e3ha2_tm2 },
+   { .compatible = "samsung,s6e3ha2-e",
+ .data = _s6e3ha2_tm2e },
{ }
 };
 MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
-- 
1.9.1

[PATCH 3/3] arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e board

[Hoegeun Kwon]

This patch add the panel device tree node for S6E3HA2 edge display
controller to TM2e dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..79f22f7 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <27800>, <4>;
 };
 
+ {
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 _reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <180>;
-- 
1.9.1

[PATCH 2/3] drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board

[Hoegeun Kwon]

This patch considers edge type of panel on TM2e board and The panel
has 1600x2560 resolution in 5.65" physical panel in the TM2e device.

This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for default
compatibility and edge type and select the drm_display_mode of default
and edge type.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 62 ---
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 4cc08d7..b4a064a 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define S6E3HA2_MIN_BRIGHTNESS 0
@@ -218,6 +219,16 @@
0x1d, 0x1e, 0x1f, 0x20, 0x21
 };
 
+enum s6e3ha2_type {
+   DEFAULT_TYPE,
+   EDGE_TYPE,
+};
+
+struct s6e3ha2_panel_desc {
+   const struct drm_display_mode *mode;
+   enum s6e3ha2_type type;
+};
+
 struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
@@ -226,6 +237,8 @@ struct s6e3ha2 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+
+   const struct s6e3ha2_panel_desc *desc;
 };
 
 static int s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
@@ -283,11 +296,19 @@ static int s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
 static int s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
 {
s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+   if (ctx->desc->type == EDGE_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67, 0x40, 0xc5);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
-   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62, 0x40,
-   0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
+   if (ctx->desc->type == DEFAULT_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+   else
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x14, 0x6d,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
return 0;
 }
 
@@ -597,16 +618,41 @@ static int s6e3ha2_enable(struct drm_panel *panel)
.flags = 0,
 };
 
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2 = {
+   .mode = _mode,
+   .type = DEFAULT_TYPE,
+};
+
+static const struct drm_display_mode edge_mode = {
+   .clock = 247856,
+   .hdisplay = 1600,
+   .hsync_start = 1600 + 1,
+   .hsync_end = 1600 + 1 + 1,
+   .htotal = 1600 + 1 + 1 + 1,
+   .vdisplay = 2560,
+   .vsync_start = 2560 + 1,
+   .vsync_end = 2560 + 1 + 1,
+   .vtotal = 2560 + 1 + 1 + 15,
+   .vrefresh = 60,
+   .flags = 0,
+};
+
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2e = {
+   .mode = _mode,
+   .type = EDGE_TYPE,
+};
+
 static int s6e3ha2_get_modes(struct drm_panel *panel)
 {
struct drm_connector *connector = panel->connector;
+   struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = drm_mode_duplicate(panel->drm, ctx->desc->mode);
if (!mode) {
DRM_ERROR("failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
+   ctx->desc->mode->vrefresh);
return -ENOMEM;
}
 
@@ -642,6 +688,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
 
ctx->dev = dev;
+   ctx->desc = of_device_get_match_data(dev);
 
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
@@ -717,7 +764,10 @@ static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
 }
 
 static const struct of_device_id s6e3ha2_of_match[] = {
-   { .compatible = "samsung,s6e3ha2" },
+   { .compatible = "samsung,s6e3ha2",
+ .data = _s6e3ha2_tm2 },
+   { .compatible = "samsung,s6e3ha2-e",
+ .data = _s6e3ha2_tm2e },
{ }
 };
 MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
-- 
1.9.1

[PATCH v3 1/2] thermal: core: Allow orderly_poweroff to be called only once

[Keerthy]

thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff

The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system it takes at least 5-10 Seconds to
power off gracefully.

In that period due to the thermal_zone_device_check triggering
periodically the thermal work queues bombard with
orderly_poweroff calls multiple times eventually leading to
failures in gracefully powering off the system.

Make sure that orderly_poweroff is called only once.

Reported-by: Keerthy 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Changed the place where mutex was locked and unlocked.

Changes in v2:

  * Added a global mutex to serialize poweroff code sequence.

 drivers/thermal/thermal_core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 11f0675..9cad1ba 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -45,6 +45,7 @@
 
 static DEFINE_MUTEX(thermal_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
+static DEFINE_MUTEX(poweroff_lock);
 
 static atomic_t in_suspend;
 
@@ -326,6 +327,7 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
  int trip, enum thermal_trip_type trip_type)
 {
int trip_temp;
+   static bool power_off_triggered;
 
tz->ops->get_trip_temp(tz, trip, _temp);
 
@@ -342,7 +344,12 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
dev_emerg(>device,
  "critical temperature reached(%d C),shutting down\n",
  tz->temperature / 1000);
-   orderly_poweroff(true);
+   mutex_lock(_lock);
+   if (!power_off_triggered) {
+   orderly_poweroff(true);
+   power_off_triggered = true;
+   }
+   mutex_unlock(_lock);
}
 }
 
@@ -1463,6 +1470,7 @@ static int __init thermal_init(void)
 {
int result;
 
+   mutex_init(_lock);
result = thermal_register_governors();
if (result)
goto error;
@@ -1497,6 +1505,7 @@ static int __init thermal_init(void)
ida_destroy(_cdev_ida);
mutex_destroy(_list_lock);
mutex_destroy(_governor_lock);
+   mutex_destroy(_lock);
return result;
 }
 
-- 
1.9.1

[PATCH v3 1/2] thermal: core: Allow orderly_poweroff to be called only once

[Keerthy]

thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff

The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system it takes at least 5-10 Seconds to
power off gracefully.

In that period due to the thermal_zone_device_check triggering
periodically the thermal work queues bombard with
orderly_poweroff calls multiple times eventually leading to
failures in gracefully powering off the system.

Make sure that orderly_poweroff is called only once.

Reported-by: Keerthy 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Changed the place where mutex was locked and unlocked.

Changes in v2:

  * Added a global mutex to serialize poweroff code sequence.

 drivers/thermal/thermal_core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 11f0675..9cad1ba 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -45,6 +45,7 @@
 
 static DEFINE_MUTEX(thermal_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
+static DEFINE_MUTEX(poweroff_lock);
 
 static atomic_t in_suspend;
 
@@ -326,6 +327,7 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
  int trip, enum thermal_trip_type trip_type)
 {
int trip_temp;
+   static bool power_off_triggered;
 
tz->ops->get_trip_temp(tz, trip, _temp);
 
@@ -342,7 +344,12 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
dev_emerg(>device,
  "critical temperature reached(%d C),shutting down\n",
  tz->temperature / 1000);
-   orderly_poweroff(true);
+   mutex_lock(_lock);
+   if (!power_off_triggered) {
+   orderly_poweroff(true);
+   power_off_triggered = true;
+   }
+   mutex_unlock(_lock);
}
 }
 
@@ -1463,6 +1470,7 @@ static int __init thermal_init(void)
 {
int result;
 
+   mutex_init(_lock);
result = thermal_register_governors();
if (result)
goto error;
@@ -1497,6 +1505,7 @@ static int __init thermal_init(void)
ida_destroy(_cdev_ida);
mutex_destroy(_list_lock);
mutex_destroy(_governor_lock);
+   mutex_destroy(_lock);
return result;
 }
 
-- 
1.9.1

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

[Christoph Hellwig]

On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote:
> Or maybe I'll just send a patch for that
> separately seeing it doesn't depend on anything and is pretty simple. I
> can do that next week.

Yes, please just send that patch linux-nvme, we should be able to get
it into 4.12.

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

[Christoph Hellwig]

On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote:
> Or maybe I'll just send a patch for that
> separately seeing it doesn't depend on anything and is pretty simple. I
> can do that next week.

Yes, please just send that patch linux-nvme, we should be able to get
it into 4.12.

[PATCH v3 2/2] thermal: core: Add a back up thermal shutdown mechanism

[Keerthy]

orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the middle of driver probes being
initiated, userspace will be unable to power off the system in a clean
manner and leaves the system in a critical state. In cases like these,
the /sbin/poweroff will return success (having forked off to attempt
powering off the system. However, the system overall will fail to
completely poweroff (since other modules will be probed) and the system
is still functional with no userspace (since that would have shut itself
off).

However, there is no clean way of detecting such failure of userspace
powering off the system. In such scenarios, it is necessary for a backup
workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.

Reported-by: Nishanth Menon 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Removed unnecessary mutex init.
  * Added WARN messages instead of a simple warning message.
  * Added Documentation.

 Documentation/thermal/sysfs-api.txt | 18 +++
 drivers/thermal/Kconfig | 13 +++
 drivers/thermal/thermal_core.c  | 45 +
 3 files changed, 76 insertions(+)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index ef473dc..94b707c 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -582,3 +582,21 @@ platform data is provided, this uses the step_wise 
throttling policy.
 This function serves as an arbitrator to set the state of a cooling
 device. It sets the cooling device to the deepest cooling state if
 possible.
+
+6. thermal_emergency_poweroff:
+
+On an event of critical trip temperature crossing. Thermal framework
+allows the system to shutdown gracefully by calling orderly_poweroff.
+In the event of a failure of orderly_poweroff to shut down the system
+we are in danger of keeping the system alive at undesirably high
+temperatures. To mitigate this high risk scenario we program a work
+queue to fire after a pre-determined number of seconds to start
+an emergency shutdown of the device using the kernel_power_off
+function.
+
+The delay should be carefully profiled so as to give adequate time for
+orderly_poweroff. In case of failure of an orderly_poweroff the
+emergency poweroff kicks in after the delay has elapsed and shuts down
+the system.
+
+If set to 0 emergency poweroff will happen immediately.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9347401..971fd54 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -15,6 +15,19 @@ menuconfig THERMAL
 
 if THERMAL
 
+config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
+   int "Emergency poweroff delay in milli-seconds"
+   depends on THERMAL
+   default 0
+   help
+ The number of milliseconds to delay before emergency
+ poweroff kicks in. The delay should be carefully profiled
+ so as to give adequate time for orderly_poweroff. In case
+ of failure of an orderly_poweroff the emergency poweroff
+ kicks in after the delay has elapsed and shuts down the system.
+
+ If set to 0 poweroff will happen immediately.
+
 config THERMAL_HWMON
bool
prompt "Expose thermal sensors as hwmon device"
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9cad1ba..30098cd 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -323,6 +323,46 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+/**
+ * emergency_poweroff_func - emergency poweroff work after a known delay
+ * @work: work_struct associated with the emergency poweroff function
+ *
+ * This function is called in very critical situations to force
+ * a kernel poweroff after a configurable timeout value.
+ */
+static void emergency_poweroff_func(struct work_struct *work)
+{
+   /*
+* We have reached here after the emergency thermal shutdown
+* Waiting period has expired. This means orderly_poweroff has
+* not been able to shut off the system for some reason.
+* Try to shut down the system immediately using kernel_power_off
+* if populated
+*/
+   WARN(1, "Attempting kernel_power_off: Temperature too high\n");
+   kernel_power_off();
+
+   /*
+* Worst of the worst case trigger emergency restart
+*/
+   WARN(1, "Attempting emergency_restart: Temperature too high\n");
+   emergency_restart();
+}
+
+static DECLARE_DELAYED_WORK(emergency_poweroff_work, emergency_poweroff_func);
+
+/**
+ * emergency_poweroff - 

[PATCH v3 2/2] thermal: core: Add a back up thermal shutdown mechanism

[Keerthy]

orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the middle of driver probes being
initiated, userspace will be unable to power off the system in a clean
manner and leaves the system in a critical state. In cases like these,
the /sbin/poweroff will return success (having forked off to attempt
powering off the system. However, the system overall will fail to
completely poweroff (since other modules will be probed) and the system
is still functional with no userspace (since that would have shut itself
off).

However, there is no clean way of detecting such failure of userspace
powering off the system. In such scenarios, it is necessary for a backup
workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.

Reported-by: Nishanth Menon 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Removed unnecessary mutex init.
  * Added WARN messages instead of a simple warning message.
  * Added Documentation.

 Documentation/thermal/sysfs-api.txt | 18 +++
 drivers/thermal/Kconfig | 13 +++
 drivers/thermal/thermal_core.c  | 45 +
 3 files changed, 76 insertions(+)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index ef473dc..94b707c 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -582,3 +582,21 @@ platform data is provided, this uses the step_wise 
throttling policy.
 This function serves as an arbitrator to set the state of a cooling
 device. It sets the cooling device to the deepest cooling state if
 possible.
+
+6. thermal_emergency_poweroff:
+
+On an event of critical trip temperature crossing. Thermal framework
+allows the system to shutdown gracefully by calling orderly_poweroff.
+In the event of a failure of orderly_poweroff to shut down the system
+we are in danger of keeping the system alive at undesirably high
+temperatures. To mitigate this high risk scenario we program a work
+queue to fire after a pre-determined number of seconds to start
+an emergency shutdown of the device using the kernel_power_off
+function.
+
+The delay should be carefully profiled so as to give adequate time for
+orderly_poweroff. In case of failure of an orderly_poweroff the
+emergency poweroff kicks in after the delay has elapsed and shuts down
+the system.
+
+If set to 0 emergency poweroff will happen immediately.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9347401..971fd54 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -15,6 +15,19 @@ menuconfig THERMAL
 
 if THERMAL
 
+config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
+   int "Emergency poweroff delay in milli-seconds"
+   depends on THERMAL
+   default 0
+   help
+ The number of milliseconds to delay before emergency
+ poweroff kicks in. The delay should be carefully profiled
+ so as to give adequate time for orderly_poweroff. In case
+ of failure of an orderly_poweroff the emergency poweroff
+ kicks in after the delay has elapsed and shuts down the system.
+
+ If set to 0 poweroff will happen immediately.
+
 config THERMAL_HWMON
bool
prompt "Expose thermal sensors as hwmon device"
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9cad1ba..30098cd 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -323,6 +323,46 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+/**
+ * emergency_poweroff_func - emergency poweroff work after a known delay
+ * @work: work_struct associated with the emergency poweroff function
+ *
+ * This function is called in very critical situations to force
+ * a kernel poweroff after a configurable timeout value.
+ */
+static void emergency_poweroff_func(struct work_struct *work)
+{
+   /*
+* We have reached here after the emergency thermal shutdown
+* Waiting period has expired. This means orderly_poweroff has
+* not been able to shut off the system for some reason.
+* Try to shut down the system immediately using kernel_power_off
+* if populated
+*/
+   WARN(1, "Attempting kernel_power_off: Temperature too high\n");
+   kernel_power_off();
+
+   /*
+* Worst of the worst case trigger emergency restart
+*/
+   WARN(1, "Attempting emergency_restart: Temperature too high\n");
+   emergency_restart();
+}
+
+static DECLARE_DELAYED_WORK(emergency_poweroff_work, emergency_poweroff_func);
+
+/**
+ * emergency_poweroff - Trigger an emergency system 

Re: [PATCH 4/6] kvm: nVMX: support EPT accessed/dirty bits

[Paolo Bonzini]

On 13/04/2017 07:02, Bandan Das wrote:
>> For EPT it is, you're right it's fishy.  The "nested_access" should be
>> computed in translate_nested_gpa, which is where kvm->arch.nested_mmu
>> (non-EPT) requests to access kvm->arch.mmu (EPT).
>
> Thanks for the clarification. Is it the case when L1 runs L2 without
> EPT ? I can't figure out the case where translate_nested_gpa will actually
> be called.

It happens when L2 instruction are emulated by L0, for example when L1
is passing through I/O ports to L2 and L2 runs an "insb" instruction.  I
think this case is not covered by vmx.flat.

Paolo

> FNAME(walk_addr_nested) calls walk_addr_generic
> with >arch.nested_mmu and init_kvm_nested_mmu() sets gva_to_gpa()
> with the appropriate "_nested" functions. But the gva_to_gpa() pointers
> don't seem to get invoked at all for the nested case.
> 
> BTW, just noticed that setting PFERR_USER_MASK is redundant since
> translate_nested_gpa does it too.

Re: [PATCH 4/6] kvm: nVMX: support EPT accessed/dirty bits

[Paolo Bonzini]

On 13/04/2017 07:02, Bandan Das wrote:
>> For EPT it is, you're right it's fishy.  The "nested_access" should be
>> computed in translate_nested_gpa, which is where kvm->arch.nested_mmu
>> (non-EPT) requests to access kvm->arch.mmu (EPT).
>
> Thanks for the clarification. Is it the case when L1 runs L2 without
> EPT ? I can't figure out the case where translate_nested_gpa will actually
> be called.

It happens when L2 instruction are emulated by L0, for example when L1
is passing through I/O ports to L2 and L2 runs an "insb" instruction.  I
think this case is not covered by vmx.flat.

Paolo

> FNAME(walk_addr_nested) calls walk_addr_generic
> with >arch.nested_mmu and init_kvm_nested_mmu() sets gva_to_gpa()
> with the appropriate "_nested" functions. But the gva_to_gpa() pointers
> don't seem to get invoked at all for the nested case.
> 
> BTW, just noticed that setting PFERR_USER_MASK is redundant since
> translate_nested_gpa does it too.

Re: [PATCH] KVM: nVMX: fix AD condition when handling EPT violation

[Paolo Bonzini]

On 14/04/2017 00:39, Radim Krčmář wrote:
> I have introduced this bug when applying and simplifying Paolo's patch
> as we agreed on the list.  The original was "x &= ~y; if (z) x |= y;".
> 
> Here is the story of a bad workflow:
> 
>   A maintainer was already testing with the intended change, but it was
>   applied only to a testing repo on a different machine.  When the time
>   to push tested patches to kvm/next came, he realized that this change
>   was missing and quickly added it to the maintenance repo, didn't test
>   again (because the change is trivial, right), and pushed the world to
>   fire.
> 
> Fixes: ae1e2d1082ae ("kvm: nVMX: support EPT accessed/dirty bits")
> Signed-off-by: Radim Krčmář 
> ---
>  arch/x86/kvm/vmx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index cfdb0d9389d1..837f6dd1ae9c 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6221,7 +6221,7 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
>* page table accesses are reads or writes.
>*/
>   u64 eptp = nested_ept_get_cr3(vcpu);
> - if (eptp & VMX_EPT_AD_ENABLE_BIT)
> + if (!(eptp & VMX_EPT_AD_ENABLE_BIT))
>   exit_qualification &= ~EPT_VIOLATION_ACC_WRITE;
>   }
>  
> 

I have done this as well, so you're forgiven. :)

More important: did kvm-unit-test catch the bug?

Paolo

Re: [PATCH] KVM: nVMX: fix AD condition when handling EPT violation

[Paolo Bonzini]

On 14/04/2017 00:39, Radim Krčmář wrote:
> I have introduced this bug when applying and simplifying Paolo's patch
> as we agreed on the list.  The original was "x &= ~y; if (z) x |= y;".
> 
> Here is the story of a bad workflow:
> 
>   A maintainer was already testing with the intended change, but it was
>   applied only to a testing repo on a different machine.  When the time
>   to push tested patches to kvm/next came, he realized that this change
>   was missing and quickly added it to the maintenance repo, didn't test
>   again (because the change is trivial, right), and pushed the world to
>   fire.
> 
> Fixes: ae1e2d1082ae ("kvm: nVMX: support EPT accessed/dirty bits")
> Signed-off-by: Radim Krčmář 
> ---
>  arch/x86/kvm/vmx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index cfdb0d9389d1..837f6dd1ae9c 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6221,7 +6221,7 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
>* page table accesses are reads or writes.
>*/
>   u64 eptp = nested_ept_get_cr3(vcpu);
> - if (eptp & VMX_EPT_AD_ENABLE_BIT)
> + if (!(eptp & VMX_EPT_AD_ENABLE_BIT))
>   exit_qualification &= ~EPT_VIOLATION_ACC_WRITE;
>   }
>  
> 

I have done this as well, so you're forgiven. :)

More important: did kvm-unit-test catch the bug?

Paolo

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Sergey Senozhatsky]

Hello,

On (04/13/17 09:17), Minchan Kim wrote:
[..]
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9e2199060040..83c38a123242 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -930,7 +930,7 @@ static int zram_rw_page(struct block_device *bdev, 
> sector_t sector,
>   }
>  
>   index = sector >> SECTORS_PER_PAGE_SHIFT;
> - offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> + offset = (sector & (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;

sorry, can it actually produce different results?

-ss

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Sergey Senozhatsky]

Hello,

On (04/13/17 09:17), Minchan Kim wrote:
[..]
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9e2199060040..83c38a123242 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -930,7 +930,7 @@ static int zram_rw_page(struct block_device *bdev, 
> sector_t sector,
>   }
>  
>   index = sector >> SECTORS_PER_PAGE_SHIFT;
> - offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> + offset = (sector & (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;

sorry, can it actually produce different results?

-ss

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

[Logan Gunthorpe]

On 13/04/17 10:59 PM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
>> This is a straight forward conversion in two places. Should kmap fail,
>> the code will return an INVALD_DATA error in the completion.
> 
> It really should be using nvmet_copy_from_sgl to make things safer,
> as we don't want to rely on any particular SG list layout.  In fact
> I'm pretty sure I did the conversion at some point, but it must never
> have made it upstream.

Ha, I did the conversion too a couple times for my RFC series. I can
change this patch to do that. Or maybe I'll just send a patch for that
separately seeing it doesn't depend on anything and is pretty simple. I
can do that next week.

Thanks,

Logan

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

[Logan Gunthorpe]

On 13/04/17 10:59 PM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
>> This is a straight forward conversion in two places. Should kmap fail,
>> the code will return an INVALD_DATA error in the completion.
> 
> It really should be using nvmet_copy_from_sgl to make things safer,
> as we don't want to rely on any particular SG list layout.  In fact
> I'm pretty sure I did the conversion at some point, but it must never
> have made it upstream.

Ha, I did the conversion too a couple times for my RFC series. I can
change this patch to do that. Or maybe I'll just send a patch for that
separately seeing it doesn't depend on anything and is pretty simple. I
can do that next week.

Thanks,

Logan

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

[Christoph Hellwig]

On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
> This is a straight forward conversion in two places. Should kmap fail,
> the code will return an INVALD_DATA error in the completion.

It really should be using nvmet_copy_from_sgl to make things safer,
as we don't want to rely on any particular SG list layout.  In fact
I'm pretty sure I did the conversion at some point, but it must never
have made it upstream.

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

[Christoph Hellwig]

On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
> This is a straight forward conversion in two places. Should kmap fail,
> the code will return an INVALD_DATA error in the completion.

It really should be using nvmet_copy_from_sgl to make things safer,
as we don't want to rely on any particular SG list layout.  In fact
I'm pretty sure I did the conversion at some point, but it must never
have made it upstream.

Re: ARM64 TPM start method patches

[anjiandi]

Adding Harb Abdulhamid for SMC details

On 2017-04-11 06:36, Mark Rutland wrote:

Hi,

I just stumbled upon the following commits in next-20170411:

  cf8252ca7ca76fa4 ("ACPICA: Update TPM2 ACPI table")
  08eff49d63ca2bf4 ("tpm/tpm_crb: Enable TPM CRB interface for ARM64")

... which leave me a little concerned, for two reasons.

Firstly, the spec these are based on (TCG ACPI Specification Family
“1.2” and “2.0” Version 1.2, Revision 8), is a draft, open for public
review until April 28th 2017 [1], and still subject to change, as noted
in the title page of the document [2]:

This document is an intermediate draft for comment only and is
subject to change without notice. Readers should not design 
products

based on this document.

... so I hope the plan is not to merge these until the final spec is
published.

Secondly, the spec is very vague as to the workings of the SMC call, 
and

does not define:

 * That the SMC call follows the SMC Calling Convention [3]
 * The parameters to the SMC call
 * The return value(s) of the SMC call

... which I believe should be clarified in the spec before we make
assumptions regarding these in the Linux driver. Otherwise, this is
liable to vary in practice.

Thanks,
Mark.

[1] https://trustedcomputinggroup.org/specifications-public-review/
[2]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-reviepdf
[3]
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf

Re: [PATCH 1/2] phy: qcom-usb-hs: Replace the extcon API

[Kishon Vijay Abraham I]

hi Chanwoo,

On Friday 14 April 2017 06:13 AM, Chanwoo Choi wrote:
> Hi Kishon,
> 
> On 2017년 04월 13일 20:47, Kishon Vijay Abraham I wrote:
>> Hi Chanwoo,
>>
>> On Tuesday 28 March 2017 10:08 AM, Chanwoo Choi wrote:
>>> This patch uses the resource-managed extcon API for 
>>> extcon_register_notifier()
>>> and replaces the deprecated extcon API as following:
>>> - (deprecated) extcon_get_cable_state_() -> extcon_get_state()
>>>
>>> Cc: Kishon Vijay Abraham I 
>>> Signed-off-by: Chanwoo Choi 
>>
>> I've missed merging this patch for the next merge window. If you want to take
>> this yourself.
>> Acked-by: Kishon Vijay Abraham I 
> 
> I already posted the pull-request to GregKH for extcon subsystem.
> So, if possible, I hope you handle these patches.
> Even if these patches are not merged to 4.12-rc1, I'm ok. 
> Just I want to handle them on your tree for next time.

Sure, I'll take them then.

Thanks
Kishon

> 
>>
>> Thanks
>> Kishon
>>> ---
>>>  drivers/phy/phy-qcom-usb-hs.c | 14 +++---
>>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
>>> index 94dfbfd739c3..f630fa553b7d 100644
>>> --- a/drivers/phy/phy-qcom-usb-hs.c
>>> +++ b/drivers/phy/phy-qcom-usb-hs.c
>>> @@ -156,12 +156,12 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>> }
>>>  
>>> if (uphy->vbus_edev) {
>>> -   state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
>>> +   state = extcon_get_state(uphy->vbus_edev, EXTCON_USB);
>>> /* setup initial state */
>>> qcom_usb_hs_phy_vbus_notifier(>vbus_notify, state,
>>>   uphy->vbus_edev);
>>> -   ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
>>> -   >vbus_notify);
>>> +   ret = devm_extcon_register_notifier(>dev, uphy->vbus_edev,
>>> +   EXTCON_USB, >vbus_notify);
>>> if (ret)
>>> goto err_ulpi;
>>> }
>>> @@ -180,16 +180,8 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>>  
>>>  static int qcom_usb_hs_phy_power_off(struct phy *phy)
>>>  {
>>> -   int ret;
>>> struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>>>  
>>> -   if (uphy->vbus_edev) {
>>> -   ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
>>> ->vbus_notify);
>>> -   if (ret)
>>> -   return ret;
>>> -   }
>>> -
>>> regulator_disable(uphy->v3p3);
>>> regulator_disable(uphy->v1p8);
>>> clk_disable_unprepare(uphy->sleep_clk);
>>>
>>
>>
>>
> 
> 

Re: ARM64 TPM start method patches

[anjiandi]

Adding Harb Abdulhamid for SMC details

On 2017-04-11 06:36, Mark Rutland wrote:

Hi,

I just stumbled upon the following commits in next-20170411:

  cf8252ca7ca76fa4 ("ACPICA: Update TPM2 ACPI table")
  08eff49d63ca2bf4 ("tpm/tpm_crb: Enable TPM CRB interface for ARM64")

... which leave me a little concerned, for two reasons.

Firstly, the spec these are based on (TCG ACPI Specification Family
“1.2” and “2.0” Version 1.2, Revision 8), is a draft, open for public
review until April 28th 2017 [1], and still subject to change, as noted
in the title page of the document [2]:

This document is an intermediate draft for comment only and is
subject to change without notice. Readers should not design 
products

based on this document.

... so I hope the plan is not to merge these until the final spec is
published.

Secondly, the spec is very vague as to the workings of the SMC call, 
and

does not define:

 * That the SMC call follows the SMC Calling Convention [3]
 * The parameters to the SMC call
 * The return value(s) of the SMC call

... which I believe should be clarified in the spec before we make
assumptions regarding these in the Linux driver. Otherwise, this is
liable to vary in practice.

Thanks,
Mark.

[1] https://trustedcomputinggroup.org/specifications-public-review/
[2]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-reviepdf
[3]
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf

Re: [PATCH 1/2] phy: qcom-usb-hs: Replace the extcon API

[Kishon Vijay Abraham I]

hi Chanwoo,

On Friday 14 April 2017 06:13 AM, Chanwoo Choi wrote:
> Hi Kishon,
> 
> On 2017년 04월 13일 20:47, Kishon Vijay Abraham I wrote:
>> Hi Chanwoo,
>>
>> On Tuesday 28 March 2017 10:08 AM, Chanwoo Choi wrote:
>>> This patch uses the resource-managed extcon API for 
>>> extcon_register_notifier()
>>> and replaces the deprecated extcon API as following:
>>> - (deprecated) extcon_get_cable_state_() -> extcon_get_state()
>>>
>>> Cc: Kishon Vijay Abraham I 
>>> Signed-off-by: Chanwoo Choi 
>>
>> I've missed merging this patch for the next merge window. If you want to take
>> this yourself.
>> Acked-by: Kishon Vijay Abraham I 
> 
> I already posted the pull-request to GregKH for extcon subsystem.
> So, if possible, I hope you handle these patches.
> Even if these patches are not merged to 4.12-rc1, I'm ok. 
> Just I want to handle them on your tree for next time.

Sure, I'll take them then.

Thanks
Kishon

> 
>>
>> Thanks
>> Kishon
>>> ---
>>>  drivers/phy/phy-qcom-usb-hs.c | 14 +++---
>>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
>>> index 94dfbfd739c3..f630fa553b7d 100644
>>> --- a/drivers/phy/phy-qcom-usb-hs.c
>>> +++ b/drivers/phy/phy-qcom-usb-hs.c
>>> @@ -156,12 +156,12 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>> }
>>>  
>>> if (uphy->vbus_edev) {
>>> -   state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
>>> +   state = extcon_get_state(uphy->vbus_edev, EXTCON_USB);
>>> /* setup initial state */
>>> qcom_usb_hs_phy_vbus_notifier(>vbus_notify, state,
>>>   uphy->vbus_edev);
>>> -   ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
>>> -   >vbus_notify);
>>> +   ret = devm_extcon_register_notifier(>dev, uphy->vbus_edev,
>>> +   EXTCON_USB, >vbus_notify);
>>> if (ret)
>>> goto err_ulpi;
>>> }
>>> @@ -180,16 +180,8 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>>  
>>>  static int qcom_usb_hs_phy_power_off(struct phy *phy)
>>>  {
>>> -   int ret;
>>> struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>>>  
>>> -   if (uphy->vbus_edev) {
>>> -   ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
>>> ->vbus_notify);
>>> -   if (ret)
>>> -   return ret;
>>> -   }
>>> -
>>> regulator_disable(uphy->v3p3);
>>> regulator_disable(uphy->v1p8);
>>> clk_disable_unprepare(uphy->sleep_clk);
>>>
>>
>>
>>
> 
> 

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[PrasannaKumar Muralidharan]

On 14 April 2017 at 09:28, Sean Wang  wrote:
>
> Hi PrasannaKumar,
>
> Add my comments inline
>
>>
>> Use readl_poll_timeout_atomic's return value or -EIO instead of
>> !!ready. This will simplify mtk_rng_read.
>>
>
> !!ready provided is in order to let blocking/non-blocking case could
> share same code path. And readl_poll_timeout_atomic only handles
> blocking case.

Missed this point. Makes sense. My previous comment about return value
in mtk_rng_read is invalid as I based it on a wrong assumption.

>
>> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool 
>> > wait)
>> > +{
>> > +   struct mtk_rng *priv = to_mtk_rng(rng);
>> > +   int retval = 0;
>> > +
>> > +   while (max >= sizeof(u32)) {
>> > +   if (!mtk_rng_wait_ready(rng, wait))
>> > +   break;
>> > +
>> > +   *(u32 *)buf = readl(priv->base + RNG_DATA);
>> > +   retval += sizeof(u32);
>> > +   buf += sizeof(u32);
>> > +   max -= sizeof(u32);
>> > +   }
>> > +
>> > +   if (unlikely(wait && max))
>> > +   dev_warn(priv->dev, "timeout might be not properly set\n");
>>
>> Is this really necessary? Better to choose proper timeout than
>> providing this warning message. In rare cases if the timeout could
>> occur due to some reason (may be a hardware fault) print appropriate
>> warning message.
>
> It is good, I will choose the proper timeout and remove the log in the
> next one.
>
>>
>> > +   return retval || !wait ? retval : -EIO;
>> > +}
>>
>> Set retavl to mtk_rng_wait_ready and return retval.
>>
>
> Maybe i didn't get your points exactly. Adding some explanation about
> thoughts here.
>
> "return retval || !wait ? retval : -EIO;" I use can also help handling
> the both cases in one line which i think is elegant enough.
>
> And retval is accumulated with each round if some data's existing in
> hardware, so we don't return the value from mtk_rng_wait_ready().

retval can be 0 only when mkt_rng_wait_ready fails, returning 0 when
wait is true is confusing. Expected return value when 0 bytes is read
from device and wait is true is not clearly documented.

"return retval || !wait ? retval : -EIO;" is also fine.

Overall the code looks good to me. You can add:
Reviewed-by: PrasannaKumar Muralidharan .

Regards,
PrasannaKumar

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[PrasannaKumar Muralidharan]

On 14 April 2017 at 09:28, Sean Wang  wrote:
>
> Hi PrasannaKumar,
>
> Add my comments inline
>
>>
>> Use readl_poll_timeout_atomic's return value or -EIO instead of
>> !!ready. This will simplify mtk_rng_read.
>>
>
> !!ready provided is in order to let blocking/non-blocking case could
> share same code path. And readl_poll_timeout_atomic only handles
> blocking case.

Missed this point. Makes sense. My previous comment about return value
in mtk_rng_read is invalid as I based it on a wrong assumption.

>
>> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool 
>> > wait)
>> > +{
>> > +   struct mtk_rng *priv = to_mtk_rng(rng);
>> > +   int retval = 0;
>> > +
>> > +   while (max >= sizeof(u32)) {
>> > +   if (!mtk_rng_wait_ready(rng, wait))
>> > +   break;
>> > +
>> > +   *(u32 *)buf = readl(priv->base + RNG_DATA);
>> > +   retval += sizeof(u32);
>> > +   buf += sizeof(u32);
>> > +   max -= sizeof(u32);
>> > +   }
>> > +
>> > +   if (unlikely(wait && max))
>> > +   dev_warn(priv->dev, "timeout might be not properly set\n");
>>
>> Is this really necessary? Better to choose proper timeout than
>> providing this warning message. In rare cases if the timeout could
>> occur due to some reason (may be a hardware fault) print appropriate
>> warning message.
>
> It is good, I will choose the proper timeout and remove the log in the
> next one.
>
>>
>> > +   return retval || !wait ? retval : -EIO;
>> > +}
>>
>> Set retavl to mtk_rng_wait_ready and return retval.
>>
>
> Maybe i didn't get your points exactly. Adding some explanation about
> thoughts here.
>
> "return retval || !wait ? retval : -EIO;" I use can also help handling
> the both cases in one line which i think is elegant enough.
>
> And retval is accumulated with each round if some data's existing in
> hardware, so we don't return the value from mtk_rng_wait_ready().

retval can be 0 only when mkt_rng_wait_ready fails, returning 0 when
wait is true is confusing. Expected return value when 0 bytes is read
from device and wait is true is not clearly documented.

"return retval || !wait ? retval : -EIO;" is also fine.

Overall the code looks good to me. You can add:
Reviewed-by: PrasannaKumar Muralidharan .

Regards,
PrasannaKumar

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Sergey Senozhatsky]

Hello Petr,

thanks for taking a look!

On (04/13/17 16:03), Petr Mladek wrote:
> > +static inline bool console_offload_printing(void)
> > +{
> > +   static struct task_struct *printing_task = NULL;
> > +   static unsigned long lines_printed = 0;
> > +
> > +   if (!atomic_print_limit || !printk_kthread_enabled())
> > +   return false;
> > +
> > +   /* We rescheduled - reset the counters. */
> > +   if (printing_task != current) {
> > +   lines_printed = 0;
> > +   printing_task = current;
> > +   return false;
> > +   }
> 
> If we want to check that the process rescheduled, we should
> store/check also current->nvcsw + current->nivcsw.

ok.

[..]
> My only fear is that it is getting more and more complicated.
> On the other hand, any partial solution is asking for
> troubles and complains.

yeah. we have to aim slightly different and conflicting targets - introducing
a new printk behavior, while preserving an already existing guarantees. which
is a bit tricky.


[..]
> > +   if (lines_printed > 2 * (unsigned long)atomic_print_limit) {
> > +   printk_enforce_emergency = true;
> > +   pr_crit("Declaring printk emergency mode.\n");
> > +   return false;
> > +   }
> 
> The only messages that are printed on my workstation are the same
> few lines everytime I connect my phone over USB to get it charged.

you are right. this is a known and yet to be resolved issue.


> It might help to check the number of process switch counts as
> suggested above.

will take a look at your 'current->nvcsw + current->nivcsw' idea.
thanks.


[..]
> > +   /*
> > +* Sometimes we may lock console_sem before printk_kthread.
> > +* In this case we will jump to `again' label (if there are
> > +* pending messages), print one more line from current
> > +* process, break out of printing loop (we don't reset the
> > +* counter of printed lines) and do up_console_sem() to
> > +* wakeup printk_kthread again.
> > +*
> > +* If printk_kthread never wakes up (which may indicate that
> > +* the system is unstable or something weird is going on),
> > +* then we will keep jumping to `again' label and printing
> > +* one message from the logbuf. This is a bit ugly, but at
> > +* least we will print out the logbuf.
> > +*
> > +* If such condition occurs, console_offload_printing() can
> > +* declare `printk_emergency' at some point.
> 
> I am a bit confused by the comment above. The again goto target is
> used only when there is a race between leaving the loop and releasing
> the console_sem. It is a corner case.

not really.

this is the part where "preserve printk guarantees" jumps in.

when we limit the number of lines we can print we have to leave this loop
with not fully flushed logbuf. so `goto again' is not solely for corner
case anymore. when we prematurely leave the printing loop, we wake_up
printk_kthread, unlock console_sem... and then we have no idea if
printk_kthread going to wake_up at all, and, if it's going to, how much
time will it take. at the same time we have a task that is already in
console_unlock() and, probably, we still have pending messages in the logbuf.
that's why the process that just has left the printing loop [and there easily
might be pending messages in the logbuf] does the whole 'retry' thing. we can
have a misbehaving high priority process or something, that would prevent
printk_kthread from becoming running just when we need it. so, at least
sometimes, the printing process (the one that breaks ouf of printing loop
and wakes up printk_kthread) can re-acquire console_sem and print one more
line, then it up() console_sem, which, hopefully, will wake_up printk_kthread.
if printk_kthread did become running then if would be in console_sem wait
list at this point. if it didn't - then we

a) wake up some other process that is probably in console_sem list
   (hopefully there is one)

or

b) continue printing from the current process. because printk_kthread
   is still not running and there are no other processes that want to
   console_lock(). not much we can do at this point.


so in expected/normal scenario, we fail to re-acquire the console_sem lock
(console_trylock()), which means that either printk_kthread or some other
process from console_sem wait list acquired the console_sem and will take
over printing.


I do something like this

---
@@ -2427,6 +2427,8 @@ void console_unlock(void)
console_seq++;
raw_spin_unlock(_lock);
 
+   sprintf(text + 7, "{%s}", current->comm);
+
stop_critical_timings();/* don't trace print latency */
call_console_drivers(ext_text, ext_len, text, len);
start_critical_timings();
---


and fire up some silly printk 

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Sergey Senozhatsky]

Hello Petr,

thanks for taking a look!

On (04/13/17 16:03), Petr Mladek wrote:
> > +static inline bool console_offload_printing(void)
> > +{
> > +   static struct task_struct *printing_task = NULL;
> > +   static unsigned long lines_printed = 0;
> > +
> > +   if (!atomic_print_limit || !printk_kthread_enabled())
> > +   return false;
> > +
> > +   /* We rescheduled - reset the counters. */
> > +   if (printing_task != current) {
> > +   lines_printed = 0;
> > +   printing_task = current;
> > +   return false;
> > +   }
> 
> If we want to check that the process rescheduled, we should
> store/check also current->nvcsw + current->nivcsw.

ok.

[..]
> My only fear is that it is getting more and more complicated.
> On the other hand, any partial solution is asking for
> troubles and complains.

yeah. we have to aim slightly different and conflicting targets - introducing
a new printk behavior, while preserving an already existing guarantees. which
is a bit tricky.


[..]
> > +   if (lines_printed > 2 * (unsigned long)atomic_print_limit) {
> > +   printk_enforce_emergency = true;
> > +   pr_crit("Declaring printk emergency mode.\n");
> > +   return false;
> > +   }
> 
> The only messages that are printed on my workstation are the same
> few lines everytime I connect my phone over USB to get it charged.

you are right. this is a known and yet to be resolved issue.


> It might help to check the number of process switch counts as
> suggested above.

will take a look at your 'current->nvcsw + current->nivcsw' idea.
thanks.


[..]
> > +   /*
> > +* Sometimes we may lock console_sem before printk_kthread.
> > +* In this case we will jump to `again' label (if there are
> > +* pending messages), print one more line from current
> > +* process, break out of printing loop (we don't reset the
> > +* counter of printed lines) and do up_console_sem() to
> > +* wakeup printk_kthread again.
> > +*
> > +* If printk_kthread never wakes up (which may indicate that
> > +* the system is unstable or something weird is going on),
> > +* then we will keep jumping to `again' label and printing
> > +* one message from the logbuf. This is a bit ugly, but at
> > +* least we will print out the logbuf.
> > +*
> > +* If such condition occurs, console_offload_printing() can
> > +* declare `printk_emergency' at some point.
> 
> I am a bit confused by the comment above. The again goto target is
> used only when there is a race between leaving the loop and releasing
> the console_sem. It is a corner case.

not really.

this is the part where "preserve printk guarantees" jumps in.

when we limit the number of lines we can print we have to leave this loop
with not fully flushed logbuf. so `goto again' is not solely for corner
case anymore. when we prematurely leave the printing loop, we wake_up
printk_kthread, unlock console_sem... and then we have no idea if
printk_kthread going to wake_up at all, and, if it's going to, how much
time will it take. at the same time we have a task that is already in
console_unlock() and, probably, we still have pending messages in the logbuf.
that's why the process that just has left the printing loop [and there easily
might be pending messages in the logbuf] does the whole 'retry' thing. we can
have a misbehaving high priority process or something, that would prevent
printk_kthread from becoming running just when we need it. so, at least
sometimes, the printing process (the one that breaks ouf of printing loop
and wakes up printk_kthread) can re-acquire console_sem and print one more
line, then it up() console_sem, which, hopefully, will wake_up printk_kthread.
if printk_kthread did become running then if would be in console_sem wait
list at this point. if it didn't - then we

a) wake up some other process that is probably in console_sem list
   (hopefully there is one)

or

b) continue printing from the current process. because printk_kthread
   is still not running and there are no other processes that want to
   console_lock(). not much we can do at this point.


so in expected/normal scenario, we fail to re-acquire the console_sem lock
(console_trylock()), which means that either printk_kthread or some other
process from console_sem wait list acquired the console_sem and will take
over printing.


I do something like this

---
@@ -2427,6 +2427,8 @@ void console_unlock(void)
console_seq++;
raw_spin_unlock(_lock);
 
+   sprintf(text + 7, "{%s}", current->comm);
+
stop_critical_timings();/* don't trace print latency */
call_console_drivers(ext_text, ext_len, text, len);
start_critical_timings();
---


and fire up some silly printk 

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> I'd suggest just detecting if there is any translation in bus
> addresses anywhere and just hard disabling P2P on such systems.

That's a fantastic suggestion. It simplifies things significantly.
Unless there are any significant objections I think I will plan on doing
that.

> On modern hardware with 64 bit BARs there is very little reason to
> have translation, so I think this is a legacy feature.

Yes, p2pmem users are likely to be designing systems around it (ie
JBOFs) and not trying to shoehorn it onto legacy architectures.

At the very least, it makes sense to leave it out and if someone comes
along who cares they can put in the effort to support the address
translation.

Thanks,

Logan

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> I'd suggest just detecting if there is any translation in bus
> addresses anywhere and just hard disabling P2P on such systems.

That's a fantastic suggestion. It simplifies things significantly.
Unless there are any significant objections I think I will plan on doing
that.

> On modern hardware with 64 bit BARs there is very little reason to
> have translation, so I think this is a legacy feature.

Yes, p2pmem users are likely to be designing systems around it (ie
JBOFs) and not trying to shoehorn it onto legacy architectures.

At the very least, it makes sense to leave it out and if someone comes
along who cares they can put in the effort to support the address
translation.

Thanks,

Logan

[PATCH] drivers: input: joystick: Add PSX(Play Staion 1/2) pad with SPI driver Add PSX(Play Staion 1/2) pad with SPI driver. Pads can be connected directry SPI bus.

[AZO]

---
 drivers/input/joystick/Kconfig  |  11 +-
 drivers/input/joystick/Makefile |   1 +
 drivers/input/joystick/psxpad-spi.c | 679 
 3 files changed, 690 insertions(+), 1 deletion(-)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 4215b53..6e38a74 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -330,4 +330,13 @@ config JOYSTICK_MAPLE
  To compile this as a module choose M here: the module will be called
  maplecontrol.
 
-endif
+config JOYSTICK_PSXPAD_SPI
+   tristate "PSX(Play Station 1/2) pad with SPI Bus Driver"
+   depends on INPUT_POLLDEV && SPI
+   help
+ Say Y here if you connect PSX(PS1/2) pad with SPI Interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called psxpad-spi.
+
+endifendif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 92dc0de..2b71848 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_JOYSTICK_WARRIOR)+= warrior.o
 obj-$(CONFIG_JOYSTICK_XPAD)+= xpad.o
 obj-$(CONFIG_JOYSTICK_ZHENHUA) += zhenhua.o
 obj-$(CONFIG_JOYSTICK_WALKERA0701) += walkera0701.o
+obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)  += psxpad-spi.o
 
diff --git a/drivers/input/joystick/psxpad-spi.c 
b/drivers/input/joystick/psxpad-spi.c
new file mode 100644
index 000..c5b497b
--- /dev/null
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -0,0 +1,679 @@
+/*
+ * PSX(Play Station 1/2) pad (SPI Interface)
+ *
+ * Copyright (C) 2017 AZO 
+ * Licensed under the GPL-2 or later.
+ *
+ * PSX pad plug (not socket)
+ *  123 456 789
+ * (...|...|...)
+ *
+ * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
+ * 2: CMD -> MOSI
+ * 3: 9V (for motor, if not use N.C.)
+ * 4: GND
+ * 5: 3.3V
+ * 6: Attention -> CS(SS)
+ * 7: SCK -> SCK
+ * 8: N.C.
+ * 9: ACK -> N.C.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+//#define PSXPAD_ENABLE_ANALOG2
+#define PSXPAD_ENABLE_FF
+
+enum {
+   PSXPAD_SPI_SPEED_125KHZ = 0,
+   PSXPAD_SPI_SPEED_250KHZ,
+   PSXPAD_SPI_SPEED_500KHZ,
+   PSXPAD_SPI_SPEED_UNKNOWN
+};
+
+#define PSXPAD_DEFAULT_SPI_DELAY   100
+#define PSXPAD_DEFAULT_SPI_SPEED   PSXPAD_SPI_SPEED_125KHZ
+#define PSXPAD_DEFAULT_INTERVAL16
+#define PSXPAD_DEFAULT_INTERVAL_MIN8
+#define PSXPAD_DEFAULT_INTERVAL_MAX32
+#define PSXPAD_DEFAULT_ADMODE  true
+#define PSXPAD_DEFAULT_INPUT_PHYSIZE   32
+
+#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | (((x) & 
0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | (((x) & 0x04) << 3) | 
(((x) & 0x02) << 5) | (((x) & 0x01) << 7))
+
+enum {
+   PSXPAD_KEYSTATE_TYPE_DIGITAL = 0,
+   PSXPAD_KEYSTATE_TYPE_ANALOG1,
+#ifdef PSXPAD_ENABLE_ANALOG2
+   PSXPAD_KEYSTATE_TYPE_ANALOG2,
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+   PSXPAD_KEYSTATE_TYPE_UNKNOWN
+};
+
+#ifdef PSXPAD_ENABLE_ANALOG2
+static const u8 PSX_CMD_INIT_PRESSURE[]= {0x01, 0x40, 0x00, 0x00, 
0x02, 0x00, 0x00, 0x00, 0x00};
+static const u8 PSX_CMD_ALL_PRESSURE[] = {0x01, 0x4F, 0x00, 0xFF, 0xFF, 0x03, 
0x00, 0x00, 0x00};
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+static const u8 PSX_CMD_POLL[] = {0x01, 0x42, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00};
+static const u8 PSX_CMD_ENTER_CFG[]= {0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 
0x00, 0x00, 0x00};
+static const u8 PSX_CMD_EXIT_CFG[] = {0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 
0x5A, 0x5A, 0x5A};
+static const u8 PSX_CMD_ENABLE_MOTOR[] = {0x01, 0x4D, 0x00, 0xFF, 0xFF, 0xFF, 
0xFF, 0xFF, 0xFF};
+static const u8 PSX_CMD_AD_MODE[]  = {0x01, 0x44, 0x00, 0x01, 0x00, 0x00, 
0x00, 0x00, 0x00};
+
+struct psxpad_keystate {
+   int type;
+   /* PSXPAD_KEYSTATE_TYPE_DIGITAL */
+   bool select;
+   bool start;
+   bool up;
+   bool right;
+   bool down;
+   bool left;
+   bool l2;
+   bool r2;
+   bool l1;
+   bool r1;
+   bool triangle;
+   bool circle;
+   bool cross;
+   bool square;
+   /* PSXPAD_KEYSTATE_TYPE_ANALOG1 */
+   u8 l3;
+   u8 r3;
+   u8 lx;
+   u8 ly;
+   u8 rx;
+   u8 ry;
+#ifdef PSXPAD_ENABLE_ANALOG2
+   /* PSXPAD_KEYSTATE_TYPE_ANALOG2 */
+   u8 a_right;
+   u8 a_left;
+   u8 a_up;
+   u8 a_down;
+   u8 a_triangle;
+   u8 a_circle;
+   u8 a_cross;
+   u8 a_square;
+   u8 a_l1;
+   u8 a_r1;
+   u8 a_l2;
+   u8 a_r2;
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+};
+
+struct psxpad {
+   struct spi_device *spi;
+   struct input_polled_dev *pdev;
+   struct input_dev *idev;
+   char phys[PSXPAD_DEFAULT_INPUT_PHYSIZE];
+   

[PATCH] drivers: input: joystick: Add PSX(Play Staion 1/2) pad with SPI driver Add PSX(Play Staion 1/2) pad with SPI driver. Pads can be connected directry SPI bus.

[AZO]

---
 drivers/input/joystick/Kconfig  |  11 +-
 drivers/input/joystick/Makefile |   1 +
 drivers/input/joystick/psxpad-spi.c | 679 
 3 files changed, 690 insertions(+), 1 deletion(-)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 4215b53..6e38a74 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -330,4 +330,13 @@ config JOYSTICK_MAPLE
  To compile this as a module choose M here: the module will be called
  maplecontrol.
 
-endif
+config JOYSTICK_PSXPAD_SPI
+   tristate "PSX(Play Station 1/2) pad with SPI Bus Driver"
+   depends on INPUT_POLLDEV && SPI
+   help
+ Say Y here if you connect PSX(PS1/2) pad with SPI Interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called psxpad-spi.
+
+endifendif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 92dc0de..2b71848 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_JOYSTICK_WARRIOR)+= warrior.o
 obj-$(CONFIG_JOYSTICK_XPAD)+= xpad.o
 obj-$(CONFIG_JOYSTICK_ZHENHUA) += zhenhua.o
 obj-$(CONFIG_JOYSTICK_WALKERA0701) += walkera0701.o
+obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)  += psxpad-spi.o
 
diff --git a/drivers/input/joystick/psxpad-spi.c 
b/drivers/input/joystick/psxpad-spi.c
new file mode 100644
index 000..c5b497b
--- /dev/null
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -0,0 +1,679 @@
+/*
+ * PSX(Play Station 1/2) pad (SPI Interface)
+ *
+ * Copyright (C) 2017 AZO 
+ * Licensed under the GPL-2 or later.
+ *
+ * PSX pad plug (not socket)
+ *  123 456 789
+ * (...|...|...)
+ *
+ * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
+ * 2: CMD -> MOSI
+ * 3: 9V (for motor, if not use N.C.)
+ * 4: GND
+ * 5: 3.3V
+ * 6: Attention -> CS(SS)
+ * 7: SCK -> SCK
+ * 8: N.C.
+ * 9: ACK -> N.C.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+//#define PSXPAD_ENABLE_ANALOG2
+#define PSXPAD_ENABLE_FF
+
+enum {
+   PSXPAD_SPI_SPEED_125KHZ = 0,
+   PSXPAD_SPI_SPEED_250KHZ,
+   PSXPAD_SPI_SPEED_500KHZ,
+   PSXPAD_SPI_SPEED_UNKNOWN
+};
+
+#define PSXPAD_DEFAULT_SPI_DELAY   100
+#define PSXPAD_DEFAULT_SPI_SPEED   PSXPAD_SPI_SPEED_125KHZ
+#define PSXPAD_DEFAULT_INTERVAL16
+#define PSXPAD_DEFAULT_INTERVAL_MIN8
+#define PSXPAD_DEFAULT_INTERVAL_MAX32
+#define PSXPAD_DEFAULT_ADMODE  true
+#define PSXPAD_DEFAULT_INPUT_PHYSIZE   32
+
+#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | (((x) & 
0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | (((x) & 0x04) << 3) | 
(((x) & 0x02) << 5) | (((x) & 0x01) << 7))
+
+enum {
+   PSXPAD_KEYSTATE_TYPE_DIGITAL = 0,
+   PSXPAD_KEYSTATE_TYPE_ANALOG1,
+#ifdef PSXPAD_ENABLE_ANALOG2
+   PSXPAD_KEYSTATE_TYPE_ANALOG2,
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+   PSXPAD_KEYSTATE_TYPE_UNKNOWN
+};
+
+#ifdef PSXPAD_ENABLE_ANALOG2
+static const u8 PSX_CMD_INIT_PRESSURE[]= {0x01, 0x40, 0x00, 0x00, 
0x02, 0x00, 0x00, 0x00, 0x00};
+static const u8 PSX_CMD_ALL_PRESSURE[] = {0x01, 0x4F, 0x00, 0xFF, 0xFF, 0x03, 
0x00, 0x00, 0x00};
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+static const u8 PSX_CMD_POLL[] = {0x01, 0x42, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00};
+static const u8 PSX_CMD_ENTER_CFG[]= {0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 
0x00, 0x00, 0x00};
+static const u8 PSX_CMD_EXIT_CFG[] = {0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 
0x5A, 0x5A, 0x5A};
+static const u8 PSX_CMD_ENABLE_MOTOR[] = {0x01, 0x4D, 0x00, 0xFF, 0xFF, 0xFF, 
0xFF, 0xFF, 0xFF};
+static const u8 PSX_CMD_AD_MODE[]  = {0x01, 0x44, 0x00, 0x01, 0x00, 0x00, 
0x00, 0x00, 0x00};
+
+struct psxpad_keystate {
+   int type;
+   /* PSXPAD_KEYSTATE_TYPE_DIGITAL */
+   bool select;
+   bool start;
+   bool up;
+   bool right;
+   bool down;
+   bool left;
+   bool l2;
+   bool r2;
+   bool l1;
+   bool r1;
+   bool triangle;
+   bool circle;
+   bool cross;
+   bool square;
+   /* PSXPAD_KEYSTATE_TYPE_ANALOG1 */
+   u8 l3;
+   u8 r3;
+   u8 lx;
+   u8 ly;
+   u8 rx;
+   u8 ry;
+#ifdef PSXPAD_ENABLE_ANALOG2
+   /* PSXPAD_KEYSTATE_TYPE_ANALOG2 */
+   u8 a_right;
+   u8 a_left;
+   u8 a_up;
+   u8 a_down;
+   u8 a_triangle;
+   u8 a_circle;
+   u8 a_cross;
+   u8 a_square;
+   u8 a_l1;
+   u8 a_r1;
+   u8 a_l2;
+   u8 a_r2;
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+};
+
+struct psxpad {
+   struct spi_device *spi;
+   struct input_polled_dev *pdev;
+   struct input_dev *idev;
+   char phys[PSXPAD_DEFAULT_INPUT_PHYSIZE];
+   u16 spi_delay;
+ 

Re: [patch 02/13] workqueue: Provide work_on_cpu_safe()

[Tejun Heo]

On Wed, Apr 12, 2017 at 10:07:28PM +0200, Thomas Gleixner wrote:
> work_on_cpu() is not protected against CPU hotplug. For code which requires
> to be either executed on an online CPU or to fail if the CPU is not
> available the callsite would have to protect against CPU hotplug.
> 
> Provide a function which does get/put_online_cpus() around the call to
> work_on_cpu() and fails the call with -ENODEV if the target CPU is not
> online.
> 
> Preparatory patch to convert several racy task affinity manipulations.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Tejun Heo 
> Cc: Lai Jiangshan 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

Re: [patch 02/13] workqueue: Provide work_on_cpu_safe()

[Tejun Heo]

On Wed, Apr 12, 2017 at 10:07:28PM +0200, Thomas Gleixner wrote:
> work_on_cpu() is not protected against CPU hotplug. For code which requires
> to be either executed on an online CPU or to fail if the CPU is not
> available the callsite would have to protect against CPU hotplug.
> 
> Provide a function which does get/put_online_cpus() around the call to
> work_on_cpu() and fails the call with -ENODEV if the target CPU is not
> online.
> 
> Preparatory patch to convert several racy task affinity manipulations.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Tejun Heo 
> Cc: Lai Jiangshan 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

Re: [PATCH] hugetlbfs: fix offset overflow in huegtlbfs mmap

[Naoya Horiguchi]

On Tue, Apr 11, 2017 at 03:51:58PM -0700, Mike Kravetz wrote:
...
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 7163fe0..dde8613 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -136,17 +136,26 @@ static int hugetlbfs_file_mmap(struct file *file, 
> struct vm_area_struct *vma)
>   vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND;
>   vma->vm_ops = _vm_ops;
>  
> + /*
> +  * Offset passed to mmap (before page shift) could have been
> +  * negative when represented as a (l)off_t.
> +  */
> + if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
> + return -EINVAL;
> +
>   if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
>   return -EINVAL;
>  
>   vma_len = (loff_t)(vma->vm_end - vma->vm_start);
> + len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> + /* check for overflow */
> + if (len < vma_len)
> + return -EINVAL;

Andrew sent this patch to Linus today, so I know it's a little too late, but
I think that getting len directly from vma like below might be a simpler fix.

  len = (loff_t)(vma->vm_end - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT)); 

This shouldn't overflow because vma->vm_{end|start|pgoff} are unsigned long,
but if worried you can add VM_BUG_ON_VMA(len < 0, vma).

Thanks,
Naoya Horiguchi

>  
>   inode_lock(inode);
>   file_accessed(file);
>  
>   ret = -ENOMEM;
> - len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> -
>   if (hugetlb_reserve_pages(inode,
>   vma->vm_pgoff >> huge_page_order(h),
>   len >> huge_page_shift(h), vma,
> @@ -155,7 +164,7 @@ static int hugetlbfs_file_mmap(struct file *file, struct 
> vm_area_struct *vma)
>  
>   ret = 0;
>   if (vma->vm_flags & VM_WRITE && inode->i_size < len)
> - inode->i_size = len;
> + i_size_write(inode, len);
>  out:
>   inode_unlock(inode);
>  
> -- 
> 2.7.4
> 
> 

Re: [PATCH] hugetlbfs: fix offset overflow in huegtlbfs mmap

[Naoya Horiguchi]

On Tue, Apr 11, 2017 at 03:51:58PM -0700, Mike Kravetz wrote:
...
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 7163fe0..dde8613 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -136,17 +136,26 @@ static int hugetlbfs_file_mmap(struct file *file, 
> struct vm_area_struct *vma)
>   vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND;
>   vma->vm_ops = _vm_ops;
>  
> + /*
> +  * Offset passed to mmap (before page shift) could have been
> +  * negative when represented as a (l)off_t.
> +  */
> + if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
> + return -EINVAL;
> +
>   if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
>   return -EINVAL;
>  
>   vma_len = (loff_t)(vma->vm_end - vma->vm_start);
> + len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> + /* check for overflow */
> + if (len < vma_len)
> + return -EINVAL;

Andrew sent this patch to Linus today, so I know it's a little too late, but
I think that getting len directly from vma like below might be a simpler fix.

  len = (loff_t)(vma->vm_end - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT)); 

This shouldn't overflow because vma->vm_{end|start|pgoff} are unsigned long,
but if worried you can add VM_BUG_ON_VMA(len < 0, vma).

Thanks,
Naoya Horiguchi

>  
>   inode_lock(inode);
>   file_accessed(file);
>  
>   ret = -ENOMEM;
> - len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> -
>   if (hugetlb_reserve_pages(inode,
>   vma->vm_pgoff >> huge_page_order(h),
>   len >> huge_page_shift(h), vma,
> @@ -155,7 +164,7 @@ static int hugetlbfs_file_mmap(struct file *file, struct 
> vm_area_struct *vma)
>  
>   ret = 0;
>   if (vma->vm_flags & VM_WRITE && inode->i_size < len)
> - inode->i_size = len;
> + i_size_write(inode, len);
>  out:
>   inode_unlock(inode);
>  
> -- 
> 2.7.4
> 
> 

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Jason Gunthorpe]

On Thu, Apr 13, 2017 at 06:26:31PM -0500, Bjorn Helgaas wrote:
> > Ah, thanks for the tip! On my system, this translation returns the same
> > address so it was not necessary. And, yes, that means this would have to
> > find its way into the dma mapping routine somehow. This means we'll
> > eventually need a way to look-up the p2pmem device from the struct page.
> > Which means we will likely need a new flag bit in the struct page or
> > something. The big difficulty I see is testing. Do you know what
> > architectures or in what circumstances are these translations used?
> 
> Any caller of pci_add_resource_offset() uses CPU addresses different from
> the PCI bus addresses (unless the offset is zero, of course).  All ACPI
> platforms also support this translation (see "translation_offset"), though
> in most x86 systems the offset is zero.  I'm aware of one x86 system that
> was tested with a non-zero offset but I don't think it was shipped that
> way.

I'd suggest just detecting if there is any translation in bus
addresses anywhere and just hard disabling P2P on such systems.

On modern hardware with 64 bit BARs there is very little reason to
have translation, so I think this is a legacy feature.

Jason

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Jason Gunthorpe]

On Thu, Apr 13, 2017 at 06:26:31PM -0500, Bjorn Helgaas wrote:
> > Ah, thanks for the tip! On my system, this translation returns the same
> > address so it was not necessary. And, yes, that means this would have to
> > find its way into the dma mapping routine somehow. This means we'll
> > eventually need a way to look-up the p2pmem device from the struct page.
> > Which means we will likely need a new flag bit in the struct page or
> > something. The big difficulty I see is testing. Do you know what
> > architectures or in what circumstances are these translations used?
> 
> Any caller of pci_add_resource_offset() uses CPU addresses different from
> the PCI bus addresses (unless the offset is zero, of course).  All ACPI
> platforms also support this translation (see "translation_offset"), though
> in most x86 systems the offset is zero.  I'm aware of one x86 system that
> was tested with a non-zero offset but I don't think it was shipped that
> way.

I'd suggest just detecting if there is any translation in bus
addresses anywhere and just hard disabling P2P on such systems.

On modern hardware with 64 bit BARs there is very little reason to
have translation, so I think this is a legacy feature.

Jason

Re: [PATCH] powerpc/mm: Fix missing page attributes in page table dump

[kbuild test robot]

Hi Christophe,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.11-rc6 next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-mm-Fix-missing-page-attributes-in-page-table-dump/20170414-013347
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

>> arch/powerpc/mm/dump_linuxpagetables.c:212:11: error: '_PAGE_SHARED' 
>> undeclared here (not in a function)
  .mask = _PAGE_SHARED,
  ^~~~

vim +/_PAGE_SHARED +212 arch/powerpc/mm/dump_linuxpagetables.c

   206  }, {
   207  #endif
   208  .mask   = _PAGE_SPECIAL,
   209  .val= _PAGE_SPECIAL,
   210  .set= "special",
   211  }, {
 > 212  .mask   = _PAGE_SHARED,
   213  .val= _PAGE_SHARED,
   214  .set= "shared",
   215  }

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


.config.gz
Description: application/gzip

Re: [PATCH] powerpc/mm: Fix missing page attributes in page table dump

[kbuild test robot]

Hi Christophe,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.11-rc6 next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-mm-Fix-missing-page-attributes-in-page-table-dump/20170414-013347
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

>> arch/powerpc/mm/dump_linuxpagetables.c:212:11: error: '_PAGE_SHARED' 
>> undeclared here (not in a function)
  .mask = _PAGE_SHARED,
  ^~~~

vim +/_PAGE_SHARED +212 arch/powerpc/mm/dump_linuxpagetables.c

   206  }, {
   207  #endif
   208  .mask   = _PAGE_SPECIAL,
   209  .val= _PAGE_SPECIAL,
   210  .set= "special",
   211  }, {
 > 212  .mask   = _PAGE_SHARED,
   213  .val= _PAGE_SHARED,
   214  .set= "shared",
   215  }

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


.config.gz
Description: application/gzip

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[Sean Wang]

Hi PrasannaKumar,

Add my comments inline


On Thu, 2017-04-13 at 14:09 +0530, PrasannaKumar Muralidharan wrote:
> Hi Sean,
> 
> Mostly looks good, have few minor comments.
> 
> On 13 April 2017 at 12:35,   wrote:
> > +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   int ready;
> > +
> > +   ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> > +   if (!ready && wait)
> > +   readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> > + ready & RNG_READY, USEC_POLL,
> > + TIMEOUT_POLL);
> > +   return !!ready;
> > +}
> 
> Use readl_poll_timeout_atomic's return value or -EIO instead of
> !!ready. This will simplify mtk_rng_read.
> 

!!ready provided is in order to let blocking/non-blocking case could
share same code path. And readl_poll_timeout_atomic only handles
blocking case.



> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool 
> > wait)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   int retval = 0;
> > +
> > +   while (max >= sizeof(u32)) {
> > +   if (!mtk_rng_wait_ready(rng, wait))
> > +   break;
> > +
> > +   *(u32 *)buf = readl(priv->base + RNG_DATA);
> > +   retval += sizeof(u32);
> > +   buf += sizeof(u32);
> > +   max -= sizeof(u32);
> > +   }
> > +
> > +   if (unlikely(wait && max))
> > +   dev_warn(priv->dev, "timeout might be not properly set\n");
> 
> Is this really necessary? Better to choose proper timeout than
> providing this warning message. In rare cases if the timeout could
> occur due to some reason (may be a hardware fault) print appropriate
> warning message.

It is good, I will choose the proper timeout and remove the log in the
next one.

> 
> > +   return retval || !wait ? retval : -EIO;
> > +}
> 
> Set retavl to mtk_rng_wait_ready and return retval.
> 

Maybe i didn't get your points exactly. Adding some explanation about
thoughts here.

"return retval || !wait ? retval : -EIO;" I use can also help handling
the both cases in one line which i think is elegant enough. 

And retval is accumulated with each round if some data's existing in
hardware, so we don't return the value from mtk_rng_wait_ready().


> Regards,
> Prasanna

thanks for all your reviewing and suggestion

Sean

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[Sean Wang]

Hi PrasannaKumar,

Add my comments inline


On Thu, 2017-04-13 at 14:09 +0530, PrasannaKumar Muralidharan wrote:
> Hi Sean,
> 
> Mostly looks good, have few minor comments.
> 
> On 13 April 2017 at 12:35,   wrote:
> > +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   int ready;
> > +
> > +   ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> > +   if (!ready && wait)
> > +   readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> > + ready & RNG_READY, USEC_POLL,
> > + TIMEOUT_POLL);
> > +   return !!ready;
> > +}
> 
> Use readl_poll_timeout_atomic's return value or -EIO instead of
> !!ready. This will simplify mtk_rng_read.
> 

!!ready provided is in order to let blocking/non-blocking case could
share same code path. And readl_poll_timeout_atomic only handles
blocking case.



> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool 
> > wait)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   int retval = 0;
> > +
> > +   while (max >= sizeof(u32)) {
> > +   if (!mtk_rng_wait_ready(rng, wait))
> > +   break;
> > +
> > +   *(u32 *)buf = readl(priv->base + RNG_DATA);
> > +   retval += sizeof(u32);
> > +   buf += sizeof(u32);
> > +   max -= sizeof(u32);
> > +   }
> > +
> > +   if (unlikely(wait && max))
> > +   dev_warn(priv->dev, "timeout might be not properly set\n");
> 
> Is this really necessary? Better to choose proper timeout than
> providing this warning message. In rare cases if the timeout could
> occur due to some reason (may be a hardware fault) print appropriate
> warning message.

It is good, I will choose the proper timeout and remove the log in the
next one.

> 
> > +   return retval || !wait ? retval : -EIO;
> > +}
> 
> Set retavl to mtk_rng_wait_ready and return retval.
> 

Maybe i didn't get your points exactly. Adding some explanation about
thoughts here.

"return retval || !wait ? retval : -EIO;" I use can also help handling
the both cases in one line which i think is elegant enough. 

And retval is accumulated with each round if some data's existing in
hardware, so we don't return the value from mtk_rng_wait_ready().


> Regards,
> Prasanna

thanks for all your reviewing and suggestion

Sean

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

[Gary Lin]

On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote:
> On April 11, 2017 3:20:41 AM PDT, Gary Lin  wrote:
> >This commit adds the new config options to allow the user to modify the
> >following fields in the PE-COFF header.
> >
> >UINT16 MajorOperatingSystemVersion
> >UINT16 MinorOperatingSystemVersion
> >UINT16 MajorImageVersion
> >UINT16 MinorImageVersion
> >
> >Those fields are mainly for the executables or libraries in Windows NT
> >or higher to specify the minimum supported Windows version and the
> >version of the image itself.
> >
> >Given the fact that those fields are ignored in UEFI, we can safely
> >reuse
> >those fields for other purposes, e.g. Security Version(*).
> >
> >(*) https://github.com/lcp/shim/wiki/Security-Version
> >
> >Cc: Thomas Gleixner 
> >Cc: Ingo Molnar 
> >Cc: "H. Peter Anvin" 
> >Cc: Masahiro Yamada 
> >Cc: Michal Marek 
> >Cc: Matt Fleming 
> >Cc: Ard Biesheuvel 
> >Cc: Joey Lee 
> >Cc: Vojtech Pavlik 
> >Signed-off-by: Gary Lin 
> >Tested-by: Joey Lee 
> >---
[snip]
> 
> Reusing PECOFF fields seems doubleplusunsafe: we don't own those fields, the 
> UEFI forum does.  It would make a lot more sense to add these fields to the 
> bzImage header directly or indirectly (via a pointer), the latter would be 
> more economical since the bzImage header size is bounded.
> 
> We could even define it as a pointer to a "security information header" with 
> its own size field, so it can be grown in the future as needed.
Reusing PE-COFF simplifies the implementation since shim can parse the
header directly. I can raise the issue to the UEFI forum to clarify the
usage of those fields.

Meanwhile, I'll also look into the bzImage header in case the PE-COFF
header is really a NO-GO.

Thanks,

Gary Lin

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

[Gary Lin]

On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote:
> On April 11, 2017 3:20:41 AM PDT, Gary Lin  wrote:
> >This commit adds the new config options to allow the user to modify the
> >following fields in the PE-COFF header.
> >
> >UINT16 MajorOperatingSystemVersion
> >UINT16 MinorOperatingSystemVersion
> >UINT16 MajorImageVersion
> >UINT16 MinorImageVersion
> >
> >Those fields are mainly for the executables or libraries in Windows NT
> >or higher to specify the minimum supported Windows version and the
> >version of the image itself.
> >
> >Given the fact that those fields are ignored in UEFI, we can safely
> >reuse
> >those fields for other purposes, e.g. Security Version(*).
> >
> >(*) https://github.com/lcp/shim/wiki/Security-Version
> >
> >Cc: Thomas Gleixner 
> >Cc: Ingo Molnar 
> >Cc: "H. Peter Anvin" 
> >Cc: Masahiro Yamada 
> >Cc: Michal Marek 
> >Cc: Matt Fleming 
> >Cc: Ard Biesheuvel 
> >Cc: Joey Lee 
> >Cc: Vojtech Pavlik 
> >Signed-off-by: Gary Lin 
> >Tested-by: Joey Lee 
> >---
[snip]
> 
> Reusing PECOFF fields seems doubleplusunsafe: we don't own those fields, the 
> UEFI forum does.  It would make a lot more sense to add these fields to the 
> bzImage header directly or indirectly (via a pointer), the latter would be 
> more economical since the bzImage header size is bounded.
> 
> We could even define it as a pointer to a "security information header" with 
> its own size field, so it can be grown in the future as needed.
Reusing PE-COFF simplifies the implementation since shim can parse the
header directly. I can raise the issue to the UEFI forum to clarify the
usage of those fields.

Meanwhile, I'll also look into the bzImage header in case the PE-COFF
header is really a NO-GO.

Thanks,

Gary Lin

Re: [PATCH 8/8] ARM: dts: imx7d-sdb: Enable PCIe peripheral

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:42AM -0700, Andrey Smirnov wrote:
> Enable PCIe peripheral on this board.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7d-sdb.dts | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index e0ff276..f77e26a 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -352,6 +352,13 @@
>   };
>  };
>  
> + {
> + pinctrl-names = "default";
> + reset-gpio = <_spi 1 GPIO_ACTIVE_LOW>;
> + disable-gpio = <_spi 0 GPIO_ACTIVE_LOW>;

I do not see this disable-gpio is documented or supported.

Shawn

> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pwm1>;
> -- 
> 2.9.3
> 

Re: [PATCH 8/8] ARM: dts: imx7d-sdb: Enable PCIe peripheral

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:42AM -0700, Andrey Smirnov wrote:
> Enable PCIe peripheral on this board.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7d-sdb.dts | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index e0ff276..f77e26a 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -352,6 +352,13 @@
>   };
>  };
>  
> + {
> + pinctrl-names = "default";
> + reset-gpio = <_spi 1 GPIO_ACTIVE_LOW>;
> + disable-gpio = <_spi 0 GPIO_ACTIVE_LOW>;

I do not see this disable-gpio is documented or supported.

Shawn

> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pwm1>;
> -- 
> 2.9.3
> 

Re: [PATCH 6/8] ARM: dts: imx7d-sdb: Add GPIO expander node

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:40AM -0700, Andrey Smirnov wrote:
> Add node for U38, a 74LV595PW serial-in shift register that acts as a
> GPIO expander on the board.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7d-sdb.dts | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 5be01a1..e0ff276 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -52,6 +52,30 @@
>   reg = <0x8000 0x8000>;
>   };
>  
> + spi4 {
> + compatible = "spi-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi1>;
> + status = "okay";

The 'status' is not needed in this case.

> + gpio-sck = < 13 0>;
> + gpio-mosi = < 9 0>;
> + cs-gpios = < 12 0>;
> + num-chipselects = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio_spi: gpio_spi@0 {

gpio-expander might be a better node name?

> + compatible = "fairchild,74hc595";
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0>;
> + registers-number = <1>;
> +  /* Enable PERI_3V3, SENSOR_RST_B and HDMI_RST*/
> + registers-default = /bits/ 8 <0x74>;

I do not see this property is documented or supported by kernel.

> + spi-max-frequency = <10>;
> + };
> + };
> +
>   regulators {
>   compatible = "simple-bus";
>   #address-cells = <1>;
> @@ -642,5 +666,13 @@
>   fsl,pins = <
>   MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT  0x110b0
>   >;
> +
> + pinctrl_spi1: spi1grp {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO09__GPIO1_IO9  0x59
> + MX7D_PAD_GPIO1_IO12__GPIO1_IO12 0x59
> + MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x59
> + >;
> + };
>   };
>  };
> -- 
> 2.9.3
> 

Re: [PATCH 6/8] ARM: dts: imx7d-sdb: Add GPIO expander node

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:40AM -0700, Andrey Smirnov wrote:
> Add node for U38, a 74LV595PW serial-in shift register that acts as a
> GPIO expander on the board.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7d-sdb.dts | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 5be01a1..e0ff276 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -52,6 +52,30 @@
>   reg = <0x8000 0x8000>;
>   };
>  
> + spi4 {
> + compatible = "spi-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi1>;
> + status = "okay";

The 'status' is not needed in this case.

> + gpio-sck = < 13 0>;
> + gpio-mosi = < 9 0>;
> + cs-gpios = < 12 0>;
> + num-chipselects = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio_spi: gpio_spi@0 {

gpio-expander might be a better node name?

> + compatible = "fairchild,74hc595";
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0>;
> + registers-number = <1>;
> +  /* Enable PERI_3V3, SENSOR_RST_B and HDMI_RST*/
> + registers-default = /bits/ 8 <0x74>;

I do not see this property is documented or supported by kernel.

> + spi-max-frequency = <10>;
> + };
> + };
> +
>   regulators {
>   compatible = "simple-bus";
>   #address-cells = <1>;
> @@ -642,5 +666,13 @@
>   fsl,pins = <
>   MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT  0x110b0
>   >;
> +
> + pinctrl_spi1: spi1grp {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO09__GPIO1_IO9  0x59
> + MX7D_PAD_GPIO1_IO12__GPIO1_IO12 0x59
> + MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x59
> + >;
> + };
>   };
>  };
> -- 
> 2.9.3
> 

Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:38AM -0700, Andrey Smirnov wrote:
> Add node for GPC and specify as a parent interrupt controller for SoC bus.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7s.dtsi | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 8fee299..1a7058f 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -119,7 +120,7 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>   compatible = "simple-bus";
> - interrupt-parent = <>;
> + interrupt-parent = <>;
>   ranges;
>  
>   funnel@30041000 {
> @@ -301,6 +302,7 @@
>   interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
>   #interrupt-cells = <3>;
>   interrupt-controller;
> + interrupt-parent = <>;
>   reg = <0x31001000 0x1000>,
> <0x31002000 0x2000>,
> <0x31004000 0x2000>,
> @@ -309,6 +311,7 @@
>  
>   timer {
>   compatible = "arm,armv7-timer";
> + interrupt-parent = <>;
>   interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>,
> @@ -564,6 +567,28 @@
>   interrupts = ;
>   #reset-cells = <1>;
>   };
> +
> + gpc: gpc@303a {
> + compatible = "fsl,imx7d-gpc";
> + reg = <0x303a 0x1>;
> + interrupt-controller;
> + interrupts = ;
> + #interrupt-cells = <3>;
> + interrupt-parent = <>;
> + #power-domain-cells = <1>;
> +
> + pgc {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pgc_pcie_phy: pgc-pcie-phy-domain {

The node name should be something generic and has a unit-address when
there is a 'reg' property in the node.

> + #power-domain-cells = <0>;
> +

Drop this newline.

Shawn

> + reg = 
> ;
> + power-supply = <_1p0d>;
> + };
> + };
> + };
>   };
>  
>   aips2: aips-bus@3040 {
> -- 
> 2.9.3
> 

Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:38AM -0700, Andrey Smirnov wrote:
> Add node for GPC and specify as a parent interrupt controller for SoC bus.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7s.dtsi | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 8fee299..1a7058f 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -119,7 +120,7 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>   compatible = "simple-bus";
> - interrupt-parent = <>;
> + interrupt-parent = <>;
>   ranges;
>  
>   funnel@30041000 {
> @@ -301,6 +302,7 @@
>   interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
>   #interrupt-cells = <3>;
>   interrupt-controller;
> + interrupt-parent = <>;
>   reg = <0x31001000 0x1000>,
> <0x31002000 0x2000>,
> <0x31004000 0x2000>,
> @@ -309,6 +311,7 @@
>  
>   timer {
>   compatible = "arm,armv7-timer";
> + interrupt-parent = <>;
>   interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>,
> @@ -564,6 +567,28 @@
>   interrupts = ;
>   #reset-cells = <1>;
>   };
> +
> + gpc: gpc@303a {
> + compatible = "fsl,imx7d-gpc";
> + reg = <0x303a 0x1>;
> + interrupt-controller;
> + interrupts = ;
> + #interrupt-cells = <3>;
> + interrupt-parent = <>;
> + #power-domain-cells = <1>;
> +
> + pgc {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pgc_pcie_phy: pgc-pcie-phy-domain {

The node name should be something generic and has a unit-address when
there is a 'reg' property in the node.

> + #power-domain-cells = <0>;
> +

Drop this newline.

Shawn

> + reg = 
> ;
> + power-supply = <_1p0d>;
> + };
> + };
> + };
>   };
>  
>   aips2: aips-bus@3040 {
> -- 
> 2.9.3
> 

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[Sean Wang]

Hi Corentin,

I all agree and appreciate your careful reviewing. 

They will be added into the next one.

Sean

On Thu, 2017-04-13 at 13:06 +0200, Corentin Labbe wrote:
> Hello
> 
> I have some minor comment below:
> 
> On Thu, Apr 13, 2017 at 03:05:08PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > This patch adds support for hardware random generator on MT7623 SoC
> > and should also work on other similar Mediatek SoCs. Currently,
> > the driver is already tested successfully with rng-tools.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  drivers/char/hw_random/Kconfig   |  16 +++-
> >  drivers/char/hw_random/Makefile  |   2 +-
> >  drivers/char/hw_random/mtk-rng.c | 174 
> > +++
> >  3 files changed, 190 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/char/hw_random/mtk-rng.c
> > 
> > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> > index 0cafe08..af782ce 100644
> > --- a/drivers/char/hw_random/Kconfig
> > +++ b/drivers/char/hw_random/Kconfig
> > @@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
> >   Generator hardware found on Cavium SoCs.
> >  
> >   To compile this driver as a module, choose M here: the
> > - module will be called cavium_rng.
> > + module will be called mtk-rng.
> 
> Unwanted change
> 
> >  
> >   If unsure, say Y.
> >  
> > +config HW_RANDOM_MTK
> > +   tristate "Mediatek Random Number Generator support"
> > +   depends on HW_RANDOM
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   default y
> > +   ---help---
> > + This driver provides kernel-side support for the Random Number
> > + Generator hardware found on Mediatek SoCs.
> > +
> > + To compile this driver as a module, choose M here. the
> > + module will be called mtk-rng.
> > +
> > + If unsure, say Y.
> > +
> >  endif # HW_RANDOM
> >  
> >  config UML_RANDOM
> > diff --git a/drivers/char/hw_random/Makefile 
> > b/drivers/char/hw_random/Makefile
> > index 5f52b1e..68be716 100644
> > --- a/drivers/char/hw_random/Makefile
> > +++ b/drivers/char/hw_random/Makefile
> > @@ -1,7 +1,6 @@
> >  #
> >  # Makefile for HW Random Number Generator (RNG) device drivers.
> >  #
> > -
> 
> Another unwanted change
> 
> >  obj-$(CONFIG_HW_RANDOM) += rng-core.o
> >  rng-core-y := core.o
> >  obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
> > @@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
> >  obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
> >  obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
> >  obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
> > +obj-$(CONFIG_HW_RANDOM_MTK)+= mtk-rng.o
> > diff --git a/drivers/char/hw_random/mtk-rng.c 
> > b/drivers/char/hw_random/mtk-rng.c
> > new file mode 100644
> > index 000..6561ee0
> > --- /dev/null
> > +++ b/drivers/char/hw_random/mtk-rng.c
> > @@ -0,0 +1,174 @@
> > +/*
> > + * Driver for Mediatek Hardware Random Number Generator
> > + *
> > + * Copyright (C) 2017 Sean Wang 
> > + *
> > + * This program 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 program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +#define MTK_RNG_DEV KBUILD_MODNAME
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define USEC_POLL  2
> > +#define TIMEOUT_POLL   20
> > +
> > +#define RNG_CTRL   0x00
> > +#define  RNG_ENBIT(0)
> > +#define  RNG_READY BIT(31)
> 
> Keep only one space between define and name
> 
> > +
> > +#define RNG_DATA   0x08
> > +
> > +#define to_mtk_rng(p)  container_of(p, struct mtk_rng, rng)
> > +
> > +struct mtk_rng {
> > +   struct device   *dev;
> > +   void __iomem *base;
> > +   struct clk *clk;
> > +   struct hwrng rng;
> > +};
> > +
> > +static int mtk_rng_init(struct hwrng *rng)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   u32 val;
> > +   int err;
> > +
> > +   err = clk_prepare_enable(priv->clk);
> > +   if (err)
> > +   return err;
> > +
> > +   val = readl(priv->base + RNG_CTRL);
> > +   val |= RNG_EN;
> > +   writel(val, priv->base + RNG_CTRL);
> > +
> > +   return 0;
> > +}
> > +
> > +static void mtk_rng_cleanup(struct hwrng *rng)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   u32 val;
> > +
> > +   val = 

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[Sean Wang]

Hi Corentin,

I all agree and appreciate your careful reviewing. 

They will be added into the next one.

Sean

On Thu, 2017-04-13 at 13:06 +0200, Corentin Labbe wrote:
> Hello
> 
> I have some minor comment below:
> 
> On Thu, Apr 13, 2017 at 03:05:08PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > This patch adds support for hardware random generator on MT7623 SoC
> > and should also work on other similar Mediatek SoCs. Currently,
> > the driver is already tested successfully with rng-tools.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  drivers/char/hw_random/Kconfig   |  16 +++-
> >  drivers/char/hw_random/Makefile  |   2 +-
> >  drivers/char/hw_random/mtk-rng.c | 174 
> > +++
> >  3 files changed, 190 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/char/hw_random/mtk-rng.c
> > 
> > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> > index 0cafe08..af782ce 100644
> > --- a/drivers/char/hw_random/Kconfig
> > +++ b/drivers/char/hw_random/Kconfig
> > @@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
> >   Generator hardware found on Cavium SoCs.
> >  
> >   To compile this driver as a module, choose M here: the
> > - module will be called cavium_rng.
> > + module will be called mtk-rng.
> 
> Unwanted change
> 
> >  
> >   If unsure, say Y.
> >  
> > +config HW_RANDOM_MTK
> > +   tristate "Mediatek Random Number Generator support"
> > +   depends on HW_RANDOM
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   default y
> > +   ---help---
> > + This driver provides kernel-side support for the Random Number
> > + Generator hardware found on Mediatek SoCs.
> > +
> > + To compile this driver as a module, choose M here. the
> > + module will be called mtk-rng.
> > +
> > + If unsure, say Y.
> > +
> >  endif # HW_RANDOM
> >  
> >  config UML_RANDOM
> > diff --git a/drivers/char/hw_random/Makefile 
> > b/drivers/char/hw_random/Makefile
> > index 5f52b1e..68be716 100644
> > --- a/drivers/char/hw_random/Makefile
> > +++ b/drivers/char/hw_random/Makefile
> > @@ -1,7 +1,6 @@
> >  #
> >  # Makefile for HW Random Number Generator (RNG) device drivers.
> >  #
> > -
> 
> Another unwanted change
> 
> >  obj-$(CONFIG_HW_RANDOM) += rng-core.o
> >  rng-core-y := core.o
> >  obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
> > @@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
> >  obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
> >  obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
> >  obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
> > +obj-$(CONFIG_HW_RANDOM_MTK)+= mtk-rng.o
> > diff --git a/drivers/char/hw_random/mtk-rng.c 
> > b/drivers/char/hw_random/mtk-rng.c
> > new file mode 100644
> > index 000..6561ee0
> > --- /dev/null
> > +++ b/drivers/char/hw_random/mtk-rng.c
> > @@ -0,0 +1,174 @@
> > +/*
> > + * Driver for Mediatek Hardware Random Number Generator
> > + *
> > + * Copyright (C) 2017 Sean Wang 
> > + *
> > + * This program 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 program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +#define MTK_RNG_DEV KBUILD_MODNAME
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define USEC_POLL  2
> > +#define TIMEOUT_POLL   20
> > +
> > +#define RNG_CTRL   0x00
> > +#define  RNG_ENBIT(0)
> > +#define  RNG_READY BIT(31)
> 
> Keep only one space between define and name
> 
> > +
> > +#define RNG_DATA   0x08
> > +
> > +#define to_mtk_rng(p)  container_of(p, struct mtk_rng, rng)
> > +
> > +struct mtk_rng {
> > +   struct device   *dev;
> > +   void __iomem *base;
> > +   struct clk *clk;
> > +   struct hwrng rng;
> > +};
> > +
> > +static int mtk_rng_init(struct hwrng *rng)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   u32 val;
> > +   int err;
> > +
> > +   err = clk_prepare_enable(priv->clk);
> > +   if (err)
> > +   return err;
> > +
> > +   val = readl(priv->base + RNG_CTRL);
> > +   val |= RNG_EN;
> > +   writel(val, priv->base + RNG_CTRL);
> > +
> > +   return 0;
> > +}
> > +
> > +static void mtk_rng_cleanup(struct hwrng *rng)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   u32 val;
> > +
> > +   val = readl(priv->base + RNG_CTRL);
> > +   val &= ~RNG_EN;
> > +   writel(val, 

Re: [PATCH 3/8] ARM: dts: imx7s: Adjust anatop-enable-bit for 'reg_1p0d'

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:37AM -0700, Andrey Smirnov wrote:
> In PMU_REG_1P0Dn ENABLE_LINREG is bit 0. Bit 31 is called OVERRIDE and
> it serves the function of granting permission to GPC IP block to alter
> various bit-fields of the register. The reason why this property, that
> trickeld here from Freescale BSP, is set to 31 is because in the code
> it came from it is used in conjunction with a notifier handler for
> REGULATOR_EVENT_PRE_DO_ENABLE and REGULATOR_EVENT_PRE_DO_DISABLE
> events (not found in upstream kernel) that triggers GPC to start
> manipulating aforementioned other bitfields.
> 
> Since:
>   a) none of the aforementioned machinery is implemented by
>  upstream
>   b) using 'anatop-enable-bit' in that capacity is a bit of a
>  semantic stretch
> 
> simplify the situation by setting the value of 'anatop-enable-bit' to
> point to ENABLE_LINREG (same as i.MX6).
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 

Since patch 1 ~ 3 are all about adding anatop-enable-bit, can we squash
them into one patch?

Shawn

> ---
>  arch/arm/boot/dts/imx7s.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 22c9788..8fee299 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -516,7 +516,7 @@
>   anatop-min-bit-val = <8>;
>   anatop-min-voltage = <80>;
>   anatop-max-voltage = <120>;
> - anatop-enable-bit = <31>;
> + anatop-enable-bit = <0>;
>   };
>   };
>  
> -- 
> 2.9.3
> 

Re: [PATCH 3/8] ARM: dts: imx7s: Adjust anatop-enable-bit for 'reg_1p0d'

[Shawn Guo]

On Thu, Apr 13, 2017 at 06:32:37AM -0700, Andrey Smirnov wrote:
> In PMU_REG_1P0Dn ENABLE_LINREG is bit 0. Bit 31 is called OVERRIDE and
> it serves the function of granting permission to GPC IP block to alter
> various bit-fields of the register. The reason why this property, that
> trickeld here from Freescale BSP, is set to 31 is because in the code
> it came from it is used in conjunction with a notifier handler for
> REGULATOR_EVENT_PRE_DO_ENABLE and REGULATOR_EVENT_PRE_DO_DISABLE
> events (not found in upstream kernel) that triggers GPC to start
> manipulating aforementioned other bitfields.
> 
> Since:
>   a) none of the aforementioned machinery is implemented by
>  upstream
>   b) using 'anatop-enable-bit' in that capacity is a bit of a
>  semantic stretch
> 
> simplify the situation by setting the value of 'anatop-enable-bit' to
> point to ENABLE_LINREG (same as i.MX6).
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 

Since patch 1 ~ 3 are all about adding anatop-enable-bit, can we squash
them into one patch?

Shawn

> ---
>  arch/arm/boot/dts/imx7s.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 22c9788..8fee299 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -516,7 +516,7 @@
>   anatop-min-bit-val = <8>;
>   anatop-min-voltage = <80>;
>   anatop-max-voltage = <120>;
> - anatop-enable-bit = <31>;
> + anatop-enable-bit = <0>;
>   };
>   };
>  
> -- 
> 2.9.3
> 

[PATCH v2 net 2/2] net: ethernet: mediatek: fix inconsistency of port number carried in TXD

[sean.wang]

From: Sean Wang 

Fix port inconsistency on TXD due to hardware BUG that would cause
different port number is carried on the same TXD between tx_map()
and tx_unmap() with the iperf test. It would cause confusing BQL
logic which leads to kernel panic when dual GMAC runs concurrently.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 14 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 12 +---
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 48ba617..6313c53 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -648,6 +648,8 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
 
WRITE_ONCE(itxd->txd1, mapped_addr);
itx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
+   itx_buf->flags |= (!mac->id) ? MTK_TX_FLAGS_FPORT0 :
+ MTK_TX_FLAGS_FPORT1;
dma_unmap_addr_set(itx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(itx_buf, dma_len0, skb_headlen(skb));
 
@@ -689,6 +691,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
memset(tx_buf, 0, sizeof(*tx_buf));
tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf->flags |= MTK_TX_FLAGS_PAGE0;
+   tx_buf->flags |= (!mac->id) ? MTK_TX_FLAGS_FPORT0 :
+MTK_TX_FLAGS_FPORT1;
+
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(tx_buf, dma_len0, frag_map_size);
frag_size -= frag_map_size;
@@ -1011,17 +1016,16 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 
while ((cpu != dma) && budget) {
u32 next_cpu = desc->txd2;
-   int mac;
+   int mac = 0;
 
desc = mtk_qdma_phys_to_virt(ring, desc->txd2);
if ((desc->txd3 & TX_DMA_OWNER_CPU) == 0)
break;
 
-   mac = (desc->txd4 >> TX_DMA_FPORT_SHIFT) &
-  TX_DMA_FPORT_MASK;
-   mac--;
-
tx_buf = mtk_desc_to_tx_buf(ring, desc);
+   if (tx_buf->flags & MTK_TX_FLAGS_FPORT1)
+   mac = 1;
+
skb = tx_buf->skb;
if (!skb) {
condition = 1;
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 996024d..3c46a3b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -410,12 +410,18 @@ struct mtk_hw_stats {
struct u64_stats_sync   syncp;
 };
 
-/* PDMA descriptor can point at 1-2 segments. This enum allows us to track how
- * memory was allocated so that it can be freed properly
- */
 enum mtk_tx_flags {
+   /* PDMA descriptor can point at 1-2 segments. This enum allows us to
+* track how memory was allocated so that it can be freed properly.
+*/
MTK_TX_FLAGS_SINGLE0= 0x01,
MTK_TX_FLAGS_PAGE0  = 0x02,
+
+   /* MTK_TX_FLAGS_FPORTx allows tracking which port the transmitted
+* SKB out instead of looking up through hardware TX descriptor.
+*/
+   MTK_TX_FLAGS_FPORT0 = 0x04,
+   MTK_TX_FLAGS_FPORT1 = 0x08,
 };
 
 /* This enum allows us to identify how the clock is defined on the array of the
-- 
1.9.1

[PATCH v2 net 2/2] net: ethernet: mediatek: fix inconsistency of port number carried in TXD

[sean.wang]

From: Sean Wang 

Fix port inconsistency on TXD due to hardware BUG that would cause
different port number is carried on the same TXD between tx_map()
and tx_unmap() with the iperf test. It would cause confusing BQL
logic which leads to kernel panic when dual GMAC runs concurrently.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 14 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 12 +---
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 48ba617..6313c53 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -648,6 +648,8 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
 
WRITE_ONCE(itxd->txd1, mapped_addr);
itx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
+   itx_buf->flags |= (!mac->id) ? MTK_TX_FLAGS_FPORT0 :
+ MTK_TX_FLAGS_FPORT1;
dma_unmap_addr_set(itx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(itx_buf, dma_len0, skb_headlen(skb));
 
@@ -689,6 +691,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
memset(tx_buf, 0, sizeof(*tx_buf));
tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf->flags |= MTK_TX_FLAGS_PAGE0;
+   tx_buf->flags |= (!mac->id) ? MTK_TX_FLAGS_FPORT0 :
+MTK_TX_FLAGS_FPORT1;
+
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(tx_buf, dma_len0, frag_map_size);
frag_size -= frag_map_size;
@@ -1011,17 +1016,16 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 
while ((cpu != dma) && budget) {
u32 next_cpu = desc->txd2;
-   int mac;
+   int mac = 0;
 
desc = mtk_qdma_phys_to_virt(ring, desc->txd2);
if ((desc->txd3 & TX_DMA_OWNER_CPU) == 0)
break;
 
-   mac = (desc->txd4 >> TX_DMA_FPORT_SHIFT) &
-  TX_DMA_FPORT_MASK;
-   mac--;
-
tx_buf = mtk_desc_to_tx_buf(ring, desc);
+   if (tx_buf->flags & MTK_TX_FLAGS_FPORT1)
+   mac = 1;
+
skb = tx_buf->skb;
if (!skb) {
condition = 1;
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 996024d..3c46a3b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -410,12 +410,18 @@ struct mtk_hw_stats {
struct u64_stats_sync   syncp;
 };
 
-/* PDMA descriptor can point at 1-2 segments. This enum allows us to track how
- * memory was allocated so that it can be freed properly
- */
 enum mtk_tx_flags {
+   /* PDMA descriptor can point at 1-2 segments. This enum allows us to
+* track how memory was allocated so that it can be freed properly.
+*/
MTK_TX_FLAGS_SINGLE0= 0x01,
MTK_TX_FLAGS_PAGE0  = 0x02,
+
+   /* MTK_TX_FLAGS_FPORTx allows tracking which port the transmitted
+* SKB out instead of looking up through hardware TX descriptor.
+*/
+   MTK_TX_FLAGS_FPORT0 = 0x04,
+   MTK_TX_FLAGS_FPORT1 = 0x08,
 };
 
 /* This enum allows us to identify how the clock is defined on the array of the
-- 
1.9.1

[PATCH v2 net 1/2] net: ethernet: mediatek: fix inconsistency between TXD and the used buffer

[sean.wang]

From: Sean Wang 

Fix inconsistency between the TXD descriptor and the used buffer that
would cause unexpected logic at mtk_tx_unmap() during skb housekeeping.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 14e1bd1..48ba617 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -613,7 +613,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
struct mtk_mac *mac = netdev_priv(dev);
struct mtk_eth *eth = mac->hw;
struct mtk_tx_dma *itxd, *txd;
-   struct mtk_tx_buf *tx_buf;
+   struct mtk_tx_buf *itx_buf, *tx_buf;
dma_addr_t mapped_addr;
unsigned int nr_frags;
int i, n_desc = 1;
@@ -627,8 +627,8 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
fport = (mac->id + 1) << TX_DMA_FPORT_SHIFT;
txd4 |= fport;
 
-   tx_buf = mtk_desc_to_tx_buf(ring, itxd);
-   memset(tx_buf, 0, sizeof(*tx_buf));
+   itx_buf = mtk_desc_to_tx_buf(ring, itxd);
+   memset(itx_buf, 0, sizeof(*itx_buf));
 
if (gso)
txd4 |= TX_DMA_TSO;
@@ -647,9 +647,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
return -ENOMEM;
 
WRITE_ONCE(itxd->txd1, mapped_addr);
-   tx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
-   dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
-   dma_unmap_len_set(tx_buf, dma_len0, skb_headlen(skb));
+   itx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
+   dma_unmap_addr_set(itx_buf, dma_addr0, mapped_addr);
+   dma_unmap_len_set(itx_buf, dma_len0, skb_headlen(skb));
 
/* TX SG offload */
txd = itxd;
@@ -685,10 +685,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
   last_frag * TX_DMA_LS0));
WRITE_ONCE(txd->txd4, fport);
 
-   tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf = mtk_desc_to_tx_buf(ring, txd);
memset(tx_buf, 0, sizeof(*tx_buf));
-
+   tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf->flags |= MTK_TX_FLAGS_PAGE0;
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(tx_buf, dma_len0, frag_map_size);
@@ -698,7 +697,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
}
 
/* store skb to cleanup */
-   tx_buf->skb = skb;
+   itx_buf->skb = skb;
 
WRITE_ONCE(itxd->txd4, txd4);
WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
-- 
1.9.1

[PATCH v2 net 1/2] net: ethernet: mediatek: fix inconsistency between TXD and the used buffer

[sean.wang]

From: Sean Wang 

Fix inconsistency between the TXD descriptor and the used buffer that
would cause unexpected logic at mtk_tx_unmap() during skb housekeeping.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 14e1bd1..48ba617 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -613,7 +613,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
struct mtk_mac *mac = netdev_priv(dev);
struct mtk_eth *eth = mac->hw;
struct mtk_tx_dma *itxd, *txd;
-   struct mtk_tx_buf *tx_buf;
+   struct mtk_tx_buf *itx_buf, *tx_buf;
dma_addr_t mapped_addr;
unsigned int nr_frags;
int i, n_desc = 1;
@@ -627,8 +627,8 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
fport = (mac->id + 1) << TX_DMA_FPORT_SHIFT;
txd4 |= fport;
 
-   tx_buf = mtk_desc_to_tx_buf(ring, itxd);
-   memset(tx_buf, 0, sizeof(*tx_buf));
+   itx_buf = mtk_desc_to_tx_buf(ring, itxd);
+   memset(itx_buf, 0, sizeof(*itx_buf));
 
if (gso)
txd4 |= TX_DMA_TSO;
@@ -647,9 +647,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
return -ENOMEM;
 
WRITE_ONCE(itxd->txd1, mapped_addr);
-   tx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
-   dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
-   dma_unmap_len_set(tx_buf, dma_len0, skb_headlen(skb));
+   itx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
+   dma_unmap_addr_set(itx_buf, dma_addr0, mapped_addr);
+   dma_unmap_len_set(itx_buf, dma_len0, skb_headlen(skb));
 
/* TX SG offload */
txd = itxd;
@@ -685,10 +685,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
   last_frag * TX_DMA_LS0));
WRITE_ONCE(txd->txd4, fport);
 
-   tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf = mtk_desc_to_tx_buf(ring, txd);
memset(tx_buf, 0, sizeof(*tx_buf));
-
+   tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf->flags |= MTK_TX_FLAGS_PAGE0;
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(tx_buf, dma_len0, frag_map_size);
@@ -698,7 +697,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
}
 
/* store skb to cleanup */
-   tx_buf->skb = skb;
+   itx_buf->skb = skb;
 
WRITE_ONCE(itxd->txd4, txd4);
WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
-- 
1.9.1

[PATCH v2 net 0/2] Fix crash caused by reporting inconsistent skb->len to BQL

[sean.wang]

From: Sean Wang 

Changes since v1:
- fix inconsistent enumeration which easily causes the potential bug

The series fixes kernel BUG caused by inconsistent SKB length reported
into BQL. The reason for inconsistent length comes from hardware BUG which
results in different port number carried on the TXD within the lifecycle of
SKB. So patch 2) is proposed for use a software way to track which port
the SKB involving instead of hardware way. And patch 1) is given for another
issue I found which causes TXD and SKB inconsistency that is not expected
in the initial logic, so it is also being corrected it in the series.

The log for the kernel BUG caused by the issue is posted as below.

[  120.825955] kernel BUG at ... lib/dynamic_queue_limits.c:26!
[  120.837684] Internal error: Oops - BUG: 0 [#1] SMP ARM
[  120.842778] Modules linked in:
[  120.845811] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.11.0-rc1-191576-gdbcef47 #35
[  120.853488] Hardware name: Mediatek Cortex-A7 (Device Tree)
[  120.859012] task: c1007480 task.stack: c100
[  120.863510] PC is at dql_completed+0x108/0x17c
[  120.867915] LR is at 0x46
[  120.870512] pc : []lr : [<0046>]psr: 8113
[  120.870512] sp : c1001d58  ip : c1001d80  fp : c1001d7c
[  120.881895] r10: 003e  r9 : df6b3400  r8 : 0ed86506
[  120.887075] r7 : 0001  r6 : 0001  r5 : 0ed8654c  r4 : df0135d8
[  120.893546] r3 : 0001  r2 : df016800  r1 : fece  r0 : df6b3480
[  120.900018] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  120.907093] Control: 10c5387d  Table: 9e27806a  DAC: 0051
[  120.912789] Process swapper/0 (pid: 0, stack limit = 0xc1000218)
[  120.918744] Stack: (0xc1001d58 to 0xc1002000)



121.085331] 1fc0:  c0a52a28  c10855d4 c1003c58 c0a52a24 
c100885c 8000406a
[  121.093444] 1fe0: 410fc073   c1001ff8 8000807c c0a009cc 
 
[  121.101575] [] (dql_completed) from [] 
(mtk_napi_tx+0x1d0/0x37c)
[  121.109263] [] (mtk_napi_tx) from [] 
(net_rx_action+0x24c/0x3b8)
[  121.116951] [] (net_rx_action) from [] 
(__do_softirq+0xe4/0x35c)
[  121.124638] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x150)
[  121.131895] [] (irq_exit) from [] 
(__handle_domain_irq+0x70/0xc4)
[  121.139666] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x58/0x9c)
[  121.147953] [] (gic_handle_irq) from [] 
(__irq_svc+0x6c/0x90)
[  121.155373] Exception stack(0xc1001ef8 to 0xc1001f40)

Sean Wang (2):
  net: ethernet: mediatek: fix inconsistency between TXD and the used
buffer
  net: ethernet: mediatek: fix inconsistency of port number carried in
TXD

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 31 -
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 12 ---
 2 files changed, 26 insertions(+), 17 deletions(-)

-- 
1.9.1

[PATCH v2 net 0/2] Fix crash caused by reporting inconsistent skb->len to BQL

[sean.wang]

From: Sean Wang 

Changes since v1:
- fix inconsistent enumeration which easily causes the potential bug

The series fixes kernel BUG caused by inconsistent SKB length reported
into BQL. The reason for inconsistent length comes from hardware BUG which
results in different port number carried on the TXD within the lifecycle of
SKB. So patch 2) is proposed for use a software way to track which port
the SKB involving instead of hardware way. And patch 1) is given for another
issue I found which causes TXD and SKB inconsistency that is not expected
in the initial logic, so it is also being corrected it in the series.

The log for the kernel BUG caused by the issue is posted as below.

[  120.825955] kernel BUG at ... lib/dynamic_queue_limits.c:26!
[  120.837684] Internal error: Oops - BUG: 0 [#1] SMP ARM
[  120.842778] Modules linked in:
[  120.845811] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.11.0-rc1-191576-gdbcef47 #35
[  120.853488] Hardware name: Mediatek Cortex-A7 (Device Tree)
[  120.859012] task: c1007480 task.stack: c100
[  120.863510] PC is at dql_completed+0x108/0x17c
[  120.867915] LR is at 0x46
[  120.870512] pc : []lr : [<0046>]psr: 8113
[  120.870512] sp : c1001d58  ip : c1001d80  fp : c1001d7c
[  120.881895] r10: 003e  r9 : df6b3400  r8 : 0ed86506
[  120.887075] r7 : 0001  r6 : 0001  r5 : 0ed8654c  r4 : df0135d8
[  120.893546] r3 : 0001  r2 : df016800  r1 : fece  r0 : df6b3480
[  120.900018] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  120.907093] Control: 10c5387d  Table: 9e27806a  DAC: 0051
[  120.912789] Process swapper/0 (pid: 0, stack limit = 0xc1000218)
[  120.918744] Stack: (0xc1001d58 to 0xc1002000)



121.085331] 1fc0:  c0a52a28  c10855d4 c1003c58 c0a52a24 
c100885c 8000406a
[  121.093444] 1fe0: 410fc073   c1001ff8 8000807c c0a009cc 
 
[  121.101575] [] (dql_completed) from [] 
(mtk_napi_tx+0x1d0/0x37c)
[  121.109263] [] (mtk_napi_tx) from [] 
(net_rx_action+0x24c/0x3b8)
[  121.116951] [] (net_rx_action) from [] 
(__do_softirq+0xe4/0x35c)
[  121.124638] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x150)
[  121.131895] [] (irq_exit) from [] 
(__handle_domain_irq+0x70/0xc4)
[  121.139666] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x58/0x9c)
[  121.147953] [] (gic_handle_irq) from [] 
(__irq_svc+0x6c/0x90)
[  121.155373] Exception stack(0xc1001ef8 to 0xc1001f40)

Sean Wang (2):
  net: ethernet: mediatek: fix inconsistency between TXD and the used
buffer
  net: ethernet: mediatek: fix inconsistency of port number carried in
TXD

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 31 -
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 12 ---
 2 files changed, 26 insertions(+), 17 deletions(-)

-- 
1.9.1

Re: [PATCH v2 07/22] ARM: dts: imx: Add generic compatible string for I2C EEPROM

[Shawn Guo]

On Thu, Apr 13, 2017 at 03:28:24PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
> 
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
> 
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
> 
> Signed-off-by: Javier Martinez Canillas 

I wouldn't apply it before driver and bindings change get accepted.
Ping me when that happens.

Shawn

> ---
> 
> Changes in v2: None
> 
>  arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi | 2 +-
>  arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi   | 2 +-
>  arch/arm/boot/dts/imx28-evk.dts   | 2 +-
>  arch/arm/boot/dts/imx53-tqma53.dtsi   | 2 +-
>  arch/arm/boot/dts/imx6q-cm-fx6.dts| 2 +-
>  arch/arm/boot/dts/imx6q-utilite-pro.dts   | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi 
> b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> index 4f3e0f473581..61e741092efa 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> +++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> @@ -40,7 +40,7 @@
>   status = "okay";
>  
>   at24@52 {
> - compatible = "at,24c32";
> + compatible = "at,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x52>;
>   };
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi 
> b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> index 82fec935ce83..5b6b651af18f 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> +++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> @@ -193,7 +193,7 @@
>   status = "okay";
>  
>   at24@52 {
> - compatible = "at,24c32";
> + compatible = "at,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x52>;
>   };
> diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
> index a5ba669b4eaa..5ab990ac36b4 100644
> --- a/arch/arm/boot/dts/imx28-evk.dts
> +++ b/arch/arm/boot/dts/imx28-evk.dts
> @@ -203,7 +203,7 @@
>   };
>  
>   at24@51 {
> - compatible = "at24,24c32";
> + compatible = "at24,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x51>;
>   };
> diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi 
> b/arch/arm/boot/dts/imx53-tqma53.dtsi
> index 85972f2201c2..c8bc0522a1e9 100644
> --- a/arch/arm/boot/dts/imx53-tqma53.dtsi
> +++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
> @@ -272,7 +272,7 @@
>   };
>  
>   eeprom: 24c64@50 {
> - compatible = "at,24c64";
> + compatible = "at,24c64","atmel,24c64";
>   pagesize = <32>;
>   reg = <0x50>;
>   };
> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts 
> b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> index 66cac5328b86..8cf478c67f83 100644
> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> @@ -215,7 +215,7 @@
>   clock-frequency = <10>;
>  
>   eeprom@50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02","atmel,24c02";
>   reg = <0x50>;
>   pagesize = <16>;
>   };
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts 
> b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 69bdd82ce21f..644889d813d0 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -128,7 +128,7 @@
>   #size-cells = <0>;
>  
>   eeprom@50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02","atmel,24c02";
>   reg = <0x50>;
>   pagesize = <16>;
>   };
> -- 
> 2.9.3
> 

Re: [PATCH v2 07/22] ARM: dts: imx: Add generic compatible string for I2C EEPROM

[Shawn Guo]

On Thu, Apr 13, 2017 at 03:28:24PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
> 
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
> 
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
> 
> Signed-off-by: Javier Martinez Canillas 

I wouldn't apply it before driver and bindings change get accepted.
Ping me when that happens.

Shawn

> ---
> 
> Changes in v2: None
> 
>  arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi | 2 +-
>  arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi   | 2 +-
>  arch/arm/boot/dts/imx28-evk.dts   | 2 +-
>  arch/arm/boot/dts/imx53-tqma53.dtsi   | 2 +-
>  arch/arm/boot/dts/imx6q-cm-fx6.dts| 2 +-
>  arch/arm/boot/dts/imx6q-utilite-pro.dts   | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi 
> b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> index 4f3e0f473581..61e741092efa 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> +++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> @@ -40,7 +40,7 @@
>   status = "okay";
>  
>   at24@52 {
> - compatible = "at,24c32";
> + compatible = "at,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x52>;
>   };
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi 
> b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> index 82fec935ce83..5b6b651af18f 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> +++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> @@ -193,7 +193,7 @@
>   status = "okay";
>  
>   at24@52 {
> - compatible = "at,24c32";
> + compatible = "at,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x52>;
>   };
> diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
> index a5ba669b4eaa..5ab990ac36b4 100644
> --- a/arch/arm/boot/dts/imx28-evk.dts
> +++ b/arch/arm/boot/dts/imx28-evk.dts
> @@ -203,7 +203,7 @@
>   };
>  
>   at24@51 {
> - compatible = "at24,24c32";
> + compatible = "at24,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x51>;
>   };
> diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi 
> b/arch/arm/boot/dts/imx53-tqma53.dtsi
> index 85972f2201c2..c8bc0522a1e9 100644
> --- a/arch/arm/boot/dts/imx53-tqma53.dtsi
> +++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
> @@ -272,7 +272,7 @@
>   };
>  
>   eeprom: 24c64@50 {
> - compatible = "at,24c64";
> + compatible = "at,24c64","atmel,24c64";
>   pagesize = <32>;
>   reg = <0x50>;
>   };
> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts 
> b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> index 66cac5328b86..8cf478c67f83 100644
> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> @@ -215,7 +215,7 @@
>   clock-frequency = <10>;
>  
>   eeprom@50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02","atmel,24c02";
>   reg = <0x50>;
>   pagesize = <16>;
>   };
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts 
> b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 69bdd82ce21f..644889d813d0 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -128,7 +128,7 @@
>   #size-cells = <0>;
>  
>   eeprom@50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02","atmel,24c02";
>   reg = <0x50>;
>   pagesize = <16>;
>   };
> -- 
> 2.9.3
> 

[lkp-robot] [locking/ww] 57dd924e54: BUG:soft_lockup-CPU##stuck_for#s

[kernel test robot]

FYI, we noticed the following commit:

commit: 57dd924e541a98219bf3a508623db2e0c07e75a7 ("locking/ww-mutex: Limit 
stress test to 2 seconds")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 44fe84459f | 57dd924e54 |
+--+++
| boot_successes   | 0  | 0  |
| boot_failures| 8  | 8  |
| INFO:task_blocked_for_more_than#seconds  | 8  ||
| calltrace:debug_show_all_locks   | 8  ||
| calltrace:ww_mutex_lock_slow | 7  ||
| Kernel_panic-not_syncing:hung_task:blocked_tasks | 8  ||
| calltrace:stress_inorder_work| 1  ||
| IP-Config:Auto-configuration_of_network_failed   | 0  | 4  |
| BUG:soft_lockup-CPU##stuck_for#s | 0  | 4  |
| Kernel_panic-not_syncing:softlockup:hung_tasks   | 0  | 4  |
+--+++



[  273.632796] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[swapper/0:1]
[  273.675540] irq event stamp: 4865008
[  273.685130] hardirqs last  enabled at (4865007): [] 
restore_regs_and_iret+0x0/0x1d
[  273.698804] hardirqs last disabled at (4865008): [] 
apic_timer_interrupt+0x98/0xb0
[  273.712354] softirqs last  enabled at (4865006): [] 
__do_softirq+0x1cf/0x22a
[  273.725144] softirqs last disabled at (4864999): [] 
irq_exit+0x56/0xa6
[  273.737170] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.11.0-rc2-00029-g57dd924 #1
[  273.748511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  273.763553] task: 89a4bae9c040 task.stack: 89a4baea
[  273.772653] RIP: 0010:erase_augmented+0x79/0x23b
[  273.781081] RSP: :89a4baea3e20 EFLAGS: 0296 ORIG_RAX: 
ff10
[  273.792428] RAX:  RBX: 91ce7a38 RCX: 89a4bae9c040
[  273.802992] RDX: 91ce7b50 RSI:  RDI: 91ce7328
[  273.813680] RBP: 89a4baea3e50 R08: 91ce7560 R09: 
[  273.824245] R10:  R11: 89a4bae9c768 R12: 
[  273.834880] R13: 91ce7a38 R14: 91ce7a39 R15: 91ce8200
[  273.845602] FS:  () GS:89a4bbc0() 
knlGS:
[  273.857595] CS:  0010 DS:  ES:  CR0: 80050033
[  273.884265] CR2:  CR3: 0d419000 CR4: 06a0
[  273.894885] Call Trace:
[  273.898736]  rbtree_test_init+0x1c3/0x27f
[  273.904839]  ? irq_poll_setup+0x96/0x96
[  273.910698]  ? set_debug_rodata+0x20/0x20
[  273.916791]  do_one_initcall+0xa2/0x17c
[  273.922687]  ? set_debug_rodata+0x20/0x20
[  273.928744]  kernel_init_freeable+0x202/0x2a3
[  273.935363]  ? rest_init+0x16d/0x16d
[  273.940809]  kernel_init+0xf/0x142
[  273.946056]  ? rest_init+0x16d/0x16d
[  273.951528]  ret_from_fork+0x31/0x40
[  273.956974] Code: 45 10 75 0b e8 e5 db e1 ff 4d 89 65 10 eb 17 e8 da db e1 
ff 4d 89 65 08 eb 0c e8 cf db e1 ff 4c 89 25 e7 ca 3b 04 e8 c3 db e1 ff <4d> 85 
e4 74 0e e8 b9 db e1 ff 4d 89 34 24 e9 4e 01 00 00 e8 ab 
[  273.987248] Kernel panic - not syncing: softlockup: hung tasks
[  273.996061] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G L  
4.11.0-rc2-00029-g57dd924 #1
[  274.009087] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  274.024313] Call Trace:
[  274.028133]  
[  274.031381]  dump_stack+0xb1/0x103
[  274.036617]  panic+0xfb/0x2c2
[  274.041180]  watchdog_timer_fn+0x227/0x25a
[  274.047441]  ? __touch_watchdog+0x1c/0x1c
[  274.053526]  hrtimer_run_queues+0x140/0x1e4
[  274.059914]  run_local_timers+0x1e/0x64
[  274.065741]  update_process_times+0x21/0x4d
[  274.072159]  tick_nohz_handler+0xbd/0xf6
[  274.078129]  smp_trace_apic_timer_interrupt+0x62/0x74
[  274.085735]  smp_apic_timer_interrupt+0x9/0xb
[  274.092356]  apic_timer_interrupt+0x9d/0xb0
[  274.098767] RIP: 0010:erase_augmented+0x79/0x23b
[  274.107194] RSP: :89a4baea3e20 EFLAGS: 0296 ORIG_RAX: 
ff10
[  274.118506] RAX:  RBX: 91ce7a38 RCX: 89a4bae9c040
[  274.129096] RDX: 91ce7b50 RSI:  RDI: 91ce7328
[  274.139761] RBP: 89a4baea3e50 R08: 91ce7560 R09: 
[  274.150265] R10:  R11: 89a4bae9c768 R12: 
[  274.160893] R13: 

[lkp-robot] [locking/ww] 57dd924e54: BUG:soft_lockup-CPU##stuck_for#s

[kernel test robot]

FYI, we noticed the following commit:

commit: 57dd924e541a98219bf3a508623db2e0c07e75a7 ("locking/ww-mutex: Limit 
stress test to 2 seconds")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 44fe84459f | 57dd924e54 |
+--+++
| boot_successes   | 0  | 0  |
| boot_failures| 8  | 8  |
| INFO:task_blocked_for_more_than#seconds  | 8  ||
| calltrace:debug_show_all_locks   | 8  ||
| calltrace:ww_mutex_lock_slow | 7  ||
| Kernel_panic-not_syncing:hung_task:blocked_tasks | 8  ||
| calltrace:stress_inorder_work| 1  ||
| IP-Config:Auto-configuration_of_network_failed   | 0  | 4  |
| BUG:soft_lockup-CPU##stuck_for#s | 0  | 4  |
| Kernel_panic-not_syncing:softlockup:hung_tasks   | 0  | 4  |
+--+++



[  273.632796] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[swapper/0:1]
[  273.675540] irq event stamp: 4865008
[  273.685130] hardirqs last  enabled at (4865007): [] 
restore_regs_and_iret+0x0/0x1d
[  273.698804] hardirqs last disabled at (4865008): [] 
apic_timer_interrupt+0x98/0xb0
[  273.712354] softirqs last  enabled at (4865006): [] 
__do_softirq+0x1cf/0x22a
[  273.725144] softirqs last disabled at (4864999): [] 
irq_exit+0x56/0xa6
[  273.737170] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.11.0-rc2-00029-g57dd924 #1
[  273.748511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  273.763553] task: 89a4bae9c040 task.stack: 89a4baea
[  273.772653] RIP: 0010:erase_augmented+0x79/0x23b
[  273.781081] RSP: :89a4baea3e20 EFLAGS: 0296 ORIG_RAX: 
ff10
[  273.792428] RAX:  RBX: 91ce7a38 RCX: 89a4bae9c040
[  273.802992] RDX: 91ce7b50 RSI:  RDI: 91ce7328
[  273.813680] RBP: 89a4baea3e50 R08: 91ce7560 R09: 
[  273.824245] R10:  R11: 89a4bae9c768 R12: 
[  273.834880] R13: 91ce7a38 R14: 91ce7a39 R15: 91ce8200
[  273.845602] FS:  () GS:89a4bbc0() 
knlGS:
[  273.857595] CS:  0010 DS:  ES:  CR0: 80050033
[  273.884265] CR2:  CR3: 0d419000 CR4: 06a0
[  273.894885] Call Trace:
[  273.898736]  rbtree_test_init+0x1c3/0x27f
[  273.904839]  ? irq_poll_setup+0x96/0x96
[  273.910698]  ? set_debug_rodata+0x20/0x20
[  273.916791]  do_one_initcall+0xa2/0x17c
[  273.922687]  ? set_debug_rodata+0x20/0x20
[  273.928744]  kernel_init_freeable+0x202/0x2a3
[  273.935363]  ? rest_init+0x16d/0x16d
[  273.940809]  kernel_init+0xf/0x142
[  273.946056]  ? rest_init+0x16d/0x16d
[  273.951528]  ret_from_fork+0x31/0x40
[  273.956974] Code: 45 10 75 0b e8 e5 db e1 ff 4d 89 65 10 eb 17 e8 da db e1 
ff 4d 89 65 08 eb 0c e8 cf db e1 ff 4c 89 25 e7 ca 3b 04 e8 c3 db e1 ff <4d> 85 
e4 74 0e e8 b9 db e1 ff 4d 89 34 24 e9 4e 01 00 00 e8 ab 
[  273.987248] Kernel panic - not syncing: softlockup: hung tasks
[  273.996061] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G L  
4.11.0-rc2-00029-g57dd924 #1
[  274.009087] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  274.024313] Call Trace:
[  274.028133]  
[  274.031381]  dump_stack+0xb1/0x103
[  274.036617]  panic+0xfb/0x2c2
[  274.041180]  watchdog_timer_fn+0x227/0x25a
[  274.047441]  ? __touch_watchdog+0x1c/0x1c
[  274.053526]  hrtimer_run_queues+0x140/0x1e4
[  274.059914]  run_local_timers+0x1e/0x64
[  274.065741]  update_process_times+0x21/0x4d
[  274.072159]  tick_nohz_handler+0xbd/0xf6
[  274.078129]  smp_trace_apic_timer_interrupt+0x62/0x74
[  274.085735]  smp_apic_timer_interrupt+0x9/0xb
[  274.092356]  apic_timer_interrupt+0x9d/0xb0
[  274.098767] RIP: 0010:erase_augmented+0x79/0x23b
[  274.107194] RSP: :89a4baea3e20 EFLAGS: 0296 ORIG_RAX: 
ff10
[  274.118506] RAX:  RBX: 91ce7a38 RCX: 89a4bae9c040
[  274.129096] RDX: 91ce7b50 RSI:  RDI: 91ce7328
[  274.139761] RBP: 89a4baea3e50 R08: 91ce7560 R09: 
[  274.150265] R10:  R11: 89a4bae9c768 R12: 
[  274.160893] R13: 

Re: [PATCH v9 3/5] mm: function to offer a page block on the free list

[Matthew Wilcox]

On Fri, Apr 14, 2017 at 10:30:27AM +0800, Wei Wang wrote:
> OK. What do you think if we add this:
> 
> #if defined(CONFIG_VIRTIO_BALLOON) || defined(CONFIG_VIRTIO_BALLOON_MODULE)

That's spelled "IS_ENABLED(CONFIG_VIRTIO_BALLOON)", FYI.

Re: [PATCH v9 3/5] mm: function to offer a page block on the free list

[Matthew Wilcox]

On Fri, Apr 14, 2017 at 10:30:27AM +0800, Wei Wang wrote:
> OK. What do you think if we add this:
> 
> #if defined(CONFIG_VIRTIO_BALLOON) || defined(CONFIG_VIRTIO_BALLOON_MODULE)

That's spelled "IS_ENABLED(CONFIG_VIRTIO_BALLOON)", FYI.

Re: [PATCH v9 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

[Michael S. Tsirkin]

On Fri, Apr 14, 2017 at 10:28:32AM +0800, Wei Wang wrote:
> On 04/14/2017 09:50 AM, Michael S. Tsirkin wrote:
> > On Thu, Apr 13, 2017 at 01:44:11PM -0700, Matthew Wilcox wrote:
> > > On Thu, Apr 13, 2017 at 05:35:03PM +0800, Wei Wang wrote:
> > > > 2) transfer the guest unused pages to the host so that they
> > > > can be skipped to migrate in live migration.
> > > I don't understand this second bit.  You leave the pages on the free list,
> > > and tell the host they're free.  What's preventing somebody else from
> > > allocating them and using them for something?  Is the guest semi-frozen
> > > at this point with just enough of it running to ask the balloon driver
> > > to do things?
> > There's missing documentation here.
> > 
> > The way things actually work is host sends to guest
> > a request for unused pages and then write-protects all memory.
> > 
> > So guest isn't frozen but any changes will be detected by host.
> > 
> 
> Probably it's better to say " transfer the info about the guest unused pages
> to the host so that the host gets a chance to skip the transfer of the
> unused
> pages during live migration".
> 
> Best,
> Wei

IMHO this would not be helpful.
Most people don't know how does migration work, even if they did
this isn't tied to migration in any way.
It just makes people go "oh it's some virtualization mumbo jumbo".
We want people to be able to review and for that
interfaces need to be separate from the implementation.

IOW we must document what the interface promises not how it's used.


The promise is that pages have been unused at some time between when
host sent command and when guest completed it.  Host uses that by
tracking memory changes and then discarding changes made to pages
it gets from guest before it sent the command.

Say that and drop all mention of transfer, migration etc.

-- 
MST

Re: [PATCH v9 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

[Michael S. Tsirkin]

On Fri, Apr 14, 2017 at 10:28:32AM +0800, Wei Wang wrote:
> On 04/14/2017 09:50 AM, Michael S. Tsirkin wrote:
> > On Thu, Apr 13, 2017 at 01:44:11PM -0700, Matthew Wilcox wrote:
> > > On Thu, Apr 13, 2017 at 05:35:03PM +0800, Wei Wang wrote:
> > > > 2) transfer the guest unused pages to the host so that they
> > > > can be skipped to migrate in live migration.
> > > I don't understand this second bit.  You leave the pages on the free list,
> > > and tell the host they're free.  What's preventing somebody else from
> > > allocating them and using them for something?  Is the guest semi-frozen
> > > at this point with just enough of it running to ask the balloon driver
> > > to do things?
> > There's missing documentation here.
> > 
> > The way things actually work is host sends to guest
> > a request for unused pages and then write-protects all memory.
> > 
> > So guest isn't frozen but any changes will be detected by host.
> > 
> 
> Probably it's better to say " transfer the info about the guest unused pages
> to the host so that the host gets a chance to skip the transfer of the
> unused
> pages during live migration".
> 
> Best,
> Wei

IMHO this would not be helpful.
Most people don't know how does migration work, even if they did
this isn't tied to migration in any way.
It just makes people go "oh it's some virtualization mumbo jumbo".
We want people to be able to review and for that
interfaces need to be separate from the implementation.

IOW we must document what the interface promises not how it's used.


The promise is that pages have been unused at some time between when
host sent command and when guest completed it.  Host uses that by
tracking memory changes and then discarding changes made to pages
it gets from guest before it sent the command.

Say that and drop all mention of transfer, migration etc.

-- 
MST

Re: USB Type-C Port Manager API concern

[Guenter Roeck]

On 04/09/2017 02:05 PM, Mats Karrman wrote:

On 04/09/2017 05:16 PM, Guenter Roeck wrote:


Hi Mats,

On Sun, Apr 09, 2017 at 01:09:57AM +0200, Mats Karrman wrote:

I'm working on a tcpi driver and have some concern about the tcpm api.
The tcpm_register_port() is typically called from the probe function of
tcpi driver where the tcpm_port reference returned is stored in the
driver private data. The problem I ran into is that tcpm_register_port()
calls back to the not yet fully initialized tcpi driver, causing null-
pointer dereferences. This could of course be solved by extra logic in
the tcpi driver but I think it would be more elegant if the registration
of a port could be free of premature callbacks. E.g. it could be required
that the tcpi driver probe called tcpm_tcpc_reset() once it's done
initializing or the necessary data could be supplied in the call to
tcpm_register_port().
What do you think?

Let me think about it. In theory it should be possible to avoid callbacks into
the underlying driver until after the return from the registration code, but
that would still be racy if the underlying driver is not ready.

Basic problem seems to be that an API in general assumes that the caller is
ready to serve it once it registers itself. It is kind of unusual to have two
calls, one to register the driver and one to tell the infrastructure that it
is ready (which I assume your reset call would do). Ultimately this means
that the tcpm driver would have to have additional logic to identify if the
underlying driver is ready to handle callbacks.

Can you delay tcpm registration until after the underlying driver is ready,
ie typically to the end of its probe function ? Or am I misunderstanding
your problem ?


The problem I had was that I was trying to pull the same trick that you do ;)
I.e. the probe function calls tcpm_register_port() that is calling back
to the driver that was trying to call back to tcpm, just that the call to
tcpm_register_port() has not yet returned so the pointer to tcpm_port in the
driver data structure was still null.

I was able to fix the issue by commenting out the call to tcpm_init() at the
end of tcpm_register_port() and instead call ("your") tcpm_tcpc_reset(), that
currently does nothing but calling tcpm_init(), after I'm done.

Even though I'm not overly excited about the tcpm register function calling back
to the driver I don't think my fix is much better. I should live by my own words
and refrain from calling back to tcpm until registration has finished...


Problem is that I can't even defer the call to tcpm_init(), or for that matter 
any
other call into the low level driver code, into the worker, since there is still
no guarantee that the low level driver is "done" with its initialization. The 
only
real solution I can think of is that the low level driver should not use the 
pointer
to tcpm_port in any of its callback functions.

Overall I think there is an assumption in any API that any callback functions 
provided
in a registration call can immediately be called. Otherwise any API would be in 
trouble.
Can you modify your code to not require the port pointer in its callback 
functions ?

Thanks,
Guenter

Re: USB Type-C Port Manager API concern

[Guenter Roeck]

On 04/09/2017 02:05 PM, Mats Karrman wrote:

On 04/09/2017 05:16 PM, Guenter Roeck wrote:


Hi Mats,

On Sun, Apr 09, 2017 at 01:09:57AM +0200, Mats Karrman wrote:

I'm working on a tcpi driver and have some concern about the tcpm api.
The tcpm_register_port() is typically called from the probe function of
tcpi driver where the tcpm_port reference returned is stored in the
driver private data. The problem I ran into is that tcpm_register_port()
calls back to the not yet fully initialized tcpi driver, causing null-
pointer dereferences. This could of course be solved by extra logic in
the tcpi driver but I think it would be more elegant if the registration
of a port could be free of premature callbacks. E.g. it could be required
that the tcpi driver probe called tcpm_tcpc_reset() once it's done
initializing or the necessary data could be supplied in the call to
tcpm_register_port().
What do you think?

Let me think about it. In theory it should be possible to avoid callbacks into
the underlying driver until after the return from the registration code, but
that would still be racy if the underlying driver is not ready.

Basic problem seems to be that an API in general assumes that the caller is
ready to serve it once it registers itself. It is kind of unusual to have two
calls, one to register the driver and one to tell the infrastructure that it
is ready (which I assume your reset call would do). Ultimately this means
that the tcpm driver would have to have additional logic to identify if the
underlying driver is ready to handle callbacks.

Can you delay tcpm registration until after the underlying driver is ready,
ie typically to the end of its probe function ? Or am I misunderstanding
your problem ?


The problem I had was that I was trying to pull the same trick that you do ;)
I.e. the probe function calls tcpm_register_port() that is calling back
to the driver that was trying to call back to tcpm, just that the call to
tcpm_register_port() has not yet returned so the pointer to tcpm_port in the
driver data structure was still null.

I was able to fix the issue by commenting out the call to tcpm_init() at the
end of tcpm_register_port() and instead call ("your") tcpm_tcpc_reset(), that
currently does nothing but calling tcpm_init(), after I'm done.

Even though I'm not overly excited about the tcpm register function calling back
to the driver I don't think my fix is much better. I should live by my own words
and refrain from calling back to tcpm until registration has finished...


Problem is that I can't even defer the call to tcpm_init(), or for that matter 
any
other call into the low level driver code, into the worker, since there is still
no guarantee that the low level driver is "done" with its initialization. The 
only
real solution I can think of is that the low level driver should not use the 
pointer
to tcpm_port in any of its callback functions.

Overall I think there is an assumption in any API that any callback functions 
provided
in a registration call can immediately be called. Otherwise any API would be in 
trouble.
Can you modify your code to not require the port pointer in its callback 
functions ?

Thanks,
Guenter

[PATCH] regulator: vctrl: Fix out of bounds array access for vctrl->vtable

[Axel Lin]

Current code only allocates rdesc->n_voltages entries for vctrl->vtable.
Thus use rdesc->n_voltages instead of n_voltages in the for loop.

While at it, also switch to use devm_kcalloc instead of devm_kmalloc_array
+ __GFP_ZERO flag and fix the argument order.

Signed-off-by: Axel Lin 
---
 drivers/regulator/vctrl-regulator.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/vctrl-regulator.c 
b/drivers/regulator/vctrl-regulator.c
index 6baadef..78de002 100644
--- a/drivers/regulator/vctrl-regulator.c
+++ b/drivers/regulator/vctrl-regulator.c
@@ -345,9 +345,9 @@ static int vctrl_init_vtable(struct platform_device *pdev)
return -EINVAL;
}
 
-   vctrl->vtable = devm_kmalloc_array(
-   >dev, sizeof(struct vctrl_voltage_table),
-   rdesc->n_voltages, GFP_KERNEL | __GFP_ZERO);
+   vctrl->vtable = devm_kcalloc(>dev, rdesc->n_voltages,
+sizeof(struct vctrl_voltage_table),
+GFP_KERNEL);
if (!vctrl->vtable)
return -ENOMEM;
 
@@ -371,7 +371,7 @@ static int vctrl_init_vtable(struct platform_device *pdev)
 NULL);
 
/* pre-calculate OVP-safe downward transitions */
-   for (i = n_voltages - 1; i > 0; i--) {
+   for (i = rdesc->n_voltages - 1; i > 0; i--) {
int j;
int ovp_min_uV = (vctrl->vtable[i].out *
  (100 - vctrl->ovp_threshold)) / 100;
-- 
2.9.3

[PATCH] regulator: vctrl: Fix out of bounds array access for vctrl->vtable

[Axel Lin]

Current code only allocates rdesc->n_voltages entries for vctrl->vtable.
Thus use rdesc->n_voltages instead of n_voltages in the for loop.

While at it, also switch to use devm_kcalloc instead of devm_kmalloc_array
+ __GFP_ZERO flag and fix the argument order.

Signed-off-by: Axel Lin 
---
 drivers/regulator/vctrl-regulator.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/vctrl-regulator.c 
b/drivers/regulator/vctrl-regulator.c
index 6baadef..78de002 100644
--- a/drivers/regulator/vctrl-regulator.c
+++ b/drivers/regulator/vctrl-regulator.c
@@ -345,9 +345,9 @@ static int vctrl_init_vtable(struct platform_device *pdev)
return -EINVAL;
}
 
-   vctrl->vtable = devm_kmalloc_array(
-   >dev, sizeof(struct vctrl_voltage_table),
-   rdesc->n_voltages, GFP_KERNEL | __GFP_ZERO);
+   vctrl->vtable = devm_kcalloc(>dev, rdesc->n_voltages,
+sizeof(struct vctrl_voltage_table),
+GFP_KERNEL);
if (!vctrl->vtable)
return -ENOMEM;
 
@@ -371,7 +371,7 @@ static int vctrl_init_vtable(struct platform_device *pdev)
 NULL);
 
/* pre-calculate OVP-safe downward transitions */
-   for (i = n_voltages - 1; i > 0; i--) {
+   for (i = rdesc->n_voltages - 1; i > 0; i--) {
int j;
int ovp_min_uV = (vctrl->vtable[i].out *
  (100 - vctrl->ovp_threshold)) / 100;
-- 
2.9.3

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Guenter Roeck]

On 04/13/2017 03:53 PM, Moritz Fischer wrote:

Hi Guenter,

On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck  wrote:

On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:

From: Moritz Fischer 

The ChromeOS EC has mapped memory regions where things like temperature
sensors and fan speed are stored. Provide access to those from the
cros-ec mfd device.



Turns out struct cros_ec_device already provides a cmd_readmem callback,
which is widely used by other drivers. Why don't you just use it ?


This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs


Hmm - weird. I thought I saw it implemented for those, but I must have been
struck by lightning or something. Let me check with Gwendal to see how
this (ie its use from iio) is supposed to work on non-LPC systems.

Guenter


emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.

Thanks for the feedback!

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

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Guenter Roeck]

On 04/13/2017 03:53 PM, Moritz Fischer wrote:

Hi Guenter,

On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck  wrote:

On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:

From: Moritz Fischer 

The ChromeOS EC has mapped memory regions where things like temperature
sensors and fan speed are stored. Provide access to those from the
cros-ec mfd device.



Turns out struct cros_ec_device already provides a cmd_readmem callback,
which is widely used by other drivers. Why don't you just use it ?


This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs


Hmm - weird. I thought I saw it implemented for those, but I must have been
struck by lightning or something. Let me check with Gwendal to see how
this (ie its use from iio) is supposed to work on non-LPC systems.

Guenter


emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.

Thanks for the feedback!

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