Extend the inkern api with functions for reading and writing ext_info
of iio channels.
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NJonathan Cameron <jic23@kernel.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Everything else is indented with two spaces, so fix the odd one out.
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NRobert Lippert <rlippert@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the SPMI interrupt will not wake the device. Enable this
interrupt as a wakeup source.
Signed-off-by: NNicholas Troast <ntroast@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

PMIC bus arbiter v3 supports 512 SPMI peripherals. Add the v3 operators to
support this new arbiter version.
Signed-off-by: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 7975bd4c, because
VPD relies on driver core to handle deferrals returned by
coreboot_table_find().
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

convert list_for_each() to list_for_each_entry() where
applicable.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

notifcation -> notification
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

mei_cl_bus_rescan is used only in bus.c,
so make it local to the file and mark static.
Signed-off-by: NAlexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAndrew F. Davis <afd@ti.com>
Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of open coded variant use generic helper to convert UUID strings
to binary format.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of open-coding kstrndup with kzalloc + memcpy, let's use
the helper.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NJulius Werner <jwerner@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We want the fixes in here as well to handle merge issues.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NLinus Torvalds <torvalds@linux-foundation.org>