* [PATCH 0/3] HID: sony: Various cleanups and fixes for the sony module
From: Frank Praznik @ 2014-02-18 22:22 UTC (permalink / raw)
To: linux-input; +Cc: dh.herrmann, jkosina, Frank Praznik
Since the new ll_driver functions allow for reports to be sent on the control
channel the LEDs and force-feedback can be enabled for the Sixaxis/Dualshock 3.
The second patch only sets the force-feedback flags for devices that actually
support force feedback. It also moves the cancel_work_sync function out of the
ff shutdown function since the worker functions are initialized and used for
the LEDs even when force-feedback support is disabled at compile time.
The final patch is an updated version of the duplicate controller detection code
that was originally part of the Bluetooth patch set. It now works on both the
Sixaxis and Dualshock 4. On USB the MAC can be retrieved via feature reports.
Unfortunately, neither controller supports retrieving the MAC address via a
feature report when connected via Bluetooth so it needs to be parsed from the
uniq string where HIDP stores it. Based on previous discussions
(http://www.spinics.net/lists/linux-input/msg29530.html), uniq should provide a
stable way for retrieving a Bluetooth MAC address under normal circumstances,
unless the behavior in HIDP changes for some reason. If a MAC cannot be parsed
from the uniq string the duplicate check will be skipped and the connection will
proceed, so even in the case of a uHID device or the behavior of HIDP changing
in the future, a user's controller will still work.
^ permalink raw reply
* [PATCH 1/3] HID: sony: Enable LED controls and rumble for the Sixaxis on Bluetooth.
From: Frank Praznik @ 2014-02-18 22:22 UTC (permalink / raw)
To: linux-input; +Cc: dh.herrmann, jkosina, Frank Praznik
In-Reply-To: <1392762123-17725-1-git-send-email-frank.praznik@oh.rr.com>
Add a SIXAXIS_CONTROLLER macro to simplify conditionals where the
connection type is irrelevant.
Enable the LED and force feedback controls for Sixaxis controllers connected via
Bluetooth.
Send Sixaxis Bluetooth output reports on the control channel.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
---
drivers/hid/hid-sony.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index f88d1ae..81917eb 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -44,12 +44,12 @@
#define DUALSHOCK4_CONTROLLER_USB BIT(5)
#define DUALSHOCK4_CONTROLLER_BT BIT(6)
+#define SIXAXIS_CONTROLLER (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT)
#define DUALSHOCK4_CONTROLLER (DUALSHOCK4_CONTROLLER_USB |\
DUALSHOCK4_CONTROLLER_BT)
-#define SONY_LED_SUPPORT (SIXAXIS_CONTROLLER_USB | BUZZ_CONTROLLER |\
- DUALSHOCK4_CONTROLLER)
-#define SONY_BATTERY_SUPPORT (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT |\
+#define SONY_LED_SUPPORT (SIXAXIS_CONTROLLER | BUZZ_CONTROLLER |\
DUALSHOCK4_CONTROLLER)
+#define SONY_BATTERY_SUPPORT (SIXAXIS_CONTROLLER | DUALSHOCK4_CONTROLLER)
#define MAX_LEDS 4
@@ -935,8 +935,7 @@ static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
/* Sixaxis HID report has acclerometers/gyro with MSByte first, this
* has to be BYTE_SWAPPED before passing up to joystick interface
*/
- if ((sc->quirks & (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT)) &&
- rd[0] == 0x01 && size == 49) {
+ if ((sc->quirks & SIXAXIS_CONTROLLER) && rd[0] == 0x01 && size == 49) {
swap(rd[41], rd[42]);
swap(rd[43], rd[44]);
swap(rd[45], rd[46]);
@@ -1096,8 +1095,7 @@ static void sony_set_leds(struct hid_device *hdev, const __u8 *leds, int count)
if (drv_data->quirks & BUZZ_CONTROLLER && count == 4) {
buzz_set_leds(hdev, leds);
- } else if ((drv_data->quirks & SIXAXIS_CONTROLLER_USB) ||
- (drv_data->quirks & DUALSHOCK4_CONTROLLER)) {
+ } else {
for (n = 0; n < count; n++)
drv_data->led_state[n] = leds[n];
schedule_work(&drv_data->state_worker);
@@ -1285,7 +1283,11 @@ static void sixaxis_state_worker(struct work_struct *work)
buf[10] |= sc->led_state[2] << 3;
buf[10] |= sc->led_state[3] << 4;
- hid_output_raw_report(sc->hdev, buf, sizeof(buf), HID_OUTPUT_REPORT);
+ if (sc->quirks & SIXAXIS_CONTROLLER_USB)
+ hid_output_raw_report(sc->hdev, buf, sizeof(buf), HID_OUTPUT_REPORT);
+ else
+ hid_hw_raw_request(sc->hdev, 0x01, buf, sizeof(buf),
+ HID_OUTPUT_REPORT, HID_REQ_SET_REPORT);
}
static void dualshock4_state_worker(struct work_struct *work)
@@ -1520,10 +1522,10 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
hdev->hid_output_raw_report = sixaxis_usb_output_raw_report;
ret = sixaxis_set_operational_usb(hdev);
INIT_WORK(&sc->state_worker, sixaxis_state_worker);
- }
- else if (sc->quirks & SIXAXIS_CONTROLLER_BT)
+ } else if (sc->quirks & SIXAXIS_CONTROLLER_BT) {
ret = sixaxis_set_operational_bt(hdev);
- else if (sc->quirks & DUALSHOCK4_CONTROLLER) {
+ INIT_WORK(&sc->state_worker, sixaxis_state_worker);
+ } else if (sc->quirks & DUALSHOCK4_CONTROLLER) {
if (sc->quirks & DUALSHOCK4_CONTROLLER_BT) {
ret = dualshock4_set_operational_bt(hdev);
if (ret < 0) {
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH 03/11] Input: synaptics-rmi4 - do not update configuration in rmi_f01_probe()
From: Christopher Heiny @ 2014-02-18 21:32 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Duggan, Vincent Huang, Vivian Ly, Daniel Rosenberg,
Linus Walleij, Benjamin Tissoires, Courtney Cavin, Linux Input,
Linux Kernel
In-Reply-To: <20140217192321.GC19223@core.coreip.homeip.net>
On 02/17/2014 11:23 AM, Dmitry Torokhov wrote:
> On Fri, Feb 14, 2014 at 03:00:43PM -0800, Christopher Heiny wrote:
>> On 02/13/2014 01:54 PM, Dmitry Torokhov wrote:
>>> On Thu, Feb 13, 2014 at 11:23:44AM -0800, Christopher Heiny wrote:
>>>>> On 02/12/2014 09:27 PM, Dmitry Torokhov wrote:
>>>>>>> Do not write configuration data in probe(), we have config() for that.
>>>>>
>>>>> Then we should call config() in rmi_function_probe() to ensure that
>>>>> any platform data or device tree configuration settings get written
>>>>> to the device.
>>>
>>> Well, yes, we may elect to update device configuration in probe, but
>>> then we should not be doing that 2nd time in ->config(). We shoudl pick
>>> either one or another.
>>
>> But as the code currently stands, config() is only called when a
>> device reset is detected, not during initialization. So if there's
>> platform specific configuration data that needs to be written to a
>> function, it won't get written until after a device reset occurs,
>> which might never happen. So either we need to write that data (or
>> call config()) in each function's probe(), or in
>> rmi_function_probe().
>
> Ah, I missed the fact that we do not normally call ->config() unless
> device was reset. BTW, if device was reset, shouldn't we tear down
> everything and then reenumerate all functions?
That's only required if the reset is a result of the device being
reflashed. Since we're dropping support for user-space control of
reflash, and will instead use an in-driver reflash, we know which resets
are the result of a reflash and which aren't. The reflash code will do
the following sequence:
- tell the core to tear down the functions
- perform the reflash operation
- reset the device
- tell the core to re-enumerate the functions
Chris
^ permalink raw reply
* Re: linux-next: Tree for Feb 18 (hid/hid-cp2112.c)
From: Randy Dunlap @ 2014-02-18 16:34 UTC (permalink / raw)
To: Stephen Rothwell, linux-next
Cc: LKML, linux-input@vger.kernel.org, David Barksdale
In-Reply-To: <20140218160612.34d64514ade66fcb21a6cc0f@canb.auug.org.au>
On 02/17/14 21:06, Stephen Rothwell wrote:
> Hi all,
>
> If you see failures in building this tree due to missing declarations of
> k..alloc/free, then it may be caused by commit 2bd59d48ebfb ("cgroup:
> convert to kernfs"). Please send Tejun Heo <tj@kernel.org> a patch
> adding an inclusion of linux/slab.h to the appropriate file(s).
>
> This tree fails (more than usual) the powerpc allyesconfig build.
>
> Changes since 20140217:
>
on x86_64:
when GPIOLIB is not enabled.
Add
depends on GPIOLIB
to drivers/hid/Kconfig?
CC [M] drivers/hid/hid-cp2112.o
drivers/hid/hid-cp2112.c:162:19: error: field 'gc' has incomplete type
drivers/hid/hid-cp2112.c: In function 'cp2112_gpio_direction_input':
drivers/hid/hid-cp2112.c:171:30: warning: initialization from incompatible pointer type [enabled by default]
drivers/hid/hid-cp2112.c:171:30: warning: (near initialization for 'dev') [enabled by default]
drivers/hid/hid-cp2112.c: In function 'cp2112_gpio_set':
drivers/hid/hid-cp2112.c:200:30: warning: initialization from incompatible pointer type [enabled by default]
drivers/hid/hid-cp2112.c:200:30: warning: (near initialization for 'dev') [enabled by default]
drivers/hid/hid-cp2112.c: In function 'cp2112_gpio_get':
drivers/hid/hid-cp2112.c:218:30: warning: initialization from incompatible pointer type [enabled by default]
drivers/hid/hid-cp2112.c:218:30: warning: (near initialization for 'dev') [enabled by default]
drivers/hid/hid-cp2112.c: In function 'cp2112_gpio_direction_output':
drivers/hid/hid-cp2112.c:237:30: warning: initialization from incompatible pointer type [enabled by default]
drivers/hid/hid-cp2112.c:237:30: warning: (near initialization for 'dev') [enabled by default]
drivers/hid/hid-cp2112.c: In function 'cp2112_probe':
drivers/hid/hid-cp2112.c:944:2: error: implicit declaration of function 'gpiochip_add' [-Werror=implicit-function-declaration]
/local/lnx/next/linux-next-20140218/drivers/hid/hid-cp2112.c:962:2: error: implicit declaration of function 'gpiochip_remove' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/hid/hid-cp2112.o] Error 1
--
~Randy
^ permalink raw reply
* [PATCH] HID: cp2112: fix incorrect error propagation in cp2112_xfer()
From: Jiri Kosina @ 2014-02-18 8:56 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input, fengguang.wu
Both cp2112_read_req() and cp2112_write_req() are returning negative
value in cases of error, but cp2112_xfer() is storing the return
value into unsigned size_t-typed 'count'.
Fix this by making 'count' signed type.
Reported-by: fengguang.wu@intel.com
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cp2112.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 6d679f1..1025982 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -428,7 +428,7 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
struct hid_device *hdev = dev->hdev;
u8 buf[64];
__be16 word;
- size_t count;
+ ssize_t count;
size_t read_length = 0;
unsigned int retries;
int ret;
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH] HID: cp2112: can't be used without gpio support
From: Jiri Kosina @ 2014-02-18 8:55 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input, fengguang.wu
Add Kconfig driver dependency on GPIOLIB.
Reported-by: fengguang.wu@intel.com
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 5eaf0db..669cc19 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -177,7 +177,7 @@ config HID_PRODIKEYS
config HID_CP2112
tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
- depends on USB_HID && I2C
+ depends on USB_HID && I2C && GPIOLIB
---help---
Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
This is a HID device driver which registers as an i2c adapter
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH v3] input: sirfsoc-onkey - report onkey untouch event by detecting pin status
From: Barry Song @ 2014-02-18 6:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Xianglong Du, linux-input@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Rongjun Ying, Barry Song,
DL-SHA-WorkGroupLinux
In-Reply-To: <20140217191658.GA19223@core.coreip.homeip.net>
2014-02-18 3:16 GMT+08:00 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Fri, Feb 14, 2014 at 09:41:06PM +0800, Barry Song wrote:
>> >> Input: sirfsoc-onkey - implement open and close methods
>> >>
>> >> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> >>
>> >> We can control whetehr device generates interrupts or not so let's
>> >> implement open and close methods of input device so that we do not do any
>> >> processing until there are users.
>> >>
>> >> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>
>> Tested-by: Xianglong Du <Xianglong.Du@csr.com>
>>
>> Dmitry, will you push this one to your tree so that i can rebase others?
>
> I rebased and pushed everything out, please take a look to make sure it
> all looks good.
thanks, we have done a update to CSR local tree.
>
> Thanks.
>
> --
> Dmitry
-barry
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Daniel J Blueman @ 2014-02-18 3:36 UTC (permalink / raw)
To: Peter Stuge; +Cc: linux-usb, linux-input, Dmitry Torokhov, Clinton Sprain
In-Reply-To: <20140218022105.14422.qmail@stuge.se>
On 18 February 2014 10:21, Peter Stuge <peter@stuge.se> wrote:
> Clinton Sprain wrote:
>> I noticed your examples are both fn combos. I'm seeing something like
>> this and it seems specifically related to the fn key. Reproducible on a
>> Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
>>
>> Press key
>> Press fn
>> Release key
>> Release fn
>>
>> The key will be 'stuck' until you press another key. It seems to only
>> apply to keys that are part of a fn combo
>
> Fn is handled by the embedded controller (H8 as per Intel reference
> design in case of Macbook or Thinkpad) which has its own closed
> firmware which is rarely perfectly bug-free.
The likelyhood that the root-cause was in an embedded controller was
holding me back from reporting it.
I believe the Mac keyboards use the generic HID driver in Windows, so
it may be that there isn't a device-specific workaround, but maybe a
generic workaround, though I can't reason the mechanism without more
input-stack-fu.
I guess one test hack to confirm our sanity would be to re-read the
key state every 100ms until a matching key-up is received, logging
when it detects a disparity between key state and no key-up
received...?
--
Daniel J Blueman
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Peter Stuge @ 2014-02-18 2:21 UTC (permalink / raw)
To: Clinton Sprain
Cc: Daniel J Blueman, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov
In-Reply-To: <5302C0B2.9010506-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Clinton Sprain wrote:
> I noticed your examples are both fn combos. I'm seeing something like
> this and it seems specifically related to the fn key. Reproducible on a
> Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
>
> Press key
> Press fn
> Release key
> Release fn
>
> The key will be 'stuck' until you press another key. It seems to only
> apply to keys that are part of a fn combo
Fn is handled by the embedded controller (H8 as per Intel reference
design in case of Macbook or Thinkpad) which has its own closed
firmware which is rarely perfectly bug-free.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Clinton Sprain @ 2014-02-18 2:08 UTC (permalink / raw)
To: Daniel J Blueman, linux-usb, linux-input; +Cc: Dmitry Torokhov
In-Reply-To: <CAMVG2ss9nA4zcOT3c47EwEMrR7Z_gAQU-HTYGjdWcdYzihSnbg@mail.gmail.com>
I noticed your examples are both fn combos. I'm seeing something like
this and it seems specifically related to the fn key. Reproducible on a
Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
Press key
Press fn
Release key
Release fn
The key will be 'stuck' until you press another key. It seems to only
apply to keys that are part of a fn combo, so affected keys vary from
one model to another; it appears that if nothing is mapped to fn+key on
a given hardware, the key is not affected. For example, delete is
affected on the Macbook (which has fn+delete = backspace), but not on
the Yoga (which has a dedicated backspace key). Arrow keys are an
exception to this rule though.
Is this what you're seeing?
- Clinton
On 02/17/2014 07:23 AM, Daniel J Blueman wrote:
> Across 5+ years of kernels, I've been seeing occasional (1-2 times per
> day) key-stuck issues where eg a fn+delete combo repeats delete until
> I press delete again. I've seen this happen with fn+ctrl+left, leaving
> left held and likewise with right.
>
> This has occurred on Apple laptops, external USB keyboards and Dell
> laptops, so seems like a linux USB input issue, as I haven't seen
> occur on Windows or MacOS on the same hardware.
>
> It seems a good move for me to rebuild and run a kernel with some USB
> HID instrumentation to locate this issue over time. Without apriori
> knowledge of the linux USB input stack, what is a good initial
> approach?
>
> Thanks,
> Daniel
^ permalink raw reply
* [PATCH] HID: cp2112: convert to use hid_hw_raw_request()
From: Jiri Kosina @ 2014-02-17 23:43 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input, fengguang.wu
Commit cafebc0 ("HID: remove hid_get_raw_report in struct hid_device")
obsoletes the use of hdev->hid_get_raw_report(), as calling
hid_hw_raw_request() is functionally equivalent.
Convert cp2112 to use this notation.
Reported-by: fengguang.wu@intel.com
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cp2112.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index f326726..6d679f1 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -174,8 +174,9 @@ static int cp2112_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
u8 buf[5];
int ret;
- ret = hdev->hid_get_raw_report(hdev, CP2112_GPIO_CONFIG, buf,
- sizeof(buf), HID_FEATURE_REPORT);
+ ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
+ sizeof(buf), HID_FEATURE_REPORT,
+ HID_REQ_GET_REPORT);
if (ret != sizeof(buf)) {
hid_err(hdev, "error requesting GPIO config: %d\n", ret);
return ret;
@@ -220,8 +221,8 @@ static int cp2112_gpio_get(struct gpio_chip *chip, unsigned offset)
u8 buf[2];
int ret;
- ret = hdev->hid_get_raw_report(hdev, CP2112_GPIO_GET, buf, sizeof(buf),
- HID_FEATURE_REPORT);
+ ret = hid_hw_raw_request(hdev, CP2112_GPIO_GET, buf, sizeof(buf),
+ HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
if (ret != sizeof(buf)) {
hid_err(hdev, "error requesting GPIO values: %d\n", ret);
return ret;
@@ -241,8 +242,9 @@ static int cp2112_gpio_direction_output(struct gpio_chip *chip,
cp2112_gpio_set(chip, offset, value);
- ret = hdev->hid_get_raw_report(hdev, CP2112_GPIO_CONFIG, buf,
- sizeof(buf), HID_FEATURE_REPORT);
+ ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
+ sizeof(buf), HID_FEATURE_REPORT,
+ HID_REQ_GET_REPORT);
if (ret != sizeof(buf)) {
hid_err(hdev, "error requesting GPIO config: %d\n", ret);
return ret;
@@ -271,8 +273,8 @@ static int cp2112_hid_get(struct hid_device *hdev, unsigned char report_number,
if (!buf)
return -ENOMEM;
- ret = hdev->hid_get_raw_report(hdev, report_number, buf, count,
- report_type);
+ ret = hid_hw_raw_request(hdev, report_number, buf, count,
+ report_type, HID_REQ_GET_REPORT);
memcpy(data, buf, count);
kfree(buf);
return ret;
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH 2/2] HID: cp2112: use proper specifier for size_t
From: Jiri Kosina @ 2014-02-17 22:48 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input
In-Reply-To: <alpine.LNX.2.00.1402172346500.1192@pobox.suse.cz>
%zd is a proper format string specifier for size_t
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cp2112.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 57cf045..f326726 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -361,7 +361,7 @@ static int cp2112_read(struct cp2112_device *dev, u8 *data, size_t size)
if (ret)
return ret;
- hid_dbg(hdev, "read %d of %d bytes requested\n",
+ hid_dbg(hdev, "read %d of %zd bytes requested\n",
dev->read_length, size);
if (size > dev->read_length)
@@ -552,7 +552,7 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
if (ret < 0)
goto power_normal;
if (ret != read_length) {
- hid_warn(hdev, "short read: %d < %d\n", ret, read_length);
+ hid_warn(hdev, "short read: %d < %zd\n", ret, read_length);
ret = -EIO;
goto power_normal;
}
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH 1/2] HID: cp2112: make sysfs attributes static
From: Jiri Kosina @ 2014-02-17 22:47 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input
No need to pollute namespace with dev_attr_*.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cp2112.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index ca0f356..57cf045 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -663,7 +663,7 @@ static ssize_t name##_show(struct device *kdev, \
return ret; \
return scnprintf(buf, PAGE_SIZE, format, ##__VA_ARGS__); \
} \
-DEVICE_ATTR_RW(name);
+static DEVICE_ATTR_RW(name);
CP2112_CONFIG_ATTR(vendor_id, ({
u16 vid;
@@ -784,7 +784,7 @@ static ssize_t pstr_show(struct device *kdev,
}
#define CP2112_PSTR_ATTR(name, _report) \
-struct cp2112_pstring_attribute dev_attr_##name = { \
+static struct cp2112_pstring_attribute dev_attr_##name = { \
.attr = __ATTR(name, (S_IWUSR | S_IRUGO), pstr_show, pstr_store), \
.report = _report, \
};
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH] HID: sony: Correct Sixaxis battery reporting
From: Jiri Kosina @ 2014-02-17 22:18 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input
In-Reply-To: <1392489342-5401-1-git-send-email-frank.praznik@oh.rr.com>
On Sat, 15 Feb 2014, Frank Praznik wrote:
> The battery_charging and cable_state flags were backwards on the Sixaxis.
> The low bit of report byte 30 is 0 when charging and 1 when not.
> Bit 5 of byte 31 is 0 when a USB cable is connected and 1 when not.
>
> Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Applied, thanks Frank.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] Input: imx_keypad -Remove obsolete commment
From: Fabio Estevam @ 2014-02-17 20:26 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit 81e8f2bc (Input: imx_keypad - add pm suspend and resume support)
the imx_keypad driver supports power management, so remove the obsolete comment.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/input/keyboard/imx_keypad.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
index cbf4f80..80091c2 100644
--- a/drivers/input/keyboard/imx_keypad.c
+++ b/drivers/input/keyboard/imx_keypad.c
@@ -6,7 +6,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
- * <<Power management needs to be implemented>>.
*/
#include <linux/clk.h>
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-02-17 20:21 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, David Herrmann, open list:HID CORE LAYER,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org development
In-Reply-To: <37F7D8DE-5861-4452-B2F7-00D5E5F952B0-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On Mon, 17 Feb 2014, Marcel Holtmann wrote:
> >> Gustavo, what is your take on this please? I can take it through hid.git
> >> in case you don't have anything else queued for -rc2.
> >
> > ... ping?
> >
> > In case this doesn't get reacted upon by the end of the week, I am
> > inclined to take it through hid.git.
>
> take it through hid.git please.
Now applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* RE: [PATCH] HID: hyperv: make sure input buffer is big enough
From: Jiri Kosina @ 2014-02-17 20:21 UTC (permalink / raw)
To: KY Srinivasan
Cc: David Herrmann, linux-input@vger.kernel.org, Dan Carpenter,
Joseph Salisbury, Haiyang Zhang, linux-kernel@vger.kernel.org
In-Reply-To: <5bae77400133466d9698c925bfe58df5@BY2PR03MB299.namprd03.prod.outlook.com>
On Thu, 19 Dec 2013, KY Srinivasan wrote:
> > We need at least HID_MAX_BUFFER_SIZE (4096) bytes as input buffer. HID
> > core depends on this as it requires every input report to be at least as
> > big as advertised.
> >
> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Now applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Bruno Prémont @ 2014-02-17 20:11 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: linux-input, linux-usb, Linux Kernel, Dmitry Torokhov
In-Reply-To: <CAMVG2ss9nA4zcOT3c47EwEMrR7Z_gAQU-HTYGjdWcdYzihSnbg@mail.gmail.com>
On Mon, 17 February 2014 Daniel J Blueman <daniel@quora.org> wrote:
> Across 5+ years of kernels, I've been seeing occasional (1-2 times per
> day) key-stuck issues where eg a fn+delete combo repeats delete until
> I press delete again. I've seen this happen with fn+ctrl+left, leaving
> left held and likewise with right.
>
> This has occurred on Apple laptops, external USB keyboards and Dell
> laptops, so seems like a linux USB input issue, as I haven't seen
> occur on Windows or MacOS on the same hardware.
>
> It seems a good move for me to rebuild and run a kernel with some USB
> HID instrumentation to locate this issue over time. Without apriori
> knowledge of the linux USB input stack, what is a good initial
> approach?
I've seen some similar behavior on servers connected to a KVM switch
(USB keyboard/mouse) where without apparent reason the ENTER key became
pressed and did continuously send repeat events.
Physically touching the KVM keyboard or unbinding&rebinding the HID
keyboard solved the issue (on a console that triggers a busy loop of
agettys on active vt).
I've been tempted to attribute it to the KVM switch doing something
when switching to another server via key-press (yes, some co-worker
as at the KVM terminal when the getty load started).
On the other hand, some other co-worker had "dead keyboard" issues
though only under X, things still worked at console level, for quite
some time now. Annoying but not regular enough to look further into it.
If you want to look at what happens for you, monitoring the USB activity
for your keyboard (in combination with output from event device) might
be the most useful way (it would also catch details on when the USB
side goes into power-saving, if at all).
Bruno
^ permalink raw reply
* Re: [PATCH 2/2] Input: imx_keypad - Omit error message devm_kzalloc() failure
From: Dmitry Torokhov @ 2014-02-17 19:34 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-input, Fabio Estevam
In-Reply-To: <1392433187-7756-2-git-send-email-festevam@gmail.com>
On Sat, Feb 15, 2014 at 12:59:47AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> There is no need to print an error message in the driver for devm_kzalloc()
> failure because OOM core code handles it properly.
I'd rather keep this in. We may change OOM messaging at later time
making it less verbose.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> drivers/input/keyboard/imx_keypad.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
> index de07035..40ad98d 100644
> --- a/drivers/input/keyboard/imx_keypad.c
> +++ b/drivers/input/keyboard/imx_keypad.c
> @@ -450,10 +450,8 @@ static int imx_keypad_probe(struct platform_device *pdev)
>
> keypad = devm_kzalloc(&pdev->dev, sizeof(struct imx_keypad),
> GFP_KERNEL);
> - if (!keypad) {
> - dev_err(&pdev->dev, "not enough memory for driver data\n");
> + if (!keypad)
> return -ENOMEM;
> - }
>
> keypad->input_dev = input_dev;
> keypad->irq = irq;
> --
> 1.8.1.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: imx_keypad - Propagate the real error code on platform_get_irq() failure
From: Dmitry Torokhov @ 2014-02-17 19:33 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-input, Fabio Estevam
In-Reply-To: <1392433187-7756-1-git-send-email-festevam@gmail.com>
On Sat, Feb 15, 2014 at 12:59:46AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> No need to return a 'fake' return value on platform_get_irq() failure.
>
> Just return the error code itself instead.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thank you.
> ---
> drivers/input/keyboard/imx_keypad.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
> index cbf4f80..de07035 100644
> --- a/drivers/input/keyboard/imx_keypad.c
> +++ b/drivers/input/keyboard/imx_keypad.c
> @@ -439,7 +439,7 @@ static int imx_keypad_probe(struct platform_device *pdev)
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> dev_err(&pdev->dev, "no irq defined in platform data\n");
> - return -EINVAL;
> + return irq;
> }
>
> input_dev = devm_input_allocate_device(&pdev->dev);
> --
> 1.8.1.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH V2] ONKEY: da9052: Use correct register bit for key status
From: Dmitry Torokhov @ 2014-02-17 19:29 UTC (permalink / raw)
To: Anthony Olech; +Cc: Paul Gortmaker, linux-input, linux-kernel, David Dajun Chen
In-Reply-To: <201402121518.s1CFIkDP009092@swsrvapps-02.lan>
On Wed, Feb 12, 2014 at 02:11:34PM +0000, Anthony Olech wrote:
> The wrong register bit of the DA9052/3 PMIC registers was
> used to determine the status on the ONKEY.
>
> Also a failure in reading the status register will no longer
> result in the work queue being rescheduled as that would result
> in a (potentially) endless retry.
>
> Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
> Acked-by: David Dajun Chen <david.chen@diasemi.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 03/11] Input: synaptics-rmi4 - do not update configuration in rmi_f01_probe()
From: Dmitry Torokhov @ 2014-02-17 19:23 UTC (permalink / raw)
To: Christopher Heiny
Cc: Andrew Duggan, Vincent Huang, Vivian Ly, Daniel Rosenberg,
Linus Walleij, Benjamin Tissoires, Courtney Cavin, Linux Input,
Linux Kernel
In-Reply-To: <52FEA01B.7040604@synaptics.com>
On Fri, Feb 14, 2014 at 03:00:43PM -0800, Christopher Heiny wrote:
> On 02/13/2014 01:54 PM, Dmitry Torokhov wrote:
> >On Thu, Feb 13, 2014 at 11:23:44AM -0800, Christopher Heiny wrote:
> >>>On 02/12/2014 09:27 PM, Dmitry Torokhov wrote:
> >>>> >Do not write configuration data in probe(), we have config() for that.
> >>>
> >>>Then we should call config() in rmi_function_probe() to ensure that
> >>>any platform data or device tree configuration settings get written
> >>>to the device.
> >
> >Well, yes, we may elect to update device configuration in probe, but
> >then we should not be doing that 2nd time in ->config(). We shoudl pick
> >either one or another.
>
> But as the code currently stands, config() is only called when a
> device reset is detected, not during initialization. So if there's
> platform specific configuration data that needs to be written to a
> function, it won't get written until after a device reset occurs,
> which might never happen. So either we need to write that data (or
> call config()) in each function's probe(), or in
> rmi_function_probe().
Ah, I missed the fact that we do not normally call ->config() unless
device was reset. BTW, if device was reset, shouldn't we tear down
everything and then reenumerate all functions?
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] input: sirfsoc-onkey - report onkey untouch event by detecting pin status
From: Dmitry Torokhov @ 2014-02-17 19:16 UTC (permalink / raw)
To: Barry Song
Cc: Xianglong Du, linux-input@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, DL-SHA-WorkGroupLinux,
Rongjun Ying, Barry Song
In-Reply-To: <CAGsJ_4zjtWV3Z1AJ2bqekXn54rm=k8d4iOi_zzainCEnNGefCw@mail.gmail.com>
On Fri, Feb 14, 2014 at 09:41:06PM +0800, Barry Song wrote:
> >> Input: sirfsoc-onkey - implement open and close methods
> >>
> >> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >>
> >> We can control whetehr device generates interrupts or not so let's
> >> implement open and close methods of input device so that we do not do any
> >> processing until there are users.
> >>
> >> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Tested-by: Xianglong Du <Xianglong.Du@csr.com>
>
> Dmitry, will you push this one to your tree so that i can rebase others?
I rebased and pushed everything out, please take a look to make sure it
all looks good.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Marcel Holtmann @ 2014-02-17 16:32 UTC (permalink / raw)
To: Jiri Kosina
Cc: Gustavo F. Padovan, David Herrmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <alpine.LNX.2.00.1402171506450.1192@pobox.suse.cz>
Hi Jiri,
>>>>>>>> just got back to this, finally ... did you have time to work on this at
>>>>>>>> all, or should I just start from scratch?
>>>>>>>
>>>>>>> Sorry, no. Fosdem is this weekend and I needed to get my code ready
>>>>>>> for that. But I'll finally have time again next week.
>>>>>>
>>>>>> Okay, thanks. I then guess we should proceed with this bandaid (double
>>>>>> allocation) for 3.14
>>>>>
>>>>> It would be really nice if we could get the HIDP patch into 3.14-rc2
>>>>> and backported to stable. There have been quite a bunch of reports now
>>>>> and I dislike adding a GFP_ATOMIC allocation in HID core.
>>>>
>>>> I agree with David; Gustavo, what is your take on this, please?
>>>
>>> I leave this up to Gustavo to get this into wireless tree for 3.14-rc2.
>>>
>>> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>>
>> Thanks a lot.
>>
>> Gustavo, what is your take on this please? I can take it through hid.git
>> in case you don't have anything else queued for -rc2.
>
> ... ping?
>
> In case this doesn't get reacted upon by the end of the week, I am
> inclined to take it through hid.git.
take it through hid.git please.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v1] HID: hid-sensor-hub: Processing for duplicate physical ids
From: Jiri Kosina @ 2014-02-17 16:16 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: jic23, linux-input, Archana Patni
In-Reply-To: <1391198650-15468-1-git-send-email-srinivas.pandruvada@linux.intel.com>
On Fri, 31 Jan 2014, Srinivas Pandruvada wrote:
> In HID sensor hub, HID physical ids are used to represent different
> sensors. For example physical id of 0x73 in usage page = 0x20, represents
> an accelerometer. The HID sensor hub driver uses this physical ids to
> create platform devices using MFD. There is 1:1 correspondence between
> an phy id and a client driver.
> But in some cases these physical ids are reused. There is a phy id 0xe1,
> which specifies a custom sensor, which can exist multiple times to represent
> various custom sensors. In this case there can be multiple instances
> of client MFD drivers, processing specific custom sensor. In this
> case when client driver looks for report id or a field index, it
> should still get the report id specific to its own type. This is
> also true for reports, they should be directed towards correct instance.
> This change introduce a way to parse and tie physical devices to their
> correct instance.
> Summary of changes:
> - To get physical ids, use collections. If a collection of type=physical
> exist then use usage id as in the name of platform device name
> - As part of the platform data, we assign a hdsev instance, which has
> start and end of collection indexes. Using these indexes attributes
> can be tied to correct MFD client instances
> - When a report is received, call callback with correct hsdev instance.
> In this way using its private data stored as part of its registry, it
> can distinguish different sensors even when they have same physical and
> logical ids.
> This patch is co-authored with Archana Patni<archna.patni@intel.com>.
I have massaged the changelog a little bit, and applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox