linux-kernel - Re: [PATCHv4 1/5] misc: Driver for bh1770glc / sfh7770 ALS and proximity sensor

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]

Date:	Tue, 26 Oct 2010 10:47:48 -0400
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Samu Onkalo <samu.p.onkalo@...ia.com>
Cc:	akpm@...ux-foundation.org, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [PATCHv4 1/5] misc: Driver for bh1770glc / sfh7770 ALS and
 proximity sensor

010/10/19 Samu Onkalo <samu.p.onkalo@...ia.com>:

> This is a driver for ROHM BH1770GLC and OSRAM SFH7770 combined
> ALS and proximity sensor.
>
> Interface is sysfs based. The driver uses interrupts to provide new data.
> The driver supports pm_runtime and regulator frameworks.
> (...)
> +static DEVICE_ATTR(prox0_raw_en, S_IRUGO | S_IWUSR, bh1770_prox_enable_show,
> +                                               bh1770_prox_enable_store);
> +static DEVICE_ATTR(prox0_thresh_above1_value, S_IRUGO | S_IWUSR,
> +                                               bh1770_prox_abs_thres_show,
> +                                               bh1770_prox_abs_thres_store);
> +static DEVICE_ATTR(prox0_thresh_above0_value, S_IRUGO | S_IWUSR,
> +                                               bh1770_get_prox_thres,
> +                                               bh1770_set_prox_thres);
> +static DEVICE_ATTR(prox0_raw, S_IRUGO, bh1770_prox_result_show, NULL);

So you have sysfs entries for enabling, calibrating hysteris
(above/below) and the reading the raw value which I assume
will be 0 (if nothing is in proximity) or 1 (if it is in proximity).

These entries are pretty OK I think, but the transition from
0 to 1 which I assume will generate an interrupt and generate
a new value in this attribute.

But should it not hook into the input framework and generate
a SW_FRONT_PROXIMITY event as well?

I think this could be pretty helpful for generic userspace
applications like X that want to use this event.

Of course I can send a patch for this later, but I'd like
to hear whether you agree on this or not.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/