From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E5D749641 for ; Tue, 24 Sep 2024 18:02:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727200945; cv=none; b=Dl0LsVRBHtAz12+gq/dvSUXeRqdYQXD2BQzoY2ghmDHLkdxDf90Be0UrFF/lkwcT5xnFk7wtasbGBMcHrGHj4BjOvvFLIJUlE/7QqFwq7cLSVknhh7yFOFinLFcbFHlq3xDvp62voo7cCqTkh7nt5+0Kqgf+8zKTd6Mzt4s1Wa0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727200945; c=relaxed/simple; bh=6W6Y+kifFqrN7M+nduK5Yxd3rGxzXysHmSQTcLRAt/g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TjkBQHPWg/Gt946cxAAKnj/uAIcFaTzhKefBIvogDmSpMLsCE4x6lecmjI8+mc4cmRzhLKGu4whzJq1zO118XJIOVKgLA3ftAhX1xRP4eCggYNFGeyonEnX9sslg9y/MHKGsflbXbj2ZMlPHduOPM2Z3qhgdUjF8JDYJlem0+/U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com; spf=fail smtp.mailfrom=gmail.com; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=gmail.com X-CSE-ConnectionGUID: K9Ns0OmjTEmft7F+Rh7dyw== X-CSE-MsgGUID: 8TFgLXt5R1qm0GN+GqOl5g== X-IronPort-AV: E=McAfee;i="6700,10204,11205"; a="26087013" X-IronPort-AV: E=Sophos;i="6.10,255,1719903600"; d="scan'208";a="26087013" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2024 11:02:05 -0700 X-CSE-ConnectionGUID: y8hQ46MLTTaRKpEYf6C2EA== X-CSE-MsgGUID: wQnRmF4eRDiKXtTzSBR1NQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,255,1719903600"; d="scan'208";a="71386831" Received: from smile.fi.intel.com ([10.237.72.54]) by orviesa010.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2024 11:02:03 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1st9rM-0000000CXCh-1rpP; Tue, 24 Sep 2024 21:02:00 +0300 Date: Tue, 24 Sep 2024 21:02:00 +0300 From: Andy Shevchenko To: Zhang Ning Cc: gregkh@linuxfoundation.org, rafael@kernel.org, linux-kernel@vger.kernel.org, lee@kernel.org Subject: Re: mfd: intel_soc_pmic_bxtwc: irq 0 issue, tmu and typec components fail to probe. Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Thu, Sep 05, 2024 at 03:33:14PM +0300, Andy Shevchenko wrote: > On Thu, Sep 05, 2024 at 07:27:25PM +0800, Zhang Ning wrote: > > On Wed, Sep 04, 2024 at 05:36:35PM +0300, Andy Shevchenko wrote: > > > On Wed, Sep 4, 2024 at 5:29 PM Zhang Ning wrote: > > > > On Fri, Aug 09, 2024 at 05:09:49PM +0300, Andy Shevchenko wrote: > > > > > On Fri, Aug 09, 2024 at 08:53:24PM +0800, Zhang Ning wrote: > > > > > > On Fri, Aug 09, 2024 at 03:33:33PM +0300, Andy Shevchenko wrote: > > > > > > > On Fri, Aug 09, 2024 at 08:02:43PM +0800, Zhang Ning wrote: > > > > > > > > Hi, Greg & Rafael > > > > > > > > > > > > > > > > recently, when I try to enable mfd components for intel_soc_pmic_bxtwc > > > > > > > > for debian kernel[0]. I find tmu and typec failed to probe. > > > > > > > > > > > > > > > > after check source code, I find irq for these two devices are 0, when > > > > > > > > use platform_get_irq, it will alway fail. > > > > > > > > > > > > > > > > if (WARN(!ret, "0 is an invalid IRQ number\n")) > > > > > > > > return -EINVAL; > > > > > > > > return ret; > > > > > > > > > > > > > > > > My workaround for debian is to hardcode irq to 0, instead to use api. > > > > > > > > > > > > > > > > I don't know how to write a good solution, thus send an email to you. > > > > > > > > > > > > > > Hold on, how the heck you got 0 in the first place?A > > > > > > > > > > > > use tmu as an example > > > > > > > > > > > > enum bxtwc_irqs_tmu { > > > > > > BXTWC_TMU_IRQ = 0, > > > > > > }; > > > > > > > > > > > > static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = { > > > > > > REGMAP_IRQ_REG(BXTWC_TMU_IRQ, 0, GENMASK(2, 1)), > > > > > > }; > > > > > > > > > > > > static const struct resource tmu_resources[] = { > > > > > > DEFINE_RES_IRQ_NAMED(BXTWC_TMU_IRQ, "TMU"), > > > > > > }; > > > > > > > > > > > > { > > > > > > .name = "bxt_wcove_tmu", > > > > > > .num_resources = ARRAY_SIZE(tmu_resources), > > > > > > .resources = tmu_resources, > > > > > > }, > > > > > > > > > > > > this is why I got 0, and I don't do any hack. > > > > > > > > > > Thanks for elaboration, I will look at this a bit later (may be next or one > > > > > after next week, just returned from vacations). > > > > > > > could you share the patch link to the fix? then I could port it to > > > > debian. > > > > > > Sorry I was busy with other stuff (as well), I am still in the middle > > > of debugging that. > > > The issue is that the leaf drivers for some reason do not request > > > proper vIRQ (that should come from the secondary IRQ chip). OTOH there > > > is only one _similar_ design in the kernel besides this one. And when > > > I tried to test the version where all this appears, I couldn't boot > > > (yeah, I spent some time on bisecting things) the board I have (One of > > > pre-production variants of Intel Joule SoM). > > > > Yes, me too. I'm trying to enable Joule on Debian. thus found this > > issue. you can use debian sid with linux 6.11 to debug this issue. > > > > and another issue is Joule HDA pci id is removed from Linux kernel, thus > > no sound, but I don't plan to submit an issue. > > > > > Do you have any (most recent) kernel version that works as expected? > > I don't try any old kernel, but from git log, I think bad commit is: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57129044f5044dcd73c22d91491906104bd331fd` > > No, it does the right thing from architectural point of view. It might be that > it was never tested or it was a regression somewhere. That's why I wanted to find > the newest possible kernel that works on that machine. > > > > > > > > > [0]: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1156/diffs I guess I now know all the story, hopefully I will come up with the fix this or next week. Stay tuned! -- With Best Regards, Andy Shevchenko