>-----Original Message-----
>From: Mike Frysinger [mailto:[email protected]] 
>Sent: Wednesday, February 03, 2010 5:29 PM
>To: [email protected]
>Cc: [email protected]
>Subject: Re: [Linux-kernel-commits] [8267] trunk: taske 
>[#5868], New IIO driver for ad715x CDC devices
>
>On Wed, Feb 3, 2010 at 04:15,  <[email protected]> wrote:
>> +static ssize_t ad715x_store_ch2_threshold(struct device *dev,
>> +            struct device_attribute *attr,
>> +            const char *buf,
>> +            size_t len)
>> +{
>> +    if ((!ret) && (data < 0x10000)) {
>
>done need those paren in all the places like this
Sure. Is there a coding style requirement about that? Personally, I
think paren makes more readable. 
Why let people to remember the precedence?
>
>> +static int __devinit ad715x_probe(struct i2c_client *client,
>> +            const struct i2c_device_id *id)
>> +{
>> ...
>> +    if (client->irq && 
>gpio_is_valid(irq_to_gpio(client->irq)) > 0) {
>
>shouldnt an error from gpio_is_valid() cause the probe() to abort ?
>i'd say so ...
Just follow the style in other iio drivers.
>
>> +    dev_err(&client->dev, "%s capacitive sensor registered, 
>irq :%d\n",
>> id->name, client->irq);
>
>dev_info(), and isnt the name already part of the &dev output ?  it
>should be "irq: %d" rather than "irq :%d" ...
The name of dev is "ad715x", id->name gives "ad7150" in the ID table.
>
>> +static int ad715x_remove(struct i2c_client *client)
>
>__devexit ?
ok
>
>> +    if (client->irq && gpio_is_valid(irq_to_gpio(client->irq)) > 0)
>> +            iio_unregister_interrupt_line(indio_dev, 0);
>
>dont need the gpio_is_valid() check once probe() makes this a 
>fatal error
>
>> +    .remove = ad715x_remove,
>
>__devexit_p()
ok
>
>> +MODULE_DESCRIPTION("Analog Device ad715x capacitive sensor driver");
>
>should be AD715x in description type strings (so the Kconfig too)
ok
>-mike
>
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits

Reply via email to