(Upstream commit d0022c0ef29b78bcbe8a5c5894bd2307143afce1.)
Add brackets around the evaluation of the 'addr' parameter to the
untagged_addr() macro so that the cast to 'u64' applies to the result
of the expression.
Cc: <stable@vger.kernel.org>
Fixes: 597399d0cb ("arm64: tags: Preserve tags for addresses translated via TTBR1")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 135692346
Change-Id: I1bce8f6a185258a365aaa292483fabc02519301f
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
(Upstream commit dcde237319e626d1ec3c9d8b7613032f0fd4663a.)
Currently the arm64 kernel ignores the top address byte passed to brk(),
mmap() and mremap(). When the user is not aware of the 56-bit address
limit or relies on the kernel to return an error, untagging such
pointers has the potential to create address aliases in user-space.
Passing a tagged address to munmap(), madvise() is permitted since the
tagged pointer is expected to be inside an existing mapping.
The current behaviour breaks the existing glibc malloc() implementation
which relies on brk() with an address beyond 56-bit to be rejected by
the kernel.
Remove untagging in the above functions by partially reverting commit
ce18d171cb ("mm: untag user pointers in mmap/munmap/mremap/brk"). In
addition, update the arm64 tagged-address-abi.rst document accordingly.
Link: https://bugzilla.redhat.com/1797052
Fixes: ce18d171cb ("mm: untag user pointers in mmap/munmap/mremap/brk")
Cc: <stable@vger.kernel.org> # 5.4.x-
Cc: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Victor Stinner <vstinner@redhat.com>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 135692346
Change-Id: Iadeceb2d5d5fb576ab1bb5ae1a67f4971bbbf88e
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
This module allows presenting the kernel TPM interface while proxying
the TPM commands into a file descriptor. The module was originally
implemented to support running a TPM simulator on the same host system
and exposing a kernel TPM interface to a Linux container, but it is also
a convenient incremental step while we figure out our long-term strategy
with crosvm, which does not have TPM support following the same
standards as qemu.
CONFIG_TCG_TPM, the base config for the various TPM drivers, required
CONFIG_SECURITYFS. CONFIG_SECURITYFS exists only as a boolean and not a
tristate, so we can't install it as a module.
Bug: 148102533
Test: Build and run locally with cuttlefish, check for /dev/vtpmx
Change-Id: I568a50c2ecb7899aae70e7a20efaedc84443511d
Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
We don't need this any more as devices which are consoles and also
platform devices are automatically excluded from binding unless the user
opts into it.
This reverts commit 2fdad105a0.
Bug: 146517987
Change-Id: I2b9cc9c13870e5ecccbf04addadd48e59658aee3
Signed-off-by: Alistair Delva <adelva@google.com>
Make the fallback path for claiming platform devices trigger only if a
new module parameter is specified:
serdev_ttyport.pdev_tty_port=ttyS2
Bug: 146517987
Change-Id: Ibf331ad6e6d8712a405921530f217f7122428b13
Signed-off-by: Alistair Delva <adelva@google.com>
This patch supports fusb302 to do data role swap for
Type-C Dongle with PD adapter.
The test case is:
- Use a Type-C Dongle (PD adapter & USB & HDMI)
- Plug a PD adapter into Type-C Dongle first, then
connect the Dongle with RK3399 Type-C0 port.
- Check if Type-C Dongle can fetch 5V with the following log:
"fusb302 4-0022: PD connected as UFP, fetching 5V"
- Wait for the data role swap completion (hundreds of
milliseconds), then check if the Type-C USB can work
in DFP mode.
Without this patch, the DWC3 can't switch to DFP mode
after the data role swap completion. It's because that
when the fusb302 do data role swap, it only sends extcon
notifier with EXTCON_USB true or EXTCON_USB_HOST true.
Generally, the sequence of the extcon notifier sent from
fusb302 is:
- send "EXTCON_USB = true" and "EXTCON_USB_HOST=false"
to DWC3 driver, then DWC3 switch to UFP, and set the
connected flag to true.
- After swap completion, send "EXTCON_USB = false" and
"EXTCON_USB_HOST = true" to DWC3 driver. Because the
connected flag is true, the DWC3 is unable to switch
to DFP mode.
This patch forces DWC3 to do disconnection if it detects
the connected flag is true and the DWC3 mode is UFP.
This patch can also fix a bug if we use command to force
DWC3 mode to DFP (host mode) when the DWC3 is working on
UFP mode and connecting to USB Host.
Change-Id: I5b3a17957ef720eb90664186033ef91269ecbc38
Signed-off-by: William Wu <william.wu@rock-chips.com>
There are currently 1200+ instances of using platform_get_resource()
and devm_ioremap_resource() together in the kernel tree.
This patch wraps these two calls in a single helper. Thanks to that
we don't have to declare a local variable for struct resource * and can
omit the redundant argument for resource type. We also have one
function call less.
Change-Id: Ibca8e80bb3724ee7dcfb1754ae93dbe6220bf556
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
(cherry picked from commit 7945f929f1)
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 3 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct typec_mux at typec_mux.h:38:1' changed:
type size changed from 256 to 6272 (in bits)
1 data member deletion:
'list_head typec_mux::entry', at offset 64 (in bits) at typec_mux.h:40:1
there are data member changes:
type 'void ()*' of 'typec_mux::set' changed:
entity changed from 'void ()*' to compatible type 'typedef typec_mux_set_fn_t' at typec_mux.h:32:1
type size hasn't changed
and offset changed from 192 to 6208 (in bits) (by +6016 bits)
10 impacted interfaces
'struct typec_switch at typec_mux.h:21:1' changed:
type size changed from 256 to 6272 (in bits)
1 data member deletion:
'list_head typec_switch::entry', at offset 64 (in bits) at typec_mux.h:23:1
there are data member changes:
type 'void ()*' of 'typec_switch::set' changed:
entity changed from 'void ()*' to compatible type 'typedef typec_switch_set_fn_t' at typec_mux.h:13:1
type size hasn't changed
and offset changed from 192 to 6208 (in bits) (by +6016 bits)
10 impacted interfaces
'struct usb_pd_identity at typec.h:83:1' changed:
type size changed from 96 to 128 (in bits)
1 data member insertion:
'u32 usb_pd_identity::product_type', at offset 96 (in bits) at typec.h:88:1
4 impacted interfaces
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150877929
Change-Id: I769ce04dfc099c5de744c39e5a850397589f313a
This ABI difference was introduced by commit 6e7065617217 ("tcpm: Add
support for VPD detection by a DRP port"). Add the struct field for ABI
compatibility for TPCM vendor module support.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150877929
Change-Id: I036893d5f149cfe1314b45c6308888dcfc3f417f
Registering real device entries (struct device) for the mode
muxes as well as for the orientation switches.
The Type-C mux code was deliberately attempting to avoid
creation of separate device entries for the orientation
switch and the mode switch (alternate modes) because they
are not physical devices. They are functions of a single
physical multiplexer/demultiplexer switch device.
Unfortunately because of the dependency we still have on the
underlying mux device driver, we had to put in hacks like
the one in the commit 3e3b81965c ("usb: typec: mux: Take
care of driver module reference counting") to make sure the
driver does not disappear from underneath us. Even with
those hacks we were still left with a potential NUll pointer
dereference scenario, so just creating the device entries,
and letting the core take care of the dependencies. No more
hacks needed.
Bug: 150877929
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change-Id: I63038acfdbf2fff9eef5f5d6a9eae77fc7f0fcb4
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 3370db3519)
All the code paths that lead to the return statement are where
match is always true, hence the check to see if it is true is
redundant and can be removed.
Detected by CoverityScan, CID#14769672 ("Logically dead code")
Bug: 150877929
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Iedfd85df7b0719ff0b9dc4431188850921157e57
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit eb76b37aaf)
The return from the call to fwnode_property_read_u16_array is int,
it can be a negative error code however this is being assigned to
an size_t variable 'nval', hence the check is always false.
Fix this by making 'nval' an int.
Detected by Coccinelle ("Unsigned expression compared with
zero: nval < 0")
Bug: 150877929
Fixes: 96a6d031ca ("usb: typec: mux: Find the muxes by also matching against the device node")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I3169e47b59bbe5972b79ce88f849b345a401898e
(cherry picked from commit 4e46f271c3)
Signed-off-by: Will McVicker <willmcvicker@google.com>
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>
Fix commit 079b3c7cdb ("usb: dwc2: make hcd into L3 power
off state when suspend").
This fixes otg-host restore failed after system resume for
dwc2 related interrupts were not enabled when no gadget had
been bounded before.
Change-Id: Iceac66acf063c6226dcafb2086149122511ab5c1
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Refer to lowlevel mechanism of dwc2, amend the PHY operation
process in case of unbalance for power on and off as well.
This patch fix unbalanced phy power management if otg cable
plug in between the completion of dwc2 probe and udc_start.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Change-Id: Ic0c2811ed84f8f46e99e03eff44c9d20a791e05f
update this for support some GRF's register offset over 0x10000
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Change-Id: I8427e17fafa537980f2233483c23e8f3511fd9e9
The Audio PWM provides an easy and cheap solution for audio playback
in low quality. it acts as a digital-to-analog converter(DAC), which
converts the digital audio PCM data to the analog PWM signals.
Change-Id: I50ca4aebf4fc5c92ff07d2aa53e9d33b91035e46
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.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>
