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 <[email protected]>
Cc: Maciej W. Rozycki <[email protected]>
Cc: David S. Miller <[email protected]>
---
diff --git a/drivers/net/defxx.c b/drivers/net/defxx.c
index 6a6ea03..e4eac4b 100644
--- a/drivers/net/defxx.c
+++ b/drivers/net/defxx.c
@@ -1052,12 +1052,9 @@ static int __devinit dfx_driver_init(struct net_device *dev,
board_name = "DEFEA";
if (dfx_bus_pci)
board_name = "DEFPA";
- pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, "
- "Hardware addr = %02X-%02X-%02X-%02X-%02X-%02X\n",
+ pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, Hardware addr = %pMF\n",
print_name, board_name, dfx_use_mmio ? "" : "I/O ",
- (long long)bar_start, dev->irq,
- dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
- dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
+ (long long)bar_start, dev->irq, dev->dev_addr);
/*
* Get memory for descriptor block, consumer block, and other buffers
From: H Hartley Sweeten <[email protected]>
Date: Thu, 7 Jan 2010 16:24:19 -0700
> 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 <[email protected]>
Applied.
On Thu, 2010-01-07 at 16:24 -0700, H Hartley Sweeten wrote:
> Use the %pMF kernel extension to display the MAC address.
> The address will still be displayed in the FDDI Canonical format.
> diff --git a/drivers/net/defxx.c b/drivers/net/defxx.c
> index 6a6ea03..e4eac4b 100644
> --- a/drivers/net/defxx.c
> +++ b/drivers/net/defxx.c
> @@ -1052,12 +1052,9 @@ static int __devinit dfx_driver_init(struct net_device *dev,
> board_name = "DEFEA";
> if (dfx_bus_pci)
> board_name = "DEFPA";
> - pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, "
> - "Hardware addr = %02X-%02X-%02X-%02X-%02X-%02X\n",
> + pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, Hardware addr = %pMF\n",
> print_name, board_name, dfx_use_mmio ? "" : "I/O ",
I believe the output will _now_ be in the canonical form.
Before it wasn't bit reversed. Now it should be.
On Thu, 7 Jan 2010, Joe Perches wrote:
> On Thu, 2010-01-07 at 16:24 -0700, H Hartley Sweeten wrote:
> > Use the %pMF kernel extension to display the MAC address.
> > The address will still be displayed in the FDDI Canonical format.
>
> > diff --git a/drivers/net/defxx.c b/drivers/net/defxx.c
> > index 6a6ea03..e4eac4b 100644
> > --- a/drivers/net/defxx.c
> > +++ b/drivers/net/defxx.c
> > @@ -1052,12 +1052,9 @@ static int __devinit dfx_driver_init(struct net_device *dev,
> > board_name = "DEFEA";
> > if (dfx_bus_pci)
> > board_name = "DEFPA";
> > - pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, "
> > - "Hardware addr = %02X-%02X-%02X-%02X-%02X-%02X\n",
> > + pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, Hardware addr = %pMF\n",
> > print_name, board_name, dfx_use_mmio ? "" : "I/O ",
>
> I believe the output will _now_ be in the canonical form.
> Before it wasn't bit reversed. Now it should be.
Output was correct -- why would you assume otherwise? The bit order in
the MLA (My Long Address) register as retrieved from the MAC chip by
board's firmware has nothing to do with the wire order and is already in
the canonical form (the same applies to CAM entries and frame headers) --
the board designers were sane people.
With the two patches in place the output produced is now broken. :(
Maciej
On Thursday, January 07, 2010 7:06 PM, Maciej W. Rozycki wrote:
> On Thu, 7 Jan 2010, Joe Perches wrote:
>
>> On Thu, 2010-01-07 at 16:24 -0700, H Hartley Sweeten wrote:
>>> Use the %pMF kernel extension to display the MAC address.
>>> The address will still be displayed in the FDDI Canonical format.
>>
>>> diff --git a/drivers/net/defxx.c b/drivers/net/defxx.c
>>> index 6a6ea03..e4eac4b 100644
>>> --- a/drivers/net/defxx.c
>>> +++ b/drivers/net/defxx.c
>>> @@ -1052,12 +1052,9 @@ static int __devinit dfx_driver_init(struct net_device *dev,
>>> board_name = "DEFEA";
>>> if (dfx_bus_pci)
>>> board_name = "DEFPA";
>>> - pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, "
>>> - "Hardware addr = %02X-%02X-%02X-%02X-%02X-%02X\n",
>>> + pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, Hardware addr = %pMF\n",
>>> print_name, board_name, dfx_use_mmio ? "" : "I/O ",
>>
>> I believe the output will _now_ be in the canonical form.
>> Before it wasn't bit reversed. Now it should be.
>
> Output was correct -- why would you assume otherwise? The bit order in
> the MLA (My Long Address) register as retrieved from the MAC chip by
> board's firmware has nothing to do with the wire order and is already in
> the canonical form (the same applies to CAM entries and frame headers) --
> the board designers were sane people.
>
> With the two patches in place the output produced is now broken. :(
>
Ugh.. This is a mess...
David,
Can you please un-apply both this patch and the one for skfddi.c?
I think they should both use some form of the %p[mMF] format to display
the address but it appears Maciej is the only person that really knows
what the output _should" be...
Oh well... So much for trying to make things consistent...
Regards,
Hartley
From: "H Hartley Sweeten" <[email protected]>
Date: Thu, 7 Jan 2010 21:11:34 -0500
> Can you please un-apply both this patch and the one for skfddi.c?
I can't "unapply" them. They have been pushed out to my
net-next-2.6 tree and thus are irreversably a part of the
permanent record.
Submit fixes instead, if indeed fixes are even necessary.
On Thu, 7 Jan 2010, H Hartley Sweeten wrote:
> >> I believe the output will _now_ be in the canonical form.
> >> Before it wasn't bit reversed. Now it should be.
> >
> > Output was correct -- why would you assume otherwise? The bit order in
> > the MLA (My Long Address) register as retrieved from the MAC chip by
> > board's firmware has nothing to do with the wire order and is already in
> > the canonical form (the same applies to CAM entries and frame headers) --
> > the board designers were sane people.
> >
> > With the two patches in place the output produced is now broken. :(
> >
>
> Ugh.. This is a mess...
>
> David,
>
> Can you please un-apply both this patch and the one for skfddi.c?
> I think they should both use some form of the %p[mMF] format to display
> the address but it appears Maciej is the only person that really knows
> what the output _should" be...
Here are excerpts from old bootstrap logs -- I don't have any of these
boards handy at the moment, but I'll have access to a couple in a few
weeks' time:
defxx: v1.10 2006/12/14 Lawrence V. Stefani and others
tc0: DEFTA at addr = 0x10100000, IRQ = 2, Hardware addr = 08-00-2B-A3-66-C8
tc0: registered as fddi0
tc1: DEFTA at addr = 0x14100000, IRQ = 3, Hardware addr = 08-00-2B-A3-A3-29
tc1: registered as fddi1
defxx: v1.10 2006/12/14 Lawrence V. Stefani and others
0000:00:06.0: DEFPA at addr = 0x41071000, IRQ = 57, Hardware addr = 00-60-B0-58-40-75
0000:00:06.0: registered as fddi0
0000:02:00.0: DEFPA at addr = 0x41510000, IRQ = 57, Hardware addr = 00-60-B0-58-41-E7
0000:02:00.0: registered as fddi1
Compare the addresses reported with the OUIs of the respective
manufacturers -- the former is DEC and the latter is HP. See
http://standards.ieee.org/regauth/oui/oui.txt for a reference.
Maciej
On Fri, 2010-01-08 at 13:34 +0000, Maciej W. Rozycki wrote:
> On Thu, 7 Jan 2010, H Hartley Sweeten wrote:
> > >> I believe the output will _now_ be in the canonical form.
> > >> Before it wasn't bit reversed. Now it should be.
> > >
> > > Output was correct -- why would you assume otherwise?
> > > With the two patches in place the output produced is now broken. :(
> Here are excerpts from old bootstrap logs -- I don't have any of these
> boards handy at the moment, but I'll have access to a couple in a few
> weeks' time:
>
> defxx: v1.10 2006/12/14 Lawrence V. Stefani and others
> tc0: DEFTA at addr = 0x10100000, IRQ = 2, Hardware addr = 08-00-2B-A3-66-C8
> tc0: registered as fddi0
> tc1: DEFTA at addr = 0x14100000, IRQ = 3, Hardware addr = 08-00-2B-A3-A3-29
> tc1: registered as fddi1
>
> defxx: v1.10 2006/12/14 Lawrence V. Stefani and others
> 0000:00:06.0: DEFPA at addr = 0x41071000, IRQ = 57, Hardware addr = 00-60-B0-58-40-75
> 0000:00:06.0: registered as fddi0
> 0000:02:00.0: DEFPA at addr = 0x41510000, IRQ = 57, Hardware addr = 00-60-B0-58-41-E7
> 0000:02:00.0: registered as fddi1
>
> Compare the addresses reported with the OUIs of the respective
> manufacturers -- the former is DEC and the latter is HP. See
> http://standards.ieee.org/regauth/oui/oui.txt for a reference.
Then isn't the hardware address shown as ethernet and not as
in the FDDI canonical format?
Which confuses me relative to what you wrote earlier.
> On Mon, 2010-01-04 at 23:43 +0000, Maciej W. Rozycki wrote:
> > The example below shows an address, and the sequence of bits or symbols
> > that would be transmitted when the address is used in the Source Address
> > or Destination Address fields on the MAC header. The transmission line
> > shows the address bits in the order transmitted, from left to right. For
> > IEEE 802 LANs these correspond to actual bits on the medium. The FDDI
> > symbols line shows how the FDDI PHY sends the address bits as encoded
> > symbols.
> >
> > MSB: 35:7B:12:00:00:01
> > Canonical: AC-DE-48-00-00-80
So, it should simply use %pM correct?
Is there any address that should be shown in the
FDDI canonical form?
cheers, Joe
On Fri, 8 Jan 2010, Joe Perches wrote:
> > Here are excerpts from old bootstrap logs -- I don't have any of these
> > boards handy at the moment, but I'll have access to a couple in a few
> > weeks' time:
> >
> > defxx: v1.10 2006/12/14 Lawrence V. Stefani and others
> > tc0: DEFTA at addr = 0x10100000, IRQ = 2, Hardware addr = 08-00-2B-A3-66-C8
> > tc0: registered as fddi0
> > tc1: DEFTA at addr = 0x14100000, IRQ = 3, Hardware addr = 08-00-2B-A3-A3-29
> > tc1: registered as fddi1
> >
> > defxx: v1.10 2006/12/14 Lawrence V. Stefani and others
> > 0000:00:06.0: DEFPA at addr = 0x41071000, IRQ = 57, Hardware addr = 00-60-B0-58-40-75
> > 0000:00:06.0: registered as fddi0
> > 0000:02:00.0: DEFPA at addr = 0x41510000, IRQ = 57, Hardware addr = 00-60-B0-58-41-E7
> > 0000:02:00.0: registered as fddi1
> >
> > Compare the addresses reported with the OUIs of the respective
> > manufacturers -- the former is DEC and the latter is HP. See
> > http://standards.ieee.org/regauth/oui/oui.txt for a reference.
>
> Then isn't the hardware address shown as ethernet and not as
> in the FDDI canonical format?
>
> Which confuses me relative to what you wrote earlier.
It's shown in the FDDI canonical form, so it should use dashes as
separators. That's been my point from the very beginning.
> > On Mon, 2010-01-04 at 23:43 +0000, Maciej W. Rozycki wrote:
> > > The example below shows an address, and the sequence of bits or symbols
> > > that would be transmitted when the address is used in the Source Address
> > > or Destination Address fields on the MAC header. The transmission line
> > > shows the address bits in the order transmitted, from left to right. For
> > > IEEE 802 LANs these correspond to actual bits on the medium. The FDDI
> > > symbols line shows how the FDDI PHY sends the address bits as encoded
> > > symbols.
> > >
> > > MSB: 35:7B:12:00:00:01
> > > Canonical: AC-DE-48-00-00-80
>
> So, it should simply use %pM correct?
No. The %pM specifier would print the hex numbers in the canonical form,
but still use the MSB form separator and therefore confuse the reader who
would normally conclude from the separators that the address is actually
in the MSB form.
> Is there any address that should be shown in the
> FDDI canonical form?
All are typically shown in that form.
WRT the DEFxx boards: the firmware presents and expects addresses
communicated with the OS in the canonical form (they are bitswapped in
hardware by appropriate circuitry I believe). However if data contained
within SMT management frames (normally out of interest and not passed to
the OS, but can be received if the appropriate promiscuous mode is
selected) is examined, then addresses embedded within are in the (native)
MSB form (SMT is low-bandwidth traffic, so software processing overhead is
not critical). That's I believe the reason both forms are used in the
first place and the possible source of confusion.
Please let me know if I've been clear enough this time.
Maciej