On Mon, Dec 13, 2021 at 5:30 AM Javier Martinez Canillas javier@dowhile0.org wrote:
On Mon, Dec 13, 2021 at 11:46 AM Hector Martin marcan@marcan.st 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@marcan.st 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@suse.de Signed-off-by: Hector Martin marcan@marcan.st
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].
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