* Re: [PATCH 1/3] cap1106: Add support for various cap11xx devices
From: Daniel Mack @ 2014-09-21 9:58 UTC (permalink / raw)
To: Matt Ranostay, galak, linux-input, linux-kernel, dmitry.torokhov,
robh+dt
Cc: devicetree
In-Reply-To: <1411268469-21283-2-git-send-email-mranostay@gmail.com>
Hi,
On 09/21/2014 05:01 AM, Matt Ranostay wrote:
> Several other variants of the cap11xx device exists with a varying
> number of capacitance detection channels. Add support for creating
> the channels dynamically.
Thanks for the patches!
>
> Signed-off-by: Matt Ranostay <mranostay@gmail.com>
> ---
> drivers/input/keyboard/cap1106.c | 54 +++++++++++++++++++---------------------
Please also add a patch to rename the file to cap11xx.c, and make sure
to export the patch with 'git format-patch -M' to detect the rename.
> diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
> index d70b65a..b9c43b5 100644
> --- a/drivers/input/keyboard/cap1106.c
> +++ b/drivers/input/keyboard/cap1106.c
> @@ -55,8 +55,6 @@
> #define CAP1106_REG_MANUFACTURER_ID 0xfe
> #define CAP1106_REG_REVISION 0xff
>
> -#define CAP1106_NUM_CHN 6
> -#define CAP1106_PRODUCT_ID 0x55
> #define CAP1106_MANUFACTURER_ID 0x5d
>
> struct cap1106_priv {
> @@ -64,7 +62,8 @@ struct cap1106_priv {
> struct input_dev *idev;
>
> /* config */
> - unsigned short keycodes[CAP1106_NUM_CHN];
> + u32 *keycodes;
unsigned short *, please. See below.
> @@ -189,27 +188,23 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> struct cap1106_priv *priv;
> struct device_node *node;
> int i, error, irq, gain = 0;
> - unsigned int val, rev;
> - u32 gain32, keycodes[CAP1106_NUM_CHN];
> + unsigned int val, prod, rev;
> + u32 gain32;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> + priv->num_channels = (unsigned long) id->driver_data;
priv->num_channels is unsigned int.
Also, a BUG_ON(!priv->num_channels) wouldn't harm.
> + priv->keycodes = devm_kzalloc(dev,
> + sizeof(u32) * priv->num_channels, GFP_KERNEL);
Use devm_kcalloc() to allocate an array.
> @@ -235,17 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
> }
>
> - BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
> -
> /* Provide some useful defaults */
> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
> - keycodes[i] = KEY_A + i;
> + for (i = 0; i < priv->num_channels; i++)
> + priv->keycodes[i] = KEY_A + i;
>
> of_property_read_u32_array(node, "linux,keycodes",
> - keycodes, ARRAY_SIZE(keycodes));
> -
> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
> - priv->keycodes[i] = keycodes[i];
> + priv->keycodes, priv->num_channels);
Hmm, no. Internally, you have to store the keycodes as unsigned short,
otherwise EVIOC{G|S}KEYCODE from usespace doesn't work.
of_property_read_u16_array() should work here for unsigned short, I
guess. Otherwise, you'd have to open-code the routine.
> @@ -313,12 +307,16 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
>
> static const struct of_device_id cap1106_dt_ids[] = {
> { .compatible = "microchip,cap1106", },
> + { .compatible = "microchip,cap1126", },
> + { .compatible = "microchip,cap1188", },
Hmm, how can that work unless you set .data to the number of channels
here? Did you test that with a DT-enabled board?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 2/3] cap1106: support for active-high interrupt option
From: Daniel Mack @ 2014-09-21 10:06 UTC (permalink / raw)
To: Matt Ranostay, galak, linux-input, linux-kernel, dmitry.torokhov,
robh+dt
Cc: devicetree
In-Reply-To: <1411268469-21283-3-git-send-email-mranostay@gmail.com>
On 09/21/2014 05:01 AM, Matt Ranostay wrote:
> Some applications need to use the active-high push-pull interrupt
> option. This allows it be enabled in the device tree child node.
>
> Signed-off-by: Matt Ranostay <mranostay@gmail.com>
> ---
> drivers/input/keyboard/cap1106.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
> index b9c43b5..33e2590 100644
> --- a/drivers/input/keyboard/cap1106.c
> +++ b/drivers/input/keyboard/cap1106.c
> @@ -234,6 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
> }
>
> + if (of_property_read_bool(node, "microchip,active-high")) {
I think the name of that property should make clear it's only changing
the interrupt output driver configuration. What about
"microchip,irq-active-high"?
Also, patch 3/3, which documents this new property, can be squashed into
this one.
> + error = regmap_write(priv->regmap, CAP1106_REG_CONFIG2, 0);
This register controls a lot more details than that. Overriding it with
0 doesn't seem right. Please use regmap_update_bits() to just update
ALT_POL, and also add a #define for it, so the next reader knows what
the code is doing :)
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 1/3] cap1106: Add support for various cap11xx devices
From: Daniel Mack @ 2014-09-21 10:53 UTC (permalink / raw)
To: Matt Ranostay, galak, linux-input, linux-kernel, dmitry.torokhov,
robh+dt
Cc: devicetree
In-Reply-To: <1411268469-21283-2-git-send-email-mranostay@gmail.com>
Hi,
On 09/21/2014 05:01 AM, Matt Ranostay wrote:
> priv->regmap = devm_regmap_init_i2c(i2c_client, &cap1106_regmap_config);
> if (IS_ERR(priv->regmap))
> return PTR_ERR(priv->regmap);
>
> - error = regmap_read(priv->regmap, CAP1106_REG_PRODUCT_ID, &val);
> - if (error)
> - return error;
> -
> - if (val != CAP1106_PRODUCT_ID) {
> - dev_err(dev, "Product ID: Got 0x%02x, expected 0x%02x\n",
> - val, CAP1106_PRODUCT_ID);
> - return -ENODEV;
> - }
> -
Btw - the purpose of this code was to detect board configuration
mismatch. After all, I2C lacks a way to properly identify peripherals,
so the more runtime checks we do at probe time, the more of a chance we
have to detect wrong setups. This device is actually well implemented
and tells us something about itself.
Hence, I'd propose to define a structure like this:
struct cap11xx_hw_model {
uint8_t product_id;
unsigned int num_channels;
};
... and attach instances of that to the members of cap1106_dt_ids[] and
cap1106_i2c_ids[]. In the probe function, check that the contents of
CAP1106_PRODUCT_ID match what is expected by the configured model.
Thanks,
Daniel
^ permalink raw reply
* [Bug 84921] Logitech Cordless Rumblepad II navigates up until a button is pressed
From: John @ 2014-09-21 14:53 UTC (permalink / raw)
To: linux-input; +Cc: bugzilla-daemon
In-Reply-To: <bug-84921-112111-Gl7DT4RsEZ@https.bugzilla.kernel.org/>
Hi, I noticed a bug in the drivers of the 'Logitech cordless rumblepad 2' controllers.
When starting SteamOS (debian based) and running steam both my controllers keep navigating up. This disappears when on all connected controllers a button is pressed. Probably because at this moment the controller connects to the receiver and takes over input from the controller. The default settings before getting any controller input seems to be 'navigate up'.
* Expected behaviour
Receiver gives no output to computer until any input from with controller received
Tested on different setups:
Steam + SteamOS has Bug
Steam + Ubuntu 14.04 has the same bug.
Steam + windows 8 does not give this bug.
Please let me know if there are any questions.
On 21-09-14 16:31, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=84921
>
> --- Comment #1 from Greg Kroah-Hartman <greg@kroah.com> ---
> On Sun, Sep 21, 2014 at 01:51:30PM +0000, bugzilla-daemon@bugzilla.kernel.org
> wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=84921
>>
>> Bug ID: 84921
>> Summary: Logitech Cordless Rumblepad II navigates up until a
>> button is pressed
> Please send this to the linux-input@vger.kernel.org mailing list.
>
^ permalink raw reply
* Re: [PATCH 1/3] cap1106: Add support for various cap11xx devices
From: Matt Ranostay @ 2014-09-21 22:46 UTC (permalink / raw)
To: Daniel Mack
Cc: Kumar Gala, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dmitry Torokhov, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <541EA149.5000408-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
On Sun, Sep 21, 2014 at 2:58 AM, Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org> wrote:
>
> Hi,
>
> On 09/21/2014 05:01 AM, Matt Ranostay wrote:
> > Several other variants of the cap11xx device exists with a varying
> > number of capacitance detection channels. Add support for creating
> > the channels dynamically.
>
> Thanks for the patches!
>
> >
> > Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > drivers/input/keyboard/cap1106.c | 54 +++++++++++++++++++---------------------
>
> Please also add a patch to rename the file to cap11xx.c, and make sure
> to export the patch with 'git format-patch -M' to detect the rename.
>
> > diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
> > index d70b65a..b9c43b5 100644
> > --- a/drivers/input/keyboard/cap1106.c
> > +++ b/drivers/input/keyboard/cap1106.c
> > @@ -55,8 +55,6 @@
> > #define CAP1106_REG_MANUFACTURER_ID 0xfe
> > #define CAP1106_REG_REVISION 0xff
> >
> > -#define CAP1106_NUM_CHN 6
> > -#define CAP1106_PRODUCT_ID 0x55
> > #define CAP1106_MANUFACTURER_ID 0x5d
> >
> > struct cap1106_priv {
> > @@ -64,7 +62,8 @@ struct cap1106_priv {
> > struct input_dev *idev;
> >
> > /* config */
> > - unsigned short keycodes[CAP1106_NUM_CHN];
> > + u32 *keycodes;
>
> unsigned short *, please. See below.
>
> > @@ -189,27 +188,23 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> > struct cap1106_priv *priv;
> > struct device_node *node;
> > int i, error, irq, gain = 0;
> > - unsigned int val, rev;
> > - u32 gain32, keycodes[CAP1106_NUM_CHN];
> > + unsigned int val, prod, rev;
> > + u32 gain32;
> >
> > priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > if (!priv)
> > return -ENOMEM;
> >
> > + priv->num_channels = (unsigned long) id->driver_data;
>
> priv->num_channels is unsigned int.
>
> Also, a BUG_ON(!priv->num_channels) wouldn't harm.
Oops. Will fix..
>
> > + priv->keycodes = devm_kzalloc(dev,
> > + sizeof(u32) * priv->num_channels, GFP_KERNEL);
>
> Use devm_kcalloc() to allocate an array.
>
> > @@ -235,17 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> > dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
> > }
> >
> > - BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
> > -
> > /* Provide some useful defaults */
> > - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
> > - keycodes[i] = KEY_A + i;
> > + for (i = 0; i < priv->num_channels; i++)
> > + priv->keycodes[i] = KEY_A + i;
> >
> > of_property_read_u32_array(node, "linux,keycodes",
> > - keycodes, ARRAY_SIZE(keycodes));
> > -
> > - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
> > - priv->keycodes[i] = keycodes[i];
> > + priv->keycodes, priv->num_channels);
>
> Hmm, no. Internally, you have to store the keycodes as unsigned short,
> otherwise EVIOC{G|S}KEYCODE from usespace doesn't work.
>
> of_property_read_u16_array() should work here for unsigned short, I
> guess. Otherwise, you'd have to open-code the routine.
>
Ok I'l test that.
> > @@ -313,12 +307,16 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> >
> > static const struct of_device_id cap1106_dt_ids[] = {
> > { .compatible = "microchip,cap1106", },
> > + { .compatible = "microchip,cap1126", },
> > + { .compatible = "microchip,cap1188", },
>
> Hmm, how can that work unless you set .data to the number of channels
> here? Did you test that with a DT-enabled board?
>
Yes it was tested on a BBB. The num_channels is set from cap1106_i2c_ids
>
> Thanks,
> Daniel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: [PATCH 1/3] cap1106: Add support for various cap11xx devices
From: Matt Ranostay @ 2014-09-22 0:28 UTC (permalink / raw)
To: Daniel Mack
Cc: Kumar Gala, linux-input, linux-kernel@vger.kernel.org,
Dmitry Torokhov, Rob Herring, devicetree@vger.kernel.org
In-Reply-To: <541EA149.5000408@zonque.org>
On Sun, Sep 21, 2014 at 2:58 AM, Daniel Mack <daniel@zonque.org> wrote:
> Hi,
>
> On 09/21/2014 05:01 AM, Matt Ranostay wrote:
>> Several other variants of the cap11xx device exists with a varying
>> number of capacitance detection channels. Add support for creating
>> the channels dynamically.
>
> Thanks for the patches!
>
>>
>> Signed-off-by: Matt Ranostay <mranostay@gmail.com>
>> ---
>> drivers/input/keyboard/cap1106.c | 54 +++++++++++++++++++---------------------
>
> Please also add a patch to rename the file to cap11xx.c, and make sure
> to export the patch with 'git format-patch -M' to detect the rename.
>
>> diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
>> index d70b65a..b9c43b5 100644
>> --- a/drivers/input/keyboard/cap1106.c
>> +++ b/drivers/input/keyboard/cap1106.c
>> @@ -55,8 +55,6 @@
>> #define CAP1106_REG_MANUFACTURER_ID 0xfe
>> #define CAP1106_REG_REVISION 0xff
>>
>> -#define CAP1106_NUM_CHN 6
>> -#define CAP1106_PRODUCT_ID 0x55
>> #define CAP1106_MANUFACTURER_ID 0x5d
>>
>> struct cap1106_priv {
>> @@ -64,7 +62,8 @@ struct cap1106_priv {
>> struct input_dev *idev;
>>
>> /* config */
>> - unsigned short keycodes[CAP1106_NUM_CHN];
>> + u32 *keycodes;
>
> unsigned short *, please. See below.
>
>> @@ -189,27 +188,23 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
>> struct cap1106_priv *priv;
>> struct device_node *node;
>> int i, error, irq, gain = 0;
>> - unsigned int val, rev;
>> - u32 gain32, keycodes[CAP1106_NUM_CHN];
>> + unsigned int val, prod, rev;
>> + u32 gain32;
>>
>> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> if (!priv)
>> return -ENOMEM;
>>
>> + priv->num_channels = (unsigned long) id->driver_data;
>
> priv->num_channels is unsigned int.
>
> Also, a BUG_ON(!priv->num_channels) wouldn't harm.
>
>> + priv->keycodes = devm_kzalloc(dev,
>> + sizeof(u32) * priv->num_channels, GFP_KERNEL);
>
> Use devm_kcalloc() to allocate an array.
>
>> @@ -235,17 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
>> dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
>> }
>>
>> - BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
>> -
>> /* Provide some useful defaults */
>> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
>> - keycodes[i] = KEY_A + i;
>> + for (i = 0; i < priv->num_channels; i++)
>> + priv->keycodes[i] = KEY_A + i;
>>
>> of_property_read_u32_array(node, "linux,keycodes",
>> - keycodes, ARRAY_SIZE(keycodes));
>> -
>> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
>> - priv->keycodes[i] = keycodes[i];
>> + priv->keycodes, priv->num_channels);
>
> Hmm, no. Internally, you have to store the keycodes as unsigned short,
> otherwise EVIOC{G|S}KEYCODE from usespace doesn't work.
>
> of_property_read_u16_array() should work here for unsigned short, I
> guess. Otherwise, you'd have to open-code the routine.
>
Problem with u16 is you'll to mark it */bits/ 16* in the device tree
entry.. I doubt that is acceptable
>> @@ -313,12 +307,16 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
>>
>> static const struct of_device_id cap1106_dt_ids[] = {
>> { .compatible = "microchip,cap1106", },
>> + { .compatible = "microchip,cap1126", },
>> + { .compatible = "microchip,cap1188", },
>
> Hmm, how can that work unless you set .data to the number of channels
> here? Did you test that with a DT-enabled board?
>
>
> Thanks,
> Daniel
^ permalink raw reply
* HOW ARE YOU?
From: Benjamin Siaka @ 2014-09-22 1:14 UTC (permalink / raw)
To: linux-input
Hello my Dear,
I will greatly appreciate my correspondence meets you in good health condition.
My name is Mr. Benjamin Siaka. I am seeking for your co-operation for investment partnership in your Country. I shall provide the FUND for the investment. When you acknowledged the receipt of this correspondence, thereafter I will give you the Full Details of my investment proposal.
I await your response in earliest.
My regards,
Mr. Benjamin Siaka.
^ 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-09-22 1:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Rafael J. Wysocki, yao.jin, linux-input
In-Reply-To: <1406702719.10148.3.camel@rzhang1-toshiba>
Hi, Dmitry,
On Wed, 2014-07-30 at 14:45 +0800, Zhang Rui wrote:
> Hi, Dmitry,
>
> On Wed, 2014-07-09 at 09:57 -0700, Dmitry Torokhov wrote:
> > On Tue, Jul 08, 2014 at 10:50:04PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, July 02, 2014 10:01:53 PM Zhang Rui wrote:
> > > > 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
> > >
> > > Hi Rui,
> > >
> > > For 3.16 I'm afraid we need to add the missing device ID to the PNP list.
> > > It is too late to do the conversion at this point IMO and we can do it later.
> >
> > But for 3.17 this patch is the right way of doing things, right?
>
> This is the patch we should use for 3.17.
> Compared with the previous version, I just removed the soc_button_array id
> from acpi pnp id list, which was added in 3.16-rc5, as an urgent fix.
>
> Please review.
>
Can you please take a look at this patch?
thanks,
rui
> From f09ff78ba75a9de0f6df333be6238a5b1bf36464 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] convert soc_button_array driver to platform bus
>
> 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.
> But ACPI folks will continue their effort on shrinking this id list by
> converting the PNP drivers to platform drivers, for the devices that don't
> belong to PNP bus in nature.
>
> convert soc_button_array driver from PNP bus to platform bus in this patch.
>
> Signed-off-by: Jin Yao <yao.jin@intel.com>
> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> ---
> drivers/acpi/acpi_pnp.c | 2 --
> drivers/input/misc/soc_button_array.c | 60 ++++++++++++++++++-----------------
> 2 files changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
> index 4ddb0dc..6703c1f 100644
> --- a/drivers/acpi/acpi_pnp.c
> +++ b/drivers/acpi/acpi_pnp.c
> @@ -14,8 +14,6 @@
> #include <linux/module.h>
>
> static const struct acpi_device_id acpi_pnp_device_ids[] = {
> - /* soc_button_array */
> - {"PNP0C40"},
> /* pata_isapnp */
> {"PNP0600"}, /* Generic ESDI/IDE/ATA compatible hard disk controller */
> /* floppy */
> 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");
^ permalink raw reply
* Re: [PATCH 2/3] cap1106: support for active-high interrupt option
From: Dmitry Torokhov @ 2014-09-22 5:56 UTC (permalink / raw)
To: Daniel Mack
Cc: Matt Ranostay, galak, linux-input, linux-kernel, robh+dt,
devicetree
In-Reply-To: <541EA326.1070404@zonque.org>
On Sun, Sep 21, 2014 at 12:06:30PM +0200, Daniel Mack wrote:
> On 09/21/2014 05:01 AM, Matt Ranostay wrote:
> > Some applications need to use the active-high push-pull interrupt
> > option. This allows it be enabled in the device tree child node.
> >
> > Signed-off-by: Matt Ranostay <mranostay@gmail.com>
> > ---
> > drivers/input/keyboard/cap1106.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
> > index b9c43b5..33e2590 100644
> > --- a/drivers/input/keyboard/cap1106.c
> > +++ b/drivers/input/keyboard/cap1106.c
> > @@ -234,6 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> > dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
> > }
> >
> > + if (of_property_read_bool(node, "microchip,active-high")) {
>
> I think the name of that property should make clear it's only changing
> the interrupt output driver configuration. What about
> "microchip,irq-active-high"?
Can we infer the setting from IRQ flags by chance?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] cap1106: Add support for various cap11xx devices
From: Dmitry Torokhov @ 2014-09-22 5:59 UTC (permalink / raw)
To: Matt Ranostay
Cc: Daniel Mack, Kumar Gala, linux-input,
linux-kernel@vger.kernel.org, Rob Herring,
devicetree@vger.kernel.org
In-Reply-To: <CAKzfze-3gmQX6oPKZvXPAqC1WxvPKS9QW1omXNA9+CSPW50BXw@mail.gmail.com>
On Sun, Sep 21, 2014 at 05:28:05PM -0700, Matt Ranostay wrote:
> On Sun, Sep 21, 2014 at 2:58 AM, Daniel Mack <daniel@zonque.org> wrote:
> > Hi,
> >
> > On 09/21/2014 05:01 AM, Matt Ranostay wrote:
> >> Several other variants of the cap11xx device exists with a varying
> >> number of capacitance detection channels. Add support for creating
> >> the channels dynamically.
> >
> > Thanks for the patches!
> >
> >>
> >> Signed-off-by: Matt Ranostay <mranostay@gmail.com>
> >> ---
> >> drivers/input/keyboard/cap1106.c | 54 +++++++++++++++++++---------------------
> >
> > Please also add a patch to rename the file to cap11xx.c, and make sure
> > to export the patch with 'git format-patch -M' to detect the rename.
> >
> >> diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
> >> index d70b65a..b9c43b5 100644
> >> --- a/drivers/input/keyboard/cap1106.c
> >> +++ b/drivers/input/keyboard/cap1106.c
> >> @@ -55,8 +55,6 @@
> >> #define CAP1106_REG_MANUFACTURER_ID 0xfe
> >> #define CAP1106_REG_REVISION 0xff
> >>
> >> -#define CAP1106_NUM_CHN 6
> >> -#define CAP1106_PRODUCT_ID 0x55
> >> #define CAP1106_MANUFACTURER_ID 0x5d
> >>
> >> struct cap1106_priv {
> >> @@ -64,7 +62,8 @@ struct cap1106_priv {
> >> struct input_dev *idev;
> >>
> >> /* config */
> >> - unsigned short keycodes[CAP1106_NUM_CHN];
> >> + u32 *keycodes;
> >
> > unsigned short *, please. See below.
> >
> >> @@ -189,27 +188,23 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> >> struct cap1106_priv *priv;
> >> struct device_node *node;
> >> int i, error, irq, gain = 0;
> >> - unsigned int val, rev;
> >> - u32 gain32, keycodes[CAP1106_NUM_CHN];
> >> + unsigned int val, prod, rev;
> >> + u32 gain32;
> >>
> >> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> >> if (!priv)
> >> return -ENOMEM;
> >>
> >> + priv->num_channels = (unsigned long) id->driver_data;
> >
> > priv->num_channels is unsigned int.
> >
> > Also, a BUG_ON(!priv->num_channels) wouldn't harm.
> >
> >> + priv->keycodes = devm_kzalloc(dev,
> >> + sizeof(u32) * priv->num_channels, GFP_KERNEL);
You do not need to allocate keycodes separately if you make a flexible length
array at the end of the main structure.
> >
> > Use devm_kcalloc() to allocate an array.
> >
> >> @@ -235,17 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
> >> dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
> >> }
> >>
> >> - BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
> >> -
> >> /* Provide some useful defaults */
> >> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
> >> - keycodes[i] = KEY_A + i;
> >> + for (i = 0; i < priv->num_channels; i++)
> >> + priv->keycodes[i] = KEY_A + i;
> >>
> >> of_property_read_u32_array(node, "linux,keycodes",
> >> - keycodes, ARRAY_SIZE(keycodes));
> >> -
> >> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
> >> - priv->keycodes[i] = keycodes[i];
> >> + priv->keycodes, priv->num_channels);
> >
> > Hmm, no. Internally, you have to store the keycodes as unsigned short,
> > otherwise EVIOC{G|S}KEYCODE from usespace doesn't work.
> >
> > of_property_read_u16_array() should work here for unsigned short, I
> > guess. Otherwise, you'd have to open-code the routine.
> >
> Problem with u16 is you'll to mark it */bits/ 16* in the device tree
> entry.. I doubt that is acceptable
You can make keymap u32. As long as you set input->keycodesize appropriately
(and we do) everything should work just fine.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] cap1106: Add support for various cap11xx devices
From: Daniel Mack @ 2014-09-22 7:36 UTC (permalink / raw)
To: Matt Ranostay
Cc: Kumar Gala, linux-input, linux-kernel@vger.kernel.org,
Dmitry Torokhov, Rob Herring, devicetree@vger.kernel.org
In-Reply-To: <CAKzfze--CZ3EVMpRgNy393ddDE64pPm0sibkVBFxWjEm8wL=dA@mail.gmail.com>
On 09/22/2014 12:46 AM, Matt Ranostay wrote:
> On Sun, Sep 21, 2014 at 2:58 AM, Daniel Mack <daniel@zonque.org> wrote:
>> On 09/21/2014 05:01 AM, Matt Ranostay wrote:
>>> @@ -313,12 +307,16 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
>>>
>>> static const struct of_device_id cap1106_dt_ids[] = {
>>> { .compatible = "microchip,cap1106", },
>>> + { .compatible = "microchip,cap1126", },
>>> + { .compatible = "microchip,cap1188", },
>>
>> Hmm, how can that work unless you set .data to the number of channels
>> here? Did you test that with a DT-enabled board?
>>
> Yes it was tested on a BBB. The num_channels is set from cap1106_i2c_ids
Ah ok. I forgot there's this fallback to the i2c ids. What others driver
do is to use of_match_device() in the probe function, and then access
->data of the returned match.
But I'm fine with falling back to cap1106_i2c_ids unless anyone else has
objections.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 2/3] cap1106: support for active-high interrupt option
From: Daniel Mack @ 2014-09-22 7:44 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Matt Ranostay, galak, linux-input, linux-kernel, robh+dt,
devicetree
In-Reply-To: <20140922055656.GA4147@core.coreip.homeip.net>
On 09/22/2014 07:56 AM, Dmitry Torokhov wrote:
> On Sun, Sep 21, 2014 at 12:06:30PM +0200, Daniel Mack wrote:
>> On 09/21/2014 05:01 AM, Matt Ranostay wrote:
>>> Some applications need to use the active-high push-pull interrupt
>>> option. This allows it be enabled in the device tree child node.
>>>
>>> Signed-off-by: Matt Ranostay <mranostay@gmail.com>
>>> ---
>>> drivers/input/keyboard/cap1106.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
>>> index b9c43b5..33e2590 100644
>>> --- a/drivers/input/keyboard/cap1106.c
>>> +++ b/drivers/input/keyboard/cap1106.c
>>> @@ -234,6 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
>>> dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
>>> }
>>>
>>> + if (of_property_read_bool(node, "microchip,active-high")) {
>>
>> I think the name of that property should make clear it's only changing
>> the interrupt output driver configuration. What about
>> "microchip,irq-active-high"?
>
> Can we infer the setting from IRQ flags by chance?
Hmm, I thought of that as well, but there could be electrical wiring
setups that want the CPU's hardware pin in push/pull mode but the one on
the sensor chip in open-drain. I'd rather not make the assuption the
pins are directly connected and have both sides individually configurable.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v2] hid: sony: Set touchpad bits in the input_configured callback
From: Jiri Kosina @ 2014-09-22 14:05 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input
In-Reply-To: <1411089301-1546-1-git-send-email-frank.praznik@oh.rr.com>
On Thu, 18 Sep 2014, Frank Praznik wrote:
> Set the DualShock4 touchpad bits in the input_configured callback
> so that they are registered properly for any input devices created
> during hid_hw_start.
>
> Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Applied, thanks Frank.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: fix timeout on probe for some wacoms
From: Jiri Kosina @ 2014-09-22 14:09 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Ping Cheng, killertofu, linux-input, linux-kernel
In-Reply-To: <1410900999-24692-1-git-send-email-benjamin.tissoires@redhat.com>
On Tue, 16 Sep 2014, Benjamin Tissoires wrote:
> Some Wacom tablets (at least the ISDv4 found in the Lenovo X230) timeout
> during probe while retrieving the input reports.
> The only time this information is valuable is during the feature_mapping
> stage, so we can ask for it there and discard the generic input reports
> retrieval.
>
> This gives a code path closer to the wacom.ko driver when it was in the
> input subtree (not HID).
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>
> Hi Jiri,
>
> I run into this today while trying to improve the generic support of the ISDv4
> sensors (those found on laptops not sold by Wacom).
> This is a regression from 3.16, in a sense that it can add up to 10 seconds to
> the boot of the laptop. So IMO, this should go as a fix for 3.17-rc6.
>
> Unfortunately, c64d883476 changed the ABI and wacom_get_report() takes now one
> less argument. I based my patch on top of the for-3.18/wacom branch, so in 3.17,
> it will not compile.
> I would personally be in favor of having c64d883476 and this one in 3.17, but
> c64d883476 will also require some manual conflict resolution (cherry-pick is
> complaining).
> I can also resend it based on the v3.17-rc5 tag, but then we will have to update
> the for-3.18/wacom when you will merge with Linus' tree.
Hi Benjamin,
c64d883476 is not really a rc7 material, so I'd not like to be
cherry-picking it for this.
My take on this would actually be to apply to for-3.18/wacom, mark it for
stable, and then make sure that c64d883476 makes it to the first
3.17-stable.
What do you think?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: fix timeout on probe for some wacoms
From: Benjamin Tissoires @ 2014-09-22 14:50 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Ping Cheng, killertofu, linux-input, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1409221608420.5523@pobox.suse.cz>
On Sep 22 2014 or thereabouts, Jiri Kosina wrote:
> On Tue, 16 Sep 2014, Benjamin Tissoires wrote:
>
> > Some Wacom tablets (at least the ISDv4 found in the Lenovo X230) timeout
> > during probe while retrieving the input reports.
> > The only time this information is valuable is during the feature_mapping
> > stage, so we can ask for it there and discard the generic input reports
> > retrieval.
> >
> > This gives a code path closer to the wacom.ko driver when it was in the
> > input subtree (not HID).
> >
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > ---
> >
> > Hi Jiri,
> >
> > I run into this today while trying to improve the generic support of the ISDv4
> > sensors (those found on laptops not sold by Wacom).
> > This is a regression from 3.16, in a sense that it can add up to 10 seconds to
> > the boot of the laptop. So IMO, this should go as a fix for 3.17-rc6.
> >
> > Unfortunately, c64d883476 changed the ABI and wacom_get_report() takes now one
> > less argument. I based my patch on top of the for-3.18/wacom branch, so in 3.17,
> > it will not compile.
> > I would personally be in favor of having c64d883476 and this one in 3.17, but
> > c64d883476 will also require some manual conflict resolution (cherry-pick is
> > complaining).
> > I can also resend it based on the v3.17-rc5 tag, but then we will have to update
> > the for-3.18/wacom when you will merge with Linus' tree.
>
> Hi Benjamin,
>
> c64d883476 is not really a rc7 material, so I'd not like to be
> cherry-picking it for this.
>
> My take on this would actually be to apply to for-3.18/wacom, mark it for
> stable, and then make sure that c64d883476 makes it to the first
> 3.17-stable.
>
> What do you think?
>
Fine by me. It will be easier to include the follow up patches this way.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: wacom: fix timeout on probe for some wacoms
From: Jiri Kosina @ 2014-09-22 14:56 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Ping Cheng, killertofu, linux-input, linux-kernel
In-Reply-To: <20140922145056.GA14547@mail.corp.redhat.com>
On Mon, 22 Sep 2014, Benjamin Tissoires wrote:
> > > I run into this today while trying to improve the generic support of
> > > the ISDv4 sensors (those found on laptops not sold by Wacom). This
> > > is a regression from 3.16, in a sense that it can add up to 10
> > > seconds to the boot of the laptop. So IMO, this should go as a fix
> > > for 3.17-rc6.
> > >
> > > Unfortunately, c64d883476 changed the ABI and wacom_get_report() takes now one
> > > less argument. I based my patch on top of the for-3.18/wacom branch, so in 3.17,
> > > it will not compile.
> > > I would personally be in favor of having c64d883476 and this one in 3.17, but
> > > c64d883476 will also require some manual conflict resolution (cherry-pick is
> > > complaining).
> > > I can also resend it based on the v3.17-rc5 tag, but then we will have to update
> > > the for-3.18/wacom when you will merge with Linus' tree.
> >
> > Hi Benjamin,
> >
> > c64d883476 is not really a rc7 material, so I'd not like to be
> > cherry-picking it for this.
> >
> > My take on this would actually be to apply to for-3.18/wacom, mark it for
> > stable, and then make sure that c64d883476 makes it to the first
> > 3.17-stable.
> >
> > What do you think?
> >
>
> Fine by me. It will be easier to include the follow up patches this way.
Ok, applied to for-3.18/wacom, annotated for stable (and made a note about
the need of cherry-picking pre-requisite commit c64d883476) and pushed
out.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* HID: wacom: regression - system freezes when resuming from S3 suspend
From: Jonas Jelten @ 2014-09-22 15:01 UTC (permalink / raw)
To: linux-input
Hi!
I encountered that my system freezes when resuming my Lenovo X220t with
integrated Wacom ISDv4 tablet from S3 suspend.
Currently running 3.17.0-rc6, I started to bisect and found that this
commit causes the issue:
commit 29b4739134c73a2873adec93346f09bb76d6a794
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Thu Jul 24 12:52:23 2014 -0700
Input: wacom - switch from an USB driver to a HID driver
Running 3.17.0-rc6, right after boot, this shows up in the log:
[ 25.843484] wacom 0003:056A:00E6.0001: usb_submit_urb(ctrl) failed: -1
[ 25.843531] wacom 0003:056A:00E6.0001: timeout initializing reports
[ 25.843886] wacom 0003:056A:00E6.0001: hidraw0: USB HID v1.11 Device
[Tablet ISD-V4] on usb-0000:00:1d.0-1.5/input0
[ 25.846036] input: Wacom ISDv4 E6 Finger as
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.1/0003:056A:00E6.0002/input/input18
When suspending, the screen goes off and about 8 seconds later, the
machine actually suspends.
Right after the (instant) resume, I can see the frame buffer I had when
suspending (X screen) for about 10 seconds. During that time, no sysrq
works. After this short period, the tty1-framebuffer appears, with
messed up linebreaks (no carriage returns occur any more), and the
capslock-led starts blinking. Sysrq keys still don't work. The system is
completely frozen.
Running the kernel from the bisected first good commit, the suspend is
faster (under 1 second) and the resume does not crash.
I just saw the "HID: wacom: fix timeout on probe for some wacoms" mail,
which probably has to do something with my problem.
Any ideas?
Cheers,
Jonas
^ permalink raw reply
* Re: HID: wacom: regression - system freezes when resuming from S3 suspend
From: Benjamin Tissoires @ 2014-09-22 15:52 UTC (permalink / raw)
To: Jonas Jelten, Jiri Kosina; +Cc: linux-input
In-Reply-To: <542039C1.1000605@in.tum.de>
On Mon, Sep 22, 2014 at 11:01 AM, Jonas Jelten <jelten@in.tum.de> wrote:
> Hi!
>
> I encountered that my system freezes when resuming my Lenovo X220t with
> integrated Wacom ISDv4 tablet from S3 suspend.
>
> Currently running 3.17.0-rc6, I started to bisect and found that this
> commit causes the issue:
>
> commit 29b4739134c73a2873adec93346f09bb76d6a794
> Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Thu Jul 24 12:52:23 2014 -0700
>
> Input: wacom - switch from an USB driver to a HID driver
>
>
> Running 3.17.0-rc6, right after boot, this shows up in the log:
>
> [ 25.843484] wacom 0003:056A:00E6.0001: usb_submit_urb(ctrl) failed: -1
> [ 25.843531] wacom 0003:056A:00E6.0001: timeout initializing reports
> [ 25.843886] wacom 0003:056A:00E6.0001: hidraw0: USB HID v1.11 Device
> [Tablet ISD-V4] on usb-0000:00:1d.0-1.5/input0
> [ 25.846036] input: Wacom ISDv4 E6 Finger as
> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.1/0003:056A:00E6.0002/input/input18
>
> When suspending, the screen goes off and about 8 seconds later, the
> machine actually suspends.
>
> Right after the (instant) resume, I can see the frame buffer I had when
> suspending (X screen) for about 10 seconds. During that time, no sysrq
> works. After this short period, the tty1-framebuffer appears, with
> messed up linebreaks (no carriage returns occur any more), and the
> capslock-led starts blinking. Sysrq keys still don't work. The system is
> completely frozen.
>
> Running the kernel from the bisected first good commit, the suspend is
> faster (under 1 second) and the resume does not crash.
>
> I just saw the "HID: wacom: fix timeout on probe for some wacoms" mail,
> which probably has to do something with my problem.
>
> Any ideas?
Yes, this commit will fix your problem. It has just been delayed for
3.17.1 as mentioned by Jiri today.
Cheers,
Benjamin
^ permalink raw reply
* [PATCH] HID: input: Finish TransducerSerialNumber implementation
From: Jason Gerecke @ 2014-09-22 16:58 UTC (permalink / raw)
To: linux-input, jkosina, benjamin.tissoires, pinglinux
Cc: Jason Gerecke, Jason Gerecke
The commit which introduced TransducerSerialNumber (368c966) is missing
two crucial implementation details. Firstly, the commit does not set the
type/code/bit/max fields as expected later down the code which can cause
the driver to crash when a tablet with this usage is connected. Secondly,
the code to send a MSC_SERIAL event to userspace when this usage is seen
in a report is nowhere to be found. This commit addresses both issues.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
drivers/hid/hid-input.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 2619f7f..abed624 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -690,6 +690,10 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
case 0x5b: /* TransducerSerialNumber */
set_bit(MSC_SERIAL, input->mscbit);
+ usage->type = EV_MSC;
+ usage->code = MSC_SERIAL;
+ bit = input->mscbit;
+ max = MSC_MAX;
break;
default: goto unknown;
@@ -1041,6 +1045,11 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
input_event(input, EV_KEY, BTN_TOUCH, value > a + ((b - a) >> 3));
}
+ if (usage->hid == (HID_UP_DIGITIZER | 0x005b)) { /* TransducerSerialNumber */
+ input_event(input, EV_MSC, MSC_SERIAL, value);
+ return;
+ }
+
if (usage->hid == (HID_UP_PID | 0x83UL)) { /* Simultaneous Effects Max */
dbg_hid("Maximum Effects - %d\n",value);
return;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] soc_button_array: fix the issue that button device can't be enumerated since 3.16-rc1
From: Dmitry Torokhov @ 2014-09-22 17:36 UTC (permalink / raw)
To: Zhang Rui; +Cc: Rafael J. Wysocki, yao.jin, linux-input
In-Reply-To: <1411350272.1280.51.camel@rzhang1-toshiba>
On Mon, Sep 22, 2014 at 09:44:32AM +0800, Zhang Rui wrote:
> Hi, Dmitry,
>
> On Wed, 2014-07-30 at 14:45 +0800, Zhang Rui wrote:
> > Hi, Dmitry,
> >
> > On Wed, 2014-07-09 at 09:57 -0700, Dmitry Torokhov wrote:
> > > On Tue, Jul 08, 2014 at 10:50:04PM +0200, Rafael J. Wysocki wrote:
> > > > On Wednesday, July 02, 2014 10:01:53 PM Zhang Rui wrote:
> > > > > 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
> > > >
> > > > Hi Rui,
> > > >
> > > > For 3.16 I'm afraid we need to add the missing device ID to the PNP list.
> > > > It is too late to do the conversion at this point IMO and we can do it later.
> > >
> > > But for 3.17 this patch is the right way of doing things, right?
> >
> > This is the patch we should use for 3.17.
> > Compared with the previous version, I just removed the soc_button_array id
> > from acpi pnp id list, which was added in 3.16-rc5, as an urgent fix.
> >
> > Please review.
> >
> Can you please take a look at this patch?
Ah, yes, it looks good. I think it's OK to hold it for 3.18 though,
right?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: add new gamepad LED constants
From: Michael Wright @ 2014-09-22 21:36 UTC (permalink / raw)
To: Pierre-Loup A. Griffais
Cc: Simon Wood, Dmitry Torokhov, David Herrmann, HID CORE LAYER,
Michael Wright, Jiri Kosina
In-Reply-To: <CAON4U=PuRK3bpK5r5PA2a3dHoqWHit1bqBMbgYtAVg9KxxY_eQ@mail.gmail.com>
Just so I can figure out the next steps, are you still convinced that
new LEDs should go in the led subsystem Dmitry?
Thanks,
--
Michael Wright
Android Frameworks
^ 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-09-23 1:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Rafael J. Wysocki, yao.jin, linux-input
In-Reply-To: <20140922173630.GA22421@core.coreip.homeip.net>
On Mon, 2014-09-22 at 10:36 -0700, Dmitry Torokhov wrote:
> On Mon, Sep 22, 2014 at 09:44:32AM +0800, Zhang Rui wrote:
> > Hi, Dmitry,
> >
> > On Wed, 2014-07-30 at 14:45 +0800, Zhang Rui wrote:
> > > Hi, Dmitry,
> > >
> > > On Wed, 2014-07-09 at 09:57 -0700, Dmitry Torokhov wrote:
> > > > On Tue, Jul 08, 2014 at 10:50:04PM +0200, Rafael J. Wysocki wrote:
> > > > > On Wednesday, July 02, 2014 10:01:53 PM Zhang Rui wrote:
> > > > > > 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
> > > > >
> > > > > Hi Rui,
> > > > >
> > > > > For 3.16 I'm afraid we need to add the missing device ID to the PNP list.
> > > > > It is too late to do the conversion at this point IMO and we can do it later.
> > > >
> > > > But for 3.17 this patch is the right way of doing things, right?
> > >
> > > This is the patch we should use for 3.17.
> > > Compared with the previous version, I just removed the soc_button_array id
> > > from acpi pnp id list, which was added in 3.16-rc5, as an urgent fix.
> > >
> > > Please review.
> > >
> > Can you please take a look at this patch?
>
> Ah, yes, it looks good. I think it's OK to hold it for 3.18 though,
> right?
>
yes.
thanks,
rui
> Thanks.
>
^ permalink raw reply
* [PATCH v2 0/2] cap1106: add support for cap11xx variants
From: Matt Ranostay @ 2014-09-23 4:04 UTC (permalink / raw)
To: galak, dmitry.torokhov, zonque, linux-input, linux-kernel,
robh+dt
Cc: devicetree, Matt Ranostay
Changes from v1:
* Reworked various devices support to check product id for
respective device.
* Added check for invalid zero channels.
* Renamed active-high option to more clear irq-active-high
* Use regmap_update_bits() instead of regmap_write_bits()
Matt Ranostay (2):
cap1106: Add support for various cap11xx devices
cap1106: support for irq-active-high option
.../devicetree/bindings/input/cap1106.txt | 4 ++
drivers/input/keyboard/cap1106.c | 70 ++++++++++++++++------
2 files changed, 55 insertions(+), 19 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/2] cap1106: Add support for various cap11xx devices
From: Matt Ranostay @ 2014-09-23 4:04 UTC (permalink / raw)
To: galak, dmitry.torokhov, zonque, linux-input, linux-kernel,
robh+dt
Cc: devicetree, Matt Ranostay
In-Reply-To: <1411445057-30048-1-git-send-email-mranostay@gmail.com>
Several other variants of the cap11xx device exists with a varying
number of capacitance detection channels. Add support for creating
the channels dynamically.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
---
drivers/input/keyboard/cap1106.c | 64 +++++++++++++++++++++++++++-------------
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
index d70b65a..07f9e88 100644
--- a/drivers/input/keyboard/cap1106.c
+++ b/drivers/input/keyboard/cap1106.c
@@ -55,8 +55,6 @@
#define CAP1106_REG_MANUFACTURER_ID 0xfe
#define CAP1106_REG_REVISION 0xff
-#define CAP1106_NUM_CHN 6
-#define CAP1106_PRODUCT_ID 0x55
#define CAP1106_MANUFACTURER_ID 0x5d
struct cap1106_priv {
@@ -64,7 +62,25 @@ struct cap1106_priv {
struct input_dev *idev;
/* config */
- unsigned short keycodes[CAP1106_NUM_CHN];
+ u32 *keycodes;
+ unsigned int num_channels;
+};
+
+struct cap11xx_hw_model {
+ uint8_t product_id;
+ unsigned int num_channels;
+};
+
+enum {
+ CAP1106,
+ CAP1126,
+ CAP1188,
+};
+
+struct cap11xx_hw_model cap11xx_devices[] = {
+ [CAP1106] = { .product_id = 0x55, .num_channels = 6 },
+ [CAP1126] = { .product_id = 0x53, .num_channels = 6 },
+ [CAP1188] = { .product_id = 0x50, .num_channels = 8 },
};
static const struct reg_default cap1106_reg_defaults[] = {
@@ -151,7 +167,7 @@ static irqreturn_t cap1106_thread_func(int irq_num, void *data)
if (ret < 0)
goto out;
- for (i = 0; i < CAP1106_NUM_CHN; i++)
+ for (i = 0; i < priv->num_channels; i++)
input_report_key(priv->idev, priv->keycodes[i],
status & (1 << i));
@@ -188,14 +204,23 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
struct device *dev = &i2c_client->dev;
struct cap1106_priv *priv;
struct device_node *node;
+ struct cap11xx_hw_model *cap = &cap11xx_devices[id->driver_data];
int i, error, irq, gain = 0;
unsigned int val, rev;
- u32 gain32, keycodes[CAP1106_NUM_CHN];
+ u32 gain32;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
+ BUG_ON(!cap->num_channels);
+
+ priv->num_channels = cap->num_channels;
+ priv->keycodes = devm_kcalloc(dev,
+ priv->num_channels, sizeof(u32), GFP_KERNEL);
+ if (!priv->keycodes)
+ return -ENOMEM;
+
priv->regmap = devm_regmap_init_i2c(i2c_client, &cap1106_regmap_config);
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
@@ -204,9 +229,9 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
if (error)
return error;
- if (val != CAP1106_PRODUCT_ID) {
+ if (val != cap->product_id) {
dev_err(dev, "Product ID: Got 0x%02x, expected 0x%02x\n",
- val, CAP1106_PRODUCT_ID);
+ val, cap->product_id);
return -ENODEV;
}
@@ -235,17 +260,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
}
- BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
-
/* Provide some useful defaults */
- for (i = 0; i < ARRAY_SIZE(keycodes); i++)
- keycodes[i] = KEY_A + i;
+ for (i = 0; i < priv->num_channels; i++)
+ priv->keycodes[i] = KEY_A + i;
of_property_read_u32_array(node, "linux,keycodes",
- keycodes, ARRAY_SIZE(keycodes));
-
- for (i = 0; i < ARRAY_SIZE(keycodes); i++)
- priv->keycodes[i] = keycodes[i];
+ priv->keycodes, priv->num_channels);
error = regmap_update_bits(priv->regmap, CAP1106_REG_MAIN_CONTROL,
CAP1106_REG_MAIN_CONTROL_GAIN_MASK,
@@ -269,17 +289,17 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
if (of_property_read_bool(node, "autorepeat"))
__set_bit(EV_REP, priv->idev->evbit);
- for (i = 0; i < CAP1106_NUM_CHN; i++)
+ for (i = 0; i < priv->num_channels; i++)
__set_bit(priv->keycodes[i], priv->idev->keybit);
__clear_bit(KEY_RESERVED, priv->idev->keybit);
priv->idev->keycode = priv->keycodes;
- priv->idev->keycodesize = sizeof(priv->keycodes[0]);
- priv->idev->keycodemax = ARRAY_SIZE(priv->keycodes);
+ priv->idev->keycodesize = sizeof(u32);
+ priv->idev->keycodemax = priv->num_channels;
priv->idev->id.vendor = CAP1106_MANUFACTURER_ID;
- priv->idev->id.product = CAP1106_PRODUCT_ID;
+ priv->idev->id.product = cap->product_id;
priv->idev->id.version = rev;
priv->idev->open = cap1106_input_open;
@@ -313,12 +333,16 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
static const struct of_device_id cap1106_dt_ids[] = {
{ .compatible = "microchip,cap1106", },
+ { .compatible = "microchip,cap1126", },
+ { .compatible = "microchip,cap1188", },
{}
};
MODULE_DEVICE_TABLE(of, cap1106_dt_ids);
static const struct i2c_device_id cap1106_i2c_ids[] = {
- { "cap1106", 0 },
+ { "cap1106", CAP1106 },
+ { "cap1126", CAP1126 },
+ { "cap1188", CAP1188 },
{}
};
MODULE_DEVICE_TABLE(i2c, cap1106_i2c_ids);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] cap1106: support for irq-active-high option
From: Matt Ranostay @ 2014-09-23 4:04 UTC (permalink / raw)
To: galak, dmitry.torokhov, zonque, linux-input, linux-kernel,
robh+dt
Cc: devicetree, Matt Ranostay
In-Reply-To: <1411445057-30048-1-git-send-email-mranostay@gmail.com>
Some applications need to use the irq-active-high push-pull option.
This allows it be enabled in the device tree child node.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
---
Documentation/devicetree/bindings/input/cap1106.txt | 4 ++++
drivers/input/keyboard/cap1106.c | 8 ++++++++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/cap1106.txt b/Documentation/devicetree/bindings/input/cap1106.txt
index 4b46390..6f5a143 100644
--- a/Documentation/devicetree/bindings/input/cap1106.txt
+++ b/Documentation/devicetree/bindings/input/cap1106.txt
@@ -26,6 +26,10 @@ Optional properties:
Valid values are 1, 2, 4, and 8.
By default, a gain of 1 is set.
+ microchip,irq-active-high: By default the interrupt pin is active low
+ open drain. This property allows using the active
+ high push-pull output.
+
linux,keycodes: Specifies an array of numeric keycode values to
be used for the channels. If this property is
omitted, KEY_A, KEY_B, etc are used as
diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
index 07f9e88..d5ce060 100644
--- a/drivers/input/keyboard/cap1106.c
+++ b/drivers/input/keyboard/cap1106.c
@@ -47,6 +47,7 @@
#define CAP1106_REG_STANDBY_SENSITIVITY 0x42
#define CAP1106_REG_STANDBY_THRESH 0x43
#define CAP1106_REG_CONFIG2 0x44
+#define CAP1106_REG_CONFIG2_ALT_POL BIT(6)
#define CAP1106_REG_SENSOR_BASE_CNT(X) (0x50 + (X))
#define CAP1106_REG_SENSOR_CALIB (0xb1 + (X))
#define CAP1106_REG_SENSOR_CALIB_LSB1 0xb9
@@ -260,6 +261,13 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
}
+ if (of_property_read_bool(node, "microchip,irq-active-high")) {
+ error = regmap_update_bits(priv->regmap, CAP1106_REG_CONFIG2,
+ CAP1106_REG_CONFIG2_ALT_POL, 0);
+ if (error)
+ return error;
+ }
+
/* Provide some useful defaults */
for (i = 0; i < priv->num_channels; i++)
priv->keycodes[i] = KEY_A + i;
--
1.9.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