From: Lee Jones <lee.jones@linaro.org>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
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 11:58:17 +0000 [thread overview]
Message-ID: <20141120115817.GC13269@x1> (raw)
In-Reply-To: <546DD00E.4000704@collabora.co.uk>
[...]
> >> +#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.
Right, I think don't think you should be using those on a platform device.
> >> +#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?
Exactly as you said, they add a layer of (pointless)
indirection/complexity. You only use this name once, just change it
where you use it if you wish to (but probably never will) adapt the
name.
[...]
> >> +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__); \
> } \
I know how the device driver model works. I'm asking where the
'device' is registered from, not the 'driver' i.e. platform data, DT,
ACPI?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-11-20 11:58 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
2014-11-20 11:58 ` Lee Jones [this message]
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=20141120115817.GC13269@x1 \
--to=lee.jones@linaro.org \
--cc=dianders@chromium.org \
--cc=gwendal@google.com \
--cc=javier.martinez@collabora.co.uk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.