> > 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?
> >
>
> Right, sorry for misunderstanding your question and the silly comment then.
>
> $Subject adds a "cros-ec-dev" mfd cell to the cros ec
Hello Lee,
On 11/20/2014 12:58 PM, Lee Jones wrote:
>> 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.
>
Yes, I'll use dev_err() instead.
>> I prefer
[...]
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >
> > What do you need this for?
> >
>
> the printk.h header? to use the pr_* functions but I'll make sure that only
> the
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
Hello Olof,
On 11/19/2014 09:45 PM, Olof Johansson wrote:
>> Is true that this is a new API for mainline but there is a lot of ChromeOS
>> installations that depends on this API which means that just replacing the
>> kernel with a mainline one there, will break existing user-space programs.
>
>
Hello Olof,
On 11/19/2014 09:45 PM, Olof Johansson wrote:
Is true that this is a new API for mainline but there is a lot of ChromeOS
installations that depends on this API which means that just replacing the
kernel with a mainline one there, will break existing user-space programs.
I think
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
[...]
+#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
Hello Lee,
On 11/20/2014 12:58 PM, Lee Jones wrote:
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.
Yes, I'll use dev_err() instead.
I prefer macros if
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?
Right, sorry for misunderstanding your question and the silly comment then.
$Subject adds a cros-ec-dev mfd cell to the cros ec mfd driver.
So
On Wed, Nov 19, 2014 at 10:37 AM, Javier Martinez Canillas
wrote:
> Hello Alan,
>
> Thanks a lot for your feedback.
>
> On 11/18/2014 06:00 PM, One Thousand Gnomes wrote:
>>> +#ifdef CONFIG_COMPAT
>>> +struct compat_cros_ec_command {
>>> +uint32_t version;
>>> +uint32_t command;
>>> +
Hello Alan,
Thanks a lot for your feedback.
On 11/18/2014 06:00 PM, One Thousand Gnomes wrote:
>> +#ifdef CONFIG_COMPAT
>> +struct compat_cros_ec_command {
>> +uint32_t version;
>> +uint32_t command;
>> +compat_uptr_t outdata;
>> +uint32_t outsize;
>> +compat_uptr_t indata;
Hello Alan,
Thanks a lot for your feedback.
On 11/18/2014 06:00 PM, One Thousand Gnomes wrote:
+#ifdef CONFIG_COMPAT
+struct compat_cros_ec_command {
+uint32_t version;
+uint32_t command;
+compat_uptr_t outdata;
+uint32_t outsize;
+compat_uptr_t indata;
+uint32_t
On Wed, Nov 19, 2014 at 10:37 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Hello Alan,
Thanks a lot for your feedback.
On 11/18/2014 06:00 PM, One Thousand Gnomes wrote:
+#ifdef CONFIG_COMPAT
+struct compat_cros_ec_command {
+uint32_t version;
+uint32_t
> +#ifdef CONFIG_COMPAT
> +struct compat_cros_ec_command {
> + uint32_t version;
> + uint32_t command;
> + compat_uptr_t outdata;
> + uint32_t outsize;
> + compat_uptr_t indata;
> + uint32_t insize;
> + uint32_t result;
> +};
> +
> +struct compat_cros_ec_readmem {
> +
On Mon, 17 Nov 2014, Javier Martinez Canillas wrote:
> From: Bill Richardson
>
> This patch adds a device interface to access the
> ChromeOS Embedded Controller from user-space.
>
> Signed-off-by: Bill Richardson
> Reviewed-on: https://gerrit-int.chromium.org/38364
> Reviewed-by: Simon Glass
+#ifdef CONFIG_COMPAT
+struct compat_cros_ec_command {
+ uint32_t version;
+ uint32_t command;
+ compat_uptr_t outdata;
+ uint32_t outsize;
+ compat_uptr_t indata;
+ uint32_t insize;
+ uint32_t result;
+};
+
+struct compat_cros_ec_readmem {
+ uint32_t
On Mon, 17 Nov 2014, Javier Martinez Canillas wrote:
From: Bill Richardson wfric...@chromium.org
This patch adds a device interface to access the
ChromeOS Embedded Controller from user-space.
Signed-off-by: Bill Richardson wfric...@chromium.org
Reviewed-on:
From: Bill Richardson
This patch adds a device interface to access the
ChromeOS Embedded Controller from user-space.
Signed-off-by: Bill Richardson
Reviewed-on: https://gerrit-int.chromium.org/38364
Reviewed-by: Simon Glass
Tested-by: Simon Glass
Signed-off-by: Javier Martinez Canillas
---
From: Bill Richardson wfric...@chromium.org
This patch adds a device interface to access the
ChromeOS Embedded Controller from user-space.
Signed-off-by: Bill Richardson wfric...@chromium.org
Reviewed-on: https://gerrit-int.chromium.org/38364
Reviewed-by: Simon Glass s...@google.com
Tested-by:
20 matches
Mail list logo
