Re: [Y2038] [PATCH 0/3] introduce new evdev interface type

[Arnd Bergmann]

On Thursday 03 December 2015 13:54:47 Arnd Bergmann wrote:
> > > struct input_event {
> > > #if !defined(__KERNEL__) && __TIME_T_BITS == __BITS_PER_LONG
> > >struct timeval time;
> > 
> > > #else
> > > struct {
> > > union {
> > > __u32 tv_sec __attribute__((deprecated));
> > > __u32 tv_sec_monotonic;
> > > };
> > > __s32 tv_usec;
> > > } time;
> > > #endif
> > >__u16 type;
> > >__u16 code;
> > >__s32 value;
> > > };
> > 
> > I have one question here, if userspace use this structure, all helper 
> > functions
> > of timeval will not work. And userspace need to write extra helper function 
> > for
> > this fake timeval. This just create an another urgly time structure.
> 
> Correct, this is a useful side-effect of the change: any user space access to
> the event->time member that assumes it's a timeval will cause a compile-time
> warning or error (depending on the access), which helps us identify the
> broken code and fix it to use monotonic times as well as access the right
> struct members.
> 

To clarify, the code also intentionally only changes the types when
we are compiling with a new 32-bit libc: everything that builds today
will continue to build and work without warnings, unless it gets
recompiled with 64-bit time_t and needs to be fixed.

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

Re: [PATCH 0/3] introduce new evdev interface type

[Arnd Bergmann]

On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote:
> Hi, Arnd
> 
>  
>  The patch series add three evdev interface type:
>  
>  - EV_IF_LEGACY
>  send event by input_event. This is the default option, keep kernel
>  backward compatible.
> >>> 
> >>> The problem I see with this approach is that it still breaks any
> >>> legacy source code that is compiled with a new libc that uses 64-bit
> >>> time_t. If we are requiring source code changes for building users
> >>> of input devices with a new libc, we can easily get them to handle
> >>> the overflow (they normally only care about the microsecond portion
> >>> anyway, so it doesn't matter in most cases), or to use monotonic time.
> >> 
> >> I don’t think so.
> >> 
> >> Actually, from the view of userspace, EV_IF_LEGACY interface is work
> >> exactly the same as old evdev. We didn’t change anything in input_event
> >> and input_event_compat. And the problem you said will still be there,
> >> even without those patches.
> > 
> > I think we're still talking past one another. I thought we had established
> > that
> > 
> > 1. the current interface is broken when time_t changes in user space
> 
> What kinds of changes in time_t? Extending it to 64-bits in both kernel
> and userspace? Ok, I get confused here, if there are some sample codes
> or use-cases here, it will help me a lot.

We don't change time_t in the kernel, we just try to replace it
with time64_t, or ktime_t where appropriate.

What I meant is the problem when glibc defines their time_t to
be 'long long' so that user space can be built that runs after
2038. This changes the timeval and timespec definitions, so
a process that tries to use 'struct input_event' has a different
layout compared to what the kernel has.

I though that we had already discussed that multiple times.

> > 2. we can fix it by redefining struct input_event in a way that
> >   is independent of time_t
> > 3. once both user space and kernel are using the same ABI independent
> >   of time_t, we can look improving the timestamps so they don't
> >   overflow
> > 4. the monotonic timestamp interface already avoids the overflow, so
> >   it would be sufficient as a solution for 3.
> > 
> > Where did I lose you here? Did you find any other facts that I
> > was missing? I don't know whether the two new event structures make
> > the interface better in some other way, but it seems mostly unrelated
> > to either of the two problems we already have with time_t (the
> > ABI mismatch, and the use of non-monotonic timestamps).
> 
> It seems we are mismatch here.
> 
> Actually input_composite_event has the similar structure with input_event,
> but with a nicer definition, which can take both monotonic and non-monotonic
> timestamps safely.
> 
> What I assumed here, is that leaving EV_IF_LEGACY as a untouched, deprecated
> interface. If userspace try to adapt to new libc and kernel, it should move
> to new interface. The userspace can do a lazy update, keep the code untouched,
> but suffer the y2038 problem by itself.

Forcing the move to the new API is very ugly, because you can't do it
in a way that works on old kernels as well, unless you then try to support
both APIs at runtime.

Just requiring user space to switch to monotonic time is easily done,
as it can likely work either way.

> We can force kernel using monotonic time in EV_IF_LEGACY interface, and
> making input_event independent from time_t(after evdev has converted to
> input_value, it’s easy to do that), but that also imply userspace
> must change their code to fit this change. If changing userspace code is
> a mandatory option, why not to force them do a complete conversion?

Most user space programs won't care, as they don't even look at the tv_sec
portion, and the goal is to avoid having to change them.

There is still an open question to how exactly we want to get user space
to change.

We could do some compile-time trick by having a union in struct input_event
and mark the existing timeval part as deprecated, so we flag any use of the
32-bit tv_sec member, such as:

struct input_event {
#if !defined(__KERNEL__) && __TIME_T_BITS == __BITS_PER_LONG
struct timeval time;
#else
struct {
union {
__u32 tv_sec __attribute__((deprecated));
__u32 tv_sec_monotonic;
};
__s32 tv_usec;
} time;
#endif
__u16 type;
__u16 code;
__s32 value;
};

Another option is to do a runtime change, and always set the time field
to zero when the kernel is built without support for 32-bit time_t
and user space has not yet called the ioctl to change to monotonic time.

We can also do a combination of the two.

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

Re: [PATCH 0/3] introduce new evdev interface type

[Arnd Bergmann]

On Sunday 29 November 2015 17:13:50 Pingbo Wen wrote:
> > 在 2015年11月28日，00:58，Arnd Bergmann <a...@arndb.de> 写道：
> > 
> > On Friday 27 November 2015 18:00:29 WEN Pingbo wrote:
> >> To solve the y2038 problem in input_event, I had some attempts before [1],
> >> and this is the second one.
> >> 
> >> We can force userspace to use monotonic time in event timestamp, so the
> >> 'struct timeval' is enough to keep y2038-safe, as Arnd suggested. But we
> >> can not find a way to make kernel compatible with old binaries, which use
> >> realtime, and there are still some devices, which depend on realtime.
> >> 
> >> So I get a idea to add a new evdev interface, which is y2038 safe. And
> >> userspace can switch between the old and new interface via ioctl.
> >> 
> >> The patch series add three evdev interface type:
> >> 
> >> - EV_IF_LEGACY
> >>  send event by input_event. This is the default option, keep kernel
> >>  backward compatible.
> > 
> > The problem I see with this approach is that it still breaks any
> > legacy source code that is compiled with a new libc that uses 64-bit
> > time_t. If we are requiring source code changes for building users
> > of input devices with a new libc, we can easily get them to handle
> > the overflow (they normally only care about the microsecond portion
> > anyway, so it doesn't matter in most cases), or to use monotonic time.
> 
> I don’t think so.
> 
> Actually, from the view of userspace, EV_IF_LEGACY interface is work
> exactly the same as old evdev. We didn’t change anything in input_event
> and input_event_compat. And the problem you said will still be there,
> even without those patches.

I think we're still talking past one another. I thought we had established
that

1. the current interface is broken when time_t changes in user space
2. we can fix it by redefining struct input_event in a way that
   is independent of time_t
3. once both user space and kernel are using the same ABI independent
   of time_t, we can look improving the timestamps so they don't
   overflow
4. the monotonic timestamp interface already avoids the overflow, so
   it would be sufficient as a solution for 3.

Where did I lose you here? Did you find any other facts that I
was missing? I don't know whether the two new event structures make
the interface better in some other way, but it seems mostly unrelated
to either of the two problems we already have with time_t (the
ABI mismatch, and the use of non-monotonic timestamps).

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

Re: [PATCH 0/3] introduce new evdev interface type

[Arnd Bergmann]

On Friday 27 November 2015 18:00:29 WEN Pingbo wrote:
> To solve the y2038 problem in input_event, I had some attempts before [1],
> and this is the second one.
> 
> We can force userspace to use monotonic time in event timestamp, so the
> 'struct timeval' is enough to keep y2038-safe, as Arnd suggested. But we
> can not find a way to make kernel compatible with old binaries, which use
> realtime, and there are still some devices, which depend on realtime.
> 
> So I get a idea to add a new evdev interface, which is y2038 safe. And
> userspace can switch between the old and new interface via ioctl.
> 
> The patch series add three evdev interface type:
> 
> - EV_IF_LEGACY
>   send event by input_event. This is the default option, keep kernel
>   backward compatible.

The problem I see with this approach is that it still breaks any
legacy source code that is compiled with a new libc that uses 64-bit
time_t. If we are requiring source code changes for building users
of input devices with a new libc, we can easily get them to handle
the overflow (they normally only care about the microsecond portion
anyway, so it doesn't matter in most cases), or to use monotonic time.

Did I miss something here?

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

Re: [PATCH 2/3] input: evdev: add new ioctl EVIOCSIFTYPE / EVIOCGIFTYPE

[Arnd Bergmann]

On Friday 27 November 2015 18:00:31 WEN Pingbo wrote:
> This patch depends on 'introduce new evdev interface'.
> 
> Userspace cat set / get evdev interface type via the two ioctl
> commands. And default interface type is EV_IF_LEGACY, so the old binary
> will work normal with new kernel. Maybe we should change this default
> option to encourage people to move to new interface.
> 
> And since all events are stored as input_value in evdev, there are no
> need to flush evdev_client's buffer if we change clk_type and if_type.

I would split out the change to evdev_set_clk_type into a separate patch.

> + case EVIOCSIFTYPE:
> + if (get_user(if_type, ip))
> + return -EFAULT;
> +
> + return evdev_set_if_type(client, if_type);
> + case EVIOCGIFTYPE:
> + return put_user(client->if_type, ip);
>   }

This look asymmetric: EVIOCSIFTYPE uses a EVDEV_* constant, while
EVIOCGIFTYPE returns a EV_IF_* constant. Should those just
be the same constants anyway?

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

Re: [Y2038] [PATCH 0/3] fix y2038 problem in input_event

[Arnd Bergmann]

On Wednesday 04 November 2015 11:35:20 Pingbo Wen wrote:
> > 在 2015年11月3日，09:43，Dmitry Torokhov  写道：
> > 
> > On Mon, Nov 02, 2015 at 09:35:36PM +0800, WEN Pingbo wrote:
> >> Before this, I have discussed this problem with Arnd. And Arnd have
> >> an idea that by converting timeval to long / long in input_event, so that
> >> input_event structure size will be unchanged, and timeval structure will
> >> removed entirely. But we also need to avoid using CLOCK_REALTIME in
> >> userland, to keep the new input_event structure y2038 safe.
> >> 
> >> The input_event will only support monotonic time in Arnd's idea. And
> >> we still need to add wall time support for old 32-bit binary. 
> >> 
> >> Those patches try to keep original input capacity, and resolve y2038
> >> problem in input_event radically.
> >> 
> >> struct input_event is only used between kernel and userspace
> >> communication (except uinput). So that we can replace input_event
> >> with input_event64 in kernel entirely, and add a conversion in
> >> input_event_from/to_user() to keep compatible with old 32-bits binary.
> >> 
> >> userland can switch to input_event64, which is y2038 safe, via ioctl.
> > 
> > If we are forcing userspace to change the protocol I'd rather explore
> > whether we need to transmit the timestamp in each and every event. I
> > would much rather drop it and instead introduce new event code for
> > timestamp (we already have MSC_TIMESTAMP for hardware-generated
> > timestamps, maybe we can introduce new ones for kernel-generated
> > timestamps).
> 
> Yes, we can do that by replacing all input_event with input_value in kernel,
> and injecting a timestamp event after every normal event (maybe we can give
> userspace a option here).
> 
> But we still need do some conversion work in input_event_from/to_user to
> be compatible with old binary. And we need extend value field in
> ’struct input_value’ to s64, so the timestamp can be passed safely.

Right, that would be equivalent to Pingbo's approach (fixing the y2038
problem by requiring user space changes that are incompatible with
old kernels), but with a nicer interface.

The approach of leaving the event timestamps as 32 bit but requiring
montonic times in contrast would require only user space to change when
it cares about time stamps and doesn't already use montonic times.
Importantly, the modified user space would remain compatible with older
kernels as long as they support monotonic times. Those were introduced
by John Stultz in a80b83b7b8 ("Input: add infrastructure for selecting
clockid for event time stamps") and merged into linux-3.3, and are
generally a good idea because of time jumps.

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

[PATCH] HID: hid-gfrm: avoid warning for input_configured API change

[Arnd Bergmann]

The input_configured callback was recently changed to return
an 'int', but the newly added driver uses the old API:

drivers/hid/hid-gfrm.c:151:22: warning: initialization from incompatible 
pointer type [-Wincompatible-pointer-types]

This changes the driver like the other ones.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
Fixes: 34fc1322e7aa ("HID: hid-gfrm: Google Fiber TV Box remote controls")
Fixes: b2c68a2f1bab ("HID: hid-input: allow input_configured callback return 
errors")
---
Found on ARM allmodconfig with yesterday's linux-next

diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
index 4d7b7e7f0792..075b1c020846 100644
--- a/drivers/hid/hid-gfrm.c
+++ b/drivers/hid/hid-gfrm.c
@@ -88,7 +88,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct 
hid_report *report,
return (ret < 0) ? ret : -1;
 }
 
-static void gfrm_input_configured(struct hid_device *hid, struct hid_input 
*hidinput)
+static int gfrm_input_configured(struct hid_device *hid, struct hid_input 
*hidinput)
 {
/*
 * Enable software autorepeat with:
@@ -96,6 +96,7 @@ static void gfrm_input_configured(struct hid_device *hid, 
struct hid_input *hidi
 * - repeat period: 100 msec
 */
input_enable_softrepeat(hidinput->input, 400, 100);
+   return 0;
 }
 
 static int gfrm_probe(struct hid_device *hdev, const struct hid_device_id *id)

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

Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004

[Arnd Bergmann]

On Thursday 29 October 2015 20:01:51 Michael Welling wrote:
> On Fri, Oct 30, 2015 at 09:39:05AM +0900, Mark Brown wrote:
> > On Thu, Oct 29, 2015 at 03:23:31PM -0700, Dmitry Torokhov wrote:
> > 
> > > However, you have regmap in the driver core already. Mark, is it
> > > possible to have regmap API also allow doing raw underlying protocol
> > > transfer so that consumers could issue command requests without needing
> > > to know if they need to do it over i2c or spi or whatever. Or we need a
> > > notion of command registers in regmap...
> > 
> > I don't think it's a good idea to break the encapsulation of the regmap
> > and export the raw I/O functionality directly, there seem to be more bad
> > ways of using that than good.  The driver must at some point know what
> > bus it is dealing with and be able to manage this itself.
> > 
> > I don't know what "command registers" are.
> 
> With this device, if the MSB of the first byte of the transaction is 1 then
> a convertor command is encoded in that byte instead of a register address.
> 
> So here is my plan:
> - Add a function pointer for tsc2005_cmd in the struct tsc2005
> - Put the spi and i2c tsc2005_cmd versions in their respective drivers
> - Pass the cmd functions to the core via tsc200x_probe
> 
> Any objections?

Sounds good. If you end up needing more than one function pointer,
better pass a 'const' pointer to a structure of function pointers that
you can declare statically in the driver.

> Other review suggestions before I code the revision?
> Am I doing too much with a single patch?

Yes.

Please split out the DT binding changes into a separate patch, and
start with one patch that just moves the common parts out of the SPI
driver before you add the new driver.

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

Re: [PATCH v2] Input: tsc2005 - Add support for tsc2004

[Arnd Bergmann]

On Tuesday 27 October 2015 23:12:58 Dmitry Torokhov wrote:
> > Yes it does.
> > 
> > I have been told that using wildcard names is bad in other subsystems.
> > Perhaps tsc200x-core.c should be called something else because it has
> > nothing to do with the tsc2007 but it is covered by the wildcard.
> > 
> > You you think this is a big deal?
> 
> No I do not.

To clarify: using wildcards in DT bindings is bad, because that is
the only way to clearly identify small differences between related
devices there. In file names or identifiers in the kernel, there is
no problem.

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

Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004

[Arnd Bergmann]

On Thursday 29 October 2015 09:22:37 Michael Welling wrote:
> > 
> > All errors (new ones prefixed by >>):
> > 
> >drivers/built-in.o: In function `tsc2005_cmd':
> > >> tsc200x-core.c:(.text+0x2ae07f): undefined reference to 
> > >> `i2c_smbus_write_byte'
> 
> Argh!
> 
> How do I fix this one?
> 

Move all the I2C specific code into the tsc2004.c file and remove the
#ifdef. The problem is that tsc200x-core.c is used as built-in when
TOUCHSCREEN_TSC2005=y and I2C=m, so it can't call functions that are
defined in i2c-core.c.

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

Re: [Y2038] [PATCH V2] hil_mlc: convert timeval to ktime_t

[Arnd Bergmann]

On Friday 23 October 2015 20:32:50 Pingbo Wen wrote:
> >> -do_gettimeofday();
> >> -tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - 
> >> mlc->instart.tv_sec);
> >> -tv.tv_usec -= mlc->instart.tv_usec;
> >> -if (tv.tv_usec >= mlc->intimeout) goto sched;
> >> -tv.tv_usec = (mlc->intimeout - tv.tv_usec) * HZ / 
> >> USEC_PER_SEC;
> >> -if (!tv.tv_usec) goto sched;
> >> -mod_timer(_mlcs_kicker, jiffies + tv.tv_usec);
> >> +if (tmp.tv64 >= (mlc->intimeout * NSEC_PER_USEC))
> >> +goto sched;
> >> +tmp.tv64 = mlc->intimeout * NSEC_PER_USEC - tmp.tv64;
> >> +if (tmp.tv64 < NSEC_PER_USEC)
> >> +goto sched;
> >> +mod_timer(_mlcs_kicker,
> >> +jiffies + nsecs_to_jiffies(tmp.tv64));
> >>  break;
> >>  sched:
> >>  tasklet_schedule(_mlcs_tasklet);
> > 
> > If I read this right, the code is executed one for each input event such
> > as a keypress or mouse movement. In the latter case, doing 
> > nsecs_to_jiffies()
> > here is actually a bit expensive, and I stil think it can be avoided
> > by just using jiffies.
> > 
> > For the (tmp.tv64 < NSEC_PER_USEC) part, did you just do that because
> > I said this, or did you actually prove that it is required? I'm still
> > confused about what the driver is trying to achieve here.
> 
> More explanation here:)
> the judgement here is to prevent mod_timer with zero delta. I can not
> make sure whether the module have nanosecond precise, so just keep same.

Ok, I guess I was misreading the original code. What it actually does
is to check the remaining time in jiffies, not in microseconds, so the
algorithm is:

if (already expired)
schedule tasklet
else {
convert to jiffies
if (expired just now)
schedule tasklet
else
schedule tasklet from timer
}

So the entire code is meant to guarantee that the tasklet is getting
scheduled, and the first two cases are just an optimization to avoid
going through the timer. I checked the code for mod_timer to verify
that mod_timer with an argument in the past will just cause the
handler to be called at the next tick, so we don't really need the
middle case, and the logic becomes really simple if you use jiffies
instead of ktime_t.

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

Re: [Y2038] [PATCH V2] hp_sdc: fixed y2038 problem

[Arnd Bergmann]

On Friday 23 October 2015 16:53:26 WEN Pingbo wrote:
> 1. Converting timeval to ktime_t, and there is no need to handle sec and
> usec separately
> 
> 2. hp_sdc.rtv is only used for time diff, monotonic time is better here
> 
> Signed-off-by: WEN Pingbo 
> ---

This version is still correct and looks better than the first version, but
I'd still like you to improve some details:

- read some other changelogs and follow the common style. In particular,
  in the subject line say /what/ you do ("e.g. use ktime_get instead of
  do_gettimeofday",  or "avoid using struct timespec") instead of /why/,
  but then explain in the changelog text what is wrong with the current
  version and why it gets changed like this.

- Below the '---', add a short list of things you have changed since
  the previous versions. This part will not get copied into the git
  history.

> - do_gettimeofday();
> - if (tv.tv_sec > hp_sdc.rtv.tv_sec)
> - tv.tv_usec += USEC_PER_SEC;
> -
> - if (tv.tv_usec - hp_sdc.rtv.tv_usec > HP_SDC_MAX_REG_DELAY) {
> + if (time_diff.tv64 > HP_SDC_MAX_REG_DELAY) {
>   hp_sdc_transaction *curr;
>   uint8_t tmp;
>  
> - printk(KERN_WARNING PREFIX "read timeout (%ius)!\n",
> -(int)(tv.tv_usec - hp_sdc.rtv.tv_usec));
> + printk(KERN_WARNING PREFIX "read timeout (%llins)!\n",
> +time_diff.tv64);
>   curr->idx += hp_sdc.rqty;
>   hp_sdc.rqty = 0;
>   tmp = curr->seq[curr->actidx];

A tiny style comment here: please use ktime_to_ns() to extract the
nanoseconds out of the ktime_t type rather than accessing the tv64
member directly.

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

Re: [Y2038] [PATCH] hil_mlc: convert timeval to timespec64

[Arnd Bergmann]

On Friday 23 October 2015 17:12:38 Pingbo Wen wrote:
> On Monday, October 19, 2015 04:58 PM, Arnd Bergmann wrote:
> >> -do_gettimeofday();
> >> -tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - 
> >> mlc->instart.tv_sec);
> >> -tv.tv_usec -= mlc->instart.tv_usec;
> >> -if (tv.tv_usec >= mlc->intimeout) goto sched;
> >> -tv.tv_usec = (mlc->intimeout - tv.tv_usec) * HZ / 
> >> USEC_PER_SEC;
> >> -if (!tv.tv_usec) goto sched;
> >> -mod_timer(_mlcs_kicker, jiffies + tv.tv_usec);
> >> +ktime_get_ts64();
> >> +ts64.tv_nsec += NSEC_PER_SEC *
> >> +(ts64.tv_sec - mlc->instart.tv_sec);
> >> +ts64.tv_nsec -= mlc->instart.tv_nsec;
> > 
> > tv_nsec will overflow here for any timeout over 4.3 seconds, where it
> > used to overflow after 4294 seconds. This is almost certainly a bug.
> > 
> > You could work around that by using ktime_get_ns() to get a nanosecond
> > value right away, but a 64-bit number is more expensive to convert to
> > jiffies.
> 
> You are right, I didn't notice that tv_nsec is a 32bit variable. Maybe
> we should use ktime_t here, so that handling sec and nsec separately is
> needless.
> 
> Using jiffies here will need to take more codes to handle jiffies overflow
> carefully. I think coverting 64bit number to jiffies is the price we must 
> take, if we use 64bit version here.

Handling the jiffies overflow is trivially done through the time_before()
and time_after() helpers, like


start = jiffies;
...
now = jiffies;
timeout = start + HZ * timeout_usec / USEC_PER_SEC;
if (time_after(now, start + timeout_jiffies)
timeout();
else
mod_timer(timer, start + timeout_jiffies);

The time_after function works because unsigned overflow is well-defined
in C (unlike signed overflow).

As a side-note, please take the time to delete any lines from the original
mail that you are not referencing when you reply.

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

Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

[Arnd Bergmann]

On Friday 23 October 2015 19:29:39 WEN Pingbo wrote:
> 1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no 
> need to handle sec and usec separately
> 
> 2. hp_sdc.rtv is only used for time diff, monotonic time is better here
> 
> Signed-off-by: WEN Pingbo 
> ---
> 
> Version 2:
> Using ktime_t instead of struct timespec64
> Version 3:
> Commit msg adjustment, and using ktime_to_ns to extract nsecs 
> 

The patch looks good now, but the changelog still needs a tiny bit of
work. First of all, your line wrapping is off, please start a new line
after around 70 characters as you do in an email.

Also, we don't normally have enumerated lists in a changelog, just use
normal text. The best changelogs typically have three paragraphs:

The first paragraph describes what the driver currently does. For really
obvious cases, this can be combined with the second paragraph.

The second paragraph explains why that is bad. This is where you can
mention the monotonic time vs real time issue and say whether we
just want the timeval removed to fix the kernel in general or whether
this particular driver is broken.

The third paragraph explains what the patch does to resolve the issue
described in the second one. This is also where you can list other
approaches that would have solved the problem, and why you picked on
over the others.

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

Re: [Y2038] [PATCH V2] hil_mlc: convert timeval to ktime_t

[Arnd Bergmann]

On Friday 23 October 2015 17:24:59 WEN Pingbo wrote:
> Using struct timeval will cause time overflow in 2038, replacing it with
> ktime_t. And we don't need to handle sec and nsec separately.
> 
> Since mlc->lcv_t is only interested in seconds, directly using
> time64_t here.
> 
> And monotonic time is better here, since the original driver don't care
> the wall time.
> 
> In addition, the original driver try to covert usec to jiffies manually in
> hilse_donode(). This is not a universal and safe way, using
> nsecs_to_jiffies() to fix that.
> 
> Signed-off-by: WEN Pingbo 

The changelog text looks good.

> +++ b/drivers/input/serio/hil_mlc.c
> @@ -274,14 +274,12 @@ static int hilse_match(hil_mlc *mlc, int unused)
>  /* An LCV used to prevent runaway loops, forces 5 second sleep when reset. */
>  static int hilse_init_lcv(hil_mlc *mlc, int unused)
>  {
> - struct timeval tv;
> + time64_t now = ktime_get_seconds();
>  
> - do_gettimeofday();
> -
> - if (mlc->lcv && (tv.tv_sec - mlc->lcv_tv.tv_sec) < 5)
> + if (mlc->lcv && (now - mlc->lcv_t) < 5)
>   return -1;
>  
> - mlc->lcv_tv = tv;
> + mlc->lcv_t = now;
>   mlc->lcv = 0;
>  
>   return 0;

This part looks good now, but as I commented in version 1, it should
really be a separate patch rather than combined with the rest that
is dealing with another use of timeval.
>  
> - do_gettimeofday();
> - tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - mlc->instart.tv_sec);
> - tv.tv_usec -= mlc->instart.tv_usec;
> - if (tv.tv_usec >= mlc->intimeout) goto sched;
> - tv.tv_usec = (mlc->intimeout - tv.tv_usec) * HZ / USEC_PER_SEC;
> - if (!tv.tv_usec) goto sched;
> - mod_timer(_mlcs_kicker, jiffies + tv.tv_usec);
> + if (tmp.tv64 >= (mlc->intimeout * NSEC_PER_USEC))
> + goto sched;
> + tmp.tv64 = mlc->intimeout * NSEC_PER_USEC - tmp.tv64;
> + if (tmp.tv64 < NSEC_PER_USEC)
> + goto sched;
> + mod_timer(_mlcs_kicker,
> + jiffies + nsecs_to_jiffies(tmp.tv64));
>   break;
>   sched:
>   tasklet_schedule(_mlcs_tasklet);

If I read this right, the code is executed one for each input event such
as a keypress or mouse movement. In the latter case, doing nsecs_to_jiffies()
here is actually a bit expensive, and I stil think it can be avoided
by just using jiffies.

For the (tmp.tv64 < NSEC_PER_USEC) part, did you just do that because
I said this, or did you actually prove that it is required? I'm still
confused about what the driver is trying to achieve here.

> diff --git a/drivers/input/serio/hp_sdc_mlc.c 
> b/drivers/input/serio/hp_sdc_mlc.c
> index d50f067..0a27b89 100644
> --- a/drivers/input/serio/hp_sdc_mlc.c
> +++ b/drivers/input/serio/hp_sdc_mlc.c
> @@ -149,7 +149,8 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t 
> timeout)
>  
>   /* Try to down the semaphore */
>   if (down_trylock(>isem)) {
> - struct timeval tv;
> + ktime_t tmp = ktime_sub(ktime_get(), mlc->instart);
> +
>   if (priv->emtestmode) {
>   mlc->ipacket[0] =
>   HIL_ERR_INT | (mlc->opacket &

Maybe give the variable a more useful name than 'tmp'?

You could also remove the variable entirely if you slightly restructure
the condition below.

> @@ -160,9 +161,8 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t 
> timeout)
>   /* printk(KERN_DEBUG PREFIX ">[%x]\n", 
> mlc->ipacket[0]); */
>   goto wasup;
>   }
> - do_gettimeofday();
> - tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - mlc->instart.tv_sec);
> - if (tv.tv_usec - mlc->instart.tv_usec > mlc->intimeout) {
> +
> + if (tmp.tv64 > mlc->intimeout * NSEC_PER_USEC) {
>   /*  printk("!%i %i",
>   tv.tv_usec - mlc->instart.tv_usec,
>   mlc->intimeout);

As I mentioned, better use ktime_to_ns() instead of accessing the tv64 member
directly, but that is just a small style question.

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

Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

[Arnd Bergmann]

On Friday 23 October 2015 20:19:46 Pingbo Wen wrote:
> 
> > Also, we don't normally have enumerated lists in a changelog, just use
> > normal text. The best changelogs typically have three paragraphs:
> > 
> > The first paragraph describes what the driver currently does. For really
> > obvious cases, this can be combined with the second paragraph.
> > 
> > The second paragraph explains why that is bad. This is where you can
> > mention the monotonic time vs real time issue and say whether we
> > just want the timeval removed to fix the kernel in general or whether
> > this particular driver is broken.
> > 
> > The third paragraph explains what the patch does to resolve the issue
> > described in the second one. This is also where you can list other
> > approaches that would have solved the problem, and why you picked on
> > over the others.
> 
> Do we really need this in ChangeLog? Commit msg already states this. I think
> the purpose of ChangeLog is let people know the main difference of two
> version patch at a glance, and the ‘what’ and ‘why’ should be placed in
> commit msg.
> 

I was using the terms changelog and commit message interchangeably, sorry
for being unclear. I meant the part above the --- line. The revision
history you have below the --- line looks good here.

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

Re: [Y2038] [PATCH] hp_sdc: fixed y2038 problem

[Arnd Bergmann]

On Sunday 18 October 2015 17:44:19 WEN Pingbo wrote:
> Two replacements happened in this patch:
> 1. using timespec64 to prevent time overflow in 2038
> 2. using ktime_get_ts64 to avoid wall time issues(leap second, etc)
> 
> Signed-off-by: WEN Pingbo 
> 

The patch looks correct, but I think this could be written a little
simpler and clearer using ktime_get() or ktime_getns().

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

Re: [PATCH v8 0/9] Goodix touchscreen enhancements

[Arnd Bergmann]

On Friday 09 October 2015 11:02:01 Tirdea, Irina wrote:
> > -Original Message-
> > From: linux-input-ow...@vger.kernel.org 
> > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Arnd Bergmann
> > Sent: 08 October, 2015 17:32
> > To: Tirdea, Irina
> > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; 
> > linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > Subject: Re: [PATCH v8 0/9] Goodix touchscreen enhancements
> > 
> > On Thursday 08 October 2015 17:23:42 Irina Tirdea wrote:
> > > Add several enhancements to the Goodix touchscreen driver.
> > >
> > > The new functionality is only available for devices that
> > > declare named gpio pins for interrupt and reset in their
> > > ACPI/DT configuration.
> > >
> > > Thanks,
> > > Irina
> > >
> > > Changes in v8:
> > >  - only allow new functionality for devices that declare named
> > > gpios (using _DSD properties in ACPI or named DT properties)
> > >
> > >
> > 
> > Looks much cleaner this way, thanks!
> > 
> > One remaining question: how would you handle the case where
> > the hardware doesn't support configuring the int-gpios line
> > as output but you still want to use the named gpios?
> > 
> 
> The only reason to use named gpios is to enable the new functionality
> introduced by this patch set (mainly reset and power management).
> You cannot use only one gpio either (e.g. only reset gpio but not the
> interrupt gpio), you need both for this functionality to work.
> 
> If the hardware does not support using the interrupt gpio pin as output,
> it should not declare the named int-gpio pin in ACPI. It is true that
> we might later run into platforms that declare the int-gpio pin even if it
> does not actually work (just like we now have the indexed gpio pins).
> I could have added an additional property for this as you first suggested,
> but if we can modify the ACPI to add it, we could simply remove the
> named interrupt pin instead (that does not work anyway).

Ok, got it. Thanks,

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

Re: [PATCH v7 2/9] Input: goodix - reset device at init

[Arnd Bergmann]

On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote:
> After power on, it is recommended that the driver resets the device.
> The reset procedure timing is described in the datasheet and is used
> at device init (before writing device configuration) and
> for power management. It is a sequence of setting the interrupt
> and reset pins high/low at specific timing intervals. This procedure
> also includes setting the slave address to the one specified in the
> ACPI/device tree.
> 
> This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> driver gt9xx.c for Android (publicly available in Android kernel
> trees for various devices).
> 
> For reset the driver needs to control the interrupt and
> reset gpio pins (configured through ACPI/device tree). For devices
> that do not have the gpio pins declared, the functionality depending
> on these pins will not be available, but the device can still be used
> with basic functionality.
> 
> For both device tree and ACPI, the interrupt gpio pin configuration is
> read from the "irq-gpio" property and the reset pin configuration is
> read from the "reset-gpio" property. For ACPI 5.1, named properties
> can be specified using the _DSD section. If there is no _DSD section
> in the ACPI table, the driver will fall back to using indexed gpio
> pins declared in the _CRS section.

Would it help to use a plain "gpios" property here to always look
up the lines by index?

> +/*
> + * Some platforms specify the gpio pins for interrupt and reset properly
> + * in ACPI, but cannot use the interrupt pin as output due to their specific
> + * HW configuration.
> + */
> +static const struct dmi_system_id goodix_no_gpio_pins_support[] = {
> +#if defined(CONFIG_DMI) && defined(CONFIG_X86)
> + {
> + .ident = "Onda v975w",
> + .matches = {
> + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."),
> + DMI_MATCH(DMI_PRODUCT_UUID,
> +   "03000200-0400-0500-0006-000700080009"),
> + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"),
> + }
> + },

I think lists like this in drivers should be avoided if at all possible,
it just leads to other people adding their platform in the lists as
opposed to fixing their boot loaders.

Can you find another way to detect at runtime whether it works, and
print a warning if it doesn't? If there is no way to detect that kind
of device, we should probably have another property that the driver
can read to determine this, so we can avoid adding each system here.

> + /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */
> + error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14);
> + if (error)
> + return error;

If the "interrupt" gpio is used as an output, maybe it has the wrong
name? Is that the name from the goodix datasheet (that would be ok)
or something you picked?

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

Re: [PATCH v7 0/9] Goodix touchscreen enhancements

[Arnd Bergmann]

On Thursday 08 October 2015 13:19:26 Irina Tirdea wrote:
> Add several enhancements to the Goodix touchscreen driver.
> 
> Bastien, the functionality from this patches should be now skipped
> for your devices (Onda v975w, WinBook TW100 and WinBook TW700).
> 
> Aleksei, I have removed your Tested-by tag since I have done some
> non-trivial changes to the "reset device at init" patch.
> 
> 

I've read over all 9 patches now, most of them look good, but I
commented on the one that I have concerns about.

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

Re: [PATCH v7 2/9] Input: goodix - reset device at init

[Arnd Bergmann]

On Thursday 08 October 2015 12:18:37 Tirdea, Irina wrote:
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: 08 October, 2015 13:54
> > To: Tirdea, Irina
> > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; 
> > linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init
> > 
> > On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote:
> > > After power on, it is recommended that the driver resets the device.
> > > The reset procedure timing is described in the datasheet and is used
> > > at device init (before writing device configuration) and
> > > for power management. It is a sequence of setting the interrupt
> > > and reset pins high/low at specific timing intervals. This procedure
> > > also includes setting the slave address to the one specified in the
> > > ACPI/device tree.
> > >
> > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > driver gt9xx.c for Android (publicly available in Android kernel
> > > trees for various devices).
> > >
> > > For reset the driver needs to control the interrupt and
> > > reset gpio pins (configured through ACPI/device tree). For devices
> > > that do not have the gpio pins declared, the functionality depending
> > > on these pins will not be available, but the device can still be used
> > > with basic functionality.
> > >
> > > For both device tree and ACPI, the interrupt gpio pin configuration is
> > > read from the "irq-gpio" property and the reset pin configuration is
> > > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > > can be specified using the _DSD section. If there is no _DSD section
> > > in the ACPI table, the driver will fall back to using indexed gpio
> > > pins declared in the _CRS section.
> > 
> > Would it help to use a plain "gpios" property here to always look
> > up the lines by index?
> > 
> 
> The problem with ACPI indexed gpios is that platforms declare the
> pins in random order. In this case we have some platforms that declare
> the interrupt pin first and others that declare the reset pin first.
> There is no way to differentiate between them so the only way to support
> these platforms is to pick a default and list all exceptions in the driver.
> My previous implementation did that with indexed gpios and dmi quirks. [1]
> 
> This can be solved by using named gpios, which are available starting with 
> ACPI 5.1.
> In this way we know exactly which is the interrupt pin and which is the reset 
> pin
> and we do not need to add any additional exceptions to the driver.
> However, we still need to support the platforms that are already out there so
> we fall back to indexed gpios.
> 
> [1] https://lkml.org/lkml/2015/9/15/609

Right.

> > > +/*
> > > + * Some platforms specify the gpio pins for interrupt and reset properly
> > > + * in ACPI, but cannot use the interrupt pin as output due to their 
> > > specific
> > > + * HW configuration.
> > > + */
> > > +static const struct dmi_system_id goodix_no_gpio_pins_support[] = {
> > > +#if defined(CONFIG_DMI) && defined(CONFIG_X86)
> > > + {
> > > + .ident = "Onda v975w",
> > > + .matches = {
> > > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."),
> > > + DMI_MATCH(DMI_PRODUCT_UUID,
> > > +   "03000200-0400-0500-0006-000700080009"),
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> > > + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"),
> > > + }
> > > + },
> > 
> > I think lists like this in drivers should be avoided if at all possible,
> > it just leads to other people adding their platform in the lists as
> > opposed to fixing their boot loaders.
> > 
> > Can you find another way to detect at runtime whether it works, and
> > print a warning if it doesn't?
> 
> I agree with you on this, but unfortunately I have not found a better way to 
> do it.
> 
> The main problem comes from the interrupt pin. This device uses the interrupt 
> pin
> as output, which some platforms do not support (either due to the HW 
> configuration
> or due to flagging it wrong in BIOS) [2] [3]. There is no error returned, 
> just a warning
> in dmesg.
&

Re: [PATCH v8 0/9] Goodix touchscreen enhancements

[Arnd Bergmann]

On Thursday 08 October 2015 17:23:42 Irina Tirdea wrote:
> Add several enhancements to the Goodix touchscreen driver.
> 
> The new functionality is only available for devices that
> declare named gpio pins for interrupt and reset in their
> ACPI/DT configuration.
> 
> Thanks,
> Irina
> 
> Changes in v8:
>  - only allow new functionality for devices that declare named
> gpios (using _DSD properties in ACPI or named DT properties)
> 
> 

Looks much cleaner this way, thanks!

One remaining question: how would you handle the case where
the hardware doesn't support configuring the int-gpios line
as output but you still want to use the named gpios?

I assume you have that case covered, but I don't see it immediately.

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

Re: [Y2038] [PATCH V2] hp_sdc_rtc: fixed y2038 problem in proc_show

[Arnd Bergmann]

On Wednesday 16 September 2015 21:45:38 WEN Pingbo wrote:
> hp_sdc_rtc_proc_show() use timeval to store the time, which will
> overflowed in 2038.
> 
> This patch fixes this problem by replacing timeval with timespec64.
> hp_sdc_rtc_proc_show() only output string, so that userspace will work
> normally if we apply this patch.
> 
> Not all timer in i8042 have y2038 risk(handshake, match timer, etc),
> Replacements in those timer are just for consistency.
> 
> Version 2 Updates:
> - compiled in m68k gcc cross compiler(4.6.3), no extra warnings
> - placed s64 type cast in tv.tv_sec, making sure it work properly in
> both 32bit and 64bit platform.
> 
> Signed-off-by: WEN Pingbo <pingbo@linaro.org>
> Cc: Y2038 <y2...@lists.linaro.org>
> 

Looks very good,

Reviewed-by: Arnd Bergmann <a...@arndb.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v0] gpio_keys: fix gpio key driver to proper support GIC interrupt

[Arnd Bergmann]

On Monday 08 June 2015 09:48:29 Y Vo wrote:
 On Fri, Jun 5, 2015 at 7:50 PM, Arnd Bergmann a...@arndb.de wrote:
  On Thursday 04 June 2015 14:25:12 Y Vo wrote:
  GIC is designed to support two of trigger mechanisms - active level
  high or edge rising. But in the gpio_keys driver, it tries to use both
  edge rising and edge falling trigger. This patch fixes the gpio_keys
  driver to request only the edge rising event when failed to configure the
  interrupt.
 
  Signed-off-by: Y Vo y...@apm.com
 
  I think you want to use an 'interrupts' property instead of a 'gpios'
  property (or possibly both), so you can pass the right polarity.
 
 gpio-keys {
 compatible = gpio-keys;
 apm_ctrl_name = Power Button;
 btn2 {
 label = EXT_INT2;
 gpios = sbgpio 13 0x0;
 linux,code = 116;
 linux,input-type = 0x1; /* EV_KEY */
 };
 };
 
  sbgpio: sbgpio@17001000{
 compatible = apm,xgene-gpio-sb;
 reg = 0x0 0x17001000 0x0 0x400;
 #gpio-cells = 2;
 gpio-controller;
 interrupts =0x0 0x28 0x1,
 0x0 0x29 0x1,
 0x0 0x2a 0x1,
 0x0 0x2b 0x1,
 0x0 0x2c 0x1,
 0x0 0x2d 0x1;
 };
 I can change the polarity of interrupt in the sbgpio node, but the
 issue here is the gpio_key driver always set interrupt type to
 (irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING). And the GIC
 driver only support edge rising or level high. So that's our issue.

No, please do as I wrote, and use an interrupts property in the gpio-keys
node.

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

Re: [PATCH v0] gpio_keys: fix gpio key driver to proper support GIC interrupt

[Arnd Bergmann]

On Thursday 04 June 2015 14:25:12 Y Vo wrote:
 GIC is designed to support two of trigger mechanisms - active level
 high or edge rising. But in the gpio_keys driver, it tries to use both
 edge rising and edge falling trigger. This patch fixes the gpio_keys
 driver to request only the edge rising event when failed to configure the
 interrupt.
 
 Signed-off-by: Y Vo y...@apm.com

I think you want to use an 'interrupts' property instead of a 'gpios'
property (or possibly both), so you can pass the right polarity.

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

[PATCH v2] tty: remove platform_sysrq_reset_seq

[Arnd Bergmann]

The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over
two years, nobody has started using it in an upstream kernel, and
the platforms that were interested in it have moved on to devicetree,
which can be used to configure the sequence without requiring kernel
changes. The method is also incompatible with the way that most
architectures build support for multiple platforms into a single
kernel.

Now the code is producing warnings when built with gcc-5.1:

drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds 
[-Warray-bounds]
   key = platform_sysrq_reset_seq[i];

We could fix this, but it seems unlikely that it will ever be used,
so let's just remove the code instead. We still have the option to
pass the sequence either in DT, using the kernel command line,
or using the /sys/module/sysrq/parameters/reset_seq file.

Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: 154b7a489a (Input: sysrq - allow specifying alternate reset sequence)

v2: moved sysrq_reset_downtime_ms variable to avoid introducing a compile
warning when CONFIG_INPUT is disabled

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 8ba52e56bb8b..9c69af749d48 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -55,9 +55,6 @@
 static int __read_mostly sysrq_enabled = CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE;
 static bool __read_mostly sysrq_always_enabled;
 
-unsigned short platform_sysrq_reset_seq[] __weak = { KEY_RESERVED };
-int sysrq_reset_downtime_ms __weak;
-
 static bool sysrq_on(void)
 {
return sysrq_enabled || sysrq_always_enabled;
@@ -570,6 +567,7 @@ void handle_sysrq(int key)
 EXPORT_SYMBOL(handle_sysrq);
 
 #ifdef CONFIG_INPUT
+static int sysrq_reset_downtime_ms;
 
 /* Simple translation table for the SysRq keys */
 static const unsigned char sysrq_xlate[KEY_CNT] =
@@ -950,23 +948,8 @@ static bool sysrq_handler_registered;
 
 static inline void sysrq_register_handler(void)
 {
-   unsigned short key;
int error;
-   int i;
-
-   /* First check if a __weak interface was instantiated. */
-   for (i = 0; i  ARRAY_SIZE(sysrq_reset_seq); i++) {
-   key = platform_sysrq_reset_seq[i];
-   if (key == KEY_RESERVED || key  KEY_MAX)
-   break;
-
-   sysrq_reset_seq[sysrq_reset_seq_len++] = key;
-   }
 
-   /*
-* DT configuration takes precedence over anything that would
-* have been defined via the __weak interface.
-*/
sysrq_of_get_keyreset_config();
 
error = input_register_handler(sysrq_handler);

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

[PATCH] tty: remove platform_sysrq_reset_seq

[Arnd Bergmann]

The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over
two years, nobody has started using it in an upstream kernel, and
the platforms that were interested in it have moved on to devicetree,
which can be used to configure the sequence without requiring kernel
changes. The method is also incompatible with the way that most
architectures build support for multiple platforms into a single
kernel.

Now the code is producing warnings when built with gcc-5.1:

drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds 
[-Warray-bounds]
   key = platform_sysrq_reset_seq[i];

We could fix this, but it seems unlikely that it will ever be used,
so let's just remove the code instead. We still have the option to
pass the sequence either in DT, using the kernel command line,
or using the /sys/module/sysrq/parameters/reset_seq file.

Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: 154b7a489a (Input: sysrq - allow specifying alternate reset sequence)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 8ba52e56bb8b..9c5395db6a57 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -55,8 +55,7 @@
 static int __read_mostly sysrq_enabled = CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE;
 static bool __read_mostly sysrq_always_enabled;
 
-unsigned short platform_sysrq_reset_seq[] __weak = { KEY_RESERVED };
-int sysrq_reset_downtime_ms __weak;
+static int sysrq_reset_downtime_ms;
 
 static bool sysrq_on(void)
 {
@@ -950,23 +949,8 @@ static bool sysrq_handler_registered;
 
 static inline void sysrq_register_handler(void)
 {
-   unsigned short key;
int error;
-   int i;
-
-   /* First check if a __weak interface was instantiated. */
-   for (i = 0; i  ARRAY_SIZE(sysrq_reset_seq); i++) {
-   key = platform_sysrq_reset_seq[i];
-   if (key == KEY_RESERVED || key  KEY_MAX)
-   break;
 
-   sysrq_reset_seq[sysrq_reset_seq_len++] = key;
-   }
-
-   /*
-* DT configuration takes precedence over anything that would
-* have been defined via the __weak interface.
-*/
sysrq_of_get_keyreset_config();
 
error = input_register_handler(sysrq_handler);

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

Re: [PATCH v7 1/8] ARM: dt: Binding documentation for imx25 ADC/TSC

[Arnd Bergmann]

On Tuesday 03 March 2015 08:58:11 Markus Pargmann wrote:
 +Example:
 +   tscadc: tscadc@5003 {
 +   compatible = fsl,imx25-tsadc;
 +   reg = 0x5003 0xc;
 +   interrupts = 46;
 +   clocks = clks 119;
 +   clock-names = ipg;
 +   interrupt-controller;
 +   #interrupt-cells = 1;
 +   #address-cells = 1;
 +   #size-cells = 1;
 +   ranges;
 +
 +   tsc: tcq@50030400 {
 +   compatible = fsl,imx25-tcq;
 +   reg = 0x50030400 0x60;
 +   ...
 +   };
 +
 +   adc: gcq@50030800 {
 +   compatible = fsl,imx25-gcq;
 +   reg = 0x50030800 0x60;
 +   ...
 +   };
 +   };
 

I wonder if we should just treat this MFD as a single IIO device
that also registers to the input layer.

Are there any other registers in the 0x5003-0x50031000
range, or could the fsl,imx25-tcq and fsl,imx25-gcq devices
be reused outside of a fsl,imx25-tsadc device?

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

[PATCH] Input: sun4i-ts: add thermal driver dependency

[Arnd Bergmann]

The sun4i-ts driver has had a dependency on the thermal code
since it was first merged, but this is not currently enforced
in Kconfig, so in some randconfig builds we get

drivers/built-in.o: In function `sun4i_ts_remove':
:(.text+0x2376f4): undefined reference to `thermal_zone_of_sensor_unregister'
drivers/built-in.o: In function `sun4i_ts_probe':
:(.text+0x237a94): undefined reference to `thermal_zone_of_sensor_register'
:(.text+0x237c00): undefined reference to `thermal_zone_of_sensor_unregister'

We need the dependency on THERMAL in order to ensure that this
driver becomes a loadable module if the thermal support itself
is modular, while the dependency on THERMAL_OF is a runtime dependency
and the driver will still build but not work if it is missing.

Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: 6decea7c5438e2 (Input: add driver for Allwinner sunxi SoC's rtp 
controller)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 58917525126e..e2447f0063b7 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -943,6 +943,8 @@ config TOUCHSCREEN_SUN4I
tristate Allwinner sun4i resistive touchscreen controller support
depends on ARCH_SUNXI || COMPILE_TEST
depends on HWMON
+   depends on THERMAL
+   depends on THERMAL_OF || COMPILE_TEST
help
  This selects support for the resistive touchscreen controller
  found on Allwinner sunxi SoCs.

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

Re: [PATCH 3/3] input: goodix: Add bindings documentation

[Arnd Bergmann]

On Saturday 17 January 2015 17:36:50 Aleksei Mamlin wrote:
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/touchscreen/gt9xx.txt
 @@ -0,0 +1,23 @@
 +Device tree bindings for Goodix GT9xx series touchscreen controller
 +
 +Required properties:
 +
 + - compatible  : Should be goodix,gt9xx
 + - reg : I2C address of the chip
 + - interrupt-parent: Interrupt controller to which the chip is connected
 + - interrupts  : Interrupt to which the chip is connected
 +
 

You should avoid the use of wildcards in compatible strings. Better list
all the known part numbers, or (if they are 100% compatible with one another)
pick the oldest one we support and use that as the compatible string.

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

Re: [PATCH 2/3] drivers:input:ps2 Added sunxi A20 ps2 driver, changed makefile and Kconfig

[Arnd Bergmann]

On Thursday 04 December 2014 04:23:44 vishnupatekar wrote:
 +
 +#define DRIVER_NAME  sunxi-ps2
 +
 +#define RESSIZE(res)(((res)-end - (res)-start)+1)

Remove this and use the existing resource_size() function

 +
 +struct sunxips2data {
 + int irq;
 + spinlock_t ps2_lock;
 + void __iomem *base_address; /* virt address of control registers*/
 + struct serio *serio;/* serio*/
 + struct device *dev;
 + struct  clk *pclk;
 +};

As this is dynamically allocated, better embed the serio member
directly to avoid allocating both separately.

 +static int sunxips2_open(struct serio *pserio)
 +{
 + struct sunxips2data *drvdata = pserio-port_data;
 + u32 src_clk = 0;
 + u32 clk_scdf;
 + u32 clk_pcdf;
 + u32 rval;
 +
 + /*Set Line Control And Enable Interrupt*/
 + rval = 
 SWPS2_LCTL_TXDTOEN|SWPS2_LCTL_STOPERREN|SWPS2_LCTL_ACKERREN|SWPS2_LCTL_PARERREN|SWPS2_LCTL_RXDTOEN;
 + writel(rval, drvdata-base_address + SW_PS2_LCTRL);
 +
 + /*Reset FIFO*/
 + writel(0x316 | 0x607, drvdata-base_address + SW_PS2_FCTRL);
 +
 + src_clk = clk_get_rate(drvdata-pclk);
 +
 + if (!src_clk) {
 + dev_info(drvdata-dev, w_ps2c_set_sclk error, source clock is 
 0.);
 + return -1;
 + }
 +
 + /*Set Clock Divider Register*/
 + clk_scdf = ((src_clk + (SW_PS2_SAMPLE_CLK1)) / SW_PS2_SAMPLE_CLK - 1);
 + clk_pcdf = ((SW_PS2_SAMPLE_CLK + (SW_PS2_SCLK1)) / SW_PS2_SCLK - 1);
 + rval = (clk_scdf8) | clk_pcdf;/* | (PS2_DEBUG_SEL16);*/
 + writel(rval, drvdata-base_address + SW_PS2_CLKDR);
 +
 + /*Set Global Control Register*/
 + rval = SWPS2_RESET|SWPS2_INTEN|SWPS2_MASTER|SWPS2_BUSEN;
 + writel(rval, drvdata-base_address + SW_PS2_GCTRL);
 +
 + udelay(100);

100 microseconds is a rather long time to block the CPU for, so this
needs a comment explaining why the particular delay is needed and why
you can't use usleep_range() instead.

 +static void sunxips2_close(struct serio *pserio)
 +{
 +   struct sunxips2data *drvdata = pserio-port_data;
 +
 +   spin_lock(drvdata-ps2_lock);
 +   /* Disable the PS2 interrupts */
 +   writel(0, drvdata-base_address + SW_PS2_GCTRL);
 +   spin_unlock(drvdata-ps2_lock);
 +}

The locking is wrong here: you take the lock without disabling the
interrupts first, so if the interrupt happens between the spin_lock()
call and the writel(), the kernel will deadlock.

You will either have to use spin_lock_irq() here, or find a justification
for dropping the lock entirely.

 +static int sunxips2_write(struct serio *pserio, unsigned char val)
 +{
 + struct sunxips2data *drvdata = (struct sunxips2data *)pserio-port_data;
 + u32 timeout = 1;
 +
 + do {
 + if (readl(drvdata-base_address + SW_PS2_FSTAT)  
 SWPS2_FSTA_TXRDY) {
 + writel(val, drvdata-base_address + SW_PS2_DATA);
 + return 0;
 + }
 + } while (timeout--);
 +
 + return -1;
 +}

We never return '-1' from in-kernel functions. Either make this a bool
argument, or return a proper errno.h value. This should probably return
-EIO.

 + drvdata-irq = irq;
 + drvdata-serio = serio;
 + drvdata-dev = dev;
 + error = devm_request_any_context_irq(drvdata-dev, drvdata-irq, 
 sunxips2_interrupt, 0,
 + DRIVER_NAME, drvdata);
 + if (error) {
 + dev_err(drvdata-dev,
 + Couldn't allocate interrupt %d : error: %d\n, 
 drvdata-irq, error);
 + return error;
 + }
 + return 0;   /* success */
 +}

Why any_context?

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

Re: [PATCH 2/3] drivers:input:ps2 Added sunxi A20 ps2 driver, changed makefile and Kconfig

[Arnd Bergmann]

On Friday 05 December 2014 07:01:17 Dmitry Torokhov wrote:
 
 On December 5, 2014 2:33:11 AM PST, Arnd Bergmann a...@arndb.de wrote:
 On Thursday 04 December 2014 04:23:44 vishnupatekar wrote:
  +
  +struct sunxips2data {
  +int irq;
  +spinlock_t ps2_lock;
  +void __iomem *base_address; /* virt address of control registers*/
  +struct serio *serio;/* serio*/
  +struct device *dev;
  +struct  clk *pclk;
  +};
 
 As this is dynamically allocated, better embed the serio member
 directly to avoid allocating both separately.
 
 That would be wrong - serio is refcounted and it may outlive instance of 
 sunxips2data you embedded it into.

Ok, I see. I guess in this case the use of devm_kzalloc for serio is a bug,
because that would lead to a double free upon module unload, right?

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

Re: [PATCH v2 1/1] Input: gpio_keys - add device tree support for interrupt only keys

[Arnd Bergmann]

On Thursday 13 November 2014 11:35:42 Alexander Stein wrote:
 On Wednesday 12 November 2014 20:16:06, Arnd Bergmann wrote:
  On Wednesday 12 November 2014 17:38:31 Alexander Stein wrote:
   On Wednesday 12 November 2014 17:04:57, Arnd Bergmann wrote:
On Wednesday 12 November 2014 17:02:56 Alexander Stein wrote:
 This features already exists for board config setups. Add support for
 device tree based systems.
 
 Signed-off-by: Alexander Stein alexander.st...@systec-electronic.com
 ---
 Please note: Due to current lack of hardware I could not test it yet. 
 V2
 includes the changes proposed by Dmitry.
 
 Changes in v2:
 * Added device tree bindings
 * IRQ is only parsed and mapped when there is no gpios property
 

Can you list one or more examples in the patch description?
Are these systems that don't expose the GPIO controller with a
standalone driver, or systems that really actually connect the
buttons to an interrupt pin?
   
   You mean a use case? I came to this situation to test interrupt polarity 
   on a microcontroller, thus a simple /IRQ pin, no GPIO at all. So in the 
   end I have an input just connected to an interrupt line.
   I noticed gpio_keys using platform data only can be used for this setup. 
   So I added this support for device tree.
   
  
  I meant a specific board file that uses this, which can't be converted
  to DT without your change.
 
 I've searched (hopefully) the complete arch/ tree on v3.18-rc4 for
 struct gpio_keys_button and checked each occurrence. I didn't found
 any usage of IRQ based input keys.

Ok, I see.

I notice that Laxman Dewangan initially added the feature as part of
(I assume) work on Tegra, but these days Tegra is DT-only so it can't
actually get used for that any more.

If we have a real usecase, I think we can still take your patch, but
my impression at the moment is that it may be better to instead
remove the feature entirely by reverting d8ee4a1c9052 (Input:
gpio_keys - add support for interrupt only keys).

Regarding your initial use case of testing interrupt polarity, would
you have been able to do the same thing by looking at the interrupt
count in /proc/interrupts?

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

Re: [PATCH v2 1/1] Input: gpio_keys - add device tree support for interrupt only keys

[Arnd Bergmann]

On Thursday 13 November 2014 11:52:48 Alexander Stein wrote:
 On Thursday 13 November 2014 11:47:13, Arnd Bergmann wrote:
  Regarding your initial use case of testing interrupt polarity, would
  you have been able to do the same thing by looking at the interrupt
  count in /proc/interrupts?
 
 This is only possible if some driver actually requests this interrupt, no?

Yes, I think that is correct, at least with sparseirq, which is now the
default. For interrupts that are mapped by the irqchip, you can look
up the number of spurious interrupts in /proc/irq/nr/spurious.

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

Re: [PATCH v2 1/1] Input: gpio_keys - add device tree support for interrupt only keys

[Arnd Bergmann]

On Thursday 13 November 2014 16:29:02 Laxman Dewangan wrote:
 On Thursday 13 November 2014 04:17 PM, Arnd Bergmann wrote:
  I notice that Laxman Dewangan initially added the feature as part of
  (I assume) work on Tegra, but these days Tegra is DT-only so it can't
  actually get used for that any more.
 
  If we have a real usecase, I think we can still take your patch, but
  my impression at the moment is that it may be better to instead
  remove the feature entirely by reverting d8ee4a1c9052 (Input:
  gpio_keys - add support for interrupt only keys).
 
  Regarding your initial use case of testing interrupt polarity, would
  you have been able to do the same thing by looking at the interrupt
  count in /proc/interrupts?
 
 
 Yes, I posted patch for interrupt key on context on key connected to 
 PMIC-Onkey.
 On PMIC, there is onkey pin input which generates interrupt only when it 
 toggles. So if we have key (power key on our platforms) connected to 
 this pin then we will only get interrupt from PMIC.
 Instead of implementing full interrupt key driver, I added this support 
 on existing gpio keys.

So is this code still in place, and do you think it's worthwhile to
have a DT binding for it?

Could the PMIC register a gpio controller instead?

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Sunday 20 July 2014 17:45:40 Chen Gang wrote:
  
  Next, I shall:
  
   - Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.
  
   - Try to make dummy IOMEM functions for score architecture.
  
   - Continue discussing with UML for it.
 
  
 Oh, sorry, I forgot, after remove IOMEM from kernel, also s390 and tile
 need implement dummy IOMEM if !PCI.
 
 If possible, I shall try to implement the dummy IOMEM in 'asm-generic',
 and let uml, score, s390 and tile use them when they need.

Sorry for going round in circles, but looking back at the original patches,
adding the extra 'depends on HAS_IOMEM' does seem much better than the
other suggestions that came afterwards.

In particular, removing HAS_IOMEM and NO_IOMEM sounds like an awful idea
to me. I'd rather add a HAS_IOPORT in addition to also catch architectures
that have no support for PC-style PIO.

Arnd

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

[PATCH v2] iio: exynos-adc: add experimental touchscreen support

[Arnd Bergmann]

This adds support for the touchscreen on Samsung s3c64xx.
The driver is completely untested but shows roughly how
it could be done, following the example of the at91 driver.

Open questions include:

- compared to the old plat-samsung/adc driver, there is
  no support for prioritizing ts over other clients, nor
  for oversampling. From my reading of the code, the
  priorities didn't actually have any effect at all, but
  the oversampling might be needed. Maybe the original
  authors have some insight.

- We probably need to add support for platform_data as well,
  I've skipped this so far.

Signed-off-by: Arnd Bergmann a...@arndb.de
---
This should address all previous comments, and I've also added
a write to ADC_V1_DLY() as the old driver does.

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index cad81b666a67..ba30836c73cb 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -43,6 +43,10 @@ Required properties:
   and compatible ADC block)
 - vdd-supply   VDD input supply.
 
+Optional properties:
+- has-touchscreen: If present, indicates that a touchscreen is
+   connected an usable.
+
 Note: child nodes can be added for auto probing from device tree.
 
 Example: adding device info in dtsi file
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 420c5cda09c3..3b684a117b9c 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -34,6 +34,7 @@
 #include linux/regulator/consumer.h
 #include linux/of_platform.h
 #include linux/err.h
+#include linux/input.h
 
 #include linux/iio/iio.h
 #include linux/iio/machine.h
@@ -66,6 +67,9 @@
 
 #define ADC_S3C2410_CON_SELMUX(x) (((x)0x7)3)
 
+/* touch screen always uses channel 0 */
+#define ADC_S3C2410_MUX_TS 0
+
 /* ADCTSC Register Bits */
 #define ADC_S3C2443_TSC_UD_SEN (1u  8)
 #define ADC_S3C2410_TSC_YM_SEN (1u  7)
@@ -103,24 +107,32 @@
 
 /* Bit definitions common for ADC_V1 and ADC_V2 */
 #define ADC_CON_EN_START   (1u  0)
+#define ADC_DATX_PRESSED   (1u  15)
 #define ADC_DATX_MASK  0xFFF
+#define ADC_DATY_MASK  0xFFF
 
 #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
 
 struct exynos_adc {
struct exynos_adc_data  *data;
struct device   *dev;
+   struct input_dev*input;
void __iomem*regs;
void __iomem*enable_reg;
struct clk  *clk;
struct clk  *sclk;
unsigned intirq;
+   unsigned inttsirq;
struct regulator*vdd;
 
struct completion   completion;
 
u32 value;
unsigned intversion;
+
+   boolread_ts;
+   u32 ts_x;
+   u32 ts_y;
 };
 
 struct exynos_adc_data {
@@ -205,6 +217,9 @@ static void exynos_adc_v1_init_hw(struct exynos_adc *info)
/* Enable 12-bit ADC resolution */
con1 |= ADC_V1_CON_RES;
writel(con1, ADC_V1_CON(info-regs));
+
+   /* set default touchscreen delay */
+   writel(1, ADC_V1_DLY(info-regs));
 }
 
 static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
@@ -390,12 +405,54 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
 }
 
+static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y)
+{
+   struct exynos_adc *info = iio_priv(indio_dev);
+   unsigned long timeout;
+   int ret;
+
+   mutex_lock(indio_dev-mlock);
+   info-read_ts = true;
+
+   reinit_completion(info-completion);
+
+   writel(ADC_S3C2410_TSC_PULL_UP_DISABLE | ADC_TSC_AUTOPST,
+  ADC_V1_TSC(info-regs));
+
+   /* Select the ts channel to be used and Trigger conversion */
+   info-data-start_conv(info, ADC_S3C2410_MUX_TS);
+
+   timeout = wait_for_completion_timeout
+   (info-completion, EXYNOS_ADC_TIMEOUT);
+   if (timeout == 0) {
+   dev_warn(indio_dev-dev, Conversion timed out! Resetting\n);
+   if (info-data-init_hw)
+   info-data-init_hw(info);
+   ret = -ETIMEDOUT;
+   } else {
+   *x = info-ts_x;
+   *y = info-ts_y;
+   ret = 0;
+   }
+
+   info-read_ts = false;
+   mutex_unlock(indio_dev-mlock);
+
+   return ret;
+}
+
 static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
 {
struct exynos_adc *info = (struct exynos_adc *)dev_id;
 
/* Read value */
-   info-value = readl(ADC_V1_DATX(info-regs))  ADC_DATX_MASK;
+   if (info-read_ts) {
+   info-ts_x = readl(ADC_V1_DATX(info-regs));
+   info-ts_y = readl(ADC_V1_DATY(info-regs

Re: [PATCH v2] iio: exynos-adc: add experimental touchscreen support

[Arnd Bergmann]

On Tuesday 22 July 2014 11:09:04 Dmitry Torokhov wrote:
  @@ -565,6 +722,15 @@ static int exynos_adc_probe(struct platform_device 
  *pdev)
if (info-data-init_hw)
info-data-init_hw(info);
   
  + /* leave out any TS related code if unreachable */
  + if (IS_BUILTIN(CONFIG_INPUT) ||
  + (IS_MODULE(CONFIG_INPUT)  config_enabled(MODULE)))
 
 This is ugly... We need IS_SUBSYSTEM_AVAILABLE() wrapper for this...
 
 Anyway,
 
 Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com
 
 

I actually have a patch to introduce IS_REACHABLE() for this purpose,
but I haven't sent it out for review yet. The main user of this would
be drivers/media, which had the correct logic earlier until someone
tried to simplify it by replacing it all with IS_ENABLED()...

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

Re: [PATCH 2/2] iio: exynos-adc: add experimental touchscreen support

[Arnd Bergmann]

On Sunday 20 July 2014 13:28:42 Dmitry Torokhov wrote:
 On Sun, Jul 20, 2014 at 02:51:37PM +0100, Jonathan Cameron wrote:
  +
  +do {
  +ret =exynos_read_s3c64xx_ts(dev, NULL, x, y, 
  IIO_CHAN_INFO_RAW);
  = exynos
  +if (ret == -ETIMEDOUT)
  +break;
  +
  +pressed = x  y  ADC_DATX_PRESSED;
  +if (!pressed)
  +break;
  +
  +input_report_abs(info-input, ABS_X, x  ADC_DATX_MASK);
  +input_report_abs(info-input, ABS_Y, y  ADC_DATX_MASK);
  +input_report_key(info-input, BTN_TOUCH, 1);
  +input_sync(info-input);
  +
  +msleep(1);
  +} while (1);
 
 It would be nice to actually close the device even if someone is
 touching screen. Please implement open/close methods and have them set a
 flag that you would check here.

Ok. I think it's even better to move the request_irq() into the open function,
which will avoid the flag and defer the error handling into the actual opening,
as well as syncing the running irq with the close function.

  +/* data from s3c2410_ts driver */
  +info-input-name = S3C24xx TouchScreen;
  +info-input-id.bustype = BUS_HOST;
  +info-input-id.vendor = 0xDEAD;
  +info-input-id.product = 0xBEEF;
 
 You do not need to fill these entries with fake data.

Ok, I wondered about this, but didn't want to change too much from
the old driver (I changed the version number).

  +info-input-id.version = 0x0200;

Do I need this?

  @@ -576,6 +728,11 @@ static int exynos_adc_probe(struct platform_device 
  *pdev)
err_of_populate:
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
  +if (has_ts) {
  +input_unregister_device(info-input);
  +free_irq(info-tsirq, info);
 
 Are we sure that device is quiesced here and interrupt won't arrive
 between input_unregister_device() and free_irq()? I guess if you
 properly implement open/close it won't matter.
 
Should be fixed now.

  +err_iio:
iio_device_unregister(indio_dev);
err_irq:
free_irq(info-irq, info);
  @@ -595,9 +752,12 @@ static int exynos_adc_remove(struct platform_device 
  *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
  
  +input_free_device(info-input);
 
 Should be unregister, not free.

Ok.

Thanks a lot for the review! I'll send out the new version after some build 
testing.

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

Re: [PATCH 2/2] iio: exynos-adc: add experimental touchscreen support

[Arnd Bergmann]

On Monday 21 July 2014 12:23:58 Arnd Bergmann wrote:
 
 Thanks a lot for the review! I'll send out the new version after some build 
 testing.

Here are the changes I did to the adc driver based on the review comments.
I'll start a new thread for the updated version that includes the changes.

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 3d2caea05977..823d7ebc7f52 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -67,6 +67,9 @@
 
 #define ADC_S3C2410_CON_SELMUX(x) (((x)0x7)3)
 
+/* touch screen always uses channel 0 */
+#define ADC_S3C2410_MUX_TS 0
+
 /* ADCTSC Register Bits */
 #define ADC_S3C2443_TSC_UD_SEN (1u  8)
 #define ADC_S3C2410_TSC_YM_SEN (1u  7)
@@ -106,6 +109,7 @@
 #define ADC_CON_EN_START   (1u  0)
 #define ADC_DATX_PRESSED   (1u  15)
 #define ADC_DATX_MASK  0xFFF
+#define ADC_DATY_MASK  0xFFF
 
 #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
 
@@ -123,10 +127,12 @@ struct exynos_adc {
 
struct completion   completion;
 
-   boolread_ts;
u32 value;
-   u32 value2;
unsigned intversion;
+
+   boolread_ts;
+   u32 ts_x;
+   u32 ts_y;
 };
 
 struct exynos_adc_data {
@@ -396,21 +402,14 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
 }
 
-static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
-   struct iio_chan_spec const *chan,
-   int *val,
-   int *val2,
-   long mask)
+static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y)
 {
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
int ret;
 
-   if (mask != IIO_CHAN_INFO_RAW)
-   return -EINVAL;
-
mutex_lock(indio_dev-mlock);
-   info-read_ts = 1;
+   info-read_ts = true;
 
reinit_completion(info-completion);
 
@@ -418,7 +417,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
   ADC_V1_TSC(info-regs));
 
/* Select the ts channel to be used and Trigger conversion */
-   info-data-start_conv(info, 0);
+   info-data-start_conv(info, ADC_S3C2410_MUX_TS);
 
timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
@@ -428,12 +427,12 @@ static int exynos_read_s3c64xx_ts(struct iio_dev 
*indio_dev,
info-data-init_hw(info);
ret = -ETIMEDOUT;
} else {
-   *val = info-value;
-   *val2 = info-value2;
-   ret = IIO_VAL_INT;
+   *x = info-ts_x;
+   *y = info-ts_y;
+   ret = 0;
}
 
-   info-read_ts = 0;
+   info-read_ts = false;
mutex_unlock(indio_dev-mlock);
 
return ret;
@@ -445,8 +444,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
 
/* Read value */
if (info-read_ts) {
-   info-value = readl(ADC_V1_DATX(info-regs))  ADC_DATX_MASK;
-   info-value2 = readl(ADC_V1_DATY(info-regs))  ADC_DATX_MASK;
+   info-ts_x = readl(ADC_V1_DATX(info-regs));
+   info-ts_y = readl(ADC_V1_DATY(info-regs));
writel(ADC_TSC_WAIT4INT | ADC_S3C2443_TSC_UD_SEN, 
ADC_V1_TSC(info-regs));
} else {
info-value = readl(ADC_V1_DATX(info-regs))  ADC_DATX_MASK;
@@ -477,7 +476,7 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
int ret;
 
do {
-   ret =exynos_read_s3c64xx_ts(dev, NULL, x, y, 
IIO_CHAN_INFO_RAW);
+   ret = exynos_read_s3c64xx_ts(dev, x, y);
if (ret == -ETIMEDOUT)
break;
 
@@ -486,11 +485,15 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
break;
 
input_report_abs(info-input, ABS_X, x  ADC_DATX_MASK);
-   input_report_abs(info-input, ABS_Y, y  ADC_DATX_MASK);
+   input_report_abs(info-input, ABS_Y, y  ADC_DATY_MASK);
input_report_key(info-input, BTN_TOUCH, 1);
input_sync(info-input);
 
msleep(1);
+
+   /* device may have been closed while touched */
+   if (!info-input-users)
+   return IRQ_HANDLED;
} while (1);
 
input_report_key(info-input, BTN_TOUCH, 0);
@@ -552,10 +555,28 @@ static int exynos_adc_remove_devices(struct device *dev, 
void *c)
return 0;
 }
 
+static int exynos_adc_ts_open(struct input_dev *dev)
+{
+   struct exynos_adc *info = input_get_drvdata(dev);
+
+   return request_threaded_irq(info-tsirq, NULL, exynos_ts_isr,
+   0, touchscreen, info

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 11:26:57 Richard Weinberger wrote:
 Am 17.07.2014 11:20, schrieb Arnd Bergmann:
  On Thursday 17 July 2014 09:27:58 Chen Gang wrote:
   gfp_t gfp_mask, unsigned int 
  order);
   extern void devm_free_pages(struct device *dev, unsigned long addr);
   
  +#ifdef CONFIG_HAS_IOMEM
   void __iomem *devm_ioremap_resource(struct device *dev, struct resource 
  *res);
  +#elif defined(CONFIG_COMPILE_TEST)
  +static inline void __iomem *devm_ioremap_resource(struct device *dev,
  +   struct resource *res)
  +{
  +   pr_warn(no hardware io memory, only for COMPILE_TEST\n);
  +   return (__force void __iomem *)ERR_PTR(-ENXIO);
  +}
  +#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
   
   /* allows to add/remove a custom action to devres stack */
  
  To be honest, I think it's a bad idea to introduce wrappers functions
  that are only available when CONFIG_COMPILE_TEST is set.
  
  COMPILE_TEST is a great tool in general, but it has its limits.
  In particular, the case for !CONFIG_IOMEM is completely obscure
  and we won't find any bugs by allowing more drivers to be built
  in those configurations, but attempting to do it would cause
  endless churn by changing each instance of 'depends on HAS_IOMEM'
  to 'depends on HAS_IOMEM || COMPILE_TEST'.
  
  Note that s390 no has gained support for IOMEM, tile has it most
  of the time (when PCI is enabled, so you get it in half the
  test builds already), score should set HAS_IOMEM and doesn't
  even have public compilers, and uml doesn't even compile in
  latest mainline. Nothing else ever sets NO_IOMEM.
 
 Huh? UML (v3.16-rc5-143-gb6603fe) builds fine here. What build issue are you 
 facing?

This is what I got upon trying earlier. I have not attempted to look into
why this is happening. Note this is on linux-next from yesterday,
not mainline as I incorrectly stated above.

In file included from ../arch/um/include/asm/fixmap.h:58:0,
 from ../arch/um/include/asm/pgtable.h:11,
 from ../include/linux/mm.h:51,
 from ../kernel/uid16.c:6:
../include/asm-generic/fixmap.h: In function 'fix_to_virt':
../include/asm-generic/fixmap.h:31:2: error: size of unnamed array is negative
  BUILD_BUG_ON(idx = __end_of_fixed_addresses);


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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 11:56:58 Thierry Reding wrote:
 On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
 [...]
score should set HAS_IOMEM and doesn't
  even have public compilers
 
 This begs an interesting question. Should it be made a requirement to
 have publicly available compilers for new architectures so that they can
 at least be compile-tested? Preferably this would of course be in source
 form so that there aren't any dependencies on the distribution.

The question has come up a few times. I wouldn't mandate that the port
has an upstream gcc (you've got to start mainlining one of them first
after all), but having compilers available for download should probably be
required. It's hard to ask for a particular quality of that gcc port
though, or to expect it to stay available online.

Where did you find the gcc port for score?

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 17:29:31 Chen Gang wrote:
  
  COMPILE_TEST is a great tool in general, but it has its limits.
  In particular, the case for !CONFIG_IOMEM is completely obscure
  and we won't find any bugs by allowing more drivers to be built
  in those configurations, but attempting to do it would cause
  endless churn by changing each instance of 'depends on HAS_IOMEM'
  to 'depends on HAS_IOMEM || COMPILE_TEST'.
 
 
 Architecture members and driver members really have different tastes,
 they are different roles. It really need additional discussion.
 
 For me, I only want to change devm_io*map*, not touch so much.

But what do you gain from that? All drivers that need these
functions should already 'depends on HAS_IOMEM' and if they don't,
we should fix /that/ instead. I don't see this dependency as any
different from a lot of others (PCI, DMAENGINE, HAVE_CLK, ...)
that we use to intentionally annotate drivers that need a particular
feature to be present for compilation. Do you want to do the
same hack to those?

 Welcome any other members' idea or suggestions.

  Note that s390 no has gained support for IOMEM, tile has it most
  of the time (when PCI is enabled, so you get it in half the
  test builds already), score should set HAS_IOMEM and doesn't
  even have public compilers, and uml doesn't even compile in
  latest mainline. Nothing else ever sets NO_IOMEM.
  
 
 In latest gcc and binutils, can compile score cross compiler
 successfully for building kernel (but I am not quite sure whether the
 compiling result are really OK, but I guess so).

Ok. Would you mind sending a patch that enables HAS_IOMEM on
score?
 
 And next (maybe after finish allmodconfig for microblaze), I shall try
 to let uml pass allmodconfig for linux-next tree.

That is a fair goal, but it seems better to do that by ensuring
we don't build any code that tries to call the MMIO functions
rather than trying to make them build.

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 12:40:25 Lars-Peter Clausen wrote:
 On 07/17/2014 11:20 AM, Arnd Bergmann wrote:
  On Thursday 17 July 2014 09:27:58 Chen Gang wrote:
gfp_t gfp_mask, unsigned int 
  order);
extern void devm_free_pages(struct device *dev, unsigned long addr);
 
  +#ifdef CONFIG_HAS_IOMEM
void __iomem *devm_ioremap_resource(struct device *dev, struct resource 
  *res);
  +#elif defined(CONFIG_COMPILE_TEST)
  +static inline void __iomem *devm_ioremap_resource(struct device *dev,
  +   struct resource *res)
  +{
  +   pr_warn(no hardware io memory, only for COMPILE_TEST\n);
  +   return (__force void __iomem *)ERR_PTR(-ENXIO);
  +}
  +#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
/* allows to add/remove a custom action to devres stack */
 
  To be honest, I think it's a bad idea to introduce wrappers functions
  that are only available when CONFIG_COMPILE_TEST is set.
 
  COMPILE_TEST is a great tool in general, but it has its limits.
  In particular, the case for !CONFIG_IOMEM is completely obscure
  and we won't find any bugs by allowing more drivers to be built
  in those configurations, but attempting to do it would cause
  endless churn by changing each instance of 'depends on HAS_IOMEM'
  to 'depends on HAS_IOMEM || COMPILE_TEST'.
 
 The point of this exercise is that we do not have to replace a good chunk of 
 'depends on COMPILE_TEST' with 'depends on COMPILE_TEST  HAS_IOMEM'

Ok, I see.

 E.g. the typical Kconfig entry for your random SoC peripheral driver looks 
 like
 
 config ARCH_FOOBAR_DRIVER
 depends on ARCH_FOOBAR || COMPILE_TEST
 ...
 
 Now when COMPILE_TEST is not set there is a implicit dependency on HAS_IOMEM 
 since the architecture will provide it. If COMPILE_TEST is selected the 
 driver will also be build-able on architectures that do no have HAS_IOMEM 
 and hence linking the driver fails. One way to fix this is of course to 
 replace the COMPILE_TEST with (COMPILE_TEST  HAS_IOMEM). But this is very 
 often overlooked and only noticed later on when somebody actually builds a 
 allyesconfig on an architecture that does not provide HAS_IOMEM. To avoid 
 these kinds of build errors and tedious fixup patches the idea is to provide 
 a stub function when HAS_IOMEM is not enabled, but COMPILE_TEST is enabled.

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take
a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff
to build on UML seems pointless to me and we special-case it in a number of
places already.

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 12:58:55 Richard Weinberger wrote:
  This is what I got upon trying earlier. I have not attempted to look into
  why this is happening. Note this is on linux-next from yesterday,
  not mainline as I incorrectly stated above.
  
  In file included from ../arch/um/include/asm/fixmap.h:58:0,
   from ../arch/um/include/asm/pgtable.h:11,
   from ../include/linux/mm.h:51,
   from ../kernel/uid16.c:6:
  ../include/asm-generic/fixmap.h: In function 'fix_to_virt':
  ../include/asm-generic/fixmap.h:31:2: error: size of unnamed array is 
  negative
BUILD_BUG_ON(idx = __end_of_fixed_addresses);
 
 So, this is next-20140716?
 I don't see the fixmap issue you're reporting, also not on the most recent 
 next.

Sorry, nevermind. I had a workaround for a gcc-4.9 bug applied that
turned off optimization for uid16.c, which fixed the build for ARM for
me but happened to break x86 including uml.

Without that patch, I don't see this problem.

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 16:41:14 Chris Metcalf wrote:
 On 7/17/2014 7:28 AM, Chen Gang wrote:
  On 07/17/2014 06:48 PM, Arnd Bergmann wrote:
  AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take
  a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff
  to build on UML seems pointless to me and we special-case it in a number of
  places already.
 
  According to current source code, tile still has chance to choose
  NO_IOMEM, for me, welcome the tile's maintainer's ideas or suggestions.
 
 I'm not really sure.  It's true that on tile, if you don't enable PCI
 support there's no other I/O memory (or I/O port) space you can use.
 We pretty much always enable PCI support in our kernel, though.  I'm
 kind of surprised that other architectures don't also have the model
 that IOMEM requires PCI, but perhaps most architectures just don't
 encode that in the Kconfig file?

Only s390 as far as I know. Most architectures have integrated
peripherals that use MMIO without PCI.

 My observation is just that if I remove the NO_IOMEM if !PCI from
 arch/tile/Kconfig, my build fails with ioremap() undefined.  No doubt I
 could work around that, but my assumption was that NO_IOMEM was exactly the
 right thing to express the fact that without PCI there is no I/O memory 

Your assumption is correct.

For tile by itself it would certainly be best to leave this
dependency, it makes no sense to enable IOMEM without PCI.

That doesn't solve the problem of COMPILE_TEST enabling drivers
that require IOMEM though. An easy hack for that would be to
make COMPILE_TEST depend on HAS_IOMEM, but it gets into hacky territory
there, and it's not clear if this is any better than the original patch
to provide fallbacks for ioremap and friends. Definitely simpler
though.

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

Re: [PATCH 1/2] input: fix ps2/serio module dependency

[Arnd Bergmann]

On Thursday 08 May 2014 08:59:31 Dmitry Torokhov wrote:
 Hi Arnd,
 
 On Thu, May 08, 2014 at 04:56:26PM +0200, Arnd Bergmann wrote:
  @@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
default y
select SERIO
select SERIO_LIBPS2
  - select SERIO_I8042 if X86
  + select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
 
 x86 also selects ARCH_MIGHT_HAVE_PC_SERIO so shouldn't this be
 
 select SERIO_I8042 if ARCH_MIGHT_HAVE_PC_SERIO
 
 ?
 
 I can fix it up on my side if you agree.

Yes, sounds good, thanks!

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

Re: [PATCH 00/22] Random ARM randconfig fixes in drivers

[Arnd Bergmann]

On Thursday 08 May 2014, Guenter Roeck wrote:
 On Thu, May 08, 2014 at 04:46:51PM +0200, Arnd Bergmann wrote:
  These are a bunch of fixes I had to do to get all randconfig
  configurations on ARM working. Most of these are really old
  bugs, but there are also some new ones. I don't think any of
  them require a backport to linux-stable.
  
  I have checked that they are all still required on yesterday's
  linux-next kernel. Please apply on the appropriate trees unless
  there are objections.
  
 Is this series of patches also going to fix arm:allmodconfig ?

Possibly, I haven't checked in a while. I'm unfortunately sitting on
about 200 other patches in the same branch, which together fix all
build errors in any configuration I encountered.

I should really do some allmodconfig/allnoconfig/allyesconfig
builds without my series again, and prioritize sending out the
ones required for that.

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

[PATCH 00/22] Random ARM randconfig fixes in drivers

[Arnd Bergmann]

These are a bunch of fixes I had to do to get all randconfig
configurations on ARM working. Most of these are really old
bugs, but there are also some new ones. I don't think any of
them require a backport to linux-stable.

I have checked that they are all still required on yesterday's
linux-next kernel. Please apply on the appropriate trees unless
there are objections.

Patch numbers are per subsystem, which I thought is less confusing
than numbering them 1-22 when they are all totall independent.

Arnd Bergmann (22):
  mdio_bus: fix devm_mdiobus_alloc_size export
  phy: kona2: use 'select GENERIC_PHY' in Kconfig
  phy: exynos: fix SATA phy license typo
  dmaengine: omap: hide filter_fn for built-in drivers
  dmaengine: sa11x0: remove broken #ifdef
  mtd/onenand: fix build warning for dma type
  mtd: orion-nand: fix build error with ARMv4
  clk/versatile: export symbols for impd1
  bus/omap_l3: avoid sync initcall for modules
  bus/arm-cci: add dependency on OF  CPU_V7
  watchdog: iop_wdt only builds for mach-iop13xx
  mpilib: use 'static inline' for mpi-inline.h
  ata: pata_at91 only works on sam9
  i2c/nuc900: fix ancient build error
  iio: always select ANON_INODES
  iio:adc: at91 requires the input subsystem
  pci: rcar host needs OF
  input: fix ps2/serio module dependency
  input: atmel-wm97xx: only build for AVR32
  misc: atmel_pwm: only build for supported platforms
  remoteproc: da8xx: don't select CMA on no-MMU
  regulator: arizona-ldo1: add missing #include

 drivers/ata/Kconfig   | 2 +-
 drivers/bus/Kconfig   | 2 +-
 drivers/bus/omap_l3_noc.c | 4 
 drivers/bus/omap_l3_smx.c | 4 
 drivers/clk/versatile/clk-icst.c  | 1 +
 drivers/clk/versatile/clk-impd1.c | 2 ++
 drivers/dma/sa11x0-dma.c  | 4 
 drivers/i2c/busses/i2c-nuc900.c   | 2 +-
 drivers/iio/Kconfig   | 1 +
 drivers/iio/adc/Kconfig   | 1 +
 drivers/input/keyboard/Kconfig| 2 +-
 drivers/input/mouse/Kconfig   | 2 +-
 drivers/input/touchscreen/Kconfig | 2 +-
 drivers/misc/Kconfig  | 3 ++-
 drivers/mtd/nand/orion_nand.c | 5 +
 drivers/mtd/onenand/samsung.c | 8 
 drivers/net/phy/mdio_bus.c| 2 +-
 drivers/pci/host/Kconfig  | 2 +-
 drivers/phy/Kconfig   | 2 +-
 drivers/phy/phy-exynos5250-sata.c | 2 +-
 drivers/regulator/arizona-ldo1.c  | 1 +
 drivers/remoteproc/Kconfig| 2 +-
 drivers/watchdog/Kconfig  | 2 +-
 include/linux/omap-dma.h  | 2 +-
 lib/mpi/mpi-inline.h  | 2 +-
 lib/mpi/mpi-internal.h| 8 
 26 files changed, 39 insertions(+), 31 deletions(-)

-- 
1.8.3.2

Cc: bhelg...@google.com
Cc: dw...@infradead.org
Cc: dmitry.torok...@gmail.com
Cc: ba...@ti.com
Cc: gre...@linuxfoundation.org
Cc: plagn...@jcrosoft.com
Cc: ji...@kernel.org
Cc: josh...@atmel.com
Cc: kis...@ti.com
Cc: linus.wall...@linaro.org
Cc: broo...@kernel.org
Cc: mturque...@linaro.org
Cc: nicolas.fe...@atmel.com
Cc: o...@wizery.com
Cc: li...@arm.linux.org.uk
Cc: t...@atomide.com
Cc: vinod.k...@intel.com
Cc: w...@iguana.be
Cc: w...@the-dreams.de
Cc: dmaeng...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-watch...@vger.kernel.org
Cc: net...@vger.kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] input: fix ps2/serio module dependency

[Arnd Bergmann]

The ps2 mouse and keyboard drivers use the serio framework that
they correctly select in Kconfig, and that in turn depends on the
i8042 driver, which is also allowed to be disabled for architectures
that don't have an i8042.

However, Kconfig also allows i8042 to be built as a module while
the serio framework is built-in, which causes this link error:

drivers/built-in.o: In function `ps2_begin_command':
:(.text+0x26b6cc): undefined reference to `i8042_check_port_owner'
:(.text+0x26b6d4): undefined reference to `i8042_lock_chip'
drivers/built-in.o: In function `ps2_end_command':
:(.text+0x26b734): undefined reference to `i8042_check_port_owner'
:(.text+0x26b73c): undefined reference to `i8042_unlock_chip'

On x86, a specific 'select SERIO_I8042' takes care of it, but
not on the other architecture that potentially have a u8042.

This patch changes the Kconfig logic to ensure that whenever
there is an i8042, it does get used for the serio driver, avoiding
the link error above.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: linux-input@vger.kernel.org
---
 drivers/input/keyboard/Kconfig | 2 +-
 drivers/input/mouse/Kconfig| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4f115db..dd2435a 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
default y
select SERIO
select SERIO_LIBPS2
-   select SERIO_I8042 if X86
+   select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
select SERIO_GSCPS2 if GSC
help
  Say Y here if you want to use a standard AT or PS/2 keyboard. Usually
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index effa9c5..cf534ee 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -17,7 +17,7 @@ config MOUSE_PS2
default y
select SERIO
select SERIO_LIBPS2
-   select SERIO_I8042 if X86
+   select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
select SERIO_GSCPS2 if GSC
help
  Say Y here if you have a PS/2 mouse connected to your system. This
-- 
1.8.3.2

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

[PATCH 2/2] input: atmel-wm97xx: only build for AVR32

[Arnd Bergmann]

Building this driver on ARM/at91 always gives us this error message:

drivers/input/touchscreen/atmel-wm97xx.c:63:2: error: #error Unknown CPU, this 
driver only supports AT32AP700X CPUs.

Clearly this configuration is not meant to work, so let's just prevent
it in Kconfig. If we ever want to use it on another platform, we should
also pass proper resources for GPIO, IRQ and memory, which are hardcoded
to AT32AP700X at the moment.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: linux-input@vger.kernel.org
---
 drivers/input/touchscreen/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index e2f0264..fe4c264 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -640,7 +640,7 @@ config TOUCHSCREEN_WM9713
 
 config TOUCHSCREEN_WM97XX_ATMEL
tristate WM97xx Atmel accelerated touch
-   depends on TOUCHSCREEN_WM97XX  (AVR32 || ARCH_AT91)
+   depends on TOUCHSCREEN_WM97XX  AVR32
help
  Say Y here for support for streaming mode with WM97xx touchscreens
  on Atmel AT91 or AVR32 systems with an AC97C module.
-- 
1.8.3.2

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

Re: [PATCH v4 1/9] mfd: AXP20x: Add mfd driver for AXP20x PMIC

[Arnd Bergmann]

On Friday 11 April 2014 11:38:05 Carlo Caione wrote:
 +#define AXP20X_IRQ(_irq, _off, _mask) \
 +   [AXP20X_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
 +
 +static const struct regmap_irq axp20x_regmap_irqs[] = {
 +   AXP20X_IRQ(ACIN_OVER_V, 0, 7),
 +   AXP20X_IRQ(ACIN_PLUGIN, 0, 6),
 +   AXP20X_IRQ(ACIN_REMOVAL,0, 5),
 +   AXP20X_IRQ(VBUS_OVER_V, 0, 4),
 +   AXP20X_IRQ(VBUS_PLUGIN, 0, 3),
 +   AXP20X_IRQ(VBUS_REMOVAL,0, 2),
 +   AXP20X_IRQ(VBUS_V_LOW,  0, 1),
 +   AXP20X_IRQ(BATT_PLUGIN, 1, 7),
 +   AXP20X_IRQ(BATT_REMOVAL,1, 6),
 +   AXP20X_IRQ(BATT_ENT_ACT_MODE,   1, 5),
 +   AXP20X_IRQ(BATT_EXIT_ACT_MODE,  1, 4),
 +   AXP20X_IRQ(CHARG,   1, 3),
 +   AXP20X_IRQ(CHARG_DONE,  1, 2),
 +   AXP20X_IRQ(BATT_TEMP_HIGH,  1, 1),

Why do you have to enumerate the interrupts here? Can't you just
put all the numbers into the DT nodes of the devices using them?

In general, I would say that the mfd driver should not care about
what is connected to it.

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

[PATCH 3/3] input: remove obsolete tnetv107x drivers

[Arnd Bergmann]

The tnetv107x platform is getting removed, so the touchscreen
and keypad drivers for this platform will no longer be needed
either.

Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Sekhar Nori nsek...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: linux-input@vger.kernel.org
---
 drivers/input/keyboard/Kconfig|  10 -
 drivers/input/keyboard/Makefile   |   1 -
 drivers/input/keyboard/tnetv107x-keypad.c | 329 -
 drivers/input/touchscreen/Kconfig |   9 -
 drivers/input/touchscreen/Makefile|   1 -
 drivers/input/touchscreen/tnetv107x-ts.c  | 384 --
 6 files changed, 734 deletions(-)
 delete mode 100644 drivers/input/keyboard/tnetv107x-keypad.c
 delete mode 100644 drivers/input/touchscreen/tnetv107x-ts.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a673c9f..935dcaf 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -595,16 +595,6 @@ config KEYBOARD_TC3589X
  To compile this driver as a module, choose M here: the
  module will be called tc3589x-keypad.
 
-config KEYBOARD_TNETV107X
-   tristate TI TNETV107X keypad support
-   depends on ARCH_DAVINCI_TNETV107X
-   select INPUT_MATRIXKMAP
-   help
- Say Y here if you want to use the TNETV107X keypad.
-
- To compile this driver as a module, choose M here: the
- module will be called tnetv107x-keypad.
-
 config KEYBOARD_TWL4030
tristate TI TWL4030/TWL5030/TPS659x0 keypad support
depends on TWL4030_CORE
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index a699b61..81014d9 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -53,7 +53,6 @@ obj-$(CONFIG_KEYBOARD_STOWAWAY)   += stowaway.o
 obj-$(CONFIG_KEYBOARD_SUNKBD)  += sunkbd.o
 obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
 obj-$(CONFIG_KEYBOARD_TEGRA)   += tegra-kbc.o
-obj-$(CONFIG_KEYBOARD_TNETV107X)   += tnetv107x-keypad.o
 obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
 obj-$(CONFIG_KEYBOARD_XTKBD)   += xtkbd.o
 obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/tnetv107x-keypad.c 
b/drivers/input/keyboard/tnetv107x-keypad.c
deleted file mode 100644
index 086511c..000
--- a/drivers/input/keyboard/tnetv107x-keypad.c
+++ /dev/null
@@ -1,329 +0,0 @@
-/*
- * Texas Instruments TNETV107X Keypad Driver
- *
- * Copyright (C) 2010 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed as is WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/err.h
-#include linux/errno.h
-#include linux/input.h
-#include linux/platform_device.h
-#include linux/interrupt.h
-#include linux/slab.h
-#include linux/delay.h
-#include linux/io.h
-#include linux/clk.h
-#include linux/input/matrix_keypad.h
-#include linux/module.h
-
-#define BITS(x)(BIT(x) - 1)
-
-#define KEYPAD_ROWS9
-#define KEYPAD_COLS9
-
-#define DEBOUNCE_MIN   0x400ul
-#define DEBOUNCE_MAX   0x3ffful
-
-struct keypad_regs {
-   u32 rev;
-   u32 mode;
-   u32 mask;
-   u32 pol;
-   u32 dclock;
-   u32 rclock;
-   u32 stable_cnt;
-   u32 in_en;
-   u32 out;
-   u32 out_en;
-   u32 in;
-   u32 lock;
-   u32 pres[3];
-};
-
-#define keypad_read(kp, reg)   __raw_readl((kp)-regs-reg)
-#define keypad_write(kp, reg, val) __raw_writel(val, (kp)-regs-reg)
-
-struct keypad_data {
-   struct input_dev*input_dev;
-   struct resource *res;
-   struct keypad_regs __iomem  *regs;
-   struct clk  *clk;
-   struct device   *dev;
-   spinlock_t  lock;
-   int irq_press;
-   int irq_release;
-   int rows, cols, row_shift;
-   int debounce_ms, active_low;
-   u32 prev_keys[3];
-   unsigned short  keycodes[];
-};
-
-static irqreturn_t keypad_irq(int irq, void *data)
-{
-   struct keypad_data *kp = data;
-   int i, bit, val, row, col, code;
-   unsigned long flags;
-   u32 curr_keys[3];
-   u32 change;
-
-   spin_lock_irqsave(kp-lock, flags

[PATCH 0/3] Remove obsolete tnetv107x drivers

[Arnd Bergmann]

I have applied the platform removal patch with the Ack
from Kevin and Sekhar. Please apply these other patches
through the input/mfd/spi trees.

Arnd Bergmann (3):
  spi: remove obsolete spi-ti-ssp driver
  mfd: remove obsolete ti-ssp driver
  input: remove obsolete tnetv107x drivers

 drivers/input/keyboard/Kconfig|  10 -
 drivers/input/keyboard/Makefile   |   1 -
 drivers/input/keyboard/tnetv107x-keypad.c | 329 -
 drivers/input/touchscreen/Kconfig |   9 -
 drivers/input/touchscreen/Makefile|   1 -
 drivers/input/touchscreen/tnetv107x-ts.c  | 384 
 drivers/mfd/Kconfig   |  11 -
 drivers/mfd/Makefile  |   1 -
 drivers/mfd/ti-ssp.c  | 465 --
 drivers/spi/Kconfig   |   7 -
 drivers/spi/Makefile  |   1 -
 drivers/spi/spi-ti-ssp.c  | 378 
 12 files changed, 1597 deletions(-)
 delete mode 100644 drivers/input/keyboard/tnetv107x-keypad.c
 delete mode 100644 drivers/input/touchscreen/tnetv107x-ts.c
 delete mode 100644 drivers/mfd/ti-ssp.c
 delete mode 100644 drivers/spi/spi-ti-ssp.c

Cc: Mark Brown broo...@kernel.org
Cc: linux-...@vger.kernel.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: linux-input@vger.kernel.org

-- 
1.8.3.2

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

[PATCH 0/5] ARM: davinci: tnetv107x removal

[Arnd Bergmann]

This series removes the TI davinci/tnetv107x platform that
has evidently bitrotted to the point where it's completely
useless. While we could probably fix it and add a defconfig,
it appears that there are actually no users of this platform,
and it complicates the davinci code base because it's
incompatible with all the other SoCs in there that are
based on ARM926T.

The five patches are completely independent of one another,
and applying them out of order is fine since we just want
to remove the code. However, I'm looking for an Ack from
Cyril Chemparathy and Sekhar Nori first, to be sure we
won't need this code in the future. Kevin Hilman has
already mentioned that he sees no reason to keep this
code.

I can apply the first patch directly into arm-soc once
I have an Ack, and I'd like the other patches to get picked
up by the respective subsystem maintainers.

Arnd

Arnd Bergmann (5):
  ARM: davinci: remove tnetv107x support
  gpio: remove obsolete tnetv107x driver
  spi: remove obsolete spi-ti-ssp driver
  mfd: remove obsolete ti-ssp driver
  input: remove obsolete tnetv107x drivers

 arch/arm/Kconfig.debug  |  13 +-
 arch/arm/mach-davinci/Kconfig   |  12 -
 arch/arm/mach-davinci/Makefile  |   2 -
 arch/arm/mach-davinci/board-tnetv107x-evm.c | 287 -
 arch/arm/mach-davinci/devices-tnetv107x.c   | 434 --
 arch/arm/mach-davinci/include/mach/cputype.h|   8 -
 arch/arm/mach-davinci/include/mach/irqs.h   |  97 ---
 arch/arm/mach-davinci/include/mach/mux.h| 269 -
 arch/arm/mach-davinci/include/mach/psc.h|  47 --
 arch/arm/mach-davinci/include/mach/serial.h |   8 -
 arch/arm/mach-davinci/include/mach/tnetv107x.h  |  61 --
 arch/arm/mach-davinci/include/mach/uncompress.h |   6 -
 arch/arm/mach-davinci/tnetv107x.c   | 766 
 drivers/gpio/Makefile   |   1 -
 drivers/gpio/gpio-tnetv107x.c   | 206 ---
 drivers/input/keyboard/Kconfig  |  10 -
 drivers/input/keyboard/Makefile |   1 -
 drivers/input/keyboard/tnetv107x-keypad.c   | 329 --
 drivers/input/touchscreen/Kconfig   |   9 -
 drivers/input/touchscreen/Makefile  |   1 -
 drivers/input/touchscreen/tnetv107x-ts.c| 384 
 drivers/mfd/Kconfig |  11 -
 drivers/mfd/Makefile|   1 -
 drivers/mfd/ti-ssp.c| 465 --
 drivers/spi/Kconfig |   7 -
 drivers/spi/Makefile|   1 -
 drivers/spi/spi-ti-ssp.c| 378 
 include/linux/platform_data/gpio-davinci.h  |   4 -
 28 files changed, 1 insertion(+), 3817 deletions(-)
 delete mode 100644 arch/arm/mach-davinci/board-tnetv107x-evm.c
 delete mode 100644 arch/arm/mach-davinci/devices-tnetv107x.c
 delete mode 100644 arch/arm/mach-davinci/include/mach/tnetv107x.h
 delete mode 100644 arch/arm/mach-davinci/tnetv107x.c
 delete mode 100644 drivers/gpio/gpio-tnetv107x.c
 delete mode 100644 drivers/input/keyboard/tnetv107x-keypad.c
 delete mode 100644 drivers/input/touchscreen/tnetv107x-ts.c
 delete mode 100644 drivers/mfd/ti-ssp.c
 delete mode 100644 drivers/spi/spi-ti-ssp.c

Cc: Alexandre Courbot gnu...@gmail.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Lee Jones lee.jo...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Mark Brown broo...@kernel.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: linux-g...@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-...@vger.kernel.org

-- 
1.8.3.2

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

[PATCH 5/5] input: remove obsolete tnetv107x drivers

[Arnd Bergmann]

The tnetv107x platform is getting removed, so the touchscreen
and keypad drivers for this platform will no longer be needed
either.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: linux-input@vger.kernel.org
---
 drivers/input/keyboard/Kconfig|  10 -
 drivers/input/keyboard/Makefile   |   1 -
 drivers/input/keyboard/tnetv107x-keypad.c | 329 -
 drivers/input/touchscreen/Kconfig |   9 -
 drivers/input/touchscreen/Makefile|   1 -
 drivers/input/touchscreen/tnetv107x-ts.c  | 384 --
 6 files changed, 734 deletions(-)
 delete mode 100644 drivers/input/keyboard/tnetv107x-keypad.c
 delete mode 100644 drivers/input/touchscreen/tnetv107x-ts.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a673c9f..935dcaf 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -595,16 +595,6 @@ config KEYBOARD_TC3589X
  To compile this driver as a module, choose M here: the
  module will be called tc3589x-keypad.
 
-config KEYBOARD_TNETV107X
-   tristate TI TNETV107X keypad support
-   depends on ARCH_DAVINCI_TNETV107X
-   select INPUT_MATRIXKMAP
-   help
- Say Y here if you want to use the TNETV107X keypad.
-
- To compile this driver as a module, choose M here: the
- module will be called tnetv107x-keypad.
-
 config KEYBOARD_TWL4030
tristate TI TWL4030/TWL5030/TPS659x0 keypad support
depends on TWL4030_CORE
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index a699b61..81014d9 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -53,7 +53,6 @@ obj-$(CONFIG_KEYBOARD_STOWAWAY)   += stowaway.o
 obj-$(CONFIG_KEYBOARD_SUNKBD)  += sunkbd.o
 obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
 obj-$(CONFIG_KEYBOARD_TEGRA)   += tegra-kbc.o
-obj-$(CONFIG_KEYBOARD_TNETV107X)   += tnetv107x-keypad.o
 obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
 obj-$(CONFIG_KEYBOARD_XTKBD)   += xtkbd.o
 obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/tnetv107x-keypad.c 
b/drivers/input/keyboard/tnetv107x-keypad.c
deleted file mode 100644
index 086511c..000
--- a/drivers/input/keyboard/tnetv107x-keypad.c
+++ /dev/null
@@ -1,329 +0,0 @@
-/*
- * Texas Instruments TNETV107X Keypad Driver
- *
- * Copyright (C) 2010 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed as is WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/err.h
-#include linux/errno.h
-#include linux/input.h
-#include linux/platform_device.h
-#include linux/interrupt.h
-#include linux/slab.h
-#include linux/delay.h
-#include linux/io.h
-#include linux/clk.h
-#include linux/input/matrix_keypad.h
-#include linux/module.h
-
-#define BITS(x)(BIT(x) - 1)
-
-#define KEYPAD_ROWS9
-#define KEYPAD_COLS9
-
-#define DEBOUNCE_MIN   0x400ul
-#define DEBOUNCE_MAX   0x3ffful
-
-struct keypad_regs {
-   u32 rev;
-   u32 mode;
-   u32 mask;
-   u32 pol;
-   u32 dclock;
-   u32 rclock;
-   u32 stable_cnt;
-   u32 in_en;
-   u32 out;
-   u32 out_en;
-   u32 in;
-   u32 lock;
-   u32 pres[3];
-};
-
-#define keypad_read(kp, reg)   __raw_readl((kp)-regs-reg)
-#define keypad_write(kp, reg, val) __raw_writel(val, (kp)-regs-reg)
-
-struct keypad_data {
-   struct input_dev*input_dev;
-   struct resource *res;
-   struct keypad_regs __iomem  *regs;
-   struct clk  *clk;
-   struct device   *dev;
-   spinlock_t  lock;
-   int irq_press;
-   int irq_release;
-   int rows, cols, row_shift;
-   int debounce_ms, active_low;
-   u32 prev_keys[3];
-   unsigned short  keycodes[];
-};
-
-static irqreturn_t keypad_irq(int irq, void *data)
-{
-   struct keypad_data *kp = data;
-   int i, bit, val, row, col, code;
-   unsigned long flags;
-   u32 curr_keys[3];
-   u32 change;
-
-   spin_lock_irqsave(kp-lock, flags);
-
-   memset(curr_keys, 0, sizeof(curr_keys));
-   if (irq == kp-irq_press

Re: [PATCH 0/5] ARM: davinci: tnetv107x removal

[Arnd Bergmann]

On Wednesday 26 February 2014, Arnd Bergmann wrote:

 The five patches are completely independent of one another,
 and applying them out of order is fine since we just want
 to remove the code. However, I'm looking for an Ack from
 Cyril Chemparathy and Sekhar Nori first, to be sure we
 won't need this code in the future. Kevin Hilman has
 already mentioned that he sees no reason to keep this
 code.

Hmm, apparently Cyril is no longer at TI. If anyone has his
current email address and thinks he might have an opinion,
could you forward the original email?

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

Re: [PATCH] ARM: Kirkwood: Add DT description of QNAP 419

[Arnd Bergmann]

On Saturday 11 January 2014, Andrew Lunn wrote:
 The id of -1 causes platform_device_add() to set the device name to
 plain gpio-keys.
 
 When using DT, the device name is created by the function
 of_device_make_bus_id(). It has the following comment:
 
  * This routine will first try using either the dcr-reg or the reg property
  * value to derive a unique name.  As a last resort it will use the node
  * name followed by a unique number.
 
 Since the gpio_keys node does not have a reg properties, it gets a
 unique number appended to it. We end up with the device name
 gpio_keys.3
 
 So as it stands, it does not appear i can make the DT system use the
 same device name as a board system.
 
 But i'm also a little bit concerned by the unique number and this
 ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this
 path supposed to be stable? This unique number is not stable. An
 unwitting change to the DT could cause its value to change. Do we need
 to make it stable?
 

One possibility would be to create an artificial bus in DT for all
gpio-keys devices, use #address-cells=1 and #size-cells=0
for it, and give each device a unique reg property. Not sure if that
would be considered an elegant solution though.

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

Re: [PATCH] ARM: Kirkwood: Add DT description of QNAP 419

[Arnd Bergmann]

On Wednesday 15 January 2014 18:45:19 Andrew Lunn wrote:
   But i'm also a little bit concerned by the unique number and this
   ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this
   path supposed to be stable? This unique number is not stable. An
   unwitting change to the DT could cause its value to change. Do we need
   to make it stable?
   
  
  One possibility would be to create an artificial bus in DT for all
  gpio-keys devices, use #address-cells=1 and #size-cells=0
  for it, and give each device a unique reg property. Not sure if that
  would be considered an elegant solution though.
 
 Hi Arnd
 
 Can i imply from your answer that you think 
 
 /dev/input/by-path/platform-gpio_keys.3-event
 
 should be stable?

No, I have no idea whether it should be or not. I was just trying
to come up with a way to make it stable if that's desired.

 A quick look at udev rules seems to suggestion this is an issue for
 input/gpio-keys and maybe audio and video if there is a top level DT
 property collecting the different sub devices together for ASOC and
 V4L.

For some other subsystems, we have entries in /aliases/ to sort
them. Maybe that would work here to get a stable path independent
of the location in DT.

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

Re: [PATCH] usb: USB host support should depend on HAS_DMA

[Arnd Bergmann]

On Wednesday 10 July 2013, Alan Stern wrote:
 This isn't right.  There are USB host controllers that use PIO, not
 DMA.  The HAS_DMA dependency should go with the controller driver, not 
 the USB core.
 
 On the other hand, the USB core does call various routines like 
 dma_unmap_single.  It ought to be possible to compile these calls even 
 when DMA isn't enabled.  That is, they should be defined as do-nothing 
 stubs.

The asm-generic/dma-mapping-broken.h file intentionally causes link
errors, but that could be changed.

The better approach in my mind would be to replace code like


if (hcd-self.uses_dma)

with

if (IS_ENABLED(CONFIG_HAS_DMA)  hcd-self.uses_dma) {

which will reliably cause that reference to be omitted from object code,
but not stop giving link errors for drivers that actually require
DMA.

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

Re: [PATCH V3 5/5] input: pxa27x-keypad: add device tree support

[Arnd Bergmann]

On Thursday 20 June 2013, Chao Xie wrote:
 On Wed, Jun 19, 2013 at 7:13 PM, Gerhard Sittig g...@denx.de wrote:
  On Wed, Jun 19, 2013 at 16:38 +0800, Chao Xie wrote:
 
  On Wed, Jun 19, 2013 at 4:22 PM, Marek Vasut ma...@denx.de wrote:
  
   Signed-off-by: Chao Xie chao@marvell.com
   [ ... ]
   +++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
   @@ -0,0 +1,60 @@
   +* Marvell PXA Keypad controller
   +
   +Required Properties
   +- compatible : should be marvell,pxa27x-keypad
   +- reg : Address and length of the register set for the device
   +- interrupts : The interrupt for the keypad controller
   +- marvell,debounce-interval : How long time the key will be
  
   Is there no generic prop name for this debounce interval?
  
  I searched at drivers/input and Documents.
  Two drivers use debounce-interval, gpio-keys.c and stmpe-keypad.c.
  They describe the meanings of debounce-interval at its own document file.
  Some other drivers uses xxx,debounce-delay-ms or debounce-delay-ms
  So it seems that there is no generic prop name for this debounce interval.
 
  Actually there is, but under a different (more user friendly)
  name:  See the 'debounce-delay-ms' property in
  Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
  which gets referenced in the matrix_keypad_parse_dt() routine in
  the drivers/input/keyboard/matrix_keypad.c source file.  Ah, your
  last sentence mentions that fact.
 
  But when you introduce DT support into an existing driver which
  previously used platform data, then there is no problem with
  backwards compatibility in .dts files.  So I suggest to go with
  the debounce-delay-ms name since it better reflects to the .dts
  author (hardware engineer) which unit the number is supposed to
  be specified in.
 
 So Arnd
 What do you think? I am fine with either one.

debounce-delay-ms

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

Re: eGalax touchscreen regression

[Arnd Bergmann]

On Wednesday 24 April 2013 12:03:13 Artem Bityutskiy wrote:
 On Tue, 2013-04-23 at 08:40 -0700, Dmitry Torokhov wrote:
   the eGalax driver now requires OF. For us this is a regression because
   we do not have OF: https://bugs.tizen.org/jira/browse/TIVI-740
  
  I see. In this case we need to come up with a platform data to pass
  wakeup gpio in case platform does not support OF. irq_to_gpio() is not
  supported on many platforms, causing compilation errors.
  
  Is the platform that you are trying to use the touchscreen upstream?
 
 OK, so this is about just a monitor with a touchscreen (Giantec high-res
 capacitive 11.6” LCD monitor). The touchscreen is connected to a
 commodity hardware via USB.
 
 So yes, the platform _is_ upstream  Namely, we use just a SandyBridge
 PC.

So you use a usb-to-i2c interface?

You have to figure out how the wakeup line is connected to the eGalax
device and provide an alternative implementation for egalax_wake_up_device
that can be used in your case then.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Wednesday 20 March 2013, Fabio Porcedda wrote:
 I think we can check inside the  deferred_probe_work_func()
 if the dev-probe function pointer is equal to platform_drv_probe_fail().

I think it's too late by then, because that would only warn if we try to probe
it again, but when platform_driver_probe() does not succeed immediately, it
unregisters the driver again, so we never get there.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Wednesday 20 March 2013, Fabio Porcedda wrote:
 
 On Wed, Mar 20, 2013 at 11:20 AM, Arnd Bergmann a...@arndb.de wrote:
  On Wednesday 20 March 2013, Fabio Porcedda wrote:
  I think we can check inside the  deferred_probe_work_func()
  if the dev-probe function pointer is equal to platform_drv_probe_fail().
 
  I think it's too late by then, because that would only warn if we try to 
  probe
  it again, but when platform_driver_probe() does not succeed immediately, it
 
 Maybe you mean does succeed immediately ?

I mean in this code (simplified for the sake of discussion)

int __init_or_module platform_driver_probe(struct platform_driver *drv,
int (*probe)(struct platform_device *))
{
int retval, code;

drv-probe = probe;
retval = code = platform_driver_register(drv);

drv-probe = NULL;
if (code == 0  list_empty(drv-driver.p-klist_devices.k_list))
retval = -ENODEV;
drv-driver.probe = platform_drv_probe_fail;

if (code != retval)
platform_driver_unregister(drv);
return retval;
}

we assume that all devices are bound to drivers during the call to
platform_driver_register, and if the device list is empty afterwards,
we unregister the driver and will never get to the deferred probing
stage.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
 Hmm, so we may have drivers that (now) work perfectly fine with
 module_platform_driver_probe()/platform_driver_probe(), but will start
 failing suddenly in the future?

They will fail if someone changes the initialization order. That would
already break drivers before deferred probing support (and was the reason
we added feature in the first place), but now we can be much more liberal
with the order in which drivers are initialized, except when they are
using platform_driver_probe()

 I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
 platform_driver_probe() to catch these?

Yes, very good idea.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Tuesday 19 March 2013, Fabio Porcedda wrote:
 On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann a...@arndb.de wrote:
  On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
  Hmm, so we may have drivers that (now) work perfectly fine with
  module_platform_driver_probe()/platform_driver_probe(), but will start
  failing suddenly in the future?
 
  They will fail if someone changes the initialization order. That would
  already break drivers before deferred probing support (and was the reason
  we added feature in the first place), but now we can be much more liberal
  with the order in which drivers are initialized, except when they are
  using platform_driver_probe()
 
  I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
  platform_driver_probe() to catch these?
 
  Yes, very good idea.
 
 If it's fine, I'll send a patch for that.

That would be cool, yes. I looked at it earlier (after sending my email above)
and couldn't find an easy way to do it though, because platform_drv_probe
does not know whether it is called from platform_driver_probe or not.

Maybe using something other than platform_driver_register would work here.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Monday 18 March 2013, Fabio Porcedda wrote:
 Since by using platform_driver_probe() the  function
 ep93xx_pwm_probe() is freed after initialization,
 is better to use module_platform_drive_probe().
 IMHO i don't see any good reason to use module_platform_driver() for
 this driver.

As I commented earlier, the platform_driver_probe() and
module_platform_drive_probe() interfaces are rather dangerous in combination
with deferred probing, I would much prefer Harley's patch.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Monday 18 March 2013, Fabio Porcedda wrote:
 
 On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann a...@arndb.de wrote:
  On Monday 18 March 2013, Fabio Porcedda wrote:
  Since by using platform_driver_probe() the  function
  ep93xx_pwm_probe() is freed after initialization,
  is better to use module_platform_drive_probe().
  IMHO i don't see any good reason to use module_platform_driver() for
  this driver.
 
  As I commented earlier, the platform_driver_probe() and
  module_platform_drive_probe() interfaces are rather dangerous in combination
  with deferred probing, I would much prefer Harley's patch.
 
 Since those drivers don't use -EPROBE_DEFER i was thinking that they don't use
 deferred probing.
 I'm missing something?

clk_get() may return -EPROBE_DEFER after ep93xx is converted to use the
common clk API. We currently return the value of clk_get from the probe()
function, which will automatically do the right thing as long as the probe
function remains reachable.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Friday 15 March 2013, Fabio Porcedda wrote:
  * Regarding the use of module_platform_driver_probe, I'm a little worried 
  about
the interactions with deferred probing. I don't think there are any 
  regressions,
but we should probably make people aware that one cannot return 
  -EPROBE_DEFER
from a platform_driver_probe function.
 
 The use of module_platform_driver_probe() doesn't change anything about that,
 it's exactly the same thing as using return platform_driver_probe().
 I'm right or I'm missing something? Maybe are you just speaking about
 the misuse of platform_driver_probe?

Yes, that was what I meant. The point is that if we need to review or remove
all uses of platform_driver_probe, it would be better not to introduce a
module_platform_driver_probe() interface to make it easier to use.

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

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

[Arnd Bergmann]

On Thursday 14 March 2013, Fabio Porcedda wrote:
 This patch converts the drivers to use the
 module_platform_driver_probe() macro which makes the code smaller and
 a bit simpler.
 
 Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: Arnd Bergmann a...@arndb.de
 ---
  drivers/misc/atmel_pwm.c  | 12 +---
  drivers/misc/ep93xx_pwm.c | 13 +
  2 files changed, 2 insertions(+), 23 deletions(-)

The patch itself seems fine, but there are two issues around it:

* The PWM drivers should really get moved to drivers/pwm and converted to the 
new
  PWM subsystem. I don't know if Hartley or Hans-Christian have plans to do
  that already.

* Regarding the use of module_platform_driver_probe, I'm a little worried about
  the interactions with deferred probing. I don't think there are any 
regressions,
  but we should probably make people aware that one cannot return -EPROBE_DEFER
  from a platform_driver_probe function.

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

Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation

[Arnd Bergmann]

On Monday 14 January 2013, Thierry Reding wrote:
 It certainly sounds like a less complicated way to do it. But it also
 involves adding a function with a made up name and drop a function with
 a perfectly good name instead. I wouldn't even know what name to choose
 for the new API.
 

How about devm_ioremap_resource()? Sounds equally fitting, and is shorter.

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

Re: [PATCH v4 RESEND 1/3] Input: egalax_ts: get gpio from devicetree

[Arnd Bergmann]

On Wednesday 10 October 2012, Dmitry Torokhov wrote:
 On Wed, Oct 10, 2012 at 05:12:01PM +0800, Hui Wang wrote:
  The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework
  and don't support this API anymore.
  
  The i.MX6q sabrelite platform equips an egalax touchscreen controller,
  and this platform already transfered to GENERIC_GPIO framework, to
  support this driver, we use a more generic way to get gpio.
 
 Unfortunately this does break the driver for platforms that do still
 support irq_to_gpio and have not transitioned to device tree (yet?).
 It looks like the API suffered from premature deletion...

The API was changed after all users of irq_to_gpio on ARM were assumed to
be converted. The remaining users either had patches back then that were
not merged in time or were merged after the conversion. Right now what
we have left are:

drivers/ata/pata_rb532_cf.c: blackfin specific, not for ARM

drivers/input/touchscreen/egalax_ts.c: currently broken, patches were sent a 
few times

drivers/pcmcia/db1xxx_ss.c: MIPS specific

drivers/power/tosa_battery.c: has been broken for a long time, ARM PXA specific

drivers/staging/iio/accel/lis3l02dq_core.c: patch was sent recently,
will get merged into 3.7

egalax_ts is currently the only thing that prevents us from building
allyesconfig on ARM.

 I really do not want to add a new platform data structure with only gpio
 in it, is there a better way to detect if irq_to_gpio() (even if only a
 stub) is available?

There are no platforms in the mainline kernel that define an egalax_ts
platforms_device, I think we can safely assume all users are either DT
based, or they need out of tree patches anyway.

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

Re: [PATCH v4 1/3] Input: egalax_ts: get gpio from devicetree node

[Arnd Bergmann]

On Friday 17 August 2012, Shawn Guo wrote:
 On Thu, Aug 16, 2012 at 06:47:29PM +0800, Hui Wang wrote:
  The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework
  and don't support this API anymore.
  
  The i.MX6q sabrelite platform equips an egalax touchscreen controller,
  and this platform already transfered to GENERIC_GPIO framework, to
  support this driver, we use a more generic way to get gpio.
  
  Add a return value checking for waking up the controller in the probe
  function, this guarantee only a workable device can pass init.
  
  Signed-off-by: Hui Wang jason77.w...@gmail.com
 
 Reviewed-by: Shawn Guo shawn@linaro.org

What's the status on this patch? I'm still getting build errors from this
driver, so I guess it was never accepted for the 3.7 merge window.

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

Re: [PATCH 1/1] Input: ab8500-ponkey: Make the distinction between DT and non-DT boots

[Arnd Bergmann]

On Wednesday 08 August 2012, Lee Jones wrote:
 Okay, actually this isn't so easy. Currently we have:
 
 During DT boot:
  - No platform data is passed, hence no IRQ base for AB8500 is either
  - No IRQ base means we register a Linear IRQ Domain
  - MFD sees there is no base and leaves the IRQ resource as a hwirq
  - AB8500 child devices use *_get_virq() to convert the hwirq to a virq
 
 During non-DT boot:
  - Platform data is passed, which contains an IRQ base
  - If an IRQ base is requested we use it to register a Legacy IRQ Domain
  - MFD adds the IRQ base to the hwirq and registers it as a virq
  - AB8500 child devices use *_get_virq() to convert virq to virq - ERROR
 
 I guess my suggestion falls-back to placing logic in *_get_virq() to only
 call irq_create_mapping() when when !ab8500-irq_base.

In general, it seems easier to use the same domain type for both cases.
I don't think that MOP500_AB8500_VIR_GPIO_IRQ_BASE is used anywhere
else besides the .irq_base definition in board-mop500.c, so I would guess
that you can just remove that identifier and always use the linear
domain.

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