Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 19 Jun 2023 17:19:12 +0200
From:   Jean Delvare <jdelvare@suse.de>
To:     Marius Hoch <mail@mariushoch.de>
Cc:     linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] i2c: i801: Force no IRQ for Dell Latitude E7450
Message-ID: <20230619171912.5407a7eb@endymion.delvare>
In-Reply-To: <967411b3-7013-619e-4fef-90644fa8d489@mariushoch.de>
References: <20230514103634.235917-1-mail@mariushoch.de>
        <20230523200350.62ab4788@endymion.delvare>
        <59a6a917-2a93-d52d-37f3-091295dd0db4@mariushoch.de>
        <20230604160132.102dd6a7@endymion.delvare>
        <967411b3-7013-619e-4fef-90644fa8d489@mariushoch.de>
Organization: SUSE Linux
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, 18 Jun 2023 15:42:40 +0200, Marius Hoch wrote:
> I just booted with acpi=3Dnoirq, the PCI device no longer fails to be=20
> enabled and the device got assigned IRQ 19 now (according to lspci -v/=20
> proc/interrupts), while the freefall device remained at IRQ 18.
> Interestingly dmesg is full of spam from the freefall device (endlessly=20
> reporting that freefall got detected, probably indicating a problem in=20
> IRQ handling, yikes).

Unfortunately, while acpi=3Dnoirq can be useful for testing purposes and
bug investigation, there's no guarantee that a modern x86 system can
actually work properly without ACPI-based PCI routing.

> Booting without the smo8800 module results in:
> [root@fedora ~]# dmesg | grep -i smbus
> [=C2=A0=C2=A0 20.042515] i801_smbus 0000:00:1f.3: PCI->APIC IRQ transform=
: INT C=20
> -> IRQ 19 =20
> [=C2=A0=C2=A0 20.042548] i801_smbus 0000:00:1f.3: SPD Write Disable is set
> [=C2=A0=C2=A0 20.042574] i801_smbus 0000:00:1f.3: SMBus using PCI interru=
pt
> [=C2=A0=C2=A0 20.051270] i801_smbus 0000:00:1f.3: Accelerometer lis3lv02d=
 is=20
> present on SMBus but its address is unknown, skipping registration
> [=C2=A0=C2=A0 20.253942] i801_smbus 0000:00:1f.3: Transaction timeout
> [=C2=A0=C2=A0 20.461962] i801_smbus 0000:00:1f.3: Transaction timeout
>=20
> The "Transaction timeout" messages might indicate that interrupt routing=
=20
> isn't actually working?

Indeed. This means the driver waited for an interrupt but was never
called back.

--=20
Jean Delvare
SUSE L3 Support