From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Lee Jones <lee.jones@linaro.org>
Cc: Doug Anderson <dianders@chromium.org>,
Bill Richardson <wfrichar@chromium.org>,
Olof Johansson <olof@lixom.net>, Simon Glass <sjg@google.com>,
Gwendal Grignou <gwendal@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mfd: cros_ec: Add Chrome OS EC userspace device interface
Date: Thu, 20 Nov 2014 12:27:10 +0100 [thread overview]
Message-ID: <546DD00E.4000704@collabora.co.uk> (raw)
In-Reply-To: <20141118141827.GB24004@x1>
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
next prev parent reply other threads:[~2014-11-20 11:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 15:30 [PATCH 0/3] mfd: cros_ec: Add user-space dev inferface support Javier Martinez Canillas
2014-11-17 15:30 ` [PATCH 1/3] mfd: cros_ec: Add Chrome OS EC userspace device interface Javier Martinez Canillas
2014-11-18 14:18 ` Lee Jones
2014-11-20 11:27 ` Javier Martinez Canillas [this message]
2014-11-20 11:58 ` Lee Jones
2014-11-20 12:13 ` Javier Martinez Canillas
2014-11-20 13:26 ` Lee Jones
2014-11-18 17:00 ` One Thousand Gnomes
2014-11-19 18:37 ` Javier Martinez Canillas
2014-11-19 20:45 ` Olof Johansson
2014-11-20 10:03 ` Javier Martinez Canillas
2014-11-17 15:30 ` [PATCH 2/3] mfd: cros_ec: Create sysfs attributes for the ChromeOS EC Javier Martinez Canillas
2014-11-18 14:26 ` Lee Jones
2014-11-20 11:58 ` Javier Martinez Canillas
2014-11-20 18:16 ` Bill Richardson
2014-11-21 18:40 ` Javier Martinez Canillas
2014-11-17 15:30 ` [PATCH 3/3] mfd: cros_ec: Expose Chrome OS Lightbar to users Javier Martinez Canillas
2014-11-18 14:22 ` Lee Jones
2014-11-20 12:00 ` Javier Martinez Canillas
2014-11-20 13:27 ` Lee Jones
2014-11-20 13:36 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546DD00E.4000704@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=dianders@chromium.org \
--cc=gwendal@google.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=sjg@google.com \
--cc=wfrichar@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox