Re: [PATCH v4 04/25] virtio: defer config changed notifications

2014-10-14 Thread Rusty Russell 
Michael S. Tsirkin m...@redhat.com writes:
 Defer config changed notifications that arrive during
 probe/scan/freeze/restore.

 This will allow drivers to set DRIVER_OK earlier, without worrying about
 racing with config change interrupts.

 This change will also benefit old hypervisors (before 2009)
 that send interrupts without checking DRIVER_OK: previously,
 the callback could race with driver-specific initialization.

 This will also help simplify drivers.

But AFAICT you never *read* dev-config_changed.

You unconditionally trigger a config_changed event in
virtio_config_enable().  That's a bit weird, but probably OK.

How about the following change (on top of your patch).  I
think the renaming is clearer, and note the added if() test in
virtio_config_enable().

If you approve, I'll fold it in.

Cheers,
Rusty.

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 2536701b098b..df598dd8c5c8 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -122,7 +122,7 @@ static void __virtio_config_changed(struct virtio_device 
*dev)
struct virtio_driver *drv = drv_to_virtio(dev-dev.driver);
 
if (!dev-config_enabled)
-   dev-config_changed = true;
+   dev-config_change_pending = true;
else if (drv  drv-config_changed)
drv-config_changed(dev);
 }
@@ -148,8 +148,9 @@ static void virtio_config_enable(struct virtio_device *dev)
 {
spin_lock_irq(dev-config_lock);
dev-config_enabled = true;
-   __virtio_config_changed(dev);
-   dev-config_changed = false;
+   if (dev-config_change_pending)
+   __virtio_config_changed(dev);
+   dev-config_change_pending = false;
spin_unlock_irq(dev-config_lock);
 }
 
@@ -253,7 +254,7 @@ int register_virtio_device(struct virtio_device *dev)
 
spin_lock_init(dev-config_lock);
dev-config_enabled = false;
-   dev-config_changed = false;
+   dev-config_change_pending = false;
 
/* We always start by resetting the device, in case a previous
 * driver messed it up.  This also tests that code path a little. */
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 5636b119dc25..65261a7244fc 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -80,7 +80,7 @@ bool virtqueue_is_broken(struct virtqueue *vq);
  * @index: unique position on the virtio bus
  * @failed: saved value for CONFIG_S_FAILED bit (for restore)
  * @config_enabled: configuration change reporting enabled
- * @config_changed: configuration change reported while disabled
+ * @config_change_pending: configuration change reported while disabled
  * @config_lock: protects configuration change reporting
  * @dev: underlying device.
  * @id: the device type identification (used to match it with a driver).
@@ -94,7 +94,7 @@ struct virtio_device {
int index;
bool failed;
bool config_enabled;
-   bool config_changed;
+   bool config_change_pending;
spinlock_t config_lock;
struct device dev;
struct virtio_device_id id;
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 04/25] virtio: defer config changed notifications

2014-10-14 Thread Michael S. Tsirkin 
On Tue, Oct 14, 2014 at 11:01:12AM +1030, Rusty Russell wrote:
 Michael S. Tsirkin m...@redhat.com writes:
  Defer config changed notifications that arrive during
  probe/scan/freeze/restore.
 
  This will allow drivers to set DRIVER_OK earlier, without worrying about
  racing with config change interrupts.
 
  This change will also benefit old hypervisors (before 2009)
  that send interrupts without checking DRIVER_OK: previously,
  the callback could race with driver-specific initialization.
 
  This will also help simplify drivers.
 
 But AFAICT you never *read* dev-config_changed.
 
 You unconditionally trigger a config_changed event in
 virtio_config_enable().  That's a bit weird, but probably OK.
 
 How about the following change (on top of your patch).  I
 think the renaming is clearer, and note the added if() test in
 virtio_config_enable().
 
 If you approve, I'll fold it in.
 
 Cheers,
 Rusty.

Hi Rusty,
I'm okay with both changes.
You can fold it in if you prefer, or just make it a patch on top.

 diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
 index 2536701b098b..df598dd8c5c8 100644
 --- a/drivers/virtio/virtio.c
 +++ b/drivers/virtio/virtio.c
 @@ -122,7 +122,7 @@ static void __virtio_config_changed(struct virtio_device 
 *dev)
   struct virtio_driver *drv = drv_to_virtio(dev-dev.driver);
  
   if (!dev-config_enabled)
 - dev-config_changed = true;
 + dev-config_change_pending = true;
   else if (drv  drv-config_changed)
   drv-config_changed(dev);
  }
 @@ -148,8 +148,9 @@ static void virtio_config_enable(struct virtio_device 
 *dev)
  {
   spin_lock_irq(dev-config_lock);
   dev-config_enabled = true;
 - __virtio_config_changed(dev);
 - dev-config_changed = false;
 + if (dev-config_change_pending)
 + __virtio_config_changed(dev);
 + dev-config_change_pending = false;
   spin_unlock_irq(dev-config_lock);
  }
  
 @@ -253,7 +254,7 @@ int register_virtio_device(struct virtio_device *dev)
  
   spin_lock_init(dev-config_lock);
   dev-config_enabled = false;
 - dev-config_changed = false;
 + dev-config_change_pending = false;
  
   /* We always start by resetting the device, in case a previous
* driver messed it up.  This also tests that code path a little. */
 diff --git a/include/linux/virtio.h b/include/linux/virtio.h
 index 5636b119dc25..65261a7244fc 100644
 --- a/include/linux/virtio.h
 +++ b/include/linux/virtio.h
 @@ -80,7 +80,7 @@ bool virtqueue_is_broken(struct virtqueue *vq);
   * @index: unique position on the virtio bus
   * @failed: saved value for CONFIG_S_FAILED bit (for restore)
   * @config_enabled: configuration change reporting enabled
 - * @config_changed: configuration change reported while disabled
 + * @config_change_pending: configuration change reported while disabled
   * @config_lock: protects configuration change reporting
   * @dev: underlying device.
   * @id: the device type identification (used to match it with a driver).
 @@ -94,7 +94,7 @@ struct virtio_device {
   int index;
   bool failed;
   bool config_enabled;
 - bool config_changed;
 + bool config_change_pending;
   spinlock_t config_lock;
   struct device dev;
   struct virtio_device_id id;
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Concurrent SG_SCSI_RESET ioctls

2014-10-14 Thread Christoph Hellwig 
On Sat, Oct 11, 2014 at 10:06:47PM +, Elliott, Robert (Server Storage) 
wrote:
 Thanks.  That's a bit better, but sg_reset can now run into
 No such device errors.

That's the -ENODEV we return if another reset is in progress.  Given
that I suspect sg_reset is the prime if not only user of this interface
I'm happy to change the error code we return here to anything Doug
agrees to.

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SG_SCSI_RESET ioctl reset escalation

2014-10-14 Thread Christoph Hellwig 
On Mon, Oct 13, 2014 at 10:24:01PM +, Elliott, Robert (Server Storage) 
wrote:
 Those stronger reset levels affect multiple devices,
 which may or may not be desired.
 
 sg-reset includes a --no-esc option to ask the kernel
 to not escalate resets, based on a February 2013 thread,
 but the matching kernel changes were never merged.
 
 Original issue:
 http://marc.info/?l=linux-scsim=136000904311597w=2
 
 Suggested fix:
 http://marc.info/?l=linux-scsim=136095718729372w=2
 
 Could that fix be revived?

I'd be happy to merge it if Doug can resend it against a current
tree, preferably my scsi-ioctl branch from the previous thread.

While we're at it: Doug, can you replace the addition of the constants
in the switch with a logical or - that's the more common kernel style.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] scsi: Resolve some missing-field-initializers warnings

2014-10-14 Thread Jeff Kirsher 
From: Mark Rustad mark.d.rus...@intel.com

Resolve some missing-field-initializers warnings by using
designated initialization.

Signed-off-by: Mark Rustad mark.d.rus...@intel.com
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
---
 drivers/scsi/scsi_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index db8c449..4d59256 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -47,7 +47,7 @@ struct scsi_host_sg_pool {
mempool_t   *pool;
 };
 
-#define SP(x) { x, sgpool- __stringify(x) }
+#define SP(x) { .size = x, sgpool- __stringify(x) }
 #if (SCSI_MAX_SG_SEGMENTS  32)
 #error SCSI_MAX_SG_SEGMENTS is too small (must be 32 or greater)
 #endif
-- 
1.9.3

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sparc ESP problem with blk-mq

2014-10-14 Thread Jens Axboe 

(resent with correct linux-scsi address)

On 2014-10-13 16:07, Meelis Roos wrote:

I turned on blk-mq for all my test machines today and got a failure from
Sun Ultra 1 with Sparc ESP SCSI (dmesg below). Booting with
scsi_mod.use_blk_mq=0 fixes the problem. The problem is reproducible.


[snip]


[   63.244199] esp: esp0, regs[1ffe880:1ffe840] irq[10]
[   63.310055] esp: esp0 is a FAS100A, 40 MHz (ccf=0), SCSI ID 7
[   66.383895] scsi host0: esp
[  148.437533] scsi 0:0:0:0: timing out command, waited 82s
[  149.674112] ESP: unexpected IREG 40
[  149.713889] esp: esp0: Dumping command log
[  149.762847] esp: esp0: ent[14] CMD val[01] sreg[93] seqreg[04] sreg2[00] 
ireg[18] ss[00] event[0d]


[snip]

Christoph, any idea on this? The command just times out, for some 
reason. Only thing I could think of was related to perhaps missing 
bouncing or similar, but I don't think that's the case. But the hba must 
not like the request somehow. Or perhaps it sets up the wrong number of 
segments.


--
Jens Axboe

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)

2014-10-14 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=85151

--- Comment #14 from Tommy Apel tommyape...@gmail.com ---
This problem is seen on 3.14.21 aswell with expander discovery failure running
Adaptec firmware 1.2.0 Build 10624

I applied the patch stated above and it fixed the problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Concurrent SG_SCSI_RESET ioctls

2014-10-14 Thread Douglas Gilbert 

On 14-10-14 07:13 AM, Christoph Hellwig wrote:

On Sat, Oct 11, 2014 at 10:06:47PM +, Elliott, Robert (Server Storage) 
wrote:

Thanks.  That's a bit better, but sg_reset can now run into
No such device errors.


That's the -ENODEV we return if another reset is in progress.  Given
that I suspect sg_reset is the prime if not only user of this interface
I'm happy to change the error code we return here to anything Doug
agrees to.


I don't mind if you change it. However I plan to release
sg3_utils-1.40 in the next 2 or 3 weeks, so that would
be the earliest a revised sg_reset would be available for
distros. Improving error reports is something I always
like to do (so ENODEV for the in progress case seems a
bit strident).

On the other hand, the existing sg_reset code with --no-esc
has been in place since sg3_utils-1.36 [20130531]. So there
is a good chance current distributions have that version or
later.

Doug Gilbert

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

2014-10-14 Thread Martin K. Petersen 
 Sitsofe == Sitsofe Wheeler sits...@gmail.com writes:

Sitsofe A previous patch attempted to add a quirk to workaround this
Sitsofe but the quirk was only enabled after the features had been
Sitsofe scanned for, wouldn't work for small disks 

What does that mean, exactly?

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag

2014-10-14 Thread Martin K. Petersen 
 Sitsofe == Sitsofe Wheeler sits...@gmail.com writes:

Sitsofe Microsoft Hyper-V virtual disks currently only claim SPC-2
Sitsofe compliance causing the kernel skip checks for features such as
Sitsofe thin provisioning even though the virtual disk advertises them.

Last time around we identified this as a problem with Microsoft's
interpretation of the T10 SBC spec. And they promised that they are
going to fix that.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/3] scsi: add try_rc16 blacklist flag

2014-10-14 Thread KY Srinivasan 


 -Original Message-
 From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
 Sent: Tuesday, October 14, 2014 6:08 PM
 To: Sitsofe Wheeler
 Cc: KY Srinivasan; Haiyang Zhang; Christoph Hellwig; Hannes Reinecke; linux-
 s...@vger.kernel.org; linux-ker...@vger.kernel.org;
 de...@linuxdriverproject.org; James E.J. Bottomley
 Subject: Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag
 
  Sitsofe == Sitsofe Wheeler sits...@gmail.com writes:
 
 Sitsofe Microsoft Hyper-V virtual disks currently only claim SPC-2
 Sitsofe compliance causing the kernel skip checks for features such as
 Sitsofe thin provisioning even though the virtual disk advertises them.
 
 Last time around we identified this as a problem with Microsoft's
 interpretation of the T10 SBC spec. And they promised that they are going to
 fix that.

It has been fixed in windows 10 and a bug has been opened for earlier hosts.

K. Y
 
 --
 Martin K. PetersenOracle Linux Engineering
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v2 1/4] cxgb4i : Remove duplicated CLIP handling code

2014-10-14 Thread Anish Bhatt 
cxgb4 already handles CLIP updates from a previous changeset for iw_cxgb4,
there is no need to have this functionality in cxgb4i. Remove duplicated code

Signed-off-by: Anish Bhatt an...@chelsio.com
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |   7 ++
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c  | 133 
 2 files changed, 7 insertions(+), 133 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index fed8f26..411acf0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4490,6 +4490,13 @@ static int update_root_dev_clip(struct net_device *dev)
return ret;
 
/* Parse all bond and vlan devices layered on top of the physical dev */
+   root_dev = netdev_master_upper_dev_get_rcu(dev);
+   if (root_dev) {
+   ret = update_dev_clip(root_dev, dev);
+   if (ret)
+   return ret;
+   }
+
for (i = 0; i  VLAN_N_VID; i++) {
root_dev = __vlan_find_dev_deep_rcu(dev, htons(ETH_P_8021Q), i);
if (!root_dev)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c 
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 02e69e7..18d0d1c 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1635,129 +1635,6 @@ static int cxgb4i_ddp_init(struct cxgbi_device *cdev)
return 0;
 }
 
-#if IS_ENABLED(CONFIG_IPV6)
-static int cxgbi_inet6addr_handler(struct notifier_block *this,
-  unsigned long event, void *data)
-{
-   struct inet6_ifaddr *ifa = data;
-   struct net_device *event_dev = ifa-idev-dev;
-   struct cxgbi_device *cdev;
-   int ret = NOTIFY_DONE;
-
-   if (event_dev-priv_flags  IFF_802_1Q_VLAN)
-   event_dev = vlan_dev_real_dev(event_dev);
-
-   cdev = cxgbi_device_find_by_netdev_rcu(event_dev, NULL);
-
-   if (!cdev)
-   return ret;
-
-   switch (event) {
-   case NETDEV_UP:
-   ret = cxgb4_clip_get(event_dev,
-(const struct in6_addr *)
-((ifa)-addr.s6_addr));
-   if (ret  0)
-   return ret;
-
-   ret = NOTIFY_OK;
-   break;
-
-   case NETDEV_DOWN:
-   cxgb4_clip_release(event_dev,
-  (const struct in6_addr *)
-  ((ifa)-addr.s6_addr));
-   ret = NOTIFY_OK;
-   break;
-
-   default:
-   break;
-   }
-
-   return ret;
-}
-
-static struct notifier_block cxgbi_inet6addr_notifier = {
-   .notifier_call = cxgbi_inet6addr_handler
-};
-
-/* Retrieve IPv6 addresses from a root device (bond, vlan) associated with
- * a physical device.
- * The physical device reference is needed to send the actual CLIP command.
- */
-static int update_dev_clip(struct net_device *root_dev, struct net_device *dev)
-{
-   struct inet6_dev *idev = NULL;
-   struct inet6_ifaddr *ifa;
-   int ret = 0;
-
-   idev = __in6_dev_get(root_dev);
-   if (!idev)
-   return ret;
-
-   read_lock_bh(idev-lock);
-   list_for_each_entry(ifa, idev-addr_list, if_list) {
-   pr_info(updating the clip for addr %pI6\n,
-   ifa-addr.s6_addr);
-   ret = cxgb4_clip_get(dev, (const struct in6_addr *)
-ifa-addr.s6_addr);
-   if (ret  0)
-   break;
-   }
-
-   read_unlock_bh(idev-lock);
-   return ret;
-}
-
-static int update_root_dev_clip(struct net_device *dev)
-{
-   struct net_device *root_dev = NULL;
-   int i, ret = 0;
-
-   /* First populate the real net device's IPv6 address */
-   ret = update_dev_clip(dev, dev);
-   if (ret)
-   return ret;
-
-   /* Parse all bond and vlan devices layered on top of the physical dev */
-   root_dev = netdev_master_upper_dev_get(dev);
-   if (root_dev) {
-   ret = update_dev_clip(root_dev, dev);
-   if (ret)
-   return ret;
-   }
-
-   for (i = 0; i  VLAN_N_VID; i++) {
-   root_dev = __vlan_find_dev_deep_rcu(dev, htons(ETH_P_8021Q), i);
-   if (!root_dev)
-   continue;
-
-   ret = update_dev_clip(root_dev, dev);
-   if (ret)
-   break;
-   }
-   return ret;
-}
-
-static void cxgbi_update_clip(struct cxgbi_device *cdev)
-{
-   int i;
-
-   rcu_read_lock();
-
-   for (i = 0; i  cdev-nports; i++) {
-   struct net_device *dev = cdev-ports[i];
-   int ret = 0;
-
-   if (dev)
-   ret = update_root_dev_clip(dev);
-   if (ret  0)
-

[PATCH net v2 2/4] cxgb4 : Fix build failure in cxgb4 when ipv6 is disabled/not in-built

2014-10-14 Thread Anish Bhatt 
cxgb4 ipv6 does not guard against ipv6 being disabled, or the standard
ipv6 module vs inbuilt tri-state issue. This was fixed for cxgb4i  iw_cxgb4
but missed for cxgb4.

Signed-off-by: Anish Bhatt an...@chelsio.com
---
 drivers/net/ethernet/chelsio/Kconfig| 2 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/Kconfig 
b/drivers/net/ethernet/chelsio/Kconfig
index c3ce9df..ac6473f 100644
--- a/drivers/net/ethernet/chelsio/Kconfig
+++ b/drivers/net/ethernet/chelsio/Kconfig
@@ -68,7 +68,7 @@ config CHELSIO_T3
 
 config CHELSIO_T4
tristate Chelsio Communications T4/T5 Ethernet support
-   depends on PCI
+   depends on PCI  (IPV6 || IPV6=n)
select FW_LOADER
select MDIO
---help---
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 411acf0..3f60070 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4369,6 +4369,7 @@ EXPORT_SYMBOL(cxgb4_unregister_uld);
  * success (true) if it belongs otherwise failure (false).
  * Called with rcu_read_lock() held.
  */
+#if IS_ENABLED(CONFIG_IPV6)
 static bool cxgb4_netdev(const struct net_device *netdev)
 {
struct adapter *adap;
@@ -4529,6 +4530,7 @@ static void update_clip(const struct adapter *adap)
}
rcu_read_unlock();
 }
+#endif /* IS_ENABLED(CONFIG_IPV6) */
 
 /**
  * cxgb_up - enable the adapter
@@ -4575,7 +4577,9 @@ static int cxgb_up(struct adapter *adap)
t4_intr_enable(adap);
adap-flags |= FULL_INIT_DONE;
notify_ulds(adap, CXGB4_STATE_UP);
+#if IS_ENABLED(CONFIG_IPV6)
update_clip(adap);
+#endif
  out:
return err;
  irq_err:
@@ -6869,14 +6873,18 @@ static int __init cxgb4_init_module(void)
if (ret  0)
debugfs_remove(cxgb4_debugfs_root);
 
+#if IS_ENABLED(CONFIG_IPV6)
register_inet6addr_notifier(cxgb4_inet6addr_notifier);
+#endif
 
return ret;
 }
 
 static void __exit cxgb4_cleanup_module(void)
 {
+#if IS_ENABLED(CONFIG_IPV6)
unregister_inet6addr_notifier(cxgb4_inet6addr_notifier);
+#endif
pci_unregister_driver(cxgb4_driver);
debugfs_remove(cxgb4_debugfs_root);  /* NULL ok */
 }
-- 
2.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v2 3/4] cxgb4i : Fix -Wunused-function warning

2014-10-14 Thread Anish Bhatt 
A bunch of ipv6 related code is left on by default. While this causes no
compilation issues, there is no need to have this enabled by default. Guard
with an ipv6 check, which also takes care of a -Wunused-function warning.

Signed-off-by: Anish Bhatt an...@chelsio.com
---
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 8 
 drivers/scsi/cxgbi/libcxgbi.c  | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c 
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 18d0d1c..df176f0 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -259,6 +259,7 @@ static void send_act_open_req(struct cxgbi_sock *csk, 
struct sk_buff *skb,
cxgb4_l2t_send(csk-cdev-ports[csk-port_id], skb, csk-l2t);
 }
 
+#if IS_ENABLED(CONFIG_IPV6)
 static void send_act_open_req6(struct cxgbi_sock *csk, struct sk_buff *skb,
   struct l2t_entry *e)
 {
@@ -344,6 +345,7 @@ static void send_act_open_req6(struct cxgbi_sock *csk, 
struct sk_buff *skb,
 
cxgb4_l2t_send(csk-cdev-ports[csk-port_id], skb, csk-l2t);
 }
+#endif
 
 static void send_close_req(struct cxgbi_sock *csk)
 {
@@ -781,9 +783,11 @@ static void csk_act_open_retry_timer(unsigned long data)
if (csk-csk_family == AF_INET) {
send_act_open_func = send_act_open_req;
skb = alloc_wr(size, 0, GFP_ATOMIC);
+#if IS_ENABLED(CONFIG_IPV6)
} else {
send_act_open_func = send_act_open_req6;
skb = alloc_wr(size6, 0, GFP_ATOMIC);
+#endif
}
 
if (!skb)
@@ -1335,8 +1339,10 @@ static int init_act_open(struct cxgbi_sock *csk)
 
if (csk-csk_family == AF_INET)
skb = alloc_wr(size, 0, GFP_NOIO);
+#if IS_ENABLED(CONFIG_IPV6)
else
skb = alloc_wr(size6, 0, GFP_NOIO);
+#endif
 
if (!skb)
goto rel_resource;
@@ -1370,8 +1376,10 @@ static int init_act_open(struct cxgbi_sock *csk)
cxgbi_sock_set_state(csk, CTP_ACTIVE_OPEN);
if (csk-csk_family == AF_INET)
send_act_open_req(csk, skb, csk-l2t);
+#if IS_ENABLED(CONFIG_IPV6)
else
send_act_open_req6(csk, skb, csk-l2t);
+#endif
neigh_release(n);
 
return 0;
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 6a2001d..54fa6e0 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -275,6 +275,7 @@ struct cxgbi_device *cxgbi_device_find_by_netdev_rcu(struct 
net_device *ndev,
 }
 EXPORT_SYMBOL_GPL(cxgbi_device_find_by_netdev_rcu);
 
+#if IS_ENABLED(CONFIG_IPV6)
 static struct cxgbi_device *cxgbi_device_find_by_mac(struct net_device *ndev,
 int *port)
 {
@@ -307,6 +308,7 @@ static struct cxgbi_device *cxgbi_device_find_by_mac(struct 
net_device *ndev,
  ndev, ndev-name);
return NULL;
 }
+#endif
 
 void cxgbi_hbas_remove(struct cxgbi_device *cdev)
 {
-- 
2.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v2 0/4] ipv6 and related cleanup for cxgb4/cxgb4i

2014-10-14 Thread Anish Bhatt 
This patch set removes some duplicated/extraneous code from cxgb4i, guards
cxgb4 against compilation failure based on ipv6 tristate, make ipv6 related
code no longer be enabled by default irrespective of ipv6 tristate and fixes
a refcnt issue.
-Anish

v2 : Provide more detailed commit messages, make subject more concise as 
recommended by Dave Miller.

Anish Bhatt (4):
  cxgb4i : Remove duplicated CLIP handling code
  cxgb4 : Fix build failure in cxgb4 when ipv6 is disabled/not in-built
  cxgb4i : Fix -Wunused-function warning
  cxgb4i: Remove duplicate call to dst_neigh_lookup()

 drivers/net/ethernet/chelsio/Kconfig|   2 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |  15 +++
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c  | 146 ++--
 drivers/scsi/cxgbi/libcxgbi.c   |   2 +
 4 files changed, 26 insertions(+), 139 deletions(-)

-- 
2.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v2 0/4] ipv6 and related cleanup for cxgb4/cxgb4i

2014-10-14 Thread David Miller 
From: Anish Bhatt an...@chelsio.com
Date: Tue, 14 Oct 2014 20:07:20 -0700

 This patch set removes some duplicated/extraneous code from cxgb4i, guards
 cxgb4 against compilation failure based on ipv6 tristate, make ipv6 related
 code no longer be enabled by default irrespective of ipv6 tristate and fixes
 a refcnt issue.
 -Anish
 
 v2 : Provide more detailed commit messages, make subject more concise as 
 recommended by Dave Miller.

Much better, series applied, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html