- 03 Jun, 2017 18 commits
-
-
Peter Rosin authored
Extend the inkern api with functions for reading and writing ext_info of iio channels. Acked-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Rosin authored
The driver builds a single multiplexer controller using a number of gpio pins. For N pins, there will be 2^N possible multiplexer states. The GPIO pins can be connected (by the hardware) to several multiplexers, which in that case will be operated in parallel. Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Peter Rosin authored
Add a new minimalistic subsystem that handles multiplexer controllers. When multiplexers are used in various places in the kernel, and the same multiplexer controller can be used for several independent things, there should be one place to implement support for said multiplexer controller. A single multiplexer controller can also be used to control several parallel multiplexers, that are in turn used by different subsystems in the kernel, leading to a need to coordinate multiplexer accesses. The multiplexer subsystem handles this coordination. Thanks go out to Lars-Peter Clausen, Jonathan Cameron, Rob Herring, Wolfram Sang, Paul Gortmaker, Dan Carpenter, Colin Ian King, Greg Kroah-Hartman and last but certainly not least to Philipp Zabel for helpful comments, reviews, patches and general encouragement! Reviewed-by:
-
Peter Rosin authored
Allow specifying that a single multiplexer controller can be used to control several parallel multiplexers, thus enabling sharing of the multiplexer controller by different consumers. Add a binding for a first mux controller in the form of a GPIO based mux controller. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Rosin authored
Everything else is indented with two spaces, so fix the odd one out. Acked-by:
-
Robert Lippert authored
This driver enables the LPC snoop hardware on the ASPEED BMC which generates an interrupt upon every write to an I/O port by the host. This is typically used to monitor BIOS boot progress by listening to well-known debug port 80h. The functionality in this commit just saves all snooped values to a circular 2K buffer in the kernel, subsequent commits can act on the values to do things with them. Signed-off-by:
Robert Lippert <rlippert@google.com> Signed-off-by:
-
Arvind Yadav authored
clk_prepare_enable() can fail here and we must check its return value. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Kiran Gunda authored
Currently the SPMI interrupt will not wake the device. Enable this interrupt as a wakeup source. Signed-off-by:
Nicholas Troast <ntroast@codeaurora.org> Signed-off-by:
Kiran Gunda <kgunda@codeaurora.org> Signed-off-by:
-
Abhijeet Dharmapurikar authored
PMIC bus arbiter v3 supports 512 SPMI peripherals. Add the v3 operators to support this new arbiter version. Signed-off-by:
Abhijeet Dharmapurikar <adharmap@codeaurora.org> Signed-off-by:
-
Abhijeet Dharmapurikar authored
The driver currently invokes the apid handler (periph_handler()) once it sees that the summary status bit for that apid is set. However the hardware is designed to set that bit even if the apid interrupts are disabled. The driver should check whether the apid is indeed enabled before calling the apid handler. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The current code uses handle_level_irq flow handler even if the trigger type of the interrupt is edge. This can lead to missing of an edge transition that happens when the interrupt is being handled. The level flow handler masks the interrupt while it is being handled, so if an edge transition happens at that time, that edge is lost. Use an edge flow handler for edge type interrupts which ensures that the interrupt stays enabled while being handled - at least until it triggers at which point the flow handler sets the IRQF_PENDING flag and only then masks the interrupt. That IRQF_PENDING state indicates an edge transition happened while the interrupt was being handled and the handler is called again. Signed-off-by:
-
Abhijeet Dharmapurikar authored
PMIC interrupts each have an internal latched status bit which is not visible from any register. This status bit is set as soon as the conditions specified in the interrupt type and polarity registers are met even if the interrupt is not enabled. When it is set, nothing else changes within the PMIC and no interrupt notification packets are sent. If the internal latched status bit is set when an interrupt is enabled, then the value is immediately propagated into the interrupt latched status register and an interrupt notification packet is sent out from the PMIC over SPMI. This PMIC hardware behavior can lead to a situation where the handler for a level triggered interrupt is called immediately after enable_irq() is called even though the interrupt physically triggered while it was disabled within the genirq framework. This situation takes place if the the interrupt fires twice after calling disable_irq(). The first time it fires, the level flow handler will mask and disregard it. Unfortunately, the second time it fires, the internal latched status bit is set within the PMIC and no further notification is received. When enable_irq() is called later, the interrupt is unmasked (enabled in the PMIC) which results in the PMIC immediately sending an interrupt notification packet out over SPMI. This breaks the semantics of level triggered interrupts within the genirq framework since they should be completely ignored while disabled. The PMIC internal latched status behavior also affects how interrupts are treated during suspend. While entering suspend, all interrupts not specified as wakeup mode are masked. Upon resume, these interrupts are unmasked. Thus if any of the non-wakeup PMIC interrupts fired while the system was suspended, then the PMIC will send interrupt notification packets out via SPMI as soon as they are unmasked during resume. This behavior violates genirq semantics as well since non-wakeup interrupts should be completely ignored during suspend. Modify the qpnpint_irq_unmask() function so that the interrupt latched status clear register is written immediately before the interrupt enable register. This clears the internal latched status bit of the interrupt so that it cannot trigger spuriously immediately upon being enabled. Also, while resuming an irq, an unmask could be called even if it was not previously masked. So, before writing these registers, check if the interrupt is already enabled within the PMIC. If it is, then no further register writes are required. This condition check ensures that a valid latched status register bit is not cleared until it is properly handled. Signed-off-by:
-
Abhijeet Dharmapurikar authored
irq_enable is called when the device resumes. Note that the irq_enable is called regardless of whether the interrupt was marked enabled/disabled in the descriptor or whether it was masked/unmasked at the controller while resuming. The current driver unconditionally clears the interrupt in its irq_enable callback. This is dangerous as any interrupts that happen right before the resume could be missed. Remove the irq_enable callback and use mask/unmask instead. Also remove struct pmic_arb_irq_spec as it serves no real purpose. It is used only in the translate function and the code is much cleaner without it. Signed-off-by:
-
Abhijeet Dharmapurikar authored
We see a unmapped irqs trigger right around bootup. This could likely be because the bootloader exited leaving the interrupts in an unknown or unhandled state. Ack and mask the interrupt if one is found. A request_irq later will unmask it and also setup proper mapping structures. Also the current driver ensures that no read/write transaction is in progress while it makes changes to the interrupt regions. This is not necessary because read/writes over spmi and arbiter interrupt control are independent operations. Hence, remove the synchronized accesses to interrupt region. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The current driver uses a mix of radix tree and a fwd lookup table to translate between apid and ppid. It is buggy and confusing. Instead simply use a radix tree for v1 hardware and use the forward lookup table for v2. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The driver currently uses "apid" and "chan" to mean apid. Remove the use of chan and use only apid. On a SPMI bus there is allocation to manage up to 4K peripherals. However, in practice only few peripherals are instantiated and only few among the instantiated ones actually interrupt. APID is CPU's way of keeping track of peripherals that could interrupt. There is a table that maps the 256 interrupting peripherals to a number between 0 and 255. This number is called APID. Information about that interrupting peripheral is stored in registers offset by its corresponding apid. Signed-off-by:
-
Abhijeet Dharmapurikar authored
Usually *_dev best used for structures that embed a struct device in them. spmi_pmic_arb_dev doesn't embed one. It is simply a driver data structure. Use an appropriate name for it. Also there are many places in the driver that left shift the bit to generate a bit mask. Replace it with the BIT() macro. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The system crashes due to bad access when reading from an non configured peripheral and when writing to peripheral which is not owned by current ee. This patch verifies ownership to avoid crashing on write. For reads, since the forward mapping table, data_channel->ppid, is towards the end of the block, we use the core size to figure the max number of ppids supported. The table starts at an offset of 0x800 within the block, so size - 0x800 will give us the area used by the table. Since each table is 4 bytes long (core_size - 0x800) / 4 will gives us the number of data_channel supported. This new protection is functional on hw v2. Signed-off-by:
-
- 27 May, 2017 1 commit
-
-
Dmitry Torokhov authored
This reverts commit 7975bd4c, because VPD relies on driver core to handle deferrals returned by coreboot_table_find(). Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
- 25 May, 2017 18 commits
-
-
Wolfram Sang authored
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Wolfram Sang authored
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by:
-
Wei Yongjun authored
convert list_for_each() to list_for_each_entry() where applicable. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Colin Ian King authored
Make this static as it's only referenced in this source and it does not need global scope. Cleans up a sparse warning: drivers/platform/goldfish/goldfish_pipe.c: warning: symbol 'pipe_dev' was not declared. Should it be static? Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Tomas Winkler authored
notifcation -> notification Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Alexander Usyskin authored
mei_cl_bus_rescan is used only in bus.c, so make it local to the file and mark static. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
-
Andrew F. Davis authored
Structures and functions should be ordered such that forward declaration use is minimized. MODULE_* macros should immediately follow the structures and functions upon which they act. Remaining MODULE_* macros should be at the end of the file in alphabetical order. Signed-off-by:
Andrew F. Davis <afd@ti.com> Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Michael Kelley authored
Extend the disabling of preemption to include the hypercall so that another thread can't get the CPU and corrupt the per-cpu page used for hypercall arguments. Cc: <Stable@vger.kernel.org> #4.11 Signed-off-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of open coded variant use generic helper to convert UUID strings to binary format. Signed-off-by:
-
K. Y. Srinivasan authored
Commit c0bb0392 ("Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()") increased the retry/wait limits of vmbus_post_msg() to address the new DoS protection policies in WS2016. Increase the time between retries to make the code more robust. Signed-off-by:
-
Vitaly Kuznetsov authored
It was found that ICTIMESYNCFLAG_SYNC packets are handled incorrectly on WS2012R2, e.g. after the guest is paused and resumed its time is set to something different from host's time. The problem is that we call adj_guesttime() with reftime=0 for these old hosts and we don't account for that in 'if (adj_flags & ICTIMESYNCFLAG_SYNC)' branch and hv_set_host_time(). While we could've solved this by adding a check like 'if (ts_srv_version > TS_VERSION_3)' to hv_set_host_time() I prefer to do some refactoring. We don't need to have two separate containers for host samples, struct host_ts which we use for PTP is enough. Throw away 'struct adj_time_work' and create hv_get_adj_host_time() accessor to host_ts to avoid code duplication. Fixes: 3716a49a ("hv_utils: implement Hyper-V PTP source") Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Turns out that our implementation of .getcrosststamp() never actually worked. Hyper-V is sending time samples every 5 seconds and this is too much for get_device_system_crosststamp() as it's interpolation algorithm (which nobody is currently using in kernel, btw) accounts for a 'slow' device but we're not slow in Hyper-V, our time reference is too far away. .getcrosststamp() is not currently used, get_device_system_crosststamp() almost always returns -EINVAL and client falls back to using PTP_SYS_OFFSET so this patch doesn't change much. I also tried doing interpolation manually (e.g. the same way hv_ptp_gettime() works and it turns out that we're getting even lower quality: PTP_SYS_OFFSET_PRECISE with manual interpolation: * PHC0 0 3 37 4 -3974ns[-5338ns] +/- 977ns * PHC0 0 3 77 7 +2227ns[+3184ns] +/- 576ns * PHC0 0 3 177 10 +3060ns[+5220ns] +/- 548ns * PHC0 0 3 377 12 +3937ns[+4371ns] +/- 1414ns * PHC0 0 3 377 6 +764ns[+1240ns] +/- 1047ns * PHC0 0 3 377 7 -1210ns[-3731ns] +/- 479ns * PHC0 0 3 377 9 +153ns[-1019ns] +/- 406ns * PHC0 0 3 377 12 -872ns[-1793ns] +/- 443ns * PHC0 0 3 377 5 +701ns[+3599ns] +/- 426ns * PHC0 0 3 377 5 -923ns[ -375ns] +/- 1062ns PTP_SYS_OFFSET: * PHC0 0 3 7 5 +72ns[+8020ns] +/- 251ns * PHC0 0 3 17 5 -885ns[-3661ns] +/- 254ns * PHC0 0 3 37 6 -454ns[-5732ns] +/- 258ns * PHC0 0 3 77 10 +1183ns[+3754ns] +/- 164ns * PHC0 0 3 377 5 +579ns[+1137ns] +/- 110ns * PHC0 0 3 377 7 +501ns[+1064ns] +/- 96ns * PHC0 0 3 377 9 +1641ns[+3342ns] +/- 106ns * PHC0 0 3 377 8 -47ns[ +77ns] +/- 160ns * PHC0 0 3 377 5 +54ns[ +107ns] +/- 102ns * PHC0 0 3 377 8 -354ns[ -617ns] +/- 89ns This fact wasn't noticed during the initial testing of the PTP device somehow but got revealed now. Let's just drop .getcrosststamp() implementation for now as it doesn't seem to be suitable for us. Signed-off-by:
-
K. Y. Srinivasan authored
The current code uses the MSR based mechanism to get the current tick. Use the current clock source as that might be more optimal. Signed-off-by:
-
Dmitry Torokhov authored
There is no reason why VPD should register platform device and driver, given that we do not use their respective kobjects to attach attributes, nor do we need suspend/resume hooks, or any other features of device core. Signed-off-by:
-
Dmitry Torokhov authored
ro_vpd and rw_vpd are static module-scope variables that are guaranteed to be initialized with zeroes, there is no need for explicit memset(). Signed-off-by:
-
Dmitry Torokhov authored
When creating name for the "raw" attribute, let's switch to using kaspeintf() instead of doing it by hand. Also make sure we handle errors. Signed-off-by:
-
Dmitry Torokhov authored
Instead of open-coding kstrndup with kzalloc + memcpy, let's use the helper. Signed-off-by:
-
Julius Werner authored
The recent coreboot memory console update (firmware: google: memconsole: Adapt to new coreboot ring buffer format) introduced a small security issue in the driver: The new driver implementation parses the memory console structure again on every access. This is intentional so that additional lines added concurrently by runtime firmware can be read out. However, if an attacker can write to the structure, they could increase the size value to a point where the driver would read potentially sensitive memory areas from outside the original console buffer during the next access. This can be done through /dev/mem, since the console buffer usually resides in firmware-reserved memory that is not covered by STRICT_DEVMEM. This patch resolves that problem by reading the buffer's size value only once during boot (where we can still trust the structure). Other parts of the structure can still be modified at runtime, but the driver's bounds checks make sure that it will never read outside the buffer. Fixes: a5061d02 ("firmware: google: memconsole: Adapt to new coreboot ring buffer format") Signed-off-by:
Julius Werner <jwerner@chromium.org> Signed-off-by:
-
- 22 May, 2017 3 commits
-
-
Greg Kroah-Hartman authored
We want the fixes in here as well to handle merge issues. Signed-off-by: -
Linus Torvalds authored
-
Linus Torvalds authored
The code to fetch a 64-bit value from user space was entirely buggered, and has been since the code was merged in early 2016 in commit b2f68038 ("x86/mm/32: Add support for 64-bit __get_user() on 32-bit kernels"). Happily the buggered routine is almost certainly entirely unused, since the normal way to access user space memory is just with the non-inlined "get_user()", and the inlined version didn't even historically exist. The normal "get_user()" case is handled by external hand-written asm in arch/x86/lib/getuser.S that doesn't have either of these issues. There were two independent bugs in __get_user_asm_u64(): - it still did the STAC/CLAC user space access marking, even though that is now done by the wrapper macros, see commit 11f1a4b9 ("x86: reorganize SMAP handling in user space accesses"). This didn't result in a semantic error, it just means that the inlined optimized version was hugely less efficient than the allegedly slower standard version, since the CLAC/STAC overhead is quite high on modern Intel CPU's. - the double register %eax/%edx was marked as an output, but the %eax part of it was touched early in the asm, and could thus clobber other inputs to the asm that gcc didn't expect it to touch. In particular, that meant that the generated code could look like this: mov (%eax),%eax mov 0x4(%eax),%edx where the load of %edx obviously was _supposed_ to be from the 32-bit word that followed the source of %eax, but because %eax was overwritten by the first instruction, the source of %edx was basically random garbage. The fixes are trivial: remove the extraneous STAC/CLAC entries, and mark the 64-bit output as early-clobber to let gcc know that no inputs should alias with the output register. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: stable@kernel.org # v4.8+ Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
