Message-ID: <VI1PR04MB44318D7C92B6A29D04840B0DED540@VI1PR04MB4431.eurprd04.prod.outlook.com>
Date:   Fri, 13 Dec 2019 10:33:51 +0000
From:   Peng Ma <peng.ma@....com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
CC:     "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux@...pel-privat.de" <linux@...pel-privat.de>,
        Abel Vesa <abel.vesa@....com>,
        Aisheng Dong <aisheng.dong@....com>,
        Anson Huang <anson.huang@....com>,
        Bogdan Florin Vlad <bogdan.vlad@....com>,
        BOUGH CHEN <haibo.chen@....com>,
        Clark Wang <xiaoning.wang@....com>,
        Daniel Baluta <daniel.baluta@....com>,
        Fancy Fang <chen.fang@....com>, Han Xu <han.xu@....com>,
        Horia Geanta <horia.geanta@....com>,
        Iuliana Prodan <iuliana.prodan@....com>,
        Jacky Bai <ping.bai@....com>,
        Joakim Zhang <qiangqing.zhang@....com>,
        Jun Li <jun.li@....com>, Leo Zhang <leo.zhang@....com>,
        Leonard Crestez <leonard.crestez@....com>,
        Mircea Pop <mircea.pop@....com>,
        Mirela Rabulea <mirela.rabulea@....com>,
        Peng Fan <peng.fan@....com>, Peter Chen <peter.chen@....com>,
        Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>,
        Robert Chiras <robert.chiras@....com>,
        Robin Gong <yibin.gong@....com>,
        Shenwei Wang <shenwei.wang@....com>,
        Viorel Suman <viorel.suman@....com>,
        Ying Liu <victor.liu@....com>,
        Zening Wang <zening.wang@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH] i2c: imx: Defer probing if EDMA not available



>-----Original Message-----
>From: Russell King - ARM Linux admin <linux@...linux.org.uk>
>Sent: 2019年12月12日 18:59
>To: Peng Ma <peng.ma@....com>
>Cc: shawnguo@...nel.org; s.hauer@...gutronix.de;
>linux-kernel@...r.kernel.org; linux@...pel-privat.de; Abel Vesa
><abel.vesa@....com>; Aisheng Dong <aisheng.dong@....com>; Anson Huang
><anson.huang@....com>; Bogdan Florin Vlad <bogdan.vlad@....com>;
>BOUGH CHEN <haibo.chen@....com>; Clark Wang
><xiaoning.wang@....com>; Daniel Baluta <daniel.baluta@....com>; Fancy
>Fang <chen.fang@....com>; Han Xu <han.xu@....com>; Horia Geanta
><horia.geanta@....com>; Iuliana Prodan <iuliana.prodan@....com>; Jacky
>Bai <ping.bai@....com>; Joakim Zhang <qiangqing.zhang@....com>; Jun Li
><jun.li@....com>; Leo Zhang <leo.zhang@....com>; Leonard Crestez
><leonard.crestez@....com>; Mircea Pop <mircea.pop@....com>; Mirela
>Rabulea <mirela.rabulea@....com>; Peng Fan <peng.fan@....com>; Peter
>Chen <peter.chen@....com>; Ranjani Vaidyanathan
><ranjani.vaidyanathan@....com>; Robert Chiras <robert.chiras@....com>;
>Robin Gong <yibin.gong@....com>; Shenwei Wang
><shenwei.wang@....com>; Viorel Suman <viorel.suman@....com>; Ying Liu
><victor.liu@....com>; Zening Wang <zening.wang@....com>;
>kernel@...gutronix.de; festevam@...il.com;
>linux-arm-kernel@...ts.infradead.org; linux-i2c@...r.kernel.org
>Subject: Re: [EXT] Re: [PATCH] i2c: imx: Defer probing if EDMA not available
>
>Caution: EXT Email
>
>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.
>
Hello Russell,

The result of my test is not like that, It is still with probe loop, the test config as follows:
1.EDMA build-in
2.return -EINVAL top of fsl_edma_probe when edma probe
3.i2c probe with original patch, I put the i2c_imx_dma_request in front of i2c_add_numbered_adapter or used original patch.

I send you the function of_dma_request_slave_channel could explain it last mail,
"Return -EPROBE_DEFER" depends on:
1. edma not probe or probe failed
2. There is edma node in DTS and I2C with edma property

>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.
>
[Peng Ma] the i2c probe loop still exist but not infinite loop with below cases:
1: 
	Used original patch
	Build i2c-imx into the kernel
	Build edma into the kernel
2:
	Used original patch
	Build i2c-imx into the kernel
	Build edma into the kernel
	Move i2c_imx_dma_request() before i2c_add_numbered_adapter()
3:
	Used original patch
	Build i2c-imx into the kernel
	Build edma as a module
	Move i2c_imx_dma_request() before i2c_add_numbered_adapter()

I saw the commit e8c220fac415d9f4a994b0c2871b835feac1eb4e you said
1. i2c_imx_probe() is called and successfully registers an I2C
   adapter via i2c_add_numbered_adapter()

2. As a part of i2c_add_numbered_adapter() new I2C slave devices
   are added from DT which results in a call to
   driver_deferred_probe_trigger()

3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which
   due to lack of proper DMA driver returns -EPROBE_DEFER

4. i2c_imx_probe() fails, removes I2C adapter and returns
   -EPROBE_DEFER, which places it into deferred probe list

5. Deferred probe work triggered in #2 above kicks in and calls
   i2c_imx_probe() again thus bringing us to step #1"
Can I understand 4, you mean just remove I2C adapter the i2c slave devices not be removed? Then the i2c slave devices will probe their drivers triggered the driver_deferred_probe_trigger().
If so, My test is not like this, when the i2c probe failed the i2c slave devices will be removed and I2C adapter will be removed too.

Best Regards,
Peng
>--
>RMK's Patch system:
>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ar
>mlinux.org.uk%2Fdeveloper%2Fpatches%2F&amp;data=02%7C01%7Cpeng.ma
>%40nxp.com%7Ca535712eabe343a51c2f08d77ef250e4%7C686ea1d3bc2b4c6
>fa92cd99c5c301635%7C0%7C0%7C637117451627341155&amp;sdata=%2Fyz
>xAI8%2FezVRwGTaT4vYa3CMkIMsaSYiaH8DjvJWUKA%3D&amp;reserved=0
>FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps
>up According to speedtest.net: 11.9Mbps down 500kbps up

Powered by blists - more mailing lists