Messages in this thread | | | From | Guenter Roeck <> | Date | Wed, 6 Mar 2019 09:20:33 -0800 | Subject | Re: [PATCH] mfd: cros: Update EC protocol to match current EC code |
| |
[resending in plain text mode ]
On Wed, Mar 6, 2019 at 8:57 AM Enric Balletbo Serra <eballetbo@gmail.com> wrote: > > 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. > Is all that even possible ? After all, this is an imported file, and we don't usually expect that imported files meet the Linux kernel coding style.
Thanks, Guenter
> [snip] > > Thanks, > Enric
| |