- 21 Mar, 2017 9 commits
-
-
Logan Gunthorpe authored
This replaces the suspect looking cdev.kobj.parent lines with the equivalent cdev_set_parent function. This is a straightforward change that's largely cosmetic but it does push the kobj.parent ownership into char_dev.c where it belongs. Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason Gunthorpe authored
The use after free is not triggerable here because the cdev holds the module lock and the only device_unregister is only triggered by module unload, however make the change for consistency. To make this work the cdev_del needs to move out of the struct device release function. This cleans up the error path significantly and thus also fixes a minor bug where the devnum would not be released if cdev_add failed. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. At the same time we cleanup the error path through device_probe function: we use put_device instead of kfree directly as recommended by the device_initialize documentation. Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper in evdev, joydev and mousedev. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Dan Williams authored
If device_add() fails, cleanup the cdev. Otherwise, we leak a kobj_map() with a stale device number. As Jason points out, there is a small possibility that userspace has opened and mapped the device in the time between cdev_add() and the device_add() failure. We need a new kill_dax_dev() helper to invalidate any established mappings. Fixes: ba09c01d ("dax: convert to the cdev api") Cc: <stable@vger.kernel.org> Reported-by:
-
Logan Gunthorpe authored
Credit for this patch goes is shared with Dan Williams [1]. I've taken things one step further to make the helper function more useful and clean up calling code. There's a common pattern in the kernel whereby a struct cdev is placed in a structure along side a struct device which manages the life-cycle of both. In the naive approach, the reference counting is broken and the struct device can free everything before the chardev code is entirely released. Many developers have solved this problem by linking the internal kobjs in this fashion: cdev.kobj.parent = &parent_dev.kobj; The cdev code explicitly gets and puts a reference to it's kobj parent. So this seems like it was intended to be used this way. Dmitrty Torokhov first put this in place in 2012 with this commit: 2f0157f1 char_dev: pin parent kobject and the first instance of the fix was then done in the input subsystem in the following commit: 4a215aad Input: fix use-after-free introduced with dynamic minor changes Subsequently over the years, however, this issue seems to have tripped up multiple developers independently. For example, see these commits: 0d5b7dae iio: Prevent race between IIO chardev opening and IIO device (by Lars-Peter Clausen in 2013) ba0ef854 tpm: Fix initialization of the cdev (by Jason Gunthorpe in 2015) 5b28dde5 [media] media: fix use-after-free in cdev_put() when app exits after driver unbind (by Shauh Khan in 2016) This technique is similarly done in at least 15 places within the kernel and probably should have been done so in another, at least, 5 places. The kobj line also looks very suspect in that one would not expect drivers to have to mess with kobject internals in this way. Even highly experienced kernel developers can be surprised by this code, as seen in [2]. To help alleviate this situation, and hopefully prevent future wasted effort on this problem, this patch introduces a helper function to register a char device along with its parent struct device. This creates a more regular API for tying a char device to its parent without the developer having to set members in the underlying kobject. This patch introduce cdev_device_add and cdev_device_del which replaces a common pattern including setting the kobj parent, calling cdev_add and then calling device_add. It also introduces cdev_set_parent for the few cases that set the kobject parent without using device_add. [1] https://lkml.org/lkml/2017/2/13/700 [2] https://lkml.org/lkml/2017/2/10/370Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
- 17 Mar, 2017 31 commits
-
-
Geert Uytterhoeven authored
The Hitachi HD44780 Character LCD Controller is commonly used on character LCDs that can display one or more lines of text. This driver supports character LCDs connected to GPIOs, using either a 4-bit or 8-bit data bus, and provides access through the charlcd core and /dev/lcd. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
Add DT bindings for an Hitachi HD44780 Character LCD Controller where its M6800 bus interface is connected to GPIOs. Memory-mapped configurations are not yet supported. Signed-off-by:
-
Geert Uytterhoeven authored
On displays with more than two lines, the additional lines are stored in the buffers used for the first two lines, but beyond the visible parts. Adjust the DDRAM address calculation to cater for this. When clearing the display, avoid writing more spaces than the actual size of the physical buffer. Signed-off-by:
-
Geert Uytterhoeven authored
In 4-bit mode, 8-bit commands and data are written using two raw writes to the data interface: high nibble first, low nibble last. This must be handled by the low-level driver. However, as we don't know in which mode (4-bit or 8-bit) nor 4-bit phase the LCD was left, initialization must always be handled using raw writes, and needs to configure the LCD for 8-bit mode first. Signed-off-by:
-
Geert Uytterhoeven authored
Extract the character LCD core from the Parallel port LCD/Keypad Panel driver in the misc subsystem, and convert it into a subdriver in the auxdisplay subsystem. This allows the character LCD core to be used by other drivers later. Compilation is controlled by its own Kconfig symbol CHARLCD, which is to be selected by its users, but can be enabled manually for compile-testing. All functions changed their prefix from "lcd_" to "charlcd_", and gained a "struct charlcd *" parameter to operate on a specific instance. While the driver API thus is ready to support multiple instances, the current limitation of a single display (/dev/lcd has a single misc minor assigned) is retained. No functional changes intended. Signed-off-by:
-
Joe Perches authored
To enable eventual removal of pr_warning This makes pr_warn use consistent for drivers/char Prior to this patch, there were 1 use of pr_warning and 40 uses of pr_warn in drivers/char Signed-off-by:
Joe Perches <joe@perches.com> Reviewed-by:
Amit Shah <amit@kernel.org> Signed-off-by:
-
Mariusz Bialonczyk authored
Signed-off-by:
Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by:
-
Mariusz Bialonczyk authored
Signed-off-by:
-
Mariusz Bialonczyk authored
Detailed information about support and provided sysfs files in my next commit which creates a documentation file: Documentation/w1/slaves/w1_ds2438 Signed-off-by:
-
Mariusz Bialonczyk authored
Signed-off-by:
-
Matt Ranostay authored
Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes so this patchset works around the issue and corrects the data returned in pps_fdata_compat. Acked-by:
Rodolfo Giometti <giometti@enneenne.com> Signed-off-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
-
Matt Ranostay authored
ioctl definitions use the pointer size of the architecture which is fine when userspace and kernel are the same bitsize. This patchset workarounds an issue with mixed bitsize kernel + userspace by rewriting the cmd to the kernelspace architecture pointer size. Acked-by:
-
Martyn Welch authored
Update VME documentation given that kerneldoc comments are now provided. Add "VME API" section to VME RST to pull in kerneldoc comments. Signed-off-by:
Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by:
-
Martyn Welch authored
Add kernel-doc comments to the VME driver API and structures. This documentation will be integrated into the RST documentation in a later patch. Signed-off-by:
-
Matthias Kaehlcke authored
The value passed by the two callers of the function is unsigned anyway. Making the parameter unsigned fixes the following warning when building with clang: drivers/char/hpet.c:588:7: error: overflow converting case value to switch condition type (2149083139 to 18446744071563667459) [-Werror,-Wswitch] case HPET_INFO: ^ include/uapi/linux/hpet.h:18:19: note: expanded from macro 'HPET_INFO' ^ include/uapi/asm-generic/ioctl.h:77:28: note: expanded from macro '_IOR' ^ include/uapi/asm-generic/ioctl.h:66:2: note: expanded from macro '_IOC' (((dir) << _IOC_DIRSHIFT) | \ Signed-off-by:Matthias Kaehlcke <mka@chromium.org> Acked-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Cyril Bur authored
In order to manage server systems, there is typically another processor known as a BMC (Baseboard Management Controller) which is responsible for powering the server and other various elements, sometimes fans, often the system flash. The Aspeed BMC family which is what is used on OpenPOWER machines and a number of x86 as well is typically connected to the host via an LPC (Low Pin Count) bus (among others). The LPC bus is an ISA bus on steroids. It's generally used by the BMC chip to provide the host with access to the system flash (via MEM/FW cycles) that contains the BIOS or other host firmware along with a number of SuperIO-style IOs (via IO space) such as UARTs, IPMI controllers. On the BMC chip side, this is all configured via a bunch of registers whose content is related to a given policy of what devices are exposed at a per system level, which is system/vendor specific, so we don't want to bolt that into the BMC kernel. This started with a need to provide something nicer than /dev/mem for user space to configure these things. One important aspect of the configuration is how the MEM/FW space is exposed to the host (ie, the x86 or POWER). Some registers in that bridge can define a window remapping all or portion of the LPC MEM/FW space to a portion of the BMC internal bus, with no specific limits imposed in HW. I think it makes sense to ensure that this window is configured by a kernel driver that can apply some serious sanity checks on what it is configured to map. In practice, user space wants to control this by flipping the mapping between essentially two types of portions of the BMC address space: - The flash space. This is a region of the BMC MMIO space that more/less directly maps the system flash (at least for reads, writes are somewhat more complicated). - One (or more) reserved area(s) of the BMC physical memory. The latter is needed for a number of things, such as avoiding letting the host manipulate the innards of the BMC flash controller via some evil backdoor, we want to do flash updates by routing the window to a portion of memory (under control of a mailbox protocol via some separate set of registers) which the host can use to write new data in bulk and then request the BMC to flash it. There are other uses, such as allowing the host to boot from an in-memory flash image rather than the one in flash (very handy for continuous integration and test, the BMC can just download new images). It is important to note that due to the way the Aspeed chip lets the kernel configure the mapping between host LPC addresses and BMC ram addresses the offset within the window must be a multiple of size. Not doing so will fragment the accessible space rather than simply moving 'zero' upwards. This is caused by the nature of HICR8 being a mask and the way host LPC addresses are translated. Signed-off-by:
Cyril Bur <cyrilbur@gmail.com> Reviewed-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Dmitry Torokhov authored
Instead of creating attributes one by one, define attribute_group array and attach it to bus->dev_groups, so that all needed attributes are created automatically when a new device is registered on the bus. Also switch to using standard DEVICE_ATTR_RO() macros. Signed-off-by:
-
Ming Lei authored
This email of 'ming.lei@canonical.com' isn't valid any more, please remove the entry. Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
Instead of creating switch-specific attributes by hand, implement is_visible() method of attribute group and hide them when dealing with non-switch devices. This will ensure that all attributes are created together, before userspace gets notified of new device. Also, remove rio-sysfs.c from list of files that are scanned when compiling RapiodIO documentations as it no longer has any structured comments, and leaving it in leads to warning when building docs. Signed-off-by:
-
Rob Herring authored
As AOSP master is now starting to require a hwbinder device, add it to the the default Kconfig. Having the hwbinder device when not needed shouldn't hurt anything either. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Martijn Coenen <maco@google.com> Cc: Arve Hjønnevåg <arve@android.com> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Serban Constantinescu <serban.constantinescu@arm.com> Cc: Dmitry Shmidt <dimitrysh@google.com> Cc: Rom Lemarchand <romlem@google.com> Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
K. Y. Srinivasan authored
Don't enable auto-eoi if the hypervisor recommends otherwise. This will enable vAPIC functionality if available. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
Fix a typo in the macro. Signed-off-by:
-
Stephen Hemminger authored
Allow driver to get debug information about state of the ring. Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
Stephen Hemminger authored
Minor changes to align hyper-v vmbus include files with current linux kernel style. Signed-off-by:
-
Stephen Hemminger authored
This table is immutable and should be const. Cleanup indentation and whitespace for this as well. Signed-off-by:
-
Stephen Hemminger authored
hv_ringbuffer_read cleanup. Signed-off-by:
-
Stephen Hemminger authored
Several spelling errors in comments Signed-off-by:
-
Stephen Hemminger authored
Don't initialize variables that are then set a few lines later. Signed-off-by:
-
Stephen Hemminger authored
No need for empty return at end of void function Signed-off-by:
-
Stephen Hemminger authored
Compiling with warnings enabled finds missing prototype for hv_do_hypercall. Signed-off-by:
-
Stephen Hemminger authored
The change to reschedule tasklet if more data arrives in ring buffer can cause performance regression if host timing is such that the next response happens in small window. Go back to a modified version of the original looping behavior. If the race occurs in a small time, then loop. But if the tasklet has been running for a long interval due to flood, then reschedule the tasklet to allow migration to ksoftirqd. Signed-off-by:
-
