From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 5D70A28C854 for ; Wed, 29 Apr 2026 08:45:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777452349; cv=none; b=djhLhQ0y6FZ3+wPmUNdLPeVnniT0zv2uZYCz6/1uiw09wDU7pMrkEywPn2tuew1fqiSKEjKDYiJBw7j8F7l4/30LksylvmXlXsFuqA9oh/FHVkSvTlOl7Y3cy3+Q7EtVrqaO3xTdgUH2jk+tvuYK4PJ1JTFbW73zxFQpwt7q04U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777452349; c=relaxed/simple; bh=jlk07w5atrdjJYIOmiPzRu9EP7qKp/IGW1WWBJ6uPHk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ShcQkdfv6WN1cW8ecMMK0gZjFNQTlc33T4fGMrwS4lOI7urbbh7bapn+vFFJZEeqdzs5xkqNpcOpDVigvFowCoYXJo8ArYjczOC9csGkibdJ5P+mVbxSX6StBNgy1hzvVuW2JcCV3+EE7679f+AZS4glgDy9cjMjmaTcrKiL4kA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uqdsVtzE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uqdsVtzE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D48EC19425; Wed, 29 Apr 2026 08:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777452349; bh=jlk07w5atrdjJYIOmiPzRu9EP7qKp/IGW1WWBJ6uPHk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=uqdsVtzEDQWO+jo7uIHfkAbdq4GKmCd4pG9G5IfgCs6J9BVln/DO85ELClOIQS4n7 YH8vmwHDOj0WexZuO6W9J/08OKzLQ1cl2+Rsa3o8Ww4M74t4+AOUyAy+EPa/mcUDME 8t/Dq9YujV0IuY95wL6wafIblj+WCkyPGWvsKxbg7AThHIUfi6SMZniFsJbd8SMszA 437DJtnblre+4HjESTG/xQ9D2n+vnlXwHSsCOnTIj/h1Gbq7GEbUs0N81qMYmcPB0+ 8llkSVwGmuRj3z5yKB+ZTIGLOALgns7Ddn7lb0Jyfd/+DDwyISbgu/uH9ZMzj/l45e v62U021acC5pw== Message-ID: <15b38580-02bb-4c5c-a46b-1a1c9cc71a89@kernel.org> Date: Wed, 29 Apr 2026 10:45:44 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Linux 7.1-rc1 To: Andy Shevchenko , "Rafael J. Wysocki" Cc: Linus Torvalds , Luna Jernberg , lee@kernel.org, Jani Nikula , intel-gfx-bugs@lists.freedesktop.org, Mikael Eriksson , Linux Kernel Mailing List , Greg Kroah-Hartman References: From: Hans de Goede Content-Language: en-US, nl In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, On 29-Apr-26 08:12, Andy Shevchenko wrote: > On Tue, Apr 28, 2026 at 09:37:31PM +0200, Rafael J. Wysocki wrote: >> On Tue, Apr 28, 2026 at 8:46 PM Linus Torvalds >> wrote: >>> On Tue, 28 Apr 2026 at 11:11, Luna Jernberg wrote: >>>> >>>> have checked dmesg now, seems to be a module that's not loading as it should >>> >>> Hmm. Interesting, but I wouldn't expect that LPSS driver to matter. I >>> think it's mainly used for some random SoC boards, not by the display >>> backlight code. >>> >>> And in the full dmesg I then see >>> >>> intel-lpss 0000:00:15.2: enabling device (0000 -> 0002) >>> intel-lpss 0000:00:15.3: enabling device (0000 -> 0002) >>> >>> so I think it all should work regardless. >>> >>> Of course, maybe it does mess up i2c or something, which then messes >>> up EDID or whatever, but I would expect the backlight to most likely >>> be controlled by aome ACPI thing. >>> >>> So that module failure sounds to me like it should be unrelated - and >>> might happen even on a working setup? >>> >>> I'm adding Rafael to the cc anyway, because he'd likely know about >>> both the OpRegion conflict thing, but also maybe if something has >>> changed in the ACPI backlight situation that might be the cause of >>> your backlight issues... > > Thanks for Cc'ing me. > > The OpRegion conflict is known issue from the past. The background is that. > The GEXP device described in the DSDT (main ACPI table) is a PCA953x compatible > GPIO I²C expander which has a bare minimum driver written in ASL! We do not > support such configuration in the kernel (we have C-based kernel driver for > such hardware). The question is, what the configuration made that appears > (I bet this conflict was on the working case). Because we have workarounds > for PCI enumerated devices, but here it seems to come from ACPI-enumerated > one?! Luna, please, share the output of the following run by root user (via > some pastebin or alike service to avoid spamming too much the mailing lists): > > - `acpidump -o dell-7390-skl.dat` # The *.dat file > - `lspci -vv -nk` > - `grep -H 15 /sys/bus/acpi/devices/*/status` > - `cat /proc/iomem` > > In either case, to avoid that OpRegion warning message we should add your > platform to the quirk list (either to intel-lpss-pci.c or, surprisingly to > me, to intel-lpss-acpi.c). One may see some in the PCI case already there. We actually already have a patch pending upstream adding a similar quirk mechanism to intel-lpss-acpi.c: https://lore.kernel.org/platform-driver-x86/20260320000937.9177-2-tchatard@gmail.com/ Extending this with the DMI info from Luna's machine should fix the resource conflict. But as Andy said this resource conflict is a well known issue on this generation of laptops when using IPU3 MIPI cameras instead of a UVC camera. Adding the quirk quirk will make the LPSS i2c-controller used for the camera sensor but that should be completely unrelated to the backlight problem. Also note that just getting the i2c-controller resource conflict resolved is NOT enough to get the cameras to work on these devices. I expect that the working 7.0.2 dmesg will have the same resource-conflict. Regards, Hans > >>> (Rafael, see >>> >>> https://lore.kernel.org/all/CADo9pHg8c=rouBQAd0o0TzK4iZc88dUAhSfV7q2T3GCf2qjuiQ@mail.gmail.com/ >>> >>> for dmesg etc information) >> >> Thanks! >> >> It would be good to know what the problem with the display is, specifically. >> >> Luna, can you send dmesg output from 7.0.2 for comparison? >> >> There are a few changes in 7.1-rc1 that touch the ACPI video bus driver: >> >> e18947038bf4 ACPI: driver: Do not set acpi_device_class() unnecessarily >> 69652f32c9ac ACPI: event: Redefine acpi_notifier_call_chain() >> 97892d5f0690 ACPI: driver: Do not set acpi_device_name() unnecessarily >> 6a8e793ca8db ACPI: video: Consolidate pnp.bus_id workarounds handling >> 9dc11faca245 ACPI: video: Rework checking for duplicate video bus devices >> >> but this one seems to be working: >> >> [ 2.111324] ACPI: video: Video Device [GFX0] (multi-head: yes rom: >> no post: no) >> [ 2.112585] input: Video Bus as >> /devices/pci0000:00/acpi.video_bus.0/input/input5 >> >> As for the OpRegion conflict message, it appears to come from >> mfd_add_device() that invokes acpi_check_resource_conflict() and >> passes its return value to the caller. That caller is most likely >> intel_lpss_probe() which then fails, so the probe fails for device >> INT3446:00 which is an i2c controller AFAICS. >> >> I'm wondering if this also happens in 7.0.2. >> >> Adding Andy (for intel-lpss) and Hans who has more experience with the >> ACPI video bus driver than I do. >