| Message ID | 201001071624.20139.hartleys@visionengravers.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: H Hartley Sweeten <hartleys@visionengravers.com> 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 <hsweeten@visionengravers.com> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "H Hartley Sweeten" <hartleys@visionengravers.com> 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 <hsweeten@visionengravers.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: David S. Miller <davem@davemloft.net> --- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html