Re: [PATCH 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions

[Doug Anderson]

Simon,

On Tue, Jun 17, 2014 at 8:42 PM, Simon Glass <sjg@xxxxxxxxxxxx> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/