linux-next: manual merge of the scsi tree with Linus' tree

linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/scsi/osst.c

between commit:

  09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")

from Linus' tree and commit:

  70841904d909 ("scsi: osst: kill obsolete driver")

from the scsi tree.

I fixed it up (I just removed the file) 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.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Greg Kroah-Hartman]

On Thu, Jun 20, 2019 at 09:14:07PM -0400, Martin K. Petersen wrote:
> 
> James,
> 
> > There's two problems.  One is simple terminology: the
> > Documentation/process/licence-rules.rst say:
> >
> > GPL-2.0 means GPL 2 only
> > GPL-2.0+ means GPL 2 or later
> >
> > I believe RMS made a fuss about this and he finally agreed to 
> >
> > GPL-2.0-only
> > GPL-2.0-or-later
> 
> Looks like there are tons of the old style SPDX tags in the kernel. Is
> there going to be a treewide conversion to the new tag format?

Not any time soon.  Both are "valid" for us, and the tools.  We are
focusing on actually tagging all files before we worry about these two
different types of tag that mean the same thing.

thanks,

greg k-h

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Martin K. Petersen]

James,

> There's two problems.  One is simple terminology: the
> Documentation/process/licence-rules.rst say:
>
> GPL-2.0 means GPL 2 only
> GPL-2.0+ means GPL 2 or later
>
> I believe RMS made a fuss about this and he finally agreed to 
>
> GPL-2.0-only
> GPL-2.0-or-later

Looks like there are tons of the old style SPDX tags in the kernel. Is
there going to be a treewide conversion to the new tag format?

Just wondering how much to clean up given that the files Christoph
touched only constitute a subset of the old style tags found under
drivers/scsi.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Linus Torvalds]

On Thu, Jun 20, 2019 at 5:35 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> * This file is licensed under GPLv2.
>
> In all the libsas files, but then muddied the water by quoting GPLv2
> verbatim (which includes the or later than language).

Ok, thanks for the explanation. And yes, that would have likely
confused people who just looked at the license text.

            Linus

Re: linux-next: manual merge of the scsi tree with Linus' tree

[James Bottomley]

On Thu, 2019-06-20 at 17:07 -0700, Linus Torvalds wrote:
> On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell <sfr@canb.auug.org.a
> u> wrote:
> > 
> > At what point does it become worth while to do a back merge of
> > v5.2-rc4 (I think the last of the SPDX changes went into there) to
> > take care of all these (rather than Linus having to edit each of
> > these files himself during the merge window)?
> 
> For just trivial conflicts like this that have no code, I really
> would prefer no backmerges.
> 
> That said, I would tend to trust the due diligence that Thomas, Greg
> & co have done, and am wondering why the scsi tree ends up having
> different SPDX results in the first place..

There's two problems.  One is simple terminology: the
Documentation/process/licence-rules.rst say:

GPL-2.0 means GPL 2 only
GPL-2.0+ means GPL 2 or later

I believe RMS made a fuss about this and he finally agreed to 

GPL-2.0-only
GPL-2.0-or-later

It's just the kernel doc hasn't been updated so Christoph did what the
doc says when making the change and Thomas did what we've apparently
agreed to with RMS, hence textual discrepencies.

The other problem is actually substantive: In the libsas code Luben
Tuikov originally specified gpl 2.0 only by dint of stating:

* This file is licensed under GPLv2.

In all the libsas files, but then muddied the water by quoting GPLv2
verbatim (which includes the or later than language).  So for these
files Christoph did the conversion to v2 only SPDX tags and Thomas
converted to v2 or later tags.  Based on somewhat distant recollections
of history, I believe Christoph is right on this one.

James

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Martin K. Petersen]

Linus,

> That said, I would tend to trust the due diligence that Thomas, Greg &
> co have done, and am wondering why the scsi tree ends up having
> different SPDX results in the first place..

I left Christoph's patches in my 5.3 queue after Stephen let me know
about the treewide series because, well, it came from people with SCSI
affiliation and it got reviewed.

In any case I assumed the delta was formatting or purely cosmetic. I
don't recall there being any ambiguity about choice of license or SPDX
tag when I reviewed the patches.

I have been meaning to take a closer look but have had a critical fire
eating up a bunch of my time the last couple of weeks. I'll get to it...

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Linus Torvalds]

On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> At what point does it become worth while to do a back merge of v5.2-rc4
> (I think the last of the SPDX changes went into there) to take care of
> all these (rather than Linus having to edit each of these files himself
> during the merge window)?

For just trivial conflicts like this that have no code, I really would
prefer no backmerges.

That said, I would tend to trust the due diligence that Thomas, Greg &
co have done, and am wondering why the scsi tree ends up having
different SPDX results in the first place..

             Linus

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

On Tue, 28 May 2019 11:43:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 22 May 2019 10:08:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the scsi tree got conflicts in:
> > 
> >   drivers/scsi/hosts.c

	...

> > between commits:
> > 
> >   457c89965399 ("treewide: Add SPDX license identifier for missed files")
> >   09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")
> > 
> > from Linus' tree and commits:
> > 
> >   026104bfa591 ("scsi: core: add SPDX tags to scsi midlayer files missing licensing information")
> >   5502239e73e6 ("scsi: libsas: add a SPDX tag to sas_task.c")
> >   5897b844b7f9 ("scsi: sd: add a SPDX tag to sd.c")
> >   95b04a2ff9c7 ("scsi: sr: add a SPDX tag to sr.c")
> >   50a1ea5bebbc ("scsi: st: add a SPDX tag to st.c")  
> 
> I have now got more of these conflicts in
> 
> drivers/scsi/libsas/sas_init.c

	...

OK, so here is the complete list (so far) of files in the scsi tree
that conflict with the SPDX updates in Linus' tree:

drivers/scsi/fcoe/fcoe.c
drivers/scsi/fcoe/fcoe.h
drivers/scsi/fcoe/fcoe_ctlr.c
drivers/scsi/fcoe/fcoe_sysfs.c
drivers/scsi/fcoe/fcoe_transport.c
drivers/scsi/hosts.c
drivers/scsi/libfc/fc_disc.c
drivers/scsi/libfc/fc_elsct.c
drivers/scsi/libfc/fc_exch.c
drivers/scsi/libfc/fc_fcp.c
drivers/scsi/libfc/fc_frame.c
drivers/scsi/libfc/fc_libfc.c
drivers/scsi/libfc/fc_libfc.h
drivers/scsi/libfc/fc_lport.c
drivers/scsi/libfc/fc_npiv.c
drivers/scsi/libfc/fc_rport.c
drivers/scsi/libiscsi.c
drivers/scsi/libiscsi_tcp.c
drivers/scsi/libsas/sas_ata.c
drivers/scsi/libsas/sas_host_smp.c
drivers/scsi/libsas/sas_init.c
drivers/scsi/libsas/sas_internal.h
drivers/scsi/libsas/sas_scsi_host.c
drivers/scsi/libsas/sas_task.c
drivers/scsi/osst.c
drivers/scsi/scsi.c
drivers/scsi/scsi_error.c
drivers/scsi/scsi_ioctl.c
drivers/scsi/scsi_lib.c
drivers/scsi/scsi_logging.c
drivers/scsi/scsi_pm.c
drivers/scsi/scsi_sysctl.c
drivers/scsi/scsi_sysfs.c
drivers/scsi/scsi_trace.c
drivers/scsi/scsi_transport_fc.c
drivers/scsi/scsi_transport_iscsi.c
drivers/scsi/scsi_transport_sas.c
drivers/scsi/scsi_transport_spi.c
drivers/scsi/sd.c
drivers/scsi/sd_dif.c
drivers/scsi/sd_zbc.c
drivers/scsi/ses.c
drivers/scsi/sg.c
drivers/scsi/sr.c
drivers/scsi/st.c
include/scsi/fc/fc_encaps.h
include/scsi/fc/fc_fc2.h
include/scsi/fc/fc_fcoe.h
include/scsi/fc/fc_fcp.h
include/scsi/fc/fc_ms.h
include/scsi/iscsi_if.h
include/scsi/iscsi_proto.h
include/scsi/libfc.h
include/scsi/libfcoe.h
include/scsi/libiscsi.h
include/scsi/libiscsi_tcp.h
include/scsi/libsas.h
include/scsi/sas.h
include/scsi/sas_ata.h
include/scsi/scsi_bsg_iscsi.h
include/scsi/scsi_transport.h
include/scsi/scsi_transport_fc.h
include/scsi/scsi_transport_iscsi.h
include/scsi/scsi_transport_spi.h

At what point does it become worth while to do a back merge of v5.2-rc4
(I think the last of the SPDX changes went into there) to take care of
all these (rather than Linus having to edit each of these files himself
during the merge window)?

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

On Wed, 22 May 2019 10:08:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the scsi tree got conflicts in:
> 
>   drivers/scsi/hosts.c
>   drivers/scsi/libsas/sas_task.c
>   drivers/scsi/scsi.c
>   drivers/scsi/scsi_error.c
>   drivers/scsi/scsi_ioctl.c
>   drivers/scsi/scsi_lib.c
>   drivers/scsi/scsi_pm.c
>   drivers/scsi/scsi_sysfs.c
>   drivers/scsi/sd.c
>   drivers/scsi/sr.c
>   drivers/scsi/st.c
> 
> between commits:
> 
>   457c89965399 ("treewide: Add SPDX license identifier for missed files")
>   09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")
> 
> from Linus' tree and commits:
> 
>   026104bfa591 ("scsi: core: add SPDX tags to scsi midlayer files missing licensing information")
>   5502239e73e6 ("scsi: libsas: add a SPDX tag to sas_task.c")
>   5897b844b7f9 ("scsi: sd: add a SPDX tag to sd.c")
>   95b04a2ff9c7 ("scsi: sr: add a SPDX tag to sr.c")
>   50a1ea5bebbc ("scsi: st: add a SPDX tag to st.c")

I have now got more of these conflicts in

drivers/scsi/libsas/sas_init.c
drivers/scsi/libsas/sas_internal.h
drivers/scsi/libsas/sas_scsi_host.c
drivers/scsi/sg.c
include/scsi/libsas.h
include/scsi/sas.h

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

FIXME: Add owner of second tree to To:
       Add author(s)/SOB of conflicting commits.

Today's linux-next merge of the scsi tree got conflicts in:

  drivers/scsi/hosts.c
  drivers/scsi/libsas/sas_task.c
  drivers/scsi/scsi.c
  drivers/scsi/scsi_error.c
  drivers/scsi/scsi_ioctl.c
  drivers/scsi/scsi_lib.c
  drivers/scsi/scsi_pm.c
  drivers/scsi/scsi_sysfs.c
  drivers/scsi/sd.c
  drivers/scsi/sr.c
  drivers/scsi/st.c

between commits:

  457c89965399 ("treewide: Add SPDX license identifier for missed files")
  09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")

from Linus' tree and commits:

  026104bfa591 ("scsi: core: add SPDX tags to scsi midlayer files missing licensing information")
  5502239e73e6 ("scsi: libsas: add a SPDX tag to sas_task.c")
  5897b844b7f9 ("scsi: sd: add a SPDX tag to sd.c")
  95b04a2ff9c7 ("scsi: sr: add a SPDX tag to sr.c")
  50a1ea5bebbc ("scsi: st: add a SPDX tag to st.c")

from the scsi tree.

I fixed it up (I just used the scsi tree versions - which are GPL-2.0
instead of GPL-2.0-only) 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.



-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

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

Hi James,

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

  drivers/scsi/arcmsr/arcmsr_hba.c

between commit:

  750afb08ca71 ("cross-tree: phase out dma_zalloc_coherent()")

from Linus' tree and commit:

  3e3153b050fc ("scsi: arcmsr: Use dma_alloc_coherent to replace dma_zalloc_coherent")

from the scsi tree.

I fixed it up (I just used the scsi tree version) 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.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the scsi tree with Linus' tree

[黃清隆]

Thanks Stephen's help.

Ching Huang

Stephen Rothwell <sfr@canb.auug.org.au> 於 2019年1月14日 週一 上午10:48寫道：
>
> Hi all,
>
> Today's linux-next merge of the scsi tree got a conflict in:
>
>   drivers/scsi/arcmsr/arcmsr_hba.c
>
> between commit:
>
>   750afb08ca71 ("cross-tree: phase out dma_zalloc_coherent()")
>
> from Linus' tree and commit:
>
>   381d66da7212 ("scsi: arcmsr: Rename acb structure member roundup_ccbsize to ioqueue_size")
>
> from the scsi 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.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/scsi/arcmsr/arcmsr_hba.c
> index 57c6fa388bf6,9f85d5abbb0c..000000000000
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> @@@ -585,12 -641,9 +641,11 @@@ static bool arcmsr_alloc_io_queue(struc
>
>         switch (acb->adapter_type) {
>         case ACB_ADAPTER_TYPE_B: {
> -               struct MessageUnit_B *reg;
> -               acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_B), 32);
> +               acb->ioqueue_size = roundup(sizeof(struct MessageUnit_B), 32);
>  -              dma_coherent = dma_zalloc_coherent(&pdev->dev, acb->ioqueue_size,
>  -                      &dma_coherent_handle, GFP_KERNEL);
>  +              dma_coherent = dma_alloc_coherent(&pdev->dev,
> -                                                 acb->roundup_ccbsize,
> ++                                                acb->ioqueue_size,
>  +                                                &dma_coherent_handle,
>  +                                                GFP_KERNEL);
>                 if (!dma_coherent) {
>                         pr_notice("arcmsr%d: DMA allocation failed\n", acb->host->host_no);
>                         return false;
> @@@ -616,13 -655,9 +657,11 @@@
>                 }
>                 break;
>         case ACB_ADAPTER_TYPE_D: {
> -               struct MessageUnit_D *reg;
> -
> -               acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_D), 32);
> +               acb->ioqueue_size = roundup(sizeof(struct MessageUnit_D), 32);
>  -              dma_coherent = dma_zalloc_coherent(&pdev->dev, acb->ioqueue_size,
>  -                      &dma_coherent_handle, GFP_KERNEL);
>  +              dma_coherent = dma_alloc_coherent(&pdev->dev,
> -                                                 acb->roundup_ccbsize,
> ++                                                acb->ioqueue_size,
>  +                                                &dma_coherent_handle,
>  +                                                GFP_KERNEL);
>                 if (!dma_coherent) {
>                         pr_notice("arcmsr%d: DMA allocation failed\n", acb->host->host_no);
>                         return false;
> @@@ -662,11 -671,9 +675,11 @@@
>         case ACB_ADAPTER_TYPE_E: {
>                 uint32_t completeQ_size;
>                 completeQ_size = sizeof(struct deliver_completeQ) * ARCMSR_MAX_HBE_DONEQUEUE + 128;
> -               acb->roundup_ccbsize = roundup(completeQ_size, 32);
> +               acb->ioqueue_size = roundup(completeQ_size, 32);
>  -              dma_coherent = dma_zalloc_coherent(&pdev->dev, acb->ioqueue_size,
>  -                      &dma_coherent_handle, GFP_KERNEL);
>  +              dma_coherent = dma_alloc_coherent(&pdev->dev,
> -                                                 acb->roundup_ccbsize,
> ++                                                acb->ioqueue_size,
>  +                                                &dma_coherent_handle,
>  +                                                GFP_KERNEL);
>                 if (!dma_coherent){
>                         pr_notice("arcmsr%d: DMA allocation failed\n", acb->host->host_no);
>                         return false;

linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/scsi/arcmsr/arcmsr_hba.c

between commit:

  750afb08ca71 ("cross-tree: phase out dma_zalloc_coherent()")

from Linus' tree and commit:

  381d66da7212 ("scsi: arcmsr: Rename acb structure member roundup_ccbsize to ioqueue_size")

from the scsi 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/scsi/arcmsr/arcmsr_hba.c
index 57c6fa388bf6,9f85d5abbb0c..000000000000
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@@ -585,12 -641,9 +641,11 @@@ static bool arcmsr_alloc_io_queue(struc
  
  	switch (acb->adapter_type) {
  	case ACB_ADAPTER_TYPE_B: {
- 		struct MessageUnit_B *reg;
- 		acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_B), 32);
+ 		acb->ioqueue_size = roundup(sizeof(struct MessageUnit_B), 32);
 -		dma_coherent = dma_zalloc_coherent(&pdev->dev, acb->ioqueue_size,
 -			&dma_coherent_handle, GFP_KERNEL);
 +		dma_coherent = dma_alloc_coherent(&pdev->dev,
- 						  acb->roundup_ccbsize,
++						  acb->ioqueue_size,
 +						  &dma_coherent_handle,
 +						  GFP_KERNEL);
  		if (!dma_coherent) {
  			pr_notice("arcmsr%d: DMA allocation failed\n", acb->host->host_no);
  			return false;
@@@ -616,13 -655,9 +657,11 @@@
  		}
  		break;
  	case ACB_ADAPTER_TYPE_D: {
- 		struct MessageUnit_D *reg;
- 
- 		acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_D), 32);
+ 		acb->ioqueue_size = roundup(sizeof(struct MessageUnit_D), 32);
 -		dma_coherent = dma_zalloc_coherent(&pdev->dev, acb->ioqueue_size,
 -			&dma_coherent_handle, GFP_KERNEL);
 +		dma_coherent = dma_alloc_coherent(&pdev->dev,
- 						  acb->roundup_ccbsize,
++						  acb->ioqueue_size,
 +						  &dma_coherent_handle,
 +						  GFP_KERNEL);
  		if (!dma_coherent) {
  			pr_notice("arcmsr%d: DMA allocation failed\n", acb->host->host_no);
  			return false;
@@@ -662,11 -671,9 +675,11 @@@
  	case ACB_ADAPTER_TYPE_E: {
  		uint32_t completeQ_size;
  		completeQ_size = sizeof(struct deliver_completeQ) * ARCMSR_MAX_HBE_DONEQUEUE + 128;
- 		acb->roundup_ccbsize = roundup(completeQ_size, 32);
+ 		acb->ioqueue_size = roundup(completeQ_size, 32);
 -		dma_coherent = dma_zalloc_coherent(&pdev->dev, acb->ioqueue_size,
 -			&dma_coherent_handle, GFP_KERNEL);
 +		dma_coherent = dma_alloc_coherent(&pdev->dev,
- 						  acb->roundup_ccbsize,
++						  acb->ioqueue_size,
 +						  &dma_coherent_handle,
 +						  GFP_KERNEL);
  		if (!dma_coherent){
  			pr_notice("arcmsr%d: DMA allocation failed\n", acb->host->host_no);
  			return false;

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

linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

Hi James,

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

  include/scsi/scsi_devinfo.h

between commit:

  28a0bc4120d3 ("scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP")

from Linus' tree and commit:

  f26aeada0493 ("scsi: scsi_devinfo: Reformat blacklist flags")

from the scsi 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.

-- 
Cheers,
Stephen Rothwell

diff --cc include/scsi/scsi_devinfo.h
index 3575693bb628,7a2329c026a4..000000000000
--- a/include/scsi/scsi_devinfo.h
+++ b/include/scsi/scsi_devinfo.h
@@@ -4,32 -3,55 +4,57 @@@
  /*
   * Flags for SCSI devices that need special treatment
   */
- #define BLIST_NOLUN     	0x001	/* Only scan LUN 0 */
- #define BLIST_FORCELUN  	0x002	/* Known to have LUNs, force scanning,
- 					   deprecated: Use max_luns=N */
- #define BLIST_BORKEN    	0x004	/* Flag for broken handshaking */
- #define BLIST_KEY       	0x008	/* unlock by special command */
- #define BLIST_SINGLELUN 	0x010	/* Do not use LUNs in parallel */
- #define BLIST_NOTQ		0x020	/* Buggy Tagged Command Queuing */
- #define BLIST_SPARSELUN 	0x040	/* Non consecutive LUN numbering */
- #define BLIST_MAX5LUN		0x080	/* Avoid LUNS >= 5 */
- #define BLIST_ISROM     	0x100	/* Treat as (removable) CD-ROM */
- #define BLIST_LARGELUN		0x200	/* LUNs past 7 on a SCSI-2 device */
- #define BLIST_INQUIRY_36	0x400	/* override additional length field */
- #define BLIST_NOSTARTONADD	0x1000	/* do not do automatic start on add */
- #define BLIST_REPORTLUN2	0x20000	/* try REPORT_LUNS even for SCSI-2 devs
-  					   (if HBA supports more than 8 LUNs) */
- #define BLIST_NOREPORTLUN	0x40000	/* don't try REPORT_LUNS scan (SCSI-3 devs) */
- #define BLIST_NOT_LOCKABLE	0x80000	/* don't use PREVENT-ALLOW commands */
- #define BLIST_NO_ULD_ATTACH	0x100000 /* device is actually for RAID config */
- #define BLIST_SELECT_NO_ATN	0x200000 /* select without ATN */
- #define BLIST_RETRY_HWERROR	0x400000 /* retry HARDWARE_ERROR */
- #define BLIST_MAX_512		0x800000 /* maximum 512 sector cdb length */
- #define BLIST_NO_DIF		0x2000000 /* Disable T10 PI (DIF) */
- #define BLIST_SKIP_VPD_PAGES	0x4000000 /* Ignore SBC-3 VPD pages */
- #define BLIST_TRY_VPD_PAGES	0x10000000 /* Attempt to read VPD pages */
- #define BLIST_NO_RSOC		0x20000000 /* don't try to issue RSOC */
- #define BLIST_MAX_1024		0x40000000 /* maximum 1024 sector cdb length */
- #define BLIST_UNMAP_LIMIT_WS	0x80000000 /* Use UNMAP limit for WRITE SAME */
+ 
+ /* Only scan LUN 0 */
+ #define BLIST_NOLUN		((__force __u32 __bitwise)(1 << 0))
+ /* Known to have LUNs, force scanning.
+  * DEPRECATED: Use max_luns=N */
+ #define BLIST_FORCELUN		((__force __u32 __bitwise)(1 << 1))
+ /* Flag for broken handshaking */
+ #define BLIST_BORKEN		((__force __u32 __bitwise)(1 << 2))
+ /* unlock by special command */
+ #define BLIST_KEY		((__force __u32 __bitwise)(1 << 3))
+ /* Do not use LUNs in parallel */
+ #define BLIST_SINGLELUN		((__force __u32 __bitwise)(1 << 4))
+ /* Buggy Tagged Command Queuing */
+ #define BLIST_NOTQ		((__force __u32 __bitwise)(1 << 5))
+ /* Non consecutive LUN numbering */
+ #define BLIST_SPARSELUN		((__force __u32 __bitwise)(1 << 6))
+ /* Avoid LUNS >= 5 */
+ #define BLIST_MAX5LUN		((__force __u32 __bitwise)(1 << 7))
+ /* Treat as (removable) CD-ROM */
+ #define BLIST_ISROM		((__force __u32 __bitwise)(1 << 8))
+ /* LUNs past 7 on a SCSI-2 device */
+ #define BLIST_LARGELUN		((__force __u32 __bitwise)(1 << 9))
+ /* override additional length field */
+ #define BLIST_INQUIRY_36	((__force __u32 __bitwise)(1 << 10))
+ /* do not do automatic start on add */
+ #define BLIST_NOSTARTONADD	((__force __u32 __bitwise)(1 << 12))
+ /* try REPORT_LUNS even for SCSI-2 devs (if HBA supports more than 8 LUNs) */
+ #define BLIST_REPORTLUN2	((__force __u32 __bitwise)(1 << 17))
+ /* don't try REPORT_LUNS scan (SCSI-3 devs) */
+ #define BLIST_NOREPORTLUN	((__force __u32 __bitwise)(1 << 18))
+ /* don't use PREVENT-ALLOW commands */
+ #define BLIST_NOT_LOCKABLE	((__force __u32 __bitwise)(1 << 19))
+ /* device is actually for RAID config */
+ #define BLIST_NO_ULD_ATTACH	((__force __u32 __bitwise)(1 << 20))
+ /* select without ATN */
+ #define BLIST_SELECT_NO_ATN	((__force __u32 __bitwise)(1 << 21))
+ /* retry HARDWARE_ERROR */
+ #define BLIST_RETRY_HWERROR	((__force __u32 __bitwise)(1 << 22))
+ /* maximum 512 sector cdb length */
+ #define BLIST_MAX_512		((__force __u32 __bitwise)(1 << 23))
+ /* Disable T10 PI (DIF) */
+ #define BLIST_NO_DIF		((__force __u32 __bitwise)(1 << 25))
+ /* Ignore SBC-3 VPD pages */
+ #define BLIST_SKIP_VPD_PAGES	((__force __u32 __bitwise)(1 << 26))
+ /* Attempt to read VPD pages */
+ #define BLIST_TRY_VPD_PAGES	((__force __u32 __bitwise)(1 << 28))
+ /* don't try to issue RSOC */
+ #define BLIST_NO_RSOC		((__force __u32 __bitwise)(1 << 29))
+ /* maximum 1024 sector cdb length */
+ #define BLIST_MAX_1024		((__force __u32 __bitwise)(1 << 30))
++/* Use UNMAP limit for WRITE SAME */
++#define BLIST_UNMAP_LIMIT_WS	((__force __u32 __bitwise)(1 << 31))
  
  #endif

Re: linux-next: manual merge of the scsi tree with Linus' tree

[James Bottomley]

On Fri, 2014-01-24 at 13:05 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> Today's linux-next merge of the scsi tree got conflicts in
> drivers/scsi/hpsa.c and drivers/scsi/hpsa.h between commits from Linus'
> tree and commits from the scsi tree.
> 
> This has happened because what you submitted to Linus differed
> significantly to what is in the scsi tree in linux-next.  :-(
> 
> I have just dropped the scsi tree for now.

Hm, sorry about that.  It looks like there was a failed push of the
for-next branch five weeks ago when I rebased to drop a pm80xx commit.
This also caused it to be six commits behind (five hpsa and one ipr)
because they were added after the rebase.

Not sure what else to do except "will try harder in future".

James

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Linus Torvalds]

On Fri, Jul 20, 2012 at 12:29 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> By the way, Linus, the patch says:
>
>     Cc: Dan Williams <dan.j.williams@gmail.com>
>     Cc: Alan Stern <stern@rowland.harvard.edu>
>     Cc: James Bottomley <jbottomley@parallels.com>
>     Cc: Borislav Petkov <bp@amd64.org>
>     Cc: linux-scsi <linux-scsi@vger.kernel.org>
>
> But best I can tell it never went to either me or linux-scsi.

Both you and linux-scsi were cc'd at least in some of the discussion. Search for

  "a7a20d103994fd760766e6c9d494daa569cbfe06 makes kernel 3.5
unbootable on an Intel chipset based motherboard"

but most of the noise is in the bugzilla itself:

  https://bugzilla.kernel.org/show_bug.cgi?id=44771

and it may well be that you weren't listed for the bugzilla entry.

Ugh, how I hate bugzilla.

                Linus

Re: linux-next: manual merge of the scsi tree with Linus' tree

[James Bottomley]

On Fri, 2012-07-20 at 10:32 +1000, Stephen Rothwell wrote:
> Hi James,
> 
> Today's linux-next merge of the scsi tree got a conflict in
> drivers/scsi/scsi_wait_scan.c between commit eea03c20ae38 ("Make
> wait_for_device_probe() also do scsi_complete_async_scans()") from Linus'
> tree and commit 01444e1106cb ("[SCSI] Remove scsi_wait_scan module") from
> the scsi tree.
> 
> I just removed the file.

That won't quite work; there's a lot of nasty fallout ... I'll actually
have to rebase the misc and async branches to fix this.

By the way, Linus, the patch says:

    Cc: Dan Williams <dan.j.williams@gmail.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: James Bottomley <jbottomley@parallels.com>
    Cc: Borislav Petkov <bp@amd64.org>
    Cc: linux-scsi <linux-scsi@vger.kernel.org>

But best I can tell it never went to either me or linux-scsi.

James

linux-next: manual merge of the scsi tree with Linus' tree

[Stephen Rothwell]

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

Hi James,

Today's linux-next merge of the scsi tree got a conflict in
drivers/scsi/scsi_wait_scan.c between commit eea03c20ae38 ("Make
wait_for_device_probe() also do scsi_complete_async_scans()") from Linus'
tree and commit 01444e1106cb ("[SCSI] Remove scsi_wait_scan module") from
the scsi tree.

I just removed the file.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]