netdev - Re: [PATCH net-next v9 6/6] net: tn40xx: add phylink support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240610.151023.1062977558544031951.fujita.tomonori@gmail.com>
Date: Mon, 10 Jun 2024 15:10:23 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: linux@...linux.org.uk
Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org, andrew@...n.ch,
 horms@...nel.org, kuba@...nel.org, jiri@...nulli.us, pabeni@...hat.com,
 hfdevel@....net, naveenm@...vell.com, jdamato@...tly.com
Subject: Re: [PATCH net-next v9 6/6] net: tn40xx: add phylink support

Hi,

On Sun, 9 Jun 2024 11:34:28 +0100
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

>> +int tn40_phy_register(struct tn40_priv *priv)
>> +{
>> +	struct phylink_config *config;
>> +	struct phy_device *phydev;
>> +	struct phylink *phylink;
>> +
>> +	phydev = phy_find_first(priv->mdio);
>> +	if (!phydev) {
>> +		dev_err(&priv->pdev->dev, "PHY isn't found\n");
>> +		return -1;
> 
> And my email client, setup with rules to catch common programming
> mistakes, highlights the above line. I have no idea why people do
> this... why people think "lets return -1 on error". It seems to be
> a very common pattern... but it's utterly wrong. -1 is -EPERM, aka
> "Operation not permitted". This is not what you mean here. Please
> return a more suitable negative errno symbol... and please refrain
> from using "return -1" in kernel code.

Indeed, my bad. How about -ENODEV? Or -ENOXIO?


> (The only case where "return -1" may be permissible is where the
> value doesn't get propagated outside of the compilation unit, but
> even there, there is the possibility that later changes may end
> up propagating it outside... personally, I would like to see
> "return -1" totally banned from the kernel.)

Understood. This driver should only use "return -1" here.