Hi Matt,
On 06/18/2015 05:58 AM, Matt Ranostay wrote:
Several cap11xx variants have LEDs that be can be controlled, this
patchset implements this functionality.
Signed-off-by: Matt Ranostay
---
drivers/input/keyboard/cap11xx.c | 141 ++-
1 file changed, 1
Hi Matt,
On 06/18/2015 05:58 AM, Matt Ranostay wrote:
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/input/cap11xx.txt | 25 ++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/cap11xx.txt
b/Documentation/devicetre
>> I have further advanced the patch to include reading via buffer, but I'm
>> having trigger 'conceptual' problems getting my head around the HID
>> device
>> issuing an interrupt when a input report is received. Looking at
>> iio_dummy_event and iios_sysfs for inspiration
> You can skip the
Several cap11xx variants have LEDs that be can be controlled, this
patchset implements this functionality.
Signed-off-by: Matt Ranostay
---
drivers/input/keyboard/cap11xx.c | 141 ++-
1 file changed, 138 insertions(+), 3 deletions(-)
diff --git a/drivers/inpu
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/input/cap11xx.txt | 25 ++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/cap11xx.txt
b/Documentation/devicetree/bindings/input/cap11xx.txt
index 7d0a300..09cdc43 100644
Changes from v4:
* Update docs to show proper address and size properties for DT bindings
* Make all LEDs blank on startup, and remove racey schedule_work calls
that did this in last revisions
* Disable cap11xx_set_sleep() if any LEDs registered
* TODO: Make cap11xx_set_sleep() able to det
On 06/15/2015 02:10 AM, Antonio Borneo wrote:
On Sat, Jun 13, 2015 at 4:26 PM, Ellen Wang wrote:
cp2112_i2c_xfer() only supports a single i2c_msg and only
reads up to 61 bytes. More than one message at a time
and longers reads just return errors. This breaks certain
important cases. For exam
cp2112_i2c_xfer() only reads up to 61 bytes, returning EIO
on longers reads. The fix is to wrap a loop around
cp2112_read() to pick up all the returned data.
Signed-off-by: Ellen Wang
---
This is like the previous patch but with the controversial
part left out.
---
drivers/hid/hid-cp2112.c |
On Wed, Jun 17, 2015 at 3:38 PM, Dmitry Torokhov
wrote:
> On Wed, Jun 17, 2015 at 02:53:26PM -0700, Matt Ranostay wrote:
>> On Wed, Jun 17, 2015 at 1:59 AM, Daniel Mack wrote:
>> > On 06/17/2015 08:49 AM, Matt Ranostay wrote:
>> >> Actually after further reading of the datasheet and testing with
On Wed, Jun 17, 2015 at 02:53:26PM -0700, Matt Ranostay wrote:
> On Wed, Jun 17, 2015 at 1:59 AM, Daniel Mack wrote:
> > On 06/17/2015 08:49 AM, Matt Ranostay wrote:
> >> Actually after further reading of the datasheet and testing with
> >> i2ctools it seems cap11xx_input_close() isn't putting the
Dudley,
On Mon, Jun 15, 2015 at 05:01:30PM +0800, Dudley Du wrote:
> V1 patches mainly have following updates compared with V0 patches:
> 1) This patch series is generated base on code base linux-next 20150612,
>so fix the patch v0 6/7 failed to apply on linux-next 20150611 issue.
> 1) Fix spe
On Wed, Jun 17, 2015 at 1:59 AM, Daniel Mack wrote:
> On 06/17/2015 08:49 AM, Matt Ranostay wrote:
>> Actually after further reading of the datasheet and testing with
>> i2ctools it seems cap11xx_input_close() isn't putting the device in
>> DEEP SLEEP mode.
>>
>> Any thoughts why?
>
> No, sorry. I
On 06/17/2015 08:49 AM, Matt Ranostay wrote:
> Actually after further reading of the datasheet and testing with
> i2ctools it seems cap11xx_input_close() isn't putting the device in
> DEEP SLEEP mode.
>
> Any thoughts why?
No, sorry. IIRC, the board I wrote the driver for didn't give me the
abili
13 matches
Mail list logo
