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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/15/23 23:19, Cyril Brulebois wrote:
Hi Rob,

Rob Herring <robh@xxxxxxxxxx> (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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux