linux-kernel - Re: [RESEND PATCH v7 2/6] mfd: cros_ec: Add cros_ec_cmd_xfer

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAAObsKCDqzx5GeVxqHuKCcbiAnwCE97VXxacBe6zc0BFMLAK7A@mail.gmail.com>
Date:	Mon, 11 Apr 2016 15:53:07 +0200
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sameer Nanda <snanda@...omium.org>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Benson Leung <bleung@...omium.org>,
	Enric Balletbò <enric.balletbo@...labora.co.uk>,
	Vic Yang <victoryang@...omium.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Vincent Palatin <vpalatin@...omium.org>,
	Randall Spangler <rspangler@...omium.org>,
	Todd Broch <tbroch@...omium.org>,
	Gwendal Grignou <gwendal@...omium.org>,
	Olof Johansson <olof@...om.net>
Subject: Re: [RESEND PATCH v7 2/6] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

On 11 April 2016 at 13:18, Lee Jones <lee.jones@...aro.org> wrote:
> On Tue, 05 Apr 2016, Tomeu Vizoso wrote:
>
>> So that callers of cros_ec_cmd_xfer don't have to repeat boilerplate
>> code when checking for errors from the EC side.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
>> Reviewed-by: Benson Leung <bleung@...omium.org>
>> ---
>>
>> Changes in v7: None
>> Changes in v6: None
>> Changes in v5:
>> - Check explicitly for !EC_RES_SUCCESS as suggested by Benson Leung.
>>
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2: None
>>
>>  drivers/platform/chrome/cros_ec_proto.c | 14 ++++++++++++++
>>  include/linux/mfd/cros_ec.h             | 18 ++++++++++++++++++
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
>> index c792e116e621..aaccdde1c9d5 100644
>> --- a/drivers/platform/chrome/cros_ec_proto.c
>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>> @@ -472,3 +472,17 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev)
>>               return get_keyboard_state_event(ec_dev);
>>  }
>>  EXPORT_SYMBOL(cros_ec_get_next_event);
>> +
>> +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
>> +                         struct cros_ec_command *msg)
>> +{
>> +     int ret = cros_ec_cmd_xfer(ec_dev, msg);
>
> I don't really like function calls during declaration time.

Ok.

> If you make the call here, you don't have to leave a pointless '\n'
> between it and checking the return value.
>
>> +     if (ret < 0)
>> +             dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
>> +     else if (msg->result != EC_RES_SUCCESS)
>> +             return -EECRESULT - msg->result;
>> +
>> +     return ret;
>> +}
>> +EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
>> index ddc935ef1911..e4c4c0480c14 100644
>> --- a/include/linux/mfd/cros_ec.h
>> +++ b/include/linux/mfd/cros_ec.h
>> @@ -40,6 +40,9 @@
>>  #define EC_MAX_REQUEST_OVERHEAD              1
>>  #define EC_MAX_RESPONSE_OVERHEAD     2
>>
>> +/* ec_command return value for non-success result from EC */
>> +#define EECRESULT 1000
>> +
>>  /*
>>   * Command interface between EC and AP, for LPC, I2C and SPI interfaces.
>>   */
>> @@ -250,6 +253,21 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
>>                    struct cros_ec_command *msg);
>>
>>  /**
>> + * cros_ec_cmd_xfer_status - Send a command to the ChromeOS EC
>> + *
>> + * This function is identical to cros_ec_cmd_xfer, except it returns succes
>> + * status only if both the command was transmitted successfully and the EC
>> + * replied with success status. It's not necessary to check msg->result when
>> + * using this function.
>
> Is it useful for callers of cros_ec_cmd_xfer() to ever not do this?
> If not, why don't you make these changes in cros_ec_cmd_xfer() itself?

Some callers of cros_ec_cmd_xfer() (for example, the tunnel) just want
to know if the message was successfully transmitted, regardless of
whether the command was successful or not.

Thanks,

Tomeu

>> + * @ec_dev: EC device
>> + * @msg: Message to write
>> + * @return: Num. of bytes transferred on success, <0 on failure
>> + */
>> +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
>> +                         struct cros_ec_command *msg);
>> +
>> +/**
>>   * cros_ec_remove - Remove a ChromeOS EC
>>   *
>>   * Call this to deregister a ChromeOS EC, then clean up any private data.
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog