linux-kernel - Re: [PATCH 1/1] ACPI: scan: Ignore Dell XPS 9320 camera graph port nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0jN3CXM9vWQniu1Q2t1NvG9n5KoG0VGHnMgdPU2iHpBvw@mail.gmail.com>
Date: Thu, 13 Jun 2024 11:50:48 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: Hans de Goede <hdegoede@...hat.com>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Genes Lists <lists@...ience.com>, linux-kernel@...r.kernel.org, mchehab@...nel.org, 
	hverkuil-cisco@...all.nl, laurent.pinchart@...asonboard.com, 
	wentong.wu@...el.com, linux-media@...r.kernel.org, linux-acpi@...r.kernel.org, 
	"regressions@...ts.linux.dev" <regressions@...ts.linux.dev>
Subject: Re: [PATCH 1/1] ACPI: scan: Ignore Dell XPS 9320 camera graph port nodes

Hi Sakari,

On Wed, Jun 12, 2024 at 10:17 PM Sakari Ailus
<sakari.ailus@...ux.intel.com> wrote:
>
> Hi Hans,
>
> On Wed, Jun 12, 2024 at 04:30:30PM +0200, Hans de Goede wrote:
> > Sakari I know you have been pushing for MIPI camera descriptions under
> > ACPI to move to a standardized format and I can see how that is a good
> > thing, but atm it seems to mainly cause things to break and before
> > the ACPI MIPI DISCO support landed in 6.8 we did not have these issues,
> > since the information used by the ipu-bridge code does seem to be correct.
>
> Support for capturing from cameras on IPU6 systems (IPU6 ISYS driver and
> IPU bridge changes) was upstreamed for 6.10, with some drivers such as IVSC
> (four of them) and IVSC related IPU bridge changes merged for 6.8 already.
>
> We can't guarantee the continued functioning of downstream drivers in cases
> where new upstream drivers for the same devices get merged to the kernel,
> often with different APIs. You know that as well as I do.
>
> In other words, there was no regression with respect to the upstream
> kernel.

Users' opinions on this may differ I suppose.

If a user sees a new kernel warning on boot, they will easily count it
as a regression, and with panic_on_warn this becomes a full-fledged
kernel crash.

This is bad, even though it may be coming from a new driver strictly speaking.