- 26 Apr, 2017 1 commit
-
-
Tomas Winkler authored
The TODO file is not relevant anymore and it's just a leftover from the time the driver was in the staging tree. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 Apr, 2017 3 commits
-
-
Wei-Ning Huang authored
This patch introduces the Google Vital Product Data driver. This driver reads Vital Product Data from coreboot tables and then creates the corresponding sysfs entries under /sys/firmware/vpd to provide easy access for userspace programs (does not require flashrom). The sysfs is structured as follow: /sys/firmware/vpd |-- ro | |-- key1 | `-- key2 |-- ro_raw |-- rw | `-- key1 `-- rw_raw Where ro_raw and rw_raw contain the raw VPD partition. The files under ro and rw correspond to the key name in the VPD and the the file content is the value for the key. Signed-off-by: Wei-Ning Huang <wnhuang@google.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wei-Ning Huang authored
This patch imports lib_vpd.h and vpd_decode.c from the Chromium Vital Product Data project. This library is used to parse VPD sections obtained from coreboot table entries describing Chromebook devices product data. Only the sections of type VPD_TYPE_STRING are decoded. The VPD string sections in the coreboot tables contain the type (1 byte set to 0x01 for strings), the key length, the key ascii array, the value length, and the value ascii array. The key and value arrays are not null terminated. Signed-off-by: Wei-Ning Huang <wnhuang@google.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Davidson authored
Add a volatile qualifier where a NULL pointer is deliberately dereferenced to trigger a panic. Without the volatile qualifier clang will issue the following warning: "indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference]" and replace the pointer reference with a __builtin_trap() (which generates a ud2 instruction on x86_64). Signed-off-by: Michael Davidson <md@google.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 Apr, 2017 1 commit
-
-
Greg Kroah-Hartman authored
Merge tag 'extcon-next-for-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Update extcon for 4.12 Detailed description for this pull request: 1. Add new 'extcon-intel-cht-wc.c' driver - Intel Cherrytrail Whiskey Cove PMIC extcon driver supports the detection of the charger connectors and the control. 2. Add new extcon API to monitor the all external connectors. - The extcon consumer might need to monitor the all supported external connectors from the extcon device. Before, the extcon consumer should have each notifier_block structure for each external connector. In order to support the requirement, the extcon adds new extcon_register_notifier_all() API. The extcon consumer is able to monitor the state change of all supported external connectors from the extcon device by using only one notifier_block. - extcon_(register|unregister)_notifier_all(struct extcon_dev *edev struct notifier_block *nb) - devm_extcon_(register|unregister)_notifier_all(struct device *dev, struct extcon_dev *edev struct notifier_block *nb) 3. Remove porting compatibility of old switch class - The extcon removes the porting compatibility of old switch class because there are no any use-case and requirement of switch class. 4. Update the extcon drivers and Fix the minor issues - Revert the ACPI gpio interface on the extcon-usb-gpioc.c. - Fix the issues related to the suspend-to-ram for both extcon-usb-gpio.c and extcon-palmas.c. - Add warning message for extcon-arizona.c when headphone detection is not finished.
-
- 08 Apr, 2017 35 commits
-
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andrew F. Davis authored
The only use of assert() is in matrox_w1.c and is used to check the input to probe() from the PCI subsystem for NULL values, these are guaranteed to be populated and no other PCI driver makes this check, remove this. As this was the only definition in w1_log.h, remove this also. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andrew F. Davis authored
Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michal Sojka authored
mf624 card has its registers not aligned to pages. Since commit b6550287 ("uio: we cannot mmap unaligned page contents") mmap()ing mf624 registers fails, because now the uio drivers must set uio_mem->addr to be page-aligned. We align the address here and set the newly introduced offs field to the offset of the mf264 registers within the page so that userspace can find the address of the mmap()ed register by reading /sys/class/uio/uio?/maps/map?/offset. Tested with real mf624 card. Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michal Sojka authored
No functional changes. Move initialization of struct uio_mem to a function. This will allow the next commit to change the initialization code at a single place rather that at three different places. Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michal Sojka authored
Since commit b6550287 ("uio: we cannot mmap unaligned page contents") addresses and sizes of UIO memory regions must be page-aligned. If the address in the BAR register is not page-aligned (which is the case of the mf264 card), the mentioned commit forces the UIO driver to round the address down to the page size. Then, there is no easy way for user-space to learn the offset of the actual memory region within the page, because the offset seen in /sys/class/uio/uio?/maps/map?/offset is calculated from the rounded address and thus it is always zero. Fix that problem by including the offset in struct uio_mem. UIO drivers can set this field and userspace can read its value from /sys/class/uio/uio?/maps/map?/offset. The following commits update the uio_mf264 driver to set this new offs field. Drivers for hardware with page-aligned BARs need not to be modified provided that they initialize struct uio_info (which contains uio_mem) with zeros. Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Shile Zhang authored
Fix the typo "alloted" -> "allotted" in comment. Signed-off-by: Shile Zhang <shile.zhang@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
K. Y. Srinivasan authored
When auto EOI is not enabled; issue an explicit EOI for hyper-v interrupts. Fixes: 6c248aad ("Drivers: hv: Base autoeoi enablement based on hypervisor hints") Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thierry Escande authored
This patch expands the Google firmware memory console driver to also work on certain tree based platforms running coreboot, such as ARM/ARM64 Chromebooks. This patch now adds another path to find the coreboot table through the device tree. In order to find that, a second level bootloader must have installed the 'coreboot' compatible device tree node that describes its base address and size. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Wei-Ning Huang <wnhuang@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Julius Werner authored
This patch adds documentation describing a device tree binding for the coreboot firmware. It is meant to be dynamically added during boot and contains address definitions for the coreboot table (a list of variable-sized descriptors providing information about various compile- and run-time generated firmware parameters) and the CBMEM area (the structure containing most run-time resident memory regions set up by coreboot). These definitions allow kernel drivers to easily access data contained in and pointed to by these regions (such as coreboot's in-memory log). (An example implementation can be seen in the following patch) Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thierry Escande authored
Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thierry Escande authored
This patch splits memconsole.c in 2 parts. One containing the architecture-independent part and the other one containing the EBDA specific part. This prepares the integration of coreboot support for the memconsole. The memconsole driver is now named as memconsole-x86-legacy. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thierry Escande authored
This patch removes the "Google Firmware Drivers" menu containing a menuconfig entry with the exact same name. The menuconfig is now directly under the "Firmware Drivers" entry. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saul Wold authored
Most Linux distributions contain awk in /usr/bin by default, not in /bin. This script's suggested use is for creating version information for bug reporting. This has been tested on a number of different distributions, including Fedora, Ubuntu, OpenSUSE, Debian, Centos, Arch Linuxi, and Poky! Signed-off-by: Saul Wold <sgw@linux.intel.com> Reviewed-by: Alexander Kapshuk <alexander.kapshuk@gmail.com> Reviewed-by: Mark Gross <mgross@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
I ran into a link error on ARM64 for lkdtm_rodata_do_nothing: drivers/misc/built-in.o: In function `lkdtm_rodata_do_nothing': :(.rodata+0x68c8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `__sanitizer_cov_trace_pc' defined in .text section in kernel/built-in.o I did not analyze this further, but my theory is that we would need a trampoline to call __sanitizer_cov_trace_pc(), but the linker (correctly) only adds trampolines for callers in executable sections. Disabling KCOV for this one file avoids the build failure with no other practical downsides I can think of. The problem can only happen on kernels that contain both kcov and lkdtm, so if we want to backport this, it should be in the earliest version that has both (v4.8). Fixes: 5c9a8750 ("kernel: add kcov code coverage") Fixes: 9a49a528 ("lkdtm: add function for testing .rodata section") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Dmitry Vyukov <dvyukov@google.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kees Cook authored
This adds CORRUPT_USER_DS to check that the get_fs() test on syscall return (via __VERIFY_PRE_USERMODE_STATE) still sees USER_DS. Since trying to deal with values other than USER_DS and KERNEL_DS across all architectures in a safe way is not sensible, this sets KERNEL_DS, but since that could be extremely dangerous if the protection is not present, it also raises SIGKILL for current, so that no matter what, the process will die. A successful test will be visible with a BUG(), like all the other LKDTM tests. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Varsha Rao authored
Replace printk with pr_err to fix the checkpatch issue. Signed-off-by: Varsha Rao <rvarsha016@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Varsha Rao authored
Add a blank line after declaration, to fix the checkpatch issue. Signed-off-by: Varsha Rao <rvarsha016@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Varsha Rao authored
Add space which is required after ',' to follow linux coding style. This patch fixes the checkpatch issue. Signed-off-by: Varsha Rao <rvarsha016@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Varsha Rao authored
Remove space after * in pointer type, to follow linux coding style. This patch fixes the following checkpatch issue: ERROR: "foo * bar" should be "foo *bar" Signed-off-by: Varsha Rao <rvarsha016@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Richard Leitner authored
Implement write routine for OCOTP controller found in i.MX6 SoC's. Furthermore add locking to the read function to prevent race conditions. The write routine code is based on the fsl_otp driver from Freescale. Signed-off-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Richard Leitner authored
When reading a "read locked" value from the OCOTP controller on i.MX6 SoC's an error bit is set. This bit has to be cleared by software before any new write, read or reload access can be issued. Therefore clear it after we detect such an "locked read". Signed-off-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peng Fan authored
Add i.MX7D support. There is 16 banks, each bank 4 words. Signed-off-by: Peng Fan <peng.fan@nxp.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peng Fan authored
Add compatible string for i.MX7D/S Signed-off-by: Peng Fan <peng.fan@nxp.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sascha Hauer authored
The IIM is part of the i.MX device trees for long already, add a binding document for it. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Grzeschik authored
This adds a readonly nvmem driver for the i.MX IC Identification Module (IIM). The IIM is found on the older i.MX SoCs like the i.MX25, i.MX27, i.MX31, i.MX35, i.MX51 and the i.MX53. The IIM can control up to 8 fuse banks with 256 bit each. Not all of the banks are equipped on the different SoCs. The actual number of fuses differ from 512 on the i.MX27 and 1152 on the i.MX53. The fuses are one time writable, but writing is currently not supported in the driver. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Richard Leitner authored
Assign the correct dev pointer to struct ocotp_priv during probe. This is needed to display dev_* messages correctly. Furthermore harmonize the usage of dev (instead of &pdev->dev) in the probe function. Signed-off-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Icenowy Zheng authored
The H3 SoC have a bigger SID controller, which has its direct read address at 0x200 position in the SID block, not 0x0. Also, H3 SID controller has some silicon bug that makes the direct read value wrong at cold boot, add code to workaround the bug. (This bug has already been fixed on A64 and later SoCs) Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Icenowy Zheng authored
Sometimes the SID device have more memory address space than the real NVMEM size (for the registers used to read/write the SID). Fetch the NVMEM size from device compatible, rather than the memory address space's length, in order to prepare for adding some registers-based read support. Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Aban Bedel authored
Currently the nvmem core expect the config to provide a name and ID that are then used to create the device name. When no device name is given 'nvmem' is used. However if there is several such anonymous devices they all get named 'nvmem0', which doesn't work. To fix this problem use the ID from the config only when the config also provides a name. When no name is provided take the uinque ID of the nvmem device instead. Signed-off-by: Aban Bedel <albeu@free.fr> Reviewed-by: Moritz Fischer <mdf@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Maxime Ripard authored
I've never been really been maintaining nvmem, so make that official. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Moritz Fischer authored
This adds support for the Xilinx LogiCORE PR Decoupler soft-ip that does decoupling of PR regions in the FPGA fabric during partial reconfiguration. Signed-off-by: Moritz Fischer <mdf@kernel.org> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com> Cc: linux-kernel@vger.kernel.org Cc: devicetree@vger.kernel.org Acked-by: Alan Tull <atull@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andy Shevchenko authored
It looks like arm-charlcd.c belongs to auxdisplay subsystem. Move it to drivers/auxdisplay folder. No functional changes intended. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-