From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0616AC433EF for ; Tue, 21 Jun 2022 14:00:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350061AbiFUOAo (ORCPT ); Tue, 21 Jun 2022 10:00:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345600AbiFUOAm (ORCPT ); Tue, 21 Jun 2022 10:00:42 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 765A41CFC0; Tue, 21 Jun 2022 07:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655820041; x=1687356041; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HaIHmdDuWNWs5ZY/z5rbTpXTCQ5tcbRSe3Xe+h2LBBU=; b=dK0yhS23np6whT1VvrB459g+eiuGTeT4eXwjq9+jkr0IjTWBnJJPVP/j EGc/YL/qwwoiDZh3QThJtdzbnGcoWXrBieH1GuCZyF+0oOUrivjUhPvm8 FIzr1u/W/4pa4DbCzLj9NQ87pn33FLDuAxg/z8MJJDec1ciln7nsL0MkU y4j71WYW/H5F74FoiwVYOX5BUmZmZ8bLyxeRP5CHiQJ34s34FvwN06AfJ Um0HNPl37T3wFF4WRB9jsYiWst6mkRa0Ffw7Ysb+3Ai/SlaefCm7rP6bv z3S3PjWToBERizN1gsVaIg7a3XMpHM+d6M/vzCmBE91aMY6T4LoRvn+sN w==; X-IronPort-AV: E=McAfee;i="6400,9594,10384"; a="277672115" X-IronPort-AV: E=Sophos;i="5.92,209,1650956400"; d="scan'208";a="277672115" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2022 07:00:41 -0700 X-IronPort-AV: E=Sophos;i="5.92,209,1650956400"; d="scan'208";a="714983313" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2022 07:00:38 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1o3eQl-000rZF-Rb; Tue, 21 Jun 2022 17:00:35 +0300 Date: Tue, 21 Jun 2022 17:00:35 +0300 From: Andy Shevchenko To: Bjorn Helgaas , Marc Zyngier Cc: Fabio Estevam , Marek Vasut , Ksenija Stanojevic , Dmitry Torokhov , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring Subject: Re: mxs_lradc_ts: Warning due to "0 is an invalid IRQ number" Message-ID: References: <20200701224145.GA3616172@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200701224145.GA3616172@bjorn-Precision-5520> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Cc: Marc in case I'm utterly wrong in my conclusion below. On Wed, Jul 01, 2020 at 05:41:45PM -0500, Bjorn Helgaas wrote: > On Wed, Jul 01, 2020 at 12:32:48PM -0300, Fabio Estevam wrote: > > On Tue, Jun 16, 2020 at 8:52 PM Fabio Estevam wrote: > > > I am seeing the following warning on a imx28-evk running linux-next: > > > > > > [ 7.625012] ------------[ cut here ]------------ > > > [ 7.630111] WARNING: CPU: 0 PID: 1 at drivers/base/platform.c:317 > > > __platform_get_irq_byname+0x74/0x90 > > > [ 7.639692] 0 is an invalid IRQ number > > > [ 7.643540] Modules linked in: > > > [ 7.646961] CPU: 0 PID: 1 Comm: swapper Not tainted > > > 5.8.0-rc1-next-20200616-dirty #92 > > > [ 7.654896] Hardware name: Freescale MXS (Device Tree) > > > [ 7.660434] [] (unwind_backtrace) from [] > > > (show_stack+0x10/0x14) > > > [ 7.668591] [] (show_stack) from [] (__warn+0xe4/0x108) > > > [ 7.675941] [] (__warn) from [] > > > (warn_slowpath_fmt+0x6c/0xb8) > > > [ 7.683575] [] (warn_slowpath_fmt) from [] > > > (__platform_get_irq_byname+0x74/0x90) > > > [ 7.693101] [] (__platform_get_irq_byname) from > > > [] (platform_get_irq_byname+0x10/0x48) > > > [ 7.703154] [] (platform_get_irq_byname) from > > > [] (mxs_lradc_ts_probe+0x190/0x384) > > > [ 7.712771] [] (mxs_lradc_ts_probe) from [] > > > (platform_drv_probe+0x48/0x98) > > > [ 7.722806] [] (platform_drv_probe) from [] > > > (really_probe+0x218/0x348) > > > [ 7.731530] [] (really_probe) from [] > > > (driver_probe_device+0x58/0xb4) > > > [ 7.740189] [] (driver_probe_device) from [] > > > (device_driver_attach+0x58/0x60) > > > [ 7.749471] [] (device_driver_attach) from [] > > > (__driver_attach+0x84/0xc0) > > > [ 7.758394] [] (__driver_attach) from [] > > > (bus_for_each_dev+0x70/0xb4) > > > [ 7.766977] [] (bus_for_each_dev) from [] > > > (bus_add_driver+0x154/0x1e0) > > > [ 7.775385] [] (bus_add_driver) from [] > > > (driver_register+0x74/0x108) > > > [ 7.783872] [] (driver_register) from [] > > > (do_one_initcall+0x68/0x268) > > > [ 7.792467] [] (do_one_initcall) from [] > > > (kernel_init_freeable+0x160/0x1f4) > > > [ 7.801661] [] (kernel_init_freeable) from [] > > > (kernel_init+0x8/0xf4) > > > [ 7.810165] [] (kernel_init) from [] > > > (ret_from_fork+0x14/0x24) > > > [ 7.818101] Exception stack(0xc748dfb0 to 0xc748dff8) > > > [ 7.823273] dfa0: 00000000 > > > 00000000 00000000 00000000 > > > [ 7.831815] dfc0: 00000000 00000000 00000000 00000000 00000000 > > > 00000000 00000000 00000000 > > > [ 7.840351] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 > > > [ 7.847322] irq event stamp: 273303 > > > [ 7.850940] hardirqs last enabled at (273311): [] > > > console_unlock+0x390/0x534 > > > [ 7.859314] hardirqs last disabled at (273328): [] > > > console_unlock+0x44/0x534 > > > [ 7.867605] softirqs last enabled at (273344): [] > > > __do_softirq+0x2d4/0x450 > > > [ 7.875817] softirqs last disabled at (273355): [] > > > irq_exit+0x150/0x174 > > > [ 7.883472] ---[ end trace ddb222ada5cbf5cd ]--- > > > [ 7.900004] input: mxs-lradc-ts as > > > /devices/soc0/80000000.apb/80040000.apbx/80050000.lradc/mxs-lradc-ts/input/input0 > > > > > > The touchscreen irq is defined as: > > > > > > enum mx28_lradc_irqs { > > > MX28_LRADC_TS_IRQ = 0, > > > > > > Shouldn't we retrieve the IRQ number from the device tree instead? > > mxs_lradc_ts_probe() > { > ... > irq = platform_get_irq_byname(pdev, mxs_lradc_ts_irq_names[i]); > if (irq < 0) > return irq; > > virq = irq_of_parse_and_map(node, irq); > ... > } > > That's not right, is it? irq_of_parse_and_map() takes an *index*, but > we're passing an IRQ. > > mxs_lradc_adc_probe() also has the same pattern. Yeah, you are right. This code is broken by design. But the issue is that MFD driver supplies _index_ and not vIRQ from proper IRQ domain. I dunno how it's supposed to work without dirty tricks in the GIC (or whatever interrupt controller is there). Since there is no response to this thread by the authors of the code, I would mark it as BROKEN and perhaps remove from the kernel if no-one steps in to fix this mess. -- With Best Regards, Andy Shevchenko