[PATCH v2] drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP

[Thorsten Leemhuis]

[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 at linux-m68k.org> wrote:
>>> On Tue, Feb 8, 2022 at 10:39 AM Geert Uytterhoeven
>>> <geert at linux-m68k.org> wrote:
>>>> On Mon, Feb 7, 2022 at 12:31 PM Thomas Zimmermann
>>>> <tzimmermann at 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 at suse.de>
>>>>
>>>> Thanks for your patch!
>>>>
>>>> This fixes the build errors I'm seeing, so
>>>> Tested-by: Geert Uytterhoeven <geert+renesas at 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 at suse.de>
>> AuthorDate: Thu Feb 3 10:39:22 2022 +0100
>> Commit:     Thomas Zimmermann <tzimmermann at 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/Documentation/process/handling-regressions.rst#n131

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