linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Enric Balletbo Serra <eballetbo@gmail.com>
To: Gwendal Grignou <gwendal@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Benson Leung <bleung@chromium.org>,
	Lee Jones <lee.jones@linaro.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mfd: cros: Update EC protocol to match current EC code
Date: Wed, 6 Mar 2019 17:57:04 +0100	[thread overview]
Message-ID: <CAFqH_52tWw8pGwY5fdAPQ6npbfWA7o4OhtPxvbUbCh5TdnbSew@mail.gmail.com> (raw)
In-Reply-To: <20190228002725.57444-1-gwendal@chromium.org>

Hi Gwendal,

Many thanks to send this upstream.

Missatge de Gwendal Grignou <gwendal@chromium.org> del dia dj., 28 de
febr. 2019 a les 1:31:
>
> Chromebook Embedded Controller protocol is defined in the kernel at
> cros_ec_commands.h.
> The source of trust for the EC protocol is at
> https://chromium.googlesource.com/chromiumos/platform/ec/+/master/include/ec_commands.h
>
> Only needed changes have been picked up from this file to the kernel
> include file leading to gaps between the upstream version and what the
> latest ECs can do.
>
> Fill the gaps to ease future integrations. Changes from the original
> files is header/footer for license and include files for alignment.
>
> Check this include file works on ChomeOS kernel 4.14 and 4.19 on eve.
>
> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
> ---
>  include/linux/mfd/cros_ec_commands.h | 3627 +++++++++++++++++++++-----

I'm wondering if we should move this file to include/uapi at some
point as this file is also used as user-space API for some userspace
applications.

While we are here I'd suggest if we can also fix the few errors (3)
and warnings (5) spotted by checkpatch. With that it's an ack from my
side.

Being strict, though, on most cases the variables are going to be used
in code that can be seen by user-space programs so maybe we should
really need to switch to __u8/__u16/etc exportable data types instead
of the uint8_t/uint16_t/etc types (those are not aimed to be used
within the kernel). For those types that are internal we should use
in-kernel type (u8/u16/etc)

There is also the use of the BIT macro instead of the (1 << x), I know
that this is a maintainer preference.

[snip]

Thanks,
 Enric

  reply	other threads:[~2019-03-06 16:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-28  0:27 [PATCH] mfd: cros: Update EC protocol to match current EC code Gwendal Grignou
2019-03-06 16:57 ` Enric Balletbo Serra [this message]
2019-03-06 17:20   ` Guenter Roeck
2019-03-06 18:26     ` Enric Balletbo Serra
2019-03-06 18:57       ` Guenter Roeck
2019-03-07 14:49         ` Enric Balletbo Serra
2019-03-12  6:50           ` Gwendal Grignou
2019-03-26 17:21             ` [PATCH v2] " Gwendal Grignou
2019-03-27  9:31               ` Enric Balletbo i Serra
2019-03-28 21:48                 ` Gwendal Grignou
2019-03-28 21:52                   ` [PATCH v3] " Gwendal Grignou
2019-03-28 21:58                     ` Gwendal Grignou
2019-03-29 12:14                       ` Enric Balletbo i Serra
2019-03-29 13:36                     ` Enric Balletbo i Serra
2019-03-29 17:44                       ` Gwendal Grignou
2019-03-29 17:56                         ` [PATCH 1/3] ASoC: cros_ec_codec: Rename ec_response_codec_gain into ec_codec_i2s_gain Gwendal Grignou
2019-04-01  7:56                           ` Mark Brown
     [not found]                         ` <20190329175628.31481-1-gwendal@chromium.org>
2019-03-29 17:56                           ` [PATCH v3 2/3] mfd: cros: Update EC protocol to match current EC code Gwendal Grignou
2019-03-30 14:55                             ` Jonathan Cameron
2019-03-29 17:56                           ` [PATCH 3/3] mfd: cros: Update EC to use BIT() and merge Gwendal Grignou
2019-03-30 14:43                             ` Jonathan Cameron
2019-04-01 10:06 ` [PATCH] mfd: cros: Update EC protocol to match current EC code Lee Jones

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=CAFqH_52tWw8pGwY5fdAPQ6npbfWA7o4OhtPxvbUbCh5TdnbSew@mail.gmail.com \
    --to=eballetbo@gmail.com \
    --cc=bleung@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).