[PATCH net-next] net: phy: use network device in phy_print_status

[PATCH net-next] net: phy: use network device in phy_print_status

[Florian Fainelli]

phy_print_status() currently uses dev_name(&phydev->dev) which will
usually result in printing something along those lines for Device Tree
aware drivers:

libphy: f0b60000.etherne:0a - Link is Down
libphy: f0ba0000.etherne:00 - Link is Up - 1000/Full

This is not terribly useful for network administrators or users since we
expect a network interface name to be able to correlate link events with
interfaces. Update phy_print_status() to use netdev_info() with
phydev->attached_dev which is the backing network device for our PHY
device.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/phy/phy.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 19c9eca..8acf57f 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -45,12 +45,11 @@
 void phy_print_status(struct phy_device *phydev)
 {
 	if (phydev->link) {
-		pr_info("%s - Link is Up - %d/%s\n",
-			dev_name(&phydev->dev),
+		netdev_info(phydev->attached_dev, "- Link is Up - %d/%s\n",
 			phydev->speed,
 			DUPLEX_FULL == phydev->duplex ? "Full" : "Half");
 	} else	{
-		pr_info("%s - Link is Down\n", dev_name(&phydev->dev));
+		netdev_info(phydev->attached_dev, "- Link is Down\n");
 	}
 }
 EXPORT_SYMBOL(phy_print_status);
-- 
1.8.3.2

Re: [PATCH net-next] net: phy: use network device in phy_print_status

[Joe Perches]

On Wed, 2014-01-22 at 10:32 -0800, Florian Fainelli wrote:
> phy_print_status() currently uses dev_name(&phydev->dev) which will
> usually result in printing something along those lines for Device Tree
> aware drivers:
> 
> libphy: f0b60000.etherne:0a - Link is Down
> libphy: f0ba0000.etherne:00 - Link is Up - 1000/Full
> 
> This is not terribly useful for network administrators or users since we
> expect a network interface name to be able to correlate link events with
> interfaces. Update phy_print_status() to use netdev_info() with
> phydev->attached_dev which is the backing network device for our PHY
> device.
[]
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
[]
> @@ -45,12 +45,11 @@
>  void phy_print_status(struct phy_device *phydev)
>  {
>  	if (phydev->link) {
> -		pr_info("%s - Link is Up - %d/%s\n",
> -			dev_name(&phydev->dev),
> +		netdev_info(phydev->attached_dev, "- Link is Up - %d/%s\n",
>  			phydev->speed,
>  			DUPLEX_FULL == phydev->duplex ? "Full" : "Half");
>  	} else	{
> -		pr_info("%s - Link is Down\n", dev_name(&phydev->dev));
> +		netdev_info(phydev->attached_dev, "- Link is Down\n");
>  	}

The leading "- "'s now aren't useful and these could be

	if (phydev->link)
		netdev_info(phydev->attached_dev, "Link is Up - %d/%s\n",
			    phydev->speed,
			    phydev->duplex == DUPLEX_FULL ? "Full" : "Half");
	else
		netdev_info(phydev->attached_dev, "Link is Down\n");

Is is possible that phydev->attached_dev is NULL?

It may also be possible to slightly improve the output by
reducing the number of 0's in the speed block and emitting
Kb/Mb/Gb (or Kbps/Mbps/Gbps) and maybe flow control if it's
available.

Re: [PATCH net-next] net: phy: use network device in phy_print_status

[Florian Fainelli]

2014/1/22 Joe Perches <joe@perches.com>:
> On Wed, 2014-01-22 at 10:32 -0800, Florian Fainelli wrote:
>> phy_print_status() currently uses dev_name(&phydev->dev) which will
>> usually result in printing something along those lines for Device Tree
>> aware drivers:
>>
>> libphy: f0b60000.etherne:0a - Link is Down
>> libphy: f0ba0000.etherne:00 - Link is Up - 1000/Full
>>
>> This is not terribly useful for network administrators or users since we
>> expect a network interface name to be able to correlate link events with
>> interfaces. Update phy_print_status() to use netdev_info() with
>> phydev->attached_dev which is the backing network device for our PHY
>> device.
> []
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> []
>> @@ -45,12 +45,11 @@
>>  void phy_print_status(struct phy_device *phydev)
>>  {
>>       if (phydev->link) {
>> -             pr_info("%s - Link is Up - %d/%s\n",
>> -                     dev_name(&phydev->dev),
>> +             netdev_info(phydev->attached_dev, "- Link is Up - %d/%s\n",
>>                       phydev->speed,
>>                       DUPLEX_FULL == phydev->duplex ? "Full" : "Half");
>>       } else  {
>> -             pr_info("%s - Link is Down\n", dev_name(&phydev->dev));
>> +             netdev_info(phydev->attached_dev, "- Link is Down\n");
>>       }
>
> The leading "- "'s now aren't useful and these could be

I did not want to remove the leading "- " since this would sort of
produce a very different message now, that said, I have no strong
feeling removing it.

>
>         if (phydev->link)
>                 netdev_info(phydev->attached_dev, "Link is Up - %d/%s\n",
>                             phydev->speed,
>                             phydev->duplex == DUPLEX_FULL ? "Full" : "Half");
>         else
>                 netdev_info(phydev->attached_dev, "Link is Down\n");
>
> Is is possible that phydev->attached_dev is NULL?

Not when this is called, it is safe to use phydev->attached_dev.

>
> It may also be possible to slightly improve the output by
> reducing the number of 0's in the speed block and emitting
> Kb/Mb/Gb (or Kbps/Mbps/Gbps) and maybe flow control if it's
> available.

Sure thing, that calls for a follow-up patch though.
-- 
Florian

Re: [PATCH net-next] net: phy: use network device in phy_print_status

[Joe Perches]

On Wed, 2014-01-22 at 10:52 -0800, Florian Fainelli wrote:
> 2014/1/22 Joe Perches <joe@perches.com>:
> > On Wed, 2014-01-22 at 10:32 -0800, Florian Fainelli wrote:
> >> phy_print_status() currently uses dev_name(&phydev->dev) which will
> >> usually result in printing something along those lines for Device Tree
> >> aware drivers:
> >>
> >> libphy: f0b60000.etherne:0a - Link is Down
> >> libphy: f0ba0000.etherne:00 - Link is Up - 1000/Full
[]
> > The leading "- "'s now aren't useful and these could be
> 
> I did not want to remove the leading "- " since this would sort of
> produce a very different message now, that said, I have no strong
> feeling removing it.

The output would already be different as it's no longer
prefixed by "phylib: ".

With the dash it'll look like:

r8169 0000:01:00.0 eth3: - Link is Up

when all the other netdev_info link messages
don't use the - separator after the "ethX: "

> > It may also be possible to slightly improve the output by
> > reducing the number of 0's in the speed block and emitting
> > Kb/Mb/Gb (or Kbps/Mbps/Gbps) and maybe flow control if it's
> > available.
> 
> Sure thing, that calls for a follow-up patch though.

Thanks.

Re: [PATCH net-next] net: phy: use network device in phy_print_status

[Florian Fainelli]

2014/1/22 Joe Perches <joe@perches.com>:
> On Wed, 2014-01-22 at 10:52 -0800, Florian Fainelli wrote:
>> 2014/1/22 Joe Perches <joe@perches.com>:
>> > On Wed, 2014-01-22 at 10:32 -0800, Florian Fainelli wrote:
>> >> phy_print_status() currently uses dev_name(&phydev->dev) which will
>> >> usually result in printing something along those lines for Device Tree
>> >> aware drivers:
>> >>
>> >> libphy: f0b60000.etherne:0a - Link is Down
>> >> libphy: f0ba0000.etherne:00 - Link is Up - 1000/Full
> []
>> > The leading "- "'s now aren't useful and these could be
>>
>> I did not want to remove the leading "- " since this would sort of
>> produce a very different message now, that said, I have no strong
>> feeling removing it.
>
> The output would already be different as it's no longer
> prefixed by "phylib: ".
>
> With the dash it'll look like:
>
> r8169 0000:01:00.0 eth3: - Link is Up
>
> when all the other netdev_info link messages
> don't use the - separator after the "ethX: "

You are right, thanks for spotting that, I will re-submit.

>
>> > It may also be possible to slightly improve the output by
>> > reducing the number of 0's in the speed block and emitting
>> > Kb/Mb/Gb (or Kbps/Mbps/Gbps) and maybe flow control if it's
>> > available.
>>
>> Sure thing, that calls for a follow-up patch though.
>
> Thanks.
>
-- 
Florian