Re: linux-next: manual merge of the scsi tree with Linus' tree
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
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
On Thu, Jun 20, 2019 at 5:35 PM James Bottomley 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
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
On Thu, 2019-06-20 at 17:07 -0700, Linus Torvalds wrote: > On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell 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
On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell 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
Hi all,
On Tue, 28 May 2019 11:43:20 +1000 Stephen Rothwell
wrote:
>
> On Wed, 22 May 2019 10:08:34 +1000 Stephen Rothwell
> 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
pgpfm6UwMXinz.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the scsi tree with Linus' tree
Hi all,
On Wed, 22 May 2019 10:08:34 +1000 Stephen Rothwell
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
pgpQb44fFRyOL.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the scsi tree with Linus' tree
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
pgpJe3l6mJrA2.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the scsi tree with Linus' tree
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
pgpf_5bjSIegW.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the scsi tree with Linus' tree
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
pgpt7hzwUErmU.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the scsi tree with Linus' tree
Thanks Stephen's help.
Ching Huang
Stephen Rothwell 於 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..
> --- 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(>dev,
> acb->ioqueue_size,
> - _coherent_handle, GFP_KERNEL);
> + dma_coherent = dma_alloc_coherent(>dev,
> - acb->roundup_ccbsize,
> ++acb->ioqueue_size,
> +_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(>dev,
> acb->ioqueue_size,
> - _coherent_handle, GFP_KERNEL);
> + dma_coherent = dma_alloc_coherent(>dev,
> - acb->roundup_ccbsize,
> ++acb->ioqueue_size,
> +_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(>dev,
> acb->ioqueue_size,
> - _coherent_handle, GFP_KERNEL);
> + dma_coherent = dma_alloc_coherent(>dev,
> - acb->roundup_ccbsize,
> ++acb->ioqueue_size,
> +_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
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..
--- 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(>dev,
acb->ioqueue_size,
- _coherent_handle, GFP_KERNEL);
+ dma_coherent = dma_alloc_coherent(>dev,
- acb->roundup_ccbsize,
++acb->ioqueue_size,
+_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(>dev,
acb->ioqueue_size,
- _coherent_handle, GFP_KERNEL);
+ dma_coherent = dma_alloc_coherent(>dev,
- acb->roundup_ccbsize,
++acb->ioqueue_size,
+_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(>dev,
acb->ioqueue_size,
- _coherent_handle, GFP_KERNEL);
+ dma_coherent = dma_alloc_coherent(>dev,
- acb->roundup_ccbsize,
++acb->ioqueue_size,
+_coherent_handle,
+GFP_KERNEL);
if (!dma_coherent){
pr_notice("arcmsr%d: DMA allocation failed\n",
acb->host->host_no);
return false;
pgpcNOv73umMy.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the scsi tree with Linus' tree
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..
--- 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_FORCELUN0x002 /* 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_NOTQ0x020 /* 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_LARGELUN0x200 /* LUNs past 7 on a SCSI-2
device */
- #define BLIST_INQUIRY_36 0x400 /* override additional length field */
- #define BLIST_NOSTARTONADD0x1000 /* do not do automatic start on add */
- #define BLIST_REPORTLUN2 0x2 /* try REPORT_LUNS even for SCSI-2 devs
- (if HBA supports more than 8 LUNs) */
- #define BLIST_NOREPORTLUN 0x4 /* don't try REPORT_LUNS scan (SCSI-3
devs) */
- #define BLIST_NOT_LOCKABLE0x8 /* don't use PREVENT-ALLOW commands */
- #define BLIST_NO_ULD_ATTACH 0x10 /* device is actually for RAID config
*/
- #define BLIST_SELECT_NO_ATN 0x20 /* select without ATN */
- #define BLIST_RETRY_HWERROR 0x40 /* retry HARDWARE_ERROR */
- #define BLIST_MAX_512 0x80 /* maximum 512 sector cdb length */
- #define BLIST_NO_DIF 0x200 /* Disable T10 PI (DIF) */
- #define BLIST_SKIP_VPD_PAGES 0x400 /* Ignore SBC-3 VPD pages */
- #define BLIST_TRY_VPD_PAGES 0x1000 /* Attempt to read VPD pages */
- #define BLIST_NO_RSOC 0x2000 /* don't try to issue RSOC */
- #define BLIST_MAX_10240x4000 /* maximum 1024 sector cdb
length */
- #define BLIST_UNMAP_LIMIT_WS 0x8000 /* 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
linux-next: manual merge of the scsi tree with Linus' tree
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..
--- 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_FORCELUN0x002 /* 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_NOTQ0x020 /* 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_LARGELUN0x200 /* LUNs past 7 on a SCSI-2
device */
- #define BLIST_INQUIRY_36 0x400 /* override additional length field */
- #define BLIST_NOSTARTONADD0x1000 /* do not do automatic start on add */
- #define BLIST_REPORTLUN2 0x2 /* try REPORT_LUNS even for SCSI-2 devs
- (if HBA supports more than 8 LUNs) */
- #define BLIST_NOREPORTLUN 0x4 /* don't try REPORT_LUNS scan (SCSI-3
devs) */
- #define BLIST_NOT_LOCKABLE0x8 /* don't use PREVENT-ALLOW commands */
- #define BLIST_NO_ULD_ATTACH 0x10 /* device is actually for RAID config
*/
- #define BLIST_SELECT_NO_ATN 0x20 /* select without ATN */
- #define BLIST_RETRY_HWERROR 0x40 /* retry HARDWARE_ERROR */
- #define BLIST_MAX_512 0x80 /* maximum 512 sector cdb length */
- #define BLIST_NO_DIF 0x200 /* Disable T10 PI (DIF) */
- #define BLIST_SKIP_VPD_PAGES 0x400 /* Ignore SBC-3 VPD pages */
- #define BLIST_TRY_VPD_PAGES 0x1000 /* Attempt to read VPD pages */
- #define BLIST_NO_RSOC 0x2000 /* don't try to issue RSOC */
- #define BLIST_MAX_10240x4000 /* maximum 1024 sector cdb
length */
- #define BLIST_UNMAP_LIMIT_WS 0x8000 /* 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
Re: linux-next: manual merge of the scsi tree with Linus' tree
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the scsi tree with Linus' tree
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the scsi tree with Linus' tree
On Fri, Jul 20, 2012 at 12:29 AM, James Bottomley wrote: > > By the way, Linus, the patch says: > > Cc: Dan Williams > Cc: Alan Stern > Cc: James Bottomley > Cc: Borislav Petkov > Cc: linux-scsi > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the scsi tree with Linus' tree
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
Cc: Alan Stern
Cc: James Bottomley
Cc: Borislav Petkov
Cc: linux-scsi
But best I can tell it never went to either me or linux-scsi.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the scsi tree with Linus' tree
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.willi...@gmail.com Cc: Alan Stern st...@rowland.harvard.edu Cc: James Bottomley jbottom...@parallels.com Cc: Borislav Petkov b...@amd64.org Cc: linux-scsi linux-s...@vger.kernel.org But best I can tell it never went to either me or linux-scsi. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the scsi tree with Linus' tree
On Fri, Jul 20, 2012 at 12:29 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: By the way, Linus, the patch says: Cc: Dan Williams dan.j.willi...@gmail.com Cc: Alan Stern st...@rowland.harvard.edu Cc: James Bottomley jbottom...@parallels.com Cc: Borislav Petkov b...@amd64.org Cc: linux-scsi linux-s...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the scsi tree with Linus' tree
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 Rothwells...@canb.auug.org.au
pgpW15sOt7ks9.pgp
Description: PGP signature
linux-next: manual merge of the scsi tree with Linus' tree
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 Rothwells...@canb.auug.org.au pgpW15sOt7ks9.pgp Description: PGP signature
