Looks like 0x8882 needs the same quirk than 0x8883.
Given that both devices claim they are "TPV OpticalTouchScreen" rename
the 0x8883 to add its PID in the #define.
Reported-by: NBlaine Lee <blaine.j.lee@medtronic.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.

Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason.  The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.

The check for HID_NO_BANDWIDTH was inverted.  Fix was simple.

Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The 'wacom_wireless_work' function does not recalculate the tablet's
resolution, causing the value contained in the 'features' struct to
always be reported to userspace. This value is valid only for the pen
interface, meaning that the value will be incorrect for the touchpad (if
present). This in particular causes problems for libinput which relies
on the reported resolution being correct.

This patch adds the necessary calls to recalculate the resolution for
each interface. This requires a little bit of code shuffling since both
the 'wacom_set_default_phy' and 'wacom_calculate_res' are declared below
their new first point of use in 'wacom_wireless_work'.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

As an extension of aef3156d, there is no sense in repeatedly calling the
'wacom_set_report' and 'wacom_get_report' functions if they return an
error. Getting an error from them implies that the device is out to lunch:
either a hard error code was returned or repeated attempts at recovering
from a "soft" error all failed. In either case, doing even more retries is
not likely to resolve whatever is wrong.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

During unbinding the driver was dereferencing a pointer to memory
already freed by power_supply_unregister().

Driver was freeing its internal description of battery through pointers
stored in power_supply structure. However, because the core owns the
power supply instance, after calling power_supply_unregister() this
memory is freed and the driver cannot access these members.

Fix this by storing the pointer to internal description of battery in a
local variable before calling power_supply_unregister(), so the pointer
remains valid.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: NH.J. Lu <hjl.tools@gmail.com>
Fixes: 297d716f ("power_supply: Change ownership from driver to core")
Cc: <stable@vger.kernel.org>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

The limit should be ARRAY_SIZE(params) (5 elements) here instead of
sizeof(params) (20 bytes).

Fixes: 08177f40 ('HID: uclogic: merge hid-huion driver in hid-uclogic')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Some device present proprietary collections with a usage min of 0x00 and
a usage max of 0xffff. hid-core currently reject them while most of the
time this is harmless.
Let's ignore the exceeding usages, and hope for the best.
Reported-by: NSimon Wörner <mail@simon-woerner.de>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

We need to emit EV_SYN/SYN_REPORT between key press and release, otherwise
userspace is allowed to "swallow" the event.

[jkosina@suse.com: Dmitry says that he's observing this behavior with
 Plantronics headset]
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

The input_free_device() function tests whether its argument is NULL and
then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Current implementation of cp2112_raw_event() only accepts one data report at a
time. If last received data report is not fully handled yet, a new incoming
data report will overwrite it. In such case we don't guaranteed to propagate
the correct incoming data.

The trivial fix implemented here forces a single report at a time by requesting
in cp2112_read() no more than 61 byte of data, which is the payload size of a
single data report.

Cc: stable@vger.kernel.org
Signed-off-by: NAntonio Borneo <borneo.antonio@gmail.com>
Tested-by: NEllen Wang <ellen@cumulusnetworks.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Commit 862cf553 ("HID: wacom: Introduce a new WACOM_DEVICETYPE_PAD device_type")
neglected to set the WACOM_DEVICETYPE_PAD flag for older two-finger Bamboo
Touch tablets. Not only does this result in the pad device not appearing when
such a tablet is plugged in, but also causes a segfault when 'wacom_bpt_touch'
tries to send pad events. This patch adds the flag to resolve these issues.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

During open() it is unnecessary to wait for the device to flush
stale inputs if the device is polled while closed due to a quirk
or opening fails.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Fields like HID_DG_CONTACTCOUNT are outside of the physical collection,
but within the application collection and report ID.  Make sure to catch
those fields that are not part of the mt_report_id and return 0 so they
can be processed with the pen.  Otherwise, the wrong HID_DG_CONTACTCOUNT
will be applied to cc_index and result in dereferencing a null pointer in
mt_touch_report.
Signed-off-by: NBrent Adam <brentadam@smarttech.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

The newer firmware on MS Surface 2 tablets causes the type and touch cover keyboards to timeout when waiting for reports.
The quirk HID_QUIRK_NO_INIT_REPORTS allows them to function normally.
Signed-off-by: NReyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We can't pass a NULL to input_unregister_device().

Fixes: 2a6cdbdd ('HID: wacom: Introduce new 'touch_input' device')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The CESA driver calls phys_to_virt() which is not available on all
architectures.
Remove the depency on COMPILE_TEST to prevent building this driver on
non ARM architectures.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Suggested-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add hwmon driver for the Microchip TC74.

The TC74 is a single-input 8-bit I2C temperature sensor,
with +-2 degrees centigrade accuracy.
Signed-off-by: NMaciej Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

This driver leaks out into arch/parisc builds that don't have
CONFIG_GENERIC_CLOCKEVENTS, leading to the following (truncated)
wreckage:

  CC      drivers/clocksource/timer-stm32.o
drivers/clocksource/timer-stm32.c:38:28: error: field 'evtdev' has incomplete type
drivers/clocksource/timer-stm32.c:44:19: warning: 'enum clock_event_mode' declared inside parameter list
drivers/clocksource/timer-stm32.c:44:19: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/clocksource/timer-stm32.c:43:62: error: parameter 1 ('mode') has incomplete type
drivers/clocksource/timer-stm32.c:43:13: error: function declaration isn't a prototype
drivers/clocksource/timer-stm32.c: In function 'stm32_clock_event_set_mode':
drivers/clocksource/timer-stm32.c:47:3: error: type defaults to 'int' in declaration of '__mptr'
drivers/clocksource/timer-stm32.c:47:3: warning: initialization from incompatible pointer type
drivers/clocksource/timer-stm32.c:51:7: error: 'CLOCK_EVT_MODE_PERIODIC' undeclared (first use in this function)
drivers/clocksource/timer-stm32.c:51:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/clocksource/timer-stm32.c:56:7: error: 'CLOCK_EVT_MODE_ONESHOT' undeclared (first use in this function)

Tighten up the dependencies to limit where it gets built by copying
the style of the Kconfig line for CLKSRC_EFM32 a few lines above.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: http://lkml.kernel.org/r/1434841352-24300-1-git-send-email-paul.gortmaker@windriver.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

clk_prepare_enable() may fail, so we should better check its return value
and propagate it in the case of error.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The picoXcell hardware crypto accelerator driver was using an
older version of the clk framework, and not (un)preparing the
clock before enabling/disabling it.  This change uses the handy
clk_prepare_enable function to interact with the current clk
framework correctly.
Signed-off-by: NMichael van der Westhuizen <michael@smart-africa.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The nx driver reads two crucial paramters from the firmware for
each crypto algorithm, the maximum SG list length and byte limit.
Unfortunately those two parameters may be bogus, or worse they
may be absent altogether.  When this happens the algorithms will
still register successfully but will fail when used or tested.

This patch adds checks to report any firmware entries which are
found to be bogus, and avoid registering algorithms which have
bogus parameters.  A warning is also printed when an algorithm
is not registered because of this as there may have been no firmware
entries for it at all.
Reported-by: NOndrej Moriš <omoris@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.

Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is explicitly requested to do
so).
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The old and new marvell CESA drivers both support Orion and Kirkwood SoCs.
Add a module parameter to choose whether these SoCs should be attached to
the new or the old driver.

The default policy is to keep attaching those IPs to the old driver if it
is enabled, until we decide the new CESA driver is stable/secure enough.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for SHA256 operations.
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for MD5 operations.
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for Triple-DES operations.
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for DES operations.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).

Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.

This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.

Other algorithms and platforms will be added later on.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support on Dove and Kirkwood.
In the other hand, the migration from the old driver to the new one is not
something all people are willing to do without first auditing the new
driver.
Hence we have to support the new compatible in the mv_cesa driver so that
new platforms with updated DTs can still attach their crypto engine device
to this driver.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.

This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine

The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.

To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.

Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Trivial fix that prevents to compile this pmc clock driver if h32mx clock is
present but smd clock isn't.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Fixes: bcc5fd49 ("clk: at91: add a driver for the h32mx clock")
Cc: <stable@vger.kernel.org> # 3.18+

Fix the PERIPHERAL_MAX_SHIFT definition (3 instead of 4) and adapt the
round_rate and set_rate logic accordingly.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: N"Wu, Songjun" <Songjun.Wu@atmel.com>

The PLL impose a certain input range to work correctly, but it appears that
this input range does not apply on the input clock (or parent clock) but
on the input clock after it has passed the PLL divisor.
Fix the implementation accordingly.

Cc: <stable@vger.kernel.org> # v3.14+
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: NJonas Andersson <jonas@microbit.se>

Add support to the nx-842-pseries.c driver for running in little endian
mode.

The pSeries platform NX 842 driver currently only works as big endian.
This adds cpu_to_be*() and be*_to_cpu() in the appropriate places to
work in LE mode also.
Signed-off-by: NDan Streetman <ddstreet@ieee.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The new aead_edesc_alloc left out the bit indicating the last
entry on the source SG list.  This patch fixes it.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

I incorrectly removed DESC_MAX_USED_BYTES when enlarging the size
of the shared descriptor buffers, thus making it four times larger
than what is necessary.  This patch restores the division by four
calculation.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The pciehp_handle_*() functions (pciehp_handle_attention_button(), etc.)
only contain a line or two of useful code, so it's clumsy to put
them in separate functions.  All they so is add an event to a work queue,
and it's clearer to see that directly in the ISR.

Inline them directly into pcie_isr().  No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRajat Jain <rajatja@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>