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

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_alloc':
drivers/scsi/qla2xxx/qla_nx.c:4815:2: error: implicit declaration of function 'vmalloc'
drivers/scsi/qla2xxx/qla_nx.c:4815:14: warning: assignment makes pointer from integer without a cast
drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_free':
drivers/scsi/qla2xxx/qla_nx.c:4845:3: error: implicit declaration of function 'vfree'

Caused by commit b60bb5832c00 ("[SCSI] qla2xxx: Add support for ISP82xx
to capture dump (minidump) on failure").  Missing include of
linux/vmalloc.h.  See Rule 1 in Documentation/SubmitChecklist.

I have used the scsi tree from next-20110826 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Mon, 2011-08-29 at 12:09 +1000, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_alloc':
> drivers/scsi/qla2xxx/qla_nx.c:4815:2: error: implicit declaration of function 'vmalloc'
> drivers/scsi/qla2xxx/qla_nx.c:4815:14: warning: assignment makes pointer from integer without a cast
> drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_free':
> drivers/scsi/qla2xxx/qla_nx.c:4845:3: error: implicit declaration of function 'vfree'
> 
> Caused by commit b60bb5832c00 ("[SCSI] qla2xxx: Add support for ISP82xx
> to capture dump (minidump) on failure").  Missing include of
> linux/vmalloc.h.  See Rule 1 in Documentation/SubmitChecklist.
> 
> I have used the scsi tree from next-20110826 for today.

Thanks for finding the problem.  I updated the commit with a simple fix
and re-pushed.

James

Re: linux-next: build failure after merge of the scsi tree

[Giridhar Malavali]

>>

>On Mon, 2011-08-29 at 12:09 +1000, Stephen Rothwell wrote:
>> Hi James,
>> 
>> After merging the scsi tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>> 
>> drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_alloc':
>> drivers/scsi/qla2xxx/qla_nx.c:4815:2: error: implicit declaration of
>>function 'vmalloc'
>> drivers/scsi/qla2xxx/qla_nx.c:4815:14: warning: assignment makes
>>pointer from integer without a cast
>> drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_free':
>> drivers/scsi/qla2xxx/qla_nx.c:4845:3: error: implicit declaration of
>>function 'vfree'
>> 
>> Caused by commit b60bb5832c00 ("[SCSI] qla2xxx: Add support for ISP82xx
>> to capture dump (minidump) on failure").  Missing include of
>> linux/vmalloc.h.  See Rule 1 in Documentation/SubmitChecklist.
>> 
>> I have used the scsi tree from next-20110826 for today.
>
>Thanks for finding the problem.  I updated the commit with a simple fix
>and re-pushed.

Thanks James and Stephen for finding and fixing this problem. I will make
sure that such issues won't happen in future.

-- Giri

>
>James
>
>
>

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from drivers/scsi/lpfc/lpfc_debugfs.c:46:
drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_idiag_queacc_write':
drivers/scsi/lpfc/lpfc_sli4.h:1083:14: error: inlining failed in call to always_inline 'lpfc_sli4_qe': function body not available
 inline void *lpfc_sli4_qe(struct lpfc_queue *, uint16_t);
              ^~~~~~~~~~~~
drivers/scsi/lpfc/lpfc_debugfs.c:4488:12: note: called from here
   pentry = lpfc_sli4_qe(pque, index);
            ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/scsi/lpfc/lpfc_debugfs.c:46:
drivers/scsi/lpfc/lpfc_sli4.h:1083:14: error: inlining failed in call to always_inline 'lpfc_sli4_qe': function body not available
 inline void *lpfc_sli4_qe(struct lpfc_queue *, uint16_t);
              ^~~~~~~~~~~~
drivers/scsi/lpfc/lpfc_debugfs.c:4488:12: note: called from here
   pentry = lpfc_sli4_qe(pque, index);
            ^~~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  9afbee3d62a4 ("scsi: lpfc: Reduce memory footprint for lpfc_queue")

I applied the following fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 20 Mar 2019 11:44:21 +1100
Subject: [PATCH] scsi: lpfc: remove inappropriate inline

Fixes: 9afbee3d62a4 ("scsi: lpfc: Reduce memory footprint for lpfc_queue")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/lpfc/lpfc_sli4.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli4.h b/drivers/scsi/lpfc/lpfc_sli4.h
index bd5b5c3de35e..6670c6e7e28d 100644
--- a/drivers/scsi/lpfc/lpfc_sli4.h
+++ b/drivers/scsi/lpfc/lpfc_sli4.h
@@ -1080,4 +1080,4 @@ int lpfc_sli4_post_status_check(struct lpfc_hba *);
 uint8_t lpfc_sli_config_mbox_subsys_get(struct lpfc_hba *, LPFC_MBOXQ_t *);
 uint8_t lpfc_sli_config_mbox_opcode_get(struct lpfc_hba *, LPFC_MBOXQ_t *);
 void lpfc_sli4_ras_dma_free(struct lpfc_hba *phba);
-inline void *lpfc_sli4_qe(struct lpfc_queue *, uint16_t);
+void *lpfc_sli4_qe(struct lpfc_queue *, uint16_t);
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

Hi James,

After merging the scsi tree, today's linux-next build (sparc defconfig)
failed like this:

drivers/scsi/qlogicpti.c:1285:27: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .eh_host_reset_handler = qlogicpti_reset,
                           ^

Caused by commit

  af167bc42d86 ("scsi: qlogicpti: move bus reset to host reset")

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/uapi/linux/stddef.h:1:0,
                 from include/linux/stddef.h:4,
                 from include/uapi/linux/posix_types.h:4,
                 from include/uapi/linux/types.h:13,
                 from include/linux/types.h:5,
                 from include/linux/list.h:4,
                 from include/linux/module.h:9,
                 from drivers/scsi/mpt3sas/mpt3sas_scsih.c:45:
drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:28: error: 'struct request' has no member named 'cmd_type'
  if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
                            ^
include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
 # define unlikely(x) __builtin_expect(!!(x), 0)
                                          ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:42: error: 'REQ_TYPE_FS' undeclared (first use in this function)
  if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
                                          ^
include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
 # define unlikely(x) __builtin_expect(!!(x), 0)
                                          ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:42: note: each undeclared identifier is reported only once for each function it appears in
  if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
                                          ^
include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
 # define unlikely(x) __builtin_expect(!!(x), 0)
                                          ^

Caused by commit

  f2e767bb5d6e ("scsi: mpt3sas: Force request partial completion alignment")

interacting with commit

  aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")

from the block tree.

I have applied teh following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 6 Feb 2017 16:00:54 +1100
Subject: [PATCH] scsi: mpt3sas: fix up for "block: fold cmd_type into the
 REQ_OP_ space"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 5f7b0c7d7e4d..81a64678390d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -4747,7 +4747,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
 	 * then scsi-ml does not need to handle this misbehavior.
 	 */
 	sector_sz = scmd->device->sector_size;
-	if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
+	if (unlikely(!blk_rq_is_passthrough(scmd->request) && sector_sz &&
 		     xfer_cnt % sector_sz)) {
 		sdev_printk(KERN_INFO, scmd->device,
 		    "unaligned partial completion avoided (xfer_cnt=%u, sector_sz=%u)\n",
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the scsi tree

[Stephen Rothwell]

Hi all,

On Mon, 6 Feb 2017 16:04:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/uapi/linux/stddef.h:1:0,
>                  from include/linux/stddef.h:4,
>                  from include/uapi/linux/posix_types.h:4,
>                  from include/uapi/linux/types.h:13,
>                  from include/linux/types.h:5,
>                  from include/linux/list.h:4,
>                  from include/linux/module.h:9,
>                  from drivers/scsi/mpt3sas/mpt3sas_scsih.c:45:
> drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:28: error: 'struct request' has no member named 'cmd_type'
>   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
>                             ^
> include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
>  # define unlikely(x) __builtin_expect(!!(x), 0)
>                                           ^
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:42: error: 'REQ_TYPE_FS' undeclared (first use in this function)
>   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
>                                           ^
> include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
>  # define unlikely(x) __builtin_expect(!!(x), 0)
>                                           ^
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:42: note: each undeclared identifier is reported only once for each function it appears in
>   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
>                                           ^
> include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
>  # define unlikely(x) __builtin_expect(!!(x), 0)
>                                           ^
> 
> Caused by commit
> 
>   f2e767bb5d6e ("scsi: mpt3sas: Force request partial completion alignment")
> 
> interacting with commit
> 
>   aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")
> 
> from the block tree.
> 
> I have applied teh following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 6 Feb 2017 16:00:54 +1100
> Subject: [PATCH] scsi: mpt3sas: fix up for "block: fold cmd_type into the
>  REQ_OP_ space"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 5f7b0c7d7e4d..81a64678390d 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -4747,7 +4747,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
>  	 * then scsi-ml does not need to handle this misbehavior.
>  	 */
>  	sector_sz = scmd->device->sector_size;
> -	if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
> +	if (unlikely(!blk_rq_is_passthrough(scmd->request) && sector_sz &&
>  		     xfer_cnt % sector_sz)) {
>  		sdev_printk(KERN_INFO, scmd->device,
>  		    "unaligned partial completion avoided (xfer_cnt=%u, sector_sz=%u)\n",
> -- 
> 2.10.2

The scsi tree commit has been merged into Linus' tree, so this
interaction occurs between tyhe block tree and Linus' tree, now.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the scsi tree

[Jens Axboe]

On 02/12/2017 05:32 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 6 Feb 2017 16:04:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the scsi tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> In file included from include/uapi/linux/stddef.h:1:0,
>>                  from include/linux/stddef.h:4,
>>                  from include/uapi/linux/posix_types.h:4,
>>                  from include/uapi/linux/types.h:13,
>>                  from include/linux/types.h:5,
>>                  from include/linux/list.h:4,
>>                  from include/linux/module.h:9,
>>                  from drivers/scsi/mpt3sas/mpt3sas_scsih.c:45:
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:28: error: 'struct request' has no member named 'cmd_type'
>>   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
>>                             ^
>> include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
>>  # define unlikely(x) __builtin_expect(!!(x), 0)
>>                                           ^
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:42: error: 'REQ_TYPE_FS' undeclared (first use in this function)
>>   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
>>                                           ^
>> include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
>>  # define unlikely(x) __builtin_expect(!!(x), 0)
>>                                           ^
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4750:42: note: each undeclared identifier is reported only once for each function it appears in
>>   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
>>                                           ^
>> include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
>>  # define unlikely(x) __builtin_expect(!!(x), 0)
>>                                           ^
>>
>> Caused by commit
>>
>>   f2e767bb5d6e ("scsi: mpt3sas: Force request partial completion alignment")
>>
>> interacting with commit
>>
>>   aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")
>>
>> from the block tree.
>>
>> I have applied teh following merge fix patch:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Mon, 6 Feb 2017 16:00:54 +1100
>> Subject: [PATCH] scsi: mpt3sas: fix up for "block: fold cmd_type into the
>>  REQ_OP_ space"
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> index 5f7b0c7d7e4d..81a64678390d 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> @@ -4747,7 +4747,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
>>  	 * then scsi-ml does not need to handle this misbehavior.
>>  	 */
>>  	sector_sz = scmd->device->sector_size;
>> -	if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
>> +	if (unlikely(!blk_rq_is_passthrough(scmd->request) && sector_sz &&
>>  		     xfer_cnt % sector_sz)) {
>>  		sdev_printk(KERN_INFO, scmd->device,
>>  		    "unaligned partial completion avoided (xfer_cnt=%u, sector_sz=%u)\n",
>> -- 
>> 2.10.2
> 
> The scsi tree commit has been merged into Linus' tree, so this
> interaction occurs between tyhe block tree and Linus' tree, now.

Thanks Stephen, I'll prepare a merged tree as well for Linus, so we
don't lose this when the block tree is merged for 4.11.

-- 
Jens Axboe

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

[Stephen Rothwell]

Hi James,

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

drivers/scsi/qedi/qedi_main.c: In function 'qedi_init':
drivers/scsi/qedi/qedi_main.c:2073:2: error: implicit declaration of function 'register_hotcpu_notifier' [-Werror=implicit-function-declaration]
  register_hotcpu_notifier(&qedi_cpu_notifier);
  ^
drivers/scsi/qedi/qedi_main.c: In function 'qedi_cleanup':
drivers/scsi/qedi/qedi_main.c:2113:2: error: implicit declaration of function 'unregister_hotcpu_notifier' [-Werror=implicit-function-declaration]
  unregister_hotcpu_notifier(&qedi_cpu_notifier);
  ^

Caused by commit

  ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.")

Interacting with commit

  8e38db753d95 ("cpu/hotplug: Remove obsolete cpu hotplug register/unregister functions")

from the tip tree.

I have disabled that driver for now:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 Dec 2016 11:39:41 +1100
Subject: [PATCH] scsi: disable the QEDI driver for now

until it can be converted to cope with the removal of
register_hotcpu_notifier.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/qedi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/qedi/Kconfig b/drivers/scsi/qedi/Kconfig
index 23ca8a274586..8261f0abd807 100644
--- a/drivers/scsi/qedi/Kconfig
+++ b/drivers/scsi/qedi/Kconfig
@@ -2,6 +2,7 @@ config QEDI
 	tristate "QLogic QEDI 25/40/100Gb iSCSI Initiator Driver Support"
 	depends on PCI && SCSI
 	depends on QED
+	depends on BROKEN
 	select SCSI_ISCSI_ATTRS
 	select QED_LL2
 	select QED_ISCSI
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2016-12-23 at 11:45 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/scsi/qedi/qedi_main.c: In function 'qedi_init':
> drivers/scsi/qedi/qedi_main.c:2073:2: error: implicit declaration of
> function 'register_hotcpu_notifier' [-Werror=implicit-function
> -declaration]
>   register_hotcpu_notifier(&qedi_cpu_notifier);
>   ^
> drivers/scsi/qedi/qedi_main.c: In function 'qedi_cleanup':
> drivers/scsi/qedi/qedi_main.c:2113:2: error: implicit declaration of
> function 'unregister_hotcpu_notifier' [-Werror=implicit-function
> -declaration]
>   unregister_hotcpu_notifier(&qedi_cpu_notifier);
>   ^
> 
> Caused by commit
> 
>   ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver
> framework.")
> 
> Interacting with commit
> 
>   8e38db753d95 ("cpu/hotplug: Remove obsolete cpu hotplug
> register/unregister functions")
> 
> from the tip tree.

Well, that's a bit of a problem given that the SCSI tree has a pending
pull request including this driver.

Thomas, can you do another fixup in your tip tree like you did for the
two BNX2* drivers?

Thanks,

James

Re: linux-next: build failure after merge of the scsi tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi All,
> 
> On Thu, 22 Dec 2016 16:56:34 -0800 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >
> > On Fri, 2016-12-23 at 11:45 +1100, Stephen Rothwell wrote:
> > > Hi James,
> > > 
> > > After merging the scsi tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > drivers/scsi/qedi/qedi_main.c: In function 'qedi_init':
> > > drivers/scsi/qedi/qedi_main.c:2073:2: error: implicit declaration of
> > > function 'register_hotcpu_notifier' [-Werror=implicit-function
> > > -declaration]
> > >   register_hotcpu_notifier(&qedi_cpu_notifier);
> > >   ^
> > > drivers/scsi/qedi/qedi_main.c: In function 'qedi_cleanup':
> > > drivers/scsi/qedi/qedi_main.c:2113:2: error: implicit declaration of
> > > function 'unregister_hotcpu_notifier' [-Werror=implicit-function
> > > -declaration]
> > >   unregister_hotcpu_notifier(&qedi_cpu_notifier);
> > >   ^
> > > 
> > > Caused by commit
> > > 
> > >   ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver
> > > framework.")
> > > 
> > > Interacting with commit
> > > 
> > >   8e38db753d95 ("cpu/hotplug: Remove obsolete cpu hotplug
> > > register/unregister functions")
> > > 
> > > from the tip tree.  
> > 
> > Well, that's a bit of a problem given that the SCSI tree has a pending
> > pull request including this driver.
> > 
> > Thomas, can you do another fixup in your tip tree like you did for the
> > two BNX2* drivers?
> 
> OK, so this is now a problem for the tip tree merge since James tree
> has been pulled by Linus.

Yeah, we'll handle it - that's why the final chunk of changes were left to after 
-rc1, to not cause such merge conflicts upstream.

For now I've excluded the relevant -tip side commits from the linux-next branch.

Thanks,

	Ingo

Re: linux-next: build failure after merge of the scsi tree

[Stephen Rothwell]

Hi Ingo,

On Sat, 24 Dec 2016 11:15:08 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> Yeah, we'll handle it - that's why the final chunk of changes were left to after 
> -rc1, to not cause such merge conflicts upstream.

Excellent, thanks.

> For now I've excluded the relevant -tip side commits from the linux-next branch.

Well, there probably won't be any linux-next releases until Jan 3, so that's ok.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the scsi tree

[Thomas Gleixner]

On Sat, 24 Dec 2016, Stephen Rothwell wrote:
> On Thu, 22 Dec 2016 16:56:34 -0800 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >
> > On Fri, 2016-12-23 at 11:45 +1100, Stephen Rothwell wrote:
> > > Hi James,
> > > 
> > > After merging the scsi tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > drivers/scsi/qedi/qedi_main.c: In function 'qedi_init':
> > > drivers/scsi/qedi/qedi_main.c:2073:2: error: implicit declaration of
> > > function 'register_hotcpu_notifier' [-Werror=implicit-function
> > > -declaration]
> > >   register_hotcpu_notifier(&qedi_cpu_notifier);
> > >   ^
> > > drivers/scsi/qedi/qedi_main.c: In function 'qedi_cleanup':
> > > drivers/scsi/qedi/qedi_main.c:2113:2: error: implicit declaration of
> > > function 'unregister_hotcpu_notifier' [-Werror=implicit-function
> > > -declaration]
> > >   unregister_hotcpu_notifier(&qedi_cpu_notifier);
> > >   ^
> > > 
> > > Caused by commit
> > > 
> > >   ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver
> > > framework.")
> > > 
> > > Interacting with commit
> > > 
> > >   8e38db753d95 ("cpu/hotplug: Remove obsolete cpu hotplug
> > > register/unregister functions")
> > > 
> > > from the tip tree.  
> > 
> > Well, that's a bit of a problem given that the SCSI tree has a pending
> > pull request including this driver.
> > 
> > Thomas, can you do another fixup in your tip tree like you did for the
> > two BNX2* drivers?
> 
> OK, so this is now a problem for the tip tree merge since James tree
> has been pulled by Linus.

Sure, because SSCI people merge broken crap and I can wipe up the mess they
create.

Dammit, SCSI folks knew for a long time that the old interface goes away,
but just waving crap through and let other people deal with the outcome is
way simpler.

And of course that hotplug code in this new driver is broken as hell. It
leaks notifiers in cases of errors and is racy against cpu hotplug. The
proper thing would be to mark this trainwreck broken and be done with it.

I'm seriously pissed off as I now have to rebase my stuff and cleanup that
sad affair in order to not break bisects completely.

Yours grumpy,

	tglx

.

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Sat, 2016-12-24 at 12:46 +0100, Thomas Gleixner wrote:
> On Sat, 24 Dec 2016, Stephen Rothwell wrote:
> > On Thu, 22 Dec 2016 16:56:34 -0800 James Bottomley <
> > James.Bottomley@HansenPartnership.com> wrote:
> > > 
> > > On Fri, 2016-12-23 at 11:45 +1100, Stephen Rothwell wrote:
> > > > Hi James,
> > > > 
> > > > After merging the scsi tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > drivers/scsi/qedi/qedi_main.c: In function 'qedi_init':
> > > > drivers/scsi/qedi/qedi_main.c:2073:2: error: implicit
> > > > declaration of
> > > > function 'register_hotcpu_notifier' [-Werror=implicit-function
> > > > -declaration]
> > > >   register_hotcpu_notifier(&qedi_cpu_notifier);
> > > >   ^
> > > > drivers/scsi/qedi/qedi_main.c: In function 'qedi_cleanup':
> > > > drivers/scsi/qedi/qedi_main.c:2113:2: error: implicit
> > > > declaration of
> > > > function 'unregister_hotcpu_notifier' [-Werror=implicit
> > > > -function
> > > > -declaration]
> > > >   unregister_hotcpu_notifier(&qedi_cpu_notifier);
> > > >   ^
> > > > 
> > > > Caused by commit
> > > > 
> > > >   ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI
> > > > driver
> > > > framework.")
> > > > 
> > > > Interacting with commit
> > > > 
> > > >   8e38db753d95 ("cpu/hotplug: Remove obsolete cpu hotplug
> > > > register/unregister functions")
> > > > 
> > > > from the tip tree.  
> > > 
> > > Well, that's a bit of a problem given that the SCSI tree has a 
> > > pending pull request including this driver.
> > > 
> > > Thomas, can you do another fixup in your tip tree like you did 
> > > for the two BNX2* drivers?
> > 
> > OK, so this is now a problem for the tip tree merge since James 
> > tree has been pulled by Linus.
> 
> Sure, because SSCI people merge broken crap and I can wipe up the 
> mess they create.

Well, the driver was reviewed, but I don't think biting the heads of
the reviewers would help.

> Dammit, SCSI folks knew for a long time that the old interface goes
> away, but just waving crap through and let other people deal with the
> outcome is way simpler.

So this is the problem: I don't think this was actually communicated
this in a meaningful way; I think that's because we don't really have a
functional process for deprecating stuff.  Saying "this is broken or
deprecated" doesn't work because people don't necessarily see it and
even if they do, they often forget.  Putting it in some document
doesn't work either because we can't agree which one (and even if we
could, I bet the reviewers won't always consult it).

So here's the thing: if you want me to notice that a driver is using a
deprecated API, the API must be *marked* as deprecated so that I get a
build warning to investigate.  Absent that, I'm going to assume the
reviewers knew what they were talking about ... and likely a build
warning is the only way they'd know as well.

> And of course that hotplug code in this new driver is broken as hell. 
> It leaks notifiers in cases of errors and is racy against cpu 
> hotplug. The proper thing would be to mark this trainwreck broken and 
> be done with it.
> 
> I'm seriously pissed off as I now have to rebase my stuff and cleanup 
> that sad affair in order to not break bisects completely.

Well, I'm sorry, but it's a timing thing.  I could have removed this
driver from the pull it if I'd got the next failure before it was in
-flight.  I did incubate this final pull tree in next for a week which
was supposed to catch all the issues like this.

James

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

[Stephen Rothwell]

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
drivers/scsi/mpt3sas/mpt3sas_base.h:1414:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_get': function body not available
 mpt3sas_scsi_direct_io_get(struct MPT3SAS_ADAPTER *ioc, u16 smid);
 ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4448:6: error: called from here
  if (mpt3sas_scsi_direct_io_get(ioc, smid) &&
      ^
In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
 mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
 ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
   mpt3sas_scsi_direct_io_set(ioc, smid, 0);
   ^
In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:5
9:0:
drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
 mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
 ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
   mpt3sas_scsi_direct_io_set(ioc, smid, 0);
   ^

Presumably caused by commit

  c84b06a48c4d ("mpt3sas: Single driver module which supports both SAS 2.0 & SAS 3.0 HBAs")

I applied the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Nov 2015 12:31:09 +1100
Subject: [PATCH] mpt3sas: fix inline markers on non inline function
 declarations

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h
index a17bea95b0c5..5ad271efbd45 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -1410,9 +1410,9 @@ void mpt3sas_trigger_mpi(struct MPT3SAS_ADAPTER *ioc, u16 ioc_status,
 u8 mpt3sas_get_num_volumes(struct MPT3SAS_ADAPTER *ioc);
 void mpt3sas_init_warpdrive_properties(struct MPT3SAS_ADAPTER *ioc,
 	struct _raid_device *raid_device);
-inline u8
+u8
 mpt3sas_scsi_direct_io_get(struct MPT3SAS_ADAPTER *ioc, u16 smid);
-inline void
+void
 mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
 void
 mpt3sas_setup_direct_io(struct MPT3SAS_ADAPTER *ioc, struct scsi_cmnd *scmd,
-- 
2.6.2

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

Re: linux-next: build failure after merge of the scsi tree

[Sreekanth Reddy]

Thanks Stephen.

Please consider this patch as Ack-by: Sreekanth Reddy
<sreekanth.reddy@avagotech.com>

Thanks,
Sreekanth

On Fri, Nov 13, 2015 at 7:05 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi James,
>
> After merging the scsi tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
> drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
> drivers/scsi/mpt3sas/mpt3sas_base.h:1414:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_get': function body not available
>  mpt3sas_scsi_direct_io_get(struct MPT3SAS_ADAPTER *ioc, u16 smid);
>  ^
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4448:6: error: called from here
>   if (mpt3sas_scsi_direct_io_get(ioc, smid) &&
>       ^
> In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
> drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
>  mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
>  ^
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
>    mpt3sas_scsi_direct_io_set(ioc, smid, 0);
>    ^
> In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:5
> 9:0:
> drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
>  mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
>  ^
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
>    mpt3sas_scsi_direct_io_set(ioc, smid, 0);
>    ^
>
> Presumably caused by commit
>
>   c84b06a48c4d ("mpt3sas: Single driver module which supports both SAS 2.0 & SAS 3.0 HBAs")
>
> I applied the following fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Nov 2015 12:31:09 +1100
> Subject: [PATCH] mpt3sas: fix inline markers on non inline function
>  declarations
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index a17bea95b0c5..5ad271efbd45 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -1410,9 +1410,9 @@ void mpt3sas_trigger_mpi(struct MPT3SAS_ADAPTER *ioc, u16 ioc_status,
>  u8 mpt3sas_get_num_volumes(struct MPT3SAS_ADAPTER *ioc);
>  void mpt3sas_init_warpdrive_properties(struct MPT3SAS_ADAPTER *ioc,
>         struct _raid_device *raid_device);
> -inline u8
> +u8
>  mpt3sas_scsi_direct_io_get(struct MPT3SAS_ADAPTER *ioc, u16 smid);
> -inline void
> +void
>  mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
>  void
>  mpt3sas_setup_direct_io(struct MPT3SAS_ADAPTER *ioc, struct scsi_cmnd *scmd,
> --
> 2.6.2
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

[Stephen Rothwell]

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

Hi James,

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

drivers/usb/gadget/function/f_mass_storage.c:280:12: error: 'MAX_COMMAND_SIZE' undeclared here (not in a function)
  u8   cmnd[MAX_COMMAND_SIZE];
            ^

Caused by commit 0e640c799103 ("Replace MAX_COMMAND_SIZE with BLK_MAX_CDB").

I have used the scsi tree from next-20150601 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Tue, 2015-06-02 at 18:06 +1000, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/usb/gadget/function/f_mass_storage.c:280:12: error: 'MAX_COMMAND_SIZE' undeclared here (not in a function)
>   u8   cmnd[MAX_COMMAND_SIZE];
>             ^
> 
> Caused by commit 0e640c799103 ("Replace MAX_COMMAND_SIZE with BLK_MAX_CDB").
> 
> I have used the scsi tree from next-20150601 for today.

Hm, yes, the commit causes a dependency on blkdev.h but doesn't pull it
in.  I'll drop it for a resubmit.

James

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/scsi_logging.c: In function 'sdev_prefix_printk':
drivers/scsi/scsi_logging.c:119:6: error: void value not ignored as it ought to be
  ret = dev_printk(level, &sdev->sdev_gendev, "%s", logbuf);
      ^
drivers/scsi/scsi_logging.c: In function 'scmd_printk':
drivers/scsi/scsi_logging.c:146:6: error: void value not ignored as it ought to be
  ret = dev_printk(level, &scmd->device->sdev_gendev, "%s", logbuf);
      ^

Caused by commit ded85c193a39 ("scsi: Implement per-cpu logging
buffer") interacting with commit d1f1052c5204 ("device: Change
dev_<level> logging functions to return void") from the driver-core
tree.

I added the following merge resolution patch.  Someone will have to
remember to tell Linus.  Also, the void return may be able to be
propagated further up the chain since these two new affected functions
now always return 0.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 4 Feb 2015 17:18:08 +1100
Subject: [PATCH] scsi: merge resolution for dev_printk API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/scsi_logging.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/scsi_logging.c b/drivers/scsi/scsi_logging.c
index ecc5918e372a..0810e92874d2 100644
--- a/drivers/scsi/scsi_logging.c
+++ b/drivers/scsi/scsi_logging.c
@@ -99,7 +99,6 @@ int sdev_prefix_printk(const char *level, const struct scsi_device *sdev,
 	va_list args;
 	char *logbuf;
 	size_t off = 0, logbuf_len;
-	int ret;
 
 	if (!sdev)
 		return 0;
@@ -116,9 +115,9 @@ int sdev_prefix_printk(const char *level, const struct scsi_device *sdev,
 		off += vscnprintf(logbuf + off, logbuf_len - off, fmt, args);
 		va_end(args);
 	}
-	ret = dev_printk(level, &sdev->sdev_gendev, "%s", logbuf);
+	dev_printk(level, &sdev->sdev_gendev, "%s", logbuf);
 	scsi_log_release_buffer(logbuf);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(sdev_prefix_printk);
 
@@ -128,7 +127,6 @@ int scmd_printk(const char *level, const struct scsi_cmnd *scmd,
 	va_list args;
 	char *logbuf;
 	size_t off = 0, logbuf_len;
-	int ret;
 
 	if (!scmd || !scmd->cmnd)
 		return 0;
@@ -143,9 +141,9 @@ int scmd_printk(const char *level, const struct scsi_cmnd *scmd,
 		off += vscnprintf(logbuf + off, logbuf_len - off, fmt, args);
 		va_end(args);
 	}
-	ret = dev_printk(level, &scmd->device->sdev_gendev, "%s", logbuf);
+	dev_printk(level, &scmd->device->sdev_gendev, "%s", logbuf);
 	scsi_log_release_buffer(logbuf);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(scmd_printk);
 
-- 
2.1.4

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

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

Re: linux-next: build failure after merge of the scsi tree

[Joe Perches]

(adding Christoph Hellwig)

On Wed, 2015-02-04 at 17:29 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/scsi_logging.c: In function 'sdev_prefix_printk':
> drivers/scsi/scsi_logging.c:119:6: error: void value not ignored as it ought to be
>   ret = dev_printk(level, &sdev->sdev_gendev, "%s", logbuf);
>       ^
> drivers/scsi/scsi_logging.c: In function 'scmd_printk':
> drivers/scsi/scsi_logging.c:146:6: error: void value not ignored as it ought to be
>   ret = dev_printk(level, &scmd->device->sdev_gendev, "%s", logbuf);
>       ^
> 
> Caused by commit ded85c193a39 ("scsi: Implement per-cpu logging
> buffer") interacting with commit d1f1052c5204 ("device: Change
> dev_<level> logging functions to return void") from the driver-core
> tree.
> 
> I added the following merge resolution patch.  Someone will have to
> remember to tell Linus.  Also, the void return may be able to be
> propagated further up the chain since these two new affected functions
> now always return 0.

Thanks and just so.

It seems that nothing uses either return value,
so it's probably better to use void for both
sdev_prefix_printk and scmd_printk.

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Wed, 2015-02-04 at 17:29 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/scsi_logging.c: In function 'sdev_prefix_printk':
> drivers/scsi/scsi_logging.c:119:6: error: void value not ignored as it ought to be
>   ret = dev_printk(level, &sdev->sdev_gendev, "%s", logbuf);
>       ^
> drivers/scsi/scsi_logging.c: In function 'scmd_printk':
> drivers/scsi/scsi_logging.c:146:6: error: void value not ignored as it ought to be
>   ret = dev_printk(level, &scmd->device->sdev_gendev, "%s", logbuf);
>       ^
> 
> Caused by commit ded85c193a39 ("scsi: Implement per-cpu logging
> buffer") interacting with commit d1f1052c5204 ("device: Change
> dev_<level> logging functions to return void") from the driver-core
> tree.
> 
> I added the following merge resolution patch.  Someone will have to
> remember to tell Linus.  Also, the void return may be able to be
> propagated further up the chain since these two new affected functions
> now always return 0.

Hannes posted a more correct fix for it today to the scsi list.
However, sorting this out isn't just about the short term fix:  We can't
afford the bisection failure of SCSI not building over a wide range of
commits, so our tree will need to be pulled ahead of the driver-core
tree.

I've got to say, while it's great that linux-next spotted this ahead of
time (saves us all a massive beating from Linus, thanks Stephen) it's
unfortunate to have this type of thing turn up on the edge of a merge
window, especially caused by a trivial commit which perhaps shouldn't
have gone in so late.

James

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/cxgbi/cxgb4i/cxgb4i.c: In function 'do_abort_req_rss':
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:942:3: error: too many arguments to function 'send_tx_flowc_wr'
   send_tx_flowc_wr(csk, 0);
   ^
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:492:20: note: declared here
 static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
                    ^

Caused by commit 4be50d4f7649 ("cxgb4i: send abort_rpl correctly").

I have used the scsi tree from next-20141106 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

RE: linux-next: build failure after merge of the scsi tree

[Anish Bhatt]

Fix for this was sent out on thursday itself, but does not seem to be applied yet :
http://marc.info/?l=linux-scsi&m=141529629911520&w=2
________________________________________
From: Stephen Rothwell [sfr@canb.auug.org.au]
Sent: Sunday, November 09, 2014 10:15 PM
To: James Bottomley
Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; Christoph Hellwig; Karen Xie
Subject: linux-next: build failure after merge of the scsi tree

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/cxgbi/cxgb4i/cxgb4i.c: In function 'do_abort_req_rss':
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:942:3: error: too many arguments to function 'send_tx_flowc_wr'
   send_tx_flowc_wr(csk, 0);
   ^
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:492:20: note: declared here
 static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
                    ^

Caused by commit 4be50d4f7649 ("cxgb4i: send abort_rpl correctly").

I have used the scsi tree from next-20141106 for today.
--
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

Re: linux-next: build failure after merge of the scsi tree

[Christoph Hellwig]

On Mon, Nov 10, 2014 at 06:27:13AM +0000, Anish Bhatt wrote:
> Fix for this was sent out on thursday itself, but does not seem to be applied yet :
> http://marc.info/?l=linux-scsi&m=141529629911520&w=2

And I pulled it from drivers-for-3.18 early on Thursday, but that didn't
propagate to James' tree it seems.  I'll do another range of patch merging
these afternoon and will add the proper version.

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Mon, 2014-11-10 at 14:46 +0100, Christoph Hellwig wrote:
> On Mon, Nov 10, 2014 at 06:27:13AM +0000, Anish Bhatt wrote:
> > Fix for this was sent out on thursday itself, but does not seem to be applied yet :
> > http://marc.info/?l=linux-scsi&m=141529629911520&w=2
> 
> And I pulled it from drivers-for-3.18 early on Thursday, but that didn't
> propagate to James' tree it seems.  I'll do another range of patch merging
> these afternoon and will add the proper version.

so that's adding the 3.18-incoming trees?

James

Re: linux-next: build failure after merge of the scsi tree

[Christoph Hellwig]

On Mon, Nov 10, 2014 at 07:21:30AM -0800, James Bottomley wrote:
> so that's adding the 3.18-incoming trees?

Not yet.  Those are for the buildbolt to find any issues before pushing
it to the actual for-3.x branch.  It's a trick I picked up from the nfsd tree.

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Mon, 2014-11-10 at 16:48 +0100, Christoph Hellwig wrote:
> On Mon, Nov 10, 2014 at 07:21:30AM -0800, James Bottomley wrote:
> > so that's adding the 3.18-incoming trees?
> 
> Not yet.  Those are for the buildbolt to find any issues before pushing
> it to the actual for-3.x branch.  It's a trick I picked up from the nfsd tree.

So your idea is Fenguang first then linux-next.

OK.

James

Re: linux-next: build failure after merge of the scsi tree

[Christoph Hellwig]

On Mon, Nov 10, 2014 at 07:50:16AM -0800, James Bottomley wrote:
> So your idea is Fenguang first then linux-next.

Exactly.

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/linux/sched.h:17:0,
                 from include/linux/blkdev.h:4,
                 from drivers/scsi/constants.c:10:
drivers/scsi/constants.c: In function 'scsi_opcode_sa_name':
include/linux/kernel.h:54:32: error: invalid application of 'sizeof' to incomplete type 'const char *[]'
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                ^
drivers/scsi/constants.c:300:15: note: in expansion of macro 'ARRAY_SIZE'
  if (opcode < ARRAY_SIZE(cdb_byte0_names))
               ^

Caused by 94bafab0008c ("scsi: consolidate opcode lookup in
scsi_opcode_sa_name()").  This build does not have
CONFIG_SCSI_CONSTANTS set.

I have used the scsi tree from next-20141031 again (since yesterday's
tree had a different build problem).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

Re: linux-next: build failure after merge of the scsi tree

[Hannes Reinecke]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2014 05:43 AM, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (arm 
> multi_v7_defconfig) failed like this:
> 
> In file included from include/linux/sched.h:17:0, from
> include/linux/blkdev.h:4, from drivers/scsi/constants.c:10: 
> drivers/scsi/constants.c: In function 'scsi_opcode_sa_name': 
> include/linux/kernel.h:54:32: error: invalid application of
> 'sizeof' to incomplete type 'const char *[]' #define
> ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr)) ^ drivers/scsi/constants.c:300:15: note:
> in expansion of macro 'ARRAY_SIZE' if (opcode <
> ARRAY_SIZE(cdb_byte0_names)) ^
> 
> Caused by 94bafab0008c ("scsi: consolidate opcode lookup in 
> scsi_opcode_sa_name()").  This build does not have 
> CONFIG_SCSI_CONSTANTS set.
> 
> I have used the scsi tree from next-20141031 again (since
> yesterday's tree had a different build problem).
> 
Sorry. Here's the patch.

Cheers,

Hannes
- -- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJUWHtHAAoJEGz4yi9OyKjPfdgP+wZweCbK1HJ7PBz8CCqT6n6d
HDOv0oX4Ia3Oo53NhdIAD9745sCWWegSBYZf7C/gTXVtmBxJ30NnuI+Cg0otaTHA
DPJZ26mBCNijYvpVGqgcSkXRdQQMiBGo6TLmsdpXxn4NFuh3IoRS+8gMgEFxpQdK
aAsHnRBTbfaeYpuNR2P5IJVc1L89rg3DkLWMw3ybSO5WzAcjg4yDiasCsGNHq/T4
e9t+V7/+YA14UOMAHfsAnD/B7UI/7B0ealDbepr/cq1NdJ1F0G7JoCS0yAExRumv
3KBznE29YMZTXCqJg6DNQqkV1xmuB2l2/eAZrM/pHTHGWBQk27WI/KsmqISt9Vb+
vmowDuJQNwZG784KSmbRcjSnuNTIltUybhgF/r+m3dNq4j+H/SroBIi5xI+5HJR+
m7G0tjQkpI3Hie3kf9Egwj09goMZ5ka8tIETMqgJFa2AZ3VpnBekxXGe1OtFgfeo
3nOCnYNNADUSIFUmGmAUusPlgFyMGoWvTHs+koYN8cS+q+X9WJgI3mihnMuiVIux
jG2W7IDCimiss/g0Bnol7M7FdL4QMVeg9/LX5wIl2G1b9Nz4ZDCSI/ooHL+xMFrm
H1wwBF9/xjpc0J6RWimkSvFa4iRCti4Ac8w41l+APwEtH2mWdrefTaadV0JXH/wh
brJGtCQhTrCLGuyLluPx
=xaoW
-----END PGP SIGNATURE-----

[-- Attachment #2: 0001-scsi-Fixup-compilation-warning-when-SCSI_CONSTANTS-i.patch --]
[-- Type: text/x-patch, Size: 863 bytes --]

>From 355eac426aea2e1f98b99a41707b37e9ba3ef02b Mon Sep 17 00:00:00 2001
From: Hannes Reinecke <hare@suse.de>
Date: Tue, 4 Nov 2014 08:06:03 +0100
Subject: [PATCH] scsi: Fixup compilation warning when SCSI_CONSTANTS is not
 set

ARRAY_SIZE() requires the array to actually have a size.

Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/scsi/constants.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index b3cbf3a..a1a7fca 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -267,7 +267,7 @@ static struct sa_name_list sa_names_arr[] = {
 };
 
 #else /* ifndef CONFIG_SCSI_CONSTANTS */
-static const char *cdb_byte0_names[];
+static const char *cdb_byte0_names[0];
 
 static struct sa_name_list sa_names_arr[] = {
 	{VARIABLE_LENGTH_CMD, NULL, 0},
-- 
1.8.5.2

Re: linux-next: build failure after merge of the scsi tree

[Stephen Rothwell]

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

Hi Hannes,

On Tue, 04 Nov 2014 08:07:51 +0100 Hannes Reinecke <hare@suse.de> wrote:
>
> On 11/04/2014 05:43 AM, Stephen Rothwell wrote:
> > 
> > After merging the scsi tree, today's linux-next build (arm 
> > multi_v7_defconfig) failed like this:
> > 
> > In file included from include/linux/sched.h:17:0, from
> > include/linux/blkdev.h:4, from drivers/scsi/constants.c:10: 
> > drivers/scsi/constants.c: In function 'scsi_opcode_sa_name': 
> > include/linux/kernel.h:54:32: error: invalid application of
> > 'sizeof' to incomplete type 'const char *[]' #define
> > ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> > __must_be_array(arr)) ^ drivers/scsi/constants.c:300:15: note:
> > in expansion of macro 'ARRAY_SIZE' if (opcode <
> > ARRAY_SIZE(cdb_byte0_names)) ^
> > 
> > Caused by 94bafab0008c ("scsi: consolidate opcode lookup in 
> > scsi_opcode_sa_name()").  This build does not have 
> > CONFIG_SCSI_CONSTANTS set.
> > 
> > I have used the scsi tree from next-20141031 again (since
> > yesterday's tree had a different build problem).
> > 
> Sorry. Here's the patch.

I applied that patch to linux-next today (pending James adding it to
the scsi tree).

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

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

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc ppc64_defconfig)
failed like this:

drivers/scsi/scsi_lib.c: In function 'scsi_io_completion':
drivers/scsi/scsi_lib.c:1048:5: error: implicit declaration of function 'SCSI_LOG_LEVEL' [-Werror=implicit-function-declaration]
     level = SCSI_LOG_LEVEL(SCSI_LOG_MLCOMPLETE_SHIFT,
     ^

Caused by commit b6568e80be82 ("scsi: simplify
scsi_log_(send|completion)").  SCSI_LOG_LEVEL is defined in
drivers/scsi/scsi_logging.h, but only if CONFIG_SCSI_LOGGING is defined.

I have used the version of the scsi tree from next-20141031 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

Re: linux-next: build failure after merge of the scsi tree

[Hannes Reinecke]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/03/2014 03:52 AM, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/scsi_lib.c: In function 'scsi_io_completion': 
> drivers/scsi/scsi_lib.c:1048:5: error: implicit declaration of
> function 'SCSI_LOG_LEVEL'
> [-Werror=implicit-function-declaration] level =
> SCSI_LOG_LEVEL(SCSI_LOG_MLCOMPLETE_SHIFT, ^
> 
> Caused by commit b6568e80be82 ("scsi: simplify 
> scsi_log_(send|completion)").  SCSI_LOG_LEVEL is defined in 
> drivers/scsi/scsi_logging.h, but only if CONFIG_SCSI_LOGGING is
> defined.
> 
> I have used the version of the scsi tree from next-20141031 for
> today.
> 
Ah, missed that. Here's the patch.

Cheers,

Hannes
- -- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJUVzPtAAoJEGz4yi9OyKjPX/YP/2CmPtJDed4+ckb0gjJ8bdlW
i6F532mihXN1WuFYahFujCmZczF8aPEZrViKp/6BZGaqezhqg7BdoH/dXzsYzWAh
Slwlqu52WIj4Eo0B39dN8uuWRPJXV+jvSRE2NucVVhICYYYghR8YhK3HeY2Mw/g7
M1G82a3Ry0g/NpJePzdLImvWj8QoLhua9p61aias0kJjf3p+JskMV3PK9QbroVp/
QsubWkj2yaSs/j21E77JMMzLaQsRK0SIwDvN7AdGxh+h5e9r+eWJrpfdJscAZ4td
FsPApfQR9fxtG9mDPZigf2Oy3XX++N1TPQN6Y7s1KE78d+XGJFxtXEIf1gmp07Pg
lCQACp2WVA14mA+A5PTN7xYtYwvPgMPez63XnAjFkVVXpSMYilRqSPQs82ruN42w
0GGX293ay2s6o1CcFNk/xJp/l7KomKlQbjdIMCkWVbKb3gpO8ivxThPzJv001SN8
zOF7u9YxATQS5EG0Cja9/aLVrhjg0GWFjtmvs9ToSrSgsFrrLycg7zP+DtfP4uz8
2hsAU9Ss9PlxfgbOIMoH42S0YZe4vo6RJmY25POuSfHQVsn+FTVpxqYErMUnNql6
dPfcQq+YqcfcT4n0rBV8VtzRulU11SzNZBEwbJhML4zUs4DCLteemYCWyp/5F+hw
hmmeOMsJfUW8EiLgoLbf
=nK00
-----END PGP SIGNATURE-----

[-- Attachment #2: 0001-scsi-define-SCSI_LOG_LEVEL.patch --]
[-- Type: text/x-patch, Size: 827 bytes --]

>From e5c943164a981e32d88c7083c84a85ff513bb0ee Mon Sep 17 00:00:00 2001
From: Hannes Reinecke <hare@suse.de>
Date: Mon, 3 Nov 2014 08:03:48 +0100
Subject: [PATCH] scsi: define SCSI_LOG_LEVEL

SCSI_LOG_LEVEL needs to be defined even if CONFIG_SCSI_LOGGING
is not enabled.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/scsi/scsi_logging.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/scsi_logging.h b/drivers/scsi/scsi_logging.h
index 1f65139..7fe64a8 100644
--- a/drivers/scsi/scsi_logging.h
+++ b/drivers/scsi/scsi_logging.h
@@ -51,6 +51,7 @@ do {								\
 		} while (0);					\
 } while (0)
 #else
+#define SCSI_LOG_LEVEL(SHIFT, BITS) 0
 #define SCSI_CHECK_LOGGING(SHIFT, BITS, LEVEL, CMD)
 #endif /* CONFIG_SCSI_LOGGING */
 
-- 
1.8.4.5

Re: linux-next: build failure after merge of the scsi tree

[Christoph Hellwig]

Thanks, I've folded that patch into the one that caused the issue.

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/ipr.c: In function 'ipr_handle_log_data':
drivers/scsi/ipr.c:2468:15: error: 'IPR_IOASC_HW_CMD_FAILED' undeclared (first use in this function)
  if (ioasc == IPR_IOASC_HW_CMD_FAILED &&
               ^

Caused by commit 3185ea63907c ("ipr: don't log error messages when
applications issues illegal requests").  Someone typoed that name in
ipr.h ...

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

Re: linux-next: build failure after merge of the scsi tree

[Christoph Hellwig]

On Fri, Sep 26, 2014 at 06:34:50PM +1000, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/ipr.c: In function 'ipr_handle_log_data':
> drivers/scsi/ipr.c:2468:15: error: 'IPR_IOASC_HW_CMD_FAILED' undeclared (first use in this function)
>   if (ioasc == IPR_IOASC_HW_CMD_FAILED &&
>                ^
> 
> Caused by commit 3185ea63907c ("ipr: don't log error messages when
> applications issues illegal requests").  Someone typoed that name in
> ipr.h ...
> 
> I have reverted that commit for today.

Thanks.  The fix should be here:

http://git.infradead.org/users/hch/scsi-queue.git/commitdiff/d247a70a4d67623eb738176ee703a7bb8b6c325c

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2014-09-26 at 10:36 +0200, Christoph Hellwig wrote:
> On Fri, Sep 26, 2014 at 06:34:50PM +1000, Stephen Rothwell wrote:
> > Hi James,
> > 
> > After merging the scsi tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > drivers/scsi/ipr.c: In function 'ipr_handle_log_data':
> > drivers/scsi/ipr.c:2468:15: error: 'IPR_IOASC_HW_CMD_FAILED' undeclared (first use in this function)
> >   if (ioasc == IPR_IOASC_HW_CMD_FAILED &&
> >                ^
> > 
> > Caused by commit 3185ea63907c ("ipr: don't log error messages when
> > applications issues illegal requests").  Someone typoed that name in
> > ipr.h ...
> > 
> > I have reverted that commit for today.
> 
> Thanks.  The fix should be here:
> 
> http://git.infradead.org/users/hch/scsi-queue.git/commitdiff/d247a70a4d67623eb738176ee703a7bb8b6c325c

OK, Pushed out.

I'll wait for the next couple of build cycles before pushing (assuming
merge window opens on Sunday) just in case more things show up.

James

Re: linux-next: build failure after merge of the scsi tree

[Brian King]

On 09/26/2014 04:57 AM, James Bottomley wrote:
> On Fri, 2014-09-26 at 10:36 +0200, Christoph Hellwig wrote:
>> On Fri, Sep 26, 2014 at 06:34:50PM +1000, Stephen Rothwell wrote:
>>> Hi James,
>>>
>>> After merging the scsi tree, today's linux-next build (powerpc
>>> ppc64_defconfig) failed like this:
>>>
>>> drivers/scsi/ipr.c: In function 'ipr_handle_log_data':
>>> drivers/scsi/ipr.c:2468:15: error: 'IPR_IOASC_HW_CMD_FAILED' undeclared (first use in this function)
>>>   if (ioasc == IPR_IOASC_HW_CMD_FAILED &&
>>>                ^
>>>
>>> Caused by commit 3185ea63907c ("ipr: don't log error messages when
>>> applications issues illegal requests").  Someone typoed that name in
>>> ipr.h ...
>>>
>>> I have reverted that commit for today.
>>
>> Thanks.  The fix should be here:
>>
>> http://git.infradead.org/users/hch/scsi-queue.git/commitdiff/d247a70a4d67623eb738176ee703a7bb8b6c325c
> 
> OK, Pushed out.
> 
> I'll wait for the next couple of build cycles before pushing (assuming
> merge window opens on Sunday) just in case more things show up.

Hi James,

Anything preventing this patch set from getting picked up? Do you need a resend?

http://marc.info/?l=linux-scsi&m=140657929221696&w=2

Thanks,

Brian

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

Re: linux-next: build failure after merge of the scsi tree

[wenxiong]

Quoting James Bottomley <James.Bottomley@hansenpartnership.com>:

> On Fri, 2013-01-11 at 11:35 -0600, Brian King wrote:
>> On 01/11/2013 10:05 AM, Greg KH wrote:
>> > On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
>> >> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
>> >>> It looks like this was a due to the fact that the new patches
>> >>> added __devinit tags in the same merge window the __devinit tag
>> >>> itself was getting removed.
>> >>
>> >> Not exactly.  The patch which makes them nops went into 3.8.  Now
>> >> there's a patch queued in, Gregs tree I presume, to remove them all and
>> >> the #defines which causes the compile failure.
>> >>
>> >>> As to the sparse warnings, this patch fixed the ones that
>> >>> were actual bugs in the new code, although we could have
>> >>> made that more clear in the patch description.
>> >>>
>> >>> http://marc.info/?l=linux-scsi&m=135716576204083&w=2
>> >>
>> >> Ah, thanks ... I've been on holiday for a while, so I did miss that.
>> >>
>> >>> There is one outstanding issue I am aware of which was an
>> >>> array bounds compiler warning which looks to be a misdetection
>> >>> by the compiler. Wendy and I discussed adding a BUG_ON
>> >>> to stop the compiler from complaining.
>> >>>
>> >>> Wendy - lets queue these two changes up ASAP. They should both
>> >>> be very simple changes.
>> >>
>> >> If it's a simple gcc bug, just ignore it.
>> >>
>> >> I do need you to redo the patches to remove the __dev annotations,
>> >> though.  We can't risk introducing a bisect killing compile breakage if
>> >> Greg's tree merges before mine in the next merge window.
>> >
>> > This change should be pushed to Linus in time for 3.8-final, so there
>> > should not be any bisect issues.
>>
>> We can do this either way.
>>
>> James - what is your preference? Drop everything and do a resend of the
>> entire series or delta patches on top of what is currently in your tree?
>
> Drop everything and resend still, I think.  There's still a rebase
> problem, because the merge failure will happen if I rebase the misc tree
> to beyond Greg's merge point and I'd rather not have to worry about it.
>
> Thanks,
>
> James

Hi James, I just re-sent all patches which are against
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git.
This kernel already have Greg's "Drivers: scsi: remove _dev*  
attributes" patch.

Let me know if you have any questions for these patches.

Thanks for for your help!
Wendy

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/ipr.c:9138:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msix'
drivers/scsi/ipr.c:9165:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msi'
drivers/scsi/ipr.c:9188:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'name_msi_vectors'
drivers/scsi/ipr.c:9200:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_request_other_msi_irqs'
drivers/scsi/ipr.c: In function 'ipr_probe_ioa':
drivers/scsi/ipr.c:9422:4: error: implicit declaration of function 'ipr_enable_msix' [-Werror=implicit-function-declaration]
drivers/scsi/ipr.c:9425:4: error: implicit declaration of function 'ipr_enable_msi' [-Werror=implicit-function-declaration]
drivers/scsi/ipr.c:9517:3: error: implicit declaration of function 'name_msi_vectors' [-Werror=implicit-function-declaration]
drivers/scsi/ipr.c:9523:4: error: implicit declaration of function 'ipr_request_other_msi_irqs' [-Werror=implicit-function-declaration]

Caused by commit 7af0de314b73 ("[SCSI] ipr: Add support for MSI-X and
distributed completion") interacting with commit 54b956b90360 ("Remove
__dev* markings from init.h") from the drover-core.current tree.

I have added the following merge fix patch for today which could be added
directly to the scsi tree (please).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 11 Jan 2013 11:59:34 +1100
Subject: [PATCH] [SCSI] ipr: remove new __dev* annotations

CONFIG_HOTPLUG is always true now and the __dev* macros have been removed.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/ipr.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index e1ef0b1..8fe61da 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -9135,7 +9135,7 @@ ipr_get_chip_info(const struct pci_device_id *dev_id)
 	return NULL;
 }
 
-static int __devinit ipr_enable_msix(struct ipr_ioa_cfg *ioa_cfg)
+static int ipr_enable_msix(struct ipr_ioa_cfg *ioa_cfg)
 {
 	struct msix_entry entries[IPR_MAX_MSIX_VECTORS];
 	int i, err, vectors;
@@ -9162,7 +9162,7 @@ static int __devinit ipr_enable_msix(struct ipr_ioa_cfg *ioa_cfg)
 	return err;
 }
 
-static int __devinit ipr_enable_msi(struct ipr_ioa_cfg *ioa_cfg)
+static int ipr_enable_msi(struct ipr_ioa_cfg *ioa_cfg)
 {
 	int i, err, vectors;
 
@@ -9185,7 +9185,7 @@ static int __devinit ipr_enable_msi(struct ipr_ioa_cfg *ioa_cfg)
 	return err;
 }
 
-static void __devinit name_msi_vectors(struct ipr_ioa_cfg *ioa_cfg)
+static void name_msi_vectors(struct ipr_ioa_cfg *ioa_cfg)
 {
 	int vec_idx, n = sizeof(ioa_cfg->vectors_info[0].desc) - 1;
 
@@ -9197,7 +9197,7 @@ static void __devinit name_msi_vectors(struct ipr_ioa_cfg *ioa_cfg)
 	}
 }
 
-static int __devinit ipr_request_other_msi_irqs(struct ipr_ioa_cfg *ioa_cfg)
+static int ipr_request_other_msi_irqs(struct ipr_ioa_cfg *ioa_cfg)
 {
 	int i, rc;
 
-- 
1.7.10.280.gaa39

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

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2013-01-11 at 12:03 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/ipr.c:9138:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msix'
> drivers/scsi/ipr.c:9165:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msi'
> drivers/scsi/ipr.c:9188:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'name_msi_vectors'
> drivers/scsi/ipr.c:9200:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_request_other_msi_irqs'
> drivers/scsi/ipr.c: In function 'ipr_probe_ioa':
> drivers/scsi/ipr.c:9422:4: error: implicit declaration of function 'ipr_enable_msix' [-Werror=implicit-function-declaration]
> drivers/scsi/ipr.c:9425:4: error: implicit declaration of function 'ipr_enable_msi' [-Werror=implicit-function-declaration]
> drivers/scsi/ipr.c:9517:3: error: implicit declaration of function 'name_msi_vectors' [-Werror=implicit-function-declaration]
> drivers/scsi/ipr.c:9523:4: error: implicit declaration of function 'ipr_request_other_msi_irqs' [-Werror=implicit-function-declaration]

OK, fine, I'll drop all the ipr patches.  I've been waiting for a month
for them to fix the smatch and sparse warnings.  Please resend the
series with all the fixes.

Thanks,

James

Re: linux-next: build failure after merge of the scsi tree

[Brian King]

It looks like this was a due to the fact that the new patches
added __devinit tags in the same merge window the __devinit tag
itself was getting removed.

As to the sparse warnings, this patch fixed the ones that
were actual bugs in the new code, although we could have
made that more clear in the patch description.

http://marc.info/?l=linux-scsi&m=135716576204083&w=2

There is one outstanding issue I am aware of which was an
array bounds compiler warning which looks to be a misdetection
by the compiler. Wendy and I discussed adding a BUG_ON
to stop the compiler from complaining.

Wendy - lets queue these two changes up ASAP. They should both
be very simple changes.

Thanks,

Brian


On 01/11/2013 01:34 AM, James Bottomley wrote:
> On Fri, 2013-01-11 at 12:03 +1100, Stephen Rothwell wrote:
>> Hi James,
>>
>> After merging the scsi tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/scsi/ipr.c:9138:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msix'
>> drivers/scsi/ipr.c:9165:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msi'
>> drivers/scsi/ipr.c:9188:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'name_msi_vectors'
>> drivers/scsi/ipr.c:9200:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_request_other_msi_irqs'
>> drivers/scsi/ipr.c: In function 'ipr_probe_ioa':
>> drivers/scsi/ipr.c:9422:4: error: implicit declaration of function 'ipr_enable_msix' [-Werror=implicit-function-declaration]
>> drivers/scsi/ipr.c:9425:4: error: implicit declaration of function 'ipr_enable_msi' [-Werror=implicit-function-declaration]
>> drivers/scsi/ipr.c:9517:3: error: implicit declaration of function 'name_msi_vectors' [-Werror=implicit-function-declaration]
>> drivers/scsi/ipr.c:9523:4: error: implicit declaration of function 'ipr_request_other_msi_irqs' [-Werror=implicit-function-declaration]
> 
> OK, fine, I'll drop all the ipr patches.  I've been waiting for a month
> for them to fix the smatch and sparse warnings.  Please resend the
> series with all the fixes.
> 
> Thanks,
> 
> James
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
> It looks like this was a due to the fact that the new patches
> added __devinit tags in the same merge window the __devinit tag
> itself was getting removed.

Not exactly.  The patch which makes them nops went into 3.8.  Now
there's a patch queued in, Gregs tree I presume, to remove them all and
the #defines which causes the compile failure.

> As to the sparse warnings, this patch fixed the ones that
> were actual bugs in the new code, although we could have
> made that more clear in the patch description.
> 
> http://marc.info/?l=linux-scsi&m=135716576204083&w=2

Ah, thanks ... I've been on holiday for a while, so I did miss that.

> There is one outstanding issue I am aware of which was an
> array bounds compiler warning which looks to be a misdetection
> by the compiler. Wendy and I discussed adding a BUG_ON
> to stop the compiler from complaining.
> 
> Wendy - lets queue these two changes up ASAP. They should both
> be very simple changes.

If it's a simple gcc bug, just ignore it.

I do need you to redo the patches to remove the __dev annotations,
though.  We can't risk introducing a bisect killing compile breakage if
Greg's tree merges before mine in the next merge window.

James

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
> > It looks like this was a due to the fact that the new patches
> > added __devinit tags in the same merge window the __devinit tag
> > itself was getting removed.
> 
> Not exactly.  The patch which makes them nops went into 3.8.  Now
> there's a patch queued in, Gregs tree I presume, to remove them all and
> the #defines which causes the compile failure.
> 
> > As to the sparse warnings, this patch fixed the ones that
> > were actual bugs in the new code, although we could have
> > made that more clear in the patch description.
> > 
> > http://marc.info/?l=linux-scsi&m=135716576204083&w=2
> 
> Ah, thanks ... I've been on holiday for a while, so I did miss that.
> 
> > There is one outstanding issue I am aware of which was an
> > array bounds compiler warning which looks to be a misdetection
> > by the compiler. Wendy and I discussed adding a BUG_ON
> > to stop the compiler from complaining.
> > 
> > Wendy - lets queue these two changes up ASAP. They should both
> > be very simple changes.
> 
> If it's a simple gcc bug, just ignore it.
> 
> I do need you to redo the patches to remove the __dev annotations,
> though.  We can't risk introducing a bisect killing compile breakage if
> Greg's tree merges before mine in the next merge window.

This change should be pushed to Linus in time for 3.8-final, so there
should not be any bisect issues.

thanks,

greg k-h

Re: linux-next: build failure after merge of the scsi tree

[Brian King]

On 01/11/2013 10:05 AM, Greg KH wrote:
> On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
>> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
>>> It looks like this was a due to the fact that the new patches
>>> added __devinit tags in the same merge window the __devinit tag
>>> itself was getting removed.
>>
>> Not exactly.  The patch which makes them nops went into 3.8.  Now
>> there's a patch queued in, Gregs tree I presume, to remove them all and
>> the #defines which causes the compile failure.
>>
>>> As to the sparse warnings, this patch fixed the ones that
>>> were actual bugs in the new code, although we could have
>>> made that more clear in the patch description.
>>>
>>> http://marc.info/?l=linux-scsi&m=135716576204083&w=2
>>
>> Ah, thanks ... I've been on holiday for a while, so I did miss that.
>>
>>> There is one outstanding issue I am aware of which was an
>>> array bounds compiler warning which looks to be a misdetection
>>> by the compiler. Wendy and I discussed adding a BUG_ON
>>> to stop the compiler from complaining.
>>>
>>> Wendy - lets queue these two changes up ASAP. They should both
>>> be very simple changes.
>>
>> If it's a simple gcc bug, just ignore it.
>>
>> I do need you to redo the patches to remove the __dev annotations,
>> though.  We can't risk introducing a bisect killing compile breakage if
>> Greg's tree merges before mine in the next merge window.
> 
> This change should be pushed to Linus in time for 3.8-final, so there
> should not be any bisect issues.

We can do this either way.

James - what is your preference? Drop everything and do a resend of the
entire series or delta patches on top of what is currently in your tree?

Thanks,

Brian


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2013-01-11 at 11:35 -0600, Brian King wrote:
> On 01/11/2013 10:05 AM, Greg KH wrote:
> > On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
> >> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
> >>> It looks like this was a due to the fact that the new patches
> >>> added __devinit tags in the same merge window the __devinit tag
> >>> itself was getting removed.
> >>
> >> Not exactly.  The patch which makes them nops went into 3.8.  Now
> >> there's a patch queued in, Gregs tree I presume, to remove them all and
> >> the #defines which causes the compile failure.
> >>
> >>> As to the sparse warnings, this patch fixed the ones that
> >>> were actual bugs in the new code, although we could have
> >>> made that more clear in the patch description.
> >>>
> >>> http://marc.info/?l=linux-scsi&m=135716576204083&w=2
> >>
> >> Ah, thanks ... I've been on holiday for a while, so I did miss that.
> >>
> >>> There is one outstanding issue I am aware of which was an
> >>> array bounds compiler warning which looks to be a misdetection
> >>> by the compiler. Wendy and I discussed adding a BUG_ON
> >>> to stop the compiler from complaining.
> >>>
> >>> Wendy - lets queue these two changes up ASAP. They should both
> >>> be very simple changes.
> >>
> >> If it's a simple gcc bug, just ignore it.
> >>
> >> I do need you to redo the patches to remove the __dev annotations,
> >> though.  We can't risk introducing a bisect killing compile breakage if
> >> Greg's tree merges before mine in the next merge window.
> > 
> > This change should be pushed to Linus in time for 3.8-final, so there
> > should not be any bisect issues.
> 
> We can do this either way.
> 
> James - what is your preference? Drop everything and do a resend of the
> entire series or delta patches on top of what is currently in your tree?

Drop everything and resend still, I think.  There's still a rebase
problem, because the merge failure will happen if I rebase the misc tree
to beyond Greg's merge point and I'd rather not have to worry about it.

Thanks,

James

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/base/dd.c:27:28: fatal error: scsi/scsi_scan.h: No such file or directory

Caused by commit eea03c20ae38 ("Make wait_for_device_probe() also do
scsi_complete_async_scans()") from Linus' tree interacting with commit
758da9dc2be8 ("[SCSI] cleanup usages of scsi_complete_async_scans") from
the scsi tree.

I have reverted commit 758da9dc2be8 for today (which may not be the best
thing to do).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2012-07-20 at 10:41 +1000, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/base/dd.c:27:28: fatal error: scsi/scsi_scan.h: No such file or directory
> 
> Caused by commit eea03c20ae38 ("Make wait_for_device_probe() also do
> scsi_complete_async_scans()") from Linus' tree interacting with commit
> 758da9dc2be8 ("[SCSI] cleanup usages of scsi_complete_async_scans") from
> the scsi tree.
> 
> I have reverted commit 758da9dc2be8 for today (which may not be the best
> thing to do).

That probably just about works, since 758da9dc2be8 is just removing
redundant code.

I've got this all fixed up properly in for-next now.

James

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

[Stephen Rothwell]

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

Hi James,

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

drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer

Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").

Since this is a staging driver, I applied these following patches:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 26 Mar 2012 12:07:35 +1100
Subject: [PATCH] scsi: disable broken staging driver

This driver is broken by commit 104c4fe25dc9 ("[SCSI] remove
scsi_host_template::proc_info") from the scsi tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/keucr/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/keucr/Kconfig b/drivers/staging/keucr/Kconfig
index ba756bf..aef4858 100644
--- a/drivers/staging/keucr/Kconfig
+++ b/drivers/staging/keucr/Kconfig
@@ -1,6 +1,6 @@
 config USB_ENESTORAGE
 	tristate "USB ENE SM card reader support"
-	depends on USB && SCSI && m
+	depends on USB && SCSI && m && BROKEN
 	---help---
 	  Say Y here if you wish to control a ENE SM Card reader.
 	  To use SD/MS card, please build driver/usb/storage/ums-eneub6250.ko
-- 
1.7.9.1

From 4c836f9935ea1d2b2bc365aa1af70afbb2545311 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 26 Mar 2012 12:13:34 +1100
Subject: [PATCH] scsi: disable more staging drivers due to scsi breakage

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/rts5139/Kconfig   |    2 +-
 drivers/staging/rts_pstor/Kconfig |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5139/Kconfig b/drivers/staging/rts5139/Kconfig
index afd526b..56bff83 100644
--- a/drivers/staging/rts5139/Kconfig
+++ b/drivers/staging/rts5139/Kconfig
@@ -1,6 +1,6 @@
 config RTS5139
 	tristate "Realtek RTS5139 USB card reader support"
-	depends on USB && SCSI
+	depends on USB && SCSI && BROKEN
 	help
 	  Say Y here to include driver code to support the Realtek
 	  RTS5139 USB card readers.
diff --git a/drivers/staging/rts_pstor/Kconfig b/drivers/staging/rts_pstor/Kconfig
index 4d66a99..1980a49 100644
--- a/drivers/staging/rts_pstor/Kconfig
+++ b/drivers/staging/rts_pstor/Kconfig
@@ -1,6 +1,6 @@
 config RTS_PSTOR
 	tristate "RealTek PCI-E Card Reader support"
-	depends on PCI && SCSI
+	depends on PCI && SCSI && BROKEN
 	help
 	  Say Y here to include driver code to support the Realtek
 	  PCI-E card readers.
-- 
1.7.9.1

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

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
> 
> Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
> 
> Since this is a staging driver, I applied these following patches:

Yes, that looks about right, thanks.  We haven't seen anything about
these drivers on the SCSI list, so I've no idea where they are in
development.

James

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Mon, Mar 26, 2012 at 08:57:21AM +0100, James Bottomley wrote:
> On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> > Hi James,
> > 
> > After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> > drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> > drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
> > 
> > Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
> > 
> > Since this is a staging driver, I applied these following patches:
> 
> Yes, that looks about right, thanks.  We haven't seen anything about
> these drivers on the SCSI list, so I've no idea where they are in
> development.

Why is new patches going into your tree right now, during the 3.4 merge
window?  API changes should have happened weeks ago, to let others fix
up things like this.

As for the "where they are in development", they vary, but, a simple
grep should have shown you that these in-kernel drivers should also be
fixed up, or at the least, give me the heads up to let me do it for you.

Care to send me the patch that causes this problem so I can create a fix
for this?

thanks,

greg k-h

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Mon, 2012-03-26 at 07:07 -0700, Greg KH wrote:
> On Mon, Mar 26, 2012 at 08:57:21AM +0100, James Bottomley wrote:
> > On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> > > Hi James,
> > > 
> > > After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> > > drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> > > drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
> > > 
> > > Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
> > > 
> > > Since this is a staging driver, I applied these following patches:
> > 
> > Yes, that looks about right, thanks.  We haven't seen anything about
> > these drivers on the SCSI list, so I've no idea where they are in
> > development.
> 
> Why is new patches going into your tree right now, during the 3.4 merge
> window?  API changes should have happened weeks ago, to let others fix
> up things like this.

Yes, I'll defer this change to the next merge window.

James

> As for the "where they are in development", they vary, but, a simple
> grep should have shown you that these in-kernel drivers should also be
> fixed up, or at the least, give me the heads up to let me do it for you.
> 
> Care to send me the patch that causes this problem so I can create a fix
> for this?
> 
> thanks,
> 
> greg k-h

Re: linux-next: build failure after merge of the scsi tree

[Alexey Dobriyan]

On Mon, Mar 26, 2012 at 07:07:21AM -0700, Greg KH wrote:
> On Mon, Mar 26, 2012 at 08:57:21AM +0100, James Bottomley wrote:
> > On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> > > Hi James,
> > > 
> > > After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> > > drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> > > drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
> > > 
> > > Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
> > > 
> > > Since this is a staging driver, I applied these following patches:
> > 
> > Yes, that looks about right, thanks.  We haven't seen anything about
> > these drivers on the SCSI list, so I've no idea where they are in
> > development.
> 
> Why is new patches going into your tree right now, during the 3.4 merge
> window?  API changes should have happened weeks ago, to let others fix
> up things like this.
> 
> As for the "where they are in development", they vary, but, a simple
> grep should have shown you that these in-kernel drivers should also be
> fixed up, or at the least, give me the heads up to let me do it for you.
> 
> Care to send me the patch that causes this problem so I can create a fix
> for this?

See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
Especially the first one.

Probably the best course of action is to remove proc_info code from
these drivers because the interface was deprecated for a long time.

The amount of code once removed from staging prevented me from doing
any work on them.

Looking at staging ->read_proc users this is going to be a problem for
its removal. :-(

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Wed, Mar 28, 2012 at 01:17:21AM +0300, Alexey Dobriyan wrote:
> On Mon, Mar 26, 2012 at 07:07:21AM -0700, Greg KH wrote:
> > On Mon, Mar 26, 2012 at 08:57:21AM +0100, James Bottomley wrote:
> > > On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> > > > Hi James,
> > > > 
> > > > After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> > > > failed like this:
> > > > 
> > > > drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> > > > drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> > > > drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
> > > > 
> > > > Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
> > > > 
> > > > Since this is a staging driver, I applied these following patches:
> > > 
> > > Yes, that looks about right, thanks.  We haven't seen anything about
> > > these drivers on the SCSI list, so I've no idea where they are in
> > > development.
> > 
> > Why is new patches going into your tree right now, during the 3.4 merge
> > window?  API changes should have happened weeks ago, to let others fix
> > up things like this.
> > 
> > As for the "where they are in development", they vary, but, a simple
> > grep should have shown you that these in-kernel drivers should also be
> > fixed up, or at the least, give me the heads up to let me do it for you.
> > 
> > Care to send me the patch that causes this problem so I can create a fix
> > for this?
> 
> See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> Especially the first one.
> 
> Probably the best course of action is to remove proc_info code from
> these drivers because the interface was deprecated for a long time.

If the interface is depreciated, yes, I can remove it now, just let me
know and I will do so.

> The amount of code once removed from staging prevented me from doing
> any work on them.
> 
> Looking at staging ->read_proc users this is going to be a problem for
> its removal. :-(

Why?

Re: linux-next: build failure after merge of the scsi tree

[Alexey Dobriyan]

On Tue, Mar 27, 2012 at 03:22:16PM -0700, Greg KH wrote:
> On Wed, Mar 28, 2012 at 01:17:21AM +0300, Alexey Dobriyan wrote:
> > On Mon, Mar 26, 2012 at 07:07:21AM -0700, Greg KH wrote:
> > > On Mon, Mar 26, 2012 at 08:57:21AM +0100, James Bottomley wrote:
> > > > On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> > > > > Hi James,
> > > > > 
> > > > > After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> > > > > failed like this:
> > > > > 
> > > > > drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> > > > > drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> > > > > drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
> > > > > 
> > > > > Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
> > > > > 
> > > > > Since this is a staging driver, I applied these following patches:
> > > > 
> > > > Yes, that looks about right, thanks.  We haven't seen anything about
> > > > these drivers on the SCSI list, so I've no idea where they are in
> > > > development.
> > > 
> > > Why is new patches going into your tree right now, during the 3.4 merge
> > > window?  API changes should have happened weeks ago, to let others fix
> > > up things like this.
> > > 
> > > As for the "where they are in development", they vary, but, a simple
> > > grep should have shown you that these in-kernel drivers should also be
> > > fixed up, or at the least, give me the heads up to let me do it for you.
> > > 
> > > Care to send me the patch that causes this problem so I can create a fix
> > > for this?
> > 
> > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> > Especially the first one.
> > 
> > Probably the best course of action is to remove proc_info code from
> > these drivers because the interface was deprecated for a long time.
> 
> If the interface is depreciated, yes, I can remove it now, just let me
> know and I will do so.
> 
> > The amount of code once removed from staging prevented me from doing
> > any work on them.
> > 
> > Looking at staging ->read_proc users this is going to be a problem for
> > its removal. :-(
> 
> Why?

Because if staging does count, I can't remove the interface
without breaking allmodconfig and it would take forever to convert
staging stuff. I don't have energy to do it anymore.
Mainline still have several _hard_ ->read_proc conversions.
I've tried several times and failed.

If staging doesn't count, I will break allmodconfig and all those nasty
emails will show up anyway implying that staging does count.

Re: linux-next: build failure after merge of the scsi tree

[Alexey Dobriyan]

On Wed, Mar 28, 2012 at 01:35:10AM +0300, Alexey Dobriyan wrote:
> On Tue, Mar 27, 2012 at 03:22:16PM -0700, Greg KH wrote:

> > > The amount of code once removed from staging prevented me from doing
> > > any work on them.
> > > 
> > > Looking at staging ->read_proc users this is going to be a problem for
> > > its removal. :-(
> > 
> > Why?
> 
> Because if staging does count, I can't remove the interface
> without breaking allmodconfig and it would take forever to convert
> staging stuff. I don't have energy to do it anymore.
> Mainline still have several _hard_ ->read_proc conversions.
> I've tried several times and failed.
> 
> If staging doesn't count, I will break allmodconfig and all those nasty
> emails will show up anyway implying that staging does count.

It's comparable to what mainline has besides staging.
I'm talking about this.

$ grep -e read_proc -w -n -r drivers/staging/
drivers/staging/comedi/proc.c:92:               comedi_proc->read_proc = comedi_read;
drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:298:      e->read_proc = show_debug_level;
drivers/staging/serial/68360serial.c:2428:      /* .read_proc = rs_360_read_proc, */
drivers/staging/rtl8192e/rtllib_module.c:262:   e->read_proc = show_debug_level;

$ grep -e create_proc_read_entry -w -n -r drivers/staging/
drivers/staging/telephony/ixj.c:7763:   create_proc_read_entry ("ixj", 0, NULL, ixj_read_proc, NULL);
drivers/staging/ft1000/ft1000-usb/ft1000_proc.c:189:            ft1000_proc_file = create_proc_read_entry(dev->name, 0644,
drivers/staging/ft1000/ft1000-usb/ft1000_proc.c:221:            create_proc_read_entry(dev->name, 0644,
drivers/staging/ft1000/ft1000-pcmcia/ft1000_proc.c:181:         create_proc_read_entry(dev->name, 0644, info->proc_ft1000,
drivers/staging/ft1000/ft1000-pcmcia/ft1000_proc.c:200: create_proc_read_entry(dev->name, 0644, info->proc_ft1000,
drivers/staging/rtl8192u/r8192U_core.c:714:     e = create_proc_read_entry("stats-rx", S_IFREG | S_IRUGO,
drivers/staging/rtl8192u/r8192U_core.c:724:     e = create_proc_read_entry("stats-tx", S_IFREG | S_IRUGO,
drivers/staging/rtl8192u/r8192U_core.c:733:     e = create_proc_read_entry("stats-ap", S_IFREG | S_IRUGO,
drivers/staging/rtl8192u/r8192U_core.c:742:     e = create_proc_read_entry("registers", S_IFREG | S_IRUGO,
drivers/staging/cxt1e1/sbeproc.c:325:    e = create_proc_read_entry ("info", S_IFREG | S_IRUGO,
drivers/staging/rtl8187se/r8180_core.c:343:     e = create_proc_read_entry("stats-hw", S_IFREG | S_IRUGO,
drivers/staging/rtl8187se/r8180_core.c:351:     e = create_proc_read_entry("stats-rx", S_IFREG | S_IRUGO,
drivers/staging/rtl8187se/r8180_core.c:360:     e = create_proc_read_entry("stats-tx", S_IFREG | S_IRUGO,
drivers/staging/rtl8187se/r8180_core.c:368:     e = create_proc_read_entry("registers", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:873:      e = create_proc_read_entry("stats-rx", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:881:      e = create_proc_read_entry("stats-tx", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:889:      e = create_proc_read_entry("stats-ap", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:897:      e = create_proc_read_entry("registers-0", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:903:      e = create_proc_read_entry("registers-1", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:909:      e = create_proc_read_entry("registers-2", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:915:      e = create_proc_read_entry("registers-3", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:921:      e = create_proc_read_entry("registers-4", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:927:      e = create_proc_read_entry("registers-5", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:933:      e = create_proc_read_entry("registers-6", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:939:      e = create_proc_read_entry("registers-7", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:945:      e = create_proc_read_entry("registers-8", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:951:      e = create_proc_read_entry("registers-9", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:957:      e = create_proc_read_entry("registers-a", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:963:      e = create_proc_read_entry("registers-b", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:969:      e = create_proc_read_entry("registers-c", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:975:      e = create_proc_read_entry("registers-d", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:981:      e = create_proc_read_entry("registers-e", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:987:      e = create_proc_read_entry("RF-A", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:993:      e = create_proc_read_entry("RF-B", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:999:      e = create_proc_read_entry("RF-C", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1005:     e = create_proc_read_entry("RF-D", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1011:     e = create_proc_read_entry("SEC-CAM-1", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1017:     e = create_proc_read_entry("SEC-CAM-2", S_IFREG | S_IRUGO,
drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1023:     e = create_proc_read_entry("SEC-CAM-3", S_IFREG | S_IRUGO,
drivers/staging/wlags49_h2/wl_main.c:912:       create_proc_read_entry( "wlags", 0, NULL, scull_read_procmem, dev );

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Wed, Mar 28, 2012 at 01:39:39AM +0300, Alexey Dobriyan wrote:
> On Wed, Mar 28, 2012 at 01:35:10AM +0300, Alexey Dobriyan wrote:
> > On Tue, Mar 27, 2012 at 03:22:16PM -0700, Greg KH wrote:
> 
> > > > The amount of code once removed from staging prevented me from doing
> > > > any work on them.
> > > > 
> > > > Looking at staging ->read_proc users this is going to be a problem for
> > > > its removal. :-(
> > > 
> > > Why?
> > 
> > Because if staging does count, I can't remove the interface
> > without breaking allmodconfig and it would take forever to convert
> > staging stuff. I don't have energy to do it anymore.
> > Mainline still have several _hard_ ->read_proc conversions.
> > I've tried several times and failed.
> > 
> > If staging doesn't count, I will break allmodconfig and all those nasty
> > emails will show up anyway implying that staging does count.
> 
> It's comparable to what mainline has besides staging.
> I'm talking about this.
> 
> $ grep -e read_proc -w -n -r drivers/staging/
> drivers/staging/comedi/proc.c:92:               comedi_proc->read_proc = comedi_read;
> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:298:      e->read_proc = show_debug_level;
> drivers/staging/serial/68360serial.c:2428:      /* .read_proc = rs_360_read_proc, */
> drivers/staging/rtl8192e/rtllib_module.c:262:   e->read_proc = show_debug_level;

Only the comedi one should probably stick around, and even then, it
really should be moved to a sysfs file or three, or even better, a
debugfs file.

> $ grep -e create_proc_read_entry -w -n -r drivers/staging/
> drivers/staging/telephony/ixj.c:7763:   create_proc_read_entry ("ixj", 0, NULL, ixj_read_proc, NULL);
> drivers/staging/ft1000/ft1000-usb/ft1000_proc.c:189:            ft1000_proc_file = create_proc_read_entry(dev->name, 0644,
> drivers/staging/ft1000/ft1000-usb/ft1000_proc.c:221:            create_proc_read_entry(dev->name, 0644,
> drivers/staging/ft1000/ft1000-pcmcia/ft1000_proc.c:181:         create_proc_read_entry(dev->name, 0644, info->proc_ft1000,
> drivers/staging/ft1000/ft1000-pcmcia/ft1000_proc.c:200: create_proc_read_entry(dev->name, 0644, info->proc_ft1000,
> drivers/staging/rtl8192u/r8192U_core.c:714:     e = create_proc_read_entry("stats-rx", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192u/r8192U_core.c:724:     e = create_proc_read_entry("stats-tx", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192u/r8192U_core.c:733:     e = create_proc_read_entry("stats-ap", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192u/r8192U_core.c:742:     e = create_proc_read_entry("registers", S_IFREG | S_IRUGO,
> drivers/staging/cxt1e1/sbeproc.c:325:    e = create_proc_read_entry ("info", S_IFREG | S_IRUGO,
> drivers/staging/rtl8187se/r8180_core.c:343:     e = create_proc_read_entry("stats-hw", S_IFREG | S_IRUGO,
> drivers/staging/rtl8187se/r8180_core.c:351:     e = create_proc_read_entry("stats-rx", S_IFREG | S_IRUGO,
> drivers/staging/rtl8187se/r8180_core.c:360:     e = create_proc_read_entry("stats-tx", S_IFREG | S_IRUGO,
> drivers/staging/rtl8187se/r8180_core.c:368:     e = create_proc_read_entry("registers", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:873:      e = create_proc_read_entry("stats-rx", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:881:      e = create_proc_read_entry("stats-tx", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:889:      e = create_proc_read_entry("stats-ap", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:897:      e = create_proc_read_entry("registers-0", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:903:      e = create_proc_read_entry("registers-1", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:909:      e = create_proc_read_entry("registers-2", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:915:      e = create_proc_read_entry("registers-3", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:921:      e = create_proc_read_entry("registers-4", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:927:      e = create_proc_read_entry("registers-5", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:933:      e = create_proc_read_entry("registers-6", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:939:      e = create_proc_read_entry("registers-7", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:945:      e = create_proc_read_entry("registers-8", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:951:      e = create_proc_read_entry("registers-9", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:957:      e = create_proc_read_entry("registers-a", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:963:      e = create_proc_read_entry("registers-b", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:969:      e = create_proc_read_entry("registers-c", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:975:      e = create_proc_read_entry("registers-d", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:981:      e = create_proc_read_entry("registers-e", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:987:      e = create_proc_read_entry("RF-A", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:993:      e = create_proc_read_entry("RF-B", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:999:      e = create_proc_read_entry("RF-C", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1005:     e = create_proc_read_entry("RF-D", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1011:     e = create_proc_read_entry("SEC-CAM-1", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1017:     e = create_proc_read_entry("SEC-CAM-2", S_IFREG | S_IRUGO,
> drivers/staging/rtl8192e/rtl8192e/rtl_debug.c:1023:     e = create_proc_read_entry("SEC-CAM-3", S_IFREG | S_IRUGO,
> drivers/staging/wlags49_h2/wl_main.c:912:       create_proc_read_entry( "wlags", 0, NULL, scull_read_procmem, dev );


I don't understand, I thought you were talking about scsi drivers, why
list all of these?  What does your patch do?

greg k-h

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Wed, Mar 28, 2012 at 01:39:39AM +0300, Alexey Dobriyan wrote:
> On Wed, Mar 28, 2012 at 01:35:10AM +0300, Alexey Dobriyan wrote:
> > On Tue, Mar 27, 2012 at 03:22:16PM -0700, Greg KH wrote:
> 
> > > > The amount of code once removed from staging prevented me from doing
> > > > any work on them.
> > > > 
> > > > Looking at staging ->read_proc users this is going to be a problem for
> > > > its removal. :-(
> > > 
> > > Why?
> > 
> > Because if staging does count, I can't remove the interface
> > without breaking allmodconfig and it would take forever to convert
> > staging stuff. I don't have energy to do it anymore.
> > Mainline still have several _hard_ ->read_proc conversions.
> > I've tried several times and failed.
> > 
> > If staging doesn't count, I will break allmodconfig and all those nasty
> > emails will show up anyway implying that staging does count.
> 
> It's comparable to what mainline has besides staging.
> I'm talking about this.
> 
> $ grep -e read_proc -w -n -r drivers/staging/
> drivers/staging/comedi/proc.c:92:               comedi_proc->read_proc = comedi_read;
> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:298:      e->read_proc = show_debug_level;
> drivers/staging/serial/68360serial.c:2428:      /* .read_proc = rs_360_read_proc, */
> drivers/staging/rtl8192e/rtllib_module.c:262:   e->read_proc = show_debug_level;

No you are not at all.  That's not the function to grep for, I have no
idea what you are trying to prove with this grep, but it is flat out
wrong.

Thanks to Gerard, I've looked at your patches, and it's obvious that you
didn't look to see what would needed to be done to convert the
drivers/staging/ drivers to your new interface.

In short, it's trivial, and it looks like you could take one of your
existing patches, rename the file, and it would apply cleanly to two of
the drivers, so you are already 2/3 done.

The other one is even simpler than that, I've included it below for your
perusal.

If you need me to, I can write these patches, but I can't build or test
them, as I do not see the proc_ops field in the scsi_host_template in
Linus's tree.

It's just part of changing apis, if you want to break them, then fix up
the existing users.  If you need help with existing users, just ask.

So feel free to take my patch below for your patch series, and if you
want me to fix up the other two, just ask.

thanks,

greg k-h
----------------------------

Subject: staging: rts_pstor: convert to scsi proc_ops

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/staging/rts_pstor/rtsx.c b/drivers/staging/rts_pstor/rtsx.c
index a7feb3e..114971c 100644
--- a/drivers/staging/rts_pstor/rtsx.c
+++ b/drivers/staging/rts_pstor/rtsx.c
@@ -24,6 +24,8 @@
 #include <linux/kthread.h>
 #include <linux/sched.h>
 #include <linux/workqueue.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
 
 #include "rtsx.h"
 #include "rtsx_chip.h"
@@ -128,16 +130,11 @@ static int slave_configure(struct scsi_device *sdev)
 /* we use this macro to help us write into the buffer */
 #undef SPRINTF
 #define SPRINTF(args...) \
-	do { if (pos < buffer+length) pos += sprintf(pos, ## args); } while (0)
+	seq_printf(m, ## args)
 
-static int proc_info(struct Scsi_Host *host, char *buffer,
-		char **start, off_t offset, int length, int inout)
+static int proc_show(struct seq_file *m, void *v)
 {
-	char *pos = buffer;
-
-	/* if someone is sending us data, just throw it away */
-	if (inout)
-		return length;
+	struct Scsi_Host *host = m->private;
 
 	/* print the controller name */
 	SPRINTF("   Host scsi%d: %s\n", host->host_no, CR_DRIVER_NAME);
@@ -146,20 +143,21 @@ static int proc_info(struct Scsi_Host *host, char *buffer,
 	SPRINTF("       Vendor: Realtek Corp.\n");
 	SPRINTF("      Product: PCIE Card Reader\n");
 	SPRINTF("      Version: %s\n", DRIVER_VERSION);
+	return 0;
+}
 
-	/*
-	 * Calculate start of next buffer, and return value.
-	 */
-	*start = buffer + offset;
-
-	if ((pos - buffer) < offset)
-		return 0;
-	else if ((pos - buffer - offset) < length)
-		return pos - buffer - offset;
-	else
-		return length;
+static int proc_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, proc_show, PDE(inode)->data);
 }
 
+static const struct file_operations proc_ops = {
+	.open		= proc_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= single_release,
+};
+
 /* queue a command */
 /* This is always called with scsi_lock(host) held */
 static int queuecommand_lck(struct scsi_cmnd *srb,
@@ -255,7 +253,7 @@ static struct scsi_host_template rtsx_host_template = {
 	/* basic userland interface stuff */
 	.name =				CR_DRIVER_NAME,
 	.proc_name =			CR_DRIVER_NAME,
-	.proc_info =			proc_info,
+	.proc_ops = 			&proc_ops,
 	.info =				host_info,
 
 	/* command interface -- queued only */

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Wed, Mar 28, 2012 at 01:35:10AM +0300, Alexey Dobriyan wrote:
> On Tue, Mar 27, 2012 at 03:22:16PM -0700, Greg KH wrote:
> > On Wed, Mar 28, 2012 at 01:17:21AM +0300, Alexey Dobriyan wrote:
> > > On Mon, Mar 26, 2012 at 07:07:21AM -0700, Greg KH wrote:
> > > > On Mon, Mar 26, 2012 at 08:57:21AM +0100, James Bottomley wrote:
> > > > > On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> > > > > > Hi James,
> > > > > > 
> > > > > > After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> > > > > > failed like this:
> > > > > > 
> > > > > > drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> > > > > > drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> > > > > > drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
> > > > > > 
> > > > > > Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
> > > > > > 
> > > > > > Since this is a staging driver, I applied these following patches:
> > > > > 
> > > > > Yes, that looks about right, thanks.  We haven't seen anything about
> > > > > these drivers on the SCSI list, so I've no idea where they are in
> > > > > development.
> > > > 
> > > > Why is new patches going into your tree right now, during the 3.4 merge
> > > > window?  API changes should have happened weeks ago, to let others fix
> > > > up things like this.
> > > > 
> > > > As for the "where they are in development", they vary, but, a simple
> > > > grep should have shown you that these in-kernel drivers should also be
> > > > fixed up, or at the least, give me the heads up to let me do it for you.
> > > > 
> > > > Care to send me the patch that causes this problem so I can create a fix
> > > > for this?
> > > 
> > > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> > > Especially the first one.

I don't know where to find these patches, care to send them to me, or
point me at a link with them?

> > > Probably the best course of action is to remove proc_info code from
> > > these drivers because the interface was deprecated for a long time.
> > 
> > If the interface is depreciated, yes, I can remove it now, just let me
> > know and I will do so.
> > 
> > > The amount of code once removed from staging prevented me from doing
> > > any work on them.
> > > 
> > > Looking at staging ->read_proc users this is going to be a problem for
> > > its removal. :-(
> > 
> > Why?
> 
> Because if staging does count, I can't remove the interface
> without breaking allmodconfig and it would take forever to convert
> staging stuff. I don't have energy to do it anymore.
> Mainline still have several _hard_ ->read_proc conversions.
> I've tried several times and failed.
> 
> If staging doesn't count, I will break allmodconfig and all those nasty
> emails will show up anyway implying that staging does count.

I don't understand, if read_proc is depreciated, why can't I just remove
it from the staging drivers and then all will be fine, right?

confused,

greg k-h

Re: linux-next: build failure after merge of the scsi tree

[Gerard Snitselaar]

On Wed Mar 28 12, Greg KH wrote:
> > > > 
> > > > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> > > > Especially the first one.
> 
> I don't know where to find these patches, care to send them to me, or
> point me at a link with them?
> 

They are visible in next-20120329

Re: linux-next: build failure after merge of the scsi tree

[Stephen Rothwell]

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

On Thu, 29 Mar 2012 00:32:40 -0700 Gerard Snitselaar <dev@snitselaar.org> wrote:
>
> On Wed Mar 28 12, Greg KH wrote:
> > > > > 
> > > > > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> > > > > Especially the first one.
> > 
> > I don't know where to find these patches, care to send them to me, or
> > point me at a link with them?
> > 
> 
> They are visible in next-20120329

I don't think so.  They were in next-2012032[67], but were removed again.

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

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Thu, 2012-03-29 at 19:25 +1100, Stephen Rothwell wrote:
> On Thu, 29 Mar 2012 00:32:40 -0700 Gerard Snitselaar <dev@snitselaar.org> wrote:
> > On Wed Mar 28 12, Greg KH wrote:
> > > > > > 
> > > > > > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> > > > > > Especially the first one.
> > > 
> > > I don't know where to find these patches, care to send them to me, or
> > > point me at a link with them?
> > > 
> > 
> > They are visible in next-20120329
> 
> I don't think so.  They were in next-2012032[67], but were removed again.

The plan is to put them back once we go 3.4-rc1 so we have a whole
release cycle to fix up any breakage.

James

Re: linux-next: build failure after merge of the scsi tree

[Gerard Snitselaar]

On Thu Mar 29 12, Stephen Rothwell wrote:
> On Thu, 29 Mar 2012 00:32:40 -0700 Gerard Snitselaar <dev@snitselaar.org> wrote:
> >
> > On Wed Mar 28 12, Greg KH wrote:
> > > > > > 
> > > > > > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> > > > > > Especially the first one.
> > > 
> > > I don't know where to find these patches, care to send them to me, or
> > > point me at a link with them?
> > > 
> > 
> > They are visible in next-20120329
> 
> I don't think so.  They were in next-2012032[67], but were removed again.
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

Sorry, poorly worded on my part. What I meant to say was I could see
the commits in the repository when doing
 
git show 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Thu, Mar 29, 2012 at 02:03:51AM -0700, Gerard Snitselaar wrote:
> On Thu Mar 29 12, Stephen Rothwell wrote:
> > On Thu, 29 Mar 2012 00:32:40 -0700 Gerard Snitselaar <dev@snitselaar.org> wrote:
> > >
> > > On Wed Mar 28 12, Greg KH wrote:
> > > > > > > 
> > > > > > > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
> > > > > > > Especially the first one.
> > > > 
> > > > I don't know where to find these patches, care to send them to me, or
> > > > point me at a link with them?
> > > > 
> > > 
> > > They are visible in next-20120329
> > 
> > I don't think so.  They were in next-2012032[67], but were removed again.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> 
> Sorry, poorly worded on my part. What I meant to say was I could see
> the commits in the repository when doing
>  
> git show 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5

Can someone just email me them?

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/ata/sata_svw.c: In function 'k2_sata_proc_open':
drivers/ata/sata_svw.c:327:2: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
drivers/ata/sata_svw.c:327:56: error: invalid type argument of '->' (have 'int')
drivers/ata/sata_svw.c:328:1: warning: control reaches end of non-void function [-Wreturn-type]

Caused by commit 343ac4b031a7 ("[SCSI] sata_svw: convert to scsi proc_ops").

I have used the scsi tree from next-20120322 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

Re: linux-next: build failure after merge of the scsi tree

[Benjamin Herrenschmidt]

On Fri, 2012-03-23 at 13:00 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/ata/sata_svw.c: In function 'k2_sata_proc_open':
> drivers/ata/sata_svw.c:327:2: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
> drivers/ata/sata_svw.c:327:56: error: invalid type argument of '->' (have 'int')
> drivers/ata/sata_svw.c:328:1: warning: control reaches end of non-void function [-Wreturn-type]
> 
> Caused by commit 343ac4b031a7 ("[SCSI] sata_svw: convert to scsi proc_ops").
> 
> I have used the scsi tree from next-20120322 for today.

Additionally, I am the author and maintainer of that driver and I don't
remember ever being CCed on that patch ... or did I miss it ?

Cheers,
Ben.

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2012-03-23 at 15:50 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2012-03-23 at 13:00 +1100, Stephen Rothwell wrote:
> > Hi James,
> > 
> > After merging the scsi tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > drivers/ata/sata_svw.c: In function 'k2_sata_proc_open':
> > drivers/ata/sata_svw.c:327:2: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
> > drivers/ata/sata_svw.c:327:56: error: invalid type argument of '->' (have 'int')
> > drivers/ata/sata_svw.c:328:1: warning: control reaches end of non-void function [-Wreturn-type]
> > 
> > Caused by commit 343ac4b031a7 ("[SCSI] sata_svw: convert to scsi proc_ops").
> > 
> > I have used the scsi tree from next-20120322 for today.
> 
> Additionally, I am the author and maintainer of that driver and I don't
> remember ever being CCed on that patch ... or did I miss it ?

You missed it ... I added you and Jeff for automatic cc's when the
commit hit the scsi tree.

This is the mail log:

Mar 22 07:53:17 bedivere postfix/smtp[14322]: C3A1F8EE136: to=<benh@kernel.crashing.org>, relay=gate.crashing.org[63.228.1.57]:25, delay=2.7, delays=0.13/0.12/1.3/1.2, dsn=2.0.0, status=sent (250 2.0.0 q2MErGNT019145 Message accepted for delivery)

James

Re: linux-next: build failure after merge of the scsi tree

[Benjamin Herrenschmidt]

On Fri, 2012-03-23 at 08:14 +0000, James Bottomley wrote:
> > Additionally, I am the author and maintainer of that driver and I
> don't
> > remember ever being CCed on that patch ... or did I miss it ?
> 
> You missed it ... I added you and Jeff for automatic cc's when the
> commit hit the scsi tree.
> 
> This is the mail log:
> 
> Mar 22 07:53:17 bedivere postfix/smtp[14322]: C3A1F8EE136:
> to=<benh@kernel.crashing.org>,
> relay=gate.crashing.org[63.228.1.57]:25, delay=2.7,
> delays=0.13/0.12/1.3/1.2, dsn=2.0.0, status=sent (250 2.0.0
> q2MErGNT019145 Message accepted for delivery)

Allright, Mar 22, that's yesterday (.au time)... that's a short time
between notifying the maintainer and going into -next :-) No biggie,
I'll have a look next week, it's just annoying to get build failure
reports from Stephen about drivers I own for patches I never heard
about ...

Cheers,
Ben.

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2012-03-23 at 19:53 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2012-03-23 at 08:14 +0000, James Bottomley wrote:
> > > Additionally, I am the author and maintainer of that driver and I
> > don't
> > > remember ever being CCed on that patch ... or did I miss it ?
> > 
> > You missed it ... I added you and Jeff for automatic cc's when the
> > commit hit the scsi tree.
> > 
> > This is the mail log:
> > 
> > Mar 22 07:53:17 bedivere postfix/smtp[14322]: C3A1F8EE136:
> > to=<benh@kernel.crashing.org>,
> > relay=gate.crashing.org[63.228.1.57]:25, delay=2.7,
> > delays=0.13/0.12/1.3/1.2, dsn=2.0.0, status=sent (250 2.0.0
> > q2MErGNT019145 Message accepted for delivery)
> 
> Allright, Mar 22, that's yesterday (.au time)... that's a short time
> between notifying the maintainer and going into -next :-) No biggie,
> I'll have a look next week, it's just annoying to get build failure
> reports from Stephen about drivers I own for patches I never heard
> about ...

Yes, sorry ... it's one of those large all or nothing type series that
touches about 33 different drivers (about 75% of which are
unmaintained).

I would have checked the ppc compile if I still had a working ppc
machine.  Having looked through the code, I think this is the fix ...
could someone check?

James

---

diff --git a/drivers/ata/sata_svw.c b/drivers/ata/sata_svw.c
index 05838bf..0bbd0cb 100644
--- a/drivers/ata/sata_svw.c
+++ b/drivers/ata/sata_svw.c
@@ -42,6 +42,7 @@
 #include <linux/init.h>
 #include <linux/blkdev.h>
 #include <linux/delay.h>
+#include <linux/proc_fs.h>
 #include <linux/interrupt.h>
 #include <linux/device.h>
 #include <scsi/scsi_host.h>

Re: linux-next: build failure after merge of the scsi tree

[Jeff Garzik]

On 03/23/2012 05:01 AM, James Bottomley wrote:
> Yes, sorry ... it's one of those large all or nothing type series that
> touches about 33 different drivers (about 75% of which are
> unmaintained).

To be more specific, it was a patch series that was never CC'd to ANY 
driver author, nor linux-ide, nor LKML.

	Jeff

Re: linux-next: build failure after merge of the scsi tree

[Alexey Dobriyan]

On Fri, Mar 23, 2012 at 7:50 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2012-03-23 at 13:00 +1100, Stephen Rothwell wrote:
>> Hi James,
>>
>> After merging the scsi tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/ata/sata_svw.c: In function 'k2_sata_proc_open':
>> drivers/ata/sata_svw.c:327:2: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
>> drivers/ata/sata_svw.c:327:56: error: invalid type argument of '->' (have 'int')
>> drivers/ata/sata_svw.c:328:1: warning: control reaches end of non-void function [-Wreturn-type]
>>
>> Caused by commit 343ac4b031a7 ("[SCSI] sata_svw: convert to scsi proc_ops").
>>
>> I have used the scsi tree from next-20120322 for today.
>
> Additionally, I am the author and maintainer of that driver and I don't
> remember ever being CCed on that patch ... or did I miss it ?

Your email was not mentioned in changelogs for 6 years nor the driver
has specific MAINTAINERS entry.

Re: linux-next: build failure after merge of the scsi tree

[Jeff Garzik]

On 03/23/2012 06:26 AM, Alexey Dobriyan wrote:
> On Fri, Mar 23, 2012 at 7:50 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org>  wrote:
>> On Fri, 2012-03-23 at 13:00 +1100, Stephen Rothwell wrote:
>>> Hi James,
>>>
>>> After merging the scsi tree, today's linux-next build (powerpc
>>> ppc64_defconfig) failed like this:
>>>
>>> drivers/ata/sata_svw.c: In function 'k2_sata_proc_open':
>>> drivers/ata/sata_svw.c:327:2: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
>>> drivers/ata/sata_svw.c:327:56: error: invalid type argument of '->' (have 'int')
>>> drivers/ata/sata_svw.c:328:1: warning: control reaches end of non-void function [-Wreturn-type]
>>>
>>> Caused by commit 343ac4b031a7 ("[SCSI] sata_svw: convert to scsi proc_ops").
>>>
>>> I have used the scsi tree from next-20120322 for today.
>>
>> Additionally, I am the author and maintainer of that driver and I don't
>> remember ever being CCed on that patch ... or did I miss it ?
>
> Your email was not mentioned in changelogs for 6 years nor the driver
> has specific MAINTAINERS entry.


At the top of drivers/ata/sata_svw.c, we find:

  *  Maintained by: Benjamin Herrenschmidt <benh@kernel.crashing.org> and
  *                 Jeff Garzik <jgarzik@pobox.com>
  *                  Please ALWAYS copy linux-ide@vger.kernel.org
  *                  on emails.

and in MAINTAINERS we also find

SERIAL ATA (SATA) SUBSYSTEM
M:      Jeff Garzik <jgarzik@pobox.com>
L:      linux-ide@vger.kernel.org
T:      git 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
S:      Supported
F:      drivers/ata/

None of these addresses, nor LKML, were copied.  Please do so in the future.

	Jeff

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2012-03-23 at 13:00 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/ata/sata_svw.c: In function 'k2_sata_proc_open':
> drivers/ata/sata_svw.c:327:2: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
> drivers/ata/sata_svw.c:327:56: error: invalid type argument of '->' (have 'int')
> drivers/ata/sata_svw.c:328:1: warning: control reaches end of non-void function [-Wreturn-type]

That's defined in linux/proc_fs.h

What was the config?  Was it a no-PROCFS config, or is this just
something that needs to be explicitly included?

James

Re: linux-next: build failure after merge of the scsi tree

[Stephen Rothwell]

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

Hi James,

On Fri, 23 Mar 2012 08:20:09 +0000 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Fri, 2012-03-23 at 13:00 +1100, Stephen Rothwell wrote:
> > 
> > After merging the scsi tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > drivers/ata/sata_svw.c: In function 'k2_sata_proc_open':
> > drivers/ata/sata_svw.c:327:2: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
> > drivers/ata/sata_svw.c:327:56: error: invalid type argument of '->' (have 'int')
> > drivers/ata/sata_svw.c:328:1: warning: control reaches end of non-void function [-Wreturn-type]
> 
> That's defined in linux/proc_fs.h
> 
> What was the config?  Was it a no-PROCFS config, or is this just
> something that needs to be explicitly included?

See above, that was a powerpc ppc64_defconfig.  It certainly has PROCFS
enabled.  Almost everything needs to be explicitly included - see Rule 1
in Documentation/SubmitChecklist ...

Implicit includes are vulnerable to CONFIG changes and
architecture/platform differences in the include files.  I have seen lots
of these.  :-(

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

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

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/qla4xxx/ql4_os.c:2135:6: error: redefinition of 'qla4xxx_check_relogin_flash_ddb'
drivers/scsi/qla4xxx/ql4_os.c:2081:6: note: previous definition of 'qla4xxx_check_relogin_flash_ddb' was here

Caused by a bad automatic merge when I merged the scsi tree today.  The
patch "[SCSI] qla4xxx: fix flash/ddb support" appears in both the scsi
and scsi-rc-fixes tree (as separate commits) and git has messed up the
merge.  I fixed it up by using the version of this file from the scsi
tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Thu, 2011-12-15 at 12:58 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/qla4xxx/ql4_os.c:2135:6: error: redefinition of 'qla4xxx_check_relogin_flash_ddb'
> drivers/scsi/qla4xxx/ql4_os.c:2081:6: note: previous definition of 'qla4xxx_check_relogin_flash_ddb' was here
> 
> Caused by a bad automatic merge when I merged the scsi tree today.  The
> patch "[SCSI] qla4xxx: fix flash/ddb support" appears in both the scsi
> and scsi-rc-fixes tree (as separate commits) and git has messed up the
> merge.  I fixed it up by using the version of this file from the scsi
> tree.

Erk sorry ... I blame tglx ... I had to rebase the rc-fixes tree to get
a cc stable on to one of his patches, but I need to rebase scsi-misc as
well since it's built on top of rc-fixes.  Should be fixed for the next
go around (which is where the duplicate came from).

James

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

[Stephen Rothwell]

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

Hi James,

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

ERROR: "blk_put_queue" [drivers/scsi/scsi_mod.ko] undefined!
ERROR: "blk_get_queue" [drivers/scsi/scsi_mod.ko] undefined!

Caused by commit 069a596c12ca ("[SCSI] Fix oops caused by queue
refcounting failure").

I have used the scsi tree from next-20110526 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2011-05-27 at 13:25 +1000, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "blk_put_queue" [drivers/scsi/scsi_mod.ko] undefined!
> ERROR: "blk_get_queue" [drivers/scsi/scsi_mod.ko] undefined!
> 
> Caused by commit 069a596c12ca ("[SCSI] Fix oops caused by queue
> refcounting failure").
> 
> I have used the scsi tree from next-20110526 for today.

I dropped the patch for now and am circling back around with Jens to get
the necessary EXPORT_SYMBOL_GPL() tags added.

Thanks,

James

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/lpfc/lpfc_hbadisc.c: In function 'lpfc_mbx_cmpl_fcf_rr_read_fcf_rec':
drivers/scsi/lpfc/lpfc_hbadisc.c:2332: error: implicit declaration of function 'msleep'

Caused by commit 2c09c56c0967ff6a0974ebe2b03da39b26073dd0 ("[SCSI] lpfc
8.3.18: Add logic to detect last devloss timeout").

I have used the scsi tree from next-20101025 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Tue, 2010-10-26 at 11:19 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/lpfc/lpfc_hbadisc.c: In function 'lpfc_mbx_cmpl_fcf_rr_read_fcf_rec':
> drivers/scsi/lpfc/lpfc_hbadisc.c:2332: error: implicit declaration of function 'msleep'
> 
> Caused by commit 2c09c56c0967ff6a0974ebe2b03da39b26073dd0 ("[SCSI] lpfc
> 8.3.18: Add logic to detect last devloss timeout").
> 
> I have used the scsi tree from next-20101025 for today.

I've fixed this up in scsi-misc (by adding an explicit delay.h to
lpfc_hbadisc.c).  So hopefully the scsi branch should work for the next
build.

James

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

[Stephen Rothwell]

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

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/lpfc/lpfc_bsg.c: In function 'lpfc_bsg_diag_mode':
drivers/scsi/lpfc/lpfc_bsg.c:1496: error: implicit declaration of function 'msleep'

Caused by commit 3b5dd52aaffd291edea9f939ed46a960b240bb45 ("[SCSI] lpfc
8.3.8: (BSG4) Add new vendor specific BSG Commands").

Missing include of linux/delay.h?

I have used the version of the scsi tree from next-20100209 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Wed, 2010-02-10 at 12:33 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/lpfc/lpfc_bsg.c: In function 'lpfc_bsg_diag_mode':
> drivers/scsi/lpfc/lpfc_bsg.c:1496: error: implicit declaration of function 'msleep'
> 
> Caused by commit 3b5dd52aaffd291edea9f939ed46a960b240bb45 ("[SCSI] lpfc
> 8.3.8: (BSG4) Add new vendor specific BSG Commands").
> 
> Missing include of linux/delay.h?

Looks to be exactly the problem.  delay.h gets pulled into some of the
generic headers on x86, but not on ppc.

Sorry, my powerstation isn't working (orange warning light) and I can't
seem to get anyone to repair it, so I can't build for ppc anymore (which
is why this didn't get spotted on commit).

James

Re: linux-next: build failure after merge of the scsi tree

[Stephen Rothwell]

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

Hi James,

On Wed, 10 Feb 2010 17:16:16 -0500 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> Sorry, my powerstation isn't working (orange warning light) and I can't
> seem to get anyone to repair it, so I can't build for ppc anymore (which
> is why this didn't get spotted on commit).

There are some (kernel building only) cross compilers at
http://bakeyournoodle.com/cross/ .  (yes, I know they are not PARISC
hosted :-))

That being said, I don't expect every maintainer to cross build very
much, just to react when they get problem reports. ;-)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: build failure after merge of the scsi tree

[Stephen Rothwell]

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

Hi James,

On Wed, 10 Feb 2010 17:16:16 -0500 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Wed, 2010-02-10 at 12:33 +1100, Stephen Rothwell wrote:
> > 
> > After merging the scsi tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > drivers/scsi/lpfc/lpfc_bsg.c: In function 'lpfc_bsg_diag_mode':
> > drivers/scsi/lpfc/lpfc_bsg.c:1496: error: implicit declaration of function 'msleep'
> > 
> > Caused by commit 3b5dd52aaffd291edea9f939ed46a960b240bb45 ("[SCSI] lpfc
> > 8.3.8: (BSG4) Add new vendor specific BSG Commands").
> > 
> > Missing include of linux/delay.h?
> 
> Looks to be exactly the problem.  delay.h gets pulled into some of the
> generic headers on x86, but not on ppc.
> 
> Sorry, my powerstation isn't working (orange warning light) and I can't
> seem to get anyone to repair it, so I can't build for ppc anymore (which
> is why this didn't get spotted on commit).

This is still broken ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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