From: Mark Brown <broonie@kernel.org>
To: amelie.delaunay@st.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@st.com, linux-spi@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, fabrice.gasnier@st.com
Subject: Re: [PATCH 02/18] spi: stm32-spi: defer probe for reset
Date: Fri, 7 Aug 2020 15:01:54 +0100 [thread overview]
Message-ID: <20200807140154.GK5435@sirena.org.uk> (raw)
In-Reply-To: <20200807134254.GC12946@gnbcxd0016.gnb.st.com>
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]
On Fri, Aug 07, 2020 at 03:42:54PM +0200, Alain Volmat wrote:
> 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 ?
Yes, if for examaple the reset driver isn't being built then the driver
will defer for ever waiting for it to instantiate and the user will have
to have some method for figuring out what it's waiting for.
> 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.
This is not something that should be open coded in your driver.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-08-07 14:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-05 7:01 [PATCH 00/18] spi: stm32: various driver enhancements Alain Volmat
2020-08-05 7:01 ` [PATCH 01/18] spi: stm32-spi: driver uses reset controller only at init Alain Volmat
2020-08-05 7:01 ` [PATCH 02/18] spi: stm32-spi: defer probe for reset Alain Volmat
2020-08-05 10:49 ` Mark Brown
2020-08-07 13:42 ` Alain Volmat
2020-08-07 14:01 ` Mark Brown [this message]
2020-08-05 7:01 ` [PATCH 03/18] spi: stm32h7: remove unused mode fault MODF event handling Alain Volmat
2020-08-05 10:51 ` Mark Brown
2020-08-05 7:01 ` [PATCH 04/18] spi: stm32: use bitfield macros Alain Volmat
2020-08-05 7:02 ` [PATCH 05/18] spi: stm32h7: replace private SPI_1HZ_NS with NSEC_PER_SEC Alain Volmat
2020-08-05 7:02 ` [PATCH 06/18] spi: stm32h7: fix irq handler Alain Volmat
2020-08-05 7:02 ` [PATCH 07/18] spi: stm32h7: rework rx fifo read function Alain Volmat
2020-08-05 7:02 ` [PATCH 08/18] spi: stm32h7: fix dbg/warn/err conditions in irq handler Alain Volmat
2020-08-05 7:02 ` [PATCH 09/18] spi: stm32h7: fix race condition at end of transfer Alain Volmat
2020-08-05 10:53 ` Mark Brown
2020-08-05 7:02 ` [PATCH 10/18] spi: stm32: wait for completion in transfer_one() Alain Volmat
2020-08-05 10:58 ` Mark Brown
2020-08-05 7:02 ` [PATCH 11/18] spi: stm32: fix fifo threshold level in case of short transfer Alain Volmat
2020-08-05 10:59 ` Mark Brown
2020-08-05 7:02 ` [PATCH 12/18] spi: stm32: move spi disable out of irq handler Alain Volmat
2020-08-05 11:01 ` Mark Brown
2020-08-05 7:02 ` [PATCH 13/18] spi: stm32h7: fix handling of dma transfer completed Alain Volmat
2020-08-05 11:02 ` Mark Brown
2020-08-05 7:02 ` [PATCH 14/18] spi: stm32: improve suspend/resume management Alain Volmat
2020-08-05 7:02 ` [PATCH 15/18] spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate Alain Volmat
2020-08-05 11:02 ` Mark Brown
2020-08-05 7:02 ` [PATCH 16/18] spi: stm32: always perform registers configuration prior to transfer Alain Volmat
2020-08-05 11:03 ` Mark Brown
2020-08-05 7:02 ` [PATCH 17/18] spi: stm32: properly handle 0 byte transfer Alain Volmat
2020-08-05 7:02 ` [PATCH 18/18] spi: stm32h7: ensure message are smaller than max size Alain Volmat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200807140154.GK5435@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alexandre.torgue@st.com \
--cc=amelie.delaunay@st.com \
--cc=fabrice.gasnier@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®