linux-kernel - Re: [PATCH] mfd: cros: Update EC protocol to match current EC code

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAFqH_53uYy0oTTYSJkkgM+Sz+uJYpJ3pAq0LtRjCKaZF0FS0gg@mail.gmail.com>
Date:   Thu, 7 Mar 2019 15:49:30 +0100
From:   Enric Balletbo Serra <eballetbo@...il.com>
To:     Guenter Roeck <groeck@...gle.com>
Cc:     Gwendal Grignou <gwendal@...omium.org>,
        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 Lee,
Missatge de Guenter Roeck <groeck@...gle.com> del dia dc., 6 de març
2019 a les 19:58:
>
> On Wed, Mar 6, 2019 at 10:27 AM Enric Balletbo Serra
> <eballetbo@...il.com> wrote:
> >
> > Hi Guenter,
> >
> > Missatge de Guenter Roeck <groeck@...gle.com> del dia dc., 6 de març
> > 2019 a les 18:20:
> > >
> > > [resending in plain text mode ]
> > >
> > > On Wed, Mar 6, 2019 at 8:57 AM Enric Balletbo Serra <eballetbo@...il.com> wrote:
> > > >
> > > > 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 +++++++++++++++++++++-----
> > > >

Just for if I was not clear after the discussion this is an ack from my side

Acked-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>

> > > > 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 ?
> >
> > Sorry, if I wasn't clear from my side, I should have marked those as
> > nit, as in this case, I don't really mind, but I remember Lee
> > requesting some of those changes for this file.
> >
> > What I want to avoid is the desynchronization again. As this file
> > belongs to the MFD subsystem Lee needs to be happy with it or at least
> > know that we're not following the kernel style because is an imported
> > file (i.e not using the BIT macro, doing this example because I know
> > he takes care of this).
> >
> > So I think that the main question here is if an imported file like
> > this is acceptable in the include/linux/mfd?
> >
>
> I find it highly (and more and more) confusing about what is
> acceptable in the kernel and where, and what isn't. There are imported
> files all over the place, and they seem to be widely acceptable and
> accepted. It is difficult to keep track of what is acceptable and what
> isn't on a per subsystem basis. I'll step back and keep my confusion
> to myself.
>

In theory, I should be cc'ied if someone sends a modification to this
file, also Guenter and Benson. So we can take care that is synced with
the EC code and doesn't diverge again. I think that this is the main
purpose.

Thanks,
 Enric

> > > After all, this is an imported file, and
> > > we don't usually expect that imported files meet the Linux kernel
> > > coding style.
> > >
> >
> > I remember seeing somewhere that the EC code was following the Linux
> > kernel style? Now I am not able to find where.
> >
>
> You are correct: https://www.chromium.org/chromium-os/ec-development
>
> Running checkpatch over the code, it doesn't look like that is
> followed, though, much less enforced.
>
> Guenter
>
> > Thanks,
> >  Enric
> >
> > > Thanks,
> > > Guenter
> > >
> > > > [snip]
> > > >
> > > > Thanks,
> > > >  Enric