Re: mfd: intel_soc_pmic_bxtwc: irq 0 issue, tmu and typec components fail to probe.

[Andy Shevchenko <andy.shevchenko@gmail.com>]

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 <zhangn1985@outlook.com> 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

-- 
With Best Regards,
Andy Shevchenko