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: <AANLkTikWvRKzr+kffcpTHTs3q3TLeUPzdwzuQSR_tSU2@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ