[PATCH 2/7] cxgb3 - fix netpoll hanlder

[PATCH 2/7] cxgb3 - fix netpoll hanlder

[divy]

From: Divy Le Ray <divy@chelsio.com>

Fix netpoll handler to work with line interrupt, msi and msi-x.

Signed-off-by: Divy Le Ray <divy@chelsio.com>
---

 drivers/net/cxgb3/cxgb3_main.c |   12 +++++++++---
 drivers/net/cxgb3/sge.c        |    1 -
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 67b4b21..e0ef724 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2076,10 +2076,16 @@ static void vlan_rx_kill_vid(struct net_
 static void cxgb_netpoll(struct net_device *dev)
 {
 	struct adapter *adapter = dev->priv;
-	struct sge_qset *qs = dev2qset(dev);
+	struct port_info *pi = netdev_priv(dev);
+	int qidx;
 
-	t3_intr_handler(adapter, qs->rspq.polling) (adapter->pdev->irq,
-						    adapter);
+	for (qidx = pi->first_qset; qidx < pi->first_qset + pi->nqsets; qidx++) {
+		struct sge_qset *qs = &adapter->sge.qs[qidx];
+		
+		t3_intr_handler(adapter, qs->rspq.polling) (0, 
+					(adapter->flags & USING_MSIX) ?
+					(void *)qs : (void *)adapter);
+	}
 }
 #endif
 
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 8dd5b1e..a2cfd68 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -2228,7 +2228,6 @@ irqreturn_t t3_sge_intr_msix_napi(int ir
 	struct sge_rspq *q = &qs->rspq;
 
 	spin_lock(&q->lock);
-	BUG_ON(napi_is_scheduled(qs->netdev));
 
 	if (handle_responses(adap, q) < 0)
 		q->unhandled_irqs++;

Re: [PATCH 2/7] cxgb3 - fix netpoll hanlder

[Jeff Garzik]

divy@chelsio.com wrote:
> From: Divy Le Ray <divy@chelsio.com>
> 
> Fix netpoll handler to work with line interrupt, msi and msi-x.
> 
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
> 
>  drivers/net/cxgb3/cxgb3_main.c |   12 +++++++++---
>  drivers/net/cxgb3/sge.c        |    1 -
>  2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
> index 67b4b21..e0ef724 100644
> --- a/drivers/net/cxgb3/cxgb3_main.c
> +++ b/drivers/net/cxgb3/cxgb3_main.c
> @@ -2076,10 +2076,16 @@ static void vlan_rx_kill_vid(struct net_
>  static void cxgb_netpoll(struct net_device *dev)
>  {
>  	struct adapter *adapter = dev->priv;
> -	struct sge_qset *qs = dev2qset(dev);
> +	struct port_info *pi = netdev_priv(dev);
> +	int qidx;
>  
> -	t3_intr_handler(adapter, qs->rspq.polling) (adapter->pdev->irq,
> -						    adapter);
> +	for (qidx = pi->first_qset; qidx < pi->first_qset + pi->nqsets; qidx++) {
> +		struct sge_qset *qs = &adapter->sge.qs[qidx];
> +		
> +		t3_intr_handler(adapter, qs->rspq.polling) (0, 
> +					(adapter->flags & USING_MSIX) ?
> +					(void *)qs : (void *)adapter);

Remove needless casts to void*

Re: [PATCH 2/7] cxgb3 - fix netpoll hanlder

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
>>
>> +        t3_intr_handler(adapter, qs->rspq.polling) (0,
>> +                    (adapter->flags & USING_MSIX) ?
>> +                    (void *)qs : (void *)adapter);
>
> Remove needless casts to void*
The two branches of ?: need to have the same type; without the casts
they'd be "struct sge_qset" and "struct adapter".  Seems a bit cruddy to
have two types passed to one function depending on the MSI state, but
maybe that's OK.

    J

Re: [PATCH 2/7] cxgb3 - fix netpoll hanlder

[Jeff Garzik]

Jeremy Fitzhardinge wrote:
> Jeff Garzik wrote:
>>> +        t3_intr_handler(adapter, qs->rspq.polling) (0,
>>> +                    (adapter->flags & USING_MSIX) ?
>>> +                    (void *)qs : (void *)adapter);
>> Remove needless casts to void*
> The two branches of ?: need to have the same type; without the casts
> they'd be "struct sge_qset" and "struct adapter".  Seems a bit cruddy to
> have two types passed to one function depending on the MSI state, but
> maybe that's OK.

Look at the function argument...

	Jeff

Re: [PATCH 2/7] cxgb3 - fix netpoll hanlder

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
> Look at the function argument... 

Yes, it's void *.  But my point is that C requires the ?: to evaluate to
some specific type, so if you have different types on each side of the :
the compiler can be legitimately upset.  The fact that the whole thing
gets cast to void * is somewhat irrelevant.

    J