summaryrefslogtreecommitdiff
path: root/drivers/hid/hid-cp2112.c
AgeCommit message (Collapse)AuthorFilesLines
2024-10-18HID: replace BUG_ON() with WARN_ON()He Lugang1-1/+2
There is no need to kill the system entirely in HID with BUG_ON, use WARN_ON to handle fault more gracefully which allow the system to keep running. Signed-off-by: He Lugang <helugang@uniontech.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-09-13hid: cp2112: Use irq_get_trigger_type() helperJinjie Ruan1-5/+2
Use irq_get_trigger_type() to replace irq_get_irq_data() and then irqd_get_trigger_type(), if the irq data is NULL it will return 0. No functional changed. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20240913074632.3779321-1-ruanjinjie@huawei.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-10-25hid: cp2112: Fix IRQ shutdown stopping polling for all IRQs on chipDanny Kaehn1-1/+5
Previously cp2112_gpio_irq_shutdown() always cancelled the gpio_poll_worker, even if other IRQs were still active, and did not set the gpio_poll flag to false. This resulted in any call to _shutdown() resulting in interrupts no longer functioning on the chip until a _remove() occurred (a.e. the cp2112 is unplugged or system rebooted). Only cancel polling if all IRQs are disabled/masked, and correctly set the gpio_poll flag, allowing polling to restart when an interrupt is next enabled. Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com> Fixes: 13de9cca514e ("HID: cp2112: add IRQ chip handling") Link: https://lore.kernel.org/r/20231011182317.1053344-1-danny.kaehn@plexus.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-10-04hid: cp2112: Fix duplicate workqueue initializationDanny Kaehn1-2/+2
Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead. Fixes: 13de9cca514e ("HID: cp2112: add IRQ chip handling") Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-07-28HID: cp2112: Use octal permissionsAndy Shevchenko1-2/+2
Octal permissions are preferred as stated in Documentation/dev-tools/checkpatch.rst. Replace symbolic permissions with octal permissions when creating the files. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-13-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Convert to DEVICE_ATTR_RW()Andy Shevchenko1-23/+19
Instead of custom wrapper, use DEVICE_tATTR_RW() directly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-12-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Use sysfs_emit() to instead of scnprintf()Andy Shevchenko1-1/+1
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-11-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Use BIT() in GPIO setter and getterAndy Shevchenko1-2/+2
Use BIT() in GPIO setter and getter for the sake of consistency with GENMASK() usage elsewhere in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-10-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Define all GPIO mask and use itAndy Shevchenko1-2/+3
Define all GPIO mask and use it in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-9-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Define maximum GPIO constant and use itAndy Shevchenko1-2/+3
Define maximum GPIO constant and use it in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-8-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Remove dead codeAndy Shevchenko1-54/+0
Remove cp2112_allocate_irq() and counterparts that seems to be a dead code from day 1. In case somebody needs it, it can be retrieved from Git index. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-7-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Don't call ->to_irq() explicitlyAndy Shevchenko1-4/+3
GPIO library guarantees that ->to_irq() is always exists. Moreover, it tending to become a nische thingy and has to not be used in ordinary drivers. Hence, replace that by irq_find_mapping(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-6-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Switch to for_each_set_bit() to simplify the codeAndy Shevchenko1-6/+2
It's cleaner to use for_each_set_bit() than open coding it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-5-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Make irq_chip immutableAndy Shevchenko1-13/+20
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-4-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-07-28HID: cp2112: Use str_write_read() and str_read_write()Andy Shevchenko1-5/+4
Use str_write_read() and str_read_write() from string_choices.h. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230703185222.50554-3-andriy.shevchenko@linux.intel.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-02-23HID: cp2112: Fix driver not registering GPIO IRQ chip as threadedDanny Kaehn1-0/+1
The CP2112 generates interrupts from a polling routine on a thread, and can only support threaded interrupts. This patch configures the gpiochip irq chip with this flag, disallowing consumers to request a hard IRQ from this driver, which resulted in a segfault previously. Signed-off-by: Danny Kaehn <kaehndan@gmail.com> Link: https://lore.kernel.org/r/20230210170044.11835-1-kaehndan@gmail.com Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2022-06-09HID: cp2112: prevent a buffer overflow in cp2112_xfer()Harshit Mogalapalli1-0/+5
Smatch warnings: drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'data->block[1]' too small (33 vs 255) drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'buf' too small (64 vs 255) The 'read_length' variable is provided by 'data->block[0]' which comes from user and it(read_length) can take a value between 0-255. Add an upper bound to 'read_length' variable to prevent a buffer overflow in memcpy(). Fixes: 542134c0375b ("HID: cp2112: Fix I2C_BLOCK_DATA transactions") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-09-25HID: cp2112: Use struct_group() for memcpy() regionKees Cook1-6/+8
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use struct_group() in struct cp2112_string_report around members report, length, type, and string, so they can be referenced together. This will allow memcpy() and sizeof() to more easily reason about sizes, improve readability, and avoid future warnings about writing beyond the end of report. "pahole" shows no size nor member offset changes to struct cp2112_string_report. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences.) Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Acked-by: Jiri Kosina <jikos@kernel.org> Link: https://lore.kernel.org/lkml/nycvar.YFH.7.76.2108201810560.15313@cbobk.fhfr.pm Signed-off-by: Kees Cook <keescook@chromium.org>
2021-03-08HID cp2112: fix support for multiple gpiochipsDouglas Gilbert1-11/+11
In lk 5.11.0-rc2 connecting a USB based Silicon Labs HID to I2C bridge evaluation board (CP2112EK) causes this warning: gpio gpiochip0: (cp2112_gpio): detected irqchip that is shared with multiple gpiochips: please fix the driver Simply copy what other gpio related drivers do to fix this particular warning: replicate the struct irq_chip object in each device instance rather than have a static object which makes that object (incorrectly) shared by each device. Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-08-17HID: cp2112: Use irqchip templateLinus Walleij1-9/+10
This makes the driver use the irqchip template to assign properties to the gpio_irq_chip instead of using the explicit calls to gpiochip_irqchip_add(). The irqchip is instead added while adding the gpiochip. Cc: Eudean Sun <eudean@arista.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-07-20HID: Replace HTTP links with HTTPS onesAlexander A. Klimov1-1/+1
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-08-19HID: cp2112: prevent sleeping function called from invalid contextBenjamin Tissoires1-2/+6
When calling request_threaded_irq() with a CP2112, the function cp2112_gpio_irq_startup() is called in a IRQ context. Therefore we can not sleep, and we can not call cp2112_gpio_direction_input() there. Move the call to cp2112_gpio_direction_input() earlier to have a working driver. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-07-09Merge tag 'gpio-v5.3-1' of ↵Linus Torvalds1-2/+5
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the big slew of GPIO changes for the v5.3 kernel cycle. This is mostly incremental work this time. Three important things: - The FMC subsystem is deleted through my tree. This happens through GPIO as its demise was discussed in relation to a patch decoupling its GPIO implementation from the standard way of handling GPIO. As it turns out, that is not the only subsystem it reimplements and the authors think it is better do scratch it and start over using the proper kernel subsystems than try to polish the rust shiny. See the commit (ACKed by the maintainers) for details. - Arnd made a small devres patch that was ACKed by Greg and goes into the device core. - SPDX header change colissions may happen, because at times I've seen that quite a lot changed during the -rc:s in regards to SPDX. (It is good stuff, tglx has me convinced, and it is worth the occasional pain.) Apart from this is is nothing controversial or problematic. Summary: Core: - When a gpio_chip request GPIOs from itself, it can now fully control the line characteristics, both machine and consumer flags. This makes a lot of sense, but took some time before I figured out that this is how it has to work. - Several smallish documentation fixes. New drivers: - The PCA953x driver now supports the TI TCA9539. - The DaVinci driver now supports the K3 AM654 SoCs. Driver improvements: - Major overhaul and hardening of the OMAP driver by Russell King. - Starting to move some drivers to the new API passing irq_chip along with the gpio_chip when adding the gpio_chip instead of adding it separately. Unrelated: - Delete the FMC subsystem" * tag 'gpio-v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (87 commits) Revert "gpio: tegra: Clean-up debugfs initialisation" gpiolib: Use spinlock_t instead of struct spinlock gpio: stp-xway: allow compile-testing gpio: stp-xway: get rid of the #include <lantiq_soc.h> dependency gpio: stp-xway: improve module clock error handling gpio: stp-xway: simplify error handling in xway_stp_probe() gpiolib: Clarify use of non-sleeping functions gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants gpiolib: Document new gpio_chip.init_valid_mask field Documentation: gpio: Fix reference to gpiod_get_array() gpio: pl061: drop duplicate printing of device name gpio: altera: Pass irqchip when adding gpiochip gpio: siox: Use devm_ managed gpiochip gpio: siox: Add struct device *dev helper variable gpio: siox: Pass irqchip when adding gpiochip drivers: gpio: amd-fch: make resource struct const devres: allow const resource arguments gpio: ath79: Pass irqchip when adding gpiochip gpio: tegra: Clean-up debugfs initialisation gpio: siox: Switch to IRQ_TYPE_NONE ...
2019-06-07gpio: pass lookup and descriptor flags to request_ownLinus Walleij1-2/+5
When a gpio_chip wants to request a descriptor from itself using gpiochip_request_own_desc() it needs to be able to specify fully how to use the descriptor, notably line inversion semantics. The workaround in the gpiolib.c can be removed and cases (such as SPI CS) where we need at times to request a GPIO with line inversion semantics directly on a chip for workarounds, can be fully supported with this call. Fix up some users of the API that weren't really using the last flag to set up the line as input or output properly but instead just calling direction setting explicitly after requesting the line. Cc: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 288Thomas Gleixner1-9/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 263 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-14gpio: Pass a flag to gpiochip_request_own_desc()Linus Walleij1-1/+1
Before things go out of hand, make it possible to pass flags when requesting "own" descriptors from a gpio_chip. This is necessary if the chip wants to request a GPIO with active low semantics, for example. Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Roger Quadros <rogerq@ti.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-21HID: cp2112: Fix I2C_BLOCK_DATA transactionsEudean Sun1-2/+13
The existing driver erroneously treats I2C_BLOCK_DATA and BLOCK_DATA commands the same. For I2C_BLOCK_DATA reads, the length of the read is provided in data->block[0], but the length itself should not be sent to the slave. In contrast, for BLOCK_DATA reads no length is specified since the length will be the first byte returned from the slave. When copying data back to the data buffer, for an I2C_BLOCK_DATA read we have to take care not to overwrite data->block[0] to avoid overwriting the length. A BLOCK_DATA read doesn't have this concern since the first byte returned by the device is the length and belongs in data->block[0]. For I2C_BLOCK_DATA writes, the length is also provided in data->block[0], but the length itself is not sent to the slave (in contrast to BLOCK_DATA writes where the length prefixes the data sent to the slave). This was tested on physical hardware using i2cdump with the i and s flags to test the behavior of I2C_BLOCK_DATA reads and BLOCK_DATA reads, respectively. Writes were not tested but the I2C_BLOCK_DATA write change is pretty simple to verify by inspection. Signed-off-by: Eudean Sun <eudean@arista.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-11-10HID: cp2112: fix broken gpio_direction_input callbackSébastien Szymanski1-2/+6
When everything goes smoothly, ret is set to 0 which makes the function to return EIO error. Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling") Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-11-10HID: cp2112: fix interface specification URLSébastien Szymanski1-1/+1
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-03-21HID: cp2112: use proper hidraw name with minor numberJaejoong Kim1-1/+3
The cp2112 driver is working on hidraw not hiddev. So we need to use proper hidraw name with hidraw's minor number. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-01-31HID: cp2112: fix gpio-callback error handlingJohan Hovold1-1/+1
In case of a zero-length report, the gpio direction_input callback would currently return success instead of an errno. Fixes: 1ffb3c40ffb5 ("HID: cp2112: make transfer buffers DMA capable") Cc: stable <stable@vger.kernel.org> # 4.9 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-01-31HID: cp2112: fix sleep-while-atomicJohan Hovold1-15/+11
A recent commit fixing DMA-buffers on stack added a shared transfer buffer protected by a spinlock. This is broken as the USB HID request callbacks can sleep. Fix this up by replacing the spinlock with a mutex. Fixes: 1ffb3c40ffb5 ("HID: cp2112: make transfer buffers DMA capable") Cc: stable <stable@vger.kernel.org> # 4.9 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-28HID: cp2112: add IRQ chip handlingBenjamin Tissoires1-3/+202
The GPIO part doesn't provide interrupts when GPIO are toggled. So use a polling mechanism if someone requests a GPIO as an IRQ. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-23HID: cp2112: make transfer buffers DMA capableBenjamin Tissoires1-36/+79
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove buffers allocated on the stack. Use a spinlock to prevent concurrent accesses to the buffer. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-01-17Merge tag 'gpio-v4.5-1' of ↵Linus Torvalds1-11/+7
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "Here is the bulk of GPIO changes for v4.5. Notably there are big refactorings mostly by myself, aimed at getting the gpio_chip into a shape that makes me believe I can proceed to preserve state for a proper userspace ABI (character device) that has already been proposed once, but resulted in the feedback that I need to go back and restructure stuff. So I've been restructuring stuff. On the way I ran into brokenness (return code from the get_value() callback) and had to fix it. Also, refactored generic GPIO to be simpler. Some of that is still waiting to trickle down from the subsystems all over the kernel that provide random gpio_chips, I've touched every single GPIO driver in the kernel now, oh man I didn't know I was responsible for so much... Apart from that we're churning along as usual. I took some effort to test and retest so it should merge nicely and we shook out a couple of bugs in -next. Infrastructural changes: - In struct gpio_chip, rename the .dev node to .parent to better reflect the fact that this is not the GPIO struct device abstraction. We will add that soon so this would be totallt confusing. - It was noted that the driver .get_value() callbacks was sometimes reporting negative -ERR values to the gpiolib core, expecting them to be propagated to consumer gpiod_get_value() and gpio_get_value() calls. This was not happening, so as there was a mess of drivers returning negative errors and some returning "anything else than zero" to indicate that a line was active. As some would have bit 31 set to indicate "line active" it clashed with negative error codes. This is fixed by the largeish series clamping values in all drivers with !!value to [0,1] and then augmenting the code to propagate error codes to consumers. (Includes some ACKed patches in other subsystems.) - Add a void *data pointer to struct gpio_chip. The container_of() design pattern is indeed very nice, but we want to reform the struct gpio_chip to be a non-volative, stateless business, and keep states internal to the gpiolib to be able to hold on to the state when adding a proper userspace ABI (character device) further down the road. To achieve this, drivers need a handle at the internal state that is not dependent on their struct gpio_chip() so we add gpiochip_add_data() and gpiochip_get_data() following the pattern of many other subsystems. All the "use gpiochip data pointer" patches transforms drivers to this scheme. - The Generic GPIO chip header has been merged into the general <linux/gpio/driver.h> header, and the custom header for that removed. Instead of having a separate mm_gpio_chip struct for these generic drivers, merge that into struct gpio_chip, simplifying the code and removing the need for separate and confusing includes. Misc improvements: - Stabilize the way GPIOs are looked up from the ACPI legacy specification. - Incremental driver features for PXA, PCA953X, Lantiq (patches from the OpenWRT community), RCAR, Zynq, PL061, 104-idi-48 New drivers: - Add a GPIO chip to the ALSA SoC AC97 driver. - Add a new Broadcom NSP SoC driver (this lands in the pinctrl dir, but the branch is merged here too to account for infrastructural changes). - The sx150x driver now supports the sx1502" * tag 'gpio-v4.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (220 commits) gpio: generic: make bgpio_pdata always visible gpiolib: fix chip order in gpio list gpio: mpc8xxx: Do not use gpiochip_get_data() in mpc8xxx_gpio_save_regs() gpio: mm-lantiq: Do not use gpiochip_get_data() in ltq_mm_save_regs() gpio: brcmstb: Allow building driver for BMIPS_GENERIC gpio: brcmstb: Set endian flags for big-endian MIPS gpio: moxart: fix build regression gpio: xilinx: Do not use gpiochip_get_data() in xgpio_save_regs() leds: pca9532: use gpiochip data pointer leds: tca6507: use gpiochip data pointer hid: cp2112: use gpiochip data pointer bcma: gpio: use gpiochip data pointer avr32: gpio: use gpiochip data pointer video: fbdev: via: use gpiochip data pointer gpio: pch: Optimize pch_gpio_get() Revert "pinctrl: lantiq: Implement gpio_chip.to_irq" pinctrl: nsp-gpio: use gpiochip data pointer pinctrl: vt8500-wmt: use gpiochip data pointer pinctrl: exynos5440: use gpiochip data pointer pinctrl: at91-pio4: use gpiochip data pointer ...
2016-01-07hid: cp2112: use gpiochip data pointerLinus Walleij1-10/+6
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: linux-input@vger.kernel.org Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-12-28HID: use to_hid_device()Geliang Tang1-4/+4
Use to_hid_device() instead of container_of(). Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-11-19gpio: change member .dev to .parentLinus Walleij1-1/+1
The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-14HID: cp2112: fix byte order in SMBUS operationsEllen Wang1-4/+4
Change all occurrences of be16 to le16 in cp2112_xfer(), because SMBUS words are little endian, not big endian. Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com> Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.com>
2015-07-14HID: cp2112: fix I2C_SMBUS_BYTE writeEllen Wang1-1/+1
When doing an I2C_SMBUS_BYTE write (one byte write, no address), the data to be written is in "command" not "data->byte". Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.com>
2015-07-10HID: cp2112: support i2c write-read transfers in hid-cp2112Ellen Wang1-19/+55
cp2112_i2c_xfer() only supports a single i2c_msg. More than one message at a time just returns EIO. This breaks certain important cases. For example, the at24 eeprom driver generates paired write and read messages (for eeprom address and data). Since the device doesn't support i2c repeated starts in general, but does support a single write-repeated-start-read pair (since hardware rev 1), we recognize the latter case and implement only that. Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2015-07-09HID: cp2112: support large i2c transfersEllen Wang1-7/+24
cp2112_i2c_xfer() only reads up to 61 bytes, returning EIO on longers reads. The fix is to wrap a loop around cp2112_read() to pick up all the returned data. Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2015-07-08HID: cp2112: fix to force single data-report replyAntonio Borneo1-0/+2
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: Antonio Borneo <borneo.antonio@gmail.com> Tested-by: Ellen Wang <ellen@cumulusnetworks.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2014-09-18driver:gpio remove all usage of gpio_remove retval in driverabdoulaye berthe1-4/+2
this remove all reference to gpio_remove retval in all driver except pinctrl and gpio. the same thing is done for gpio and pinctrl in two different patches. Signed-off-by: Abdoulaye Berthe <berthe.ab@gmail.com> Acked-by: Michael Büsch <m@bues.ch> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-29HID: cp2112: add I2C modeAntonio Borneo1-1/+102
cp2112 supports single I2C read/write transactions. It can't combine I2C transactions. Add master_xfer, using similar code flow as for smbus_xfer. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-07-07HID: cp2112: fix gpio value in gpio_direction_outputAntonio Borneo1-2/+6
CP2112 does not offer an atomic method to set both gpio direction and value. Also it does not permit to set gpio value before putting gpio in output. In fact, accordingly to Silicon Labs AN495, Rev. 0.2, cpt. 4.4, the HID report to set gpio values "does not affect any pins that are not configured as outputs". This is confirmed on evaluation board CP2112-EK. With current driver, after execute: echo in > /sys/class/gpio/gpio248/direction echo low > /sys/class/gpio/gpio248/direction gpio output is still high. Only after a following echo low > /sys/class/gpio/gpio248/direction gpio output gets low. Fix driver by changing order of operations; first set direction then set value. The drawback of this new sequence is that we can have a pulse on gpio pin when direction is changed from input to output-low, but this cannot be avoided on current CP2112. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-03-14HID: cp2112: remove the last hid_output_raw_report() callBenjamin Tissoires1-1/+6
tests have shown that output reports use hid_hw_output_report(). Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-03-14HID: cp2112: remove various hid_out_raw_report callsBenjamin Tissoires1-6/+6
hid_out_raw_report is going to be obsoleted as it is not part of the unified HID low level transport documentation (Documentation/hid/hid-transport.txt) hid_output_raw_report(hdev, buf, sizeof(buf), HID_FEATURE_REPORT); is strictly equivalent to: hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf), HID_FEATURE_REPORT, HID_REQ_SET_REPORT); Then replace buf[0] by the appropriate define. So use the new api. Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-18HID: cp2112: fix incorrect error propagation in cp2112_xfer()Jiri Kosina1-1/+1
Both cp2112_read_req() and cp2112_write_req() are returning negative value in cases of error, but cp2112_xfer() is storing the return value into unsigned size_t-typed 'count'. Fix this by making 'count' signed type. Reported-by: fengguang.wu@intel.com Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-18HID: cp2112: convert to use hid_hw_raw_request()Jiri Kosina1-8/+10
Commit cafebc0 ("HID: remove hid_get_raw_report in struct hid_device") obsoletes the use of hdev->hid_get_raw_report(), as calling hid_hw_raw_request() is functionally equivalent. Convert cp2112 to use this notation. Reported-by: fengguang.wu@intel.com Signed-off-by: Jiri Kosina <jkosina@suse.cz>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 11:19:42 +0000