[CCing Dave and Daniel]
Hi, this is your Linux kernel regression tracker.
On 23.02.22 20:06, Thomas Zimmermann wrote:
Am 23.02.22 um 17:11 schrieb Doug Anderson:
On Tue, Feb 22, 2022 at 1:31 AM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Feb 8, 2022 at 10:39 AM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Mon, Feb 7, 2022 at 12:31 PM Thomas Zimmermann tzimmermann@suse.de wrote:
As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select the option to fix the build failure. The error message is shown below.
arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function `panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to `drm_panel_dp_aux_backlight' make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1
The issue has been reported before, when DisplayPort helpers were hidden behind the option CONFIG_DRM_KMS_HELPER. [2]
v2: * fix and expand commit description (Arnd)
Signed-off-by: Thomas Zimmermann tzimmermann@suse.de
Thanks for your patch!
This fixes the build errors I'm seeing, so Tested-by: Geert Uytterhoeven geert+renesas@glider.be
Is this planned to be queued? This is still failing in drm-next. Thanks!
Looks like this has been in drm-misc-next since Feb 4:
commit eea89dff4c39a106f98d1cb5e4d626f8c63908b9 Author: Thomas Zimmermann tzimmermann@suse.de AuthorDate: Thu Feb 3 10:39:22 2022 +0100 Commit: Thomas Zimmermann tzimmermann@suse.de CommitDate: Fri Feb 4 09:38:47 2022 +0100
drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP
Maybe it needed to land elsewhere, though?
Sorry about the mess. We had some confusion with this cycle's drm-misc-next pull request, which got delayed significantly. There's been a PR today, which should be merged into drm-next any time now. The patch will be part of that.
The patch for this regression late last week finally showed up in linux-next, great. But:
I noticed the patch is not in drm-fixes but in drm-next -- and thus afaics seems to be on tack to only get merged in the next merge window (or am I wrong with that?). That seems wrong to me, as this fixes a regression (albeit from the previous cycle, not from the current one) and it already took quite a while to get this relative simple fix finally on track -- but it's still far away from getting fixed in 5.16 and thus will make it into 5.17, too. That seems wrong to me, at least if the risk is low (which is the case here afaics).
FWIW, this is not the only time where I noticed something like that, that's why I wrote documentation that covers this which is on track to get merged in the next merge window, unless Linus objects:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Doc...
To quote one of the sections relevant in this particular case:
Aim to fix regressions within one week after the culprit was identified, if the issue was introduced in either:
a recent stable/longterm release
the development cycle of the latest proper mainline release
Ciao, Thorsten