Kconfig CONFIG_FB dependency regression

[Thinh Nguyen]

Randy Dunlap wrote:
> 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.

Yes. It works as expected.

Thanks,
Thinh