[PATCH scsi] libcxgbi : support ipv6 address host_param

[Anish Bhatt]

libcxgbi was always returning an ipv4 address for ISCSI_HOST_PARAM_IPADDRESS,
return appropriate address based on address family

Signed-off-by: Anish Bhatt <***@chelsio.com>
Signed-off-by: Karen Xie <***@chelsio.com>
---
drivers/scsi/cxgbi/libcxgbi.c | 42 +++++++++++++++++++++++++++++++++++++-----
drivers/scsi/cxgbi/libcxgbi.h | 5 -----
2 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 6a2001d..403330a 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -397,6 +397,35 @@ EXPORT_SYMBOL_GPL(cxgbi_hbas_add);
* If the source port is outside our allocation range, the caller is
* responsible for keeping track of their port usage.
*/
+
+static struct cxgbi_sock *find_sock_on_port(struct cxgbi_device *cdev,
+ unsigned char port_id)
+{
+ struct cxgbi_ports_map *pmap = &cdev->pmap;
+ unsigned int i;
+ unsigned int used;
+
+ if (!pmap->max_connect || !pmap->used)
+ return NULL;
+
+ spin_lock_bh(&pmap->lock);
+ used = pmap->used;
+ for (i = 0; used && i < pmap->max_connect; i++) {
+ struct cxgbi_sock *csk = pmap->port_csk[i];
+
+ if (csk) {
+ if (csk->port_id == port_id) {
+ spin_unlock_bh(&pmap->lock);
+ return csk;
+ }
+ used--;
+ }
+ }
+ spin_unlock_bh(&pmap->lock);
+
+ return NULL;
+}
+
static int sock_get_port(struct cxgbi_sock *csk)
{
struct cxgbi_device *cdev = csk->cdev;
@@ -747,6 +776,7 @@ static struct cxgbi_sock *cxgbi_check_route6(struct sockaddr *dst_addr)
csk->daddr6.sin6_addr = daddr6->sin6_addr;
csk->daddr6.sin6_port = daddr6->sin6_port;
csk->daddr6.sin6_family = daddr6->sin6_family;
+ csk->saddr6.sin6_family = daddr6->sin6_family;
csk->saddr6.sin6_addr = pref_saddr;

neigh_release(n);
@@ -2645,12 +2675,14 @@ int cxgbi_get_host_param(struct Scsi_Host *shost, enum iscsi_host_param param,
break;
case ISCSI_HOST_PARAM_IPADDRESS:
{
- __be32 addr;
-
- addr = cxgbi_get_iscsi_ipv4(chba);
- len = sprintf(buf, "%pI4", &addr);
+ struct cxgbi_sock *csk = find_sock_on_port(chba->cdev,
+ chba->port_id);
+ if (csk) {
+ len = sprintf(buf, "%pIS",
+ (struct sockaddr *)&csk->saddr);
+ }
log_debug(1 << CXGBI_DBG_ISCSI,
- "hba %s, ipv4 %pI4.\n", chba->ndev->name, &addr);
+ "hba %s, addr %s.\n", chba->ndev->name, buf);
break;
}
default:
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 1d98fad..2c7cb1c 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -700,11 +700,6 @@ static inline void cxgbi_set_iscsi_ipv4(struct cxgbi_hba *chba, __be32 ipaddr)
chba->ndev->name);
}

-static inline __be32 cxgbi_get_iscsi_ipv4(struct cxgbi_hba *chba)
-{
- return chba->ipv4addr;
-}
-
struct cxgbi_device *cxgbi_device_register(unsigned int, unsigned int);
void cxgbi_device_unregister(struct cxgbi_device *);
void cxgbi_device_unregister_all(unsigned int flag);

[Anish Bhatt]

I actually wanted to get some clarification on how the branches on scsi-queue
work. The core/drivers separation is easy enough, but the current branches
are confusing. If say I am submitting a bug fix for the next 3.17 release, what
branch should I be basing my changes on ? Is there a preferred procedure for
submitting bug fixes vs new features ?
-Anish--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[h***@infradead.org]

Post by Anish Bhatt
I actually wanted to get some clarification on how the branches on scsi-queue
work. The core/drivers separation is easy enough, but the current branches
are confusing. If say I am submitting a bug fix for the next 3.17 release, what
branch should I be basing my changes on ? Is there a preferred procedure for
submitting bug fixes vs new features ?

Anything that is an urgent and/or very small fix should just be against
Linus' current tree and will go into the drivers branch for that tree.

Anything bigger and/or less urgent should be sent against the drivers
branch for the next release.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[h***@infradead.org]

Post by h***@infradead.org
Anything that is an urgent and/or very small fix should just be against
Linus' current tree and will go into the drivers branch for that tree.
Anything bigger and/or less urgent should be sent against the drivers
branch for the next release.

Oh, and anything that should go into the current -rc should have an
indicator for that, preferably in the [0/n] intro mail.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Anish Bhatt]

Aah, thanks for the clarification. I have made mistakenly made this patch
against drivers-for-3.18 then, but it applies cleanly to drivers-for-3.17 as
well, please apply this to drivers-for-3.17.
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[h***@infradead.org]

Post by Anish Bhatt
Aah, thanks for the clarification. I have made mistakenly made this patch
against drivers-for-3.18 then, but it applies cleanly to drivers-for-3.17 as
well, please apply this to drivers-for-3.17.

Linux 3.17 has been released. The current merge window is the one for
3.18, expected to be closed in about a week. So urgent patches go into
that, maybe with a Cc to ***@vger.kernel.org if they fix regressions.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Anish Bhatt]

Post by h***@infradead.org

Post by h***@infradead.org
Anything that is an urgent and/or very small fix should just be against
Linus' current tree and will go into the drivers branch for that tree.
Anything bigger and/or less urgent should be sent against the drivers
branch for the next release.

Linux 3.17 has been released. The current merge window is the one for
3.18, expected to be closed in about a week. So urgent patches go into

I may not have understood you correctly. My understanding is "Linus' current
tree and will go into the drivers branch for that tree." would imply
scsi-queue/drivers-for-3.17.

"drivers branch for next release" would imply be scsi-queue/drivers-for-3.18

So all patches go into drivers-for-3.18, but the ones fixing regressions need a
CC to ***@vger.kernel.org ? Either way, drivers-for-3.18 is fine. Please
apply there
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mike Christie]

Post by Anish Bhatt
libcxgbi was always returning an ipv4 address for ISCSI_HOST_PARAM_IPADDRESS,
return appropriate address based on address family
---
drivers/scsi/cxgbi/libcxgbi.c | 42 +++++++++++++++++++++++++++++++++++++-----
drivers/scsi/cxgbi/libcxgbi.h | 5 -----
2 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 6a2001d..403330a 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -397,6 +397,35 @@ EXPORT_SYMBOL_GPL(cxgbi_hbas_add);
* If the source port is outside our allocation range, the caller is
* responsible for keeping track of their port usage.
*/
+
+static struct cxgbi_sock *find_sock_on_port(struct cxgbi_device *cdev,
+ unsigned char port_id)
+{
+ struct cxgbi_ports_map *pmap = &cdev->pmap;
+ unsigned int i;
+ unsigned int used;
+
+ if (!pmap->max_connect || !pmap->used)
+ return NULL;
+
+ spin_lock_bh(&pmap->lock);
+ used = pmap->used;
+ for (i = 0; used && i < pmap->max_connect; i++) {
+ struct cxgbi_sock *csk = pmap->port_csk[i];
+
+ if (csk) {
+ if (csk->port_id == port_id) {
+ spin_unlock_bh(&pmap->lock);
+ return csk;
+ }
+ used--;
+ }
+ }
+ spin_unlock_bh(&pmap->lock);
+
+ return NULL;
+}
+
static int sock_get_port(struct cxgbi_sock *csk)
{
struct cxgbi_device *cdev = csk->cdev;
@@ -747,6 +776,7 @@ static struct cxgbi_sock *cxgbi_check_route6(struct sockaddr *dst_addr)
csk->daddr6.sin6_addr = daddr6->sin6_addr;
csk->daddr6.sin6_port = daddr6->sin6_port;
csk->daddr6.sin6_family = daddr6->sin6_family;
+ csk->saddr6.sin6_family = daddr6->sin6_family;
csk->saddr6.sin6_addr = pref_saddr;
neigh_release(n);
@@ -2645,12 +2675,14 @@ int cxgbi_get_host_param(struct Scsi_Host *shost, enum iscsi_host_param param,
break;
{
- __be32 addr;
-
- addr = cxgbi_get_iscsi_ipv4(chba);
- len = sprintf(buf, "%pI4", &addr);
+ struct cxgbi_sock *csk = find_sock_on_port(chba->cdev,
+ chba->port_id);
+ if (csk) {
+ len = sprintf(buf, "%pIS",
+ (struct sockaddr *)&csk->saddr);
+ }
log_debug(1 << CXGBI_DBG_ISCSI,
- "hba %s, ipv4 %pI4.\n", chba->ndev->name, &addr);
+ "hba %s, addr %s.\n", chba->ndev->name, buf);
break;
}
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 1d98fad..2c7cb1c 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -700,11 +700,6 @@ static inline void cxgbi_set_iscsi_ipv4(struct cxgbi_hba *chba, __be32 ipaddr)
chba->ndev->name);
}
-static inline __be32 cxgbi_get_iscsi_ipv4(struct cxgbi_hba *chba)
-{
- return chba->ipv4addr;
-}
-
struct cxgbi_device *cxgbi_device_register(unsigned int, unsigned int);
void cxgbi_device_unregister(struct cxgbi_device *);
void cxgbi_device_unregister_all(unsigned int flag);

Looks ok.

Reviewed-by: Mike Christie <***@cs.wisc.edu>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html