The address will still be displayed in the FDDI Canonical format.
Signed-off-by: H Hartley Sweeten <hswe...@visionengravers.com>
Cc: David S. Miller <da...@davemloft.net>
---
diff --git a/drivers/net/skfp/skfddi.c b/drivers/net/skfp/skfddi.c
index db216a7..1f9698c 100644
--- a/drivers/net/skfp/skfddi.c
+++ b/drivers/net/skfp/skfddi.c
@@ -435,13 +435,7 @@ static int skfp_driver_init(struct net_device *dev)
goto fail;
}
read_address(smc, NULL);
- pr_debug(KERN_INFO "HW-Addr: %02x %02x %02x %02x %02x %02x\n",
- smc->hw.fddi_canon_addr.a[0],
- smc->hw.fddi_canon_addr.a[1],
- smc->hw.fddi_canon_addr.a[2],
- smc->hw.fddi_canon_addr.a[3],
- smc->hw.fddi_canon_addr.a[4],
- smc->hw.fddi_canon_addr.a[5]);
+ pr_debug(KERN_INFO "HW-Addr: %pMF\n", smc->hw.fddi_canon_addr.a);
memcpy(dev->dev_addr, smc->hw.fddi_canon_addr.a, 6);
smt_reset_defaults(smc, 0);
@@ -890,15 +884,8 @@ static void skfp_ctl_set_multicast_list_wo_lock(struct net_device *dev)
(struct fddi_addr *)dmi->dmi_addr,
1);
- pr_debug(KERN_INFO "ENABLE MC ADDRESS:");
- pr_debug(" %02x %02x %02x ",
- dmi->dmi_addr[0],
- dmi->dmi_addr[1],
- dmi->dmi_addr[2]);
- pr_debug("%02x %02x %02x\n",
- dmi->dmi_addr[3],
- dmi->dmi_addr[4],
- dmi->dmi_addr[5]);
+ pr_debug(KERN_INFO "ENABLE MC ADDRESS: %pMF\n",
+ dmi->dmi_addr);
dmi = dmi->next;
} // for
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I'm not sure that it matters, but prior to this patch
the address was displayed with octets delimited by spaces,
and afterwards its delimited by hyphens. So perhaps the comment
should read:
The address will now be displayed in the FDDI Canonical format.
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> Use the %pMF kernel extension to display the MAC address.
>
> The address will still be displayed in the FDDI Canonical format.
>
> Signed-off-by: H Hartley Sweeten <hswe...@visionengravers.com>
Applied.
> I'm not sure that it matters, but prior to this patch
> the address was displayed with octets delimited by spaces,
> and afterwards its delimited by hyphens. So perhaps the comment
> should read:
>
> The address will now be displayed in the FDDI Canonical format.
And it probably wasn't bit reversed.
> > diff --git a/drivers/net/skfp/skfddi.c b/drivers/net/skfp/skfddi.c
> > index db216a7..1f9698c 100644
> > --- a/drivers/net/skfp/skfddi.c
> > +++ b/drivers/net/skfp/skfddi.c
> > @@ -435,13 +435,7 @@ static int skfp_driver_init(struct net_device *dev)
> > goto fail;
> > }
> > read_address(smc, NULL);
> > - pr_debug(KERN_INFO "HW-Addr: %02x %02x %02x %02x %02x %02x\n",
> > - smc->hw.fddi_canon_addr.a[0],
> > - smc->hw.fddi_canon_addr.a[1],
> > - smc->hw.fddi_canon_addr.a[2],
> > - smc->hw.fddi_canon_addr.a[3],
> > - smc->hw.fddi_canon_addr.a[4],
> > - smc->hw.fddi_canon_addr.a[5]);
> > + pr_debug(KERN_INFO "HW-Addr: %pMF\n", smc->hw.fddi_canon_addr.a);
Is fddi_canon_addr already bit reversed?
It's memcpy'd to dev->dev_addr later, so probably not.
> > smt_reset_defaults(smc, 0);
> > @@ -890,15 +884,8 @@ static void skfp_ctl_set_multicast_list_wo_lock(struct net_device *dev)
> > (struct fddi_addr *)dmi->dmi_addr,
> > 1);
> >
> > - pr_debug(KERN_INFO "ENABLE MC ADDRESS:");
> > - pr_debug(" %02x %02x %02x ",
> > - dmi->dmi_addr[0],
> > - dmi->dmi_addr[1],
> > - dmi->dmi_addr[2]);
> > - pr_debug("%02x %02x %02x\n",
> > - dmi->dmi_addr[3],
> > - dmi->dmi_addr[4],
> > - dmi->dmi_addr[5]);
> > + pr_debug(KERN_INFO "ENABLE MC ADDRESS: %pMF\n",
> > + dmi->dmi_addr);
I think you want %pM here, not the bit-reversed %pMF form.
Keeping in mind that %pM uses ':' as the delimiter and %pMF uses '-',
which by all accounts is not the FDDI canonical format. But then again,
neither is the current use of ' ' as the delimiter.
.. seems like there is some discussion surrounding the other patch in the
series and what the format and bit-order should be.
You could add %pMf for those, that are bit-reversed already? That
should take at most two extra insns for x86. ;)
Best Regards,
Micha� Miros�aw