Re: Linux 7.1-rc1

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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
> <torvalds@linux-foundation.org> wrote:
> > On Tue, 28 Apr 2026 at 11:11, Luna Jernberg <droidbittin@gmail.com> 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.

> > (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.

-- 
With Best Regards,
Andy Shevchenko