linux-next: manual merge of the scsi-mkp tree with the origin tree

linux-next: manual merge of the scsi-mkp tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

Hi all,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  include/linux/mod_devicetable.h

between commit:

  ad428f5811bd7 ("mod_devicetable.h: Split into per subsystem headers")

from the origin tree and commit:

  e73ba3d6ed03b ("scsi: zorro: Simplify storing pointers in device id struct")

from the scsi-mkp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc include/linux/mod_devicetable.h
index a397213bedace,2673a1bd82c45..0000000000000
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
diff --git a/include/linux/device-id/zorro.h b/include/linux/device-id/zorro.h
index 5fdac81689839..26827b9b90b67 100644
--- a/include/linux/device-id/zorro.h
+++ b/include/linux/device-id/zorro.h
@@ -13,7 +13,11 @@ typedef unsigned long kernel_ulong_t;
 
 struct zorro_device_id {
 	__u32 id;			/* Device ID or ZORRO_WILDCARD */
-	kernel_ulong_t driver_data;	/* Data private to the driver */
+	union {
+		/* Data private to the driver */
+		kernel_ulong_t driver_data;
+		const void *driver_data_ptr;
+	};
 };
 
 #endif /* ifndef LINUX_DEVICE_ID_ZORRO_H */

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the scsi-mkp tree with the origin tree

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 3701 bytes --]

Hello Mark,

On Mon, Jul 13, 2026 at 04:13:24PM +0100, Mark Brown wrote:
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
> 
>   include/linux/mod_devicetable.h
> 
> between commit:
> 
>   ad428f5811bd7 ("mod_devicetable.h: Split into per subsystem headers")
> 
> from the origin tree and commit:
> 
>   e73ba3d6ed03b ("scsi: zorro: Simplify storing pointers in device id struct")
> 
> from the scsi-mkp tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc include/linux/mod_devicetable.h
> index a397213bedace,2673a1bd82c45..0000000000000
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> diff --git a/include/linux/device-id/zorro.h b/include/linux/device-id/zorro.h
> index 5fdac81689839..26827b9b90b67 100644
> --- a/include/linux/device-id/zorro.h
> +++ b/include/linux/device-id/zorro.h
> @@ -13,7 +13,11 @@ typedef unsigned long kernel_ulong_t;
>  
>  struct zorro_device_id {
>  	__u32 id;			/* Device ID or ZORRO_WILDCARD */
> -	kernel_ulong_t driver_data;	/* Data private to the driver */
> +	union {
> +		/* Data private to the driver */
> +		kernel_ulong_t driver_data;
> +		const void *driver_data_ptr;
> +	};
>  };

While this looks right, I think it's wrong in git:

$ git show next-20260715~32
commit b36e50419ebc00bef45b574c6ce3e7edbbda5eb9
Merge: 20361c12febf cf1af0ccca54
Author: Mark Brown <broonie@kernel.org>
Date:   Wed Jul 15 14:23:48 2026 +0100

    Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git

diff --cc include/linux/device-id/zorro.h
index 5fdac8168983,000000000000..26827b9b90b6
mode 100644,000000..100644
--- a/include/linux/device-id/zorro.h
+++ b/include/linux/device-id/zorro.h
@@@ -1,19 -1,0 +1,23 @@@
 +/* SPDX-License-Identifier: GPL-2.0 */
 +#ifndef LINUX_DEVICE_ID_ZORRO_H
 +#define LINUX_DEVICE_ID_ZORRO_H
 +
 +#ifdef __KERNEL__
 +#include <linux/types.h>
 +typedef unsigned long kernel_ulong_t;
 +#endif
 +
 +#define ZORRO_WILDCARD                        (0xffffffff)    /* not official */
 +
 +#define ZORRO_DEVICE_MODALIAS_FMT     "zorro:i%08X"
 +
 +struct zorro_device_id {
 +      __u32 id;                       /* Device ID or ZORRO_WILDCARD */
-       kernel_ulong_t driver_data;     /* Data private to the driver */
++      union {
++              /* Data private to the driver */
++              kernel_ulong_t driver_data;
++              const void *driver_data_ptr;
++      };
 +};
 +
 +#endif /* ifndef LINUX_DEVICE_ID_ZORRO_H */

So the fixup is applied to the merge of the scsi tree and not the
scsi-mkp tree. The latter wasn't pulled into next-20260715 at all. Given
that e73ba3d6ed03b isn't in next, the fixup shouldn't be there either.

Looking at merge.log I see merging scsi-mkp is tried, the fixup is
applied, yielding 0fd66dadace89 and then `git reset --hard HEAD^`
follows throwing away that commit to replace it by
next-20260714/scsi-mkp which is already included and thus the
patches/device-id-zorro fixup is applied to the wrong commit.

Having said that e73ba3d6ed03b is still in
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
without the patch preparing drivers/ata/pata_buddha.c for that change
and thus resulting in a build failure on m68k.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the scsi-mkp tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

On Thu, Jul 16, 2026 at 12:13:59PM +0200, Uwe Kleine-König wrote:

> So the fixup is applied to the merge of the scsi tree and not the
> scsi-mkp tree. The latter wasn't pulled into next-20260715 at all. Given
> that e73ba3d6ed03b isn't in next, the fixup shouldn't be there either.

> Looking at merge.log I see merging scsi-mkp is tried, the fixup is
> applied, yielding 0fd66dadace89 and then `git reset --hard HEAD^`
> follows throwing away that commit to replace it by
> next-20260714/scsi-mkp which is already included and thus the
> patches/device-id-zorro fixup is applied to the wrong commit.

Right, the fixups don't differentiate between versions of the tree and
the fact that scsi-mkp is broken and never had a version that was merged
this cycle means that the tooling gets confused about the fixup.  We
need the fixup to try the build on the off chance that there's a fix,
but then it's not needed if the fix failed and since it's not dependent
on any context added by the merge it doesn't get skipped.

> Having said that e73ba3d6ed03b is still in
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
> without the patch preparing drivers/ata/pata_buddha.c for that change
> and thus resulting in a build failure on m68k.

It's also got an arm64 allyesconfig build failure which is what's
keeping it out of -next, the submitter of the offending patch asked for
their patches to be dropped but I've seen no response from Martin.

Hopefully at some point the various build failures will be addressed and
this will all get sorted.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the scsi-mkp tree with the origin tree

[Martin K. Petersen]

Mark,

> It's also got an arm64 allyesconfig build failure which is what's
> keeping it out of -next, the submitter of the offending patch asked for
> their patches to be dropped but I've seen no response from Martin.

I've been traveling for a couple of days. Will resolve this later today.

-- 
Martin K. Petersen

Re: linux-next: manual merge of the scsi-mkp tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Thu, Jul 16, 2026 at 09:09:14AM -0400, Martin K. Petersen wrote:

> > It's also got an arm64 allyesconfig build failure which is what's
> > keeping it out of -next, the submitter of the offending patch asked for
> > their patches to be dropped but I've seen no response from Martin.

> I've been traveling for a couple of days. Will resolve this later today.

Ah, excellent - thanks!  That will also resolve the issue with the fixup
from Uwe so we should be good.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the scsi-mkp tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

Hi all,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  drivers/scsi/mpi3mr/mpi3mr_fw.c

between commit:

  fa96392ebebc8 ("scsi: mpi3mr: Add NULL checks when resetting request and reply queues")

from the origin tree and commit:

  9d660e482071b ("scsi: mpi3mr: Add queue-full tracking for operational request queues")

from the scsi-mkp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc drivers/scsi/mpi3mr/mpi3mr_fw.c
index c744210cc9018,01042eaf0dff4..0000000000000
--- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
+++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
@@@ -4817,25 -4828,22 +4838,26 @@@ void mpi3mr_memset_buffers(struct mpi3m
  	}
  
  	for (i = 0; i < mrioc->num_queues; i++) {
 -		mrioc->op_reply_qinfo[i].qid = 0;
 -		mrioc->op_reply_qinfo[i].ci = 0;
 -		mrioc->op_reply_qinfo[i].num_replies = 0;
 -		mrioc->op_reply_qinfo[i].ephase = 0;
 -		atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
 -		atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
 -		mpi3mr_memset_op_reply_q_buffers(mrioc, i);
 +		if (mrioc->op_reply_qinfo) {
 +			mrioc->op_reply_qinfo[i].qid = 0;
 +			mrioc->op_reply_qinfo[i].ci = 0;
 +			mrioc->op_reply_qinfo[i].num_replies = 0;
 +			mrioc->op_reply_qinfo[i].ephase = 0;
 +			atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
 +			atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
 +			mpi3mr_memset_op_reply_q_buffers(mrioc, i);
 +		}
  
 -		mrioc->req_qinfo[i].ci = 0;
 -		mrioc->req_qinfo[i].pi = 0;
 -		mrioc->req_qinfo[i].num_requests = 0;
 -		mrioc->req_qinfo[i].qid = 0;
 -		mrioc->req_qinfo[i].reply_qid = 0;
 -		spin_lock_init(&mrioc->req_qinfo[i].q_lock);
 -		mrioc->req_qinfo[i].last_full_host_tag = 0;
 -		mpi3mr_memset_op_req_q_buffers(mrioc, i);
 +		if (mrioc->req_qinfo) {
 +			mrioc->req_qinfo[i].ci = 0;
 +			mrioc->req_qinfo[i].pi = 0;
 +			mrioc->req_qinfo[i].num_requests = 0;
 +			mrioc->req_qinfo[i].qid = 0;
 +			mrioc->req_qinfo[i].reply_qid = 0;
 +			spin_lock_init(&mrioc->req_qinfo[i].q_lock);
++			mrioc->req_qinfo[i].last_full_host_tag = 0;
 +			mpi3mr_memset_op_req_q_buffers(mrioc, i);
 +		}
  	}
  
  	atomic_set(&mrioc->pend_large_data_sz, 0);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]