When the connections are defined in firmware, struct
device_connection will have the fwnode member pointing to
the device node (struct fwnode_handle) of the requested
device, and the endpoint will not be used at all in that
case.
Bug: 150877929
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I9e109b61a63ed005d419ee59c5fbad48903835b3
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 96a6d031ca)
When the connections are defined in firmware, struct
device_connection will have the fwnode member pointing to
the device node (struct fwnode_handle) of the requested
device, and the endpoint will not be used at all in that
case.
Bug: 150877929
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ie6e233c158bae77cf1f332c45957248e4521c7f8
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 6a0bbcf96b)
Since with accessory modes there is no need for additional
identification when requesting a handle to the mux, we can
replace the second parameter that is passed to the
typec_mux_get() function with a pointer to alternate mode
description structure, and simply passing NULL with
accessory modes.
This change means the naming of the mux device connections
can be updated. Alternate and Accessory Modes will both be
handled with muxes named "mode-switch", and the orientation
switches will be named "orientation-switch".
Future identification of the alternate modes will be later
done using device property "svid" of the mux.
Bug: 150877929
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Iafd151d0c0dab6847a35ac222d0d209c77096cd1
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 540bfab7fb)
The usual pattern to allocate the necessary space for an array of properties is
to count them first by calling:
count = device_property_read_uXX_array(dev, propname, NULL, 0);
if (count < 0)
return count;
Introduce helpers device_property_count_uXX() to count items by supplying hard
coded last two parameters to device_property_readXX_array().
Bug: 150877929
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: If7cdedae76d0543997b96b3da3d28f6657472d29
(cherry picked from commit 33ee09cd59)
The new mux connection naming scheme is now in use, so
dropping the connections still using the old names. From now
on the same connection description named "mode-switch" is
used with both the port and the alternate modes, so on CHT
the DP alt mode will use the same connection as the port to
get a handle to the mux device.
Bug: 150877929
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: If11eda46906d48ab4824aca0d949e1cf23067756
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 393cd68d0d)
Because of UCSI, we have to support alt mode enter/exit
reporting even when there is no alt mode driver bind to the
alt mode device. With UCSI a firmware handles the alternate
modes, and the modes are entered automatically from OS PoW.
Changing typec_altmode_update_active() so that the driver
module ref count is incremented/decremented only if there
really is a driver for the alt mode. That avoids a NULL
pointer dereference from happening when the driver is
missing.
Bug: 150877929
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: If8dd297875ff88c2c82bdb1d43eb2c72469e9bf0
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit b0fcdffdd6)
Add API to find the ddr device type from memory node.
Test: build
Bug: 150980314
Change-Id: I1cfc38d46f1ea0abc6fbe8cbb6e37cde72b9fc2e
Signed-off-by: Channagoud Kadabi <ckadabi@codeaurora.org>
(cherry picked from commit 368f22bc0d35888285a523f190ac1f5024168fa4)
[hridya: added an EXPORT_SYMBOL_GPL statement to make the new
symbol avaialable to kernel modules].
Signed-off-by: Hridya Valsaraju <hridya@google.com>
We need to reset input device's timestamp on input_sync(), otherwise
drivers not using input_set_timestamp() will end up with a stale
timestamp after their clients consume first input event.
Bug: 150896413
Fixes: 3b51c44bd6 ("Input: allow drivers specify timestamp for input events")
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit 4370b231d1)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Change-Id: I35b76cbed146a4ee8e021388eb7a68282daf9003
Currently, evdev stamps events with timestamps acquired in evdev_events()
However, this timestamping may not be accurate in terms of measuring
when the actual event happened.
Let's allow individual drivers specify timestamp in order to provide a more
accurate sense of time for the event. It is expected that drivers will set the
timestamp in their hard interrupt routine.
Bug: 150896413
Signed-off-by: Atif Niyaz <atifniyaz@google.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Change-Id: I718209b41958a771c48f6069a597cec469c4074d
(cherry picked from commit 3b51c44bd6)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
dwc_usb31 supports DRD only mode. It does not support
USB OTG mode. SNPS core consultant parameter DWC_USB3_EN_OTG
is not set for dwc_usb31. Hence add USB_DR_MODE_DRD which
reflects support for host and device mode support without
supporting USB OTG features.
Bug: 150901210
Test: make
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Change-Id: If3b683d4d47f0eb846a2ac302aff8848096395b9
(cherry picked from commit d4c4fb2d63ce1f2f7bf07975f71a5a0a4b2f5aec)
[hridya: commit amended to only include the ABI diff]
Signed-off-by: Hridya Valsaraju <hridya@google.com>
This API registers a virtual thermal sensor.
Test: build
Bug: 149945768
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Change-Id: I72b29b4296d9be949d096913471153b596c67e1f
[hridya: commit amended to only pull in the API implementation and code
needed to build it.]
(cherry picked commit from 8a12149c264c7b871932ad90f76e5981452bb4bb)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
In preparation for removal of VLAs due to skcipher requests on the stack
via SKCIPHER_REQUEST_ON_STACK() usage, this introduces the infrastructure
for the "sync skcipher" tfm, which is for handling the on-stack cases of
skcipher, which are always non-ASYNC and have a known limited request
size.
The crypto API additions:
struct crypto_sync_skcipher (wrapper for struct crypto_skcipher)
crypto_alloc_sync_skcipher()
crypto_free_sync_skcipher()
crypto_sync_skcipher_setkey()
crypto_sync_skcipher_get_flags()
crypto_sync_skcipher_set_flags()
crypto_sync_skcipher_clear_flags()
crypto_sync_skcipher_blocksize()
crypto_sync_skcipher_ivsize()
crypto_sync_skcipher_reqtfm()
skcipher_request_set_sync_tfm()
SYNC_SKCIPHER_REQUEST_ON_STACK() (with tfm type check)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 150811495
Test: make
Change-Id: I5d002a7af64509a293cd4d685b97d2cd2c4d10e1
(cherry picked from commit b350bee5ea)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
AP stopped interface can be used to indicate that the AP mode has
stopped functioning, WLAN driver may have encountered errors that has
forced the driver to stop the AP mode.
When the driver is in P2P-Go mode, and when it goes thru automatic
recovery from firmware crashes, it uses this interface to notify the
userspace that the group has been deleted.
CRs-Fixed: 1078172
Bug: 150894598
Test: make
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
Change-Id: Id566b35cd0afdb7277fbd2aef74601bfabc65e42
(cherry picked from commit 44643035d7f5d74edebac551928a7b03fe76f19c)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Patch series "Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()".
Despite having just a single modular in-tree user that I could spot,
kallsyms_lookup_name() is exported to modules and provides a mechanism
for out-of-tree modules to access and invoke arbitrary, non-exported
kernel symbols when kallsyms is enabled.
This patch series fixes up that one user and unexports the symbol along
with kallsyms_on_each_symbol(), since that could also be abused in a
similar manner.
I would like to avoid out-of-tree modules being easily able to call
functions that are not exported. kallsyms_lookup_name() makes this
trivial to the point that there is very little incentive to rework these
modules to either use upstream interfaces correctly or propose
functionality which may be otherwise missing upstream. Both of these
latter solutions would be pre-requisites to upstreaming these modules, and
the current state of things actively discourages that approach.
The background here is that we are aiming for Android devices to be able
to use a generic binary kernel image closely following upstream, with any
vendor extensions coming in as kernel modules. In this case, we (Google)
end up maintaining the binary module ABI within the scope of a single LTS
kernel. Monitoring and managing the ABI surface is not feasible if it
effectively includes all data and functions via kallsyms_lookup_name().
Of course, we could just carry this patch in the Android kernel tree, but
we're aiming to carry as little as possible (ideally nothing) and I think
it's a sensible change in its own right. I'm surprised you object to it,
in all honesty.
Now, you could turn around and say "that's not upstream's problem", but it
still seems highly undesirable to me to have an upstream bypass for
exported symbols that isn't even used by upstream modules. It's ripe for
abuse and encourages people to work outside of the upstream tree. The
usual rule is that we don't export symbols without a user in the tree and
that seems especially relevant in this case.
Joe Lawrence said:
: FWIW, kallsyms was historically used by the out-of-tree kpatch support
: module to resolve external symbols as well as call set_memory_r{w,o}()
: API. All of that support code has been merged upstream, so modern kpatch
: modules* no longer leverage kallsyms by default.
:
: That said, there are still some users who still use the deprecated support
: module with newer kernels, but that is not officially supported by the
: project.
This patch (of 3):
Given the name of a kernel symbol, the 'data_breakpoint' test claims to
"report any write operations on the kernel symbol". However, it creates
the breakpoint using both HW_BREAKPOINT_W and HW_BREAKPOINT_R, which menas
it also fires for read access.
Drop HW_BREAKPOINT_R from the breakpoint attributes.
Bug: 149978696
Change-Id: I12f793136a7187c844841e7dd65b90645d5519f6
Link: http://lkml.kernel.org/r/20200221114404.14641-2-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Quentin Perret <qperret@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 0c1b9251116b972cafa3cf16bd02cb2354535b38
https://github.com/hnaz/linux-mm.git master)
Signed-off-by: Quentin Perret <qperret@google.com>
After FS_IOC_REMOVE_ENCRYPTION_KEY removes a key, it syncs the
filesystem and tries to get and put all inodes that were unlocked by the
key so that unused inodes get evicted via fscrypt_drop_inode().
Normally, the inodes are all clean due to the sync.
However, after the filesystem is sync'ed, userspace can modify and close
one of the files. (Userspace is *supposed* to close the files before
removing the key. But it doesn't always happen, and the kernel can't
assume it.) This causes the inode to be dirtied and have i_count == 0.
Then, fscrypt_drop_inode() failed to consider this case and indicated
that the inode can be dropped, causing the write to be lost.
On f2fs, other problems such as a filesystem freeze could occur due to
the inode being freed while still on f2fs's dirty inode list.
Fix this bug by making fscrypt_drop_inode() only drop clean inodes.
I've written an xfstest which detects this bug on ext4, f2fs, and ubifs.
Fixes: b1c0ec3599 ("fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl")
Cc: <stable@vger.kernel.org> # v5.4+
Link: https://lore.kernel.org/r/20200305084138.653498-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 2b4eae95c7)
Bug: 150589360
Test: kvm-xfstests -c ext4,f2fs -g encrypt
Change-Id: Ia32db980c2fffb68caeaf9f38e5cfbe781b45011
Signed-off-by: Eric Biggers <ebiggers@google.com>
This was "default y" but disabled manually because we set
CONFIG_EXPERT=y. Disabling it does not seem to be a big win and we have
had requests to enable it.
Bug: 150871026
Change-Id: I4a7f8da1e8480dc46f168def89016a5152e421ea
Signed-off-by: Alistair Delva <adelva@google.com>
Changes in 4.19.109
EDAC/amd64: Set grain per DIMM
ALSA: hda/realtek - Fix a regression for mute led on Lenovo Carbon X1
net: dsa: bcm_sf2: Forcibly configure IMP port for 1Gb/sec
RDMA/core: Fix pkey and port assignment in get_new_pps
RDMA/core: Fix use of logical OR in get_new_pps
kprobes: Fix optimize_kprobe()/unoptimize_kprobe() cancellation logic
ALSA: hda: do not override bus codec_mask in link_get()
serial: ar933x_uart: set UART_CS_{RX,TX}_READY_ORIDE
selftests: fix too long argument
usb: gadget: composite: Support more than 500mA MaxPower
usb: gadget: ffs: ffs_aio_cancel(): Save/restore IRQ flags
usb: gadget: serial: fix Tx stall after buffer overflow
drm/msm/mdp5: rate limit pp done timeout warnings
drm: msm: Fix return type of dsi_mgr_connector_mode_valid for kCFI
scsi: megaraid_sas: silence a warning
drm/msm/dsi: save pll state before dsi host is powered off
drm/msm/dsi/pll: call vco set rate explicitly
selftests: forwarding: use proto icmp for {gretap, ip6gretap}_mac testing
net: dsa: b53: Ensure the default VID is untagged
net: ks8851-ml: Remove 8-bit bus accessors
net: ks8851-ml: Fix 16-bit data access
net: ks8851-ml: Fix 16-bit IO operation
watchdog: da9062: do not ping the hw during stop()
s390/cio: cio_ignore_proc_seq_next should increase position index
s390: make 'install' not depend on vmlinux
x86/boot/compressed: Don't declare __force_order in kaslr_64.c
s390/qdio: fill SL with absolute addresses
nvme: Fix uninitialized-variable warning
ice: Don't tell the OS that link is going down
x86/xen: Distribute switch variables for initialization
net: thunderx: workaround BGX TX Underflow issue
ALSA: hda/realtek - Add Headset Mic supported
ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master
cifs: don't leak -EAGAIN for stat() during reconnect
usb: storage: Add quirk for Samsung Fit flash
usb: quirks: add NO_LPM quirk for Logitech Screen Share
usb: dwc3: gadget: Update chain bit correctly when using sg list
usb: core: hub: fix unhandled return by employing a void function
usb: core: hub: do error out if usb_autopm_get_interface() fails
usb: core: port: do error out if usb_autopm_get_interface() fails
vgacon: Fix a UAF in vgacon_invert_region
mm, numa: fix bad pmd by atomically check for pmd_trans_huge when marking page tables prot_numa
mm: fix possible PMD dirty bit lost in set_pmd_migration_entry()
fat: fix uninit-memory access for partial initialized inode
arm: dts: dra76x: Fix mmc3 max-frequency
tty:serial:mvebu-uart:fix a wrong return
serial: 8250_exar: add support for ACCES cards
vt: selection, close sel_buffer race
vt: selection, push console lock down
vt: selection, push sel_lock up
media: v4l2-mem2mem.c: fix broken links
x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes
dmaengine: tegra-apb: Fix use-after-free
dmaengine: tegra-apb: Prevent race conditions of tasklet vs free list
dm cache: fix a crash due to incorrect work item cancelling
dm: report suspended device during destroy
dm writecache: verify watermark during resume
ARM: dts: ls1021a: Restore MDIO compatible to gianfar
spi: bcm63xx-hsspi: Really keep pll clk enabled
ASoC: topology: Fix memleak in soc_tplg_link_elems_load()
ASoC: topology: Fix memleak in soc_tplg_manifest_load()
ASoC: intel: skl: Fix pin debug prints
ASoC: intel: skl: Fix possible buffer overflow in debug outputs
dmaengine: imx-sdma: remove dma_slave_config direction usage and leave sdma_event_enable()
ASoC: pcm: Fix possible buffer overflow in dpcm state sysfs output
ASoC: pcm512x: Fix unbalanced regulator enable call in probe error path
ASoC: dapm: Correct DAPM handling of active widgets during shutdown
drm/sun4i: Fix DE2 VI layer format support
drm/sun4i: de2/de3: Remove unsupported VI layer formats
phy: mapphone-mdm6600: Fix timeouts by adding wake-up handling
phy: mapphone-mdm6600: Fix write timeouts with shorter GPIO toggle interval
ARM: dts: imx6: phycore-som: fix emmc supply
RDMA/iwcm: Fix iwcm work deallocation
RMDA/cm: Fix missing ib_cm_destroy_id() in ib_cm_insert_listen()
IB/hfi1, qib: Ensure RCU is locked when accessing list
ARM: imx: build v7_cpu_resume() unconditionally
ARM: dts: am437x-idk-evm: Fix incorrect OPP node names
ARM: dts: imx7-colibri: Fix frequency for sd/mmc
hwmon: (adt7462) Fix an error return in ADT7462_REG_VOLT()
dmaengine: coh901318: Fix a double lock bug in dma_tc_handle()
powerpc: fix hardware PMU exception bug on PowerVM compatibility mode systems
efi/x86: Align GUIDs to their size in the mixed mode runtime wrapper
efi/x86: Handle by-ref arguments covering multiple pages in mixed mode
dm integrity: fix a deadlock due to offloading to an incorrect workqueue
scsi: pm80xx: Fixed kernel panic during error recovery for SATA drive
Linux 4.19.109
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iae5cc72b8c7c96b0a15c76657b9c3bcc4341a7aa
Disable CONFIG_DEBUG_DEVRES to fix ABI differences caused by changes to
devres_alloc_node function when this debug option is enabled.
Bug: 151110905
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I27ba172843c80ffd1dfbcc6cc4d706c5b18eb5d3
commit 53770f0ec5 upstream.
If we need to perform synchronous I/O in dm_integrity_map_continue(),
we must make sure that we are not in the map function - in order to
avoid the deadlock due to bio queuing in generic_make_request. To
avoid the deadlock, we offload the request to metadata_wq.
However, metadata_wq also processes metadata updates for write requests.
If there are too many requests that get offloaded to metadata_wq at the
beginning of dm_integrity_map_continue, the workqueue metadata_wq
becomes clogged and the system is incapable of processing any metadata
updates.
This causes a deadlock because all the requests that need to do metadata
updates wait for metadata_wq to proceed and metadata_wq waits inside
wait_and_add_new_range until some existing request releases its range
lock (which doesn't happen because the range lock is released after
metadata update).
In order to fix the deadlock, we create a new workqueue offload_wq and
offload requests to it - so that processing of offload_wq is independent
from processing of metadata_wq.
Fixes: 7eada909bf ("dm: add integrity target")
Cc: stable@vger.kernel.org # v4.12+
Reported-by: Heinz Mauelshagen <heinzm@redhat.com>
Tested-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8319e9d5ad upstream.
The mixed mode runtime wrappers are fragile when it comes to how the
memory referred to by its pointer arguments are laid out in memory, due
to the fact that it translates these addresses to physical addresses that
the runtime services can dereference when running in 1:1 mode. Since
vmalloc'ed pages (including the vmap'ed stack) are not contiguous in the
physical address space, this scheme only works if the referenced memory
objects do not cross page boundaries.
Currently, the mixed mode runtime service wrappers require that all by-ref
arguments that live in the vmalloc space have a size that is a power of 2,
and are aligned to that same value. While this is a sensible way to
construct an object that is guaranteed not to cross a page boundary, it is
overly strict when it comes to checking whether a given object violates
this requirement, as we can simply take the physical address of the first
and the last byte, and verify that they point into the same physical page.
When this check fails, we emit a WARN(), but then simply proceed with the
call, which could cause data corruption if the next physical page belongs
to a mapping that is entirely unrelated.
Given that with vmap'ed stacks, this condition is much more likely to
trigger, let's relax the condition a bit, but fail the runtime service
call if it does trigger.
Fixes: f6697df36b ("x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20200221084849.26878-4-ardb@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 63056e8b5e upstream.
Hans reports that his mixed mode systems running v5.6-rc1 kernels hit
the WARN_ON() in virt_to_phys_or_null_size(), caused by the fact that
efi_guid_t objects on the vmap'ed stack happen to be misaligned with
respect to their sizes. As a quick (i.e., backportable) fix, copy GUID
pointer arguments to the local stack into a buffer that is naturally
aligned to its size, so that it is guaranteed to cover only one
physical page.
Note that on x86, we cannot rely on the stack pointer being aligned
the way the compiler expects, so we need to allocate an 8-byte aligned
buffer of sufficient size, and copy the GUID into that buffer at an
offset that is aligned to 16 bytes.
Fixes: f6697df36b ("x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y")
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20200221084849.26878-2-ardb@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc37a1632d upstream.
PowerVM systems running compatibility mode on a few Power8 revisions are
still vulnerable to the hardware defect that loses PMU exceptions arriving
prior to a context switch.
The software fix for this issue is enabled through the CPU_FTR_PMAO_BUG
cpu_feature bit, nevertheless this bit also needs to be set for PowerVM
compatibility mode systems.
Fixes: 68f2f0d431 ("powerpc: Add a cpu feature CPU_FTR_PMAO_BUG")
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
Reviewed-by: Leonardo Bras <leonardo@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200227134715.9715-1-desnesn@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 31623468be upstream.
The commit 337c6c9a69 ("ARM: dts: am437x-idk-evm: Disable
OPP50 for MPU") adjusts couple of OPP nodes defined in the
common am4372.dtsi file, but used outdated node names. This
results in these getting treated as new OPP nodes with missing
properties.
Fix this properly by using the correct node names as updated in
commit b9cb2ba718 ("ARM: dts: Use - instead of @ for DT OPP
entries for TI SoCs").
Reported-by: Roger Quadros <rogerq@ti.com>
Fixes: 337c6c9a69 ("ARM: dts: am437x-idk-evm: Disable OPP50 for MPU")
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 512a928aff upstream.
This function is not only needed by the platform suspend code, but is also
reused as the CPU resume function when the ARM cores can be powered down
completely in deep idle, which is the case on i.MX6SX and i.MX6UL(L).
Providing the static inline stub whenever CONFIG_SUSPEND is disabled means
that those platforms will hang on resume from cpuidle if suspend is disabled.
So there are two problems:
- The static inline stub masks the linker error
- The function is not available where needed
Fix both by just building the function unconditionally, when
CONFIG_SOC_IMX6 is enabled. The actual code is three instructions long,
so it's arguably ok to just leave it in for all i.MX6 kernel configurations.
Fixes: 05136f0897 ("ARM: imx: support arm power off in cpuidle for i.mx6sx")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 817a68a658 upstream.
The packet handling function, specifically the iteration of the qp list
for mad packet processing misses locking RCU before running through the
list. Not only is this incorrect, but the list_for_each_entry_rcu() call
can not be called with a conditional check for lock dependency. Remedy
this by invoking the rcu lock and unlock around the critical section.
This brings MAD packet processing in line with what is done for non-MAD
packets.
Fixes: 7724105686 ("IB/hfi1: add driver files")
Link: https://lore.kernel.org/r/20200225195445.140896.41873.stgit@awfm-01.aw.intel.com
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eb0bbba763 upstream.
Currently the vmmc is supplied by the 1.8V pmic rail but this is wrong.
The default module behaviour is to power VCCQ and VCC by the 3.3V power
rail. Optional the user can connect the VCCQ to the pmic 1.8V emmc
power rail using a solder jumper.
Fixes: ddec5d1c00 ("ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM")
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 46b7edf1c7 upstream.
I've noticed that when writing data to the modem the writes can time out
at some point eventually. Looks like kicking the modem idle GPIO every
600 ms instead of once a second fixes the issue. Note that this rate is
different from our runtime PM autosuspend rate MDM6600_MODEM_IDLE_DELAY_MS
that we still want to keep at 1 second, so let's add a separate define for
PHY_MDM6600_IDLE_KICK_MS.
Fixes: f7f50b2a7b ("phy: mapphone-mdm6600: Add runtime PM support for n_gsm on USB suspend")
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Michael Scott <hashcode0f@gmail.com>
Cc: NeKit <nekit1000@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit be4e3c737e upstream.
We have an interrupt handler for the wake-up GPIO pin, but we're missing
the code to wake-up the system. This can cause timeouts receiving data
for the UART that shares the wake-up GPIO pin with the USB PHY.
All we need to do is just wake the system and kick the autosuspend
timeout to fix the issue.
Fixes: 5d1ebbda03 ("phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4")
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Michael Scott <hashcode0f@gmail.com>
Cc: NeKit <nekit1000@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9b3193089e upstream.
commit c2caa4da46 ("ASoC: Fix widget powerdown on shutdown") added a
set of the power state during snd_soc_dapm_shutdown to ensure the
widgets powered off. However, when commit 39eb5fd13d
("ASoC: dapm: Delay w->power update until the changes are written")
added the new_power member of the widget structure, to differentiate
between the current power state and the target power state, it did not
update the shutdown to use the new_power member.
As new_power has not updated it will be left in the state set by the
last DAPM sequence, ie. 1 for active widgets. So as the DAPM sequence
for the shutdown proceeds it will turn the widgets on (despite them
already being on) rather than turning them off.
Fixes: 39eb5fd13d ("ASoC: dapm: Delay w->power update until the changes are written")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200228153145.21013-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6c89ffea60 upstream.
dpcm_show_state() invokes multiple snprintf() calls to concatenate
formatted strings on the fixed size buffer. The usage of snprintf()
is supposed for avoiding the buffer overflow, but it doesn't work as
expected because snprintf() doesn't return the actual output size but
the size to be written.
Fix this bug by replacing all snprintf() calls with scnprintf()
calls.
Fixes: f86dcef87b ("ASoC: dpcm: Add debugFS support for DPCM")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200218111737.14193-4-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 107d06441b ]
dma_slave_config direction was marked as deprecated quite some
time back, remove the usage from this driver so that the field
can be removed
ENBLn bit should be set before any dma request triggered, please
refer to the below information from i.mx6sololite RM. Otherwise,
spi/uart test will be fail because there is dma request from tx
fifo always before dmaengine_prep_slave_sg() in where ENBLn set
and violate the below rule.
https://www.nxp.com/docs/en/reference-manual/IMX6SLRM.pdf:
40.8.28 Channel Enable RAM (SDMAARM_CHNENBLn)
"It is thus essential for the Arm platform to program them before
any DMA request is triggered to the SDMA, otherwise an unpredictable
combination of channels may be started".
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
[vkoul: sqashed patch from Robin into direction change]
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 549cd0ba04 upstream.
The debugfs output of intel skl driver writes strings with multiple
snprintf() calls with the fixed size. This was supposed to avoid the
buffer overflow but actually it still would, because snprintf()
returns the expected size to be output, not the actual output size.
Fix it by replacing snprintf() calls with scnprintf().
Fixes: d14700a01f ("ASoC: Intel: Skylake: Debugfs facility to dump module config")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200218111737.14193-3-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
