Re: [PATCH 10/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC
Hi Doug, On 17 June 2014 21:54, Doug Anderson wrote: > Simon, > > On Tue, Jun 17, 2014 at 8:46 PM, Simon Glass wrote: >> Hi, >> >> On 16 June 2014 14:40, Doug Anderson wrote: >>> From: Bill Richardson >>> >>> When communicating with the EC, the cmd_xfer() function should return the >>> number of bytes it received from the EC, or negative on error. >> >> This is just for the I2C tunnel feature, right? If so, I think this >> should be mentioned here. It seems to be affecting ec_i2c_xfer(), not >> cmd_xfer(). > > No, the tunnel feature is implemented just fine without this (and is > already landed and working). It looks like the (not yet upstreamed) > ec_i2c_limited_xfer for spring returns this new value directly but I'm > not convinced that's technicall correct. > > Bill can correct me if I'm wrong, but I think this is primarily > interesting once we add in cros_ec_dev (the userspace API) which needs > this info. Until that happens this patch doesn't hurt and just > returns some extra info. Agreed. Reviewed-by: Simon Glass Regards, Simon -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
Hi Doug,
On 17 June 2014 21:27, Doug Anderson wrote:
> Simon,
>
> On Tue, Jun 17, 2014 at 8:42 PM, Simon Glass wrote:
>>> diff --git a/drivers/input/keyboard/cros_ec_keyb.c
>>> b/drivers/input/keyboard/cros_ec_keyb.c
>>> index 4083796..dc37b6b 100644
>>> --- a/drivers/input/keyboard/cros_ec_keyb.c
>>> +++ b/drivers/input/keyboard/cros_ec_keyb.c
>>> @@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)
>>>
>>> static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
>>> *kb_state)
>>> {
>>> - return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
>>> - kb_state, ckdev->cols);
>>> + int ret;
>>> + struct cros_ec_command msg = {
>>> + .version = 0,
>>> + .command = EC_CMD_MKBP_STATE,
>>> + .outdata = NULL,
>>> + .outsize = 0,
>>> + .indata = kb_state,
>>> + .insize = ckdev->cols,
>>> + };
>>> +
>>> + ret = ckdev->ec->cmd_xfer(ckdev->ec, &msg);
>>
>> Do we need ret?
>
> No. If you wish I will spin without it. Let me know.
>
> Note that locally this code includes a comment between the above and the
> return:
> /* FIXME: This assumes msg.result == EC_RES_SUCCESS */
It's not important to me, and you've explained the other question.
Reviewed-by: Simon Glass
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC
Simon, On Tue, Jun 17, 2014 at 8:46 PM, Simon Glass wrote: > Hi, > > On 16 June 2014 14:40, Doug Anderson wrote: >> From: Bill Richardson >> >> When communicating with the EC, the cmd_xfer() function should return the >> number of bytes it received from the EC, or negative on error. > > This is just for the I2C tunnel feature, right? If so, I think this > should be mentioned here. It seems to be affecting ec_i2c_xfer(), not > cmd_xfer(). No, the tunnel feature is implemented just fine without this (and is already landed and working). It looks like the (not yet upstreamed) ec_i2c_limited_xfer for spring returns this new value directly but I'm not convinced that's technicall correct. Bill can correct me if I'm wrong, but I think this is primarily interesting once we add in cros_ec_dev (the userspace API) which needs this info. Until that happens this patch doesn't hurt and just returns some extra info. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
Simon,
On Tue, Jun 17, 2014 at 8:42 PM, Simon Glass wrote:
>> diff --git a/drivers/input/keyboard/cros_ec_keyb.c
>> b/drivers/input/keyboard/cros_ec_keyb.c
>> index 4083796..dc37b6b 100644
>> --- a/drivers/input/keyboard/cros_ec_keyb.c
>> +++ b/drivers/input/keyboard/cros_ec_keyb.c
>> @@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)
>>
>> static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
>> *kb_state)
>> {
>> - return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
>> - kb_state, ckdev->cols);
>> + int ret;
>> + struct cros_ec_command msg = {
>> + .version = 0,
>> + .command = EC_CMD_MKBP_STATE,
>> + .outdata = NULL,
>> + .outsize = 0,
>> + .indata = kb_state,
>> + .insize = ckdev->cols,
>> + };
>> +
>> + ret = ckdev->ec->cmd_xfer(ckdev->ec, &msg);
>
> Do we need ret?
No. If you wish I will spin without it. Let me know.
Note that locally this code includes a comment between the above and the return:
/* FIXME: This assumes msg.result == EC_RES_SUCCESS */
Given that this is not a new problem introduced in this code, that it
still hasn't been fixed locally in the ChromeOS tree, and that
generally FIXMEs don't seem to be left in the code upstream, I left it
out.
>> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
>> index 2b0c598..60c0880 100644
>> --- a/include/linux/mfd/cros_ec.h
>> +++ b/include/linux/mfd/cros_ec.h
>> @@ -63,9 +63,10 @@ struct cros_ec_command {
>> * @was_wake_device: true if this device was set to wake the system from
>> * sleep at the last suspend
>> * @event_notifier: interrupt event notifier for transport devices
>> - * @command_send: send a command
>> - * @command_recv: receive a response
>> - * @command_sendrecv: send a command and receive a response
>> + * @cmd_xfer: send command to EC and get response
>> + * Returns 0 if the communication succeeded, but that doesn't mean the
>> EC
>> + * was happy with the command it got. Caller should check msg.result for
>> + * the EC's result code.
>> *
>> * @priv: Private data
>> * @irq: Interrupt to use
>> @@ -83,7 +84,6 @@ struct cros_ec_command {
>> * @parent: pointer to parent device (e.g. i2c or spi device)
>> * @wake_enabled: true if this device can wake the system from sleep
>> * @lock: one transaction at a time
>> - * @cmd_xfer: low-level channel to the EC
>> */
>> struct cros_ec_device {
>>
>> @@ -94,13 +94,8 @@ struct cros_ec_device {
>> bool was_wake_device;
>> struct class *cros_class;
>> struct blocking_notifier_head event_notifier;
>> - int (*command_send)(struct cros_ec_device *ec,
>> - uint16_t cmd, void *out_buf, int out_len);
>> - int (*command_recv)(struct cros_ec_device *ec,
>> - uint16_t cmd, void *in_buf, int in_len);
>> - int (*command_sendrecv)(struct cros_ec_device *ec,
>> - uint16_t cmd, void *out_buf, int out_len,
>> - void *in_buf, int in_len);
>> + int (*cmd_xfer)(struct cros_ec_device *ec,
>> + struct cros_ec_command *msg);
>>
>> /* These are used to implement the platform-specific interface */
>> void *priv;
>> @@ -112,8 +107,6 @@ struct cros_ec_device {
>> struct device *parent;
>> bool wake_enabled;
>> struct mutex lock;
>> - int (*cmd_xfer)(struct cros_ec_device *ec,
>> - struct cros_ec_command *msg);
>
> Seems odd - maybe this line move of cmd_xfer() should be in an earlier patch?
It got moved from "private" to public. Bill reorganized all the
public stuff at the top and the private at the bottom.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC
Hi,
On 16 June 2014 14:40, Doug Anderson wrote:
> From: Bill Richardson
>
> When communicating with the EC, the cmd_xfer() function should return the
> number of bytes it received from the EC, or negative on error.
This is just for the I2C tunnel feature, right? If so, I think this
should be mentioned here. It seems to be affecting ec_i2c_xfer(), not
cmd_xfer().
>
> Signed-off-by: Bill Richardson
> Signed-off-by: Doug Anderson
> ---
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
> drivers/mfd/cros_ec_i2c.c | 2 +-
> drivers/mfd/cros_ec_spi.c | 2 +-
> include/linux/mfd/cros_ec.h | 8
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index dd07818..05e033c 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -228,7 +228,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg i2c_msgs[],
> msg.insize = response_len;
>
> result = bus->ec->cmd_xfer(bus->ec, &msg);
> - if (result)
> + if (result < 0)
> goto exit;
>
> result = ec_i2c_parse_response(response, i2c_msgs, &num);
> diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
> index 2276096..dc0ba29 100644
> --- a/drivers/mfd/cros_ec_i2c.c
> +++ b/drivers/mfd/cros_ec_i2c.c
> @@ -120,7 +120,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
> *ec_dev,
> goto done;
> }
>
> - ret = 0;
> + ret = i2c_msg[1].buf[1];
> done:
> kfree(in_buf);
> kfree(out_buf);
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 4d34f1c..beba1bc 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -333,7 +333,7 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
> *ec_dev,
> goto exit;
> }
>
> - ret = 0;
> + ret = len;
> exit:
> mutex_unlock(&ec_spi->lock);
> return ret;
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 60c0880..7b65a75 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -41,7 +41,7 @@ enum {
> * @outdata: Outgoing data to EC
> * @outsize: Outgoing length in bytes
> * @indata: Where to put the incoming data from EC
> - * @insize: Incoming length in bytes (filled in by EC)
> + * @insize: Max number of bytes to accept from EC
> * @result: EC's response to the command (separate from communication
> failure)
> */
> struct cros_ec_command {
> @@ -64,9 +64,9 @@ struct cros_ec_command {
> * sleep at the last suspend
> * @event_notifier: interrupt event notifier for transport devices
> * @cmd_xfer: send command to EC and get response
> - * Returns 0 if the communication succeeded, but that doesn't mean the EC
> - * was happy with the command it got. Caller should check msg.result for
> - * the EC's result code.
> + * Returns the number of bytes received if the communication succeeded,
> but
> + * that doesn't mean the EC was happy with the command. The caller
> + * should check msg.result for the EC's result code.
> *
> * @priv: Private data
> * @irq: Interrupt to use
> --
> 2.0.0.526.g5318336
>
Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
Hi Doug,
On 16 June 2014 14:39, Doug Anderson wrote:
> From: Bill Richardson
>
> Remove the three wrapper functions that talk to the EC without passing all
> the desired arguments and just use the underlying communication function
> that passes everything in a struct intead.
>
> This is internal code refactoring only. Nothing should change.
>
> Signed-off-by: Bill Richardson
> Signed-off-by: Doug Anderson
> ---
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 15 +++
> drivers/input/keyboard/cros_ec_keyb.c | 14 --
> drivers/mfd/cros_ec.c | 32
> include/linux/mfd/cros_ec.h | 19 ++-
> 4 files changed, 29 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index 8e7a714..dd07818 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -183,6 +183,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg i2c_msgs[],
> u8 *request = NULL;
> u8 *response = NULL;
> int result;
> + struct cros_ec_command msg;
>
> request_len = ec_i2c_count_message(i2c_msgs, num);
> if (request_len < 0) {
> @@ -218,9 +219,15 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg i2c_msgs[],
> }
>
> ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
> - result = bus->ec->command_sendrecv(bus->ec, EC_CMD_I2C_PASSTHRU,
> - request, request_len,
> - response, response_len);
> +
> + msg.version = 0;
> + msg.command = EC_CMD_I2C_PASSTHRU;
> + msg.outdata = request;
> + msg.outsize = request_len;
> + msg.indata = response;
> + msg.insize = response_len;
> +
> + result = bus->ec->cmd_xfer(bus->ec, &msg);
> if (result)
> goto exit;
>
> @@ -258,7 +265,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
> u32 remote_bus;
> int err;
>
> - if (!ec->command_sendrecv) {
> + if (!ec->cmd_xfer) {
> dev_err(dev, "Missing sendrecv\n");
> return -EINVAL;
> }
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c
> b/drivers/input/keyboard/cros_ec_keyb.c
> index 4083796..dc37b6b 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)
>
> static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
> *kb_state)
> {
> - return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
> - kb_state, ckdev->cols);
> + int ret;
> + struct cros_ec_command msg = {
> + .version = 0,
> + .command = EC_CMD_MKBP_STATE,
> + .outdata = NULL,
> + .outsize = 0,
> + .indata = kb_state,
> + .insize = ckdev->cols,
> + };
> +
> + ret = ckdev->ec->cmd_xfer(ckdev->ec, &msg);
Do we need ret?
> + return ret;
> }
>
> static int cros_ec_keyb_work(struct notifier_block *nb,
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index d242714..6dd91e9 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -44,34 +44,6 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_prepare_tx);
>
> -static int cros_ec_command_sendrecv(struct cros_ec_device *ec_dev,
> - uint16_t cmd, void *out_buf, int out_len,
> - void *in_buf, int in_len)
> -{
> - struct cros_ec_command msg;
> -
> - msg.version = cmd >> 8;
> - msg.command = cmd & 0xff;
> - msg.outdata = out_buf;
> - msg.outsize = out_len;
> - msg.indata = in_buf;
> - msg.insize = in_len;
> -
> - return ec_dev->cmd_xfer(ec_dev, &msg);
> -}
> -
> -static int cros_ec_command_recv(struct cros_ec_device *ec_dev,
> - uint16_t cmd, void *buf, int buf_len)
> -{
> - return cros_ec_command_sendrecv(ec_dev, cmd, NULL, 0, buf, buf_len);
> -}
> -
> -static int cros_ec_command_send(struct cros_ec_device *ec_dev,
> - uint16_t cmd, void *buf, int buf_len)
> -{
> - return cros_ec_command_sendrecv(ec_dev, cmd, buf, buf_len, NULL, 0);
> -}
> -
> static irqreturn_t ec_irq_thread(int irq, void *data)
> {
> struct cros_ec_device *ec_dev = data;
> @@ -104,10 +76,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>
> BLOCKING_INIT_NOTIFIER_HEAD(&ec_dev->event_notifier);
>
> - ec_dev->command_send = cros_ec_command_send;
> - ec_dev->command_recv = cros_ec_command_recv;
> - ec_dev->command_sendrecv = cros_ec_command_sendrecv;
> -
> if (ec_dev->din_size) {
> ec_dev->din = devm_kzalloc(
Re: [PATCH v2] i2c: sun6-p2wi: fix call to snprintf
On Fri, Jun 13, 2014 at 12:23:48PM +0200, Boris BREZILLON wrote: > Fixes possible issue in case pdev name contains formatting characters. > > Signed-off-by: Boris BREZILLON > Reported-by: Kees Cook Applied to for-next, thanks! signature.asc Description: Digital signature
Re: I2C Slave monitor mode support
> Few of the I2C interfaces are [operated] with slave monitor mode, when > there is a requirement for > a particular slave may need to wait some time to get the ADDR before > sending an ACK. Can you describe an existing scenario? Why can't the slave use clock stretching? > This feature is an optional and defined in few of the controllers, Can > anyone tell me is this support is > added already in kernel, if yes please point to the respective driver > or code link. None that I know of. The above questions should help me understand why it is needed on master driver level at all. signature.asc Description: Digital signature
Re: [PATCH 1/2] I2C: EMMA Mobile I2C master driver
On Tue, Feb 18, 2014 at 06:38:43PM +0100, Wolfram Sang wrote: > On Tue, Sep 03, 2013 at 05:49:29PM +0100, Ian Molton wrote: > > Add a driver for the EMMA mobile I2C block. > > > > The driver supports low and high-speed interrupt driven PIO transfers. > > > > Signed-off-by: Ian Molton > > > --- a/drivers/i2c/busses/Kconfig > > +++ b/drivers/i2c/busses/Kconfig > > @@ -777,6 +777,16 @@ config I2C_RCAR > > This driver can also be built as a module. If so, the module > > will be called i2c-rcar. > > > > +config I2C_EM > > + tristate "EMMA Mobile series I2C adapter" > > + depends on I2C && HAVE_CLK > > + help > > + If you say yes to this option, support will be included for the > > + I2C interface on the Renesas Electronics EM/EV family of processors. > > + > > + This driver can also be built as a module. If so, the module > > + will be called i2c-em > > + > > Please keep it sorted. Ping. Still any interest in this one? signature.asc Description: Digital signature
