Message ID | 20180718161035.7005-3-brgl@bgdev.pl (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Jul 18, 2018 at 06:10:32PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > Many drivers that read the MAC address from EEPROM or MTD emit a log > message when they succeed. Since this function is meant to be reused > in those drivers instead of reimplementing the same operation > everywhere, add an info message when we successfully read the MAC > address. Hi Bartosz This makes eth_platform_get_mac_address() generally more verbose, which i guess people won't like. To keep it backwards compatible, it would be better to issue the message just when EEPROM to MTD is used. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2018-07-18 18:31 GMT+02:00 Andrew Lunn <andrew@lunn.ch>: > On Wed, Jul 18, 2018 at 06:10:32PM +0200, Bartosz Golaszewski wrote: >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >> >> Many drivers that read the MAC address from EEPROM or MTD emit a log >> message when they succeed. Since this function is meant to be reused >> in those drivers instead of reimplementing the same operation >> everywhere, add an info message when we successfully read the MAC >> address. > > Hi Bartosz > > This makes eth_platform_get_mac_address() generally more verbose, > which i guess people won't like. To keep it backwards compatible, it > would be better to issue the message just when EEPROM to MTD is used. > > Andrew This function should be used at most once per interface - I guess it's not like it's a huge impact on verbosity. Bart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Bartosz Golaszewski <brgl@bgdev.pl> Date: Wed, 18 Jul 2018 18:10:32 +0200 > > + dev_info(dev, "read MAC address from %s\n", from); > ether_addr_copy(mac_addr, addr); > return 0; Ugh, please don't do this. We probe various bits of information from various sources during driver probe, and none of them are more or less important than the MAC address. So singling this out for log info output is really not such a great idea. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/net/ethernet/eth.c b/net/ethernet/eth.c index da8530879e1e..2a2173324d9e 100644 --- a/net/ethernet/eth.c +++ b/net/ethernet/eth.c @@ -530,15 +530,24 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr) struct device_node *dp = dev_is_pci(dev) ? pci_device_to_OF_node(to_pci_dev(dev)) : dev->of_node; const unsigned char *addr = NULL; + const char *from = NULL; - if (dp) + if (dp) { addr = of_get_mac_address(dp); - if (!addr) + if (addr) + from = "device tree"; + } + + if (!addr) { addr = arch_get_platform_mac_address(); + if (addr) + from = "arch callback"; + } if (!addr) return -ENODEV; + dev_info(dev, "read MAC address from %s\n", from); ether_addr_copy(mac_addr, addr); return 0; }