[NET]: Undo code bloat in hot paths due to print_mac().

If print_mac() is used inside of a pr_debug() the compiler
can't see that the call is redundant so still performs it
even of pr_debug() ends up being a nop.

So don't use print_mac() in such cases in hot code paths,
use MAC_FMT et al. instead.

As noted by Joe Perches, pr_debug() could be modified to
handle this better, but that is a change to an interface
used by the entire kernel and thus needs to be validated
carefully.  This here is thus the less risky fix for
2.6.25

Signed-off-by: David S. Miller <davem@davemloft.net>

1 files changed, 5 insertions, 6 deletions

diff --git a/drivers/net/starfire.c b/drivers/net/starfire.c
index c49214feae9..7b7b1717b0d 100644
--- a/drivers/net/starfire.c
+++ b/drivers/net/starfire.c
@@ -1472,13 +1472,12 @@ static int __netdev_rx(struct net_device *dev, int *quota)
 #ifndef final_version                   /* Remove after testing. */
                 /* You will want this info for the initial debug. */
                 if (debug > 5) {
-                        DECLARE_MAC_BUF(mac);
-                        DECLARE_MAC_BUF(mac2);
-
-                        printk(KERN_DEBUG "  Rx data %s %s"
+                        printk(KERN_DEBUG "  Rx data " MAC_FMT " " MAC_FMT
                                " %2.2x%2.2x.\n",
-                               print_mac(mac, &skb->data[0]),
-                               print_mac(mac2, &skb->data[6]),
+                               skb->data[0], skb->data[1], skb->data[2],
+                               skb->data[3], skb->data[4], skb->data[5],
+                               skb->data[6], skb->data[7], skb->data[8],
+                               skb->data[9], skb->data[10], skb->data[11],
                                skb->data[12], skb->data[13]);
                 }
 #endif