Kconfig CONFIG_FB dependency regression

[Thinh Nguyen]

Arnd Bergmann wrote:
> On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen <Thinh.Nguyen at synopsys.com> wrote:
>> Arnd Bergmann wrote:
>>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <Thinh.Nguyen at synopsys.com> wrote:
>>>> Fabio Estevam wrote:
>>>
>>> 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.
> 
> No, that one is different: the change for imx_v6_v7_defconfig was
> done because they actually use a framebuffer console on some devices,
> so the patch just adds the symbol to enable the drivers they are using.
> 
> This is expected with my original patch that doesn't implicitly enable
> the framebuffer layer any more. What is not expected is for the kernel
> to hang during boot as you reported for your unidentified platform.
> 
>>> 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.
> 
> Do you mean you don't know if there is a screen attached to the system?
> 

It does have a graphical output device, but I didn't check what it is or
what driver is driving it. I just notice that after the reported commit,
something stopped working.

>>>
>>> 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.
>>>
>>
>> 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.
> 
> Looking at the config, I see that this is for an x86 machine,
> and you have the FB_EFI driver and EFI_EARLYCON enabled.
> 
> What I suspec is going on is that you are looking at a screen rather
> than a serial console, and the kernel doesn't actually hang but you
> just don't see any more messages after the DRM driver takes
> over from EFI_EARLYCON because there is no console driver.
> 
> In this case, what you see is the intended behavior, not a bug.
> If you want a graphical console in your system, you need to
> enable the support for this in your config.
> 

It sounds like that's the case. Unfortunately I'm not familiar with this
subsystem to say that's what happening. If there's nothing actually
broken from review, we can ignore this email thread.

Thanks,
Thinh