Get rid of the packed structures for representing data as that does not
apply to other similar Ilitek touchscreens. Instead, implement a function
which parses the data and reports touch events and coordinates.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Convert the driver to devm_request_irq(), drop the related unmanaged
deregistration code and add ili210x_irq_teardown() to tear the IRQ
down and cancel possible touchscreen pending work.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The touchscreen can have a reset GPIO connected to it, add support
for such an arrangement.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Convert the driver to dev-managed allocations.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The .get_pendown_state callback is set only by the platform data code,
which was just removed. Thus, get_pendown_state() always returns false,
so drop that altogether.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

There is not a single user of the ili210x platform data in the kernel,
just drop it.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add DT binding document for the Ilitek ILI210x and ILI251x
touchscreen controllers.
Signed-off-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds a new vibrator driver that supports various Qualcomm
MSM SOCs. Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: NBrian Masney <masneyb@onstation.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On some platforms (e.g.: ARCH_BRCMSTB) it is possible to enter
"poweroff" while leaving some wake-up sources enabled such as key
presses in order to allow for the system to wake-up.

Wire up a .shutdown() callback which calls into the existing
gpio_keys_suspend() since the logic is essentially the same.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

We should rely on the interrupt trigger (level vs edge) set up by the
firmware or board code instead of forcing what we consider appropriate.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some of the #defined register values are one-bit flags. Convert them to
use the BIT(x) macro instead of 1 byte hexadecimal values. This improves
readability and clarifies the intent.
Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

of_touchscreen.c provides a common interface for a axis inversion and
swapping of touchscreens. Therefore use it in the sx8654 driver.
Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
Reviewed-by: NRob Herring <robh@kernel.org>
[dtor: use __be16 in sx8650_irq, add missing del_timer_sync]
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.

If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This adds myself as an author of the st1232 driver module as Tony's
email address doesn't seem to work anymore.
Signed-off-by: NMartin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add support for the Sitronix ST1633 touchscreen controller to the st1232
driver. A protocol spec can be found here:
www.ampdisplay.com/documents/pdf/AM-320480B6TZQW-TC0H.pdf
Signed-off-by: NMartin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Unfortunately the evervision focaltech implementation uses two offset
registers, one for the x coordinate and one for y.

This patch extends the driver to handle those offset registers only for
devices that support these.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Currently only the threshold and gain parameters can be read.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Evervision displays are using different Focaltech touchscreen
controllers. This commit adds the initial support for the ones using the
FT5726 controller. Receiving the touch data is the same as for the
GENERIC_FT but the x and y cooridnates are swapped. The main differences
are the register addresses where the GAIN and THRESHOLD parameters are
stored.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

iSOrt includes in alphabetical order and remove duplicated include file
linux/kernel.h
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:

struct foo {
    int stuff;
    void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with
memory for some number of elements for that array. For example:

struct foo {
    int stuff;
    void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Merge with mainline to bring in the new APIs.

regmap_bulk_read() can return a non zero value on failure. The fix checks
if the function call succeeded before calling mod_timer. The issue was
identified by a static analysis tool.
Signed-off-by: NAditya Pakki <pakki001@umn.edu>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The touchkey variant found on aries board is slighty different,
it uses a fixed regulator and writes/read to the same place
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Not all devices use the same keycodes in the same order,
so add possibility to define keycodes for buttons present
on actual hardware.

If keycodes property is not present, we assume that device has
at least MENU and BACK keys.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

tm2-touchkey doesn't have brightness levels, but only on/off states,
so replace LED_FULL with LED_ON.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The touchkey on midas boards is almost identical.
The only real difference is that it uses the same register for both
keycode and base.
Signed-off-by: NSimon Shields <simon@lineageos.org>
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Microsoft documenation for the PNP0C40 device aka the
"Windows-compatible button array" describes the 5th GpioInt listed in
the resources as: '5. Interrupt corresponding to the "Rotation Lock"
button, if supported'.

Notice this describes the 5th entry as a button while we sofar have been
mapping it to EV_SW, SW_ROTATE_LOCK. On my Point of View TAB P1006W-232
which actually comes with a rotation-lock button, the button indeed is a
button and not a slider/switch. An image search for other Windows tablets
has found 2 more models with a rotation-lock button and on both of those
it too is a push-button and not a slider/switch.

Further evidence can be found in the HUT extension HUTRR52 from Microsoft
which adds rotation lock support to the HUT, which describes 2 different
usages: "0xC9 System Display Rotation Lock Button" and
"0xCA System Display Rotation Lock Slider Switch" note that switch is seen
as a separate thing here and the non switch wording is an exact match for
the "Windows-compatible button array" spec wording.

TL;DR: our current mapping of the 5th GPIO to SW_ROTATE_LOCK is wrong
because the 5th GPIO is for a push-button not a switch.

This commit fixes this by maping the 5th GPIO to KEY_ROTATE_LOCK_TOGGLE.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The ACPI0011 _DSD button descriptor on a CHT based Intel Compute Sticks
contains a mapping for usage-page 0x01 usage-id 0xca.

As described in hutrr52_system_display_rotation_lock_controls_0.pdf this
should be mapped as a "System Display Rotation Lock Slider Switch", this
commit adds support for this, silencing the following warning:

soc_button_array ACPI0011:00: Unknown button index 4 upage 01 usage ca,
ignoring
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

If the user attempts to update Atmel device with an invalid configuration
cfg file, error handling code is trying to free cfg file memory which is
not allocated yet hence results into kernel crash.

This patch fixes the order of memory free operations.
Signed-off-by: NSanjeev Chugh <sanjeev_chugh@mentor.com>
Fixes: a4891f10 ("Input: atmel_mxt_ts - zero terminate config firmware file")
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Pull vfs fixes from Al Viro:
 "A couple of fixes - no common topic ;-)"

[ The aio spectre patch also came in from Jens, so now we have that
  doubly fixed .. ]

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  proc/sysctl: don't return ENOMEM on lookup when a table is unregistering
  aio: fix spectre gadget in lookup_ioctx

Pull SCSI fixes from James Bottomley:
 "This is two simple target fixes and one discard related I/O starvation
  problem in sd.

  The discard problem occurs because the discard page doesn't have a
  mempool backing so if the allocation fails due to memory pressure, we
  then lose the forward progress we require if the writeout is on the
  same device. The fix is to back it with a mempool"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: sd: use mempool for discard special page
  scsi: target: iscsi: cxgbit: add missing spin_lock_init()
  scsi: target: iscsi: cxgbit: fix csk leak

Pull compiler_types.h fix from Miguel Ojeda:
 "A cleanup for userspace in compiler_types.h: don't pollute userspace
  with macro definitions (Xiaozhou Liu)

  This is harmless for the kernel, but v4.19 was released with a few
  macros exposed to userspace as the patch explains; which this removes,
  so it *could* happen that we break something for someone (although
  leaving inline redefined is probably worse)"

* tag 'compiler-attributes-for-linus-v4.20' of https://github.com/ojeda/linux:
  include/linux/compiler_types.h: don't pollute userspace with macro definitions

Pull auxdisplay fix from Miguel Ojeda:
 "charlcd: fix x/y command parsing (Mans Rullgard)"

* tag 'auxdisplay-for-linus-v4.20' of https://github.com/ojeda/linux:
  auxdisplay: charlcd: fix x/y command parsing

This reverts commit 55956b59.

commit 55956b59 ("vfs: Allow userns root to call mknod on owned filesystems.")
enabled mknod() in user namespaces for userns root if CAP_MKNOD is
available. However, these device nodes are useless since any filesystem
mounted from a non-initial user namespace will set the SB_I_NODEV flag on
the filesystem. Now, when a device node s created in a non-initial user
namespace a call to open() on said device node will fail due to:

bool may_open_dev(const struct path *path)
{
        return !(path->mnt->mnt_flags & MNT_NODEV) &&
                !(path->mnt->mnt_sb->s_iflags & SB_I_NODEV);
}

The problem with this is that as of the aforementioned commit mknod()
creates partially functional device nodes in non-initial user namespaces.
In particular, it has the consequence that as of the aforementioned commit
open() will be more privileged with respect to device nodes than mknod().
Before it was the other way around. Specifically, if mknod() succeeded
then it was transparent for any userspace application that a fatal error
must have occured when open() failed.

All of this breaks multiple userspace workloads and a widespread assumption
about how to handle mknod(). Basically, all container runtimes and systemd
live by the slogan "ask for forgiveness not permission" when running user
namespace workloads. For mknod() the assumption is that if the syscall
succeeds the device nodes are useable irrespective of whether it succeeds
in a non-initial user namespace or not. This logic was chosen explicitly
to allow for the glorious day when mknod() will actually be able to create
fully functional device nodes in user namespaces.
A specific problem people are already running into when running 4.18 rc
kernels are failing systemd services. For any distro that is run in a
container systemd services started with the PrivateDevices= property set
will fail to start since the device nodes in question cannot be
opened (cf. the arguments in [1]).

Full disclosure, Seth made the very sound argument that it is already
possible to end up with partially functional device nodes. Any filesystem
mounted with MS_NODEV set will allow mknod() to succeed but will not allow
open() to succeed. The difference to the case here is that the MS_NODEV
case is transparent to userspace since it is an explicitly set mount option
while the SB_I_NODEV case is an implicit property enforced by the kernel
and hence opaque to userspace.

[1]: https://github.com/systemd/systemd/pull/9483Signed-off-by: NChristian Brauner <christian@brauner.io>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Serge Hallyn <serge@hallyn.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We really need the writecombine flag in dma_alloc_wc, fix a stupid
oversight.

Fixes: 7ed1d91a ("dma-mapping: translate __GFP_NOFAIL to DMA_ATTR_NO_WARN")
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are some statements that are indented incorrectly, fix this by
removing the extra tabs.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>