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: <20210206161711.6f555434@archlinux>
Date:   Sat, 6 Feb 2021 16:17:11 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Benson Leung <bleung@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Douglas Anderson <dianders@...omium.org>,
        Gwendal Grignou <gwendal@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>
Subject: Re: [PATCH v4 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity
 driver

On Tue,  2 Feb 2021 10:44:34 -0800
Stephen Boyd <swboyd@...omium.org> wrote:

> Add support for a ChromeOS EC proximity driver that exposes a "front"
> proximity sensor via the IIO subsystem. The EC decides when front
> proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
> notify the kernel of proximity. Similarly, when proximity detects
> something far away it sets the switch bit to 0. For now this driver
> exposes a single sensor, but it could be expanded in the future via more
> MKBP bits if desired.
> 
> Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>
> Cc: Benson Leung <bleung@...omium.org>
> Cc: Guenter Roeck <groeck@...omium.org>
> Cc: Douglas Anderson <dianders@...omium.org>
> Cc: Gwendal Grignou <gwendal@...omium.org>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
> Signed-off-by: Stephen Boyd <swboyd@...omium.org>

Just one thing noticed on a final read through.  I'm happy to fix up
whilst applying.  Otherwise all I'm waiting for now is to give
Rob time to look at the device tree binding if he wants to do so.

Jonathan

> diff --git a/drivers/iio/proximity/cros_ec_mkbp_proximity.c b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> new file mode 100644
> index 000000000000..23bed4562b34
> --- /dev/null
> +++ b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> @@ -0,0 +1,242 @@
...

> +static struct platform_driver cros_ec_mkbp_proximity_driver = {
> +	.driver = {
> +		.name = "cros-ec-mkbp-proximity",
> +		.of_match_table = of_match_ptr(cros_ec_mkbp_proximity_of_match),
I'm going to assume we know no one is going to use this with
ACPI via PRP0001 given presumably the firmware on these devices
is tightly controlled.

However, we should should still drop the of_match_ptr
as it will lead to an unused warning for cros_ec_mkbp_proximity_of_match
if anyone builds this without CONFIG_OF + it sets a general bad
precedence that I'd rather wasn't around for people to copy.
Note that in general we are slowly ripping these out of IIO but
probably lots still there.

If this is all that is needed in this version I'll just do it
whilst applying unless anyone shouts.

Jonathan

> +	},
> +	.probe = cros_ec_mkbp_proximity_probe,
> +	.remove = cros_ec_mkbp_proximity_remove,
> +};
> +module_platform_driver(cros_ec_mkbp_proximity_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("ChromeOS EC MKBP proximity sensor driver");

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ