Right now only anonymous page faults are speculatively handled,
thus leaving out a large percentage of faults still requiring to
take mmap_sem. These were left out since there can be fault
handlers mainly in the fs layer which may use vma in unknown ways.
This patch enables speculative fault for ext4, f2fs and shmem. The
feature is disabled by default and enabled via allow_file_spec_access
kernel param.
Bug: 171954515
Change-Id: I0d23ebf299000e4ac5e2c71bc0b7fc9006e98da9
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
add vendor hooks to compute new cpu freq for oem feature.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I232d2e1ae885d6736eca9e4709870f4272b4873d
This reverts commit 1aff922933 as we are
free to update the ABI at this point in time.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iba293953586fd78503ef5f47db40ccdc03b098f5
When a PD charger advertising Rp-3.0 is connected to a sink port, the
sink port current limit would 3A, during SNK_DISCOVERY, till power
negotiation starts. Once the negotiation starts the power limit needs
to drop down to pSnkStby(500mA @ 5V) and to negotiated current limit
once the explicit contract is in place. Not all charging loops can ramp
up to 3A and drop down to 500mA within tSnkStdby which is 15ms. The port
partner might hard reset if tSnkStdby is not met.
To solve this problem, this patch introduces slow-charger-loop which
when set makes the port request PD_P_SNK_STDBY_MW upon entering
SNK_DISCOVERY(instead of 3A or the 1.5A during SNK_DISCOVERY) and the
actual currrent limit after RX of PD_CTRL_PSRDY for PD link or during
SNK_READY for non-pd link.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210414024000.4175263-2-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1373fefc6243cc96b3565f0ffffadfac4ccfb977
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I811b7f9ec732da0cab715837737ea09ea4a5bbbf
Since cpu_hwcaps and cpu_hwcap_keys are exported symbols, reserve
space in them for any future cpu capabilities or erratas.
Bug: 183169515
Change-Id: I85ebab5ee0eaeabaa2f2856aaae8730c77b16177
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
The CRC calculation done by genksyms is triggered when the parser hits
EXPORT_SYMBOL*() macros. At this point, genksyms recursively expands the
types, and uses that as the input for the CRC calculation. In the case
of forward-declared structs, the type expands to 'UNKNOWN'. Next, the
result of the expansion of each type is cached, and is re-used when/if
the same type is seen again for another exported symbol in the file.
Unfortunately, this can cause CRC 'stability' issues when a struct
definition becomes visible in the middle of a C file. For example, let's
assume code with the following pattern:
struct foo;
int bar(struct foo *arg)
{
/* Do work ... */
}
EXPORT_SYMBOL_GPL(bar);
/* This contains struct foo's definition */
#include "foo.h"
int baz(struct foo *arg)
{
/* Do more work ... */
}
EXPORT_SYMBOL_GPL(baz);
Here, baz's CRC will be computed using the expansion of struct foo that
was cached after bar's CRC calculation ('UNKOWN' here). But if
EXPORT_SYMBOL_GPL(bar) is removed from the file (because of e.g. symbol
trimming using CONFIG_TRIM_UNUSED_KSYMS), struct foo will be expanded
late, during baz's CRC calculation, which now has visibility over the
full struct definition, hence resulting in a different CRC for baz.
This can cause annoying issues for distro kernel (such as the Android
Generic Kernel Image) which use CONFIG_UNUSED_KSYMS_WHITELIST. Indeed,
as per the above, adding a symbol to the whitelist can change the CRC of
symbols that are already kept exported. As such, modules built against a
kernel with a trimmed ABI may not load against the same kernel built
with an extended whitelist, even though they are still strictly binary
compatible. While rebuilding the modules would obviously solve the
issue, I believe this classifies as an odd genksyms corner case, and it
gets in the way of kernel updates in the GKI context.
To work around the issue, make sure to keep issuing the
__GENKSYMS_EXPORT_SYMBOL macros for all trimmed symbols, hence making
the genksyms parsing insensitive to symbol trimming.
Bug: 184275771
Bug: 167230325
Signed-off-by: Quentin Perret <qperret@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210408180105.2496212-1-qperret@google.com
Change-Id: Id94085d446d5648943d4fe4f79e3177bc4f98093
Enable hidden config SND_SOC_TOPOLOGY need by SND_SOC=m
Bug: 153682187
Change-Id: I47dabfaa6f0d138f78fbc1c9fc0d4ac3c7c73986
Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com>
Using the default setting 5 means the first bucket contains the
uclamp values from 0 to 19 (in percentage), in this case, if the
uclamp.min setting of a group is under 20, it will fall into this
bucket with other groups that have uclamp.min set to 0, which
increase the possibility of over boost. By setting the bucket
count to 20 will ease this situation, while a uclamp.min greater
than 4 will fall into a different bucket.
Bug: 170487162
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: Ife96b199bee36faedc8e129ade17e475cdbe44e0
Add snd_soc_pcm_component_ack back, which can be used to get an
updated buffer pointer in the platform driver.
On Asymmetric multiprocessor, this pointer can be sent to Cortex-M
core for audio processing.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1615516725-4975-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 159736148
(cherry picked from commit 8bdfc0455e3a59e2c1207a56be22e910fae0e0d5
https: //git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git sound/for-5.13)
Change-Id: I16f49ea140b9b9185313814fce3f3d9ef4c1a44a
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
The commit e7bbb7acabf4 ("dmaengine: add peripheral configuration")
adds peripheral configuration for dma_slave_config.
This configuration is useful for some audio peripherals, for
example, the peripheral supports multi fifos, we can
let the DMA know which fifos are selected. So also add
this configuration for snd_dmaengine_dai_dma_data.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1612509985-11063-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 159736148
(cherry picked from commit 500c9f8c58a7c8cd5d9c1483569c046cfcfc47a4)
Change-Id: Ib8fd722b382e8d605db9edee65ab16df014d63db
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Some complex dmaengine controllers have capability to program the
peripheral device, so pass on the peripheral configuration as part of
dma_slave_config
Link: https://lore.kernel.org/r/20201109085450.24843-3-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Bug: 159736148
(cherry picked from commit e7bbb7acabf47d74672e0e314bed4d452d2097b4)
Change-Id: Id12675fe9b79781310d99e1aec6d323dc4f360f5
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Currently, a PM domain's idle state is determined based on whether the
QoS requirements are met. However, even entering an idle state may waste
power if the minimum residency requirements aren't fulfilled.
CPU PM domains use the next timer wakeup for the CPUs in the domain to
determine the sleep duration of the domain. This is compared with the
idle state residencies to determine the optimal idle state. For other PM
domains, determining the sleep length is not that straight forward. But
if the device's next_event is available, we can use that to determine
the sleep duration of the PM domain.
Let's update the domain governor logic to check for idle state residency
based on the next wakeup of devices as well as QoS constraints. But
since, not all domains may contain devices capable of specifying the
next wakeup, let's enable this additional check only if specified by the
domain's flags when initializing the domain.
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit c79aa080fb0f60a0e24c87014dc9c2f373e1379b)
Bug: 170654157
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I70714c4d5840034771b2b4a6b1d38eb4c73d1f85
Some devices may have a predictable interrupt pattern while executing
usecases. An example would be the VSYNC interrupt associated with
display devices. A 60 Hz display could cause a interrupt every 16 ms. If
the device were in a PM domain, the domain would need to be powered up
for device to resume and handle the interrupt.
Entering a domain idle state saves power, only if the residency of the
idle state is met. Without knowing the idle duration of the domain, the
governor would just choose the deepest idle state that matches the QoS
requirements. The domain might be powered off just as the device is
expecting to wake up. If devices could inform PM frameworks of their
next event, the parent PM domain's idle duration can be determined.
So let's add the dev_pm_genpd_set_next_wakeup() API for the device to
inform PM domains of the impending wakeup. This information will be the
domain governor to determine the best idle state given the wakeup.
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 67e3242ee28052daa90e1fa193efc601939fde58)
Bug: 170654157
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: Id0b4c3a3d0f6223a24d94ae953777ff8c8f160f3
This reverts commit e6c313525b.
Drop [v6] patches in favor of upstream backports.
Bug: 170654157
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: Iafa2cb1397ff033efe1c6d1c963e58d0478eed23
This reverts commit 7a9d53c2ea.
Drop [v6] patches in favor of upstream backports.
Bug: 170654157
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I1ed4debfe724940b4c11c18f87ef97d046975918
This reverts commit 283e327164.
Drop [v6] patches in favor of upstream backports.
Bug: 170654157
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I82b8117cc6c6bf6b28af666f34257775ade428fa
Guard isolate_and_split_free_page() with CONFIG_COMPACTION. This fixes
the follwoing build error as the function collides with its inline stub
from the header file:
mm/compaction.c:766:15: error: redefinition of ‘isolate_and_split_free_page’
766 | unsigned long isolate_and_split_free_page(struct page *page,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from mm/compaction.c:14:
./include/linux/compaction.h:241:29: note: previous definition of ‘isolate_and_split_free_page’ was here
241 | static inline unsigned long isolate_and_split_free_page(struct page *page,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Bug: 186243330
Fixes: 8cd9aa93b7 ("ANDROID: implement wrapper for reverse migration")
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: Ie8f3fedcc9d4af5cfdcfd5829377671745ab77d6
Enable CONFIG_HIST_TRIGGERS which will be useful
in various perf evaluations.
Bug: 185890730
Change-Id: Ia4c140863ce248fea0dd235ca8a9cdee1176f8ed
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
The broadcast device is switched to oneshot mode when the system switches
to oneshot mode. If a broadcast clock event device is registered after the
system switched to oneshot mode, it will stay in periodic mode forever.
Ensure that a late registered device which is selected as broadcast device
is initialized in oneshot mode when the system already uses oneshot mode.
[ tglx: Massage changelog ]
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210331083318.21794-1-jindong.yue@nxp.com
(cherry picked from commit 9c336c9935cff267470bb3aaa85c66fac194b650
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core)
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: If570b8d396f84add2266150bc85d5c82c45bcb0f
Bug: 185092876
This patch separates arm64's user and kernel memory access primitives
into distinct routines, adding new __{get,put}_kernel_nofault() helpers
to access kernel memory, upon which core code builds larger copy
routines.
The kernel access routines (using LDR/STR) are not affected by PAN (when
legitimately accessing kernel memory), nor are they affected by UAO.
Switching to KERNEL_DS may set UAO, but this does not adversely affect
the kernel access routines.
The user access routines (using LDTR/STTR) are not affected by PAN (when
legitimately accessing user memory), but are affected by UAO. As these
are only legitimate to use under USER_DS with UAO clear, this should not
be problematic.
Routines performing atomics to user memory (futex and deprecated
instruction emulation) still need to transiently clear PAN, and these
are left as-is. These are never used on kernel memory.
Subsequent patches will refactor the uaccess helpers to remove redundant
code, and will also remove the redundant PAN/UAO manipulation.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20201202131558.39270-8-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 170327579
Bug: 172318110
(cherry picked from commit fc703d80130b1c9d6783f4cbb9516fd5fe4a750d)
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: Ia465de7c1cb4ed40119962669475406737fefa6a
As a step towards implementing __{get,put}_kernel_nofault(), this patch
splits most user-memory specific logic out of __{get,put}_user(), with
the memory access and fault handling in new __{raw_get,put}_mem()
helpers.
For now the LDR/LDTR patching is left within the *get_mem() helpers, and
will be removed in a subsequent patch.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20201202131558.39270-7-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 170327579
Bug: 172318110
(cherry picked from commit f253d827f33cb5a5990b5cfd271941d1a21ecd85)
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I9ffa7320fa877fc452dc515573bc8990ecc99a52
We currently have many uaccess_*{enable,disable}*() variants, which
subsequent patches will cut down as part of removing set_fs() and
friends. Once this simplification is made, most uaccess routines will
only need to ensure that the user page tables are mapped in TTBR0, as is
currently dealt with by uaccess_ttbr0_{enable,disable}().
The existing uaccess_{enable,disable}() routines ensure that user page
tables are mapped in TTBR0, and also disable PAN protections, which is
necessary to be able to use atomics on user memory, but also permit
unrelated privileged accesses to access user memory.
As preparatory step, let's rename uaccess_{enable,disable}() to
uaccess_{enable,disable}_privileged(), highlighting this caveat and
discouraging wider misuse. Subsequent patches can reuse the
uaccess_{enable,disable}() naming for the common case of ensuring the
user page tables are mapped in TTBR0.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20201202131558.39270-5-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 170327579
Bug: 172318110
(cherry picked from commit 923e1e7d8223cfa6e67d00ad238ee415c3c59320)
[glider: resolved minor conflicts in arch/arm64/include/asm/uaccess.h]
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I15e3ba3b5b7b99ff93c42acf1aac17984094aebc
Sparse complains about casting a five byte number to a ulong on 32-bit
platorms. Fix by anding the constant with ULONG_MAX
Bug: 186015158
Test: incfs_test passes, sparse reports no warnings on 32 & 64 bit builds
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ic83e03626b7f290370d75b3aaba187b8392fb344
Adding seven sysfs entries per mount:
reads_failed_timed_out
reads_failed_hash_verification
reads_failed_other
reads_delayed_pending
reads_delayed_pending_us
reads_delayed_min
reads_delayed_min_us
to allow for status monitoring from userland
Change-Id: I50677511c2af4778ba0c574bb80323f31425b4d0
Test: incfs_test passes
Bug: 160634343
Bug: 184291759
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Compiler (arm-linux-gnueabihf-gcc 8.3.0) complains about an invalid cast
of an __aligned_u64 integer to a pointer on 32-bit architectures. Using
u64_to_user_ptr() for the cast fixes the following warning:
fs/incfs/pseudo_files.c: In function ‘ioctl_create_file’:
fs/incfs/pseudo_files.c:656:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
656 | (u8 __user *)args.signature_info,
| ^
Bug: 183339614
Fixes: bc6a70e849 (ANDROID: Incremental fs: Remove signature checks from kernel)
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I98a987fb83c160740796c0b4b3fdd7551880e12a
Exporting the symbol find_user()& free_uid(), in which ko module can get
user task information for tuning.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I12135c0af312904dd21b6f074beda086ad5ece98
Update whitelist for the symbols used by the unisoc device and
update the ABI representation accordingly.
Bug: 186088840
Change-Id: Ia113c052fbe65c27284f9a752f349138026f8d27
Signed-off-by: Jian Gong <jian.gong@unisoc.com>
add vendor hooks for cpu affinity to support oem's feature.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I3402abec4d9faa08f564409bfb8db8d7902f3aa2
Allows PMIC charger loops which are slow(i.e. cannot meet the
15ms deadline) to still comply to pSnkStby i.e Maximum power
that can be consumed by sink while in Sink Standby state as defined
in 7.4.2 Sink Electrical Parameters of USB Power Delivery Specification
Revision 3.0, Version 1.2.
This patch introduces slow-charger-loop which when set makes
the port request PD_P_SNK_STDBY_MW(2.5W i.e 500mA@5V) upon entering
SNK_DISCOVERY (instead of 3A or the 1.5A during SNK_DISCOVERY) and the
actual currrent limit after RX of PD_CTRL_PSRDY for PD link or during
SNK_READY for non-pd link.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210414142656.63749-3-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ca0584c40a6648ae2c7f2ef50446af2f7bdf82db
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4d407142756274487113cadd38f6cbe1aa7e5b68
The START_TRANSFER command needs to be executed while in ON/U0 link
state (with an exception during register initialization). Don't use
dwc->link_state to check this since the driver only tracks the link
state when the link state change interrupt is enabled. Check the link
state from DSTS register instead.
Note that often the host already brings the device out of low power
before it sends/requests the next transfer. So, the user won't see any
issue when the device starts transfer then. This issue is more
noticeable in cases when the device delays starting transfer, which can
happen during delayed control status after the host put the device in
low power.
Fixes: 799e9dc829 ("usb: dwc3: gadget: conditionally disable Link State change events")
Cc: <stable@vger.kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/bcefaa9ecbc3e1936858c0baa14de6612960e909.1618884221.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c560e76319a94a3b9285bc426c609903408e4826
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I19ddf77f506ee44c05c6d2be8dc30e351bf6d94d
"usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply"
introduced a regression for req_out_volt and req_op_curr calculation.
req_out_volt should consider the newly calculated max voltage instead
of previously accepted max voltage by the port partner. Likewise,
req_op_curr should consider the newly calculated max current instead
of previously accepted max current by the port partner.
Fixes: e3a072022487 ("usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210415050121.1928298-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 374157ff88ae1a7f7927331cbc72c1ec11994e8a
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iac776f49da8e84daa65080728a5a53b184766b2a
