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 CBC86217704; Sat, 14 Feb 2026 01:06:19 +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=1771031179; cv=none; b=rbXqINScjJAKRkAzW15fF53JZnwR2oetUpacLxTMNRXNB0E2qCfTOGWgk+N1tmCz7uJjXMEjMawic50Tql5H8pUeZi2cJB78axKzGRceAXTj/TSeLpDWc04h0F904MgRqm0B/hHzw9ecHQeJLhkAFRdSJDLW+jRVPDcBsXBJOfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771031179; c=relaxed/simple; bh=fsFvBqud3Tvk5e7OR8HtRWBc2tx6+MNclWALLq3iwLw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=j0B/0MfJtATluUFc6+axGot3tTq1nRW7Ia58hD/cpQ7LevRzgXThdaCwnQu6M3OwXN1+zO641m3CXOYdYCpSlxgYzy71/7M5/f4n2GCTa4PD1qwJ0LV3UipBrinume8tD7MvmTcRB1HwVMndDzShaKi//gv+1I5xDcxka4zgOys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ngx3TUb7; 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="Ngx3TUb7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C30FAC19425; Sat, 14 Feb 2026 01:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771031179; bh=fsFvBqud3Tvk5e7OR8HtRWBc2tx6+MNclWALLq3iwLw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ngx3TUb7GpPfBnAjMctLd9eudS5iwLA4kOGo93Cf67eAxdzCBQC6F8kumnM7GgPoo tajBSVNhnEE/fjubEKnC/fUcsjLw8jT+P3qiowZ3zAji+gozjJmnwVpRscxpqoF3l3 IHwcMuJQ5zh0vQkQb954WTyHLjE4UIlbQOHTRm9DOjgYbQgW1XasGpc/zDMFUrdI3v NisSeUsKhOvq10tbOb5Li4ZuCpo5npsMInMeXJyVlXfEB/ediv+q1kmfyl8XLI9bi1 YDDCFnqW6wyd3hLspaHRJjVTPS8dL/VGm9goID+rSAa0wt+B412kpY9BcCA+PGKzyb IPYXfAmLVf1qQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Alexey Klimov , Bjorn Andersson , Vinod Koul , Douglas Anderson , Sasha Levin , neil.armstrong@linaro.org, dri-devel@lists.freedesktop.org Subject: [PATCH AUTOSEL 6.19-6.12] gpu/panel-edp: add AUO panel entry for B140HAN06.4 Date: Fri, 13 Feb 2026 19:59:32 -0500 Message-ID: <20260214010245.3671907-92-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260214010245.3671907-1-sashal@kernel.org> References: <20260214010245.3671907-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19 Content-Transfer-Encoding: 8bit From: Alexey Klimov [ Upstream commit 2976aeb0de77da599ad37691963efbdcb07435ce ] Add an eDP panel entry for AUO B140HAN06.4 that is also used in some variants of Lenovo Flex 5G with Qcom SC8180 SoC. The raw edid of the panel is: 00 ff ff ff ff ff ff 00 06 af 3d 64 00 00 00 00 2b 1d 01 04 a5 1f 11 78 03 b8 1a a6 54 4a 9b 26 0e 52 55 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 14 37 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 10 2c 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 34 30 48 41 4e 30 36 2e 34 20 0a 00 eb I do not have access to the datasheet and but it is tested on above mentioned laptop for a few weeks and seems to work just fine with timing info of similar panels. Cc: Bjorn Andersson Cc: Vinod Koul Signed-off-by: Alexey Klimov Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251203074555.690613-1-alexey.klimov@linaro.org Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: This is the key section. Now I have a complete understanding. Let me summarize the analysis. ## Detailed Analysis ### 1. Commit Message Analysis The commit adds a new panel entry (`EDP_PANEL_ENTRY`) for AUO B140HAN06.4 (panel ID `0x643d`) to the `panel-edp.c` driver's `edp_panels[]` lookup table. The panel is used in the Lenovo Flex 5G with a Qualcomm SC8180 SoC. The commit has been reviewed by Douglas Anderson (the panel-edp subsystem maintainer), and the author confirms it has been tested on real hardware for several weeks. ### 2. Code Change Analysis The change is a **single line addition**: ```c EDP_PANEL_ENTRY('A', 'U', 'O', 0x643d, &delay_200_500_e50, "B140HAN06.4"), ``` This adds the panel ID `0x643d` to the sorted list of known AUO panels, using the standard `delay_200_500_e50` delay timing (200ms HPD absent, 500ms unprepare, 50ms enable) -- a delay structure already heavily used by dozens of other AUO panel entries. The entry is inserted in the correct sorted position between `0x639c` and `0x723c`. ### 3. What happens WITHOUT this entry Looking at lines 805-825 of `panel-edp.c`, when `find_edp_panel()` fails to match a panel in the `edp_panels[]` table: 1. **`WARN_ON(!panel->detected_panel)` fires** (line 814) -- this produces a **kernel WARNING stack trace** in dmesg every time the system boots with this panel. This is a user-visible issue. 2. **Conservative timings are used** (line 818): `panel_edp_set_conservative_timings()` sets a 2000ms unprepare delay and 200ms enable delay (lines 753-754) instead of the optimal 500ms/50ms. This makes panel operations **significantly slower** for users. 3. **`detected_panel` is set to `ERR_PTR(-EINVAL)`** (line 756), which may affect other downstream behaviors. So without this entry, users with a Lenovo Flex 5G see a WARN_ON kernel splat on every boot and get suboptimal display performance. ### 4. Historical Context The B140HAN06.4 panel was originally added to `panel-simple.c` in commit `93ea7aa8dfc0c` (v5.15-era). During the split to `panel-edp.c` in commit `5f04e7ce392db` (v5.16-rc1), it was moved. However, it was then **removed** in commit `51e1fb144f17c` ("drm/panel-edp: drop several legacy panels", merged in v6.11-rc1) because the legacy compatible string approach was dropped in favor of the generic "edp-panel" device on the AUX bus. After that removal, the panel no longer had an entry in the `edp_panels[]` ID table, meaning the AUX bus approach can't find it by panel ID. This new commit restores support through the modern mechanism. ### 5. Classification: Device ID / Hardware Quirk Addition This is a textbook **device ID addition** to an existing driver -- one of the explicitly allowed exception categories for stable backports. The `edp_panels[]` table is directly analogous to PCI ID tables or USB ID tables. The commit: - Adds a single panel ID to an existing, well-established table - Uses existing delay parameters (`delay_200_500_e50`) -- no new code - Follows the exact same pattern as ~192 other entries in the table - The driver (`panel-edp.c`) already exists in stable trees (since v5.16) ### 6. Risk Assessment - **Risk: Essentially zero.** This is a one-line addition to a data table. It cannot affect any other panel or any other code path. It only activates when a panel with the exact matching EDID vendor/product ID is detected. - **Scope:** Single line, single file, data-only change. - **Dependencies:** None. The `delay_200_500_e50` structure and `EDP_PANEL_ENTRY` macro exist in all stable trees that have `panel- edp.c`. ### 7. User Impact - **Who:** Users of the Lenovo Flex 5G laptop (Qualcomm SC8180 SoC platform). This is a real, commercially available product. - **Without fix:** Kernel WARNING on every boot + slower panel operations due to conservative timings. - **With fix:** Clean boot, optimal panel timing, proper panel identification. ### 8. Backport Considerations - For stable trees **v6.11.y and later**: The legacy `panel-simple.c` entry was removed in v6.11-rc1, so the panel-edp entry is essential. - For stable trees **v5.16.y to v6.10.y**: The panel was supported through the legacy `panel-simple.c` compatible string, so the AUX bus lookup wasn't needed. Whether this entry is needed depends on whether the DT uses the legacy compatible or the generic `edp-panel` approach. - The commit should apply cleanly to v6.11+ stable trees (the table structure is the same). ### 9. Stability Indicators - **Reviewed-by: Douglas Anderson** -- the panel-edp subsystem maintainer - Tested on real hardware for weeks - Standard, well-understood change pattern ### Conclusion This is a clear-cut device ID addition to an existing driver's panel identification table. It fixes a real user-visible issue (WARN_ON kernel splat on boot + degraded panel timings) for users of a specific laptop model. The change is a single line of data, uses existing infrastructure, carries essentially zero regression risk, and has been reviewed by the subsystem maintainer. It fits perfectly into the "new device IDs to existing drivers" exception category for stable backports. **YES** drivers/gpu/drm/panel/panel-edp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index 023fbbb10eb4f..2c35970377431 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -1904,6 +1904,7 @@ static const struct edp_panel_entry edp_panels[] = { EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, &delay_200_500_e50, "B116XAN06.1"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, &delay_200_500_e50, "B116XAN06.3"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, &delay_200_500_e50, "B140HAK02.7"), + EDP_PANEL_ENTRY('A', 'U', 'O', 0x643d, &delay_200_500_e50, "B140HAN06.4"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x723c, &delay_200_500_e50, "B140XTN07.2"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x73aa, &delay_200_500_e50, "B116XTN02.3"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, &delay_200_500_e50, "B133UAN01.0"), -- 2.51.0