[PATCH 4.9 015/130] perf trace: Use the syscall raw_syscalls:sys_enter timestamp

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnaldo Carvalho de Melo 

commit ecf1e2253ea79c6204f4d6a5e756e8fb4aed5a7e upstream.

Instead of the one when another syscall takes place while another is being
processed (in another CPU, but we show it serialized, so need to "interrupt"
the other), and also when finally showing the sys_enter + sys_exit + duration,
where we were showing the sample->time for the sys_exit, duh.

Before:

  # perf trace sleep 1
  
 0.373 (   0.001 ms): close(fd: 3   ) = 0
  1000.626 (1000.211 ms): nanosleep(rqtp: 0x7ffd6fb0) = 0
  1000.653 (   0.003 ms): close(fd: 1   ) = 0
  1000.657 (   0.002 ms): close(fd: 2   ) = 0
  1000.667 (   0.000 ms): exit_group(   )
  #

After:

  # perf trace sleep 1
  
 0.336 (   0.001 ms): close(fd: 3   ) = 0
 0.373 (1000.086 ms): nanosleep(rqtp: 0x7ffe303e9550) = 0
  1000.481 (   0.002 ms): close(fd: 1   ) = 0
  1000.485 (   0.001 ms): close(fd: 2   ) = 0
  1000.494 (   0.000 ms): exit_group(   )
[root@jouet linux]#

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ecbzgmu2ni6glc6zkw8p1...@git.kernel.org
Fixes: 752fde44fd1c ("perf trace: Support interrupted syscalls")
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/builtin-trace.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1452,7 +1452,7 @@ static int trace__printf_interrupted_ent
 
duration = sample->time - ttrace->entry_time;
 
-   printed  = trace__fprintf_entry_head(trace, trace->current, duration, 
sample->time, trace->output);
+   printed  = trace__fprintf_entry_head(trace, trace->current, duration, 
ttrace->entry_time, trace->output);
printed += fprintf(trace->output, "%-70s) ...\n", ttrace->entry_str);
ttrace->entry_pending = false;
 
@@ -1499,7 +1499,7 @@ static int trace__sys_enter(struct trace
 
if (sc->is_exit) {
if (!(trace->duration_filter || trace->summary_only || 
trace->min_stack)) {
-   trace__fprintf_entry_head(trace, thread, 1, 
sample->time, trace->output);
+   trace__fprintf_entry_head(trace, thread, 1, 
ttrace->entry_time, trace->output);
fprintf(trace->output, "%-70s)\n", ttrace->entry_str);
}
} else {
@@ -1592,7 +1592,7 @@ static int trace__sys_exit(struct trace
if (trace->summary_only)
goto out;
 
-   trace__fprintf_entry_head(trace, thread, duration, sample->time, 
trace->output);
+   trace__fprintf_entry_head(trace, thread, duration, ttrace->entry_time, 
trace->output);
 
if (ttrace->entry_pending) {
fprintf(trace->output, "%-70s", ttrace->entry_str);

[PATCH 4.9 015/130] perf trace: Use the syscall raw_syscalls:sys_enter timestamp

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnaldo Carvalho de Melo 

commit ecf1e2253ea79c6204f4d6a5e756e8fb4aed5a7e upstream.

Instead of the one when another syscall takes place while another is being
processed (in another CPU, but we show it serialized, so need to "interrupt"
the other), and also when finally showing the sys_enter + sys_exit + duration,
where we were showing the sample->time for the sys_exit, duh.

Before:

  # perf trace sleep 1
  
 0.373 (   0.001 ms): close(fd: 3   ) = 0
  1000.626 (1000.211 ms): nanosleep(rqtp: 0x7ffd6fb0) = 0
  1000.653 (   0.003 ms): close(fd: 1   ) = 0
  1000.657 (   0.002 ms): close(fd: 2   ) = 0
  1000.667 (   0.000 ms): exit_group(   )
  #

After:

  # perf trace sleep 1
  
 0.336 (   0.001 ms): close(fd: 3   ) = 0
 0.373 (1000.086 ms): nanosleep(rqtp: 0x7ffe303e9550) = 0
  1000.481 (   0.002 ms): close(fd: 1   ) = 0
  1000.485 (   0.001 ms): close(fd: 2   ) = 0
  1000.494 (   0.000 ms): exit_group(   )
[root@jouet linux]#

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ecbzgmu2ni6glc6zkw8p1...@git.kernel.org
Fixes: 752fde44fd1c ("perf trace: Support interrupted syscalls")
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/builtin-trace.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1452,7 +1452,7 @@ static int trace__printf_interrupted_ent
 
duration = sample->time - ttrace->entry_time;
 
-   printed  = trace__fprintf_entry_head(trace, trace->current, duration, 
sample->time, trace->output);
+   printed  = trace__fprintf_entry_head(trace, trace->current, duration, 
ttrace->entry_time, trace->output);
printed += fprintf(trace->output, "%-70s) ...\n", ttrace->entry_str);
ttrace->entry_pending = false;
 
@@ -1499,7 +1499,7 @@ static int trace__sys_enter(struct trace
 
if (sc->is_exit) {
if (!(trace->duration_filter || trace->summary_only || 
trace->min_stack)) {
-   trace__fprintf_entry_head(trace, thread, 1, 
sample->time, trace->output);
+   trace__fprintf_entry_head(trace, thread, 1, 
ttrace->entry_time, trace->output);
fprintf(trace->output, "%-70s)\n", ttrace->entry_str);
}
} else {
@@ -1592,7 +1592,7 @@ static int trace__sys_exit(struct trace
if (trace->summary_only)
goto out;
 
-   trace__fprintf_entry_head(trace, thread, duration, sample->time, 
trace->output);
+   trace__fprintf_entry_head(trace, thread, duration, ttrace->entry_time, 
trace->output);
 
if (ttrace->entry_pending) {
fprintf(trace->output, "%-70s", ttrace->entry_str);

[PATCH 4.4 36/42] ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit f0e8faa7a5e894b0fc99d24be1b18685a92ea466 upstream.

This function clearly never worked and always returns true,
as pointed out by gcc-7:

arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi':
arch/arm/mach-ux500/pm.c:137:212: error: ?:
using integer constants in boolean context, the expression
will always evaluate to 'true' [-Werror=int-in-bool-context]

With the added braces, the condition actually makes sense.

Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI")
Signed-off-by: Arnd Bergmann 
Acked-by: Daniel Lezcano 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mach-ux500/pm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/mach-ux500/pm.c
+++ b/arch/arm/mach-ux500/pm.c
@@ -134,8 +134,8 @@ bool prcmu_pending_irq(void)
  */
 bool prcmu_is_cpu_in_wfi(int cpu)
 {
-   return readl(PRCM_ARM_WFI_STANDBY) & cpu ? PRCM_ARM_WFI_STANDBY_WFI1 :
-PRCM_ARM_WFI_STANDBY_WFI0;
+   return readl(PRCM_ARM_WFI_STANDBY) &
+   (cpu ? PRCM_ARM_WFI_STANDBY_WFI1 : PRCM_ARM_WFI_STANDBY_WFI0);
 }
 
 /*

[PATCH 4.4 36/42] ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit f0e8faa7a5e894b0fc99d24be1b18685a92ea466 upstream.

This function clearly never worked and always returns true,
as pointed out by gcc-7:

arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi':
arch/arm/mach-ux500/pm.c:137:212: error: ?:
using integer constants in boolean context, the expression
will always evaluate to 'true' [-Werror=int-in-bool-context]

With the added braces, the condition actually makes sense.

Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI")
Signed-off-by: Arnd Bergmann 
Acked-by: Daniel Lezcano 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mach-ux500/pm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/mach-ux500/pm.c
+++ b/arch/arm/mach-ux500/pm.c
@@ -134,8 +134,8 @@ bool prcmu_pending_irq(void)
  */
 bool prcmu_is_cpu_in_wfi(int cpu)
 {
-   return readl(PRCM_ARM_WFI_STANDBY) & cpu ? PRCM_ARM_WFI_STANDBY_WFI1 :
-PRCM_ARM_WFI_STANDBY_WFI0;
+   return readl(PRCM_ARM_WFI_STANDBY) &
+   (cpu ? PRCM_ARM_WFI_STANDBY_WFI1 : PRCM_ARM_WFI_STANDBY_WFI0);
 }
 
 /*

[PATCH 4.4 41/42] selftest/powerpc: Wrong PMC initialized in pmc56_overflow test

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Madhavan Srinivasan 

commit df21d2fa733035e4d414379960f94b2516b41296 upstream.

Test uses PMC2 to count the event. But PMC1 is being initialized.
Patch to fix it.

Fixes: 3752e453f6ba ('selftests/powerpc: Add tests of PMU EBBs')
Signed-off-by: Madhavan Srinivasan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
@@ -66,7 +66,7 @@ int pmc56_overflow(void)
 
FAIL_IF(ebb_event_enable());
 
-   mtspr(SPRN_PMC1, pmc_sample_period(sample_period));
+   mtspr(SPRN_PMC2, pmc_sample_period(sample_period));
mtspr(SPRN_PMC5, 0);
mtspr(SPRN_PMC6, 0);
 

[PATCH 4.9 001/130] IB/core: Release allocated memory in cache setup failure

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Leon Romanovsky 

commit aa6aae38f7fb2c030f326a6dd10b58fff1851dfa upstream.

The failure in ib_cache_setup_one function during
ib_register_device will leave leaked allocated memory.

Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management")
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/core/cache.c |   16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

--- a/drivers/infiniband/core/cache.c
+++ b/drivers/infiniband/core/cache.c
@@ -770,12 +770,8 @@ static int _gid_table_setup_one(struct i
int err = 0;
 
table = kcalloc(ib_dev->phys_port_cnt, sizeof(*table), GFP_KERNEL);
-
-   if (!table) {
-   pr_warn("failed to allocate ib gid cache for %s\n",
-   ib_dev->name);
+   if (!table)
return -ENOMEM;
-   }
 
for (port = 0; port < ib_dev->phys_port_cnt; port++) {
u8 rdma_port = port + rdma_start_port(ib_dev);
@@ -1170,14 +1166,13 @@ int ib_cache_setup_one(struct ib_device
  GFP_KERNEL);
if (!device->cache.pkey_cache ||
!device->cache.lmc_cache) {
-   pr_warn("Couldn't allocate cache for %s\n", device->name);
-   return -ENOMEM;
+   err = -ENOMEM;
+   goto free;
}
 
err = gid_table_setup_one(device);
if (err)
-   /* Allocated memory will be cleaned in the release function */
-   return err;
+   goto free;
 
for (p = 0; p <= rdma_end_port(device) - rdma_start_port(device); ++p)
ib_cache_update(device, p + rdma_start_port(device));
@@ -1192,6 +1187,9 @@ int ib_cache_setup_one(struct ib_device
 
 err:
gid_table_cleanup_one(device);
+free:
+   kfree(device->cache.pkey_cache);
+   kfree(device->cache.lmc_cache);
return err;
 }
 

[PATCH 4.9 011/130] IB/mlx4: Fix port query for 56Gb Ethernet links

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Saeed Mahameed 

commit 6fa26208206c406fa529cd73f7ae6bf4181e270b upstream.

Report the correct speed in the port attributes when using a 56Gbps
ethernet link.  Without this change the field is incorrectly set to 10.

Fixes: a9c766bb75ee ('IB/mlx4: Fix info returned when querying IBoE ports')
Fixes: 2e96691c31ec ('IB: Use central enum for speed instead of hard-coded 
values')
Signed-off-by: Saeed Mahameed 
Signed-off-by: Yishai Hadas 
Signed-off-by: Daniel Jurgens 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/main.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -697,9 +697,11 @@ static int eth_link_query_port(struct ib
if (err)
goto out;
 
-   props->active_width =  (((u8 *)mailbox->buf)[5] == 0x40) ?
-   IB_WIDTH_4X : IB_WIDTH_1X;
-   props->active_speed = IB_SPEED_QDR;
+   props->active_width =  (((u8 *)mailbox->buf)[5] == 0x40) ||
+  (((u8 *)mailbox->buf)[5] == 0x20 /*56Gb*/) ?
+  IB_WIDTH_4X : IB_WIDTH_1X;
+   props->active_speed =  (((u8 *)mailbox->buf)[5] == 0x20 /*56Gb*/) ?
+  IB_SPEED_FDR : IB_SPEED_QDR;
props->port_cap_flags   = IB_PORT_CM_SUP | IB_PORT_IP_BASED_GIDS;
props->gid_tbl_len  = mdev->dev->caps.gid_table_len[port];
props->max_msg_sz   = mdev->dev->caps.max_msg_sz;

[PATCH 4.4 33/42] arm64/ptrace: Avoid uninitialised struct padding in fpr_set()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Martin 

commit aeb1f39d814b2e21e5e5706a48834bfd553d0059 upstream.

This patch adds an explicit __reserved[] field to user_fpsimd_state
to replace what was previously unnamed padding.

This ensures that data in this region are propagated across
assignment rather than being left possibly uninitialised at the
destination.

Fixes: 60ffc30d5652 ("arm64: Exception handling")
Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/include/uapi/asm/ptrace.h |1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -76,6 +76,7 @@ struct user_fpsimd_state {
__uint128_t vregs[32];
__u32   fpsr;
__u32   fpcr;
+   __u32   __reserved[2];
 };
 
 struct user_hwdebug_state {

[PATCH 4.9 010/130] IB/mlx4: Handle well-known-gid in mad_demux processing

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jack Morgenstein 

commit befcabcd530e4ffb6f016638f693b7d94986d2ba upstream.

If OpenSM runs over a ConnectX-3, and there are ConnectX-4 or Connect-IB
VFs active on the network, the OpenSM will receive QP1 packets containing
a GRH where the destination GID is the "Well-Known GID" -- which is not a
GID in the HCA Port's GID Table.

This GID must be tested-for separately -- and packets which contain
this destination GID should be routed to slave 0 (the PF).

Fixes: 37bfc7c1e83f ('IB/mlx4: SR-IOV multiplex and demultiplex MADs')
Signed-off-by: Jack Morgenstein 
Signed-off-by: Daniel Jurgens 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/mad.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw/mlx4/mad.c
@@ -702,10 +702,18 @@ static int mlx4_ib_demux_mad(struct ib_d
 
/* If a grh is present, we demux according to it */
if (wc->wc_flags & IB_WC_GRH) {
-   slave = mlx4_ib_find_real_gid(ibdev, port, 
grh->dgid.global.interface_id);
-   if (slave < 0) {
-   mlx4_ib_warn(ibdev, "failed matching grh\n");
-   return -ENOENT;
+   if (grh->dgid.global.interface_id ==
+   cpu_to_be64(IB_SA_WELL_KNOWN_GUID) &&
+   grh->dgid.global.subnet_prefix == cpu_to_be64(
+   atomic64_read(>sriov.demux[port - 
1].subnet_prefix))) {
+   slave = 0;
+   } else {
+   slave = mlx4_ib_find_real_gid(ibdev, port,
+ 
grh->dgid.global.interface_id);
+   if (slave < 0) {
+   mlx4_ib_warn(ibdev, "failed matching grh\n");
+   return -ENOENT;
+   }
}
}
/* Class-specific handling */

[PATCH 4.9 011/130] IB/mlx4: Fix port query for 56Gb Ethernet links

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Saeed Mahameed 

commit 6fa26208206c406fa529cd73f7ae6bf4181e270b upstream.

Report the correct speed in the port attributes when using a 56Gbps
ethernet link.  Without this change the field is incorrectly set to 10.

Fixes: a9c766bb75ee ('IB/mlx4: Fix info returned when querying IBoE ports')
Fixes: 2e96691c31ec ('IB: Use central enum for speed instead of hard-coded 
values')
Signed-off-by: Saeed Mahameed 
Signed-off-by: Yishai Hadas 
Signed-off-by: Daniel Jurgens 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/main.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -697,9 +697,11 @@ static int eth_link_query_port(struct ib
if (err)
goto out;
 
-   props->active_width =  (((u8 *)mailbox->buf)[5] == 0x40) ?
-   IB_WIDTH_4X : IB_WIDTH_1X;
-   props->active_speed = IB_SPEED_QDR;
+   props->active_width =  (((u8 *)mailbox->buf)[5] == 0x40) ||
+  (((u8 *)mailbox->buf)[5] == 0x20 /*56Gb*/) ?
+  IB_WIDTH_4X : IB_WIDTH_1X;
+   props->active_speed =  (((u8 *)mailbox->buf)[5] == 0x20 /*56Gb*/) ?
+  IB_SPEED_FDR : IB_SPEED_QDR;
props->port_cap_flags   = IB_PORT_CM_SUP | IB_PORT_IP_BASED_GIDS;
props->gid_tbl_len  = mdev->dev->caps.gid_table_len[port];
props->max_msg_sz   = mdev->dev->caps.max_msg_sz;

[PATCH 4.4 33/42] arm64/ptrace: Avoid uninitialised struct padding in fpr_set()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Martin 

commit aeb1f39d814b2e21e5e5706a48834bfd553d0059 upstream.

This patch adds an explicit __reserved[] field to user_fpsimd_state
to replace what was previously unnamed padding.

This ensures that data in this region are propagated across
assignment rather than being left possibly uninitialised at the
destination.

Fixes: 60ffc30d5652 ("arm64: Exception handling")
Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/include/uapi/asm/ptrace.h |1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -76,6 +76,7 @@ struct user_fpsimd_state {
__uint128_t vregs[32];
__u32   fpsr;
__u32   fpcr;
+   __u32   __reserved[2];
 };
 
 struct user_hwdebug_state {

[PATCH 4.9 010/130] IB/mlx4: Handle well-known-gid in mad_demux processing

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jack Morgenstein 

commit befcabcd530e4ffb6f016638f693b7d94986d2ba upstream.

If OpenSM runs over a ConnectX-3, and there are ConnectX-4 or Connect-IB
VFs active on the network, the OpenSM will receive QP1 packets containing
a GRH where the destination GID is the "Well-Known GID" -- which is not a
GID in the HCA Port's GID Table.

This GID must be tested-for separately -- and packets which contain
this destination GID should be routed to slave 0 (the PF).

Fixes: 37bfc7c1e83f ('IB/mlx4: SR-IOV multiplex and demultiplex MADs')
Signed-off-by: Jack Morgenstein 
Signed-off-by: Daniel Jurgens 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/mad.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw/mlx4/mad.c
@@ -702,10 +702,18 @@ static int mlx4_ib_demux_mad(struct ib_d
 
/* If a grh is present, we demux according to it */
if (wc->wc_flags & IB_WC_GRH) {
-   slave = mlx4_ib_find_real_gid(ibdev, port, 
grh->dgid.global.interface_id);
-   if (slave < 0) {
-   mlx4_ib_warn(ibdev, "failed matching grh\n");
-   return -ENOENT;
+   if (grh->dgid.global.interface_id ==
+   cpu_to_be64(IB_SA_WELL_KNOWN_GUID) &&
+   grh->dgid.global.subnet_prefix == cpu_to_be64(
+   atomic64_read(>sriov.demux[port - 
1].subnet_prefix))) {
+   slave = 0;
+   } else {
+   slave = mlx4_ib_find_real_gid(ibdev, port,
+ 
grh->dgid.global.interface_id);
+   if (slave < 0) {
+   mlx4_ib_warn(ibdev, "failed matching grh\n");
+   return -ENOENT;
+   }
}
}
/* Class-specific handling */

[PATCH 4.4 41/42] selftest/powerpc: Wrong PMC initialized in pmc56_overflow test

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Madhavan Srinivasan 

commit df21d2fa733035e4d414379960f94b2516b41296 upstream.

Test uses PMC2 to count the event. But PMC1 is being initialized.
Patch to fix it.

Fixes: 3752e453f6ba ('selftests/powerpc: Add tests of PMU EBBs')
Signed-off-by: Madhavan Srinivasan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
@@ -66,7 +66,7 @@ int pmc56_overflow(void)
 
FAIL_IF(ebb_event_enable());
 
-   mtspr(SPRN_PMC1, pmc_sample_period(sample_period));
+   mtspr(SPRN_PMC2, pmc_sample_period(sample_period));
mtspr(SPRN_PMC5, 0);
mtspr(SPRN_PMC6, 0);
 

[PATCH 4.9 001/130] IB/core: Release allocated memory in cache setup failure

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Leon Romanovsky 

commit aa6aae38f7fb2c030f326a6dd10b58fff1851dfa upstream.

The failure in ib_cache_setup_one function during
ib_register_device will leave leaked allocated memory.

Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management")
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/core/cache.c |   16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

--- a/drivers/infiniband/core/cache.c
+++ b/drivers/infiniband/core/cache.c
@@ -770,12 +770,8 @@ static int _gid_table_setup_one(struct i
int err = 0;
 
table = kcalloc(ib_dev->phys_port_cnt, sizeof(*table), GFP_KERNEL);
-
-   if (!table) {
-   pr_warn("failed to allocate ib gid cache for %s\n",
-   ib_dev->name);
+   if (!table)
return -ENOMEM;
-   }
 
for (port = 0; port < ib_dev->phys_port_cnt; port++) {
u8 rdma_port = port + rdma_start_port(ib_dev);
@@ -1170,14 +1166,13 @@ int ib_cache_setup_one(struct ib_device
  GFP_KERNEL);
if (!device->cache.pkey_cache ||
!device->cache.lmc_cache) {
-   pr_warn("Couldn't allocate cache for %s\n", device->name);
-   return -ENOMEM;
+   err = -ENOMEM;
+   goto free;
}
 
err = gid_table_setup_one(device);
if (err)
-   /* Allocated memory will be cleaned in the release function */
-   return err;
+   goto free;
 
for (p = 0; p <= rdma_end_port(device) - rdma_start_port(device); ++p)
ib_cache_update(device, p + rdma_start_port(device));
@@ -1192,6 +1187,9 @@ int ib_cache_setup_one(struct ib_device
 
 err:
gid_table_cleanup_one(device);
+free:
+   kfree(device->cache.pkey_cache);
+   kfree(device->cache.lmc_cache);
return err;
 }
 

[PATCH 4.4 39/42] [media] ite-cir: initialize use_demodulator before using it

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolas Iooss 

commit 7ec03e60ef81c19b5d3a46dd070ee966774b860f upstream.

Function ite_set_carrier_params() uses variable use_demodulator after
having initialized it to false in some if branches, but this variable is
never set to true otherwise.

This bug has been found using clang -Wsometimes-uninitialized warning
flag.

Fixes: 620a32bba4a2 ("[media] rc: New rc-based ite-cir driver for
several ITE CIRs")

Signed-off-by: Nicolas Iooss 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/rc/ite-cir.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -263,6 +263,8 @@ static void ite_set_carrier_params(struc
 
if (allowance > ITE_RXDCR_MAX)
allowance = ITE_RXDCR_MAX;
+
+   use_demodulator = true;
}
}
 

[PATCH 4.9 017/130] perf trace: Check if MAP_32BIT is defined (again)

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit 2bd42f3aaa53ebe78b9be6f898b7945dd61f9773 upstream.

There might be systems where MAP_32BIT is not defined, like some some
RHEL7 powerpc versions.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Kyle McMartin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Fixes: 256763b01741 ("perf trace beauty mmap: Add more conditional defines")
Link: 
http://lkml.kernel.org/r/1481831814-23683-1-git-send-email-jo...@kernel.org
[ Changed the Fixme cset to the one removing the conditional switch case for 
MAP_32BIT ]
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/trace/beauty/mmap.c |2 ++
 1 file changed, 2 insertions(+)

--- a/tools/perf/trace/beauty/mmap.c
+++ b/tools/perf/trace/beauty/mmap.c
@@ -42,7 +42,9 @@ static size_t syscall_arg__scnprintf_mma
 
P_MMAP_FLAG(SHARED);
P_MMAP_FLAG(PRIVATE);
+#ifdef MAP_32BIT
P_MMAP_FLAG(32BIT);
+#endif
P_MMAP_FLAG(ANONYMOUS);
P_MMAP_FLAG(DENYWRITE);
P_MMAP_FLAG(EXECUTABLE);

[PATCH 4.9 012/130] IB/mlx4: When no DMFS for IPoIB, dont allow NET_IF QPs

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Eran Ben Elisha 

commit 1f22e454df2eb99ba6b7ace3f594f6805cdf5cbc upstream.

According to the firmware spec, FLOW_STEERING_IB_UC_QP_RANGE command is
supported only if dmfs_ipoib bit is set.

If it isn't set we want to ensure allocating NET_IF QPs fail. We do so
by filling out the allocation bitmap. By thus, the NET_IF QPs allocating
function won't find any free QP and will fail.

Fixes: c1c98501121e ('IB/mlx4: Add support for steerable IB UD QPs')
Signed-off-by: Eran Ben Elisha 
Signed-off-by: Daniel Jurgens 
Reviewed-by: Mark Bloch 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/main.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2822,14 +2822,19 @@ static void *mlx4_ib_add(struct mlx4_dev
goto err_steer_qp_release;
}
 
-   bitmap_zero(ibdev->ib_uc_qpns_bitmap, ibdev->steer_qpn_count);
-
-   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
-   dev, ibdev->steer_qpn_base,
-   ibdev->steer_qpn_base +
-   ibdev->steer_qpn_count - 1);
-   if (err)
-   goto err_steer_free_bitmap;
+   if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_DMFS_IPOIB) {
+   bitmap_zero(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
+   dev, ibdev->steer_qpn_base,
+   ibdev->steer_qpn_base +
+   ibdev->steer_qpn_count - 1);
+   if (err)
+   goto err_steer_free_bitmap;
+   } else {
+   bitmap_fill(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   }
}
 
for (j = 1; j <= ibdev->dev->caps.num_ports; j++)

[PATCH 4.4 39/42] [media] ite-cir: initialize use_demodulator before using it

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolas Iooss 

commit 7ec03e60ef81c19b5d3a46dd070ee966774b860f upstream.

Function ite_set_carrier_params() uses variable use_demodulator after
having initialized it to false in some if branches, but this variable is
never set to true otherwise.

This bug has been found using clang -Wsometimes-uninitialized warning
flag.

Fixes: 620a32bba4a2 ("[media] rc: New rc-based ite-cir driver for
several ITE CIRs")

Signed-off-by: Nicolas Iooss 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/rc/ite-cir.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -263,6 +263,8 @@ static void ite_set_carrier_params(struc
 
if (allowance > ITE_RXDCR_MAX)
allowance = ITE_RXDCR_MAX;
+
+   use_demodulator = true;
}
}
 

[PATCH 4.9 017/130] perf trace: Check if MAP_32BIT is defined (again)

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit 2bd42f3aaa53ebe78b9be6f898b7945dd61f9773 upstream.

There might be systems where MAP_32BIT is not defined, like some some
RHEL7 powerpc versions.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Kyle McMartin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Fixes: 256763b01741 ("perf trace beauty mmap: Add more conditional defines")
Link: 
http://lkml.kernel.org/r/1481831814-23683-1-git-send-email-jo...@kernel.org
[ Changed the Fixme cset to the one removing the conditional switch case for 
MAP_32BIT ]
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/trace/beauty/mmap.c |2 ++
 1 file changed, 2 insertions(+)

--- a/tools/perf/trace/beauty/mmap.c
+++ b/tools/perf/trace/beauty/mmap.c
@@ -42,7 +42,9 @@ static size_t syscall_arg__scnprintf_mma
 
P_MMAP_FLAG(SHARED);
P_MMAP_FLAG(PRIVATE);
+#ifdef MAP_32BIT
P_MMAP_FLAG(32BIT);
+#endif
P_MMAP_FLAG(ANONYMOUS);
P_MMAP_FLAG(DENYWRITE);
P_MMAP_FLAG(EXECUTABLE);

[PATCH 4.9 012/130] IB/mlx4: When no DMFS for IPoIB, dont allow NET_IF QPs

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Eran Ben Elisha 

commit 1f22e454df2eb99ba6b7ace3f594f6805cdf5cbc upstream.

According to the firmware spec, FLOW_STEERING_IB_UC_QP_RANGE command is
supported only if dmfs_ipoib bit is set.

If it isn't set we want to ensure allocating NET_IF QPs fail. We do so
by filling out the allocation bitmap. By thus, the NET_IF QPs allocating
function won't find any free QP and will fail.

Fixes: c1c98501121e ('IB/mlx4: Add support for steerable IB UD QPs')
Signed-off-by: Eran Ben Elisha 
Signed-off-by: Daniel Jurgens 
Reviewed-by: Mark Bloch 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/main.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2822,14 +2822,19 @@ static void *mlx4_ib_add(struct mlx4_dev
goto err_steer_qp_release;
}
 
-   bitmap_zero(ibdev->ib_uc_qpns_bitmap, ibdev->steer_qpn_count);
-
-   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
-   dev, ibdev->steer_qpn_base,
-   ibdev->steer_qpn_base +
-   ibdev->steer_qpn_count - 1);
-   if (err)
-   goto err_steer_free_bitmap;
+   if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_DMFS_IPOIB) {
+   bitmap_zero(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
+   dev, ibdev->steer_qpn_base,
+   ibdev->steer_qpn_base +
+   ibdev->steer_qpn_count - 1);
+   if (err)
+   goto err_steer_free_bitmap;
+   } else {
+   bitmap_fill(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   }
}
 
for (j = 1; j <= ibdev->dev->caps.num_ports; j++)

[PATCH 4.4 06/42] IB/mlx4: When no DMFS for IPoIB, dont allow NET_IF QPs

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Eran Ben Elisha 

commit 1f22e454df2eb99ba6b7ace3f594f6805cdf5cbc upstream.

According to the firmware spec, FLOW_STEERING_IB_UC_QP_RANGE command is
supported only if dmfs_ipoib bit is set.

If it isn't set we want to ensure allocating NET_IF QPs fail. We do so
by filling out the allocation bitmap. By thus, the NET_IF QPs allocating
function won't find any free QP and will fail.

Fixes: c1c98501121e ('IB/mlx4: Add support for steerable IB UD QPs')
Signed-off-by: Eran Ben Elisha 
Signed-off-by: Daniel Jurgens 
Reviewed-by: Mark Bloch 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/main.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2403,14 +2403,19 @@ static void *mlx4_ib_add(struct mlx4_dev
goto err_steer_qp_release;
}
 
-   bitmap_zero(ibdev->ib_uc_qpns_bitmap, ibdev->steer_qpn_count);
-
-   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
-   dev, ibdev->steer_qpn_base,
-   ibdev->steer_qpn_base +
-   ibdev->steer_qpn_count - 1);
-   if (err)
-   goto err_steer_free_bitmap;
+   if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_DMFS_IPOIB) {
+   bitmap_zero(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
+   dev, ibdev->steer_qpn_base,
+   ibdev->steer_qpn_base +
+   ibdev->steer_qpn_count - 1);
+   if (err)
+   goto err_steer_free_bitmap;
+   } else {
+   bitmap_fill(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   }
}
 
for (j = 1; j <= ibdev->dev->caps.num_ports; j++)

[PATCH 4.4 04/42] IB/mlx4: Fix out-of-range array index in destroy qp flow

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jack Morgenstein 

commit c482af646d0809a8d5e1b7f4398cce3592589b98 upstream.

For non-special QPs, the port value becomes non-zero only at the
RESET-to-INIT transition. If the QP has not undergone that transition,
its port number value is still zero.

If such a QP is destroyed before being moved out of the RESET state,
subtracting one from the qp port number results in a negative value.
Using that negative value as an index into the qp1_proxy array
results in an out-of-bounds array reference.

Fix this by testing that the QP type is one that uses qp1_proxy before
using the port number. For special QPs of all types, the port number is
specified at QP creation time.

Fixes: 9433c188915c ("IB/mlx4: Invoke UPDATE_QP for proxy QP1 on MAC changes")
Signed-off-by: Jack Morgenstein 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/qp.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1207,7 +1207,8 @@ int mlx4_ib_destroy_qp(struct ib_qp *qp)
if (is_qp0(dev, mqp))
mlx4_CLOSE_PORT(dev->dev, mqp->port);
 
-   if (dev->qp1_proxy[mqp->port - 1] == mqp) {
+   if (mqp->mlx4_ib_qp_type == MLX4_IB_QPT_PROXY_GSI &&
+   dev->qp1_proxy[mqp->port - 1] == mqp) {
mutex_lock(>qp1_proxy_lock[mqp->port - 1]);
dev->qp1_proxy[mqp->port - 1] = NULL;
mutex_unlock(>qp1_proxy_lock[mqp->port - 1]);

[PATCH 4.4 06/42] IB/mlx4: When no DMFS for IPoIB, dont allow NET_IF QPs

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Eran Ben Elisha 

commit 1f22e454df2eb99ba6b7ace3f594f6805cdf5cbc upstream.

According to the firmware spec, FLOW_STEERING_IB_UC_QP_RANGE command is
supported only if dmfs_ipoib bit is set.

If it isn't set we want to ensure allocating NET_IF QPs fail. We do so
by filling out the allocation bitmap. By thus, the NET_IF QPs allocating
function won't find any free QP and will fail.

Fixes: c1c98501121e ('IB/mlx4: Add support for steerable IB UD QPs')
Signed-off-by: Eran Ben Elisha 
Signed-off-by: Daniel Jurgens 
Reviewed-by: Mark Bloch 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/main.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2403,14 +2403,19 @@ static void *mlx4_ib_add(struct mlx4_dev
goto err_steer_qp_release;
}
 
-   bitmap_zero(ibdev->ib_uc_qpns_bitmap, ibdev->steer_qpn_count);
-
-   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
-   dev, ibdev->steer_qpn_base,
-   ibdev->steer_qpn_base +
-   ibdev->steer_qpn_count - 1);
-   if (err)
-   goto err_steer_free_bitmap;
+   if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_DMFS_IPOIB) {
+   bitmap_zero(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   err = mlx4_FLOW_STEERING_IB_UC_QP_RANGE(
+   dev, ibdev->steer_qpn_base,
+   ibdev->steer_qpn_base +
+   ibdev->steer_qpn_count - 1);
+   if (err)
+   goto err_steer_free_bitmap;
+   } else {
+   bitmap_fill(ibdev->ib_uc_qpns_bitmap,
+   ibdev->steer_qpn_count);
+   }
}
 
for (j = 1; j <= ibdev->dev->caps.num_ports; j++)

[PATCH 4.4 04/42] IB/mlx4: Fix out-of-range array index in destroy qp flow

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jack Morgenstein 

commit c482af646d0809a8d5e1b7f4398cce3592589b98 upstream.

For non-special QPs, the port value becomes non-zero only at the
RESET-to-INIT transition. If the QP has not undergone that transition,
its port number value is still zero.

If such a QP is destroyed before being moved out of the RESET state,
subtracting one from the qp port number results in a negative value.
Using that negative value as an index into the qp1_proxy array
results in an out-of-bounds array reference.

Fix this by testing that the QP type is one that uses qp1_proxy before
using the port number. For special QPs of all types, the port number is
specified at QP creation time.

Fixes: 9433c188915c ("IB/mlx4: Invoke UPDATE_QP for proxy QP1 on MAC changes")
Signed-off-by: Jack Morgenstein 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx4/qp.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1207,7 +1207,8 @@ int mlx4_ib_destroy_qp(struct ib_qp *qp)
if (is_qp0(dev, mqp))
mlx4_CLOSE_PORT(dev->dev, mqp->port);
 
-   if (dev->qp1_proxy[mqp->port - 1] == mqp) {
+   if (mqp->mlx4_ib_qp_type == MLX4_IB_QPT_PROXY_GSI &&
+   dev->qp1_proxy[mqp->port - 1] == mqp) {
mutex_lock(>qp1_proxy_lock[mqp->port - 1]);
dev->qp1_proxy[mqp->port - 1] = NULL;
mutex_unlock(>qp1_proxy_lock[mqp->port - 1]);

[PATCH 4.4 07/42] IB/IPoIB: Remove cant use GFP_NOIO warning

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Kamal Heib 

commit 0b59970e7d96edcb3c7f651d9d48e1a59af3c3b0 upstream.

Remove the warning print of "can't use of GFP_NOIO" to avoid prints in
each QP creation when devices aren't supporting IB_QP_CREATE_USE_GFP_NOIO.

This print become more annoying when the IPoIB interface is configured
to work in connected mode.

Fixes: 09b93088d750 ('IB: Add a QP creation flag to use GFP_NOIO allocations')
Signed-off-by: Kamal Heib 
Signed-off-by: Leon Romanovsky 
Reviewed-by: Yuval Shaia 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/ulp/ipoib/ipoib_cm.c |2 --
 1 file changed, 2 deletions(-)

--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1035,8 +1035,6 @@ static struct ib_qp *ipoib_cm_create_tx_
 
tx_qp = ib_create_qp(priv->pd, );
if (PTR_ERR(tx_qp) == -EINVAL) {
-   ipoib_warn(priv, "can't use GFP_NOIO for QPs on device %s, 
using GFP_KERNEL\n",
-  priv->ca->name);
attr.create_flags &= ~IB_QP_CREATE_USE_GFP_NOIO;
tx_qp = ib_create_qp(priv->pd, );
}

[PATCH 4.4 07/42] IB/IPoIB: Remove cant use GFP_NOIO warning

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Kamal Heib 

commit 0b59970e7d96edcb3c7f651d9d48e1a59af3c3b0 upstream.

Remove the warning print of "can't use of GFP_NOIO" to avoid prints in
each QP creation when devices aren't supporting IB_QP_CREATE_USE_GFP_NOIO.

This print become more annoying when the IPoIB interface is configured
to work in connected mode.

Fixes: 09b93088d750 ('IB: Add a QP creation flag to use GFP_NOIO allocations')
Signed-off-by: Kamal Heib 
Signed-off-by: Leon Romanovsky 
Reviewed-by: Yuval Shaia 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/ulp/ipoib/ipoib_cm.c |2 --
 1 file changed, 2 deletions(-)

--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1035,8 +1035,6 @@ static struct ib_qp *ipoib_cm_create_tx_
 
tx_qp = ib_create_qp(priv->pd, );
if (PTR_ERR(tx_qp) == -EINVAL) {
-   ipoib_warn(priv, "can't use GFP_NOIO for QPs on device %s, 
using GFP_KERNEL\n",
-  priv->ca->name);
attr.create_flags &= ~IB_QP_CREATE_USE_GFP_NOIO;
tx_qp = ib_create_qp(priv->pd, );
}

[PATCH 4.4 26/42] svcrdma: avoid duplicate dma unmapping during error recovery

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Sriharsha Basavapatna 

commit ce1ca7d2d140a1f4aaffd297ac487f246963dd2f upstream.

In rdma_read_chunk_frmr() when ib_post_send() fails, the error code path
invokes ib_dma_unmap_sg() to unmap the sg list. It then invokes
svc_rdma_put_frmr() which in turn tries to unmap the same sg list through
ib_dma_unmap_sg() again. This second unmap is invalid and could lead to
problems when the iova being unmapped is subsequently reused. Remove
the call to unmap in rdma_read_chunk_frmr() and let svc_rdma_put_frmr()
handle it.

Fixes: 412a15c0fe53 ("svcrdma: Port to new memory registration API")
Signed-off-by: Sriharsha Basavapatna 
Reviewed-by: Chuck Lever 
Reviewed-by: Yuval Shaia 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman 

---
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c |2 --
 1 file changed, 2 deletions(-)

--- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
@@ -346,8 +346,6 @@ int rdma_read_chunk_frmr(struct svcxprt_
atomic_inc(_stat_read);
return ret;
  err:
-   ib_dma_unmap_sg(xprt->sc_cm_id->device,
-   frmr->sg, frmr->sg_nents, frmr->direction);
svc_rdma_put_context(ctxt, 0);
svc_rdma_put_frmr(xprt, frmr);
return ret;

[PATCH 4.4 30/42] arm64/ptrace: Preserve previous registers for short regset write

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Martin 

commit 9a17b876b573441bfb3387ad55d98bf7184daf9d upstream.

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Fixes: 478fcb2cdb23 ("arm64: Debugging support")
Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/ptrace.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -495,7 +495,7 @@ static int gpr_set(struct task_struct *t
   const void *kbuf, const void __user *ubuf)
 {
int ret;
-   struct user_pt_regs newregs;
+   struct user_pt_regs newregs = task_pt_regs(target)->user_regs;
 
ret = user_regset_copyin(, , , , , 0, -1);
if (ret)
@@ -525,7 +525,8 @@ static int fpr_set(struct task_struct *t
   const void *kbuf, const void __user *ubuf)
 {
int ret;
-   struct user_fpsimd_state newstate;
+   struct user_fpsimd_state newstate =
+   target->thread.fpsimd_state.user_fpsimd;
 
ret = user_regset_copyin(, , , , , 0, -1);
if (ret)
@@ -549,7 +550,7 @@ static int tls_set(struct task_struct *t
   const void *kbuf, const void __user *ubuf)
 {
int ret;
-   unsigned long tls;
+   unsigned long tls = target->thread.tp_value;
 
ret = user_regset_copyin(, , , , , 0, -1);
if (ret)

[PATCH 4.4 26/42] svcrdma: avoid duplicate dma unmapping during error recovery

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Sriharsha Basavapatna 

commit ce1ca7d2d140a1f4aaffd297ac487f246963dd2f upstream.

In rdma_read_chunk_frmr() when ib_post_send() fails, the error code path
invokes ib_dma_unmap_sg() to unmap the sg list. It then invokes
svc_rdma_put_frmr() which in turn tries to unmap the same sg list through
ib_dma_unmap_sg() again. This second unmap is invalid and could lead to
problems when the iova being unmapped is subsequently reused. Remove
the call to unmap in rdma_read_chunk_frmr() and let svc_rdma_put_frmr()
handle it.

Fixes: 412a15c0fe53 ("svcrdma: Port to new memory registration API")
Signed-off-by: Sriharsha Basavapatna 
Reviewed-by: Chuck Lever 
Reviewed-by: Yuval Shaia 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman 

---
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c |2 --
 1 file changed, 2 deletions(-)

--- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
@@ -346,8 +346,6 @@ int rdma_read_chunk_frmr(struct svcxprt_
atomic_inc(_stat_read);
return ret;
  err:
-   ib_dma_unmap_sg(xprt->sc_cm_id->device,
-   frmr->sg, frmr->sg_nents, frmr->direction);
svc_rdma_put_context(ctxt, 0);
svc_rdma_put_frmr(xprt, frmr);
return ret;

[PATCH 4.4 30/42] arm64/ptrace: Preserve previous registers for short regset write

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Martin 

commit 9a17b876b573441bfb3387ad55d98bf7184daf9d upstream.

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Fixes: 478fcb2cdb23 ("arm64: Debugging support")
Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/ptrace.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -495,7 +495,7 @@ static int gpr_set(struct task_struct *t
   const void *kbuf, const void __user *ubuf)
 {
int ret;
-   struct user_pt_regs newregs;
+   struct user_pt_regs newregs = task_pt_regs(target)->user_regs;
 
ret = user_regset_copyin(, , , , , 0, -1);
if (ret)
@@ -525,7 +525,8 @@ static int fpr_set(struct task_struct *t
   const void *kbuf, const void __user *ubuf)
 {
int ret;
-   struct user_fpsimd_state newstate;
+   struct user_fpsimd_state newstate =
+   target->thread.fpsimd_state.user_fpsimd;
 
ret = user_regset_copyin(, , , , , 0, -1);
if (ret)
@@ -549,7 +550,7 @@ static int tls_set(struct task_struct *t
   const void *kbuf, const void __user *ubuf)
 {
int ret;
-   unsigned long tls;
+   unsigned long tls = target->thread.tp_value;
 
ret = user_regset_copyin(, , , , , 0, -1);
if (ret)

[PATCH 4.4 20/42] ieee802154: atusb: do not use the stack for buffers to make them DMA able

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Schmidt 

commit 05a974efa4bdf6e2a150e3f27dc6fcf0a9ad5655 upstream.

>From 4.9 we should really avoid using the stack here as this will not be DMA
able on various platforms. This changes the buffers already being present in
time of 4.9 being released. This should go into stable as well.

Reported-by: Dan Carpenter 
Signed-off-by: Stefan Schmidt 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ieee802154/atusb.c |   31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -110,13 +110,26 @@ static int atusb_read_reg(struct atusb *
 {
struct usb_device *usb_dev = atusb->usb_dev;
int ret;
+   uint8_t *buffer;
uint8_t value;
 
+   buffer = kmalloc(1, GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
dev_dbg(_dev->dev, "atusb: reg = 0x%x\n", reg);
ret = atusb_control_msg(atusb, usb_rcvctrlpipe(usb_dev, 0),
ATUSB_REG_READ, ATUSB_REQ_FROM_DEV,
-   0, reg, , 1, 1000);
-   return ret >= 0 ? value : ret;
+   0, reg, buffer, 1, 1000);
+
+   if (ret >= 0) {
+   value = buffer[0];
+   kfree(buffer);
+   return value;
+   } else {
+   kfree(buffer);
+   return ret;
+   }
 }
 
 static int atusb_write_subreg(struct atusb *atusb, uint8_t reg, uint8_t mask,
@@ -517,9 +530,13 @@ static struct ieee802154_ops atusb_ops =
 static int atusb_get_and_show_revision(struct atusb *atusb)
 {
struct usb_device *usb_dev = atusb->usb_dev;
-   unsigned char buffer[3];
+   unsigned char *buffer;
int ret;
 
+   buffer = kmalloc(3, GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
/* Get a couple of the ATMega Firmware values */
ret = atusb_control_msg(atusb, usb_rcvctrlpipe(usb_dev, 0),
ATUSB_ID, ATUSB_REQ_FROM_DEV, 0, 0,
@@ -535,15 +552,20 @@ static int atusb_get_and_show_revision(s
dev_info(_dev->dev, "Please update to version 0.2 or 
newer");
}
 
+   kfree(buffer);
return ret;
 }
 
 static int atusb_get_and_show_build(struct atusb *atusb)
 {
struct usb_device *usb_dev = atusb->usb_dev;
-   char build[ATUSB_BUILD_SIZE + 1];
+   char *build;
int ret;
 
+   build = kmalloc(ATUSB_BUILD_SIZE + 1, GFP_KERNEL);
+   if (!build)
+   return -ENOMEM;
+
ret = atusb_control_msg(atusb, usb_rcvctrlpipe(usb_dev, 0),
ATUSB_BUILD, ATUSB_REQ_FROM_DEV, 0, 0,
build, ATUSB_BUILD_SIZE, 1000);
@@ -552,6 +574,7 @@ static int atusb_get_and_show_build(stru
dev_info(_dev->dev, "Firmware: build %s\n", build);
}
 
+   kfree(build);
return ret;
 }
 

[PATCH 4.4 18/42] HID: corsair: fix control-transfer error handling

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 7a546af50eb78ab99840903083231eb635c8a566 upstream.

Make sure to check for short control transfers in order to avoid parsing
uninitialised buffer data and leaking it to user space.

Note that the backlight and macro-mode buffer constraints are kept as
loose as possible in order to avoid any regressions should the current
buffer sizes be larger than necessary.

Fixes: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-corsair.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -159,7 +159,7 @@ static enum led_brightness k90_backlight
  USB_DIR_IN | USB_TYPE_VENDOR |
  USB_RECIP_DEVICE, 0, 0, data, 8,
  USB_CTRL_SET_TIMEOUT);
-   if (ret < 0) {
+   if (ret < 5) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
ret = -EIO;
@@ -274,7 +274,7 @@ static ssize_t k90_show_macro_mode(struc
  USB_DIR_IN | USB_TYPE_VENDOR |
  USB_RECIP_DEVICE, 0, 0, data, 2,
  USB_CTRL_SET_TIMEOUT);
-   if (ret < 0) {
+   if (ret < 1) {
dev_warn(dev, "Failed to get K90 initial mode (error %d).\n",
 ret);
ret = -EIO;
@@ -351,7 +351,7 @@ static ssize_t k90_show_current_profile(
  USB_DIR_IN | USB_TYPE_VENDOR |
  USB_RECIP_DEVICE, 0, 0, data, 8,
  USB_CTRL_SET_TIMEOUT);
-   if (ret < 0) {
+   if (ret < 8) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
ret = -EIO;

[PATCH 4.4 18/42] HID: corsair: fix control-transfer error handling

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 7a546af50eb78ab99840903083231eb635c8a566 upstream.

Make sure to check for short control transfers in order to avoid parsing
uninitialised buffer data and leaking it to user space.

Note that the backlight and macro-mode buffer constraints are kept as
loose as possible in order to avoid any regressions should the current
buffer sizes be larger than necessary.

Fixes: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-corsair.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -159,7 +159,7 @@ static enum led_brightness k90_backlight
  USB_DIR_IN | USB_TYPE_VENDOR |
  USB_RECIP_DEVICE, 0, 0, data, 8,
  USB_CTRL_SET_TIMEOUT);
-   if (ret < 0) {
+   if (ret < 5) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
ret = -EIO;
@@ -274,7 +274,7 @@ static ssize_t k90_show_macro_mode(struc
  USB_DIR_IN | USB_TYPE_VENDOR |
  USB_RECIP_DEVICE, 0, 0, data, 2,
  USB_CTRL_SET_TIMEOUT);
-   if (ret < 0) {
+   if (ret < 1) {
dev_warn(dev, "Failed to get K90 initial mode (error %d).\n",
 ret);
ret = -EIO;
@@ -351,7 +351,7 @@ static ssize_t k90_show_current_profile(
  USB_DIR_IN | USB_TYPE_VENDOR |
  USB_RECIP_DEVICE, 0, 0, data, 8,
  USB_CTRL_SET_TIMEOUT);
-   if (ret < 0) {
+   if (ret < 8) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
ret = -EIO;

[PATCH 4.4 20/42] ieee802154: atusb: do not use the stack for buffers to make them DMA able

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Schmidt 

commit 05a974efa4bdf6e2a150e3f27dc6fcf0a9ad5655 upstream.

>From 4.9 we should really avoid using the stack here as this will not be DMA
able on various platforms. This changes the buffers already being present in
time of 4.9 being released. This should go into stable as well.

Reported-by: Dan Carpenter 
Signed-off-by: Stefan Schmidt 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ieee802154/atusb.c |   31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -110,13 +110,26 @@ static int atusb_read_reg(struct atusb *
 {
struct usb_device *usb_dev = atusb->usb_dev;
int ret;
+   uint8_t *buffer;
uint8_t value;
 
+   buffer = kmalloc(1, GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
dev_dbg(_dev->dev, "atusb: reg = 0x%x\n", reg);
ret = atusb_control_msg(atusb, usb_rcvctrlpipe(usb_dev, 0),
ATUSB_REG_READ, ATUSB_REQ_FROM_DEV,
-   0, reg, , 1, 1000);
-   return ret >= 0 ? value : ret;
+   0, reg, buffer, 1, 1000);
+
+   if (ret >= 0) {
+   value = buffer[0];
+   kfree(buffer);
+   return value;
+   } else {
+   kfree(buffer);
+   return ret;
+   }
 }
 
 static int atusb_write_subreg(struct atusb *atusb, uint8_t reg, uint8_t mask,
@@ -517,9 +530,13 @@ static struct ieee802154_ops atusb_ops =
 static int atusb_get_and_show_revision(struct atusb *atusb)
 {
struct usb_device *usb_dev = atusb->usb_dev;
-   unsigned char buffer[3];
+   unsigned char *buffer;
int ret;
 
+   buffer = kmalloc(3, GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
/* Get a couple of the ATMega Firmware values */
ret = atusb_control_msg(atusb, usb_rcvctrlpipe(usb_dev, 0),
ATUSB_ID, ATUSB_REQ_FROM_DEV, 0, 0,
@@ -535,15 +552,20 @@ static int atusb_get_and_show_revision(s
dev_info(_dev->dev, "Please update to version 0.2 or 
newer");
}
 
+   kfree(buffer);
return ret;
 }
 
 static int atusb_get_and_show_build(struct atusb *atusb)
 {
struct usb_device *usb_dev = atusb->usb_dev;
-   char build[ATUSB_BUILD_SIZE + 1];
+   char *build;
int ret;
 
+   build = kmalloc(ATUSB_BUILD_SIZE + 1, GFP_KERNEL);
+   if (!build)
+   return -ENOMEM;
+
ret = atusb_control_msg(atusb, usb_rcvctrlpipe(usb_dev, 0),
ATUSB_BUILD, ATUSB_REQ_FROM_DEV, 0, 0,
build, ATUSB_BUILD_SIZE, 1000);
@@ -552,6 +574,7 @@ static int atusb_get_and_show_build(stru
dev_info(_dev->dev, "Firmware: build %s\n", build);
}
 
+   kfree(build);
return ret;
 }
 

[PATCH 4.4 12/42] tmpfs: clear S_ISGID when setting posix ACLs

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Gu Zheng 

commit 497de07d89c1410d76a15bec2bb41f24a2a89f31 upstream.

This change was missed the tmpfs modification in In CVE-2016-7097
commit 073931017b49 ("posix_acl: Clear SGID bit when setting
file permissions")
It can test by xfstest generic/375, which failed to clear
setgid bit in the following test case on tmpfs:

  touch $testfile
  chown 100:100 $testfile
  chmod 2755 $testfile
  _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile

Signed-off-by: Gu Zheng 
Signed-off-by: Al Viro 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/posix_acl.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -903,11 +903,10 @@ int simple_set_acl(struct inode *inode,
int error;
 
if (type == ACL_TYPE_ACCESS) {
-   error = posix_acl_equiv_mode(acl, >i_mode);
-   if (error < 0)
-   return 0;
-   if (error == 0)
-   acl = NULL;
+   error = posix_acl_update_mode(inode,
+   >i_mode, );
+   if (error)
+   return error;
}
 
inode->i_ctime = CURRENT_TIME;

[PATCH 4.4 01/42] ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Steven Rostedt 

commit 8329e818f14926a6040df86b2668568bde342ebf upstream.

Matt Fleming reported seeing crashes when enabling and disabling
function profiling which uses function graph tracer. Later Namhyung Kim
hit a similar issue and he found that the issue was due to the jmp to
ftrace_stub in ftrace_graph_call was only two bytes, and when it was
changed to jump to the tracing code, it overwrote the ftrace_stub that
was after it.

Masami Hiramatsu bisected this down to a binutils change:

8dcea93252a9ea7dff57e85220a719e2a5e8ab41 is the first bad commit
commit 8dcea93252a9ea7dff57e85220a719e2a5e8ab41
Author: H.J. Lu 
Date:   Fri May 15 03:17:31 2015 -0700

Add -mshared option to x86 ELF assembler

This patch adds -mshared option to x86 ELF assembler.  By default,
assembler will optimize out non-PLT relocations against defined non-weak
global branch targets with default visibility.  The -mshared option tells
the assembler to generate code which may go into a shared library
where all non-weak global branch targets with default visibility can
be preempted.  The resulting code is slightly bigger.  This option
only affects the handling of branch instructions.

Declaring ftrace_stub as a weak call prevents gas from using two byte
jumps to it, which would be converted to a jump to the function graph
code.

Link: http://lkml.kernel.org/r/20160516230035.1dbae...@gandalf.local.home

Reported-by: Matt Fleming 
Reported-by: Namhyung Kim 
Tested-by: Matt Fleming 
Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/mcount_64.S |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -180,7 +180,8 @@ GLOBAL(ftrace_graph_call)
jmp ftrace_stub
 #endif
 
-GLOBAL(ftrace_stub)
+/* This is weak to keep gas from relaxing the jumps */
+WEAK(ftrace_stub)
retq
 END(ftrace_caller)
 

[PATCH 4.4 12/42] tmpfs: clear S_ISGID when setting posix ACLs

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Gu Zheng 

commit 497de07d89c1410d76a15bec2bb41f24a2a89f31 upstream.

This change was missed the tmpfs modification in In CVE-2016-7097
commit 073931017b49 ("posix_acl: Clear SGID bit when setting
file permissions")
It can test by xfstest generic/375, which failed to clear
setgid bit in the following test case on tmpfs:

  touch $testfile
  chown 100:100 $testfile
  chmod 2755 $testfile
  _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile

Signed-off-by: Gu Zheng 
Signed-off-by: Al Viro 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/posix_acl.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -903,11 +903,10 @@ int simple_set_acl(struct inode *inode,
int error;
 
if (type == ACL_TYPE_ACCESS) {
-   error = posix_acl_equiv_mode(acl, >i_mode);
-   if (error < 0)
-   return 0;
-   if (error == 0)
-   acl = NULL;
+   error = posix_acl_update_mode(inode,
+   >i_mode, );
+   if (error)
+   return error;
}
 
inode->i_ctime = CURRENT_TIME;

[PATCH 4.4 01/42] ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Steven Rostedt 

commit 8329e818f14926a6040df86b2668568bde342ebf upstream.

Matt Fleming reported seeing crashes when enabling and disabling
function profiling which uses function graph tracer. Later Namhyung Kim
hit a similar issue and he found that the issue was due to the jmp to
ftrace_stub in ftrace_graph_call was only two bytes, and when it was
changed to jump to the tracing code, it overwrote the ftrace_stub that
was after it.

Masami Hiramatsu bisected this down to a binutils change:

8dcea93252a9ea7dff57e85220a719e2a5e8ab41 is the first bad commit
commit 8dcea93252a9ea7dff57e85220a719e2a5e8ab41
Author: H.J. Lu 
Date:   Fri May 15 03:17:31 2015 -0700

Add -mshared option to x86 ELF assembler

This patch adds -mshared option to x86 ELF assembler.  By default,
assembler will optimize out non-PLT relocations against defined non-weak
global branch targets with default visibility.  The -mshared option tells
the assembler to generate code which may go into a shared library
where all non-weak global branch targets with default visibility can
be preempted.  The resulting code is slightly bigger.  This option
only affects the handling of branch instructions.

Declaring ftrace_stub as a weak call prevents gas from using two byte
jumps to it, which would be converted to a jump to the function graph
code.

Link: http://lkml.kernel.org/r/20160516230035.1dbae...@gandalf.local.home

Reported-by: Matt Fleming 
Reported-by: Namhyung Kim 
Tested-by: Matt Fleming 
Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/mcount_64.S |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -180,7 +180,8 @@ GLOBAL(ftrace_graph_call)
jmp ftrace_stub
 #endif
 
-GLOBAL(ftrace_stub)
+/* This is weak to keep gas from relaxing the jumps */
+WEAK(ftrace_stub)
retq
 END(ftrace_caller)
 

[PATCH 4.4 13/42] x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Helgaas 

commit 89e9f7bcd8744ea25fcf0ac671b8d72c10d7d790 upstream.

Martin reported that the Supermicro X8DTH-i/6/iF/6F advertises incorrect
host bridge windows via _CRS:

  pci_root PNP0A08:00: host bridge window [io  0xf000-0x]
  pci_root PNP0A08:01: host bridge window [io  0xf000-0x]

Both bridges advertise the 0xf000-0x window, which cannot be correct.

Work around this by ignoring _CRS on this system.  The downside is that we
may not assign resources correctly to hot-added PCI devices (if they are
possible on this system).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42606
Reported-by: Martin Burnicki 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/pci/acpi.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -114,6 +114,16 @@ static const struct dmi_system_id pci_cr
DMI_MATCH(DMI_BIOS_VERSION, "6JET85WW (1.43 )"),
},
},
+   /* https://bugzilla.kernel.org/show_bug.cgi?id=42606 */
+   {
+   .callback = set_nouse_crs,
+   .ident = "Supermicro X8DTH",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Supermicro"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X8DTH-i/6/iF/6F"),
+   DMI_MATCH(DMI_BIOS_VERSION, "2.0a"),
+   },
+   },
 
/* https://bugzilla.kernel.org/show_bug.cgi?id=15362 */
{

[PATCH 4.4 11/42] ARM: dts: imx31: fix AVIC base address

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Vladimir Zapolskiy 

commit af92305e567b7f4c9cf48b9e46c1f48ec9ffb1fb upstream.

On i.MX31 AVIC interrupt controller base address is at 0x6800.

The problem was shadowed by the AVIC driver, which takes the correct
base address from a SoC specific header file.

Fixes: d2a37b3d91f4 ("ARM i.MX31: Add devicetree support")
Signed-off-by: Vladimir Zapolskiy 
Reviewed-by: Fabio Estevam 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/imx31.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -30,11 +30,11 @@
};
};
 
-   avic: avic-interrupt-controller@6000 {
+   avic: interrupt-controller@6800 {
compatible = "fsl,imx31-avic", "fsl,avic";
interrupt-controller;
#interrupt-cells = <1>;
-   reg = <0x6000 0x10>;
+   reg = <0x6800 0x10>;
};
 
soc {

[PATCH 4.4 17/42] HID: corsair: fix DMA buffers on stack

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 6d104af38b570d37aa32a5803b04c354f8ed513d upstream.

Not all platforms support DMA to the stack, and specifically since v4.9
this is no longer supported on x86 with VMAP_STACK either.

Note that the macro-mode buffer was larger than necessary.

Fixes: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-corsair.c |   54 +++---
 1 file changed, 42 insertions(+), 12 deletions(-)

--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -148,7 +148,11 @@ static enum led_brightness k90_backlight
struct usb_interface *usbif = to_usb_interface(dev->parent);
struct usb_device *usbdev = interface_to_usbdev(usbif);
int brightness;
-   char data[8];
+   char *data;
+
+   data = kmalloc(8, GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
 
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
  K90_REQUEST_STATUS,
@@ -158,16 +162,22 @@ static enum led_brightness k90_backlight
if (ret < 0) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
brightness = data[4];
if (brightness < 0 || brightness > 3) {
dev_warn(dev,
 "Read invalid backlight brightness: %02hhx.\n",
 data[4]);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
-   return brightness;
+   ret = brightness;
+out:
+   kfree(data);
+
+   return ret;
 }
 
 static enum led_brightness k90_record_led_get(struct led_classdev *led_cdev)
@@ -253,7 +263,11 @@ static ssize_t k90_show_macro_mode(struc
struct usb_interface *usbif = to_usb_interface(dev->parent);
struct usb_device *usbdev = interface_to_usbdev(usbif);
const char *macro_mode;
-   char data[8];
+   char *data;
+
+   data = kmalloc(2, GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
 
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
  K90_REQUEST_GET_MODE,
@@ -263,7 +277,8 @@ static ssize_t k90_show_macro_mode(struc
if (ret < 0) {
dev_warn(dev, "Failed to get K90 initial mode (error %d).\n",
 ret);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
switch (data[0]) {
@@ -277,10 +292,15 @@ static ssize_t k90_show_macro_mode(struc
default:
dev_warn(dev, "K90 in unknown mode: %02hhx.\n",
 data[0]);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", macro_mode);
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", macro_mode);
+out:
+   kfree(data);
+
+   return ret;
 }
 
 static ssize_t k90_store_macro_mode(struct device *dev,
@@ -320,7 +340,11 @@ static ssize_t k90_show_current_profile(
struct usb_interface *usbif = to_usb_interface(dev->parent);
struct usb_device *usbdev = interface_to_usbdev(usbif);
int current_profile;
-   char data[8];
+   char *data;
+
+   data = kmalloc(8, GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
 
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
  K90_REQUEST_STATUS,
@@ -330,16 +354,22 @@ static ssize_t k90_show_current_profile(
if (ret < 0) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
current_profile = data[7];
if (current_profile < 1 || current_profile > 3) {
dev_warn(dev, "Read invalid current profile: %02hhx.\n",
 data[7]);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
-   return snprintf(buf, PAGE_SIZE, "%d\n", current_profile);
+   ret = snprintf(buf, PAGE_SIZE, "%d\n", current_profile);
+out:
+   kfree(data);
+
+   return ret;
 }
 
 static ssize_t k90_store_current_profile(struct device *dev,

[PATCH 4.4 13/42] x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Helgaas 

commit 89e9f7bcd8744ea25fcf0ac671b8d72c10d7d790 upstream.

Martin reported that the Supermicro X8DTH-i/6/iF/6F advertises incorrect
host bridge windows via _CRS:

  pci_root PNP0A08:00: host bridge window [io  0xf000-0x]
  pci_root PNP0A08:01: host bridge window [io  0xf000-0x]

Both bridges advertise the 0xf000-0x window, which cannot be correct.

Work around this by ignoring _CRS on this system.  The downside is that we
may not assign resources correctly to hot-added PCI devices (if they are
possible on this system).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42606
Reported-by: Martin Burnicki 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/pci/acpi.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -114,6 +114,16 @@ static const struct dmi_system_id pci_cr
DMI_MATCH(DMI_BIOS_VERSION, "6JET85WW (1.43 )"),
},
},
+   /* https://bugzilla.kernel.org/show_bug.cgi?id=42606 */
+   {
+   .callback = set_nouse_crs,
+   .ident = "Supermicro X8DTH",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Supermicro"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X8DTH-i/6/iF/6F"),
+   DMI_MATCH(DMI_BIOS_VERSION, "2.0a"),
+   },
+   },
 
/* https://bugzilla.kernel.org/show_bug.cgi?id=15362 */
{

[PATCH 4.4 11/42] ARM: dts: imx31: fix AVIC base address

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Vladimir Zapolskiy 

commit af92305e567b7f4c9cf48b9e46c1f48ec9ffb1fb upstream.

On i.MX31 AVIC interrupt controller base address is at 0x6800.

The problem was shadowed by the AVIC driver, which takes the correct
base address from a SoC specific header file.

Fixes: d2a37b3d91f4 ("ARM i.MX31: Add devicetree support")
Signed-off-by: Vladimir Zapolskiy 
Reviewed-by: Fabio Estevam 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/imx31.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -30,11 +30,11 @@
};
};
 
-   avic: avic-interrupt-controller@6000 {
+   avic: interrupt-controller@6800 {
compatible = "fsl,imx31-avic", "fsl,avic";
interrupt-controller;
#interrupt-cells = <1>;
-   reg = <0x6000 0x10>;
+   reg = <0x6800 0x10>;
};
 
soc {

[PATCH 4.4 17/42] HID: corsair: fix DMA buffers on stack

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 6d104af38b570d37aa32a5803b04c354f8ed513d upstream.

Not all platforms support DMA to the stack, and specifically since v4.9
this is no longer supported on x86 with VMAP_STACK either.

Note that the macro-mode buffer was larger than necessary.

Fixes: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-corsair.c |   54 +++---
 1 file changed, 42 insertions(+), 12 deletions(-)

--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -148,7 +148,11 @@ static enum led_brightness k90_backlight
struct usb_interface *usbif = to_usb_interface(dev->parent);
struct usb_device *usbdev = interface_to_usbdev(usbif);
int brightness;
-   char data[8];
+   char *data;
+
+   data = kmalloc(8, GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
 
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
  K90_REQUEST_STATUS,
@@ -158,16 +162,22 @@ static enum led_brightness k90_backlight
if (ret < 0) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
brightness = data[4];
if (brightness < 0 || brightness > 3) {
dev_warn(dev,
 "Read invalid backlight brightness: %02hhx.\n",
 data[4]);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
-   return brightness;
+   ret = brightness;
+out:
+   kfree(data);
+
+   return ret;
 }
 
 static enum led_brightness k90_record_led_get(struct led_classdev *led_cdev)
@@ -253,7 +263,11 @@ static ssize_t k90_show_macro_mode(struc
struct usb_interface *usbif = to_usb_interface(dev->parent);
struct usb_device *usbdev = interface_to_usbdev(usbif);
const char *macro_mode;
-   char data[8];
+   char *data;
+
+   data = kmalloc(2, GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
 
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
  K90_REQUEST_GET_MODE,
@@ -263,7 +277,8 @@ static ssize_t k90_show_macro_mode(struc
if (ret < 0) {
dev_warn(dev, "Failed to get K90 initial mode (error %d).\n",
 ret);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
switch (data[0]) {
@@ -277,10 +292,15 @@ static ssize_t k90_show_macro_mode(struc
default:
dev_warn(dev, "K90 in unknown mode: %02hhx.\n",
 data[0]);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", macro_mode);
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", macro_mode);
+out:
+   kfree(data);
+
+   return ret;
 }
 
 static ssize_t k90_store_macro_mode(struct device *dev,
@@ -320,7 +340,11 @@ static ssize_t k90_show_current_profile(
struct usb_interface *usbif = to_usb_interface(dev->parent);
struct usb_device *usbdev = interface_to_usbdev(usbif);
int current_profile;
-   char data[8];
+   char *data;
+
+   data = kmalloc(8, GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
 
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
  K90_REQUEST_STATUS,
@@ -330,16 +354,22 @@ static ssize_t k90_show_current_profile(
if (ret < 0) {
dev_warn(dev, "Failed to get K90 initial state (error %d).\n",
 ret);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
current_profile = data[7];
if (current_profile < 1 || current_profile > 3) {
dev_warn(dev, "Read invalid current profile: %02hhx.\n",
 data[7]);
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
-   return snprintf(buf, PAGE_SIZE, "%d\n", current_profile);
+   ret = snprintf(buf, PAGE_SIZE, "%d\n", current_profile);
+out:
+   kfree(data);
+
+   return ret;
 }
 
 static ssize_t k90_store_current_profile(struct device *dev,

Re: [PATCH] i2c: Fix error print when address is invalid

[Wolfram Sang]

On Mon, Jan 23, 2017 at 06:24:24PM -0800, Stephen Boyd wrote:
> When the address is invalid, we print out the address that's
> in info.addr, but that member of info hasn't been assigned yet.
> It's assigned in the line after we check the address. This causes
> the print to show something like
> 
>  i2c i2c-1: of_i2c: invalid addr=0 on ...
> 
> when we want something like
> 
>  i2c i2c-1: of_i2c: invalid addr=0xaf on ...
> 
> Just pass addr here, and update the print format to indicate hex
> as well.
> 
> Signed-off-by: Stephen Boyd 

Thanks, yet already fixed since v4.10-rc4 with 6f724fb3039522 ("i2c:
print correct device invalid address").



signature.asc
Description: PGP signature

Re: [PATCH] i2c: Fix error print when address is invalid

[Wolfram Sang]

On Mon, Jan 23, 2017 at 06:24:24PM -0800, Stephen Boyd wrote:
> When the address is invalid, we print out the address that's
> in info.addr, but that member of info hasn't been assigned yet.
> It's assigned in the line after we check the address. This causes
> the print to show something like
> 
>  i2c i2c-1: of_i2c: invalid addr=0 on ...
> 
> when we want something like
> 
>  i2c i2c-1: of_i2c: invalid addr=0xaf on ...
> 
> Just pass addr here, and update the print format to indicate hex
> as well.
> 
> Signed-off-by: Stephen Boyd 

Thanks, yet already fixed since v4.10-rc4 with 6f724fb3039522 ("i2c:
print correct device invalid address").



signature.asc
Description: PGP signature

[PATCH] netfilter: nf_ct_helper: warn when not applying default helper assignment (was Re: [RFC PATCH 0/2] restore original default of nf_conntrack_helper sysctl)

[Jiri Kosina]

On Mon, 23 Jan 2017, Linus Torvalds wrote:

> For all I know, there may be some security reason why we really don't
> want the automatic helpers, even if they can be convenient.
> 
> Also, you can just enable them with a kernel command line or a sysctl,
> so it's not like you can't get the old behavior back.

Yeah, the only concern really is causing instant breakage of existing 
firewall configurations just by upgrading the kernel.

On Tue, 24 Jan 2017, Pablo Neira Ayuso wrote:

> Yes, with helper modules in place, this is known to allow attackers to
> push holes in your firewall.  Eric Leblond actually show that it's
> perfectly feasible to exploit this via handcrafted packets [1]. The
> problem is documented here [2].
> 
> > Also, you can just enable them with a kernel command line or a sysctl,
> > so it's not like you can't get the old behavior back.
> 
> Right.
> 
> [1] https://cansecwest.com/csw12/conntrack-attack.pdf
> [2] https://home.regit.org/netfilter-en/secure-use-of-helpers/

Alright, that's a valid reason.

Still, I'd like us to be as helpful as possible when we really have no 
other choice than breaking existing userspace setup.

So how about issuing a warning in case we'd normally perform the automatic 
helper assignment, but we actually don't due to the new default setting? 
The fact that we've had the 'deprecated' warning there since 3.5 is nice, 
but let's face it -- that's not where the poor guy would be debugging why 
his firewall doesn't work. It'd be the kernel with the new default, and 
that doesn't give any hints whatsoever.



From: Jiri Kosina 
Subject: [PATCH] netfilter: nf_ct_helper: warn when not applying default helper 
assignment

Commit 3bb398d925 ("netfilter: nf_ct_helper: disable automatic helper 
assignment") is causing behavior regressions in firewalls, as traffic 
handled by conntrack helpers is now by default not passed through even 
though it was before due to missing CT targets (which were not necessary 
before this commit).

The default had to be switched off due to security reasons [1] [2] and
therefore should stay the way it is, but let's be friendly to firewall
admins and issue a warning the first time we're in situation where packet
would be likely passed through with the old default but we're likely going
to drop it on the floor now.

Re-use the 'net->ct.auto_assign_helper_warned' flag, as it'd be sufficient 
to warn one way or the other.

[1] https://cansecwest.com/csw12/conntrack-attack.pdf
[2] https://home.regit.org/netfilter-en/secure-use-of-helpers/

Signed-off-by: Jiri Kosina 
---
 net/netfilter/nf_conntrack_helper.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conntrack_helper.c 
b/net/netfilter/nf_conntrack_helper.c
index 7341adf..02a26b0 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/net/netfilter/nf_conntrack_helper.c
@@ -213,17 +213,28 @@ int __nf_ct_try_assign_helper(struct nf_conn *ct, struct 
nf_conn *tmpl,
}
 
help = nfct_help(ct);
-   if (net->ct.sysctl_auto_assign_helper && helper == NULL) {
-   helper = 
__nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple);
-   if (unlikely(!net->ct.auto_assign_helper_warned && helper)) {
+   if (!helper)
+   {
+   if (__nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple) 
&&
+   !net->ct.sysctl_auto_assign_helper &&
+   !net->ct.auto_assign_helper_warned) {
+   pr_info("nf_conntrack: default automatic helper 
assignment "
+   "has been turned off for security reasons "
+   "and CT-based firewall rule not found. Use the "
+   "iptables CT target to attach helpers 
instead.\n");
+   net->ct.auto_assign_helper_warned = true;
+   } else {
+   helper = 
__nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple);
+   if (unlikely(!net->ct.auto_assign_helper_warned && 
helper &&
+   !net->ct.auto_assign_helper_warned)) {
pr_info("nf_conntrack: automatic helper "
"assignment is deprecated and it will "
"be removed soon. Use the iptables CT target "
"to attach helpers instead.\n");
net->ct.auto_assign_helper_warned = true;
+   }
}
}
-
if (helper == NULL) {
if (help)
RCU_INIT_POINTER(help->helper, NULL);

-- 
Jiri Kosina
SUSE Labs

[PATCH] netfilter: nf_ct_helper: warn when not applying default helper assignment (was Re: [RFC PATCH 0/2] restore original default of nf_conntrack_helper sysctl)

[Jiri Kosina]

On Mon, 23 Jan 2017, Linus Torvalds wrote:

> For all I know, there may be some security reason why we really don't
> want the automatic helpers, even if they can be convenient.
> 
> Also, you can just enable them with a kernel command line or a sysctl,
> so it's not like you can't get the old behavior back.

Yeah, the only concern really is causing instant breakage of existing 
firewall configurations just by upgrading the kernel.

On Tue, 24 Jan 2017, Pablo Neira Ayuso wrote:

> Yes, with helper modules in place, this is known to allow attackers to
> push holes in your firewall.  Eric Leblond actually show that it's
> perfectly feasible to exploit this via handcrafted packets [1]. The
> problem is documented here [2].
> 
> > Also, you can just enable them with a kernel command line or a sysctl,
> > so it's not like you can't get the old behavior back.
> 
> Right.
> 
> [1] https://cansecwest.com/csw12/conntrack-attack.pdf
> [2] https://home.regit.org/netfilter-en/secure-use-of-helpers/

Alright, that's a valid reason.

Still, I'd like us to be as helpful as possible when we really have no 
other choice than breaking existing userspace setup.

So how about issuing a warning in case we'd normally perform the automatic 
helper assignment, but we actually don't due to the new default setting? 
The fact that we've had the 'deprecated' warning there since 3.5 is nice, 
but let's face it -- that's not where the poor guy would be debugging why 
his firewall doesn't work. It'd be the kernel with the new default, and 
that doesn't give any hints whatsoever.



From: Jiri Kosina 
Subject: [PATCH] netfilter: nf_ct_helper: warn when not applying default helper 
assignment

Commit 3bb398d925 ("netfilter: nf_ct_helper: disable automatic helper 
assignment") is causing behavior regressions in firewalls, as traffic 
handled by conntrack helpers is now by default not passed through even 
though it was before due to missing CT targets (which were not necessary 
before this commit).

The default had to be switched off due to security reasons [1] [2] and
therefore should stay the way it is, but let's be friendly to firewall
admins and issue a warning the first time we're in situation where packet
would be likely passed through with the old default but we're likely going
to drop it on the floor now.

Re-use the 'net->ct.auto_assign_helper_warned' flag, as it'd be sufficient 
to warn one way or the other.

[1] https://cansecwest.com/csw12/conntrack-attack.pdf
[2] https://home.regit.org/netfilter-en/secure-use-of-helpers/

Signed-off-by: Jiri Kosina 
---
 net/netfilter/nf_conntrack_helper.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conntrack_helper.c 
b/net/netfilter/nf_conntrack_helper.c
index 7341adf..02a26b0 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/net/netfilter/nf_conntrack_helper.c
@@ -213,17 +213,28 @@ int __nf_ct_try_assign_helper(struct nf_conn *ct, struct 
nf_conn *tmpl,
}
 
help = nfct_help(ct);
-   if (net->ct.sysctl_auto_assign_helper && helper == NULL) {
-   helper = 
__nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple);
-   if (unlikely(!net->ct.auto_assign_helper_warned && helper)) {
+   if (!helper)
+   {
+   if (__nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple) 
&&
+   !net->ct.sysctl_auto_assign_helper &&
+   !net->ct.auto_assign_helper_warned) {
+   pr_info("nf_conntrack: default automatic helper 
assignment "
+   "has been turned off for security reasons "
+   "and CT-based firewall rule not found. Use the "
+   "iptables CT target to attach helpers 
instead.\n");
+   net->ct.auto_assign_helper_warned = true;
+   } else {
+   helper = 
__nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple);
+   if (unlikely(!net->ct.auto_assign_helper_warned && 
helper &&
+   !net->ct.auto_assign_helper_warned)) {
pr_info("nf_conntrack: automatic helper "
"assignment is deprecated and it will "
"be removed soon. Use the iptables CT target "
"to attach helpers instead.\n");
net->ct.auto_assign_helper_warned = true;
+   }
}
}
-
if (helper == NULL) {
if (help)
RCU_INIT_POINTER(help->helper, NULL);

-- 
Jiri Kosina
SUSE Labs

[PATCH RFC 1/3] mm/hugetlb: split alloc_fresh_huge_page_node into fast and slow path

[Jia He]

This patch split alloc_fresh_huge_page_node into 2 parts:
- fast path without __GFP_REPEAT flag
- slow path with __GFP_REPEAT flag

Thus, if there is a server with uneven numa memory layout:
available: 7 nodes (0-6)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 6603 MB
node 0 free: 91 MB
node 1 cpus:
node 1 size: 12527 MB
node 1 free: 157 MB
node 2 cpus:
node 2 size: 15087 MB
node 2 free: 189 MB
node 3 cpus:
node 3 size: 16111 MB
node 3 free: 205 MB
node 4 cpus: 8 9 10 11 12 13 14 15
node 4 size: 24815 MB
node 4 free: 310 MB
node 5 cpus:
node 5 size: 4095 MB
node 5 free: 61 MB
node 6 cpus:
node 6 size: 22750 MB
node 6 free: 283 MB
node distances:
node   0   1   2   3   4   5   6
  0:  10  20  40  40  40  40  40
  1:  20  10  40  40  40  40  40
  2:  40  40  10  20  40  40  40
  3:  40  40  20  10  40  40  40
  4:  40  40  40  40  10  20  40
  5:  40  40  40  40  20  10  40
  6:  40  40  40  40  40  40  10

In this case node 5 has less memory and we will alloc the hugepages
from these nodes one by one.
After this patch, we will not trigger too early direct memory/kswap
reclaim for node 5 if there are enough memory in other nodes.

Signed-off-by: Jia He 
---
 mm/hugetlb.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c7025c1..f2415ce 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1364,10 +1364,19 @@ static struct page *alloc_fresh_huge_page_node(struct 
hstate *h, int nid)
 {
struct page *page;
 
+   /* fast path without __GFP_REPEAT */
page = __alloc_pages_node(nid,
htlb_alloc_mask(h)|__GFP_COMP|__GFP_THISNODE|
__GFP_REPEAT|__GFP_NOWARN,
huge_page_order(h));
+
+   /* slow path with __GFP_REPEAT*/
+   if (!page)
+   page = __alloc_pages_node(nid,
+   htlb_alloc_mask(h)|__GFP_COMP|__GFP_THISNODE|
+   __GFP_NOWARN,
+   huge_page_order(h));
+
if (page) {
prep_new_huge_page(h, page, nid);
}
-- 
2.5.5

[PATCH RFC 1/3] mm/hugetlb: split alloc_fresh_huge_page_node into fast and slow path

[Jia He]

This patch split alloc_fresh_huge_page_node into 2 parts:
- fast path without __GFP_REPEAT flag
- slow path with __GFP_REPEAT flag

Thus, if there is a server with uneven numa memory layout:
available: 7 nodes (0-6)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 6603 MB
node 0 free: 91 MB
node 1 cpus:
node 1 size: 12527 MB
node 1 free: 157 MB
node 2 cpus:
node 2 size: 15087 MB
node 2 free: 189 MB
node 3 cpus:
node 3 size: 16111 MB
node 3 free: 205 MB
node 4 cpus: 8 9 10 11 12 13 14 15
node 4 size: 24815 MB
node 4 free: 310 MB
node 5 cpus:
node 5 size: 4095 MB
node 5 free: 61 MB
node 6 cpus:
node 6 size: 22750 MB
node 6 free: 283 MB
node distances:
node   0   1   2   3   4   5   6
  0:  10  20  40  40  40  40  40
  1:  20  10  40  40  40  40  40
  2:  40  40  10  20  40  40  40
  3:  40  40  20  10  40  40  40
  4:  40  40  40  40  10  20  40
  5:  40  40  40  40  20  10  40
  6:  40  40  40  40  40  40  10

In this case node 5 has less memory and we will alloc the hugepages
from these nodes one by one.
After this patch, we will not trigger too early direct memory/kswap
reclaim for node 5 if there are enough memory in other nodes.

Signed-off-by: Jia He 
---
 mm/hugetlb.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c7025c1..f2415ce 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1364,10 +1364,19 @@ static struct page *alloc_fresh_huge_page_node(struct 
hstate *h, int nid)
 {
struct page *page;
 
+   /* fast path without __GFP_REPEAT */
page = __alloc_pages_node(nid,
htlb_alloc_mask(h)|__GFP_COMP|__GFP_THISNODE|
__GFP_REPEAT|__GFP_NOWARN,
huge_page_order(h));
+
+   /* slow path with __GFP_REPEAT*/
+   if (!page)
+   page = __alloc_pages_node(nid,
+   htlb_alloc_mask(h)|__GFP_COMP|__GFP_THISNODE|
+   __GFP_NOWARN,
+   huge_page_order(h));
+
if (page) {
prep_new_huge_page(h, page, nid);
}
-- 
2.5.5

[PATCH RFC 2/3] mm, vmscan: limit kswapd loop if no progress is made

[Jia He]

Currently there is no hard limitation for kswapd retry times if no progress
is made. Then kswapd will take 100% for a long time.

In my test, I tried to allocate 4000 hugepages by:
echo 4000 > /proc/sys/vm/nr_hugepages

Then,kswapd will take 100% cpu for a long time.

The numa layout is:
available: 7 nodes (0-6)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 6611 MB
node 0 free: 1103 MB
node 1 cpus:
node 1 size: 12527 MB
node 1 free: 8477 MB
node 2 cpus:
node 2 size: 15087 MB
node 2 free: 11037 MB
node 3 cpus:
node 3 size: 16111 MB
node 3 free: 12060 MB
node 4 cpus: 8 9 10 11 12 13 14 15
node 4 size: 24815 MB
node 4 free: 20704 MB
node 5 cpus:
node 5 size: 4095 MB
node 5 free: 61 MB 
node 6 cpus:
node 6 size: 22750 MB
node 6 free: 18716 MB

The cause is kswapd will loop for long time even if there is no progress in
balance_pgdat.

Signed-off-by: Jia He 
---
 mm/vmscan.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 532a2a7..7396a0a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -59,6 +59,7 @@
 #define CREATE_TRACE_POINTS
 #include 
 
+#define MAX_KSWAPD_RECLAIM_RETRIES 16
 struct scan_control {
/* How many pages shrink_list() should reclaim */
unsigned long nr_to_reclaim;
@@ -3202,7 +3203,8 @@ static bool kswapd_shrink_node(pg_data_t *pgdat,
  * or lower is eligible for reclaim until at least one usable zone is
  * balanced.
  */
-static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
+static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx,
+int *did_some_progress)
 {
int i;
unsigned long nr_soft_reclaimed;
@@ -3322,6 +3324,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
 * entered the allocator slow path while kswapd was awake, order will
 * remain at the higher level.
 */
+   *did_some_progress = !!(sc.nr_scanned || sc.nr_reclaimed);
return sc.order;
 }
 
@@ -3417,6 +3420,8 @@ static int kswapd(void *p)
unsigned int alloc_order, reclaim_order, classzone_idx;
pg_data_t *pgdat = (pg_data_t*)p;
struct task_struct *tsk = current;
+   int no_progress_loops = 0;
+   int did_some_progress = 0;
 
struct reclaim_state reclaim_state = {
.reclaimed_slab = 0,
@@ -3480,9 +3485,23 @@ static int kswapd(void *p)
 */
trace_mm_vmscan_kswapd_wake(pgdat->node_id, classzone_idx,
alloc_order);
-   reclaim_order = balance_pgdat(pgdat, alloc_order, 
classzone_idx);
-   if (reclaim_order < alloc_order)
+   reclaim_order = balance_pgdat(pgdat, alloc_order, classzone_idx,
+   _some_progress);
+
+   if (reclaim_order < alloc_order) {
+   no_progress_loops = 0;
goto kswapd_try_sleep;
+   }
+
+   if (did_some_progress)
+   no_progress_loops = 0;
+   else
+   no_progress_loops++;
+
+   if (no_progress_loops >= MAX_KSWAPD_RECLAIM_RETRIES) {
+   no_progress_loops = 0;
+   goto kswapd_try_sleep;
+   }
 
alloc_order = reclaim_order = pgdat->kswapd_order;
classzone_idx = pgdat->kswapd_classzone_idx;
-- 
2.5.5

[PATCH RFC 2/3] mm, vmscan: limit kswapd loop if no progress is made

[Jia He]

Currently there is no hard limitation for kswapd retry times if no progress
is made. Then kswapd will take 100% for a long time.

In my test, I tried to allocate 4000 hugepages by:
echo 4000 > /proc/sys/vm/nr_hugepages

Then,kswapd will take 100% cpu for a long time.

The numa layout is:
available: 7 nodes (0-6)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 6611 MB
node 0 free: 1103 MB
node 1 cpus:
node 1 size: 12527 MB
node 1 free: 8477 MB
node 2 cpus:
node 2 size: 15087 MB
node 2 free: 11037 MB
node 3 cpus:
node 3 size: 16111 MB
node 3 free: 12060 MB
node 4 cpus: 8 9 10 11 12 13 14 15
node 4 size: 24815 MB
node 4 free: 20704 MB
node 5 cpus:
node 5 size: 4095 MB
node 5 free: 61 MB 
node 6 cpus:
node 6 size: 22750 MB
node 6 free: 18716 MB

The cause is kswapd will loop for long time even if there is no progress in
balance_pgdat.

Signed-off-by: Jia He 
---
 mm/vmscan.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 532a2a7..7396a0a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -59,6 +59,7 @@
 #define CREATE_TRACE_POINTS
 #include 
 
+#define MAX_KSWAPD_RECLAIM_RETRIES 16
 struct scan_control {
/* How many pages shrink_list() should reclaim */
unsigned long nr_to_reclaim;
@@ -3202,7 +3203,8 @@ static bool kswapd_shrink_node(pg_data_t *pgdat,
  * or lower is eligible for reclaim until at least one usable zone is
  * balanced.
  */
-static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
+static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx,
+int *did_some_progress)
 {
int i;
unsigned long nr_soft_reclaimed;
@@ -3322,6 +3324,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
 * entered the allocator slow path while kswapd was awake, order will
 * remain at the higher level.
 */
+   *did_some_progress = !!(sc.nr_scanned || sc.nr_reclaimed);
return sc.order;
 }
 
@@ -3417,6 +3420,8 @@ static int kswapd(void *p)
unsigned int alloc_order, reclaim_order, classzone_idx;
pg_data_t *pgdat = (pg_data_t*)p;
struct task_struct *tsk = current;
+   int no_progress_loops = 0;
+   int did_some_progress = 0;
 
struct reclaim_state reclaim_state = {
.reclaimed_slab = 0,
@@ -3480,9 +3485,23 @@ static int kswapd(void *p)
 */
trace_mm_vmscan_kswapd_wake(pgdat->node_id, classzone_idx,
alloc_order);
-   reclaim_order = balance_pgdat(pgdat, alloc_order, 
classzone_idx);
-   if (reclaim_order < alloc_order)
+   reclaim_order = balance_pgdat(pgdat, alloc_order, classzone_idx,
+   _some_progress);
+
+   if (reclaim_order < alloc_order) {
+   no_progress_loops = 0;
goto kswapd_try_sleep;
+   }
+
+   if (did_some_progress)
+   no_progress_loops = 0;
+   else
+   no_progress_loops++;
+
+   if (no_progress_loops >= MAX_KSWAPD_RECLAIM_RETRIES) {
+   no_progress_loops = 0;
+   goto kswapd_try_sleep;
+   }
 
alloc_order = reclaim_order = pgdat->kswapd_order;
classzone_idx = pgdat->kswapd_classzone_idx;
-- 
2.5.5

[PATCH RFC 3/3] mm, vmscan: correct prepare_kswapd_sleep return value

[Jia He]

When there is no reclaimable pages in the zone, even the zone is
not balanced, we let kswapd go sleeping. That is prepare_kswapd_sleep
will return true in this case.

Signed-off-by: Jia He 
---
 mm/vmscan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7396a0a..54445e2 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3140,7 +3140,8 @@ static bool prepare_kswapd_sleep(pg_data_t *pgdat, int 
order, int classzone_idx)
if (!managed_zone(zone))
continue;
 
-   if (!zone_balanced(zone, order, classzone_idx))
+   if (!zone_balanced(zone, order, classzone_idx)
+   && !zone_reclaimable_pages(zone))
return false;
}
 
-- 
2.5.5

[PATCH RFC 0/3] optimize kswapd when it does reclaim for hugepage

[Jia He]

If there is a server with uneven numa memory layout:
available: 7 nodes (0-6)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 6603 MB
node 0 free: 91 MB
node 1 cpus:
node 1 size: 12527 MB
node 1 free: 157 MB
node 2 cpus:
node 2 size: 15087 MB
node 2 free: 189 MB
node 3 cpus:
node 3 size: 16111 MB
node 3 free: 205 MB
node 4 cpus: 8 9 10 11 12 13 14 15
node 4 size: 24815 MB
node 4 free: 310 MB
node 5 cpus:
node 5 size: 4095 MB
node 5 free: 61 MB
node 6 cpus:
node 6 size: 22750 MB
node 6 free: 283 MB
node distances:
node   0   1   2   3   4   5   6
  0:  10  20  40  40  40  40  40
  1:  20  10  40  40  40  40  40
  2:  40  40  10  20  40  40  40
  3:  40  40  20  10  40  40  40
  4:  40  40  40  40  10  20  40
  5:  40  40  40  40  20  10  40
  6:  40  40  40  40  40  40  10

In this case node 5 has less memory and we will alloc the hugepages
from these nodes one by one after we trigger 
echo 4000 > /proc/sys/vm/nr_hugepages

Then the kswapd5 will take 100% cpu for a long time. This is a livelock
issue in kswapd. This patch set fixes it.

The 3rd patch improves the kswapd's bad performance significantly.

Jia He (3):
  mm/hugetlb: split alloc_fresh_huge_page_node into fast and slow path
  mm, vmscan: limit kswapd loop if no progress is made
  mm, vmscan: correct prepare_kswapd_sleep return value

 mm/hugetlb.c |  9 +
 mm/vmscan.c  | 28 
 2 files changed, 33 insertions(+), 4 deletions(-)

-- 
2.5.5

[PATCH RFC 0/3] optimize kswapd when it does reclaim for hugepage

[Jia He]

If there is a server with uneven numa memory layout:
available: 7 nodes (0-6)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 6603 MB
node 0 free: 91 MB
node 1 cpus:
node 1 size: 12527 MB
node 1 free: 157 MB
node 2 cpus:
node 2 size: 15087 MB
node 2 free: 189 MB
node 3 cpus:
node 3 size: 16111 MB
node 3 free: 205 MB
node 4 cpus: 8 9 10 11 12 13 14 15
node 4 size: 24815 MB
node 4 free: 310 MB
node 5 cpus:
node 5 size: 4095 MB
node 5 free: 61 MB
node 6 cpus:
node 6 size: 22750 MB
node 6 free: 283 MB
node distances:
node   0   1   2   3   4   5   6
  0:  10  20  40  40  40  40  40
  1:  20  10  40  40  40  40  40
  2:  40  40  10  20  40  40  40
  3:  40  40  20  10  40  40  40
  4:  40  40  40  40  10  20  40
  5:  40  40  40  40  20  10  40
  6:  40  40  40  40  40  40  10

In this case node 5 has less memory and we will alloc the hugepages
from these nodes one by one after we trigger 
echo 4000 > /proc/sys/vm/nr_hugepages

Then the kswapd5 will take 100% cpu for a long time. This is a livelock
issue in kswapd. This patch set fixes it.

The 3rd patch improves the kswapd's bad performance significantly.

Jia He (3):
  mm/hugetlb: split alloc_fresh_huge_page_node into fast and slow path
  mm, vmscan: limit kswapd loop if no progress is made
  mm, vmscan: correct prepare_kswapd_sleep return value

 mm/hugetlb.c |  9 +
 mm/vmscan.c  | 28 
 2 files changed, 33 insertions(+), 4 deletions(-)

-- 
2.5.5

[PATCH RFC 3/3] mm, vmscan: correct prepare_kswapd_sleep return value

[Jia He]

When there is no reclaimable pages in the zone, even the zone is
not balanced, we let kswapd go sleeping. That is prepare_kswapd_sleep
will return true in this case.

Signed-off-by: Jia He 
---
 mm/vmscan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7396a0a..54445e2 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3140,7 +3140,8 @@ static bool prepare_kswapd_sleep(pg_data_t *pgdat, int 
order, int classzone_idx)
if (!managed_zone(zone))
continue;
 
-   if (!zone_balanced(zone, order, classzone_idx))
+   if (!zone_balanced(zone, order, classzone_idx)
+   && !zone_reclaimable_pages(zone))
return false;
}
 
-- 
2.5.5

Re: [PATCH] USB: Add quirk for WORLDE easykey.25 MIDI keyboard

[Lukáš Lalinský]

On Tue, Jan 24, 2017 at 8:32 AM, Oliver Neukum  wrote:
> Am Montag, den 23.01.2017, 19:36 +0100 schrieb Lukáš Lalinský:
>> I have uploaded both captures here -
>> https://gist.github.com/lalinsky/83148a827d5cd43e79e377d8e1b5ed0d
>
> Indeed it is does not set a configuration. Either the capture
> is incomplete or device and host violate the standard. A device
> may be left unconfigured.

Is this may or may not? I'm not familiar with USB, so I assumed if
there is only one configuration and there is always one active, it
does not need to be set explicitly because the correct one is already
active.

> We need to read the descriptors even if we
> see only one configuration to get the power budgeting right.

Aren't those in the CONFIGURATION descriptors? Reading the STRING
descriptor is probably only useful if you need to print the
configuration details somewhere.

> Does the device work without any .ini file?

Yes. It's a standard MIDI device, no configuration is required.

Lukas

Re: [PATCH] USB: Add quirk for WORLDE easykey.25 MIDI keyboard

[Lukáš Lalinský]

On Tue, Jan 24, 2017 at 8:32 AM, Oliver Neukum  wrote:
> Am Montag, den 23.01.2017, 19:36 +0100 schrieb Lukáš Lalinský:
>> I have uploaded both captures here -
>> https://gist.github.com/lalinsky/83148a827d5cd43e79e377d8e1b5ed0d
>
> Indeed it is does not set a configuration. Either the capture
> is incomplete or device and host violate the standard. A device
> may be left unconfigured.

Is this may or may not? I'm not familiar with USB, so I assumed if
there is only one configuration and there is always one active, it
does not need to be set explicitly because the correct one is already
active.

> We need to read the descriptors even if we
> see only one configuration to get the power budgeting right.

Aren't those in the CONFIGURATION descriptors? Reading the STRING
descriptor is probably only useful if you need to print the
configuration details somewhere.

> Does the device work without any .ini file?

Yes. It's a standard MIDI device, no configuration is required.

Lukas

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Pavel Machek]

On Tue 2017-01-24 15:06:39, Zhang Rui wrote:
> On Mon, Jan 23, 2017 at 03:49:12PM -0800, Guenter Roeck wrote:
> > On Tue, Jan 24, 2017 at 12:26:54AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > >I'll try to revert it on the top of v4.10-rc5 now... and yes, it 
> > > > > >fixes
> > > > > >the issue.
> > > > > >
> > > > > >Any idea what went wrong and how to fix that?
> > > > > >
> > > > > >Anyway as we are at -rc5 and this is warning fix that caused a
> > > > > >regression on different hardware... it should be reverted.
> > > > > >
> > > > > Agreed.
> > > > > 
> > > > > What exactly does "stopped working" mean ? That might help 
> > > > > understanding
> > > > > what went wrong.
> > > > 
> > > > /sys files related to battery no longer appear. I beieve this has
> > > > something to do with it:
> > > > 
> > > > [2.374877] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > > > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > > > [2.375946] input: TSC2005 touchscreen as
> > > > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > > > [2.392120] rx51-battery: probe of n900-battery failed with error
> > > > -22
> > > 
> > > Mystery solved:
> > > 
> > > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> > > index 3932f92..fe5ec82 100644
> > > --- a/drivers/hwmon/hwmon.c
> > > +++ b/drivers/hwmon/hwmon.c
> > > @@ -545,8 +545,10 @@ __hwmon_device_register(struct device *dev, const 
> > > char *name, void *drvdata,
> > >   int i, j, err, id;
> > >  
> > >   /* Do not accept invalid characters in hwmon name attribute */
> > > - if (name && (!strlen(name) || strpbrk(name, "-* \t\n")))
> > > + if (name && (!strlen(name) || strpbrk(name, "-* \t\n"))) {
> > > + printk("hwmon: Invalid character detected: %s\n", name);
> > >   return ERR_PTR(-EINVAL);
> > > + }
> > >  
> > >   id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> > >   if (id < 0)
> > > 
> > > 
> > > pavel@n900:~$ dmesg | grep -5 Invalid
> > > [0.829650] of_get_named_gpiod_flags: parsed 'gpio-reset' property
> > > of node '/ocp@6800/i2c@48072000/tlv320aic3x@19[0]' - status (0)
> > > [0.833831] tsl2563 2-0029: model 7, rev. 0
> > > [0.837768] of_get_named_gpiod_flags: parsed 'enable-gpio' property
> > > of node '/ocp@6800/i2c@48072000/lp5523@32[0]' - status (0)
> > > [1.921417] omap_i2c 48072000.i2c: controller timed out
> > > [2.056823] lp5523x 2-0032: lp5523 Programmable led chip found
> > > [2.064147] hwmon: Invalid character detected: bq27200-0
> > 
> > So the problem is really that the thermal driver needs to create a valid 
> > name.
> >
> Right.
> 
> Before reverting, can you please try if this patch works or not?

Not really. Revert now. Sorry.

Are you sure? This does not look equivalent to me at all.

"name" file handling moved from drivers to the core, which added some
crazy checks what name can contain. Even if this "works", what is the
expected effect on the "name" file?

Pavel

> thanks,
> rui
> 
> >From 79320ea3721314ec29ed6cdd6987ff922b11d6f9 Mon Sep 17 00:00:00 2001
> From: Zhang Rui 
> Date: Tue, 24 Jan 2017 14:11:03 +0800
> Subject: [PATCH] thermal: fix parameter when registering hwmon
> 
> commit 7611fb68062f ("thermal: thermal_hwmon: Convert to
> hwmon_device_register_with_info()") converts thermal core to use
> hwmon_device_register_with_info() to register to hwmon instead of
> deprecated hwmon_device_register().
> But at the same time, the name of the hwmon device created is changed to
> the thermal zone device name in this commit, which may contain
> incompatible characters for hwmon.
> 
> Fixes it by using exactly the same parameters as before this commit.
> 
> Fixes: 7611fb68062f ("thermal: thermal_hwmon: Convert to 
> hwmon_devce_register_with_info()")
> Reported-by: Pavel Machek 
> Signed-off-by: Zhang Rui 
> ---
>  drivers/thermal/thermal_hwmon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
> index c4a508a..0c6789f 100644
> --- a/drivers/thermal/thermal_hwmon.c
> +++ b/drivers/thermal/thermal_hwmon.c
> @@ -157,8 +157,8 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device 
> *tz)
>  
>   INIT_LIST_HEAD(>tz_list);
>   strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
> - hwmon->device = hwmon_device_register_with_info(NULL, hwmon->type,
> - hwmon, NULL, NULL);
> + hwmon->device = hwmon_device_register_with_info(NULL, NULL, NULL,
> + NULL, NULL);
>   if (IS_ERR(hwmon->device)) {
>   result = PTR_ERR(hwmon->device);
>   goto free_mem;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Pavel Machek]

On Tue 2017-01-24 15:06:39, Zhang Rui wrote:
> On Mon, Jan 23, 2017 at 03:49:12PM -0800, Guenter Roeck wrote:
> > On Tue, Jan 24, 2017 at 12:26:54AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > >I'll try to revert it on the top of v4.10-rc5 now... and yes, it 
> > > > > >fixes
> > > > > >the issue.
> > > > > >
> > > > > >Any idea what went wrong and how to fix that?
> > > > > >
> > > > > >Anyway as we are at -rc5 and this is warning fix that caused a
> > > > > >regression on different hardware... it should be reverted.
> > > > > >
> > > > > Agreed.
> > > > > 
> > > > > What exactly does "stopped working" mean ? That might help 
> > > > > understanding
> > > > > what went wrong.
> > > > 
> > > > /sys files related to battery no longer appear. I beieve this has
> > > > something to do with it:
> > > > 
> > > > [2.374877] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > > > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > > > [2.375946] input: TSC2005 touchscreen as
> > > > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > > > [2.392120] rx51-battery: probe of n900-battery failed with error
> > > > -22
> > > 
> > > Mystery solved:
> > > 
> > > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> > > index 3932f92..fe5ec82 100644
> > > --- a/drivers/hwmon/hwmon.c
> > > +++ b/drivers/hwmon/hwmon.c
> > > @@ -545,8 +545,10 @@ __hwmon_device_register(struct device *dev, const 
> > > char *name, void *drvdata,
> > >   int i, j, err, id;
> > >  
> > >   /* Do not accept invalid characters in hwmon name attribute */
> > > - if (name && (!strlen(name) || strpbrk(name, "-* \t\n")))
> > > + if (name && (!strlen(name) || strpbrk(name, "-* \t\n"))) {
> > > + printk("hwmon: Invalid character detected: %s\n", name);
> > >   return ERR_PTR(-EINVAL);
> > > + }
> > >  
> > >   id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> > >   if (id < 0)
> > > 
> > > 
> > > pavel@n900:~$ dmesg | grep -5 Invalid
> > > [0.829650] of_get_named_gpiod_flags: parsed 'gpio-reset' property
> > > of node '/ocp@6800/i2c@48072000/tlv320aic3x@19[0]' - status (0)
> > > [0.833831] tsl2563 2-0029: model 7, rev. 0
> > > [0.837768] of_get_named_gpiod_flags: parsed 'enable-gpio' property
> > > of node '/ocp@6800/i2c@48072000/lp5523@32[0]' - status (0)
> > > [1.921417] omap_i2c 48072000.i2c: controller timed out
> > > [2.056823] lp5523x 2-0032: lp5523 Programmable led chip found
> > > [2.064147] hwmon: Invalid character detected: bq27200-0
> > 
> > So the problem is really that the thermal driver needs to create a valid 
> > name.
> >
> Right.
> 
> Before reverting, can you please try if this patch works or not?

Not really. Revert now. Sorry.

Are you sure? This does not look equivalent to me at all.

"name" file handling moved from drivers to the core, which added some
crazy checks what name can contain. Even if this "works", what is the
expected effect on the "name" file?

Pavel

> thanks,
> rui
> 
> >From 79320ea3721314ec29ed6cdd6987ff922b11d6f9 Mon Sep 17 00:00:00 2001
> From: Zhang Rui 
> Date: Tue, 24 Jan 2017 14:11:03 +0800
> Subject: [PATCH] thermal: fix parameter when registering hwmon
> 
> commit 7611fb68062f ("thermal: thermal_hwmon: Convert to
> hwmon_device_register_with_info()") converts thermal core to use
> hwmon_device_register_with_info() to register to hwmon instead of
> deprecated hwmon_device_register().
> But at the same time, the name of the hwmon device created is changed to
> the thermal zone device name in this commit, which may contain
> incompatible characters for hwmon.
> 
> Fixes it by using exactly the same parameters as before this commit.
> 
> Fixes: 7611fb68062f ("thermal: thermal_hwmon: Convert to 
> hwmon_devce_register_with_info()")
> Reported-by: Pavel Machek 
> Signed-off-by: Zhang Rui 
> ---
>  drivers/thermal/thermal_hwmon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
> index c4a508a..0c6789f 100644
> --- a/drivers/thermal/thermal_hwmon.c
> +++ b/drivers/thermal/thermal_hwmon.c
> @@ -157,8 +157,8 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device 
> *tz)
>  
>   INIT_LIST_HEAD(>tz_list);
>   strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
> - hwmon->device = hwmon_device_register_with_info(NULL, hwmon->type,
> - hwmon, NULL, NULL);
> + hwmon->device = hwmon_device_register_with_info(NULL, NULL, NULL,
> + NULL, NULL);
>   if (IS_ERR(hwmon->device)) {
>   result = PTR_ERR(hwmon->device);
>   goto free_mem;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Pavel Machek]

Hi!

> > > > >I'll try to revert it on the top of v4.10-rc5 now... and yes, it fixes
> > > > >the issue.
> > > > >
> > > > >Any idea what went wrong and how to fix that?
> > > > >
> > > > >Anyway as we are at -rc5 and this is warning fix that caused a
> > > > >regression on different hardware... it should be reverted.
> > > > >
> > > > Agreed.
> > > > 
> > > > What exactly does "stopped working" mean ? That might help understanding
> > > > what went wrong.
> > > 
> > > /sys files related to battery no longer appear. I beieve this has
> > > something to do with it:
> > > 
> > > [2.374877] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > > [2.375946] input: TSC2005 touchscreen as
> > > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > > [2.392120] rx51-battery: probe of n900-battery failed with error
> > > -22
> > 
> > Mystery solved:
> > 
> > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> > index 3932f92..fe5ec82 100644
> > --- a/drivers/hwmon/hwmon.c
> > +++ b/drivers/hwmon/hwmon.c
> > @@ -545,8 +545,10 @@ __hwmon_device_register(struct device *dev, const char 
> > *name, void *drvdata,
> > int i, j, err, id;
> >  
> > /* Do not accept invalid characters in hwmon name attribute */
> > -   if (name && (!strlen(name) || strpbrk(name, "-* \t\n")))
> > +   if (name && (!strlen(name) || strpbrk(name, "-* \t\n"))) {
> > +   printk("hwmon: Invalid character detected: %s\n", name);
> > return ERR_PTR(-EINVAL);
> > +   }
> >  
> > id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> > if (id < 0)
> > 
> > 
> > pavel@n900:~$ dmesg | grep -5 Invalid
> > [0.829650] of_get_named_gpiod_flags: parsed 'gpio-reset' property
> > of node '/ocp@6800/i2c@48072000/tlv320aic3x@19[0]' - status (0)
> > [0.833831] tsl2563 2-0029: model 7, rev. 0
> > [0.837768] of_get_named_gpiod_flags: parsed 'enable-gpio' property
> > of node '/ocp@6800/i2c@48072000/lp5523@32[0]' - status (0)
> > [1.921417] omap_i2c 48072000.i2c: controller timed out
> > [2.056823] lp5523x 2-0032: lp5523 Programmable led chip found
> > [2.064147] hwmon: Invalid character detected: bq27200-0
> 
> So the problem is really that the thermal driver needs to create a valid name.

Look down how log continues.

So we really have two problematic names on one device. Plus, those
names are exposed to userspace, AFAICT. So "just changing them" might
not be good idea.

Maybe we should just relax the check?

Anyway, this just confirms that original patch needs to be reverted,
and that there will be some fun issues to solve in v4.11.

Pavel


> > [2.064544] bq27xxx-battery 2-0055: failed to register battery
> > [2.064605] bq27xxx-battery: probe of 2-0055 failed with error -22
> > [2.065368] of_get_named_gpiod_flags: parsed 'power-gpio' property
> > of node '/ocp@6800/i2c@48072000/tpa6130a2@60[0]' - status (0)
> > [2.083221] bq2415x-charger 2-006b: automode supported, waiting for
> > events
> > [2.084442] bq2415x-charger 2-006b: driver registered
> > --
> > [2.369842] g_ether gadget: g_ether ready
> > [2.377197] tsc2005 spi1.0: GPIO lookup for consumer reset
> > [2.377227] tsc2005 spi1.0: using device tree for GPIO lookup
> > [2.377288] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > [2.378936] input: TSC2005 touchscreen as
> > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > [2.395111] hwmon: Invalid character detected: rx51-battery
> > [2.402587] rx51-battery: probe of n900-battery failed with error
> > -22
> > [2.410247] omap_hsmmc 4809c000.mmc: GPIO lookup for consumer cd
> > [2.410247] omap_hsmmc 4809c000.mmc: using device tree for GPIO
> > lookup
> > [2.410278] of_get_named_gpiod_flags: can't parse 'cd-gpios'
> > property of node '/ocp@6800/mmc@4809c000[0]'
> > [2.410278] of_get_named_gpiod_flags: can't parse 'cd-gpio'
> > property of node '/ocp@6800/mmc@4809c000[0]'
> > 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Pavel Machek]

Hi!

> > > > >I'll try to revert it on the top of v4.10-rc5 now... and yes, it fixes
> > > > >the issue.
> > > > >
> > > > >Any idea what went wrong and how to fix that?
> > > > >
> > > > >Anyway as we are at -rc5 and this is warning fix that caused a
> > > > >regression on different hardware... it should be reverted.
> > > > >
> > > > Agreed.
> > > > 
> > > > What exactly does "stopped working" mean ? That might help understanding
> > > > what went wrong.
> > > 
> > > /sys files related to battery no longer appear. I beieve this has
> > > something to do with it:
> > > 
> > > [2.374877] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > > [2.375946] input: TSC2005 touchscreen as
> > > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > > [2.392120] rx51-battery: probe of n900-battery failed with error
> > > -22
> > 
> > Mystery solved:
> > 
> > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> > index 3932f92..fe5ec82 100644
> > --- a/drivers/hwmon/hwmon.c
> > +++ b/drivers/hwmon/hwmon.c
> > @@ -545,8 +545,10 @@ __hwmon_device_register(struct device *dev, const char 
> > *name, void *drvdata,
> > int i, j, err, id;
> >  
> > /* Do not accept invalid characters in hwmon name attribute */
> > -   if (name && (!strlen(name) || strpbrk(name, "-* \t\n")))
> > +   if (name && (!strlen(name) || strpbrk(name, "-* \t\n"))) {
> > +   printk("hwmon: Invalid character detected: %s\n", name);
> > return ERR_PTR(-EINVAL);
> > +   }
> >  
> > id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> > if (id < 0)
> > 
> > 
> > pavel@n900:~$ dmesg | grep -5 Invalid
> > [0.829650] of_get_named_gpiod_flags: parsed 'gpio-reset' property
> > of node '/ocp@6800/i2c@48072000/tlv320aic3x@19[0]' - status (0)
> > [0.833831] tsl2563 2-0029: model 7, rev. 0
> > [0.837768] of_get_named_gpiod_flags: parsed 'enable-gpio' property
> > of node '/ocp@6800/i2c@48072000/lp5523@32[0]' - status (0)
> > [1.921417] omap_i2c 48072000.i2c: controller timed out
> > [2.056823] lp5523x 2-0032: lp5523 Programmable led chip found
> > [2.064147] hwmon: Invalid character detected: bq27200-0
> 
> So the problem is really that the thermal driver needs to create a valid name.

Look down how log continues.

So we really have two problematic names on one device. Plus, those
names are exposed to userspace, AFAICT. So "just changing them" might
not be good idea.

Maybe we should just relax the check?

Anyway, this just confirms that original patch needs to be reverted,
and that there will be some fun issues to solve in v4.11.

Pavel


> > [2.064544] bq27xxx-battery 2-0055: failed to register battery
> > [2.064605] bq27xxx-battery: probe of 2-0055 failed with error -22
> > [2.065368] of_get_named_gpiod_flags: parsed 'power-gpio' property
> > of node '/ocp@6800/i2c@48072000/tpa6130a2@60[0]' - status (0)
> > [2.083221] bq2415x-charger 2-006b: automode supported, waiting for
> > events
> > [2.084442] bq2415x-charger 2-006b: driver registered
> > --
> > [2.369842] g_ether gadget: g_ether ready
> > [2.377197] tsc2005 spi1.0: GPIO lookup for consumer reset
> > [2.377227] tsc2005 spi1.0: using device tree for GPIO lookup
> > [2.377288] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > [2.378936] input: TSC2005 touchscreen as
> > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > [2.395111] hwmon: Invalid character detected: rx51-battery
> > [2.402587] rx51-battery: probe of n900-battery failed with error
> > -22
> > [2.410247] omap_hsmmc 4809c000.mmc: GPIO lookup for consumer cd
> > [2.410247] omap_hsmmc 4809c000.mmc: using device tree for GPIO
> > lookup
> > [2.410278] of_get_named_gpiod_flags: can't parse 'cd-gpios'
> > property of node '/ocp@6800/mmc@4809c000[0]'
> > [2.410278] of_get_named_gpiod_flags: can't parse 'cd-gpio'
> > property of node '/ocp@6800/mmc@4809c000[0]'
> > 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] USB: Add quirk for WORLDE easykey.25 MIDI keyboard

[Oliver Neukum]

Am Montag, den 23.01.2017, 19:36 +0100 schrieb Lukáš Lalinský:
> On Sat, Jan 21, 2017 at 10:08 AM, Greg Kroah-Hartman
>  wrote:
> > 
> > Always use scripts/get_maintainer.pl to determine who to send
> > patches
> > to, and what mailing list.  You forgot linux-usb@vger, which I've
> > now
> > added...
> 
> I'm sorry about that. I actually did use scripts/get_maintainer.pl,
> but it only returned your email address and I added linux-kernel@vger
> myself. I guess I ran it with wrong options.
> 
> > 
> > That's odd, how does other operating systems handle this device?
> 
> I'm not sure how realistic this test is, but I ran a Wireshark
> capture
> from Windows 8.1 VM and it seems that for this particular device,
> Windows doesn't try to set the current configuration (since there is
> only one) and it does not even attempt to get the configuration
> string
> descriptor. I'm not sure if Windows does this in general, but it
> seems
> to work around the problem for this device by not caring about the
> configuration string descriptor in the first place.
> 
> I have uploaded both captures here -
> https://gist.github.com/lalinsky/83148a827d5cd43e79e377d8e1b5ed0d

Indeed it is does not set a configuration. Either the capture
is incomplete or device and host violate the standard. A device
may be left unconfigured. We need to read the descriptors even if we
see only one configuration to get the power budgeting right.

Does the device work without any .ini file?

Regards
Oliver

Re: [PATCH] USB: Add quirk for WORLDE easykey.25 MIDI keyboard

[Oliver Neukum]

Am Montag, den 23.01.2017, 19:36 +0100 schrieb Lukáš Lalinský:
> On Sat, Jan 21, 2017 at 10:08 AM, Greg Kroah-Hartman
>  wrote:
> > 
> > Always use scripts/get_maintainer.pl to determine who to send
> > patches
> > to, and what mailing list.  You forgot linux-usb@vger, which I've
> > now
> > added...
> 
> I'm sorry about that. I actually did use scripts/get_maintainer.pl,
> but it only returned your email address and I added linux-kernel@vger
> myself. I guess I ran it with wrong options.
> 
> > 
> > That's odd, how does other operating systems handle this device?
> 
> I'm not sure how realistic this test is, but I ran a Wireshark
> capture
> from Windows 8.1 VM and it seems that for this particular device,
> Windows doesn't try to set the current configuration (since there is
> only one) and it does not even attempt to get the configuration
> string
> descriptor. I'm not sure if Windows does this in general, but it
> seems
> to work around the problem for this device by not caring about the
> configuration string descriptor in the first place.
> 
> I have uploaded both captures here -
> https://gist.github.com/lalinsky/83148a827d5cd43e79e377d8e1b5ed0d

Indeed it is does not set a configuration. Either the capture
is incomplete or device and host violate the standard. A device
may be left unconfigured. We need to read the descriptors even if we
see only one configuration to get the power budgeting right.

Does the device work without any .ini file?

Regards
Oliver

Re: [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata

[Robert Jarzmik]

Kevin Hilman  writes:

> Hello,
>
> On Wed, Oct 26, 2016 at 12:41 PM, Robert Jarzmik  
> wrote:
>> As the power supply framework provides a way to store and retrieve
>> private supply data, use it.
>>
>> In the process, change the platform data for wm97xx_battery from a
>> container of a single struct wm97xx_batt_pdata to the direct point to 
>> wm97xx_batt_pdata.
>>
>> Signed-off-by: Robert Jarzmik 
>
> kernelci.org has been reporting that the tegra20-iris board has been
> failing in -next since next-20161123[1], and also in mainline
> v4.10-rc.  I finally took the time to bisect, and it pointed to this
> patch.  I verified that reverting $SUBJECT patch[2] on top of
> v4.10-rc5 fixes the problem.
>
> Kevin
>
> [1] https://kernelci.org/boot/id/5879a3fe59b5141534f6c3ac/
> [2] in mainline as commit: 6480af4915d6 power_supply: wm97xx_battery:
> use power_supply_get_drvdata

Hi Kevin,

There is a fix posted in here :
https://patchwork.kernel.org/patch/9499231/

I don't know if it's related, as I have no Oops signature nor any data to be
able to help further.

Cheers.

--
Robert

Re: [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata

[Robert Jarzmik]

Kevin Hilman  writes:

> Hello,
>
> On Wed, Oct 26, 2016 at 12:41 PM, Robert Jarzmik  
> wrote:
>> As the power supply framework provides a way to store and retrieve
>> private supply data, use it.
>>
>> In the process, change the platform data for wm97xx_battery from a
>> container of a single struct wm97xx_batt_pdata to the direct point to 
>> wm97xx_batt_pdata.
>>
>> Signed-off-by: Robert Jarzmik 
>
> kernelci.org has been reporting that the tegra20-iris board has been
> failing in -next since next-20161123[1], and also in mainline
> v4.10-rc.  I finally took the time to bisect, and it pointed to this
> patch.  I verified that reverting $SUBJECT patch[2] on top of
> v4.10-rc5 fixes the problem.
>
> Kevin
>
> [1] https://kernelci.org/boot/id/5879a3fe59b5141534f6c3ac/
> [2] in mainline as commit: 6480af4915d6 power_supply: wm97xx_battery:
> use power_supply_get_drvdata

Hi Kevin,

There is a fix posted in here :
https://patchwork.kernel.org/patch/9499231/

I don't know if it's related, as I have no Oops signature nor any data to be
able to help further.

Cheers.

--
Robert

Re: [PATCH] mmc: s3cmci: include linux/interrupt.h for tasklet_struct

[Ulf Hansson]

On 20 January 2017 at 21:08, Arnd Bergmann  wrote:
> I got this new build error on today's linux-next
>
> drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete 
> type
>   struct tasklet_struct pio_tasklet;
> drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
> drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 
> 'enable_irq';did you mean 'enable_imask'? 
> [-Werror=implicit-function-declaration]
>
> While I haven't found out why this happened now and not earlier, the
> solution is obvious, we should include the header that defines
> the structure.

Yes, it's a bit weird. Actually non of the automated build system have
reported this.

I have my own homebrewed makefiles, as to run a quick sanity test for
mmc host drivers. However, my quick test didn't cover s3cmci, next
time it will.

>
> Signed-off-by: Arnd Bergmann 

Thanks for helping out! Applied for next and folded it in properly in
my queue to avoid bisect issues!

Kind regards
Uffe

> ---
>  drivers/mmc/host/s3cmci.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index 932a4b1fed33..7a173f8c455b 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> --
> 2.9.0
>

Re: [PATCH] mmc: s3cmci: include linux/interrupt.h for tasklet_struct

[Ulf Hansson]

On 20 January 2017 at 21:08, Arnd Bergmann  wrote:
> I got this new build error on today's linux-next
>
> drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete 
> type
>   struct tasklet_struct pio_tasklet;
> drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
> drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 
> 'enable_irq';did you mean 'enable_imask'? 
> [-Werror=implicit-function-declaration]
>
> While I haven't found out why this happened now and not earlier, the
> solution is obvious, we should include the header that defines
> the structure.

Yes, it's a bit weird. Actually non of the automated build system have
reported this.

I have my own homebrewed makefiles, as to run a quick sanity test for
mmc host drivers. However, my quick test didn't cover s3cmci, next
time it will.

>
> Signed-off-by: Arnd Bergmann 

Thanks for helping out! Applied for next and folded it in properly in
my queue to avoid bisect issues!

Kind regards
Uffe

> ---
>  drivers/mmc/host/s3cmci.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index 932a4b1fed33..7a173f8c455b 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> --
> 2.9.0
>

Re: [PATCH] Bluetooth: hidp: might sleep error in hidp_session_thread

[jeffy]

Hi brian,

On 01/24/2017 10:31 AM, Brian Norris wrote:

Hi Jeffy,

On Fri, Jan 20, 2017 at 09:52:08PM +0800, Jeffy Chen wrote:

[   39.044329] do not call blocking ops when !TASK_RUNNING; state=1 set
at [] hidp_session_thread+0x110/0x568 [hidp]
...
[   40.159664] Call trace:
[   40.162122] [] __might_sleep+0x64/0x90
[   40.167443] [] lock_sock_nested+0x30/0x78
[   40.173047] [] l2cap_sock_sendmsg+0x90/0xf0
[bluetooth]
[   40.179842] [] sock_sendmsg+0x4c/0x68
[   40.185072] [] kernel_sendmsg+0x54/0x68
[   40.190477] [] hidp_send_frame+0x78/0xa0 [hidp]
[   40.196574] [] hidp_process_transmit+0x44/0x98
[hidp]
[   40.203191] [] hidp_session_thread+0x364/0x568
[hidp]

Am I crazy, or are several other protocols broken like this too? I see a
similar structure in net/bluetooth/bnep/core.c and
net/bluetooth/cmtp/core.c, at least, each of which also call
kernel_sendmsg(), which might be an l2cap socket (...I think? I'm not a
bluetooth expert really).
Thanx, uploaded a new serial of patchset, which contains hidp & cmtp & 
bnep:9534023/9534025/9534027



Following (https://lwn.net/Articles/628628/).

Signed-off-by: Jeffy Chen 
---

  net/bluetooth/hidp/core.c | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 0bec458..bfd3fb8 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -1180,7 +1180,9 @@ static void hidp_session_run(struct hidp_session *session)
struct sock *ctrl_sk = session->ctrl_sock->sk;
struct sock *intr_sk = session->intr_sock->sk;
struct sk_buff *skb;
+   DEFINE_WAIT_FUNC(wait, woken_wake_function);
  
+	add_wait_queue(sk_sleep(intr_sk), );

for (;;) {
/*
 * This thread can be woken up two ways:
@@ -1188,12 +1190,10 @@ static void hidp_session_run(struct hidp_session 
*session)
 *session->terminate flag and wakes this thread up.
 *  - Via modifying the socket state of ctrl/intr_sock. This
 *thread is woken up by ->sk_state_changed().
-*
-* Note: set_current_state() performs any necessary
-* memory-barriers for us.
 */
-   set_current_state(TASK_INTERRUPTIBLE);
  
+		/* Ensure session->terminate is updated */

+   smp_mb__before_atomic();
if (atomic_read(>terminate))
break;
  
@@ -1227,11 +1227,14 @@ static void hidp_session_run(struct hidp_session *session)

hidp_process_transmit(session, >ctrl_transmit,
  session->ctrl_sock);
  
-		schedule();

+   wait_woken(, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);

I think this looks mostly good, except what about the
hidp_session_terminate() condition? In that case, you're running
wake_up_process() -- which won't set WQ_FLAG_WOKEN for us. So what
happens if we see a hidp_session_terminate() call in between the check
for the ->terminate count, but before we call wait_woken()? IIUC, I
think we'll just ignore the call and keep waiting for the next wake
signal.

I think you might need to rework hidp_session_terminate() too, to
actually target the wait queue and not just the processes.

IIUC, of course. I could be wrong...

Ok, that make sense, thanx for point that out.


Brian


}
+   remove_wait_queue(sk_sleep(intr_sk), );
  
  	atomic_inc(>terminate);

-   set_current_state(TASK_RUNNING);
+
+   /* Ensure session->terminate is updated */
+   smp_mb__after_atomic();
  }
  
  /*

--
2.1.4

Re: [PATCH] Bluetooth: hidp: might sleep error in hidp_session_thread

[jeffy]

Hi brian,

On 01/24/2017 10:31 AM, Brian Norris wrote:

Hi Jeffy,

On Fri, Jan 20, 2017 at 09:52:08PM +0800, Jeffy Chen wrote:

[   39.044329] do not call blocking ops when !TASK_RUNNING; state=1 set
at [] hidp_session_thread+0x110/0x568 [hidp]
...
[   40.159664] Call trace:
[   40.162122] [] __might_sleep+0x64/0x90
[   40.167443] [] lock_sock_nested+0x30/0x78
[   40.173047] [] l2cap_sock_sendmsg+0x90/0xf0
[bluetooth]
[   40.179842] [] sock_sendmsg+0x4c/0x68
[   40.185072] [] kernel_sendmsg+0x54/0x68
[   40.190477] [] hidp_send_frame+0x78/0xa0 [hidp]
[   40.196574] [] hidp_process_transmit+0x44/0x98
[hidp]
[   40.203191] [] hidp_session_thread+0x364/0x568
[hidp]

Am I crazy, or are several other protocols broken like this too? I see a
similar structure in net/bluetooth/bnep/core.c and
net/bluetooth/cmtp/core.c, at least, each of which also call
kernel_sendmsg(), which might be an l2cap socket (...I think? I'm not a
bluetooth expert really).
Thanx, uploaded a new serial of patchset, which contains hidp & cmtp & 
bnep:9534023/9534025/9534027



Following (https://lwn.net/Articles/628628/).

Signed-off-by: Jeffy Chen 
---

  net/bluetooth/hidp/core.c | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 0bec458..bfd3fb8 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -1180,7 +1180,9 @@ static void hidp_session_run(struct hidp_session *session)
struct sock *ctrl_sk = session->ctrl_sock->sk;
struct sock *intr_sk = session->intr_sock->sk;
struct sk_buff *skb;
+   DEFINE_WAIT_FUNC(wait, woken_wake_function);
  
+	add_wait_queue(sk_sleep(intr_sk), );

for (;;) {
/*
 * This thread can be woken up two ways:
@@ -1188,12 +1190,10 @@ static void hidp_session_run(struct hidp_session 
*session)
 *session->terminate flag and wakes this thread up.
 *  - Via modifying the socket state of ctrl/intr_sock. This
 *thread is woken up by ->sk_state_changed().
-*
-* Note: set_current_state() performs any necessary
-* memory-barriers for us.
 */
-   set_current_state(TASK_INTERRUPTIBLE);
  
+		/* Ensure session->terminate is updated */

+   smp_mb__before_atomic();
if (atomic_read(>terminate))
break;
  
@@ -1227,11 +1227,14 @@ static void hidp_session_run(struct hidp_session *session)

hidp_process_transmit(session, >ctrl_transmit,
  session->ctrl_sock);
  
-		schedule();

+   wait_woken(, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);

I think this looks mostly good, except what about the
hidp_session_terminate() condition? In that case, you're running
wake_up_process() -- which won't set WQ_FLAG_WOKEN for us. So what
happens if we see a hidp_session_terminate() call in between the check
for the ->terminate count, but before we call wait_woken()? IIUC, I
think we'll just ignore the call and keep waiting for the next wake
signal.

I think you might need to rework hidp_session_terminate() too, to
actually target the wait queue and not just the processes.

IIUC, of course. I could be wrong...

Ok, that make sense, thanx for point that out.


Brian


}
+   remove_wait_queue(sk_sleep(intr_sk), );
  
  	atomic_inc(>terminate);

-   set_current_state(TASK_RUNNING);
+
+   /* Ensure session->terminate is updated */
+   smp_mb__after_atomic();
  }
  
  /*

--
2.1.4

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Zhang Rui]

On Mon, Jan 23, 2017 at 03:49:12PM -0800, Guenter Roeck wrote:
> On Tue, Jan 24, 2017 at 12:26:54AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > >I'll try to revert it on the top of v4.10-rc5 now... and yes, it fixes
> > > > >the issue.
> > > > >
> > > > >Any idea what went wrong and how to fix that?
> > > > >
> > > > >Anyway as we are at -rc5 and this is warning fix that caused a
> > > > >regression on different hardware... it should be reverted.
> > > > >
> > > > Agreed.
> > > > 
> > > > What exactly does "stopped working" mean ? That might help understanding
> > > > what went wrong.
> > > 
> > > /sys files related to battery no longer appear. I beieve this has
> > > something to do with it:
> > > 
> > > [2.374877] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > > [2.375946] input: TSC2005 touchscreen as
> > > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > > [2.392120] rx51-battery: probe of n900-battery failed with error
> > > -22
> > 
> > Mystery solved:
> > 
> > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> > index 3932f92..fe5ec82 100644
> > --- a/drivers/hwmon/hwmon.c
> > +++ b/drivers/hwmon/hwmon.c
> > @@ -545,8 +545,10 @@ __hwmon_device_register(struct device *dev, const char 
> > *name, void *drvdata,
> > int i, j, err, id;
> >  
> > /* Do not accept invalid characters in hwmon name attribute */
> > -   if (name && (!strlen(name) || strpbrk(name, "-* \t\n")))
> > +   if (name && (!strlen(name) || strpbrk(name, "-* \t\n"))) {
> > +   printk("hwmon: Invalid character detected: %s\n", name);
> > return ERR_PTR(-EINVAL);
> > +   }
> >  
> > id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> > if (id < 0)
> > 
> > 
> > pavel@n900:~$ dmesg | grep -5 Invalid
> > [0.829650] of_get_named_gpiod_flags: parsed 'gpio-reset' property
> > of node '/ocp@6800/i2c@48072000/tlv320aic3x@19[0]' - status (0)
> > [0.833831] tsl2563 2-0029: model 7, rev. 0
> > [0.837768] of_get_named_gpiod_flags: parsed 'enable-gpio' property
> > of node '/ocp@6800/i2c@48072000/lp5523@32[0]' - status (0)
> > [1.921417] omap_i2c 48072000.i2c: controller timed out
> > [2.056823] lp5523x 2-0032: lp5523 Programmable led chip found
> > [2.064147] hwmon: Invalid character detected: bq27200-0
> 
> So the problem is really that the thermal driver needs to create a valid name.
>
Right.

Before reverting, can you please try if this patch works or not?

thanks,
rui

>From 79320ea3721314ec29ed6cdd6987ff922b11d6f9 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Tue, 24 Jan 2017 14:11:03 +0800
Subject: [PATCH] thermal: fix parameter when registering hwmon

commit 7611fb68062f ("thermal: thermal_hwmon: Convert to
hwmon_device_register_with_info()") converts thermal core to use
hwmon_device_register_with_info() to register to hwmon instead of
deprecated hwmon_device_register().
But at the same time, the name of the hwmon device created is changed to
the thermal zone device name in this commit, which may contain
incompatible characters for hwmon.

Fixes it by using exactly the same parameters as before this commit.

Fixes: 7611fb68062f ("thermal: thermal_hwmon: Convert to 
hwmon_devce_register_with_info()")
Reported-by: Pavel Machek 
Signed-off-by: Zhang Rui 
---
 drivers/thermal/thermal_hwmon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index c4a508a..0c6789f 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -157,8 +157,8 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
 
INIT_LIST_HEAD(>tz_list);
strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
-   hwmon->device = hwmon_device_register_with_info(NULL, hwmon->type,
-   hwmon, NULL, NULL);
+   hwmon->device = hwmon_device_register_with_info(NULL, NULL, NULL,
+   NULL, NULL);
if (IS_ERR(hwmon->device)) {
result = PTR_ERR(hwmon->device);
goto free_mem;
-- 
2.7.4

 
> Guenter
> 
> > [2.064544] bq27xxx-battery 2-0055: failed to register battery
> > [2.064605] bq27xxx-battery: probe of 2-0055 failed with error -22
> > [2.065368] of_get_named_gpiod_flags: parsed 'power-gpio' property
> > of node '/ocp@6800/i2c@48072000/tpa6130a2@60[0]' - status (0)
> > [2.083221] bq2415x-charger 2-006b: automode supported, waiting for
> > events
> > [2.084442] bq2415x-charger 2-006b: driver registered
> > --
> > [2.369842] g_ether gadget: g_ether ready
> > [2.377197] tsc2005 spi1.0: GPIO lookup for consumer reset
> > [2.377227] tsc2005 spi1.0: using device tree for GPIO lookup
> > [2.377288] 

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Zhang Rui]

On Mon, Jan 23, 2017 at 03:49:12PM -0800, Guenter Roeck wrote:
> On Tue, Jan 24, 2017 at 12:26:54AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > >I'll try to revert it on the top of v4.10-rc5 now... and yes, it fixes
> > > > >the issue.
> > > > >
> > > > >Any idea what went wrong and how to fix that?
> > > > >
> > > > >Anyway as we are at -rc5 and this is warning fix that caused a
> > > > >regression on different hardware... it should be reverted.
> > > > >
> > > > Agreed.
> > > > 
> > > > What exactly does "stopped working" mean ? That might help understanding
> > > > what went wrong.
> > > 
> > > /sys files related to battery no longer appear. I beieve this has
> > > something to do with it:
> > > 
> > > [2.374877] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > > of node '/ocp@6800/spi@48098000/tsc2005@0[0]' - status (0)
> > > [2.375946] input: TSC2005 touchscreen as
> > > /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5
> > > [2.392120] rx51-battery: probe of n900-battery failed with error
> > > -22
> > 
> > Mystery solved:
> > 
> > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> > index 3932f92..fe5ec82 100644
> > --- a/drivers/hwmon/hwmon.c
> > +++ b/drivers/hwmon/hwmon.c
> > @@ -545,8 +545,10 @@ __hwmon_device_register(struct device *dev, const char 
> > *name, void *drvdata,
> > int i, j, err, id;
> >  
> > /* Do not accept invalid characters in hwmon name attribute */
> > -   if (name && (!strlen(name) || strpbrk(name, "-* \t\n")))
> > +   if (name && (!strlen(name) || strpbrk(name, "-* \t\n"))) {
> > +   printk("hwmon: Invalid character detected: %s\n", name);
> > return ERR_PTR(-EINVAL);
> > +   }
> >  
> > id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> > if (id < 0)
> > 
> > 
> > pavel@n900:~$ dmesg | grep -5 Invalid
> > [0.829650] of_get_named_gpiod_flags: parsed 'gpio-reset' property
> > of node '/ocp@6800/i2c@48072000/tlv320aic3x@19[0]' - status (0)
> > [0.833831] tsl2563 2-0029: model 7, rev. 0
> > [0.837768] of_get_named_gpiod_flags: parsed 'enable-gpio' property
> > of node '/ocp@6800/i2c@48072000/lp5523@32[0]' - status (0)
> > [1.921417] omap_i2c 48072000.i2c: controller timed out
> > [2.056823] lp5523x 2-0032: lp5523 Programmable led chip found
> > [2.064147] hwmon: Invalid character detected: bq27200-0
> 
> So the problem is really that the thermal driver needs to create a valid name.
>
Right.

Before reverting, can you please try if this patch works or not?

thanks,
rui

>From 79320ea3721314ec29ed6cdd6987ff922b11d6f9 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Tue, 24 Jan 2017 14:11:03 +0800
Subject: [PATCH] thermal: fix parameter when registering hwmon

commit 7611fb68062f ("thermal: thermal_hwmon: Convert to
hwmon_device_register_with_info()") converts thermal core to use
hwmon_device_register_with_info() to register to hwmon instead of
deprecated hwmon_device_register().
But at the same time, the name of the hwmon device created is changed to
the thermal zone device name in this commit, which may contain
incompatible characters for hwmon.

Fixes it by using exactly the same parameters as before this commit.

Fixes: 7611fb68062f ("thermal: thermal_hwmon: Convert to 
hwmon_devce_register_with_info()")
Reported-by: Pavel Machek 
Signed-off-by: Zhang Rui 
---
 drivers/thermal/thermal_hwmon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index c4a508a..0c6789f 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -157,8 +157,8 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
 
INIT_LIST_HEAD(>tz_list);
strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
-   hwmon->device = hwmon_device_register_with_info(NULL, hwmon->type,
-   hwmon, NULL, NULL);
+   hwmon->device = hwmon_device_register_with_info(NULL, NULL, NULL,
+   NULL, NULL);
if (IS_ERR(hwmon->device)) {
result = PTR_ERR(hwmon->device);
goto free_mem;
-- 
2.7.4

 
> Guenter
> 
> > [2.064544] bq27xxx-battery 2-0055: failed to register battery
> > [2.064605] bq27xxx-battery: probe of 2-0055 failed with error -22
> > [2.065368] of_get_named_gpiod_flags: parsed 'power-gpio' property
> > of node '/ocp@6800/i2c@48072000/tpa6130a2@60[0]' - status (0)
> > [2.083221] bq2415x-charger 2-006b: automode supported, waiting for
> > events
> > [2.084442] bq2415x-charger 2-006b: driver registered
> > --
> > [2.369842] g_ether gadget: g_ether ready
> > [2.377197] tsc2005 spi1.0: GPIO lookup for consumer reset
> > [2.377227] tsc2005 spi1.0: using device tree for GPIO lookup
> > [2.377288] of_get_named_gpiod_flags: parsed 'reset-gpios' property
> > of node 

Re: [PATCH] kernel-doc: Handle returning pointers to pointers

[Markus Heiser]

Am 23.01.2017 um 16:24 schrieb Jonathan Corbet :

> On Mon, 23 Jan 2017 15:14:51 +
> Matthew Wilcox  wrote:
> 
>>> I maintain my own stack of "linuxdoc" with a python version
>>> of the kernel-doc script (hosted on github). It uses the same
>>> regexes as the perl version (using a python rewrite here has some
>>> other benefits, one you will see below). I merged your patch:  
>> 
>> Are there plans to merge that?  It feels so odd to have a python script 
>> calling a perl script ...
> 
> I pushed back pretty hard on it last year; my feeling at the time was that
> the Sphinx transition had enough moving parts as it was.

I know what you mean ;)

>  I do think we
> can reconsider it now, though.  It's not as if the perl kerneldoc script
> is a thing of great beauty in need of preservation.
> 
> Markus, would you consider sending out a new patch set for review?  

Yes, I send RFC soon ...

> What I
> would like to do see is something adding the new script for the Sphinx
> toolchain, while leaving the DocBook build unchanged, using the old
> script.  We could then delete it once the last template file has moved
> over.

agree ...

> 4.12 would be the probable merge target; it's a big enough change that I'd
> like to have it in -next for a full development cycle.

agree once more.

Thanks for choosing this!

  -- Markus --

Re: [PATCH] kernel-doc: Handle returning pointers to pointers

[Markus Heiser]

Am 23.01.2017 um 16:24 schrieb Jonathan Corbet :

> On Mon, 23 Jan 2017 15:14:51 +
> Matthew Wilcox  wrote:
> 
>>> I maintain my own stack of "linuxdoc" with a python version
>>> of the kernel-doc script (hosted on github). It uses the same
>>> regexes as the perl version (using a python rewrite here has some
>>> other benefits, one you will see below). I merged your patch:  
>> 
>> Are there plans to merge that?  It feels so odd to have a python script 
>> calling a perl script ...
> 
> I pushed back pretty hard on it last year; my feeling at the time was that
> the Sphinx transition had enough moving parts as it was.

I know what you mean ;)

>  I do think we
> can reconsider it now, though.  It's not as if the perl kerneldoc script
> is a thing of great beauty in need of preservation.
> 
> Markus, would you consider sending out a new patch set for review?  

Yes, I send RFC soon ...

> What I
> would like to do see is something adding the new script for the Sphinx
> toolchain, while leaving the DocBook build unchanged, using the old
> script.  We could then delete it once the last template file has moved
> over.

agree ...

> 4.12 would be the probable merge target; it's a big enough change that I'd
> like to have it in -next for a full development cycle.

agree once more.

Thanks for choosing this!

  -- Markus --

Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

[Ravi Bangoria]

On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote:
> * Alexis Berlemont  wrote:
>
>> Hi Masami,
>>
>> Many thanks for your mail.
>>
>> Here is another patch set which tries to fix the points you mentioned:
>>
>> * Skip the arguments containing a constant ($123); 
>> * Review the code in charge of the register renaming (search for '%'
>>   and parse it);
>> * Minor changes (print the argument in case of error, skipping, check
>>   the sdt arg type index);
>>
>> Many thanks,
>>
>> Alexis.
>>
>> Alexis Berlemont (2):
>>   perf sdt: add scanning of sdt probles arguments
>>   perf probe: add sdt probes arguments into the uprobe cmd string
> I'd like to hijack this thread to report an SDT oddity - one of my boxen 
> reports 
> lots of SDT tracepoints in 'perf list':
>
>   mem:[/len][:access]  [Hardware breakpoint]
>
>   sdt_libc:lll_lock_wait_private [SDT event]
>   sdt_libc:longjmp   [SDT event]
>   sdt_libc:longjmp_target[SDT event]
>   sdt_libc:memory_arena_new  [SDT event]
>   sdt_libc:memory_arena_retry[SDT event]
>   sdt_libc:memory_arena_reuse[SDT event]
>   sdt_libc:memory_arena_reuse_free_list  [SDT event]
>   sdt_libc:memory_arena_reuse_wait   [SDT event]
>   sdt_libc:memory_calloc_retry   [SDT event]
>   sdt_libc:memory_heap_free  [SDT event]
>   ...
>
> But none of them work:
>
>   Error:  No permissions to read 
> /sys/kernel/debug/tracing/events/sdt_libc/longjmp
>   Hint:   Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
>
>   ...
>
>   Error:  File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found.
>   Hint:   Perhaps this kernel misses some CONFIG_ setting to enable this 
> feature?.
>
> What kind of patches are required for SDT probes to work?

Hi Ingo,

I suppose you are trying to record SDT events without probing it.
In that case, first put a probe on an event and then try to record
it. For example,

$ ./perf list | grep sdt_
  sdt_glib:main__after_prepare   [SDT event]
  sdt_glib:main__before_dispatch [SDT event]
  ...

$ ./perf record -a -e sdt_glib:main__after_prepare
  event syntax error: 'sdt_glib:main__after_prepare'
   \___ unknown tracepoint

  Error:  File /sys/kernel/debug/tracing/events/sdt_glib/main__after_prepare 
not found.
  Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
  ...

$ ./perf probe sdt_glib:main__after_prepare
  Added new events:
sdt_glib:main__after_prepare (on %main__after_prepare in 
/usr/lib64/libglib-2.0.so.0.5000.2)
sdt_glib:main__after_prepare_1 (on %main__after_prepare in 
/usr/lib64/libglib-2.0.so.0.5000.2)

  You can now use it in all perf tools, such as:

perf record -e sdt_glib:main__after_prepare_1 -aR sleep 1

$ ./perf record -a -e sdt_glib:main__after_prepare
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.191 MB perf.data ]

-Ravi

Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

[Ravi Bangoria]

On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote:
> * Alexis Berlemont  wrote:
>
>> Hi Masami,
>>
>> Many thanks for your mail.
>>
>> Here is another patch set which tries to fix the points you mentioned:
>>
>> * Skip the arguments containing a constant ($123); 
>> * Review the code in charge of the register renaming (search for '%'
>>   and parse it);
>> * Minor changes (print the argument in case of error, skipping, check
>>   the sdt arg type index);
>>
>> Many thanks,
>>
>> Alexis.
>>
>> Alexis Berlemont (2):
>>   perf sdt: add scanning of sdt probles arguments
>>   perf probe: add sdt probes arguments into the uprobe cmd string
> I'd like to hijack this thread to report an SDT oddity - one of my boxen 
> reports 
> lots of SDT tracepoints in 'perf list':
>
>   mem:[/len][:access]  [Hardware breakpoint]
>
>   sdt_libc:lll_lock_wait_private [SDT event]
>   sdt_libc:longjmp   [SDT event]
>   sdt_libc:longjmp_target[SDT event]
>   sdt_libc:memory_arena_new  [SDT event]
>   sdt_libc:memory_arena_retry[SDT event]
>   sdt_libc:memory_arena_reuse[SDT event]
>   sdt_libc:memory_arena_reuse_free_list  [SDT event]
>   sdt_libc:memory_arena_reuse_wait   [SDT event]
>   sdt_libc:memory_calloc_retry   [SDT event]
>   sdt_libc:memory_heap_free  [SDT event]
>   ...
>
> But none of them work:
>
>   Error:  No permissions to read 
> /sys/kernel/debug/tracing/events/sdt_libc/longjmp
>   Hint:   Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
>
>   ...
>
>   Error:  File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found.
>   Hint:   Perhaps this kernel misses some CONFIG_ setting to enable this 
> feature?.
>
> What kind of patches are required for SDT probes to work?

Hi Ingo,

I suppose you are trying to record SDT events without probing it.
In that case, first put a probe on an event and then try to record
it. For example,

$ ./perf list | grep sdt_
  sdt_glib:main__after_prepare   [SDT event]
  sdt_glib:main__before_dispatch [SDT event]
  ...

$ ./perf record -a -e sdt_glib:main__after_prepare
  event syntax error: 'sdt_glib:main__after_prepare'
   \___ unknown tracepoint

  Error:  File /sys/kernel/debug/tracing/events/sdt_glib/main__after_prepare 
not found.
  Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
  ...

$ ./perf probe sdt_glib:main__after_prepare
  Added new events:
sdt_glib:main__after_prepare (on %main__after_prepare in 
/usr/lib64/libglib-2.0.so.0.5000.2)
sdt_glib:main__after_prepare_1 (on %main__after_prepare in 
/usr/lib64/libglib-2.0.so.0.5000.2)

  You can now use it in all perf tools, such as:

perf record -e sdt_glib:main__after_prepare_1 -aR sleep 1

$ ./perf record -a -e sdt_glib:main__after_prepare
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.191 MB perf.data ]

-Ravi

[PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[Dexuan Cui]

Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
hv_need_to_signal_on_read()")
added the proper mb(), but removed the test "prev_write_sz < pending_sz"
when making the signal decision.

As a result, the guest can signal the host unnecessarily,
and then the host can throttle the guest because the host
thinks the guest is buggy or malicious; finally the user
running stress test can perceive intermittent freeze of
the guest.

This patch brings back the test, and properly handles the
in-place consumption APIs used by NetVSC (see get_next_pkt_raw(),
put_pkt_raw() and commit_rd_index()).

Fixes: a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
hv_need_to_signal_on_read()")
Signed-off-by: Dexuan Cui 
Reported-by: Rolf Neugebauer 
Tested-by: Rolf Neugebauer 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: 
---

The patch also changes drivers/net/hyperv/netvsc.c (Haiyang Zhang
and Stephen Hemminger have known about this patch).

This is a must, because only applying the VMBus changes will
break the netvsc driver, so the patch should go through the
char-misc tree as a whole.

The changes to netvsc.c are small enough, and hence there should be
no conflict.

 drivers/hv/ring_buffer.c|  1 +
 drivers/net/hyperv/netvsc.c |  6 ++
 include/linux/hyperv.h  | 32 ++--
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index cd49cb1..308dbda 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -383,6 +383,7 @@ int hv_ringbuffer_read(struct vmbus_channel *channel,
return ret;
}
 
+   init_cached_read_index(channel);
next_read_location = hv_get_next_read_location(inring_info);
next_read_location = hv_copyfrom_ringbuffer(inring_info, ,
sizeof(desc),
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 5a1cc08..86e5749 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -1295,6 +1295,9 @@ void netvsc_channel_cb(void *context)
ndev = hv_get_drvdata(device);
buffer = get_per_channel_state(channel);
 
+   /* commit_rd_index() -> hv_signal_on_read() needs this. */
+   init_cached_read_index(channel);
+
do {
desc = get_next_pkt_raw(channel);
if (desc != NULL) {
@@ -1347,6 +1350,9 @@ void netvsc_channel_cb(void *context)
 
bufferlen = bytes_recvd;
}
+
+   init_cached_read_index(channel);
+
} while (1);
 
if (bufferlen > NETVSC_PACKET_SIZE)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 42fe43f..183efde 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -128,6 +128,7 @@ struct hv_ring_buffer_info {
u32 ring_data_startoffset;
u32 priv_write_index;
u32 priv_read_index;
+   u32 cached_read_index;
 };
 
 /*
@@ -180,6 +181,19 @@ static inline u32 hv_get_bytes_to_write(struct 
hv_ring_buffer_info *rbi)
return write;
 }
 
+static inline u32 hv_get_cached_bytes_to_write(
+   const struct hv_ring_buffer_info *rbi)
+{
+   u32 read_loc, write_loc, dsize, write;
+
+   dsize = rbi->ring_datasize;
+   read_loc = rbi->cached_read_index;
+   write_loc = rbi->ring_buffer->write_index;
+
+   write = write_loc >= read_loc ? dsize - (write_loc - read_loc) :
+   read_loc - write_loc;
+   return write;
+}
 /*
  * VMBUS version is 32 bit entity broken up into
  * two 16 bit quantities: major_number. minor_number.
@@ -1488,7 +1502,7 @@ hv_get_ring_buffer(struct hv_ring_buffer_info *ring_info)
 
 static inline  void hv_signal_on_read(struct vmbus_channel *channel)
 {
-   u32 cur_write_sz;
+   u32 cur_write_sz, cached_write_sz;
u32 pending_sz;
struct hv_ring_buffer_info *rbi = >inbound;
 
@@ -1512,12 +1526,24 @@ static inline  void hv_signal_on_read(struct 
vmbus_channel *channel)
 
cur_write_sz = hv_get_bytes_to_write(rbi);
 
-   if (cur_write_sz >= pending_sz)
+   if (cur_write_sz < pending_sz)
+   return;
+
+   cached_write_sz = hv_get_cached_bytes_to_write(rbi);
+   if (cached_write_sz < pending_sz)
vmbus_setevent(channel);
 
return;
 }
 
+static inline void
+init_cached_read_index(struct vmbus_channel *channel)
+{
+   struct hv_ring_buffer_info *rbi = >inbound;
+
+   rbi->cached_read_index = rbi->ring_buffer->read_index;
+}
+
 /*
  * An API to support in-place processing of incoming VMBUS packets.
  */
@@ -1569,6 +1595,8 @@ static inline void put_pkt_raw(struct vmbus_channel 
*channel,
  * This call commits the read index and potentially signals 

[PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[Dexuan Cui]

Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
hv_need_to_signal_on_read()")
added the proper mb(), but removed the test "prev_write_sz < pending_sz"
when making the signal decision.

As a result, the guest can signal the host unnecessarily,
and then the host can throttle the guest because the host
thinks the guest is buggy or malicious; finally the user
running stress test can perceive intermittent freeze of
the guest.

This patch brings back the test, and properly handles the
in-place consumption APIs used by NetVSC (see get_next_pkt_raw(),
put_pkt_raw() and commit_rd_index()).

Fixes: a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
hv_need_to_signal_on_read()")
Signed-off-by: Dexuan Cui 
Reported-by: Rolf Neugebauer 
Tested-by: Rolf Neugebauer 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: 
---

The patch also changes drivers/net/hyperv/netvsc.c (Haiyang Zhang
and Stephen Hemminger have known about this patch).

This is a must, because only applying the VMBus changes will
break the netvsc driver, so the patch should go through the
char-misc tree as a whole.

The changes to netvsc.c are small enough, and hence there should be
no conflict.

 drivers/hv/ring_buffer.c|  1 +
 drivers/net/hyperv/netvsc.c |  6 ++
 include/linux/hyperv.h  | 32 ++--
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index cd49cb1..308dbda 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -383,6 +383,7 @@ int hv_ringbuffer_read(struct vmbus_channel *channel,
return ret;
}
 
+   init_cached_read_index(channel);
next_read_location = hv_get_next_read_location(inring_info);
next_read_location = hv_copyfrom_ringbuffer(inring_info, ,
sizeof(desc),
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 5a1cc08..86e5749 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -1295,6 +1295,9 @@ void netvsc_channel_cb(void *context)
ndev = hv_get_drvdata(device);
buffer = get_per_channel_state(channel);
 
+   /* commit_rd_index() -> hv_signal_on_read() needs this. */
+   init_cached_read_index(channel);
+
do {
desc = get_next_pkt_raw(channel);
if (desc != NULL) {
@@ -1347,6 +1350,9 @@ void netvsc_channel_cb(void *context)
 
bufferlen = bytes_recvd;
}
+
+   init_cached_read_index(channel);
+
} while (1);
 
if (bufferlen > NETVSC_PACKET_SIZE)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 42fe43f..183efde 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -128,6 +128,7 @@ struct hv_ring_buffer_info {
u32 ring_data_startoffset;
u32 priv_write_index;
u32 priv_read_index;
+   u32 cached_read_index;
 };
 
 /*
@@ -180,6 +181,19 @@ static inline u32 hv_get_bytes_to_write(struct 
hv_ring_buffer_info *rbi)
return write;
 }
 
+static inline u32 hv_get_cached_bytes_to_write(
+   const struct hv_ring_buffer_info *rbi)
+{
+   u32 read_loc, write_loc, dsize, write;
+
+   dsize = rbi->ring_datasize;
+   read_loc = rbi->cached_read_index;
+   write_loc = rbi->ring_buffer->write_index;
+
+   write = write_loc >= read_loc ? dsize - (write_loc - read_loc) :
+   read_loc - write_loc;
+   return write;
+}
 /*
  * VMBUS version is 32 bit entity broken up into
  * two 16 bit quantities: major_number. minor_number.
@@ -1488,7 +1502,7 @@ hv_get_ring_buffer(struct hv_ring_buffer_info *ring_info)
 
 static inline  void hv_signal_on_read(struct vmbus_channel *channel)
 {
-   u32 cur_write_sz;
+   u32 cur_write_sz, cached_write_sz;
u32 pending_sz;
struct hv_ring_buffer_info *rbi = >inbound;
 
@@ -1512,12 +1526,24 @@ static inline  void hv_signal_on_read(struct 
vmbus_channel *channel)
 
cur_write_sz = hv_get_bytes_to_write(rbi);
 
-   if (cur_write_sz >= pending_sz)
+   if (cur_write_sz < pending_sz)
+   return;
+
+   cached_write_sz = hv_get_cached_bytes_to_write(rbi);
+   if (cached_write_sz < pending_sz)
vmbus_setevent(channel);
 
return;
 }
 
+static inline void
+init_cached_read_index(struct vmbus_channel *channel)
+{
+   struct hv_ring_buffer_info *rbi = >inbound;
+
+   rbi->cached_read_index = rbi->ring_buffer->read_index;
+}
+
 /*
  * An API to support in-place processing of incoming VMBUS packets.
  */
@@ -1569,6 +1595,8 @@ static inline void put_pkt_raw(struct vmbus_channel 
*channel,
  * This call commits the read index and potentially signals the host.
  * Here is the pattern for using the "in-place" consumption APIs:
  *
+ * init_cached_read_index();
+ *
  * while (get_next_pkt_raw() {
  * process the 

Re: [patch] samples/bpf: silence shift wrapping warning

[Alexei Starovoitov]

On Mon, Jan 23, 2017 at 5:27 AM, Arnaldo Carvalho de Melo
 wrote:
> Em Sun, Jan 22, 2017 at 02:51:25PM -0800, Alexei Starovoitov escreveu:
>> On Sat, Jan 21, 2017 at 07:51:43AM +0300, Dan Carpenter wrote:
>> > max_key is a value in the 0-63 range, so on 32 bit systems the shift
>> > could wrap.
>> >
>> > Signed-off-by: Dan Carpenter 
>>
>> Looks fine. I think 'net-next' is ok.
>
> I could process these patches, if that would help,

Thanks for the offer.
I don't think there will be conflicts with all the work happening in net-next,
but it's best to avoid even possibility of it when we can.
Dan,
can you please resend the patch cc-ing Dave and netdev ?
please mention [PATCH net-next] in the subject.

> - Arnaldo
>
>> Acked-by: Alexei Starovoitov 
>
>> > diff --git a/samples/bpf/lwt_len_hist_user.c 
>> > b/samples/bpf/lwt_len_hist_user.c
>> > index ec8f3bb..bd06eef 100644
>> > --- a/samples/bpf/lwt_len_hist_user.c
>> > +++ b/samples/bpf/lwt_len_hist_user.c
>> > @@ -68,7 +68,7 @@ int main(int argc, char **argv)
>> > for (i = 1; i <= max_key + 1; i++) {
>> > stars(starstr, data[i - 1], max_value, MAX_STARS);
>> > printf("%8ld -> %-8ld : %-8ld |%-*s|\n",
>> > -  (1l << i) >> 1, (1l << i) - 1, data[i - 1],
>> > +  (1ULL << i) >> 1, (1ULL << i) - 1, data[i - 1],
>> >MAX_STARS, starstr);
>> > }
>> >

Re: [patch] samples/bpf: silence shift wrapping warning

[Alexei Starovoitov]

On Mon, Jan 23, 2017 at 5:27 AM, Arnaldo Carvalho de Melo
 wrote:
> Em Sun, Jan 22, 2017 at 02:51:25PM -0800, Alexei Starovoitov escreveu:
>> On Sat, Jan 21, 2017 at 07:51:43AM +0300, Dan Carpenter wrote:
>> > max_key is a value in the 0-63 range, so on 32 bit systems the shift
>> > could wrap.
>> >
>> > Signed-off-by: Dan Carpenter 
>>
>> Looks fine. I think 'net-next' is ok.
>
> I could process these patches, if that would help,

Thanks for the offer.
I don't think there will be conflicts with all the work happening in net-next,
but it's best to avoid even possibility of it when we can.
Dan,
can you please resend the patch cc-ing Dave and netdev ?
please mention [PATCH net-next] in the subject.

> - Arnaldo
>
>> Acked-by: Alexei Starovoitov 
>
>> > diff --git a/samples/bpf/lwt_len_hist_user.c 
>> > b/samples/bpf/lwt_len_hist_user.c
>> > index ec8f3bb..bd06eef 100644
>> > --- a/samples/bpf/lwt_len_hist_user.c
>> > +++ b/samples/bpf/lwt_len_hist_user.c
>> > @@ -68,7 +68,7 @@ int main(int argc, char **argv)
>> > for (i = 1; i <= max_key + 1; i++) {
>> > stars(starstr, data[i - 1], max_value, MAX_STARS);
>> > printf("%8ld -> %-8ld : %-8ld |%-*s|\n",
>> > -  (1l << i) >> 1, (1l << i) - 1, data[i - 1],
>> > +  (1ULL << i) >> 1, (1ULL << i) - 1, data[i - 1],
>> >MAX_STARS, starstr);
>> > }
>> >

Re: [PATCH v3 1/3] of: Support parsing phandle argument lists through a nexus node

[Frank Rowand]

Hi Stephen,

Sorry I did not get to v1 and v2 in a timely manner.


On 01/23/17 12:48, Stephen Boyd wrote:
> Platforms like 96boards have a standardized connector/expansion
> slot that exposes signals like GPIOs to expansion boards in an
> SoC agnostic way. We'd like the DT overlays for the expansion
> boards to be written once without knowledge of the SoC on the
> other side of the connector. This avoids the unscalable
> combinatorial explosion of a different DT overlay for each
> expansion board and SoC pair.
> 
> We need a way to describe the GPIOs routed through the connector
> in an SoC agnostic way. Let's introduce nexus property parsing
> into the OF core to do this. This is largely based on the
> interrupt nexus support we already have. This allows us to remap
> a phandle list in a consumer node (e.g. reset-gpios) through a
> connector in a generic way (e.g. via gpio-map). Do this in a
> generic routine so that we can remap any sort of variable length
> phandle list.
> 
> Taking GPIOs as an example, the connector would be a GPIO nexus,
> supporting the remapping of a GPIO specifier space to multiple
> GPIO providers on the SoC. DT would look as shown below, where
> 'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
> expansion port where boards can be plugged in, and
> 'expansion_device' is a device on the expansion board.
> 
>   soc {
>   soc_gpio1: gpio-controller1 {
>   #gpio-cells = <2>;
>   };
> 
>   soc_gpio2: gpio-controller2 {
>   #gpio-cells = <2>;
>   };
>   };
> 
>   connector: connector {
>   #gpio-cells = <2>;
>   gpio-map = <0 0 _gpio1 1 0>,
>  <1 0 _gpio2 4 0>,
>  <2 0 _gpio1 3 0>,
>  <3 0 _gpio2 2 0>;
>   gpio-map-mask = <0xf 0x0>;
>   gpio-map-pass-thru = <0x0 0x1>
>   };
> 
>   expansion_device {
>   reset-gpios = < 2 GPIO_ACTIVE_LOW>;
>   };

The how to architect connectors and plugs threads fell asleep before
coming to a resolution.  We need to revive that discussion.

One of the concepts of the plug and connector architecture is that
a main board may contain multiple connectors of the same type (or
different types, but the same type is sufficient for this discussion).

The node describing the card that plugs into one of the connectors
does not know the phandle of the connector it is going to be
connected to.  Some other mechanism is provided to allow a card
to be plugged into any of the available connectors.  If there are
two identical cards plugged into two connectors, then both cards
have the same exact device tree node.  But some mechanism will
exist to resolve (or "link") the two card nodes to the different
connector nodes.

As a result of this, in the above example the reset-gpios property
in the node 'expansion_device' can not contain ''.  The
concept of  belongs to the entire expansion_device node,
not to individual properties within the node.

I'm not sure where this puts us.  I'm thinking

-Frank

> 
> The GPIO core would use of_parse_phandle_with_args_map() instead
> of of_parse_phandle_with_args() and arrive at the same type of
> result, a phandle and argument list. The difference is that the
> phandle and arguments will be remapped through the nexus node to
> the underlying SoC GPIO controller node. In the example above,
> we would remap 'reset-gpios' from < 2 GPIO_ACTIVE_LOW>
> to <_gpio1 3 GPIO_ACTIVE_LOW>.
> 
> Cc: Pantelis Antoniou 
> Cc: Linus Walleij 
> Cc: Mark Brown 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/of/base.c  | 184 
> +
>  include/linux/of.h |  12 
>  2 files changed, 196 insertions(+)

< snip >

Re: [PATCH v3 1/3] of: Support parsing phandle argument lists through a nexus node

[Frank Rowand]

Hi Stephen,

Sorry I did not get to v1 and v2 in a timely manner.


On 01/23/17 12:48, Stephen Boyd wrote:
> Platforms like 96boards have a standardized connector/expansion
> slot that exposes signals like GPIOs to expansion boards in an
> SoC agnostic way. We'd like the DT overlays for the expansion
> boards to be written once without knowledge of the SoC on the
> other side of the connector. This avoids the unscalable
> combinatorial explosion of a different DT overlay for each
> expansion board and SoC pair.
> 
> We need a way to describe the GPIOs routed through the connector
> in an SoC agnostic way. Let's introduce nexus property parsing
> into the OF core to do this. This is largely based on the
> interrupt nexus support we already have. This allows us to remap
> a phandle list in a consumer node (e.g. reset-gpios) through a
> connector in a generic way (e.g. via gpio-map). Do this in a
> generic routine so that we can remap any sort of variable length
> phandle list.
> 
> Taking GPIOs as an example, the connector would be a GPIO nexus,
> supporting the remapping of a GPIO specifier space to multiple
> GPIO providers on the SoC. DT would look as shown below, where
> 'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
> expansion port where boards can be plugged in, and
> 'expansion_device' is a device on the expansion board.
> 
>   soc {
>   soc_gpio1: gpio-controller1 {
>   #gpio-cells = <2>;
>   };
> 
>   soc_gpio2: gpio-controller2 {
>   #gpio-cells = <2>;
>   };
>   };
> 
>   connector: connector {
>   #gpio-cells = <2>;
>   gpio-map = <0 0 _gpio1 1 0>,
>  <1 0 _gpio2 4 0>,
>  <2 0 _gpio1 3 0>,
>  <3 0 _gpio2 2 0>;
>   gpio-map-mask = <0xf 0x0>;
>   gpio-map-pass-thru = <0x0 0x1>
>   };
> 
>   expansion_device {
>   reset-gpios = < 2 GPIO_ACTIVE_LOW>;
>   };

The how to architect connectors and plugs threads fell asleep before
coming to a resolution.  We need to revive that discussion.

One of the concepts of the plug and connector architecture is that
a main board may contain multiple connectors of the same type (or
different types, but the same type is sufficient for this discussion).

The node describing the card that plugs into one of the connectors
does not know the phandle of the connector it is going to be
connected to.  Some other mechanism is provided to allow a card
to be plugged into any of the available connectors.  If there are
two identical cards plugged into two connectors, then both cards
have the same exact device tree node.  But some mechanism will
exist to resolve (or "link") the two card nodes to the different
connector nodes.

As a result of this, in the above example the reset-gpios property
in the node 'expansion_device' can not contain ''.  The
concept of  belongs to the entire expansion_device node,
not to individual properties within the node.

I'm not sure where this puts us.  I'm thinking

-Frank

> 
> The GPIO core would use of_parse_phandle_with_args_map() instead
> of of_parse_phandle_with_args() and arrive at the same type of
> result, a phandle and argument list. The difference is that the
> phandle and arguments will be remapped through the nexus node to
> the underlying SoC GPIO controller node. In the example above,
> we would remap 'reset-gpios' from < 2 GPIO_ACTIVE_LOW>
> to <_gpio1 3 GPIO_ACTIVE_LOW>.
> 
> Cc: Pantelis Antoniou 
> Cc: Linus Walleij 
> Cc: Mark Brown 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/of/base.c  | 184 
> +
>  include/linux/of.h |  12 
>  2 files changed, 196 insertions(+)

< snip >

Re: [GIT PULL] Immutable branch between MFD, ARM, IIO and PWM due for the v4.10 merge window

[Olof Johansson]

Hi Lee,

On Mon, Jan 23, 2017 at 4:12 AM, Lee Jones  wrote:
> Arm, IIO and PWM Maintainers,
>
> Enjoy!
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
>   Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-arm-iio-pwm-v4.10
>
> for you to fetch changes up to 94df449273475980a39f1bf47f1e3d2b07ce6577:
>
>   ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco (2017-01-23 
> 12:06:28 +)
>
> 
> Immutable branch between MFD, ARM, IIO and PWM due for the v4.10 merge window
>
> 
> Benjamin Gaignard (8):
>   dt-bindings: mfd: Add bindings for STM32 Timers driver
>   mfd: Add STM32 Timers driver
>   dt-bindings: pwm: Add STM32 bindings
>   pwm: Add driver for STM32 plaftorm
>   iio: Add bindings for STM32 timer trigger driver
>   iio: Add STM32 timer trigger driver
>   ARM: dts: stm32: add Timers driver for stm32f429 MCU
>   ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
>
>  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  29 ++
>  .../bindings/iio/timer/stm32-timer-trigger.txt |  23 ++
>  .../devicetree/bindings/mfd/stm32-timers.txt   |  46 +++
>  .../devicetree/bindings/pwm/pwm-stm32.txt  |  35 ++
>  arch/arm/boot/dts/stm32f429.dtsi   | 275 ++
>  arch/arm/boot/dts/stm32f469-disco.dts  |  28 ++
>  drivers/iio/trigger/Kconfig|   9 +
>  drivers/iio/trigger/Makefile   |   1 +
>  drivers/iio/trigger/stm32-timer-trigger.c  | 342 ++
>  drivers/mfd/Kconfig|  11 +
>  drivers/mfd/Makefile   |   2 +
>  drivers/mfd/stm32-timers.c |  80 +
>  drivers/pwm/Kconfig|   9 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-stm32.c| 398 
> +
>  include/linux/iio/timer/stm32-timer-trigger.h  |  62 
>  include/linux/mfd/stm32-timers.h   |  71 
>  17 files changed, 1422 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>  create mode 100644 
> Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>  create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c
>  create mode 100644 drivers/mfd/stm32-timers.c
>  create mode 100644 drivers/pwm/pwm-stm32.c
>  create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
>  create mode 100644 include/linux/mfd/stm32-timers.h

May I ask why you're creating an immutable branch of all this contents?

We should get the dts/dtsi contents like usual from any maintainer;
just the DT updates in a branch.

Sometimes (but less and less due to us discouraging the use) we need
an immutable branch that includes dt-include updates. But I don't see
any of those in this contents.

I.e. I guess I can see the need between mfd and downstream trees
(iio/pwm), but not the DTS contents at this time. Or am I missing
something here?

-Olof

Re: [GIT PULL] Immutable branch between MFD, ARM, IIO and PWM due for the v4.10 merge window

[Olof Johansson]

Hi Lee,

On Mon, Jan 23, 2017 at 4:12 AM, Lee Jones  wrote:
> Arm, IIO and PWM Maintainers,
>
> Enjoy!
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
>   Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-arm-iio-pwm-v4.10
>
> for you to fetch changes up to 94df449273475980a39f1bf47f1e3d2b07ce6577:
>
>   ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco (2017-01-23 
> 12:06:28 +)
>
> 
> Immutable branch between MFD, ARM, IIO and PWM due for the v4.10 merge window
>
> 
> Benjamin Gaignard (8):
>   dt-bindings: mfd: Add bindings for STM32 Timers driver
>   mfd: Add STM32 Timers driver
>   dt-bindings: pwm: Add STM32 bindings
>   pwm: Add driver for STM32 plaftorm
>   iio: Add bindings for STM32 timer trigger driver
>   iio: Add STM32 timer trigger driver
>   ARM: dts: stm32: add Timers driver for stm32f429 MCU
>   ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
>
>  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  29 ++
>  .../bindings/iio/timer/stm32-timer-trigger.txt |  23 ++
>  .../devicetree/bindings/mfd/stm32-timers.txt   |  46 +++
>  .../devicetree/bindings/pwm/pwm-stm32.txt  |  35 ++
>  arch/arm/boot/dts/stm32f429.dtsi   | 275 ++
>  arch/arm/boot/dts/stm32f469-disco.dts  |  28 ++
>  drivers/iio/trigger/Kconfig|   9 +
>  drivers/iio/trigger/Makefile   |   1 +
>  drivers/iio/trigger/stm32-timer-trigger.c  | 342 ++
>  drivers/mfd/Kconfig|  11 +
>  drivers/mfd/Makefile   |   2 +
>  drivers/mfd/stm32-timers.c |  80 +
>  drivers/pwm/Kconfig|   9 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-stm32.c| 398 
> +
>  include/linux/iio/timer/stm32-timer-trigger.h  |  62 
>  include/linux/mfd/stm32-timers.h   |  71 
>  17 files changed, 1422 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>  create mode 100644 
> Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>  create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c
>  create mode 100644 drivers/mfd/stm32-timers.c
>  create mode 100644 drivers/pwm/pwm-stm32.c
>  create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
>  create mode 100644 include/linux/mfd/stm32-timers.h

May I ask why you're creating an immutable branch of all this contents?

We should get the dts/dtsi contents like usual from any maintainer;
just the DT updates in a branch.

Sometimes (but less and less due to us discouraging the use) we need
an immutable branch that includes dt-include updates. But I don't see
any of those in this contents.

I.e. I guess I can see the need between mfd and downstream trees
(iio/pwm), but not the DTS contents at this time. Or am I missing
something here?

-Olof

[PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

[zhichang.yuan]

Low-pin-count interface is integrated into some SoCs. The accesses to those
peripherals under LPC make use of I/O ports rather than the memory mapped I/O.

To drive these devices, this patch introduces a method named indirect-IO.
In this method the in/out() accessor in include/asm-generic/io.h will be
redefined. When upper layer drivers call in/out() with those known legacy port
addresses to access the peripherals, the I/O operations will be routed to the
right hooks which are registered specific to the host device, such as LPC.
Then the hardware relevant manupulations are finished by the corresponding
host.

According to the comments on V5, this patch adds a common indirect-IO driver
which support this I/O indirection to the generic directory.

In the later pathches, some host-relevant drivers are implemented to support
the specific I/O hooks and register them.
Based on these, the upper layer drivers which depend on in/out() can work well
without any extra work or any changes.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: John Garry 
---
 include/asm-generic/io.h |  50 
 include/linux/extio.h|  85 +++
 include/linux/io.h   |   1 +
 lib/Kconfig  |   8 +++
 lib/Makefile |   2 +
 lib/extio.c  | 147 +++
 6 files changed, 293 insertions(+)
 create mode 100644 include/linux/extio.h
 create mode 100644 lib/extio.c

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ef015e..c0d6db1 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -21,6 +21,8 @@
 
 #include 
 
+#include 
+
 #ifndef mmiowb
 #define mmiowb() do {} while (0)
 #endif
@@ -358,51 +360,75 @@ static inline void writesq(volatile void __iomem *addr, 
const void *buffer,
  */
 
 #ifndef inb
+#ifdef CONFIG_INDIRECT_PIO
+#define inb extio_inb
+#else
 #define inb inb
 static inline u8 inb(unsigned long addr)
 {
return readb(PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef inw
+#ifdef CONFIG_INDIRECT_PIO
+#define inw extio_inw
+#else
 #define inw inw
 static inline u16 inw(unsigned long addr)
 {
return readw(PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef inl
+#ifdef CONFIG_INDIRECT_PIO
+#define inl extio_inl
+#else
 #define inl inl
 static inline u32 inl(unsigned long addr)
 {
return readl(PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outb
+#ifdef CONFIG_INDIRECT_PIO
+#define outb extio_outb
+#else
 #define outb outb
 static inline void outb(u8 value, unsigned long addr)
 {
writeb(value, PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outw
+#ifdef CONFIG_INDIRECT_PIO
+#define outw extio_outw
+#else
 #define outw outw
 static inline void outw(u16 value, unsigned long addr)
 {
writew(value, PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outl
+#ifdef CONFIG_INDIRECT_PIO
+#define outl extio_outl
+#else
 #define outl outl
 static inline void outl(u32 value, unsigned long addr)
 {
writel(value, PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef inb_p
@@ -459,54 +485,78 @@ static inline void outl_p(u32 value, unsigned long addr)
  */
 
 #ifndef insb
+#ifdef CONFIG_INDIRECT_PIO
+#define insb extio_insb
+#else
 #define insb insb
 static inline void insb(unsigned long addr, void *buffer, unsigned int count)
 {
readsb(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef insw
+#ifdef CONFIG_INDIRECT_PIO
+#define insw extio_insw
+#else
 #define insw insw
 static inline void insw(unsigned long addr, void *buffer, unsigned int count)
 {
readsw(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef insl
+#ifdef CONFIG_INDIRECT_PIO
+#define insl extio_insl
+#else
 #define insl insl
 static inline void insl(unsigned long addr, void *buffer, unsigned int count)
 {
readsl(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outsb
+#ifdef CONFIG_INDIRECT_PIO
+#define outsb extio_outsb
+#else
 #define outsb outsb
 static inline void outsb(unsigned long addr, const void *buffer,
 unsigned int count)
 {
writesb(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outsw
+#ifdef CONFIG_INDIRECT_PIO
+#define outsw extio_outsw
+#else
 #define outsw outsw
 static inline void outsw(unsigned long addr, const void *buffer,
 unsigned int count)
 {
writesw(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outsl
+#ifdef CONFIG_INDIRECT_PIO
+#define outsl extio_outsl
+#else
 #define outsl outsl
 static inline void outsl(unsigned 

[PATCH V6 3/5] OF: Add missing I/O range exception for indirect-IO devices

[zhichang.yuan]

There are some special ISA/LPC devices that work on a specific I/O range where
it is not correct to specify a 'ranges' property in DTS parent node as cpu
addresses translated from DTS node are only for memory space on some
architectures, such as Arm64. Without the parent 'ranges' property, current
of_translate_address() return an error.
Here we add special handlings for this case.
During the OF address translation, some checkings will be perfromed to
identify whether the device node is registered as indirect-IO. If yes, the I/O
translation will be done in a different way from that one of PCI MMIO.
In this way, the I/O 'reg' property of the special ISA/LPC devices will be
parsed correctly.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: Arnd Bergmann 
---
 drivers/of/address.c | 87 ++--
 1 file changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index d85d228..6a424ec 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -545,9 +545,14 @@ static int of_translate_one(struct device_node *parent, 
struct of_bus *bus,
  * that translation is impossible (that is we are not dealing with a value
  * that can be mapped to a cpu physical address). This is not really specified
  * that way, but this is traditionally the way IBM at least do things
+ *
+ * Whenever the translation fails, the *host pointer will be set to the
+ * device that lacks a tranlation, and the return code is relative to
+ * that node.
  */
 static u64 __of_translate_address(struct device_node *dev,
- const __be32 *in_addr, const char *rprop)
+ const __be32 *in_addr, const char *rprop,
+ struct device_node **host)
 {
struct device_node *parent = NULL;
struct of_bus *bus, *pbus;
@@ -560,6 +565,7 @@ static u64 __of_translate_address(struct device_node *dev,
/* Increase refcount at current level */
of_node_get(dev);
 
+   *host = NULL;
/* Get parent & match bus type */
parent = of_get_parent(dev);
if (parent == NULL)
@@ -592,6 +598,18 @@ static u64 __of_translate_address(struct device_node *dev,
break;
}
 
+   /*
+* For indirectIO device which has no ranges property, get
+* the address from reg directly.
+*/
+   if (extio_find_node(>fwnode)) {
+   result = of_read_number(addr + 1, na - 1);
+   pr_debug("indirectIO matched(%s) 0x%llx\n",
+   of_node_full_name(dev), result);
+   *host = of_node_get(dev);
+   break;
+   }
+
/* Get new parent bus and counts */
pbus = of_match_bus(parent);
pbus->count_cells(dev, , );
@@ -624,13 +642,32 @@ static u64 __of_translate_address(struct device_node *dev,
 
 u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
 {
-   return __of_translate_address(dev, in_addr, "ranges");
+   struct device_node *host;
+   u64 ret;
+
+   ret =  __of_translate_address(dev, in_addr, "ranges", );
+   if (host) {
+   of_node_put(host);
+   return OF_BAD_ADDR;
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL(of_translate_address);
 
 u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
 {
-   return __of_translate_address(dev, in_addr, "dma-ranges");
+   struct device_node *host;
+   u64 ret;
+
+   ret = __of_translate_address(dev, in_addr, "dma-ranges", );
+
+   if (host) {
+   of_node_put(host);
+   return OF_BAD_ADDR;
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL(of_translate_dma_address);
 
@@ -672,29 +709,47 @@ const __be32 *of_get_address(struct device_node *dev, int 
index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
+static u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr)
+{
+   u64 taddr;
+   unsigned long port;
+   struct device_node *host;
+
+   taddr = __of_translate_address(dev, in_addr, "ranges", );
+   if (host) {
+   /* host specific port access */
+   port = extio_translate(>fwnode, taddr);
+   of_node_put(host);
+   } else {
+   /* memory mapped I/O range */
+   port = pci_address_to_pio(taddr);
+   }
+
+   if (port == (unsigned long)-1)
+   return OF_BAD_ADDR;
+
+   return port;
+}
+
 static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
 {
u64 taddr;
 
-   if ((flags & 

[PATCH V6 3/5] OF: Add missing I/O range exception for indirect-IO devices

[zhichang.yuan]

There are some special ISA/LPC devices that work on a specific I/O range where
it is not correct to specify a 'ranges' property in DTS parent node as cpu
addresses translated from DTS node are only for memory space on some
architectures, such as Arm64. Without the parent 'ranges' property, current
of_translate_address() return an error.
Here we add special handlings for this case.
During the OF address translation, some checkings will be perfromed to
identify whether the device node is registered as indirect-IO. If yes, the I/O
translation will be done in a different way from that one of PCI MMIO.
In this way, the I/O 'reg' property of the special ISA/LPC devices will be
parsed correctly.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: Arnd Bergmann 
---
 drivers/of/address.c | 87 ++--
 1 file changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index d85d228..6a424ec 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -545,9 +545,14 @@ static int of_translate_one(struct device_node *parent, 
struct of_bus *bus,
  * that translation is impossible (that is we are not dealing with a value
  * that can be mapped to a cpu physical address). This is not really specified
  * that way, but this is traditionally the way IBM at least do things
+ *
+ * Whenever the translation fails, the *host pointer will be set to the
+ * device that lacks a tranlation, and the return code is relative to
+ * that node.
  */
 static u64 __of_translate_address(struct device_node *dev,
- const __be32 *in_addr, const char *rprop)
+ const __be32 *in_addr, const char *rprop,
+ struct device_node **host)
 {
struct device_node *parent = NULL;
struct of_bus *bus, *pbus;
@@ -560,6 +565,7 @@ static u64 __of_translate_address(struct device_node *dev,
/* Increase refcount at current level */
of_node_get(dev);
 
+   *host = NULL;
/* Get parent & match bus type */
parent = of_get_parent(dev);
if (parent == NULL)
@@ -592,6 +598,18 @@ static u64 __of_translate_address(struct device_node *dev,
break;
}
 
+   /*
+* For indirectIO device which has no ranges property, get
+* the address from reg directly.
+*/
+   if (extio_find_node(>fwnode)) {
+   result = of_read_number(addr + 1, na - 1);
+   pr_debug("indirectIO matched(%s) 0x%llx\n",
+   of_node_full_name(dev), result);
+   *host = of_node_get(dev);
+   break;
+   }
+
/* Get new parent bus and counts */
pbus = of_match_bus(parent);
pbus->count_cells(dev, , );
@@ -624,13 +642,32 @@ static u64 __of_translate_address(struct device_node *dev,
 
 u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
 {
-   return __of_translate_address(dev, in_addr, "ranges");
+   struct device_node *host;
+   u64 ret;
+
+   ret =  __of_translate_address(dev, in_addr, "ranges", );
+   if (host) {
+   of_node_put(host);
+   return OF_BAD_ADDR;
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL(of_translate_address);
 
 u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
 {
-   return __of_translate_address(dev, in_addr, "dma-ranges");
+   struct device_node *host;
+   u64 ret;
+
+   ret = __of_translate_address(dev, in_addr, "dma-ranges", );
+
+   if (host) {
+   of_node_put(host);
+   return OF_BAD_ADDR;
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL(of_translate_dma_address);
 
@@ -672,29 +709,47 @@ const __be32 *of_get_address(struct device_node *dev, int 
index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
+static u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr)
+{
+   u64 taddr;
+   unsigned long port;
+   struct device_node *host;
+
+   taddr = __of_translate_address(dev, in_addr, "ranges", );
+   if (host) {
+   /* host specific port access */
+   port = extio_translate(>fwnode, taddr);
+   of_node_put(host);
+   } else {
+   /* memory mapped I/O range */
+   port = pci_address_to_pio(taddr);
+   }
+
+   if (port == (unsigned long)-1)
+   return OF_BAD_ADDR;
+
+   return port;
+}
+
 static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
 {
u64 taddr;
 
-   if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
+   if (flags & 

[PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

[zhichang.yuan]

Low-pin-count interface is integrated into some SoCs. The accesses to those
peripherals under LPC make use of I/O ports rather than the memory mapped I/O.

To drive these devices, this patch introduces a method named indirect-IO.
In this method the in/out() accessor in include/asm-generic/io.h will be
redefined. When upper layer drivers call in/out() with those known legacy port
addresses to access the peripherals, the I/O operations will be routed to the
right hooks which are registered specific to the host device, such as LPC.
Then the hardware relevant manupulations are finished by the corresponding
host.

According to the comments on V5, this patch adds a common indirect-IO driver
which support this I/O indirection to the generic directory.

In the later pathches, some host-relevant drivers are implemented to support
the specific I/O hooks and register them.
Based on these, the upper layer drivers which depend on in/out() can work well
without any extra work or any changes.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: John Garry 
---
 include/asm-generic/io.h |  50 
 include/linux/extio.h|  85 +++
 include/linux/io.h   |   1 +
 lib/Kconfig  |   8 +++
 lib/Makefile |   2 +
 lib/extio.c  | 147 +++
 6 files changed, 293 insertions(+)
 create mode 100644 include/linux/extio.h
 create mode 100644 lib/extio.c

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ef015e..c0d6db1 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -21,6 +21,8 @@
 
 #include 
 
+#include 
+
 #ifndef mmiowb
 #define mmiowb() do {} while (0)
 #endif
@@ -358,51 +360,75 @@ static inline void writesq(volatile void __iomem *addr, 
const void *buffer,
  */
 
 #ifndef inb
+#ifdef CONFIG_INDIRECT_PIO
+#define inb extio_inb
+#else
 #define inb inb
 static inline u8 inb(unsigned long addr)
 {
return readb(PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef inw
+#ifdef CONFIG_INDIRECT_PIO
+#define inw extio_inw
+#else
 #define inw inw
 static inline u16 inw(unsigned long addr)
 {
return readw(PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef inl
+#ifdef CONFIG_INDIRECT_PIO
+#define inl extio_inl
+#else
 #define inl inl
 static inline u32 inl(unsigned long addr)
 {
return readl(PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outb
+#ifdef CONFIG_INDIRECT_PIO
+#define outb extio_outb
+#else
 #define outb outb
 static inline void outb(u8 value, unsigned long addr)
 {
writeb(value, PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outw
+#ifdef CONFIG_INDIRECT_PIO
+#define outw extio_outw
+#else
 #define outw outw
 static inline void outw(u16 value, unsigned long addr)
 {
writew(value, PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outl
+#ifdef CONFIG_INDIRECT_PIO
+#define outl extio_outl
+#else
 #define outl outl
 static inline void outl(u32 value, unsigned long addr)
 {
writel(value, PCI_IOBASE + addr);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef inb_p
@@ -459,54 +485,78 @@ static inline void outl_p(u32 value, unsigned long addr)
  */
 
 #ifndef insb
+#ifdef CONFIG_INDIRECT_PIO
+#define insb extio_insb
+#else
 #define insb insb
 static inline void insb(unsigned long addr, void *buffer, unsigned int count)
 {
readsb(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef insw
+#ifdef CONFIG_INDIRECT_PIO
+#define insw extio_insw
+#else
 #define insw insw
 static inline void insw(unsigned long addr, void *buffer, unsigned int count)
 {
readsw(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef insl
+#ifdef CONFIG_INDIRECT_PIO
+#define insl extio_insl
+#else
 #define insl insl
 static inline void insl(unsigned long addr, void *buffer, unsigned int count)
 {
readsl(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outsb
+#ifdef CONFIG_INDIRECT_PIO
+#define outsb extio_outsb
+#else
 #define outsb outsb
 static inline void outsb(unsigned long addr, const void *buffer,
 unsigned int count)
 {
writesb(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outsw
+#ifdef CONFIG_INDIRECT_PIO
+#define outsw extio_outsw
+#else
 #define outsw outsw
 static inline void outsw(unsigned long addr, const void *buffer,
 unsigned int count)
 {
writesw(PCI_IOBASE + addr, buffer, count);
 }
+#endif /* CONFIG_INDIRECT_PIO */
 #endif
 
 #ifndef outsl
+#ifdef CONFIG_INDIRECT_PIO
+#define outsl extio_outsl
+#else
 #define outsl outsl
 static inline void outsl(unsigned long addr, const void *buffer,
 unsigned int count)
 {

[PATCH V6 0/5] LPC: legacy ISA I/O support

[zhichang.yuan]

This patch supports the IPMI-bt device attached to the Low-Pin-Count interface
implemented on Hisilicon Hip06/Hip07 SoC.
---
| LPC host|
| |
---
 |
_V___LPC
  |   |
  V   V
 
 |  BT(ipmi)|
 

When master accesses those peripherals beneath the Hip06 LPC, a specific LPC
driver is needed to make LPC host generate the standard LPC I/O cycles with
the target peripherals'I/O port addresses. But on curent arm64 world, there is
no real I/O accesses. All the I/O operations through in/out pair are based on
MMIO which is not satisfied the I/O mechanism on Hip06 LPC.
To solve this issue and keep the relevant existing peripherals' driver
untouched, this patch set redefines the in/out() pair to support both the IO
operations for Hip06 LPC and the original MMIO. The way specific to Hip06 is
named as indirect-IO in this patchset.

Changes from V5:
  - Made the extio driver more generic and locate in lib/;
  - Supported multiple indirect-IO bus instances;
  - Extended the pci_register_io_range() to support indirect-IO, then dropped
  the I/O reservation used in previous patchset;
  - Reimplemented the ACPI LPC support;
  - Fixed some bugs, including the compile error on other archs, the module
  building failure found by Ming Lei, etc;

Changes from V4:
  - Some revises based on the comments from Bjorn, Rob on V4;
  - Fixed the compile error on some platforms, such as openrisc;

Changes from V3:
  - UART support deferred to a separate patchset; This patchset only support
  ipmi device under LPC;
  - LPC bus I/O range is fixed to 0 ~ (PCIBIOS_MIN_IO - 1), which is separeted
  from PCI/PCIE PIO space;
  - Based on Arnd's remarks, removed the ranges property from Hip06 lpc dts and
  added a new fixup function, of_isa_indirect_io(), to get the I/O address
  directly from LPC dts configurations;
  - Support in(w,l)/out(w,l) for Hip06 lpc I/O;
  - Decouple the header file dependency on the gerenic io.h by defining in/out
  as normal functions in c file;
  - removed unused macro definitions in the LPC driver;

Changes from V2:
  - Support the PIO retrieval from the linux PIO generated by
  pci_address_to_pio. This method replace the 4K PIO reservation in V2;
  - Support the flat-tree earlycon;
  - Some revises based on Arnd's remarks;
  - Make sure the linux PIO range allocated to Hip06 LPC peripherals starts
  from non-ZERO;

Changes from V1:
  - Support the ACPI LPC device;
  - Optimize the dts LPC driver in ISA compatible mode;
  - Reserve the IO range below 4K in avoid the possible conflict with PCI host
  IO ranges;
  - Support the LPC uart and relevant earlycon;


v5 thread here: https://lkml.org/lkml/2016/11/7/955
v4 thread here: https://lkml.org/lkml/2016/10/20/149
v3 thread here: https://lkml.org/lkml/2016/9/14/326
v2 thread here: https://lkml.org/lkml/2016/9/7/356
v1 thread here: https://lkml.org/lkml/2015/12/29/154


Signed-off-by: Zhichang Yuan 
zhichang.yuan (5):
  LIB: Indirect ISA/LPC port IO introduced
  PCI: Adapt pci_register_io_range() for indirect-IO and PCI I/O
translation
  OF: Add missing I/O range exception for indirect-IO devices
  LPC: Support the device-tree LPC host on Hip06/Hip07
  LPC: Add the ACPI LPC support

 .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
 MAINTAINERS|   9 +
 arch/arm64/boot/dts/hisilicon/hip06-d03.dts|   4 +
 arch/arm64/boot/dts/hisilicon/hip06.dtsi   |  14 +
 drivers/acpi/pci_root.c|  12 +-
 drivers/bus/Kconfig|   8 +
 drivers/bus/Makefile   |   1 +
 drivers/bus/hisi_lpc.c | 625 +
 drivers/of/address.c   |  95 +++-
 drivers/pci/pci.c  |  44 +-
 include/asm-generic/io.h   |  50 ++
 include/linux/extio.h  |  89 +++
 include/linux/io.h |   1 +
 include/linux/pci.h|   7 +-
 lib/Kconfig|   8 +
 lib/Makefile   |   2 +
 lib/extio.c| 375 +
 17 files changed, 1342 insertions(+), 35 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
 create mode 100644 drivers/bus/hisi_lpc.c
 create mode 100644 include/linux/extio.h
 create mode 100644 lib/extio.c

-- 
1.9.1

[PATCH V6 0/5] LPC: legacy ISA I/O support

[zhichang.yuan]

This patch supports the IPMI-bt device attached to the Low-Pin-Count interface
implemented on Hisilicon Hip06/Hip07 SoC.
---
| LPC host|
| |
---
 |
_V___LPC
  |   |
  V   V
 
 |  BT(ipmi)|
 

When master accesses those peripherals beneath the Hip06 LPC, a specific LPC
driver is needed to make LPC host generate the standard LPC I/O cycles with
the target peripherals'I/O port addresses. But on curent arm64 world, there is
no real I/O accesses. All the I/O operations through in/out pair are based on
MMIO which is not satisfied the I/O mechanism on Hip06 LPC.
To solve this issue and keep the relevant existing peripherals' driver
untouched, this patch set redefines the in/out() pair to support both the IO
operations for Hip06 LPC and the original MMIO. The way specific to Hip06 is
named as indirect-IO in this patchset.

Changes from V5:
  - Made the extio driver more generic and locate in lib/;
  - Supported multiple indirect-IO bus instances;
  - Extended the pci_register_io_range() to support indirect-IO, then dropped
  the I/O reservation used in previous patchset;
  - Reimplemented the ACPI LPC support;
  - Fixed some bugs, including the compile error on other archs, the module
  building failure found by Ming Lei, etc;

Changes from V4:
  - Some revises based on the comments from Bjorn, Rob on V4;
  - Fixed the compile error on some platforms, such as openrisc;

Changes from V3:
  - UART support deferred to a separate patchset; This patchset only support
  ipmi device under LPC;
  - LPC bus I/O range is fixed to 0 ~ (PCIBIOS_MIN_IO - 1), which is separeted
  from PCI/PCIE PIO space;
  - Based on Arnd's remarks, removed the ranges property from Hip06 lpc dts and
  added a new fixup function, of_isa_indirect_io(), to get the I/O address
  directly from LPC dts configurations;
  - Support in(w,l)/out(w,l) for Hip06 lpc I/O;
  - Decouple the header file dependency on the gerenic io.h by defining in/out
  as normal functions in c file;
  - removed unused macro definitions in the LPC driver;

Changes from V2:
  - Support the PIO retrieval from the linux PIO generated by
  pci_address_to_pio. This method replace the 4K PIO reservation in V2;
  - Support the flat-tree earlycon;
  - Some revises based on Arnd's remarks;
  - Make sure the linux PIO range allocated to Hip06 LPC peripherals starts
  from non-ZERO;

Changes from V1:
  - Support the ACPI LPC device;
  - Optimize the dts LPC driver in ISA compatible mode;
  - Reserve the IO range below 4K in avoid the possible conflict with PCI host
  IO ranges;
  - Support the LPC uart and relevant earlycon;


v5 thread here: https://lkml.org/lkml/2016/11/7/955
v4 thread here: https://lkml.org/lkml/2016/10/20/149
v3 thread here: https://lkml.org/lkml/2016/9/14/326
v2 thread here: https://lkml.org/lkml/2016/9/7/356
v1 thread here: https://lkml.org/lkml/2015/12/29/154


Signed-off-by: Zhichang Yuan 
zhichang.yuan (5):
  LIB: Indirect ISA/LPC port IO introduced
  PCI: Adapt pci_register_io_range() for indirect-IO and PCI I/O
translation
  OF: Add missing I/O range exception for indirect-IO devices
  LPC: Support the device-tree LPC host on Hip06/Hip07
  LPC: Add the ACPI LPC support

 .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
 MAINTAINERS|   9 +
 arch/arm64/boot/dts/hisilicon/hip06-d03.dts|   4 +
 arch/arm64/boot/dts/hisilicon/hip06.dtsi   |  14 +
 drivers/acpi/pci_root.c|  12 +-
 drivers/bus/Kconfig|   8 +
 drivers/bus/Makefile   |   1 +
 drivers/bus/hisi_lpc.c | 625 +
 drivers/of/address.c   |  95 +++-
 drivers/pci/pci.c  |  44 +-
 include/asm-generic/io.h   |  50 ++
 include/linux/extio.h  |  89 +++
 include/linux/io.h |   1 +
 include/linux/pci.h|   7 +-
 lib/Kconfig|   8 +
 lib/Makefile   |   2 +
 lib/extio.c| 375 +
 17 files changed, 1342 insertions(+), 35 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
 create mode 100644 drivers/bus/hisi_lpc.c
 create mode 100644 include/linux/extio.h
 create mode 100644 lib/extio.c

-- 
1.9.1

[PATCH V6 2/5] PCI: Adapt pci_register_io_range() for indirect-IO and PCI I/O translation

[zhichang.yuan]

After indirect-IO is introduced, system must can assigned indirect-IO devices
with logical I/O ranges which are different from those for PCI I/O devices.
Otherwise, I/O accessors can't identify whether the I/O port is for memory
mapped I/O or indirect-IO.
As current helper, pci_register_io_range(), is used for PCI I/O ranges
registration and translation, indirect-IO devices should also apply these
helpers to manage the I/O ranges. It will be easy to ensure the assigned
logical I/O ranges unique.
But for indirect-IO devices, there is no cpu address. The current
pci_register_io_range() can not work for this case.

This patch makes some changes on the pci_register_io_range() to support the
I/O range registration with device's fwnode also. After this, the indirect-IO
devices can register the device-local I/O range to system logical I/O and
easily perform the translation between device-local I/O range and sytem
logical I/O range.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: Arnd Bergmann 
---
 drivers/acpi/pci_root.c | 12 +---
 drivers/of/address.c|  8 ++--
 drivers/pci/pci.c   | 44 
 include/linux/pci.h |  7 +--
 4 files changed, 52 insertions(+), 19 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index bf601d4..6cadf05 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct device 
*dev,
}
 }
 
-static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
+static void acpi_pci_root_remap_iospace(struct fwnode_handle *node,
+   struct resource_entry *entry)
 {
 #ifdef PCI_IOBASE
struct resource *res = entry->res;
@@ -739,11 +740,7 @@ static void acpi_pci_root_remap_iospace(struct 
resource_entry *entry)
resource_size_t length = resource_size(res);
unsigned long port;
 
-   if (pci_register_io_range(cpu_addr, length))
-   goto err;
-
-   port = pci_address_to_pio(cpu_addr);
-   if (port == (unsigned long)-1)
+   if (pci_register_io_range(node, cpu_addr, length, ))
goto err;
 
res->start = port;
@@ -781,7 +778,8 @@ int acpi_pci_probe_root_resources(struct acpi_pci_root_info 
*info)
else {
resource_list_for_each_entry_safe(entry, tmp, list) {
if (entry->res->flags & IORESOURCE_IO)
-   acpi_pci_root_remap_iospace(entry);
+   acpi_pci_root_remap_iospace(>fwnode,
+   entry);
 
if (entry->res->flags & IORESOURCE_DISABLED)
resource_list_destroy_entry(entry);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..d85d228 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -2,6 +2,7 @@
 #define pr_fmt(fmt)"OF: " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -323,14 +324,9 @@ int of_pci_range_to_resource(struct of_pci_range *range,
 
if (res->flags & IORESOURCE_IO) {
unsigned long port;
-   err = pci_register_io_range(range->cpu_addr, range->size);
+   err = pci_register_io_range(>fwnode, range->cpu_addr, 
range->size, );
if (err)
goto invalid_range;
-   port = pci_address_to_pio(range->cpu_addr);
-   if (port == (unsigned long)-1) {
-   err = -EINVAL;
-   goto invalid_range;
-   }
res->start = port;
} else {
if ((sizeof(resource_size_t) < 8) &&
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a881c0d..5289221 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3241,6 +3241,7 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, 
const char *res_name)
 #ifdef PCI_IOBASE
 struct io_range {
struct list_head list;
+   struct fwnode_handle *node;
phys_addr_t start;
resource_size_t size;
 };
@@ -3253,7 +3254,8 @@ struct io_range {
  * Record the PCI IO range (expressed as CPU physical address + size).
  * Return a negative value if an error has occured, zero otherwise
  */
-int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+int __weak pci_register_io_range(struct fwnode_handle *node, phys_addr_t addr,
+resource_size_t size, unsigned long *port)
 {
int err = 0;
 
@@ -3261,10 +3263,31 @@ int __weak pci_register_io_range(phys_addr_t addr, 
resource_size_t size)
struct io_range *range;
resource_size_t allocated_size = 0;
 
+   /*
+* As indirect-IO which support multiple bus instances is introduced,
+* the input 

[PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

[zhichang.yuan]

The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
I/O port addresses. This patch implements the LPC host controller driver which
perform the I/O operations on the underlying hardware.
We don't want to touch those existing peripherals' driver, such as ipmi-bt. So
this driver applies the indirect-IO introduced in the previous patch after
registering an indirect-IO node to the indirect-IO devices list which will be
searched in the I/O accessors.
As the I/O translations for LPC children depend on the host I/O registration,
we should ensure the host I/O registration is finished before all the LPC
children scanning. That is why an arch_init() hook was added in this patch.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
---
 .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
 MAINTAINERS|   9 +
 arch/arm64/boot/dts/hisilicon/hip06-d03.dts|   4 +
 arch/arm64/boot/dts/hisilicon/hip06.dtsi   |  14 +
 drivers/bus/Kconfig|   8 +
 drivers/bus/Makefile   |   1 +
 drivers/bus/hisi_lpc.c | 599 +
 7 files changed, 668 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
 create mode 100644 drivers/bus/hisi_lpc.c

diff --git 
a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
new file mode 100644
index 000..213181f
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
@@ -0,0 +1,33 @@
+Hisilicon Hip06 low-pin-count device
+  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
+  provides I/O access to some legacy ISA devices.
+  Hip06 is based on arm64 architecture where there is no I/O space. So, the
+  I/O ports here are not cpu addresses, and there is no 'ranges' property in
+  LPC device node.
+
+Required properties:
+- compatible:  value should be as follows:
+   (a) "hisilicon,hip06-lpc"
+   (b) "hisilicon,hip07-lpc"
+- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
+- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
+- reg: base memory range where the LPC register set is mapped.
+
+Note:
+  The node name before '@' must be "isa" to represent the binding stick to the
+  ISA/EISA binding specification.
+
+Example:
+
+isa@a01b {
+   compatible = "hisilicon,hip06-lpc";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   reg = <0x0 0xa01b 0x0 0x1000>;
+
+   ipmi0: bt@e4 {
+   compatible = "ipmi-bt";
+   device_type = "ipmi";
+   reg = <0x01 0xe4 0x04>;
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 26edd83..0153707 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5855,6 +5855,15 @@ F:   include/uapi/linux/if_hippi.h
 F: net/802/hippi.c
 F: drivers/net/hippi/
 
+HISILICON LPC BUS DRIVER
+M: Zhichang Yuan 
+L: linux-arm-ker...@lists.infradead.org
+W: http://www.hisilicon.com
+S: Maintained
+F: drivers/bus/hisi_lpc.c
+F: lib/extio.c
+F: 
Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
+
 HISILICON NETWORK SUBSYSTEM DRIVER
 M: Yisen Zhuang 
 M: Salil Mehta 
diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts 
b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
index 7c4114a..75b2b5c 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
@@ -52,3 +52,7 @@
 _ehci {
status = "ok";
 };
+
+ {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..c450f8d 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -318,6 +318,20 @@
#size-cells = <2>;
ranges;
 
+   isa@a01b {
+   compatible = "hisilicon,hip06-lpc";
+   #size-cells = <1>;
+   #address-cells = <2>;
+   reg = <0x0 0xa01b 0x0 0x1000>;
+
+   ipmi0: bt@e4 {
+   compatible = "ipmi-bt";
+   device_type = "ipmi";
+   reg = <0x01 0xe4 0x04>;
+   status = "disabled";
+   };
+   };
+
refclk: refclk {
compatible = "fixed-clock";
clock-frequency = <5000>;
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b9e8cfc..58cee84 100644
--- a/drivers/bus/Kconfig
+++ 

[PATCH V5 5/5] LPC: Add the ACPI LPC support

[zhichang.yuan]

The patch update the _CRS of LPC children with the system logical I/O resource
after the translation from LPC-local I/O. Then the ACPI platform device
enumeration for LPC can apply the right I/O resource to request the system I/O
space.

Signed-off-by: zhichang.yuan 
---
 drivers/bus/hisi_lpc.c |  26 ++
 include/linux/extio.h  |   4 +
 lib/extio.c| 228 +
 3 files changed, 258 insertions(+)

diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
index a96e384..8d52666 100644
--- a/drivers/bus/hisi_lpc.c
+++ b/drivers/bus/hisi_lpc.c
@@ -583,6 +583,32 @@ static int hisilpc_bus_platform_notify(struct 
notifier_block *nb,
/* register the linux virtual IO range node to list. */
register_extio(io_node);
 
+   /*
+* For ACPI children, translate the bus-local I/O range to logical
+* I/O range and set it as the current resource before the children
+* are enumerated.
+*/
+   if (has_acpi_companion(dev)) {
+   struct acpi_device *root, *child;
+
+   root = to_acpi_device_node(dev->fwnode);
+   /* For hisilpc, only care about the sons of host. */
+   list_for_each_entry(child, >children, node) {
+   ret = acpi_set_extio_resource(child, root);
+   if (ret) {
+   dev_err(dev, "set resource failed..\n");
+   break;
+   }
+   }
+
+   if (ret) {
+   list_del(_node->list);
+   kfree(io_node);
+   dev_err(dev, "notify handling failed..\n");
+   return NOTIFY_DONE;
+   }
+   }
+
return NOTIFY_OK;
 }
 
diff --git a/include/linux/extio.h b/include/linux/extio.h
index 2ca7eab..c07607e 100644
--- a/include/linux/extio.h
+++ b/include/linux/extio.h
@@ -20,6 +20,7 @@
 
 #ifdef __KERNEL__
 
+#include 
 #include 
 
 struct extio_ops {
@@ -81,5 +82,8 @@ static inline struct extio_node *extio_find_node(struct 
fwnode_handle *node)
 #endif
 extern void register_extio(struct extio_node *node);
 
+extern int acpi_set_extio_resource(struct acpi_device *adev,
+   struct acpi_device *host);
+
 #endif /* __KERNEL__ */
 #endif /* __LINUX_EXTIO_H */
diff --git a/lib/extio.c b/lib/extio.c
index 46228de..47f5913 100644
--- a/lib/extio.c
+++ b/lib/extio.c
@@ -75,6 +75,234 @@ unsigned long extio_translate(struct fwnode_handle *node,
return port_id;
 }
 
+static inline bool acpi_extio_supported_resource(struct acpi_resource *res)
+{
+   switch (res->type) {
+   case ACPI_RESOURCE_TYPE_ADDRESS16:
+   case ACPI_RESOURCE_TYPE_ADDRESS32:
+   case ACPI_RESOURCE_TYPE_ADDRESS64:
+   return true;
+   }
+   return false;
+}
+
+static acpi_status acpi_count_extiores(struct acpi_resource *res,
+  void *data)
+{
+   int *res_cnt = data;
+
+   if (acpi_extio_supported_resource(res) &&
+   !acpi_dev_filter_resource_type(res, IORESOURCE_IO))
+   (*res_cnt)++;
+
+   return AE_OK;
+}
+
+static acpi_status acpi_read_one_extiores(struct acpi_resource *res,
+   void *data)
+{
+   struct acpi_resource **resource = data;
+
+   if (acpi_extio_supported_resource(res) &&
+   !acpi_dev_filter_resource_type(res, IORESOURCE_IO)) {
+   memcpy((*resource), res, sizeof(struct acpi_resource));
+   (*resource)->length = sizeof(struct acpi_resource);
+   (*resource)->type = res->type;
+   (*resource)++;
+   }
+
+   return AE_OK;
+}
+
+static acpi_status
+acpi_build_extiores_template(struct acpi_device *adev,
+   struct acpi_buffer *buffer)
+{
+   acpi_handle handle = adev->handle;
+   struct acpi_resource *resource;
+   acpi_status status;
+   int res_cnt = 0;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__PRS,
+acpi_count_extiores, _cnt);
+   if (ACPI_FAILURE(status) || !res_cnt) {
+   dev_err(>dev, "can't evaluate _CRS: %d\n", status);
+   return -EINVAL;
+   }
+
+   buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
+   buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);
+   if (!buffer->pointer)
+   return -ENOMEM;
+
+   resource = (struct acpi_resource *)buffer->pointer;
+   status = acpi_walk_resources(handle, METHOD_NAME__PRS,
+acpi_read_one_extiores, );
+   if (ACPI_FAILURE(status)) {
+   kfree(buffer->pointer);
+   dev_err(>dev, "can't evaluate _PRS: %d\n", status);
+   return -EINVAL;
+   }
+
+   resource->type = ACPI_RESOURCE_TYPE_END_TAG;
+   resource->length = 

[PATCH V6 2/5] PCI: Adapt pci_register_io_range() for indirect-IO and PCI I/O translation

[zhichang.yuan]

After indirect-IO is introduced, system must can assigned indirect-IO devices
with logical I/O ranges which are different from those for PCI I/O devices.
Otherwise, I/O accessors can't identify whether the I/O port is for memory
mapped I/O or indirect-IO.
As current helper, pci_register_io_range(), is used for PCI I/O ranges
registration and translation, indirect-IO devices should also apply these
helpers to manage the I/O ranges. It will be easy to ensure the assigned
logical I/O ranges unique.
But for indirect-IO devices, there is no cpu address. The current
pci_register_io_range() can not work for this case.

This patch makes some changes on the pci_register_io_range() to support the
I/O range registration with device's fwnode also. After this, the indirect-IO
devices can register the device-local I/O range to system logical I/O and
easily perform the translation between device-local I/O range and sytem
logical I/O range.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: Arnd Bergmann 
---
 drivers/acpi/pci_root.c | 12 +---
 drivers/of/address.c|  8 ++--
 drivers/pci/pci.c   | 44 
 include/linux/pci.h |  7 +--
 4 files changed, 52 insertions(+), 19 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index bf601d4..6cadf05 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct device 
*dev,
}
 }
 
-static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
+static void acpi_pci_root_remap_iospace(struct fwnode_handle *node,
+   struct resource_entry *entry)
 {
 #ifdef PCI_IOBASE
struct resource *res = entry->res;
@@ -739,11 +740,7 @@ static void acpi_pci_root_remap_iospace(struct 
resource_entry *entry)
resource_size_t length = resource_size(res);
unsigned long port;
 
-   if (pci_register_io_range(cpu_addr, length))
-   goto err;
-
-   port = pci_address_to_pio(cpu_addr);
-   if (port == (unsigned long)-1)
+   if (pci_register_io_range(node, cpu_addr, length, ))
goto err;
 
res->start = port;
@@ -781,7 +778,8 @@ int acpi_pci_probe_root_resources(struct acpi_pci_root_info 
*info)
else {
resource_list_for_each_entry_safe(entry, tmp, list) {
if (entry->res->flags & IORESOURCE_IO)
-   acpi_pci_root_remap_iospace(entry);
+   acpi_pci_root_remap_iospace(>fwnode,
+   entry);
 
if (entry->res->flags & IORESOURCE_DISABLED)
resource_list_destroy_entry(entry);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..d85d228 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -2,6 +2,7 @@
 #define pr_fmt(fmt)"OF: " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -323,14 +324,9 @@ int of_pci_range_to_resource(struct of_pci_range *range,
 
if (res->flags & IORESOURCE_IO) {
unsigned long port;
-   err = pci_register_io_range(range->cpu_addr, range->size);
+   err = pci_register_io_range(>fwnode, range->cpu_addr, 
range->size, );
if (err)
goto invalid_range;
-   port = pci_address_to_pio(range->cpu_addr);
-   if (port == (unsigned long)-1) {
-   err = -EINVAL;
-   goto invalid_range;
-   }
res->start = port;
} else {
if ((sizeof(resource_size_t) < 8) &&
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a881c0d..5289221 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3241,6 +3241,7 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, 
const char *res_name)
 #ifdef PCI_IOBASE
 struct io_range {
struct list_head list;
+   struct fwnode_handle *node;
phys_addr_t start;
resource_size_t size;
 };
@@ -3253,7 +3254,8 @@ struct io_range {
  * Record the PCI IO range (expressed as CPU physical address + size).
  * Return a negative value if an error has occured, zero otherwise
  */
-int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+int __weak pci_register_io_range(struct fwnode_handle *node, phys_addr_t addr,
+resource_size_t size, unsigned long *port)
 {
int err = 0;
 
@@ -3261,10 +3263,31 @@ int __weak pci_register_io_range(phys_addr_t addr, 
resource_size_t size)
struct io_range *range;
resource_size_t allocated_size = 0;
 
+   /*
+* As indirect-IO which support multiple bus instances is introduced,
+* the input 'addr' is probably not page-aligned. If the PCI I/O
+* ranges 

[PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

[zhichang.yuan]

The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
I/O port addresses. This patch implements the LPC host controller driver which
perform the I/O operations on the underlying hardware.
We don't want to touch those existing peripherals' driver, such as ipmi-bt. So
this driver applies the indirect-IO introduced in the previous patch after
registering an indirect-IO node to the indirect-IO devices list which will be
searched in the I/O accessors.
As the I/O translations for LPC children depend on the host I/O registration,
we should ensure the host I/O registration is finished before all the LPC
children scanning. That is why an arch_init() hook was added in this patch.

Signed-off-by: zhichang.yuan 
Signed-off-by: Gabriele Paoloni 
---
 .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
 MAINTAINERS|   9 +
 arch/arm64/boot/dts/hisilicon/hip06-d03.dts|   4 +
 arch/arm64/boot/dts/hisilicon/hip06.dtsi   |  14 +
 drivers/bus/Kconfig|   8 +
 drivers/bus/Makefile   |   1 +
 drivers/bus/hisi_lpc.c | 599 +
 7 files changed, 668 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
 create mode 100644 drivers/bus/hisi_lpc.c

diff --git 
a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
new file mode 100644
index 000..213181f
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
@@ -0,0 +1,33 @@
+Hisilicon Hip06 low-pin-count device
+  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
+  provides I/O access to some legacy ISA devices.
+  Hip06 is based on arm64 architecture where there is no I/O space. So, the
+  I/O ports here are not cpu addresses, and there is no 'ranges' property in
+  LPC device node.
+
+Required properties:
+- compatible:  value should be as follows:
+   (a) "hisilicon,hip06-lpc"
+   (b) "hisilicon,hip07-lpc"
+- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
+- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
+- reg: base memory range where the LPC register set is mapped.
+
+Note:
+  The node name before '@' must be "isa" to represent the binding stick to the
+  ISA/EISA binding specification.
+
+Example:
+
+isa@a01b {
+   compatible = "hisilicon,hip06-lpc";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   reg = <0x0 0xa01b 0x0 0x1000>;
+
+   ipmi0: bt@e4 {
+   compatible = "ipmi-bt";
+   device_type = "ipmi";
+   reg = <0x01 0xe4 0x04>;
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 26edd83..0153707 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5855,6 +5855,15 @@ F:   include/uapi/linux/if_hippi.h
 F: net/802/hippi.c
 F: drivers/net/hippi/
 
+HISILICON LPC BUS DRIVER
+M: Zhichang Yuan 
+L: linux-arm-ker...@lists.infradead.org
+W: http://www.hisilicon.com
+S: Maintained
+F: drivers/bus/hisi_lpc.c
+F: lib/extio.c
+F: 
Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
+
 HISILICON NETWORK SUBSYSTEM DRIVER
 M: Yisen Zhuang 
 M: Salil Mehta 
diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts 
b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
index 7c4114a..75b2b5c 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
@@ -52,3 +52,7 @@
 _ehci {
status = "ok";
 };
+
+ {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..c450f8d 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -318,6 +318,20 @@
#size-cells = <2>;
ranges;
 
+   isa@a01b {
+   compatible = "hisilicon,hip06-lpc";
+   #size-cells = <1>;
+   #address-cells = <2>;
+   reg = <0x0 0xa01b 0x0 0x1000>;
+
+   ipmi0: bt@e4 {
+   compatible = "ipmi-bt";
+   device_type = "ipmi";
+   reg = <0x01 0xe4 0x04>;
+   status = "disabled";
+   };
+   };
+
refclk: refclk {
compatible = "fixed-clock";
clock-frequency = <5000>;
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b9e8cfc..58cee84 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -64,6 +64,14 @@ config BRCMSTB_GISB_ARB
  arbiter. This driver provides timeout and target abort error handling

[PATCH V5 5/5] LPC: Add the ACPI LPC support

[zhichang.yuan]

The patch update the _CRS of LPC children with the system logical I/O resource
after the translation from LPC-local I/O. Then the ACPI platform device
enumeration for LPC can apply the right I/O resource to request the system I/O
space.

Signed-off-by: zhichang.yuan 
---
 drivers/bus/hisi_lpc.c |  26 ++
 include/linux/extio.h  |   4 +
 lib/extio.c| 228 +
 3 files changed, 258 insertions(+)

diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
index a96e384..8d52666 100644
--- a/drivers/bus/hisi_lpc.c
+++ b/drivers/bus/hisi_lpc.c
@@ -583,6 +583,32 @@ static int hisilpc_bus_platform_notify(struct 
notifier_block *nb,
/* register the linux virtual IO range node to list. */
register_extio(io_node);
 
+   /*
+* For ACPI children, translate the bus-local I/O range to logical
+* I/O range and set it as the current resource before the children
+* are enumerated.
+*/
+   if (has_acpi_companion(dev)) {
+   struct acpi_device *root, *child;
+
+   root = to_acpi_device_node(dev->fwnode);
+   /* For hisilpc, only care about the sons of host. */
+   list_for_each_entry(child, >children, node) {
+   ret = acpi_set_extio_resource(child, root);
+   if (ret) {
+   dev_err(dev, "set resource failed..\n");
+   break;
+   }
+   }
+
+   if (ret) {
+   list_del(_node->list);
+   kfree(io_node);
+   dev_err(dev, "notify handling failed..\n");
+   return NOTIFY_DONE;
+   }
+   }
+
return NOTIFY_OK;
 }
 
diff --git a/include/linux/extio.h b/include/linux/extio.h
index 2ca7eab..c07607e 100644
--- a/include/linux/extio.h
+++ b/include/linux/extio.h
@@ -20,6 +20,7 @@
 
 #ifdef __KERNEL__
 
+#include 
 #include 
 
 struct extio_ops {
@@ -81,5 +82,8 @@ static inline struct extio_node *extio_find_node(struct 
fwnode_handle *node)
 #endif
 extern void register_extio(struct extio_node *node);
 
+extern int acpi_set_extio_resource(struct acpi_device *adev,
+   struct acpi_device *host);
+
 #endif /* __KERNEL__ */
 #endif /* __LINUX_EXTIO_H */
diff --git a/lib/extio.c b/lib/extio.c
index 46228de..47f5913 100644
--- a/lib/extio.c
+++ b/lib/extio.c
@@ -75,6 +75,234 @@ unsigned long extio_translate(struct fwnode_handle *node,
return port_id;
 }
 
+static inline bool acpi_extio_supported_resource(struct acpi_resource *res)
+{
+   switch (res->type) {
+   case ACPI_RESOURCE_TYPE_ADDRESS16:
+   case ACPI_RESOURCE_TYPE_ADDRESS32:
+   case ACPI_RESOURCE_TYPE_ADDRESS64:
+   return true;
+   }
+   return false;
+}
+
+static acpi_status acpi_count_extiores(struct acpi_resource *res,
+  void *data)
+{
+   int *res_cnt = data;
+
+   if (acpi_extio_supported_resource(res) &&
+   !acpi_dev_filter_resource_type(res, IORESOURCE_IO))
+   (*res_cnt)++;
+
+   return AE_OK;
+}
+
+static acpi_status acpi_read_one_extiores(struct acpi_resource *res,
+   void *data)
+{
+   struct acpi_resource **resource = data;
+
+   if (acpi_extio_supported_resource(res) &&
+   !acpi_dev_filter_resource_type(res, IORESOURCE_IO)) {
+   memcpy((*resource), res, sizeof(struct acpi_resource));
+   (*resource)->length = sizeof(struct acpi_resource);
+   (*resource)->type = res->type;
+   (*resource)++;
+   }
+
+   return AE_OK;
+}
+
+static acpi_status
+acpi_build_extiores_template(struct acpi_device *adev,
+   struct acpi_buffer *buffer)
+{
+   acpi_handle handle = adev->handle;
+   struct acpi_resource *resource;
+   acpi_status status;
+   int res_cnt = 0;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__PRS,
+acpi_count_extiores, _cnt);
+   if (ACPI_FAILURE(status) || !res_cnt) {
+   dev_err(>dev, "can't evaluate _CRS: %d\n", status);
+   return -EINVAL;
+   }
+
+   buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
+   buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);
+   if (!buffer->pointer)
+   return -ENOMEM;
+
+   resource = (struct acpi_resource *)buffer->pointer;
+   status = acpi_walk_resources(handle, METHOD_NAME__PRS,
+acpi_read_one_extiores, );
+   if (ACPI_FAILURE(status)) {
+   kfree(buffer->pointer);
+   dev_err(>dev, "can't evaluate _PRS: %d\n", status);
+   return -EINVAL;
+   }
+
+   resource->type = ACPI_RESOURCE_TYPE_END_TAG;
+   resource->length = sizeof(struct acpi_resource);

Re: [PATCH 1/3] PM / devfreq: Fix available_governor sysfs

[Chanwoo Choi]

On 2017년 01월 24일 12:51, MyungJoo Ham wrote:
>> The devfreq using passive governor is not able to change the governor.
>> So, the user can not change the governor through 'available_governor' sysfs
>> entry. Also, the devfreq which don't use the passive governor is not able to
>> change to 'passive' governor on the fly.
> 
> Another thoughts on the characteristics of 'passive' governor:
> 
> 1. Should we prohibit moving from "others" to "passive"?

The relation between parent devfreq and passive devfreq
is fixed by h/w because they share the one power line. 

But,
if you want to permit that some devfreq change 
their governor to passive governor. The current design
of devfreq does not support it. We must need to
rework the devfreq for the moving from 'others' to 'passive'.

The devfreq should consider the multiple dependency on hierachry 
as CCF (Common Clock Framework).

devfreq2 (passive)
devfreq5 (passive)
devfreq6 (passive)
devfreq3 (passive)
devfreq4 (passive)
devfreq7 (passive)
devfreq8 (passive)


I add some examples as following:

Example1,
There is one parent devfreq which includes
the four passive devfreqs as following:
parent-dev1 (ondemand)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)
new-parent-dev2 (ondemand)


If changing the governor of 'parent-dev1' from ondemand to passive,
the user have to inform the information of new parent devfreq(new-parent-dev2).
Maybe, following command should be executed.
echo [new-parent-dev2] > /sys/class/devfreq/[parent-dev1]/parent
new-parent-dev2 
echo passive > /sys/class/devfreq/[parent-dev1]/governor

After that, the final hierarchy will be following:

new-parent-dev2 (ondemand)
parent-dev1 (passive)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)


Example2,
Before,
parent-dev1 (ondemand)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)
new-parent-dev2 (ondemand)

After that, if new-parent-dev2 use the passive governor with parent-dev1 device.

parent-dev1 (ondemand) - control voltage and freq
passive-dev1 (passive) - control freq
passive-dev2 (passive) - control freq
passive-dev3 (passive) - control freq
passive-dev4 (passive) - control freq
new-parent-dev2 (passive) - control voltage and freq


Example3,
There is one parent devfreq which includes
the four passive devfreqs as following:

parent-dev2 (ondemand)
new-parent-dev3 (passive)
parent-dev1 (ondemand)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)

After that, if parent-dev1 use the passive governor with new-parent-dev3 device.

parent-dev2 (ondemand)
new-parent-dev3 (passive)
parent-dev1 (passive)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)


> 2. Should we show "passive" in the available list if it's not passive now?

Yes. I added the test result on cover letter about this.

Even if the parent devfreq device doesn't support the passive governor,
their 'available_governor' shows the 'passive' governor.

> 3. Why don't we show anyway and reject it when actually tries to change?

I think that the sysfs entry have to provide the correct information
to user-space. If available_governor shows the name of unsupported
governor, it is not reasonable and appropriate.
- cat /sys/class/devfreq/[devfreq name]/available_governor

So, the 'available_governor' should only show the supported governors.

> 4. Or should we add a value in devfreq struct that is confired at devfreq
> device add, which prohibits changing governors? (and passive will
> return error if that flag is not set or it will set the value automatically)

If we add some flags to devfreq for passive govenror,
devfreq will prohibits the changing governors. 

And, avaiable_governor function will use the new flags
to show the only supported governors.

I tried to use the existing fields of struct devfreq
without new field. But if you want to add new field,
I'll do.

> 
> Cheers,
> MyungJoo
> 
>>
>> Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  drivers/devfreq/devfreq.c | 34 +-
>>  1 file changed, 33 insertions(+), 1 deletion(-)


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 1/3] PM / devfreq: Fix available_governor sysfs

[Chanwoo Choi]

On 2017년 01월 24일 12:51, MyungJoo Ham wrote:
>> The devfreq using passive governor is not able to change the governor.
>> So, the user can not change the governor through 'available_governor' sysfs
>> entry. Also, the devfreq which don't use the passive governor is not able to
>> change to 'passive' governor on the fly.
> 
> Another thoughts on the characteristics of 'passive' governor:
> 
> 1. Should we prohibit moving from "others" to "passive"?

The relation between parent devfreq and passive devfreq
is fixed by h/w because they share the one power line. 

But,
if you want to permit that some devfreq change 
their governor to passive governor. The current design
of devfreq does not support it. We must need to
rework the devfreq for the moving from 'others' to 'passive'.

The devfreq should consider the multiple dependency on hierachry 
as CCF (Common Clock Framework).

devfreq2 (passive)
devfreq5 (passive)
devfreq6 (passive)
devfreq3 (passive)
devfreq4 (passive)
devfreq7 (passive)
devfreq8 (passive)


I add some examples as following:

Example1,
There is one parent devfreq which includes
the four passive devfreqs as following:
parent-dev1 (ondemand)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)
new-parent-dev2 (ondemand)


If changing the governor of 'parent-dev1' from ondemand to passive,
the user have to inform the information of new parent devfreq(new-parent-dev2).
Maybe, following command should be executed.
echo [new-parent-dev2] > /sys/class/devfreq/[parent-dev1]/parent
new-parent-dev2 
echo passive > /sys/class/devfreq/[parent-dev1]/governor

After that, the final hierarchy will be following:

new-parent-dev2 (ondemand)
parent-dev1 (passive)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)


Example2,
Before,
parent-dev1 (ondemand)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)
new-parent-dev2 (ondemand)

After that, if new-parent-dev2 use the passive governor with parent-dev1 device.

parent-dev1 (ondemand) - control voltage and freq
passive-dev1 (passive) - control freq
passive-dev2 (passive) - control freq
passive-dev3 (passive) - control freq
passive-dev4 (passive) - control freq
new-parent-dev2 (passive) - control voltage and freq


Example3,
There is one parent devfreq which includes
the four passive devfreqs as following:

parent-dev2 (ondemand)
new-parent-dev3 (passive)
parent-dev1 (ondemand)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)

After that, if parent-dev1 use the passive governor with new-parent-dev3 device.

parent-dev2 (ondemand)
new-parent-dev3 (passive)
parent-dev1 (passive)
passive-dev1 (passive)
passive-dev2 (passive)
passive-dev3 (passive)
passive-dev4 (passive)


> 2. Should we show "passive" in the available list if it's not passive now?

Yes. I added the test result on cover letter about this.

Even if the parent devfreq device doesn't support the passive governor,
their 'available_governor' shows the 'passive' governor.

> 3. Why don't we show anyway and reject it when actually tries to change?

I think that the sysfs entry have to provide the correct information
to user-space. If available_governor shows the name of unsupported
governor, it is not reasonable and appropriate.
- cat /sys/class/devfreq/[devfreq name]/available_governor

So, the 'available_governor' should only show the supported governors.

> 4. Or should we add a value in devfreq struct that is confired at devfreq
> device add, which prohibits changing governors? (and passive will
> return error if that flag is not set or it will set the value automatically)

If we add some flags to devfreq for passive govenror,
devfreq will prohibits the changing governors. 

And, avaiable_governor function will use the new flags
to show the only supported governors.

I tried to use the existing fields of struct devfreq
without new field. But if you want to add new field,
I'll do.

> 
> Cheers,
> MyungJoo
> 
>>
>> Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  drivers/devfreq/devfreq.c | 34 +-
>>  1 file changed, 33 insertions(+), 1 deletion(-)


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] drm: bridge: dw-hdmi: fix building without CONFIG_OF

[Archit Taneja]

On 01/23/2017 05:50 PM, Arnd Bergmann wrote:

The of_node member in struct drm_bridge is hidden when CONFIG_OF
is disabled, causing a build error:

drivers/gpu/drm/bridge/dw-hdmi.c: In function '__dw_hdmi_probe':
drivers/gpu/drm/bridge/dw-hdmi.c:2063:14: error: 'struct drm_bridge' has no 
member named 'of_node'

We could fix this either using a Kconfig dependency on CONFIG_OF
or making the one line conditional. The latter gives us better
compile test coverage, so this is what I'm doing here.

Fixes: 69497eb9234e ("drm: bridge: dw-hdmi: Implement DRM bridge registration")
Signed-off-by: Arnd Bergmann 


Thanks for fixing this, queued to drm-misc.

Archit


---
 drivers/gpu/drm/bridge/dw-hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 4fda0717e789..9a9ec27d9e28 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -2060,7 +2060,9 @@ __dw_hdmi_probe(struct platform_device *pdev,

hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = _hdmi_bridge_funcs;
+#ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
+#endif

ret = dw_hdmi_fb_registered(hdmi);
if (ret)



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

Re: [PATCH] drm: bridge: dw-hdmi: fix building without CONFIG_OF

[Archit Taneja]

On 01/23/2017 05:50 PM, Arnd Bergmann wrote:

The of_node member in struct drm_bridge is hidden when CONFIG_OF
is disabled, causing a build error:

drivers/gpu/drm/bridge/dw-hdmi.c: In function '__dw_hdmi_probe':
drivers/gpu/drm/bridge/dw-hdmi.c:2063:14: error: 'struct drm_bridge' has no 
member named 'of_node'

We could fix this either using a Kconfig dependency on CONFIG_OF
or making the one line conditional. The latter gives us better
compile test coverage, so this is what I'm doing here.

Fixes: 69497eb9234e ("drm: bridge: dw-hdmi: Implement DRM bridge registration")
Signed-off-by: Arnd Bergmann 


Thanks for fixing this, queued to drm-misc.

Archit


---
 drivers/gpu/drm/bridge/dw-hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 4fda0717e789..9a9ec27d9e28 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -2060,7 +2060,9 @@ __dw_hdmi_probe(struct platform_device *pdev,

hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = _hdmi_bridge_funcs;
+#ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
+#endif

ret = dw_hdmi_fb_registered(hdmi);
if (ret)



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