Add support of Cavium Liquidio ethernet adapters
Hello Raghu Vatsavayi,
The patch f21fb3ed364b: "Add support of Cavium Liquidio ethernet adapters" from Jun 9, 2015, leads to the following static checker warning:
drivers/net/ethernet/cavium/liquidio/lio_main.c:1013 liquidio_schedule_droq_pkt_handlers()
warn: potential left shift more than type allows '0-63'
drivers/net/ethernet/cavium/liquidio/lio_main.c
996 static void liquidio_schedule_droq_pkt_handlers(struct octeon_device *oct) 997 {
998 struct octeon_device_priv *oct_priv 999 (struct octeon_device_priv *)oct->priv;
1000 u64 oq_no;
This should probably be int. Making it u64 doesn't do anything.
1001 struct octeon_droq *droq;
1002
1003 if (oct->int_status & OCT_DEV_INTR_PKT_DATA) {
1004 for (oq_no = 0; oq_no < MAX_OCTEON_OUTPUT_QUEUES(oct);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^This is either 32 or 64.
1005 oq_no++) {
1006 if (!(oct->droq_intr & BIT_ULL(oq_no)))
1007 continue;
1008
1009 droq = oct->droq[oq_no];
1010
1011 if (droq->ops.poll_mode) {
1012 droq->ops.napi_fn(droq);
1013 oct_priv->napi_mask |= (1 << oq_no);It should be 1ULL << oq_no. But the other bug is tahte ->napi_mask is a long but that will break on 32 bit systems when MAX_OCTEON_OUTPUT_QUEUES() is 64. Is that a possible combination?
1014 } else {
1015 tasklet_schedule(&oct_priv->droq_tasklet);
1016 }
1017 }
1018 }
1019 }regards,
dan carpenter
Please see inline:
Quoted 46 lines
-----Original Message-----
From: Dan Carpenter [mailto:[email protected]]
Sent: Wednesday, November 30, 2016 10:58 AM
To: Vatsavayi, Raghu
Cc: [email protected]; Goutham, Sunil
Subject: [bug report] Add support of Cavium Liquidio ethernet adaptersHello Raghu Vatsavayi,
The patch
f21fb3ed364b: "Add support of Cavium Liquidio ethernet adapters" from Jun 9, 2015, leads to the following static checker warning:
drivers/net/ethernet/cavium/liquidio/lio_main.c:1013liquidio_schedule_droq_pkt_handlers()
warn: potential left shift more than type allows '0-63'
drivers/net/ethernet/cavium/liquidio/lio_main.c
996 static void liquidio_schedule_droq_pkt_handlers(structocteon_device
*oct)
997 {
998 structocteon_device_priv*oct_priv=
999 (structocteon_device_priv*)oct->priv;
1000 u64oq_no;This should probably be int. Making it u64 doesn't do anything.
1001 struct
octeon_droq*droq;
1002
1003 if (oct->int_status&OCT_DEV_INTR_PKT_DATA) {
1004 for (oq_no= 0;oq_no<MAX_OCTEON_OUTPUT_QUEUES(oct); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is either32 or 64.
1005 oq_no++) { 1006 if (!(oct->droq_intr & BIT_ULL(oq_no))) 1007 continue; 1008 1009 droq = oct->droq[oq_no]; 1010 1011 if (droq->ops.poll_mode) { 1012 droq->ops.napi_fn(droq); 1013 oct_priv->napi_mask |= (1 << oq_no);
Quoted 4 lines
It should be 1ULL <<
oq_no. But the other bug is tahte ->napi_mask is a long but that will break on 32 bit systems whenMAX_OCTEON_OUTPUT_QUEUES()is 64. Is that a possible combination?
[Raghu]: These drivers are for 64 bit systems as mentioned in Kconfig.
Quoted 10 lines
1014 } else { 1015 tasklet_schedule(&oct_priv->droq_tasklet); 1016 } 1017 } 1018 } 1019 }regards,
dan carpenter
Quoted 10 lines · Raghu
Quoted 10 lines
1005 oq_no++) { 1006 if (!(oct->droq_intr & BIT_ULL(oq_no))) 1007 continue; 1008 1009 droq = oct->droq[oq_no]; 1010 1011 if (droq->ops.poll_mode) { 1012 droq->ops.napi_fn(droq); 1013 oct_priv->napi_mask |= (1 << oq_no);
Quoted 7 lines
Quoted 4 lines
It should be 1ULL <<
oq_no. But the other bug is tahte ->napi_mask is a long but that will break on 32 bit systems whenMAX_OCTEON_OUTPUT_QUEUES()is 64. Is that a possible combination?[Raghu]: These drivers are for 64 bit systems as mentioned in
Kconfig.
Ah... Grand. I see that now. Can you send a patch for the others?
regards,
dan carpenter