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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141120115817.GC13269@x1>
Date:	Thu, 20 Nov 2014 11:58:17 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc:	Doug Anderson <dianders@...omium.org>,
	Bill Richardson <wfrichar@...omium.org>,
	Olof Johansson <olof@...om.net>, Simon Glass <sjg@...gle.com>,
	Gwendal Grignou <gwendal@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mfd: cros_ec: Add Chrome OS EC userspace device
 interface

[...]

> >> +#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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/