From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Peng Ma <peng.ma@nxp.com>
Cc: Peter Chen <peter.chen@nxp.com>, Peng Fan <peng.fan@nxp.com>,
Jacky Bai <ping.bai@nxp.com>, Leo Zhang <leo.zhang@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mirela Rabulea <mirela.rabulea@nxp.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Mircea Pop <mircea.pop@nxp.com>, Fancy Fang <chen.fang@nxp.com>,
Leonard Crestez <leonard.crestez@nxp.com>,
"festevam@gmail.com" <festevam@gmail.com>,
Robin Gong <yibin.gong@nxp.com>, Abel Vesa <abel.vesa@nxp.com>,
Anson Huang <anson.huang@nxp.com>,
BOUGH CHEN <haibo.chen@nxp.com>, Ying Liu <victor.liu@nxp.com>,
Shenwei Wang <shenwei.wang@nxp.com>,
Clark Wang <xiaoning.wang@nxp.com>,
Viorel Suman <viorel.suman@nxp.com>,
Robert Chiras <robert.chiras@nxp.com>,
Iuliana Prodan <iuliana.prodan@nxp.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
Zening Wang <zening.wang@nxp.com>, Han Xu <han.xu@nxp.com>,
Daniel Baluta <daniel.baluta@nxp.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Aisheng Dong <aisheng.dong@nxp.com>,
Horia Geanta <horia.geanta@nxp.com>,
Joakim Zhang <qiangqing.zhang@nxp.com>,
"linux@rempel-privat.de" <linux@rempel-privat.de>,
Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>,
Bogdan Florin Vlad <bogdan.vlad@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
Jun Li <jun.li@nxp.com>
Subject: Re: [EXT] Re: [PATCH] i2c: imx: Defer probing if EDMA not available
Date: Thu, 12 Dec 2019 10:58:57 +0000 [thread overview]
Message-ID: <20191212105857.GE25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <VI1PR04MB4431DF2E270FC45A6CC878A9ED550@VI1PR04MB4431.eurprd04.prod.outlook.com>
On Thu, Dec 12, 2019 at 03:09:32AM +0000, Peng Ma wrote:
> Hello Russell,
>
> Thanks very much for your strict guidance and comments.
> I realized it is hard to us that we want to i2c used edma when edma
> probe after i2c probe.
I have no problem with that aim. I'm just very concerned by the
proposed implementation, especially when it has already been proven
to cause regressions in the kernel. I seem to remember that the
infinite loop caused other issues, such as the system being unable
to complete booting.
> I look forward to discussing with you as below, if you like.
> Thanks.
>
> You say I could do this:
> "So, if you want to do this (and yes, I'd also encourage it to be
> conditional on EDMA being built-in, as I2C is commonly used as a way
> to get at RTCs, which are read before kernel modules can be loaded)
> then you MUST move
> i2c_imx_dma_request() before
> i2c_add_numbered_adapter() to avoid the infinite loop."
>
> Even if I do this, It's hard to avoid the infinite loop of i2c probe caused by EDMA(build-in) initialization failure.
It isn't clear what you mean here.
If EDMA fails to probe (because fsl_edma_probe() returns an error other
than EPROBE_DEFER) then of_dma_find_controller() will return NULL. That
will be propagated down through i2c_imx_dma_request(). This is no
different from the case where EDMA is built as a module. It is also no
different from the case where EDMA hasn't yet been probed.
If i2c_imx_dma_request() is placed after i2c_add_numbered_adapter(),
and EPROBE_DEFER is propagated out of i2c_imx_probe(), then _yes_, it
will cause an infinite loop, because you are replicating the exact
conditions that caused the attempt to propagate i2c_imx_dma_request()'s
return value to be reverted last time - which brought the kernel to a
grinding halt.
If i2c_imx_dma_request() is placed before i2c_add_numbered_adapter(),
then there is no infinite deferred probing loop - yes, i2c_imx_probe()
will be called as a result of other drivers successfully probing, and
each time it will return EPROBE_DEFER, but the _key_ point is that
the action of i2c_imx_probe() will not _self trigger_ the deferred
probing _and_ place itself onto the deferred probe list.
Please, rather than continuing to send emails arguing over this point,
investigate the stated issue with some practical tests:
1. Make i2c_imx_probe() propagate i2c_imx_dma_request()'s return value,
as it did in the original patch.
2. Build i2c-imx into the kernel.
3. Build edma as a module.
4. Build and test boot the kernel and check what happens.
5. Move i2c_imx_dma_request() before i2c_add_numbered_adapter()
6. Build and test boot the resulting kernel and note any differences.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-12 11:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-27 7:12 [PATCH] i2c: imx: Defer probing if EDMA not available Peng Ma
2019-11-27 7:27 ` Uwe Kleine-König
2019-11-28 2:45 ` [EXT] " Peng Ma
2019-11-28 10:06 ` Russell King - ARM Linux admin
2019-12-11 10:25 ` [EXT] " Peng Ma
2019-12-11 10:43 ` Russell King - ARM Linux admin
2019-12-11 11:22 ` Peng Ma
2019-12-11 11:42 ` Russell King - ARM Linux admin
2019-12-12 3:09 ` Peng Ma
2019-12-12 10:58 ` Russell King - ARM Linux admin [this message]
2019-12-13 10:33 ` Peng Ma
2019-12-13 10:50 ` Russell King - ARM Linux admin
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=20191212105857.GE25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=abel.vesa@nxp.com \
--cc=aisheng.dong@nxp.com \
--cc=anson.huang@nxp.com \
--cc=bogdan.vlad@nxp.com \
--cc=chen.fang@nxp.com \
--cc=daniel.baluta@nxp.com \
--cc=festevam@gmail.com \
--cc=haibo.chen@nxp.com \
--cc=han.xu@nxp.com \
--cc=horia.geanta@nxp.com \
--cc=iuliana.prodan@nxp.com \
--cc=jun.li@nxp.com \
--cc=kernel@pengutronix.de \
--cc=leo.zhang@nxp.com \
--cc=leonard.crestez@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=mircea.pop@nxp.com \
--cc=mirela.rabulea@nxp.com \
--cc=peng.fan@nxp.com \
--cc=peng.ma@nxp.com \
--cc=peter.chen@nxp.com \
--cc=ping.bai@nxp.com \
--cc=qiangqing.zhang@nxp.com \
--cc=ranjani.vaidyanathan@nxp.com \
--cc=robert.chiras@nxp.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=shenwei.wang@nxp.com \
--cc=victor.liu@nxp.com \
--cc=viorel.suman@nxp.com \
--cc=xiaoning.wang@nxp.com \
--cc=yibin.gong@nxp.com \
--cc=zening.wang@nxp.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;
as well as URLs for NNTP newsgroup(s).