Kconfig CONFIG_FB dependency regression

[Randy Dunlap]

Hi--

On 2/2/22 15:55, Thinh Nguyen wrote:
> Arnd Bergmann wrote:
>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <Thinh.Nguyen at synopsys.com> wrote:
>>> Fabio Estevam wrote:
>>>> On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap <rdunlap at infradead.org> wrote:
>>>>>
>>>>> On 2/1/22 15:01, Thinh Nguyen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> One of our test setups is unable to boot (stuck at initramfs). Git
>>>>>> bisection points to the commit below:
>>>>>>
>>>>>> f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
>>>>>>
>>>>>> Reverting this patch resolves the issue. This issue persists in mainline
>>>>>> also. Unfortunately there isn't any meaningful log. Hopefully someone
>>>>>> can give some insight as to what could be the issue and revert/fix this
>>>>>> issue.
>>>>>
>>>>> Hi,
>>>>> Did you enable DRM_FBDEV_EMULATION?
>>>
>>> I did not enable it.
>>>
>>>>> Please provide the failing .config file.
>>>>
>>>> Does selecting CONFIG_FB=y help?
>>>>
>>>
>>> On the config that has the issue, this isn't set. After reverting the
>>> commit above, this was set. Maybe this is what's needed? I need to test it.
>>
>> CONFIG_FB should not normally be needed for booting, so unless
>> you have a graphical application in your initramfs that requires the /dev/fb0
>> device to work, it is not supposed to make a difference.
>>
> 
> I'm not sure, but it seems like the setup we have isn't the only one
> that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs
> to have CONFIG_FB set.
> 
>> Are there any other differences in your .config before and after the patch?
>> It's possible that you use some other driver that in turn depends on
>> CONFIG_FB. Does your machine have any graphical output device?
>> If yes, which driver do you use?
> 
> I don't have the answer to those questions yet. Need more investigation.
> I'm new to this particular test setup.
> 
>>
>> You may also want to make sure that you have 9d6366e743f3 ("drm:
>> fb_helper: improve CONFIG_FB dependency") in your kernel, which
>> fixes a minor problem with my original patch.
>>
>>          Arnd
> 
> The issue also occurs in mainline, which has your minor fix commit
> above. The revert isn't clean for the latest kernel version. I also have
> to revert some of the changes along with CONFIG_FB. The revert looks
> more like this for the latest kernel:
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b1f22e457fd0..7cbc733a8569 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
> 
>  config DRM_FBDEV_EMULATION
>         bool "Enable legacy fbdev support for your modesetting driver"
> -       depends on DRM_KMS_HELPER
> -       depends on FB=y || FB=DRM_KMS_HELPER
> +       depends on DRM
> +       select DRM_KMS_HELPER
> +       select FB
>         select FB_CFB_FILLRECT
>         select FB_CFB_COPYAREA
>         select FB_CFB_IMAGEBLIT
> 
> 
> 
> I attached the configs for kernel v5.17-rc1. The "bad" config is without
> any revert, the "good" config is with the change above.

I took bad.config with kernel 5.17-rc1 and then manually set/enabled:

CONFIG_FB
CONFIG_FB_EFI
CONFIG_FB_MODE_HELPERS
CONFIG_FB_TILEBLITTING
CONFIG_LOGO

and I got very close to your good.config file.
Can you do the same and see if it works for you?
If so, then we can decide what to do about it.


thanks.
-- 
~Randy