On Mon, Dec 13, 2021 at 5:30 AM Javier Martinez Canillas <javier@xxxxxxxxxxxx> wrote: > > On Mon, Dec 13, 2021 at 11:46 AM Hector Martin <marcan@xxxxxxxxx> wrote: > > > > On 13/12/2021 17.44, Javier Martinez Canillas wrote: > > > Hello Hector, > > > > > > On Sun, Dec 12, 2021 at 7:24 AM Hector Martin <marcan@xxxxxxxxx> wrote: > > >> > > >> This code is required for both simplefb and simpledrm, so let's move it > > >> into the OF core instead of having it as an ad-hoc initcall in the > > >> drivers. > > >> > > >> Acked-by: Thomas Zimmermann <tzimmermann@xxxxxxx> > > >> Signed-off-by: Hector Martin <marcan@xxxxxxxxx> > > >> --- > > >> drivers/of/platform.c | 4 ++++ > > >> drivers/video/fbdev/simplefb.c | 21 +-------------------- > > >> 2 files changed, 5 insertions(+), 20 deletions(-) > > >> > > > > > > This is indeed a much better approach than what I suggested. I just > > > have one comment. > > > > > >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c > > >> index b3faf89744aa..793350028906 100644 > > >> --- a/drivers/of/platform.c > > >> +++ b/drivers/of/platform.c > > >> @@ -540,6 +540,10 @@ static int __init of_platform_default_populate_init(void) > > >> of_node_put(node); > > >> } > > >> > > >> + node = of_get_compatible_child(of_chosen, "simple-framebuffer"); > > > > > > You have to check if the node variable is NULL here. > > > > > >> + of_platform_device_create(node, NULL, NULL); > > > > > > Otherwise this could lead to a NULL pointer dereference if debug > > > output is enabled (the node->full_name is printed). > > > > Where is it printed? I thought I might need a NULL check, but this code > > Sorry, I misread of_amba_device_create() as > of_platform_device_create(), which uses the "%pOF" printk format > specifier [0] to print the node's full name as a debug output [1]. > > [0]: https://elixir.bootlin.com/linux/v5.16-rc5/source/Documentation/core-api/printk-formats.rst#L462 > [1]: https://elixir.bootlin.com/linux/v5.16-rc5/source/drivers/of/platform.c#L233 > > > was suggested verbatim by Rob in v2 without the NULL check and digging > > through I found that the NULL codepath is safe. > > > > You are right that passing NULL is a safe code path for now due the > of_device_is_available(node) check, but that seems fragile to me since > just adding a similar debug output to of_platform_device_create() > could trigger the NULL pointer dereference. All/most DT functions work with a NULL node ptr, so why should this one be different? Rob