Skip to contentSkip to conversation

ib_srpt: depend on INFINIBAND_ADDR_TRANS

PATCH In review Greg Thelen 3 participants 6 messages Apr 25, 2018 – May 4, 2018

Subsystems (2)
InfiniBand SCSI RDMA protocol (SRP) target
lore
Share & tools
lore

Greg Thelen

author
#0 lore raw

PATCH 3/5 ib_srpt: depend on INFINIBAND_ADDR_TRANS

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS.

Signed-off-by Greg Thelen <[email protected]>
Cc Tarick Bedeir <[email protected]>
---
 drivers/infiniband/ulp/srpt/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/ulp/srpt/Kconfig +1 -1
index 31ee83d528d9..fb8b7182f05e 100644
@@ -1,6 +1,6 @@
 config INFINIBAND_SRPT
 	tristate "InfiniBand SCSI RDMA Protocol target support"
-	depends on INFINIBAND && TARGET_CORE
+	depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE
 	---help---
 
 	  Support for the SCSI RDMA Protocol (SRP) Target driver. The
Signature · 1 line
2.17.0.441.gb46fe60e1d-goog
#1 lore raw
Quoted 13 lines · Greg Thelen

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS.

Signed-off-by Greg Thelen <[email protected]>
Cc Tarick Bedeir <[email protected]>
 drivers/infiniband/ulp/srpt/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/ulp/srpt/Kconfig +1 -0
index 31ee83d528d9..fb8b7182f05e 100644
+++ b/drivers/infiniband/ulp/srpt/Kconfig

drivers/infiniband/ulp/srpt/Kconfig line 3

Quoted 4 lines
drivers/infiniband/ulp/srpt/Kconfig +1 -1
@@ -1,6 +1,6 @@
 config INFINIBAND_SRPT
 	tristate "InfiniBand SCSI RDMA Protocol target support"
-	depends on INFINIBAND && TARGET_CORE
+	depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE

Isn't INFINIBAND && INFINIBAND_ADDR_TRANS a bit redundant? Can't have INFINIBAND_ADDR_TRANS without INFINIBAND.

Jason

author
#2 lore raw
Quoted 11 lines · Jason Gunthorpe

Review

Quoted 10 lines · Greg Thelen

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS.

Signed-off-by Greg Thelen <[email protected]>
Cc Tarick Bedeir <[email protected]>
 drivers/infiniband/ulp/srpt/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/infiniband/ulp/srpt/Kconfig

Quoted 10 lines

drivers/infiniband/ulp/srpt/Kconfig line 3

Quoted 7 lines

index 31ee83d528d9..fb8b7182f05e 100644
+++ b/drivers/infiniband/ulp/srpt/Kconfig

drivers/infiniband/ulp/srpt/Kconfig +1 -1
@@ -1,6 +1,6 @@
 config INFINIBAND_SRPT
      tristate "InfiniBand SCSI RDMA Protocol target support"
-     depends on INFINIBAND && TARGET_CORE
+     depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE

Isn't INFINIBAND && INFINIBAND_ADDR_TRANS a bit redundant? Can't have INFINIBAND_ADDR_TRANS without INFINIBAND.

By kconfig INFINIBAND_ADDR_TRANS depends on INFINIBAND. So yes, it seems redundant. I don't know if anyone has designs to break this dependency and allow for ADDR_TRANS without INFINIBAND. Assuming not, I'd be willing to amend my series removing redundant INFINIBAND and a followup series to remove it from similar depends. Though I'm not familiar with rdma dev tree lifecycle. Is rdma/for-rc a throw away branch (akin to linux-next), or will it be merged into linus/master? If throwaway, then we can amend its patches, otherwise followups will be needed.

Let me know what you'd prefer. Thanks.

FYI from v4.17-rc3:
drivers/staging/lustre/lnet/Kconfig: depends on LNET && PCI && INFINIBAND && INFINIBAND_ADDR_TRANS

net/9p/Kconfig:       depends on INET && INFINIBAND && INFINIBAND_ADDR_TRANS
net/rds/Kconfig:      depends on RDS && INFINIBAND && INFINIBAND_ADDR_TRANS
net/sunrpc/Kconfig:   depends on SUNRPC && INFINIBAND &&

INFINIBAND_ADDR_TRANS

#3 lore raw
Quoted 25 lines · Greg Thelen
Quoted 11 lines · Jason Gunthorpe

Review

Quoted 10 lines · Greg Thelen

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS.

Signed-off-by Greg Thelen <[email protected]>
Cc Tarick Bedeir <[email protected]>
 drivers/infiniband/ulp/srpt/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/infiniband/ulp/srpt/Kconfig

Quoted 9 lines

drivers/infiniband/ulp/srpt/Kconfig line 3

Quoted 7 lines

index 31ee83d528d9..fb8b7182f05e 100644
+++ b/drivers/infiniband/ulp/srpt/Kconfig

drivers/infiniband/ulp/srpt/Kconfig +1 -1
@@ -1,6 +1,6 @@
 config INFINIBAND_SRPT
      tristate "InfiniBand SCSI RDMA Protocol target support"
-     depends on INFINIBAND && TARGET_CORE
+     depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE

Isn't INFINIBAND && INFINIBAND_ADDR_TRANS a bit redundant? Can't have INFINIBAND_ADDR_TRANS without INFINIBAND.

Quoted 3 lines

By kconfig INFINIBAND_ADDR_TRANS depends on INFINIBAND. So yes, it seems redundant. I don't know if anyone has designs to break this dependency and allow for ADDR_TRANS without INFINIBAND.

No, not at the moment (and I'm not sure we ever would, it would only happen if the subsystem itself became something like RDMA and INFINIBAND specifically related only to the INFINIBAND link layer support, in which case you might want to enable RoCE without INFINIBAND or something like that, but no one has plans to do that as far as I'm aware).

Quoted 6 lines

Assuming not, I'd be willing to
amend my series removing redundant INFINIBAND and a followup series to remove it from similar depends. Though I'm not familiar with rdma dev tree lifecycle. Is rdma/for-rc a throw away branch (akin to linux-next), or will it be merged into linus/master? If throwaway, then we can amend its patches, otherwise followups will be needed.

Followups will be needed.

Quoted 9 lines

Let me know what you'd prefer. Thanks.

FYI from v4.17-rc3:
drivers/staging/lustre/lnet/Kconfig: depends on LNET && PCI && INFINIBAND && INFINIBAND_ADDR_TRANS

net/9p/Kconfig:       depends on INET && INFINIBAND && INFINIBAND_ADDR_TRANS
net/rds/Kconfig:      depends on RDS && INFINIBAND && INFINIBAND_ADDR_TRANS
net/sunrpc/Kconfig:   depends on SUNRPC && INFINIBAND &&

INFINIBAND_ADDR_TRANS

Signature · 3 lines
Doug Ledford <[email protected]>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
#4 lore raw
In reply to Greg Thelen
Quoted 34 lines · Greg Thelen
Quoted 11 lines · Jason Gunthorpe

Review

Quoted 10 lines · Greg Thelen

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS.

Signed-off-by Greg Thelen <[email protected]>
Cc Tarick Bedeir <[email protected]>
 drivers/infiniband/ulp/srpt/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/infiniband/ulp/srpt/Kconfig

Quoted 10 lines

drivers/infiniband/ulp/srpt/Kconfig line 3

Quoted 7 lines

index 31ee83d528d9..fb8b7182f05e 100644
+++ b/drivers/infiniband/ulp/srpt/Kconfig

drivers/infiniband/ulp/srpt/Kconfig +1 -1
@@ -1,6 +1,6 @@
 config INFINIBAND_SRPT
      tristate "InfiniBand SCSI RDMA Protocol target support"
-     depends on INFINIBAND && TARGET_CORE
+     depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE

Isn't INFINIBAND && INFINIBAND_ADDR_TRANS a bit redundant? Can't have INFINIBAND_ADDR_TRANS without INFINIBAND.

By kconfig INFINIBAND_ADDR_TRANS depends on INFINIBAND. So yes, it seems redundant. I don't know if anyone has designs to break this dependency and allow for ADDR_TRANS without INFINIBAND. Assuming not, I'd be willing to amend my series removing redundant INFINIBAND and a followup series to remove it from similar depends. Though I'm not familiar with rdma dev tree lifecycle. Is rdma/for-rc a throw away branch (akin to linux-next), or will it be merged into linus/master? If throwaway, then we can amend its patches, otherwise followups will be needed.

Quoted 1 line

Let me know what you'd prefer. Thanks.

I think a single update patch to fix all of these, and the pre-existing ones would be great

Jason

author
#5 lore raw
Quoted 5 lines · Jason Gunthorpe
Quoted 4 lines · Greg Thelen
Quoted 2 lines · Jason Gunthorpe
Quoted 1 line · Greg Thelen

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided

symbols.

Quoted 18 lines
Quoted 18 lines
Quoted 9 lines

Review

Quoted 9 lines

So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS.

Signed-off-by Greg Thelen <[email protected]>
Cc Tarick Bedeir <[email protected]>
 drivers/infiniband/ulp/srpt/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/infiniband/ulp/srpt/Kconfig

Quoted 7 lines
Quoted 7 lines

index 31ee83d528d9..fb8b7182f05e 100644
+++ b/drivers/infiniband/ulp/srpt/Kconfig

drivers/infiniband/ulp/srpt/Kconfig +1 -1
@@ -1,6 +1,6 @@
 config INFINIBAND_SRPT
      tristate "InfiniBand SCSI RDMA Protocol target support"
-     depends on INFINIBAND && TARGET_CORE
+     depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines

Isn't INFINIBAND && INFINIBAND_ADDR_TRANS a bit redundant? Can't have INFINIBAND_ADDR_TRANS without INFINIBAND.

By kconfig INFINIBAND_ADDR_TRANS depends on INFINIBAND. So yes, it

seems

Quoted 1 line
Quoted 1 line

redundant. I don't know if anyone has designs to break this dependency

and

Quoted 1 line
Quoted 1 line

allow for ADDR_TRANS without INFINIBAND. Assuming not, I'd be willing

to

Quoted 2 lines
Quoted 2 lines

amend my series removing redundant INFINIBAND and a followup series to remove it from similar depends. Though I'm not familiar with rdma dev

tree

Quoted 8 lines
Quoted 5 lines

lifecycle. Is rdma/for-rc a throw away branch (akin to linux-next), or will it be merged into linus/master? If throwaway, then we can amend its patches, otherwise followups will be needed.

Let me know what you'd prefer. Thanks.

I think a single update patch to fix all of these, and the pre-existing ones would be great

I just posted the cleanup: https://lkml.org/lkml/2018/5/3/1045