Linux Input/HID development
 help / color / mirror / Atom feed
* Re: [PATCH] dt/sparc: Introduce the use of the managed version of kzalloc
From: Julia Lawall @ 2014-05-22 23:35 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Himangi Saraogi, linux-input, linux-kernel
In-Reply-To: <alpine.DEB.2.10.1405230700090.2606@hadrien>



On Fri, 23 May 2014, Julia Lawall wrote:

>
>
> On Thu, 22 May 2014, Dmitry Torokhov wrote:
>
> > Hi Himangi,
> >
> > On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote:
> > > This patch moves data allocated using kzalloc to managed data allocated
> > > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> > > functions. Also the unnecessary labels are done away with.
> >
> > Please no more partial devm conversions. I am not interested in patches
> > that change only 1 resource to be managed and leaving the rest as is.
> >
> > If you want to do devm conversion please do it if you convert all (or at
> > least majority) of resource handling to managed resources.
>
> Sorry, I don't think we are clear on what is wanted.  Himangi's patches
> convert everything where a devm function is already available (to our
> knowledge).  Do you prefer that new devm functions be introduced?  On the
> one hand, that is perhaps useful from a safety point of view.  On the
> other hand, it could lead to a huge number of rarely used devm functions
> that no one knows about and to a lot of code diversity.  So I don't know
> what is the good solution.

I guess that the concrete problem is of_ioremap?  Since that is a pretty
common function, I guess it could be reasonable to introduce a devm
function for it as well.  Or maybe one already exists and we overlooked
it.

julia

^ permalink raw reply

* Re: [PATCH] dt/sparc: Introduce the use of the managed version of kzalloc
From: Dmitry Torokhov @ 2014-05-22 23:14 UTC (permalink / raw)
  To: Julia Lawall; +Cc: Himangi Saraogi, linux-input, linux-kernel
In-Reply-To: <alpine.DEB.2.10.1405230700090.2606@hadrien>

Hi Julia,

On Fri, May 23, 2014 at 07:03:37AM +0800, Julia Lawall wrote:
> 
> 
> On Thu, 22 May 2014, Dmitry Torokhov wrote:
> 
> > Hi Himangi,
> >
> > On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote:
> > > This patch moves data allocated using kzalloc to managed data allocated
> > > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> > > functions. Also the unnecessary labels are done away with.
> >
> > Please no more partial devm conversions. I am not interested in patches
> > that change only 1 resource to be managed and leaving the rest as is.
> >
> > If you want to do devm conversion please do it if you convert all (or at
> > least majority) of resource handling to managed resources.
> 
> Sorry, I don't think we are clear on what is wanted.  Himangi's patches
> convert everything where a devm function is already available (to our
> knowledge).  Do you prefer that new devm functions be introduced?  On the
> one hand, that is perhaps useful from a safety point of view.  On the
> other hand, it could lead to a huge number of rarely used devm functions
> that no one knows about and to a lot of code diversity.  So I don't know
> what is the good solution.

I strongly dislike changes that mix managed and non-managed resources in
the same driver as it only leads to confusion: should this resource be
freed or will it be freed automatically.

I am applying patches that convert all (or almost all) resources in a
driver into managed ones, but if that is not [currently] possible then
those drivers are probably better left alone (maybe after additional
audit).

Thanks.

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH] dt/sparc: Introduce the use of the managed version of kzalloc
From: Julia Lawall @ 2014-05-22 23:03 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Himangi Saraogi, linux-input, linux-kernel, julia.lawall
In-Reply-To: <20140522194539.GA7708@core.coreip.homeip.net>



On Thu, 22 May 2014, Dmitry Torokhov wrote:

> Hi Himangi,
>
> On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote:
> > This patch moves data allocated using kzalloc to managed data allocated
> > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> > functions. Also the unnecessary labels are done away with.
>
> Please no more partial devm conversions. I am not interested in patches
> that change only 1 resource to be managed and leaving the rest as is.
>
> If you want to do devm conversion please do it if you convert all (or at
> least majority) of resource handling to managed resources.

Sorry, I don't think we are clear on what is wanted.  Himangi's patches
convert everything where a devm function is already available (to our
knowledge).  Do you prefer that new devm functions be introduced?  On the
one hand, that is perhaps useful from a safety point of view.  On the
other hand, it could lead to a huge number of rarely used devm functions
that no one knows about and to a lot of code diversity.  So I don't know
what is the good solution.

thanks,
julia

^ permalink raw reply

* Re: ABS_MT_TOUCH_MAJOR metric
From: Henrik Rydberg @ 2014-05-22 19:46 UTC (permalink / raw)
  To: Ferruh Yigit, Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <537E5027.9010705@cypress.com>

Ferruh,

> I understand this works for Dmitry ABS_X, ABS_Y,
> touchscreen reports between 0..A, screen resolution is 0..B, a mapping
> can be done 0..A -> 0..B
> 
> But for ABS_MT_TOUCH_MAJOR how this scaling can be done,
> touchscreen reports between 0..A, do we know the min/max values for
> application side?

You are right to be confused here. The axes you refer to are, in a way,
meaningless because both TOUCH_MAJOR and TOUCH_MINOR (and the corresponding
WIDTH_MAJOR and WIDTH_MINOR) are assumed to be measured in surface coordinates,
i.e., of the same scale as ABS_X and ABS_Y.

Historically, these axes have had specific values anyways, as an indication of
how large a touch area can be a the specific device. This is how userland MT
applications interpret the data. Strictly speaking, this is incorrect, but
that's how it is.

Henrik


^ permalink raw reply

* Re: [linux-sunxi] Re: [PATCH v6 0/7] mfd: AXP20x: Add support for AXP202 and AXP209
From: Dmitry Torokhov @ 2014-05-22 19:55 UTC (permalink / raw)
  To: Carlo Caione
  Cc: Lee Jones, Mark Brown, linux-arm-kernel, Maxime Ripard,
	Hans De Goede, Emilio Lopez, wens Tsai, sameo, linux-input,
	linux-doc, Liam Girdwood, Boris BREZILLON, linux-sunxi
In-Reply-To: <CAOQ7t2bqeQ35WxXKCRgj1ijJic=2w8++9idip4-f_LnP6Ucb6A@mail.gmail.com>

On Thu, May 22, 2014 at 09:15:12PM +0200, Carlo Caione wrote:
> On Wed, May 21, 2014 at 11:14 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> This set of patches introduces the core driver and support for two different
> >> >> subsystems:
> >> >>       - Regulators
> >> >
> >> >>  .../ABI/testing/sysfs-driver-input-axp-pek         |  11 +
> >> >>  Documentation/devicetree/bindings/mfd/axp20x.txt   |  93 +++++++
> >> >>  .../devicetree/bindings/vendor-prefixes.txt        |   1 +
> >> >>  arch/arm/configs/multi_v7_defconfig                |   3 +
> >> >>  arch/arm/configs/sunxi_defconfig                   |   4 +
> >> >>  drivers/input/misc/Kconfig                         |  11 +
> >> >>  drivers/input/misc/Makefile                        |   1 +
> >> >>  drivers/input/misc/axp20x-pek.c                    | 281 +++++++++++++++++++++
> >> >>  drivers/mfd/Kconfig                                |  12 +
> >> >>  drivers/mfd/Makefile                               |   1 +
> >> >>  drivers/mfd/axp20x.c                               | 258 +++++++++++++++++++
> >> >>  include/linux/mfd/axp20x.h                         | 180 +++++++++++++
> >> >>  12 files changed, 856 insertions(+)
> >> >
> >> > The regulator changes don't appear to be showing up in the diffstat or
> >> > obviously in the series?
> >>
> >> Right. Cut-and-paste error.
> >> You have already applied the regulator patches so I didn't include
> >> them here (in theory I posted this series to be picked up by Lee).
> >
> > That's fine.  Just tell me which patches need to stay together and
> > which are able to be applied through their respective subsystem trees
> > separately.  Then, once I have all the Acks I can apply no problem.
> 
> Hi Lee,
> I'd say #1 for the MFD tree, #4 for the input subsystem, #2 #3 and #5
> are documentations, #6 and #7 defconfigs add-on.

I am fine with the input piece going through MFD tree, no need to split
it from the rest.

Thanks.

-- 
Dmitry

^ permalink raw reply

* Re: ABS_MT_TOUCH_MAJOR metric
From: Michael Wright @ 2014-05-22 19:45 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: Dmitry Torokhov, linux-input@vger.kernel.org, Henrik Rydberg
In-Reply-To: <537E5027.9010705@cypress.com>

Yes, you do know the min / max values via EVICGABS. That being said,
you don't want to use these values to scale from surface units to
screen coordinates, as those only tell you the max reported width.
ABS_MT_TOUCH_MAJOR should be in the same units that ABS_X and ABS_Y
are for that device, so you should use those scaling values to do the
mapping. Theoretically the resolution should be exactly the same for
both, if you want to do the conversion into physical units (i.e. mm).

On Thu, May 22, 2014 at 12:29 PM, Ferruh Yigit <fery@cypress.com> wrote:
> On 05/22/2014 08:23 PM, Dmitry Torokhov wrote:
>> Hi Ferruh,
>>
>> On Thu, May 22, 2014 at 02:03:40PM +0300, Ferruh Yigit wrote:
>>> Hi,
>>>
>>> What is the metric of ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR events?
>>>
>>> The Linux documentation
>>> <https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt> says:
>>> "The length of the major axis of the contact. The length should be given
>>> in surface units. ..."
>>>
>>> What does "surface units" means, is it millimeter or pixels?
>> It is whatever unit the device reports, similarly to ABS_MT_POSITION_X
>> and ABS_MT_POSITION_Y. Userspace can use EVIOCGABS to map device units
>> onto common units.
>>
>> From include/uapi/linux/input.h (struct input_absinfo):
>>
>>  * Resolution for main axes (ABS_X, ABS_Y, ABS_Z) is reported in
>>  * units per millimeter (units/mm), resolution for rotational axes
>>  * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.
>>
>> Hope this helps.
>>
> Hi Dmitry,
>
> I understand this works for Dmitry ABS_X, ABS_Y,
> touchscreen reports between 0..A, screen resolution is 0..B, a mapping
> can be done 0..A -> 0..B
>
> But for ABS_MT_TOUCH_MAJOR how this scaling can be done,
> touchscreen reports between 0..A, do we know the min/max values for
> application side?
>
> --
>
> Thanks,
> ferruh
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] dt/sparc: Introduce the use of the managed version of kzalloc
From: Dmitry Torokhov @ 2014-05-22 19:45 UTC (permalink / raw)
  To: Himangi Saraogi; +Cc: linux-input, linux-kernel, julia.lawall
In-Reply-To: <20140522193430.GA16315@himangi-Dell>

Hi Himangi,

On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote:
> This patch moves data allocated using kzalloc to managed data allocated
> using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> functions. Also the unnecessary labels are done away with.

Please no more partial devm conversions. I am not interested in patches
that change only 1 resource to be managed and leaving the rest as is.

If you want to do devm conversion please do it if you convert all (or at
least majority) of resource handling to managed resources.

...

> ---
> Not compiled due to incompatible architecture.
> 

There are cross-compilers that can be used to work around such issues.

Thanks.

-- 
Dmitry

^ permalink raw reply

* Re: ABS_MT_TOUCH_MAJOR metric
From: Dmitry Torokhov @ 2014-05-22 19:42 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: linux-input@vger.kernel.org, Henrik Rydberg
In-Reply-To: <537E5027.9010705@cypress.com>

On Thu, May 22, 2014 at 10:29:43PM +0300, Ferruh Yigit wrote:
> On 05/22/2014 08:23 PM, Dmitry Torokhov wrote:
> > Hi Ferruh,
> >
> > On Thu, May 22, 2014 at 02:03:40PM +0300, Ferruh Yigit wrote:
> >> Hi,
> >>
> >> What is the metric of ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR events?
> >>
> >> The Linux documentation
> >> <https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt> says:
> >> "The length of the major axis of the contact. The length should be given
> >> in surface units. ..."
> >>
> >> What does "surface units" means, is it millimeter or pixels?
> > It is whatever unit the device reports, similarly to ABS_MT_POSITION_X
> > and ABS_MT_POSITION_Y. Userspace can use EVIOCGABS to map device units
> > onto common units.
> >
> > From include/uapi/linux/input.h (struct input_absinfo):
> >
> >  * Resolution for main axes (ABS_X, ABS_Y, ABS_Z) is reported in
> >  * units per millimeter (units/mm), resolution for rotational axes
> >  * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.
> >
> > Hope this helps.
> >
> Hi Dmitry,
> 
> I understand this works for Dmitry ABS_X, ABS_Y,
> touchscreen reports between 0..A, screen resolution is 0..B, a mapping
> can be done 0..A -> 0..B
> 
> But for ABS_MT_TOUCH_MAJOR how this scaling can be done,
> touchscreen reports between 0..A, do we know the min/max values for
> application side?

I believe in normal (all?) cases we'd use the same resolution iand
limits for ABS_MT_TOUCH_MAJOR/MINOR and ABS_X/Y and kernel not report
any mix/max on ABS_MT_TOUCH_MAJOR/MINOR.

Thanks.

-- 
Dmitry

^ permalink raw reply

* [PATCH] dt/sparc: Introduce the use of the managed version of kzalloc
From: Himangi Saraogi @ 2014-05-22 19:34 UTC (permalink / raw)
  To: Dmitry Torokhov, linux-input, linux-kernel; +Cc: julia.lawall

This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. Also the unnecessary labels are done away with.

The following Coccinelle semantic patch was used for making the change:

@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
  <+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(&pdev->dev, e1, e2)
  ...
?-kfree(e);
+kfree(DROPME,e);
  ...+>
}

@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
  <...
- kfree(e);
  ...>
}

@label1@
identifier platform.probefn, l1, l2;
expression e;
@@
probefn(...) {
  <+...
  l1:kfree(DROPME, e);
  l2:
  ...+>
}

@rem_label depends on label1@
identifier platform.probefn,label1.l1,label1.l2;
expression e;
@@
probefn(...) {
 <+...
-goto l1;
+goto l2;
 ...
-l1:kfree(DROPME, e);
 ...+>
}

Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
---
Not compiled due to incompatible architecture.

 drivers/input/misc/sparcspkr.c | 29 +++++++++--------------------
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/input/misc/sparcspkr.c b/drivers/input/misc/sparcspkr.c
index 65fd315..da9cdc6 100644
--- a/drivers/input/misc/sparcspkr.c
+++ b/drivers/input/misc/sparcspkr.c
@@ -187,29 +187,28 @@ static int bbc_beep_probe(struct platform_device *op)
 	struct sparcspkr_state *state;
 	struct bbc_beep_info *info;
 	struct device_node *dp;
-	int err = -ENOMEM;
+	int err;
 
-	state = kzalloc(sizeof(*state), GFP_KERNEL);
+	state = devm_kzalloc(&op->dev, sizeof(*state), GFP_KERNEL);
 	if (!state)
-		goto out_err;
+		return -ENOMEM;
 
 	state->name = "Sparc BBC Speaker";
 	state->event = bbc_spkr_event;
 	spin_lock_init(&state->lock);
 
 	dp = of_find_node_by_path("/");
-	err = -ENODEV;
 	if (!dp)
-		goto out_free;
+		return -ENODEV;
 
 	info = &state->u.bbc;
 	info->clock_freq = of_getintprop_default(dp, "clock-frequency", 0);
 	if (!info->clock_freq)
-		goto out_free;
+		return -ENODEV;
 
 	info->regs = of_ioremap(&op->resource[0], 0, 6, "bbc beep");
 	if (!info->regs)
-		goto out_free;
+		return -ENODEV;
 
 	platform_set_drvdata(op, state);
 
@@ -222,9 +221,6 @@ static int bbc_beep_probe(struct platform_device *op)
 out_clear_drvdata:
 	of_iounmap(&op->resource[0], info->regs, 6);
 
-out_free:
-	kfree(state);
-out_err:
 	return err;
 }
 
@@ -241,8 +237,6 @@ static int bbc_remove(struct platform_device *op)
 
 	of_iounmap(&op->resource[0], info->regs, 6);
 
-	kfree(state);
-
 	return 0;
 }
 
@@ -271,9 +265,9 @@ static int grover_beep_probe(struct platform_device *op)
 	struct grover_beep_info *info;
 	int err = -ENOMEM;
 
-	state = kzalloc(sizeof(*state), GFP_KERNEL);
+	state = devm_kzalloc(&op->dev, sizeof(*state), GFP_KERNEL);
 	if (!state)
-		goto out_err;
+		return -ENOMEM;
 
 	state->name = "Sparc Grover Speaker";
 	state->event = grover_spkr_event;
@@ -282,7 +276,7 @@ static int grover_beep_probe(struct platform_device *op)
 	info = &state->u.grover;
 	info->freq_regs = of_ioremap(&op->resource[2], 0, 2, "grover beep freq");
 	if (!info->freq_regs)
-		goto out_free;
+		return -ENOMEM;
 
 	info->enable_reg = of_ioremap(&op->resource[3], 0, 1, "grover beep enable");
 	if (!info->enable_reg)
@@ -301,9 +295,6 @@ out_clear_drvdata:
 
 out_unmap_freq_regs:
 	of_iounmap(&op->resource[2], info->freq_regs, 2);
-out_free:
-	kfree(state);
-out_err:
 	return err;
 }
 
@@ -321,8 +312,6 @@ static int grover_remove(struct platform_device *op)
 	of_iounmap(&op->resource[3], info->enable_reg, 1);
 	of_iounmap(&op->resource[2], info->freq_regs, 2);
 
-	kfree(state);
-
 	return 0;
 }
 
-- 
1.9.1


^ permalink raw reply related

* Re: ABS_MT_TOUCH_MAJOR metric
From: Ferruh Yigit @ 2014-05-22 19:29 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org, Henrik Rydberg
In-Reply-To: <20140522172353.GA1984@core.coreip.homeip.net>

On 05/22/2014 08:23 PM, Dmitry Torokhov wrote:
> Hi Ferruh,
>
> On Thu, May 22, 2014 at 02:03:40PM +0300, Ferruh Yigit wrote:
>> Hi,
>>
>> What is the metric of ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR events?
>>
>> The Linux documentation
>> <https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt> says:
>> "The length of the major axis of the contact. The length should be given
>> in surface units. ..."
>>
>> What does "surface units" means, is it millimeter or pixels?
> It is whatever unit the device reports, similarly to ABS_MT_POSITION_X
> and ABS_MT_POSITION_Y. Userspace can use EVIOCGABS to map device units
> onto common units.
>
> From include/uapi/linux/input.h (struct input_absinfo):
>
>  * Resolution for main axes (ABS_X, ABS_Y, ABS_Z) is reported in
>  * units per millimeter (units/mm), resolution for rotational axes
>  * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.
>
> Hope this helps.
>
Hi Dmitry,

I understand this works for Dmitry ABS_X, ABS_Y,
touchscreen reports between 0..A, screen resolution is 0..B, a mapping
can be done 0..A -> 0..B

But for ABS_MT_TOUCH_MAJOR how this scaling can be done,
touchscreen reports between 0..A, do we know the min/max values for
application side?

-- 

Thanks,
ferruh


^ permalink raw reply

* Re: [linux-sunxi] Re: [PATCH v6 0/7] mfd: AXP20x: Add support for AXP202 and AXP209
From: Carlo Caione @ 2014-05-22 19:15 UTC (permalink / raw)
  To: Lee Jones
  Cc: Carlo Caione, Mark Brown, linux-arm-kernel, Maxime Ripard,
	Hans De Goede, Emilio Lopez, wens Tsai, sameo, Dmitry Torokhov,
	linux-input, linux-doc, Liam Girdwood, Boris BREZILLON,
	linux-sunxi
In-Reply-To: <20140521091456.GB6679@lee--X1>

On Wed, May 21, 2014 at 11:14 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> This set of patches introduces the core driver and support for two different
>> >> subsystems:
>> >>       - Regulators
>> >
>> >>  .../ABI/testing/sysfs-driver-input-axp-pek         |  11 +
>> >>  Documentation/devicetree/bindings/mfd/axp20x.txt   |  93 +++++++
>> >>  .../devicetree/bindings/vendor-prefixes.txt        |   1 +
>> >>  arch/arm/configs/multi_v7_defconfig                |   3 +
>> >>  arch/arm/configs/sunxi_defconfig                   |   4 +
>> >>  drivers/input/misc/Kconfig                         |  11 +
>> >>  drivers/input/misc/Makefile                        |   1 +
>> >>  drivers/input/misc/axp20x-pek.c                    | 281 +++++++++++++++++++++
>> >>  drivers/mfd/Kconfig                                |  12 +
>> >>  drivers/mfd/Makefile                               |   1 +
>> >>  drivers/mfd/axp20x.c                               | 258 +++++++++++++++++++
>> >>  include/linux/mfd/axp20x.h                         | 180 +++++++++++++
>> >>  12 files changed, 856 insertions(+)
>> >
>> > The regulator changes don't appear to be showing up in the diffstat or
>> > obviously in the series?
>>
>> Right. Cut-and-paste error.
>> You have already applied the regulator patches so I didn't include
>> them here (in theory I posted this series to be picked up by Lee).
>
> That's fine.  Just tell me which patches need to stay together and
> which are able to be applied through their respective subsystem trees
> separately.  Then, once I have all the Acks I can apply no problem.

Hi Lee,
I'd say #1 for the MFD tree, #4 for the input subsystem, #2 #3 and #5
are documentations, #6 and #7 defconfigs add-on.

Thanks,

-- 
Carlo Caione

^ permalink raw reply

* Re: ABS_MT_TOUCH_MAJOR metric
From: Dmitry Torokhov @ 2014-05-22 17:23 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: linux-input@vger.kernel.org, Henrik Rydberg
In-Reply-To: <537DD98C.5090800@cypress.com>

Hi Ferruh,

On Thu, May 22, 2014 at 02:03:40PM +0300, Ferruh Yigit wrote:
> Hi,
> 
> What is the metric of ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR events?
> 
> The Linux documentation
> <https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt> says:
> "The length of the major axis of the contact. The length should be given
> in surface units. ..."
> 
> What does "surface units" means, is it millimeter or pixels?

It is whatever unit the device reports, similarly to ABS_MT_POSITION_X
and ABS_MT_POSITION_Y. Userspace can use EVIOCGABS to map device units
onto common units.

>From include/uapi/linux/input.h (struct input_absinfo):

 * Resolution for main axes (ABS_X, ABS_Y, ABS_Z) is reported in
 * units per millimeter (units/mm), resolution for rotational axes
 * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.

Hope this helps.

-- 
Dmitry

^ permalink raw reply

* [PATCH] input/keyboard: Introduce the use of the managed version of kzalloc
From: Himangi Saraogi @ 2014-05-22 15:52 UTC (permalink / raw)
  To: Michael Hennerich, Dmitry Torokhov, linux-input, linux-kernel
  Cc: julia.lawall

This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. The input_allocate_device is replaced by the corresponding
devm version and error handling code is cleaned up. Also, label err and
err1 no longer required are removed. Also, linux/device.h include is
added to make sure the devm_*() routine declarations are unambiguously
available.

The following Coccinelle semantic patch was used for making a part of
the change:

@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
  <+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(&pdev->dev, e1, e2)
  ...
?-kfree(e);
  ...+>
}

@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
  <...
- kfree(e);
  ...>
}

Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
---
 drivers/input/keyboard/adp5520-keys.c | 28 ++++++++--------------------
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/input/keyboard/adp5520-keys.c b/drivers/input/keyboard/adp5520-keys.c
index 4cc14c2..fdd6bdc 100644
--- a/drivers/input/keyboard/adp5520-keys.c
+++ b/drivers/input/keyboard/adp5520-keys.c
@@ -12,6 +12,7 @@
 #include <linux/input.h>
 #include <linux/mfd/adp5520.h>
 #include <linux/slab.h>
+#include <linux/device.h>
 
 struct adp5520_keys {
 	struct input_dev *input;
@@ -89,17 +90,15 @@ static int adp5520_keys_probe(struct platform_device *pdev)
 	if (!(pdata->rows_en_mask && pdata->cols_en_mask))
 		return -EINVAL;
 
-	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+	dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
 	if (dev == NULL) {
 		dev_err(&pdev->dev, "failed to alloc memory\n");
 		return -ENOMEM;
 	}
 
-	input = input_allocate_device();
-	if (!input) {
-		ret = -ENOMEM;
-		goto err;
-	}
+	input = devm_input_allocate_device(&pdev->dev);
+	if (!input)
+		return -ENOMEM;
 
 	dev->master = pdev->dev.parent;
 	dev->input = input;
@@ -135,7 +134,7 @@ static int adp5520_keys_probe(struct platform_device *pdev)
 	ret = input_register_device(input);
 	if (ret) {
 		dev_err(&pdev->dev, "unable to register input device\n");
-		goto err;
+		return ret;
 	}
 
 	en_mask = pdata->rows_en_mask | pdata->cols_en_mask;
@@ -157,8 +156,7 @@ static int adp5520_keys_probe(struct platform_device *pdev)
 
 	if (ret) {
 		dev_err(&pdev->dev, "failed to write\n");
-		ret = -EIO;
-		goto err1;
+		return -EIO;
 	}
 
 	dev->notifier.notifier_call = adp5520_keys_notifier;
@@ -166,19 +164,11 @@ static int adp5520_keys_probe(struct platform_device *pdev)
 			ADP5520_KP_IEN | ADP5520_KR_IEN);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to register notifier\n");
-		goto err1;
+		return ret;
 	}
 
 	platform_set_drvdata(pdev, dev);
 	return 0;
-
-err1:
-	input_unregister_device(input);
-	input = NULL;
-err:
-	input_free_device(input);
-	kfree(dev);
-	return ret;
 }
 
 static int adp5520_keys_remove(struct platform_device *pdev)
@@ -188,8 +178,6 @@ static int adp5520_keys_remove(struct platform_device *pdev)
 	adp5520_unregister_notifier(dev->master, &dev->notifier,
 				ADP5520_KP_IEN | ADP5520_KR_IEN);
 
-	input_unregister_device(dev->input);
-	kfree(dev);
 	return 0;
 }
 
-- 
1.9.1

^ permalink raw reply related

* Re: [PATCH 20/51] Input: atmel_mxt_ts - Set default irqflags when there is no pdata
From: Nick Dyer @ 2014-05-22 14:29 UTC (permalink / raw)
  To: Benson Leung, Yufeng Shen
  Cc: Dmitry Torokhov, rydberg, Daniel Kurtz, Joonyoung Shim,
	Alan Bowens, linux-input, linux-kernel, Peter Meerwald,
	Olof Johansson
In-Reply-To: <20130916022533.GA6468@core.coreip.homeip.net>

Dmitry Torokhov wrote:
> On Thu, Jul 18, 2013 at 07:17:44PM +0200, rydberg@euromail.se wrote:
>>> From: Yufeng Shen <miletus@chromium.org>
>>> This is the preparation for supporting the code path when there is
>>> platform data provided and still boot the device into a sane state
>>> with backup NVRAM config.
>>>
>>> Make the irqflags default to be IRQF_TRIGGER_FALLING if no platform data is
>>> provided.
> 
> I think if there is no platform data we should use 0 as IRQ falgs and
> assume that IRQ line is properly configured by the board code or via
> device tree.

Beson/Yufeng - do you still have a requirement to probe without platform
data or device tree? I'm just merging in some changes to add device tree
support, and it would simplify things a bit if I can drop this patch.

^ permalink raw reply

* [PATCH 2/2] Input: mcs5000_ts: use devm_* functions.
From: Beomho Seo @ 2014-05-22 11:26 UTC (permalink / raw)
  To: linux-input, dmitry.torokhov, jy0922.shim
  Cc: sachin.kamat, myungjoo.ham, jh80.chung, cw00.choi, Beomho Seo
In-Reply-To: <1400757980-15156-1-git-send-email-beomho.seo@samsung.com>

This patch use devm_* functions in mcs5000_ts driver.
As, a result, error patch and remove() function is simplified.

Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
---
 drivers/input/touchscreen/mcs5000_ts.c |   40 +++++++++-----------------------
 1 file changed, 11 insertions(+), 29 deletions(-)

diff --git a/drivers/input/touchscreen/mcs5000_ts.c b/drivers/input/touchscreen/mcs5000_ts.c
index 647e36f..b655341 100644
--- a/drivers/input/touchscreen/mcs5000_ts.c
+++ b/drivers/input/touchscreen/mcs5000_ts.c
@@ -197,11 +197,10 @@ static int mcs5000_ts_probe(struct i2c_client *client,
 		return -EINVAL;
 
 	data = kzalloc(sizeof(struct mcs5000_ts_data), GFP_KERNEL);
-	input_dev = input_allocate_device();
+	input_dev = devm_input_allocate_device(&client->dev);
 	if (!data || !input_dev) {
 		dev_err(&client->dev, "Failed to allocate memory\n");
-		ret = -ENOMEM;
-		goto err_free_mem;
+		return -ENOMEM;
 	}
 
 	data->client = client;
@@ -223,40 +222,24 @@ static int mcs5000_ts_probe(struct i2c_client *client,
 	if (data->platform_data->cfg_pin)
 		data->platform_data->cfg_pin();
 
-	ret = request_threaded_irq(client->irq, NULL, mcs5000_ts_interrupt,
-			IRQF_TRIGGER_LOW | IRQF_ONESHOT, "mcs5000_ts", data);
-
-	if (ret < 0) {
+	ret = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+			mcs5000_ts_interrupt, IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+			"mcs5000_ts", data);
+	if (ret) {
 		dev_err(&client->dev, "Failed to register interrupt\n");
-		goto err_free_mem;
+		return ret;
 	}
 
 	ret = input_register_device(data->input_dev);
-	if (ret < 0)
-		goto err_free_irq;
+	if (ret < 0) {
+		dev_err(&client->dev, "Failed to register input device\n");
+		return ret;
+	}
 
 	mcs5000_ts_phys_init(data);
 	i2c_set_clientdata(client, data);
 
 	return 0;
-
-err_free_irq:
-	free_irq(client->irq, data);
-err_free_mem:
-	input_free_device(input_dev);
-	kfree(data);
-	return ret;
-}
-
-static int mcs5000_ts_remove(struct i2c_client *client)
-{
-	struct mcs5000_ts_data *data = i2c_get_clientdata(client);
-
-	free_irq(client->irq, data);
-	input_unregister_device(data->input_dev);
-	kfree(data);
-
-	return 0;
 }
 
 #ifdef CONFIG_PM
@@ -291,7 +274,6 @@ MODULE_DEVICE_TABLE(i2c, mcs5000_ts_id);
 
 static struct i2c_driver mcs5000_ts_driver = {
 	.probe		= mcs5000_ts_probe,
-	.remove		= mcs5000_ts_remove,
 	.driver = {
 		.name = "mcs5000_ts",
 #ifdef CONFIG_PM
-- 
1.7.9.5


^ permalink raw reply related

* [PATCH 0/2] Use devm_* functions for Melfas touch device.
From: Beomho Seo @ 2014-05-22 11:26 UTC (permalink / raw)
  To: linux-input, dmitry.torokhov, jy0922.shim
  Cc: sachin.kamat, myungjoo.ham, jh80.chung, cw00.choi, Beomho Seo

This patch set devm_* functions in Melfas touche device driver.
As a result, error path and remove() function is simplified.

Beomho Seo (2):
  Input: mcs_touchkey: use devm_* functions
  Input: mcs5000_ts: use devm_* functions.

 drivers/input/keyboard/mcs_touchkey.c  |   49 +++++++++-----------------------
 drivers/input/touchscreen/mcs5000_ts.c |   40 +++++++-------------------
 2 files changed, 24 insertions(+), 65 deletions(-)
-- 
1.7.9.5

^ permalink raw reply

* [PATCH 1/2] Input: mcs_touchkey: use devm_* functions
From: Beomho Seo @ 2014-05-22 11:26 UTC (permalink / raw)
  To: linux-input, dmitry.torokhov, jy0922.shim
  Cc: sachin.kamat, myungjoo.ham, jh80.chung, cw00.choi, Beomho Seo
In-Reply-To: <1400757980-15156-1-git-send-email-beomho.seo@samsung.com>

This patch use devm_* funtions in mcs_touchkey driver.
As a result, error path and remove() funtion is simplified.

Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
---
 drivers/input/keyboard/mcs_touchkey.c |   49 +++++++++------------------------
 1 file changed, 13 insertions(+), 36 deletions(-)

diff --git a/drivers/input/keyboard/mcs_touchkey.c b/drivers/input/keyboard/mcs_touchkey.c
index 1da8e0b..74df214 100644
--- a/drivers/input/keyboard/mcs_touchkey.c
+++ b/drivers/input/keyboard/mcs_touchkey.c
@@ -103,7 +103,6 @@ static int mcs_touchkey_probe(struct i2c_client *client,
 	struct mcs_touchkey_data *data;
 	struct input_dev *input_dev;
 	unsigned int fw_reg;
-	int fw_ver;
 	int error;
 	int i;
 
@@ -116,11 +115,10 @@ static int mcs_touchkey_probe(struct i2c_client *client,
 	data = kzalloc(sizeof(struct mcs_touchkey_data) +
 			sizeof(data->keycodes[0]) * (pdata->key_maxval + 1),
 			GFP_KERNEL);
-	input_dev = input_allocate_device();
+	input_dev = devm_input_allocate_device(&client->dev);
 	if (!data || !input_dev) {
 		dev_err(&client->dev, "Failed to allocate memory\n");
-		error = -ENOMEM;
-		goto err_free_mem;
+		return -ENOMEM;
 	}
 
 	data->client = client;
@@ -139,13 +137,12 @@ static int mcs_touchkey_probe(struct i2c_client *client,
 		fw_reg = MCS5080_TOUCHKEY_FW;
 	}
 
-	fw_ver = i2c_smbus_read_byte_data(client, fw_reg);
-	if (fw_ver < 0) {
-		error = fw_ver;
+	error = i2c_smbus_read_byte_data(client, fw_reg);
+	if (error < 0) {
 		dev_err(&client->dev, "i2c read error[%d]\n", error);
-		goto err_free_mem;
-	}
-	dev_info(&client->dev, "Firmware version: %d\n", fw_ver);
+		return error;
+	} else
+		dev_info(&client->dev, "Firmware version: %d\n", error);
 
 	input_dev->name = "MELPAS MCS Touchkey";
 	input_dev->id.bustype = BUS_I2C;
@@ -176,40 +173,21 @@ static int mcs_touchkey_probe(struct i2c_client *client,
 		data->poweron(true);
 	}
 
-	error = request_threaded_irq(client->irq, NULL, mcs_touchkey_interrupt,
-				     IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
-				     client->dev.driver->name, data);
+	error = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+			mcs_touchkey_interrupt,	IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+			dev_name(&client->dev), data);
 	if (error) {
 		dev_err(&client->dev, "Failed to register interrupt\n");
-		goto err_free_mem;
+		return error;
 	}
 
 	error = input_register_device(input_dev);
 	if (error)
-		goto err_free_irq;
+		dev_err(&client->dev, "Failed to register input device\n");
+		return error;
 
 	i2c_set_clientdata(client, data);
 	return 0;
-
-err_free_irq:
-	free_irq(client->irq, data);
-err_free_mem:
-	input_free_device(input_dev);
-	kfree(data);
-	return error;
-}
-
-static int mcs_touchkey_remove(struct i2c_client *client)
-{
-	struct mcs_touchkey_data *data = i2c_get_clientdata(client);
-
-	free_irq(client->irq, data);
-	if (data->poweron)
-		data->poweron(false);
-	input_unregister_device(data->input_dev);
-	kfree(data);
-
-	return 0;
 }
 
 static void mcs_touchkey_shutdown(struct i2c_client *client)
@@ -269,7 +247,6 @@ static struct i2c_driver mcs_touchkey_driver = {
 		.pm	= &mcs_touchkey_pm_ops,
 	},
 	.probe		= mcs_touchkey_probe,
-	.remove		= mcs_touchkey_remove,
 	.shutdown       = mcs_touchkey_shutdown,
 	.id_table	= mcs_touchkey_id,
 };
-- 
1.7.9.5


^ permalink raw reply related

* ABS_MT_TOUCH_MAJOR metric
From: Ferruh Yigit @ 2014-05-22 11:03 UTC (permalink / raw)
  To: linux-input@vger.kernel.org, Dmitry Torokhov; +Cc: Henrik Rydberg

Hi,

What is the metric of ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR events?

The Linux documentation
<https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt> says:
"The length of the major axis of the contact. The length should be given
in surface units. ..."

What does "surface units" means, is it millimeter or pixels?

-- 

Thanks,
ferruh


^ permalink raw reply

* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Elias Vanderstuyft @ 2014-05-22  9:48 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Simon Wood, open list:HID CORE LAYER,
	linux-kernel@vger.kernel.org, Jiri Kosina, Anssi Hannula,
	Michal Malý, Roland Bosa
In-Reply-To: <CADbOyBTOQLewGSzXY6O1Rghw28bMtDYf5UdH9QU17DPur8hryw@mail.gmail.com>

On Tue, May 20, 2014 at 11:26 PM, Elias Vanderstuyft
<elias.vds@gmail.com> wrote:
> On Tue, May 20, 2014 at 10:58 PM, Michal Malý
> <madcatxster@devoid-pointer.net> wrote:
>> On Tuesday 20 of May 2014 16:16:12 simon@mungewell.org wrote:
>>> Regarding the question of emulated vs. real effects, can we extend the API
>>> so that applications can know which effects are really supported, and
>>> enable/disable emulation somehow?
>>
>> I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in
>> "uapi/linux/input.h" should suffice.
>
> @Dmitry:
> Now that we're talking about API changes, I would like to propose some
> additional things in the Linux FF API:
>
> - Possibility to *get* FF state variables, such as the value of the
> current GAIN, and the current AUTOCENTER:
> At the moment, only *setting* is possible.
> This poses a problem when implementing proper AUTOCENTER state
> recovery (upon closing a Windows program) in Wine, because the initial
> AUTOCENTER state was unknown.
> The same applies for GAIN.
>
> - Introduce multiple types of GAIN, apart from the current global
> GAIN, e.g. GAIN_CONSTANT and GAIN_DAMPER:
> This is mainly on request of some users, especially Logitech users: on
> Windows Logitech additionally supports to set the global Damper and
> Spring gain.
> Maybe it would be nicer to create a global gain for every supported
> Linux FF effect?

And Roland Bosa (from Logitech) also agrees with the following
addition/modification to the Linux FF API:

- Infinite iterations, or in Linux FF terms: playback of an effect
with an event count of infinity.
Right now, an event count of zero stops the effect, while the maximum
count is INT_MAX.
An event count value of '-1' can be used to indicate infinity.
(However note that it is somewhat inconsistent with the infinite
effect "duration" we already support: in that case '0' is used)
Is this feasible? (in terms of backward compatibility)

Thanks,
Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2] HID: rmi: do not handle touchscreens through hid-rmi
From: Jiri Kosina @ 2014-05-22  9:15 UTC (permalink / raw)
  To: Benjamin Tissoires; +Cc: Andrew Duggan, linux-input, linux-kernel
In-Reply-To: <1400685356-6126-1-git-send-email-benjamin.tissoires@redhat.com>

On Wed, 21 May 2014, Benjamin Tissoires wrote:

> Currently, hid-rmi drives every Synaptics product, but the touchscreens
> on the Windows tablets should be handled through hid-multitouch.
> 
> Instead of providing a long list of PIDs, rely on the scan_report
> capability to detect which should go to hid-multitouch, and which
> should not go to hid-rmi.
> 
> related bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=74241
> https://bugzilla.redhat.com/show_bug.cgi?id=1089583
> 
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply

* Re: [PATCH 1/2] Input: mcs_touchkey: add device tree support
From: Beomho Seo @ 2014-05-22  2:27 UTC (permalink / raw)
  To: Mark Rutland
  Cc: linux-input@vger.kernel.org, devicetree@vger.kernel.org,
	dmitry.torokhov@gmail.com, Joonyoung Shim, Myungjoo Ham,
	Jaehoon Chung, Chanwoo Choi
In-Reply-To: <20140521134819.GG17827@leverpostej>

Hello,

Thank you for your advice.

On 05/21/2014 10:48 PM, Mark Rutland wrote:
> On Wed, May 21, 2014 at 06:51:49AM +0100, Beomho Seo wrote:
>> Add device tree support for mcs touchkey driver.
>> Tested on exynos 4412 board.
>>
>> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
>> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
>> ---
>>  drivers/input/keyboard/mcs_touchkey.c |   73 +++++++++++++++++++++++++++++++--
>>  1 file changed, 69 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/mcs_touchkey.c b/drivers/input/keyboard/mcs_touchkey.c
>> index 1da8e0b..9bff47b 100644
>> --- a/drivers/input/keyboard/mcs_touchkey.c
>> +++ b/drivers/input/keyboard/mcs_touchkey.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/irq.h>
>>  #include <linux/slab.h>
>>  #include <linux/pm.h>
>> +#include <linux/of_gpio.h>
>>
>>  /* MCS5000 Touchkey */
>>  #define MCS5000_TOUCHKEY_STATUS		0x04
>> @@ -96,6 +97,60 @@ static irqreturn_t mcs_touchkey_interrupt(int irq, void *dev_id)
>>  	return IRQ_HANDLED;
>>  }
>>
>> +#ifdef CONFIG_OF
>> +static struct mcs_platform_data *mcs_touchkey_parse_dt(struct device *dev)
>> +{
>> +	struct mcs_platform_data *pdata;
>> +	struct device_node *np = dev->of_node;
>> +	unsigned int keymap[2];
>> +	unsigned int len;
>> +	int i = 0;
>> +	const __be32 *prop;
> 
> Hmm. Almost every use of __be32 *prop values is indicative of something
> that can be done with existing accessors. I suspect that may be true
> here...
> 
>> +
>> +	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> +	if (!pdata) {
>> +		dev_err(dev, "Failed to allocate platform data\n");
>> +		return ERR_PTR(-ENOMEM);
>> +	}
>> +
>> +	prop = of_get_property(np, "linux,code", &len);
>> +	if (!prop) {
>> +		dev_err(dev, "Failed to get code\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	if (len % sizeof(u32)) {
>> +		dev_err(dev, "Malformed keycode property\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	pdata->keymap_size = len / sizeof(u32);
> 
> Use of_property_count_u32_elems. It does all of this and returns a
> negative error code if anything is wrong.
> 
>> +
>> +	if (of_property_read_u32(np, "key_maxval", &pdata->key_maxval)) {
>> +		dev_err(dev, "Failed to get key max value data\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
> 
> What is this? This sounds like an implementation detail. Why is it in
> the DT?
> 
> Why doesn't it follow dt conventions ('-' rather than '_')?
> 

OK. I will revise *_parse_dt function on your advice.

>> +
>> +	if (pdata->keymap_size > pdata->key_maxval) {
>> +		dev_err(dev, "Key map size overflow\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	for (i = 0; i < pdata->keymap_size; i++) {
>> +		u32 code = be32_to_cpup(prop + i);
> 
> Use the DT accessors (e.g. of_property_read_u32_index). There is
> absolutely no reason to touch the raw DTB data here.
> 
>> +		keymap[i] = MCS_KEY_MAP(i, code);
>> +	}
>> +	pdata->keymap = keymap;
>> +	return pdata;
>> +}
>> +#else
>> +static inline struct mcs_platform_data *mcs_touchkey_parse_dt
>> +						(struct device *dev)
>> +{
>> +	return NULL;
>> +}
>> +#endif
>> +
>>  static int mcs_touchkey_probe(struct i2c_client *client,
>>  		const struct i2c_device_id *id)
>>  {
>> @@ -107,10 +162,14 @@ static int mcs_touchkey_probe(struct i2c_client *client,
>>  	int error;
>>  	int i;
>>
>> -	pdata = dev_get_platdata(&client->dev);
>> -	if (!pdata) {
>> -		dev_err(&client->dev, "no platform data defined\n");
>> -		return -EINVAL;
>> +	if (&client->dev.of_node)
>> +		pdata = mcs_touchkey_parse_dt(&client->dev);
>> +	else
>> +		pdata = dev_get_platdata(&client->dev);
>> +
>> +	if (IS_ERR(pdata)) {
>> +		dev_err(&client->dev, "Failed to get platform data\n");
>> +		return PTR_ERR(pdata);
>>  	}
>>
>>  	data = kzalloc(sizeof(struct mcs_touchkey_data) +
>> @@ -262,11 +321,17 @@ static const struct i2c_device_id mcs_touchkey_id[] = {
>>  };
>>  MODULE_DEVICE_TABLE(i2c, mcs_touchkey_id);
>>
>> +static struct of_device_id mcs_touchkey_dt_match[] = {
>> +	{ .compatible = "mcs5000_touchkey", },
>> +	{ .compatible = "mcs5080_touchkey", },
> 
> NAK. These do not follow the "$VENDOR,$DEVICE" pattern.
> 
> Mark.
> 

OK, I will changes to above pattern.
Additionally, Fix bindings documentation and vendor-prefixes.txt.

>> +};
>> +
>>  static struct i2c_driver mcs_touchkey_driver = {
>>  	.driver = {
>>  		.name	= "mcs_touchkey",
>>  		.owner	= THIS_MODULE,
>>  		.pm	= &mcs_touchkey_pm_ops,
>> +		.of_match_table = of_match_ptr(mcs_touchkey_dt_match),
>>  	},
>>  	.probe		= mcs_touchkey_probe,
>>  	.remove		= mcs_touchkey_remove,
>> -- 
>> 1.7.9.5
>>
> 
Again, thank you for your advice.
I'll fix them and send v2 patch soon.

Best regards,
Beomho Seo

^ permalink raw reply

* [PATCH v2 3/3] Input: mcs5000_ts: fix incorrect input device name
From: Beomho Seo @ 2014-05-22  0:02 UTC (permalink / raw)
  To: linux-input, dmitry.torokhov, Joonyoung Shim
  Cc: Myungjoo Ham, Jaehoon Chung, Chanwoo Choi

This patch fix a typo error in MELFAS MCS-5000 controller driver.

Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
---
 drivers/input/touchscreen/mcs5000_ts.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/mcs5000_ts.c b/drivers/input/touchscreen/mcs5000_ts.c
index 647e36f..97a005d 100644
--- a/drivers/input/touchscreen/mcs5000_ts.c
+++ b/drivers/input/touchscreen/mcs5000_ts.c
@@ -208,7 +208,7 @@ static int mcs5000_ts_probe(struct i2c_client *client,
 	data->input_dev = input_dev;
 	data->platform_data = dev_get_platdata(&client->dev);

-	input_dev->name = "MELPAS MCS-5000 Touchscreen";
+	input_dev->name = "MELFAS MCS-5000 Touchscreen";
 	input_dev->id.bustype = BUS_I2C;
 	input_dev->dev.parent = &client->dev;

-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 2/3] Input: mms114: fix incorrect input device name
From: Beomho Seo @ 2014-05-22  0:02 UTC (permalink / raw)
  To: linux-input, dmitry.torokhov, Joonyoung Shim
  Cc: Myungjoo Ham, Jaehoon Chung, Chanwoo Choi

This patch fix a typo error in mms114 touchscreen driver.

Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
---
 drivers/input/touchscreen/mms114.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index 9d83413..372bbf7 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -456,7 +456,7 @@ static int mms114_probe(struct i2c_client *client,
 	data->input_dev = input_dev;
 	data->pdata = pdata;

-	input_dev->name = "MELPAS MMS114 Touchscreen";
+	input_dev->name = "MELFAS MMS114 Touchscreen";
 	input_dev->id.bustype = BUS_I2C;
 	input_dev->dev.parent = &client->dev;
 	input_dev->open = mms114_input_open;
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 1/3] Input: mcs_touchkey: fix incorrect input device name
From: Beomho Seo @ 2014-05-22  0:02 UTC (permalink / raw)
  To: linux-input, dmitry.torokhov, Joonyoung Shim
  Cc: Myungjoo Ham, Jaehoon Chung, Chanwoo Choi

This patch fix a typo error in MELFAS 5000/5080 controller driver.

Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
---
 drivers/input/keyboard/mcs_touchkey.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/keyboard/mcs_touchkey.c b/drivers/input/keyboard/mcs_touchkey.c
index 1da8e0b..375b05c 100644
--- a/drivers/input/keyboard/mcs_touchkey.c
+++ b/drivers/input/keyboard/mcs_touchkey.c
@@ -147,7 +147,7 @@ static int mcs_touchkey_probe(struct i2c_client *client,
 	}
 	dev_info(&client->dev, "Firmware version: %d\n", fw_ver);

-	input_dev->name = "MELPAS MCS Touchkey";
+	input_dev->name = "MELFAS MCS Touchkey";
 	input_dev->id.bustype = BUS_I2C;
 	input_dev->dev.parent = &client->dev;
 	input_dev->evbit[0] = BIT_MASK(EV_KEY);
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 0/3] Input: fix typo error in MELFAS touch device driver
From: Beomho Seo @ 2014-05-22  0:02 UTC (permalink / raw)
  To: linux-input, dmitry.torokhov, Joonyoung Shim
  Cc: Myungjoo Ham, Jaehoon Chung, Chanwoo Choi

This patchset fix typo error in MELFAS touch device drivers.

Changes in v2:
- Add patch set for mms114 and mcs5000_ts drivers.

Beomho Seo (3):
  Input: mcs_touchkey: fix incorrect input device name
  Input: mms114: fix incorrect input device name
  Input: mcs5000_ts: fix incorrect input device name

 drivers/input/keyboard/mcs_touchkey.c  |    2 +-
 drivers/input/touchscreen/mcs5000_ts.c |    2 +-
 drivers/input/touchscreen/mms114.c     |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.7.9.5

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox