Re: [PATCH][BNX2X] round three
On Mon, 2007-10-15 at 12:38 -0700, David Miller wrote: From: Eliezer Tamir [EMAIL PROTECTED] Date: Mon, 15 Oct 2007 17:27:29 +0200 Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. If this means we get two copies of the firmware, this should be rethought. The space cost of the firmware (both in terms of source code size and object code size) is already enormous. I would definitely prefer if there were only little-endian firmware, and the driver uses cpu_to_le32() and friends to access chip shared data structures. OK. Then that's what we will do. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Fri, 2007-10-12 at 15:03 -0700, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 12 Oct 2007 16:47:28 +0200 Eliezer Tamir [EMAIL PROTECTED] writes: * For now depend on x86 or x86_64, will add more architectures ASAP. Why is that? Linux drivers normally should not be architecture specific. I totally agree, and the only way to weed out these kinds of bugs is to allow it to build on other systems so users can try it out and report what fails. Or even better, a motivated developer tries it out and fixes the bugs for you :-) This is not a driver issue. Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
This is not a driver issue. Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. If the firmware is big it might be better to just add the necessary conversions to the driver and always use BE. Endian conversions tend to be very cheap. Also we probably should have BE/LE Kconfig symbol for this to handle such cases more elegantly in the future. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote: This is not a driver issue. Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. If the firmware is big it might be better to just add the necessary conversions to the driver and always use BE. Endian conversions tend to be very cheap. For a given architecture, only the right version of the microcode is compiled, so the binary only contains one copy of the microcode. The good news is that future versions of the device will not have this issue. I can complain all day about hardware designers not listening to the software guys but then they just might stop talking to me altogether ;-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, Oct 15, 2007 at 06:22:03PM +0200, Eliezer Tamir wrote: On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote: This is not a driver issue. Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. If the firmware is big it might be better to just add the necessary conversions to the driver and always use BE. Endian conversions tend to be very cheap. For a given architecture, only the right version of the microcode is compiled, so the binary only contains one copy of the microcode. But we still have source code bloat. drivers/net already has too much binary gibberish in hex; no need to add to it unnecessarily. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: Eliezer Tamir [EMAIL PROTECTED] Date: Mon, 15 Oct 2007 17:27:29 +0200 Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. If this means we get two copies of the firmware, this should be rethought. The space cost of the firmware (both in terms of source code size and object code size) is already enormous. I would definitely prefer if there were only little-endian firmware, and the driver uses cpu_to_le32() and friends to access chip shared data structures. Most cpus have endian swapping loads and stores, accessible via cpu_to_le32p() and similar interfaces, so the cost on big-endian of doing things this way is very close to zero. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: Eliezer Tamir [EMAIL PROTECTED] Date: Mon, 15 Oct 2007 18:22:03 +0200 On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote: This is not a driver issue. Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. If the firmware is big it might be better to just add the necessary conversions to the driver and always use BE. Endian conversions tend to be very cheap. For a given architecture, only the right version of the microcode is compiled, so the binary only contains one copy of the microcode. But it still takes up source tree space. The good news is that future versions of the device will not have this issue. The better news is that you only need the little-endian firmware even with these chips, simple assume little-endian for all chip shared data-structures and swap in the driver as we've explained to you. The cost for big-endian cpus is almost nothing. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, 15 Oct 2007 12:38:50 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Eliezer Tamir [EMAIL PROTECTED] Date: Mon, 15 Oct 2007 17:27:29 +0200 Unfortunately, the firmware code is different for LE and BE machines. We had issues with the BE firmware that appear to be resolved. Hopefully, the next version will have both. If this means we get two copies of the firmware, this should be rethought. The space cost of the firmware (both in terms of source code size and object code size) is already enormous. I would definitely prefer if there were only little-endian firmware, and the driver uses cpu_to_le32() and friends to access chip shared data structures. Most cpus have endian swapping loads and stores, accessible via cpu_to_le32p() and similar interfaces, so the cost on big-endian of doing things this way is very close to zero. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html What about using loadable firmware rather than building it into the driver? -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 15 Oct 2007 14:58:29 -0700 What about using loadable firmware rather than building it into the driver? Stephen, do me a huge favor, and don't start down that path. Please... - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, 15 Oct 2007 15:00:22 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 15 Oct 2007 14:58:29 -0700 What about using loadable firmware rather than building it into the driver? Stephen, do me a huge favor, and don't start down that path. Please... I know the history, loadable firmware is a maintenance nuisance/nightmare. And it often leads to stupid license crap. --- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
Eliezer Tamir [EMAIL PROTECTED] writes: * For now depend on x86 or x86_64, will add more architectures ASAP. Why is that? Linux drivers normally should not be architecture specific. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 12 Oct 2007 16:47:28 +0200 Eliezer Tamir [EMAIL PROTECTED] writes: * For now depend on x86 or x86_64, will add more architectures ASAP. Why is that? Linux drivers normally should not be architecture specific. I totally agree, and the only way to weed out these kinds of bugs is to allow it to build on other systems so users can try it out and report what fails. Or even better, a motivated developer tries it out and fixes the bugs for you :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
[added Andy Whitcroft, who is listed as a CHECKPATCH maintainer]
Stephen Hemminger wrote:
Minor formatting nits reported by checkpatch.pl script:
Thanks, I Will fix them.
...
WARNING: no space between function name and open parenthesis '('
#777: FILE: drivers/net/bnx2x.c:722:
+ case (RAMROD_CMD_ID_ETH_PORT_SETUP | BNX2X_STATE_OPENING_WAIT4_PORT):
WARNING: no space between function name and open parenthesis '('
#782: FILE: drivers/net/bnx2x.c:727:
+ case (RAMROD_CMD_ID_ETH_HALT | BNX2X_STATE_CLOSING_WAIT4_HALT):
WARNING: no space between function name and open parenthesis '('
#788: FILE: drivers/net/bnx2x.c:733:
+ case (RAMROD_CMD_ID_ETH_PORT_DEL | BNX2X_STATE_CLOSING_WAIT4_DELETE):
WARNING: no space between function name and open parenthesis '('
#793: FILE: drivers/net/bnx2x.c:738:
+ case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_OPEN):
These look like false positives
...
CHECK: spinlock_t definition without comment
#9486: FILE: drivers/net/bnx2x.h:508:
+ spinlock_t spq_lock; /* Used to serialize slowpath
This one too
...
ERROR: Macros with complex values should be enclosed in parenthesis
#21196: FILE: drivers/net/bnx2x_init.h:138:
+#define INIT_INTERNAL0_MEM_WR(block_bar, block, reg, \
+ part, hw, value, off, len) \
Not sure, I think this one is too, but I'm going to rewrite bnx2x_init.h anyway,
this code is going away.
...
Thanks
Eliezer
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three - sparse warnings.
On Wed, 2007-10-10 at 18:54 -0700, Stephen Hemminger wrote: Please fix these... Thanks, All that code is going to be rewritten, as per Dave's request, but I will make sure to test the new code with sparse. Eliezer - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Wed, 2007-10-10 at 17:59 -0700, David Miller wrote: ... I was going to add this to the tree for 2.6.24 but there is simply too much super-ugly stuff in this driver for me to do so. We will rewrite bnx2x_hsi.h bnx2x_init.h and bnx2x_init_vlaues.h. Does bnx2x_asm.h look OK? Look, there is zero way I'm adding a driver that's written like this to the tree. ... This huge header file full of register programming magic goes way beyond the limits of reasonable and has to go. Will it be OK if we replace it with 4-5 headers so we can maintain them better manually. (I'm asking what is the upper bound to the number of header files you would consider reasonable for this driver.) Thanks Eliezer - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: Eliezer Tamir [EMAIL PROTECTED] Date: Thu, 11 Oct 2007 19:53:39 +0200 Will it be OK if we replace it with 4-5 headers so we can maintain them better manually. (I'm asking what is the upper bound to the number of header files you would consider reasonable for this driver.) It's not the count, it's what's in them that's the problem. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
Eliezer Tamir wrote: The full patch is available at: [EMAIL PROTECTED]://ftp1.broadcom.com/0001-BNX2X-0.40.10a-net-2.6.24.patch Just when I thought I have beaten the line beast. (or maybe it's just too much work and not enough sleep.) the right links are of course: ftp://[EMAIL PROTECTED]/0001-BNX2X-0.40.10a-net-2.6.24.patch and ftp://[EMAIL PROTECTED]/0001-BNX2X-0.40.10a-net-2.6.24.patch.gz - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: Eliezer Tamir [EMAIL PROTECTED]
Date: Wed, 10 Oct 2007 21:52:30 +0200
Eliezer Tamir wrote:
The full patch is available at:
[EMAIL PROTECTED]://ftp1.broadcom.com/0001-BNX2X-0.40.10a-net-2.6.24.patch
Just when I thought I have beaten the line beast.
(or maybe it's just too much work and not enough sleep.)
the right links are of course:
ftp://[EMAIL PROTECTED]/0001-BNX2X-0.40.10a-net-2.6.24.patch
and
ftp://[EMAIL PROTECTED]/0001-BNX2X-0.40.10a-net-2.6.24.patch.gz
I was going to add this to the tree for 2.6.24 but there is simply
too much super-ugly stuff in this driver for me to do so.
bnx2x_hsi.h is a complete mess, it seems to be a concatenation of
several internal header files automatically generated by some
program. It also defines datastructures for which no tabbing
or coding style has been applied, like this
+struct drv_fw_mb_t
+{
+u32 drv_mb_header;
This is why we hate machine generated register lists and similar
things. They are awful to read by human beings, the very people who
might need to read this to work on helping to fix a bug.
I always type every register offset and bit definition in by hand and
make them properly tabbed and look pleasant to human beings who might
have to stare at it.
+#ifndef __ETH_CONSTANTS_H_
+#define __ETH_CONSTANTS_H_
...
+#ifndef __MICROCODE_CONSTANTS_H_
+#define __MICROCODE_CONSTANTS_H_
All in one header file... Barf...
+static const struct arb_line read_arb_data[NUM_RD_Q][MAX_RD_ORD + 1] = {
+ {{ 8 , 64 , 25}, { 16 , 64 , 25}, { 32 , 64 , 25}, { 64 , 64 , 41}},
+ {{ 4 , 8 , 4}, { 4 , 8 , 4},{ 4 , 8 , 4},{ 4 , 8 , 4}},
+ {{ 4 , 3 , 3}, { 4 , 3 , 3},{ 4 , 3 , 3},{ 4 , 3 , 3}},
+ {{ 8 , 3 , 6}, { 16 , 3 , 11}, { 16 , 3 , 11}, { 16 , 3 , 11}},
+ {{ 8 , 64 , 25}, { 16 , 64 , 25}, { 32 , 64 , 25}, { 64 , 64 , 41}},
Magic constants, what do they mean?
+static const u32 EVST_TSEM_FAST_MEMORY_COMMON_MEMORY_INIT_ASIC_7[] = {
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
...
+0x0, 0x0, 0x0, 0x1};
All zeros with a trailing one, remove this table and just program this
sequence by hand. This table serves nothing but to waste unswappable
kernel memory. I don't care if they are dependent upon firmware
changes.
There are tons of tables like this, fix them.
+static const u32 EVST_TSEM_FAST_MEMORY_PORT0_MEMORY_INIT_ASIC_27[] = {
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+0x, 0x};
What do these magic constant masks mean?
+static const u32 EVST_CDU_L1TT_COMMON_MEMORY_INIT_HARDWARE[] = {
+0xfff3, 0x314f, 0xc30c30c, 0xc30c30c3, 0xcf3cf300, 0xf3cf3cf3, 0xcf3c,
Magic constants, what are they?
+static const u32 EVST_CDU_MATT_COMMON_MEMORY_INIT_HARDWARE[] = {
+0xa, 0x700a0, 0x28110, 0xb8138, 0x201f0, 0x10210, 0xf0220, 0x10310,
+0x8, 0x80080, 0x28100, 0xb8128, 0x201e0, 0x10200, 0x70210, 0x20280,
Similarly.
+INIT_REG_WR(TSDM, TSDM_REGISTERS_ENABLE_IN1, 0X7FF, COMMON, INIT_HARDWARE);
+INIT_REG_WR(TSDM, TSDM_REGISTERS_ENABLE_IN2, 0X3F, COMMON, INIT_HARDWARE);
+INIT_REG_WR(TSDM, TSDM_REGISTERS_ENABLE_OUT1, 0X7FF, COMMON,
INIT_HARDWARE);
+INIT_REG_WR(TSDM, TSDM_REGISTERS_ENABLE_OUT2, 0XF, COMMON, INIT_HARDWARE);
Magic undocumented constants.
+static const u32 EVST_TCM_XX_DESCR_TABLE_COMMON_MEMORY_INIT_HARDWARE[] = {
+0x1, 0x204c0, 0x30980, 0x40e40, 0x51300, 0x617c0, 0x71c80, 0x82140,
+0x92600, 0xa2ac0, 0xb2f80, 0xc3440, 0xd3900, 0xe3dc0, 0xf4280, 0x104740,
+0x114c00, 0x1250c0, 0x135580, 0x145a40, 0x155f00, 0x1663c0, 0x176880, 0x186d40,
+0x197200, 0x1a76c0, 0x1b7b80, 0x1c8040, 0x1d8500, 0x1e89c0, 0x1f8e80,
+0x209340};
More of same.
Look, there is zero way I'm adding a driver that's written like this
to the tree.
We've set high standards for these sorts of issues in previous
Broadcom network chip drivers and we're not about to start regressing
in this area.
I don't care if it's easier for you guys to run some program which
autogenerates tables than to code it up cleanly into C function
statements which purposefully program each element of the hardware.
This huge header file full of register programming magic goes way
beyond the limits of reasonable and has to go.
If that big concatenated header file shows up in the next submission
I'm not even going to review it, so please don't waste my time in
this way.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
Minor formatting nits reported by checkpatch.pl script:
WARNING: braces {} are not necessary for single statement blocks
#506: FILE: drivers/net/bnx2x.c:451:
+ if (REG_RD(bp, GRCBASE_HC, addr) != val) {
+ BNX2X_ERR(BUG! proper val not read from IGU!\n);
+ }
WARNING: braces {} are not necessary for single statement blocks
#709: FILE: drivers/net/bnx2x.c:654:
+ if (unlikely(bp-panic)) {
+ return;
+ }
WARNING: braces {} are not necessary for single statement blocks
#736: FILE: drivers/net/bnx2x.c:681:
+ if (done == work) {
+ break;
+ }
WARNING: braces {} are not necessary for single statement blocks
#754: FILE: drivers/net/bnx2x.c:699:
+ if ((netif_queue_stopped(bp-dev))
+ (bnx2x_tx_avail(fp) = MAX_SKB_FRAGS + 3)) {
+ netif_wake_queue(bp-dev);
+ }
WARNING: no space between function name and open parenthesis '('
#777: FILE: drivers/net/bnx2x.c:722:
+ case (RAMROD_CMD_ID_ETH_PORT_SETUP | BNX2X_STATE_OPENING_WAIT4_PORT):
WARNING: no space between function name and open parenthesis '('
#782: FILE: drivers/net/bnx2x.c:727:
+ case (RAMROD_CMD_ID_ETH_HALT | BNX2X_STATE_CLOSING_WAIT4_HALT):
WARNING: no space between function name and open parenthesis '('
#788: FILE: drivers/net/bnx2x.c:733:
+ case (RAMROD_CMD_ID_ETH_PORT_DEL | BNX2X_STATE_CLOSING_WAIT4_DELETE):
WARNING: no space between function name and open parenthesis '('
#793: FILE: drivers/net/bnx2x.c:738:
+ case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_OPEN):
WARNING: braces {} are not necessary for single statement blocks
#812: FILE: drivers/net/bnx2x.c:757:
+ if (unlikely(skb == NULL)) {
+ return -ENOMEM;
+ }
WARNING: braces {} are not necessary for single statement blocks
#873: FILE: drivers/net/bnx2x.c:818:
+ if (unlikely(bp-panic)) {
+ return 0;
+ }
WARNING: braces {} are not necessary for single statement blocks
#879: FILE: drivers/net/bnx2x.c:824:
+ if ((hw_comp_cons MAX_RX_DESC_CNT) == MAX_RX_DESC_CNT) {
+ hw_comp_cons++;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1018: FILE: drivers/net/bnx2x.c:963:
+ if ((cqe-fast_path_cqe.pars_flags.flags
+ PARSING_FLAGS_NUMBER_OF_NESTED_VLANS)
+(bp-vlgrp != 0)) {
+ vlan_hwaccel_receive_skb(skb, bp-vlgrp,
+cqe-fast_path_cqe.vlan_tag);
+ } else
WARNING: braces {} are not necessary for single statement blocks
#1069: FILE: drivers/net/bnx2x.c:1014:
+ if (unlikely(bp-panic)) {
+ return IRQ_HANDLED;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1096: FILE: drivers/net/bnx2x.c:1041:
+ if (unlikely(bp-panic)) {
+ return IRQ_HANDLED;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1118: FILE: drivers/net/bnx2x.c:1063:
+ if (!status) {
+ return IRQ_HANDLED;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1127: FILE: drivers/net/bnx2x.c:1072:
+ if (!status) {
+ return IRQ_HANDLED;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1489: FILE: drivers/net/bnx2x.c:1434:
+ if (rd_val == val) {
+ return 0;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1549: FILE: drivers/net/bnx2x.c:1494:
+ if (bp-req_flow_ctrl == FLOW_CTRL_AUTO) {
+ bp-flow_ctrl = FLOW_CTRL_BOTH;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1661: FILE: drivers/net/bnx2x.c:1606:
+ if (gp_status MDIO_AN_CL73_OR_37_COMPLETE) {
+ bp-link_status |=
+ LINK_STATUS_AUTO_NEGOTIATE_COMPLETE;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1665: FILE: drivers/net/bnx2x.c:1610:
+ if (bp-autoneg AUTONEG_PARALLEL) {
+ bp-link_status |=
+ LINK_STATUS_PARALLEL_DETECTION_USED;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1671: FILE: drivers/net/bnx2x.c:1616:
+ if (bp-flow_ctrl FLOW_CTRL_TX) {
+ bp-link_status |= LINK_STATUS_TX_FLOW_CONTROL_ENABLED;
+ }
WARNING: braces {} are not necessary for single statement blocks
#1674: FILE: drivers/net/bnx2x.c:1619:
+ if (bp-flow_ctrl FLOW_CTRL_RX) {
+ bp-link_status |= LINK_STATUS_RX_FLOW_CONTROL_ENABLED;
+ }
WARNING: braces {} are not
Re: [PATCH][BNX2X] round three - sparse warnings.
Please fix these... CHECK drivers/net/bnx2x.c drivers/net/bnx2x_asm.h:62:2: warning: cast removes address space of expression drivers/net/bnx2x_asm.h:62:2: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_asm.h:62:2:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_asm.h:62:2:got unsigned char [usertype] * drivers/net/bnx2x_asm.h:988:2: warning: cast removes address space of expression drivers/net/bnx2x_asm.h:988:2: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_asm.h:988:2:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_asm.h:988:2:got unsigned char [usertype] * drivers/net/bnx2x_asm.h:2300:2: warning: cast removes address space of expression drivers/net/bnx2x_asm.h:2300:2: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_asm.h:2300:2:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_asm.h:2300:2:got unsigned char [usertype] * drivers/net/bnx2x_asm.h:3087:2: warning: cast removes address space of expression drivers/net/bnx2x_asm.h:3087:2: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_asm.h:3087:2:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_asm.h:3087:2:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:13:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:13:1: warning: incorrect type in argument 1 (different address spaces) drivers/net/bnx2x_init_values.h:13:1:expected void const volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:13:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:14:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:14:1: warning: incorrect type in argument 1 (different address spaces) drivers/net/bnx2x_init_values.h:14:1:expected void const volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:14:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:15:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:15:1: warning: incorrect type in argument 1 (different address spaces) drivers/net/bnx2x_init_values.h:15:1:expected void const volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:15:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:16:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:16:1: warning: incorrect type in argument 1 (different address spaces) drivers/net/bnx2x_init_values.h:16:1:expected void const volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:16:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:17:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:17:1: warning: incorrect type in argument 1 (different address spaces) drivers/net/bnx2x_init_values.h:17:1:expected void const volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:17:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:18:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:18:1: warning: incorrect type in argument 1 (different address spaces) drivers/net/bnx2x_init_values.h:18:1:expected void const volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:18:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:19:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:19:1: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_init_values.h:19:1:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:19:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:20:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:20:1: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_init_values.h:20:1:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:20:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:21:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:21:1: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_init_values.h:21:1:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:21:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:22:1: warning: cast removes address space of expression drivers/net/bnx2x_init_values.h:22:1: warning: incorrect type in argument 2 (different address spaces) drivers/net/bnx2x_init_values.h:22:1:expected void volatile [noderef] asn:2*addr drivers/net/bnx2x_init_values.h:22:1:got unsigned char [usertype] * drivers/net/bnx2x_init_values.h:23:1: warning: cast removes address space of expression
