Allow for vendor components or modules to override
"TLB conflict abort" handler,
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Test: Verified with scripts/gki/device_snapshot
Test: No impact on /sys/ (except new module files) and /dev/
Test: All devices probed as before
Bug: 141888626
Change-Id: I7d0a4d7440412f2ffc611fe597d5d39d18a2a03a
(cherry picked from commit 75c07a4fbd301fbff1522e66996bad91617cd06f)
Bug: 149990629
QoS request for CPU_DMA_LATENCY can be better optimized if the request
can be set only for the required cpus and not all cpus. This helps save
power on other cores, while still gauranteeing the quality of service.
Enhance the QoS constraints data structures to support target value for
each core. Requests specify if the QoS is applicable to all cores
(default) or to a selective subset of the cores or to a core(s), that the
IRQ is affine to.
QoS requests that need to track an IRQ can be set to apply only on the
cpus to which the IRQ's smp_affinity attribute is set to. The QoS
framework will automatically track IRQ migration between the cores. The
QoS is updated to be applied only to the core(s) that the IRQ has been
migrated to.
Idle and interested drivers can request a PM QoS value for a constraint
across all cpus, or a specific cpu or a set of cpus. Separate APIs have
been added to request for individual cpu or a cpumask. The default
behaviour of PM QoS is maintained i.e, requests that do not specify a
type of the request will continue to be effected on all cores. Requests
that want to specify an affinity of cpu(s) or an irq, can modify the PM
QoS request data structures by specifying the type of the request and
either the mask of the cpus or the IRQ number depending on the type.
Updating the request does not reset the type of the request.
The userspace sysfs interface does not support CPU/IRQ affinity.
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
(cherry picked from commit 16cafdb44fb3a66a7d06936d775efe483ad62b7d)
Bug: 153463922
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I1aad836a985fd303f2254fe607bb909a6b720dd5
Leaf changes summary: 2 artifacts changed
Changed leaf types summary: 2 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 devfreq at devfreq.h:148:1' changed:
type size changed from 13824 to 14144 (in bits)
2 data member insertions:
'mutex devfreq::event_lock', at offset 384 (in bits) at devfreq.h:152:1
'bool devfreq::dev_suspended', at offset 14080 (in bits) at devfreq.h:178:1
there are data member changes:
'device devfreq::dev' offset changed from 384 to 640 (in bits) (by +256 bits)
'devfreq_dev_profile* devfreq::profile' offset changed from 6656 to 6912 (in bits) (by +256 bits)
'const devfreq_governor* devfreq::governor' offset changed from 6720 to 6976 (in bits) (by +256 bits)
'char devfreq::governor_name[16]' offset changed from 6784 to 7040 (in bits) (by +256 bits)
'notifier_block devfreq::nb' offset changed from 6912 to 7168 (in bits) (by +256 bits)
'delayed_work devfreq::work' offset changed from 7104 to 7360 (in bits) (by +256 bits)
'unsigned long int devfreq::previous_freq' offset changed from 7808 to 8064 (in bits) (by +256 bits)
'devfreq_dev_status devfreq::last_status' offset changed from 7872 to 8128 (in bits) (by +256 bits)
'void* devfreq::data' offset changed from 8128 to 8384 (in bits) (by +256 bits)
'unsigned long int devfreq::min_freq' offset changed from 8192 to 8448 (in bits) (by +256 bits)
'unsigned long int devfreq::max_freq' offset changed from 8256 to 8512 (in bits) (by +256 bits)
'unsigned long int devfreq::scaling_min_freq' offset changed from 8320 to 8576 (in bits) (by +256 bits)
'unsigned long int devfreq::scaling_max_freq' offset changed from 8384 to 8640 (in bits) (by +256 bits)
'bool devfreq::stop_polling' offset changed from 8448 to 8704 (in bits) (by +256 bits)
'unsigned int devfreq::total_trans' offset changed from 8480 to 8736 (in bits) (by +256 bits)
'unsigned int* devfreq::trans_table' offset changed from 8512 to 8768 (in bits) (by +256 bits)
'unsigned long int* devfreq::time_in_state' offset changed from 8576 to 8832 (in bits) (by +256 bits)
'unsigned long int devfreq::last_stat_updated' offset changed from 8640 to 8896 (in bits) (by +256 bits)
'srcu_notifier_head devfreq::transition_notifier_list' offset changed from 8704 to 8960 (in bits) (by +256 bits)
20 impacted interfaces:
function devfreq* devfreq_add_device(device*, devfreq_dev_profile*, const char*, void*)
function int devfreq_add_governor(devfreq_governor*)
function void devfreq_interval_update(devfreq*, unsigned int*)
function void devfreq_monitor_resume(devfreq*)
function void devfreq_monitor_start(devfreq*)
function void devfreq_monitor_stop(devfreq*)
function void devfreq_monitor_suspend(devfreq*)
function int devfreq_remove_device(devfreq*)
function int devfreq_remove_governor(devfreq_governor*)
function int devfreq_resume_device(devfreq*)
function int devfreq_suspend_device(devfreq*)
function devfreq* devm_devfreq_add_device(device*, devfreq_dev_profile*, const char*, void*)
function thermal_cooling_device* of_devfreq_cooling_register(device_node*, devfreq*)
function int ufshcd_dme_get_attr(ufs_hba*, u32, u32*, u8)
function int ufshcd_dme_set_attr(ufs_hba*, u32, u8, u32, u8)
function u32 ufshcd_get_local_unipro_ver(ufs_hba*)
function int ufshcd_hold(ufs_hba*, bool)
function void ufshcd_release(ufs_hba*)
function void ufshcd_remove(ufs_hba*)
function int update_devfreq(devfreq*)
'struct regmap_irq_chip at regmap.h:1138:1' changed:
type size hasn't changed
1 data member insertion:
'unsigned int regmap_irq_chip::clear_ack', at offset 288 (in bits) at regmap.h:1148:1
there are data member changes:
'bool regmap_irq_chip::type_invert' offset changed from 288 to 320 (in bits) (by +32 bits)
'int regmap_irq_chip::num_regs' offset changed from 320 to 352 (in bits) (by +32 bits)
3 impacted interfaces:
function int devm_regmap_add_irq_chip(device*, regmap*, int, int, int, const regmap_irq_chip*, regmap_irq_chip_data**)
function void devm_regmap_del_irq_chip(device*, int, regmap_irq_chip_data*)
function int regmap_irq_get_virq(regmap_irq_chip_data*, int)
Bug: 149430094
Signed-off-by: Saravana Kannan <saravanak@google.com>
Change-Id: I1ce004bc7d52ef153ef54be9feb7f32cd031288e
There is a possibility to switch the governors from sysfs even when the
device is in suspended state. This can cause a NOC error at times when
trying to access the device's monitor registers in a suspended state. This
change fixes this issue. Introduce a variable dev_suspended to know if
the device is in suspended state or not. Check if the device is suspended
before switching the governor from sysfs.
Change-Id: I15055aa51daa35272be4667e5bafb8ccd7933098
Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org>
Bug: 152343889
(cherry picked from commit 9c41437c072048a9487353b85a452114c4031659)
Signed-off-by: Saravana Kannan <saravanak@google.com>
There is a race condition when the event governor_store is being executed
from sysfs and the device issues a suspend. The devfreq data structures
would become stale when the suspend tries to access them in the middle
of the governor_store operation. Fix this issue by taking a lock around
suspend and resume operations so that these operations are not concurrent
with the other events from sysfs.
Also rename the sysfs_lock as event_lock since the same lock is used
for non sysfs operations like suspend and resume as well.
Change-Id: Ifa0e93915a920cec3e0429966328a1128d61098b
Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org>
Bug: 152343889
(cherry picked from commit 8bf200e7136a6896e429e9bfab116238c1d99be6)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Currently, concurrent writes to sysfs entries leave the possibility
for race conditions within the devfreq framework. For example,
concurrently executing max_freq_store and governor_store can result
in attempting to perform an update_devfreq() before the new governor's
start handler can be executed.
A more concrete case is a race between polling_interval_store and
governor_store. Because no lock is used after calling into the event
handler of the old governor and there's nothing preventing work from
being queued after the monitor is stopped, it's possible to
accidentally cause delayed work to be queued on the governor being
switched to. This can be seen if you create two threads, one which
changes a device's governor between simple_ondemand and performance,
and one which changes its polling interval between 45 and 50.
All of these races can be addressed with the introduction of a lock
that prevents sysfs operations from interleaving in this fashion.
Change-Id: Ia6887dcb2d69dc2576837a6c09fed55a28943abc
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org>
Bug: 152343889
(cherry picked from commit 78fdd25c1abb1f23f43243f09c3d81cccaa844bc)
[saravanak Fixed some conflicts]
Signed-off-by: Saravana Kannan <saravanak@google.com>
WCD codec requires clear registers to be written '1' and
'0' for clearing interrupts. Add this support in regmap irq
to clear ack registers.
Change-Id: I399592fc0ee7f3a01a32267684a9be340076ffb1
Signed-off-by: Ramprasad Katkam <katkam@codeaurora.org>
Bug: 153500481
[saravanak Minor edit to commit text]
(cherry picked from commit 25401ed921044cafdf588efb2e6ba19e8454f14a)
Signed-off-by: Saravana Kannan <saravanak@google.com>
This feature is undesirable and not required by Android.
Bug: 153460450
Change-Id: I548bb44b9fecc90ba2589fb74b4e4693e639a8c9
Signed-off-by: Alistair Delva <adelva@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
GENKSYMS shouldn't care about the __must_check compiler flag. So strip
it out for GENKSYMS.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 153478475
Test: compile, check crc
Change-Id: I512639a4f719037728ffbfa48e7b766510c7d726
Adds members set/get_min_state() to struct
thermal_cooling_device_ops.
Also adds the field min_state_throttle to struct thermal_governor.
Test: build
Bug: 149945768
Change-Id: I085feb9d3b818dcf9754f0f624166c360593bce6
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
(cherry picked from commit 8a12149c264c7b871932ad90f76e5981452bb4bb)
[hridya: cherry-picked only the ABI diff]
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Drivers may need to use the ASoC core function to
find out whether a particular component is already
registered with ALSA core or not.
Export the function so that drivers can use it outside
of the file.
Bug: 151372815
Test: build
Change-Id: I13e4a053de085974b0b53c392a9453e46f1aa66d
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
(cherry picked from commit fbcf71fe2dadcfbfe6b60f49534dd0312fd3b9d6)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Modify enum thermal_trip_type to add configurable thermal
trip points of THERMAL_TRIP_CONFIGURABLE_HI,
THERMAL_TRIP_CONFIGURABLE_LOW, and THERMAL_TRIP_CRITICAL_LOW.
Bug: 149945768
Change-Id: I25c9c3bcfd58e44da5369187d1095559062f1860
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
(cherry picked from commit 3f67fe6c0a924f23ba19033a0f55b7d82e268926)
[hridya: commit amended to only include ABI diff].
Signed-off-by: Hridya Valsaraju <hridya@google.com>
When the filesystem is mounted with '-o inlinecrypt', make fscrypt fall
back to filesystem-layer crypto when inline crypto won't work, e.g. due
to the hardware not supporting the encryption algorithm.
When blk-crypto-fallback is disabled, this fixes '-o inlinecrypt' to not
break any fscrypt policies that would otherwise work.
This is needed for VtsKernelEncryptionTest to pass on some devices.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: I3e730df4608efb12d7126d1a85faddcccb566764
Signed-off-by: Eric Biggers <ebiggers@google.com>
We need a way to tell which type of keys the inline crypto hardware
supports (standard, wrapped, or both), so that fallbacks can be used
when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto).
We can't simply assume that
keyslot_mgmt_ll_ops::derive_raw_secret == NULL
means only standard keys are supported and that
keyslot_mgmt_ll_ops::derive_raw_secret != NULL
means that only wrapped keys are supported, because device-mapper
devices always implement this method. Also, hardware might support both
types of keys.
Therefore, add a field keyslot_manager::features which contains a
bitmask of flags which indicate the supported types of keys. Drivers
will need to fill this in. This patch makes the UFS standard crypto
code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may
need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead.
Then, make keyslot_manager_crypto_mode_supported() take the key type
into account.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005
Signed-off-by: Eric Biggers <ebiggers@google.com>
If blk-crypto-fallback is needed but is disabled by kconfig, make
blk_crypto_start_using_mode() return an error rather than succeeding.
Use ENOPKG, which matches the error code used by fscrypt when crypto API
support is missing with fs-layer encryption.
Also, if blk-crypto-fallback is needed but the algorithm is missing from
the kernel's crypto API, change the error code from ENOENT to ENOPKG.
This is needed for VtsKernelEncryptionTest to pass on some devices.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: Iedf00ca8e48c74a5d4c40b12712f38738a04ef11
Signed-off-by: Eric Biggers <ebiggers@google.com>
Build error results in excess arguments provided from
commit 7c4bd0cdf4eff0dd6774183435fc8139743cd6e4
("power_supply: support for CHARGE_DISABLE")
Change introduced in partial cherry pick of the above in
commit 2d02a30a0b896e6ab970837cf54477550c34c31a
("ANDROID: GKI: power: supply: Add POWER_SUPPLY_PROP_CHARGE_DISABLE")
Removed excess unused argument.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Cc: AleX Pelosi <apelosi@google.com>
Cc: Jack Wu <wjack@google.com>
Bug: 150789066
Change-Id: I5be743eecffa0be7b8ec4969963f0a283f5684c5
The following members are added to struct backlight_device:
struct thermal_cooling_device *cdev;
int thermal_brightness_limit;
int usr_brightness_req;
Change-Id: I1405ddd6c3cfff99cd84842d3773851168dcfe78
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
(cherry picked from commit 6cd31b3ff45ab44f3624e9139a0602e3a1a6f9ea)
[connoro: commit amended to include only ABI diff]
Bug: 153189857
Signed-off-by: Connor O'Brien <connoro@google.com>
Implement APIs to dynamically allocate and free secondary
event rings based upon interrupter number. Also add exported
APIs in usb core layer which allows secondary event ring
management via remote processor entity.
Change-Id: I5ee7d44d6cad8e35e22d3c1a027a1eec5d208585
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
(cherry picked from commit 8d48fb820fb849cee2474354f75ef5a78044bd19)
[connoro: squashed the following commits:
a44f0d73af95 usb: xhci: Clear event handler busy flag upon
event ring cleanup
a1504b40da0e usb: xhci: Acknowledge pending events in
secondary event ring
a7e7dd8a3499 usb: host: xhci: Fix bound check for
interrupter number
c4d9817a3cc6 usb: core: Allow secondary event ring clean
upon disconnect
576c1e1fe65b usb: host: xhci: Fix secondary event ring
setup]
Bug: 151258428
Signed-off-by: Connor O'Brien <connoro@google.com>
Unique usb core id is used to differentiate between
different usb controllers.
[jackp@codeaurora.org: squashed with usb: host: Fix passing of
core-id property to xhci-plat]
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
(cherry picked from commit 4c874ac2de1e09d148aeb47362e89f60b2743280)
[connoro: commit amended to include only the ABI diff]
Signed-off-by: Connor O'Brien <connoro@google.com>
Bug: 151258428
Change-Id: I736d5a99f51820e562311c988ea9fd09b3e7117b
set CONFIG_USB_HCI_HCD=y for arm64 and x86 gki defconfigs
Bug: 151258428
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: I74e9a1fbc5efbbfacbe5046c1604afc05fad6bf9
Set CONFIG_BRIDGE=y for arm64 and x86 gki defconfigs
Bug: 151683251
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: Ifa34d56b2b8e497d3d696f8c80e137ffc4a93280
On modules with no executable code, LLVM generates a __cfi_check stub,
but won't align it to page size as expected. This change ensures the
function is at the beginning of the .text section and correctly aligned
for the CFI shadow.
Bug: 148458318
Change-Id: I85ea31fa851bc23988f649b021b3ac7e9d9dcb38
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
It's long been possible to disable kernel module autoloading completely
(while still allowing manual module insertion) by setting
/proc/sys/kernel/modprobe to the empty string. This can be preferable
to setting it to a nonexistent file since it avoids the overhead of an
attempted execve(), avoids potential deadlocks, and avoids the call to
security_kernel_module_request() and thus on SELinux-based systems
eliminates the need to write SELinux rules to dontaudit module_request.
However, when module autoloading is disabled in this way,
request_module() returns 0. This is broken because callers expect 0 to
mean that the module was successfully loaded.
Apparently this was never noticed because this method of disabling
module autoloading isn't used much, and also most callers don't use the
return value of request_module() since it's always necessary to check
whether the module registered its functionality or not anyway. But
improperly returning 0 can indeed confuse a few callers, for example
get_fs_type() in fs/filesystems.c where it causes a WARNING to be hit:
if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
fs = __get_fs_type(name, len);
WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no fs?\n", len, name);
}
This is easily reproduced with:
echo > /proc/sys/kernel/modprobe
mount -t NONEXISTENT none /
It causes:
request_module fs-NONEXISTENT succeeded, but still no fs?
WARNING: CPU: 1 PID: 1106 at fs/filesystems.c:275 get_fs_type+0xd6/0xf0
[...]
This should actually use pr_warn_once() rather than WARN_ONCE(), since
it's also user-reachable if userspace immediately unloads the module.
Regardless, request_module() should correctly return an error when it
fails. So let's make it return -ENOENT, which matches the error when
the modprobe binary doesn't exist.
I've also sent patches to document and test this case.
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Jessica Yu <jeyu@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: NeilBrown <neilb@suse.com>
Link: https://lore.kernel.org/r/20200318230515.171692-2-ebiggers@kernel.org
Bug: 151589316
Change-Id: I5e04f85e12a4f85da23e53bc11da1ade565abcd6
Signed-off-by: Eric Biggers <ebiggers@google.com>
Currently ASoC core creates a static route b/w
playback/capture widgets of cpu and codec dai
if they are part of the same dai-link. However
this will cause codec path to get powered up
followed by the backend dai start during device
switch use-case where the front-end is not closed,
leading to audio playback failure if either bit-width
or sample rate is different.
Test: build
Bug: 151372815
Change-Id: Icd17677a73fdc4bd30e0918fcaa7e7f394245685
Signed-off-by: Sudheer Papothi <spapothi@codeaurora.org>
(cherry picked from commit 85a57fb9237c4021150e3a3ba9a274a7b78b79a5)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Allow DAI's to be hostless so that no PCM data is sent between DAI
and CPU. This allows for power savings as there is no DMA or CPU
interaction required.
TODO: we shouldn't need to allocate a PAGE for a dummy DMA buffer.
Test: build
Bug: 151372815
Change-Id: I8947f1ad2c4a7013e92e21078b35e3cad332cf6f
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Patrick Lai <plai@codeaurora.org>
Git-commit: b77e8f4fb684f8afd45d4276e3dba9edd4a0c4e0
Git-repo: https://source.codeaurora.org/quic/la/kernel/msm/log/?h=msm-2.6.38
[bgoswami@codeaurora.org: fix merge conflict by moving
code to the right source file. Fix checkpatch errors
for line over 80 character. Fix compilation errors.]
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: Meng Wang <mwang@codeaurora.org>
(cherry picked from commit c009f70138e1b66c6ae9597947b56a761f92bc0d)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
The following members are added to struct thermal_zone_device_ops:
int (*set_polling_delay)(struct thermal_zone_device *, int);
int (*set_passive_delay)(struct thermal_zone_device *, int);
Test: build and boot
Bug: 149945768
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
(cherry picked from commit f68eb1a39e07a296ff4424c594c0fcc9b48240bc)
[hridya: commit amended to only include ABI diff]
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Change-Id: Iad25d6585a35ecb71fdef36e27b27bece93a7c11
Add support for the sensor drivers using of-thermal interface to support
reading the trip temperature from the hardware using a callback. This
can be used in case, when the hardware works on a pre-configured
threshold different from the threshold set by software.
Test: build
Bug: 149945768
Change-Id: Ic5aaf1586b8dcbb3da0dd775718407c257b2064f
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
(cherry picked from commit 8a12149c264c7b871932ad90f76e5981452bb4bb)
[hridya: added an extra null pointer check, partial cherry-pick]
Signed-off-by: Hridya Valsaraju <hridya@google.com>
These APIs handle thermal trips from sensors.
These are required to reduce ABI diff.
Test: build
Bug: 149945768
Change-Id: I2ba4e91c954c9b13a323ec729b0c5a99f51e8fc3
(cherry picked from commit 8a12149c264c7b871932ad90f76e5981452bb4bb)
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
[hridya: commit amended to only include ABI diff, some pointer checks
added, also squashed 'c379a963e6ce9 drivers: thermal: Evaluate based on
trip temperature']
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Thermal core framework subscribes for suspend/resume notification.
On resume notification it re-evaluates each thermal zone for
temperature and cooling state update. For some devices,
a large number of thermal zones are enabled for different mitigations.
Re-evaluating each thermal zone during resume leads to multiple issues
including delay in back to back suspend resume scenario, power penalty
for frequent wake up due to re-setting trip threshold especially
during cold temperature usecases.
Add wake-capable-sensor property to thermal zone devicetree node to
denote that these sensors are wakeup capable. If a thermal zone has
this property defined, thermal framework ignores resume re-evaluation
and can service the threshold notification during the suspend/resume
path.
Test: build
Bug: 149945768
Change-Id: I07edf80ad29009378af4c70e750d01bde6f30806
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
(cherry picked from commit a915ed479e624a1be30e34720b07207136fca0a9)
[hridya: added some pointer checks]
Signed-off-by: Hridya Valsaraju <hridya@google.com>
__loop_update_dio() can be called as a part of loop_set_fd(), when the
block queue is not yet up and running; avoid freezing the block queue in
that case, since that is an expensive operation.
Bug: 148607611
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Signed-off-by: Martijn Coenen <maco@android.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 0fbcf57982)
Change-Id: I17d8de6b6b54a667703d60ea1c62449bb14331da
Return early in loop_set_block_size() if the requested block size is
identical to the one we already have; this avoids expensive calls to
freeze the block queue.
Bug: 148607611
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martijn Coenen <maco@android.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 7e81f99afd)
Change-Id: I61778680579dbfeeb193133527a3926d376e0bac
A previous change added a test on the wrong config flag; rename
CFI to CFI_CLANG.
Bug: 145210207
Change-Id: Id8aead2eb2c75ad6442d10165f6cb86ccfb9c2f9
Signed-off-by: Alistair Delva <adelva@google.com>
For lots of good security reasons, this config option needs to be
enabled
Bug: 152470236
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I96a88bbee9c4d17be97ed63262dbab2ef31fee79
(cherry picked from commit ab789e8750)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Remove condition for including struct sk_buff members based on
CONFIG_BRIDGE_NETFILTER config.
Bug: 151840548
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Iee626843e107e8d64c3c6c4a1cc9c08f4e38f5af
Merged-In: Iee626843e107e8d64c3c6c4a1cc9c08f4e38f5af
Currently, PWM core driver provides interfaces for configuring PWM
period and duty length in nanoseconds with an integer data type, so
the max period can be only set to ~2.147 seconds. Add interfaces which
can set PWM period and duty with u64 data type to remove this
limitation.
Signed-off-by: Fenglin Wu <fenglinw@codeaurora.org>
Bug: 152542675
Test: build and boot
(cherry picked from commit a691c36aef3f1123f41f12e8d508c5e3457fec7f)
[surenb: removed sysfs API changes, replaced 32-bit divisions with 64-bit
ones in the following drivers to fix allmodconfig build:
drivers/clk/clk-pwm.c
drivers/hwmon/pwm-fan.c
drivers/pwm/pwm-clps711x.c
drivers/pwm/pwm-sti.c
drivers/pwm/pwm-sun4i.c
]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I149c14b2d59b181344e7bb77393c64bcd9998de5
Merged-In: I149c14b2d59b181344e7bb77393c64bcd9998de5
Since INCFS_IOC_GET_FILLED_BLOCKS potentially leaks information about usage
patterns, and is only useful to someone filling the file, best protect it in
the same way as INCFS_IOC_FILL_BLOCKS.
Add useful field data_block_out as well
Test: incfs_test passes
Bug: 152983639
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I126a8cf711e56592479093e9aadbfd0e7f700752
When read log is 0 sized, we still need to init the wait queue to avoid
kernel panics if someone does decide to poll on the read log.
Test: Added test for this condition, incfs_test crashes
With fix, incfs_test doesn't crash
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 152909243
Change-Id: Ic3250523bb7ddb1839f8e95852c17103e5ffb782
