[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ec2a401d-e504-da38-8bc7-1826f5de7941@gmail.com>
Date: Wed, 22 Jan 2020 08:28:06 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
David Miller <davem@...emloft.net>,
Maxime Ripard <mripard@...nel.org>,
Chen-Yu Tsai <wens@...e.org>, Doug Berger <opendmb@...il.com>,
Pantelis Antoniou <pantelis.antoniou@...il.com>,
Yisen Zhuang <yisen.zhuang@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>,
Vladimir Zapolskiy <vz@...ia.com>,
Sylvain Lemieux <slemieux.tyco@...il.com>,
Timur Tabi <timur@...nel.org>,
Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
Steve Glendinning <steve.glendinning@...well.net>,
Michal Simek <michal.simek@...inx.com>,
Woojung Huh <woojung.huh@...rochip.com>,
Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
bcm-kernel-feedback-list@...adcom.com,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
linux-renesas-soc@...r.kernel.org,
Linux USB Mailing List <linux-usb@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next] net: convert suitable drivers to use
phy_do_ioctl_running
On 22.01.2020 05:04, Florian Fainelli wrote:
>
>
> On 1/21/2020 1:09 PM, Heiner Kallweit wrote:
>> Convert suitable drivers to use new helper phy_do_ioctl_running.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
> The vast majority of drivers that you are converting use the following
> convention:
>
> - !netif_running -> return -EINVAL
> - !dev->phydev -> return -ENODEV
>
> so it may make sense to change the helper to accommodate the majority
> here, not that I believe this is going to make much practical
> difference, but if there were test cases that were specifically looking
> for such an error code, they could be failing after this changeset.
>
Right, I also stumbled across the different error codes, mainly as you
say -EINVAL. However there is no "wrong value", if netdev isn't running,
then typically the PHY is not attached, and from a netdev point of view
it's not there. So ENODEV seems to be best suited.
In kernel code the changed return code doesn't make a difference,
but yes, in theory there could be userspace programs checking for
-EINVAL. However such userspace programs should check for ENODEV too
anyway to cover the second check that already returns -ENODEV.
> For bgmac.c, bcmgenet.c and cpmac.c:
>
> Acked-by: Florian Fainelli <f.fainelli@...il.com>
>
> Whether you decide to spin another version or not.
>
Heiner
Powered by blists - more mailing lists