Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp675407ybl; Fri, 13 Dec 2019 02:52:48 -0800 (PST) X-Google-Smtp-Source: APXvYqwi/QsZO4SmbMM3jFmth6RkZ0ogHWOLwpR39Wb+3bvTpncnMxBgrsC8ZY6ImCFz083NdMBj X-Received: by 2002:a9d:6745:: with SMTP id w5mr13295893otm.221.1576234368913; Fri, 13 Dec 2019 02:52:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576234368; cv=none; d=google.com; s=arc-20160816; b=i2i6XcjWKGkgoQO36z6yl7DMHni5riCXlXwAwtYw0avcvzfTV+Kq1zVbgq45+gzdvM y4puk88VF6P/fP6CmQ+ZlC0OEB1G7v3q7BFCn26TIYJvgEhDga6IzC1tBhTDAwMy6UUR g52fWqMo2VeT8eKq3JHwGaeh5+5h4oqG0hjoi5LCXDxai2B/3SPB1hc7N+LVW+b/iJFu meoTCcYeoRI/J41QHks6Mld7M//mopcmBv87kW38ZcyJqquWwju96B4m/84k/8g5RE/u 1z9Bi/EMq5d0K9vv9l62ri7N4qxLIMjfqmTq6y/ZWrKCFo9qjZKmJos3U7aRZeanuA1y KRjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eE4y8gsP10bYUZzcVYOhJBg5DwSCvVSdn/DLmbL2E+c=; b=eoxZKp5Fe293UKN5lUgxugDnpAaqNwPogqbDsbp47g2F/ZSKPQiJEem0swAzB4BtWm At16vkaPlKvITQ+dweOsz0Je3/OYCWq3TYkmcvZ7Iq3/BQm9CQ3ydSssticSF0pJWQ2v IUo7XKbd4SQmspKGF6p2Q0v9yXCTTMY90cBUIN74+Z0/GOhZXgV2KtmiX1YpaAtxMgsv UvjRTqYo/7ZOwdhW6lqDpvWxTMlqJ9FMDPKPshU/Zqk5RvhZi2t2mMjLekUu9ICLhqtm TECWm4B35YduUq79GDzWO9eQqUY5kpMzd2qDK9mMiD3SOcwwmiU+MALiPebzW/AYYVCH gYrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=KG2Q9xxG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l67si5036258oib.151.2019.12.13.02.52.37; Fri, 13 Dec 2019 02:52:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=KG2Q9xxG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726771AbfLMKvI (ORCPT + 99 others); Fri, 13 Dec 2019 05:51:08 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:45278 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbfLMKvH (ORCPT ); Fri, 13 Dec 2019 05:51:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eE4y8gsP10bYUZzcVYOhJBg5DwSCvVSdn/DLmbL2E+c=; b=KG2Q9xxGPQbHwOnzaFTeiWqv4 MuzEQ0Mo63HBPb6xDidwbS+UxlTKXjYsOz5Rre7ybDEqTIEhVtAKLNr1ynkXWlvSi3D/arx+JZ3N8 YFBKUjVbMACt0wP04qZzq8vO4IXjdYdPZvE4DDM2iLkIhHZfUO8Fo8RMiC4o/34LinF5a0dYucLi5 TUwavlFDK6tAG9W9VyaXt4fHQKB/1TlRbEl4ThYBvfIarfWAbrEv9SnX6mZSfDGv9kzpGfu41OeWM mhO3sEVGlWYM283yIdijjSph58GOP4dp39WCnfVWjx3iAQbtNao5IQCMJd9Hio/TQ/WHsaLpyk+M/ tceFikAqw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:52398) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ifiX7-0004Il-Di; Fri, 13 Dec 2019 10:50:53 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1ifiX0-0007pM-S5; Fri, 13 Dec 2019 10:50:46 +0000 Date: Fri, 13 Dec 2019 10:50:46 +0000 From: Russell King - ARM Linux admin To: Peng Ma Cc: "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "linux-kernel@vger.kernel.org" , "linux@rempel-privat.de" , Abel Vesa , Aisheng Dong , Anson Huang , Bogdan Florin Vlad , BOUGH CHEN , Clark Wang , Daniel Baluta , Fancy Fang , Han Xu , Horia Geanta , Iuliana Prodan , Jacky Bai , Joakim Zhang , Jun Li , Leo Zhang , Leonard Crestez , Mircea Pop , Mirela Rabulea , Peng Fan , Peter Chen , Ranjani Vaidyanathan , Robert Chiras , Robin Gong , Shenwei Wang , Viorel Suman , Ying Liu , Zening Wang , "kernel@pengutronix.de" , "festevam@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "linux-i2c@vger.kernel.org" Subject: Re: [EXT] Re: [PATCH] i2c: imx: Defer probing if EDMA not available Message-ID: <20191213105046.GQ25745@shell.armlinux.org.uk> References: <20191127071136.5240-1-peng.ma@nxp.com> <20191128100613.GI25745@shell.armlinux.org.uk> <20191211104347.GA25745@shell.armlinux.org.uk> <20191211114230.GC25745@shell.armlinux.org.uk> <20191212105857.GE25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 13, 2019 at 10:33:51AM +0000, Peng Ma wrote: > > > >-----Original Message----- > >From: Russell King - ARM Linux admin > >Sent: 2019年12月12日 18:59 > >To: Peng Ma > >Cc: shawnguo@kernel.org; s.hauer@pengutronix.de; > >linux-kernel@vger.kernel.org; linux@rempel-privat.de; Abel Vesa > >; Aisheng Dong ; Anson Huang > >; Bogdan Florin Vlad ; > >BOUGH CHEN ; Clark Wang > >; Daniel Baluta ; Fancy > >Fang ; Han Xu ; Horia Geanta > >; Iuliana Prodan ; Jacky > >Bai ; Joakim Zhang ; Jun Li > >; Leo Zhang ; Leonard Crestez > >; Mircea Pop ; Mirela > >Rabulea ; Peng Fan ; Peter > >Chen ; Ranjani Vaidyanathan > >; Robert Chiras ; > >Robin Gong ; Shenwei Wang > >; Viorel Suman ; Ying Liu > >; Zening Wang ; > >kernel@pengutronix.de; festevam@gmail.com; > >linux-arm-kernel@lists.infradead.org; linux-i2c@vger.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: So you haven't tested the scenario that causes the problem. How convenient for you. > 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 Correct. I'm sorry, but my patience is wearing very thin. I've explained the problem in detail, I've explained how you can reproduce it, but it seems I'm not being listened to. So, I don't have anything further to add to this discussion that hasn't already been said. Consider any patch that adds *any* path that can return -EPROBE_DEFER after a successful call to i2c_add_numbered_adapter() or its similar functions to be NAK'd by myself on account of this infinite probe loop that has been proven in previous kernels to occur. Thanks. -- 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