From: Lee Jones <lee.jones@linaro.org>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: gwendal@chromium.org, bleung@chromium.org,
linux-kernel@vger.kernel.org, groeck@chromium.org,
kernel@collabora.com, dtor@chromium.org,
Vincent Palatin <vpalatin@chromium.org>
Subject: Re: [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP events
Date: Wed, 8 May 2019 08:55:40 +0100 [thread overview]
Message-ID: <20190508075540.GA3995@dell> (raw)
In-Reply-To: <c6cd7740-c3aa-6420-a789-735179ba59b4@collabora.com>
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@chromium.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
prev parent reply other threads:[~2019-05-08 7:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 12:36 [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP events Enric Balletbo i Serra
2019-04-02 4:06 ` Lee Jones
2019-04-08 15:41 ` Enric Balletbo i Serra
2019-05-08 7:55 ` Lee Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190508075540.GA3995@dell \
--to=lee.jones@linaro.org \
--cc=bleung@chromium.org \
--cc=dtor@chromium.org \
--cc=enric.balletbo@collabora.com \
--cc=groeck@chromium.org \
--cc=gwendal@chromium.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vpalatin@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox