Re: [PATCH 0/4] HID: Improve handling of multimode Logitech handling wheels
On Fri, Feb 6, 2015 at 5:34 PM, Michal Malý madcatxs...@devoid-pointer.net wrote: This patch series improves handling of various Logitech gaming wheels and allows switching between various compatibility modes which might be useful to improve compatibility with very old games and testing purposes. Signed-off-by: Michal Malý madcatxs...@devoid-pointer.net Michal Malý (4): Identify Logitech gaming wheels in compatibility modes accordingly to Logitech specifications Display the real wheel model and supported alternate modes through sysfs. This applies only to multimode wheels. Introduce a module parameter to disable automatic switch of Logitech gaming wheels from compatibility to native mode. This only applies to multimode wheels. Allow switching of Logitech gaming wheels between available compatibility modes through sysfs. This only applies to multimode wheels. .../ABI/testing/sysfs-driver-hid-logitech-lg4ff| 45 ++ drivers/hid/hid-lg.c | 6 + drivers/hid/hid-lg4ff.c| 608 ++--- 3 files changed, 583 insertions(+), 76 deletions(-) -- 2.2.2 Applied cleanly on kernel 3.17.8, and tested with: - Logitech Formula Vibration Wheel - Logitech MOMO (Black) Wheel Everything keeps working like it was before, which is correct because these wheels are no multimode wheels. Tested-by: Elias Vanderstuyft elias@gmail.com Thanks, Elias -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: bfin_rotary - mark suspend and resume code as __maybe_unused
Hi Dmitry,
Since the line I mentioned was removed in v3.19-rc1, I am fine with this patch.
Acked-by: Sonic Zhang sonic.zh...@analog.com
On Fri, Feb 6, 2015 at 2:09 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Instead of using #ifdef to guard potentially unused suspend and resume code
let's mark them as __maybe_unused so they still get discarded if they are
not used but we do not get warning. This allows for better compile coverage.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/input/misc/bfin_rotary.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/input/misc/bfin_rotary.c
b/drivers/input/misc/bfin_rotary.c
index a39793c..09d7612 100644
--- a/drivers/input/misc/bfin_rotary.c
+++ b/drivers/input/misc/bfin_rotary.c
@@ -232,8 +232,7 @@ static int bfin_rotary_remove(struct platform_device
*pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int bfin_rotary_suspend(struct device *dev)
+static int __maybe_unused bfin_rotary_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct bfin_rot *rotary = platform_get_drvdata(pdev);
@@ -248,7 +247,7 @@ static int bfin_rotary_suspend(struct device *dev)
return 0;
}
-static int bfin_rotary_resume(struct device *dev)
+static int __maybe_unused bfin_rotary_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct bfin_rot *rotary = platform_get_drvdata(pdev);
@@ -266,20 +265,15 @@ static int bfin_rotary_resume(struct device *dev)
return 0;
}
-static const struct dev_pm_ops bfin_rotary_pm_ops = {
- .suspend= bfin_rotary_suspend,
- .resume = bfin_rotary_resume,
-};
-#endif
+static SIMPLE_DEV_PM_OPS(bfin_rotary_pm_ops,
+bfin_rotary_suspend, bfin_rotary_resume);
static struct platform_driver bfin_rotary_device_driver = {
.probe = bfin_rotary_probe,
.remove = bfin_rotary_remove,
.driver = {
.name = bfin-rotary,
-#ifdef CONFIG_PM
.pm = bfin_rotary_pm_ops,
-#endif
},
};
module_platform_driver(bfin_rotary_device_driver);
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/20] power_supply: sysfs: Use power_supply_*() API for accessing function attrs
Hi Krzysztof, Krzysztof Kozlowski k.kozlow...@samsung.com hat am 30. Januar 2015 um 15:47 geschrieben: Replace direct calls to power supply function attributes with wrappers. Wrappers provide safe access in case of unregistering the power supply (e.g. by removing the driver). Replace: - get_property - power_supply_get_property - set_property - power_supply_set_property - property_is_writeable - power_supply_property_is_writeable Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Acked-by: Jonghwa Lee jonghwa3@samusng.com just a nit. It looks like a typo in the mail address which is also in patch 5 - 10. I applied patch 1 - 14 to my repo with a upcoming power driver (mxs_power) and didn't see any problems with your patches. Stefan Acked-by: Pavel Machek pa...@ucw.cz Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Reviewed-by: Sebastian Reichel s...@kernel.org --- -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] Input: atmel_mxt_ts: Make config CRC calculation match that done by the firmware for mxt224S.
Although the protocol guide says the CRC is calculated from T7 onwards on
the 224s it appears necessary to calculate from T71 (the previous object).
The mismatch is not critical from a functional perspective but causes an
incorrect warning Config CRC error, calculated=... file=...
to be emitted every time the configuration is uploaded.
My 224s has this memory map:
Family: 130 Variant: 36 Firmware V2.0.AA Objects: 23
Matrix size: X24Y14
Information Block CRC: 0x68822D
Type Start Size Instances ReportIds Name
-
T37 148 130 10-0DEBUG_DIAGNOSTIC_T37
T44 278 1 10-0SPT_MESSAGECOUNT_T44
T5279 9 10-0GEN_MESSAGEPROCESSOR_T5
T6288 6 11-1GEN_COMMANDPROCESSOR_T6
T38 294 8 10-0SPT_USERDATA_T38
T71 302 112 10-0SPT_DYNAMICCONFIGURATIONCONTAINER_T71
T7414 4 10-0GEN_POWERCONFIG_T7
On a 224e it works without this patch but the 224e does not have a T71 object.
So, if the T71 object exists start calculating the CRC from there, otherwise
from T7.
As I only have access to the mxt224e and mxt224s chips I don't know if this is
the right way for all chips, hence RFC status.
Signed-off-by: Martin Fuzzey mfuz...@parkeon.com
---
drivers/input/touchscreen/atmel_mxt_ts.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 29f9b9d..c773548 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -79,6 +79,7 @@
#define MXT_SPT_DIGITIZER_T43 43
#define MXT_SPT_MESSAGECOUNT_T44 44
#define MXT_SPT_CTECONFIG_T46 46
+#define MXT_SPT_DYNAMICCONFIGURATIONCONTAINER_T71 71
/* MXT_GEN_MESSAGE_T5 object */
#define MXT_RPTID_NOMSG0xff
@@ -264,6 +265,7 @@ struct mxt_data {
u8 T6_reportid;
u16 T6_address;
u16 T7_address;
+ u16 T71_address;
u8 T9_reportid_min;
u8 T9_reportid_max;
u8 T19_reportid;
@@ -1238,6 +1240,8 @@ static int mxt_update_cfg(struct mxt_data *data, const
struct firmware *cfg)
u32 info_crc, config_crc, calculated_crc;
u8 *config_mem;
size_t config_mem_size;
+ u16 crc_start_address;
+ const char *crc_start_obj;
mxt_update_crc(data, MXT_COMMAND_REPORTALL, 1);
@@ -1326,15 +1330,24 @@ static int mxt_update_cfg(struct mxt_data *data, const
struct firmware *cfg)
goto release_mem;
/* Calculate crc of the received configs (not the raw config file) */
- if (data-T7_address cfg_start_ofs) {
- dev_err(dev, Bad T7 address, T7addr = %x, config offset %x\n,
- data-T7_address, cfg_start_ofs);
+ if (data-T71_address) {
+ /* At least the mxt224S calculates from T71 */
+ crc_start_address = data-T71_address;
+ crc_start_obj = T71;
+ } else {
+ /* Protocol guide says from T7.. */
+ crc_start_address = data-T7_address;
+ crc_start_obj = T7;
+ }
+ if (crc_start_address cfg_start_ofs) {
+ dev_err(dev, Bad %s address, addr = %x, config offset %x\n,
+ crc_start_obj, crc_start_address, cfg_start_ofs);
ret = 0;
goto release_mem;
}
calculated_crc = mxt_calculate_crc(config_mem,
- data-T7_address - cfg_start_ofs,
+ crc_start_address - cfg_start_ofs,
config_mem_size);
if (config_crc 0 config_crc != calculated_crc)
@@ -1404,6 +1417,7 @@ static void mxt_free_object_table(struct mxt_data *data)
data-T5_msg_size = 0;
data-T6_reportid = 0;
data-T7_address = 0;
+ data-T71_address = 0;
data-T9_reportid_min = 0;
data-T9_reportid_max = 0;
data-T19_reportid = 0;
@@ -1488,6 +1502,9 @@ static int mxt_get_object_table(struct mxt_data *data)
case MXT_GEN_POWER_T7:
data-T7_address = object-start_address;
break;
+ case MXT_SPT_DYNAMICCONFIGURATIONCONTAINER_T71:
+ data-T71_address = object-start_address;
+ break;
case MXT_TOUCH_MULTI_T9:
data-T9_reportid_min = min_id;
data-T9_reportid_max = max_id;
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Input: atmel_mxt_ts: Configuration data unnecessarily uploaded at each probe.
mxt_update_cfg() first checks the info block CRC (data-info_crc) and
always does an upload irrespective of configuration CRC if it does not match.
However the info_crc is never initialised from the information provided
by the firmware which causes an upload to be done at each probe if
configuration data firmware is available.
Signed-off-by: Martin Fuzzey mfuz...@parkeon.com
---
drivers/input/touchscreen/atmel_mxt_ts.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index aaacf8b..0666759 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1413,21 +1413,26 @@ static int mxt_get_object_table(struct mxt_data *data)
int i;
u8 reportid;
u16 end_address;
+ u8 *crc_ptr;
table_size = data-info.object_num * sizeof(struct mxt_object);
- object_table = kzalloc(table_size, GFP_KERNEL);
+ object_table = kzalloc(table_size + MXT_INFO_CHECKSUM_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,
+ error = __mxt_read_reg(client, MXT_OBJECT_START,
+ table_size + MXT_INFO_CHECKSUM_SIZE,
object_table);
if (error) {
kfree(object_table);
return error;
}
+ crc_ptr = (u8 *)object_table + table_size;
+ data-info_crc = crc_ptr[0] | (crc_ptr[1] 8) | (crc_ptr[2] 16);
+
/* Valid Report IDs start counting from 1 */
reportid = 1;
data-mem_size = 0;
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Input: atmel_mxt_ts: Fix random configuration load failure
Sometimes configuration fails to load with:
Bad format: failed to parse object
This can occur because the firmware loader does not ensure that
the configuration data is null terminated.
The scanf() therefore reads arbitrary garbage at the end of file.
If one item of garbage happens to be parsable the error occurs.
By skipping control characters (line endings) before scanning
each line rather than relying on the white space skipping of sscanf
we correctly detect end of file.
Signed-off-by: Martin Fuzzey mfuz...@parkeon.com
---
drivers/input/touchscreen/atmel_mxt_ts.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 0666759..29f9b9d 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1086,6 +1086,13 @@ static int mxt_prepare_cfg_mem(struct mxt_data *data,
u8 val;
while (data_pos cfg-size) {
+ if (cfg-data[data_pos] 0x20) {
+ /* firmware loading does not ensure null termination
+* which is required by scanf */
+data_pos++;
+continue;
+ }
+
/* Read type, instance, length */
ret = sscanf(cfg-data + data_pos, %x %x %x%n,
type, instance, size, offset);
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/20] power_supply: sysfs: Use power_supply_*() API for accessing function attrs
On pon, 2015-02-09 at 20:02 +0100, Stefan Wahren wrote: Hi Krzysztof, Krzysztof Kozlowski k.kozlow...@samsung.com hat am 30. Januar 2015 um 15:47 geschrieben: Replace direct calls to power supply function attributes with wrappers. Wrappers provide safe access in case of unregistering the power supply (e.g. by removing the driver). Replace: - get_property - power_supply_get_property - set_property - power_supply_set_property - property_is_writeable - power_supply_property_is_writeable Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Acked-by: Jonghwa Lee jonghwa3@samusng.com just a nit. It looks like a typo in the mail address which is also in patch 5 - 10. Right, I copied it directly from Jonghwa's response. Thank you for noticing it. I applied patch 1 - 14 to my repo with a upcoming power driver (mxs_power) and didn't see any problems with your patches. Great, thanks! Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: sony: Enable Gasia third-party PS3 controllers
On Mon, 09 Feb 2015 11:08:01 +0100 Oliver Neukum oneu...@suse.de wrote: + ret = usb_interrupt_msg(dev, usb_sndintpipe(dev, 0x02), + buf2, sizeof(buf2), + transfered, USB_CTRL_SET_TIMEOUT); You cannot do this. Even for a single byte DMA on the stack is wrong. Not on all architectures it works at all and you violate the DMA constrainsts. You must use kmalloc(). Hi Oliver, Does this still apply when using hid_hw_output_report? - Lauri -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Fixes for ALPS trackstick
On Sun, Feb 08, 2015 at 01:26:32PM +0100, Pali Rohár wrote:
On Monday 02 February 2015 15:27:55 Pali Rohár wrote:
On Monday 02 February 2015 11:49:58 Pali Rohár wrote:
On Monday 02 February 2015 06:49:31 Dmitry Torokhov wrote:
On Sun, Jan 18, 2015 at 10:47:06AM +0100, Pali Rohár wrote:
On Sunday 18 January 2015 08:22:45 Dmitry Torokhov wrote:
On Sat, Jan 17, 2015 at 11:01:56AM +0100, Pali Rohár
wrote:
On Thursday 15 January 2015 22:02:16 Dmitry Torokhov
wrote:
On Thu, Jan 15, 2015 at 09:28:41PM +0100, Pali
Rohár
wrote:
On Thursday 15 January 2015 20:38:18 Dmitry
Torokhov
wrote:
On Thu, Jan 15, 2015 at 08:19:59PM +0100, Pali
Rohár
wrote:
On Thursday 15 January 2015 19:18:20 Dmitry
Torokhov
wrote:
On Thu, Jan 15, 2015 at 11:49:32AM +0100,
Pali Rohár
wrote:
On Wednesday 14 January 2015 23:55:48
Dmitry Torokhov
wrote:
Hi Pali,
This series try to address the issue
you brought regarding trackstick
initialization on Dell Latitudes in a
different way than the patches you
proposed. Basically in this series we
move resetting and all detection in
alps_detect() and make sure we keep
the state so alps_init() can reuse it
and not perform the detection all
over again. Doing this allows us to
set up device characteristics (name,
version, etc) properly from the get
go while still performing reset only
once.
This is untested as I do not have any
ALPS devices anymore so I'd appreciate
you giving it a spin.
Thanks!
Hi Dmitry,
on top of which branch/repository should
I apply your patches?
Should be applicable to my 'next' branch
(which I just upreved to 3.19-rc4).
Thanks.
Not working at top of next (0c3e994).
Applying: Input: ALPS - renumber protocol
numbers Applying: Input: ALPS - make
Rushmore a separate protocol error: patch
failed: drivers/input/mouse/alps.c:1275
error: drivers/input/mouse/alps.c: patch
does not apply Patch failed at 0002 Input:
ALPS - make Rushmore a separate protocol
Hmm.. I created a new alps branch (based on
3.19-rc4), can you try it?
Thanks.
Compiled from your new alps branch (with if
(!priv) fix) and modprobing psmouse.ko caused
laptop freeze :-( Even sysrq not responded. So
something is not working...
Hmm, is it on text console or in X? Any chance you
could go through pathes - there are only 8 of them
including 2 of yours that should be unmodified.
Thanks.
Hi, now I tested patch by patch and kernel crash is
caused only by last patch 6/6 and only after I touch
touchpad or trackstick.
In text console it prints lot of panic messages and
because it prints lot of messages I cannot read (or
record) more then last.
In last call trace I see that
alps_register_bare_ps2_mouse() was called and it
generated page_fault.
That happens because while you added priv-psmouse
pointer it looks like you forgot to initialize it and
I missed that too...
Right your patch 6/6 does not initialize priv-psmouse.
I looked into my original patch and it initialize it,
so there was some copy-paste error.
Look at other emails... can you fix problems and send
new version of your patches for testing?
I think I did. Can you please take another look at my alps
branch?
Thanks!
Now I tried it. It does not crash anymore which is good. But
it does not working. Driver alsp.c receive only bare PS/2
packets, not 6 bites ALPS packets. So ALPS touchpad is not
properly initialized and so is in legacy mode when it act
as genetic mouse. And events are sent via dev3 device (that
PS/2 mouse).
So your patches do not initialize my ALPS touchpad
correctly.
Hello Dmitry, I found where is problem.
This chunk is needed:
@@ -135,7 +135,7 @@ static const struct alps_protocol_info
alps_v3_protocol_data = { };
static const struct alps_protocol_info alps_v3_rushmore_data
= { - ALPS_PROTO_V3, 0x8f, 0x8f, ALPS_DUALPOINT
+ ALPS_PROTO_V3_RUSHMORE, 0x8f, 0x8f, ALPS_DUALPOINT
};
static const struct
Re: [PATCH v3 20/20] arm: mach-pxa: Decrement the power supply's device reference counter
On pią, 2015-02-06 at 15:59 +0100, Pavel Machek wrote: On Fri 2015-02-06 15:43:08, Krzysztof Kozlowski wrote: On pią, 2015-02-06 at 14:49 +0100, Pavel Machek wrote: On Fri 2015-01-30 15:47:58, Krzysztof Kozlowski wrote: Use power_supply_put() to decrement the power supply's device reference counter. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Reviewed-by: Sebastian Reichel s...@kernel.org 11,13,20 nothing obviously wrong. But I'm not sure if I studied them closely enough to warrant an ACK. It would be good to get this into kernel -- I seen no bad comments, and it is not going to improve without merge into mainline. Thanks for looking at patchset. It would be really nice if this could be tested for some time in linux-next. Such testing would help a lot. But I need acks from various maintainers for that. Actually, you don't. The various maintainers clearly don't care at this point. They had enough time. So you select one maintainer you want to push this through, and you push it. Someone may complain, so you'll solve the feedback... I am thinking also on another way of solving this huge-patch problem: 1. Mark all drivers broken (CONFIG_BROKEN). 2. Introduce change in power_supply_register() API. Broken drivers will fail to build. 3. Convert broken drivers to new API incrementally (one driver per patch) marking them also non-broken. This would be much easier to review but also this would break build-bisectability for drivers and some platforms using them (like OLPC, compal-laptop, ACPI). In case of important platforms (like ACPI) I could do the old-way: change the driver along with API change. What do you think about this? I pushed the patchset here: https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-next-power-supply-core-ownership (actually this is v4: added acks/reviews and minor issue fixed; merge window has opened so I'll wait with sending this to LKML). Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: sony: Enable Gasia third-party PS3 controllers
On Sat, 2015-02-07 at 15:48 +0200, Lauri Kasanen wrote:
Without this, my Gasia Co.,Ltd PS(R) Gamepad would not send
any events. Now everything works including the leds.
Based on work by Andrew Haines and Antonio Ospite.
cc: Antonio Ospite a...@ao2.it
cc: Andrew Haines andrewd...@aol.com
Signed-off-by: Lauri Kasanen c...@gmx.com
---
drivers/hid/hid-sony.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
Antonio's original approach was not enough; it enabled the events,
but only for a few seconds, then the controller timed out and sent
no more. Andrew's did more than was necessary. This is a combination
of the two, against Linus' git.
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 31e9d25..de93386 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -36,6 +36,7 @@
#include linux/list.h
#include linux/idr.h
#include linux/input/mt.h
+#include linux/usb/input.h
#include hid-ids.h
@@ -1130,8 +1131,12 @@ static void sony_input_configured(struct hid_device
*hdev,
*/
static int sixaxis_set_operational_usb(struct hid_device *hdev)
{
+ struct usb_interface *intf = to_usb_interface(hdev-dev.parent);
+ struct usb_device *dev = interface_to_usbdev(intf);
int ret;
- char *buf = kmalloc(18, GFP_KERNEL);
+ char *buf = kmalloc(65, GFP_KERNEL);
+ unsigned char buf2[] = { 0x00 };
+ int transfered;
if (!buf)
return -ENOMEM;
@@ -1140,7 +1145,24 @@ static int sixaxis_set_operational_usb(struct
hid_device *hdev)
HID_REQ_GET_REPORT);
if (ret 0)
- hid_err(hdev, can't set operational mode\n);
+ hid_err(hdev, can't set operational mode on the control EP\n);
+
+ /*
+ * Some compatible controllers like the Speedlink Strike FX and
+ * Gasia need another query plus an USB interrupt to get operational.
+ */
+ ret = hid_hw_raw_request(hdev, 0xf5, buf, 64, HID_FEATURE_REPORT,
+ HID_REQ_GET_REPORT);
+
+ if (ret 0)
+ hid_err(hdev, can't set operational mode on the interrupt
EP\n);
+
+ ret = usb_interrupt_msg(dev, usb_sndintpipe(dev, 0x02),
+ buf2, sizeof(buf2),
+ transfered, USB_CTRL_SET_TIMEOUT);
You cannot do this. Even for a single byte DMA on the stack is
wrong. Not on all architectures it works at all and you violate
the DMA constrainsts. You must use kmalloc().
Regards
Oliver
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] GPIO joystick driver
As far as I can tell, there is no way to specify values for ABS-keys in the device tree binding. It may not be present in device tree binding, but the driver does support it, so I would rather extend the binding than have a brand new driver. All right, I find it a bit like whacking a round peg down a square hole, but I'll head down that path and see where it leads. While both the device tree binding and the gpio-keys driver could possibly be adapted to support this, it makes sense to me to describe joysticks in a separate binding and keep the driver implementations apart. Why? From the input core perspective there is no difference. It is just a device that emits set of events. From a hardware-description/devicee-tree binding perspective its confusing (at least to me) to describe joysticks as keyboards. In addition to this, auto-repeat and the sys fs disable interface for individual keys does not make sense for joysticks. You do not need to use it when you describe the device (BTW autorepeat for trigger might be a good thing). Ah, yes. autofire. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Fri, Feb 06, 2015 at 05:00:13PM +0100, Antonio Ospite wrote:
Last doubt, now that I am fixing the DSDT I am going to add an
Interrupt resource, but what is the correct way to specify its value?
Pin 3 of GPO2 is mapped to IRQ 220 by the mainline kernel, so I added
this:
Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, ,, )
{
0x00DC,
}
And it works, but doesn't this rely on the way linux maps interrupt
numbers? Is this going to be OS agnostic? My doubt arises from the
fact that on the Android kernel the same pin is mapped to IRQ
389.
You should specify GpioInt() instead and turn it to interrupt using
gpiod_to_irq().
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
