From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Turquette Subject: Re: OMAP EHCI having clock problems? Date: Thu, 14 Feb 2013 21:12:46 -0800 Message-ID: <20130215051246.11471.99180@quantum> References: <87halea4s3.fsf@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Return-path: Received: from mail-pa0-f48.google.com ([209.85.220.48]:59394 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750718Ab3BOFMw convert rfc822-to-8bit (ORCPT ); Fri, 15 Feb 2013 00:12:52 -0500 Received: by mail-pa0-f48.google.com with SMTP id hz10so1625878pad.21 for ; Thu, 14 Feb 2013 21:12:52 -0800 (PST) In-Reply-To: <87halea4s3.fsf@linaro.org> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Kevin Hilman , Felipe Balbi , Roger Quadros Cc: linux-omap Quoting Kevin Hilman (2013-02-14 14:50:52) > Any idea what's going on? Looks like a couple of different things. > [ 0.515747] usbhs_omap usbhs_omap: ehci_logic_fck failed:-2 Seems like the clk_get lookup failed here in usbhs_omap_probe. So from this point on omap->ehci_logic_fck == -ENOENT. This bogus value gets passed into all of the clk apis, which leads us to the below error. > [ 0.516021] ------------[ cut here ]------------ > [ 0.516082] WARNING: at /work/kernel/omap/dev/drivers/clk/clk.c:522 __clk_enable+0x8c/0x9c() > [ 0.516082] Modules linked in: > [ 0.516143] [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x4c/0x64) > [ 0.516143] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x1c/0x24) > [ 0.516174] [] (warn_slowpath_null+0x1c/0x24) from [] (__clk_enable+0x8c/0x9c) > [ 0.516174] [] (__clk_enable+0x8c/0x9c) from [] (clk_enable+0x20/0x3c) > [ 0.516204] [] (clk_enable+0x20/0x3c) from [] (usbhs_runtime_resume+0x60/0xa4) > [ 0.516235] [] (usbhs_runtime_resume+0x60/0xa4) from [] (pm_generic_runtime_resume+0x2c/0x40) > [ 0.516265] [] (pm_generic_runtime_resume+0x2c/0x40) from [] (__rpm_callback+0x34/0x70) > [ 0.516296] [] (__rpm_callback+0x34/0x70) from [] (rpm_resume+0x3bc/0x648) > [ 0.516326] [] (rpm_resume+0x3bc/0x648) from [] (__pm_runtime_resume+0x48/0x60) > [ 0.516326] [] (__pm_runtime_resume+0x48/0x60) from [] (usbhs_omap_probe+0x200/0x840) > [ 0.516357] [] (usbhs_omap_probe+0x200/0x840) from [] (platform_drv_probe+0x18/0x1c) > [ 0.516387] [] (platform_drv_probe+0x18/0x1c) from [] (driver_probe_device+0x78/0x210) > [ 0.516387] [] (driver_probe_device+0x78/0x210) from [] (__driver_attach+0x94/0x98) > [ 0.516418] [] (__driver_attach+0x94/0x98) from [] (bus_for_each_dev+0x50/0x7c) > [ 0.516448] [] (bus_for_each_dev+0x50/0x7c) from [] (bus_add_driver+0x178/0x240) > [ 0.516448] [] (bus_add_driver+0x178/0x240) from [] (driver_register+0x78/0x144) > [ 0.516479] [] (driver_register+0x78/0x144) from [] (platform_driver_probe+0x18/0x9c) > [ 0.516479] [] (platform_driver_probe+0x18/0x9c) from [] (do_one_initcall+0x34/0x178) > [ 0.516510] [] (do_one_initcall+0x34/0x178) from [] (kernel_init_freeable+0xfc/0x1cc) > [ 0.516571] [] (kernel_init_freeable+0xfc/0x1cc) from [] (kernel_init+0x8/0xe4) > [ 0.516571] [] (kernel_init+0x8/0xe4) from [] (ret_from_fork+0x14/0x24) > [ 0.516693] ---[ end trace e713e7725948e018 ]--- This WARN gets tripped when a clock is enabled but not prepared. From __clk_enable in drivers/clk/clk.c: if (WARN_ON(clk->prepare_count == 0)) return -ESHUTDOWN; So we're basically dereferencing a bogus struct clk pointer in __clk_enable and the memory address of clk->prepare_count just happens to be zero filled. On a related note, even if the clk_get lookup did not fail this WARN would still be hit since this driver never once calls clk_prepare. Regards, Mike