* RE: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
From: Stephen Warren @ 2014-07-01 16:14 UTC (permalink / raw)
To: Sekhar Nori, Nick Dyer
Cc: linux-input@vger.kernel.org, Linux OMAP List, Dmitry Torokhov,
swarren@wwwdotorg.org
In-Reply-To: <53B284AE.3070302@ti.com>
Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM:
> Nick,
>
> I have been using your for-next branch to base my development of
> touchscreen support on TI's DRA7x EVM. With the recent updates,
> it has worked out great and once I got the configuration right,
> it was just a question of adding DT data for the platform.
>
> Now, there is one problem with Stephen's patch defaulting the irqflags
> to IRQF_TRIGGER_FALLING. The interrupt controller I am using (ARM GIC)
> does not seem to support that and the device fails to probe:
On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
least a valid) choice. That's probably because the Atmel IRQ signal is
routed to our GPIO controller, which is also an IRQ controller, and then
"forwarded" up the chain to the GIC, with the polarity the GIC expects.
If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add
some kind of DT property to configure the polarity of the IRQ output.
> [ 1.932798] genirq: Setting trigger mode 2 for irq 151 failed (gic_set_type+0x0/0xf0)
> [ 1.941340] atmel_mxt_ts 0-004a: Failed to register interrupt
> [ 1.947452] atmel_mxt_ts: probe of 0-004a failed with error -22
>
> Attached patch does the trick for me:
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 71154c2..f2d3f72 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -3155,9 +3155,6 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> pdata->gpio_reset = of_get_named_gpio_flags(dev->of_node,
> "atmel,reset-gpio", 0, NULL);
>
> - /* Default to this. Properties can be added to configure it later */
> - pdata->irqflags = IRQF_TRIGGER_FALLING;
> -
> of_property_read_string(dev->of_node, "atmel,cfg_name",
> &pdata->cfg_name);
>
> Can you switch to leaving the platform to specify flags (at least for the DT case)?
>
> Thanks,
> Sekhar
--
nvpublic
^ permalink raw reply
* [PATCH 2/2 v4] HID: leds: move led_mode attribute to led-class devices in MSI GT683R driver
From: Janne Kanniainen @ 2014-07-01 17:50 UTC (permalink / raw)
To: johan
Cc: cooloney, jkosina, greg, bjorn, linux-kernel, linux-leds,
linux-usb, linux-input, Janne Kanniainen
In-Reply-To: <20140630103911.GA2486@localhost>
Move led_mode attribute from HID device to led-class devices and rename it
msi_mode. This will also fix race condition by using attribute-groups.
Signed-off-by: Janne Kanniainen <janne.kanniainen@gmail.com>
---
Changes in v3:
- Style fixes
- Rename sysfs-class-hid-driver-gt683r to sysfs-class-leds-driver-gt683r
Changes in v4:
- Rename sysfs-class-leds-driver-gt683r to sysfs-class-leds-gt683r
- Change "What: " to /sys/class/leds/<led>/gt683r/mode
- Change .name from gt683r_led to gt683r
.../ABI/testing/sysfs-class-hid-driver-gt683r | 14 ----------
Documentation/ABI/testing/sysfs-class-leds-gt683r | 16 ++++++++++++
drivers/hid/hid-gt683r.c | 30 ++++++++++++----------
3 files changed, 33 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
create mode 100644 Documentation/ABI/testing/sysfs-class-leds-gt683r
diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
deleted file mode 100644
index 317e9d5..0000000
--- a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
+++ /dev/null
@@ -1,14 +0,0 @@
-What: /sys/class/hidraw/<hidraw>/device/leds_mode
-Date: Jun 2014
-KernelVersion: 3.17
-Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
-Description:
- Set the mode of LEDs
-
- 0 - normal
- 1 - audio
- 2 - breathing
-
- Normal: LEDs are fully on when enabled
- Audio: LEDs brightness depends on sound level
- Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-class-leds-gt683r b/Documentation/ABI/testing/sysfs-class-leds-gt683r
new file mode 100644
index 0000000..e4fae60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r
@@ -0,0 +1,16 @@
+What: /sys/class/leds/<led>/gt683r/mode
+Date: Jun 2014
+KernelVersion: 3.17
+Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
+Description:
+ Set the mode of LEDs. You should notice that changing the mode
+ of one LED will update the mode of its two sibling devices as
+ well.
+
+ 0 - normal
+ 1 - audio
+ 2 - breathing
+
+ Normal: LEDs are fully on when enabled
+ Audio: LEDs brightness depends on sound level
+ Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
index 073bd80..f743444 100644
--- a/drivers/hid/hid-gt683r.c
+++ b/drivers/hid/hid-gt683r.c
@@ -84,12 +84,13 @@ static void gt683r_brightness_set(struct led_classdev *led_cdev,
}
}
-static ssize_t leds_mode_show(struct device *dev,
+static ssize_t mode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
u8 sysfs_mode;
- struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+ struct hid_device *hdev = container_of(dev->parent,
+ struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
if (led->mode == GT683R_LED_NORMAL)
@@ -102,12 +103,13 @@ static ssize_t leds_mode_show(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%u\n", sysfs_mode);
}
-static ssize_t leds_mode_store(struct device *dev,
+static ssize_t mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
u8 sysfs_mode;
- struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+ struct hid_device *hdev = container_of(dev->parent,
+ struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
@@ -212,7 +214,14 @@ fail:
mutex_unlock(&led->lock);
}
-static DEVICE_ATTR_RW(leds_mode);
+static DEVICE_ATTR_RW(mode);
+
+static struct attribute *gt683r_led_attrs[] = {
+ &dev_attr_mode.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(gt683r_led);
static int gt683r_led_probe(struct hid_device *hdev,
const struct hid_device_id *id)
@@ -261,6 +270,8 @@ static int gt683r_led_probe(struct hid_device *hdev,
led->led_devs[i].name = name;
led->led_devs[i].max_brightness = 1;
led->led_devs[i].brightness_set = gt683r_brightness_set;
+ led->led_devs[i].groups = gt683r_led_groups;
+
ret = led_classdev_register(&hdev->dev, &led->led_devs[i]);
if (ret) {
hid_err(hdev, "could not register led device\n");
@@ -268,12 +279,6 @@ static int gt683r_led_probe(struct hid_device *hdev,
}
}
- ret = device_create_file(&led->hdev->dev, &dev_attr_leds_mode);
- if (ret) {
- hid_err(hdev, "could not make mode attribute file\n");
- goto fail;
- }
-
return 0;
fail:
@@ -288,7 +293,6 @@ static void gt683r_led_remove(struct hid_device *hdev)
int i;
struct gt683r_led *led = hid_get_drvdata(hdev);
- device_remove_file(&hdev->dev, &dev_attr_leds_mode);
for (i = 0; i < GT683R_LED_COUNT; i++)
led_classdev_unregister(&led->led_devs[i]);
flush_work(&led->work);
@@ -298,7 +302,7 @@ static void gt683r_led_remove(struct hid_device *hdev)
static struct hid_driver gt683r_led_driver = {
.probe = gt683r_led_probe,
.remove = gt683r_led_remove,
- .name = "gt683r_led",
+ .name = "gt683r",
.id_table = gt683r_led_id,
};
--
1.9.2
Did you mean like this?
^ permalink raw reply related
* Re: [PATCH 2/2 v2] HID: leds: Use attribute-groups in MSI GT683R driver
From: Janne Kanniainen @ 2014-07-01 17:53 UTC (permalink / raw)
To: Bryan Wu
Cc: Johan Hovold, Jiri Kosina, Greg Kroah-Hartman, Bjørn Mork,
lkml, Linux LED Subsystem, linux-usb, linux-input@vger.kernel.org
In-Reply-To: <CAK5ve-JYjDRfoyTYcc5zRNds-UF=MzK5Jc+31NQYCsEQp5ZHoA@mail.gmail.com>
> Great, I just cherry-picked and applied to my tree
> http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=for-next&id=f471d9480275796dea2ac7ec249b050e70a2888d
>
> Thanks,
> -Bryan
Ok, thank you!
Janne
^ permalink raw reply
* Re: [PATCH 2/2 v4] HID: leds: move led_mode attribute to led-class devices in MSI GT683R driver
From: Johan Hovold @ 2014-07-01 20:16 UTC (permalink / raw)
To: Janne Kanniainen
Cc: johan, cooloney, jkosina, greg, bjorn, linux-kernel, linux-leds,
linux-usb, linux-input
In-Reply-To: <1404237054-12906-1-git-send-email-janne.kanniainen@gmail.com>
On Tue, Jul 01, 2014 at 08:50:54PM +0300, Janne Kanniainen wrote:
> -static DEVICE_ATTR_RW(leds_mode);
> +static DEVICE_ATTR_RW(mode);
> +
> +static struct attribute *gt683r_led_attrs[] = {
> + &dev_attr_mode.attr,
> + NULL
> +};
> +
> +ATTRIBUTE_GROUPS(gt683r_led);
I was referring to the name field of struct attribute_group (and not of
struct hid_driver). Specifically, that means that you cannot use the
ATTRIBUTE_GROUPS macro (which leaves the name field unset), but rather
should define the two corresponding structs directly as follows:
static const struct attribute_group gt683r_led_group = {
.name = "gt683r",
.attrs = gt683r_led_attrs,
};
static const struct attribute_group *gt683r_led_groups[] = {
>683r_led_group,
NULL
};
That way the mode attribute will be created in a subdirectory (named
gt683r) of the led class device.
> static int gt683r_led_probe(struct hid_device *hdev,
> const struct hid_device_id *id)
> @@ -261,6 +270,8 @@ static int gt683r_led_probe(struct hid_device *hdev,
> led->led_devs[i].name = name;
> led->led_devs[i].max_brightness = 1;
> led->led_devs[i].brightness_set = gt683r_brightness_set;
> + led->led_devs[i].groups = gt683r_led_groups;
> +
> ret = led_classdev_register(&hdev->dev, &led->led_devs[i]);
> if (ret) {
> hid_err(hdev, "could not register led device\n");
> @@ -268,12 +279,6 @@ static int gt683r_led_probe(struct hid_device *hdev,
> }
> }
<snip>
> @@ -298,7 +302,7 @@ static void gt683r_led_remove(struct hid_device *hdev)
> static struct hid_driver gt683r_led_driver = {
> .probe = gt683r_led_probe,
> .remove = gt683r_led_remove,
> - .name = "gt683r_led",
> + .name = "gt683r",
So you should skip this bit.
> .id_table = gt683r_led_id,
> };
Johan
^ permalink raw reply
* Re: [PATCH v2] hid-appleir: Fix kernel panic due to null pointer
From: Nick Krause @ 2014-07-01 22:21 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Mateusz Guzik, linux-input, linux-kernel@vger.kernel.org
In-Reply-To: <alpine.LNX.2.00.1407010852160.1655@pobox.suse.cz>
So I am wondering them should I can it to sizeof(appleir_keymap)?
Nick
On Tue, Jul 1, 2014 at 2:55 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Tue, 1 Jul 2014, Mateusz Guzik wrote:
>
>> > > Fixes a null pointer in appleir_input_configured due to reading
>> > > into wrong size array. Changed the variable to input_dev->keycodemax.
>> >
>> > This is a stale changelog from the previous buggy version.
>> >
>> > > Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>> > > ---
>> > > drivers/hid/hid-appleir.c | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/hid/hid-appleir.c b/drivers/hid/hid-appleir.c
>> > > index 0e6a42d..cc02df4 100644
>> > > --- a/drivers/hid/hid-appleir.c
>> > > +++ b/drivers/hid/hid-appleir.c
>> > > @@ -272,7 +272,7 @@ static void appleir_input_configured(struct hid_device *hid,
>> > > input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_REP);
>> > >
>> > > memcpy(appleir->keymap, appleir_key_table, sizeof(appleir->keymap));
>> > > - for (i = 0; i < ARRAY_SIZE(appleir_key_table); i++)
>> > > + for (i = 0; i < appleir->keymap; i++)
>> >
>> > This is wrong. appleir->keymap is an array, and you want to count its
>> > elements.
>> >
>>
>> But where the claim of 'null pointer' is coming from (or reading/writing
>> past the array for that matter)?
>>
>> Replacing appleir_key_table with appleir->keymap is a noop anyway
>> because:
>> unsigned short keymap[ARRAY_SIZE(appleir_key_table)];
>
> It's not really equivalent. ARRAY_SIZE counts the number of short-sized
> elements, sizeof() counts the number of bytes that fit into the data
> structure (which is twice as much, as sizeof(unsigned short) == 2).
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/2 v2] HID: leds: Use attribute-groups in MSI GT683R driver
From: Jiri Kosina @ 2014-07-02 8:56 UTC (permalink / raw)
To: Bryan Wu
Cc: Johan Hovold, Janne Kanniainen, Greg Kroah-Hartman,
Bjørn Mork, lkml, Linux LED Subsystem, linux-usb,
linux-input@vger.kernel.org
In-Reply-To: <CAK5ve-JYjDRfoyTYcc5zRNds-UF=MzK5Jc+31NQYCsEQp5ZHoA@mail.gmail.com>
On Tue, 1 Jul 2014, Bryan Wu wrote:
> Great, I just cherry-picked and applied to my tree
> http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=for-next&id=f471d9480275796dea2ac7ec249b050e70a2888d
Ok, perfect, thanks. I am marking my 'for-3.17/hid-gt683r' so that it
wouldn't be contained in the for-linus merge window pile.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
From: Sekhar Nori @ 2014-07-02 10:49 UTC (permalink / raw)
To: Stephen Warren, Nick Dyer
Cc: linux-input@vger.kernel.org, Linux OMAP List, Dmitry Torokhov,
swarren@wwwdotorg.org
In-Reply-To: <5995217832cc40f5bcf132ac5c6c2546@HQMAIL105.nvidia.com>
On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
> Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM:
>> Nick,
>>
>> I have been using your for-next branch to base my development of
>> touchscreen support on TI's DRA7x EVM. With the recent updates,
>> it has worked out great and once I got the configuration right,
>> it was just a question of adding DT data for the platform.
>>
>> Now, there is one problem with Stephen's patch defaulting the irqflags
>> to IRQF_TRIGGER_FALLING. The interrupt controller I am using (ARM GIC)
>> does not seem to support that and the device fails to probe:
>
> On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
> least a valid) choice. That's probably because the Atmel IRQ signal is
> routed to our GPIO controller, which is also an IRQ controller, and then
> "forwarded" up the chain to the GIC, with the polarity the GIC expects.
>
> If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add
> some kind of DT property to configure the polarity of the IRQ output.
Yeah, I think so too.
Nick,
If you are going to rebase your branch, will you be able to fold in the
patch in my previous e-mail? Else, I can send a more formal patch to you.
Thanks,
Sekhar
^ permalink raw reply
* Re: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
From: Nick Dyer @ 2014-07-02 11:54 UTC (permalink / raw)
To: Sekhar Nori, Stephen Warren
Cc: linux-input@vger.kernel.org, Linux OMAP List, Dmitry Torokhov,
swarren@wwwdotorg.org
In-Reply-To: <53B3E3A8.4070605@ti.com>
On 02/07/14 11:49, Sekhar Nori wrote:
> On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
>> On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
>> least a valid) choice. That's probably because the Atmel IRQ signal is
>> routed to our GPIO controller, which is also an IRQ controller, and then
>> "forwarded" up the chain to the GIC, with the polarity the GIC expects.
>>
>> If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add
>> some kind of DT property to configure the polarity of the IRQ output.
>
> Yeah, I think so too.
>
> Nick,
>
> If you are going to rebase your branch, will you be able to fold in the
> patch in my previous e-mail? Else, I can send a more formal patch to you.
Either IRQF_TRIGGER_FALLING or IRQF_TRIGGER_LOW will work with these chips
(it isn't a question of polarity but whether it's edge- or level-
triggered). There isn't a sensible default. Atmel prefer IRQF_TRIGGER_LOW,
however I've seen some IRQ controllers will revert to a polled mode for
IRQF_TRIGGER_LOW, which kills performance.
So, the sensible course of action seems to be to remove the default
IRQF_TRIGGER_FALLING in the device tree parsing, and provide a device tree
parameter for the flags. If you agree, I will sort this out at my end, you
don't need to send a patch.
I have to leave it in in the case where there is neither static platform
data, or device tree node, because that is used for some systems, but that
shouldn't affect either of you.
BTW, I do have a set of patches ready to send, once this change is made.
cheers
Nick
^ permalink raw reply
* Re: [PATCH] soc_button_array: fix the issue that button device can't be enumerated since 3.16-rc1
From: Zhang Rui @ 2014-07-02 14:01 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: yao.jin, linux-input, Rafael J. Wysocki
In-Reply-To: <1404309504.8366.93.camel@rzhang1-toshiba>
>From c2ee1886ba230d9d93d2ea2f350b1dc1a2d5ead5 Mon Sep 17 00:00:00 2001
From: Jin Yao <yao.jin@linux.intel.com>
Date: Thu, 26 Jun 2014 10:26:44 +0800
Subject: [PATCH] soc_button_array: fix the issue that button device can't be
enumerated since 3.16-rc1
ACPI device enumeration mechanism changed a lot since 3.16-rc1.
ACPI device objects with _HID will be enumerated to platform bus by default.
For the existing PNP drivers that probe the PNPACPI devices, the device ids
are listed explicitly in drivers/acpi/acpi_pnp.c. And ACPI folks will
continue their effort on shrinking this id list by converting the PNP drivers
to platform drivers.
But unfortunately, soc_button_array device id, aka, "PNP0C40", is missing
during this transition.
Thus soc_button_array driver fails to probe any device since 3.16-rc1 because
the device is enumerated to platform bus instead.
A simply fix is to add device id PNP0C40 back to drivers/acpi/acpi_pnp.c,
but given that the soc_button_array driver will be converted to platform
driver sooner or later, and the id will be removed from the list again,
it is better to fix the problem in one time.
This patch fixes the problem by converting the soc_button_driver
from PNP bus to platform bus.
Signed-off-by: Jin Yao <yao.jin@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
drivers/input/misc/soc_button_array.c | 60 ++++++++++++++++++-----------------
1 file changed, 31 insertions(+), 29 deletions(-)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 5a6334b..16ca162 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -18,7 +18,7 @@
#include <linux/gpio/consumer.h>
#include <linux/gpio_keys.h>
#include <linux/platform_device.h>
-#include <linux/pnp.h>
+#include <linux/acpi.h>
/*
* Definition of buttons on the tablet. The ACPI index of each button
@@ -67,7 +67,7 @@ static int soc_button_lookup_gpio(struct device *dev, int acpi_index)
}
static struct platform_device *
-soc_button_device_create(struct pnp_dev *pdev,
+soc_button_device_create(struct platform_device *pdev,
const struct soc_button_info *button_info,
bool autorepeat)
{
@@ -135,30 +135,40 @@ soc_button_device_create(struct pnp_dev *pdev,
return ERR_PTR(error);
}
-static void soc_button_remove(struct pnp_dev *pdev)
+static int soc_button_remove(struct platform_device *pdev)
{
- struct soc_button_data *priv = pnp_get_drvdata(pdev);
+ struct soc_button_data *priv = platform_get_drvdata(pdev);
+
int i;
for (i = 0; i < BUTTON_TYPES; i++)
if (priv->children[i])
platform_device_unregister(priv->children[i]);
+
+ return 0;
}
-static int soc_button_pnp_probe(struct pnp_dev *pdev,
- const struct pnp_device_id *id)
+static int soc_button_probe(struct platform_device *pdev)
{
- const struct soc_button_info *button_info = (void *)id->driver_data;
+ struct device *dev = &pdev->dev;
+ const struct acpi_device_id *id;
+ struct soc_button_info *button_info;
struct soc_button_data *priv;
struct platform_device *pd;
int i;
int error;
+ id = acpi_match_device(dev->driver->acpi_match_table, dev);
+ if (!id)
+ return -ENODEV;
+
+ button_info = (struct soc_button_info *)id->driver_data;
+
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
- pnp_set_drvdata(pdev, priv);
+ platform_set_drvdata(pdev, priv);
for (i = 0; i < BUTTON_TYPES; i++) {
pd = soc_button_device_create(pdev, button_info, i == 0);
@@ -189,30 +199,22 @@ static struct soc_button_info soc_button_PNP0C40[] = {
{ }
};
-static const struct pnp_device_id soc_button_pnp_match[] = {
- { .id = "PNP0C40", .driver_data = (long)soc_button_PNP0C40 },
- { .id = "" }
+static const struct acpi_device_id soc_button_acpi_match[] = {
+ { "PNP0C40", (unsigned long)soc_button_PNP0C40 },
+ { }
};
-MODULE_DEVICE_TABLE(pnp, soc_button_pnp_match);
-static struct pnp_driver soc_button_pnp_driver = {
- .name = KBUILD_MODNAME,
- .id_table = soc_button_pnp_match,
- .probe = soc_button_pnp_probe,
+MODULE_DEVICE_TABLE(acpi, soc_button_acpi_match);
+
+static struct platform_driver soc_button_driver = {
+ .probe = soc_button_probe,
.remove = soc_button_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .owner = THIS_MODULE,
+ .acpi_match_table = ACPI_PTR(soc_button_acpi_match),
+ },
};
-
-static int __init soc_button_init(void)
-{
- return pnp_register_driver(&soc_button_pnp_driver);
-}
-
-static void __exit soc_button_exit(void)
-{
- pnp_unregister_driver(&soc_button_pnp_driver);
-}
-
-module_init(soc_button_init);
-module_exit(soc_button_exit);
+module_platform_driver(soc_button_driver);
MODULE_LICENSE("GPL");
--
1.8.3.2
^ permalink raw reply related
* Re: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
From: Dmitry Torokhov @ 2014-07-02 17:25 UTC (permalink / raw)
To: Nick Dyer
Cc: Sekhar Nori, Stephen Warren, linux-input@vger.kernel.org,
Linux OMAP List, swarren@wwwdotorg.org
In-Reply-To: <53B3F2F2.90707@itdev.co.uk>
On Wed, Jul 2, 2014 at 4:54 AM, Nick Dyer <nick.dyer@itdev.co.uk> wrote:
> On 02/07/14 11:49, Sekhar Nori wrote:
>> On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
>>> On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
>>> least a valid) choice. That's probably because the Atmel IRQ signal is
>>> routed to our GPIO controller, which is also an IRQ controller, and then
>>> "forwarded" up the chain to the GIC, with the polarity the GIC expects.
>>>
>>> If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add
>>> some kind of DT property to configure the polarity of the IRQ output.
>>
>> Yeah, I think so too.
>>
>> Nick,
>>
>> If you are going to rebase your branch, will you be able to fold in the
>> patch in my previous e-mail? Else, I can send a more formal patch to you.
>
> Either IRQF_TRIGGER_FALLING or IRQF_TRIGGER_LOW will work with these chips
> (it isn't a question of polarity but whether it's edge- or level-
> triggered). There isn't a sensible default. Atmel prefer IRQF_TRIGGER_LOW,
> however I've seen some IRQ controllers will revert to a polled mode for
> IRQF_TRIGGER_LOW, which kills performance.
>
> So, the sensible course of action seems to be to remove the default
> IRQF_TRIGGER_FALLING in the device tree parsing, and provide a device tree
> parameter for the flags. If you agree, I will sort this out at my end, you
> don't need to send a patch.
>
> I have to leave it in in the case where there is neither static platform
> data, or device tree node, because that is used for some systems, but that
> shouldn't affect either of you.
In this case board code should take care of setting up the interrupt
properly and the driver should simply use 0 as flags in request_irq().
By the way, doesn't generic DT infrastructure already allow specifying
interrupt triggers and sets them up properly?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 2/2 v5] HID: leds: move led_mode attribute to led-class devices in MSI GT683R driver
From: Janne Kanniainen @ 2014-07-02 17:37 UTC (permalink / raw)
To: johan
Cc: cooloney, jkosina, greg, bjorn, linux-kernel, linux-leds,
linux-usb, linux-input, Janne Kanniainen
In-Reply-To: <20140701201627.GA30605@localhost>
Move led_mode attribute from HID device to led-class devices. This will also fix race condition by using attribute-groups.
Signed-off-by: Janne Kanniainen <janne.kanniainen@gmail.com>
---
Changes in v3:
- Style fixes
- Rename sysfs-class-hid-driver-gt683r to sysfs-class-leds-driver-gt683r
Changes in v4:
- Rename sysfs-class-leds-driver-gt683r to sysfs-class-leds-gt683r
- Change "What: " to /sys/class/leds/<led>/gt683r/mode
- Change .name from gt683r_led to gt683r
Changes in v5:
- Move mode attribute to gt683r/mode
.../ABI/testing/sysfs-class-hid-driver-gt683r | 14 ---------
Documentation/ABI/testing/sysfs-class-leds-gt683r | 16 ++++++++++
drivers/hid/hid-gt683r.c | 36 ++++++++++++++--------
3 files changed, 40 insertions(+), 26 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
create mode 100644 Documentation/ABI/testing/sysfs-class-leds-gt683r
diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
deleted file mode 100644
index 317e9d5..0000000
--- a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
+++ /dev/null
@@ -1,14 +0,0 @@
-What: /sys/class/hidraw/<hidraw>/device/leds_mode
-Date: Jun 2014
-KernelVersion: 3.17
-Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
-Description:
- Set the mode of LEDs
-
- 0 - normal
- 1 - audio
- 2 - breathing
-
- Normal: LEDs are fully on when enabled
- Audio: LEDs brightness depends on sound level
- Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-class-leds-gt683r b/Documentation/ABI/testing/sysfs-class-leds-gt683r
new file mode 100644
index 0000000..e4fae60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r
@@ -0,0 +1,16 @@
+What: /sys/class/leds/<led>/gt683r/mode
+Date: Jun 2014
+KernelVersion: 3.17
+Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
+Description:
+ Set the mode of LEDs. You should notice that changing the mode
+ of one LED will update the mode of its two sibling devices as
+ well.
+
+ 0 - normal
+ 1 - audio
+ 2 - breathing
+
+ Normal: LEDs are fully on when enabled
+ Audio: LEDs brightness depends on sound level
+ Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
index 073bd80..0d6f135 100644
--- a/drivers/hid/hid-gt683r.c
+++ b/drivers/hid/hid-gt683r.c
@@ -84,12 +84,13 @@ static void gt683r_brightness_set(struct led_classdev *led_cdev,
}
}
-static ssize_t leds_mode_show(struct device *dev,
+static ssize_t mode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
u8 sysfs_mode;
- struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+ struct hid_device *hdev = container_of(dev->parent,
+ struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
if (led->mode == GT683R_LED_NORMAL)
@@ -102,12 +103,13 @@ static ssize_t leds_mode_show(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%u\n", sysfs_mode);
}
-static ssize_t leds_mode_store(struct device *dev,
+static ssize_t mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
u8 sysfs_mode;
- struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+ struct hid_device *hdev = container_of(dev->parent,
+ struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
@@ -212,7 +214,22 @@ fail:
mutex_unlock(&led->lock);
}
-static DEVICE_ATTR_RW(leds_mode);
+static DEVICE_ATTR_RW(mode);
+
+static struct attribute *gt683r_led_attrs[] = {
+ &dev_attr_mode.attr,
+ NULL
+};
+
+static const struct attribute_group gt683r_led_group = {
+ .name = "gt683r",
+ .attrs = gt683r_led_attrs,
+};
+
+static const struct attribute_group *gt683r_led_groups[] = {
+ >683r_led_group,
+ NULL
+};
static int gt683r_led_probe(struct hid_device *hdev,
const struct hid_device_id *id)
@@ -261,6 +278,8 @@ static int gt683r_led_probe(struct hid_device *hdev,
led->led_devs[i].name = name;
led->led_devs[i].max_brightness = 1;
led->led_devs[i].brightness_set = gt683r_brightness_set;
+ led->led_devs[i].groups = gt683r_led_groups;
+
ret = led_classdev_register(&hdev->dev, &led->led_devs[i]);
if (ret) {
hid_err(hdev, "could not register led device\n");
@@ -268,12 +287,6 @@ static int gt683r_led_probe(struct hid_device *hdev,
}
}
- ret = device_create_file(&led->hdev->dev, &dev_attr_leds_mode);
- if (ret) {
- hid_err(hdev, "could not make mode attribute file\n");
- goto fail;
- }
-
return 0;
fail:
@@ -288,7 +301,6 @@ static void gt683r_led_remove(struct hid_device *hdev)
int i;
struct gt683r_led *led = hid_get_drvdata(hdev);
- device_remove_file(&hdev->dev, &dev_attr_leds_mode);
for (i = 0; i < GT683R_LED_COUNT; i++)
led_classdev_unregister(&led->led_devs[i]);
flush_work(&led->work);
--
1.9.2
^ permalink raw reply related
* [PATCH] Input - wacom: split out the pad device for the wireless receiver
From: Benjamin Tissoires @ 2014-07-02 21:37 UTC (permalink / raw)
To: Dmitry Torokhov, Ping Cheng, Jason Gerecke; +Cc: linux-input, linux-kernel
The Wireless Receiver should also behave in the same way than regular
USB devices.
To simplify the unregistering of the different devices,
wacom_unregister_inputs() is introduced.
For consistency, the function wacom_register_input() is renamed into
wacom_register_input().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi,
I noticed this afternoon that the "pad-in-a-separate-device" was missing the
conversion for the Wireless Receiver too :(
So here is a fix.
I also have a patch for hid-wacom to behave in the same way regarding the
bluetooth devices. I'll send it once we know a little bit more about how will be
handled wacom.ko in 3.17.
Cheers,
Benjamin
drivers/input/tablet/wacom_sys.c | 46 ++++++++++++++++++++--------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 598efd4..a70aa01 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -1148,7 +1148,17 @@ static struct input_dev *wacom_allocate_input(struct wacom *wacom)
return input_dev;
}
-static int wacom_register_input(struct wacom *wacom)
+static void wacom_unregister_inputs(struct wacom *wacom)
+{
+ if (wacom->wacom_wac.input)
+ input_unregister_device(wacom->wacom_wac.input);
+ if (wacom->wacom_wac.pad_input)
+ input_unregister_device(wacom->wacom_wac.pad_input);
+ wacom->wacom_wac.input = NULL;
+ wacom->wacom_wac.pad_input = NULL;
+}
+
+static int wacom_register_inputs(struct wacom *wacom)
{
struct input_dev *input_dev, *pad_input_dev;
struct wacom_wac *wacom_wac = &(wacom->wacom_wac);
@@ -1220,16 +1230,12 @@ static void wacom_wireless_work(struct work_struct *work)
/* Stylus interface */
wacom1 = usb_get_intfdata(usbdev->config->interface[1]);
wacom_wac1 = &(wacom1->wacom_wac);
- if (wacom_wac1->input)
- input_unregister_device(wacom_wac1->input);
- wacom_wac1->input = NULL;
+ wacom_unregister_inputs(wacom1);
/* Touch interface */
wacom2 = usb_get_intfdata(usbdev->config->interface[2]);
wacom_wac2 = &(wacom2->wacom_wac);
- if (wacom_wac2->input)
- input_unregister_device(wacom_wac2->input);
- wacom_wac2->input = NULL;
+ wacom_unregister_inputs(wacom2);
if (wacom_wac->pid == 0) {
dev_info(&wacom->intf->dev, "wireless tablet disconnected\n");
@@ -1259,9 +1265,11 @@ static void wacom_wireless_work(struct work_struct *work)
wacom_wac1->features.device_type = BTN_TOOL_PEN;
snprintf(wacom_wac1->name, WACOM_NAME_MAX, "%s (WL) Pen",
wacom_wac1->features.name);
+ snprintf(wacom_wac1->pad_name, WACOM_NAME_MAX, "%s (WL) Pad",
+ wacom_wac1->features.name);
wacom_wac1->shared->touch_max = wacom_wac1->features.touch_max;
wacom_wac1->shared->type = wacom_wac1->features.type;
- error = wacom_register_input(wacom1);
+ error = wacom_register_inputs(wacom1);
if (error)
goto fail;
@@ -1279,7 +1287,9 @@ static void wacom_wireless_work(struct work_struct *work)
else
snprintf(wacom_wac2->name, WACOM_NAME_MAX,
"%s (WL) Pad",wacom_wac2->features.name);
- error = wacom_register_input(wacom2);
+ snprintf(wacom_wac2->pad_name, WACOM_NAME_MAX,
+ "%s (WL) Pad", wacom_wac2->features.name);
+ error = wacom_register_inputs(wacom2);
if (error)
goto fail;
@@ -1296,15 +1306,8 @@ static void wacom_wireless_work(struct work_struct *work)
return;
fail:
- if (wacom_wac2->input) {
- input_unregister_device(wacom_wac2->input);
- wacom_wac2->input = NULL;
- }
-
- if (wacom_wac1->input) {
- input_unregister_device(wacom_wac1->input);
- wacom_wac1->input = NULL;
- }
+ wacom_unregister_inputs(wacom1);
+ wacom_unregister_inputs(wacom2);
return;
}
@@ -1450,7 +1453,7 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
goto fail4;
if (!(features->quirks & WACOM_QUIRK_NO_INPUT)) {
- error = wacom_register_input(wacom);
+ error = wacom_register_inputs(wacom);
if (error)
goto fail5;
}
@@ -1490,10 +1493,7 @@ static void wacom_disconnect(struct usb_interface *intf)
usb_kill_urb(wacom->irq);
cancel_work_sync(&wacom->work);
- if (wacom->wacom_wac.input)
- input_unregister_device(wacom->wacom_wac.input);
- if (wacom->wacom_wac.pad_input)
- input_unregister_device(wacom->wacom_wac.pad_input);
+ wacom_unregister_inputs(wacom);
wacom_destroy_battery(wacom);
wacom_destroy_leds(wacom);
usb_free_urb(wacom->irq);
--
2.0.0
^ permalink raw reply related
* Re: [PATCH 15/15] Input - wacom: keep wacom_ids ordered
From: Benjamin Tissoires @ 2014-07-02 21:40 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Jiri Kosina, Ping Cheng, Jason Gerecke,
linux-input, linux-kernel@vger.kernel.org, linuxwacom-devel
In-Reply-To: <1404163586-29582-16-git-send-email-benjamin.tissoires@redhat.com>
On Mon, Jun 30, 2014 at 5:26 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> No Functional changes, just some reordering.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
> drivers/input/tablet/wacom_wac.c | 75 ++++++++++++++++++++--------------------
> 1 file changed, 37 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> index 15b0132..de033d5 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -2418,6 +2418,7 @@ static const struct wacom_features wacom_features_0x0309 =
>
> const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0x00) },
> + { USB_DEVICE_WACOM(0x03) },
> { USB_DEVICE_WACOM(0x10) },
> { USB_DEVICE_WACOM(0x11) },
> { USB_DEVICE_WACOM(0x12) },
> @@ -2428,20 +2429,16 @@ const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0x17) },
> { USB_DEVICE_WACOM(0x18) },
> { USB_DEVICE_WACOM(0x19) },
> - { USB_DEVICE_WACOM(0x60) },
> - { USB_DEVICE_WACOM(0x61) },
> - { USB_DEVICE_WACOM(0x62) },
> - { USB_DEVICE_WACOM(0x63) },
> - { USB_DEVICE_WACOM(0x64) },
> - { USB_DEVICE_WACOM(0x65) },
> - { USB_DEVICE_WACOM(0x69) },
> - { USB_DEVICE_WACOM(0x6A) },
> - { USB_DEVICE_WACOM(0x6B) },
> { USB_DEVICE_WACOM(0x20) },
> { USB_DEVICE_WACOM(0x21) },
> { USB_DEVICE_WACOM(0x22) },
> { USB_DEVICE_WACOM(0x23) },
> { USB_DEVICE_WACOM(0x24) },
> + { USB_DEVICE_WACOM(0x26) },
> + { USB_DEVICE_WACOM(0x27) },
> + { USB_DEVICE_WACOM(0x28) },
> + { USB_DEVICE_WACOM(0x29) },
> + { USB_DEVICE_WACOM(0x2A) },
> { USB_DEVICE_WACOM(0x30) },
> { USB_DEVICE_WACOM(0x31) },
> { USB_DEVICE_WACOM(0x32) },
> @@ -2451,20 +2448,33 @@ const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0x37) },
> { USB_DEVICE_WACOM(0x38) },
> { USB_DEVICE_WACOM(0x39) },
> - { USB_DEVICE_WACOM(0xC4) },
> - { USB_DEVICE_WACOM(0xC0) },
> - { USB_DEVICE_WACOM(0xC2) },
> - { USB_DEVICE_WACOM(0x03) },
> + { USB_DEVICE_WACOM(0x3F) },
> { USB_DEVICE_WACOM(0x41) },
> { USB_DEVICE_WACOM(0x42) },
> { USB_DEVICE_WACOM(0x43) },
> { USB_DEVICE_WACOM(0x44) },
> { USB_DEVICE_WACOM(0x45) },
> + { USB_DEVICE_WACOM(0x47) },
> { USB_DEVICE_WACOM(0x57) },
> { USB_DEVICE_WACOM(0x59) },
> - { USB_DEVICE_WACOM(0x5D) },
> { USB_DEVICE_WACOM(0x5B) },
> + { USB_DEVICE_WACOM(0x5D) },
> { USB_DEVICE_WACOM(0x5E) },
> + { USB_DEVICE_WACOM(0x60) },
> + { USB_DEVICE_WACOM(0x61) },
> + { USB_DEVICE_WACOM(0x62) },
> + { USB_DEVICE_WACOM(0x63) },
> + { USB_DEVICE_WACOM(0x64) },
> + { USB_DEVICE_WACOM(0x65) },
> + { USB_DEVICE_WACOM(0x69) },
> + { USB_DEVICE_WACOM(0x6A) },
> + { USB_DEVICE_WACOM(0x6B) },
> + { USB_DEVICE_WACOM(0x84) },
> + { USB_DEVICE_WACOM(0x90) },
> + { USB_DEVICE_WACOM(0x93) },
> + { USB_DEVICE_WACOM(0x97) },
> + { USB_DEVICE_WACOM(0x9A) },
> + { USB_DEVICE_WACOM(0x9F) },
> { USB_DEVICE_WACOM(0xB0) },
> { USB_DEVICE_WACOM(0xB1) },
> { USB_DEVICE_WACOM(0xB2) },
> @@ -2477,17 +2487,14 @@ const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0xBA) },
> { USB_DEVICE_WACOM(0xBB) },
> { USB_DEVICE_WACOM(0xBC) },
> - { USB_DEVICE_WACOM(0x26) },
> - { USB_DEVICE_WACOM(0x27) },
> - { USB_DEVICE_WACOM(0x28) },
> - { USB_DEVICE_WACOM(0x29) },
> - { USB_DEVICE_WACOM(0x2A) },
> - { USB_DEVICE_WACOM(0x3F) },
> + { USB_DEVICE_WACOM(0xC0) },
> + { USB_DEVICE_WACOM(0xC2) },
> + { USB_DEVICE_WACOM(0xC4) },
> { USB_DEVICE_WACOM(0xC5) },
> { USB_DEVICE_WACOM(0xC6) },
> { USB_DEVICE_WACOM(0xC7) },
> + { USB_DEVICE_WACOM(0xCC) },
> { USB_DEVICE_WACOM(0xCE) },
> - { USB_DEVICE_WACOM(0x84) },
> { USB_DEVICE_WACOM(0xD0) },
> { USB_DEVICE_WACOM(0xD1) },
> { USB_DEVICE_WACOM(0xD2) },
> @@ -2502,13 +2509,6 @@ const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0xDD) },
> { USB_DEVICE_WACOM(0xDE) },
> { USB_DEVICE_WACOM(0xDF) },
> - { USB_DEVICE_WACOM(0xF0) },
> - { USB_DEVICE_WACOM(0xCC) },
> - { USB_DEVICE_WACOM(0x90) },
> - { USB_DEVICE_WACOM(0x93) },
> - { USB_DEVICE_WACOM(0x97) },
> - { USB_DEVICE_WACOM(0x9A) },
> - { USB_DEVICE_WACOM(0x9F) },
> { USB_DEVICE_WACOM(0xE2) },
> { USB_DEVICE_WACOM(0xE3) },
> { USB_DEVICE_WACOM(0xE5) },
> @@ -2516,6 +2516,12 @@ const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0xEC) },
> { USB_DEVICE_WACOM(0xED) },
> { USB_DEVICE_WACOM(0xEF) },
> + { USB_DEVICE_WACOM(0xF0) },
> + { USB_DEVICE_WACOM(0xF4) },
> + { USB_DEVICE_WACOM(0xF6) },
> + { USB_DEVICE_WACOM(0xF8) },
> + { USB_DEVICE_WACOM(0xFA) },
> + { USB_DEVICE_WACOM(0xFB) },
> { USB_DEVICE_WACOM(0x100) },
> { USB_DEVICE_WACOM(0x101) },
> { USB_DEVICE_WACOM(0x10D) },
> @@ -2526,8 +2532,10 @@ const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0x301) },
> { USB_DEVICE_WACOM(0x302) },
> { USB_DEVICE_WACOM(0x303) },
> - { USB_DEVICE_WACOM(0x30E) },
> { USB_DEVICE_WACOM(0x304) },
> + { USB_DEVICE_WACOM(0x307) },
> + { USB_DEVICE_WACOM(0x309) },
These two (307 and 309) should have kept their leading '0' during the
re-order. The compilation fails without it (I still don't understand
why I did not saw it).
I don't think it is worth sending a v2 right now, we have other
important things to discuss first :)
Cheers,
Benjamin
> + { USB_DEVICE_WACOM(0x30E) },
> { USB_DEVICE_WACOM(0x314) },
> { USB_DEVICE_WACOM(0x315) },
> { USB_DEVICE_WACOM(0x317) },
> @@ -2535,15 +2543,6 @@ const struct hid_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0x4004) },
> { USB_DEVICE_WACOM(0x5000) },
> { USB_DEVICE_WACOM(0x5002) },
> - { USB_DEVICE_WACOM(0x47) },
> - { USB_DEVICE_WACOM(0xF4) },
> - { USB_DEVICE_WACOM(0xF8) },
> - { USB_DEVICE_WACOM(0xF6) },
> - { USB_DEVICE_WACOM(0xFA) },
> - { USB_DEVICE_WACOM(0xFB) },
> - { USB_DEVICE_WACOM(0x0307) },
> - { USB_DEVICE_WACOM(0x0309) },
> - { USB_DEVICE_LENOVO(0x6004) },
> { }
> };
> MODULE_DEVICE_TABLE(hid, wacom_ids);
> --
> 2.0.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] Input - wacom: split out the pad device for the wireless receiver
From: Ping Cheng @ 2014-07-02 22:05 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Jason Gerecke, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <1404337044-15142-1-git-send-email-benjamin.tissoires@redhat.com>
On Wed, Jul 2, 2014 at 2:37 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> The Wireless Receiver should also behave in the same way than regular
> USB devices.
>
> To simplify the unregistering of the different devices,
> wacom_unregister_inputs() is introduced.
> For consistency, the function wacom_register_input() is renamed into
> wacom_register_input().
wacom_register_inputs().
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>.
Ping
> ---
>
> Hi,
>
> I noticed this afternoon that the "pad-in-a-separate-device" was missing the
> conversion for the Wireless Receiver too :(
> So here is a fix.
>
> I also have a patch for hid-wacom to behave in the same way regarding the
> bluetooth devices. I'll send it once we know a little bit more about how will be
> handled wacom.ko in 3.17.
>
> Cheers,
> Benjamin
>
> drivers/input/tablet/wacom_sys.c | 46 ++++++++++++++++++++--------------------
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
> index 598efd4..a70aa01 100644
> --- a/drivers/input/tablet/wacom_sys.c
> +++ b/drivers/input/tablet/wacom_sys.c
> @@ -1148,7 +1148,17 @@ static struct input_dev *wacom_allocate_input(struct wacom *wacom)
> return input_dev;
> }
>
> -static int wacom_register_input(struct wacom *wacom)
> +static void wacom_unregister_inputs(struct wacom *wacom)
> +{
> + if (wacom->wacom_wac.input)
> + input_unregister_device(wacom->wacom_wac.input);
> + if (wacom->wacom_wac.pad_input)
> + input_unregister_device(wacom->wacom_wac.pad_input);
> + wacom->wacom_wac.input = NULL;
> + wacom->wacom_wac.pad_input = NULL;
> +}
> +
> +static int wacom_register_inputs(struct wacom *wacom)
> {
> struct input_dev *input_dev, *pad_input_dev;
> struct wacom_wac *wacom_wac = &(wacom->wacom_wac);
> @@ -1220,16 +1230,12 @@ static void wacom_wireless_work(struct work_struct *work)
> /* Stylus interface */
> wacom1 = usb_get_intfdata(usbdev->config->interface[1]);
> wacom_wac1 = &(wacom1->wacom_wac);
> - if (wacom_wac1->input)
> - input_unregister_device(wacom_wac1->input);
> - wacom_wac1->input = NULL;
> + wacom_unregister_inputs(wacom1);
>
> /* Touch interface */
> wacom2 = usb_get_intfdata(usbdev->config->interface[2]);
> wacom_wac2 = &(wacom2->wacom_wac);
> - if (wacom_wac2->input)
> - input_unregister_device(wacom_wac2->input);
> - wacom_wac2->input = NULL;
> + wacom_unregister_inputs(wacom2);
>
> if (wacom_wac->pid == 0) {
> dev_info(&wacom->intf->dev, "wireless tablet disconnected\n");
> @@ -1259,9 +1265,11 @@ static void wacom_wireless_work(struct work_struct *work)
> wacom_wac1->features.device_type = BTN_TOOL_PEN;
> snprintf(wacom_wac1->name, WACOM_NAME_MAX, "%s (WL) Pen",
> wacom_wac1->features.name);
> + snprintf(wacom_wac1->pad_name, WACOM_NAME_MAX, "%s (WL) Pad",
> + wacom_wac1->features.name);
> wacom_wac1->shared->touch_max = wacom_wac1->features.touch_max;
> wacom_wac1->shared->type = wacom_wac1->features.type;
> - error = wacom_register_input(wacom1);
> + error = wacom_register_inputs(wacom1);
> if (error)
> goto fail;
>
> @@ -1279,7 +1287,9 @@ static void wacom_wireless_work(struct work_struct *work)
> else
> snprintf(wacom_wac2->name, WACOM_NAME_MAX,
> "%s (WL) Pad",wacom_wac2->features.name);
> - error = wacom_register_input(wacom2);
> + snprintf(wacom_wac2->pad_name, WACOM_NAME_MAX,
> + "%s (WL) Pad", wacom_wac2->features.name);
> + error = wacom_register_inputs(wacom2);
> if (error)
> goto fail;
>
> @@ -1296,15 +1306,8 @@ static void wacom_wireless_work(struct work_struct *work)
> return;
>
> fail:
> - if (wacom_wac2->input) {
> - input_unregister_device(wacom_wac2->input);
> - wacom_wac2->input = NULL;
> - }
> -
> - if (wacom_wac1->input) {
> - input_unregister_device(wacom_wac1->input);
> - wacom_wac1->input = NULL;
> - }
> + wacom_unregister_inputs(wacom1);
> + wacom_unregister_inputs(wacom2);
> return;
> }
>
> @@ -1450,7 +1453,7 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
> goto fail4;
>
> if (!(features->quirks & WACOM_QUIRK_NO_INPUT)) {
> - error = wacom_register_input(wacom);
> + error = wacom_register_inputs(wacom);
> if (error)
> goto fail5;
> }
> @@ -1490,10 +1493,7 @@ static void wacom_disconnect(struct usb_interface *intf)
>
> usb_kill_urb(wacom->irq);
> cancel_work_sync(&wacom->work);
> - if (wacom->wacom_wac.input)
> - input_unregister_device(wacom->wacom_wac.input);
> - if (wacom->wacom_wac.pad_input)
> - input_unregister_device(wacom->wacom_wac.pad_input);
> + wacom_unregister_inputs(wacom);
> wacom_destroy_battery(wacom);
> wacom_destroy_leds(wacom);
> usb_free_urb(wacom->irq);
> --
> 2.0.0
>
^ permalink raw reply
* Re: [PATCH 00/15] Input - Wacom: switch from an USB to a HID driver
From: Jason Gerecke @ 2014-07-02 23:33 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Jiri Kosina, Ping Cheng, Linux Input,
linux-kernel, linuxwacom-devel
In-Reply-To: <1404163586-29582-1-git-send-email-benjamin.tissoires@redhat.com>
On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> Hi guys,
>
> this patch series is a cleanup for the Wacom USB driver.
>
> I started working on this topic when I saw patches floating around which
> implemented a report descriptor parser within the wacom.ko module.
> However, we already have a nice HID subsystem which is more generic than the
> HID implementation we can find in this USB driver.
> Further details of the benefits (code reduction, regression tests) are hopefully
> explained in the commit messages of the corresponding patches.
>
> Also, I am working on a way to handle the new Wacom tablets in a more generic
> way in the hid tree, so consider this patch series as a first step in this
> direction.
>
> This patch series transfers the wacom.ko driver from the input tree into the hid
> tree. I did not made the corresponding move of the files in the series hoping
> that we will find a way to achieve it if this step is validated.
>
> IMO, the smoothest path would be that Jiri takes care of the wacom driver
> in the input tree (and that we move into into the hid subfolder). This can be
> achieve if the current pending wacom patches are applied in the hid tree too.
>
> Another solution could be to keep the wacom changes in the input tree and put the
> hid changes in the hid tree by using separate commits. Once 3.17 is out, we can
> then change the module into the hid subfolder.
>
> I wanted to send this patch series right now so we can figure out how we will
> handle the transition.
>
> I am pretty confident the patch series does not break any existing device
> (except for the required user space changes which can be handled correctly if
> we tackle them right now). The USB commands are executed in the same way,
> and the protocol handling is also done in the same way.
>
> Anyway, the net difference in lines of code (-307) should be enough to be of
> interest.
>
> Note: This patch series requires the current pending wacom patches to be applied.
> I set up a tree with all the patch applied if anyone wants to give a try:
> https://github.com/bentiss/linux/commits/hid-wacom-legacy-3.16-rc3
>
> Cheers,
> Benjamin
>
> Benjamin Tissoires (15):
> Input - wacom: include and use linux/hid.h
> Input - wacom: switch from an USB driver to a HID driver
> Input - wacom: use hid communication instead of plain usb
> Input - wacom: use HID core to actually fetch the report descriptor
> Input - wacom: compute the HID report size to get the actual packet
> size
> Input - wacom: install LED/OLED sysfs files in the HID device instead
> of USB
> Input - wacom: register the input devices on top of the HID one
> Input - wacom: remove usb dependency for siblings devices
> Input - wacom: register power device at the HID level
> Input - wacom: use hid_info instead of plain dev_info
> HID: uhid: add and set HID_TYPE_UHID for uhid devices
> Input - wacom: use in-kernel HID parser
> Input - wacom: use hidinput_calc_abs_res instead of duplicating its
> code
> Input - wacom: remove field pktlen declaration in the list of devices
> Input - wacom: keep wacom_ids ordered
>
> drivers/hid/hid-core.c | 15 +-
> drivers/hid/hid-wacom.c | 2 +-
> drivers/hid/uhid.c | 2 +
> drivers/input/tablet/wacom.h | 7 +-
> drivers/input/tablet/wacom_sys.c | 908 +++++++++++++--------------------------
> drivers/input/tablet/wacom_wac.c | 647 ++++++++++++++--------------
> drivers/input/tablet/wacom_wac.h | 10 +-
> include/linux/hid.h | 4 +-
> 8 files changed, 644 insertions(+), 951 deletions(-)
>
> --
> 2.0.0
>
*cracks knuckles*
Well, guess I better get to work poking and prodding at these and the
pad patches. A very quick review doesn't raise any significant flags,
though I do have a question or two that I might have for you in the
next few days (need to read through the code more carefully to be sure
I understand it correctly). My 24HDT is having some trouble
initializing with the patches applied, but I'll need some time to
track down the cause. Not sure how much I'll get done this week
(holiday weekend) but next week I should have some feedback.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
--
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: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
From: Sekhar Nori @ 2014-07-03 6:15 UTC (permalink / raw)
To: Nick Dyer, Stephen Warren
Cc: linux-input@vger.kernel.org, Linux OMAP List, Dmitry Torokhov,
swarren@wwwdotorg.org
In-Reply-To: <53B3F2F2.90707@itdev.co.uk>
On Wednesday 02 July 2014 05:24 PM, Nick Dyer wrote:
> On 02/07/14 11:49, Sekhar Nori wrote:
>> On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
>>> On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
>>> least a valid) choice. That's probably because the Atmel IRQ signal is
>>> routed to our GPIO controller, which is also an IRQ controller, and then
>>> "forwarded" up the chain to the GIC, with the polarity the GIC expects.
>>>
>>> If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add
>>> some kind of DT property to configure the polarity of the IRQ output.
>>
>> Yeah, I think so too.
>>
>> Nick,
>>
>> If you are going to rebase your branch, will you be able to fold in the
>> patch in my previous e-mail? Else, I can send a more formal patch to you.
>
> Either IRQF_TRIGGER_FALLING or IRQF_TRIGGER_LOW will work with these chips
> (it isn't a question of polarity but whether it's edge- or level-
> triggered). There isn't a sensible default. Atmel prefer IRQF_TRIGGER_LOW,
> however I've seen some IRQ controllers will revert to a polled mode for
> IRQF_TRIGGER_LOW, which kills performance.
>
> So, the sensible course of action seems to be to remove the default
> IRQF_TRIGGER_FALLING in the device tree parsing, and provide a device tree
> parameter for the flags. If you agree, I will sort this out at my end, you
> don't need to send a patch.
Sounds good.
> I have to leave it in in the case where there is neither static platform
> data, or device tree node, because that is used for some systems, but that
> shouldn't affect either of you.
>
> BTW, I do have a set of patches ready to send, once this change is made.
It will be great if you could CC me on that posting so I could test and
ack.
Regards,
Sekhar
^ permalink raw reply
* Re: [PATCH v2 07/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
From: Lee Jones @ 2014-07-03 7:30 UTC (permalink / raw)
To: Doug Anderson
Cc: Andrew Bresticker, swarren-3lzwWm7+Weoh9ZMKESR00Q,
olof-nZhT3qVonbNeoWH0uzbU5w, Sonny Rao,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Javier Martinez Canillas, Bill Richardson,
sjg-F7+t8E8rja9g9hUCZPvPmw, Wolfram Sang,
broonie-DgEjT+Ai2ygdnm+yROfE0A,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
sameo-VuQAYsv1563Yd54FQh9/CA, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1403115247-8853-8-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
On Wed, 18 Jun 2014, Doug Anderson wrote:
> From: Bill Richardson <wfrichar-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> Remove the three wrapper functions that talk to the EC without passing all
> the desired arguments and just use the underlying communication function
> that passes everything in a struct intead.
>
> This is internal code refactoring only. Nothing should change.
>
> Signed-off-by: Bill Richardson <wfrichar-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> Changes in v2:
> - Removed unneeded "ret" variable.
>
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 15 +++++++++++----
> drivers/input/keyboard/cros_ec_keyb.c | 12 ++++++++++--
> drivers/mfd/cros_ec.c | 32 --------------------------------
> include/linux/mfd/cros_ec.h | 19 ++++++-------------
> 4 files changed, 27 insertions(+), 51 deletions(-)
Patch applied with Wolfram and Dmitry's Acks.
Clause: There is a chance that this patch might not be seen in -next
for ~24-48hrs. If it's not there by 72hrs, feel free to poke.
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index 8e7a714..dd07818 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -183,6 +183,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg i2c_msgs[],
> u8 *request = NULL;
> u8 *response = NULL;
> int result;
> + struct cros_ec_command msg;
>
> request_len = ec_i2c_count_message(i2c_msgs, num);
> if (request_len < 0) {
> @@ -218,9 +219,15 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg i2c_msgs[],
> }
>
> ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
> - result = bus->ec->command_sendrecv(bus->ec, EC_CMD_I2C_PASSTHRU,
> - request, request_len,
> - response, response_len);
> +
> + msg.version = 0;
> + msg.command = EC_CMD_I2C_PASSTHRU;
> + msg.outdata = request;
> + msg.outsize = request_len;
> + msg.indata = response;
> + msg.insize = response_len;
> +
> + result = bus->ec->cmd_xfer(bus->ec, &msg);
> if (result)
> goto exit;
>
> @@ -258,7 +265,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
> u32 remote_bus;
> int err;
>
> - if (!ec->command_sendrecv) {
> + if (!ec->cmd_xfer) {
> dev_err(dev, "Missing sendrecv\n");
> return -EINVAL;
> }
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index 4083796..b8341ab 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -191,8 +191,16 @@ static void cros_ec_keyb_close(struct input_dev *dev)
>
> static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t *kb_state)
> {
> - return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
> - kb_state, ckdev->cols);
> + struct cros_ec_command msg = {
> + .version = 0,
> + .command = EC_CMD_MKBP_STATE,
> + .outdata = NULL,
> + .outsize = 0,
> + .indata = kb_state,
> + .insize = ckdev->cols,
> + };
> +
> + return ckdev->ec->cmd_xfer(ckdev->ec, &msg);
> }
>
> static int cros_ec_keyb_work(struct notifier_block *nb,
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 49ed8c3..4851ed2 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -44,34 +44,6 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_prepare_tx);
>
> -static int cros_ec_command_sendrecv(struct cros_ec_device *ec_dev,
> - uint16_t cmd, void *out_buf, int out_len,
> - void *in_buf, int in_len)
> -{
> - struct cros_ec_command msg;
> -
> - msg.version = cmd >> 8;
> - msg.command = cmd & 0xff;
> - msg.outdata = out_buf;
> - msg.outsize = out_len;
> - msg.indata = in_buf;
> - msg.insize = in_len;
> -
> - return ec_dev->cmd_xfer(ec_dev, &msg);
> -}
> -
> -static int cros_ec_command_recv(struct cros_ec_device *ec_dev,
> - uint16_t cmd, void *buf, int buf_len)
> -{
> - return cros_ec_command_sendrecv(ec_dev, cmd, NULL, 0, buf, buf_len);
> -}
> -
> -static int cros_ec_command_send(struct cros_ec_device *ec_dev,
> - uint16_t cmd, void *buf, int buf_len)
> -{
> - return cros_ec_command_sendrecv(ec_dev, cmd, buf, buf_len, NULL, 0);
> -}
> -
> static irqreturn_t ec_irq_thread(int irq, void *data)
> {
> struct cros_ec_device *ec_dev = data;
> @@ -104,10 +76,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>
> BLOCKING_INIT_NOTIFIER_HEAD(&ec_dev->event_notifier);
>
> - ec_dev->command_send = cros_ec_command_send;
> - ec_dev->command_recv = cros_ec_command_recv;
> - ec_dev->command_sendrecv = cros_ec_command_sendrecv;
> -
> if (ec_dev->din_size) {
> ec_dev->din = devm_kzalloc(dev, ec_dev->din_size, GFP_KERNEL);
> if (!ec_dev->din)
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 2b0c598..60c0880 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -63,9 +63,10 @@ struct cros_ec_command {
> * @was_wake_device: true if this device was set to wake the system from
> * sleep at the last suspend
> * @event_notifier: interrupt event notifier for transport devices
> - * @command_send: send a command
> - * @command_recv: receive a response
> - * @command_sendrecv: send a command and receive a response
> + * @cmd_xfer: send command to EC and get response
> + * Returns 0 if the communication succeeded, but that doesn't mean the EC
> + * was happy with the command it got. Caller should check msg.result for
> + * the EC's result code.
> *
> * @priv: Private data
> * @irq: Interrupt to use
> @@ -83,7 +84,6 @@ struct cros_ec_command {
> * @parent: pointer to parent device (e.g. i2c or spi device)
> * @wake_enabled: true if this device can wake the system from sleep
> * @lock: one transaction at a time
> - * @cmd_xfer: low-level channel to the EC
> */
> struct cros_ec_device {
>
> @@ -94,13 +94,8 @@ struct cros_ec_device {
> bool was_wake_device;
> struct class *cros_class;
> struct blocking_notifier_head event_notifier;
> - int (*command_send)(struct cros_ec_device *ec,
> - uint16_t cmd, void *out_buf, int out_len);
> - int (*command_recv)(struct cros_ec_device *ec,
> - uint16_t cmd, void *in_buf, int in_len);
> - int (*command_sendrecv)(struct cros_ec_device *ec,
> - uint16_t cmd, void *out_buf, int out_len,
> - void *in_buf, int in_len);
> + int (*cmd_xfer)(struct cros_ec_device *ec,
> + struct cros_ec_command *msg);
>
> /* These are used to implement the platform-specific interface */
> void *priv;
> @@ -112,8 +107,6 @@ struct cros_ec_device {
> struct device *parent;
> bool wake_enabled;
> struct mutex lock;
> - int (*cmd_xfer)(struct cros_ec_device *ec,
> - struct cros_ec_command *msg);
> };
>
> /**
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 10/10] mfd: cros_ec: move EC interrupt to cros_ec_keyb
From: Lee Jones @ 2014-07-03 7:32 UTC (permalink / raw)
To: Doug Anderson
Cc: Andrew Bresticker, swarren, olof, Sonny Rao, linux-samsung-soc,
Javier Martinez Canillas, Bill Richardson, sjg, Wolfram Sang,
broonie, dmitry.torokhov, sameo, geert, linux-input, linux-kernel
In-Reply-To: <1403115247-8853-11-git-send-email-dianders@chromium.org>
On Wed, 18 Jun 2014, Doug Anderson wrote:
> From: Andrew Bresticker <abrestic@chromium.org>
>
> If we receive EC interrupts after the cros_ec driver has probed, but
> before the cros_ec_keyb driver has probed, the cros_ec IRQ handler
> will not run the cros_ec_keyb notifier and the EC will leave the IRQ
> line asserted. The cros_ec IRQ handler then returns IRQ_HANDLED and
> the resulting flood of interrupts causes the machine to hang.
>
> Since the EC interrupt is currently only used for the keyboard, move
> the setup and handling of the EC interrupt to the cros_ec_keyb driver.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> ---
> Changes in v2:
> - IRQs should be optional => move EC interrupt to keyboard.
>
> drivers/input/keyboard/cros_ec_keyb.c | 58 ++++++++++++++++++++---------------
> drivers/mfd/cros_ec.c | 35 +--------------------
> include/linux/mfd/cros_ec.h | 2 --
> 3 files changed, 34 insertions(+), 61 deletions(-)
Patch applied with Simon's Reviewed-by.
Clause: There is a chance that this patch might not be seen in -next
for ~24-48hrs. If it's not there by 72hrs, feel free to poke.
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index b8341ab..791781a 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -24,8 +24,8 @@
> #include <linux/module.h>
> #include <linux/i2c.h>
> #include <linux/input.h>
> +#include <linux/interrupt.h>
> #include <linux/kernel.h>
> -#include <linux/notifier.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> #include <linux/input/matrix_keypad.h>
> @@ -42,7 +42,6 @@
> * @dev: Device pointer
> * @idev: Input device
> * @ec: Top level ChromeOS device to use to talk to EC
> - * @event_notifier: interrupt event notifier for transport devices
> */
> struct cros_ec_keyb {
> unsigned int rows;
> @@ -55,7 +54,6 @@ struct cros_ec_keyb {
> struct device *dev;
> struct input_dev *idev;
> struct cros_ec_device *ec;
> - struct notifier_block notifier;
> };
>
>
> @@ -173,22 +171,6 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
> input_sync(ckdev->idev);
> }
>
> -static int cros_ec_keyb_open(struct input_dev *dev)
> -{
> - struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> -
> - return blocking_notifier_chain_register(&ckdev->ec->event_notifier,
> - &ckdev->notifier);
> -}
> -
> -static void cros_ec_keyb_close(struct input_dev *dev)
> -{
> - struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> -
> - blocking_notifier_chain_unregister(&ckdev->ec->event_notifier,
> - &ckdev->notifier);
> -}
> -
> static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t *kb_state)
> {
> struct cros_ec_command msg = {
> @@ -203,19 +185,41 @@ static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t *kb_state)
> return ckdev->ec->cmd_xfer(ckdev->ec, &msg);
> }
>
> -static int cros_ec_keyb_work(struct notifier_block *nb,
> - unsigned long state, void *_notify)
> +static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
> {
> + struct cros_ec_keyb *ckdev = data;
> + struct cros_ec_device *ec = ckdev->ec;
> int ret;
> - struct cros_ec_keyb *ckdev = container_of(nb, struct cros_ec_keyb,
> - notifier);
> uint8_t kb_state[ckdev->cols];
>
> + if (device_may_wakeup(ec->dev))
> + pm_wakeup_event(ec->dev, 0);
> +
> ret = cros_ec_keyb_get_state(ckdev, kb_state);
> if (ret >= 0)
> cros_ec_keyb_process(ckdev, kb_state, ret);
> + else
> + dev_err(ec->dev, "failed to get keyboard state: %d\n", ret);
>
> - return NOTIFY_DONE;
> + return IRQ_HANDLED;
> +}
> +
> +static int cros_ec_keyb_open(struct input_dev *dev)
> +{
> + struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> + struct cros_ec_device *ec = ckdev->ec;
> +
> + return request_threaded_irq(ec->irq, NULL, cros_ec_keyb_irq,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> + "cros_ec_keyb", ckdev);
> +}
> +
> +static void cros_ec_keyb_close(struct input_dev *dev)
> +{
> + struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> + struct cros_ec_device *ec = ckdev->ec;
> +
> + free_irq(ec->irq, ckdev);
> }
>
> static int cros_ec_keyb_probe(struct platform_device *pdev)
> @@ -246,8 +250,12 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
> if (!idev)
> return -ENOMEM;
>
> + if (!ec->irq) {
> + dev_err(dev, "no EC IRQ specified\n");
> + return -EINVAL;
> + }
> +
> ckdev->ec = ec;
> - ckdev->notifier.notifier_call = cros_ec_keyb_work;
> ckdev->dev = dev;
> dev_set_drvdata(&pdev->dev, ckdev);
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 83e30c6..4873f9c 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -62,18 +62,6 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_check_result);
>
> -static irqreturn_t ec_irq_thread(int irq, void *data)
> -{
> - struct cros_ec_device *ec_dev = data;
> -
> - if (device_may_wakeup(ec_dev->dev))
> - pm_wakeup_event(ec_dev->dev, 0);
> -
> - blocking_notifier_call_chain(&ec_dev->event_notifier, 1, ec_dev);
> -
> - return IRQ_HANDLED;
> -}
> -
> static const struct mfd_cell cros_devs[] = {
> {
> .name = "cros-ec-keyb",
> @@ -92,8 +80,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> struct device *dev = ec_dev->dev;
> int err = 0;
>
> - BLOCKING_INIT_NOTIFIER_HEAD(&ec_dev->event_notifier);
> -
> if (ec_dev->din_size) {
> ec_dev->din = devm_kzalloc(dev, ec_dev->din_size, GFP_KERNEL);
> if (!ec_dev->din)
> @@ -105,42 +91,23 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> return -ENOMEM;
> }
>
> - if (!ec_dev->irq) {
> - dev_dbg(dev, "no valid IRQ: %d\n", ec_dev->irq);
> - return err;
> - }
> -
> - err = request_threaded_irq(ec_dev->irq, NULL, ec_irq_thread,
> - IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> - "chromeos-ec", ec_dev);
> - if (err) {
> - dev_err(dev, "request irq %d: error %d\n", ec_dev->irq, err);
> - return err;
> - }
> -
> err = mfd_add_devices(dev, 0, cros_devs,
> ARRAY_SIZE(cros_devs),
> NULL, ec_dev->irq, NULL);
> if (err) {
> dev_err(dev, "failed to add mfd devices\n");
> - goto fail_mfd;
> + return err;
> }
>
> dev_info(dev, "Chrome EC device registered\n");
>
> return 0;
> -
> -fail_mfd:
> - free_irq(ec_dev->irq, ec_dev);
> -
> - return err;
> }
> EXPORT_SYMBOL(cros_ec_register);
>
> int cros_ec_remove(struct cros_ec_device *ec_dev)
> {
> mfd_remove_devices(ec_dev->dev);
> - free_irq(ec_dev->irq, ec_dev);
>
> return 0;
> }
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 0ebf26f..fcbe9d1 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -62,7 +62,6 @@ struct cros_ec_command {
> * @dev: Device pointer
> * @was_wake_device: true if this device was set to wake the system from
> * sleep at the last suspend
> - * @event_notifier: interrupt event notifier for transport devices
> * @cmd_xfer: send command to EC and get response
> * Returns the number of bytes received if the communication succeeded, but
> * that doesn't mean the EC was happy with the command. The caller
> @@ -93,7 +92,6 @@ struct cros_ec_device {
> struct device *dev;
> bool was_wake_device;
> struct class *cros_class;
> - struct blocking_notifier_head event_notifier;
> int (*cmd_xfer)(struct cros_ec_device *ec,
> struct cros_ec_command *msg);
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/2 v5] HID: leds: move led_mode attribute to led-class devices in MSI GT683R driver
From: Johan Hovold @ 2014-07-03 8:28 UTC (permalink / raw)
To: Janne Kanniainen
Cc: johan, cooloney, jkosina, greg, bjorn, linux-kernel, linux-leds,
linux-usb, linux-input
In-Reply-To: <1404322679-19521-1-git-send-email-janne.kanniainen@gmail.com>
On Wed, Jul 02, 2014 at 08:37:59PM +0300, Janne Kanniainen wrote:
> Move led_mode attribute from HID device to led-class devices. This will also fix race condition by using attribute-groups.
>
> Signed-off-by: Janne Kanniainen <janne.kanniainen@gmail.com>
Looks good now. Thanks!
Perhaps you can resend both patches as a series (call both v6) so it's
easy to figure which version that is to be applied.
I also noticed that your subject line is a bit long (will end up as the
commit summary). Using for example
HID: gt683r: move mode attribute to led-class devices
would make it more concise.
Oh, and your commit message lacks line breaks (around 72 cols). You
could fix that as well.
Thanks again,
Johan
^ permalink raw reply
* Re: [Linuxwacom-devel] [PATCH 06/15] Input - wacom: install LED/OLED sysfs files in the HID device instead of USB
From: Przemo Firszt @ 2014-07-03 9:21 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Jiri Kosina, Ping Cheng, Jason Gerecke,
linuxwacom-devel, linux-kernel, linux-input
In-Reply-To: <1404163586-29582-7-git-send-email-benjamin.tissoires@redhat.com>
Quoting Benjamin Tissoires <benjamin.tissoires@redhat.com>:
> Removes one more dependency over USB, but requires some changes in
> the user space to find the sysfs files correctly.
>
> This patch breaks the user space. However, the number of program
> accessing the LEDs is quite limited and we can easily patch them
> to handle the new HID behavior.
[..]
Hi Bejnamin,
If you get the green light to break the user space we might as well
think about getting it in line with led/oled over bluetooth (intuos4
wireless) or the other way around.
The biggest user of led/oled functionality is gnome and there are also
a few small projects that would stop working after that change. I can
fix i4oled project easily, i4oled-gui is based on gnome handling oleds.
Patching those 2 should be enough to fix gnome:
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/wacom/gsd-wacom-led-helper.c
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/wacom/gsd-wacom-oled-helper.c
Regards,
Przemo Firszt
^ permalink raw reply
* Re: [PATCH v7 0/5] Input: pixcir_i2c_ts: Add Type-B Multi-touch and DT support
From: Roger Quadros @ 2014-07-03 9:34 UTC (permalink / raw)
To: dmitry.torokhov, tony
Cc: rydberg, balbi, dmurphy, mugunthanvnm, nsekhar, linux-input,
linux-kernel, linux-omap
In-Reply-To: <1402997507-9736-1-git-send-email-rogerq@ti.com>
Hi Dmitry,
Gentle reminder to pick this series for -next. Thanks :).
cheers,
-roger
On 06/17/2014 12:31 PM, Roger Quadros wrote:
> Hi Dmitry,
>
> These are the pending patches that didn't go through in the 3.16 merge window.
> Please queue them for -next. Thanks.
>
> The series does the following
> - convert to Type-B multi touch protocol
> - support upto 5 fingers with hardware supplied tracking IDs
> - device tree support
>
> Tony,
>
> The last 2 patches fix the touch screen size property in the device tree since
> we now use the unified touch screen properties.
>
> cheers,
> -roger
>
> Changelog:
>
> v7:
> - Rebased on 3.16-rc1.
>
> v6:
> - Use unified touchscreen bindings.
> - Update pointer math i.e. bufptr += 4 instead of &bufptr[4];
>
> v5:
> - Changed ts->exiting flag to ts->running in patch 2.
> - Don't call pixcir_stop() from .suspend() if wakeup is required.
>
> v4:
> - Imporved pixcir_stop() as per Dmitry's suggestion.
> - Removed unnecessary input_unregister_device() from .remove().
>
> v3:
> - Rebased to 3.15-rc3
> - Fixed suspend while touchscreen in use
> - Fixed module removal while touchscreen in use
>
> v2:
> - Addressed review comments and re-arranged patch order
>
> v1:
> - http://article.gmane.org/gmane.linux.kernel/1616417
>
> --
>
> Roger Quadros (5):
> Input: pixcir_i2c_ts: Use Type-B Multi-Touch protocol
> Input: pixcir_i2c_ts: support upto 5 fingers and hardware provided
> tracking IDs
> Input: pixcir_i2c_ts: Add device tree support
> ARM: dts: am43x-epos-evm: Update binding for touchscreen size
> ARM: dts: am437x-gp-evm: Update binding for touchscreen size
>
> .../bindings/input/touchscreen/pixcir_i2c_ts.txt | 26 +++
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm/boot/dts/am437x-gp-evm.dts | 4 +-
> arch/arm/boot/dts/am43x-epos-evm.dts | 4 +-
> drivers/input/touchscreen/pixcir_i2c_ts.c | 251 ++++++++++++++++++---
> include/linux/input/pixcir_ts.h | 12 +
> 6 files changed, 259 insertions(+), 39 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
>
^ permalink raw reply
* [PATCH 1/2 v2] lib: int_sqrt: add int64_sqrt routine
From: Barry Song @ 2014-07-03 12:34 UTC (permalink / raw)
To: dmitry.torokhov, dtor, akpm
Cc: linux-input, workgroup.linux, Yibo Cai, Peter Meerwald,
Barry Song
From: Yibo Cai <yibo.cai@csr.com>
Get square root of a 64-bit digit on 32bit platforms. CSR SiRFSoC
touchscreen driver needs it.
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Yibo Cai <yibo.cai@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
-v2:
use CONFIG_64BIT MARCO
don't init for b, m
include/linux/kernel.h | 8 ++++++++
lib/int_sqrt.c | 25 +++++++++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c52907..a536c0c 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -418,6 +418,14 @@ struct pid;
extern struct pid *session_of_pgrp(struct pid *pgrp);
unsigned long int_sqrt(unsigned long);
+#ifdef CONFIG_64BIT
+static inline unsigned long long int64_sqrt(unsigned long long x)
+{
+ return int_sqrt(x);
+}
+#else
+unsigned long long int64_sqrt(unsigned long long);
+#endif
extern void bust_spinlocks(int yes);
extern int oops_in_progress; /* If set, an oops, panic(), BUG() or die() is in progress */
diff --git a/lib/int_sqrt.c b/lib/int_sqrt.c
index 1ef4cc3..b86cccb 100644
--- a/lib/int_sqrt.c
+++ b/lib/int_sqrt.c
@@ -36,3 +36,28 @@ unsigned long int_sqrt(unsigned long x)
return y;
}
EXPORT_SYMBOL(int_sqrt);
+
+#ifndef CONFIG_64BIT
+unsigned long long int64_sqrt(unsigned long long x)
+{
+ unsigned long long b, m, y = 0;
+
+ if (x <= 1)
+ return x;
+
+ m = 1ULL << (BITS_PER_LONG_LONG - 2);
+ while (m != 0) {
+ b = y + m;
+ y >>= 1;
+
+ if (x >= b) {
+ x -= b;
+ y += m;
+ }
+ m >>= 2;
+ }
+
+ return y;
+}
+EXPORT_SYMBOL(int64_sqrt);
+#endif
--
1.9.3
^ permalink raw reply related
* Re: [Linuxwacom-devel] [PATCH 06/15] Input - wacom: install LED/OLED sysfs files in the HID device instead of USB
From: Benjamin Tissoires @ 2014-07-03 13:45 UTC (permalink / raw)
To: Przemo Firszt; +Cc: linuxwacom-devel, linux-kernel, linux-input
In-Reply-To: <20140703092143.Horde.pRrZTs1B-ZEo6Oax4ouKOw1@webmail.firszt.eu>
Hi Przemo,
On Jul 03 2014 or thereabouts, Przemo Firszt wrote:
>
> Quoting Benjamin Tissoires <benjamin.tissoires@redhat.com>:
>
> >Removes one more dependency over USB, but requires some changes in
> >the user space to find the sysfs files correctly.
> >
> >This patch breaks the user space. However, the number of program
> >accessing the LEDs is quite limited and we can easily patch them
> >to handle the new HID behavior.
> [..]
> Hi Bejnamin,
> If you get the green light to break the user space we might as well think
> about getting it in line with led/oled over bluetooth (intuos4 wireless) or
> the other way around.
I think it would be easier to fix the bluetooth (current hid) driver. I
think you already implemented the bluetooth handling in gnome 3.12 and
3.13, but having an uniform way of accessing the LEDs/OLEDs would be
nice.
>
> The biggest user of led/oled functionality is gnome and there are also a few
> small projects that would stop working after that change. I can fix i4oled
> project easily, i4oled-gui is based on gnome handling oleds.
I tried i4oled-gui last week or so, and patching g-s-d was enough. That
was a good idea to rely on gnome internals for your tool :)
>
> Patching those 2 should be enough to fix gnome:
> https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/wacom/gsd-wacom-led-helper.c
> https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/wacom/gsd-wacom-oled-helper.c
Yes, those two are sufficient enough. I had to make the patches
(http://paste.fedoraproject.org/115318/14043949/) so I could test that nothing
was broken. I'll submit those as soon as the fate of this conversion is
decided.
The current libwacom code also need a fix to handle the hid devices
(bluetooth and this series), and I have to send it for a while now :(
Cheers,
Benjamin
^ permalink raw reply
* Re: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
From: Nick Dyer @ 2014-07-03 14:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Sekhar Nori, Stephen Warren, linux-input@vger.kernel.org,
Linux OMAP List, swarren@wwwdotorg.org
In-Reply-To: <CAKdAkRTueVK8ynFR7AJeeJL7SPK60U0EHESeONqqoBF_vXJQxA@mail.gmail.com>
On 02/07/14 18:25, Dmitry Torokhov wrote:
> In this case board code should take care of setting up the interrupt
> properly and the driver should simply use 0 as flags in request_irq().
> By the way, doesn't generic DT infrastructure already allow specifying
> interrupt triggers and sets them up properly?
Yes. I've checked and tested this behaviour today. If you don't specify a
trigger type, then when you request the irq it trusts that the platform has
already set it up correctly:
http://lxr.free-electrons.com/source/kernel/irq/manage.c#L1208
Stephen: you should be able to set up the interrupt config in the device
tree. I believe this should be done by putting IRQ_TYPE_LEVEL_LOW or
IRQ_TYPE_EDGE_FALLING in the third field in the "interrupts" definition,
although I haven't a tegra DTS device to test on at the moment.
I've applied the patch below, which is basically what Sekhar had
originally, with a minor extra fix.
I've merged it into the appropriate parts of my for upstream series at
https://github.com/ndyer/linux/commits/for-next
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscree
index dc46100..15efb3b 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1453,7 +1453,7 @@ static int mxt_check_retrigen(struct mxt_data *data)
int error;
int val;
- if (data->pdata->irqflags & IRQF_TRIGGER_LOW)
+ if (irq_get_trigger_type(data->irq) & IRQF_TRIGGER_LOW)
return 0;
if (data->T18_address) {
@@ -3155,9 +3155,6 @@ static struct mxt_platform_data *mxt_parse_dt(struct
i2c_c
pdata->gpio_reset = of_get_named_gpio_flags(dev->of_node,
"atmel,reset-gpio", 0, NULL);
- /* Default to this. Properties can be added to configure it later */
- pdata->irqflags = IRQF_TRIGGER_FALLING;
-
of_property_read_string(dev->of_node, "atmel,cfg_name",
&pdata->cfg_name);
^ permalink raw reply related
* [PATCH 01/15] Input: atmel_mxt_ts - initialise IRQ before probing
From: nick.dyer @ 2014-07-03 15:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Yufeng Shen, Daniel Kurtz, Henrik Rydberg, Joonyoung Shim,
Alan Bowens, linux-input, linux-kernel, Peter Meerwald,
Benson Leung, Olof Johansson, Sekhar Nori, Nick Dyer
In-Reply-To: <1404399697-26484-1-git-send-email-nick.dyer@itdev.co.uk>
From: Nick Dyer <nick.dyer@itdev.co.uk>
The maXTouch chips use the CHG line to generate status events in bootloader
mode, and during configuration download, before there is enough information to
configure the input device. Therefore set up the interrupt handler earlier.
However, this introduces states where parts of the interrupt processing must
not run. Use data->object_table as a way to tell whether the chip information
is valid, and data->input_dev as a way to tell whether it is valid to generate
input report.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 101 +++++++++++++++++++------------
1 file changed, 62 insertions(+), 39 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 6e0b4a2..02c374d 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -764,6 +764,12 @@ static irqreturn_t mxt_process_messages_until_invalid(struct mxt_data *data)
if (status & MXT_T6_STATUS_RESET)
complete(&data->reset_completion);
+ } else if (!data->input_dev) {
+ /*
+ * do not report events if input device
+ * is not yet registered
+ */
+ mxt_dump_message(dev, &message);
} else if (mxt_is_T9_message(data, &message)) {
int id = reportid - data->T9_reportid_min;
mxt_input_touchevent(data, &message, id);
@@ -792,6 +798,9 @@ static irqreturn_t mxt_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
+ if (!data->object_table)
+ return IRQ_HANDLED;
+
return mxt_process_messages_until_invalid(data);
}
@@ -942,6 +951,19 @@ static int mxt_make_highchg(struct mxt_data *data)
return 0;
}
+static int mxt_acquire_irq(struct mxt_data *data)
+{
+ int error;
+
+ enable_irq(data->irq);
+
+ error = mxt_make_highchg(data);
+ if (error)
+ return error;
+
+ return 0;
+}
+
static int mxt_get_info(struct mxt_data *data)
{
struct i2c_client *client = data->client;
@@ -960,20 +982,29 @@ static int mxt_get_object_table(struct mxt_data *data)
{
struct i2c_client *client = data->client;
size_t table_size;
+ struct mxt_object *object_table;
int error;
int i;
u8 reportid;
table_size = data->info.object_num * sizeof(struct mxt_object);
+ object_table = kzalloc(table_size, GFP_KERNEL);
+ if (!object_table) {
+ dev_err(&data->client->dev, "Failed to allocate memory\n");
+ return -ENOMEM;
+ }
+
error = __mxt_read_reg(client, MXT_OBJECT_START, table_size,
- data->object_table);
- if (error)
+ object_table);
+ if (error) {
+ kfree(object_table);
return error;
+ }
/* Valid Report IDs start counting from 1 */
reportid = 1;
for (i = 0; i < data->info.object_num; i++) {
- struct mxt_object *object = data->object_table + i;
+ struct mxt_object *object = object_table + i;
u8 min_id, max_id;
le16_to_cpus(&object->start_address);
@@ -1009,6 +1040,8 @@ static int mxt_get_object_table(struct mxt_data *data)
}
}
+ data->object_table = object_table;
+
return 0;
}
@@ -1080,21 +1113,17 @@ static int mxt_initialize(struct mxt_data *data)
if (error)
return error;
- data->object_table = kcalloc(info->object_num,
- sizeof(struct mxt_object),
- GFP_KERNEL);
- if (!data->object_table) {
- dev_err(&client->dev, "Failed to allocate memory\n");
- return -ENOMEM;
- }
-
/* Get object table information */
error = mxt_get_object_table(data);
if (error) {
dev_err(&client->dev, "Error %d reading object table\n", error);
- goto err_free_object_table;
+ return error;
}
+ mxt_acquire_irq(data);
+ if (error)
+ goto err_free_object_table;
+
/* Check register init values */
error = mxt_check_reg_init(data);
if (error) {
@@ -1345,11 +1374,7 @@ static ssize_t mxt_update_fw_store(struct device *dev,
mxt_free_object_table(data);
- mxt_initialize(data);
-
- enable_irq(data->irq);
-
- error = mxt_make_highchg(data);
+ error = mxt_initialize(data);
if (error)
return error;
}
@@ -1446,9 +1471,26 @@ static int mxt_probe(struct i2c_client *client,
init_completion(&data->reset_completion);
init_completion(&data->crc_completion);
+ error = request_threaded_irq(client->irq, NULL, mxt_interrupt,
+ pdata->irqflags | IRQF_ONESHOT,
+ client->name, data);
+ if (error) {
+ dev_err(&client->dev, "Failed to register interrupt\n");
+ goto err_free_mem;
+ }
+
+ disable_irq(client->irq);
+
+ error = input_register_device(input_dev);
+ if (error) {
+ dev_err(&client->dev, "Error %d registering input device\n",
+ error);
+ goto err_free_irq;
+ }
+
error = mxt_initialize(data);
if (error)
- goto err_free_mem;
+ goto err_unregister_device;
__set_bit(EV_ABS, input_dev->evbit);
__set_bit(EV_KEY, input_dev->evbit);
@@ -1499,25 +1541,6 @@ static int mxt_probe(struct i2c_client *client,
input_set_drvdata(input_dev, data);
i2c_set_clientdata(client, data);
- error = request_threaded_irq(client->irq, NULL, mxt_interrupt,
- pdata->irqflags | IRQF_ONESHOT,
- client->name, data);
- if (error) {
- dev_err(&client->dev, "Failed to register interrupt\n");
- goto err_free_object;
- }
-
- error = mxt_make_highchg(data);
- if (error)
- goto err_free_irq;
-
- error = input_register_device(input_dev);
- if (error) {
- dev_err(&client->dev, "Error %d registering input device\n",
- error);
- goto err_free_irq;
- }
-
error = sysfs_create_group(&client->dev.kobj, &mxt_attr_group);
if (error) {
dev_err(&client->dev, "Failure %d creating sysfs group\n",
@@ -1530,10 +1553,10 @@ static int mxt_probe(struct i2c_client *client,
err_unregister_device:
input_unregister_device(input_dev);
input_dev = NULL;
-err_free_irq:
- free_irq(client->irq, data);
err_free_object:
kfree(data->object_table);
+err_free_irq:
+ free_irq(client->irq, data);
err_free_mem:
input_free_device(input_dev);
kfree(data);
--
2.0.1
^ permalink raw reply related
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