Re: [PATCH 1/3] mfd: cros_ec: Add Chrome OS EC userspace device interface

From: Javier Martinez Canillas
Date: Thu Nov 20 2014 - 06:27:22 EST


Hello Lee,

Thanks a lot for your feedback.

On 11/18/2014 03:18 PM, Lee Jones wrote:
>>
>> +config MFD_CROS_EC_DEV
>
> _DEV as a post-fix doesn't really describe the driver.
>

the _DEV is meant to denote (user-space device interface) but is true that
a better name can be used, I'll see what I can came with.

>> + tristate "ChromeOS Embedded Controller userspace device interface"
>> + depends on MFD_CROS_EC
>> +
>
> Superfluous '\n'.
>

Ok

>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
>> obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
>> obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
>> obj-$(CONFIG_MFD_CROS_EC_SPI) += cros_ec_spi.o
>> +obj-$(CONFIG_MFD_CROS_EC_DEV) += cros_ec_dev.o
>
> Alphabetical?
>

Ok

>> +
>> +#define pr_fmt(fmt) "cros_ec_dev: " fmt
>
> This doesn't appear to even be used?
>

It is used by pr_* family of functions, e.g: from include/linux/printk.h

#define pr_err(fmt, ...) \
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)

>> +#include <linux/compat.h>
>> +#include <linux/delay.h>
>> +#include <linux/device.h>
>> +#include <linux/fs.h>
>> +#include <linux/mfd/cros_ec.h>
>> +#include <linux/mfd/cros_ec_commands.h>
>> +#include <linux/mfd/cros_ec_dev.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/printk.h>
>
> What do you need this for?
>

the printk.h header? to use the pr_* functions but I'll make sure that only
the needed headers are included.

>> +#include <linux/types.h>
>> +#include <linux/uaccess.h>
>> +
>> +/* Device variables */
>> +#define CROS_CLASS_NAME "chromeos"
>
> Any reason why you can't use the name directly?
>

I prefer macros if possible since they cost nothing and give you an indirection
level if you want to change it later. Any reason to not use a define directive?

>> +static struct cros_ec_device *ec;
>
> Can't you put this in a struct somewhere?
>

Yes, I'll remove the global variable and put it in struct file .private_data

>> +static struct class *cros_class;
>
> Why this this global instead of using the one in 'struct
> cros_ec_device'?
>
>> +static int ec_major;
>
> Same here. Only use globals if you're forced to.
>

Ok, I'll look how to refactor to remove these globals too.

>> +
>> +
>
> Superfluous '\n'.
>

Ok

>> +
>> + ret = cros_ec_cmd_xfer(ec, &msg);
>> + if (ret < 0)
>> + return ret;
>> + if (msg.result != EC_RES_SUCCESS) {
>> + snprintf(str, maxlen,
>> + "%s\nUnknown EC version: EC returned %d\n",
>> + CROS_EC_DEV_VERSION, msg.result);
>> + return 0;
>> + }
>> + if (resp.current_image >= ARRAY_SIZE(current_image_name))
>> + resp.current_image = 3; /* invalid */
>
> Add a '\n' here.
>

Ok

>> + if (*offset != 0)
>> + return 0;
>> +
>> + ret = ec_get_version(ec, msg, sizeof(msg));
>> + if (ret)
>> + return ret;
>
> New line here. Not sure why you are bunching up these segments.
>

Ok

>> + count = min(length, strlen(msg));
>> +
>> + if (copy_to_user(buffer, msg, count))
>> + return -EFAULT;
>> +
>> + *offset += count;
>
> You know offset is 0 here, so you can just *offset = count.
>

True

>> + return count;
>> +}
>> +
>> +
>
> Please remove these double line spaces throughout.
>

Ok

>> +/* Ioctls */
>> +static long ec_device_ioctl_xcmd(void __user *argp)
>> +{
>> + long ret;
>> + struct cros_ec_command s_cmd;
>> + uint8_t *user_indata;
>> + uint8_t buf[EC_PROTO2_MAX_PARAM_SIZE];
>> +
>> + if (copy_from_user(&s_cmd, argp, sizeof(s_cmd)))
>> + return -EFAULT;
>> + if (s_cmd.outsize &&
>> + copy_from_user(&buf, (void __user *)s_cmd.outdata, sizeof(buf)))
>> + return -EFAULT;
>> +
>> + user_indata = s_cmd.indata;
>> + s_cmd.indata = buf;
>> + s_cmd.outdata = buf;
>> + ret = cros_ec_cmd_xfer(ec, &s_cmd);
>> + s_cmd.indata = user_indata;
>
> For conforming if you swap these round, place a '\n' after this line
> and move the check for 'ret' to just after the call to
> cros_ec_cmd_xfer().
>

Ok

>> +static long ec_device_compat_ioctl(struct file *filp, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + void __user
>> + *argp = (void __user *)arg;
>
> Why is this expressed over multiple lines?
>

No reason at all, I'll change it.

>> + switch (cmd) {
>> + case CROS_EC_DEV_COMPAT_IOCXCMD:
>> + return ec_device_compat_ioctl_xcmd(argp);
>> + case CROS_EC_DEV_COMPAT_IOCRDMEM:
>> + return ec_device_compat_ioctl_readmem(argp);
>> + }
>
> '\n'
>

Ok

>> + return -ENOTTY;
>> +}
>> +#endif /* CONFIG_COMPAT */
>> +
>> +
>
> Please remove.
>

Ok

>> +static int ec_device_probe(struct platform_device *pdev)
>> +{
>> + int retval = -ENOTTY;
>> +
>> + ec = dev_get_drvdata(pdev->dev.parent);
>
> Stick this as the first line in the function.
>

Ok

>> + cros_class = class_create(THIS_MODULE, CROS_CLASS_NAME);
>> + if (IS_ERR(cros_class)) {
>> + pr_err("failed to register device class\n");
>
> Why are you using pr_err() over dev_err()?
>

You are right, I'll use dev_err() instead.

>> + retval = PTR_ERR(cros_class);
>> + goto failed_class;
>
> Remove this goto and the corresponding label and just return from here.
>

Ok

>> +
>> +static struct platform_driver cros_ec_dev_driver = {
>> + .driver = {
>> + .name = "cros-ec-dev",
>> + .owner = THIS_MODULE,
>
> Remove this line.
>

Right, I've seen some cleanups efforts to remove the owner from drivers
but forgot when reviewing this driver for posting.

>> + },
>> + .probe = ec_device_probe,
>> + .remove = ec_device_remove,
>> +};
>
> Where is this device registered from?
>
>> +module_platform_driver(cros_ec_dev_driver);

This preprocessor macro is expanded to (from include/linux/device.h):

module_platform_driver() -> module_driver()

#define module_driver(__driver, __register, __unregister, ...) \
static int __init __driver##_init(void) \
{ \
return __register(&(__driver) , ##__VA_ARGS__); \
} \

Again, thanks a lot for your detailed review.

Best regards,
Javier

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/