linux-kernel - Re: [PATCH v2 2/2] platform/chrome: cros_ec_lpcs: reserve the MEC LPC I/O ports first

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>] [day] [month] [year] [list]

Date:   Wed, 2 Feb 2022 11:47:17 -0800
From:   Prashant Malani <pmalani@...omium.org>
To:     Aseda Aboagye <aaboagye@...gle.com>
Cc:     Dustin Howett <dustin@...ett.net>, linux-kernel@...r.kernel.org,
        Benson Leung <bleung@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Tzung-Bi Shih <tzungbi@...gle.com>,
        Michael Niksa <michael.niksa@...e.com>,
        Aseda Aboagye <aaboagye@...omium.org>
Subject: Re: [PATCH v2 2/2] platform/chrome: cros_ec_lpcs: reserve the MEC LPC
 I/O ports first

Hi,

On Fri, Jan 28, 2022 at 9:57 AM Aseda Aboagye <aaboagye@...gle.com> wrote:
>
> Generally ec_commands.h is to be kept in sync with the copies in other projects. Periodically when someone modifies it, we should update the copies as well.
> --
> Aseda Aboagye
>
>
> On Thu, Jan 27, 2022 at 9:16 PM Dustin Howett <dustin@...ett.net> wrote:
>>
>> On Thu, Jan 27, 2022 at 1:25 PM Prashant Malani <pmalani@...omium.org> wrote:
>> >
>> > What source do Framework laptop ECs (MECs?) compile their EC firmware
>> > from?
>>
>> They just released their source here:
>> https://github.com/FrameworkComputer/EmbeddedController
>>
>> FWIW, this series was written before they went open, and you're not
>> likely to see a similar construct
>> over there.
>>
>> > Yeah, I wasn't thinking about userland i/o port access, but just having
>> > this behaviour/different I/O port mapping described in the EC code base
>> > too.
>>
>> Happy to submit this over there as well. Are cros_ec_commands.h (here)
>> and ec_commands.h (there)
>> intended to be kept in 1:1 sync?

It's not auto-generated, but FWIW cros_ec_commands.h is a subset of
ec_commands.h (only the parts of ec_commands.h which are relevant to
the kernel drivers are brought over)

>>
>> As well, is this a blocking concern?
I'd prefer it to be first documented in the EC sources via a header
update before we make changes to the kernel here. This ensures that
the authors and maintainers of the various EC sources (Chromium EC,
framework EC etc) are aware of this change and sign-off on it.

I think making this update to the Chromium OS platform/ec code base
will be sufficient (it can flow down to framework when/if they chose
to sync to Chromium platform/ec); but happy to be corrected here by
Aseda or other EC experts.

Thanks,