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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Mar 2019 17:57:04 +0100
From:   Enric Balletbo Serra <eballetbo@...il.com>
To:     Gwendal Grignou <gwendal@...omium.org>
Cc:     Guenter Roeck <groeck@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Benson Leung <bleung@...omium.org>,
        Lee Jones <lee.jones@...aro.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mfd: cros: Update EC protocol to match current EC code

Hi Gwendal,

Many thanks to send this upstream.

Missatge de Gwendal Grignou <gwendal@...omium.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@...omium.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

Powered by blists - more mailing lists