[PATCH 0/2] selftests: fix for KBUILD_OUTPUT

[Bamvor Jian Zhang]

These patches fix the two compile failures in x86 and net subnet
repectively. Test the folowing build method successful:

make -C tools/testing/selftests TARGETS=xxx
make -C tools/testing/selftests TARGETS=xxx clean
make -C tools/testing/selftests/xxx
make -C tools/testing/selftests/xxx clean
make ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE -C tools/testing/selftests 
TARGETS=xxx
make ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE -C tools/testing/selftests 
TARGETS=xxx clean

Bamvor Jian Zhang (2):
  selftests: fix the broken individual test for x86
  selftests: net:  support KBUILD_OUTPUT for reuseport_bpf_numa

 Documentation/kselftest.txt  |  6 ++
 tools/testing/selftests/net/Makefile |  2 +-
 tools/testing/selftests/x86/Makefile | 23 ++-
 3 files changed, 21 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH 0/2] selftests: fix for KBUILD_OUTPUT

[Bamvor Jian Zhang]

These patches fix the two compile failures in x86 and net subnet
repectively. Test the folowing build method successful:

make -C tools/testing/selftests TARGETS=xxx
make -C tools/testing/selftests TARGETS=xxx clean
make -C tools/testing/selftests/xxx
make -C tools/testing/selftests/xxx clean
make ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE -C tools/testing/selftests 
TARGETS=xxx
make ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE -C tools/testing/selftests 
TARGETS=xxx clean

Bamvor Jian Zhang (2):
  selftests: fix the broken individual test for x86
  selftests: net:  support KBUILD_OUTPUT for reuseport_bpf_numa

 Documentation/kselftest.txt  |  6 ++
 tools/testing/selftests/net/Makefile |  2 +-
 tools/testing/selftests/x86/Makefile | 23 ++-
 3 files changed, 21 insertions(+), 10 deletions(-)

-- 
1.9.1

Re: [PATCH v10 07/11] btrfs_tree.h: fix include from userland

[Masahiro Yamada]

Hi Nicolas,


2017-03-14 21:54 GMT+09:00 Nicolas Dichtel :
> This patch prepares the uapi export by fixing the following errors:
>
> .../linux/btrfs_tree.h:283:2: error: #error "UUID items require 
> BTRFS_UUID_SIZE == 16!"
>  #error "UUID items require BTRFS_UUID_SIZE == 16!"
>
> .../linux/btrfs_tree.h:390:12: error: ‘BTRFS_UUID_SIZE’ undeclared here (not 
> in a function)
>   __u8 uuid[BTRFS_UUID_SIZE];
> ^
> .../linux/btrfs_tree.h:796:16: error: ‘BTRFS_DEV_STAT_VALUES_MAX’ undeclared 
> here (not in a function)
>   __le64 values[BTRFS_DEV_STAT_VALUES_MAX];
>
> Signed-off-by: Nicolas Dichtel 
> ---
>  include/uapi/linux/btrfs_tree.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
> index 6a261cb52d95..6a754ada59af 100644
> --- a/include/uapi/linux/btrfs_tree.h
> +++ b/include/uapi/linux/btrfs_tree.h
> @@ -2,6 +2,7 @@
>  #define _BTRFS_CTREE_H_
>
>  #include 
> +#include 
>

Can you move  below 
to sort the includes alphabetically?

This also applies to:

include/uapi/linux/qrtr.h in 06/11
include/uapi/linux/cryptouser.h  in 08/11


-- 
Best Regards
Masahiro Yamada

[PATCH 2/2] selftests: net: support KBUILD_OUTPUT for reuseport_bpf_numa

[Bamvor Jian Zhang]

reuseport_bpf_numa is not supported by KBUILD_OUTPUT machanism in net
subset. This patch fix this by adding $(OUTPUT) before the target.

Signed-off-by: Bamvor Jian Zhang 
---
 tools/testing/selftests/net/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index fbfe5d0..cc9425e 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -3,7 +3,7 @@
 CFLAGS =  -Wall -Wl,--no-as-needed -O2 -g
 CFLAGS += -I../../../../usr/include/
 
-reuseport_bpf_numa: LDFLAGS += -lnuma
+$(OUTPUT)/reuseport_bpf_numa: LDFLAGS += -lnuma
 
 TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh
 TEST_GEN_FILES =  socket
-- 
1.9.1

Re: [PATCH v10 07/11] btrfs_tree.h: fix include from userland

[Masahiro Yamada]

Hi Nicolas,


2017-03-14 21:54 GMT+09:00 Nicolas Dichtel :
> This patch prepares the uapi export by fixing the following errors:
>
> .../linux/btrfs_tree.h:283:2: error: #error "UUID items require 
> BTRFS_UUID_SIZE == 16!"
>  #error "UUID items require BTRFS_UUID_SIZE == 16!"
>
> .../linux/btrfs_tree.h:390:12: error: ‘BTRFS_UUID_SIZE’ undeclared here (not 
> in a function)
>   __u8 uuid[BTRFS_UUID_SIZE];
> ^
> .../linux/btrfs_tree.h:796:16: error: ‘BTRFS_DEV_STAT_VALUES_MAX’ undeclared 
> here (not in a function)
>   __le64 values[BTRFS_DEV_STAT_VALUES_MAX];
>
> Signed-off-by: Nicolas Dichtel 
> ---
>  include/uapi/linux/btrfs_tree.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
> index 6a261cb52d95..6a754ada59af 100644
> --- a/include/uapi/linux/btrfs_tree.h
> +++ b/include/uapi/linux/btrfs_tree.h
> @@ -2,6 +2,7 @@
>  #define _BTRFS_CTREE_H_
>
>  #include 
> +#include 
>

Can you move  below 
to sort the includes alphabetically?

This also applies to:

include/uapi/linux/qrtr.h in 06/11
include/uapi/linux/cryptouser.h  in 08/11


-- 
Best Regards
Masahiro Yamada

[PATCH 2/2] selftests: net: support KBUILD_OUTPUT for reuseport_bpf_numa

[Bamvor Jian Zhang]

reuseport_bpf_numa is not supported by KBUILD_OUTPUT machanism in net
subset. This patch fix this by adding $(OUTPUT) before the target.

Signed-off-by: Bamvor Jian Zhang 
---
 tools/testing/selftests/net/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index fbfe5d0..cc9425e 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -3,7 +3,7 @@
 CFLAGS =  -Wall -Wl,--no-as-needed -O2 -g
 CFLAGS += -I../../../../usr/include/
 
-reuseport_bpf_numa: LDFLAGS += -lnuma
+$(OUTPUT)/reuseport_bpf_numa: LDFLAGS += -lnuma
 
 TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh
 TEST_GEN_FILES =  socket
-- 
1.9.1

[PATCH 1/2] selftests: fix the broken individual test for x86

[Bamvor Jian Zhang]

Andy Lutomirski report that build individual testcase in x86 is broken:

$ make -C tools/testing/selftests/x86 ldt_gdt_32
make: Entering directory '/home/luto/apps/linux/tools/testing/selftests/x86'
Makefile:44: warning: overriding recipe for target 'clean'
../lib.mk:55: warning: ignoring old recipe for target 'clean'
make: *** No rule to make target 'ldt_gdt_32'.  Stop.
make: Leaving directory '/home/luto/apps/linux/tools/testing/selftests/x86'

This patch fix this issue by adding default OUTPUT and convert
target in Makefile of x86.

And also mention this use case in Documentation/kselftests.txt

Reported-by: Andy Lutomirski 
Signed-off-by: Bamvor Jian Zhang 
---
 Documentation/kselftest.txt  |  6 ++
 tools/testing/selftests/x86/Makefile | 23 ++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/Documentation/kselftest.txt b/Documentation/kselftest.txt
index 5bd5903..3dfca71 100644
--- a/Documentation/kselftest.txt
+++ b/Documentation/kselftest.txt
@@ -43,6 +43,12 @@ See the top-level tools/testing/selftests/Makefile for the 
list of all
 possible targets.
 
 
+Building individual test case of a subset
+=
+You could build the individual test case in subset if subset supported:
+  $  make -C tools/testing/selftests/x86 ldt_gdt_32
+
+
 Running the full range hotplug selftests
 
 
diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 38e0a9c..855a2a1 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -17,8 +17,8 @@ TARGETS_C_64BIT_ALL := $(TARGETS_C_BOTHBITS) 
$(TARGETS_C_64BIT_ONLY)
 BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
 BINARIES_64 := $(TARGETS_C_64BIT_ALL:%=%_64)
 
-BINARIES_32 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_32))
-BINARIES_64 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_64))
+BINARIES_32_FULL_PATH := $(patsubst %,$(OUTPUT)/%,$(BINARIES_32))
+BINARIES_64_FULL_PATH := $(patsubst %,$(OUTPUT)/%,$(BINARIES_64))
 
 CFLAGS := -O2 -g -std=gnu99 -pthread -Wall
 
@@ -28,25 +28,29 @@ CAN_BUILD_X86_64 := $(shell ./check_cc.sh $(CC) 
trivial_64bit_program.c)
 
 ifeq ($(CAN_BUILD_I386),1)
 all: all_32
-TEST_PROGS += $(BINARIES_32)
+TEST_PROGS += $(BINARIES_32_FULL_PATH)
 endif
 
 ifeq ($(CAN_BUILD_X86_64),1)
 all: all_64
-TEST_PROGS += $(BINARIES_64)
+TEST_PROGS += $(BINARIES_64_FULL_PATH)
 endif
 
-all_32: $(BINARIES_32)
+all_32: $(BINARIES_32_FULL_PATH)
 
-all_64: $(BINARIES_64)
+all_64: $(BINARIES_64_FULL_PATH)
 
 clean:
-   $(RM) $(BINARIES_32) $(BINARIES_64)
+   $(RM) $(BINARIES_32_FULL_PATH) $(BINARIES_64_FULL_PATH)
 
-$(BINARIES_32): $(OUTPUT)/%_32: %.c
+$(BINARIES_32): %_32: $(OUTPUT)/%_32
+
+$(BINARIES_64): %_64: $(OUTPUT)/%_64
+
+$(BINARIES_32_FULL_PATH): $(OUTPUT)/%_32: %.c
$(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl -lm
 
-$(BINARIES_64): $(OUTPUT)/%_64: %.c
+$(BINARIES_64_FULL_PATH): $(OUTPUT)/%_64: %.c
$(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
 
 # x86_64 users should be encouraged to install 32-bit libraries
@@ -77,3 +81,4 @@ $(OUTPUT)/test_syscall_vdso_32: thunks_32.S
 # state.
 $(OUTPUT)/check_initial_reg_state_32: CFLAGS += -Wl,-ereal_start -static
 $(OUTPUT)/check_initial_reg_state_64: CFLAGS += -Wl,-ereal_start -static
+
-- 
1.9.1

[PATCH 1/2] selftests: fix the broken individual test for x86

[Bamvor Jian Zhang]

Andy Lutomirski report that build individual testcase in x86 is broken:

$ make -C tools/testing/selftests/x86 ldt_gdt_32
make: Entering directory '/home/luto/apps/linux/tools/testing/selftests/x86'
Makefile:44: warning: overriding recipe for target 'clean'
../lib.mk:55: warning: ignoring old recipe for target 'clean'
make: *** No rule to make target 'ldt_gdt_32'.  Stop.
make: Leaving directory '/home/luto/apps/linux/tools/testing/selftests/x86'

This patch fix this issue by adding default OUTPUT and convert
target in Makefile of x86.

And also mention this use case in Documentation/kselftests.txt

Reported-by: Andy Lutomirski 
Signed-off-by: Bamvor Jian Zhang 
---
 Documentation/kselftest.txt  |  6 ++
 tools/testing/selftests/x86/Makefile | 23 ++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/Documentation/kselftest.txt b/Documentation/kselftest.txt
index 5bd5903..3dfca71 100644
--- a/Documentation/kselftest.txt
+++ b/Documentation/kselftest.txt
@@ -43,6 +43,12 @@ See the top-level tools/testing/selftests/Makefile for the 
list of all
 possible targets.
 
 
+Building individual test case of a subset
+=
+You could build the individual test case in subset if subset supported:
+  $  make -C tools/testing/selftests/x86 ldt_gdt_32
+
+
 Running the full range hotplug selftests
 
 
diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 38e0a9c..855a2a1 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -17,8 +17,8 @@ TARGETS_C_64BIT_ALL := $(TARGETS_C_BOTHBITS) 
$(TARGETS_C_64BIT_ONLY)
 BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
 BINARIES_64 := $(TARGETS_C_64BIT_ALL:%=%_64)
 
-BINARIES_32 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_32))
-BINARIES_64 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_64))
+BINARIES_32_FULL_PATH := $(patsubst %,$(OUTPUT)/%,$(BINARIES_32))
+BINARIES_64_FULL_PATH := $(patsubst %,$(OUTPUT)/%,$(BINARIES_64))
 
 CFLAGS := -O2 -g -std=gnu99 -pthread -Wall
 
@@ -28,25 +28,29 @@ CAN_BUILD_X86_64 := $(shell ./check_cc.sh $(CC) 
trivial_64bit_program.c)
 
 ifeq ($(CAN_BUILD_I386),1)
 all: all_32
-TEST_PROGS += $(BINARIES_32)
+TEST_PROGS += $(BINARIES_32_FULL_PATH)
 endif
 
 ifeq ($(CAN_BUILD_X86_64),1)
 all: all_64
-TEST_PROGS += $(BINARIES_64)
+TEST_PROGS += $(BINARIES_64_FULL_PATH)
 endif
 
-all_32: $(BINARIES_32)
+all_32: $(BINARIES_32_FULL_PATH)
 
-all_64: $(BINARIES_64)
+all_64: $(BINARIES_64_FULL_PATH)
 
 clean:
-   $(RM) $(BINARIES_32) $(BINARIES_64)
+   $(RM) $(BINARIES_32_FULL_PATH) $(BINARIES_64_FULL_PATH)
 
-$(BINARIES_32): $(OUTPUT)/%_32: %.c
+$(BINARIES_32): %_32: $(OUTPUT)/%_32
+
+$(BINARIES_64): %_64: $(OUTPUT)/%_64
+
+$(BINARIES_32_FULL_PATH): $(OUTPUT)/%_32: %.c
$(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl -lm
 
-$(BINARIES_64): $(OUTPUT)/%_64: %.c
+$(BINARIES_64_FULL_PATH): $(OUTPUT)/%_64: %.c
$(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
 
 # x86_64 users should be encouraged to install 32-bit libraries
@@ -77,3 +81,4 @@ $(OUTPUT)/test_syscall_vdso_32: thunks_32.S
 # state.
 $(OUTPUT)/check_initial_reg_state_32: CFLAGS += -Wl,-ereal_start -static
 $(OUTPUT)/check_initial_reg_state_64: CFLAGS += -Wl,-ereal_start -static
+
-- 
1.9.1

Re: SELinux: Fine-tuning for several function implementations

[SF Markus Elfring]

> I've made it through the first half (23/46) and of those
> I've merged patches …, 7, …

It seems that you dropped this one while integrating the eighth
update step.

Regards,
Markus

[PATCH 4/5] fs/autofs4: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in fs/autofs4/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 fs/autofs4/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/autofs4/Kconfig b/fs/autofs4/Kconfig
index 1204d6384d39..44727bf18297 100644
--- a/fs/autofs4/Kconfig
+++ b/fs/autofs4/Kconfig
@@ -7,7 +7,7 @@ config AUTOFS4_FS
  automounter (amd), which is a pure user space daemon.
 
  To use the automounter you need the user-space tools from
- ; you also
+ ; you also
  want to answer Y to "NFS file system support", below.
 
  To compile this support as a module, choose M here: the module will be
-- 
2.10.0

[PATCH 3/5] drivers/md: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in drivers/md/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 drivers/md/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 5c5ed97c9fda..6a41633460ba 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -115,7 +115,7 @@ config MD_RAID10
 
  RAID-10 requires mdadm-1.7.0 or later, available at:
 
- ftp://ftp.kernel.org/pub/linux/utils/raid/mdadm/
+ https://www.kernel.org/pub/linux/utils/raid/mdadm/
 
  If unsure, say Y.
 
-- 
2.10.0

[PATCH 4/5] fs/autofs4: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in fs/autofs4/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 fs/autofs4/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/autofs4/Kconfig b/fs/autofs4/Kconfig
index 1204d6384d39..44727bf18297 100644
--- a/fs/autofs4/Kconfig
+++ b/fs/autofs4/Kconfig
@@ -7,7 +7,7 @@ config AUTOFS4_FS
  automounter (amd), which is a pure user space daemon.
 
  To use the automounter you need the user-space tools from
- ; you also
+ ; you also
  want to answer Y to "NFS file system support", below.
 
  To compile this support as a module, choose M here: the module will be
-- 
2.10.0

[PATCH 3/5] drivers/md: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in drivers/md/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 drivers/md/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 5c5ed97c9fda..6a41633460ba 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -115,7 +115,7 @@ config MD_RAID10
 
  RAID-10 requires mdadm-1.7.0 or later, available at:
 
- ftp://ftp.kernel.org/pub/linux/utils/raid/mdadm/
+ https://www.kernel.org/pub/linux/utils/raid/mdadm/
 
  If unsure, say Y.
 
-- 
2.10.0

Re: SELinux: Fine-tuning for several function implementations

[SF Markus Elfring]

> I've made it through the first half (23/46) and of those
> I've merged patches …, 7, …

It seems that you dropped this one while integrating the eighth
update step.

Regards,
Markus

[PATCH] Input: melfas_mip4 - ensure that device is present

[Dmitry Torokhov]

Try a quick read from the device in mip4_query_device() to make sure
that the device is there, as we do not consider failures to retrieve
product name or resolution fatal.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/melfas_mip4.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/input/touchscreen/melfas_mip4.c 
b/drivers/input/touchscreen/melfas_mip4.c
index 703d7f983d0a..05108c2fea93 100644
--- a/drivers/input/touchscreen/melfas_mip4.c
+++ b/drivers/input/touchscreen/melfas_mip4.c
@@ -253,10 +253,21 @@ static int mip4_get_fw_version(struct mip4_ts *ts)
  */
 static int mip4_query_device(struct mip4_ts *ts)
 {
+   union i2c_smbus_data dummy;
int error;
u8 cmd[2];
u8 buf[14];
 
+   /*
+* Make sure there is something at this address as we do not
+* consider subsequent failures as fatal.
+*/
+   if (i2c_smbus_xfer(ts->client->adapter, ts->client->addr,
+  0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, ) < 0) {
+   dev_err(>client->dev, "nothing at this address\n");
+   return -ENXIO;
+   }
+
/* Product name */
cmd[0] = MIP4_R0_INFO;
cmd[1] = MIP4_R1_INFO_PRODUCT_NAME;
-- 
2.12.1.578.ge9c3154ca4-goog


-- 
Dmitry

[PATCH] Input: melfas_mip4 - ensure that device is present

[Dmitry Torokhov]

Try a quick read from the device in mip4_query_device() to make sure
that the device is there, as we do not consider failures to retrieve
product name or resolution fatal.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/melfas_mip4.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/input/touchscreen/melfas_mip4.c 
b/drivers/input/touchscreen/melfas_mip4.c
index 703d7f983d0a..05108c2fea93 100644
--- a/drivers/input/touchscreen/melfas_mip4.c
+++ b/drivers/input/touchscreen/melfas_mip4.c
@@ -253,10 +253,21 @@ static int mip4_get_fw_version(struct mip4_ts *ts)
  */
 static int mip4_query_device(struct mip4_ts *ts)
 {
+   union i2c_smbus_data dummy;
int error;
u8 cmd[2];
u8 buf[14];
 
+   /*
+* Make sure there is something at this address as we do not
+* consider subsequent failures as fatal.
+*/
+   if (i2c_smbus_xfer(ts->client->adapter, ts->client->addr,
+  0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, ) < 0) {
+   dev_err(>client->dev, "nothing at this address\n");
+   return -ENXIO;
+   }
+
/* Product name */
cmd[0] = MIP4_R0_INFO;
cmd[1] = MIP4_R1_INFO_PRODUCT_NAME;
-- 
2.12.1.578.ge9c3154ca4-goog


-- 
Dmitry

[PATCH 0/5] Fix dead URLs to ftp.kernel.org

[SeongJae Park]

URLs to `ftp.kernel.org` exist here and there though `ftp.kernel.org` is
already dead [0].  This patchset fixes those URLs to use `www.kernel.org`
instead.

The change is splitted into multiple patches for independent review and merge
of each maintainer, though the change is trivial.

[0] https://www.kernel.org/shutting-down-ftp-services.html

SeongJae Park (5):
  MAINTAINERS: Fix a dead URL to ftp.kernel.org
  drivers/block: Fix a dead URL to ftp.kernel.org
  drivers/md: Fix a dead URL to ftp.kernel.org
  fs/autofs4: Fix a dead URL to ftp.kernel.org
  scripts: Fix dead URLs to ftp.kernel.org

 MAINTAINERS  | 2 +-
 drivers/block/Kconfig| 2 +-
 drivers/md/Kconfig   | 2 +-
 fs/autofs4/Kconfig   | 2 +-
 scripts/ksymoops/README  | 5 ++---
 scripts/package/builddeb | 4 ++--
 6 files changed, 8 insertions(+), 9 deletions(-)

-- 
2.10.0

[PATCH 2/5] drivers/block: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in drivers/block/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 drivers/block/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index f744de7a0f9b..7b608cf2516f 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -219,7 +219,7 @@ config BLK_DEV_LOOP
 
  To use the loop device, you need the losetup utility, found in the
  util-linux package, see
- .
+ .
 
  The loop device driver can also be used to "hide" a file system in
  a disk partition, floppy, or regular file, either using encryption
-- 
2.10.0

[PATCH 5/5] scripts: Fix dead URLs to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes dead URLs to
ftp.kernel.org in scripts/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 scripts/ksymoops/README  | 5 ++---
 scripts/package/builddeb | 4 ++--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/scripts/ksymoops/README b/scripts/ksymoops/README
index f6cb06e3f30e..413043980127 100644
--- a/scripts/ksymoops/README
+++ b/scripts/ksymoops/README
@@ -1,8 +1,7 @@
 ksymoops has been removed from the kernel.  It was always meant to be a
 free standing utility, not linked to any particular kernel version.
 The latest version can be found in
-ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops together
-with patches to other utilities in order to give more accurate Oops
-debugging.
+https://www.kernel.org/pub/linux/utils/kernel/ksymoops together with patches to
+other utilities in order to give more accurate Oops debugging.
 
 Keith Owens  Sat Jun 19 10:30:34 EST 1999
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index f04e91f0845d..d7cf7156414e 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -257,8 +257,8 @@ EOF
 cat < debian/copyright
 This is a packacked upstream version of the Linux kernel.
 
-The sources may be found at most Linux ftp sites, including:
-ftp://ftp.kernel.org/pub/linux/kernel
+The sources may be found at most Linux archive sites, including:
+https://www.kernel.org/pub/linux/kernel
 
 Copyright: 1991 - 2015 Linus Torvalds and others.
 
-- 
2.10.0

[PATCH 1/5] MAINTAINERS: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in MAINTAINERS file to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c768d79cf3f..6367f0739394 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10158,7 +10158,7 @@ W:  http://sourceforge.net/projects/accel-pptp
 PREEMPTIBLE KERNEL
 M: Robert Love 
 L: kpreempt-t...@lists.sourceforge.net
-W: ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel
+W: https://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel
 S: Supported
 F: Documentation/preempt-locking.txt
 F: include/linux/preempt.h
-- 
2.10.0

[PATCH 0/5] Fix dead URLs to ftp.kernel.org

[SeongJae Park]

URLs to `ftp.kernel.org` exist here and there though `ftp.kernel.org` is
already dead [0].  This patchset fixes those URLs to use `www.kernel.org`
instead.

The change is splitted into multiple patches for independent review and merge
of each maintainer, though the change is trivial.

[0] https://www.kernel.org/shutting-down-ftp-services.html

SeongJae Park (5):
  MAINTAINERS: Fix a dead URL to ftp.kernel.org
  drivers/block: Fix a dead URL to ftp.kernel.org
  drivers/md: Fix a dead URL to ftp.kernel.org
  fs/autofs4: Fix a dead URL to ftp.kernel.org
  scripts: Fix dead URLs to ftp.kernel.org

 MAINTAINERS  | 2 +-
 drivers/block/Kconfig| 2 +-
 drivers/md/Kconfig   | 2 +-
 fs/autofs4/Kconfig   | 2 +-
 scripts/ksymoops/README  | 5 ++---
 scripts/package/builddeb | 4 ++--
 6 files changed, 8 insertions(+), 9 deletions(-)

-- 
2.10.0

[PATCH 2/5] drivers/block: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in drivers/block/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 drivers/block/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index f744de7a0f9b..7b608cf2516f 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -219,7 +219,7 @@ config BLK_DEV_LOOP
 
  To use the loop device, you need the losetup utility, found in the
  util-linux package, see
- .
+ .
 
  The loop device driver can also be used to "hide" a file system in
  a disk partition, floppy, or regular file, either using encryption
-- 
2.10.0

[PATCH 5/5] scripts: Fix dead URLs to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes dead URLs to
ftp.kernel.org in scripts/ to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 scripts/ksymoops/README  | 5 ++---
 scripts/package/builddeb | 4 ++--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/scripts/ksymoops/README b/scripts/ksymoops/README
index f6cb06e3f30e..413043980127 100644
--- a/scripts/ksymoops/README
+++ b/scripts/ksymoops/README
@@ -1,8 +1,7 @@
 ksymoops has been removed from the kernel.  It was always meant to be a
 free standing utility, not linked to any particular kernel version.
 The latest version can be found in
-ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops together
-with patches to other utilities in order to give more accurate Oops
-debugging.
+https://www.kernel.org/pub/linux/utils/kernel/ksymoops together with patches to
+other utilities in order to give more accurate Oops debugging.
 
 Keith Owens  Sat Jun 19 10:30:34 EST 1999
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index f04e91f0845d..d7cf7156414e 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -257,8 +257,8 @@ EOF
 cat < debian/copyright
 This is a packacked upstream version of the Linux kernel.
 
-The sources may be found at most Linux ftp sites, including:
-ftp://ftp.kernel.org/pub/linux/kernel
+The sources may be found at most Linux archive sites, including:
+https://www.kernel.org/pub/linux/kernel
 
 Copyright: 1991 - 2015 Linus Torvalds and others.
 
-- 
2.10.0

[PATCH 1/5] MAINTAINERS: Fix a dead URL to ftp.kernel.org

[SeongJae Park]

As ftp.kernel.org is closed [0], this commit fixes a dead URL to
ftp.kernel.org in MAINTAINERS file to use www.kernel.org instead.

[0] https://www.kernel.org/shutting-down-ftp-services.html

Signed-off-by: SeongJae Park 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c768d79cf3f..6367f0739394 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10158,7 +10158,7 @@ W:  http://sourceforge.net/projects/accel-pptp
 PREEMPTIBLE KERNEL
 M: Robert Love 
 L: kpreempt-t...@lists.sourceforge.net
-W: ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel
+W: https://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel
 S: Supported
 F: Documentation/preempt-locking.txt
 F: include/linux/preempt.h
-- 
2.10.0

RE: [alsa-devel] [PATCH] ASoC: Add support for Maxim Integrated MAX98927 Amplifier

[Ryans Lee]

> -Original Message-
> From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com]
> Sent: Monday, March 20, 2017 7:14 AM
> To: Ryans Lee 
> Cc: lgirdw...@gmail.com; broo...@kernel.org; robh...@kernel.org; 
> mark.rutl...@arm.com; pe...@perex.cz; ti...@suse.com; 
> kuninori.morimoto...@renesas.com; a...@arndb.de; l...@metafoo.de; 
> bardl...@realtek.com; n...@nh6z.net; kch...@nuvoton.com; 
> axel@ingics.com; romain.per...@collabora.com; p...@barix.com; 
> srinivas.kandaga...@linaro.org; oder_ch...@realtek.com; 
> paul.handri...@cirrus.com; alsa-de...@alsa-project.org; 
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> dgr...@google.com
> Subject: Re: [alsa-devel] [PATCH] ASoC: Add support for Maxim 
> Integrated MAX98927 Amplifier
>
> EXTERNAL EMAIL
>
>
>
> On Mon, Mar 20, 2017 at 09:40:23AM +0900, Ryan Lee wrote:
>> Signed-off-by: Ryan Lee 
>> ---
>> Resubmit the intial version of MAX98927 driver. Added all fixes into the 
>> initial patch.
> 
>> +static int max98927_reg_get(struct snd_kcontrol *kcontrol,
>> + struct snd_ctl_elem_value *ucontrol, unsigned int reg,
>> + unsigned int mask, unsigned int shift) {
>> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + int data;
>> +
>> + regmap_read(max98927->regmap, reg, );
>> + ucontrol->value.integer.value[0] = (data & mask) >> shift;
>> + return 0;
>> +}
>> +
>> +static int max98927_reg_put(struct snd_kcontrol *kcontrol,
>> + struct snd_ctl_elem_value *ucontrol, unsigned int reg,
>> + unsigned int mask, unsigned int shift) {
>> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + unsigned int sel = ucontrol->value.integer.value[0];
>> +
>> + regmap_update_bits(max98927->regmap, reg, mask, sel << shift);
>> + dev_dbg(codec->dev, "%s: register 0x%02X, value 0x%02X\n",
>> + __func__, reg, sel);
>> + return 0;
>> +}
>
> These functions look a lot like they duplicate things the ASoC core does?

You're right. I removed 'max98927_reg_get' and 'max98927_reg_put' function to 
avoid duplication.

>
> 
>> +static int max98927_boost_voltage_get(struct snd_kcontrol *kcontrol,
>> + struct snd_ctl_elem_value *ucontrol) {
>> + return max98927_reg_get(kcontrol, ucontrol,
>> + MAX98927_R0040_BOOST_CTRL0,
>> + MAX98927_BOOST_CTRL0_VOUT_MASK, 0); }
>> +
>
> And can't these just be specified in the normal way with the register 
> information attached to the control? There doesn't seem to be any special 
> behaviour being added here. Apologies if I am missing something here.

Thank you for your feedback. Now SOC_ENUM_EXT was replaced by SOC_ENUM. 
SOC_SINGLE_EXT was also replaced by SOC_SINGLE. Above function is no longer 
being used.

>
> Thanks,
> Charles

RE: [alsa-devel] [PATCH] ASoC: Add support for Maxim Integrated MAX98927 Amplifier

[Ryans Lee]

> -Original Message-
> From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com]
> Sent: Monday, March 20, 2017 7:14 AM
> To: Ryans Lee 
> Cc: lgirdw...@gmail.com; broo...@kernel.org; robh...@kernel.org; 
> mark.rutl...@arm.com; pe...@perex.cz; ti...@suse.com; 
> kuninori.morimoto...@renesas.com; a...@arndb.de; l...@metafoo.de; 
> bardl...@realtek.com; n...@nh6z.net; kch...@nuvoton.com; 
> axel@ingics.com; romain.per...@collabora.com; p...@barix.com; 
> srinivas.kandaga...@linaro.org; oder_ch...@realtek.com; 
> paul.handri...@cirrus.com; alsa-de...@alsa-project.org; 
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> dgr...@google.com
> Subject: Re: [alsa-devel] [PATCH] ASoC: Add support for Maxim 
> Integrated MAX98927 Amplifier
>
> EXTERNAL EMAIL
>
>
>
> On Mon, Mar 20, 2017 at 09:40:23AM +0900, Ryan Lee wrote:
>> Signed-off-by: Ryan Lee 
>> ---
>> Resubmit the intial version of MAX98927 driver. Added all fixes into the 
>> initial patch.
> 
>> +static int max98927_reg_get(struct snd_kcontrol *kcontrol,
>> + struct snd_ctl_elem_value *ucontrol, unsigned int reg,
>> + unsigned int mask, unsigned int shift) {
>> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + int data;
>> +
>> + regmap_read(max98927->regmap, reg, );
>> + ucontrol->value.integer.value[0] = (data & mask) >> shift;
>> + return 0;
>> +}
>> +
>> +static int max98927_reg_put(struct snd_kcontrol *kcontrol,
>> + struct snd_ctl_elem_value *ucontrol, unsigned int reg,
>> + unsigned int mask, unsigned int shift) {
>> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + unsigned int sel = ucontrol->value.integer.value[0];
>> +
>> + regmap_update_bits(max98927->regmap, reg, mask, sel << shift);
>> + dev_dbg(codec->dev, "%s: register 0x%02X, value 0x%02X\n",
>> + __func__, reg, sel);
>> + return 0;
>> +}
>
> These functions look a lot like they duplicate things the ASoC core does?

You're right. I removed 'max98927_reg_get' and 'max98927_reg_put' function to 
avoid duplication.

>
> 
>> +static int max98927_boost_voltage_get(struct snd_kcontrol *kcontrol,
>> + struct snd_ctl_elem_value *ucontrol) {
>> + return max98927_reg_get(kcontrol, ucontrol,
>> + MAX98927_R0040_BOOST_CTRL0,
>> + MAX98927_BOOST_CTRL0_VOUT_MASK, 0); }
>> +
>
> And can't these just be specified in the normal way with the register 
> information attached to the control? There doesn't seem to be any special 
> behaviour being added here. Apologies if I am missing something here.

Thank you for your feedback. Now SOC_ENUM_EXT was replaced by SOC_ENUM. 
SOC_SINGLE_EXT was also replaced by SOC_SINGLE. Above function is no longer 
being used.

>
> Thanks,
> Charles

Re: [PATCH] PCI: dwc: fix crash seen due to missing ops

[Kishon Vijay Abraham I]

Hi,

On Thursday 23 March 2017 01:10 PM, Niklas Cassel wrote:
> On 03/22/2017 04:47 PM, Joao Pinto wrote:
>> Hi Niklas,
>>
>> Às 2:43 PM de 3/21/2017, Niklas Cassel escreveu:
>>> From: Niklas Cassel 
>>>
>>> Fix the following crash, seen in dwc/pcie-artpec6.
>>>
>>>   Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0004
>>>   pgd = c0204000
>>>   [0004] *pgd=
>>>   Internal error: Oops: 5 [#1] SMP ARM
>>>   Modules linked in:
>>>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
>>>   Hardware name: Axis ARTPEC-6 Platform
>>>   task: db098000 task.stack: db096000
>>>   PC is at dw_pcie_writel_dbi+0x2c/0xd0
>>>   ...
>>>
>>> While at it, fix the same problem for pcie-designware-plat.
>>>
>>> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only 
>>> and core structures")
>>> Signed-off-by: Niklas Cassel 
>>> ---
>>>  drivers/pci/dwc/pcie-artpec6.c | 4 
>>>  drivers/pci/dwc/pcie-designware-plat.c | 4 
>>>  2 files changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
>>> index fcd3ef845883..6d23683c0892 100644
>>> --- a/drivers/pci/dwc/pcie-artpec6.c
>>> +++ b/drivers/pci/dwc/pcie-artpec6.c
>>> @@ -234,6 +234,9 @@ static int artpec6_add_pcie_port(struct artpec6_pcie 
>>> *artpec6_pcie,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int artpec6_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -252,6 +255,7 @@ static int artpec6_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> artpec6_pcie->pci = pci;
>>>  
>>> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
>>> b/drivers/pci/dwc/pcie-designware-plat.c
>>> index b6c832ba39dd..f20d494922ab 100644
>>> --- a/drivers/pci/dwc/pcie-designware-plat.c
>>> +++ b/drivers/pci/dwc/pcie-designware-plat.c
>>> @@ -86,6 +86,9 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int dw_plat_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -103,6 +106,7 @@ static int dw_plat_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> dw_plat_pcie->pci = pci;
>>>  
>>>
>> In the case of pcie-designware-plat you have the declaration of pci->ops:
>> https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-designware-plat.c#n78
>>
>> and in artpec6 in here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-artpec6.c#n226
>>
>> Both declarations are made previously of calling dw_pcie_host_init(), so why 
>> do
>> you need this dummy ops in the probe function? I never had that necessity.
> 
> Hello Joao
> 
> Since commit 442ec4c04d12, we now have two different ops,
> dw_pcie_ops (ops for dw_pcie) and dw_pcie_host_ops (ops for a pcie_port),
> note that they are different. The dw_pcie_ops is missing for pcie-artpec6
> and pcie-designware-plat (since we are using the generic link-up function).
> 
> Before commit 442ec4c04d12, dw_pcie_writel_dbi had dw_pcie_host_ops as
> parameter, after the commit it has dw_pcie_ops as parameter.
> It should crash on pcie-designware-plat as well, since there are other
> functions, like dw_pcie_link_up, that assumes that pci->ops != null.
> 
> Another alternative to adding the dummy ops would be to add null checks
> for all uses off pci->ops in pcie-designware.c.
> I don't like the idea to sprinkle null checks everywhere pci->ops is used.

I'm okay either ways.

Acked-by: Kishon Vijay Abraham I 

> 
> One could add a null check in dw_pcie_host_init, but without a dummy ops
> we would still fail this check, so our drivers would still be non-functional
> in Linus's tree.
> 

Re: [PATCH] PCI: dwc: fix crash seen due to missing ops

[Kishon Vijay Abraham I]

Hi,

On Thursday 23 March 2017 01:10 PM, Niklas Cassel wrote:
> On 03/22/2017 04:47 PM, Joao Pinto wrote:
>> Hi Niklas,
>>
>> Às 2:43 PM de 3/21/2017, Niklas Cassel escreveu:
>>> From: Niklas Cassel 
>>>
>>> Fix the following crash, seen in dwc/pcie-artpec6.
>>>
>>>   Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0004
>>>   pgd = c0204000
>>>   [0004] *pgd=
>>>   Internal error: Oops: 5 [#1] SMP ARM
>>>   Modules linked in:
>>>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
>>>   Hardware name: Axis ARTPEC-6 Platform
>>>   task: db098000 task.stack: db096000
>>>   PC is at dw_pcie_writel_dbi+0x2c/0xd0
>>>   ...
>>>
>>> While at it, fix the same problem for pcie-designware-plat.
>>>
>>> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only 
>>> and core structures")
>>> Signed-off-by: Niklas Cassel 
>>> ---
>>>  drivers/pci/dwc/pcie-artpec6.c | 4 
>>>  drivers/pci/dwc/pcie-designware-plat.c | 4 
>>>  2 files changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
>>> index fcd3ef845883..6d23683c0892 100644
>>> --- a/drivers/pci/dwc/pcie-artpec6.c
>>> +++ b/drivers/pci/dwc/pcie-artpec6.c
>>> @@ -234,6 +234,9 @@ static int artpec6_add_pcie_port(struct artpec6_pcie 
>>> *artpec6_pcie,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int artpec6_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -252,6 +255,7 @@ static int artpec6_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> artpec6_pcie->pci = pci;
>>>  
>>> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
>>> b/drivers/pci/dwc/pcie-designware-plat.c
>>> index b6c832ba39dd..f20d494922ab 100644
>>> --- a/drivers/pci/dwc/pcie-designware-plat.c
>>> +++ b/drivers/pci/dwc/pcie-designware-plat.c
>>> @@ -86,6 +86,9 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int dw_plat_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -103,6 +106,7 @@ static int dw_plat_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> dw_plat_pcie->pci = pci;
>>>  
>>>
>> In the case of pcie-designware-plat you have the declaration of pci->ops:
>> https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-designware-plat.c#n78
>>
>> and in artpec6 in here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-artpec6.c#n226
>>
>> Both declarations are made previously of calling dw_pcie_host_init(), so why 
>> do
>> you need this dummy ops in the probe function? I never had that necessity.
> 
> Hello Joao
> 
> Since commit 442ec4c04d12, we now have two different ops,
> dw_pcie_ops (ops for dw_pcie) and dw_pcie_host_ops (ops for a pcie_port),
> note that they are different. The dw_pcie_ops is missing for pcie-artpec6
> and pcie-designware-plat (since we are using the generic link-up function).
> 
> Before commit 442ec4c04d12, dw_pcie_writel_dbi had dw_pcie_host_ops as
> parameter, after the commit it has dw_pcie_ops as parameter.
> It should crash on pcie-designware-plat as well, since there are other
> functions, like dw_pcie_link_up, that assumes that pci->ops != null.
> 
> Another alternative to adding the dummy ops would be to add null checks
> for all uses off pci->ops in pcie-designware.c.
> I don't like the idea to sprinkle null checks everywhere pci->ops is used.

I'm okay either ways.

Acked-by: Kishon Vijay Abraham I 

> 
> One could add a null check in dw_pcie_host_init, but without a dummy ops
> we would still fail this check, so our drivers would still be non-functional
> in Linus's tree.
> 

linux-next: Tree for Mar 27

[Stephen Rothwell]

Hi all,

Changes since 20170324:

The gfs2 tree gained conflicts against the net tree.

The kspp tree gained a conflict against the drm-misc tree.

Non-merge commits (relative to Linus' tree): 4906
 5492 files changed, 403174 insertions(+), 90419 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c02ed2e75ef4 Linux 4.11-rc4)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (ae9955aeb8e4 ARC: vdk: Fix support of UIO)
Merging arm-current/fixes (a1016e94cce9 ARM: wire up statx syscall)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (cc638a488a52 gcc-plugins: update architecture list 
in documentation)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6ac3b77a6fff irda: vlsi_ir: fix check for DMA mapping 
errors)
Merging ipsec/master (72ef9c4125c7 dccp: fix memory leak during tear-down of 
unsuccessful connection request)
Merging netfilter/master (f83bf8da1135 netfilter: nfnl_cthelper: Fix memory 
leak)
Merging ipvs/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging wireless-drivers/master (6be3b6cce1e2 ath10k: fix incorrect 
wlan_mac_base in qca6174_regs)
Merging mac80211/master (ea90e0dc8cec nl80211: fix dumpit error path RTNL 
deadlocks)
Merging sound-current/for-linus (3f307834e695 ALSA: hda - Adding a group of pin 
definition to fix headset problem)
Merging pci-current/for-linus (9abb27c7594a PCI: thunder-pem: Add legacy 
firmware support for Cavium ThunderX host controller)
Merging driver-core.current/driver-core-linus (966fa72a716c kernfs: Check 
KERNFS_HAS_RELEASE before calling kernfs_release_file())
Merging tty.current/tty-linus (a4a3e061149f tty: fix data race in 
tty_ldisc_ref_wait())
Merging usb.current/usb-linus (fd290e7096bd Merge tag 'usb-serial-4.11-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (436ecf5519d8 USB: serial: qcserial: add 
Dell DW5811e)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (43c49938bf72 Merge tag 
'iio-fixes-for-4.11c' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (5c1724c42dc1 Merge tag 
'extcon-fixes-for-4.11-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (5659495a7a14 uapi: add missing install of 
userio.h)
Merging crypto-current/master (9df0eb180c20 crypto: xts,lrw - fix out-of-bounds 
write after kmalloc failure)
Merging ide/master (96297aee8bce ide: palm_bk3710: add 

linux-next: Tree for Mar 27

[Stephen Rothwell]

Hi all,

Changes since 20170324:

The gfs2 tree gained conflicts against the net tree.

The kspp tree gained a conflict against the drm-misc tree.

Non-merge commits (relative to Linus' tree): 4906
 5492 files changed, 403174 insertions(+), 90419 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c02ed2e75ef4 Linux 4.11-rc4)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (ae9955aeb8e4 ARC: vdk: Fix support of UIO)
Merging arm-current/fixes (a1016e94cce9 ARM: wire up statx syscall)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (cc638a488a52 gcc-plugins: update architecture list 
in documentation)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6ac3b77a6fff irda: vlsi_ir: fix check for DMA mapping 
errors)
Merging ipsec/master (72ef9c4125c7 dccp: fix memory leak during tear-down of 
unsuccessful connection request)
Merging netfilter/master (f83bf8da1135 netfilter: nfnl_cthelper: Fix memory 
leak)
Merging ipvs/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging wireless-drivers/master (6be3b6cce1e2 ath10k: fix incorrect 
wlan_mac_base in qca6174_regs)
Merging mac80211/master (ea90e0dc8cec nl80211: fix dumpit error path RTNL 
deadlocks)
Merging sound-current/for-linus (3f307834e695 ALSA: hda - Adding a group of pin 
definition to fix headset problem)
Merging pci-current/for-linus (9abb27c7594a PCI: thunder-pem: Add legacy 
firmware support for Cavium ThunderX host controller)
Merging driver-core.current/driver-core-linus (966fa72a716c kernfs: Check 
KERNFS_HAS_RELEASE before calling kernfs_release_file())
Merging tty.current/tty-linus (a4a3e061149f tty: fix data race in 
tty_ldisc_ref_wait())
Merging usb.current/usb-linus (fd290e7096bd Merge tag 'usb-serial-4.11-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (436ecf5519d8 USB: serial: qcserial: add 
Dell DW5811e)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (43c49938bf72 Merge tag 
'iio-fixes-for-4.11c' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (5c1724c42dc1 Merge tag 
'extcon-fixes-for-4.11-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (5659495a7a14 uapi: add missing install of 
userio.h)
Merging crypto-current/master (9df0eb180c20 crypto: xts,lrw - fix out-of-bounds 
write after kmalloc failure)
Merging ide/master (96297aee8bce ide: palm_bk3710: add 

Re: [PATCH v10 00/11] uapi: export all headers under uapi directories

[Masahiro Yamada]

Hi Nocolas,


2017-03-24 18:03 GMT+09:00 Nicolas Dichtel :
> Le 24/03/2017 à 09:42, Masahiro Yamada a écrit :
>> Hi Nicolas,
>>
>>
>> 2017-03-24 17:32 GMT+09:00 Nicolas Dichtel :
>>> Le 14/03/2017 à 13:54, Nicolas Dichtel a écrit :
 Patches #1 and #2 are just cleanup: some exported headers were still under
 a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was
 not under an uapi directory.
 After these three patches, all exported headers are under an uapi 
 directory:
 path #4 stops searching files in non uapi directories.
 The patch #5 was spotted by code review: there is no in-tree user of this
 functionality.
 Patch #6 fixes some warnings/errors reported by 0-day tests.
 Patch #7 to #9 fix some errors when the corresponding files are included by
 userland.
 Patches #10 and #11 remove the need to list explicitly headers. Now all 
 files
 under an uapi directory are exported.

 This series has been tested with a 'make headers_install' on x86 and a
 'make headers_install_all'. I've checked the result of both commands.

 This patch is built on top of masahiroy/linux-kbuild.git#for-next 
 (v4.11-rc1).
 I didn't find any conflict with v4.11-rc2.
>>> Masahiro, is this series under review or do you expect something else on my 
>>> side?
>>>
>>
>> Under review.
>> Please give me time to take a closer look.
>> Sorry for the delay.
> No problem, take your time. I just wanted to be sure to not miss something ;-)
>
>


As a whole, this series is amazing.  Thanks for your great work!


I added some comments, but they are trivial.




I wanted to leave comments/questions on 10/11,
but I could not find 10/11 in my mailbox.  I do not know why.


I am leaving comments on the cover-letter,
the following are related to 10/11.



[1]

>mandatory-y += $(foreach hdr,$(opt-header), \
>  $(if \
>$(wildcard \
>$(srctree)/arch/$(SRCARCH)/include/uapi/asm/$(hdr) \
>$(srctree)/arch/$(SRCARCH)/include/asm/$(hdr) \
>), \
>$(hdr) \
>))

What is this actually checking?

If ARCH has its own (uapi/)asm/{kvm.h,kvm_para.h,a.out.h},
they are added to mandatory-y, then they are checked if they exist.
But, we know they exist.


This check reminds us only when we added asm/*.h
but forgot to add uapi/asm/*.h

$(srctree)/arch/$(SRCARCH)/include/uapi/asm/$(hdr) seems unneeded at least.
(perhaps, the whole hunk might be unneeded.)



[2]

>ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/a.out.h \
> $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h),)
>header-n += a.out.h
>endif
>
>ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/kvm.h \
> $(srctree)/arch/$(SRCARCH)/include/asm/kvm.h),)
>header-n += kvm.h
>endif
>
>ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/kvm_para.h \
> $(srctree)/arch/$(SRCARCH)/include/asm/kvm_para.h),)
>header-n += kvm_para.h
>endif

This series intends all headers are exported from uapi/, correct?
Do we still need to check $(srctree)/arch/$(SRCARCH)/include/asm/*.h ?
(related to [1])



[3]

>--- 7.1 header-n
>
>header-n is essentially used by include/uapi/linux/Kbuild to avoid
>exporting specific headers (e.g. kvm.h) on architectures that do not
>support it. It should be avoided as much as possible.


Going forward, header-y will be never used
because uapi/ is exported by default.

So, I wonder if we could rename this into something clearer.

Kbuild supports "no-clean-files".
(Please see ./Kbuild for its usage)
I guess this notation seems clearer
when we want to negate the default behavior.

Can you consider "no-export", "no-export-files", "no-export-headers"
or whatever you like?




Thanks!



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v10 00/11] uapi: export all headers under uapi directories

[Masahiro Yamada]

Hi Nocolas,


2017-03-24 18:03 GMT+09:00 Nicolas Dichtel :
> Le 24/03/2017 à 09:42, Masahiro Yamada a écrit :
>> Hi Nicolas,
>>
>>
>> 2017-03-24 17:32 GMT+09:00 Nicolas Dichtel :
>>> Le 14/03/2017 à 13:54, Nicolas Dichtel a écrit :
 Patches #1 and #2 are just cleanup: some exported headers were still under
 a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was
 not under an uapi directory.
 After these three patches, all exported headers are under an uapi 
 directory:
 path #4 stops searching files in non uapi directories.
 The patch #5 was spotted by code review: there is no in-tree user of this
 functionality.
 Patch #6 fixes some warnings/errors reported by 0-day tests.
 Patch #7 to #9 fix some errors when the corresponding files are included by
 userland.
 Patches #10 and #11 remove the need to list explicitly headers. Now all 
 files
 under an uapi directory are exported.

 This series has been tested with a 'make headers_install' on x86 and a
 'make headers_install_all'. I've checked the result of both commands.

 This patch is built on top of masahiroy/linux-kbuild.git#for-next 
 (v4.11-rc1).
 I didn't find any conflict with v4.11-rc2.
>>> Masahiro, is this series under review or do you expect something else on my 
>>> side?
>>>
>>
>> Under review.
>> Please give me time to take a closer look.
>> Sorry for the delay.
> No problem, take your time. I just wanted to be sure to not miss something ;-)
>
>


As a whole, this series is amazing.  Thanks for your great work!


I added some comments, but they are trivial.




I wanted to leave comments/questions on 10/11,
but I could not find 10/11 in my mailbox.  I do not know why.


I am leaving comments on the cover-letter,
the following are related to 10/11.



[1]

>mandatory-y += $(foreach hdr,$(opt-header), \
>  $(if \
>$(wildcard \
>$(srctree)/arch/$(SRCARCH)/include/uapi/asm/$(hdr) \
>$(srctree)/arch/$(SRCARCH)/include/asm/$(hdr) \
>), \
>$(hdr) \
>))

What is this actually checking?

If ARCH has its own (uapi/)asm/{kvm.h,kvm_para.h,a.out.h},
they are added to mandatory-y, then they are checked if they exist.
But, we know they exist.


This check reminds us only when we added asm/*.h
but forgot to add uapi/asm/*.h

$(srctree)/arch/$(SRCARCH)/include/uapi/asm/$(hdr) seems unneeded at least.
(perhaps, the whole hunk might be unneeded.)



[2]

>ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/a.out.h \
> $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h),)
>header-n += a.out.h
>endif
>
>ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/kvm.h \
> $(srctree)/arch/$(SRCARCH)/include/asm/kvm.h),)
>header-n += kvm.h
>endif
>
>ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/kvm_para.h \
> $(srctree)/arch/$(SRCARCH)/include/asm/kvm_para.h),)
>header-n += kvm_para.h
>endif

This series intends all headers are exported from uapi/, correct?
Do we still need to check $(srctree)/arch/$(SRCARCH)/include/asm/*.h ?
(related to [1])



[3]

>--- 7.1 header-n
>
>header-n is essentially used by include/uapi/linux/Kbuild to avoid
>exporting specific headers (e.g. kvm.h) on architectures that do not
>support it. It should be avoided as much as possible.


Going forward, header-y will be never used
because uapi/ is exported by default.

So, I wonder if we could rename this into something clearer.

Kbuild supports "no-clean-files".
(Please see ./Kbuild for its usage)
I guess this notation seems clearer
when we want to negate the default behavior.

Can you consider "no-export", "no-export-files", "no-export-headers"
or whatever you like?




Thanks!



-- 
Best Regards
Masahiro Yamada

Re: linux-next: build warning after merge of the spi tree

[Vignesh R]

On Monday 27 March 2017 08:11 AM, Stephen Rothwell wrote:
> Hi Mark,
> 
> After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> drivers/spi/spi-ti-qspi.c: In function 'ti_qspi_dma_xfer':
> drivers/spi/spi-ti-qspi.c:398:21: warning: unused variable 'dma_dev' 
> [-Wunused-variable]
>   struct dma_device *dma_dev = chan->device;
>  ^
> 
> Introduced by commit
> 
>   1351aaeb50b2 ("spi: spi-ti-qspi: Use dma_engine wrapper for dma memcpy 
> call")
> 

Sorry, I have posted a fix for the same.

-- 
Regards
Vignesh

Re: linux-next: build warning after merge of the spi tree

[Vignesh R]

On Monday 27 March 2017 08:11 AM, Stephen Rothwell wrote:
> Hi Mark,
> 
> After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> drivers/spi/spi-ti-qspi.c: In function 'ti_qspi_dma_xfer':
> drivers/spi/spi-ti-qspi.c:398:21: warning: unused variable 'dma_dev' 
> [-Wunused-variable]
>   struct dma_device *dma_dev = chan->device;
>  ^
> 
> Introduced by commit
> 
>   1351aaeb50b2 ("spi: spi-ti-qspi: Use dma_engine wrapper for dma memcpy 
> call")
> 

Sorry, I have posted a fix for the same.

-- 
Regards
Vignesh

[PATCH v2] ASoC: Add support for Maxim Integrated MAX98927 Amplifier

[Ryan Lee]

Signed-off-by: Ryan Lee 
---
v2: Removed local register read/write function to avoid duplication of ASoC 
core function.
 .../devicetree/bindings/sound/max98927.txt |  39 +
 sound/soc/codecs/Kconfig   |   5 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/max98927.c| 826 +
 sound/soc/codecs/max98927.h| 267 +++
 5 files changed, 1139 insertions(+)
 create mode 100755 Documentation/devicetree/bindings/sound/max98927.txt
 mode change 100644 => 100755 sound/soc/codecs/Kconfig
 mode change 100644 => 100755 sound/soc/codecs/Makefile
 create mode 100755 sound/soc/codecs/max98927.c
 create mode 100755 sound/soc/codecs/max98927.h

diff --git a/Documentation/devicetree/bindings/sound/max98927.txt 
b/Documentation/devicetree/bindings/sound/max98927.txt
new file mode 100755
index 000..d610879
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98927.txt
@@ -0,0 +1,39 @@
+max98927 audio CODEC
+
+This device supports I2C.
+
+Required properties:
+
+  - compatible : "maxim,max98927"
+
+  - maxim,vmon-slot-no : slot number used to send voltage information
+   or in inteleave mode this will be used as
+   interleave slot.
+   This property can be set to values from 0 to 15 for slot 0 
to 15.
+   Default value is 0.
+
+  - maxim,imon-slot-no : slot number used to send current information
+   This property can be set to values from 0 to 15 for slot 0 
to 15.
+   Default value is 0.
+
+  - maxim,interleave-mode : When using two MAX98927 in a system it is
+   possible to create ADC data that that will
+   overflow the frame size. Digital Audio Interleave
+   mode provides a means to output VMON and IMON data
+   from two devices on a single DOUT line when running
+   smaller frames sizes such as 32 BCLKS per LRCLK or
+   48 BCLKS per LRCLK.
+   This property can be set to values from 0 to 1 for off and 
on.
+   Default value is 0.
+
+  - reg : the I2C address of the device for I2C
+
+Example:
+
+codec: max98927@3a {
+   compatible = "maxim,max98927";
+   maxim,vmon-slot-no = <0>;
+   maxim,imon-slot-no = <1>;
+   maxim,interleave-mode = <0>;
+   reg = <0x3a>;
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
old mode 100644
new mode 100755
index e49e9da..cbdc8aa
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -89,6 +89,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX9867 if I2C
select SND_SOC_MAX98925 if I2C
select SND_SOC_MAX98926 if I2C
+   select SND_SOC_MAX98927 if I2C
select SND_SOC_MAX9850 if I2C
select SND_SOC_MAX9860 if I2C
select SND_SOC_MAX9768 if I2C
@@ -588,6 +589,10 @@ config SND_SOC_MAX98925
 config SND_SOC_MAX98926
tristate
 
+config SND_SOC_MAX98927
+   tristate "Maxim Integrated MAX98927 Speaker Amplifier"
+   depends on I2C
+
 config SND_SOC_MAX9850
tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
old mode 100644
new mode 100755
index 1796cb9..187a639
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -84,6 +84,7 @@ snd-soc-max98371-objs := max98371.o
 snd-soc-max9867-objs := max9867.o
 snd-soc-max98925-objs := max98925.o
 snd-soc-max98926-objs := max98926.o
+snd-soc-max98927-objs := max98927.o
 snd-soc-max9850-objs := max9850.o
 snd-soc-max9860-objs := max9860.o
 snd-soc-mc13783-objs := mc13783.o
@@ -313,6 +314,7 @@ obj-$(CONFIG_SND_SOC_MAX98357A) += snd-soc-max98357a.o
 obj-$(CONFIG_SND_SOC_MAX9867)  += snd-soc-max9867.o
 obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
 obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
+obj-$(CONFIG_SND_SOC_MAX98927) += snd-soc-max98927.o
 obj-$(CONFIG_SND_SOC_MAX9850)  += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MAX9860)  += snd-soc-max9860.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
new file mode 100755
index 000..784a106
--- /dev/null
+++ b/sound/soc/codecs/max98927.c
@@ -0,0 +1,826 @@
+/*
+ * max98927.c  --  MAX98927 ALSA Soc Audio driver
+ *
+ * Copyright (C) 2016 Maxim Integrated Products
+ * Author: Ryan Lee 
+ *
+ *  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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "max98927.h"
+
+static struct reg_default max98927_reg[] = {
+   

[PATCH v2] ASoC: Add support for Maxim Integrated MAX98927 Amplifier

[Ryan Lee]

Signed-off-by: Ryan Lee 
---
v2: Removed local register read/write function to avoid duplication of ASoC 
core function.
 .../devicetree/bindings/sound/max98927.txt |  39 +
 sound/soc/codecs/Kconfig   |   5 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/max98927.c| 826 +
 sound/soc/codecs/max98927.h| 267 +++
 5 files changed, 1139 insertions(+)
 create mode 100755 Documentation/devicetree/bindings/sound/max98927.txt
 mode change 100644 => 100755 sound/soc/codecs/Kconfig
 mode change 100644 => 100755 sound/soc/codecs/Makefile
 create mode 100755 sound/soc/codecs/max98927.c
 create mode 100755 sound/soc/codecs/max98927.h

diff --git a/Documentation/devicetree/bindings/sound/max98927.txt 
b/Documentation/devicetree/bindings/sound/max98927.txt
new file mode 100755
index 000..d610879
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98927.txt
@@ -0,0 +1,39 @@
+max98927 audio CODEC
+
+This device supports I2C.
+
+Required properties:
+
+  - compatible : "maxim,max98927"
+
+  - maxim,vmon-slot-no : slot number used to send voltage information
+   or in inteleave mode this will be used as
+   interleave slot.
+   This property can be set to values from 0 to 15 for slot 0 
to 15.
+   Default value is 0.
+
+  - maxim,imon-slot-no : slot number used to send current information
+   This property can be set to values from 0 to 15 for slot 0 
to 15.
+   Default value is 0.
+
+  - maxim,interleave-mode : When using two MAX98927 in a system it is
+   possible to create ADC data that that will
+   overflow the frame size. Digital Audio Interleave
+   mode provides a means to output VMON and IMON data
+   from two devices on a single DOUT line when running
+   smaller frames sizes such as 32 BCLKS per LRCLK or
+   48 BCLKS per LRCLK.
+   This property can be set to values from 0 to 1 for off and 
on.
+   Default value is 0.
+
+  - reg : the I2C address of the device for I2C
+
+Example:
+
+codec: max98927@3a {
+   compatible = "maxim,max98927";
+   maxim,vmon-slot-no = <0>;
+   maxim,imon-slot-no = <1>;
+   maxim,interleave-mode = <0>;
+   reg = <0x3a>;
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
old mode 100644
new mode 100755
index e49e9da..cbdc8aa
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -89,6 +89,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX9867 if I2C
select SND_SOC_MAX98925 if I2C
select SND_SOC_MAX98926 if I2C
+   select SND_SOC_MAX98927 if I2C
select SND_SOC_MAX9850 if I2C
select SND_SOC_MAX9860 if I2C
select SND_SOC_MAX9768 if I2C
@@ -588,6 +589,10 @@ config SND_SOC_MAX98925
 config SND_SOC_MAX98926
tristate
 
+config SND_SOC_MAX98927
+   tristate "Maxim Integrated MAX98927 Speaker Amplifier"
+   depends on I2C
+
 config SND_SOC_MAX9850
tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
old mode 100644
new mode 100755
index 1796cb9..187a639
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -84,6 +84,7 @@ snd-soc-max98371-objs := max98371.o
 snd-soc-max9867-objs := max9867.o
 snd-soc-max98925-objs := max98925.o
 snd-soc-max98926-objs := max98926.o
+snd-soc-max98927-objs := max98927.o
 snd-soc-max9850-objs := max9850.o
 snd-soc-max9860-objs := max9860.o
 snd-soc-mc13783-objs := mc13783.o
@@ -313,6 +314,7 @@ obj-$(CONFIG_SND_SOC_MAX98357A) += snd-soc-max98357a.o
 obj-$(CONFIG_SND_SOC_MAX9867)  += snd-soc-max9867.o
 obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
 obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
+obj-$(CONFIG_SND_SOC_MAX98927) += snd-soc-max98927.o
 obj-$(CONFIG_SND_SOC_MAX9850)  += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MAX9860)  += snd-soc-max9860.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
new file mode 100755
index 000..784a106
--- /dev/null
+++ b/sound/soc/codecs/max98927.c
@@ -0,0 +1,826 @@
+/*
+ * max98927.c  --  MAX98927 ALSA Soc Audio driver
+ *
+ * Copyright (C) 2016 Maxim Integrated Products
+ * Author: Ryan Lee 
+ *
+ *  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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "max98927.h"
+
+static struct reg_default max98927_reg[] = {
+   {MAX98927_R0001_INT_RAW1,  0x00},
+   

Re: [BUG nohz]: wrong user and system time accounting

[lkml]

On Thu, Mar 23, 2017 at 08:56:02PM -0400, Rik van Riel wrote:
> On Thu, 2017-03-23 at 16:55 -0400, Luiz Capitulino wrote:
> > When there are two or more tasks executing in user-space and
> > taking 100% of a nohz_full CPU, top reports 70% system time
> > and 30% user time utilization. Sometimes I'm even able to get
> > 100% system time and 0% user time.
> > 
> > This was reproduced with latest Linus tree (093b995), but I
> > don't believe it's a regression (at least not a recent one)
> > as I can reproduce it with older kernels. Also, I have
> > CONFIG_IRQ_TIME_ACCOUNTING=y and haven't tried to reproduce
> > without it yet.
> > 
> > Below you'll find the steps to reproduce and some initial
> > analysis.
> > 
> > Steps to reproduce
> > --
> > 
> > 1. Set up a CPU for nohz_full with isolcpus= nohz_full=
> > 
> > 2. Pin two tasks that hog the CPU 100% of the time to that CPU
> > 
> > 3. Run top -d1 and check system time
> > 
> > NOTE: When there's only one task hogging a nohz_full CPU, top
> >   shows 100% user-time, as expected
> > 
> > Initial analysis
> > 
> > 
> > When tracing vtime accounting functions and the user-space/kernel
> > transitions when the issue is taking place, I see several of the
> > following:
> > 
> > hog-10552 [015]  1132.711104:
> > function: enter_from_user_mode <-- apic_timer_interrupt
> > hog-10552 [015]  1132.711105:
> > function: __context_tracking_exit <--
> > enter_from_user_mode
> > hog-10552 [015]  1132.711105:
> > bprint:   __context_tracking_exit.part.4: new state=1 cur
> > state=1 active=1
> > hog-10552 [015]  1132.711105:
> > function: vtime_account_user <--
> > __context_tracking_exit.part.4
> > hog-10552 [015]  1132.711105:
> > function: smp_apic_timer_interrupt <--
> > apic_timer_interrupt
> > hog-10552 [015]  1132.711106: function: irq_enter <--
> > smp_apic_timer_interrupt
> > hog-10552 [015]  1132.711106: function: tick_sched_timer
> > <-- __hrtimer_run_queues
> > hog-10552 [015]  1132.711108: function: irq_exit <--
> > smp_apic_timer_interrupt
> > hog-10552 [015]  1132.711108:
> > function: __context_tracking_enter <--
> > prepare_exit_to_usermode
> > hog-10552 [015]  1132.711108:
> > bprint:   __context_tracking_enter.part.2: new state=1
> > cur state=0 active=1
> > hog-10552 [015]  1132.711109: function: vtime_user_enter
> > <-- __context_tracking_enter.part.2
> > hog-10552 [015]  1132.711109:
> > function: __vtime_account_system <-- vtime_user_enter
> > hog-10552 [015]  1132.711109:
> > function: account_system_time <-- __vtime_account_system
> > 
> > On entering the kernel due to a timer interrupt, vtime_account_user()
> > skips user-time accounting. Then later on when returning to user-
> > space,
> > vtime_user_enter() is probably accounting the whole time (ie. user-
> > space
> > plus kernel-space) to system time.
> > 
> > Now, when does vtime_account_user() skips accounting? Well, when the
> > time delta is less then one jiffie. This would imply that
> > vtime_account_user()
> > is being called less than one jiffie since the last accounting, but I
> > haven't
> > confirmed any of this yet.
> 
> Jiffies should be advanced by the timer interrupt, on the
> housekeeping CPU, which is not doing context tracking.
> 
> Why is the isolated/nohz_full CPU receiving timer interrupts
> at all?
> 
> I thought it would not, but obviously I am wrong. What is
> going on here?

This thread sounds awful familiar to me.

With CONFIG_NO_HZ_FULL=y && CONFIG_VIRT_CPU_ACCOUNTING_GEN=y I observed process
accounting anomalies with user CPU time being misaccounted as system time all
the way back to 4.6.0.

After switching to CONFIG_NO_HZ_IDLE=y && CONFIG_VIRT_CPU_ACCOUNTING_GEN=n the
issues went away.

The lkml thread I had seen at that time which compelled me to suspect these
settings was this:
http://lkml.iu.edu/hypermail/linux/kernel/1608.2/05860.html

It sounds like this issue is finally beginning to be understood though, good
work!

Regards,
Vito Caputo

Re: [PATCH v10 11/11] uapi: export all arch specifics directories

[Masahiro Yamada]

Hi Nicolas,


2017-03-14 21:54 GMT+09:00 Nicolas Dichtel :
> diff --git a/arch/cris/include/uapi/asm/Kbuild 
> b/arch/cris/include/uapi/asm/Kbuild
> index d0c5471856e0..b15bf6bc0e94 100644
> --- a/arch/cris/include/uapi/asm/Kbuild
> +++ b/arch/cris/include/uapi/asm/Kbuild
> @@ -1,5 +1,2 @@
>  # UAPI Header export list
>  include include/uapi/asm-generic/Kbuild.asm
> -
> -subdir-y += ../arch-v10/arch/
> -subdir-y += ../arch-v32/arch/


Can you remove
arch/cris/include/arch-v32/arch/Kbuild
arch/cris/include/arch-v10/arch/Kbuild
as well?

Or, not sure if they are still needed?



> diff --git a/arch/tile/include/uapi/asm/Kbuild 
> b/arch/tile/include/uapi/asm/Kbuild
> index e0a50111e07f..0c74c3c5ebfa 100644
> --- a/arch/tile/include/uapi/asm/Kbuild
> +++ b/arch/tile/include/uapi/asm/Kbuild
> @@ -2,5 +2,3 @@
>  include include/uapi/asm-generic/Kbuild.asm
>
>  generic-y += ucontext.h
> -
> -subdir-y += ../arch

Can you remove  arch/tile/include/arch/Kbuild as well?




-- 
Best Regards
Masahiro Yamada

Re: [BUG nohz]: wrong user and system time accounting

[lkml]

On Thu, Mar 23, 2017 at 08:56:02PM -0400, Rik van Riel wrote:
> On Thu, 2017-03-23 at 16:55 -0400, Luiz Capitulino wrote:
> > When there are two or more tasks executing in user-space and
> > taking 100% of a nohz_full CPU, top reports 70% system time
> > and 30% user time utilization. Sometimes I'm even able to get
> > 100% system time and 0% user time.
> > 
> > This was reproduced with latest Linus tree (093b995), but I
> > don't believe it's a regression (at least not a recent one)
> > as I can reproduce it with older kernels. Also, I have
> > CONFIG_IRQ_TIME_ACCOUNTING=y and haven't tried to reproduce
> > without it yet.
> > 
> > Below you'll find the steps to reproduce and some initial
> > analysis.
> > 
> > Steps to reproduce
> > --
> > 
> > 1. Set up a CPU for nohz_full with isolcpus= nohz_full=
> > 
> > 2. Pin two tasks that hog the CPU 100% of the time to that CPU
> > 
> > 3. Run top -d1 and check system time
> > 
> > NOTE: When there's only one task hogging a nohz_full CPU, top
> >   shows 100% user-time, as expected
> > 
> > Initial analysis
> > 
> > 
> > When tracing vtime accounting functions and the user-space/kernel
> > transitions when the issue is taking place, I see several of the
> > following:
> > 
> > hog-10552 [015]  1132.711104:
> > function: enter_from_user_mode <-- apic_timer_interrupt
> > hog-10552 [015]  1132.711105:
> > function: __context_tracking_exit <--
> > enter_from_user_mode
> > hog-10552 [015]  1132.711105:
> > bprint:   __context_tracking_exit.part.4: new state=1 cur
> > state=1 active=1
> > hog-10552 [015]  1132.711105:
> > function: vtime_account_user <--
> > __context_tracking_exit.part.4
> > hog-10552 [015]  1132.711105:
> > function: smp_apic_timer_interrupt <--
> > apic_timer_interrupt
> > hog-10552 [015]  1132.711106: function: irq_enter <--
> > smp_apic_timer_interrupt
> > hog-10552 [015]  1132.711106: function: tick_sched_timer
> > <-- __hrtimer_run_queues
> > hog-10552 [015]  1132.711108: function: irq_exit <--
> > smp_apic_timer_interrupt
> > hog-10552 [015]  1132.711108:
> > function: __context_tracking_enter <--
> > prepare_exit_to_usermode
> > hog-10552 [015]  1132.711108:
> > bprint:   __context_tracking_enter.part.2: new state=1
> > cur state=0 active=1
> > hog-10552 [015]  1132.711109: function: vtime_user_enter
> > <-- __context_tracking_enter.part.2
> > hog-10552 [015]  1132.711109:
> > function: __vtime_account_system <-- vtime_user_enter
> > hog-10552 [015]  1132.711109:
> > function: account_system_time <-- __vtime_account_system
> > 
> > On entering the kernel due to a timer interrupt, vtime_account_user()
> > skips user-time accounting. Then later on when returning to user-
> > space,
> > vtime_user_enter() is probably accounting the whole time (ie. user-
> > space
> > plus kernel-space) to system time.
> > 
> > Now, when does vtime_account_user() skips accounting? Well, when the
> > time delta is less then one jiffie. This would imply that
> > vtime_account_user()
> > is being called less than one jiffie since the last accounting, but I
> > haven't
> > confirmed any of this yet.
> 
> Jiffies should be advanced by the timer interrupt, on the
> housekeeping CPU, which is not doing context tracking.
> 
> Why is the isolated/nohz_full CPU receiving timer interrupts
> at all?
> 
> I thought it would not, but obviously I am wrong. What is
> going on here?

This thread sounds awful familiar to me.

With CONFIG_NO_HZ_FULL=y && CONFIG_VIRT_CPU_ACCOUNTING_GEN=y I observed process
accounting anomalies with user CPU time being misaccounted as system time all
the way back to 4.6.0.

After switching to CONFIG_NO_HZ_IDLE=y && CONFIG_VIRT_CPU_ACCOUNTING_GEN=n the
issues went away.

The lkml thread I had seen at that time which compelled me to suspect these
settings was this:
http://lkml.iu.edu/hypermail/linux/kernel/1608.2/05860.html

It sounds like this issue is finally beginning to be understood though, good
work!

Regards,
Vito Caputo

Re: [PATCH v10 11/11] uapi: export all arch specifics directories

[Masahiro Yamada]

Hi Nicolas,


2017-03-14 21:54 GMT+09:00 Nicolas Dichtel :
> diff --git a/arch/cris/include/uapi/asm/Kbuild 
> b/arch/cris/include/uapi/asm/Kbuild
> index d0c5471856e0..b15bf6bc0e94 100644
> --- a/arch/cris/include/uapi/asm/Kbuild
> +++ b/arch/cris/include/uapi/asm/Kbuild
> @@ -1,5 +1,2 @@
>  # UAPI Header export list
>  include include/uapi/asm-generic/Kbuild.asm
> -
> -subdir-y += ../arch-v10/arch/
> -subdir-y += ../arch-v32/arch/


Can you remove
arch/cris/include/arch-v32/arch/Kbuild
arch/cris/include/arch-v10/arch/Kbuild
as well?

Or, not sure if they are still needed?



> diff --git a/arch/tile/include/uapi/asm/Kbuild 
> b/arch/tile/include/uapi/asm/Kbuild
> index e0a50111e07f..0c74c3c5ebfa 100644
> --- a/arch/tile/include/uapi/asm/Kbuild
> +++ b/arch/tile/include/uapi/asm/Kbuild
> @@ -2,5 +2,3 @@
>  include include/uapi/asm-generic/Kbuild.asm
>
>  generic-y += ucontext.h
> -
> -subdir-y += ../arch

Can you remove  arch/tile/include/arch/Kbuild as well?




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v10 01/11] h8300: put bitsperlong.h in uapi

[Masahiro Yamada]

Hi Nicolas,


2017-03-14 21:54 GMT+09:00 Nicolas Dichtel :
> This header file is exported, thus move it to uapi.
>
> Signed-off-by: Nicolas Dichtel 



> -#endif /* __ASM_H8300_BITS_PER_LONG */
> diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h 
> b/arch/h8300/include/uapi/asm/bitsperlong.h
> new file mode 100644
> index ..e56cf72369b6
> --- /dev/null
> +++ b/arch/h8300/include/uapi/asm/bitsperlong.h
> @@ -0,0 +1,14 @@
> +#ifndef _UAPI_ASM_H8300_BITS_PER_LONG
> +#define _UAPI_ASM_H8300_BITS_PER_LONG


Just a minor comment.

The include guard was originally __ASM_H8300_BITS_PER_LONG.
This will change it into _ASM_H8300_BITS_PER_LONG
(after _UAPI is stripped by headers_install.sh)

I just thought _UAPI__ASM_H8300_BITS_PER_LONG might be even safer,
but I know I am nit-picking.  I can apply this as-is.
I leave it to you.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v10 01/11] h8300: put bitsperlong.h in uapi

[Masahiro Yamada]

Hi Nicolas,


2017-03-14 21:54 GMT+09:00 Nicolas Dichtel :
> This header file is exported, thus move it to uapi.
>
> Signed-off-by: Nicolas Dichtel 



> -#endif /* __ASM_H8300_BITS_PER_LONG */
> diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h 
> b/arch/h8300/include/uapi/asm/bitsperlong.h
> new file mode 100644
> index ..e56cf72369b6
> --- /dev/null
> +++ b/arch/h8300/include/uapi/asm/bitsperlong.h
> @@ -0,0 +1,14 @@
> +#ifndef _UAPI_ASM_H8300_BITS_PER_LONG
> +#define _UAPI_ASM_H8300_BITS_PER_LONG


Just a minor comment.

The include guard was originally __ASM_H8300_BITS_PER_LONG.
This will change it into _ASM_H8300_BITS_PER_LONG
(after _UAPI is stripped by headers_install.sh)

I just thought _UAPI__ASM_H8300_BITS_PER_LONG might be even safer,
but I know I am nit-picking.  I can apply this as-is.
I leave it to you.


-- 
Best Regards
Masahiro Yamada

[PATCH RESEND] dmaengine: pl330: remove pdata based initialization

[Marek Szyprowski]

This driver is now used only on platforms which support device tree, so
it is safe to remove legacy platform data based initialization code.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Ulf Hansson 
Acked-by: Arnd Bergmann 
For plat-samsung:
Acked-by: Krzysztof Kozlowski 
---
This was earlier a part of "[PATCH v8 0/3] DMA Engine: switch PL330
driver to non-irq-safe runtime PM" patchset, but it is independent from
the other patches in that patchset and can be applied separately.
---
 arch/arm/plat-samsung/devs.c |  1 -
 drivers/dma/pl330.c  | 42 --
 include/linux/amba/pl330.h   | 35 ---
 3 files changed, 8 insertions(+), 70 deletions(-)
 delete mode 100644 include/linux/amba/pl330.h

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 03fac123676d..dc269d9143bc 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -10,7 +10,6 @@
  * published by the Free Software Foundation.
 */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index f37f4978dabb..8b0da7fa520d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2077,18 +2076,6 @@ static void pl330_tasklet(unsigned long data)
}
 }
 
-bool pl330_filter(struct dma_chan *chan, void *param)
-{
-   u8 *peri_id;
-
-   if (chan->device->dev->driver != _driver.drv)
-   return false;
-
-   peri_id = chan->private;
-   return *peri_id == (unsigned long)param;
-}
-EXPORT_SYMBOL(pl330_filter);
-
 static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma)
 {
@@ -2833,7 +2820,6 @@ static int __maybe_unused pl330_resume(struct device *dev)
 static int
 pl330_probe(struct amba_device *adev, const struct amba_id *id)
 {
-   struct dma_pl330_platdata *pdat;
struct pl330_config *pcfg;
struct pl330_dmac *pl330;
struct dma_pl330_chan *pch, *_p;
@@ -2843,8 +2829,6 @@ static int __maybe_unused pl330_resume(struct device *dev)
int num_chan;
struct device_node *np = adev->dev.of_node;
 
-   pdat = dev_get_platdata(>dev);
-
ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (ret)
return ret;
@@ -2857,7 +2841,7 @@ static int __maybe_unused pl330_resume(struct device *dev)
pd = >ddma;
pd->dev = >dev;
 
-   pl330->mcbufsz = pdat ? pdat->mcbuf_sz : 0;
+   pl330->mcbufsz = 0;
 
/* get quirk */
for (i = 0; i < ARRAY_SIZE(of_quirks); i++)
@@ -2901,10 +2885,7 @@ static int __maybe_unused pl330_resume(struct device 
*dev)
INIT_LIST_HEAD(>channels);
 
/* Initialize channel parameters */
-   if (pdat)
-   num_chan = max_t(int, pdat->nr_valid_peri, pcfg->num_chan);
-   else
-   num_chan = max_t(int, pcfg->num_peri, pcfg->num_chan);
+   num_chan = max_t(int, pcfg->num_peri, pcfg->num_chan);
 
pl330->num_peripherals = num_chan;
 
@@ -2916,11 +2897,8 @@ static int __maybe_unused pl330_resume(struct device 
*dev)
 
for (i = 0; i < num_chan; i++) {
pch = >peripherals[i];
-   if (!adev->dev.of_node)
-   pch->chan.private = pdat ? >peri_id[i] : NULL;
-   else
-   pch->chan.private = adev->dev.of_node;
 
+   pch->chan.private = adev->dev.of_node;
INIT_LIST_HEAD(>submitted_list);
INIT_LIST_HEAD(>work_list);
INIT_LIST_HEAD(>completed_list);
@@ -2933,15 +2911,11 @@ static int __maybe_unused pl330_resume(struct device 
*dev)
list_add_tail(>chan.device_node, >channels);
}
 
-   if (pdat) {
-   pd->cap_mask = pdat->cap_mask;
-   } else {
-   dma_cap_set(DMA_MEMCPY, pd->cap_mask);
-   if (pcfg->num_peri) {
-   dma_cap_set(DMA_SLAVE, pd->cap_mask);
-   dma_cap_set(DMA_CYCLIC, pd->cap_mask);
-   dma_cap_set(DMA_PRIVATE, pd->cap_mask);
-   }
+   dma_cap_set(DMA_MEMCPY, pd->cap_mask);
+   if (pcfg->num_peri) {
+   dma_cap_set(DMA_SLAVE, pd->cap_mask);
+   dma_cap_set(DMA_CYCLIC, pd->cap_mask);
+   dma_cap_set(DMA_PRIVATE, pd->cap_mask);
}
 
pd->device_alloc_chan_resources = pl330_alloc_chan_resources;
diff --git a/include/linux/amba/pl330.h b/include/linux/amba/pl330.h
deleted file mode 100644
index fe93758e8403..
--- a/include/linux/amba/pl330.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/* linux/include/linux/amba/pl330.h
- *
- * Copyright (C) 2010 Samsung Electronics Co. Ltd.
- * Jaswinder 

[PATCH RESEND] dmaengine: pl330: remove pdata based initialization

[Marek Szyprowski]

This driver is now used only on platforms which support device tree, so
it is safe to remove legacy platform data based initialization code.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Ulf Hansson 
Acked-by: Arnd Bergmann 
For plat-samsung:
Acked-by: Krzysztof Kozlowski 
---
This was earlier a part of "[PATCH v8 0/3] DMA Engine: switch PL330
driver to non-irq-safe runtime PM" patchset, but it is independent from
the other patches in that patchset and can be applied separately.
---
 arch/arm/plat-samsung/devs.c |  1 -
 drivers/dma/pl330.c  | 42 --
 include/linux/amba/pl330.h   | 35 ---
 3 files changed, 8 insertions(+), 70 deletions(-)
 delete mode 100644 include/linux/amba/pl330.h

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 03fac123676d..dc269d9143bc 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -10,7 +10,6 @@
  * published by the Free Software Foundation.
 */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index f37f4978dabb..8b0da7fa520d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2077,18 +2076,6 @@ static void pl330_tasklet(unsigned long data)
}
 }
 
-bool pl330_filter(struct dma_chan *chan, void *param)
-{
-   u8 *peri_id;
-
-   if (chan->device->dev->driver != _driver.drv)
-   return false;
-
-   peri_id = chan->private;
-   return *peri_id == (unsigned long)param;
-}
-EXPORT_SYMBOL(pl330_filter);
-
 static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma)
 {
@@ -2833,7 +2820,6 @@ static int __maybe_unused pl330_resume(struct device *dev)
 static int
 pl330_probe(struct amba_device *adev, const struct amba_id *id)
 {
-   struct dma_pl330_platdata *pdat;
struct pl330_config *pcfg;
struct pl330_dmac *pl330;
struct dma_pl330_chan *pch, *_p;
@@ -2843,8 +2829,6 @@ static int __maybe_unused pl330_resume(struct device *dev)
int num_chan;
struct device_node *np = adev->dev.of_node;
 
-   pdat = dev_get_platdata(>dev);
-
ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (ret)
return ret;
@@ -2857,7 +2841,7 @@ static int __maybe_unused pl330_resume(struct device *dev)
pd = >ddma;
pd->dev = >dev;
 
-   pl330->mcbufsz = pdat ? pdat->mcbuf_sz : 0;
+   pl330->mcbufsz = 0;
 
/* get quirk */
for (i = 0; i < ARRAY_SIZE(of_quirks); i++)
@@ -2901,10 +2885,7 @@ static int __maybe_unused pl330_resume(struct device 
*dev)
INIT_LIST_HEAD(>channels);
 
/* Initialize channel parameters */
-   if (pdat)
-   num_chan = max_t(int, pdat->nr_valid_peri, pcfg->num_chan);
-   else
-   num_chan = max_t(int, pcfg->num_peri, pcfg->num_chan);
+   num_chan = max_t(int, pcfg->num_peri, pcfg->num_chan);
 
pl330->num_peripherals = num_chan;
 
@@ -2916,11 +2897,8 @@ static int __maybe_unused pl330_resume(struct device 
*dev)
 
for (i = 0; i < num_chan; i++) {
pch = >peripherals[i];
-   if (!adev->dev.of_node)
-   pch->chan.private = pdat ? >peri_id[i] : NULL;
-   else
-   pch->chan.private = adev->dev.of_node;
 
+   pch->chan.private = adev->dev.of_node;
INIT_LIST_HEAD(>submitted_list);
INIT_LIST_HEAD(>work_list);
INIT_LIST_HEAD(>completed_list);
@@ -2933,15 +2911,11 @@ static int __maybe_unused pl330_resume(struct device 
*dev)
list_add_tail(>chan.device_node, >channels);
}
 
-   if (pdat) {
-   pd->cap_mask = pdat->cap_mask;
-   } else {
-   dma_cap_set(DMA_MEMCPY, pd->cap_mask);
-   if (pcfg->num_peri) {
-   dma_cap_set(DMA_SLAVE, pd->cap_mask);
-   dma_cap_set(DMA_CYCLIC, pd->cap_mask);
-   dma_cap_set(DMA_PRIVATE, pd->cap_mask);
-   }
+   dma_cap_set(DMA_MEMCPY, pd->cap_mask);
+   if (pcfg->num_peri) {
+   dma_cap_set(DMA_SLAVE, pd->cap_mask);
+   dma_cap_set(DMA_CYCLIC, pd->cap_mask);
+   dma_cap_set(DMA_PRIVATE, pd->cap_mask);
}
 
pd->device_alloc_chan_resources = pl330_alloc_chan_resources;
diff --git a/include/linux/amba/pl330.h b/include/linux/amba/pl330.h
deleted file mode 100644
index fe93758e8403..
--- a/include/linux/amba/pl330.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/* linux/include/linux/amba/pl330.h
- *
- * Copyright (C) 2010 Samsung Electronics Co. Ltd.
- * Jaswinder Singh 
- *
- * This program is free software; you can redistribute it and/or 

Re: [RFC PATCH 1/1] tpm_tis: convert to using locality callbacks

[Jarkko Sakkinen]

On Sat, Mar 25, 2017 at 01:05:21PM -0700, Jerry Snitselaar wrote:
> This patch converts tpm_tis to use of the new tpm class ops
> request_locality, and relinquish_locality.
> 
> With the move to using the callbacks, release_locality is changed so
> that we now release the locality even if there is no request pending.
> 
> This required some changes to the tpm_tis_core_init code path to
> make sure locality is requested when needed:
> 
>   - tpm2_probe code path will end up calling request/release through
> callbacks, so request_locality prior to tpm2_probe not needed.
> 
>   - probe_itpm makes calls to tpm_tis_send_data which no longer calls
> request_locality, so add request_locality prior to tpm_tis_send_data
> calls. Also drop release_locality call in middleof probe_itpm, and
> keep locality until release_locality called at end of probe_itpm.
> 
> Cc: Peter Huewe 
> Cc: Jarkko Sakkinen 
> Cc: Jason Gunthorpe 
> Cc: Marcel Selhorst 
> Signed-off-by: Jerry Snitselaar 
> ---
>  drivers/char/tpm/tpm_tis_core.c | 35 +--
>  1 file changed, 9 insertions(+), 26 deletions(-)

LGTM except what Jason said earlier.

/Jarkko

Re: [RFC PATCH 1/1] tpm_tis: convert to using locality callbacks

[Jarkko Sakkinen]

On Sat, Mar 25, 2017 at 01:05:21PM -0700, Jerry Snitselaar wrote:
> This patch converts tpm_tis to use of the new tpm class ops
> request_locality, and relinquish_locality.
> 
> With the move to using the callbacks, release_locality is changed so
> that we now release the locality even if there is no request pending.
> 
> This required some changes to the tpm_tis_core_init code path to
> make sure locality is requested when needed:
> 
>   - tpm2_probe code path will end up calling request/release through
> callbacks, so request_locality prior to tpm2_probe not needed.
> 
>   - probe_itpm makes calls to tpm_tis_send_data which no longer calls
> request_locality, so add request_locality prior to tpm_tis_send_data
> calls. Also drop release_locality call in middleof probe_itpm, and
> keep locality until release_locality called at end of probe_itpm.
> 
> Cc: Peter Huewe 
> Cc: Jarkko Sakkinen 
> Cc: Jason Gunthorpe 
> Cc: Marcel Selhorst 
> Signed-off-by: Jerry Snitselaar 
> ---
>  drivers/char/tpm/tpm_tis_core.c | 35 +--
>  1 file changed, 9 insertions(+), 26 deletions(-)

LGTM except what Jason said earlier.

/Jarkko

Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands

[Jarkko Sakkinen]

On Mon, Mar 20, 2017 at 09:56:17AM +, alexander.stef...@infineon.com wrote:
> > I think the most straight-forward way to sort this out would be to limit
> > validation to the resource manager.
> 
> Sounds good to me.
> 
> > If I send a fix, would you care to test it?
> 
> Sure, will do.
> 
> Alexander

I sent the patch. Please check it out.

/Jarkko

Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands

[Jarkko Sakkinen]

On Mon, Mar 20, 2017 at 09:56:17AM +, alexander.stef...@infineon.com wrote:
> > I think the most straight-forward way to sort this out would be to limit
> > validation to the resource manager.
> 
> Sounds good to me.
> 
> > If I send a fix, would you care to test it?
> 
> Sure, will do.
> 
> Alexander

I sent the patch. Please check it out.

/Jarkko

Re: [PATCH v2] dma: imx-sdma: add 1ms delay to ensure SDMA channel is stopped

[Vinod Koul]

On Thu, Mar 16, 2017 at 11:12:09PM -0700, jiada_w...@mentor.com wrote:
> From: Jiada Wang 
> 
> sdma_disable_channel() cannot ensure dma is stopped to access
> module's FIFOs. There is chance SDMA core is running and accessing
> BD when disable of corresponding channel, this may cause sometimes
> even after call of .sdma_disable_channel(), SDMA core still be
> running and accessing module's FIFOs.
> 
> According to NXP R team a delay of one BD SDMA cost time (maximum
> is 1ms) should be added after disable of the channel bit, to ensure
> SDMA core has really been stopped after SDMA clients call
> .device_terminate_all.
> 
> This patch introduces adds a new function sdma_disable_channel_with_delay()
> which simply adds 1ms delay after call sdma_disable_channel(),
> and set it as .device_terminate_all.

Applied after fixing the subsystem name.


-- 
~Vinod

Re: [PATCH v2] dma: imx-sdma: add 1ms delay to ensure SDMA channel is stopped

[Vinod Koul]

On Thu, Mar 16, 2017 at 11:12:09PM -0700, jiada_w...@mentor.com wrote:
> From: Jiada Wang 
> 
> sdma_disable_channel() cannot ensure dma is stopped to access
> module's FIFOs. There is chance SDMA core is running and accessing
> BD when disable of corresponding channel, this may cause sometimes
> even after call of .sdma_disable_channel(), SDMA core still be
> running and accessing module's FIFOs.
> 
> According to NXP R team a delay of one BD SDMA cost time (maximum
> is 1ms) should be added after disable of the channel bit, to ensure
> SDMA core has really been stopped after SDMA clients call
> .device_terminate_all.
> 
> This patch introduces adds a new function sdma_disable_channel_with_delay()
> which simply adds 1ms delay after call sdma_disable_channel(),
> and set it as .device_terminate_all.

Applied after fixing the subsystem name.


-- 
~Vinod

Re: [PATCH v4] tpm_crb: request and relinquish locality 0

[Jarkko Sakkinen]

On Sun, Mar 26, 2017 at 03:42:12PM -0700, Jerry Snitselaar wrote:
> 
> Jarkko Sakkinen @ 2017-03-26 19:51 GMT:
> 
> > WTF, I applied old patch version by mistake. Sorry about that and
> > thanks for spotting that out. Better?
> >
> > /Jarkko
> 
> 
> Looks good now.

Great, thanks.

/Jarkko

Re: [PATCH v4] tpm_crb: request and relinquish locality 0

[Jarkko Sakkinen]

On Sun, Mar 26, 2017 at 03:42:12PM -0700, Jerry Snitselaar wrote:
> 
> Jarkko Sakkinen @ 2017-03-26 19:51 GMT:
> 
> > WTF, I applied old patch version by mistake. Sorry about that and
> > thanks for spotting that out. Better?
> >
> > /Jarkko
> 
> 
> Looks good now.

Great, thanks.

/Jarkko

Re: [PATCH 1/2] dmaengine: qcom_hidma: disable/enable IRQs on pause/resume

[Vinod Koul]

On Sat, Mar 25, 2017 at 07:04:02PM -0400, Sinan Kaya wrote:
> Once the channels are stopped, disable interrupts to make sure no new
> HW interaction can happen.
> 
> Similarly, re-enable the interrupts only if we know that channel is
> operational again.

Applied both, thanks

-- 
~Vinod

Re: [PATCH 1/2] dmaengine: qcom_hidma: disable/enable IRQs on pause/resume

[Vinod Koul]

On Sat, Mar 25, 2017 at 07:04:02PM -0400, Sinan Kaya wrote:
> Once the channels are stopped, disable interrupts to make sure no new
> HW interaction can happen.
> 
> Similarly, re-enable the interrupts only if we know that channel is
> operational again.

Applied both, thanks

-- 
~Vinod

Re: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

[joechang]

Hi Corey,

Thanks your feedback and suggestion. :)
I think you are right. It is better to allocate one new local variable 
to store i2c data and size that will be sent...

I create new patch in following according to your suggestion.
Could you help to review the patch again?

From eec31f51acc7e019fd0dcc512febda86870268d2 Mon Sep 17 00:00:00 2001
From: Joeseph Chang 
Date: Mon, 27 Mar 2017 10:46:42 +0800
Subject: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

msg_written_handler() may set ssif_info->multi_data to NULL
when using ipmitool to write fru.

Fix kernel panic at ipmi_ssif_thread() and incorrect
ssif_info->multi_pos by adding one local pointer i2c_data to store i2c
data and size to send before calling ssif_i2c_send().

With this change, can avoid concurrent access to ssif_info->multi_pos 
and

ssif_info->multi_data at msg_written_handler.
Because msg_written_handler can be called at any time after 
ssif_i2c_send().

---
 drivers/char/ipmi/ipmi_ssif.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 drivers/char/ipmi/ipmi_ssif.c

diff --git a/drivers/char/ipmi/ipmi_ssif.c 
b/drivers/char/ipmi/ipmi_ssif.c

old mode 100644
new mode 100755
index cca6e5b..f36f018
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -852,6 +852,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

 unsigned char *data, unsigned int len)
 {
 int rv;
+unsigned char *i2c_data;

 /* We are single-threaded here, so no need for a lock. */
 if (result < 0) {
@@ -899,6 +900,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

 left = 32;
 /* Length byte. */
 ssif_info->multi_data[ssif_info->multi_pos] = left;
+i2c_data = ssif_info->multi_data + ssif_info->multi_pos;
 ssif_info->multi_pos += left;
 if (left < 32)
 /*
@@ -912,7 +914,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

 rv = ssif_i2c_send(ssif_info, msg_written_handler,
   I2C_SMBUS_WRITE,
   SSIF_IPMI_MULTI_PART_REQUEST_MIDDLE,
-  ssif_info->multi_data + ssif_info->multi_pos,
+  i2c_data,
   I2C_SMBUS_BLOCK_DATA);
 if (rv < 0) {
 /* request failed, just return the error. */
--
1.9.1


Thank you,
Joseph.

Corey Minyard 於 2017-03-25 10:53 寫到:
This is incorrect.  These values *must* be set before ssif_i2c_send() 
is done.
Once ssif_i2c_send() is called, msg_written_handler can be called at 
any

time after that, including before where you moved the new code.

If I understand this correctly, I think you need to add a variable,
maybe named "bytes_to_write" and do

  bytes_to_write = ssif_info->multi_data + ssif_info->multi_pos;

before the comparison and pass bytes_to_write into
ssif_i2c_send().

Thanks,

-corey

On 03/23/2017 02:07 AM, Joeseph Chang wrote:

From: Joeseph Chang 

msg_written_handler() may set ssif_info->multi_data to NULL
when using ipmitool to write fru.
Change the ssif i2c send data sequence in msg_written_handler()
to fix NULL pointer kernel panic and incorrect ssif_info->multi_pos.

Signed-off-by: Joeseph Chang 
---
  drivers/char/ipmi/ipmi_ssif.c | 20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_ssif.c 
b/drivers/char/ipmi/ipmi_ssif.c

index cca6e5b..39346ee 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -899,21 +899,13 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

left = 32;
/* Length byte. */
ssif_info->multi_data[ssif_info->multi_pos] = left;
-   ssif_info->multi_pos += left;
-   if (left < 32)
-   /*
-* Write is finished.  Note that we must end
-* with a write of less than 32 bytes to
-* complete the transaction, even if it is
-* zero bytes.
-*/
-   ssif_info->multi_data = NULL;
rv = ssif_i2c_send(ssif_info, msg_written_handler,
  I2C_SMBUS_WRITE,
  SSIF_IPMI_MULTI_PART_REQUEST_MIDDLE,
  ssif_info->multi_data + ssif_info->multi_pos,
  I2C_SMBUS_BLOCK_DATA);
+
if (rv < 0) {
/* request failed, just return the error. */
ssif_inc_stat(ssif_info, send_errors);
@@ -922,6 +914,16 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

pr_info("Error from i2c_non_blocking_op(3)\n");

Re: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

[joechang]

Hi Corey,

Thanks your feedback and suggestion. :)
I think you are right. It is better to allocate one new local variable 
to store i2c data and size that will be sent...

I create new patch in following according to your suggestion.
Could you help to review the patch again?

From eec31f51acc7e019fd0dcc512febda86870268d2 Mon Sep 17 00:00:00 2001
From: Joeseph Chang 
Date: Mon, 27 Mar 2017 10:46:42 +0800
Subject: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

msg_written_handler() may set ssif_info->multi_data to NULL
when using ipmitool to write fru.

Fix kernel panic at ipmi_ssif_thread() and incorrect
ssif_info->multi_pos by adding one local pointer i2c_data to store i2c
data and size to send before calling ssif_i2c_send().

With this change, can avoid concurrent access to ssif_info->multi_pos 
and

ssif_info->multi_data at msg_written_handler.
Because msg_written_handler can be called at any time after 
ssif_i2c_send().

---
 drivers/char/ipmi/ipmi_ssif.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 drivers/char/ipmi/ipmi_ssif.c

diff --git a/drivers/char/ipmi/ipmi_ssif.c 
b/drivers/char/ipmi/ipmi_ssif.c

old mode 100644
new mode 100755
index cca6e5b..f36f018
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -852,6 +852,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

 unsigned char *data, unsigned int len)
 {
 int rv;
+unsigned char *i2c_data;

 /* We are single-threaded here, so no need for a lock. */
 if (result < 0) {
@@ -899,6 +900,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

 left = 32;
 /* Length byte. */
 ssif_info->multi_data[ssif_info->multi_pos] = left;
+i2c_data = ssif_info->multi_data + ssif_info->multi_pos;
 ssif_info->multi_pos += left;
 if (left < 32)
 /*
@@ -912,7 +914,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

 rv = ssif_i2c_send(ssif_info, msg_written_handler,
   I2C_SMBUS_WRITE,
   SSIF_IPMI_MULTI_PART_REQUEST_MIDDLE,
-  ssif_info->multi_data + ssif_info->multi_pos,
+  i2c_data,
   I2C_SMBUS_BLOCK_DATA);
 if (rv < 0) {
 /* request failed, just return the error. */
--
1.9.1


Thank you,
Joseph.

Corey Minyard 於 2017-03-25 10:53 寫到:
This is incorrect.  These values *must* be set before ssif_i2c_send() 
is done.
Once ssif_i2c_send() is called, msg_written_handler can be called at 
any

time after that, including before where you moved the new code.

If I understand this correctly, I think you need to add a variable,
maybe named "bytes_to_write" and do

  bytes_to_write = ssif_info->multi_data + ssif_info->multi_pos;

before the comparison and pass bytes_to_write into
ssif_i2c_send().

Thanks,

-corey

On 03/23/2017 02:07 AM, Joeseph Chang wrote:

From: Joeseph Chang 

msg_written_handler() may set ssif_info->multi_data to NULL
when using ipmitool to write fru.
Change the ssif i2c send data sequence in msg_written_handler()
to fix NULL pointer kernel panic and incorrect ssif_info->multi_pos.

Signed-off-by: Joeseph Chang 
---
  drivers/char/ipmi/ipmi_ssif.c | 20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_ssif.c 
b/drivers/char/ipmi/ipmi_ssif.c

index cca6e5b..39346ee 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -899,21 +899,13 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

left = 32;
/* Length byte. */
ssif_info->multi_data[ssif_info->multi_pos] = left;
-   ssif_info->multi_pos += left;
-   if (left < 32)
-   /*
-* Write is finished.  Note that we must end
-* with a write of less than 32 bytes to
-* complete the transaction, even if it is
-* zero bytes.
-*/
-   ssif_info->multi_data = NULL;
rv = ssif_i2c_send(ssif_info, msg_written_handler,
  I2C_SMBUS_WRITE,
  SSIF_IPMI_MULTI_PART_REQUEST_MIDDLE,
  ssif_info->multi_data + ssif_info->multi_pos,
  I2C_SMBUS_BLOCK_DATA);
+
if (rv < 0) {
/* request failed, just return the error. */
ssif_inc_stat(ssif_info, send_errors);
@@ -922,6 +914,16 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,

pr_info("Error from i2c_non_blocking_op(3)\n");
msg_done_handler(ssif_info, -EIO, NULL, 0);
}
+
+   

Re: [PATCH v3 5/7] zram: Convert to using memset_l

[Minchan Kim]

On Fri, Mar 24, 2017 at 09:13:16AM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> zram was the motivation for creating memset_l().  Minchan Kim sees a 7%
> performance improvement on x86 with 100MB of non-zero deduplicatable
> data:
> 
> perf stat -r 10 dd if=/dev/zram0 of=/dev/null
> 
> vanilla:0.232050465 seconds time elapsed ( +-  0.51% )
> memset_l: 0.217219387 seconds time elapsed ( +-  0.07% )
> 
> Signed-off-by: Matthew Wilcox 
> Tested-by: Minchan Kim 
Acked-by: Minchan Kim 

Thanks!

Re: [PATCH v3 5/7] zram: Convert to using memset_l

[Minchan Kim]

On Fri, Mar 24, 2017 at 09:13:16AM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> zram was the motivation for creating memset_l().  Minchan Kim sees a 7%
> performance improvement on x86 with 100MB of non-zero deduplicatable
> data:
> 
> perf stat -r 10 dd if=/dev/zram0 of=/dev/null
> 
> vanilla:0.232050465 seconds time elapsed ( +-  0.51% )
> memset_l: 0.217219387 seconds time elapsed ( +-  0.07% )
> 
> Signed-off-by: Matthew Wilcox 
> Tested-by: Minchan Kim 
Acked-by: Minchan Kim 

Thanks!

Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG

[Bjorn Andersson]

On Thu 23 Mar 13:37 PDT 2017, Pavel Machek wrote:

> Hi!
> 
> > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
> > PMICs from Qualcomm. It can operate on fixed parameters or based on a
> > lookup-table, altering the duty cycle over time - which provides the
> > means for e.g. hardware assisted transitions of LED brightness.
> 
> Ok, this is not first hardware that supports something like this. We
> have similar hardware that can do blinking on Nokia N900 -- please
> take a look at leds-lp55*.c
> 

I have not worked with the LP55xx chips before, they look quite capable!

> And it would be really good to provide hardware abstraction. We really
> don't want to have different userspace for LPG and for N900 and for
> ...
> 
> Which probably means finding subset that makes sense for everyone.
> 

While I share your concern of userspace differences I'm not sure how to
expose the advanced features of the LP55xx series and the LPG's limited
pattern-controlled PWM.

> Hmm. What is difference between "ping_pong" and "reverse"? And do we
> really want it? That seems little .. too specialized.
> 

Writing the appropriate bit in RAMP_CONTROL_REG of the LUT block
qcom_lpg_lut_sync() resets the ramp-walker; ping-pong causes the
ramp-walker to make one round-trip run over the pattern, while reverse
means that the ramp-walker should start from the hi-index.

I.e. with the pattern [1,2,3] we get:

ping-pong: [1,2,3,2,1]
reverse: [3,2,1]
ping-pong and reverse: [3,2,1,2,3]

> How are different channels on RGB LED synchronized?
> 

You can reset multiple ramp-generators simultaneously, which would cause
the channels to be synchronized. I have not implemented this though.

> > +What:  /sys/class/leds//pattern
> > +Date:  March 2017
> > +KernelVersion: 4.12
> > +Contact:   Bjorn Andersson 
> > +Description:
> > +   Comma-separated list of duty cycle values to output from
> > +   the ramp generator. Values should be in the range of 0
> > +   to 511.
> 
> We normally do "space separated" in sysfs.
> 

Okay, I'm fine with that.

> Can your engine do "smooth transitions"? For example if you want to
> slowly turn on the LED on, can you do something more clever than
> 
> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
> 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
> ...
> 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509,
> 510, 511
> 

There's nothing beyond "run the pattern", so this is exactly what you
would have to do if you need a perfectly smooth transition.

> ? What is the maximum length of the pattern?
> 

It differs between the various PMICs implementing this. I've seen cases
of 24 slots and 64 slots.

> Could we do patterns in form of "delay brightness delay brightness"
>  ?
> 

The ramp-walker is configured to tick with a fixed clock (in
milliseconds) and the PWM will be configured with the duty-cycle of the
current element of the ramp.

So you can do this, given that all your "delay" is the same fixed delay,
which is max 511 milliseconds.

> > +static enum led_brightness lpg_brightnes_get(struct led_classdev *cdev)
> > +{
> > +   struct lpg *lpg = container_of(cdev, struct lpg, cdev);
> > +   unsigned long max = (1 << lpg->pwm_size) - 1;
> > +
> > +   if (!lpg->enabled)
> > +   return LED_OFF;
> > +
> > +   return lpg->pwm_value * cdev->max_brightness / max;
> > +}
> 
> Does this return something reasonable when pattern is running?
> 

No, I'll fix that. I treat brightness as a boolean if a pattern is
provided, but I'm concerned about modifying max_brightness to reflect
this.


As you can see from these answers, the hardware is quite limited in
comparison to the LP55xx series. It would make some sense to feed e.g. a
mathematical formula to the kernel and have the driver map that to
patterns for the LPG or program code in the case of LP55xx.

But this would add quite a bit of complexity and with hardware as
limited as the 24-slot LPG we likely need that direct control of the
patterns.

Regards,
Bjorn

Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG

[Bjorn Andersson]

On Thu 23 Mar 13:37 PDT 2017, Pavel Machek wrote:

> Hi!
> 
> > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
> > PMICs from Qualcomm. It can operate on fixed parameters or based on a
> > lookup-table, altering the duty cycle over time - which provides the
> > means for e.g. hardware assisted transitions of LED brightness.
> 
> Ok, this is not first hardware that supports something like this. We
> have similar hardware that can do blinking on Nokia N900 -- please
> take a look at leds-lp55*.c
> 

I have not worked with the LP55xx chips before, they look quite capable!

> And it would be really good to provide hardware abstraction. We really
> don't want to have different userspace for LPG and for N900 and for
> ...
> 
> Which probably means finding subset that makes sense for everyone.
> 

While I share your concern of userspace differences I'm not sure how to
expose the advanced features of the LP55xx series and the LPG's limited
pattern-controlled PWM.

> Hmm. What is difference between "ping_pong" and "reverse"? And do we
> really want it? That seems little .. too specialized.
> 

Writing the appropriate bit in RAMP_CONTROL_REG of the LUT block
qcom_lpg_lut_sync() resets the ramp-walker; ping-pong causes the
ramp-walker to make one round-trip run over the pattern, while reverse
means that the ramp-walker should start from the hi-index.

I.e. with the pattern [1,2,3] we get:

ping-pong: [1,2,3,2,1]
reverse: [3,2,1]
ping-pong and reverse: [3,2,1,2,3]

> How are different channels on RGB LED synchronized?
> 

You can reset multiple ramp-generators simultaneously, which would cause
the channels to be synchronized. I have not implemented this though.

> > +What:  /sys/class/leds//pattern
> > +Date:  March 2017
> > +KernelVersion: 4.12
> > +Contact:   Bjorn Andersson 
> > +Description:
> > +   Comma-separated list of duty cycle values to output from
> > +   the ramp generator. Values should be in the range of 0
> > +   to 511.
> 
> We normally do "space separated" in sysfs.
> 

Okay, I'm fine with that.

> Can your engine do "smooth transitions"? For example if you want to
> slowly turn on the LED on, can you do something more clever than
> 
> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
> 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
> ...
> 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509,
> 510, 511
> 

There's nothing beyond "run the pattern", so this is exactly what you
would have to do if you need a perfectly smooth transition.

> ? What is the maximum length of the pattern?
> 

It differs between the various PMICs implementing this. I've seen cases
of 24 slots and 64 slots.

> Could we do patterns in form of "delay brightness delay brightness"
>  ?
> 

The ramp-walker is configured to tick with a fixed clock (in
milliseconds) and the PWM will be configured with the duty-cycle of the
current element of the ramp.

So you can do this, given that all your "delay" is the same fixed delay,
which is max 511 milliseconds.

> > +static enum led_brightness lpg_brightnes_get(struct led_classdev *cdev)
> > +{
> > +   struct lpg *lpg = container_of(cdev, struct lpg, cdev);
> > +   unsigned long max = (1 << lpg->pwm_size) - 1;
> > +
> > +   if (!lpg->enabled)
> > +   return LED_OFF;
> > +
> > +   return lpg->pwm_value * cdev->max_brightness / max;
> > +}
> 
> Does this return something reasonable when pattern is running?
> 

No, I'll fix that. I treat brightness as a boolean if a pattern is
provided, but I'm concerned about modifying max_brightness to reflect
this.


As you can see from these answers, the hardware is quite limited in
comparison to the LP55xx series. It would make some sense to feed e.g. a
mathematical formula to the kernel and have the driver map that to
patterns for the LPG or program code in the case of LP55xx.

But this would add quite a bit of complexity and with hardware as
limited as the 24-slot LPG we likely need that direct control of the
patterns.

Regards,
Bjorn

[lkp-robot] [fsnotify] 0ee0efcf7c: kernel_BUG_at_fs/notify/inotify/inotify_user.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 0ee0efcf7c7968fb045454f621b5681e94b2c288 ("fsnotify: Move queueing of 
mark for destruction into fsnotify_put_mark()")
https://git.kernel.org/cgit/linux/kernel/git/jack/linux-fs.git for_testing

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

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


++++
|| 58c5cae6d5 | 0ee0efcf7c |
++++
| boot_successes | 602| 594|
| boot_failures  | 0  | 12 |
| kernel_BUG_at_fs/notify/inotify/inotify_user.c | 0  | 12 |
| invalid_opcode:#[##]   | 0  | 12 |
| EIP:inotify_remove_from_idr| 0  | 12 |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 12 |
++++



[  330.941460] kernel BUG at fs/notify/inotify/inotify_user.c:454!
[  330.942422] invalid opcode:  [#1] SMP
[  330.942884] Modules linked in:
[  330.943531] CPU: 1 PID: 2301 Comm: ps Not tainted 4.11.0-rc2-00019-g0ee0efc 
#1
[  330.944465] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  330.945803] task: de378100 task.stack: db7ec000
[  330.946417] EIP: inotify_remove_from_idr+0xff/0x13a
[  330.947114] EFLAGS: 00010202 CPU: 1
[  330.947668] EAX: 004c EBX: dabfd4b0 ECX: df0f1d18 EDX: df0ecee4
[  330.948521] ESI: dabfd4b0 EDI: dccbbb00 EBP: db7ede60 ESP: db7ede38
[  330.949278]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  330.949950] CR0: 80050033 CR2: b7713540 CR3: 1cc4f000 CR4: 06d0
[  330.950772] DR0: b6945000 DR1:  DR2:  DR3: 
[  330.951652] DR6: 0ff0 DR7: 0600
[  330.952182] Call Trace:
[  330.952474]  inotify_ignored_and_remove_idr+0x2c/0x46
[  330.953143]  inotify_freeing_mark+0x8/0xa
[  330.953740]  fsnotify_free_mark+0x42/0x47
[  330.954234]  fsnotify_destroy_mark+0x2b/0x2f
[  330.954789]  inotify_handle_event+0xc4/0xcd
[  330.955295]  fsnotify+0x24d/0x2d8
[  330.955780]  do_sys_open+0xa9/0xc7
[  330.956341]  SyS_open+0x18/0x1a
[  330.956788]  do_int80_syscall_32+0x45/0x57
[  330.957390]  entry_INT80_32+0x2a/0x2a
[  330.957809] EIP: 0xb76d0305
[  330.958162] EFLAGS: 0282 CPU: 1
[  330.958615] EAX: ffda EBX: bf83d127 ECX: 8000 EDX: 
[  330.959579] ESI:  EDI:  EBP: bf83d104 ESP: bf83d0d8
[  330.960424]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[  330.961246] Code: 87 c1 01 e8 75 10 f3 ff 83 c4 28 eb 37 8b 43 04 83 f8 02 
7f 18 ff 73 08 ff 73 4c 53 68 60 27 4f c1 68 a8 75 78 c1 e8 38 3f fa ff <0f> 0b 
8b 55 f0 8d 87 e0 00 00 00 31 c9 e8 38 8a 06 00 89 d8 e8
[  330.963728] EIP: inotify_remove_from_idr+0xff/0x13a SS:ESP: 0068:db7ede38
[  330.964755] ---[ end trace 1a8558f20d1546cf ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.11.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y

[lkp-robot] [fsnotify] 0ee0efcf7c: kernel_BUG_at_fs/notify/inotify/inotify_user.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 0ee0efcf7c7968fb045454f621b5681e94b2c288 ("fsnotify: Move queueing of 
mark for destruction into fsnotify_put_mark()")
https://git.kernel.org/cgit/linux/kernel/git/jack/linux-fs.git for_testing

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

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


++++
|| 58c5cae6d5 | 0ee0efcf7c |
++++
| boot_successes | 602| 594|
| boot_failures  | 0  | 12 |
| kernel_BUG_at_fs/notify/inotify/inotify_user.c | 0  | 12 |
| invalid_opcode:#[##]   | 0  | 12 |
| EIP:inotify_remove_from_idr| 0  | 12 |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 12 |
++++



[  330.941460] kernel BUG at fs/notify/inotify/inotify_user.c:454!
[  330.942422] invalid opcode:  [#1] SMP
[  330.942884] Modules linked in:
[  330.943531] CPU: 1 PID: 2301 Comm: ps Not tainted 4.11.0-rc2-00019-g0ee0efc 
#1
[  330.944465] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  330.945803] task: de378100 task.stack: db7ec000
[  330.946417] EIP: inotify_remove_from_idr+0xff/0x13a
[  330.947114] EFLAGS: 00010202 CPU: 1
[  330.947668] EAX: 004c EBX: dabfd4b0 ECX: df0f1d18 EDX: df0ecee4
[  330.948521] ESI: dabfd4b0 EDI: dccbbb00 EBP: db7ede60 ESP: db7ede38
[  330.949278]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  330.949950] CR0: 80050033 CR2: b7713540 CR3: 1cc4f000 CR4: 06d0
[  330.950772] DR0: b6945000 DR1:  DR2:  DR3: 
[  330.951652] DR6: 0ff0 DR7: 0600
[  330.952182] Call Trace:
[  330.952474]  inotify_ignored_and_remove_idr+0x2c/0x46
[  330.953143]  inotify_freeing_mark+0x8/0xa
[  330.953740]  fsnotify_free_mark+0x42/0x47
[  330.954234]  fsnotify_destroy_mark+0x2b/0x2f
[  330.954789]  inotify_handle_event+0xc4/0xcd
[  330.955295]  fsnotify+0x24d/0x2d8
[  330.955780]  do_sys_open+0xa9/0xc7
[  330.956341]  SyS_open+0x18/0x1a
[  330.956788]  do_int80_syscall_32+0x45/0x57
[  330.957390]  entry_INT80_32+0x2a/0x2a
[  330.957809] EIP: 0xb76d0305
[  330.958162] EFLAGS: 0282 CPU: 1
[  330.958615] EAX: ffda EBX: bf83d127 ECX: 8000 EDX: 
[  330.959579] ESI:  EDI:  EBP: bf83d104 ESP: bf83d0d8
[  330.960424]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[  330.961246] Code: 87 c1 01 e8 75 10 f3 ff 83 c4 28 eb 37 8b 43 04 83 f8 02 
7f 18 ff 73 08 ff 73 4c 53 68 60 27 4f c1 68 a8 75 78 c1 e8 38 3f fa ff <0f> 0b 
8b 55 f0 8d 87 e0 00 00 00 31 c9 e8 38 8a 06 00 89 d8 e8
[  330.963728] EIP: inotify_remove_from_idr+0xff/0x13a SS:ESP: 0068:db7ede38
[  330.964755] ---[ end trace 1a8558f20d1546cf ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.11.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y

[lkp-robot] [blk] 34dbad5d26: WARNING:at_block/blk-stat.c:#blk_free_queue_stats

[kernel test robot]

FYI, we noticed the following commit:

commit: 34dbad5d26e2f4b88e60f0e9ad03f99480802812 ("blk-stat: convert to 
callback-based statistics reporting")
https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git for-next

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -m 512M

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


+---+++
|   | 4875253fdd | 34dbad5d26 |
+---+++
| boot_successes| 8  | 4  |
| boot_failures | 0  | 32 |
| WARNING:at_block/blk-stat.c:#blk_free_queue_stats | 0  | 31 |
| BUG:kernel_hang_in_test_stage | 0  | 12 |
+---+++



[2.506372] WARNING: CPU: 0 PID: 1 at block/blk-stat.c:236 
blk_free_queue_stats+0x26/0x40
[2.507814] Modules linked in:
[2.508274] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.11.0-rc3-5-g34dbad5 #1
[2.509337] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[2.510787] Call Trace:
[2.511167]  dump_stack+0x19/0x24
[2.511664]  __warn+0xba/0xe0
[2.512111]  warn_slowpath_null+0x18/0x20
[2.512693]  blk_free_queue_stats+0x26/0x40
[2.513358]  blk_release_queue+0x72/0x110
[2.513951]  kobject_put+0x8b/0xa0
[2.514455]  blk_put_queue+0x10/0x20
[2.514987]  scsi_device_dev_release_usercontext+0x16f/0x210
[2.515796]  ? scsi_device_cls_release+0x20/0x20
[2.529531]  execute_in_process_context+0x27/0x90
[2.530230]  scsi_device_dev_release+0x17/0x20
[2.530890]  device_release+0x54/0x90
[2.531423]  kobject_put+0x8b/0xa0
[2.531928]  put_device+0x12/0x20
[2.532414]  __scsi_remove_device+0xc6/0xd0
[2.533029]  scsi_forget_host+0x4c/0x60
[2.533600]  scsi_remove_host+0x8c/0x110
[2.534181]  sdebug_driver_remove+0x60/0xd0
[2.534784]  ? sdebug_driver_probe+0x264/0x390
[2.535434]  driver_probe_device+0x16f/0x320
[2.536061]  __device_attach_driver+0x9f/0xb0
[2.536690]  ? __driver_attach+0x90/0x90
[2.537266]  bus_for_each_drv+0x4f/0x90
[2.537822]  __device_attach+0xa7/0x120
[2.538383]  device_initial_probe+0xe/0x10
[2.538981]  bus_probe_device+0x35/0xb0
[2.539542]  device_add+0x3db/0x600
[2.540063]  device_register+0x15/0x20
[2.540610]  sdebug_add_adapter+0x146/0x1d0
[2.541232]  ? do_early_param+0x8f/0x8f
[2.541789]  scsi_debug_init+0x6bd/0x7a2
[2.543646]  ? scsi_register_driver+0x11/0x20
[2.544290]  ? init_sr+0x43/0x43
[2.544763]  do_one_initcall+0x95/0x180
[2.545333]  ? do_early_param+0x8f/0x8f
[2.545898]  kernel_init_freeable+0xfe/0x18d
[2.546512]  ? rest_init+0x130/0x130
[2.547042]  kernel_init+0x9/0xf0
[2.547526]  ret_from_fork+0x31/0x40
[2.548076] ---[ end trace d0d35b85d64d7a90 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.11.0-rc3 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not 

[lkp-robot] [blk] 34dbad5d26: WARNING:at_block/blk-stat.c:#blk_free_queue_stats

[kernel test robot]

FYI, we noticed the following commit:

commit: 34dbad5d26e2f4b88e60f0e9ad03f99480802812 ("blk-stat: convert to 
callback-based statistics reporting")
https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git for-next

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -m 512M

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


+---+++
|   | 4875253fdd | 34dbad5d26 |
+---+++
| boot_successes| 8  | 4  |
| boot_failures | 0  | 32 |
| WARNING:at_block/blk-stat.c:#blk_free_queue_stats | 0  | 31 |
| BUG:kernel_hang_in_test_stage | 0  | 12 |
+---+++



[2.506372] WARNING: CPU: 0 PID: 1 at block/blk-stat.c:236 
blk_free_queue_stats+0x26/0x40
[2.507814] Modules linked in:
[2.508274] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.11.0-rc3-5-g34dbad5 #1
[2.509337] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[2.510787] Call Trace:
[2.511167]  dump_stack+0x19/0x24
[2.511664]  __warn+0xba/0xe0
[2.512111]  warn_slowpath_null+0x18/0x20
[2.512693]  blk_free_queue_stats+0x26/0x40
[2.513358]  blk_release_queue+0x72/0x110
[2.513951]  kobject_put+0x8b/0xa0
[2.514455]  blk_put_queue+0x10/0x20
[2.514987]  scsi_device_dev_release_usercontext+0x16f/0x210
[2.515796]  ? scsi_device_cls_release+0x20/0x20
[2.529531]  execute_in_process_context+0x27/0x90
[2.530230]  scsi_device_dev_release+0x17/0x20
[2.530890]  device_release+0x54/0x90
[2.531423]  kobject_put+0x8b/0xa0
[2.531928]  put_device+0x12/0x20
[2.532414]  __scsi_remove_device+0xc6/0xd0
[2.533029]  scsi_forget_host+0x4c/0x60
[2.533600]  scsi_remove_host+0x8c/0x110
[2.534181]  sdebug_driver_remove+0x60/0xd0
[2.534784]  ? sdebug_driver_probe+0x264/0x390
[2.535434]  driver_probe_device+0x16f/0x320
[2.536061]  __device_attach_driver+0x9f/0xb0
[2.536690]  ? __driver_attach+0x90/0x90
[2.537266]  bus_for_each_drv+0x4f/0x90
[2.537822]  __device_attach+0xa7/0x120
[2.538383]  device_initial_probe+0xe/0x10
[2.538981]  bus_probe_device+0x35/0xb0
[2.539542]  device_add+0x3db/0x600
[2.540063]  device_register+0x15/0x20
[2.540610]  sdebug_add_adapter+0x146/0x1d0
[2.541232]  ? do_early_param+0x8f/0x8f
[2.541789]  scsi_debug_init+0x6bd/0x7a2
[2.543646]  ? scsi_register_driver+0x11/0x20
[2.544290]  ? init_sr+0x43/0x43
[2.544763]  do_one_initcall+0x95/0x180
[2.545333]  ? do_early_param+0x8f/0x8f
[2.545898]  kernel_init_freeable+0xfe/0x18d
[2.546512]  ? rest_init+0x130/0x130
[2.547042]  kernel_init+0x9/0xf0
[2.547526]  ret_from_fork+0x31/0x40
[2.548076] ---[ end trace d0d35b85d64d7a90 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.11.0-rc3 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not 

Re: [PATCH v3] dmaengine: rcar-dmac: enable descriptor mode on 40bit

[Vinod Koul]

On Wed, Mar 22, 2017 at 04:22:36AM +, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> SYS-DMAC can use 40bit address transfer, and it supports Descriptor
> Mode too. Current SYS-DMAC driver disables Descriptor Mode if it was
> 40bit address today. But it can use Descriptor Mode with 40bit if
> transfer Source/Destination address are located in same 4GiB region
> in the 40 bit address space.
> This patch enables it if all condition was clear

Applied, thanks

-- 
~Vinod

Re: [PATCH v3] dmaengine: rcar-dmac: enable descriptor mode on 40bit

[Vinod Koul]

On Wed, Mar 22, 2017 at 04:22:36AM +, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> SYS-DMAC can use 40bit address transfer, and it supports Descriptor
> Mode too. Current SYS-DMAC driver disables Descriptor Mode if it was
> 40bit address today. But it can use Descriptor Mode with 40bit if
> transfer Source/Destination address are located in same 4GiB region
> in the 40 bit address space.
> This patch enables it if all condition was clear

Applied, thanks

-- 
~Vinod

Re: [PATCH v8 2/3] dmaengine: pl330: remove pdata based initialization

[Vinod Koul]

On Wed, Mar 22, 2017 at 09:22:23AM +0100, Marek Szyprowski wrote:
> Hi Vinod
> 
> 
> On 2017-02-09 15:22, Marek Szyprowski wrote:
> >This driver is now used only on platforms which support device tree, so
> >it is safe to remove legacy platform data based initialization code.
> >
> >Signed-off-by: Marek Szyprowski 
> >Reviewed-by: Ulf Hansson 
> >Acked-by: Arnd Bergmann 
> >For plat-samsung:
> >Acked-by: Krzysztof Kozlowski 
> 
> Vinod: This patch is completely independent from the rest of the changes
> from that patchset. Could you apply it, or do you want me to resend it
> separately? Runtime pm related changes will wait until a new DMA engine API
> is ready.

Sure, please resend it :)

-- 
~Vinod

Re: [PATCH v8 2/3] dmaengine: pl330: remove pdata based initialization

[Vinod Koul]

On Wed, Mar 22, 2017 at 09:22:23AM +0100, Marek Szyprowski wrote:
> Hi Vinod
> 
> 
> On 2017-02-09 15:22, Marek Szyprowski wrote:
> >This driver is now used only on platforms which support device tree, so
> >it is safe to remove legacy platform data based initialization code.
> >
> >Signed-off-by: Marek Szyprowski 
> >Reviewed-by: Ulf Hansson 
> >Acked-by: Arnd Bergmann 
> >For plat-samsung:
> >Acked-by: Krzysztof Kozlowski 
> 
> Vinod: This patch is completely independent from the rest of the changes
> from that patchset. Could you apply it, or do you want me to resend it
> separately? Runtime pm related changes will wait until a new DMA engine API
> is ready.

Sure, please resend it :)

-- 
~Vinod

Re: [PATCH v1] Revert "extcon: usb-gpio: add support for ACPI gpio interface"

[Chanwoo Choi]

Hi Andy,

On 2017년 03월 22일 03:37, Andy Shevchenko wrote:
> The commit 942c7924a51e introduced a check for ACPI handle for the
> device that never appears on any ACPI-enabled platform so far. It seems
> a confusion with extcon-intel-int3496 which does support ACPI-enabled
> platforms.
> 
> Revert commit 942c7924a51e to avoid any confusion in the future.
> 
> Cc: Lu Baolu 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/extcon/extcon-usb-gpio.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 

Applied it on extcon-fixes branch.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v1] Revert "extcon: usb-gpio: add support for ACPI gpio interface"

[Chanwoo Choi]

Hi Andy,

On 2017년 03월 22일 03:37, Andy Shevchenko wrote:
> The commit 942c7924a51e introduced a check for ACPI handle for the
> device that never appears on any ACPI-enabled platform so far. It seems
> a confusion with extcon-intel-int3496 which does support ACPI-enabled
> platforms.
> 
> Revert commit 942c7924a51e to avoid any confusion in the future.
> 
> Cc: Lu Baolu 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/extcon/extcon-usb-gpio.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 

Applied it on extcon-fixes branch.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

[PrasannaKumar Muralidharan]

> Oh my, if you are right with your first guess, this is a bad DRNG design.
>
> Just out of curiousity: what happens if a caller invokes the seed function
> twice or more times (each time with the sufficient amount of bits)? What is
> your guess here?

Should the second seed use the random data generated by the device?

Regards,
PrasannaKumar

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

[PrasannaKumar Muralidharan]

> Oh my, if you are right with your first guess, this is a bad DRNG design.
>
> Just out of curiousity: what happens if a caller invokes the seed function
> twice or more times (each time with the sufficient amount of bits)? What is
> your guess here?

Should the second seed use the random data generated by the device?

Regards,
PrasannaKumar

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ander Conselvan De Oliveira  於 2017年3月14日 下午9:53 寫道：
> 
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>> 
>> 從我的 iPad 傳送
>> 
 Ville Syrjälä  於 2017年3月7日 上午2:34 寫道：
 
 On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
 
 
 從我的 iPad 傳送
 
>> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
>> 
>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
>> per channel video format.
>> 
>> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
>> per channel video format.
>> 
>> V3: Added P012 and fixed cpp for P010
>> V4: format definition refined per review
>> V5: Format comment block for each new pixel format
>> V6: reversed Cb/Cr order in comments
>> v7: reversed Cb/Cr order in comments of header files, remove
>> the wrong part of commit message.
> 
> What? Why? You just undid what Clint did in v6.
 
 He missed a file also keeping the wrong description of rockchip.
>>> 
>>> I don't follow. Who missed what exactly?
>> 
>> What he sent is v5, I increase the order number twice in the message, it 
>> confuse me as well. 
>> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
> 
> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
> 
> https://patchwork.freedesktop.org/patch/141342/
Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
since I think the V is after the U.
> 
> 
> Ander
> 
>>> 
>>> 
> 
>> 
>> Cc: Daniel Stone 
>> Cc: Ville Syrjälä 
>> 
>> Signed-off-by: Randy Li 
>> Signed-off-by: Clint Taylor 
>> ---
>> drivers/gpu/drm/drm_fourcc.c  |  3 +++
>> include/uapi/drm/drm_fourcc.h | 21 +
>> 2 files changed, 24 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index 90d2cc8..3e0fd58 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 
>> format)
>>  { .format = DRM_FORMAT_UYVY,.depth = 0,  .num_planes = 1, 
>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>  { .format = DRM_FORMAT_VYUY,.depth = 0,  .num_planes = 1, 
>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>  { .format = DRM_FORMAT_AYUV,.depth = 0,  .num_planes = 1, 
>> .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
>> +{ .format = DRM_FORMAT_P010,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>> +{ .format = DRM_FORMAT_P012,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>> +{ .format = DRM_FORMAT_P016,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>>  };
>> 
>>  unsigned int i;
>> diff --git a/include/uapi/drm/drm_fourcc.h 
>> b/include/uapi/drm/drm_fourcc.h
>> index ef20abb..306f979 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -128,6 +128,27 @@ extern "C" {
>> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
>> non-subsampled Cb:Cr plane */
>> 
>> /*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
>> + */
>> +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
>> subsampled Cb:Cr plane 10 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
>> + */
>> +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
>> subsampled Cb:Cr plane 12 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
>> + */
>> +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
>> subsampled Cb:Cr plane 16 bits per channel */
>> +
>> +/*
>> * 3 plane YCbCr
>> * index 0: Y plane, [7:0] Y
>> * index 1: Cb plane, [7:0] Cb
>> -- 
>> 2.7.4
> 
> -- 
> Ville Syrjälä
> Intel OTC
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel OTC
>> 
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ander Conselvan De Oliveira  於 2017年3月14日 下午9:53 寫道：
> 
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>> 
>> 從我的 iPad 傳送
>> 
 Ville Syrjälä  於 2017年3月7日 上午2:34 寫道：
 
 On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
 
 
 從我的 iPad 傳送
 
>> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
>> 
>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
>> per channel video format.
>> 
>> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
>> per channel video format.
>> 
>> V3: Added P012 and fixed cpp for P010
>> V4: format definition refined per review
>> V5: Format comment block for each new pixel format
>> V6: reversed Cb/Cr order in comments
>> v7: reversed Cb/Cr order in comments of header files, remove
>> the wrong part of commit message.
> 
> What? Why? You just undid what Clint did in v6.
 
 He missed a file also keeping the wrong description of rockchip.
>>> 
>>> I don't follow. Who missed what exactly?
>> 
>> What he sent is v5, I increase the order number twice in the message, it 
>> confuse me as well. 
>> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
> 
> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
> 
> https://patchwork.freedesktop.org/patch/141342/
Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
since I think the V is after the U.
> 
> 
> Ander
> 
>>> 
>>> 
> 
>> 
>> Cc: Daniel Stone 
>> Cc: Ville Syrjälä 
>> 
>> Signed-off-by: Randy Li 
>> Signed-off-by: Clint Taylor 
>> ---
>> drivers/gpu/drm/drm_fourcc.c  |  3 +++
>> include/uapi/drm/drm_fourcc.h | 21 +
>> 2 files changed, 24 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index 90d2cc8..3e0fd58 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 
>> format)
>>  { .format = DRM_FORMAT_UYVY,.depth = 0,  .num_planes = 1, 
>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>  { .format = DRM_FORMAT_VYUY,.depth = 0,  .num_planes = 1, 
>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>  { .format = DRM_FORMAT_AYUV,.depth = 0,  .num_planes = 1, 
>> .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
>> +{ .format = DRM_FORMAT_P010,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>> +{ .format = DRM_FORMAT_P012,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>> +{ .format = DRM_FORMAT_P016,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>>  };
>> 
>>  unsigned int i;
>> diff --git a/include/uapi/drm/drm_fourcc.h 
>> b/include/uapi/drm/drm_fourcc.h
>> index ef20abb..306f979 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -128,6 +128,27 @@ extern "C" {
>> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
>> non-subsampled Cb:Cr plane */
>> 
>> /*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
>> + */
>> +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
>> subsampled Cb:Cr plane 10 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
>> + */
>> +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
>> subsampled Cb:Cr plane 12 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
>> + */
>> +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
>> subsampled Cb:Cr plane 16 bits per channel */
>> +
>> +/*
>> * 3 plane YCbCr
>> * index 0: Y plane, [7:0] Y
>> * index 1: Cb plane, [7:0] Cb
>> -- 
>> 2.7.4
> 
> -- 
> Ville Syrjälä
> Intel OTC
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel OTC
>> 
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk

[Andy Tang]

PING!

Regards,
Yuantian

> -Original Message-
> From: Yuantian Tang [mailto:andy.t...@nxp.com]
> Sent: Monday, March 20, 2017 10:37 AM
> To: mturque...@baylibre.com
> Cc: sb...@codeaurora.org; robh...@kernel.org; mark.rutl...@arm.com;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Scott Wood;
> Andy Tang
> Subject: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk
> 
> From: Scott Wood 
> 
> ls1012a has separate input root clocks for core PLLs versus the platform PLL,
> with the latter described as sysclk in the hw docs.
> Update the qoriq-clock binding to allow a second input clock, named
> "coreclk".  If present, this clock will be used for the core PLLs.
> 
> Signed-off-by: Scott Wood 
> Signed-off-by: Tang Yuantian 
> Acked-by: Rob Herring 
> ---
> v2:
>   -- change the author to Scott
>  Documentation/devicetree/bindings/clock/qoriq-clock.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index aa3526f..119cafd 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -56,6 +56,11 @@ Optional properties:
>  - clocks: If clock-frequency is not specified, sysclk may be provided
>   as an input clock.  Either clock-frequency or clocks must be
>   provided.
> + A second input clock, called "coreclk", may be provided if
> + core PLLs are based on a different input clock from the
> + platform PLL.
> +- clock-names: Required if a coreclk is present.  Valid names are
> + "sysclk" and "coreclk".
> 
>  2. Clock Provider
> 
> @@ -72,6 +77,7 @@ second cell is the clock index for the specified type.
>   2   hwaccel index (n in CLKCGnHWACSR)
>   3   fman0 for fm1, 1 for fm2
>   4   platform pll0=pll, 1=pll/2, 2=pll/3, 3=pll/4
> + 5   coreclk must be 0
> 
>  3. Example
> 
> --
> 2.1.0.27.g96db324

RE: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk

[Andy Tang]

PING!

Regards,
Yuantian

> -Original Message-
> From: Yuantian Tang [mailto:andy.t...@nxp.com]
> Sent: Monday, March 20, 2017 10:37 AM
> To: mturque...@baylibre.com
> Cc: sb...@codeaurora.org; robh...@kernel.org; mark.rutl...@arm.com;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Scott Wood;
> Andy Tang
> Subject: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk
> 
> From: Scott Wood 
> 
> ls1012a has separate input root clocks for core PLLs versus the platform PLL,
> with the latter described as sysclk in the hw docs.
> Update the qoriq-clock binding to allow a second input clock, named
> "coreclk".  If present, this clock will be used for the core PLLs.
> 
> Signed-off-by: Scott Wood 
> Signed-off-by: Tang Yuantian 
> Acked-by: Rob Herring 
> ---
> v2:
>   -- change the author to Scott
>  Documentation/devicetree/bindings/clock/qoriq-clock.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index aa3526f..119cafd 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -56,6 +56,11 @@ Optional properties:
>  - clocks: If clock-frequency is not specified, sysclk may be provided
>   as an input clock.  Either clock-frequency or clocks must be
>   provided.
> + A second input clock, called "coreclk", may be provided if
> + core PLLs are based on a different input clock from the
> + platform PLL.
> +- clock-names: Required if a coreclk is present.  Valid names are
> + "sysclk" and "coreclk".
> 
>  2. Clock Provider
> 
> @@ -72,6 +77,7 @@ second cell is the clock index for the specified type.
>   2   hwaccel index (n in CLKCGnHWACSR)
>   3   fman0 for fm1, 1 for fm2
>   4   platform pll0=pll, 1=pll/2, 2=pll/3, 3=pll/4
> + 5   coreclk must be 0
> 
>  3. Example
> 
> --
> 2.1.0.27.g96db324

[BUG?] perf: dwarf unwind doesn't work correctly with -static

[Masami Hiramatsu]

Hello,

On Fri, 24 Mar 2017 22:00:30 +0900
Masami Hiramatsu  wrote:

> On Thu, 23 Mar 2017 22:24:01 -0500
> Kim Phillips  wrote:
> 
> > On Thu, 23 Feb 2017 16:50:18 +0900
> > Masami Hiramatsu  wrote:
> > 
> > [sorry for the delay, I just saw this]
> > 
> > > perf record -g dwarf (and perf report) doesn't show correct callchain
> > > on aarch64. Here is how to reproduce it.
> > ...
> > > # Samples: 6K of event 'cpu-clock:u'
> > > # Event count (approx.): 162375
> > > #
> > > # Children  Self  Command  Shared Object  Symbol
> > > #     ...  .  ..
> > > #
> > > 17.21%17.21%  main main   [.] func2
> > > |
> > > ---func2
> > > 
> > > 17.09%17.09%  main main   [.] func1
> > > |
> > > ---func1
> > > 
> > > 16.67%16.67%  main main   [.] main
> > > |
> > > ---main
> > > .
> > > 
> > > So, as you can see, the call graph reported each function has been
> > > called from itself. If I report it with fp as below, perf reported
> > > correct callgraph.
> > ...
> > > I guess there is a bug in libunwind on aarch64 or we missed to pass
> > > the stack data to libunwind. (BTW, it works correctly on arm32)
> > 
> > Trying to replicate this on a debian 9 ("stretch") arm64 box:
> 
> I'm using debian 8 ("jessie"), but I can try debian 9 too.

I've tried debian 9 and found this issue is another reason.

> 2) Build attached program as below
> # gcc -O0 -ggdb3 -funwind-tables -o main main.c

Originally, I reported above, but that is not correct, when I cleaned
up the command line, I missed important piece -- -static.

I've tested several binaries with different gcc, and found that
- Even with linaro-gcc 6.3.1, this issue happened.
- But natively build binary with gcc-6.3 (stretch) I didn't see it.
- Building binary with -static, it happened even with native binary 6.3.
- And I saw this happened even on x86-64 with -static.

So, I think the correct subject is

"perf: dwarf unwind doesn't work correctly with -static"

Thank you,

-- 
Masami Hiramatsu 

[BUG?] perf: dwarf unwind doesn't work correctly with -static

[Masami Hiramatsu]

Hello,

On Fri, 24 Mar 2017 22:00:30 +0900
Masami Hiramatsu  wrote:

> On Thu, 23 Mar 2017 22:24:01 -0500
> Kim Phillips  wrote:
> 
> > On Thu, 23 Feb 2017 16:50:18 +0900
> > Masami Hiramatsu  wrote:
> > 
> > [sorry for the delay, I just saw this]
> > 
> > > perf record -g dwarf (and perf report) doesn't show correct callchain
> > > on aarch64. Here is how to reproduce it.
> > ...
> > > # Samples: 6K of event 'cpu-clock:u'
> > > # Event count (approx.): 162375
> > > #
> > > # Children  Self  Command  Shared Object  Symbol
> > > #     ...  .  ..
> > > #
> > > 17.21%17.21%  main main   [.] func2
> > > |
> > > ---func2
> > > 
> > > 17.09%17.09%  main main   [.] func1
> > > |
> > > ---func1
> > > 
> > > 16.67%16.67%  main main   [.] main
> > > |
> > > ---main
> > > .
> > > 
> > > So, as you can see, the call graph reported each function has been
> > > called from itself. If I report it with fp as below, perf reported
> > > correct callgraph.
> > ...
> > > I guess there is a bug in libunwind on aarch64 or we missed to pass
> > > the stack data to libunwind. (BTW, it works correctly on arm32)
> > 
> > Trying to replicate this on a debian 9 ("stretch") arm64 box:
> 
> I'm using debian 8 ("jessie"), but I can try debian 9 too.

I've tried debian 9 and found this issue is another reason.

> 2) Build attached program as below
> # gcc -O0 -ggdb3 -funwind-tables -o main main.c

Originally, I reported above, but that is not correct, when I cleaned
up the command line, I missed important piece -- -static.

I've tested several binaries with different gcc, and found that
- Even with linaro-gcc 6.3.1, this issue happened.
- But natively build binary with gcc-6.3 (stretch) I didn't see it.
- Building binary with -static, it happened even with native binary 6.3.
- And I saw this happened even on x86-64 with -static.

So, I think the correct subject is

"perf: dwarf unwind doesn't work correctly with -static"

Thank you,

-- 
Masami Hiramatsu 

[PATCH] rtc: cpcap: fix improper use of IRQ_NONE for request_threaded_irq

[Tony Lindgren]

There's a funny typo where IRQ_NONE is used instead of IRQF_TRIGGER_NONE
for request_threaded_irq(). Let's fix it before it gets copied elsewhere.

Fixes: dd3bf50b35e3 ("rtc: cpcap: new rtc driver")
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 drivers/rtc/rtc-cpcap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
--- a/drivers/rtc/rtc-cpcap.c
+++ b/drivers/rtc/rtc-cpcap.c
@@ -275,7 +275,7 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
 
rtc->alarm_irq = platform_get_irq(pdev, 0);
err = devm_request_threaded_irq(dev, rtc->alarm_irq, NULL,
-   cpcap_rtc_alarm_irq, IRQ_NONE,
+   cpcap_rtc_alarm_irq, IRQF_TRIGGER_NONE,
"rtc_alarm", rtc);
if (err) {
dev_err(dev, "Could not request alarm irq: %d\n", err);
@@ -291,7 +291,7 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
 */
rtc->update_irq = platform_get_irq(pdev, 1);
err = devm_request_threaded_irq(dev, rtc->update_irq, NULL,
-   cpcap_rtc_update_irq, IRQ_NONE,
+   cpcap_rtc_update_irq, IRQF_TRIGGER_NONE,
"rtc_1hz", rtc);
if (err) {
dev_err(dev, "Could not request update irq: %d\n", err);
-- 
2.12.1

[PATCH] rtc: cpcap: fix improper use of IRQ_NONE for request_threaded_irq

[Tony Lindgren]

There's a funny typo where IRQ_NONE is used instead of IRQF_TRIGGER_NONE
for request_threaded_irq(). Let's fix it before it gets copied elsewhere.

Fixes: dd3bf50b35e3 ("rtc: cpcap: new rtc driver")
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 drivers/rtc/rtc-cpcap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
--- a/drivers/rtc/rtc-cpcap.c
+++ b/drivers/rtc/rtc-cpcap.c
@@ -275,7 +275,7 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
 
rtc->alarm_irq = platform_get_irq(pdev, 0);
err = devm_request_threaded_irq(dev, rtc->alarm_irq, NULL,
-   cpcap_rtc_alarm_irq, IRQ_NONE,
+   cpcap_rtc_alarm_irq, IRQF_TRIGGER_NONE,
"rtc_alarm", rtc);
if (err) {
dev_err(dev, "Could not request alarm irq: %d\n", err);
@@ -291,7 +291,7 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
 */
rtc->update_irq = platform_get_irq(pdev, 1);
err = devm_request_threaded_irq(dev, rtc->update_irq, NULL,
-   cpcap_rtc_update_irq, IRQ_NONE,
+   cpcap_rtc_update_irq, IRQF_TRIGGER_NONE,
"rtc_1hz", rtc);
if (err) {
dev_err(dev, "Could not request update irq: %d\n", err);
-- 
2.12.1

Respond to me immediately!!

[DR.ANTHONY EMMANUEL]

Dear how are you, 
First I got your contact from yahoo Terrors search, when am 
searching for a foreigner, please I don’t now if you can keep secret? A word of 
your own as a human-being? As I have gone through your profile.  Well I have a 
deal worth 5.5m$ from the dormant account in the bank where I am working. 
However the fund belong to one Mr J. korovo he die in years ago along with his 
family by plan crash, Please if you can keep secret, I will give you more 
details and the nest thing to do,
  No risk involve, hence I work in the same bank, 
For the expenses will be in my side not you. Till you confirm the fund in your 
account, I will take care of every expense. Also all the documents that will 
back you up must send to you. Meanwhile before I contact you I have done every 
underground work through the documents of the deceases person, I have put or 
attachment his file to our favor. Also with my position every thing works 
successfully.

Contact me for more details please if you really want to know about this 
business also want to get more details please contact me through this my 
alternative email for more detail copy this address 
dr.anthony_emman...@yahoo.fr, I will send you my ID also my working Id and my 
family picture For you to know who your dealing with. Contact me back with 
Your Full Name, 
Phone No…., 
Receiver Country.., 
Occupation.., 

PLEASE IF REALLY YOUR NEED MORE DETAILS CONTACT ME VIEW MY ALTERNATIVE FOR 
SECURITY REASONS. ALSO MY PHONE NUMBER AS FOLLOW.  
dr.anthony_emman...@yahoo.fr

thanks for your understand please contact me base if you can control this fund 
once it transfer into your account before my family and I will arriver in your 
country for the sharing, 40% for you. 10% for the poorest, rest is for me. 
Give me your Phone number Let me call you so that we can talk one and one

Yours faithfully,

>From DR.ANTHONY EMMANUEL.

Respond to me immediately!!

[DR.ANTHONY EMMANUEL]

Dear how are you, 
First I got your contact from yahoo Terrors search, when am 
searching for a foreigner, please I don’t now if you can keep secret? A word of 
your own as a human-being? As I have gone through your profile.  Well I have a 
deal worth 5.5m$ from the dormant account in the bank where I am working. 
However the fund belong to one Mr J. korovo he die in years ago along with his 
family by plan crash, Please if you can keep secret, I will give you more 
details and the nest thing to do,
  No risk involve, hence I work in the same bank, 
For the expenses will be in my side not you. Till you confirm the fund in your 
account, I will take care of every expense. Also all the documents that will 
back you up must send to you. Meanwhile before I contact you I have done every 
underground work through the documents of the deceases person, I have put or 
attachment his file to our favor. Also with my position every thing works 
successfully.

Contact me for more details please if you really want to know about this 
business also want to get more details please contact me through this my 
alternative email for more detail copy this address 
dr.anthony_emman...@yahoo.fr, I will send you my ID also my working Id and my 
family picture For you to know who your dealing with. Contact me back with 
Your Full Name, 
Phone No…., 
Receiver Country.., 
Occupation.., 

PLEASE IF REALLY YOUR NEED MORE DETAILS CONTACT ME VIEW MY ALTERNATIVE FOR 
SECURITY REASONS. ALSO MY PHONE NUMBER AS FOLLOW.  
dr.anthony_emman...@yahoo.fr

thanks for your understand please contact me base if you can control this fund 
once it transfer into your account before my family and I will arriver in your 
country for the sharing, 40% for you. 10% for the poorest, rest is for me. 
Give me your Phone number Let me call you so that we can talk one and one

Yours faithfully,

>From DR.ANTHONY EMMANUEL.

[lkp-robot] [ftrace] 42c269c88d: WARNING:at_kernel/trace/ftrace.c:#ftrace_bug

[kernel test robot]

FYI, we noticed the following commit:

commit: 42c269c88dc146982a54a8267f71abc99f12852a ("ftrace: Allow for function 
tracing to record init functions on boot up")
https://git.kernel.org/cgit/linux/kernel/git/rostedt/linux-trace.git ftrace/core

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -cpu Westmere -m 512M

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



[   33.973546] WARNING: CPU: 0 PID: 246 at kernel/trace/ftrace.c:2019 
ftrace_bug+0x266/0x360
[   33.973546] WARNING: CPU: 0 PID: 246 at kernel/trace/ftrace.c:2019 
ftrace_bug+0x266/0x360
[   33.976774] Modules linked in: cmdlinepart
[   33.976774] Modules linked in: cmdlinepart
[   33.982951] CPU: 0 PID: 246 Comm: trinity-main Not tainted 
4.11.0-rc3-5-g42c269c #1
[   33.982951] CPU: 0 PID: 246 Comm: trinity-main Not tainted 
4.11.0-rc3-5-g42c269c #1
[   33.985586] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   33.985586] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   33.988910] Call Trace:
[   33.988910] Call Trace:
[   33.989766]  dump_stack+0x58/0x74
[   33.989766]  dump_stack+0x58/0x74
[   33.990879]  __warn+0xea/0x110
[   33.990879]  __warn+0xea/0x110
[   33.991920]  ? ftrace_bug+0x266/0x360
[   33.991920]  ? ftrace_bug+0x266/0x360
[   33.993167]  ? i386_start_kernel+0x5/0x9a
[   33.993167]  ? i386_start_kernel+0x5/0x9a
[   33.994522]  warn_slowpath_null+0x2a/0x30
[   33.994522]  warn_slowpath_null+0x2a/0x30
[   33.995844]  ftrace_bug+0x266/0x360
[   33.995844]  ftrace_bug+0x266/0x360
[   33.997052]  ftrace_replace_code+0x20e/0x360
[   33.997052]  ftrace_replace_code+0x20e/0x360
[   33.998537]  ftrace_modify_all_code+0x92/0x120
[   33.998537]  ftrace_modify_all_code+0x92/0x120
[   34.17]  arch_ftrace_update_code+0xf/0x20
[   34.17]  arch_ftrace_update_code+0xf/0x20
[   34.001471]  ftrace_run_update_code+0x1b/0x60
[   34.001471]  ftrace_run_update_code+0x1b/0x60
[   34.002893]  ftrace_startup_enable+0x30/0x40
[   34.002893]  ftrace_startup_enable+0x30/0x40
[   34.004338]  ftrace_startup+0xd9/0x250
[   34.004338]  ftrace_startup+0xd9/0x250
[   34.005584]  register_ftrace_function+0x40/0x60
[   34.005584]  register_ftrace_function+0x40/0x60
[   34.007092]  perf_ftrace_event_register+0x67/0x130
[   34.007092]  perf_ftrace_event_register+0x67/0x130
[   34.008727]  perf_trace_init+0xcf/0x2e0
[   34.008727]  perf_trace_init+0xcf/0x2e0
[   34.010023]  perf_tp_event_init+0x1d/0x50
[   34.010023]  perf_tp_event_init+0x1d/0x50
[   34.011365]  perf_try_init_event+0x60/0x80
[   34.011365]  perf_try_init_event+0x60/0x80
[   34.012729]  perf_event_alloc+0x6c0/0x800
[   34.012729]  perf_event_alloc+0x6c0/0x800
[   34.014073]  ? perf_event_alloc+0x353/0x800
[   34.014073]  ? perf_event_alloc+0x353/0x800
[   34.015476]  SyS_perf_event_open+0x3fa/0xf00
[   34.015476]  SyS_perf_event_open+0x3fa/0xf00
[   34.016987]  do_fast_syscall_32+0x9a/0x160
[   34.016987]  do_fast_syscall_32+0x9a/0x160
[   34.018411]  entry_SYSENTER_32+0x47/0x71
[   34.018411]  entry_SYSENTER_32+0x47/0x71
[   34.019722] EIP: 0xb77bccd9
[   34.019722] EIP: 0xb77bccd9
[   34.020677] EFLAGS: 0286 CPU: 0
[   34.020677] EFLAGS: 0286 CPU: 0
[   34.021827] EAX: ffda EBX: 09c0a9f0 ECX:  EDX: 
[   34.021827] EAX: ffda EBX: 09c0a9f0 ECX:  EDX: 
[   34.023857] ESI:  EDI: 000b EBP: 0117 ESP: bfd76e4c
[   34.023857] ESI:  EDI: 000b EBP: 0117 ESP: bfd76e4c
[   34.025895]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[   34.025895]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[   34.053634] ---[ end trace aef11820af4e004f ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.11.0-rc3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y

[lkp-robot] [ftrace] 42c269c88d: WARNING:at_kernel/trace/ftrace.c:#ftrace_bug

[kernel test robot]

FYI, we noticed the following commit:

commit: 42c269c88dc146982a54a8267f71abc99f12852a ("ftrace: Allow for function 
tracing to record init functions on boot up")
https://git.kernel.org/cgit/linux/kernel/git/rostedt/linux-trace.git ftrace/core

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -cpu Westmere -m 512M

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



[   33.973546] WARNING: CPU: 0 PID: 246 at kernel/trace/ftrace.c:2019 
ftrace_bug+0x266/0x360
[   33.973546] WARNING: CPU: 0 PID: 246 at kernel/trace/ftrace.c:2019 
ftrace_bug+0x266/0x360
[   33.976774] Modules linked in: cmdlinepart
[   33.976774] Modules linked in: cmdlinepart
[   33.982951] CPU: 0 PID: 246 Comm: trinity-main Not tainted 
4.11.0-rc3-5-g42c269c #1
[   33.982951] CPU: 0 PID: 246 Comm: trinity-main Not tainted 
4.11.0-rc3-5-g42c269c #1
[   33.985586] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   33.985586] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   33.988910] Call Trace:
[   33.988910] Call Trace:
[   33.989766]  dump_stack+0x58/0x74
[   33.989766]  dump_stack+0x58/0x74
[   33.990879]  __warn+0xea/0x110
[   33.990879]  __warn+0xea/0x110
[   33.991920]  ? ftrace_bug+0x266/0x360
[   33.991920]  ? ftrace_bug+0x266/0x360
[   33.993167]  ? i386_start_kernel+0x5/0x9a
[   33.993167]  ? i386_start_kernel+0x5/0x9a
[   33.994522]  warn_slowpath_null+0x2a/0x30
[   33.994522]  warn_slowpath_null+0x2a/0x30
[   33.995844]  ftrace_bug+0x266/0x360
[   33.995844]  ftrace_bug+0x266/0x360
[   33.997052]  ftrace_replace_code+0x20e/0x360
[   33.997052]  ftrace_replace_code+0x20e/0x360
[   33.998537]  ftrace_modify_all_code+0x92/0x120
[   33.998537]  ftrace_modify_all_code+0x92/0x120
[   34.17]  arch_ftrace_update_code+0xf/0x20
[   34.17]  arch_ftrace_update_code+0xf/0x20
[   34.001471]  ftrace_run_update_code+0x1b/0x60
[   34.001471]  ftrace_run_update_code+0x1b/0x60
[   34.002893]  ftrace_startup_enable+0x30/0x40
[   34.002893]  ftrace_startup_enable+0x30/0x40
[   34.004338]  ftrace_startup+0xd9/0x250
[   34.004338]  ftrace_startup+0xd9/0x250
[   34.005584]  register_ftrace_function+0x40/0x60
[   34.005584]  register_ftrace_function+0x40/0x60
[   34.007092]  perf_ftrace_event_register+0x67/0x130
[   34.007092]  perf_ftrace_event_register+0x67/0x130
[   34.008727]  perf_trace_init+0xcf/0x2e0
[   34.008727]  perf_trace_init+0xcf/0x2e0
[   34.010023]  perf_tp_event_init+0x1d/0x50
[   34.010023]  perf_tp_event_init+0x1d/0x50
[   34.011365]  perf_try_init_event+0x60/0x80
[   34.011365]  perf_try_init_event+0x60/0x80
[   34.012729]  perf_event_alloc+0x6c0/0x800
[   34.012729]  perf_event_alloc+0x6c0/0x800
[   34.014073]  ? perf_event_alloc+0x353/0x800
[   34.014073]  ? perf_event_alloc+0x353/0x800
[   34.015476]  SyS_perf_event_open+0x3fa/0xf00
[   34.015476]  SyS_perf_event_open+0x3fa/0xf00
[   34.016987]  do_fast_syscall_32+0x9a/0x160
[   34.016987]  do_fast_syscall_32+0x9a/0x160
[   34.018411]  entry_SYSENTER_32+0x47/0x71
[   34.018411]  entry_SYSENTER_32+0x47/0x71
[   34.019722] EIP: 0xb77bccd9
[   34.019722] EIP: 0xb77bccd9
[   34.020677] EFLAGS: 0286 CPU: 0
[   34.020677] EFLAGS: 0286 CPU: 0
[   34.021827] EAX: ffda EBX: 09c0a9f0 ECX:  EDX: 
[   34.021827] EAX: ffda EBX: 09c0a9f0 ECX:  EDX: 
[   34.023857] ESI:  EDI: 000b EBP: 0117 ESP: bfd76e4c
[   34.023857] ESI:  EDI: 000b EBP: 0117 ESP: bfd76e4c
[   34.025895]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[   34.025895]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[   34.053634] ---[ end trace aef11820af4e004f ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.11.0-rc3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y

RE: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

[Joseph Chang]

Hi Corey,

Thanks your feedback and suggestion. :)
I think you are right. It is better to allocate one new local variable to store 
i2c data and size to be send...
I create new patch in following according to your suggestion.
Could you help to review the patch again?

>From eec31f51acc7e019fd0dcc512febda86870268d2 Mon Sep 17 00:00:00 2001
From: Joeseph Chang 
Date: Mon, 27 Mar 2017 10:46:42 +0800
Subject: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

msg_written_handler() may set ssif_info->multi_data to NULL
when using ipmitool to write fru.

Fix kernel panic at ipmi_ssif_thread() and incorrect
ssif_info->multi_pos by adding one local pointer i2c_data to store i2c
data and size to send before calling ssif_i2c_send().

With this change, can avoid concurrent access to ssif_info->multi_pos and
ssif_info->multi_data at msg_written_handler.
Because msg_written_handler can be called at any time after ssif_i2c_send().
---
 drivers/char/ipmi/ipmi_ssif.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 drivers/char/ipmi/ipmi_ssif.c

diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
old mode 100644
new mode 100755
index cca6e5b..f36f018
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -852,6 +852,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,
unsigned char *data, unsigned int len)
 {
int rv;
+   unsigned char *i2c_data;
 
/* We are single-threaded here, so no need for a lock. */
if (result < 0) {
@@ -899,6 +900,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,
left = 32;
/* Length byte. */
ssif_info->multi_data[ssif_info->multi_pos] = left;
+   i2c_data = ssif_info->multi_data + ssif_info->multi_pos;
ssif_info->multi_pos += left;
if (left < 32)
/*
@@ -912,7 +914,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,
rv = ssif_i2c_send(ssif_info, msg_written_handler,
  I2C_SMBUS_WRITE,
  SSIF_IPMI_MULTI_PART_REQUEST_MIDDLE,
- ssif_info->multi_data + ssif_info->multi_pos,
+ i2c_data,
  I2C_SMBUS_BLOCK_DATA);
if (rv < 0) {
/* request failed, just return the error. */
-- 
1.9.1


Thank you,
Joseph.
-Original Message-
From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
Sent: Saturday, March 25, 2017 10:53 AM
To: Joseph Chang ; 
openipmi-develo...@lists.sourceforge.net; linux-kernel@vger.kernel.org
Cc: Jiandi An ; Joeseph Chang 

Subject: Re: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

This is incorrect.  These values *must* be set before ssif_i2c_send() is done.
Once ssif_i2c_send() is called, msg_written_handler can be called at any time 
after that, including before where you moved the new code.

If I understand this correctly, I think you need to add a variable, maybe named 
"bytes_to_write" and do

   bytes_to_write = ssif_info->multi_data + ssif_info->multi_pos;

before the comparison and pass bytes_to_write into ssif_i2c_send().

Thanks,

-corey

On 03/23/2017 02:07 AM, Joeseph Chang wrote:
> From: Joeseph Chang 
>
> msg_written_handler() may set ssif_info->multi_data to NULL when using 
> ipmitool to write fru.
> Change the ssif i2c send data sequence in msg_written_handler() to fix 
> NULL pointer kernel panic and incorrect ssif_info->multi_pos.
>
> Signed-off-by: Joeseph Chang 
> ---
>   drivers/char/ipmi/ipmi_ssif.c | 20 +++-
>   1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_ssif.c 
> b/drivers/char/ipmi/ipmi_ssif.c index cca6e5b..39346ee 100644
> --- a/drivers/char/ipmi/ipmi_ssif.c
> +++ b/drivers/char/ipmi/ipmi_ssif.c
> @@ -899,21 +899,13 @@ static void msg_written_handler(struct ssif_info 
> *ssif_info, int result,
>   left = 32;
>   /* Length byte. */
>   ssif_info->multi_data[ssif_info->multi_pos] = left;
> - ssif_info->multi_pos += left;
> - if (left < 32)
> - /*
> -  * Write is finished.  Note that we must end
> -  * with a write of less than 32 bytes to
> -  * complete the transaction, even if it is
> -  * zero bytes.
> -  */
> - ssif_info->multi_data = NULL;
>   
>   rv = ssif_i2c_send(ssif_info, msg_written_handler,
> 

RE: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

[Joseph Chang]

Hi Corey,

Thanks your feedback and suggestion. :)
I think you are right. It is better to allocate one new local variable to store 
i2c data and size to be send...
I create new patch in following according to your suggestion.
Could you help to review the patch again?

>From eec31f51acc7e019fd0dcc512febda86870268d2 Mon Sep 17 00:00:00 2001
From: Joeseph Chang 
Date: Mon, 27 Mar 2017 10:46:42 +0800
Subject: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

msg_written_handler() may set ssif_info->multi_data to NULL
when using ipmitool to write fru.

Fix kernel panic at ipmi_ssif_thread() and incorrect
ssif_info->multi_pos by adding one local pointer i2c_data to store i2c
data and size to send before calling ssif_i2c_send().

With this change, can avoid concurrent access to ssif_info->multi_pos and
ssif_info->multi_data at msg_written_handler.
Because msg_written_handler can be called at any time after ssif_i2c_send().
---
 drivers/char/ipmi/ipmi_ssif.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 drivers/char/ipmi/ipmi_ssif.c

diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
old mode 100644
new mode 100755
index cca6e5b..f36f018
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -852,6 +852,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,
unsigned char *data, unsigned int len)
 {
int rv;
+   unsigned char *i2c_data;
 
/* We are single-threaded here, so no need for a lock. */
if (result < 0) {
@@ -899,6 +900,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,
left = 32;
/* Length byte. */
ssif_info->multi_data[ssif_info->multi_pos] = left;
+   i2c_data = ssif_info->multi_data + ssif_info->multi_pos;
ssif_info->multi_pos += left;
if (left < 32)
/*
@@ -912,7 +914,7 @@ static void msg_written_handler(struct ssif_info 
*ssif_info, int result,
rv = ssif_i2c_send(ssif_info, msg_written_handler,
  I2C_SMBUS_WRITE,
  SSIF_IPMI_MULTI_PART_REQUEST_MIDDLE,
- ssif_info->multi_data + ssif_info->multi_pos,
+ i2c_data,
  I2C_SMBUS_BLOCK_DATA);
if (rv < 0) {
/* request failed, just return the error. */
-- 
1.9.1


Thank you,
Joseph.
-Original Message-
From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
Sent: Saturday, March 25, 2017 10:53 AM
To: Joseph Chang ; 
openipmi-develo...@lists.sourceforge.net; linux-kernel@vger.kernel.org
Cc: Jiandi An ; Joeseph Chang 

Subject: Re: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

This is incorrect.  These values *must* be set before ssif_i2c_send() is done.
Once ssif_i2c_send() is called, msg_written_handler can be called at any time 
after that, including before where you moved the new code.

If I understand this correctly, I think you need to add a variable, maybe named 
"bytes_to_write" and do

   bytes_to_write = ssif_info->multi_data + ssif_info->multi_pos;

before the comparison and pass bytes_to_write into ssif_i2c_send().

Thanks,

-corey

On 03/23/2017 02:07 AM, Joeseph Chang wrote:
> From: Joeseph Chang 
>
> msg_written_handler() may set ssif_info->multi_data to NULL when using 
> ipmitool to write fru.
> Change the ssif i2c send data sequence in msg_written_handler() to fix 
> NULL pointer kernel panic and incorrect ssif_info->multi_pos.
>
> Signed-off-by: Joeseph Chang 
> ---
>   drivers/char/ipmi/ipmi_ssif.c | 20 +++-
>   1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_ssif.c 
> b/drivers/char/ipmi/ipmi_ssif.c index cca6e5b..39346ee 100644
> --- a/drivers/char/ipmi/ipmi_ssif.c
> +++ b/drivers/char/ipmi/ipmi_ssif.c
> @@ -899,21 +899,13 @@ static void msg_written_handler(struct ssif_info 
> *ssif_info, int result,
>   left = 32;
>   /* Length byte. */
>   ssif_info->multi_data[ssif_info->multi_pos] = left;
> - ssif_info->multi_pos += left;
> - if (left < 32)
> - /*
> -  * Write is finished.  Note that we must end
> -  * with a write of less than 32 bytes to
> -  * complete the transaction, even if it is
> -  * zero bytes.
> -  */
> - ssif_info->multi_data = NULL;
>   
>   rv = ssif_i2c_send(ssif_info, msg_written_handler,
> I2C_SMBUS_WRITE,
> SSIF_IPMI_MULTI_PART_REQUEST_MIDDLE,
> ssif_info->multi_data + ssif_info->multi_pos,

[PATCH] perf list sdt: Show option in man page

[Ravi Bangoria]

Commit 40218daea1db ("perf list: Show SDT and pre-cached events") added
sdt support in perf list, but it missed to update documentation.

Show sdt option in man perf-list.

Signed-off-by: Ravi Bangoria 
---
 tools/perf/Documentation/perf-list.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index 143d98d..0b268c8 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,7 +8,7 @@ perf-list - List all symbolic event types
 SYNOPSIS
 
 [verse]
-'perf list' [--no-desc] [--long-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [--long-desc] 
[hw|sw|cache|tracepoint|pmu|sdt|event_glob]
 
 DESCRIPTION
 ---
@@ -244,6 +244,8 @@ To limit the list use:
 
 . 'pmu' to print the kernel supplied PMU events.
 
+. 'sdt' to list all Statically Defined Tracepoint events.
+
 . If none of the above is matched, it will apply the supplied glob to all
   events, printing the ones that match.
 
-- 
2.9.3

[PATCH] perf list sdt: Show option in man page

[Ravi Bangoria]

Commit 40218daea1db ("perf list: Show SDT and pre-cached events") added
sdt support in perf list, but it missed to update documentation.

Show sdt option in man perf-list.

Signed-off-by: Ravi Bangoria 
---
 tools/perf/Documentation/perf-list.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index 143d98d..0b268c8 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,7 +8,7 @@ perf-list - List all symbolic event types
 SYNOPSIS
 
 [verse]
-'perf list' [--no-desc] [--long-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [--long-desc] 
[hw|sw|cache|tracepoint|pmu|sdt|event_glob]
 
 DESCRIPTION
 ---
@@ -244,6 +244,8 @@ To limit the list use:
 
 . 'pmu' to print the kernel supplied PMU events.
 
+. 'sdt' to list all Statically Defined Tracepoint events.
+
 . If none of the above is matched, it will apply the supplied glob to all
   events, printing the ones that match.
 
-- 
2.9.3

Re: [PATCH v3] Documentation: Input: Add uinput documentation

[Marcos Paulo de Souza]

On Mon, Mar 27, 2017 at 11:06:11AM +1000, Peter Hutterer wrote:
> On Sun, Mar 26, 2017 at 01:48:12PM -0300, Marcos Paulo de Souza wrote:
> > Signed-off-by: Marcos Paulo de Souza 
> > ---
> >  v2 -> v3:
> >  Changes in libevdev's description (suggested by Peter)
> >  Added uinput version check when using the old interface (suggested by 
> > Peter)
> >  Removed section numbers from sections, sphinx creates these indexes
> > (suggestion by Jon)
> > 
> >  v1 -> v2:
> >  Changes all over the place, including better descriptions (suggested by 
> > Peter)
> >  Added comments about the need of a sleep call (suggested by Peter)
> >  
> 
> 
> [...]
> 
> tested mouse/keyboard - works as expected, thanks. I found it slightly
> confusing though that the mouse example wasn't wrapped in main() but still 
> had a
> return 0 at the bottom. This code will never change once it's in the doc, so
> I'm not sure skipping things is really that useful here.

True, I'll "complete" the code in the next submission.

> 
> > +uinput old interface
> > +
> > +
> > +Before uinput version 5, there wasn't a proper ioctl to setup a virtual 
> > device.
> > +In this case, the user neesa to fill a different struct and call write o 
> > the
> > +uinput file descriptor to configure the new uinput device.
> > +
> > +.. code-block:: c
> > +
> > +#include 
> > +
> > +/* emit function is identical to of the first example */
> > +
> > +struct uinput_user_dev uud;
> > +int version;
> > +
> > +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> > +ioctl(fd, UI_GET_VERSION, );
> > +
> > +if (version < 5) {
> 
> this won't work on all kernels. UI_GET_VERSION was added in version 4, on
> kernels before you get rc == -1 and errno EINVAL. You can only check
> for >= 4. Please make sure the example compiles and works on an older
> kernel, otherwise there's no point shipping it.

OK, noting here.

> 
> Cheers,
>Peter
> 
> > +/*
> > + * the ioctls below enables the to be created device to key
> > + * events, in this case the space key
> > + */
> > +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> > +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> > +
> > +memset(, 0, sizeof(uud));
> > +snprintf(uud.name, UINPUT_MAX_NAME_SIZE, "uinput old interface");
> > +write(fd, , sizeof(uud));
> > +
> > +ioctl(fd, UI_DEV_CREATE);
> > +
> > +/*
> > + * On UI_DEV_CREATE the kernel creates the device nodes for this 
> > device.
> > + * Insert a pause so that userspace has time to detect, initialize 
> > the
> > + * new device, and can start to listen to events from this device
> > + */
> > +sleep(1);
> > +
> > +/* key press, report the event, send key release, and report again 
> > */
> > +emit(EV_KEY, KEY_SPACE, 1);
> > +emit(EV_SYN, SYN_REPORT, 0);
> > +emit(EV_KEY, KEY_SPACE, 0);
> > +emit(EV_SYN, SYN_REPORT, 0);
> > +
> > +ioctl(fd, UI_DEV_DESTROY);
> > +}
> > +
> > +close(fd);
> > +
> > +return 0;
> > +
> > -- 
> > 2.9.3
> > 

-- 
Thanks,
Marcos

Re: [PATCH v3] Documentation: Input: Add uinput documentation

[Marcos Paulo de Souza]

On Mon, Mar 27, 2017 at 11:06:11AM +1000, Peter Hutterer wrote:
> On Sun, Mar 26, 2017 at 01:48:12PM -0300, Marcos Paulo de Souza wrote:
> > Signed-off-by: Marcos Paulo de Souza 
> > ---
> >  v2 -> v3:
> >  Changes in libevdev's description (suggested by Peter)
> >  Added uinput version check when using the old interface (suggested by 
> > Peter)
> >  Removed section numbers from sections, sphinx creates these indexes
> > (suggestion by Jon)
> > 
> >  v1 -> v2:
> >  Changes all over the place, including better descriptions (suggested by 
> > Peter)
> >  Added comments about the need of a sleep call (suggested by Peter)
> >  
> 
> 
> [...]
> 
> tested mouse/keyboard - works as expected, thanks. I found it slightly
> confusing though that the mouse example wasn't wrapped in main() but still 
> had a
> return 0 at the bottom. This code will never change once it's in the doc, so
> I'm not sure skipping things is really that useful here.

True, I'll "complete" the code in the next submission.

> 
> > +uinput old interface
> > +
> > +
> > +Before uinput version 5, there wasn't a proper ioctl to setup a virtual 
> > device.
> > +In this case, the user neesa to fill a different struct and call write o 
> > the
> > +uinput file descriptor to configure the new uinput device.
> > +
> > +.. code-block:: c
> > +
> > +#include 
> > +
> > +/* emit function is identical to of the first example */
> > +
> > +struct uinput_user_dev uud;
> > +int version;
> > +
> > +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> > +ioctl(fd, UI_GET_VERSION, );
> > +
> > +if (version < 5) {
> 
> this won't work on all kernels. UI_GET_VERSION was added in version 4, on
> kernels before you get rc == -1 and errno EINVAL. You can only check
> for >= 4. Please make sure the example compiles and works on an older
> kernel, otherwise there's no point shipping it.

OK, noting here.

> 
> Cheers,
>Peter
> 
> > +/*
> > + * the ioctls below enables the to be created device to key
> > + * events, in this case the space key
> > + */
> > +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> > +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> > +
> > +memset(, 0, sizeof(uud));
> > +snprintf(uud.name, UINPUT_MAX_NAME_SIZE, "uinput old interface");
> > +write(fd, , sizeof(uud));
> > +
> > +ioctl(fd, UI_DEV_CREATE);
> > +
> > +/*
> > + * On UI_DEV_CREATE the kernel creates the device nodes for this 
> > device.
> > + * Insert a pause so that userspace has time to detect, initialize 
> > the
> > + * new device, and can start to listen to events from this device
> > + */
> > +sleep(1);
> > +
> > +/* key press, report the event, send key release, and report again 
> > */
> > +emit(EV_KEY, KEY_SPACE, 1);
> > +emit(EV_SYN, SYN_REPORT, 0);
> > +emit(EV_KEY, KEY_SPACE, 0);
> > +emit(EV_SYN, SYN_REPORT, 0);
> > +
> > +ioctl(fd, UI_DEV_DESTROY);
> > +}
> > +
> > +close(fd);
> > +
> > +return 0;
> > +
> > -- 
> > 2.9.3
> > 

-- 
Thanks,
Marcos

linux-next: build warning after merge of the spi tree

[Stephen Rothwell]

Hi Mark,

After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/spi/spi-ti-qspi.c: In function 'ti_qspi_dma_xfer':
drivers/spi/spi-ti-qspi.c:398:21: warning: unused variable 'dma_dev' 
[-Wunused-variable]
  struct dma_device *dma_dev = chan->device;
 ^

Introduced by commit

  1351aaeb50b2 ("spi: spi-ti-qspi: Use dma_engine wrapper for dma memcpy call")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the spi tree

[Stephen Rothwell]

Hi Mark,

After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/spi/spi-ti-qspi.c: In function 'ti_qspi_dma_xfer':
drivers/spi/spi-ti-qspi.c:398:21: warning: unused variable 'dma_dev' 
[-Wunused-variable]
  struct dma_device *dma_dev = chan->device;
 ^

Introduced by commit

  1351aaeb50b2 ("spi: spi-ti-qspi: Use dma_engine wrapper for dma memcpy call")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 4.10 012/167] mmc: sdhci-acpi: support deferred probe

[Zhang Rui]

On Sun, 2017-03-26 at 12:26 +0100, Andrey Utkin wrote:
> On Fri, Mar 10, 2017 at 10:07:35AM +0100, Greg Kroah-Hartman wrote:
> > 
> > 4.10-stable review patch.  If anyone has any objections, please let
> > me know.
> > 
> > --
> > 
> > From: Zhang Rui 
> > 
> > commit e28d6f048799acb0014491e6b74e580d84bd7916 upstream.
> > 
> > With commit 67bf5156edc4 ("gpio / ACPI: fix returned error from
> > acpi_dev_gpio_irq_get()"), mmc_gpiod_request_cd() returns
> > -EPROBE_DEFER if
> > GPIO is not ready when sdhci-acpi driver is probed, and sdhci-acpi
> > driver
> > should be probed again later in this case.
> > 
> > This fixes an order issue when both GPIO and sdhci-acpi drivers are
> > built
> > as modules.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177101
> > Tested-by: Jonas Aaberg 
> > Signed-off-by: Zhang Rui 
> > Acked-by: Adrian Hunter 
> > Signed-off-by: Ulf Hansson 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> >  drivers/mmc/host/sdhci-acpi.c |5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > --- a/drivers/mmc/host/sdhci-acpi.c
> > +++ b/drivers/mmc/host/sdhci-acpi.c
> > @@ -467,7 +467,10 @@ static int sdhci_acpi_probe(struct platf
> >     if (sdhci_acpi_flag(c, SDHCI_ACPI_SD_CD)) {
> >     bool v = sdhci_acpi_flag(c,
> > SDHCI_ACPI_SD_CD_OVERRIDE_LEVEL);
> >  
> > -   if (mmc_gpiod_request_cd(host->mmc, NULL, 0, v, 0,
> > NULL)) {
> > +   err = mmc_gpiod_request_cd(host->mmc, NULL, 0, v,
> > 0, NULL);
> > +   if (err) {
> > +   if (err == -EPROBE_DEFER)
> > +   goto err_free;
> >     dev_warn(dev, "failed to setup card detect
> > gpio\n");
> >     c->use_runtime_pm = false;
> >     }
> > 
> > 
> Regression reported: https://bugzilla.kernel.org/show_bug.cgi?id=1948
> 71
> 
> Reverting this patch is said to fix the issue for 4.10.2.

thanks for raising the issue. Let's see check why it breaks in the
bugzilla report.

thanks,
rui

Re: [PATCH 4.10 012/167] mmc: sdhci-acpi: support deferred probe

[Zhang Rui]

On Sun, 2017-03-26 at 12:26 +0100, Andrey Utkin wrote:
> On Fri, Mar 10, 2017 at 10:07:35AM +0100, Greg Kroah-Hartman wrote:
> > 
> > 4.10-stable review patch.  If anyone has any objections, please let
> > me know.
> > 
> > --
> > 
> > From: Zhang Rui 
> > 
> > commit e28d6f048799acb0014491e6b74e580d84bd7916 upstream.
> > 
> > With commit 67bf5156edc4 ("gpio / ACPI: fix returned error from
> > acpi_dev_gpio_irq_get()"), mmc_gpiod_request_cd() returns
> > -EPROBE_DEFER if
> > GPIO is not ready when sdhci-acpi driver is probed, and sdhci-acpi
> > driver
> > should be probed again later in this case.
> > 
> > This fixes an order issue when both GPIO and sdhci-acpi drivers are
> > built
> > as modules.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177101
> > Tested-by: Jonas Aaberg 
> > Signed-off-by: Zhang Rui 
> > Acked-by: Adrian Hunter 
> > Signed-off-by: Ulf Hansson 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> >  drivers/mmc/host/sdhci-acpi.c |5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > --- a/drivers/mmc/host/sdhci-acpi.c
> > +++ b/drivers/mmc/host/sdhci-acpi.c
> > @@ -467,7 +467,10 @@ static int sdhci_acpi_probe(struct platf
> >     if (sdhci_acpi_flag(c, SDHCI_ACPI_SD_CD)) {
> >     bool v = sdhci_acpi_flag(c,
> > SDHCI_ACPI_SD_CD_OVERRIDE_LEVEL);
> >  
> > -   if (mmc_gpiod_request_cd(host->mmc, NULL, 0, v, 0,
> > NULL)) {
> > +   err = mmc_gpiod_request_cd(host->mmc, NULL, 0, v,
> > 0, NULL);
> > +   if (err) {
> > +   if (err == -EPROBE_DEFER)
> > +   goto err_free;
> >     dev_warn(dev, "failed to setup card detect
> > gpio\n");
> >     c->use_runtime_pm = false;
> >     }
> > 
> > 
> Regression reported: https://bugzilla.kernel.org/show_bug.cgi?id=1948
> 71
> 
> Reverting this patch is said to fix the issue for 4.10.2.

thanks for raising the issue. Let's see check why it breaks in the
bugzilla report.

thanks,
rui

Re: [RFC PATCH kernel] gcc-goto.sh: Allow to pass with CONFIG_DEBUG_INFO_SPLIT=y

[Alexey Kardashevskiy]

On 15/03/17 13:27, Alexey Kardashevskiy wrote:
> On 14/03/17 13:54, Alexey Kardashevskiy wrote:
>> On 03/03/17 11:51, Alexey Kardashevskiy wrote:
>>> With just CONFIG_DEBUG_INFO=y, the makefile adds "-g" to
>>> KBUILD_CFLAGS/KBUILD_AFLAGS and the test passes.
>>>
>>> However, if CONFIG_DEBUG_INFO_SPLIT is also enabled, the makefile
>>> adds "-gsplit-dwarf" instead which makes the test fail with $?==1
>>> because of objcopy trying to split the debug info:
>>>
>>> objcopy: Warning: '/dev/null' is not an ordinary file
>>>
>>> This changes the output to $(mktemp) which fixes the problem.
>>>
>>> I am pretty sure there better ways, this is just to demonstrate the bug.
>>>
>>> gcc 5.4.1, ppc64le (does not really matter).
>>>
>>> Cc: Jason Baron 
>>
>>
>> Ping?
> 
> I am adding more folks as Jason's mail server rejects mails with "Recipient
> address rejected: Access denied ".


Anyone, ping?


> 
> 
>>
>>
>>
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>>  scripts/gcc-goto.sh | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
>>> index c9469d34ecc6..ab21216ab68d 100755
>>> --- a/scripts/gcc-goto.sh
>>> +++ b/scripts/gcc-goto.sh
>>> @@ -2,7 +2,8 @@
>>>  # Test for gcc 'asm goto' support
>>>  # Copyright (C) 2010, Jason Baron 
>>>  
>>> -cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
>>> +TMPOUT=$(mktemp)
>>> +cat << "END" | $@ -x c - -c -o $TMPOUT >/dev/null 2>&1 && echo "y"
>>>  int main(void)
>>>  {
>>>  #if defined(__arm__) || defined(__aarch64__)
>>> @@ -19,3 +20,5 @@ entry:
>>> return 0;
>>>  }
>>>  END
>>> +
>>> +rm $TMPOUT 2>/dev/null 2>&1
>>>
>>
>>
> 
> 


-- 
Alexey

Re: [RFC PATCH kernel] gcc-goto.sh: Allow to pass with CONFIG_DEBUG_INFO_SPLIT=y

[Alexey Kardashevskiy]

On 15/03/17 13:27, Alexey Kardashevskiy wrote:
> On 14/03/17 13:54, Alexey Kardashevskiy wrote:
>> On 03/03/17 11:51, Alexey Kardashevskiy wrote:
>>> With just CONFIG_DEBUG_INFO=y, the makefile adds "-g" to
>>> KBUILD_CFLAGS/KBUILD_AFLAGS and the test passes.
>>>
>>> However, if CONFIG_DEBUG_INFO_SPLIT is also enabled, the makefile
>>> adds "-gsplit-dwarf" instead which makes the test fail with $?==1
>>> because of objcopy trying to split the debug info:
>>>
>>> objcopy: Warning: '/dev/null' is not an ordinary file
>>>
>>> This changes the output to $(mktemp) which fixes the problem.
>>>
>>> I am pretty sure there better ways, this is just to demonstrate the bug.
>>>
>>> gcc 5.4.1, ppc64le (does not really matter).
>>>
>>> Cc: Jason Baron 
>>
>>
>> Ping?
> 
> I am adding more folks as Jason's mail server rejects mails with "Recipient
> address rejected: Access denied ".


Anyone, ping?


> 
> 
>>
>>
>>
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>>  scripts/gcc-goto.sh | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
>>> index c9469d34ecc6..ab21216ab68d 100755
>>> --- a/scripts/gcc-goto.sh
>>> +++ b/scripts/gcc-goto.sh
>>> @@ -2,7 +2,8 @@
>>>  # Test for gcc 'asm goto' support
>>>  # Copyright (C) 2010, Jason Baron 
>>>  
>>> -cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
>>> +TMPOUT=$(mktemp)
>>> +cat << "END" | $@ -x c - -c -o $TMPOUT >/dev/null 2>&1 && echo "y"
>>>  int main(void)
>>>  {
>>>  #if defined(__arm__) || defined(__aarch64__)
>>> @@ -19,3 +20,5 @@ entry:
>>> return 0;
>>>  }
>>>  END
>>> +
>>> +rm $TMPOUT 2>/dev/null 2>&1
>>>
>>
>>
> 
> 


-- 
Alexey

Re: [PATCH v2] Documentation: Input: Add uinput documentation

[Marcos Paulo de Souza]

On Mon, Mar 27, 2017 at 08:52:58AM +1000, Peter Hutterer wrote:
> On Sun, Mar 26, 2017 at 01:21:14PM -0300, Marcos Paulo de Souza wrote:
> > On Fri, Mar 24, 2017 at 02:39:13PM +1000, Peter Hutterer wrote:
> > > as usual, reading through these things multiple times means one spots a
> > > couple of different things. sorry about that.
> > > 
> > > On Fri, Mar 24, 2017 at 12:34:59AM -0300, Marcos Paulo de Souza wrote:
> > > > Signed-off-by: Marcos Paulo de Souza 
> > > > ---
> > > >  Documentation/input/uinput.rst | 196 
> > > > +
> > > >  1 file changed, 196 insertions(+)
> > > >  create mode 100644 Documentation/input/uinput.rst
> > > > 
> > > > diff --git a/Documentation/input/uinput.rst 
> > > > b/Documentation/input/uinput.rst
> > > > new file mode 100644
> > > > index 000..eb79b77
> > > > --- /dev/null
> > > > +++ b/Documentation/input/uinput.rst
> > > > @@ -0,0 +1,196 @@
> > > > +=
> > > > +uinput module
> > > > +=
> > > > +
> > > > +Introduction
> > > > +
> > > > +
> > > > +uinput is a kernel module that makes possible to create and handle 
> > > > input devices
> > > 
> > > typo: makes *it* possible.
> > > 
> > > replace "to create and handle" with "to emulate", the rest is in the next
> > > sentence anyway
> > 
> > Fixed.
> > 
> > > 
> > > > +from userspace. By writing to the module's /dev/uinput (or 
> > > > /dev/input/uinput), a
> > > > +process can create a virtual device with specific capabilities.
> > > > +Once created, the process can send events through that virtual device.
> > > > +
> > > > +Interface
> > > > +=
> > > > +
> > > > +::
> > > > +
> > > > +  linux/uinput.h
> > > > +
> > > > +The uinput header defines ioctls to create, setup and destroy virtual 
> > > > devices.
> > > > +
> > > > +libevdev
> > > > +
> > > > +
> > > > +libevdev is a wrapper library for evdev devices, making uinput setup 
> > > > easier
> > > > +by skipping a lot of ioctl calls. When dealing with uinput, libevdev 
> > > > is the best
> > > > +alternative over accessing uinput directly, and it is less error prone.
> > > 
> > > "libevdev is a wrapper library for evdev devices that provides interfaces 
> > > to
> > > create uinput devices and send events. libevdev is less error-prone than
> > > accessing uinput directly and should be considered for new software".
> > 
> > Much better. Fixed.
> > 
> > > 
> > > > +
> > > > +For examples and more information about libevdev:
> > > > +https://cgit.freedesktop.org/libevdev
> > > > +
> > > 
> > > Please use https://www.freedesktop.org/software/libevdev/doc/latest/
> > > (which needs a link to the git repo, I'll fix that in a minute)
> > 
> > Fixed.
> > 
> > > 
> > > > +Examples
> > > > +
> > > > +
> > > > +1.0 Keyboard events
> > > > +---
> > > > +
> > > > +This first example shows how to create a new virtual device and how to 
> > > > send a
> > > > +key event. All default imports and error handlers were removed for the 
> > > > sake of
> > > > +simplicity.
> > > > +
> > > > +.. code-block:: c
> > > > +
> > > > +   #include 
> > > > +
> > > > +   int fd;
> > > > +
> > > > +   void emit(int type, int code, int val)
> > > > +   {
> > > > +struct input_event ie;
> > > > +
> > > > +ie.type = type;
> > > > +ie.code = code;
> > > > +ie.value = val;
> > > > +/* below timestamp values are ignored */
> > > > +ie.time.tv_sec = 0;
> > > > +ie.time.tv_usec = 0;
> > > > +
> > > > +write(fd, , sizeof(ie));
> > > > +   }
> > > > +
> > > > +   int main() {
> > > > +struct uinput_setup usetup;
> > > > +
> > > > +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> > > > +
> > > > +/* the ioctls below enables the to be created device to key
> > > > + * events, in this case the space key
> > > > + **/
> > > 
> > > the comment terminator doesn't look right
> > 
> > Fixed.
> > 
> > > 
> > > > +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> > > > +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> > > > +
> > > > +memset(, 0, sizeof(usetup));
> > > > +usetup.id.bustype = BUS_USB;
> > > > +usetup.id.vendor = 0x1234; /* sample vendor */
> > > 
> > > add a sample product id too please
> > Added.
> > 
> > > 
> > > > +strcpy(usetup.name, "Example device");
> > > > +
> > > > +ioctl(fd, UI_DEV_SETUP, );
> > > > +ioctl(fd, UI_DEV_CREATE);
> > > > +
> > > > +/* UI_DEV_CREATE causes the kernel to create the device nodes 
> > > > for this
> > > 
> > > "On UI_DEV_CREATE the kernel creates the device nodes..."
> > Fixed.
> > 
> > > 
> > > > + * device. Insert a pause so that userspace has time to detect,
> > > > + * initialize the new device, and can start to listen to 
> > > > events from
> > > > + * this device
> > > > + **/
> > > 
> > > the comment terminator doesn't look right
> 

Re: [PATCH v2] Documentation: Input: Add uinput documentation

[Marcos Paulo de Souza]

On Mon, Mar 27, 2017 at 08:52:58AM +1000, Peter Hutterer wrote:
> On Sun, Mar 26, 2017 at 01:21:14PM -0300, Marcos Paulo de Souza wrote:
> > On Fri, Mar 24, 2017 at 02:39:13PM +1000, Peter Hutterer wrote:
> > > as usual, reading through these things multiple times means one spots a
> > > couple of different things. sorry about that.
> > > 
> > > On Fri, Mar 24, 2017 at 12:34:59AM -0300, Marcos Paulo de Souza wrote:
> > > > Signed-off-by: Marcos Paulo de Souza 
> > > > ---
> > > >  Documentation/input/uinput.rst | 196 
> > > > +
> > > >  1 file changed, 196 insertions(+)
> > > >  create mode 100644 Documentation/input/uinput.rst
> > > > 
> > > > diff --git a/Documentation/input/uinput.rst 
> > > > b/Documentation/input/uinput.rst
> > > > new file mode 100644
> > > > index 000..eb79b77
> > > > --- /dev/null
> > > > +++ b/Documentation/input/uinput.rst
> > > > @@ -0,0 +1,196 @@
> > > > +=
> > > > +uinput module
> > > > +=
> > > > +
> > > > +Introduction
> > > > +
> > > > +
> > > > +uinput is a kernel module that makes possible to create and handle 
> > > > input devices
> > > 
> > > typo: makes *it* possible.
> > > 
> > > replace "to create and handle" with "to emulate", the rest is in the next
> > > sentence anyway
> > 
> > Fixed.
> > 
> > > 
> > > > +from userspace. By writing to the module's /dev/uinput (or 
> > > > /dev/input/uinput), a
> > > > +process can create a virtual device with specific capabilities.
> > > > +Once created, the process can send events through that virtual device.
> > > > +
> > > > +Interface
> > > > +=
> > > > +
> > > > +::
> > > > +
> > > > +  linux/uinput.h
> > > > +
> > > > +The uinput header defines ioctls to create, setup and destroy virtual 
> > > > devices.
> > > > +
> > > > +libevdev
> > > > +
> > > > +
> > > > +libevdev is a wrapper library for evdev devices, making uinput setup 
> > > > easier
> > > > +by skipping a lot of ioctl calls. When dealing with uinput, libevdev 
> > > > is the best
> > > > +alternative over accessing uinput directly, and it is less error prone.
> > > 
> > > "libevdev is a wrapper library for evdev devices that provides interfaces 
> > > to
> > > create uinput devices and send events. libevdev is less error-prone than
> > > accessing uinput directly and should be considered for new software".
> > 
> > Much better. Fixed.
> > 
> > > 
> > > > +
> > > > +For examples and more information about libevdev:
> > > > +https://cgit.freedesktop.org/libevdev
> > > > +
> > > 
> > > Please use https://www.freedesktop.org/software/libevdev/doc/latest/
> > > (which needs a link to the git repo, I'll fix that in a minute)
> > 
> > Fixed.
> > 
> > > 
> > > > +Examples
> > > > +
> > > > +
> > > > +1.0 Keyboard events
> > > > +---
> > > > +
> > > > +This first example shows how to create a new virtual device and how to 
> > > > send a
> > > > +key event. All default imports and error handlers were removed for the 
> > > > sake of
> > > > +simplicity.
> > > > +
> > > > +.. code-block:: c
> > > > +
> > > > +   #include 
> > > > +
> > > > +   int fd;
> > > > +
> > > > +   void emit(int type, int code, int val)
> > > > +   {
> > > > +struct input_event ie;
> > > > +
> > > > +ie.type = type;
> > > > +ie.code = code;
> > > > +ie.value = val;
> > > > +/* below timestamp values are ignored */
> > > > +ie.time.tv_sec = 0;
> > > > +ie.time.tv_usec = 0;
> > > > +
> > > > +write(fd, , sizeof(ie));
> > > > +   }
> > > > +
> > > > +   int main() {
> > > > +struct uinput_setup usetup;
> > > > +
> > > > +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> > > > +
> > > > +/* the ioctls below enables the to be created device to key
> > > > + * events, in this case the space key
> > > > + **/
> > > 
> > > the comment terminator doesn't look right
> > 
> > Fixed.
> > 
> > > 
> > > > +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> > > > +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> > > > +
> > > > +memset(, 0, sizeof(usetup));
> > > > +usetup.id.bustype = BUS_USB;
> > > > +usetup.id.vendor = 0x1234; /* sample vendor */
> > > 
> > > add a sample product id too please
> > Added.
> > 
> > > 
> > > > +strcpy(usetup.name, "Example device");
> > > > +
> > > > +ioctl(fd, UI_DEV_SETUP, );
> > > > +ioctl(fd, UI_DEV_CREATE);
> > > > +
> > > > +/* UI_DEV_CREATE causes the kernel to create the device nodes 
> > > > for this
> > > 
> > > "On UI_DEV_CREATE the kernel creates the device nodes..."
> > Fixed.
> > 
> > > 
> > > > + * device. Insert a pause so that userspace has time to detect,
> > > > + * initialize the new device, and can start to listen to 
> > > > events from
> > > > + * this device
> > > > + **/
> > > 
> > > the comment terminator doesn't look right
> > > 
> > > note: the actual 

Re: [PATCH] staging: media: atomisp: compress return logic

[kbuild test robot]

Hi Arushi,

[auto build test ERROR on next-20170323]
[cannot apply to linuxtv-media/master v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc4]
[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/Arushi-Singhal/staging-media-atomisp-compress-return-logic/20170327-030611
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c: 
In function 'ia_css_bufq_dequeue_isys_event':
>> drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c:467:18:
>>  error: unused variable 'return_err' [-Werror=unused-variable]
 enum ia_css_err return_err;
 ^~
   cc1: all warnings being treated as errors

vim +/return_err +467 
drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c

a49d2536 Alan Cox 2017-02-17  461  }
a49d2536 Alan Cox 2017-02-17  462  
a49d2536 Alan Cox 2017-02-17  463  enum  ia_css_err 
ia_css_bufq_dequeue_isys_event(
a49d2536 Alan Cox 2017-02-17  464   uint8_t item[BUFQ_EVENT_SIZE])
a49d2536 Alan Cox 2017-02-17  465  {
a49d2536 Alan Cox 2017-02-17  466  #if !defined(HAS_NO_INPUT_SYSTEM)
a49d2536 Alan Cox 2017-02-17 @467   enum ia_css_err return_err;
a49d2536 Alan Cox 2017-02-17  468   int error = 0;
a49d2536 Alan Cox 2017-02-17  469   ia_css_queue_t *q;
a49d2536 Alan Cox 2017-02-17  470  

:: The code at line 467 was first introduced by commit
:: a49d25364dfb9f8a64037488a39ab1f56c5fa419 staging/atomisp: Add support 
for the Intel IPU v2

:: TO: Alan Cox 
:: CC: Greg Kroah-Hartman 

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


.config.gz
Description: application/gzip

Re: [PATCH] staging: media: atomisp: compress return logic

[kbuild test robot]

Hi Arushi,

[auto build test ERROR on next-20170323]
[cannot apply to linuxtv-media/master v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc4]
[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/Arushi-Singhal/staging-media-atomisp-compress-return-logic/20170327-030611
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c: 
In function 'ia_css_bufq_dequeue_isys_event':
>> drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c:467:18:
>>  error: unused variable 'return_err' [-Werror=unused-variable]
 enum ia_css_err return_err;
 ^~
   cc1: all warnings being treated as errors

vim +/return_err +467 
drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c

a49d2536 Alan Cox 2017-02-17  461  }
a49d2536 Alan Cox 2017-02-17  462  
a49d2536 Alan Cox 2017-02-17  463  enum  ia_css_err 
ia_css_bufq_dequeue_isys_event(
a49d2536 Alan Cox 2017-02-17  464   uint8_t item[BUFQ_EVENT_SIZE])
a49d2536 Alan Cox 2017-02-17  465  {
a49d2536 Alan Cox 2017-02-17  466  #if !defined(HAS_NO_INPUT_SYSTEM)
a49d2536 Alan Cox 2017-02-17 @467   enum ia_css_err return_err;
a49d2536 Alan Cox 2017-02-17  468   int error = 0;
a49d2536 Alan Cox 2017-02-17  469   ia_css_queue_t *q;
a49d2536 Alan Cox 2017-02-17  470  

:: The code at line 467 was first introduced by commit
:: a49d25364dfb9f8a64037488a39ab1f56c5fa419 staging/atomisp: Add support 
for the Intel IPU v2

:: TO: Alan Cox 
:: CC: Greg Kroah-Hartman 

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


.config.gz
Description: application/gzip