[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200807134254.GC12946@gnbcxd0016.gnb.st.com>
Date: Fri, 7 Aug 2020 15:42:54 +0200
From: Alain Volmat <alain.volmat@...com>
To: Mark Brown <broonie@...nel.org>
CC: <amelie.delaunay@...com>, <mcoquelin.stm32@...il.com>,
<alexandre.torgue@...com>, <linux-spi@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <fabrice.gasnier@...com>
Subject: Re: [PATCH 02/18] spi: stm32-spi: defer probe for reset
On Wed, Aug 05, 2020 at 11:49:06AM +0100, Mark Brown wrote:
> On Wed, Aug 05, 2020 at 09:01:57AM +0200, Alain Volmat wrote:
>
> > - rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> > - if (!IS_ERR(rst)) {
> > + rst = devm_reset_control_get_optional_exclusive(&pdev->dev, NULL);
> > + if (rst) {
> > + if (IS_ERR(rst)) {
> > + ret = PTR_ERR(rst);
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(&pdev->dev, "reset get failed: %d\n",
> > + ret);
> > + goto err_clk_disable;
> > + }
>
> This will not provide any diagnostics when deferring which isn't very
> helpful if there's issues.
Do you mean that a message when deferring would be needed ?
I am worrying that this would lead to having too much noise during boot
since probe deferring is kinda common. Of course it can also be due to a bad
configuration of the kernel as well but having looked around I think that
usually driver are rather silent in case of deferring.
Powered by blists - more mailing lists