From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux admin Subject: Re: REGRESSION: i2c-imx endlessly triggers clk warning Date: Mon, 29 Jul 2019 12:26:57 +0100 Message-ID: <20190729112657.GW1330@shell.armlinux.org.uk> References: <20190729111720.GV1330@shell.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190729111720.GV1330@shell.armlinux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: linux-arm-kernel@lists.infradead.org, Oleksij Rempel , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Wolfram Sang , linux-i2c@vger.kernel.org, linux-imx@nxp.com List-Id: linux-i2c@vger.kernel.org On Mon, Jul 29, 2019 at 12:17:20PM +0100, Russell King - ARM Linux admin wrote: > Booting 5.2 on the VF610 based ZII rev B board results in the board > not making progress due to an endless stream of: > > [ 153.077831] ------------[ cut here ]------------ > [ 153.082528] WARNING: CPU: 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24 > [ 153.093077] i2c0 already disabled > [ 153.096416] Modules linked in: > [ 153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G W 5.2.0+ #321 > [ 153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) > [ 153.113772] Workqueue: events deferred_probe_work_func > [ 153.118979] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [ 153.126778] [] (show_stack) from [] (dump_stack+0x9c/0xd4) > [ 153.134051] [] (dump_stack) from [] (__warn+0xf8/0x124) > [ 153.141056] [] (__warn) from [] (warn_slowpath_fmt+0x38/0x48) > [ 153.148580] [] (warn_slowpath_fmt) from [] (clk_core_disable_lock+0x18/0x24) > [ 153.157413] [] (clk_core_disable_lock) from [] (i2c_imx_probe+0x554/0x6ec) > [ 153.166076] [] (i2c_imx_probe) from [] (platform_drv_probe+0x48/0x98) > [ 153.174297] [] (platform_drv_probe) from [] (really_probe+0x1d8/0x2c0) > [ 153.182605] [] (really_probe) from [] (driver_probe_device+0x5c/0x174) > [ 153.190909] [] (driver_probe_device) from [] (bus_for_each_drv+0x44/0x8c) > [ 153.199480] [] (bus_for_each_drv) from [] (__device_attach+0xa0/0x108) > [ 153.207782] [] (__device_attach) from [] (bus_probe_device+0x88/0x90) > [ 153.215999] [] (bus_probe_device) from [] (deferred_probe_work_func+0x60/0x90) > [ 153.225003] [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x634) > [ 153.234178] [] (process_one_work) from [] (worker_thread+0x20/0x484) > [ 153.242315] [] (worker_thread) from [] (kthread+0x118/0x150) > [ 153.249758] [] (kthread) from [] (ret_from_fork+0x14/0x20) > [ 153.257006] Exception stack(0xdde43fb0 to 0xdde43ff8) > [ 153.262095] 3fa0: 00000000 00000000 00000000 00000000 > [ 153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 153.278520] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 > [ 153.285159] irq event stamp: 3323022 > [ 153.288787] hardirqs last enabled at (3323021): [] _raw_spin_unlock_irq+0x24/0x2c > [ 153.297261] hardirqs last disabled at (3323022): [] clk_enable_lock+0x10/0x124 > [ 153.305392] softirqs last enabled at (3322092): [] __do_softirq+0x344/0x540 > [ 153.313352] softirqs last disabled at (3322081): [] irq_exit+0x10c/0x128 > [ 153.320946] ---[ end trace a506731ccd9bd703 ]--- > > My guess is that this is due to a combination of e1ab9a468e3b ("i2c: > imx: improve the error handling in i2c_imx_dma_request()") and the fact > that my configuration has CONFIG_FSL_EDMA=m. Given that the boot makes > no progress, it seems that this driver now requires EDMA to be built-in > _if_ this driver is also built in. It seems that Kconfig allows an > invalid configuration as far as the driver is concerned. > > However, even though it seems that EDMA needs to be built-in with > 5.2, this should not trigger the above kernel warning, which suggests > something is wrong in the driver cleanup paths. The endless loop is probably caused by the driver not obeying the basic rule of: claim resources THEN publish APIs. The driver registers itself with the I2C core as an adapter (which then causes the child devices to be created _and_ probed, thereby triggering the deferred probing) only to fail later when trying to get DMA resources, and returning -EPROBE_DEFER. This causes the i2c-imx driver to be immediately reprobed. This driver really needs to obey the basic rule of drivers. -- 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