On Tue, Mar 17, 2009 at 08:52, <[email protected]> wrote:
> --- trunk/drivers/leds/Kconfig 2009-03-17 12:42:56 UTC (rev 6186)
> +++ trunk/drivers/leds/Kconfig 2009-03-17 12:52:24 UTC (rev 6187)
> @@ -165,6 +165,13 @@
> +config LEDS_ADP5520
> + tristate "LED Support for ADP5520/ADP5501 PMIC"
> + depends on LEDS_CLASS && PMIC_ADP5520
> + help
> + This option enables support for on-chip LED drivers found
> + on Analog Devices ADP5520/ADP5501 PMICs.
> +
could you add a line with the module name in case it is built as one ?
> --- trunk/drivers/leds/leds-adp5520.c (rev 0)
> +++ trunk/drivers/leds/leds-adp5520.c 2009-03-17 12:52:24 UTC (rev 6187)
> @@ -0,0 +1,219 @@
> +static int __devinit adp5520_led_probe(struct platform_device *pdev)
> +{
> + struct adp5520_leds_platfrom_data *pdata = pdev->dev.platform_data;
> + struct adp5520_led *led, *led_dat;
> + struct led_info *cur_led;
> + int ret, i;
> +
> + if (pdata == NULL)
> + return 0;
shouldnt there be an error message and return an error rather than 0 ?
> + if (pdata->num_leds > ADP5520_01_MAXLEDS) {
> + dev_err(&pdev->dev, "can't handle more than %d LEDS\n",
> + ADP5520_01_MAXLEDS);
> + pdata->num_leds = ADP5520_01_MAXLEDS;
> + }
how about we just return an error and force people to fix their platform data ?
> + led = kzalloc(sizeof(struct adp5520_led) * pdata->num_leds, GFP_KERNEL);
sizeof(*led)
> + for (i = 0; i < pdata->num_leds; i++) {
> + .......
> + ret = led_classdev_register(led_dat->master, &led_dat->cdev);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register LED %d\n",
> + led_dat->id);
> + goto err;
> + }
> +
> + ret = adp5520_led_setup(led_dat);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to write\n");
> + goto err;
> + }
> + }
> + .........
> +err:
> + if (i > 0) {
> + for (i = i - 1; i >= 0; i--) {
> + led_classdev_unregister(&led[i].cdev);
> + cancel_work_sync(&led[i].work);
> + }
> + }
if the error happened at led_setup(), wouldnt the current "i" also
need to be run through led_classdev_unregister ?
-mike
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
http://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
