Re: [PATCH 1/2] fbdev/offb: Update expected device name

[Helge Deller <deller@gmx.de>]

On 6/15/23 23:19, Cyril Brulebois wrote:
> Hi Rob,
>
> Rob Herring <robh@kernel.org> (2023-06-15):
>> On Thu, Jun 15, 2023 at 03:21:07PM +0200, Michal Suchánek wrote:
>>> At the time this was proposed it was said that "of-display", is wrong,
>>> and that "of-display.0" must be used for the first device instead, and
>>> if something breaks an alias can be provided.
>>>
>>> So how does one provide an alias so that offb can find "of-display.0"
>>> as "of-display"?
>>
>> I'm not aware of any way. There isn't because device names and paths are
>> not considered ABI. There are mechanisms for getting stable class device
>> indices (e.g. i2c0, mmcblk0, fb0, fb1, etc.) though not implemented for
>> fbN (and please don't add it).
>>
>> In any case, this should be an easy fix. Though if "linux,opened" or
>> "linux,boot-display" is not set, then you'd still get "of-display.0":
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 78ae84187449..e46482cef9c7 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -553,7 +553,7 @@ static int __init of_platform_default_populate_init(void)
>>                          if (!of_get_property(node, "linux,opened", NULL) ||
>>                              !of_get_property(node, "linux,boot-display", NULL))
>>                                  continue;
>> -                       dev = of_platform_device_create(node, "of-display.0", NULL);
>> +                       dev = of_platform_device_create(node, "of-display", NULL);
>>                          of_node_put(node);
>>                          if (WARN_ON(!dev))
>>                                  return -ENOMEM;

Michal, does that patch look correct?
I don't have that hardware, but that way the boot-display gets named
"of-display" while all others get "of-display.x"....

> I've just replaced my clueless workaround with this patch on top of the
> kernel found in Debian 12 (Bookworm), i.e. 6.1.27 at this point, and it
> indeed fixes the black screen problem in the installer's context.

... at least it fixes the issue.

> I didn't run a full installation to check whether this kernel is also fine
> after rebooting into the installed system, but as far as I understood for
> the original bug report[1], it wasn't affected in the first place.
>
>   1. https://bugs.debian.org/1033058
>
> Will somebody else pick up the torch from here, and submit that for
> inclusion in master? Or should I re-submit the above patch on my own?

It would be good to get some more feedback, but in general if you
or Rob send me a patch I can include it in the fbdev git tree for futher
testing (and if nobody else disagrees).

Helge