From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Lee Jones <lee.jones@linaro.org>
Cc: Olof Johansson <olof@lixom.net>,
Doug Anderson <dianders@chromium.org>,
Bill Richardson <wfrichar@chromium.org>,
Simon Glass <sjg@google.com>,
Gwendal Grignou <gwendal@google.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND v2 3/7] mfd: cros_ec: Add cros_ec_lpc driver for x86 devices
Date: Thu, 22 Jan 2015 10:08:49 +0100 [thread overview]
Message-ID: <54C0BE21.7020008@collabora.co.uk> (raw)
In-Reply-To: <20150122084244.GP22024@x1>
Hello Lee,
On 01/22/2015 09:42 AM, Lee Jones wrote:
>> >
>> > I don't think the drivers you mentioned above do anything practical.
>> > For instance, they are not SPI/IC2/etc drivers. They should only
>> > offer some abstraction layers which are used to communicate with the
>> > device. The driver you are submitting looks a lot more like a device
>> > driver, which should live somewhere else. Don't ask me where though,
>> > I'm not even sure what a Low Pin Controller does.
>> >
>>
>> The driver added by $subject doesn't really do anything practical either.
>> LPC [0] is just another transport method like i2c or spi that is used on
>> x86 Chromebooks to access the Embedded Controller.
>
> I'm not sure that's true. It's pretty simple I grant you, but it
> still looks like a driver, rather than an abstraction layer.
>
> I would expect to see something more like:
>
> static int cros_ec_lpc_readmem(...)
> {
> return call_to_driver_to_read_memory(...);
>
> }
>
> ... instead of all those memory/register reads/writes.
>
Yeah... in that sense I've to admit that is more complex than the I2C and SPI
drivers, yet those have a subsystem in the kernel with helpers functions to
do most of the communication:
static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
...
ret = i2c_transfer(client->adapter, i2c_msg, 2);
...
}
static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
struct cros_ec_command *ec_msg)
{
...
spi_message_add_tail(&trans, &msg);
ret = spi_sync(ec_spi->spi, &msg);
...
}
But there doesn't seem to be a LPC subsystem in the kernel so we don't have a
nice abstraction layer in this case.
> Are there any other Low Pin Count drivers in the kernel?
>
I don't know tbh, I didn't even know what LPC was before I picked this patch
to push it upstream. I searched in the Linux codebase for other LPC drivers
but I didn't find anything, that doesn't mean that it doesn't exist though.
Best regards,
Javier
next prev parent reply other threads:[~2015-01-22 9:08 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-02 13:32 [PATCH RESEND v2 0/7] platform/chrome: Add user-space dev inferface support Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 1/7] mfd: cros_ec: Use fixed size arrays to transfer data with the EC Javier Martinez Canillas
2015-01-20 7:48 ` Lee Jones
2015-01-20 15:40 ` Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 2/7] mfd: cros_ec: Add char dev and virtual dev pointers Javier Martinez Canillas
2015-01-20 7:50 ` Lee Jones
2015-01-20 15:41 ` Javier Martinez Canillas
2015-01-20 16:36 ` Lee Jones
2015-01-20 16:45 ` Javier Martinez Canillas
2015-01-20 16:51 ` Lee Jones
2015-01-02 13:32 ` [PATCH RESEND v2 3/7] mfd: cros_ec: Add cros_ec_lpc driver for x86 devices Javier Martinez Canillas
2015-01-20 8:11 ` Lee Jones
2015-01-20 15:58 ` Javier Martinez Canillas
2015-01-20 16:34 ` Lee Jones
2015-01-20 16:52 ` Javier Martinez Canillas
2015-01-21 17:05 ` Javier Martinez Canillas
2015-01-22 8:42 ` Lee Jones
2015-01-22 9:08 ` Javier Martinez Canillas [this message]
2015-01-22 9:46 ` Lee Jones
2015-01-22 10:36 ` Javier Martinez Canillas
2015-01-22 10:56 ` Lee Jones
2015-01-22 11:17 ` Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 4/7] platform/chrome: Add Chrome OS EC userspace device interface Javier Martinez Canillas
2015-01-13 23:40 ` Gwendal Grignou
2015-01-02 13:32 ` [PATCH RESEND v2 5/7] mfd: cros_ec: Instantiate ChromeOS EC character device Javier Martinez Canillas
2015-01-20 8:20 ` Lee Jones
2015-01-20 16:03 ` Javier Martinez Canillas
2015-01-20 16:29 ` Lee Jones
2015-01-20 16:36 ` Javier Martinez Canillas
2015-01-20 16:55 ` Lee Jones
2015-01-20 17:11 ` Javier Martinez Canillas
2015-01-21 16:56 ` Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 6/7] platform/chrome: Create sysfs attributes for the ChromeOS EC Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 7/7] platform/chrome: Expose Chrome OS Lightbar to users Javier Martinez Canillas
2015-01-12 10:18 ` [PATCH RESEND v2 0/7] platform/chrome: Add user-space dev inferface support 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=54C0BE21.7020008@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=corbet@lwn.net \
--cc=dianders@chromium.org \
--cc=gwendal@google.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@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.