[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<TY2PR01MB3322AAB13DBBB16C334A5D39CDBB2@TY2PR01MB3322.jpnprd01.prod.outlook.com>
Date: Sat, 10 Aug 2024 13:27:18 +0800
From: Zhang Ning <zhangn1985@...look.com>
To: Andy Shevchenko <andy@...nel.org>
Cc: gregkh@...uxfoundation.org, rafael@...nel.org,
linux-kernel@...r.kernel.org, lee@...nel.org
Subject: Re: mfd: intel_soc_pmic_bxtwc: irq 0 issue, tmu and typec components
fail to probe.
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;
> > > >
Hi, Greg
One more question, I don't understand why 0 is not a valid IRQ
number for platform device?
> > > > 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).
>
> > > > [0]: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1156/diffs
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Powered by blists - more mailing lists