netdev - Re: [PATCH net-next v4 5/8] net: mdio: mux-mmioreg: Simplified with dev_err

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] [day] [month] [year] [list]

Message-ID: <38a3c576-a342-4644-8509-53a6a7f45576@lunn.ch>
Date: Tue, 3 Sep 2024 14:53:23 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Jinjie Ruan <ruanjinjie@...wei.com>, woojung.huh@...rochip.com,
	olteanv@...il.com, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, linus.walleij@...aro.org,
	alsi@...g-olufsen.dk, justin.chen@...adcom.com,
	sebastian.hesselbarth@...il.com, alexandre.torgue@...s.st.com,
	joabreu@...opsys.com, mcoquelin.stm32@...il.com, wens@...e.org,
	jernej.skrabec@...il.com, samuel@...lland.org, hkallweit1@...il.com,
	linux@...linux.org.uk, UNGLinuxDriver@...rochip.com,
	netdev@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com,
	linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
	linux-stm32@...md-mailman.stormreply.com, krzk@...nel.org,
	jic23@...nel.org
Subject: Re: [PATCH net-next v4 5/8] net: mdio: mux-mmioreg: Simplified with
 dev_err_probe()

> > @@ -109,30 +109,25 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
> >   		return -ENOMEM;
> >   	ret = of_address_to_resource(np, 0, &res);
> > -	if (ret) {
> > -		dev_err(&pdev->dev, "could not obtain memory map for node %pOF\n",
> > -			np);
> > -		return ret;
> > -	}
> > +	if (ret)
> > +		return dev_err_probe(&pdev->dev, ret,
> > +				     "could not obtain memory map for node %pOF\n", np);
> 
> Besides that one, which I don't think is even a candidate for resource
> deferral in the first place given the OF platform implementation, it does
> not seem to help that much to switch to dev_err_probe() other than just
> combining the error message and return code in a single statement. So it's
> fewer lines of codes, but it is not exactly what dev_err_probe() was
> originally intended for IMHO.

Agreed. Rather than abuse dev_err_probe(), maybe a dev_err_error()
would be added with the same prototype, does the same formatting, and
skips all the PROBE_DEFFER logic. The problem would be, it would
encourage more of this churn.

	Andrew