linux-kernel - Re: [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP events

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

Message-ID: <20190508075540.GA3995@dell>
Date:   Wed, 8 May 2019 08:55:40 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Enric Balletbo i Serra <enric.balletbo@...labora.com>
Cc:     gwendal@...omium.org, bleung@...omium.org,
        linux-kernel@...r.kernel.org, groeck@...omium.org,
        kernel@...labora.com, dtor@...omium.org,
        Vincent Palatin <vpalatin@...omium.org>
Subject: Re: [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP
 events

On Mon, 08 Apr 2019, Enric Balletbo i Serra wrote:

> Hi Lee,
> 
> On 2/4/19 6:06, Lee Jones wrote:
> > On Fri, 08 Mar 2019, Enric Balletbo i Serra wrote:
> > 
> >> From: Vincent Palatin <vpalatin@...omium.org>
> >>
> >> Allow to poll on the cros_ec device to receive the MKBP events.
> >>
> >> The /dev/cros_[ec|fp|..] file operations now implements the poll
> >> operation. The userspace can now receive specific MKBP events by doing the
> >> following:
> >> - Open the /dev/cros_XX file.
> >> - Call the CROS_EC_DEV_IOCEVENTMASK ioctl with the bitmap of the MKBP
> >>   events it wishes to receive as argument.
> >> - Poll on the file descriptor.
> >> - When it gets POLLIN, do a read on the file descriptor, the first
> >>   queued event will be returned (using the struct
> >>   ec_response_get_next_event format: one byte of event type, then
> >>   the payload).
> >>
> >> The read() operation returns at most one event even if there are several
> >> queued, and it might be truncated if the buffer is smaller than the
> >> event (but the caller should know the maximum size of the events it is
> >> reading).
> >>
> >> read() used to return the EC version string, it still does it when no
> >> event mask or an empty event is set for backward compatibility (despite
> >> nobody really using this feature).
> >>
> >> This will be used, for example, by the userspace daemon to receive and
> >> treat the EC_MKBP_EVENT_FINGERPRINT sent by the FP MCU.
> > 
> > MFD does not seem like the correct place for this.  Maybe this is a
> > good candidate for drivers/platform/chrome/* where the rest of your
> > platform empire now resides.
> > 
> 
> The patch itself can't be moved without moving other parts, this would imply
> move all the file_operations and the chardev, those already resides in MFD, and
> some event handling. Is this what you're suggesting?

That would make the most sense, yes.

This whole Embedded Controller thing far extends the bounds of what
MFD was designed to do.  Hence why a great deal of it has already been
moved out to drivers/platform.

> If that's the case I need to look in more detail.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog