Commit d948e6ca1899 ("spi: add power control when set_cs") added generic
runtime PM handling, but also changed the return value to be 1 instead
of 0 that we had earlier as pm_runtime_get functions return a positve
value on success.
This causes SPI devices to return errors for cases where they do:
ret = spi_setup(spi);
if (ret)
return ret;
As in many cases the SPI devices do not check for if (ret < 0).
Let's fix this by setting the status to 0 on succeess after the
runtime PM calls. Let's not return 0 at the end of the function
as this might break again later on if the function changes and
starts returning status again.
Fixes: d948e6ca1899 ("spi: add power control when set_cs")
Cc: Luhua Xu <luhua.xu@mediatek.com>
Cc: wsd_upstream@mediatek.com
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20191111195334.44833-1-tony@atomide.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 57a9460705f105e1d79d1410c5cfe285beda8986)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I70449c0ef2cbe4c34065adbad577f78ff9928b7b
When do randbuiding, we got this:
WARNING: unmet direct dependencies detected for THERMAL_GOV_POWER_ALLOCATOR
Depends on [n]: THERMAL [=y] && ENERGY_MODEL [=n]
Selected by [y]:
- THERMAL_DEFAULT_GOV_POWER_ALLOCATOR [=y] && <choice>
The Kconfig option THERMAL_DEFAULT_GOV_POWER_ALLOCATOR selects the
THERMAL_GOV_POWER_ALLOCATOR but this one depends on the ENERGY_MODEL
which is not enabled.
Make THERMAL_DEFAULT_GOV_POWER_ALLOCATOR depend on THERMAL_GOV_POWER_ALLOCATOR
to fix this warning.
Suggested-by: Quentin Perret <qperret@google.com>
Fixes: a4e893e802e6 ("thermal: cpu_cooling: Migrate to using the EM framework")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20191113105313.41616-1-yuehaibing@huawei.com
(cherry picked from commit 50260614245b09887c197c58732298f02052d61b)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I18848e76a65a03fb79b15ffae45919562e906853
Commit 5e6669387e22 ("of/platform: Pause/resume sync state during init
and of_platform_populate()") paused/resumed sync state during init only
if Linux had parsed and populated a devicetree.
However, the check for that (of_have_populated_dt()) can change after
of_platform_default_populate_init() executes. One example of this is
when devicetree unittests are enabled. This causes an unmatched
pause/resume of sync state. To avoid this, just unconditionally
pause/resume sync state during init.
Fixes: 5e6669387e22 ("of/platform: Pause/resume sync state during init and of_platform_populate()")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit ee9b280e17dce51c44e1d04d11eb0a4acd0ee1a9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iba0f462bf45e056a03f3e925d8037db81cb517b2
Check to make sure we have loaded a policy before we query the
sidtab's hash stats. Failure to do so could result in a kernel
panic/oops due to a dereferenced NULL pointer.
Fixes: 66f8e2f03c02 ("selinux: sidtab reverse lookup hash table")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(cherry picked from commit 15b590a81fcdd44ddcb4810f2a6334df8b6ca512)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9c9309341634ba0bdc6d151ec1ae4040a71dcd40
The confinement of the 32bit specific VDSO functions missed to define
BUILD_VDSO32 when building a 32bit MIPS kernel:
arch/mips/vdso/vgettimeofday.c: In function __vdso_clock_gettime:
arch/mips/vdso/vgettimeofday.c:17:9: error: implicit declaration of function __cvdso_clock_gettime32
arch/mips/vdso/vgettimeofday.c: In function __vdso_clock_getres:
arch/mips/vdso/vgettimeofday.c:39:9: error: implicit declaration of function __cvdso_clock_getres_time32
Force the define for 32bit builds in the VDSO Makefile.
Fixes: bf279849ad59 ("lib/vdso: Build 32 bit specific functions in the right context")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul Burton <paulburton@kernel.org>
Link: https://lore.kernel.org/r/87d0bjfaqa.fsf@nanos.tec.linutronix.de
(cherry picked from commit 99570c3da96a0f7aa11c6ad4981776f3adabf3b5)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I00c1cbdbca17f9b9d018e32115ed12cff5c1db18
If CONFIG_MFD_SYSCON=n:
include/linux/mfd/syscon.h:54:23: warning: ‘syscon_regmap_lookup_by_phandle_args’ defined but not used [-Wunused-function]
Fix this by adding the missing inline keyword.
Fixes: 6a24f567af4accef ("mfd: syscon: Add arguments support for syscon reference")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 5312f321a67cfee1fe4de245bc558fa857dce33b)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Icd3816bb79110e06860ea5ede34a69692fba7a7a
The commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency")
accidentally dropped the DEBUG FS support in bcm2835_defconfig. So
restore the config as before the commit.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
(cherry picked from commit 1bba60808404b873defa0f3560497eb2e8fe86b8)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9eb54e224a75a3970956898319e0a8a4ce28676f
Commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency")
removed select for DEBUG_FS but we still need it for development purposes.
Fixes: 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency")
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
(cherry picked from commit 41bae0caf5dc216c7b43712b8c2b6a0d63b4d655)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I43ec65bdd0d67d9a3be986c8ccc2e86eed1763fa
User Mode Linux is a flavor of x86 that from the vDSO prospective always
falls back on system calls. This implies that it does not require any
of the unified vDSO definitions and their inclusion causes side effects
like this:
In file included from include/vdso/processor.h:10:0,
from include/vdso/datapage.h:17,
from arch/x86/include/asm/vgtod.h:7,
from arch/x86/um/../kernel/sys_ia32.c:49:
>> arch/x86/include/asm/vdso/processor.h:11:29: error: redefinition of 'rep_nop'
static __always_inline void rep_nop(void)
^~~~~~~
In file included from include/linux/rcupdate.h:30:0,
from include/linux/rculist.h:11,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from arch/x86/um/../kernel/sys_ia32.c:25:
arch/x86/um/asm/processor.h:24:20: note: previous definition of 'rep_nop' was here
static inline void rep_nop(void)
Make sure that the unnecessary headers are not included when um is built
to address the problem.
Fixes: abc22418db02 ("x86/vdso: Enable x86 to use common headers")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200323124109.7104-1-vincenzo.frascino@arm.com
(cherry picked from commit 1c1a18b00d7e25d1bed3507880de2da07be704a2)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9a8e1f005867caa5b9da510ec129e0640cb55f10
Xin Long says:
On udp rx path udp_rcv_segment() may do segment where the frag skbs
will get the header copied from the head skb in skb_segment_list()
by calling __copy_skb_header(), which could overwrite the frag skbs'
extensions by __skb_ext_copy() and cause a leak.
This issue was found after loading esp_offload where a sec path ext
is set in the skb.
Fix this by discarding head state of the fraglist skb before replacing
its contents.
Fixes: 3a1296a38d0cf62 ("net: Support GRO/GSO fraglist chaining.")
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Reported-by: Xiumei Mu <xmu@redhat.com>
Tested-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cf673ed0e057a2dd68d930c6d7e30d53c70c5789)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iba886d897485ddddb2f1f67347b65fbba4d3e119
See:
https://www.rfc-editor.org/authors/rfc8781.txt
Cc: Erik Kline <ek@google.com>
Cc: Jen Linkova <furry@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Michael Haro <mharo@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Fixes: c24a77edc9a7 ("ipv6: ndisc: add support for 'PREF64' dns64 prefix identifier")
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 9175d3f38816835b0801bacbf4f6aff1a1672b71)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9ac8f0e2d500846e4a545434583bda3f671e00bb
Upon adding a new device from a DT node, we scan its properties and its
children's properties in order to create a consumer/supplier
relationship between the device and the property provider.
That said, it's possible for some of the node's children to be disabled,
which will create links that'll never be fulfilled.
To get around this, use the for_each_available_child_of_node() function
instead of for_each_available_node() when iterating over the node's
children.
Fixes: d4387cd11741 ("of: property: Create device links for all child-supplier depencencies")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit ed3655729182a59b9bef1b564c6fc2dcbbbe954e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I729c42bb3ddc8ecff1e5e097a439d672faea1f89
When creating a consumer/supplier relationship between two devices,
make sure the supplier node is actually active. Otherwise this will
create a link relationship that will never be fulfilled. This, in the
worst case scenario, will hang the system during boot.
Note that, in practice, the fact that a device-tree represented
consumer/supplier relationship isn't fulfilled will not prevent devices
from successfully probing.
Fixes: a3e1d1a7f5fc ("of: property: Add functional dependency link from DT bindings")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit 7456427af9def0fec5508dd8b861556038ee96a8)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I43d1405a81b00f360a514ff67487f0b375215ee3
Previous to commit 511ce378e16f07 ("mmc: Add MMC host software queue
support"), removing MMC_CAP2_CQE was enough to disable command queuing, but
now the cqe_ops must also be NULL otherwise ->cqe_enable() will be
called. Fix SDHCI_QUIRK_BROKEN_CQE to do that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 511ce378e16f07 ("mmc: Add MMC host software queue support")
Link: https://lore.kernel.org/r/20200518120939.1399-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 2b17b8d7cc65d333a48c6d32ee44fc489cecb7d9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibadc2a45340e9c783f836401910b44123a49f02f
get_unaligned_le16() is defined in linux/unaligned/access_ok.h header
but it uses symbols which may not be available, leading to build
failures on ia64. Using asm/unaligned.h seem to be the right thing
and used in other drivers.
This fixes below error reported by kbuild test robot
In file included from drivers/usb/host/xhci-pci-renesas.c:9:
>> include/linux/unaligned/access_ok.h:8:28: error: redefinition of 'get_unaligned_le16'
8 | static __always_inline u16 get_unaligned_le16(const void *p)
| ^~~~~~~~~~~~~~~~~~
In file included from arch/ia64/include/asm/unaligned.h:5,
from arch/ia64/include/asm/io.h:23,
from arch/ia64/include/asm/smp.h:21,
from include/linux/smp.h:67,
from include/linux/percpu.h:7,
from include/linux/arch_topology.h:9,
from include/linux/topology.h:30,
from include/linux/gfp.h:9,
from include/linux/xarray.h:14,
from include/linux/radix-tree.h:18,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/of.h:17,
from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from drivers/usb/host/xhci-pci-renesas.c:4:
include/linux/unaligned/le_struct.h:7:19: note: previous definition of 'get_unaligned_le16' was here
7 | static inline u16 get_unaligned_le16(const void *p)
| ^~~~~~~~~~~~~~~~~~
In file included from drivers/usb/host/xhci-pci-renesas.c:9:
include/linux/unaligned/access_ok.h:13:28: error: redefinition of 'get_unaligned_le32'
13 | static __always_inline u32 get_unaligned_le32(const void *p)
| ^~~~~~~~~~~~~~~~~~
In file included from arch/ia64/include/asm/unaligned.h:5,
from arch/ia64/include/asm/io.h:23,
from arch/ia64/include/asm/smp.h:21,
from include/linux/smp.h:67,
from include/linux/percpu.h:7,
from include/linux/arch_topology.h:9,
from include/linux/topology.h:30,
from include/linux/gfp.h:9,
from include/linux/xarray.h:14,
from include/linux/radix-tree.h:18,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/of.h:17,
from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from drivers/usb/host/xhci-pci-renesas.c:4:
include/linux/unaligned/le_struct.h:12:19: note: previous definition of 'get_unaligned_le32' was here
Fixes: 8bd5741e3145 ("usb: renesas-xhci: Add the renesas xhci driver")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200516162516.385149-1-vkoul@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 357abc1d6b832bdb6a7d27ed258f6d2be27d096d)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I30d9b8d71db8ca8143f22f461666f1deeef2a58b
The napi_gro_receive function no longer returns GRO_DROP ever, making
handling GRO_DROP dead code. This commit removes that dead code.
Further, it's not even clear that device drivers have any business in
taking action after passing off received packets; that's arguably out of
their hands. In this case, too, the non-gro path didn't bother checking
the return value. Plus, this had some clunky debugging functions that
duplicated code from elsewhere and was generally pretty messy. So, this
commit cleans that all up too.
Fixes: 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 045790b7bc66a75070c112a61558c639cef2263e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6fa5a5c7a7b123e192e02e5dc671041454ad2df8
If there is an error when parsing the NL80211_ATTR_HE_BSS_COLOR
attribute, we return immediately without freeing param.acl. Fit it by
using goto out instead of returning immediately.
Fixes: 5c5e52d1bb96 ("nl80211: add handling for BSS color")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200626124931.7ad2a3eb894f.I60905fb70bd20389a3b170db515a07275e31845e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 60a0121f8fa64b0f4297aa6fef8207500483a874)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1b25c92cf781e73aba43e4b344358c6f458ae50e
When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/1590371941-25430-1-git-send-email-yangtiezhu@loongson.cn
(cherry picked from commit b4147917ad4ff2c755e01a7ca296b14030d2d507)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5ba1ea5bf4846edb0c0990557bbd00ce81bdc15f
IV_INO_LBLK_* exist only because of hardware limitations, and currently
the only known use case for them involves AES-256-XTS. Therefore, for
now only allow them in combination with AES-256-XTS. This way we don't
have to worry about them being combined with other encryption modes.
(To be clear, combining IV_INO_LBLK_* with other encryption modes
*should* work just fine. It's just not being tested, so we can't be
100% sure it works. So with no known use case, it's best to disallow it
for now, just like we don't allow other weird combinations like
AES-256-XTS contents encryption with Adiantum filenames encryption.)
This can be relaxed later if a use case for other combinations arises.
Fixes: b103fb7653ff ("fscrypt: add support for IV_INO_LBLK_64 policies")
Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies")
Link: https://lore.kernel.org/r/20200721181012.39308-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit f000223c981a7c75f6f3ab7288f0be7b571c3644)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9b28a1d2394a8a70d020be3a4f8661ac5987a78d
Normally smp_store_release() or cmpxchg_release() is paired with
smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with
the more lightweight READ_ONCE(). However, for this to be safe, all the
published memory must only be accessed in a way that involves the
pointer itself. This may not be the case if allocating the object also
involves initializing a static or global variable, for example.
fscrypt_prepared_key includes a pointer to a crypto_skcipher object,
which is internal to and is allocated by the crypto subsystem. By using
READ_ONCE() for it, we're relying on internal implementation details of
the crypto subsystem.
Remove this fragile assumption by using smp_load_acquire() instead.
(Note: I haven't seen any real-world problems here. This change is just
fixing the code to be guaranteed correct and less fragile.)
Fixes: 5fee36095cda ("fscrypt: add inline encryption support")
Cc: Satya Tangirala <satyat@google.com>
Link: https://lore.kernel.org/r/20200721225920.114347-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 97c6327f7192d7312eabc033b26a41ad6816496c)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I03b3e854e44734206112554dfc38cfe899127cfa
When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes: 096030e7f449 ("nvmem: sprd: Add Spreadtrum SoCs eFuse support")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200722100705.7772-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bcd14bb7a68520bf88e45e91d354e43535624f82)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6121d3ca4cb636bb4088a3baab6da554984a8dd0
The commit 24a2042cb22f ("mac80211: add HE 6 GHz Band Capability
element") failed to check device capability before adding HE 6 GHz
capability element. Below warning is reported in 11ac device in mesh.
Fix that by checking device capability at HE 6 GHz cap IE addition
in mesh beacon and association request.
WARNING: CPU: 1 PID: 1897 at net/mac80211/util.c:2878
ieee80211_ie_build_he_6ghz_cap+0x149/0x150 [mac80211]
[ 3138.720358] Call Trace:
[ 3138.720361] ieee80211_mesh_build_beacon+0x462/0x530 [mac80211]
[ 3138.720363] ieee80211_start_mesh+0xa8/0xf0 [mac80211]
[ 3138.720365] __cfg80211_join_mesh+0x122/0x3e0 [cfg80211]
[ 3138.720368] nl80211_join_mesh+0x3d3/0x510 [cfg80211]
Fixes: 24a2042cb22f ("mac80211: add HE 6 GHz Band Capability element")
Reported-by: Markus Theil <markus.theil@tu-ilmenau.de>
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1593656424-18240-1-git-send-email-rmanohar@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 65ad3ef9fced4062dfd74e2f89443fb5ce184321)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I482ae69d99fcf58b3c08fef4561673b656d32995
The interrupt might be shared, in which case it is not an error for the
interrupt handler to be called when the interrupt status is zero, so don't
print the message unless there was enabled interrupt status.
Link: https://lore.kernel.org/r/20200811133936.19171-1-adrian.hunter@intel.com
Fixes: 9333d7757348 ("scsi: ufs: Fix irq return code")
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 6337f58cec030b34ced435b3d9d7d29d63c96e36)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I60f61f9453edae05b796afa7a37e59bf8ace32e1
In find_energy_efficient_cpu() 'cpu_cap' could be less that 'util'.
It might be because of RT, DL (so higher sched class than CFS), irq or
thermal pressure signal, which reduce the capacity value.
In such situation the result of 'cpu_cap - util' might be negative but
stored in the unsigned long. Then it might be compared with other unsigned
long when uclamp_rq_util_with() reduced the 'util' such that is passes the
fits_capacity() check.
Prevent this situation and make the arithmetic more safe.
Fixes: 1d42509e475cd ("sched/fair: Make EAS wakeup placement consider uclamp restrictions")
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lkml.kernel.org/r/20200810083004.26420-1-lukasz.luba@arm.com
(cherry picked from commit da0777d35f47892f359c3f73ea155870bb595700)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib3e22c155eb031854cfb4428494c1c4da57692b1
This commit fixes two issues:
1. The lockdep warning reported by Dong Aisheng <dongas86@gmail.com> [1].
It is a warning about a cycle (dpm_list_mtx --> kn->active#3 --> fw_lock)
that was introduced when device-link devices were added to expose device
link information in sysfs.
The patch that "introduced" this cycle can't be reverted because it's fixes
a real SRCU issue and also ensures that the device-link device is deleted
as soon as the device-link is deleted. This is important to avoid sysfs
name collisions if the device-link is create again immediately (this can
happen a lot with deferred probing).
2. Inconsistency in grabbing device_pm_lock() during device link deletion
Some device link deletion code paths grab device_pm_lock(), while others
don't. The device_pm_lock() is grabbed during device_link_add() because it
checks if the supplier is in the dpm_list and also reorders the dpm_list.
However, when a device link is deleted, it does not do either of those and
therefore device_pm_lock() is not necessary. Dropping the device_pm_lock()
in all the device link deletion paths removes the inconsistency in locking.
Thanks to Stephen Boyd for helping me understand the lockdep splat.
Fixes: 843e600b8a2b ("driver core: Fix sleeping in invalid context during device link deletion")
[1] - https://lore.kernel.org/lkml/CAA+hA=S4eAreb7vo69LAXSk2t5=DEKNxHaiY1wSpk4xTp9urLg@mail.gmail.com/
Reported-by: Dong Aisheng <dongas86@gmail.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Tested-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20200901184445.1736658-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6b57b15abe11aa334ebf726e02c0deaf123ba040)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I714523d92bbfbad145df2794c481cd0b697d7d16
When an encryption policy has the IV_INO_LBLK_32 flag set, the IV
generation method involves hashing the inode number. This is different
from fscrypt's other IV generation methods, where the inode number is
either not used at all or is included directly in the IVs.
Therefore, in principle IV_INO_LBLK_32 can work with any length inode
number. However, currently fscrypt gets the inode number from
inode::i_ino, which is 'unsigned long'. So currently the implementation
limit is actually 32 bits (like IV_INO_LBLK_64), since longer inode
numbers will have been truncated by the VFS on 32-bit platforms.
Fix fscrypt_supported_v2_policy() to enforce the correct limit.
This doesn't actually matter currently, since only ext4 and f2fs support
IV_INO_LBLK_32, and they both only support 32-bit inode numbers. But we
might as well fix it in case it matters in the future.
Ideally inode::i_ino would instead be made 64-bit, but for now it's not
needed. (Note, this limit does *not* prevent filesystems with 64-bit
inode numbers from adding fscrypt support, since IV_INO_LBLK_* support
is optional and is useful only on certain hardware.)
Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies")
Reported-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20200824203841.1707847-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 5e895bd4d5233cb054447d0491d4e63c8496d419)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie4abfef403dfacf790baa667a37febf591c7e3ca
Some MediaTek platforms does not have to bind MPHY so users shall not see
any unnecessary logs. Simply remove logs for this case.
Link: https://lore.kernel.org/r/20200908064507.30774-2-stanley.chu@mediatek.com
Fixes: fc4983018fea ("scsi: ufs-mediatek: Allow unbound mphy")
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 30a90782c105fe498df74161392aa143796b6886)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I01f51f1532bf1826692b22b5650acd25a63f3698
Simply add HOST_PA_TACTIVATE quirk back since it was incorrectly removed
before.
Link: https://lore.kernel.org/r/20200908064507.30774-3-stanley.chu@mediatek.com
Fixes: 47d054580a75 ("scsi: ufs-mediatek: fix HOST_PA_TACTIVATE quirk for Samsung UFS Devices")
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a3e40b80dc951057033dce86f0e675b2b822b513)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id1f55fa74d0d393974b9f152d3289cd3ac4e3298
We shouldn't accept any channels bigger than 233, fix that.
Reported-by: Amar <asinghal@codeaurora.org>
Fixes: d1a1646c0de7 ("cfg80211: adapt to new channelization of the 6GHz band")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20200917115222.312ba6f1d461.I3a8c8fbcc3cc019814fd9cd0aced7eb591626136@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit c0de8776af6543e10d1a5c8969679fd9f6b66fa9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I83a88dce9a0c78f949abd792c824ed6f923ee809
Required to enable CFR on lahaina, and CFR is based on relay file
system. So add the configure to enable relay fs.
Change-Id: Ic62be9a54a3ea38e9f8831ae7472390d6490f680
Signed-off-by: Wu Gao <wugao@codeaurora.org>
Add support for parsing EMMC specific address for hwkm
slave in cqhci crypto driver. Add similar support
in ufs crypto driver as well to get UFS specific address.
Remove support for parsing the hwkm slave address from dtsi
node from hwkm driver as it will be received as part of
hwkm_init(). Enable/disable cqhci crypto from cqhci_enable and
cqhci_disable instead of __cqhci_enable and __cqhci_disable.
Test:
1. Device booted upto UI with File Based Encryption enabled.
2. Key insertion using fscryptctl tool.
3. Created new files under /data and checked retention across
multiple re-boots.
4. vts_kernel_encryption_test tests.
5. check_encryption test for verifying metadata encryption.
6. Bootup wth qgki compiled build.
7. Bootup on holi and shima UFS device.
8. Setting encryption policy and read/write of data over multiple
reboots, using fscryptctl tool.
Change-Id: I1f437ebf8a3f4cd008027d708ccacc02dfb14d07
Signed-off-by: Vaibhav Agrawal <vagrawa@codeaurora.org>
Enable QMI communication to external chipsets with the QRTR MHI
transport driver.
Change-Id: Ia00917c75dd360afa387742ed9851ec66de6c667
Signed-off-by: Chris Lew <clew@codeaurora.org>
* refs/heads/tmp-dc2d5a0:
ANDROID: ABI: Update allowed list for QCOM
ANDROID: ABI: Update allowed list for QCOM
ANDROID: modules: cfi cleanup for module load failure
ANDROID: Temporarily disable XFRM_USER_COMPAT filtering
ANDROID: ABI: Update allowed list for QCOM
ANDROID: ABI: update allowed list for QCOM
ANDROID: fix kernelci build-break due to stop_ipi hook
BACKPORT: rcu/tree: Export rcu_idle_{enter,exit} to modules
ANDROID: GKI: Add some symbols to symbol list
ANDROID: arm64: smp: fix Lockdep warning: RCU used illegally from idle CPU.
ANDROID: Fix build-break caused by android_rvh_nf_conn_alloc hook
ANDROID: GKI: Enable DEBUG_INFO_DWARF4
ANDROID: cfi: ensure RCU is watching in __cfi_slowpath
UPSTREAM: mm/sl[uo]b: export __kmalloc_track(_node)_caller
BACKPORT: xfrm/compat: Translate 32-bit user_policy from sockptr
UPSTREAM: xfrm/compat: Add 32=>64-bit messages translator
UPSTREAM: xfrm/compat: Attach xfrm dumps to 64=>32 bit translator
UPSTREAM: xfrm/compat: Add 64=>32-bit messages translator
BACKPORT: xfrm: Provide API to register translator module
ANDROID: ABI: update allowed list for galaxy
ANDROID: Update the KMI_GENERATION after KMI changes on October 31
ANDROID: Input: bump SW_MAX up to 0x3f
ANDROID: GKI: ABI update for Oct 31 KABI break
ANDROID: GKI: add Android ABI padding to struct nf_conn
ANDROID: GKI: add vendor padding variable in struct skb_shared_info
ANDROID: GKI: net: add vendor hooks for 'struct nf_conn' lifecycle
ANDROID: GKI: add vendor padding variable in struct nf_conn
ANDROID: GKI: net: add vendor hooks for 'struct sock' lifecycle
ANDROID: GKI: add vendor padding variable in struct sock
ANDROID: fuse: Add support for d_canonical_path
ANDROID: vfs: add d_canonical_path for stacked filesystem support
ANDROID: fscrypt: prevent fscrypt_operations from affecting KMI
Revert "ANDROID: GKI: fix ABI breakage in module.h"
ANDROID: ABI: update allowed list for galaxy
FROMLIST: char: misc: increase DYNAMIC_MINORS value
Conflicts:
net/netfilter/nf_conntrack_core.c
Change-Id: I0687237ba5f07f291a5f3b49ee2057071fcb2717
Signed-off-by: Blagovest Kolenichev <bkolenichev@codeaurora.org>
After reclaiming vmalloc and adjusting lowmem, the two
regions are no longer contiguous. Update the messages
printed during bootup to list all regions corresponding
to low memory and vmalloc respectively.
Change-Id: Ib3e25b530b3dfbd1f9796cdc580fb79da484e850
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
Signed-off-by: Zhenhua Huang <zhenhuah@codeaurora.org>
Signed-off-by: Qingqing Zhou <qqzhou@codeaurora.org>
This size is the maximum amount of virtual address space we gather
up before attempting to purge with a TLB flush. It is 128M in most cases.
With repeated and high size vmalloc operations, it may easily generate
more fragments. This is wasting limited vmalloc area, for 32bits.
So make it configable and the default multiplier as 8, 32bits only.
Change-Id: I68a75acb16d3cff05f8b13c05ae78922269e219f
Signed-off-by: Zhenhua Huang <zhenhuah@codeaurora.org>
