Re: backlight_register_device can oops if name is null ?
From: devendra.aaru <hidden>
Date: 2013-01-03 05:22:41
quoted
quoted
so if i understand the code pr_debug code, i see a printk macro assignment, is it something like printk or a wrapper macro around printk are making sure that the strings are non null ?Sorry, I don't know how printk deals this null. But I tested null by using ams369fg06 driver as below: - bd = backlight_device_register("ams369fg06-bl", &spi->dev, lcd, + bd = backlight_device_register(NULL, &spi->dev, lcd, Also, I replaced pr_debug with printk as below: - pr_debug("backlight_device_register: name=%s\n", name); + printk("backlight_device_register: name=%s\n", name); In this case, printk message is as below: backlight_device_register: name=(null)quoted
wow, you tested the code, i would have done it with a single module, great and thanks for lot of information you are putting .
quoted hunk ↗ jump to hunk
quoted
the documentation of the backlight_device_register says that "name must be same as the name of the respected frame buffer device", but do we really add a check for the null to do dev_set_name? or fail the registering ?"name must be same as the name of the respected frame buffer device" is not correct. Most backlight drivers are using their driver name as 'name'. Anyway, in my opinion, deference to null does not seem to happen. Now, backlight_device_register() calls are using 'name' properly. However, if a check for the null is added, it will be added to backlight_device_register() as below:@@ -292,6 +292,11 @@ struct backlight_device *backlight_device_register(const char *name, struct backlight_device *new_bd; int rc; + if (name = NULL) { + pr_err("....."); + return -EINVAL + } +
This is what exactly i was thinking, thanks for making a patch too. If you want to submit it then please take my Acked-By: Devendra Naga <redacted>