* [PATCH] Input: ads7846 - Use IS_ENABLED() macro
From: Fabio Estevam @ 2013-12-02 2:34 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
Using the IS_ENABLED() macro can make the code shorter and simpler
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/input/touchscreen/ads7846.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index ea19536..5695786 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -101,7 +101,7 @@ struct ads7846 {
struct spi_device *spi;
struct regulator *reg;
-#if defined(CONFIG_HWMON) || defined(CONFIG_HWMON_MODULE)
+#if IS_ENABLED(CONFIG_HWMON)
struct attribute_group *attr_group;
struct device *hwmon;
#endif
@@ -421,7 +421,7 @@ static int ads7845_read12_ser(struct device *dev, unsigned command)
return status;
}
-#if defined(CONFIG_HWMON) || defined(CONFIG_HWMON_MODULE)
+#if IS_ENABLED(CONFIG_HWMON)
#define SHOW(name, var, adjust) static ssize_t \
name ## _show(struct device *dev, struct device_attribute *attr, char *buf) \
--
1.8.1.2
^ permalink raw reply related
* Re: 3.12.x looses serial mouse over hibernate + resume
From: Peter Hurley @ 2013-12-01 15:43 UTC (permalink / raw)
To: Manuel Krause
Cc: linux-kernel, Greg KH, Dmitry Torokhov, linux-input, linux-serial
In-Reply-To: <52951E69.7090602@netscape.net>
[ +cc Dmitry Torokhov, Greg Kroah-Hartman, linux-input, linux-serial ]
On 11/26/2013 05:19 PM, Manuel Krause wrote:
> Since kernel 3.12.0 I have a problem with hibernate+resume
> not reactivating my serial mouse (trackball) with my HP notebook.
> Kernels 3.11.0 til 9 don't show this behaviour.
>
> Machine: HP Notebook with Core2Duo CPU (Penryn)
> Distro: openSUSE 12.3, 64bit, continuously updated
> Desktop: KDE 4.11.3
> MESA & drm & Xorg: most recent ones from:
>
> http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_12.3/x86_64/
> Current kernel: 3.12.1 vanilla from openSUSE repos, with
> -ck1 and BFQ patches
>
> The Logitech Trackman Marble FX is a PS/2 device and connected via an original Logitech
> PS/2-COM-port adapter and manually configured via my xorg.conf.
>
> At first, I blamed the -ck1 patches from Con Kolivas for this behaviour that I use in
> addition to the BFQ patches, what has showed up as not right: This happens with the
> normal vanilla kernel
> schedulers for CPU and disk I/O, too.
>
> By coincidence I found a weird(!) way to reactivate the serial mouse:
> (1) call Hibernate (suspend-to-disk) from KDE desktop as normal
> (2) resume --> the PS/2 touchpad is working, the serial trackball NOT
> (3) call suspend-to-RAM (Sleep) from KDE, serial trackball still dead
> (4) execute `setserial -a /dev/ttyS0` in a konsole window or a tty* console
> (5) ==> serial trackball is back with all configuration from xorg.conf
>
> It's fully reproducible over multiple hibernations. This also happens when calling
> `pm-hibernate` (to-disk) and `pm-suspend` (to-RAM) and the setserial from a root shell
> in KDE or any tty*.
>
> Please, _always_CC_me_ -- as I'm not on the kernel mailing list.
Manuel,
Please attach complete dmesgs (zipped, if necessary) of a suspend/resume cycle
on a vanilla 3.12.x (where resume fails) _and_ a vanilla 3.11.x (where resume succeeds).
For the test configurations, please do not apply patches.
Regards,
Peter Hurley
^ permalink raw reply
* [PATCH] HID: kye: Fix missing break in kye_report_fixup()
From: Ben Hutchings @ 2013-11-30 19:12 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Adam Kulagowski, Benjamin Tissoires, linux-input
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
The change to support Genius Manticore Keyboard also changed behaviour
for Genius Gx Imperator Keyboard, as there is no break between the
cases. This is presumably a mistake.
Reported by Coverity as CID 1134029.
Fixes: 4a2c94c9b6c0 ('HID: kye: Add report fixup for Genius Manticore Keyboard')
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/hid/hid-kye.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index ecb5ca6..e776963 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -341,6 +341,7 @@ static __u8 *kye_report_fixup(struct hid_device *hdev, __u8 *rdesc,
case USB_DEVICE_ID_GENIUS_GX_IMPERATOR:
rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 83,
"Genius Gx Imperator Keyboard");
+ break;
case USB_DEVICE_ID_GENIUS_MANTICORE:
rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 104,
"Genius Manticore Keyboard");
--
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
- Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] iio: hid-sensors: Fix power and report state
From: Greg KH @ 2013-11-30 17:07 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Srinivas Pandruvada, jkosina-AlSwsSmVLrQ,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5299CBD0.4030403-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Sat, Nov 30, 2013 at 11:28:16AM +0000, Jonathan Cameron wrote:
> On 11/27/13 22:19, Srinivas Pandruvada wrote:
> > In the original HID sensor hub firmwares all Named array enums were
> > to 0-based. But the most recent hub implemented as 1-based,
> > because of the implementation by one of the major OS vendor.
> > Using logical minimum for the field as the base of enum. So we add
> > logical minimum to the selector values before setting those fields.
> > Some sensor hub FWs already changed logical minimum from 0 to 1
> > to reflect this and hope every other vendor will follow.
> > There is no easy way to add a common HID quirk for NAry elements,
> > even if the standard specifies these field as NAry, the collection
> > used to describe selectors is still just "logical".
> >
> > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> Looks like a good solution to me.
>
> This one is a little interesting. Technically I 'believe' we don't have
> a bug as it is possible to make these devices work via the kconfig option
> and it definitely isn't a regression. As such I have applied this to the
> branch intended for the next kernel cycled (togreg) rather than to the
> fixes branch.
>
> If people have a very strong feeling about this then shout reasonably quickly - I'll
> probably hold off sending that branch to Greg for a few days anyway.
>
> I've cc'd GregKH to see if he has any input on the path this should take.
Making things "dynamic" and not depending on a random Kconfig option
(which one should a distro pick?) is a -fix in my mind...
thanks,
greg k-h
^ permalink raw reply
* [PATCHv4 2/2] dt: binding documentation for twl4030-keypad
From: Sebastian Reichel @ 2013-11-30 16:53 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Grant Likely, devicetree, linux-doc,
linux-kernel, Sebastian Reichel
In-Reply-To: <1385830416-12900-1-git-send-email-sre@debian.org>
Add devicetree binding documentation for twl4030-keypad.
Signed-off-by: Sebastian Reichel <sre@debian.org>
---
.../devicetree/bindings/input/twl4030-keypad.txt | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/twl4030-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/twl4030-keypad.txt b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
new file mode 100644
index 0000000..e4be2f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
@@ -0,0 +1,27 @@
+* TWL4030's Keypad Controller device tree bindings
+
+TWL4030's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+ * keypad,num-rows and keypad,num-columns are required.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - "ti,twl4030-keypad": For controllers compatible with twl4030 keypad
+ controller.
+- interrupt: should be one of the following
+ - <1>: For controllers compatible with twl4030 keypad controller.
+
+Example:
+ twl_keypad: keypad {
+ compatible = "ti,twl4030-keypad";
+ interrupts = <1>;
+ keypad,num-rows = <8>;
+ keypad,num-columns = <8>;
+ };
--
1.8.4.3
^ permalink raw reply related
* [PATCHv4 0/2] twl4030-keypad DT binding
From: Sebastian Reichel @ 2013-11-30 16:53 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Grant Likely, devicetree, linux-doc,
linux-kernel, Sebastian Reichel
In-Reply-To: <1383948866-32672-1-git-send-email-sre@debian.org>
Hi,
Add device tree support for the twl4030 keypad, which is
for example used in the Nokia N900.
Changes since v3 [0]:
* Removed support for disabling autorepeat via DT. There
is still discussion going on, how the standard binding
should look like. On the other hand everyone agrees,
that autorepeat should be default for keypads.
* Remove useless twl4030_keypad_dt_match
[0] https://lkml.org/lkml/2013/11/8/463
-- Sebastian
Sebastian Reichel (2):
Input: twl4030-keypad - add device tree support
dt: binding documentation for twl4030-keypad
.../devicetree/bindings/input/twl4030-keypad.txt | 27 +++++++++
drivers/input/keyboard/twl4030_keypad.c | 65 ++++++++++++++++------
2 files changed, 75 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/twl4030-keypad.txt
--
1.8.4.3
^ permalink raw reply
* [PATCHv4 1/2] Input: twl4030-keypad - add device tree support
From: Sebastian Reichel @ 2013-11-30 16:53 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Grant Likely, devicetree, linux-doc,
linux-kernel, Sebastian Reichel
In-Reply-To: <1385830416-12900-1-git-send-email-sre@debian.org>
Add device tree support for twl4030 keypad driver.
Tested on Nokia N900.
Signed-off-by: Sebastian Reichel <sre@debian.org>
---
drivers/input/keyboard/twl4030_keypad.c | 65 ++++++++++++++++++++++++---------
1 file changed, 48 insertions(+), 17 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c b/drivers/input/keyboard/twl4030_keypad.c
index d2d178c..5d0cffb 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -33,6 +33,7 @@
#include <linux/platform_device.h>
#include <linux/i2c/twl.h>
#include <linux/slab.h>
+#include <linux/of.h>
/*
* The TWL4030 family chips include a keypad controller that supports
@@ -60,6 +61,7 @@
struct twl4030_keypad {
unsigned short keymap[TWL4030_KEYMAP_SIZE];
u16 kp_state[TWL4030_MAX_ROWS];
+ bool autorepeat;
unsigned n_rows;
unsigned n_cols;
unsigned irq;
@@ -331,20 +333,12 @@ static int twl4030_kp_program(struct twl4030_keypad *kp)
static int twl4030_kp_probe(struct platform_device *pdev)
{
struct twl4030_keypad_data *pdata = pdev->dev.platform_data;
- const struct matrix_keymap_data *keymap_data;
+ const struct matrix_keymap_data *keymap_data = NULL;
struct twl4030_keypad *kp;
struct input_dev *input;
u8 reg;
int error;
- if (!pdata || !pdata->rows || !pdata->cols || !pdata->keymap_data ||
- pdata->rows > TWL4030_MAX_ROWS || pdata->cols > TWL4030_MAX_COLS) {
- dev_err(&pdev->dev, "Invalid platform_data\n");
- return -EINVAL;
- }
-
- keymap_data = pdata->keymap_data;
-
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
input = input_allocate_device();
if (!kp || !input) {
@@ -352,13 +346,9 @@ static int twl4030_kp_probe(struct platform_device *pdev)
goto err1;
}
- /* Get the debug Device */
- kp->dbg_dev = &pdev->dev;
- kp->input = input;
-
- kp->n_rows = pdata->rows;
- kp->n_cols = pdata->cols;
- kp->irq = platform_get_irq(pdev, 0);
+ /* get the debug device */
+ kp->dbg_dev = &pdev->dev;
+ kp->input = input;
/* setup input device */
input->name = "TWL4030 Keypad";
@@ -370,6 +360,38 @@ static int twl4030_kp_probe(struct platform_device *pdev)
input->id.product = 0x0001;
input->id.version = 0x0003;
+ if (pdata) {
+ if (!pdata->rows || !pdata->cols || !pdata->keymap_data) {
+ dev_err(&pdev->dev, "Missing platform_data\n");
+ error = -EINVAL;
+ goto err1;
+ }
+
+ kp->n_rows = pdata->rows;
+ kp->n_cols = pdata->cols;
+ kp->autorepeat = pdata->rep;
+ keymap_data = pdata->keymap_data;
+ } else {
+ error = matrix_keypad_parse_of_params(&pdev->dev, &kp->n_rows,
+ &kp->n_cols);
+ kp->autorepeat = true;
+ if (error)
+ goto err1;
+ }
+
+ if (kp->n_rows > TWL4030_MAX_ROWS || kp->n_cols > TWL4030_MAX_COLS) {
+ dev_err(&pdev->dev, "Invalid rows/cols amount specified in platform/devicetree data\n");
+ error = -EINVAL;
+ goto err1;
+ }
+
+ kp->irq = platform_get_irq(pdev, 0);
+ if (!kp->irq) {
+ dev_err(&pdev->dev, "no keyboard irq assigned\n");
+ error = -EINVAL;
+ goto err1;
+ }
+
error = matrix_keypad_build_keymap(keymap_data, NULL,
TWL4030_MAX_ROWS,
1 << TWL4030_ROW_SHIFT,
@@ -381,7 +403,7 @@ static int twl4030_kp_probe(struct platform_device *pdev)
input_set_capability(input, EV_MSC, MSC_SCAN);
/* Enable auto repeat feature of Linux input subsystem */
- if (pdata->rep)
+ if (kp->autorepeat)
__set_bit(EV_REP, input->evbit);
error = input_register_device(input);
@@ -443,6 +465,14 @@ static int twl4030_kp_remove(struct platform_device *pdev)
return 0;
}
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id twl4030_keypad_dt_match_table[] = {
+ { .compatible = "ti,twl4030-keypad" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, twl4030_keypad_dt_match_table);
+#endif
+
/*
* NOTE: twl4030 are multi-function devices connected via I2C.
* So this device is a child of an I2C parent, thus it needs to
@@ -455,6 +485,7 @@ static struct platform_driver twl4030_kp_driver = {
.driver = {
.name = "twl4030_keypad",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_keypad_dt_match_table),
},
};
module_platform_driver(twl4030_kp_driver);
--
1.8.4.3
^ permalink raw reply related
* Re: [PATCH 1/2] HID: hid-sensor-hub: Add logical min and max
From: Jonathan Cameron @ 2013-11-30 11:31 UTC (permalink / raw)
To: Srinivas Pandruvada, jkosina-AlSwsSmVLrQ
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1385590783-27604-1-git-send-email-srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/27/13 22:19, Srinivas Pandruvada wrote:
> Exporting logical minimum and maximum of HID fields as part of the
> hid sensor attribute info. This can be used for range checking and
> to calculate enumeration base for NAry fields of HID sensor hub.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Hi, I would have preffred this being done in two patches, the first
refactoring the function call and the second doing the min and max.
Anyhow, I'll take it anyway.
Applied to the togreg branch of iio.git.
> ---
> drivers/hid/hid-sensor-hub.c | 20 ++++++++------------
> include/linux/hid-sensor-hub.h | 2 ++
> 2 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index a184e19..d87f7cb 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -112,13 +112,15 @@ static int sensor_hub_get_physical_device_count(
>
> static void sensor_hub_fill_attr_info(
> struct hid_sensor_hub_attribute_info *info,
> - s32 index, s32 report_id, s32 units, s32 unit_expo, s32 size)
> + s32 index, s32 report_id, struct hid_field *field)
> {
> info->index = index;
> info->report_id = report_id;
> - info->units = units;
> - info->unit_expo = unit_expo;
> - info->size = size/8;
> + info->units = field->unit;
> + info->unit_expo = field->unit_exponent;
> + info->size = (field->report_size * field->report_count)/8;
> + info->logical_minimum = field->logical_minimum;
> + info->logical_maximum = field->logical_maximum;
> }
>
> static struct hid_sensor_hub_callbacks *sensor_hub_get_callback(
> @@ -325,9 +327,7 @@ int sensor_hub_input_get_attribute_info(struct hid_sensor_hub_device *hsdev,
> if (field->physical == usage_id &&
> field->logical == attr_usage_id) {
> sensor_hub_fill_attr_info(info, i, report->id,
> - field->unit, field->unit_exponent,
> - field->report_size *
> - field->report_count);
> + field);
> ret = 0;
> } else {
> for (j = 0; j < field->maxusage; ++j) {
> @@ -336,11 +336,7 @@ int sensor_hub_input_get_attribute_info(struct hid_sensor_hub_device *hsdev,
> field->usage[j].collection_index ==
> collection_index) {
> sensor_hub_fill_attr_info(info,
> - i, report->id,
> - field->unit,
> - field->unit_exponent,
> - field->report_size *
> - field->report_count);
> + i, report->id, field);
> ret = 0;
> break;
> }
> diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
> index a265af2..fd66e45 100644
> --- a/include/linux/hid-sensor-hub.h
> +++ b/include/linux/hid-sensor-hub.h
> @@ -40,6 +40,8 @@ struct hid_sensor_hub_attribute_info {
> s32 units;
> s32 unit_expo;
> s32 size;
> + s32 logical_minimum;
> + s32 logical_maximum;
> };
>
> /**
>
^ permalink raw reply
* Re: [PATCH 2/2] iio: hid-sensors: Fix power and report state
From: Jonathan Cameron @ 2013-11-30 11:28 UTC (permalink / raw)
To: Srinivas Pandruvada, jkosina-AlSwsSmVLrQ
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Greg KH
In-Reply-To: <1385590783-27604-2-git-send-email-srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/27/13 22:19, Srinivas Pandruvada wrote:
> In the original HID sensor hub firmwares all Named array enums were
> to 0-based. But the most recent hub implemented as 1-based,
> because of the implementation by one of the major OS vendor.
> Using logical minimum for the field as the base of enum. So we add
> logical minimum to the selector values before setting those fields.
> Some sensor hub FWs already changed logical minimum from 0 to 1
> to reflect this and hope every other vendor will follow.
> There is no easy way to add a common HID quirk for NAry elements,
> even if the standard specifies these field as NAry, the collection
> used to describe selectors is still just "logical".
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Looks like a good solution to me.
This one is a little interesting. Technically I 'believe' we don't have
a bug as it is possible to make these devices work via the kconfig option
and it definitely isn't a regression. As such I have applied this to the
branch intended for the next kernel cycled (togreg) rather than to the
fixes branch.
If people have a very strong feeling about this then shout reasonably quickly - I'll
probably hold off sending that branch to Greg for a few days anyway.
I've cc'd GregKH to see if he has any input on the path this should take.
Jonathan
> ---
> drivers/iio/common/hid-sensors/Kconfig | 9 ---------
> drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 20 +++++++++++++++-----
> include/linux/hid-sensor-ids.h | 12 ++++++++++++
> 3 files changed, 27 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/iio/common/hid-sensors/Kconfig b/drivers/iio/common/hid-sensors/Kconfig
> index 1178121..39188b7 100644
> --- a/drivers/iio/common/hid-sensors/Kconfig
> +++ b/drivers/iio/common/hid-sensors/Kconfig
> @@ -25,13 +25,4 @@ config HID_SENSOR_IIO_TRIGGER
> If this driver is compiled as a module, it will be named
> hid-sensor-trigger.
>
> -config HID_SENSOR_ENUM_BASE_QUIRKS
> - bool "ENUM base quirks for HID Sensor IIO drivers"
> - depends on HID_SENSOR_IIO_COMMON
> - help
> - Say yes here to build support for sensor hub FW using
> - enumeration, which is using 1 as base instead of 0.
> - Since logical minimum is still set 0 instead of 1,
> - there is no easy way to differentiate.
> -
> endmenu
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index b6e77e0..781d3fa 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -33,24 +33,34 @@ static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
> {
> struct hid_sensor_common *st = iio_trigger_get_drvdata(trig);
> int state_val;
> + int report_val;
>
> if (state) {
> if (sensor_hub_device_open(st->hsdev))
> return -EIO;
> - } else
> + state_val =
> + HID_USAGE_SENSOR_PROP_POWER_STATE_D0_FULL_POWER_ENUM;
> + report_val =
> + HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM;
> +
> + } else {
> sensor_hub_device_close(st->hsdev);
> + state_val =
> + HID_USAGE_SENSOR_PROP_POWER_STATE_D4_POWER_OFF_ENUM;
> + report_val =
> + HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM;
> + }
>
> - state_val = state ? 1 : 0;
> - if (IS_ENABLED(CONFIG_HID_SENSOR_ENUM_BASE_QUIRKS))
> - ++state_val;
> st->data_ready = state;
> + state_val += st->power_state.logical_minimum;
> + report_val += st->report_state.logical_minimum;
> sensor_hub_set_feature(st->hsdev, st->power_state.report_id,
> st->power_state.index,
> (s32)state_val);
>
> sensor_hub_set_feature(st->hsdev, st->report_state.report_id,
> st->report_state.index,
> - (s32)state_val);
> + (s32)report_val);
>
> return 0;
> }
> diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
> index 4f945d3..8323775 100644
> --- a/include/linux/hid-sensor-ids.h
> +++ b/include/linux/hid-sensor-ids.h
> @@ -117,4 +117,16 @@
> #define HID_USAGE_SENSOR_PROP_REPORT_STATE 0x200316
> #define HID_USAGE_SENSOR_PROY_POWER_STATE 0x200319
>
> +/* Power state enumerations */
> +#define HID_USAGE_SENSOR_PROP_POWER_STATE_UNDEFINED_ENUM 0x00
> +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D0_FULL_POWER_ENUM 0x01
> +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D1_LOW_POWER_ENUM 0x02
> +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D2_STANDBY_WITH_WAKE_ENUM 0x03
> +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D3_SLEEP_WITH_WAKE_ENUM 0x04
> +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D4_POWER_OFF_ENUM 0x05
> +
> +/* Report State enumerations */
> +#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM 0x00
> +#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x01
> +
> #endif
>
^ permalink raw reply
* [PATCH] hid: add NOGET quirk and device id for Logitech Dual Action gamepads support
From: Zawullon @ 2013-11-30 9:51 UTC (permalink / raw)
To: jkosina; +Cc: linux-input, linux-kernel
Issue description: I have two Logitech Dual Action gamepads, both have
same Vendor/Device id pair. Newest gamepad (A) can switch between old mode (HID)
and XBox gamepad emulation mode. Old gamepad (B) can only work in HID mode.
In HID mode gamepad A sends many EPIPE errors during initialization and was
disconnected immediately after connect to usb port. It works fine in Win and
Mac. After adding NOGET quirk in driver, it was working properly.
Gamepad B works fine before and after changes. I tested both gamepads
with 3.8.0 and 3.11.6 kernels with modified driver. Follow patch can apply
for current git kernel version. I can send pcap log from usb bus with both
gamepads or any other additional information if it is needed
diff -uprN -X linux-git/Documentation/dontdiff linux-git/drivers/hid/hid-ids.h linux-my/drivers/hid/hid-ids.h
--- linux-git/drivers/hid/hid-ids.h 2013-11-30 13:29:27.937351968 +0400
+++ linux-my/drivers/hid/hid-ids.h 2013-11-30 13:46:05.201378674 +0400
@@ -552,6 +552,7 @@
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD 0xc20a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD 0xc211
#define USB_DEVICE_ID_LOGITECH_EXTREME_3D 0xc215
+#define USB_DEVICE_ID_LOGITECH_DUAL_ACTION 0xc216
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2 0xc218
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2_2 0xc219
#define USB_DEVICE_ID_LOGITECH_WINGMAN_F3D 0xc283
diff -uprN -X linux-git/Documentation/dontdiff linux-git/drivers/hid/hid-lg.c linux-my/drivers/hid/hid-lg.c
--- linux-git/drivers/hid/hid-lg.c 2013-11-30 13:29:27.937351968 +0400
+++ linux-my/drivers/hid/hid-lg.c 2013-11-30 13:46:05.201378674 +0400
@@ -758,6 +758,8 @@ static const struct hid_device_id lg_dev
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_EXTREME_3D),
.driver_data = LG_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DUAL_ACTION),
+ .driver_data = LG_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WHEEL),
.driver_data = LG_NOGET | LG_FF4 },
^ permalink raw reply
* Re: [Patch] Fix for so that recent Elantech touchpads are recognized as such
From: Hauke Mehrtens @ 2013-11-29 21:26 UTC (permalink / raw)
To: Matt Walker
Cc: backports-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+X2d=AuAm3ENDbrfk7L5fXoSiLwVU5xxKVo+MbbCf_aWu=cyg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/29/2013 01:00 AM, Matt Walker wrote:
> Hello,
>
> Attached is a patch for drivers/input/mouse/elantech.c. It allows
> recent Elantech touchpads to be detected. I have tested it on the
> touchpad that comes with the Acer Aspire S7-392 (released ~August
> 2013)
>
> I figure it could be backported with little effort and no danger,
> since all it does it add one to the number of values that were
> previously recognized as valid "firmware version numbers".
>
> Begin Patch:
> 1315a1316
>> case 8:
> End Patch
>
> Best,
> Matt
>
This is not a patch, I do not know what you want to do.
This is the documentation for hacking on backprts:
https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking
This is the guideline for patch submission to the linux kernel which
mostly also applies for backports:
https://www.kernel.org/doc/Documentation/SubmittingPatches
Hauke
^ permalink raw reply
* Re: [PATCH] Input: gpio_keys - add ack_irq callback for HW that needs ACK
From: Rafał Miłecki @ 2013-11-29 14:57 UTC (permalink / raw)
To: linux-input, Jiri Kosina; +Cc: Hauke Mehrtens
In-Reply-To: <1385650800-8908-1-git-send-email-zajec5@gmail.com>
2013/11/28 Rafał Miłecki <zajec5@gmail.com>:
> On bcm47xx arch we have GPIO keys with interrupts, but after every IRQ
> we have to change GPIO interrupt polarity. This is necessary to stop
> hardware from generating IRQs all the time and set it into state that
> will generate another IRQ on button release.
> This is not exactly an ACK, but I think it makes sense to use this more
> generic name.
> With this patch we can easily implement GPIO keys support for bcm47xx
> just using gpio_keys.
I think I missed quite important kernel feature: irq_domain... I'll
just try to use it.
Please ignore this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 26/31] Input: tegra-kbc - use reset framework
From: Thierry Reding @ 2013-11-29 14:50 UTC (permalink / raw)
To: Stephen Warren
Cc: Stephen Warren, treding-DDmLM1+adcrQT0dZR+AlfA,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Dmitry Torokhov, Dmitry Torokhov,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1384548866-13141-27-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
On Fri, Nov 15, 2013 at 01:54:21PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Tegra's clock driver now provides an implementation of the common
> reset API (include/linux/reset.h). Use this instead of the old Tegra-
> specific API; that will soon be removed.
>
> Cc: treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
> Cc: pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
> Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Dmitry Torokhov <dtor-JGs/UdohzUI@public.gmane.org>
> Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> This patch is part of a series with strong internal depdendencies. I'm
> looking for an ack so that I can take the entire series through the Tegra
> and arm-soc trees. The series will be part of a stable branch that can be
> merged into other subsystems if needed to avoid/resolve dependencies.
> ---
> drivers/input/keyboard/tegra-kbc.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
Reviewed-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [Patch] Fix for so that recent Elantech touchpads are recognized as such
From: Matt Walker @ 2013-11-29 0:00 UTC (permalink / raw)
To: backports, linux-input
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Hello,
Attached is a patch for drivers/input/mouse/elantech.c. It allows
recent Elantech touchpads to be detected. I have tested it on the
touchpad that comes with the Acer Aspire S7-392 (released ~August
2013)
I figure it could be backported with little effort and no danger,
since all it does it add one to the number of values that were
previously recognized as valid "firmware version numbers".
Begin Patch:
1315a1316
> case 8:
End Patch
Best,
Matt
[-- Attachment #2: elantech.patch --]
[-- Type: text/x-patch, Size: 22 bytes --]
1315a1316
> case 8:
^ permalink raw reply
* [PATCH] Input: define KEY_WWAN for Wireless WAN
From: Rafał Miłecki @ 2013-11-28 18:42 UTC (permalink / raw)
To: linux-input, Jiri Kosina; +Cc: Hauke Mehrtens, Rafał Miłecki
Some devices with support for mobile networks may have buttons for
enabling/disabling such connection. An example can be Linksys router
54G3G.
We already have KEY_BLUETOOTH, KEY_WLAN and KEY_UWB so it makes sense
to add KEY_WWAN as well.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
include/uapi/linux/input.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 4649ee3..173d77f 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -749,6 +749,8 @@ struct input_keymap_entry {
#define BTN_TRIGGER_HAPPY39 0x2e6
#define BTN_TRIGGER_HAPPY40 0x2e7
+#define KEY_WWAN 0x2e8 /* Wireless WAN (LTE, UMTS, GSM, etc.) */
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] Input: gpio_keys - add ack_irq callback for HW that needs ACK
From: Rafał Miłecki @ 2013-11-28 15:26 UTC (permalink / raw)
To: linux-input, Jiri Kosina; +Cc: Hauke Mehrtens
In-Reply-To: <1385650800-8908-1-git-send-email-zajec5@gmail.com>
2013/11/28 Rafał Miłecki <zajec5@gmail.com>:
> On bcm47xx arch we have GPIO keys with interrupts, but after every IRQ
> we have to change GPIO interrupt polarity. This is necessary to stop
> hardware from generating IRQs all the time and set it into state that
> will generate another IRQ on button release.
> This is not exactly an ACK, but I think it makes sense to use this more
> generic name.
> With this patch we can easily implement GPIO keys support for bcm47xx
> just using gpio_keys.
Example usage:
http://www.linux-mips.org/archives/linux-mips/2013-11/msg00163.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Input: gpio_keys - add ack_irq callback for HW that needs ACK
From: Rafał Miłecki @ 2013-11-28 15:00 UTC (permalink / raw)
To: linux-input, Jiri Kosina; +Cc: Hauke Mehrtens, Rafał Miłecki
On bcm47xx arch we have GPIO keys with interrupts, but after every IRQ
we have to change GPIO interrupt polarity. This is necessary to stop
hardware from generating IRQs all the time and set it into state that
will generate another IRQ on button release.
This is not exactly an ACK, but I think it makes sense to use this more
generic name.
With this patch we can easily implement GPIO keys support for bcm47xx
just using gpio_keys.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
This change to gpio_keys was proposed as an alternative to
re-implementing most of the gpio_keys code in arch tree, see patch:
MIPS: BCM47XX: Prepare support for GPIO buttons
http://www.linux-mips.org/archives/linux-mips/2013-11/msg00160.html
Please let me know if this is acceptable change for you.
---
drivers/input/keyboard/gpio_keys.c | 2 ++
include/linux/gpio_keys.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index b29ca65..c6e41be 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -362,6 +362,8 @@ static irqreturn_t gpio_keys_gpio_isr(int irq, void *dev_id)
BUG_ON(irq != bdata->irq);
+ if (bdata->button->ack_irq)
+ bdata->button->ack_irq(bdata->button);
if (bdata->button->wakeup)
pm_stay_awake(bdata->input->dev.parent);
if (bdata->timer_debounce)
diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
index a7e977f..3c4244e 100644
--- a/include/linux/gpio_keys.h
+++ b/include/linux/gpio_keys.h
@@ -15,6 +15,7 @@ struct gpio_keys_button {
bool can_disable;
int value; /* axis value for EV_ABS */
unsigned int irq; /* Irq number in case of interrupt keys */
+ void (*ack_irq)(const struct gpio_keys_button *button);
};
struct gpio_keys_platform_data {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
From: Bastien Nocera @ 2013-11-28 14:14 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Hauke Mehrtens, linux-input, Jiri Kosina
In-Reply-To: <CACna6ry8gE28ke=yNgO1OC_ahzcN0EStfpDhFoFL9+N_yddpHg@mail.gmail.com>
On Thu, 2013-11-28 at 15:06 +0100, Rafał Miłecki wrote:
> 2013/11/28 Bastien Nocera <hadess@hadess.net>:
> > On Thu, 2013-11-28 at 13:32 +0100, Rafał Miłecki wrote:
> >> I'm just not sure about possible scenarios. I imagined end-user
> >> pressing SES button router and SES button on a device and complaining
> >> it's not working (because of SES being interpreted as WPS).
> >>
> >> If you guys think we should just use WPS for the SES button, I'm OK with that.
> >
> > Isn't the fact that it returns WPS or SES an implementation detail?
> >
> > Is WPS vs. SES just a software choice, or a hardware one? If it's a
> > hardware one, you'd expect to have other ways to discover whether SES or
> > WPS was requested (because that's the one supported by the hardware). If
> > it's a software choice, then you'd expect the button to one or the other
> > based on the software stack.
> >
> > Or are both possible at the same time, and there are devices with both
> > buttons?
> >
> > Seems that adding a note that other similar "pairing" methods for Wi-Fi
> > could be triggered when the button is used, in input.h would be enough.
>
> I think it's just a software thing (some EAP messages probably).
>
> Thanks for your comments!
>
> What about KEY_WWAN. Does it make sense to add it?
If there are "keys" with that sort of label, it would make sense to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
From: Rafał Miłecki @ 2013-11-28 14:06 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Hauke Mehrtens, linux-input, Jiri Kosina
In-Reply-To: <1385643706.17991.9.camel@nuvo>
2013/11/28 Bastien Nocera <hadess@hadess.net>:
> On Thu, 2013-11-28 at 13:32 +0100, Rafał Miłecki wrote:
>> I'm just not sure about possible scenarios. I imagined end-user
>> pressing SES button router and SES button on a device and complaining
>> it's not working (because of SES being interpreted as WPS).
>>
>> If you guys think we should just use WPS for the SES button, I'm OK with that.
>
> Isn't the fact that it returns WPS or SES an implementation detail?
>
> Is WPS vs. SES just a software choice, or a hardware one? If it's a
> hardware one, you'd expect to have other ways to discover whether SES or
> WPS was requested (because that's the one supported by the hardware). If
> it's a software choice, then you'd expect the button to one or the other
> based on the software stack.
>
> Or are both possible at the same time, and there are devices with both
> buttons?
>
> Seems that adding a note that other similar "pairing" methods for Wi-Fi
> could be triggered when the button is used, in input.h would be enough.
I think it's just a software thing (some EAP messages probably).
Thanks for your comments!
What about KEY_WWAN. Does it make sense to add it?
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
From: Bastien Nocera @ 2013-11-28 13:01 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Hauke Mehrtens, linux-input, Jiri Kosina
In-Reply-To: <CACna6rz58KybJ4dMPWUwXzR6QkQXnkdu_5zvQWteBaepikS0UA@mail.gmail.com>
On Thu, 2013-11-28 at 13:32 +0100, Rafał Miłecki wrote:
> 2013/11/28 Hauke Mehrtens <hauke@hauke-m.de>:
> > On 11/28/2013 12:48 PM, Rafał Miłecki wrote:
> >> This is just a RFC, so be nice to this "patch", please ;)
> >>
> >> My goal is to add support for buttons on bcm47xx arch. However after
> >> analyzing existing database of devices I realized I don't know what code
> >> I should assign to some buttons.
> >>
> >> First of all, older routers often have a "SES" button. SES stands for
> >> SecureEasySetup and is Broadcom's proprietary protocol which was later
> >> replaced with WPS (Wi-Fi Protected Setup).
> >> Btw. WPS appeared to be broken because it's easy to attack it with
> >> brutal-force method.
> >
> > Only a badly implemented WPS pin authentication is vulnerable to the
> > brute force attack, as far as I know.
>
> Oh, indeed, I missed that. Thanks!
>
> >> I'm not sure if any distribution have any interest
> >> in using that buttons, but it still would be nice to have support for
> >> them in kernel. One option is to add KEY_SES for this purpose.
> >> Is this the right way? It's similar to the KEY_WPS_BUTTON, but I wanted
> >> to somehow distinct them. Is there any other option? Should I use
> >> KEY_UNKNOWN or BTN_MISC or BTN_n?
> >
> > I do not think you or someone else plans to implement SecureEasySetup on
> > a device running current Linux kernel, why not use the WPS button key
> > for for these button. If someone wants to implement this just use the
> > WPS button key for that.
>
> I'm just not sure about possible scenarios. I imagined end-user
> pressing SES button router and SES button on a device and complaining
> it's not working (because of SES being interpreted as WPS).
>
> If you guys think we should just use WPS for the SES button, I'm OK with that.
Isn't the fact that it returns WPS or SES an implementation detail?
Is WPS vs. SES just a software choice, or a hardware one? If it's a
hardware one, you'd expect to have other ways to discover whether SES or
WPS was requested (because that's the one supported by the hardware). If
it's a software choice, then you'd expect the button to one or the other
based on the software stack.
Or are both possible at the same time, and there are devices with both
buttons?
Seems that adding a note that other similar "pairing" methods for Wi-Fi
could be triggered when the button is used, in input.h would be enough.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
From: Rafał Miłecki @ 2013-11-28 12:32 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-input, Jiri Kosina
In-Reply-To: <529731CB.3010107@hauke-m.de>
2013/11/28 Hauke Mehrtens <hauke@hauke-m.de>:
> On 11/28/2013 12:48 PM, Rafał Miłecki wrote:
>> This is just a RFC, so be nice to this "patch", please ;)
>>
>> My goal is to add support for buttons on bcm47xx arch. However after
>> analyzing existing database of devices I realized I don't know what code
>> I should assign to some buttons.
>>
>> First of all, older routers often have a "SES" button. SES stands for
>> SecureEasySetup and is Broadcom's proprietary protocol which was later
>> replaced with WPS (Wi-Fi Protected Setup).
>> Btw. WPS appeared to be broken because it's easy to attack it with
>> brutal-force method.
>
> Only a badly implemented WPS pin authentication is vulnerable to the
> brute force attack, as far as I know.
Oh, indeed, I missed that. Thanks!
>> I'm not sure if any distribution have any interest
>> in using that buttons, but it still would be nice to have support for
>> them in kernel. One option is to add KEY_SES for this purpose.
>> Is this the right way? It's similar to the KEY_WPS_BUTTON, but I wanted
>> to somehow distinct them. Is there any other option? Should I use
>> KEY_UNKNOWN or BTN_MISC or BTN_n?
>
> I do not think you or someone else plans to implement SecureEasySetup on
> a device running current Linux kernel, why not use the WPS button key
> for for these button. If someone wants to implement this just use the
> WPS button key for that.
I'm just not sure about possible scenarios. I imagined end-user
pressing SES button router and SES button on a device and complaining
it's not working (because of SES being interpreted as WPS).
If you guys think we should just use WPS for the SES button, I'm OK with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
From: Hauke Mehrtens @ 2013-11-28 12:06 UTC (permalink / raw)
To: Rafał Miłecki, linux-input, Jiri Kosina
In-Reply-To: <1385639293-23225-1-git-send-email-zajec5@gmail.com>
On 11/28/2013 12:48 PM, Rafał Miłecki wrote:
> This is just a RFC, so be nice to this "patch", please ;)
>
> My goal is to add support for buttons on bcm47xx arch. However after
> analyzing existing database of devices I realized I don't know what code
> I should assign to some buttons.
>
> First of all, older routers often have a "SES" button. SES stands for
> SecureEasySetup and is Broadcom's proprietary protocol which was later
> replaced with WPS (Wi-Fi Protected Setup).
> Btw. WPS appeared to be broken because it's easy to attack it with
> brutal-force method.
Only a badly implemented WPS pin authentication is vulnerable to the
brute force attack, as far as I know.
> I'm not sure if any distribution have any interest
> in using that buttons, but it still would be nice to have support for
> them in kernel. One option is to add KEY_SES for this purpose.
> Is this the right way? It's similar to the KEY_WPS_BUTTON, but I wanted
> to somehow distinct them. Is there any other option? Should I use
> KEY_UNKNOWN or BTN_MISC or BTN_n?
I do not think you or someone else plans to implement SecureEasySetup on
a device running current Linux kernel, why not use the WPS button key
for for these button. If someone wants to implement this just use the
WPS button key for that.
> Another thing is WWAN key. Some routers support mobile networks (for
> example Linksys 54G3G) and they may have button for enabling/disabling
> such connection. We already have KEY_BLUETOOTH, KEY_WLAN and KEY_UWB,
> but nothing for WWAN device control. I guess in future KEY_WWAN could
> be also supported in rfkill by mapping it to the RFKILL_TYPE_WWAN.
>
> What do you think about this?
> ---
> include/uapi/linux/input.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index 4649ee3..a06c8bf 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -749,6 +749,9 @@ struct input_keymap_entry {
> #define BTN_TRIGGER_HAPPY39 0x2e6
> #define BTN_TRIGGER_HAPPY40 0x2e7
>
> +#define KEY_WWAN 0x2e8 /* Wireless WAN (LTE, UMTS, GSM, etc.) */
> +#define KEY_SES 0x2e9 /* SecureEasySetup */
> +
> /* We avoid low common keys in module aliases so they don't get huge. */
> #define KEY_MIN_INTERESTING KEY_MUTE
> #define KEY_MAX 0x2ff
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC][PATCH] Input: define keys for WWAN and SES
From: Rafał Miłecki @ 2013-11-28 11:48 UTC (permalink / raw)
To: linux-input, Jiri Kosina; +Cc: Hauke Mehrtens, Rafał Miłecki
This is just a RFC, so be nice to this "patch", please ;)
My goal is to add support for buttons on bcm47xx arch. However after
analyzing existing database of devices I realized I don't know what code
I should assign to some buttons.
First of all, older routers often have a "SES" button. SES stands for
SecureEasySetup and is Broadcom's proprietary protocol which was later
replaced with WPS (Wi-Fi Protected Setup).
Btw. WPS appeared to be broken because it's easy to attack it with
brutal-force method. I'm not sure if any distribution have any interest
in using that buttons, but it still would be nice to have support for
them in kernel. One option is to add KEY_SES for this purpose.
Is this the right way? It's similar to the KEY_WPS_BUTTON, but I wanted
to somehow distinct them. Is there any other option? Should I use
KEY_UNKNOWN or BTN_MISC or BTN_n?
Another thing is WWAN key. Some routers support mobile networks (for
example Linksys 54G3G) and they may have button for enabling/disabling
such connection. We already have KEY_BLUETOOTH, KEY_WLAN and KEY_UWB,
but nothing for WWAN device control. I guess in future KEY_WWAN could
be also supported in rfkill by mapping it to the RFKILL_TYPE_WWAN.
What do you think about this?
---
include/uapi/linux/input.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 4649ee3..a06c8bf 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -749,6 +749,9 @@ struct input_keymap_entry {
#define BTN_TRIGGER_HAPPY39 0x2e6
#define BTN_TRIGGER_HAPPY40 0x2e7
+#define KEY_WWAN 0x2e8 /* Wireless WAN (LTE, UMTS, GSM, etc.) */
+#define KEY_SES 0x2e9 /* SecureEasySetup */
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 02/15] input: sh_keysc: Restrict non-COMPILE_TEST compilation
From: Simon Horman @ 2013-11-28 7:36 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-sh, linux-arm-kernel, Dmitry Torokhov, linux-input
In-Reply-To: <1385515117-23664-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Wed, Nov 27, 2013 at 02:18:24AM +0100, Laurent Pinchart wrote:
> Hardware supported by the driver is only found on SUPERH or
> ARCH_SHMOBILE platforms. Restrict non-COMPILE_TEST compilation to them.
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input@vger.kernel.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/input/keyboard/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index bb174c1..a673c9f 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -525,7 +525,7 @@ config KEYBOARD_SUNKBD
>
> config KEYBOARD_SH_KEYSC
> tristate "SuperH KEYSC keypad support"
> - depends on SUPERH || ARM || COMPILE_TEST
> + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> help
> Say Y here if you want to use a keypad attached to the KEYSC block
> on SuperH processors such as sh7722 and sh7343.
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 3/3] Input: pcips2 - use DEFINE_PCI_DEVICE_TABLE macro
From: Dmitry Torokhov @ 2013-11-28 7:35 UTC (permalink / raw)
To: Jingoo Han; +Cc: linux-input
In-Reply-To: <005001ceebf2$da2da300$8e88e900$%han@samsung.com>
On Thu, Nov 28, 2013 at 01:32:31PM +0900, Jingoo Han wrote:
> On Thursday, November 28, 2013 12:57 PM, Dmitry Torokhov wrote:
> > On Thu, Nov 28, 2013 at 11:21:12AM +0900, Jingoo Han wrote:
> > > This macro is used to create a struct pci_device_id array.
> >
> > Applied all 3, thank you.
>
> Please, drop these patches.
> According to the Greg Kroah-Hartman,
>
> "Yeah, and it's a horrid macro that deserves to be removed, please don't
> use it in more places.
>
> Actually, if you could just remove it, that would be best, sorry, I'm
> not going to take these patches."
>
> So, I will send the patch to remove 'DEFINE_PCI_DEVICE_TABLE' instead.
> Sorry for annoying. :-)
No worries, I dropped them.
Thanks.
--
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox