Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

[Sascha Hauer]

On Thu, Oct 27, 2016 at 09:40:05AM +0200, Boris Brezillon wrote:
> On Thu, 27 Oct 2016 08:29:39 +0200
> Lukasz Majewski  wrote:
> 
> > The code has been rewritten to remove "generic" calls to
> > imx_pwm_{enable|disable|config}.
> > 
> > Such approach would facilitate switch to atomic PWM (a.k.a ->apply())
> > implementation.
> > 
> > Suggested-by: Stefan Agner 
> > Suggested-by: Boris Brezillon 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > Changes for v2:
> > - Add missing clock unprepare for clk_ipg
> > - Enable peripheral PWM clock (clk_per)
> > ---
> >  drivers/pwm/pwm-imx.c | 50 
> > ++
> >  1 file changed, 38 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > index ea3ce79..822eb5a 100644
> > --- a/drivers/pwm/pwm-imx.c
> > +++ b/drivers/pwm/pwm-imx.c
> > @@ -65,8 +65,6 @@ struct imx_chip {
> >  static int imx_pwm_config_v1(struct pwm_chip *chip,
> > struct pwm_device *pwm, int duty_ns, int period_ns)
> >  {
> > -   struct imx_chip *imx = to_imx_chip(chip);
> > -
> > /*
> >  * The PWM subsystem allows for exact frequencies. However,
> >  * I cannot connect a scope on my device to the PWM line and
> > @@ -84,26 +82,56 @@ static int imx_pwm_config_v1(struct pwm_chip *chip,
> >  * both the prescaler (/1 .. /128) and then by CLKSEL
> >  * (/2 .. /16).
> >  */
> > +   struct imx_chip *imx = to_imx_chip(chip);
> > u32 max = readl(imx->mmio_base + MX1_PWMP);
> > u32 p = max * duty_ns / period_ns;
> > +   int ret;
> > +
> > +   ret = clk_prepare_enable(imx->clk_ipg);
> > +   if (ret)
> > +   return ret;
> > +
> > writel(max - p, imx->mmio_base + MX1_PWMS);
> >  
> > +   clk_disable_unprepare(imx->clk_ipg);
> > +
> > return 0;
> >  }
> >  
> > -static void imx_pwm_set_enable_v1(struct pwm_chip *chip, bool enable)
> > +static int imx_pwm_enable_v1(struct pwm_chip *chip, struct pwm_device *pwm)
> >  {
> > struct imx_chip *imx = to_imx_chip(chip);
> > +   int ret;
> > u32 val;
> >  
> > +   ret = clk_prepare_enable(imx->clk_ipg);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = clk_prepare_enable(imx->clk_per);
> > +   if (ret)
> > +   return ret;
> > +
> > val = readl(imx->mmio_base + MX1_PWMC);
> > +   val |= MX1_PWMC_EN;
> > +   writel(val, imx->mmio_base + MX1_PWMC);
> >  
> > -   if (enable)
> > -   val |= MX1_PWMC_EN;
> > -   else
> > -   val &= ~MX1_PWMC_EN;
> > +   clk_disable_unprepare(imx->clk_ipg);
> > +
> > +   return 0;
> > +}
> > +
> > +static void imx_pwm_disable_v1(struct pwm_chip *chip, struct pwm_device 
> > *pwm)
> > +{
> > +   struct imx_chip *imx = to_imx_chip(chip);
> > +   u32 val;
> > +
> > +   val = readl(imx->mmio_base + MX1_PWMC);
> > +   val &= ~MX1_PWMC_EN;
> >  
> > writel(val, imx->mmio_base + MX1_PWMC);
> 
> Are you sure you don't need to enable the ipg clk when manipulating the
> PWMC register?
> If it's not needed here, then it's probably not needed in
> imx_pwm_enable_v1() either.

As said, even the commit 7b27c160c68 introducing the register clk did not
enable the clock consistently for all register accesses. Maybe it's best
to include the following patch so that we can find a clear culprit and
do not bury the ipg clock changes in larger patches.

Sascha

-8<---

>From 30b77e83269a58c2cb5ce6de8be647e027030d34 Mon Sep 17 00:00:00 2001
From: Sascha Hauer 
Date: Mon, 31 Oct 2016 06:45:33 +0100
Subject: [PATCH] pwm: imx: remove ipg clock

The use of the ipg clock was introduced with commit 7b27c160c6. In the
commit message it was claimed that the ipg clock is enabled for register
accesses. This is true for the ->config() callback, but not for the
->set_enable() callback. Given that the ipg clock is not consistently
enabled for all register accesses we can assume that either it is not
required at all or that the current code does not work.
Remove the ipg clock code for now so that it's no longer in the way of
refactoring the driver.

Signed-off-by: Sascha Hauer 
Cc: Philipp Zabel 
---
 drivers/pwm/pwm-imx.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index d600fd5..70609ef2 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -49,7 +49,6 @@
 
 struct imx_chip {
struct clk  *clk_per;
-   struct clk  *clk_ipg;
 
void __iomem*mmio_base;
 
@@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
 {
struct imx_chip *imx = to_imx_chip(chip);
-   int ret;
-
-   ret = clk_prepare_enable(imx->clk_ipg);
-   if (ret)
-   

Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

[Sascha Hauer]

On Thu, Oct 27, 2016 at 09:40:05AM +0200, Boris Brezillon wrote:
> On Thu, 27 Oct 2016 08:29:39 +0200
> Lukasz Majewski  wrote:
> 
> > The code has been rewritten to remove "generic" calls to
> > imx_pwm_{enable|disable|config}.
> > 
> > Such approach would facilitate switch to atomic PWM (a.k.a ->apply())
> > implementation.
> > 
> > Suggested-by: Stefan Agner 
> > Suggested-by: Boris Brezillon 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > Changes for v2:
> > - Add missing clock unprepare for clk_ipg
> > - Enable peripheral PWM clock (clk_per)
> > ---
> >  drivers/pwm/pwm-imx.c | 50 
> > ++
> >  1 file changed, 38 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > index ea3ce79..822eb5a 100644
> > --- a/drivers/pwm/pwm-imx.c
> > +++ b/drivers/pwm/pwm-imx.c
> > @@ -65,8 +65,6 @@ struct imx_chip {
> >  static int imx_pwm_config_v1(struct pwm_chip *chip,
> > struct pwm_device *pwm, int duty_ns, int period_ns)
> >  {
> > -   struct imx_chip *imx = to_imx_chip(chip);
> > -
> > /*
> >  * The PWM subsystem allows for exact frequencies. However,
> >  * I cannot connect a scope on my device to the PWM line and
> > @@ -84,26 +82,56 @@ static int imx_pwm_config_v1(struct pwm_chip *chip,
> >  * both the prescaler (/1 .. /128) and then by CLKSEL
> >  * (/2 .. /16).
> >  */
> > +   struct imx_chip *imx = to_imx_chip(chip);
> > u32 max = readl(imx->mmio_base + MX1_PWMP);
> > u32 p = max * duty_ns / period_ns;
> > +   int ret;
> > +
> > +   ret = clk_prepare_enable(imx->clk_ipg);
> > +   if (ret)
> > +   return ret;
> > +
> > writel(max - p, imx->mmio_base + MX1_PWMS);
> >  
> > +   clk_disable_unprepare(imx->clk_ipg);
> > +
> > return 0;
> >  }
> >  
> > -static void imx_pwm_set_enable_v1(struct pwm_chip *chip, bool enable)
> > +static int imx_pwm_enable_v1(struct pwm_chip *chip, struct pwm_device *pwm)
> >  {
> > struct imx_chip *imx = to_imx_chip(chip);
> > +   int ret;
> > u32 val;
> >  
> > +   ret = clk_prepare_enable(imx->clk_ipg);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = clk_prepare_enable(imx->clk_per);
> > +   if (ret)
> > +   return ret;
> > +
> > val = readl(imx->mmio_base + MX1_PWMC);
> > +   val |= MX1_PWMC_EN;
> > +   writel(val, imx->mmio_base + MX1_PWMC);
> >  
> > -   if (enable)
> > -   val |= MX1_PWMC_EN;
> > -   else
> > -   val &= ~MX1_PWMC_EN;
> > +   clk_disable_unprepare(imx->clk_ipg);
> > +
> > +   return 0;
> > +}
> > +
> > +static void imx_pwm_disable_v1(struct pwm_chip *chip, struct pwm_device 
> > *pwm)
> > +{
> > +   struct imx_chip *imx = to_imx_chip(chip);
> > +   u32 val;
> > +
> > +   val = readl(imx->mmio_base + MX1_PWMC);
> > +   val &= ~MX1_PWMC_EN;
> >  
> > writel(val, imx->mmio_base + MX1_PWMC);
> 
> Are you sure you don't need to enable the ipg clk when manipulating the
> PWMC register?
> If it's not needed here, then it's probably not needed in
> imx_pwm_enable_v1() either.

As said, even the commit 7b27c160c68 introducing the register clk did not
enable the clock consistently for all register accesses. Maybe it's best
to include the following patch so that we can find a clear culprit and
do not bury the ipg clock changes in larger patches.

Sascha

-8<---

>From 30b77e83269a58c2cb5ce6de8be647e027030d34 Mon Sep 17 00:00:00 2001
From: Sascha Hauer 
Date: Mon, 31 Oct 2016 06:45:33 +0100
Subject: [PATCH] pwm: imx: remove ipg clock

The use of the ipg clock was introduced with commit 7b27c160c6. In the
commit message it was claimed that the ipg clock is enabled for register
accesses. This is true for the ->config() callback, but not for the
->set_enable() callback. Given that the ipg clock is not consistently
enabled for all register accesses we can assume that either it is not
required at all or that the current code does not work.
Remove the ipg clock code for now so that it's no longer in the way of
refactoring the driver.

Signed-off-by: Sascha Hauer 
Cc: Philipp Zabel 
---
 drivers/pwm/pwm-imx.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index d600fd5..70609ef2 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -49,7 +49,6 @@
 
 struct imx_chip {
struct clk  *clk_per;
-   struct clk  *clk_ipg;
 
void __iomem*mmio_base;
 
@@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
 {
struct imx_chip *imx = to_imx_chip(chip);
-   int ret;
-
-   ret = clk_prepare_enable(imx->clk_ipg);
-   if (ret)
-   return ret;
 
-   ret = imx->config(chip, pwm, duty_ns, period_ns);
-
-   clk_disable_unprepare(imx->clk_ipg);
-
-   return ret;
+   return 

Re: [PATCH v2 2/3] dt-bindings: reset: Add K2G reset definitions

[Rob Herring]

On Thu, Oct 27, 2016 at 04:49:40PM -0500, Andrew F. Davis wrote:
> Add identifiers for the K2G resets managed by the PMMC.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  MAINTAINERS |  1 +
>  include/dt-bindings/reset/k2g.h | 22 ++
>  2 files changed, 23 insertions(+)
>  create mode 100644 include/dt-bindings/reset/k2g.h

This belongs with the previous patch. It is part of the binding 
definition.

Rob

Re: [PATCH v2 2/3] dt-bindings: reset: Add K2G reset definitions

[Rob Herring]

On Thu, Oct 27, 2016 at 04:49:40PM -0500, Andrew F. Davis wrote:
> Add identifiers for the K2G resets managed by the PMMC.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  MAINTAINERS |  1 +
>  include/dt-bindings/reset/k2g.h | 22 ++
>  2 files changed, 23 insertions(+)
>  create mode 100644 include/dt-bindings/reset/k2g.h

This belongs with the previous patch. It is part of the binding 
definition.

Rob

[PATCH 06/15] Drivers: hv: vss: Improve log messages.

[kys]

From: Alex Ng 

Adding log messages to help troubleshoot error cases and transaction
handling.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_snapshot.c |   25 +++--
 1 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
index a670713..5c95ba1 100644
--- a/drivers/hv/hv_snapshot.c
+++ b/drivers/hv/hv_snapshot.c
@@ -120,7 +120,7 @@ static int vss_handle_handshake(struct hv_vss_msg *vss_msg)
default:
return -EINVAL;
}
-   pr_debug("VSS: userspace daemon ver. %d connected\n", dm_reg_value);
+   pr_info("VSS: userspace daemon ver. %d connected\n", dm_reg_value);
return 0;
 }
 
@@ -128,8 +128,10 @@ static int vss_on_msg(void *msg, int len)
 {
struct hv_vss_msg *vss_msg = (struct hv_vss_msg *)msg;
 
-   if (len != sizeof(*vss_msg))
+   if (len != sizeof(*vss_msg)) {
+   pr_debug("VSS: Message size does not match length\n");
return -EINVAL;
+   }
 
if (vss_msg->vss_hdr.operation == VSS_OP_REGISTER ||
vss_msg->vss_hdr.operation == VSS_OP_REGISTER1) {
@@ -137,8 +139,11 @@ static int vss_on_msg(void *msg, int len)
 * Don't process registration messages if we're in the middle
 * of a transaction processing.
 */
-   if (vss_transaction.state > HVUTIL_READY)
+   if (vss_transaction.state > HVUTIL_READY) {
+   pr_debug("VSS: Got unexpected registration request\n");
return -EINVAL;
+   }
+
return vss_handle_handshake(vss_msg);
} else if (vss_transaction.state == HVUTIL_USERSPACE_REQ) {
vss_transaction.state = HVUTIL_USERSPACE_RECV;
@@ -155,7 +160,7 @@ static int vss_on_msg(void *msg, int len)
}
} else {
/* This is a spurious call! */
-   pr_warn("VSS: Transaction not active\n");
+   pr_debug("VSS: Transaction not active\n");
return -EINVAL;
}
return 0;
@@ -168,8 +173,10 @@ static void vss_send_op(void)
struct hv_vss_msg *vss_msg;
 
/* The transaction state is wrong. */
-   if (vss_transaction.state != HVUTIL_HOSTMSG_RECEIVED)
+   if (vss_transaction.state != HVUTIL_HOSTMSG_RECEIVED) {
+   pr_debug("VSS: Unexpected attempt to send to daemon\n");
return;
+   }
 
vss_msg = kzalloc(sizeof(*vss_msg), GFP_KERNEL);
if (!vss_msg)
@@ -210,9 +217,13 @@ static void vss_handle_request(struct work_struct *dummy)
case VSS_OP_HOT_BACKUP:
if (vss_transaction.state < HVUTIL_READY) {
/* Userspace is not registered yet */
+   pr_debug("VSS: Not ready for request.\n");
vss_respond_to_host(HV_E_FAIL);
return;
}
+
+   pr_debug("VSS: Received request for op code: %d\n",
+   vss_transaction.msg->vss_hdr.operation);
vss_transaction.state = HVUTIL_HOSTMSG_RECEIVED;
vss_send_op();
return;
@@ -353,8 +364,10 @@ hv_vss_init(struct hv_util_service *srv)
 
hvt = hvutil_transport_init(vss_devname, CN_VSS_IDX, CN_VSS_VAL,
vss_on_msg, vss_on_reset);
-   if (!hvt)
+   if (!hvt) {
+   pr_warn("VSS: Failed to initialize transport\n");
return -EFAULT;
+   }
 
return 0;
 }
-- 
1.7.4.1

[PATCH 15/15] Drivers: hv: vmbus: On the read path cleanup the logic to interrupt the host

[kys]

From: K. Y. Srinivasan 

Signal the host when we determine the host is to be signaled -
on th read path. The currrent code determines the need to signal in the
ringbuffer code and actually issues the signal elsewhere. This can result
in the host viewing this interrupt as spurious since the host may also
poll the channel. Make the necessary adjustments.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel.c  |   11 ++-
 drivers/hv/hyperv_vmbus.h |4 ++--
 drivers/hv/ring_buffer.c  |7 ---
 include/linux/hyperv.h|   12 ++--
 4 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 975c98a..bffdca3 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -878,16 +878,9 @@ __vmbus_recvpacket(struct vmbus_channel *channel, void 
*buffer,
   u32 bufferlen, u32 *buffer_actual_len, u64 *requestid,
   bool raw)
 {
-   int ret;
-   bool signal = false;
-
-   ret = hv_ringbuffer_read(>inbound, buffer, bufferlen,
-buffer_actual_len, requestid, , raw);
+   return hv_ringbuffer_read(channel, buffer, bufferlen,
+ buffer_actual_len, requestid, raw);
 
-   if (signal)
-   vmbus_setevent(channel);
-
-   return ret;
 }
 
 int vmbus_recvpacket(struct vmbus_channel *channel, void *buffer,
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 2d42ebe..0675b39 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -532,9 +532,9 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
u32 kv_count, bool lock,
bool kick_q);
 
-int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+int hv_ringbuffer_read(struct vmbus_channel *channel,
   void *buffer, u32 buflen, u32 *buffer_actual_len,
-  u64 *requestid, bool *signal, bool raw);
+  u64 *requestid, bool raw);
 
 void hv_ringbuffer_get_debuginfo(struct hv_ring_buffer_info *ring_info,
struct hv_ring_buffer_debug_info *debug_info);
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 4af7130..cd49cb1 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -353,9 +353,9 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
return 0;
 }
 
-int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+int hv_ringbuffer_read(struct vmbus_channel *channel,
   void *buffer, u32 buflen, u32 *buffer_actual_len,
-  u64 *requestid, bool *signal, bool raw)
+  u64 *requestid, bool raw)
 {
u32 bytes_avail_toread;
u32 next_read_location = 0;
@@ -364,6 +364,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info,
u32 offset;
u32 packetlen;
int ret = 0;
+   struct hv_ring_buffer_info *inring_info = >inbound;
 
if (buflen <= 0)
return -EINVAL;
@@ -421,7 +422,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info,
/* Update the read index */
hv_set_next_read_location(inring_info, next_read_location);
 
-   *signal = hv_need_to_signal_on_read(inring_info);
+   hv_signal_on_read(channel);
 
return ret;
 }
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index dd31882..2a52d9a 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1480,10 +1480,11 @@ hv_get_ring_buffer(struct hv_ring_buffer_info 
*ring_info)
  *there is room for the producer to send the pending packet.
  */
 
-static inline  bool hv_need_to_signal_on_read(struct hv_ring_buffer_info *rbi)
+static inline  void hv_signal_on_read(struct vmbus_channel *channel)
 {
u32 cur_write_sz;
u32 pending_sz;
+   struct hv_ring_buffer_info *rbi = >inbound;
 
/*
 * Issue a full memory barrier before making the signaling decision.
@@ -1501,14 +1502,14 @@ static inline  bool hv_need_to_signal_on_read(struct 
hv_ring_buffer_info *rbi)
pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
/* If the other end is not blocked on write don't bother. */
if (pending_sz == 0)
-   return false;
+   return;
 
cur_write_sz = hv_get_bytes_to_write(rbi);
 
if (cur_write_sz >= pending_sz)
-   return true;
+   vmbus_setevent(channel);
 
-   return false;
+   return;
 }
 
 /*
@@ -1580,8 +1581,7 @@ static inline void commit_rd_index(struct vmbus_channel 
*channel)
virt_rmb();
ring_info->ring_buffer->read_index = ring_info->priv_read_index;
 
-   if (hv_need_to_signal_on_read(ring_info))
-   vmbus_set_event(channel);
+   hv_signal_on_read(channel);
 }
 
 
-- 
1.7.4.1

[PATCH 03/15] Drivers: hv: utils: Fix the mapping between host version and protocol to use

[kys]

From: Alex Ng 

We should intentionally declare the protocols to use for every known host
and default to using the latest protocol if the host is unknown or new.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_util.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index bcd0630..1b693bf 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -389,16 +389,19 @@ static int util_probe(struct hv_device *dev,
ts_srv_version = TS_VERSION_1;
hb_srv_version = HB_VERSION_1;
break;
-   case(VERSION_WIN10):
+   case (VERSION_WIN7):
+   case (VERSION_WIN8):
+   case (VERSION_WIN8_1):
util_fw_version = UTIL_FW_VERSION;
sd_srv_version = SD_VERSION;
-   ts_srv_version = TS_VERSION;
+   ts_srv_version = TS_VERSION_3;
hb_srv_version = HB_VERSION;
break;
+   case (VERSION_WIN10):
default:
util_fw_version = UTIL_FW_VERSION;
sd_srv_version = SD_VERSION;
-   ts_srv_version = TS_VERSION_3;
+   ts_srv_version = TS_VERSION;
hb_srv_version = HB_VERSION;
}
 
-- 
1.7.4.1

[PATCH 11/15] tools: hv: remove unnecessary header files and netlink related code

[kys]

From: Weibing Zhang 

Remove unnecessary header files and netlink related code as the daemons
do not use netlink to communicate with the kernel now.

Signed-off-by: Weibing Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_fcopy_daemon.c |7 ---
 tools/hv/hv_kvp_daemon.c   |7 ---
 2 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index fdc9ca4..26ae609 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -18,21 +18,14 @@
 
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static int target_fd;
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bb0719b..d791dbf 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -22,8 +22,6 @@
  */
 
 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -34,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -99,10 +96,6 @@ static struct utsname uts_buf;
 #define MAX_FILE_NAME 100
 #define ENTRIES_PER_BLOCK 50
 
-#ifndef SOL_NETLINK
-#define SOL_NETLINK 270
-#endif
-
 struct kvp_record {
char key[HV_KVP_EXCHANGE_MAX_KEY_SIZE];
char value[HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
-- 
1.7.4.1

[PATCH 06/15] Drivers: hv: vss: Improve log messages.

[kys]

From: Alex Ng 

Adding log messages to help troubleshoot error cases and transaction
handling.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_snapshot.c |   25 +++--
 1 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
index a670713..5c95ba1 100644
--- a/drivers/hv/hv_snapshot.c
+++ b/drivers/hv/hv_snapshot.c
@@ -120,7 +120,7 @@ static int vss_handle_handshake(struct hv_vss_msg *vss_msg)
default:
return -EINVAL;
}
-   pr_debug("VSS: userspace daemon ver. %d connected\n", dm_reg_value);
+   pr_info("VSS: userspace daemon ver. %d connected\n", dm_reg_value);
return 0;
 }
 
@@ -128,8 +128,10 @@ static int vss_on_msg(void *msg, int len)
 {
struct hv_vss_msg *vss_msg = (struct hv_vss_msg *)msg;
 
-   if (len != sizeof(*vss_msg))
+   if (len != sizeof(*vss_msg)) {
+   pr_debug("VSS: Message size does not match length\n");
return -EINVAL;
+   }
 
if (vss_msg->vss_hdr.operation == VSS_OP_REGISTER ||
vss_msg->vss_hdr.operation == VSS_OP_REGISTER1) {
@@ -137,8 +139,11 @@ static int vss_on_msg(void *msg, int len)
 * Don't process registration messages if we're in the middle
 * of a transaction processing.
 */
-   if (vss_transaction.state > HVUTIL_READY)
+   if (vss_transaction.state > HVUTIL_READY) {
+   pr_debug("VSS: Got unexpected registration request\n");
return -EINVAL;
+   }
+
return vss_handle_handshake(vss_msg);
} else if (vss_transaction.state == HVUTIL_USERSPACE_REQ) {
vss_transaction.state = HVUTIL_USERSPACE_RECV;
@@ -155,7 +160,7 @@ static int vss_on_msg(void *msg, int len)
}
} else {
/* This is a spurious call! */
-   pr_warn("VSS: Transaction not active\n");
+   pr_debug("VSS: Transaction not active\n");
return -EINVAL;
}
return 0;
@@ -168,8 +173,10 @@ static void vss_send_op(void)
struct hv_vss_msg *vss_msg;
 
/* The transaction state is wrong. */
-   if (vss_transaction.state != HVUTIL_HOSTMSG_RECEIVED)
+   if (vss_transaction.state != HVUTIL_HOSTMSG_RECEIVED) {
+   pr_debug("VSS: Unexpected attempt to send to daemon\n");
return;
+   }
 
vss_msg = kzalloc(sizeof(*vss_msg), GFP_KERNEL);
if (!vss_msg)
@@ -210,9 +217,13 @@ static void vss_handle_request(struct work_struct *dummy)
case VSS_OP_HOT_BACKUP:
if (vss_transaction.state < HVUTIL_READY) {
/* Userspace is not registered yet */
+   pr_debug("VSS: Not ready for request.\n");
vss_respond_to_host(HV_E_FAIL);
return;
}
+
+   pr_debug("VSS: Received request for op code: %d\n",
+   vss_transaction.msg->vss_hdr.operation);
vss_transaction.state = HVUTIL_HOSTMSG_RECEIVED;
vss_send_op();
return;
@@ -353,8 +364,10 @@ hv_vss_init(struct hv_util_service *srv)
 
hvt = hvutil_transport_init(vss_devname, CN_VSS_IDX, CN_VSS_VAL,
vss_on_msg, vss_on_reset);
-   if (!hvt)
+   if (!hvt) {
+   pr_warn("VSS: Failed to initialize transport\n");
return -EFAULT;
+   }
 
return 0;
 }
-- 
1.7.4.1

[PATCH 15/15] Drivers: hv: vmbus: On the read path cleanup the logic to interrupt the host

[kys]

From: K. Y. Srinivasan 

Signal the host when we determine the host is to be signaled -
on th read path. The currrent code determines the need to signal in the
ringbuffer code and actually issues the signal elsewhere. This can result
in the host viewing this interrupt as spurious since the host may also
poll the channel. Make the necessary adjustments.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel.c  |   11 ++-
 drivers/hv/hyperv_vmbus.h |4 ++--
 drivers/hv/ring_buffer.c  |7 ---
 include/linux/hyperv.h|   12 ++--
 4 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 975c98a..bffdca3 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -878,16 +878,9 @@ __vmbus_recvpacket(struct vmbus_channel *channel, void 
*buffer,
   u32 bufferlen, u32 *buffer_actual_len, u64 *requestid,
   bool raw)
 {
-   int ret;
-   bool signal = false;
-
-   ret = hv_ringbuffer_read(>inbound, buffer, bufferlen,
-buffer_actual_len, requestid, , raw);
+   return hv_ringbuffer_read(channel, buffer, bufferlen,
+ buffer_actual_len, requestid, raw);
 
-   if (signal)
-   vmbus_setevent(channel);
-
-   return ret;
 }
 
 int vmbus_recvpacket(struct vmbus_channel *channel, void *buffer,
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 2d42ebe..0675b39 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -532,9 +532,9 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
u32 kv_count, bool lock,
bool kick_q);
 
-int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+int hv_ringbuffer_read(struct vmbus_channel *channel,
   void *buffer, u32 buflen, u32 *buffer_actual_len,
-  u64 *requestid, bool *signal, bool raw);
+  u64 *requestid, bool raw);
 
 void hv_ringbuffer_get_debuginfo(struct hv_ring_buffer_info *ring_info,
struct hv_ring_buffer_debug_info *debug_info);
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 4af7130..cd49cb1 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -353,9 +353,9 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
return 0;
 }
 
-int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+int hv_ringbuffer_read(struct vmbus_channel *channel,
   void *buffer, u32 buflen, u32 *buffer_actual_len,
-  u64 *requestid, bool *signal, bool raw)
+  u64 *requestid, bool raw)
 {
u32 bytes_avail_toread;
u32 next_read_location = 0;
@@ -364,6 +364,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info,
u32 offset;
u32 packetlen;
int ret = 0;
+   struct hv_ring_buffer_info *inring_info = >inbound;
 
if (buflen <= 0)
return -EINVAL;
@@ -421,7 +422,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info,
/* Update the read index */
hv_set_next_read_location(inring_info, next_read_location);
 
-   *signal = hv_need_to_signal_on_read(inring_info);
+   hv_signal_on_read(channel);
 
return ret;
 }
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index dd31882..2a52d9a 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1480,10 +1480,11 @@ hv_get_ring_buffer(struct hv_ring_buffer_info 
*ring_info)
  *there is room for the producer to send the pending packet.
  */
 
-static inline  bool hv_need_to_signal_on_read(struct hv_ring_buffer_info *rbi)
+static inline  void hv_signal_on_read(struct vmbus_channel *channel)
 {
u32 cur_write_sz;
u32 pending_sz;
+   struct hv_ring_buffer_info *rbi = >inbound;
 
/*
 * Issue a full memory barrier before making the signaling decision.
@@ -1501,14 +1502,14 @@ static inline  bool hv_need_to_signal_on_read(struct 
hv_ring_buffer_info *rbi)
pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
/* If the other end is not blocked on write don't bother. */
if (pending_sz == 0)
-   return false;
+   return;
 
cur_write_sz = hv_get_bytes_to_write(rbi);
 
if (cur_write_sz >= pending_sz)
-   return true;
+   vmbus_setevent(channel);
 
-   return false;
+   return;
 }
 
 /*
@@ -1580,8 +1581,7 @@ static inline void commit_rd_index(struct vmbus_channel 
*channel)
virt_rmb();
ring_info->ring_buffer->read_index = ring_info->priv_read_index;
 
-   if (hv_need_to_signal_on_read(ring_info))
-   vmbus_set_event(channel);
+   hv_signal_on_read(channel);
 }
 
 
-- 
1.7.4.1

[PATCH 03/15] Drivers: hv: utils: Fix the mapping between host version and protocol to use

[kys]

From: Alex Ng 

We should intentionally declare the protocols to use for every known host
and default to using the latest protocol if the host is unknown or new.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_util.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index bcd0630..1b693bf 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -389,16 +389,19 @@ static int util_probe(struct hv_device *dev,
ts_srv_version = TS_VERSION_1;
hb_srv_version = HB_VERSION_1;
break;
-   case(VERSION_WIN10):
+   case (VERSION_WIN7):
+   case (VERSION_WIN8):
+   case (VERSION_WIN8_1):
util_fw_version = UTIL_FW_VERSION;
sd_srv_version = SD_VERSION;
-   ts_srv_version = TS_VERSION;
+   ts_srv_version = TS_VERSION_3;
hb_srv_version = HB_VERSION;
break;
+   case (VERSION_WIN10):
default:
util_fw_version = UTIL_FW_VERSION;
sd_srv_version = SD_VERSION;
-   ts_srv_version = TS_VERSION_3;
+   ts_srv_version = TS_VERSION;
hb_srv_version = HB_VERSION;
}
 
-- 
1.7.4.1

[PATCH 11/15] tools: hv: remove unnecessary header files and netlink related code

[kys]

From: Weibing Zhang 

Remove unnecessary header files and netlink related code as the daemons
do not use netlink to communicate with the kernel now.

Signed-off-by: Weibing Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_fcopy_daemon.c |7 ---
 tools/hv/hv_kvp_daemon.c   |7 ---
 2 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index fdc9ca4..26ae609 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -18,21 +18,14 @@
 
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static int target_fd;
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bb0719b..d791dbf 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -22,8 +22,6 @@
  */
 
 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -34,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -99,10 +96,6 @@ static struct utsname uts_buf;
 #define MAX_FILE_NAME 100
 #define ENTRIES_PER_BLOCK 50
 
-#ifndef SOL_NETLINK
-#define SOL_NETLINK 270
-#endif
-
 struct kvp_record {
char key[HV_KVP_EXCHANGE_MAX_KEY_SIZE];
char value[HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
-- 
1.7.4.1

[PATCH 10/15] tools: hv: fix a compile warning in snprintf

[kys]

From: Weibing Zhang 

hv_kvp_daemon.c: In function .kvp_mac_to_if_name.:
hv_kvp_daemon.c:705:2: warning: format not a string literal and no format 
arguments [-Wformat-security]
  snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
  ^
hv_kvp_daemon.c:705:2: warning: format not a string literal and no format 
arguments [-Wformat-security]

Signed-off-by: Weibing Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_kvp_daemon.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bc7adb8..bb0719b 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -702,7 +702,7 @@ static char *kvp_mac_to_if_name(char *mac)
if (dir == NULL)
return NULL;
 
-   snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
+   snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
q = dev_id + strlen(kvp_net_dir);
 
while ((entry = readdir(dir)) != NULL) {
-- 
1.7.4.1

[PATCH 10/15] tools: hv: fix a compile warning in snprintf

[kys]

From: Weibing Zhang 

hv_kvp_daemon.c: In function .kvp_mac_to_if_name.:
hv_kvp_daemon.c:705:2: warning: format not a string literal and no format 
arguments [-Wformat-security]
  snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
  ^
hv_kvp_daemon.c:705:2: warning: format not a string literal and no format 
arguments [-Wformat-security]

Signed-off-by: Weibing Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_kvp_daemon.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bc7adb8..bb0719b 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -702,7 +702,7 @@ static char *kvp_mac_to_if_name(char *mac)
if (dir == NULL)
return NULL;
 
-   snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
+   snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
q = dev_id + strlen(kvp_net_dir);
 
while ((entry = readdir(dir)) != NULL) {
-- 
1.7.4.1

[PATCH 12/15] vmbus: make sysfs names consistent with PCI

[kys]

From: Stephen Hemminger 

In commit 9a56e5d6a0ba ("Drivers: hv: make VMBus bus ids persistent")
the name of vmbus devices in sysfs changed to be (in 4.9-rc1):
  /sys/bus/vmbus/vmbus-6aebe374-9ba0-11e6-933c-00259086b36b

The prefix ("vmbus-") is redundant and differs from how PCI is
represented in sysfs. Therefore simplify to:
  /sys/bus/vmbus/6aebe374-9ba0-11e6-933c-00259086b36b

Please merge this before 4.9 is released and the old format
has to live forever.

Signed-off-by: Stephen Hemminger 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/vmbus_drv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index a259e18..0276d2e 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -961,7 +961,7 @@ int vmbus_device_register(struct hv_device 
*child_device_obj)
 {
int ret = 0;
 
-   dev_set_name(_device_obj->device, "vmbus-%pUl",
+   dev_set_name(_device_obj->device, "%pUl",
 child_device_obj->channel->offermsg.offer.if_instance.b);
 
child_device_obj->device.bus = _bus;
-- 
1.7.4.1

[PATCH 04/15] Drivers: hv: balloon: Disable hot add when CONFIG_MEMORY_HOTPLUG is not set

[kys]

From: Alex Ng 

If the guest does not support memory hotplugging, it should respond to
the host with zero pages added and successful result code. This signals
to the host that hotplugging is not supported and the host will avoid
sending future hot-add requests.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index fdf8da9..8f932aa 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1501,7 +1501,11 @@ static int balloon_probe(struct hv_device *dev,
struct dm_version_request version_req;
struct dm_capabilities cap_msg;
 
+#ifdef CONFIG_MEMORY_HOTPLUG
do_hot_add = hot_add;
+#else
+   do_hot_add = false;
+#endif
 
/*
 * First allocate a send buffer.
-- 
1.7.4.1

[PATCH 01/15] Drivers: hv: ring_buffer: count on wrap around mappings in get_next_pkt_raw() (v2)

[kys]

From: Vitaly Kuznetsov 

With wrap around mappings in place we can always provide drivers with
direct links to packets on the ring buffer, even when they wrap around.
Do the required updates to get_next_pkt_raw()/put_pkt_raw()

The first version of this commit was reverted (65a532f3d50a) to deal with
cross-tree merge issues which are (hopefully) resolved now.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Tested-by: Dexuan Cui 
---
 include/linux/hyperv.h |   32 +++-
 1 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index cd184bd..2f65c30 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1519,31 +1519,23 @@ static inline struct vmpacket_descriptor *
 get_next_pkt_raw(struct vmbus_channel *channel)
 {
struct hv_ring_buffer_info *ring_info = >inbound;
-   u32 read_loc = ring_info->priv_read_index;
+   u32 priv_read_loc = ring_info->priv_read_index;
void *ring_buffer = hv_get_ring_buffer(ring_info);
-   struct vmpacket_descriptor *cur_desc;
-   u32 packetlen;
u32 dsize = ring_info->ring_datasize;
-   u32 delta = read_loc - ring_info->ring_buffer->read_index;
+   /*
+* delta is the difference between what is available to read and
+* what was already consumed in place. We commit read index after
+* the whole batch is processed.
+*/
+   u32 delta = priv_read_loc >= ring_info->ring_buffer->read_index ?
+   priv_read_loc - ring_info->ring_buffer->read_index :
+   (dsize - ring_info->ring_buffer->read_index) + priv_read_loc;
u32 bytes_avail_toread = (hv_get_bytes_to_read(ring_info) - delta);
 
if (bytes_avail_toread < sizeof(struct vmpacket_descriptor))
return NULL;
 
-   if ((read_loc + sizeof(*cur_desc)) > dsize)
-   return NULL;
-
-   cur_desc = ring_buffer + read_loc;
-   packetlen = cur_desc->len8 << 3;
-
-   /*
-* If the packet under consideration is wrapping around,
-* return failure.
-*/
-   if ((read_loc + packetlen + VMBUS_PKT_TRAILER) > (dsize - 1))
-   return NULL;
-
-   return cur_desc;
+   return ring_buffer + priv_read_loc;
 }
 
 /*
@@ -1555,16 +1547,14 @@ static inline void put_pkt_raw(struct vmbus_channel 
*channel,
struct vmpacket_descriptor *desc)
 {
struct hv_ring_buffer_info *ring_info = >inbound;
-   u32 read_loc = ring_info->priv_read_index;
u32 packetlen = desc->len8 << 3;
u32 dsize = ring_info->ring_datasize;
 
-   if ((read_loc + packetlen + VMBUS_PKT_TRAILER) > dsize)
-   BUG();
/*
 * Include the packet trailer.
 */
ring_info->priv_read_index += packetlen + VMBUS_PKT_TRAILER;
+   ring_info->priv_read_index %= dsize;
 }
 
 /*
-- 
1.7.4.1

[PATCH 01/15] Drivers: hv: ring_buffer: count on wrap around mappings in get_next_pkt_raw() (v2)

[kys]

From: Vitaly Kuznetsov 

With wrap around mappings in place we can always provide drivers with
direct links to packets on the ring buffer, even when they wrap around.
Do the required updates to get_next_pkt_raw()/put_pkt_raw()

The first version of this commit was reverted (65a532f3d50a) to deal with
cross-tree merge issues which are (hopefully) resolved now.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Tested-by: Dexuan Cui 
---
 include/linux/hyperv.h |   32 +++-
 1 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index cd184bd..2f65c30 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1519,31 +1519,23 @@ static inline struct vmpacket_descriptor *
 get_next_pkt_raw(struct vmbus_channel *channel)
 {
struct hv_ring_buffer_info *ring_info = >inbound;
-   u32 read_loc = ring_info->priv_read_index;
+   u32 priv_read_loc = ring_info->priv_read_index;
void *ring_buffer = hv_get_ring_buffer(ring_info);
-   struct vmpacket_descriptor *cur_desc;
-   u32 packetlen;
u32 dsize = ring_info->ring_datasize;
-   u32 delta = read_loc - ring_info->ring_buffer->read_index;
+   /*
+* delta is the difference between what is available to read and
+* what was already consumed in place. We commit read index after
+* the whole batch is processed.
+*/
+   u32 delta = priv_read_loc >= ring_info->ring_buffer->read_index ?
+   priv_read_loc - ring_info->ring_buffer->read_index :
+   (dsize - ring_info->ring_buffer->read_index) + priv_read_loc;
u32 bytes_avail_toread = (hv_get_bytes_to_read(ring_info) - delta);
 
if (bytes_avail_toread < sizeof(struct vmpacket_descriptor))
return NULL;
 
-   if ((read_loc + sizeof(*cur_desc)) > dsize)
-   return NULL;
-
-   cur_desc = ring_buffer + read_loc;
-   packetlen = cur_desc->len8 << 3;
-
-   /*
-* If the packet under consideration is wrapping around,
-* return failure.
-*/
-   if ((read_loc + packetlen + VMBUS_PKT_TRAILER) > (dsize - 1))
-   return NULL;
-
-   return cur_desc;
+   return ring_buffer + priv_read_loc;
 }
 
 /*
@@ -1555,16 +1547,14 @@ static inline void put_pkt_raw(struct vmbus_channel 
*channel,
struct vmpacket_descriptor *desc)
 {
struct hv_ring_buffer_info *ring_info = >inbound;
-   u32 read_loc = ring_info->priv_read_index;
u32 packetlen = desc->len8 << 3;
u32 dsize = ring_info->ring_datasize;
 
-   if ((read_loc + packetlen + VMBUS_PKT_TRAILER) > dsize)
-   BUG();
/*
 * Include the packet trailer.
 */
ring_info->priv_read_index += packetlen + VMBUS_PKT_TRAILER;
+   ring_info->priv_read_index %= dsize;
 }
 
 /*
-- 
1.7.4.1

[PATCH 12/15] vmbus: make sysfs names consistent with PCI

[kys]

From: Stephen Hemminger 

In commit 9a56e5d6a0ba ("Drivers: hv: make VMBus bus ids persistent")
the name of vmbus devices in sysfs changed to be (in 4.9-rc1):
  /sys/bus/vmbus/vmbus-6aebe374-9ba0-11e6-933c-00259086b36b

The prefix ("vmbus-") is redundant and differs from how PCI is
represented in sysfs. Therefore simplify to:
  /sys/bus/vmbus/6aebe374-9ba0-11e6-933c-00259086b36b

Please merge this before 4.9 is released and the old format
has to live forever.

Signed-off-by: Stephen Hemminger 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/vmbus_drv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index a259e18..0276d2e 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -961,7 +961,7 @@ int vmbus_device_register(struct hv_device 
*child_device_obj)
 {
int ret = 0;
 
-   dev_set_name(_device_obj->device, "vmbus-%pUl",
+   dev_set_name(_device_obj->device, "%pUl",
 child_device_obj->channel->offermsg.offer.if_instance.b);
 
child_device_obj->device.bus = _bus;
-- 
1.7.4.1

[PATCH 04/15] Drivers: hv: balloon: Disable hot add when CONFIG_MEMORY_HOTPLUG is not set

[kys]

From: Alex Ng 

If the guest does not support memory hotplugging, it should respond to
the host with zero pages added and successful result code. This signals
to the host that hotplugging is not supported and the host will avoid
sending future hot-add requests.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index fdf8da9..8f932aa 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1501,7 +1501,11 @@ static int balloon_probe(struct hv_device *dev,
struct dm_version_request version_req;
struct dm_capabilities cap_msg;
 
+#ifdef CONFIG_MEMORY_HOTPLUG
do_hot_add = hot_add;
+#else
+   do_hot_add = false;
+#endif
 
/*
 * First allocate a send buffer.
-- 
1.7.4.1

[PATCH 02/15] Drivers: hv: utils: reduce HV_UTIL_NEGO_TIMEOUT timeout

[kys]

From: Vitaly Kuznetsov 

I discovered that at least WS2016TP5 host has 60 seconds timeout for the
ICMSGTYPE_NEGOTIATE message so we need to lower guest's timeout a little
bit to make sure we always respond in time. Let's make it 55 seconds.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hyperv_vmbus.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index a5b4442..bdab7e7 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -38,7 +38,7 @@
 /*
  * Timeout for guest-host handshake for services.
  */
-#define HV_UTIL_NEGO_TIMEOUT 60
+#define HV_UTIL_NEGO_TIMEOUT 55
 
 /*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
-- 
1.7.4.1

[PATCH 02/15] Drivers: hv: utils: reduce HV_UTIL_NEGO_TIMEOUT timeout

[kys]

From: Vitaly Kuznetsov 

I discovered that at least WS2016TP5 host has 60 seconds timeout for the
ICMSGTYPE_NEGOTIATE message so we need to lower guest's timeout a little
bit to make sure we always respond in time. Let's make it 55 seconds.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hyperv_vmbus.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index a5b4442..bdab7e7 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -38,7 +38,7 @@
 /*
  * Timeout for guest-host handshake for services.
  */
-#define HV_UTIL_NEGO_TIMEOUT 60
+#define HV_UTIL_NEGO_TIMEOUT 55
 
 /*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
-- 
1.7.4.1

[PATCH 09/15] tools: hv: remove unnecessary link flag

[kys]

From: Weibing Zhang 

The link flag pthread is not needed.

Signed-off-by: Weibing Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/Makefile |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index a8c4644..0d1e61b 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -1,9 +1,8 @@
 # Makefile for Hyper-V tools
 
 CC = $(CROSS_COMPILE)gcc
-PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
-CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS)
+CFLAGS = $(WARNINGS) -g $(shell getconf LFS_CFLAGS)
 
 CFLAGS += -D__EXPORTED_HEADERS__ -I../../include/uapi -I../../include
 
-- 
1.7.4.1

[PATCH 07/15] Drivers: hv: vss: Operation timeouts should match host expectation

[kys]

From: Alex Ng 

Increase the timeout of backup operations. When system is under I/O load,
it needs more time to freeze. These timeout values should also match the
host timeout values more closely.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_snapshot.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
index 5c95ba1..eee238c 100644
--- a/drivers/hv/hv_snapshot.c
+++ b/drivers/hv/hv_snapshot.c
@@ -31,7 +31,10 @@
 #define VSS_MINOR  0
 #define VSS_VERSION(VSS_MAJOR << 16 | VSS_MINOR)
 
-#define VSS_USERSPACE_TIMEOUT (msecs_to_jiffies(10 * 1000))
+/*
+ * Timeout values are based on expecations from host
+ */
+#define VSS_FREEZE_TIMEOUT (15 * 60)
 
 /*
  * Global state maintained for transaction that is being processed. For a class
@@ -186,7 +189,8 @@ static void vss_send_op(void)
 
vss_transaction.state = HVUTIL_USERSPACE_REQ;
 
-   schedule_delayed_work(_timeout_work, VSS_USERSPACE_TIMEOUT);
+   schedule_delayed_work(_timeout_work, op == VSS_OP_FREEZE ?
+   VSS_FREEZE_TIMEOUT * HZ : HV_UTIL_TIMEOUT * HZ);
 
rc = hvutil_transport_send(hvt, vss_msg, sizeof(*vss_msg), NULL);
if (rc) {
-- 
1.7.4.1

[PATCH 09/15] tools: hv: remove unnecessary link flag

[kys]

From: Weibing Zhang 

The link flag pthread is not needed.

Signed-off-by: Weibing Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/Makefile |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index a8c4644..0d1e61b 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -1,9 +1,8 @@
 # Makefile for Hyper-V tools
 
 CC = $(CROSS_COMPILE)gcc
-PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
-CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS)
+CFLAGS = $(WARNINGS) -g $(shell getconf LFS_CFLAGS)
 
 CFLAGS += -D__EXPORTED_HEADERS__ -I../../include/uapi -I../../include
 
-- 
1.7.4.1

[PATCH 07/15] Drivers: hv: vss: Operation timeouts should match host expectation

[kys]

From: Alex Ng 

Increase the timeout of backup operations. When system is under I/O load,
it needs more time to freeze. These timeout values should also match the
host timeout values more closely.

Signed-off-by: Alex Ng 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_snapshot.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
index 5c95ba1..eee238c 100644
--- a/drivers/hv/hv_snapshot.c
+++ b/drivers/hv/hv_snapshot.c
@@ -31,7 +31,10 @@
 #define VSS_MINOR  0
 #define VSS_VERSION(VSS_MAJOR << 16 | VSS_MINOR)
 
-#define VSS_USERSPACE_TIMEOUT (msecs_to_jiffies(10 * 1000))
+/*
+ * Timeout values are based on expecations from host
+ */
+#define VSS_FREEZE_TIMEOUT (15 * 60)
 
 /*
  * Global state maintained for transaction that is being processed. For a class
@@ -186,7 +189,8 @@ static void vss_send_op(void)
 
vss_transaction.state = HVUTIL_USERSPACE_REQ;
 
-   schedule_delayed_work(_timeout_work, VSS_USERSPACE_TIMEOUT);
+   schedule_delayed_work(_timeout_work, op == VSS_OP_FREEZE ?
+   VSS_FREEZE_TIMEOUT * HZ : HV_UTIL_TIMEOUT * HZ);
 
rc = hvutil_transport_send(hvt, vss_msg, sizeof(*vss_msg), NULL);
if (rc) {
-- 
1.7.4.1

Re: [PATCH v5 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

[Rob Herring]

On Thu, Oct 27, 2016 at 02:05:34PM -0700, Markus Mayer wrote:
> From: Markus Mayer 
> 
> Add the binding document for the new brcmstb-avs-cpufreq driver.
> 
> Signed-off-by: Markus Mayer 
> Acked-by: Viresh Kumar 
> ---
>  .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 78 
> ++
>  MAINTAINERS|  7 ++
>  2 files changed, 85 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt

I guess if one of the nodes is used elsewhere, combining the nodes 
doesn't make sense. So:

Acked-by: Rob Herring 

Re: [PATCH v5 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

[Rob Herring]

On Thu, Oct 27, 2016 at 02:05:34PM -0700, Markus Mayer wrote:
> From: Markus Mayer 
> 
> Add the binding document for the new brcmstb-avs-cpufreq driver.
> 
> Signed-off-by: Markus Mayer 
> Acked-by: Viresh Kumar 
> ---
>  .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 78 
> ++
>  MAINTAINERS|  7 ++
>  2 files changed, 85 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt

I guess if one of the nodes is used elsewhere, combining the nodes 
doesn't make sense. So:

Acked-by: Rob Herring 

Re: [LKP] [lkp] [x86/platform/UV] 71854cb812: will-it-scale.per_thread_ops -2.3% regression

[Fengguang Wu]

Hi Thomas,

It's been a big challenge that we'll occasionally run into such bisect
whose data show clear changes, however cannot be easily explained by
looking at the code logic.

On Fri, Oct 28, 2016 at 12:37:45AM +0200, Thomas Gleixner wrote:

On Thu, 27 Oct 2016, Ye Xiaolong wrote:

Yes, this is weird, the per_thread_ops change is small and should be run
to run variation, the actual significant change is will-it-scale.time.user_time
-27% decrease, but the patch seems not relevant, we can't interpret it. :(

We've tried to queue the jobs (4 times) for
71854cb812ec23bfe5f63d52217e6b9e6cb901f5 and v4.9-rc1 with new kconfig
(added CONFIG_DEBUG_INFO_REDUCED), and result shows user_time change is
quite stable.



v4.9-rc1 71854cb812ec23bfe5f63d5221
 --
 %stddev %change %stddev
 \  |\
   1670068 ±  0%  -3.8%1606650 ±  1%  will-it-scale.per_thread_ops
  9749 ±  2%   +1328.0% 139222 ±105%  
will-it-scale.time.involuntary_context_switches


  ^^ This is massive

I have no explanation for this either, but you really should try to figure
out what's going on here.


Xiaolong, how about doing a small debug patch (a WARN_ONCE() line may
be enough) to verify whether the code path is executed?

It'd also help to compare vmlinux according to Thomas' reasoning:


The only difference between plain rc1 and rc + this patch is the resulting
text size and therefor some other unrelated stuff moving to different
places in memory which has some yet to figure out side effects.


Yeah that's possible.


From bisect POV, the below graphs show the user_time and system_time

are clearly and consistently different before/after commit 71854cb812.
So this commit must impacted something.

Legend:
   [*] bisect good samples (eg. tests run on commits before 71854cb812)
   [o] bisect bad samples  (eg. tests run on commits  since 71854cb812)

 will-it-scale.time.user_time

 85 ++-+
| .*.*..  .*..*..*..*.   .*.. .*..*.   .*  |
 80 *+  *.*..*  *..*  *..*..**  *..*.*.|
|  |
|  |
 75 ++ |
|  |
 70 ++ |
|  |
 65 ++ |
|  |
|OO|
 60 O+ OO   O   O O  O  OO  O  O O  O O  O O  O O  O
|O O  OO OOO  O|
 55 ++-+



 will-it-scale.time.system_time

 1010 ++---+
  ||
 1005 ++  O  O OO  O   O O  O O|
  O OOO  O  O O  O   O O  O O  O O  O O  O O
  |OO  |
 1000 ++   |
  ||
  995 ++   |
  ||
  990 ++   |
  ||
  ||
  985 ++   |
  *..*..*.*...*.*...*.*..*. .*...*.*..*.   |
  980 ++*--*-*-*---*-*-**-*-*--+


The voluntary_context_switches increase looks obvious, too, though not
as consistent:

   will-it-scale.time.voluntary_context_switches

 16 ++-+
|   O  |
 15 ++ |
|  |
 14 ++  O O   O|
|  

Re: [LKP] [lkp] [x86/platform/UV] 71854cb812: will-it-scale.per_thread_ops -2.3% regression

[Fengguang Wu]

Hi Thomas,

It's been a big challenge that we'll occasionally run into such bisect
whose data show clear changes, however cannot be easily explained by
looking at the code logic.

On Fri, Oct 28, 2016 at 12:37:45AM +0200, Thomas Gleixner wrote:

On Thu, 27 Oct 2016, Ye Xiaolong wrote:

Yes, this is weird, the per_thread_ops change is small and should be run
to run variation, the actual significant change is will-it-scale.time.user_time
-27% decrease, but the patch seems not relevant, we can't interpret it. :(

We've tried to queue the jobs (4 times) for
71854cb812ec23bfe5f63d52217e6b9e6cb901f5 and v4.9-rc1 with new kconfig
(added CONFIG_DEBUG_INFO_REDUCED), and result shows user_time change is
quite stable.



v4.9-rc1 71854cb812ec23bfe5f63d5221
 --
 %stddev %change %stddev
 \  |\
   1670068 ±  0%  -3.8%1606650 ±  1%  will-it-scale.per_thread_ops
  9749 ±  2%   +1328.0% 139222 ±105%  
will-it-scale.time.involuntary_context_switches


  ^^ This is massive

I have no explanation for this either, but you really should try to figure
out what's going on here.


Xiaolong, how about doing a small debug patch (a WARN_ONCE() line may
be enough) to verify whether the code path is executed?

It'd also help to compare vmlinux according to Thomas' reasoning:


The only difference between plain rc1 and rc + this patch is the resulting
text size and therefor some other unrelated stuff moving to different
places in memory which has some yet to figure out side effects.


Yeah that's possible.


From bisect POV, the below graphs show the user_time and system_time

are clearly and consistently different before/after commit 71854cb812.
So this commit must impacted something.

Legend:
   [*] bisect good samples (eg. tests run on commits before 71854cb812)
   [o] bisect bad samples  (eg. tests run on commits  since 71854cb812)

 will-it-scale.time.user_time

 85 ++-+
| .*.*..  .*..*..*..*.   .*.. .*..*.   .*  |
 80 *+  *.*..*  *..*  *..*..**  *..*.*.|
|  |
|  |
 75 ++ |
|  |
 70 ++ |
|  |
 65 ++ |
|  |
|OO|
 60 O+ OO   O   O O  O  OO  O  O O  O O  O O  O O  O
|O O  OO OOO  O|
 55 ++-+



 will-it-scale.time.system_time

 1010 ++---+
  ||
 1005 ++  O  O OO  O   O O  O O|
  O OOO  O  O O  O   O O  O O  O O  O O  O O
  |OO  |
 1000 ++   |
  ||
  995 ++   |
  ||
  990 ++   |
  ||
  ||
  985 ++   |
  *..*..*.*...*.*...*.*..*. .*...*.*..*.   |
  980 ++*--*-*-*---*-*-**-*-*--+


The voluntary_context_switches increase looks obvious, too, though not
as consistent:

   will-it-scale.time.voluntary_context_switches

 16 ++-+
|   O  |
 15 ++ |
|  |
 14 ++  O O   O|
|  

[PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[Dongli Zhang]

While grant reference is of type uint32_t, xen-netfront erroneously casts
it to signed short in BUG_ON().

This would lead to the xen domU panic during boot-up or migration when it
is attached with lots of paravirtual devices.

Signed-off-by: Dongli Zhang 
---
 drivers/net/xen-netfront.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e17879d..189a28d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue 
*queue)
queue->rx_skbs[id] = skb;
 
ref = gnttab_claim_grant_reference(>gref_rx_head);
-   BUG_ON((signed short)ref < 0);
+   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
queue->grant_rx_ref[id] = ref;
 
page = skb_frag_page(_shinfo(skb)->frags[0]);
@@ -428,7 +428,7 @@ static void xennet_tx_setup_grant(unsigned long gfn, 
unsigned int offset,
id = get_id_from_freelist(>tx_skb_freelist, queue->tx_skbs);
tx = RING_GET_REQUEST(>tx, queue->tx.req_prod_pvt++);
ref = gnttab_claim_grant_reference(>gref_tx_head);
-   BUG_ON((signed short)ref < 0);
+   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
 
gnttab_grant_foreign_access_ref(ref, queue->info->xbdev->otherend_id,
gfn, GNTMAP_readonly);
-- 
2.7.4

[PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[Dongli Zhang]

While grant reference is of type uint32_t, xen-netfront erroneously casts
it to signed short in BUG_ON().

This would lead to the xen domU panic during boot-up or migration when it
is attached with lots of paravirtual devices.

Signed-off-by: Dongli Zhang 
---
 drivers/net/xen-netfront.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e17879d..189a28d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue 
*queue)
queue->rx_skbs[id] = skb;
 
ref = gnttab_claim_grant_reference(>gref_rx_head);
-   BUG_ON((signed short)ref < 0);
+   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
queue->grant_rx_ref[id] = ref;
 
page = skb_frag_page(_shinfo(skb)->frags[0]);
@@ -428,7 +428,7 @@ static void xennet_tx_setup_grant(unsigned long gfn, 
unsigned int offset,
id = get_id_from_freelist(>tx_skb_freelist, queue->tx_skbs);
tx = RING_GET_REQUEST(>tx, queue->tx.req_prod_pvt++);
ref = gnttab_claim_grant_reference(>gref_tx_head);
-   BUG_ON((signed short)ref < 0);
+   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
 
gnttab_grant_foreign_access_ref(ref, queue->info->xbdev->otherend_id,
gfn, GNTMAP_readonly);
-- 
2.7.4

Re: [PATCH] cxl: Fix error handling

[Michael Ellerman]

Christophe JAILLET  writes:

> 'cxl_dev_context_init()' returns an error pointer in case of error, not
> NULL. So test it with IS_ERR.
>
> Signed-off-by: Christophe JAILLET 
> ---
> un-compiled because I don't have the required  cross build environment.

Do you run Ubuntu or Fedora? If so it's just a dnf/apt-get away:

$ sudo dnf install gcc-c++-powerpc64-linux-gnu binutils-powerpc64-linux-gnu 
gcc-powerpc64-linux-gnu
or
$ sudo apt-get install gcc-powerpc64le-linux-gnu gcc-powerpc-linux-gnu 
libc-dev-powerpc-cross libc-dev-ppc64el-cross

More here:

https://github.com/linuxppc/linux/wiki/Building-powerpc-kernels


cheers

Re: [PATCH] cxl: Fix error handling

[Michael Ellerman]

Christophe JAILLET  writes:

> 'cxl_dev_context_init()' returns an error pointer in case of error, not
> NULL. So test it with IS_ERR.
>
> Signed-off-by: Christophe JAILLET 
> ---
> un-compiled because I don't have the required  cross build environment.

Do you run Ubuntu or Fedora? If so it's just a dnf/apt-get away:

$ sudo dnf install gcc-c++-powerpc64-linux-gnu binutils-powerpc64-linux-gnu 
gcc-powerpc64-linux-gnu
or
$ sudo apt-get install gcc-powerpc64le-linux-gnu gcc-powerpc-linux-gnu 
libc-dev-powerpc-cross libc-dev-ppc64el-cross

More here:

https://github.com/linuxppc/linux/wiki/Building-powerpc-kernels


cheers

Re: [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor

[Rob Herring]

On Thu, Oct 27, 2016 at 03:00:23PM -0500, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Add the Arria10 DevKit System Resource Chip register and state
> monitoring module to the MFD.
> 
> Signed-off-by: Thor Thayer 
> ---
> Note: This needs to be applied to the bindings document that
> was Acked & Applied but didn't reach the for-next branch.
> See https://patchwork.ozlabs.org/patch/629397/
> ---
> v2  Change compatible string -mon to -monitor for clarity
> ---
>  Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt 
> b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> index ea151f2..c47be28 100644
> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
>  Device   Description
>  --   --
>  a10sr_gpio   GPIO Controller

This should be just "gpio" BTW.

> +a10sr_monitorRegister and State Monitoring

s/_/-/ or maybe just "monitor". Not really a generic node name to use 
for this.

Rob

Re: [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor

[Rob Herring]

On Thu, Oct 27, 2016 at 03:00:23PM -0500, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Add the Arria10 DevKit System Resource Chip register and state
> monitoring module to the MFD.
> 
> Signed-off-by: Thor Thayer 
> ---
> Note: This needs to be applied to the bindings document that
> was Acked & Applied but didn't reach the for-next branch.
> See https://patchwork.ozlabs.org/patch/629397/
> ---
> v2  Change compatible string -mon to -monitor for clarity
> ---
>  Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt 
> b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> index ea151f2..c47be28 100644
> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
>  Device   Description
>  --   --
>  a10sr_gpio   GPIO Controller

This should be just "gpio" BTW.

> +a10sr_monitorRegister and State Monitoring

s/_/-/ or maybe just "monitor". Not really a generic node name to use 
for this.

Rob

Re: [PATCH V3 3/6] dt/bindings: Add bindings for Tegra GMI controller

[Rob Herring]

On Thu, Oct 27, 2016 at 04:01:09PM +0200, Mirza Krak wrote:
> From: Mirza Krak 
> 
> Document the devicetree bindings for the Generic Memory Interface (GMI)
> bus driver found on Tegra SOCs.
> 
> Signed-off-by: Mirza Krak 
> Tested-by: Marcel Ziswiler 
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
> ---
> 
> Changes in v2:
> - Updated examples and some information based on comments from Jon Hunter.
> 
> Changes in v3:
> - Updates ranges description based on comments from Rob Herring
> 
>  .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 
> +
>  1 file changed, 132 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> 
> diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt 
> b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> new file mode 100644
> index 000..49bda2f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> @@ -0,0 +1,132 @@
> +Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
> +
> +The Generic Memory Interface bus enables memory transfers between internal 
> and
> +external memory. Can be used to attach various high speed devices such as
> +synchronous/asynchronous NOR, FPGA, UARTS and more.
> +
> +The actual devices are instantiated from the child nodes of a GMI node.
> +
> +Required properties:
> + - compatible : Should contain one of the following:
> +For Tegra20 must contain "nvidia,tegra20-gmi".
> +For Tegra30 must contain "nvidia,tegra30-gmi".
> + - reg: Should contain GMI controller registers location and length.
> + - clocks: Must contain an entry for each entry in clock-names.
> + - clock-names: Must include the following entries: "gmi"
> + - resets : Must contain an entry for each entry in reset-names.
> + - reset-names : Must include the following entries: "gmi"
> + - #address-cells: The number of cells used to represent physical base
> +   addresses in the GMI address space. Should be 2.
> + - #size-cells: The number of cells used to represent the size of an address
> +   range in the GMI address space. Should be 1.
> + - ranges: Must be set up to reflect the memory layout with three integer 
> values
> +   for each chip-select line in use (only one entry is supported, see below
> +   comments):
> +  
> +
> +Note that the GMI controller does not have any internal chip-select address
> +decoding, because of that chip-selects either need to be managed via software
> +or by employing external chip-select decoding logic.
> +
> +If external chip-select logic is used to support multiple devices it is 
> assumed
> +that the devices use the same timing and so are probably the same type. It 
> also
> +assumes that they can fit in the 256MB address range. In this case only one
> +child device is supported which represents the active chip-select line, see
> +examples for more insight.
> +
> +The chip-select number is decoded from the child nodes second address cell of
> +'ranges' property, if 'ranges' property is not present or empty chip-select 
> will
> +then be decoded from the first cell of the 'reg' property.
> +
> +Optional child cs node properties:
> +
> + - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
> + - nvidia,snor-mux-mode: Enable address/data MUX mode.
> + - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before 
> data.
> +   If omitted it will be asserted with data.
> + - nvidia,snor-rdy-inv: RDY signal is active high
> + - nvidia,snor-adv-inv: ADV signal is active high
> + - nvidia,snor-oe-inv: WE/OE signal is active high
> + - nvidia,snor-cs-inv: CS signal is active high

Inverted is meaningless unless I know what not inverted state is. Name 
the properties using "active high".

With that,

Acked-by: Rob Herring 

Re: [PATCH V3 3/6] dt/bindings: Add bindings for Tegra GMI controller

[Rob Herring]

On Thu, Oct 27, 2016 at 04:01:09PM +0200, Mirza Krak wrote:
> From: Mirza Krak 
> 
> Document the devicetree bindings for the Generic Memory Interface (GMI)
> bus driver found on Tegra SOCs.
> 
> Signed-off-by: Mirza Krak 
> Tested-by: Marcel Ziswiler 
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
> ---
> 
> Changes in v2:
> - Updated examples and some information based on comments from Jon Hunter.
> 
> Changes in v3:
> - Updates ranges description based on comments from Rob Herring
> 
>  .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 
> +
>  1 file changed, 132 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> 
> diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt 
> b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> new file mode 100644
> index 000..49bda2f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> @@ -0,0 +1,132 @@
> +Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
> +
> +The Generic Memory Interface bus enables memory transfers between internal 
> and
> +external memory. Can be used to attach various high speed devices such as
> +synchronous/asynchronous NOR, FPGA, UARTS and more.
> +
> +The actual devices are instantiated from the child nodes of a GMI node.
> +
> +Required properties:
> + - compatible : Should contain one of the following:
> +For Tegra20 must contain "nvidia,tegra20-gmi".
> +For Tegra30 must contain "nvidia,tegra30-gmi".
> + - reg: Should contain GMI controller registers location and length.
> + - clocks: Must contain an entry for each entry in clock-names.
> + - clock-names: Must include the following entries: "gmi"
> + - resets : Must contain an entry for each entry in reset-names.
> + - reset-names : Must include the following entries: "gmi"
> + - #address-cells: The number of cells used to represent physical base
> +   addresses in the GMI address space. Should be 2.
> + - #size-cells: The number of cells used to represent the size of an address
> +   range in the GMI address space. Should be 1.
> + - ranges: Must be set up to reflect the memory layout with three integer 
> values
> +   for each chip-select line in use (only one entry is supported, see below
> +   comments):
> +  
> +
> +Note that the GMI controller does not have any internal chip-select address
> +decoding, because of that chip-selects either need to be managed via software
> +or by employing external chip-select decoding logic.
> +
> +If external chip-select logic is used to support multiple devices it is 
> assumed
> +that the devices use the same timing and so are probably the same type. It 
> also
> +assumes that they can fit in the 256MB address range. In this case only one
> +child device is supported which represents the active chip-select line, see
> +examples for more insight.
> +
> +The chip-select number is decoded from the child nodes second address cell of
> +'ranges' property, if 'ranges' property is not present or empty chip-select 
> will
> +then be decoded from the first cell of the 'reg' property.
> +
> +Optional child cs node properties:
> +
> + - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
> + - nvidia,snor-mux-mode: Enable address/data MUX mode.
> + - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before 
> data.
> +   If omitted it will be asserted with data.
> + - nvidia,snor-rdy-inv: RDY signal is active high
> + - nvidia,snor-adv-inv: ADV signal is active high
> + - nvidia,snor-oe-inv: WE/OE signal is active high
> + - nvidia,snor-cs-inv: CS signal is active high

Inverted is meaningless unless I know what not inverted state is. Name 
the properties using "active high".

With that,

Acked-by: Rob Herring 

Re: [PATCH] console: use first console if stdout-path device doesn't appear

[Michael Ellerman]

Andreas Schwab  writes:

> Any news?

We discovered it also breaks VGA on qemu, which presumably is not the
type of news you were hoping for.


To reproduce you just need to build a ppc64le kernel:

$ apt-get install gcc-powerpc64le-linux-gnu
$ make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- pseries_le_defconfig
$ make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu-

And then run qemu:

$ qemu-system-ppc64 -M pseries -m 1G  -kernel vmlinux


Which will display the Tux logo but then nothing else and then reboot
after 10 seconds or so.

If you revert 05fd007e4629 on top of rc3 it boots fine.


Paul I tried your "console: use first console if stdout-path device
doesn't appear" patch, but it didn't help. I'll try and work out why,
but it's a bit hard with no output :)


If we can't come up with a fix soon I'm inclined to ask for a revert.

cheers

Re: [PATCH] console: use first console if stdout-path device doesn't appear

[Michael Ellerman]

Andreas Schwab  writes:

> Any news?

We discovered it also breaks VGA on qemu, which presumably is not the
type of news you were hoping for.


To reproduce you just need to build a ppc64le kernel:

$ apt-get install gcc-powerpc64le-linux-gnu
$ make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- pseries_le_defconfig
$ make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu-

And then run qemu:

$ qemu-system-ppc64 -M pseries -m 1G  -kernel vmlinux


Which will display the Tux logo but then nothing else and then reboot
after 10 seconds or so.

If you revert 05fd007e4629 on top of rc3 it boots fine.


Paul I tried your "console: use first console if stdout-path device
doesn't appear" patch, but it didn't help. I'll try and work out why,
but it's a bit hard with no output :)


If we can't come up with a fix soon I'm inclined to ask for a revert.

cheers

[patch v3 1/1] platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

[Vadim Pasternak]

Since mlx-platform is not an architectural driver, it is moved out
of arch/x86/platform to drivers/platform/x86.
Relevant Makefile and Kconfig are updated.

Signed-off-by: Vadim Pasternak 
---
v2->v3:
 Comments pointed out by Andy:
  - Remove "driver" prefix from the subject;
  - Change subject content;
  - Reduce CC list;
  - Put patch history exactly after '---' marker;
  - Remove reference to module name from module header;
  - Explain changes in Kconfig:
remove "depends on MLX_PLATFORM", since it has default n and this line
is not needed;
  Fixes added by Vadim:
  - Remove "select MLX_PLATFORM" from Kconfig, since it has unmet direct
dependencies (X86 && X86_PLATFORM_DEVICES && X86_64);
v1->v2:
 Comments pointed out by Andy:
  - Use -M -C -n option in git format-patch;
---
 MAINTAINERS |  2 +-
 arch/x86/Kconfig| 12 
 arch/x86/platform/Makefile  |  1 -
 arch/x86/platform/mellanox/Makefile |  1 -
 drivers/platform/x86/Kconfig| 13 -
 drivers/platform/x86/Makefile   |  1 +
 .../mellanox => drivers/platform/x86}/mlx-platform.c|  1 -
 7 files changed, 14 insertions(+), 17 deletions(-)
 delete mode 100644 arch/x86/platform/mellanox/Makefile
 rename {arch/x86/platform/mellanox => drivers/platform/x86}/mlx-platform.c 
(99%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3e30399..960f364f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7879,7 +7879,7 @@ MELLANOX PLATFORM DRIVER
 M:  Vadim Pasternak 
 L:  platform-driver-...@vger.kernel.org
 S:  Supported
-F:  arch/x86/platform/mellanox/mlx-platform.c
+F:  drivers/platform/x86/mlx-platform.c
 
 MELLANOX MLX CPLD HOTPLUG DRIVER
 M: Vadim Pasternak 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..ccd5ff7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -550,18 +550,6 @@ config X86_INTEL_QUARK
  Say Y here if you have a Quark based system such as the Arduino
  compatible Intel Galileo.
 
-config MLX_PLATFORM
-   tristate "Mellanox Technologies platform support"
-   depends on X86_64
-   depends on X86_EXTENDED_PLATFORM
-   ---help---
- This option enables system support for the Mellanox Technologies
- platform.
-
- Say Y here if you are building a kernel for Mellanox system.
-
- Otherwise, say N.
-
 config X86_INTEL_LPSS
bool "Intel Low Power Subsystem Support"
depends on X86 && ACPI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 3c3c19e..184842e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,7 +8,6 @@ obj-y   += iris/
 obj-y  += intel/
 obj-y  += intel-mid/
 obj-y  += intel-quark/
-obj-y  += mellanox/
 obj-y  += olpc/
 obj-y  += scx200/
 obj-y  += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile 
b/arch/x86/platform/mellanox/Makefile
deleted file mode 100644
index f43c931..000
--- a/arch/x86/platform/mellanox/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 1853769..4639d97 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1028,10 +1028,21 @@ config INTEL_TELEMETRY
  directly via debugfs files. Various tools may use
  this interface for SoC state monitoring.
 
+config MLX_PLATFORM
+   tristate "Mellanox Technologies platform support"
+   depends on X86_64
+   ---help---
+ This option enables system support for the Mellanox Technologies
+ platform. The Mellanox systems provide data center networking
+ solutions based on Virtual Protocol Interconnect (VPI) technology
+ enable seamless connectivity to 56/100Gb/s InfiniBand or 10/40/56GbE
+ connection.
+
+ If you have a Mellanox system, say Y or M here.
+
 config MLX_CPLD_PLATFORM
tristate "Mellanox platform hotplug driver support"
default n
-   depends on MLX_PLATFORM
select HWMON
select I2C
---help---
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 1f06b63..2d6a587 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -71,4 +71,5 @@ obj-$(CONFIG_INTEL_TELEMETRY) += intel_telemetry_core.o \
   intel_telemetry_pltdrv.o \
   intel_telemetry_debugfs.o
 obj-$(CONFIG_INTEL_PMC_CORE)+= intel_pmc_core.o
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
 obj-$(CONFIG_MLX_CPLD_PLATFORM)+= mlxcpld-hotplug.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
similarity index 99%
rename 

[patch v3 1/1] platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

[Vadim Pasternak]

Since mlx-platform is not an architectural driver, it is moved out
of arch/x86/platform to drivers/platform/x86.
Relevant Makefile and Kconfig are updated.

Signed-off-by: Vadim Pasternak 
---
v2->v3:
 Comments pointed out by Andy:
  - Remove "driver" prefix from the subject;
  - Change subject content;
  - Reduce CC list;
  - Put patch history exactly after '---' marker;
  - Remove reference to module name from module header;
  - Explain changes in Kconfig:
remove "depends on MLX_PLATFORM", since it has default n and this line
is not needed;
  Fixes added by Vadim:
  - Remove "select MLX_PLATFORM" from Kconfig, since it has unmet direct
dependencies (X86 && X86_PLATFORM_DEVICES && X86_64);
v1->v2:
 Comments pointed out by Andy:
  - Use -M -C -n option in git format-patch;
---
 MAINTAINERS |  2 +-
 arch/x86/Kconfig| 12 
 arch/x86/platform/Makefile  |  1 -
 arch/x86/platform/mellanox/Makefile |  1 -
 drivers/platform/x86/Kconfig| 13 -
 drivers/platform/x86/Makefile   |  1 +
 .../mellanox => drivers/platform/x86}/mlx-platform.c|  1 -
 7 files changed, 14 insertions(+), 17 deletions(-)
 delete mode 100644 arch/x86/platform/mellanox/Makefile
 rename {arch/x86/platform/mellanox => drivers/platform/x86}/mlx-platform.c 
(99%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3e30399..960f364f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7879,7 +7879,7 @@ MELLANOX PLATFORM DRIVER
 M:  Vadim Pasternak 
 L:  platform-driver-...@vger.kernel.org
 S:  Supported
-F:  arch/x86/platform/mellanox/mlx-platform.c
+F:  drivers/platform/x86/mlx-platform.c
 
 MELLANOX MLX CPLD HOTPLUG DRIVER
 M: Vadim Pasternak 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..ccd5ff7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -550,18 +550,6 @@ config X86_INTEL_QUARK
  Say Y here if you have a Quark based system such as the Arduino
  compatible Intel Galileo.
 
-config MLX_PLATFORM
-   tristate "Mellanox Technologies platform support"
-   depends on X86_64
-   depends on X86_EXTENDED_PLATFORM
-   ---help---
- This option enables system support for the Mellanox Technologies
- platform.
-
- Say Y here if you are building a kernel for Mellanox system.
-
- Otherwise, say N.
-
 config X86_INTEL_LPSS
bool "Intel Low Power Subsystem Support"
depends on X86 && ACPI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 3c3c19e..184842e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,7 +8,6 @@ obj-y   += iris/
 obj-y  += intel/
 obj-y  += intel-mid/
 obj-y  += intel-quark/
-obj-y  += mellanox/
 obj-y  += olpc/
 obj-y  += scx200/
 obj-y  += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile 
b/arch/x86/platform/mellanox/Makefile
deleted file mode 100644
index f43c931..000
--- a/arch/x86/platform/mellanox/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 1853769..4639d97 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1028,10 +1028,21 @@ config INTEL_TELEMETRY
  directly via debugfs files. Various tools may use
  this interface for SoC state monitoring.
 
+config MLX_PLATFORM
+   tristate "Mellanox Technologies platform support"
+   depends on X86_64
+   ---help---
+ This option enables system support for the Mellanox Technologies
+ platform. The Mellanox systems provide data center networking
+ solutions based on Virtual Protocol Interconnect (VPI) technology
+ enable seamless connectivity to 56/100Gb/s InfiniBand or 10/40/56GbE
+ connection.
+
+ If you have a Mellanox system, say Y or M here.
+
 config MLX_CPLD_PLATFORM
tristate "Mellanox platform hotplug driver support"
default n
-   depends on MLX_PLATFORM
select HWMON
select I2C
---help---
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 1f06b63..2d6a587 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -71,4 +71,5 @@ obj-$(CONFIG_INTEL_TELEMETRY) += intel_telemetry_core.o \
   intel_telemetry_pltdrv.o \
   intel_telemetry_debugfs.o
 obj-$(CONFIG_INTEL_PMC_CORE)+= intel_pmc_core.o
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
 obj-$(CONFIG_MLX_CPLD_PLATFORM)+= mlxcpld-hotplug.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
similarity index 99%
rename from arch/x86/platform/mellanox/mlx-platform.c
rename to 

Re: [PATCH v2] iommu/ipmmu-vmsa: Add r8a7796 DT binding

[Rob Herring]

On Thu, Oct 27, 2016 at 07:45:10PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Update the IPMMU DT binding documentation to include the r8a7796 compat
> string for R-Car M3-W.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Laurent Pinchart 
> ---
> 
>  Changes since V1:
>  - Added Acked-by from Laurent - thanks!
> 
>  Now broken out, however earlier V1 posted as part of:
>  [PATCH 0/3] iommu/ipmmu-vmsa: Initial r8a7796 support
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v2] iommu/ipmmu-vmsa: Add r8a7796 DT binding

[Rob Herring]

On Thu, Oct 27, 2016 at 07:45:10PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Update the IPMMU DT binding documentation to include the r8a7796 compat
> string for R-Car M3-W.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Laurent Pinchart 
> ---
> 
>  Changes since V1:
>  - Added Acked-by from Laurent - thanks!
> 
>  Now broken out, however earlier V1 posted as part of:
>  [PATCH 0/3] iommu/ipmmu-vmsa: Initial r8a7796 support
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v3 1/4] dt/bindings: Add binding for the DA8xx MUSB driver

[Rob Herring]

On Thu, Oct 27, 2016 at 11:34:04AM +0200, Alexandre Bailon wrote:
> From: Petr Kulhavy 
> 
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
> 
> Signed-off-by: Petr Kulhavy 
> Signed-off-by: Alexandre Bailon 
> ---
>  .../devicetree/bindings/usb/da8xx-usb.txt  | 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt

Acked-by: Rob Herring 

Re: [PATCH v3 1/4] dt/bindings: Add binding for the DA8xx MUSB driver

[Rob Herring]

On Thu, Oct 27, 2016 at 11:34:04AM +0200, Alexandre Bailon wrote:
> From: Petr Kulhavy 
> 
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
> 
> Signed-off-by: Petr Kulhavy 
> Signed-off-by: Alexandre Bailon 
> ---
>  .../devicetree/bindings/usb/da8xx-usb.txt  | 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt

Acked-by: Rob Herring 

Re: [linus:master] BUILD REGRESSION 2a26d99b251b8625d27aed14e97fc10707a3a81f

[Fengguang Wu]

Hi Linus,

On Sun, Oct 30, 2016 at 01:25:50PM -0700, Linus Torvalds wrote:

On Sun, Oct 30, 2016 at 11:03 AM, kbuild test robot
 wrote:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  master
2a26d99b251b8625d27aed14e97fc10707a3a81f  Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net


Hmm. The build errors seem to be pretty independent of that merge,
including internal compiler errors etc.


This "BUILD REGRESSION" report lists errors in all commits of a branch
-- ie. not only the showed HEAD commit. Sure "all commits" will be too
huge for the mainline kernel, so there will be limits applied.


Did perhaps something change in the kbuild test robot?


Recently we lowered the threshold to 2 before sending unsolicited
reports like this. That threshold means when we find >= 3 errors in a
tree, only the first 2 will be reported in the regular way (reporting
to the first bad commit). The more errors will be send in a summary
"BUILD REGRESSION" email listing all the triggered errors.

That's a trick to avoid flooding possibly large number of duplicate
error reports to LKML while avoiding hiding possibly non-duplicate
errors. It works well for normal branches, however looks less
effective for linus/master because here we have less clue about the
origin of errors.

So sorry -- this report is a noise. The fix could be to raise the
reporting threshold significantly for linus/master. It's also possible
some bug in the 0day-bot triggered this report unexpectedly.

Regards,
Fengguang

Re: [linus:master] BUILD REGRESSION 2a26d99b251b8625d27aed14e97fc10707a3a81f

[Fengguang Wu]

Hi Linus,

On Sun, Oct 30, 2016 at 01:25:50PM -0700, Linus Torvalds wrote:

On Sun, Oct 30, 2016 at 11:03 AM, kbuild test robot
 wrote:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  master
2a26d99b251b8625d27aed14e97fc10707a3a81f  Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net


Hmm. The build errors seem to be pretty independent of that merge,
including internal compiler errors etc.


This "BUILD REGRESSION" report lists errors in all commits of a branch
-- ie. not only the showed HEAD commit. Sure "all commits" will be too
huge for the mainline kernel, so there will be limits applied.


Did perhaps something change in the kbuild test robot?


Recently we lowered the threshold to 2 before sending unsolicited
reports like this. That threshold means when we find >= 3 errors in a
tree, only the first 2 will be reported in the regular way (reporting
to the first bad commit). The more errors will be send in a summary
"BUILD REGRESSION" email listing all the triggered errors.

That's a trick to avoid flooding possibly large number of duplicate
error reports to LKML while avoiding hiding possibly non-duplicate
errors. It works well for normal branches, however looks less
effective for linus/master because here we have less clue about the
origin of errors.

So sorry -- this report is a noise. The fix could be to raise the
reporting threshold significantly for linus/master. It's also possible
some bug in the 0day-bot triggered this report unexpectedly.

Regards,
Fengguang

Re: [PATCH v2 09/10] pwm: imx: doc: Update imx-pwm.txt documentation entry

[Rob Herring]

On Thu, Oct 27, 2016 at 08:33:19AM +0200, Lukasz Majewski wrote:
> The imx-pwm.txt documentation update as a preparation for polarity
> support.
> 
> Signed-off-by: Bhuvanchandra DV 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - New patch
> ---
>  Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v2 09/10] pwm: imx: doc: Update imx-pwm.txt documentation entry

[Rob Herring]

On Thu, Oct 27, 2016 at 08:33:19AM +0200, Lukasz Majewski wrote:
> The imx-pwm.txt documentation update as a preparation for polarity
> support.
> 
> Signed-off-by: Bhuvanchandra DV 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - New patch
> ---
>  Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH] IBcore/CM: Issue DREQ when receiving REQ/REP for stale QP

[santosh.shilim...@oracle.com]

On 10/30/16 2:06 PM, Sagi Grimberg wrote:

from "InfiBand Architecture Specifications Volume 1":

  A QP is said to have a stale connection when only one side has
  connection information. A stale connection may result if the remote CM
  had dropped the connection and sent a DREQ but the DREQ was never
  received by the local CM. Alternatively the remote CM may have lost
  all record of past connections because its node crashed and rebooted,
  while the local CM did not become aware of the remote node's reboot
  and therefore did not clean up stale connections.

and:

   A local CM may receive a REQ/REP for a stale connection. It shall
   abort the connection issuing REJ to the REQ/REP. It shall then issue
   DREQ with "DREQ:remote QPN” set to the remote QPN from the REQ/REP.

This patch solves a problem with reuse of QPN. Current codebase, that
is IPoIB, relies on a REAP-mechanism to do cleanup of the structures
in CM. A problem with this is the timeconstants governing this
mechanism; they are up to 768 seconds and the interface may look
inresponsive in that period.  Issuing a DREQ (and receiving a DREP)
does the necessary cleanup and the interface comes up.


I like this fix, so,


Me too and hence suggested Hans to post it on rdma list when
saw this patch in internal review.


Reviewed-by: Sagi Grimberg 

But I think the CM layer still is buggy in this area.

In vol 1 the state transition table specifically states that DREP
timeouts should move the cm_id to timewait state but the CM doesn't
seem to maintain response timeouts on disconnect requests. If the
DREQ happened to fail (send error completion) things are fine, but
if the DREQ makes it to the peer but it doesn't reply then no one
will take care of it (i.e. we will never see a TIMEWAIT event from
this cm_id)...

I recall some debugging session with Hal on this area a ~year ago
with a new iser target (which didn't reply to DREQs on reboot
sequences). iser initiator waits for a DISCONNECTED/TIMEWAIT events
before destroying the cm_id (which never happened because of the
above). I think I ended up working around that in iser to just go
ahead and destroy the cm_id after issuing a DREQ (but now I realize
it was never included so I'll probably dig it up again soon).


There is another fundamental issue with core CM code wrt DREQ
getting dropped. The the mad agent used to send the DREQ is
associated with a port and if this port is down, the IB link
layer will drop that DREQ as per SPEC. Similarly if the destination
port is down where the DREQ is suppose to reach, then the DREQ
gets dropped there too. These dropped CM ids are retried by MAD
agent on same port till the port comes back alive.

Am not sure in your case the ports were going down or not
but it was the case then IIUC, what you are doing for ISER is
still needed (up front destroying the cm id).

Regards,
Santosh

Re: [PATCH] IBcore/CM: Issue DREQ when receiving REQ/REP for stale QP

[santosh.shilim...@oracle.com]

On 10/30/16 2:06 PM, Sagi Grimberg wrote:

from "InfiBand Architecture Specifications Volume 1":

  A QP is said to have a stale connection when only one side has
  connection information. A stale connection may result if the remote CM
  had dropped the connection and sent a DREQ but the DREQ was never
  received by the local CM. Alternatively the remote CM may have lost
  all record of past connections because its node crashed and rebooted,
  while the local CM did not become aware of the remote node's reboot
  and therefore did not clean up stale connections.

and:

   A local CM may receive a REQ/REP for a stale connection. It shall
   abort the connection issuing REJ to the REQ/REP. It shall then issue
   DREQ with "DREQ:remote QPN” set to the remote QPN from the REQ/REP.

This patch solves a problem with reuse of QPN. Current codebase, that
is IPoIB, relies on a REAP-mechanism to do cleanup of the structures
in CM. A problem with this is the timeconstants governing this
mechanism; they are up to 768 seconds and the interface may look
inresponsive in that period.  Issuing a DREQ (and receiving a DREP)
does the necessary cleanup and the interface comes up.


I like this fix, so,


Me too and hence suggested Hans to post it on rdma list when
saw this patch in internal review.


Reviewed-by: Sagi Grimberg 

But I think the CM layer still is buggy in this area.

In vol 1 the state transition table specifically states that DREP
timeouts should move the cm_id to timewait state but the CM doesn't
seem to maintain response timeouts on disconnect requests. If the
DREQ happened to fail (send error completion) things are fine, but
if the DREQ makes it to the peer but it doesn't reply then no one
will take care of it (i.e. we will never see a TIMEWAIT event from
this cm_id)...

I recall some debugging session with Hal on this area a ~year ago
with a new iser target (which didn't reply to DREQs on reboot
sequences). iser initiator waits for a DISCONNECTED/TIMEWAIT events
before destroying the cm_id (which never happened because of the
above). I think I ended up working around that in iser to just go
ahead and destroy the cm_id after issuing a DREQ (but now I realize
it was never included so I'll probably dig it up again soon).


There is another fundamental issue with core CM code wrt DREQ
getting dropped. The the mad agent used to send the DREQ is
associated with a port and if this port is down, the IB link
layer will drop that DREQ as per SPEC. Similarly if the destination
port is down where the DREQ is suppose to reach, then the DREQ
gets dropped there too. These dropped CM ids are retried by MAD
agent on same port till the port comes back alive.

Am not sure in your case the ports were going down or not
but it was the case then IIUC, what you are doing for ISER is
still needed (up front destroying the cm id).

Regards,
Santosh

[PATCH] dt-bindings/gpio: Add Aspeed GPIO bindings header

[Joel Stanley]

This provides constants for using GPIOs in the device tree on Aspeed
SoCs.

Signed-off-by: Joel Stanley 
---
The Apseed GPIO driver and binding document went upstream in 4.9, but we forgot
to send this patch as part of the series.

 include/dt-bindings/gpio/aspeed-gpio.h | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h

diff --git a/include/dt-bindings/gpio/aspeed-gpio.h 
b/include/dt-bindings/gpio/aspeed-gpio.h
new file mode 100644
index ..058c527cbcaf
--- /dev/null
+++ b/include/dt-bindings/gpio/aspeed-gpio.h
@@ -0,0 +1,47 @@
+/*
+ * This header provides constants for binding aspeed,*-gpio.
+ *
+ * The first cell in Aspeed's GPIO specifier is the GPIO ID. The macros below
+ * provide names for this.
+ *
+ * The second cell contains standard flag values specified in gpio.h.
+ */
+
+#ifndef _DT_BINDINGS_GPIO_ASPEED_GPIO_H
+#define _DT_BINDINGS_GPIO_ASPEED_GPIO_H
+
+#include 
+
+#define ASPEED_GPIO_PORT_A 0
+#define ASPEED_GPIO_PORT_B 1
+#define ASPEED_GPIO_PORT_C 2
+#define ASPEED_GPIO_PORT_D 3
+#define ASPEED_GPIO_PORT_E 4
+#define ASPEED_GPIO_PORT_F 5
+#define ASPEED_GPIO_PORT_G 6
+#define ASPEED_GPIO_PORT_H 7
+#define ASPEED_GPIO_PORT_I 8
+#define ASPEED_GPIO_PORT_J 9
+#define ASPEED_GPIO_PORT_K 10
+#define ASPEED_GPIO_PORT_L 11
+#define ASPEED_GPIO_PORT_M 12
+#define ASPEED_GPIO_PORT_N 13
+#define ASPEED_GPIO_PORT_O 14
+#define ASPEED_GPIO_PORT_P 15
+#define ASPEED_GPIO_PORT_Q 16
+#define ASPEED_GPIO_PORT_R 17
+#define ASPEED_GPIO_PORT_S 18
+#define ASPEED_GPIO_PORT_T 19
+#define ASPEED_GPIO_PORT_U 20
+#define ASPEED_GPIO_PORT_V 21
+#define ASPEED_GPIO_PORT_W 22
+#define ASPEED_GPIO_PORT_X 23
+#define ASPEED_GPIO_PORT_Y 24
+#define ASPEED_GPIO_PORT_Z 25
+#define ASPEED_GPIO_PORT_AA 26
+#define ASPEED_GPIO_PORT_BB 27
+
+#define ASPEED_GPIO(port, offset) \
+   ((ASPEED_GPIO_PORT_##port * 8) + offset)
+
+#endif
-- 
2.9.3

[PATCH] dt-bindings/gpio: Add Aspeed GPIO bindings header

[Joel Stanley]

This provides constants for using GPIOs in the device tree on Aspeed
SoCs.

Signed-off-by: Joel Stanley 
---
The Apseed GPIO driver and binding document went upstream in 4.9, but we forgot
to send this patch as part of the series.

 include/dt-bindings/gpio/aspeed-gpio.h | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h

diff --git a/include/dt-bindings/gpio/aspeed-gpio.h 
b/include/dt-bindings/gpio/aspeed-gpio.h
new file mode 100644
index ..058c527cbcaf
--- /dev/null
+++ b/include/dt-bindings/gpio/aspeed-gpio.h
@@ -0,0 +1,47 @@
+/*
+ * This header provides constants for binding aspeed,*-gpio.
+ *
+ * The first cell in Aspeed's GPIO specifier is the GPIO ID. The macros below
+ * provide names for this.
+ *
+ * The second cell contains standard flag values specified in gpio.h.
+ */
+
+#ifndef _DT_BINDINGS_GPIO_ASPEED_GPIO_H
+#define _DT_BINDINGS_GPIO_ASPEED_GPIO_H
+
+#include 
+
+#define ASPEED_GPIO_PORT_A 0
+#define ASPEED_GPIO_PORT_B 1
+#define ASPEED_GPIO_PORT_C 2
+#define ASPEED_GPIO_PORT_D 3
+#define ASPEED_GPIO_PORT_E 4
+#define ASPEED_GPIO_PORT_F 5
+#define ASPEED_GPIO_PORT_G 6
+#define ASPEED_GPIO_PORT_H 7
+#define ASPEED_GPIO_PORT_I 8
+#define ASPEED_GPIO_PORT_J 9
+#define ASPEED_GPIO_PORT_K 10
+#define ASPEED_GPIO_PORT_L 11
+#define ASPEED_GPIO_PORT_M 12
+#define ASPEED_GPIO_PORT_N 13
+#define ASPEED_GPIO_PORT_O 14
+#define ASPEED_GPIO_PORT_P 15
+#define ASPEED_GPIO_PORT_Q 16
+#define ASPEED_GPIO_PORT_R 17
+#define ASPEED_GPIO_PORT_S 18
+#define ASPEED_GPIO_PORT_T 19
+#define ASPEED_GPIO_PORT_U 20
+#define ASPEED_GPIO_PORT_V 21
+#define ASPEED_GPIO_PORT_W 22
+#define ASPEED_GPIO_PORT_X 23
+#define ASPEED_GPIO_PORT_Y 24
+#define ASPEED_GPIO_PORT_Z 25
+#define ASPEED_GPIO_PORT_AA 26
+#define ASPEED_GPIO_PORT_BB 27
+
+#define ASPEED_GPIO(port, offset) \
+   ((ASPEED_GPIO_PORT_##port * 8) + offset)
+
+#endif
-- 
2.9.3

Re: [PATCH V2 1/4] Documentation: pv88080: Move binding document

[Rob Herring]

On Thu, Oct 27, 2016 at 10:03:14AM +0900, Eric Jeong wrote:
> 
> From: Eric Jeong 
> 
> The change is to move pv88080 binding document 
> from the regulator directory to mfd binding directory
> for PV88080 PMIC MFD support.
> 
> 
> Signed-off-by: Eric Jeong 
> 
> ---
> This patch applies against linux-next and next-20161026
> 
> Hi,
> 
> Change since PATCH V1
>  - Patch separated from PATCH V1
> 
> Regards,
> Eric Jeong, Dialog Semiconductor Ltd.
> 
> 
>  Documentation/devicetree/bindings/mfd/pv88080.txt  |   63 
> 
>  .../devicetree/bindings/regulator/pv88080.txt  |   62 ---
>  2 files changed, 63 insertions(+), 62 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/pv88080.txt
>  delete mode 100644 Documentation/devicetree/bindings/regulator/pv88080.txt

Please resend using git-format-patch -M option.

Rob

Re: [PATCH V2 1/4] Documentation: pv88080: Move binding document

[Rob Herring]

On Thu, Oct 27, 2016 at 10:03:14AM +0900, Eric Jeong wrote:
> 
> From: Eric Jeong 
> 
> The change is to move pv88080 binding document 
> from the regulator directory to mfd binding directory
> for PV88080 PMIC MFD support.
> 
> 
> Signed-off-by: Eric Jeong 
> 
> ---
> This patch applies against linux-next and next-20161026
> 
> Hi,
> 
> Change since PATCH V1
>  - Patch separated from PATCH V1
> 
> Regards,
> Eric Jeong, Dialog Semiconductor Ltd.
> 
> 
>  Documentation/devicetree/bindings/mfd/pv88080.txt  |   63 
> 
>  .../devicetree/bindings/regulator/pv88080.txt  |   62 ---
>  2 files changed, 63 insertions(+), 62 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/pv88080.txt
>  delete mode 100644 Documentation/devicetree/bindings/regulator/pv88080.txt

Please resend using git-format-patch -M option.

Rob

Re: [PATCH V2] pinctrl: qcom: Add msm8994 pinctrl driver

[Rob Herring]

On Wed, Oct 26, 2016 at 04:32:28PM -0700, Michael Scott wrote:
> Initial pinctrl driver for QCOM msm8994 platforms.
> 
> In order to continue the initial board support for QCOM msm8994/msm8992
> presented in patches from Jeremy McNicoll , let's put
> a proper pinctrl driver in place.
> 
> Currently, the DT for these platforms uses the msm8x74 pinctrl driver to 
> enable
> basic UART.  Beyond the first few pins the rest are different enough to 
> justify
> it's own driver.
> 
> Note: This driver is also be used by QCOM's msm8992 platform as it's TLM block
> is the same.
> 
> - Initial formatting and style was taken from the msm8x74 pinctrl driver added
>   by Björn Andersson 
> - Data was then adjusted per QCOM MSM8994 documentation for Top Level 
> Multiplexing
> - Bindings documentation was based on qcom,msm8996-pinctrl.txt by
>   Joonwoo Park  and then modified for msm8994 content
> 
> Signed-off-by: Michael Scott 
> ---
> 
> V1 -> V2: fixed missing FUNCTION(nav_pps) and removed 3 odd newlines between 
> blsp_i2c4_groups and cci_timer0_groups
> 
>  .../bindings/pinctrl/qcom,msm8994-pinctrl.txt  |  175 +++

Acked-by: Rob Herring 

>  drivers/pinctrl/qcom/Kconfig   |9 +
>  drivers/pinctrl/qcom/Makefile  |1 +
>  drivers/pinctrl/qcom/pinctrl-msm8994.c | 1400 
> 
>  4 files changed, 1585 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.txt
>  create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8994.c

[PATCH] drm/radeon: Fix kernel panic on shutdown

[Larry Finger]

Since commit a481daa88fd4 ("drm/radeon: always apply pci shutdown
callbacks"), a Dell Latitude D600 laptop has crashed on shutdown. The
PCI Identification of the graphics adapter is "VGA compatible controller
[0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV250/M9 GL [Mobility
FireGL 9000/Radeon 9000] [1002:4c66] (rev 01)".

Prior to commit b0c80bd5d2e3 ("drm/radeon: fix up dp aux tear down (v2)"),
I have no idea where the panic happened as the screen was blanked before
the crash.  Since that more recent change, the panic has been in routine
radeon_connector_unregister(), and has been shown to be due to a NULL
value in the ddc_bus member of struct drm_connector.

Fixes: a481daa88fd4 ("drm/radeon: always apply pci shutdown callbacks")
Signed-off-by: Larry Finger 
Cc: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index e18839d..27affbd 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -931,7 +931,7 @@ static void radeon_connector_unregister(struct 
drm_connector *connector)
 {
struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
 
-   if (radeon_connector->ddc_bus->has_aux) {
+   if (radeon_connector->ddc_bus && radeon_connector->ddc_bus->has_aux) {
drm_dp_aux_unregister(_connector->ddc_bus->aux);
radeon_connector->ddc_bus->has_aux = false;
}
-- 
2.10.0

Re: [PATCH V2] pinctrl: qcom: Add msm8994 pinctrl driver

[Rob Herring]

On Wed, Oct 26, 2016 at 04:32:28PM -0700, Michael Scott wrote:
> Initial pinctrl driver for QCOM msm8994 platforms.
> 
> In order to continue the initial board support for QCOM msm8994/msm8992
> presented in patches from Jeremy McNicoll , let's put
> a proper pinctrl driver in place.
> 
> Currently, the DT for these platforms uses the msm8x74 pinctrl driver to 
> enable
> basic UART.  Beyond the first few pins the rest are different enough to 
> justify
> it's own driver.
> 
> Note: This driver is also be used by QCOM's msm8992 platform as it's TLM block
> is the same.
> 
> - Initial formatting and style was taken from the msm8x74 pinctrl driver added
>   by Björn Andersson 
> - Data was then adjusted per QCOM MSM8994 documentation for Top Level 
> Multiplexing
> - Bindings documentation was based on qcom,msm8996-pinctrl.txt by
>   Joonwoo Park  and then modified for msm8994 content
> 
> Signed-off-by: Michael Scott 
> ---
> 
> V1 -> V2: fixed missing FUNCTION(nav_pps) and removed 3 odd newlines between 
> blsp_i2c4_groups and cci_timer0_groups
> 
>  .../bindings/pinctrl/qcom,msm8994-pinctrl.txt  |  175 +++

Acked-by: Rob Herring 

>  drivers/pinctrl/qcom/Kconfig   |9 +
>  drivers/pinctrl/qcom/Makefile  |1 +
>  drivers/pinctrl/qcom/pinctrl-msm8994.c | 1400 
> 
>  4 files changed, 1585 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.txt
>  create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8994.c

[PATCH] drm/radeon: Fix kernel panic on shutdown

[Larry Finger]

Since commit a481daa88fd4 ("drm/radeon: always apply pci shutdown
callbacks"), a Dell Latitude D600 laptop has crashed on shutdown. The
PCI Identification of the graphics adapter is "VGA compatible controller
[0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV250/M9 GL [Mobility
FireGL 9000/Radeon 9000] [1002:4c66] (rev 01)".

Prior to commit b0c80bd5d2e3 ("drm/radeon: fix up dp aux tear down (v2)"),
I have no idea where the panic happened as the screen was blanked before
the crash.  Since that more recent change, the panic has been in routine
radeon_connector_unregister(), and has been shown to be due to a NULL
value in the ddc_bus member of struct drm_connector.

Fixes: a481daa88fd4 ("drm/radeon: always apply pci shutdown callbacks")
Signed-off-by: Larry Finger 
Cc: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index e18839d..27affbd 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -931,7 +931,7 @@ static void radeon_connector_unregister(struct 
drm_connector *connector)
 {
struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
 
-   if (radeon_connector->ddc_bus->has_aux) {
+   if (radeon_connector->ddc_bus && radeon_connector->ddc_bus->has_aux) {
drm_dp_aux_unregister(_connector->ddc_bus->aux);
radeon_connector->ddc_bus->has_aux = false;
}
-- 
2.10.0

Re: [PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices

[Rob Herring]

On Wed, Oct 26, 2016 at 04:30:01PM -0400, Olimpiu Dejeu wrote:
> Resubmition of arcxcnn backliught driver bindings with added register
>  documentation
> 
> Signed-off-by: Olimpiu Dejeu 
> 
> ---
>  .../bindings/leds/backlight/arcxcnn_bl.txt | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt 
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> new file mode 100644
> index 000..a7b6ff2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> @@ -0,0 +1,31 @@
> +Binding for ArcticSand arc2c0608 LED driver
> +
> +Required properties:
> +- compatible: should be "arc,arc2c0608"

What's the correct vendor prefix? arc or arcticsand used below?

> +- reg: slave address
> +
> +Optional properties:
> +- default-brightness: brightness value on boot, value from: 0-4095
> +- label: The name of the backlight device
> + See Documentation/devicetree/bindings/leds/common.txt
> +- led-sources: List of enabled channels from 0 to 5.
> + See Documentation/devicetree/bindings/leds/common.txt
> +
> +- arcticsand,led-config-0: setting for register ILED_CONFIG_0
> +- arcticsand,led-config-1: setting for register ILED_CONFIG_1
> +- arcticsand,dim-freq: PWM mode frequence setting (bits [3:0] used)
> +- arcticsand,comp-config: setting for register CONFIG_COMP
> +- arcticsand,filter-config: setting for register FILTER_CONFIG
> +- arcticsand,trim-config: setting for register IMAXTUNE

What are the default values if not present?

What determines these settings? If the board design, then okay. If a 
an enduser wants to adjust, then they shouldn't be in DT.

> +
> +Example:
> +
> +arc2c0608@30 {
> + compatible = "arc,arc2c0608";
> + reg = <0x30>;
> + default-brightness = <500>;
> + label = "lcd-backlight";
> + linux,default-trigger = "backlight";
> + led-sources = <0 1 2 5>;
> +};
> +
> -- 
> 2.7.4
> 

Re: [PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices

[Rob Herring]

On Wed, Oct 26, 2016 at 04:30:01PM -0400, Olimpiu Dejeu wrote:
> Resubmition of arcxcnn backliught driver bindings with added register
>  documentation
> 
> Signed-off-by: Olimpiu Dejeu 
> 
> ---
>  .../bindings/leds/backlight/arcxcnn_bl.txt | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt 
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> new file mode 100644
> index 000..a7b6ff2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> @@ -0,0 +1,31 @@
> +Binding for ArcticSand arc2c0608 LED driver
> +
> +Required properties:
> +- compatible: should be "arc,arc2c0608"

What's the correct vendor prefix? arc or arcticsand used below?

> +- reg: slave address
> +
> +Optional properties:
> +- default-brightness: brightness value on boot, value from: 0-4095
> +- label: The name of the backlight device
> + See Documentation/devicetree/bindings/leds/common.txt
> +- led-sources: List of enabled channels from 0 to 5.
> + See Documentation/devicetree/bindings/leds/common.txt
> +
> +- arcticsand,led-config-0: setting for register ILED_CONFIG_0
> +- arcticsand,led-config-1: setting for register ILED_CONFIG_1
> +- arcticsand,dim-freq: PWM mode frequence setting (bits [3:0] used)
> +- arcticsand,comp-config: setting for register CONFIG_COMP
> +- arcticsand,filter-config: setting for register FILTER_CONFIG
> +- arcticsand,trim-config: setting for register IMAXTUNE

What are the default values if not present?

What determines these settings? If the board design, then okay. If a 
an enduser wants to adjust, then they shouldn't be in DT.

> +
> +Example:
> +
> +arc2c0608@30 {
> + compatible = "arc,arc2c0608";
> + reg = <0x30>;
> + default-brightness = <500>;
> + label = "lcd-backlight";
> + linux,default-trigger = "backlight";
> + led-sources = <0 1 2 5>;
> +};
> +
> -- 
> 2.7.4
> 

Re: [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver

[Rob Herring]

On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../devicetree/bindings/bus/ti,da850-mstpri.txt|  20 ++
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   2 +
>  drivers/bus/da8xx-mstpri.c | 266 
> +
>  4 files changed, 297 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>  create mode 100644 drivers/bus/da8xx-mstpri.c
> 
> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt 
> b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> new file mode 100644
> index 000..225af09
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx master peripheral
> +  priority driver
> +
> +DA8XX SoCs feature a set of registers allowing to change the priority of all
> +peripherals classified as masters.
> +
> +Documentation:
> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> +
> +Required properties:
> +
> +- compatible:"ti,da850-mstpri", "syscon" - for da850 based 
> boards

Drop syscon. Doesn't look like it is needed and the example doesn't 
match.

> +- reg:   offset and length of the mstpri registers
> +
> +Example for da850-lcdk is shown below.
> +
> +mstpri {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;
> +};

Re: [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver

[Rob Herring]

On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../devicetree/bindings/bus/ti,da850-mstpri.txt|  20 ++
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   2 +
>  drivers/bus/da8xx-mstpri.c | 266 
> +
>  4 files changed, 297 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>  create mode 100644 drivers/bus/da8xx-mstpri.c
> 
> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt 
> b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> new file mode 100644
> index 000..225af09
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx master peripheral
> +  priority driver
> +
> +DA8XX SoCs feature a set of registers allowing to change the priority of all
> +peripherals classified as masters.
> +
> +Documentation:
> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> +
> +Required properties:
> +
> +- compatible:"ti,da850-mstpri", "syscon" - for da850 based 
> boards

Drop syscon. Doesn't look like it is needed and the example doesn't 
match.

> +- reg:   offset and length of the mstpri registers
> +
> +Example for da850-lcdk is shown below.
> +
> +mstpri {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;
> +};

Re: [PATCH 1/2] ARM: memory: da8xx-ddrctl: new driver

[Rob Herring]

On Wed, Oct 26, 2016 at 07:35:54PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++

Acked-by: Rob Herring 

>  drivers/memory/Kconfig |   8 +
>  drivers/memory/Makefile|   1 +
>  drivers/memory/da8xx-ddrctl.c  | 175 
> +
>  4 files changed, 204 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>  create mode 100644 drivers/memory/da8xx-ddrctl.c

Re: [PATCH 1/2] ARM: memory: da8xx-ddrctl: new driver

[Rob Herring]

On Wed, Oct 26, 2016 at 07:35:54PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++

Acked-by: Rob Herring 

>  drivers/memory/Kconfig |   8 +
>  drivers/memory/Makefile|   1 +
>  drivers/memory/da8xx-ddrctl.c  | 175 
> +
>  4 files changed, 204 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>  create mode 100644 drivers/memory/da8xx-ddrctl.c

Re: [PATCH V2 04/10] Documentation: devicetree: mfd: da9062/61 MFD binding

[Rob Herring]

On Wed, Oct 26, 2016 at 05:56:38PM +0100, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Extend existing DA9062 binding information to include the DA9061 PMIC for
> MFD core and regulators.
> 
> Add a da9062-onkey link to the existing onkey binding file.
> 
> Add a da9062-thermal link to the new temperature monitoring binding file
> found in [PATCH V2 03/10].
> 
> Delete the da9062-watchdog section and replace it with a link to the new
> DA9061/62 binding information file added by [PATCH V2 02/10].
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> This patch applies against linux-next and v4.8
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
> 
> Hi,
> 
> This patch depends on acceptance of the main code for the DA9061 MFD:
> 
> - [PATCH V2 1/10] mfd: da9061: MFD core support
> 
> and also from the following binding file changes:
> 
> - [PATCH V2 01/10] Binding for onkey
> - [PATCH V2 02/10] Binding for watchdog
> - [PATCH V2 03/10] Binding for thermal
> 
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  Documentation/devicetree/bindings/mfd/da9062.txt | 45 
> +---
>  1 file changed, 33 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt 
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 38802b5..38ba5e2 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -1,22 +1,32 @@
>  * Dialog DA9062 Power Management Integrated Circuit (PMIC)
>  
> -DA9062 consists of a large and varied group of sub-devices:
> +The DA9062 driver is compatible with the DA9062 and DA9061 devices.

Describe the device, not driver.

> +
> +Product information can be found here:
> +- http://www.dialog-semiconductor.com/products/da9062
> +- http://www.dialog-semiconductor.com/products/da9061
> +
> +DA9062 driver consists of a large and varied group of sub-devices:

DA9062/DA9061 PMIC consists of...

>  
>  Device   Supply NamesDescription
>  --   ---
>  da9062-regulator:   : LDOs & BUCKs
>  da9062-rtc  :   : Real-Time Clock
> +da9062-onkey:   : On Key
>  da9062-watchdog :   : Watchdog Timer
> +da9062-thermal  :   : Thermal
>  
>  ==
>  
>  Required properties:
>  
> -- compatible : Should be "dlg,da9062".
> +- compatible : Should be
> +"dlg,da9062" for DA9062
> +"dlg,da9061" for DA9061
>  - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
>modified to match the chip's OTP settings).
>  - interrupt-parent : Specifies the reference to the interrupt controller for
> -  the DA9062.
> +  the DA9062 or DA9061.
>  - interrupts : IRQ line information.
>  - interrupt-controller
>  
> @@ -25,8 +35,8 @@ further information on IRQ bindings.
>  
>  Sub-nodes:
>  
> -- regulators : This node defines the settings for the LDOs and BUCKs. The
> -  DA9062 regulators are bound using their names listed below:
> +- regulators : This node defines the settings for the LDOs and BUCKs.
> +  The DA9062 regulators are bound using their names listed below:
>  
>  buck1: BUCK_1
>  buck2: BUCK_2
> @@ -37,6 +47,16 @@ Sub-nodes:
>  ldo3 : LDO_3
>  ldo4 : LDO_4
>  
> +  The DA9061 regulators are bound using their names listed below:
> +
> +buck1: BUCK_1
> +buck2: BUCK_2
> +buck3: BUCK_3
> +ldo1 : LDO_1
> +ldo2 : LDO_2
> +ldo3 : LDO_3
> +ldo4 : LDO_4
> +
>The component follows the standard regulator framework and the bindings
>details of individual regulator device can be found in:
>Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -46,9 +66,14 @@ Sub-nodes:
>with the DA9062. There are currently no entries in this binding, however
>compatible = "dlg,da9062-rtc" should be added if a node is created.
>  
> -- watchdog: This node defines the settings for the watchdog driver associated
> -  with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be 
> added
> -  if a node is created.
> +
> +- onkey : See ../input/da9062-onkey.txt
> +
> +
> +- watchdog: See ../watchdog/da9062-watchdog.txt
> +
> +
> +- thermal : See ../thermal/da9062-thermal.txt
>  
>  
>  Example:
> @@ -64,10 +89,6 @@ Example:
>   compatible = "dlg,da9062-rtc";
>   };
>  
> - watchdog {
> - compatible = "dlg,da9062-watchdog";
> - };
> -
>   regulators {
>   DA9062_BUCK1: buck1 {
>   regulator-name = "BUCK1";
> -- 
> end-of-patch for PATCH V2
> 

Re: [PATCH V2 04/10] Documentation: devicetree: mfd: da9062/61 MFD binding

[Rob Herring]

On Wed, Oct 26, 2016 at 05:56:38PM +0100, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Extend existing DA9062 binding information to include the DA9061 PMIC for
> MFD core and regulators.
> 
> Add a da9062-onkey link to the existing onkey binding file.
> 
> Add a da9062-thermal link to the new temperature monitoring binding file
> found in [PATCH V2 03/10].
> 
> Delete the da9062-watchdog section and replace it with a link to the new
> DA9061/62 binding information file added by [PATCH V2 02/10].
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> This patch applies against linux-next and v4.8
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
> 
> Hi,
> 
> This patch depends on acceptance of the main code for the DA9061 MFD:
> 
> - [PATCH V2 1/10] mfd: da9061: MFD core support
> 
> and also from the following binding file changes:
> 
> - [PATCH V2 01/10] Binding for onkey
> - [PATCH V2 02/10] Binding for watchdog
> - [PATCH V2 03/10] Binding for thermal
> 
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  Documentation/devicetree/bindings/mfd/da9062.txt | 45 
> +---
>  1 file changed, 33 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt 
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 38802b5..38ba5e2 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -1,22 +1,32 @@
>  * Dialog DA9062 Power Management Integrated Circuit (PMIC)
>  
> -DA9062 consists of a large and varied group of sub-devices:
> +The DA9062 driver is compatible with the DA9062 and DA9061 devices.

Describe the device, not driver.

> +
> +Product information can be found here:
> +- http://www.dialog-semiconductor.com/products/da9062
> +- http://www.dialog-semiconductor.com/products/da9061
> +
> +DA9062 driver consists of a large and varied group of sub-devices:

DA9062/DA9061 PMIC consists of...

>  
>  Device   Supply NamesDescription
>  --   ---
>  da9062-regulator:   : LDOs & BUCKs
>  da9062-rtc  :   : Real-Time Clock
> +da9062-onkey:   : On Key
>  da9062-watchdog :   : Watchdog Timer
> +da9062-thermal  :   : Thermal
>  
>  ==
>  
>  Required properties:
>  
> -- compatible : Should be "dlg,da9062".
> +- compatible : Should be
> +"dlg,da9062" for DA9062
> +"dlg,da9061" for DA9061
>  - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
>modified to match the chip's OTP settings).
>  - interrupt-parent : Specifies the reference to the interrupt controller for
> -  the DA9062.
> +  the DA9062 or DA9061.
>  - interrupts : IRQ line information.
>  - interrupt-controller
>  
> @@ -25,8 +35,8 @@ further information on IRQ bindings.
>  
>  Sub-nodes:
>  
> -- regulators : This node defines the settings for the LDOs and BUCKs. The
> -  DA9062 regulators are bound using their names listed below:
> +- regulators : This node defines the settings for the LDOs and BUCKs.
> +  The DA9062 regulators are bound using their names listed below:
>  
>  buck1: BUCK_1
>  buck2: BUCK_2
> @@ -37,6 +47,16 @@ Sub-nodes:
>  ldo3 : LDO_3
>  ldo4 : LDO_4
>  
> +  The DA9061 regulators are bound using their names listed below:
> +
> +buck1: BUCK_1
> +buck2: BUCK_2
> +buck3: BUCK_3
> +ldo1 : LDO_1
> +ldo2 : LDO_2
> +ldo3 : LDO_3
> +ldo4 : LDO_4
> +
>The component follows the standard regulator framework and the bindings
>details of individual regulator device can be found in:
>Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -46,9 +66,14 @@ Sub-nodes:
>with the DA9062. There are currently no entries in this binding, however
>compatible = "dlg,da9062-rtc" should be added if a node is created.
>  
> -- watchdog: This node defines the settings for the watchdog driver associated
> -  with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be 
> added
> -  if a node is created.
> +
> +- onkey : See ../input/da9062-onkey.txt
> +
> +
> +- watchdog: See ../watchdog/da9062-watchdog.txt
> +
> +
> +- thermal : See ../thermal/da9062-thermal.txt
>  
>  
>  Example:
> @@ -64,10 +89,6 @@ Example:
>   compatible = "dlg,da9062-rtc";
>   };
>  
> - watchdog {
> - compatible = "dlg,da9062-watchdog";
> - };
> -
>   regulators {
>   DA9062_BUCK1: buck1 {
>   regulator-name = "BUCK1";
> -- 
> end-of-patch for PATCH V2
> 

Re: [PATCH V2 02/10] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding

[Rob Herring]

On Wed, Oct 26, 2016 at 05:56:37PM +0100, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Add binding information for DA9062 and DA9061 watchdog.
> 
> Example bindings for both devices are added.
> 
> The original binding for DA9062 (only) used to reside inside the
> Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
> The da9062-watchdog section was deleted in that file and replaced
> with a link to the new DA9061/62 binding information stored in this
> patch.
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> This patch applies against linux-next and v4.8
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
>  - Updated the patch description to be explicit about where parts of
>this binding had originally been stored
>  - A second example for DA9061 is provided to highlight the use of a
>fall-back compatible option for the DA9062 watchdog driver
> 
> Hi,
> 
> This patch depends on the acceptance of DA9061 watchdog driver:
>   [PATCH V2 08/10] watchdog: da9061: watchdog driver
> 
> This previous [PATCH V1 07/10] was acked-by: Rob Herring, however changes
> in the Linux device driver have meant an additional binding example is
> necessary to describe the use of DA9061.
> 
> The Linux device driver changes for DA9061 were rejected after
> conversations with the watchdog maintainers, specifically about
> compatibility between DA9061 and DA9062 watchdog hardware components. In
> the case of the watchdog the DA9062 device driver is compatible with the
> DA9061 and for this reason there is minimal change required to the DA9062
> watchdog device driver and so the example for the DA9061 watchdog shows
> the use of a fall-back compatible string.
>  
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  .../devicetree/bindings/watchdog/da9062-wdt.txt | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> new file mode 100644
> index 000..1f8255c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> @@ -0,0 +1,21 @@
> +* Dialog Semiconductor DA9062/61 Watchdog Timer
> +
> +Required properties:
> +- compatible: "dlg,da9062-watchdog"
> +  "dlg,da9061-watchdog"

Similar comment here. List each valid combination.

> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + watchdog {
> + compatible = "dlg,da9062-watchdog";
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
> +
> + pmic0: da9061@58 {
> + watchdog {
> + compatible = "dlg,da9061-watchdog", 
> "dlg,da9062-watchdog";
> + };
> + };
> -- 
> end-of-patch for PATCH V2
> 

Re: [PATCH V2 02/10] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding

[Rob Herring]

On Wed, Oct 26, 2016 at 05:56:37PM +0100, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Add binding information for DA9062 and DA9061 watchdog.
> 
> Example bindings for both devices are added.
> 
> The original binding for DA9062 (only) used to reside inside the
> Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
> The da9062-watchdog section was deleted in that file and replaced
> with a link to the new DA9061/62 binding information stored in this
> patch.
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> This patch applies against linux-next and v4.8
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
>  - Updated the patch description to be explicit about where parts of
>this binding had originally been stored
>  - A second example for DA9061 is provided to highlight the use of a
>fall-back compatible option for the DA9062 watchdog driver
> 
> Hi,
> 
> This patch depends on the acceptance of DA9061 watchdog driver:
>   [PATCH V2 08/10] watchdog: da9061: watchdog driver
> 
> This previous [PATCH V1 07/10] was acked-by: Rob Herring, however changes
> in the Linux device driver have meant an additional binding example is
> necessary to describe the use of DA9061.
> 
> The Linux device driver changes for DA9061 were rejected after
> conversations with the watchdog maintainers, specifically about
> compatibility between DA9061 and DA9062 watchdog hardware components. In
> the case of the watchdog the DA9062 device driver is compatible with the
> DA9061 and for this reason there is minimal change required to the DA9062
> watchdog device driver and so the example for the DA9061 watchdog shows
> the use of a fall-back compatible string.
>  
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  .../devicetree/bindings/watchdog/da9062-wdt.txt | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> new file mode 100644
> index 000..1f8255c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> @@ -0,0 +1,21 @@
> +* Dialog Semiconductor DA9062/61 Watchdog Timer
> +
> +Required properties:
> +- compatible: "dlg,da9062-watchdog"
> +  "dlg,da9061-watchdog"

Similar comment here. List each valid combination.

> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + watchdog {
> + compatible = "dlg,da9062-watchdog";
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
> +
> + pmic0: da9061@58 {
> + watchdog {
> + compatible = "dlg,da9061-watchdog", 
> "dlg,da9062-watchdog";
> + };
> + };
> -- 
> end-of-patch for PATCH V2
> 

Re: [PATCH V2 01/10] Documentation: devicetree: input: additions for da9061 onkey driver

[Rob Herring]

On Wed, Oct 26, 2016 at 05:56:37PM +0100, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Add binding information for DA9061 onkey.
> 
> This patch updates the compatible string "dlg,da9061-onkey" to support
> DA9061, removes the reference to KEY_SLEEP (which the driver no longer
> supports) and fixes a typo in the example for DA9063.
> 
> It also adds two new examples, one for DA9062 and one for DA9061. The
> DA9061 examples uses a fall-back compatible string for the DA9062 onkey
> driver.
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> This patch applies against linux-next and v4.8
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 06/10] to [PATCH V2 01/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
>  - Typo s/ther/the/ in commit message
>  - Explanation about why KEY_SLEEP was removed (see below)
>  - Addition of DA9062 example
>  - Addition of a DA9061 example to follow the driver fall-back compatible
>convention being applied for this device driver
> 
> Hi,
> 
> This patch depends on the acceptance of the main code for the onkey:
>   [PATCH V2 07/10] Input: da9061: onkey driver.

Just FYI, not really. While common practice is we take the whole series 
together bindings could come first without a driver.

> The device driver no longer supports KEY_SLEEP. It only supports
> KEY_POWER. This change was sent a while ago for the DA9063 ONKEY driver,
> but the docs were not updated.
> 
> Supporting KEY_SLEEP was not the general convention and the typical
> solution should have been for KEY_POWER to support both cases of suspend
> and S/W power off.

This info will be lost when applied. You should add it to the commit 
message.

> 
> There is also new binding examples for DA9062 and DA9061. Importantly,
> the Linux device driver changes for DA9061 were rejected because the
> DA9062 device driver can be reused. For this reason, the DA9061 example
> uses a fall-back compatible string.
> 
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  .../devicetree/bindings/input/da9062-onkey.txt | 39 
> +++---
>  1 file changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt 
> b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> index ab0e048..e5a0469 100644
> --- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
> +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> @@ -1,32 +1,47 @@
> -* Dialog DA9062/63 OnKey Module
> +* Dialog DA9061/62/63 OnKey Module
>  
> -This module is part of the DA9062/DA9063. For more details about entire
> -chips see Documentation/devicetree/bindings/mfd/da9062.txt and
> -Documentation/devicetree/bindings/mfd/da9063.txt
> +This module is part of the DA9061/DA9062/DA9063. For more details about 
> entire
> +DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
> +For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
>  
> -This module provides KEY_POWER, KEY_SLEEP and events.
> +This module provides the KEY_POWER event.
>  
>  Required properties:
>  
>  - compatible: should be one of:
> + dlg,da9061-onkey

This needs to list the fallback too. It's below, but each line should be 
valid combinations of compatible strings.

>   dlg,da9062-onkey
>   dlg,da9063-onkey
>  
>  Optional properties:
>  
> -  - dlg,disable-key-power : Disable power-down using a long key-press. If 
> this
> +- dlg,disable-key-power : Disable power-down using a long key-press. If this
>  entry exists the OnKey driver will remove support for the KEY_POWER key
> -press. If this entry does not exist then by default the key-press
> -triggered power down is enabled and the OnKey will support both KEY_POWER
> -and KEY_SLEEP.
> +press when triggered using a long press of the OnKey.
>  
> -Example:
> -
> - pmic0: da9062@58 {
> +Example: DA9063
>  
> + pmic0: da9063@58 {
>   onkey {
>   compatible = "dlg,da9063-onkey";
>   dlg,disable-key-power;
>   };
> + };
> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + onkey {
> + compatible = "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
>  
> + pmic0: da9061@58 {
> + onkey {
> + compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
>   };
> -- 
> end-of-patch for PATCH V2
> 

Re: [PATCH V2 01/10] Documentation: devicetree: input: additions for da9061 onkey driver

[Rob Herring]

On Wed, Oct 26, 2016 at 05:56:37PM +0100, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Add binding information for DA9061 onkey.
> 
> This patch updates the compatible string "dlg,da9061-onkey" to support
> DA9061, removes the reference to KEY_SLEEP (which the driver no longer
> supports) and fixes a typo in the example for DA9063.
> 
> It also adds two new examples, one for DA9062 and one for DA9061. The
> DA9061 examples uses a fall-back compatible string for the DA9062 onkey
> driver.
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> This patch applies against linux-next and v4.8
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 06/10] to [PATCH V2 01/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
>  - Typo s/ther/the/ in commit message
>  - Explanation about why KEY_SLEEP was removed (see below)
>  - Addition of DA9062 example
>  - Addition of a DA9061 example to follow the driver fall-back compatible
>convention being applied for this device driver
> 
> Hi,
> 
> This patch depends on the acceptance of the main code for the onkey:
>   [PATCH V2 07/10] Input: da9061: onkey driver.

Just FYI, not really. While common practice is we take the whole series 
together bindings could come first without a driver.

> The device driver no longer supports KEY_SLEEP. It only supports
> KEY_POWER. This change was sent a while ago for the DA9063 ONKEY driver,
> but the docs were not updated.
> 
> Supporting KEY_SLEEP was not the general convention and the typical
> solution should have been for KEY_POWER to support both cases of suspend
> and S/W power off.

This info will be lost when applied. You should add it to the commit 
message.

> 
> There is also new binding examples for DA9062 and DA9061. Importantly,
> the Linux device driver changes for DA9061 were rejected because the
> DA9062 device driver can be reused. For this reason, the DA9061 example
> uses a fall-back compatible string.
> 
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  .../devicetree/bindings/input/da9062-onkey.txt | 39 
> +++---
>  1 file changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt 
> b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> index ab0e048..e5a0469 100644
> --- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
> +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> @@ -1,32 +1,47 @@
> -* Dialog DA9062/63 OnKey Module
> +* Dialog DA9061/62/63 OnKey Module
>  
> -This module is part of the DA9062/DA9063. For more details about entire
> -chips see Documentation/devicetree/bindings/mfd/da9062.txt and
> -Documentation/devicetree/bindings/mfd/da9063.txt
> +This module is part of the DA9061/DA9062/DA9063. For more details about 
> entire
> +DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
> +For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
>  
> -This module provides KEY_POWER, KEY_SLEEP and events.
> +This module provides the KEY_POWER event.
>  
>  Required properties:
>  
>  - compatible: should be one of:
> + dlg,da9061-onkey

This needs to list the fallback too. It's below, but each line should be 
valid combinations of compatible strings.

>   dlg,da9062-onkey
>   dlg,da9063-onkey
>  
>  Optional properties:
>  
> -  - dlg,disable-key-power : Disable power-down using a long key-press. If 
> this
> +- dlg,disable-key-power : Disable power-down using a long key-press. If this
>  entry exists the OnKey driver will remove support for the KEY_POWER key
> -press. If this entry does not exist then by default the key-press
> -triggered power down is enabled and the OnKey will support both KEY_POWER
> -and KEY_SLEEP.
> +press when triggered using a long press of the OnKey.
>  
> -Example:
> -
> - pmic0: da9062@58 {
> +Example: DA9063
>  
> + pmic0: da9063@58 {
>   onkey {
>   compatible = "dlg,da9063-onkey";
>   dlg,disable-key-power;
>   };
> + };
> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + onkey {
> + compatible = "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
>  
> + pmic0: da9061@58 {
> + onkey {
> + compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
>   };
> -- 
> end-of-patch for PATCH V2
> 

Re: [PATCH net] r8152: Fix broken RX checksums.

[David Miller]

From: Mark Lord 
Date: Sun, 30 Oct 2016 22:07:25 -0400

> On 16-10-30 08:57 PM, David Miller wrote:
>> From: Mark Lord 
>> Date: Sun, 30 Oct 2016 19:28:27 -0400
>> 
>>> The r8152 driver has been broken since (approx) 3.16.xx
>>> when support was added for hardware RX checksums
>>> on newer chip versions.  Symptoms include random
>>> segfaults and silent data corruption over NFS.
>>>
>>> The hardware checksum logig does not work on the VER_02
>>> dongles I have here when used with a slow embedded system CPU.
>>> Google reveals others reporting similar issues on Raspberry Pi.
>>>
>>> So, disable hardware RX checksum support for VER_02, and fix
>>> an obvious coding error for IPV6 checksums in the same function.
>>>
>>> Because this bug results in silent data corruption,
>>> it is a good candidate for back-porting to -stable >= 3.16.xx.
>>>
>>> Signed-off-by: Mark Lord 
>> 
>> Applied and queued up for -stable, thanks.
> 
> Thanks.  Now that this is taken care of, I do wonder if perhaps
> RX checksums ought to be enabled at all for ANY versions of this chip?

You should really start a dialogue with the developer who has been
making the most, if not all, of the major changes to this driver over
the past few years, Hayes Wang.

Re: [PATCH net] r8152: Fix broken RX checksums.

[David Miller]

From: Mark Lord 
Date: Sun, 30 Oct 2016 22:07:25 -0400

> On 16-10-30 08:57 PM, David Miller wrote:
>> From: Mark Lord 
>> Date: Sun, 30 Oct 2016 19:28:27 -0400
>> 
>>> The r8152 driver has been broken since (approx) 3.16.xx
>>> when support was added for hardware RX checksums
>>> on newer chip versions.  Symptoms include random
>>> segfaults and silent data corruption over NFS.
>>>
>>> The hardware checksum logig does not work on the VER_02
>>> dongles I have here when used with a slow embedded system CPU.
>>> Google reveals others reporting similar issues on Raspberry Pi.
>>>
>>> So, disable hardware RX checksum support for VER_02, and fix
>>> an obvious coding error for IPV6 checksums in the same function.
>>>
>>> Because this bug results in silent data corruption,
>>> it is a good candidate for back-porting to -stable >= 3.16.xx.
>>>
>>> Signed-off-by: Mark Lord 
>> 
>> Applied and queued up for -stable, thanks.
> 
> Thanks.  Now that this is taken care of, I do wonder if perhaps
> RX checksums ought to be enabled at all for ANY versions of this chip?

You should really start a dialogue with the developer who has been
making the most, if not all, of the major changes to this driver over
the past few years, Hayes Wang.

Re: [PATCH v10 10/19] vfio iommu: Add blocking notifier to notify DMA_UNMAP

[Jike Song]

On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Vendor driver should register notifer using these APIs.
> Vendor driver should use VFIO_IOMMU_NOTIFY_DMA_UNMAP action to invalidate
> mappings.
> 
> Signed-off-by: Kirti Wankhede 
> Signed-off-by: Neo Jia 
> Change-Id: I5910d0024d6be87f3e8d3e0ca0eaeaaa0b17f271
> ---
>  drivers/vfio/vfio.c | 73 +
>  drivers/vfio/vfio_iommu_type1.c | 89 
> -
>  include/linux/vfio.h| 11 +
>  3 files changed, 163 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 28b50ca14c52..ff05ac6b1e90 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1891,6 +1891,79 @@ err_unpin_pages:
>  }
>  EXPORT_SYMBOL(vfio_unpin_pages);
>  
> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> +{

Hi Kirti,

Given that below 4 methods are members of vfio_iommu_driver_ops:

pin_pages
unpin_pages
register_notifier
unregister_notifier

the names of exposed VFIO APIs could possibly be clearer:

vfio_iommu_pin_pages
vfio_iommu_unpin_pages
vfio_iommu_register_notifier
vfio_iommu_unreigster_nodier

--
Thanks,
Jike

> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_register_nb;
> +
> + container = group->container;
> + down_read(>group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->register_notifier))
> + ret = driver->ops->register_notifier(container->iommu_data, nb);
> + else
> + ret = -EINVAL;
> +
> + up_read(>group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_register_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_register_notifier);
> +
> +int vfio_unregister_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_unregister_nb;
> +
> + container = group->container;
> + down_read(>group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->unregister_notifier))
> + ret = driver->ops->unregister_notifier(container->iommu_data,
> +nb);
> + else
> + ret = -EINVAL;
> +
> + up_read(>group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_unregister_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_unregister_notifier);
> +
>  /**
>   * Module/class support
>   */
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 5add11a147e1..a4bd331ac0fd 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DRIVER_VERSION  "0.2"
>  #define DRIVER_AUTHOR   "Alex Williamson "
> @@ -59,6 +60,7 @@ struct vfio_iommu {
>   struct vfio_domain  *external_domain; /* domain for external user */
>   struct mutexlock;
>   struct rb_root  dma_list;
> + struct blocking_notifier_head notifier;
>   boolv2;
>   boolnesting;
>  };
> @@ -549,7 +551,8 @@ static long vfio_iommu_type1_pin_pages(void *iommu_data,
>  
>   mutex_lock(>lock);
>  
> - if (!iommu->external_domain) {
> + /* Fail if notifier list is empty */
> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
>   ret = -EINVAL;
>   goto pin_done;
>   }
> @@ -768,6 +771,50 @@ static unsigned long vfio_pgsize_bitmap(struct 
> vfio_iommu *iommu)
>   return bitmap;
>  }
>  
> +/*
> + * This function finds pfn in domain->external_addr_space->pfn_list for given
> + * iova range. If pfn exist, notify pfn to registered notifier list. On
> + * receiving notifier callback, vendor driver should invalidate the mapping 
> and

Re: [PATCH v10 10/19] vfio iommu: Add blocking notifier to notify DMA_UNMAP

[Jike Song]

On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Vendor driver should register notifer using these APIs.
> Vendor driver should use VFIO_IOMMU_NOTIFY_DMA_UNMAP action to invalidate
> mappings.
> 
> Signed-off-by: Kirti Wankhede 
> Signed-off-by: Neo Jia 
> Change-Id: I5910d0024d6be87f3e8d3e0ca0eaeaaa0b17f271
> ---
>  drivers/vfio/vfio.c | 73 +
>  drivers/vfio/vfio_iommu_type1.c | 89 
> -
>  include/linux/vfio.h| 11 +
>  3 files changed, 163 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 28b50ca14c52..ff05ac6b1e90 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1891,6 +1891,79 @@ err_unpin_pages:
>  }
>  EXPORT_SYMBOL(vfio_unpin_pages);
>  
> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> +{

Hi Kirti,

Given that below 4 methods are members of vfio_iommu_driver_ops:

pin_pages
unpin_pages
register_notifier
unregister_notifier

the names of exposed VFIO APIs could possibly be clearer:

vfio_iommu_pin_pages
vfio_iommu_unpin_pages
vfio_iommu_register_notifier
vfio_iommu_unreigster_nodier

--
Thanks,
Jike

> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_register_nb;
> +
> + container = group->container;
> + down_read(>group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->register_notifier))
> + ret = driver->ops->register_notifier(container->iommu_data, nb);
> + else
> + ret = -EINVAL;
> +
> + up_read(>group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_register_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_register_notifier);
> +
> +int vfio_unregister_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_unregister_nb;
> +
> + container = group->container;
> + down_read(>group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->unregister_notifier))
> + ret = driver->ops->unregister_notifier(container->iommu_data,
> +nb);
> + else
> + ret = -EINVAL;
> +
> + up_read(>group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_unregister_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_unregister_notifier);
> +
>  /**
>   * Module/class support
>   */
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 5add11a147e1..a4bd331ac0fd 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DRIVER_VERSION  "0.2"
>  #define DRIVER_AUTHOR   "Alex Williamson "
> @@ -59,6 +60,7 @@ struct vfio_iommu {
>   struct vfio_domain  *external_domain; /* domain for external user */
>   struct mutexlock;
>   struct rb_root  dma_list;
> + struct blocking_notifier_head notifier;
>   boolv2;
>   boolnesting;
>  };
> @@ -549,7 +551,8 @@ static long vfio_iommu_type1_pin_pages(void *iommu_data,
>  
>   mutex_lock(>lock);
>  
> - if (!iommu->external_domain) {
> + /* Fail if notifier list is empty */
> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
>   ret = -EINVAL;
>   goto pin_done;
>   }
> @@ -768,6 +771,50 @@ static unsigned long vfio_pgsize_bitmap(struct 
> vfio_iommu *iommu)
>   return bitmap;
>  }
>  
> +/*
> + * This function finds pfn in domain->external_addr_space->pfn_list for given
> + * iova range. If pfn exist, notify pfn to registered notifier list. On
> + * receiving notifier callback, vendor driver should invalidate the mapping 
> and
> + * call vfio_unpin_pages() to unpin this pfn. With that vfio_pfn 

Re: [linus:master] BUILD REGRESSION 2a26d99b251b8625d27aed14e97fc10707a3a81f

[Philip Li]

On Sun, Oct 30, 2016 at 01:25:50PM -0700, Linus Torvalds wrote:
> On Sun, Oct 30, 2016 at 11:03 AM, kbuild test robot
>  wrote:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  master
> > 2a26d99b251b8625d27aed14e97fc10707a3a81f  Merge 
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> 
> Hmm. The build errors seem to be pretty independent of that merge,
> including internal compiler errors etc.
> 
> Did perhaps something change in the kbuild test robot?
thanks Linus, we will double check this, and provide info.

> 
> Linus
> 

vgacon.c:undefined reference to `screen_info'

[kbuild test robot]

Hi Chen,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2a26d99b251b8625d27aed14e97fc10707a3a81f
commit: f69405ce6c0fc9f4a039011007371b31f80b470d openrisc: include: asm: 
Kbuild: add default "vga.h"
date:   3 years ago
config: openrisc-alldefconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f69405ce6c0fc9f4a039011007371b31f80b470d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `vgacon_save_screen':
>> vgacon.c:(.text+0x20e0): undefined reference to `screen_info'
   vgacon.c:(.text+0x20e8): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_init':
   vgacon.c:(.text+0x284c): undefined reference to `screen_info'
   vgacon.c:(.text+0x2850): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_startup':
   vgacon.c:(.text+0x28d8): undefined reference to `screen_info'
   drivers/built-in.o:vgacon.c:(.text+0x28f0): more undefined references to 
`screen_info' follow

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


.config.gz
Description: application/gzip

vgacon.c:undefined reference to `screen_info'

[kbuild test robot]

Hi Chen,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2a26d99b251b8625d27aed14e97fc10707a3a81f
commit: f69405ce6c0fc9f4a039011007371b31f80b470d openrisc: include: asm: 
Kbuild: add default "vga.h"
date:   3 years ago
config: openrisc-alldefconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f69405ce6c0fc9f4a039011007371b31f80b470d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `vgacon_save_screen':
>> vgacon.c:(.text+0x20e0): undefined reference to `screen_info'
   vgacon.c:(.text+0x20e8): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_init':
   vgacon.c:(.text+0x284c): undefined reference to `screen_info'
   vgacon.c:(.text+0x2850): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_startup':
   vgacon.c:(.text+0x28d8): undefined reference to `screen_info'
   drivers/built-in.o:vgacon.c:(.text+0x28f0): more undefined references to 
`screen_info' follow

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


.config.gz
Description: application/gzip

Re: [linus:master] BUILD REGRESSION 2a26d99b251b8625d27aed14e97fc10707a3a81f

[Philip Li]

On Sun, Oct 30, 2016 at 01:25:50PM -0700, Linus Torvalds wrote:
> On Sun, Oct 30, 2016 at 11:03 AM, kbuild test robot
>  wrote:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  master
> > 2a26d99b251b8625d27aed14e97fc10707a3a81f  Merge 
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> 
> Hmm. The build errors seem to be pretty independent of that merge,
> including internal compiler errors etc.
> 
> Did perhaps something change in the kbuild test robot?
thanks Linus, we will double check this, and provide info.

> 
> Linus
> 

Re: [PATCH v6 6/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[Rob Herring]

On Thu, Oct 27, 2016 at 10:44:19AM +0200, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
> swapped axes")
> added another helper for parsing axis inversion and swapping
> and applying them to x and y coordinates.
> 
> Both helpers have been integrated to accommodate any orientation of the
> touch panel in relation to the LCD.
> 
> A new feature is to introduce scaling the min/max ADC values to the screen
> size.
> 
> This makes it possible to pre-calibrate the touch so that is (almost)
> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> well enough operate the touch before a user space calibration step can
> improve the precision.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  .../devicetree/bindings/input/ads7846.txt  |  9 +++-
>  drivers/input/touchscreen/ads7846.c| 60 
> ++
>  2 files changed, 57 insertions(+), 12 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v6 6/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[Rob Herring]

On Thu, Oct 27, 2016 at 10:44:19AM +0200, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
> swapped axes")
> added another helper for parsing axis inversion and swapping
> and applying them to x and y coordinates.
> 
> Both helpers have been integrated to accommodate any orientation of the
> touch panel in relation to the LCD.
> 
> A new feature is to introduce scaling the min/max ADC values to the screen
> size.
> 
> This makes it possible to pre-calibrate the touch so that is (almost)
> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> well enough operate the touch before a user space calibration step can
> improve the precision.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  .../devicetree/bindings/input/ads7846.txt  |  9 +++-
>  drivers/input/touchscreen/ads7846.c| 60 
> ++
>  2 files changed, 57 insertions(+), 12 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v4 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Rob Herring]

On Tue, Oct 18, 2016 at 12:27 PM, H. Nikolaus Schaller
 wrote:
> Hi Rob,
>
>> Am 18.10.2016 um 18:22 schrieb Rob Herring :
>>
>> On Mon, Oct 17, 2016 at 8:57 AM, H. Nikolaus Schaller  
>> wrote:
>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>> parse the DT.
>>>
>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
>>> swapped axes")
>>> added another helper for parsing axis inversion and swapping
>>> and applying them to x and y coordinates.
>>>
>>> Both helpers have been integrated to accommodate any orientation of the
>>> touch panel in relation to the LCD.
>>
>> Please add the explanation of why this is a compatible change here.
>
> Can you please describe in more detail what you are missing here?

You stop handling ti,fuzzx for example. So the default driver value
will be used and this is okay because...

Seems like you would have a regression in behavior if the fuzz values
specified in an existing DT are ignored.

> The patch simply makes use of the generic helper function introduced by the
> two patches cited above and is therefore automatically compatible if none of
> the new properties is defined.
>
> The tsc2007 didn't have these features before. So what should we say
> about compatibility?

It certainly had the fuzz features before.


>>> -- ti,max-rt: maximum pressure.
>>> -- ti,fuzzx: specifies the absolute input fuzz x value.
>>> -  If set, it will permit noise in the data up to +- the value given to the 
>>> fuzz
>>> -  parameter, that is used to filter noise from the event stream.
>>> -- ti,fuzzy: specifies the absolute input fuzz y value.
>>> -- ti,fuzzz: specifies the absolute input fuzz z value.
>>> +- ti,max-rt: maximum pressure resistance above which samples are ignored
>>> +  (default: 4095).
>>> +- ti,report-resistance: report resistance (no pressure = max_rt) instead
>>> +  of pressure (no pressure = 0).
>>> +- ti,min-x: minimum value reported by X axis ADC (default 0).
>>> +- ti,max-x: maximum value reported by X axis ADC (default 4095).
>>> +- ti,min-y: minimum value reported by Y axis ADC (default 0).
>>> +- ti,max-y: maximum value reported by Y axis ADC (default 4095).
>>
>> I thought these were going to be common? I think they should be.
>
> Yes, we had discussed that before.
>
> In a second thought, I found that they are not even existing for the different
> touch chip drivers that are around. And some chip might not need them (because
> e.g. min/max are constants or defined my means outside the DT or the chip 
> itself
> can store them in NV memory).
>
> And, since they define ADC raw-values, they are very closely related to the
> individual chip, so that I am not sure if it is really necessary to make
> them common. At least if they are properly documented in the bindings for
> the specific chip they can have different names without disturbing each
> other.

They wouldn't disturb each other, but then there is no chance to have
common parsing either.

> So I think it is perfectly reasonable to define common bindings towards
> the input event layer (e.g. size, fuzz, swapping, inversion) and support
> them by common code which bakes raw coordinates into input events. The latest
> helper functions already do most of that fully automatic.

I could argue that size in pixels has no business being in DT. That's
a property of the panel the touchscreen is glued to. I guess in some
cases, the controller is internally scaling the ADC values.

> Next, I had simply copied them from the ads7846 driver where they
> exist for a long time. So this is sort of "common", at least for two different
> chips now. See also patch 6/8 of this series which adds the common properties
> to the ads7846 as well.
>
> For more reference about the existing bindings:
>
> Documentation/devicetree/bindings/input/ads7846.txt
>
> (btw I think someone should move them to bindings/input/touchscreen).

Patches welcome.

> It appears as if there is some overlap of the new generic properties (for x/y
> swapping) with the old ads7846 properties, but that is something you had
> already proposed a while ago to make me the driver recognize both properties 
> to
> stay compatible with older DT files.
>
> So if we now rename the min/max-x/y properties for the tsc2007 we have to 
> rename
> them for the ads7846 (and maybe others) as well, which might break out-of-tree
> ads7846 devices or leads to more complex code for handling of property 
> aliases.

We don't have to rename them for ads7846. That's already baked. But
there's a trend here. You're defining the same property. Use a common
name, so when the 3rd binding comes along needing the same thing, we
already have a common binding. If we're catching this on only the 2nd
binding, we're doing pretty good.

Rob

Re: [PATCH v4 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Rob Herring]

On Tue, Oct 18, 2016 at 12:27 PM, H. Nikolaus Schaller
 wrote:
> Hi Rob,
>
>> Am 18.10.2016 um 18:22 schrieb Rob Herring :
>>
>> On Mon, Oct 17, 2016 at 8:57 AM, H. Nikolaus Schaller  
>> wrote:
>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>> parse the DT.
>>>
>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
>>> swapped axes")
>>> added another helper for parsing axis inversion and swapping
>>> and applying them to x and y coordinates.
>>>
>>> Both helpers have been integrated to accommodate any orientation of the
>>> touch panel in relation to the LCD.
>>
>> Please add the explanation of why this is a compatible change here.
>
> Can you please describe in more detail what you are missing here?

You stop handling ti,fuzzx for example. So the default driver value
will be used and this is okay because...

Seems like you would have a regression in behavior if the fuzz values
specified in an existing DT are ignored.

> The patch simply makes use of the generic helper function introduced by the
> two patches cited above and is therefore automatically compatible if none of
> the new properties is defined.
>
> The tsc2007 didn't have these features before. So what should we say
> about compatibility?

It certainly had the fuzz features before.


>>> -- ti,max-rt: maximum pressure.
>>> -- ti,fuzzx: specifies the absolute input fuzz x value.
>>> -  If set, it will permit noise in the data up to +- the value given to the 
>>> fuzz
>>> -  parameter, that is used to filter noise from the event stream.
>>> -- ti,fuzzy: specifies the absolute input fuzz y value.
>>> -- ti,fuzzz: specifies the absolute input fuzz z value.
>>> +- ti,max-rt: maximum pressure resistance above which samples are ignored
>>> +  (default: 4095).
>>> +- ti,report-resistance: report resistance (no pressure = max_rt) instead
>>> +  of pressure (no pressure = 0).
>>> +- ti,min-x: minimum value reported by X axis ADC (default 0).
>>> +- ti,max-x: maximum value reported by X axis ADC (default 4095).
>>> +- ti,min-y: minimum value reported by Y axis ADC (default 0).
>>> +- ti,max-y: maximum value reported by Y axis ADC (default 4095).
>>
>> I thought these were going to be common? I think they should be.
>
> Yes, we had discussed that before.
>
> In a second thought, I found that they are not even existing for the different
> touch chip drivers that are around. And some chip might not need them (because
> e.g. min/max are constants or defined my means outside the DT or the chip 
> itself
> can store them in NV memory).
>
> And, since they define ADC raw-values, they are very closely related to the
> individual chip, so that I am not sure if it is really necessary to make
> them common. At least if they are properly documented in the bindings for
> the specific chip they can have different names without disturbing each
> other.

They wouldn't disturb each other, but then there is no chance to have
common parsing either.

> So I think it is perfectly reasonable to define common bindings towards
> the input event layer (e.g. size, fuzz, swapping, inversion) and support
> them by common code which bakes raw coordinates into input events. The latest
> helper functions already do most of that fully automatic.

I could argue that size in pixels has no business being in DT. That's
a property of the panel the touchscreen is glued to. I guess in some
cases, the controller is internally scaling the ADC values.

> Next, I had simply copied them from the ads7846 driver where they
> exist for a long time. So this is sort of "common", at least for two different
> chips now. See also patch 6/8 of this series which adds the common properties
> to the ads7846 as well.
>
> For more reference about the existing bindings:
>
> Documentation/devicetree/bindings/input/ads7846.txt
>
> (btw I think someone should move them to bindings/input/touchscreen).

Patches welcome.

> It appears as if there is some overlap of the new generic properties (for x/y
> swapping) with the old ads7846 properties, but that is something you had
> already proposed a while ago to make me the driver recognize both properties 
> to
> stay compatible with older DT files.
>
> So if we now rename the min/max-x/y properties for the tsc2007 we have to 
> rename
> them for the ads7846 (and maybe others) as well, which might break out-of-tree
> ads7846 devices or leads to more complex code for handling of property 
> aliases.

We don't have to rename them for ads7846. That's already baked. But
there's a trend here. You're defining the same property. Use a common
name, so when the 3rd binding comes along needing the same thing, we
already have a common binding. If we're catching this on only the 2nd
binding, we're doing pretty good.

Rob

Re: [PATCH v7, 0/8] Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

On Fri, 2016-10-28 at 12:37 +0200, Matthias Brugger wrote:
> Hi Chunfeng,
> 
> On 10/19/2016 04:28 AM, Chunfeng Yun wrote:
> > These patches introduce the MediaTek USB3 dual-role controller
> > driver.
> >
> > The driver can be configured as Dual-Role Device (DRD),
> > Peripheral Only and Host Only (xHCI) modes. It works well
> > with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
> > tested on MT8173 platform which only contains USB2.0 device IP,
> > and on MT6290 platform which contains USB3.0 device IP.
[...]
> >
> > Change in v2:
> > 1. modify binding docs according to suggestions
> > 2. modify some comments and remove some dummy blank lines
> > 3. fix memory leakage
> >
> >
> > Chunfeng Yun (8):
> >   dt-bindings: mt8173-xhci: support host side of dual-role mode
> >   dt-bindings: mt8173-mtu3: add devicetree bindings
> >   usb: xhci-mtk: make IPPC register optional
> >   usb: Add MediaTek USB3 DRD driver
> >   usb: mtu3: Super-Speed Peripheral mode support
> >   usb: mtu3: host only mode support
> >   usb: mtu3: dual-role mode support
> >   arm64: dts: mediatek: add USB3 DRD driver
> >
> 
> I tried the driver with my mt8173-evb, but wasn't able to get USB 
> working (no usb stick detected when adding to the usb port).
> 
Can you test it again by USB3.0 type-A port? If it works, then
regulators of vusb33 and vbus are got after PROBE_DEFER of
mt6397-regulator driver;

For OTG port, need cherry pick a patch:

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

which is abandoned because GPIO driver owner wants to fix all pins with
the same problem.

Then device will be recognized well when connected to PC with OTG cable.

But it is a trouble for OTG host mode, due to vbus 5.5V of OTG port is
originally provided by charger driver which is not upstreamed on EVB
board, we need rework the board to control vbus by gpio.
There is a simple way, you can plug in a self-powered hub to test OTG
host mode.


> # dmesg |grep mtu
> [0.428420] mtu3 11271000.usb: failed to get vusb33
> [0.510570] mtu3 11271000.usb: failed to get vbus
> [0.592103] mtu3 11271000.usb: failed to get vbus
> 
> 
> Relevant config options:
> CONFIG_USB_MTU3=y
> CONFIG_USB_MTU3_HOST=y
> CONFIG_USB_MTU3_DEBUG=y
> CONFIG_PHY_MT65XX_USB3=y
> 
> 
> Looks like an error in the device tree. I can see that the mt6397 
> regulater get's initialized *after* the mtu3 driver:
> [0.505166] mt6397-regulator mt6397-regulator: Chip ID = 0x4097
> 
> Not sure if this is related.
> Any idea whats going wrong here?
> 
as above.

Sorry for inconvenience

> Cheers,
> Matthias

Re: [PATCH v7, 0/8] Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

On Fri, 2016-10-28 at 12:37 +0200, Matthias Brugger wrote:
> Hi Chunfeng,
> 
> On 10/19/2016 04:28 AM, Chunfeng Yun wrote:
> > These patches introduce the MediaTek USB3 dual-role controller
> > driver.
> >
> > The driver can be configured as Dual-Role Device (DRD),
> > Peripheral Only and Host Only (xHCI) modes. It works well
> > with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
> > tested on MT8173 platform which only contains USB2.0 device IP,
> > and on MT6290 platform which contains USB3.0 device IP.
[...]
> >
> > Change in v2:
> > 1. modify binding docs according to suggestions
> > 2. modify some comments and remove some dummy blank lines
> > 3. fix memory leakage
> >
> >
> > Chunfeng Yun (8):
> >   dt-bindings: mt8173-xhci: support host side of dual-role mode
> >   dt-bindings: mt8173-mtu3: add devicetree bindings
> >   usb: xhci-mtk: make IPPC register optional
> >   usb: Add MediaTek USB3 DRD driver
> >   usb: mtu3: Super-Speed Peripheral mode support
> >   usb: mtu3: host only mode support
> >   usb: mtu3: dual-role mode support
> >   arm64: dts: mediatek: add USB3 DRD driver
> >
> 
> I tried the driver with my mt8173-evb, but wasn't able to get USB 
> working (no usb stick detected when adding to the usb port).
> 
Can you test it again by USB3.0 type-A port? If it works, then
regulators of vusb33 and vbus are got after PROBE_DEFER of
mt6397-regulator driver;

For OTG port, need cherry pick a patch:

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

which is abandoned because GPIO driver owner wants to fix all pins with
the same problem.

Then device will be recognized well when connected to PC with OTG cable.

But it is a trouble for OTG host mode, due to vbus 5.5V of OTG port is
originally provided by charger driver which is not upstreamed on EVB
board, we need rework the board to control vbus by gpio.
There is a simple way, you can plug in a self-powered hub to test OTG
host mode.


> # dmesg |grep mtu
> [0.428420] mtu3 11271000.usb: failed to get vusb33
> [0.510570] mtu3 11271000.usb: failed to get vbus
> [0.592103] mtu3 11271000.usb: failed to get vbus
> 
> 
> Relevant config options:
> CONFIG_USB_MTU3=y
> CONFIG_USB_MTU3_HOST=y
> CONFIG_USB_MTU3_DEBUG=y
> CONFIG_PHY_MT65XX_USB3=y
> 
> 
> Looks like an error in the device tree. I can see that the mt6397 
> regulater get's initialized *after* the mtu3 driver:
> [0.505166] mt6397-regulator mt6397-regulator: Chip ID = 0x4097
> 
> Not sure if this is related.
> Any idea whats going wrong here?
> 
as above.

Sorry for inconvenience

> Cheers,
> Matthias

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Benjamin Herrenschmidt]

On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
> 
> Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to
> commit 05fd007e4629
> Repo: 2016-10-20 https://www.mail-archive.com/linux-kernel@vger.kerne
> l.org/msg1253391.html
> Stat: 2016-10-22 https://www.mail-archive.com/linux-kernel@vger.kerne
> l.org/msg1255516.html https://www.linux-mips.org/archives/linux-mips/
> 2016-10/msg00176.html https://lkml.org/lkml/2016/10/18/142
> Note: Larry made a hack that works for him.

This breaks framebuffer console on ppc64 I've been told as well, I
heard...

I'm at KS now, hard to get you more details, but there's something
fishy here either with the commit or with something we do on ppc with
fbdev that this commit breaks.

Cheers,
Ben.

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Benjamin Herrenschmidt]

On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
> 
> Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to
> commit 05fd007e4629
> Repo: 2016-10-20 https://www.mail-archive.com/linux-kernel@vger.kerne
> l.org/msg1253391.html
> Stat: 2016-10-22 https://www.mail-archive.com/linux-kernel@vger.kerne
> l.org/msg1255516.html https://www.linux-mips.org/archives/linux-mips/
> 2016-10/msg00176.html https://lkml.org/lkml/2016/10/18/142
> Note: Larry made a hack that works for him.

This breaks framebuffer console on ppc64 I've been told as well, I
heard...

I'm at KS now, hard to get you more details, but there's something
fishy here either with the commit or with something we do on ppc with
fbdev that this commit breaks.

Cheers,
Ben.

Re: [PATCH 3/3] NCR5380: Check for chip presence in NCR5380_init()

[Finn Thain]

On Sun, 30 Oct 2016, Ondrej Zary wrote:

> Read back MODE_REG after writing it in NCR5380_init() to check if the
> chip is really there.
> 
> This prevents hang when incorrect I/O address was specified by user.

Do you know whereabouts in the driver the hang happens? Maybe there is a 
robustness issue there.

Card type detection (and vacant slot detection) is a good idea but I'm not 
sure how we can detect this chip reliably.

-- 

> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/NCR5380.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
> index 01c0027..ce3156d 100644
> --- a/drivers/scsi/NCR5380.c
> +++ b/drivers/scsi/NCR5380.c
> @@ -495,6 +495,11 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
> flags)
>  
>   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
>   NCR5380_write(MODE_REG, MR_BASE);
> + /* check if the chip is really there */
> + if (NCR5380_read(MODE_REG) != MR_BASE) {
> + NCR5380_exit(instance);
> + return -ENODEV;
> + }
>   NCR5380_write(TARGET_COMMAND_REG, 0);
>   NCR5380_write(SELECT_ENABLE_REG, 0);
>  
> 

Re: [PATCH 3/3] NCR5380: Check for chip presence in NCR5380_init()

[Finn Thain]

On Sun, 30 Oct 2016, Ondrej Zary wrote:

> Read back MODE_REG after writing it in NCR5380_init() to check if the
> chip is really there.
> 
> This prevents hang when incorrect I/O address was specified by user.

Do you know whereabouts in the driver the hang happens? Maybe there is a 
robustness issue there.

Card type detection (and vacant slot detection) is a good idea but I'm not 
sure how we can detect this chip reliably.

-- 

> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/NCR5380.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
> index 01c0027..ce3156d 100644
> --- a/drivers/scsi/NCR5380.c
> +++ b/drivers/scsi/NCR5380.c
> @@ -495,6 +495,11 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
> flags)
>  
>   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
>   NCR5380_write(MODE_REG, MR_BASE);
> + /* check if the chip is really there */
> + if (NCR5380_read(MODE_REG) != MR_BASE) {
> + NCR5380_exit(instance);
> + return -ENODEV;
> + }
>   NCR5380_write(TARGET_COMMAND_REG, 0);
>   NCR5380_write(SELECT_ENABLE_REG, 0);
>  
> 

Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression

[Huang, Ying]

Hi, Kim,

Jaegeuk Kim  writes:

> On Tue, Sep 27, 2016 at 08:50:02AM +0800, Huang, Ying wrote:
>> Jaegeuk Kim  writes:
>> 
>> > On Mon, Sep 26, 2016 at 02:26:06PM +0800, Huang, Ying wrote:
>> >> Hi, Jaegeuk,
>> >> 
>> >> "Huang, Ying"  writes:
>> >> 
>> >> > Jaegeuk Kim  writes:
>> >> >
>> >> >> Hello,
>> >> >>
>> >> >> On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote:
>> >> >>> Hi Jaegeuk,
>> >> >>> 
>> >> >>> > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% 
>> >> >>> > > >> > regression
>> >> >>> > > >> >
>> >> >>> > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via 
>> >> >>> > > >> > mdadm.  The
>> >> >>> > > >> > steps for aim7 is,
>> >> >>> > > >> >
>> >> >>> > > >> > cat > workfile <> >> >>> > > >> > FILESIZE: 1M
>> >> >>> > > >> > POOLSIZE: 10M
>> >> >>> > > >> > 10 sync_disk_rw
>> >> >>> > > >> > EOF
>> >> >>> > > >> >
>> >> >>> > > >> > (
>> >> >>> > > >> > echo $HOSTNAME
>> >> >>> > > >> > echo sync_disk_rw
>> >> >>> > > >> >
>> >> >>> > > >> > echo 1
>> >> >>> > > >> > echo 600
>> >> >>> > > >> > echo 2
>> >> >>> > > >> > echo 600
>> >> >>> > > >> > echo 1
>> >> >>> > > >> > ) | ./multitask -t &
>> >> >>> > > >>
>> >> >>> > > >> Any update on these 2 regressions?  Is the information is 
>> >> >>> > > >> enough for you
>> >> >>> > > >> to reproduce?
>> >> >>> > > >
>> >> >>> > > > Sorry, I've had no time to dig this due to business travel now.
>> >> >>> > > > I'll check that when back to US.
>> >> >>> > > 
>> >> >>> > > Any update?
>> >> >>> > 
>> >> >>> > Sorry, how can I get multitask binary?
>> >> >>> 
>> >> >>> It's part of aim7, which can be downloaded here:
>> >> >>> 
>> >> >>> http://nchc.dl.sourceforge.net/project/aimbench/aim-suite7/Initial%20release/s7110.tar.Z
>> >> >>
>> >> >> Thank you for the codes.
>> >> >>
>> >> >> I've run this workload on the latest f2fs and compared performance 
>> >> >> having
>> >> >> without the reported patch. (1TB nvme SSD, 16 cores, 16GB DRAM)
>> >> >> Interestingly, I could find slight performance improvement rather than
>> >> >> regression. :(
>> >> >> Not sure how to reproduce this.
>> >> >
>> >> > I think the difference lies on disk used.  The ramdisk is used in the
>> >> > original test, but it appears that your memory is too small to setup the
>> >> > RAM disk for test.  So it may be impossible for you to reproduce the
>> >> > test unless you can find more memory :)
>> >> >
>> >> > But we can help you to root cause the issue.  What additional data do
>> >> > you want?  perf-profile data before and after the patch?
>> >> 
>> >> Any update to this regression?
>> >
>> > Sorry, no. But meanwhile, I've purchased more DRAMs. :)
>> > Now I'm with 128GB DRAM. I can configure 64GB as pmem.
>> > Is it worth to try the test again?
>> 
>> I think you are the decision maker for this.  You can judge whether the
>> test is reasonable.  And we can adjust our test accordingly.
>> 
>> BTW: For this test, we use brd ram disk and raid to test.
>
> Okay, let me try this again.

Any update on this?

Best Regards,
Huang, Ying

Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression

[Huang, Ying]

Hi, Kim,

Jaegeuk Kim  writes:

> On Tue, Sep 27, 2016 at 08:50:02AM +0800, Huang, Ying wrote:
>> Jaegeuk Kim  writes:
>> 
>> > On Mon, Sep 26, 2016 at 02:26:06PM +0800, Huang, Ying wrote:
>> >> Hi, Jaegeuk,
>> >> 
>> >> "Huang, Ying"  writes:
>> >> 
>> >> > Jaegeuk Kim  writes:
>> >> >
>> >> >> Hello,
>> >> >>
>> >> >> On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote:
>> >> >>> Hi Jaegeuk,
>> >> >>> 
>> >> >>> > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% 
>> >> >>> > > >> > regression
>> >> >>> > > >> >
>> >> >>> > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via 
>> >> >>> > > >> > mdadm.  The
>> >> >>> > > >> > steps for aim7 is,
>> >> >>> > > >> >
>> >> >>> > > >> > cat > workfile <> >> >>> > > >> > FILESIZE: 1M
>> >> >>> > > >> > POOLSIZE: 10M
>> >> >>> > > >> > 10 sync_disk_rw
>> >> >>> > > >> > EOF
>> >> >>> > > >> >
>> >> >>> > > >> > (
>> >> >>> > > >> > echo $HOSTNAME
>> >> >>> > > >> > echo sync_disk_rw
>> >> >>> > > >> >
>> >> >>> > > >> > echo 1
>> >> >>> > > >> > echo 600
>> >> >>> > > >> > echo 2
>> >> >>> > > >> > echo 600
>> >> >>> > > >> > echo 1
>> >> >>> > > >> > ) | ./multitask -t &
>> >> >>> > > >>
>> >> >>> > > >> Any update on these 2 regressions?  Is the information is 
>> >> >>> > > >> enough for you
>> >> >>> > > >> to reproduce?
>> >> >>> > > >
>> >> >>> > > > Sorry, I've had no time to dig this due to business travel now.
>> >> >>> > > > I'll check that when back to US.
>> >> >>> > > 
>> >> >>> > > Any update?
>> >> >>> > 
>> >> >>> > Sorry, how can I get multitask binary?
>> >> >>> 
>> >> >>> It's part of aim7, which can be downloaded here:
>> >> >>> 
>> >> >>> http://nchc.dl.sourceforge.net/project/aimbench/aim-suite7/Initial%20release/s7110.tar.Z
>> >> >>
>> >> >> Thank you for the codes.
>> >> >>
>> >> >> I've run this workload on the latest f2fs and compared performance 
>> >> >> having
>> >> >> without the reported patch. (1TB nvme SSD, 16 cores, 16GB DRAM)
>> >> >> Interestingly, I could find slight performance improvement rather than
>> >> >> regression. :(
>> >> >> Not sure how to reproduce this.
>> >> >
>> >> > I think the difference lies on disk used.  The ramdisk is used in the
>> >> > original test, but it appears that your memory is too small to setup the
>> >> > RAM disk for test.  So it may be impossible for you to reproduce the
>> >> > test unless you can find more memory :)
>> >> >
>> >> > But we can help you to root cause the issue.  What additional data do
>> >> > you want?  perf-profile data before and after the patch?
>> >> 
>> >> Any update to this regression?
>> >
>> > Sorry, no. But meanwhile, I've purchased more DRAMs. :)
>> > Now I'm with 128GB DRAM. I can configure 64GB as pmem.
>> > Is it worth to try the test again?
>> 
>> I think you are the decision maker for this.  You can judge whether the
>> test is reasonable.  And we can adjust our test accordingly.
>> 
>> BTW: For this test, we use brd ram disk and raid to test.
>
> Okay, let me try this again.

Any update on this?

Best Regards,
Huang, Ying

Re: [PATCH 3/3] NCR5380: Check for chip presence in NCR5380_init()

[Finn Thain]

On Sun, 30 Oct 2016, Ondrej Zary wrote:

> Read back MODE_REG after writing it in NCR5380_init() to check if the
> chip is really there.
> 
> This prevents hang when incorrect I/O address was specified by user.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/NCR5380.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
> index 01c0027..ce3156d 100644
> --- a/drivers/scsi/NCR5380.c
> +++ b/drivers/scsi/NCR5380.c
> @@ -495,6 +495,11 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
> flags)
>  
>   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
>   NCR5380_write(MODE_REG, MR_BASE);
> + /* check if the chip is really there */
> + if (NCR5380_read(MODE_REG) != MR_BASE) {
> + NCR5380_exit(instance);
> + return -ENODEV;
> + }

This doesn't belong in the core driver. Only the 5380 ISA drivers have 
configurable base addresses.

Also, MR_BASE == 0, so that test is likely to be ineffectual anyway. This 
patch doesn't really add any value AFAICT.

-- 

>   NCR5380_write(TARGET_COMMAND_REG, 0);
>   NCR5380_write(SELECT_ENABLE_REG, 0);
>  
> 

Re: [PATCH 3/3] NCR5380: Check for chip presence in NCR5380_init()

[Finn Thain]

On Sun, 30 Oct 2016, Ondrej Zary wrote:

> Read back MODE_REG after writing it in NCR5380_init() to check if the
> chip is really there.
> 
> This prevents hang when incorrect I/O address was specified by user.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/NCR5380.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
> index 01c0027..ce3156d 100644
> --- a/drivers/scsi/NCR5380.c
> +++ b/drivers/scsi/NCR5380.c
> @@ -495,6 +495,11 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
> flags)
>  
>   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
>   NCR5380_write(MODE_REG, MR_BASE);
> + /* check if the chip is really there */
> + if (NCR5380_read(MODE_REG) != MR_BASE) {
> + NCR5380_exit(instance);
> + return -ENODEV;
> + }

This doesn't belong in the core driver. Only the 5380 ISA drivers have 
configurable base addresses.

Also, MR_BASE == 0, so that test is likely to be ineffectual anyway. This 
patch doesn't really add any value AFAICT.

-- 

>   NCR5380_write(TARGET_COMMAND_REG, 0);
>   NCR5380_write(SELECT_ENABLE_REG, 0);
>  
> 

Re: [PATCH 2/3] g_NCR5380: Test the IRQ before accepting it

[Finn Thain]

On Sun, 30 Oct 2016, Ondrej Zary wrote:

> Trigger an IRQ first with a test IRQ handler to find out if it really
> works. Disable the IRQ if not.
> 
> This prevents hang when incorrect IRQ was specified by user.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/g_NCR5380.c |   32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 3790ed5..261e168 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -67,6 +67,14 @@
>  MODULE_ALIAS("g_NCR5380_mmio");
>  MODULE_LICENSE("GPL");
>  
> +static bool irq_working;
> +
> +static irqreturn_t test_irq(int irq, void *dev_id)
> +{
> + irq_working = true;
> + return IRQ_HANDLED;
> +}
> +
>  /*
>   * Configure I/O address of 53C400A or DTC436 by writing magic numbers
>   * to ports 0x779 and 0x379.
> @@ -275,10 +283,30 @@ static int generic_NCR5380_init_one(struct 
> scsi_host_template *tpnt,
>   /* set IRQ for HP C2502 */
>   if (board == BOARD_HP_C2502)
>   magic_configure(port_idx, instance->irq, magic);
> - if (request_irq(instance->irq, generic_NCR5380_intr,
> - 0, "NCR5380", instance)) {
> + /* test if the IRQ is working */
> + irq_working = false;
> + if (request_irq(instance->irq, test_irq,
> + 0, "NCR5380-irqtest", NULL)) {
>   printk(KERN_WARNING "scsi%d : IRQ%d not free, 
> interrupts disabled\n", instance->host_no, instance->irq);
>   instance->irq = NO_IRQ;
> + } else {
> + NCR5380_trigger_irq(instance);
> + NCR5380_read(RESET_PARITY_INTERRUPT_REG);
> + free_irq(instance->irq, NULL);
> + if (irq_working) {
> + if (request_irq(instance->irq,
> + generic_NCR5380_intr, 0,
> + "NCR5380", instance)) {
> + printk(KERN_WARNING "scsi%d : IRQ%d not 
> free, interrupts disabled\n",
> +instance->host_no,
> +instance->irq);
> + instance->irq = NO_IRQ;
> + }
> + } else {
> + printk(KERN_WARNING "scsi%d : IRQ%d not 
> working, interrupts disabled\n",
> +instance->host_no, instance->irq);
> + instance->irq = NO_IRQ;
> + }
>   }
>   }
>  
> 

If the user omits to specify an irq, you can just default to IRQ_AUTO. 
This might result in NO_IRQ, which gives the same result as this patch.
 
And when the user does specify an IRQ, we should trust them. So this 
compexity doesn't add any value AFAICT. Thanks but no thanks.

-- 

Re: [PATCH 2/3] g_NCR5380: Test the IRQ before accepting it

[Finn Thain]

On Sun, 30 Oct 2016, Ondrej Zary wrote:

> Trigger an IRQ first with a test IRQ handler to find out if it really
> works. Disable the IRQ if not.
> 
> This prevents hang when incorrect IRQ was specified by user.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/g_NCR5380.c |   32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 3790ed5..261e168 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -67,6 +67,14 @@
>  MODULE_ALIAS("g_NCR5380_mmio");
>  MODULE_LICENSE("GPL");
>  
> +static bool irq_working;
> +
> +static irqreturn_t test_irq(int irq, void *dev_id)
> +{
> + irq_working = true;
> + return IRQ_HANDLED;
> +}
> +
>  /*
>   * Configure I/O address of 53C400A or DTC436 by writing magic numbers
>   * to ports 0x779 and 0x379.
> @@ -275,10 +283,30 @@ static int generic_NCR5380_init_one(struct 
> scsi_host_template *tpnt,
>   /* set IRQ for HP C2502 */
>   if (board == BOARD_HP_C2502)
>   magic_configure(port_idx, instance->irq, magic);
> - if (request_irq(instance->irq, generic_NCR5380_intr,
> - 0, "NCR5380", instance)) {
> + /* test if the IRQ is working */
> + irq_working = false;
> + if (request_irq(instance->irq, test_irq,
> + 0, "NCR5380-irqtest", NULL)) {
>   printk(KERN_WARNING "scsi%d : IRQ%d not free, 
> interrupts disabled\n", instance->host_no, instance->irq);
>   instance->irq = NO_IRQ;
> + } else {
> + NCR5380_trigger_irq(instance);
> + NCR5380_read(RESET_PARITY_INTERRUPT_REG);
> + free_irq(instance->irq, NULL);
> + if (irq_working) {
> + if (request_irq(instance->irq,
> + generic_NCR5380_intr, 0,
> + "NCR5380", instance)) {
> + printk(KERN_WARNING "scsi%d : IRQ%d not 
> free, interrupts disabled\n",
> +instance->host_no,
> +instance->irq);
> + instance->irq = NO_IRQ;
> + }
> + } else {
> + printk(KERN_WARNING "scsi%d : IRQ%d not 
> working, interrupts disabled\n",
> +instance->host_no, instance->irq);
> + instance->irq = NO_IRQ;
> + }
>   }
>   }
>  
> 

If the user omits to specify an irq, you can just default to IRQ_AUTO. 
This might result in NO_IRQ, which gives the same result as this patch.
 
And when the user does specify an IRQ, we should trust them. So this 
compexity doesn't add any value AFAICT. Thanks but no thanks.

-- 

Re: [PATCH] iio: si7020: Add devicetree support and trivial bindings

[Rob Herring]

On Tue, Oct 25, 2016 at 09:20:10PM +0200, Paul Kocialkowski wrote:
> This adds devicetree support for the si7020 iio driver. Since it works
> well without requiring any additional property, its compatible string is
> added to the trivial i2c devices bindings list.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt |  1 +
>  drivers/iio/humidity/si7020.c | 11 ++-
>  2 files changed, 11 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH] iio: si7020: Add devicetree support and trivial bindings

[Rob Herring]

On Tue, Oct 25, 2016 at 09:20:10PM +0200, Paul Kocialkowski wrote:
> This adds devicetree support for the si7020 iio driver. Since it works
> well without requiring any additional property, its compatible string is
> added to the trivial i2c devices bindings list.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt |  1 +
>  drivers/iio/humidity/si7020.c | 11 ++-
>  2 files changed, 11 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH resent v3 3/3] ASoC: omap-abe-twl6040: fix typo in bindings documentation

[Rob Herring]

On Tue, Oct 25, 2016 at 07:38:11PM +0200, H. Nikolaus Schaller wrote:
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH resent v3 3/3] ASoC: omap-abe-twl6040: fix typo in bindings documentation

[Rob Herring]

On Tue, Oct 25, 2016 at 07:38:11PM +0200, H. Nikolaus Schaller wrote:
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Rob Herring