Re: [PATCH 0/2] i2c: i801: Force no IRQ for Dell Latitude E7450

[Jean Delvare <jdelvare@suse.de>]

Hi Marius,

On Sat, 3 Jun 2023 11:24:02 +0200, Marius Hoch wrote:
> On 23/05/2023 20:03, Jean Delvare wrote:
> > On Sun, 14 May 2023 12:36:32 +0200, Marius Hoch wrote:  
> >> The Dell Latitude E7450 uses IRQ 18 for the accelerometer,
> >> but also claims that the SMBus uses IRQ 18. This will
> >> result in:
> >>
> >> i801_smbus 0000:00:1f.3: PCI INT C: failed to register GSI
> >> i801_smbus 0000:00:1f.3: Failed to enable SMBus PCI device (-16)
> >> i801_smbus: probe of 0000:00:1f.3 failed with error -16  
> > The i2c-i801 driver supports shared IRQ. If this fails, this means that
> > the other driver is not passing IRQF_SHARED when registering the
> > interrupt. Which driver is this? I'd rather check whether sharing the
> > IRQ is possible, rather that falling back to polling, which has a
> > performance cost.  
> I don't think this is a conflict rather than a completely bogus entry: 
> smo8800 uses IRQ 18 (the freefall sensor).

You're probably right. I admit I misread your report originally and
thought requesting the IRQ was failing. But actually the failure
happens before that, when enabling the PCI device. So its not related
to sharing the interrupt.

> For the SMBus in acpi_pci_irq_enable, acpi_register_gsi fails for GSI 18 
> with IRQ 255 (dev->irq), independently from the presence of the 
> dell_smo8800 module.
>
> Now looking into this again, seeing dev->irq at 255 seems very 
> suspicious here? Doesn't that mean not connected (although I'm not sure 
> how this relates to it supposedly having GSI 18)?

I admit I don't know. I'm not familiar with how GSI numbers relate to
IRQ numbers. I think I understand that GSI numbers are an ACPI thing,
and the ACPI layer is responsible for mapping these to actual IRQ
numbers? Is there a GSI-to-IRQ table available somewhere as part of the
ACPI tables? If so, it would be interesting to disassemble the ACPI
tables on your system and check what this looks like for you.

If this is a bug in the ACPI data then it might be worth booting with
acpi=noirq and see if it helps. This option might break other things
though (like free fall detection or thermal management) so be cautious.

IRQ number 255 indeed looks suspicious, but I'm also not aware of this
being a special value (nr_irqs is defined as an unsigned int, which
suggest that large IRQ numbers, albeit unusual on desktop and laptop
systems, are supported and frequently seen on large server systems), so
the i2c-i801 driver has no reason to handle it in a particular way.

Out of curiosity, did you check for a BIOS update for your laptop? Did
you look at BIOS option to see if by any chance enabling/disabling the
SMBus interrupt is an option there?

I'm also curious how you collected the IRQ value. Did you boot with
some debug kernel parameter, like dyndbg="file pci_irq.c +p"?

Did you manage to figure out where in the function call chain (starting
with pcim_enable_device) the failure actually happens? Even if IRQ
value 255 is most probably wrong in your case, I'm surprised that this
causes an error at device activation time, rather than when later
requesting the IRQ.

> >> Force the SMBus IRQ to IRQ_NOTCONNECTED in this case, so that
> >> we fall back to polling, which also seems to be what the (very
> >> dated) Windows 7 drivers on the Dell Latitude E7450 do.  
> > What makes you think so?
>
> According to the Windows 7 device manager IRQ view, the SMBus has no IRQ 
> assigned, which I assumed implies that polling is used. If there is 
> another way to check this on Windows 7, please let me know.

That's a reasonable assumption, and not being familiar with Windows, I
don't have any other suggestion. However that doesn't necessarily mean
that interrupts can't work. After all, the original i2c-i801 Linux
driver also did not support interrupts.

-- 
Jean Delvare
SUSE L3 Support