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

Hi all,

After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .callback = qcom_smd_qrtr_callback,
              ^
net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')

Caused by commit

  bdabad3e363d ("net: Add Qualcomm IPC router")

interacting with commit

  b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")

from the arm-soc tree.

I added the following merge fix patch (and it turned out I needed the
new stubs).

From: Stephen Rothwell <redacted>
Date: Tue, 10 May 2016 11:14:06 +1000
Subject: [PATCH] soc: qcom: smd: fix for Qualcomm IPC router and callback API
 change

Signed-off-by: Stephen Rothwell <redacted>
---
 include/linux/soc/qcom/smd.h | 9 +++++++++
 net/qrtr/smd.c               | 9 ++++++---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index 086e36d76be9..fbebbfc82ed3 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h

@@ -70,6 +70,15 @@ static inline void qcom_smd_driver_unregister(struct qcom_smd_driver *drv)
 	WARN_ON(1);
 }
 
+static inline void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel)
+{
+	return NULL;
+}
+
+static inline void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void *data)
+{
+}
+
 static inline int qcom_smd_send(struct qcom_smd_channel *channel,
 				const void *data, int len)
 {

diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 84ebce73aa23..0d11132b3370 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c

@@ -21,13 +21,14 @@
 struct qrtr_smd_dev {
 	struct qrtr_endpoint ep;
 	struct qcom_smd_channel *channel;
+	struct device *dev;
 };
 
 /* from smd to qrtr */
-static int qcom_smd_qrtr_callback(struct qcom_smd_device *sdev,
+static int qcom_smd_qrtr_callback(struct qcom_smd_channel *channel,
 				  const void *data, size_t len)
 {
-	struct qrtr_smd_dev *qdev = dev_get_drvdata(&sdev->dev);
+	struct qrtr_smd_dev *qdev = qcom_smd_get_drvdata(channel);
 	int rc;
 
 	if (!qdev)

@@ -35,7 +36,7 @@ static int qcom_smd_qrtr_callback(struct qcom_smd_device *sdev,
 
 	rc = qrtr_endpoint_post(&qdev->ep, data, len);
 	if (rc == -EINVAL) {
-		dev_err(&sdev->dev, "invalid ipcrouter packet\n");
+		dev_err(qdev->dev, "invalid ipcrouter packet\n");
 		/* return 0 to let smd drop the packet */
 		rc = 0;
 	}

@@ -73,12 +74,14 @@ static int qcom_smd_qrtr_probe(struct qcom_smd_device *sdev)
 		return -ENOMEM;
 
 	qdev->channel = sdev->channel;
+	qdev->dev = &sdev->dev;
 	qdev->ep.xmit = qcom_smd_qrtr_send;
 
 	rc = qrtr_endpoint_register(&qdev->ep, QRTR_EP_NID_AUTO);
 	if (rc)
 		return rc;
 
+	qcom_smd_set_drvdata(sdev->channel, qdev);
 	dev_set_drvdata(&sdev->dev, qdev);
 
 	dev_dbg(&sdev->dev, "Qualcomm SMD QRTR driver probed\n");

-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

On 9 May 2016 at 20:29, Stephen Rothwell [off-list ref] wrote:

Hi all,

After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .callback = qcom_smd_qrtr_callback,
              ^
net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')

Caused by commit

  bdabad3e363d ("net: Add Qualcomm IPC router")

interacting with commit

  b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")

from the arm-soc tree.

I added the following merge fix patch (and it turned out I needed the
new stubs).

Thanks for fixing this up.  I'll work with Bjorn to get this resolved.
I'll have something up for tomorrow's next pull.


Regards,

Andy Gross

On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:

Hi all,

After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .callback = qcom_smd_qrtr_callback,
              ^
net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')

Caused by commit

  bdabad3e363d ("net: Add Qualcomm IPC router")

interacting with commit

  b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")

from the arm-soc tree.

I added the following merge fix patch (and it turned out I needed the
new stubs).

Sorry for not spotting this issue earlier, I missed Andy's second pull
request towards arm-soc and thought the SMD changes missed this cycle.


Your patch looks good, but I'm not sure how we should approach the merge
window; Andy can't pick the patch because he doesn't have the qrtr code
and David doesn't have the SMD patches coming through Andy.

FWIW, Reviewed-by: Bjorn Andersson [off-list ref]


I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?

Suggestions are welcome.

Regards,
Bjorn

On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:

On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:

quoted

Hi all,

After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .callback = qcom_smd_qrtr_callback,
              ^
net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')

Caused by commit

  bdabad3e363d ("net: Add Qualcomm IPC router")

interacting with commit

  b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")

from the arm-soc tree.

I added the following merge fix patch (and it turned out I needed the
new stubs).

Sorry for not spotting this issue earlier, I missed Andy's second pull
request towards arm-soc and thought the SMD changes missed this cycle.


Your patch looks good, but I'm not sure how we should approach the merge
window; Andy can't pick the patch because he doesn't have the qrtr code
and David doesn't have the SMD patches coming through Andy.

FWIW, Reviewed-by: Bjorn Andersson [off-list ref]


I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?

I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
we have in arm-soc and resolve the conflict in the merge, then send
a pull request with the merge to davem.

Alternatively, in case Linus merges net-next before we get that fix
in, I could send Stephen's fix to Linus along with the pull requests.

	Arnd

On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:

On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:

[..]

quoted

I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?

I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
we have in arm-soc and resolve the conflict in the merge, then send
a pull request with the merge to davem.

Hi David,

In case you missed this thread, linux-next highlighted an upcoming merge
conflict between the net-next and one of the branches included in the
arm-soc trees.

I have prepared the merge of net-next and the conflicting tag from the
Qualcomm SOC, please include this in your pull towards Linus to avoid
the merge conflict.

Regards,
Bjorn

The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771:

  udp: Resolve NULL pointer dereference over flow-based vxlan device (2016-05-13 01:56:14 -0400)

are available in the git repository at:

  git://github.com/andersson/kernel tags/net-next-qcom-soc-4.7-2-merge

for you to fetch changes up to f79a917e69e1f5cd86e864b67f06147f1b0340f4:

  Merge tag 'qcom-soc-for-4.7-2' into net-next (2016-05-13 14:42:23 -0700)

----------------------------------------------------------------
Merge tag 'qcom-soc-for-4.7-2' into net-next

This merges the Qualcomm SOC tree with the net-next, solving the
merge conflict in the SMD API between the two.

----------------------------------------------------------------
Andy Gross (1):
      Merge tag 'qcom-soc-for-4.7' into soc-for-4.7-p2

Bjorn Andersson (9):
      soc: qcom: smem_state: Add stubs for disabled smem_state
      soc: qcom: smd: Introduce callback setter
      soc: qcom: smd: Split discovery and state change work
      soc: qcom: smd: Refactor channel open and close handling
      soc: qcom: smd: Support multiple channels per sdev
      soc: qcom: smd: Support opening additional channels
      soc: qcom: smem: Use write-combine remap for SMEM
      soc: qcom: smd: Make callback pass channel reference
      Merge tag 'qcom-soc-for-4.7-2' into net-next

Lina Iyer (1):
      drivers: qcom: spm: avoid module usage in non-modular SPM driver

Srinivas Kandagatla (2):
      MAINTAINERS: add qcom i2c and spi drivers to list
      MAINTAINERS: add qcom clocks to the maintainers list

 MAINTAINERS                         |   3 +
 drivers/soc/qcom/smd-rpm.c          |   9 +-
 drivers/soc/qcom/smd.c              | 247 +++++++++++++++++++++++++++---------
 drivers/soc/qcom/smem.c             |   3 +-
 drivers/soc/qcom/spm.c              |   8 +-
 drivers/soc/qcom/wcnss_ctrl.c       |   8 +-
 include/linux/soc/qcom/smd.h        |  33 ++++-
 include/linux/soc/qcom/smem_state.h |  35 +++++
 net/qrtr/smd.c                      |   9 +-
 9 files changed, 278 insertions(+), 77 deletions(-)

Alternatively, in case Linus merges net-next before we get that fix
in, I could send Stephen's fix to Linus along with the pull requests.

	Arnd

On 13 May 2016 at 17:19, Bjorn Andersson [off-list ref] wrote:

On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:

quoted

On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:

[..]

quoted

quoted

I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?

I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
we have in arm-soc and resolve the conflict in the merge, then send
a pull request with the merge to davem.

Hi David,

In case you missed this thread, linux-next highlighted an upcoming merge
conflict between the net-next and one of the branches included in the
arm-soc trees.

I have prepared the merge of net-next and the conflicting tag from the
Qualcomm SOC, please include this in your pull towards Linus to avoid
the merge conflict.

Regards,
Bjorn

The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771:

  udp: Resolve NULL pointer dereference over flow-based vxlan device (2016-05-13 01:56:14 -0400)

OK. The contents look good to me.

Acked-by: Andy Gross <redacted>

On Friday 13 May 2016 17:47:17 Andy Gross wrote:

On 13 May 2016 at 17:19, Bjorn Andersson [off-list ref] wrote:

quoted

On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:

quoted

On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:

[..]

quoted

quoted

I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?

I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
we have in arm-soc and resolve the conflict in the merge, then send
a pull request with the merge to davem.

Hi David,

In case you missed this thread, linux-next highlighted an upcoming merge
conflict between the net-next and one of the branches included in the
arm-soc trees.

I have prepared the merge of net-next and the conflicting tag from the
Qualcomm SOC, please include this in your pull towards Linus to avoid
the merge conflict.

Regards,
Bjorn

The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771:

  udp: Resolve NULL pointer dereference over flow-based vxlan device (2016-05-13 01:56:14 -0400)

OK. The contents look good to me.

Acked-by: Andy Gross <redacted>

Acked-by: Arnd Bergmann <arnd@arndb.de>

From: Bjorn Andersson <redacted>
Date: Fri, 13 May 2016 15:19:09 -0700

I have prepared the merge of net-next and the conflicting tag from the
Qualcomm SOC, please include this in your pull towards Linus to avoid
the merge conflict.

Pulled, thanks.

Hi David,

On Tue, 17 May 2016 14:11:54 -0400 (EDT) David Miller [off-list ref] wrote:

From: Bjorn Andersson <redacted>
Date: Fri, 13 May 2016 15:19:09 -0700

quoted

I have prepared the merge of net-next and the conflicting tag from the
Qualcomm SOC, please include this in your pull towards Linus to avoid
the merge conflict.  

Pulled, thanks.

Except in the merge resolution, the 2 new functions added to
include/linux/soc/qcom/smd.h (qcom_smd_get_drvdata and
qcom_smd_set_drvdata) were not marked "static inline" :-(

-- 
Cheers,
Stephen Rothwell

On Tue 17 May 17:43 PDT 2016, Stephen Rothwell wrote:

Hi David,

On Tue, 17 May 2016 14:11:54 -0400 (EDT) David Miller [off-list ref] wrote:

quoted

From: Bjorn Andersson <redacted>
Date: Fri, 13 May 2016 15:19:09 -0700

quoted

I have prepared the merge of net-next and the conflicting tag from the
Qualcomm SOC, please include this in your pull towards Linus to avoid
the merge conflict.  

Pulled, thanks.

Except in the merge resolution, the 2 new functions added to
include/linux/soc/qcom/smd.h (qcom_smd_get_drvdata and
qcom_smd_set_drvdata) were not marked "static inline" :-(

How silly of me to miss that, sorry about that.

I didn't spot this in my compile testing either, because this is the
only driver in the tree including that file that doesn't depend on
QCOM_SMD.

As there is no immediate problem with moving forward I suggest that I'll
fix this, through arm-soc, once the code has landed.

Regards,
Bjorn