Re: Linux 7.1-rc1

[Luna Jernberg]

Yeah noticed that it did when i looked later on the train

i can run Kernel 7.0.2 for now tough and if i fix another or an extra
problem thats just good

Den ons 29 apr. 2026 kl 10:45 skrev Hans de Goede <hansg@xxxxxxxxxx>:
>
> 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
> >> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >>> On Tue, 28 Apr 2026 at 11:11, Luna Jernberg <droidbittin@xxxxxxxxx> 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@xxxxxxxxx/
>
> 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@xxxxxxxxxxxxxx/
> >>>
> >>> 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.
> >
>