[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230629211023.pznzgue6arn7fzfl@halaney-x13s>
Date: Thu, 29 Jun 2023 16:10:23 -0500
From: Andrew Halaney <ahalaney@...hat.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com, netdev@...r.kernel.org,
mcoquelin.stm32@...il.com, pabeni@...hat.com, kuba@...nel.org,
edumazet@...gle.com, davem@...emloft.net, joabreu@...opsys.com,
alexandre.torgue@...s.st.com, peppe.cavallaro@...com,
bhupesh.sharma@...aro.org, vkoul@...nel.org,
bartosz.golaszewski@...aro.org
Subject: Re: [PATCH 3/3] net: stmmac: dwmac-qcom-ethqos: Log more errors in
probe
On Thu, Jun 29, 2023 at 10:32:24PM +0200, Andrew Lunn wrote:
> On Thu, Jun 29, 2023 at 02:14:18PM -0500, Andrew Halaney wrote:
> > These are useful to see when debugging a probe failure.
>
> Since this is used for debugging, maybe netdev_dbg(). Anybody actually
> doing debugging should be able to turn that on.
>
In my opinion it is better to use dev_err_probe() as done here because:
1. If it's -EPROBE_DEFER it will be under debug level already
2. If it's anything else, its an error and the logs are useful
I've ran into both ends of this now (failure of a platform dependency to
load, be it a bug in the driver, or just failing to select said driver),
and I've seen issues where new integrators (say you're bringing up a new
board) leave something out, etc, and run into issues because of that.
Thanks,
Andrew
Powered by blists - more mailing lists