This reverts commit 443c11e0b16bb99f9f59e563184c86d9e7f10974.
Reinstate patch for June 17 KMI update
Bug: 233781098
Change-Id: I47ebbc6a1cecc363b97e35c10a5e44d7221caa01
Enable CONFIG_SCSI_UFS_HPB such that the UFS HPB (Host Performance
Booster) feature can be used.
Bug: 235167182
Change-Id: I1aab63c83445e243be190396c452a4203e93dbc1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The sensor driver which register through thermal_of interface doesn't
have an option to get thermal zone mode change notification from
thermal core.
Add support for change_mode ops in thermal_of interface so that sensor
driver can use this ops for mode change notification.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
Link: https://lore.kernel.org/r/1646767586-31908-1-git-send-email-quic_manafm@quicinc.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Bug: 234115106
(cherry picked from commit bf70c57751
https: //git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git
thermal-v5.19-rc1)
Change-Id: I24bafb16ebc1d33c7ca71aa88bd964eb71973b4d
Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
Reserve ANDROID_OEM_DATA in struct mutex/rw_semaphore for recoreding
informaition about the lock, which helps to do oem specific lock
optimization.
Bug: 188869548
Change-Id: I33f767a1823f854a8deb8ba9078079aa6a9d76ea
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
(cherry picked from commit 372b24bad2)
Some vendors want to add a field when a 'sruct sock' is added so give a
hook to handle this. Any memory allocated when
trace_android_rvh_sk_alloc() is called needs to be freed when
trace_android_rvh_sk_free() is called.
Note, if trace_android_rvh_sk_alloc() fails, be sure to be able to
handle this in trace_android_rvh_sk_free(), but that should not be an
issue as that needs to be addressed in vendor code that runs for 'struct
sock' objects that have been created before the vendor code is loaded no
matter what.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I108a2f31d2dcc228f46159816deee6235afafbbd
Some vendors want to add a field when a 'sruct nf_conn' is added so give a
hook to handle this. Any memory allocated when
trace_android_rvh_nf_conn_alloc() is called needs to be freed when
trace_android_rvh_nf_conn_free() is called.
Note, if trace_android_rvh_nf_conn_alloc() fails, be sure to be able to
handle this in trace_android_rvh_nf_conn_free(), but that should not be
an issue as that needs to be addressed in vendor code that runs for
'struct nf_conn' objects that have been created before the vendor code
is loaded no matter what.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I4d2b025196a3df7ba4adec313c90483811cac728
Some vendors want to add things to 'struct sock', so give them a u64
where they can then have a pointer off to their private data and they
can do whatever they want to do without breaking or changing any abi for
anyone else.
Note, usually an android trace hook is also needed to use this properly,
so be aware that this will be required as well.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: Iab0b5570753d4a9722ecf9ca9eeb9b9887e2a9d9
Some vendors want to add things to 'struct nf_conn', so give them a u64
where they can then have a pointer off to their private data and they
can do whatever they want to do without breaking or changing any abi for
anyone else.
Note, usually an android trace hook is also needed to use this properly,
so be aware that this will be required as well.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I245c162ee3fb083e3f39cf7bec3bd78cb624e005
Recently, we noticed an issue where a process went into direct reclaim
while holding the kernfs rw semaphore for sysfs in write (exclusive)
mode. This caused processes who were doing DMA-BUF exports and releases
to go into uninterruptible sleep since they needed to acquire the same
semaphore for the DMA-BUF sysfs entry creation/deletion. In order to avoid
blocking DMA-BUF export for an indeterminate amount of time while
another process is holding the sysfs rw semaphore in exclusive mode,
this patch moves the per-buffer sysfs file creation to the default work
queue. Note that this can lead to a short-term inaccuracy in the dmabuf
sysfs statistics, but this is a tradeoff to prevent the hot path from
being blocked. A work_struct is added to dma_buf to achieve this, but as
it is unioned with the kobject in the sysfs_entry, dma_buf does not
increase in size.
Fixes: bdb8d06dfe ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs")
Originally-by: Hridya Valsaraju <hridya@google.com>
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Bug: 206979019
Link: https://lore.kernel.org/lkml/CABdmKX2dNYhgOYdrrJU6-jt6F=LjCidbKhR6t4F7yaa0SPr+-A@mail.gmail.com/T/
Change-Id: Ic0386849b6b248b0a72215633fc1a50782455bac
The associated vendor hooks/data are used for implementing dynamic memory.low protection based on memcgv2.
Bug: 232723420
Test: build pass
Change-Id: I2e92bdc2840af1eaaa08ee6427d2a82d78390005
Signed-off-by: zhaoyang.huang <zhaoyang.huang@unisoc.com>
This adds a ->execute_hs400_tuning() host callback to enable optional
support for host specific tuning for eMMC HS400 mode. Additionally, share
mmc_get_ext_csd() through the public host headerfile, to allow it to be
used by the host drivers, which is needed to support the HS400 tuning.
Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com>
Link: https://lore.kernel.org/r/20210917124803.22871-3-wenbin.mei@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Bug: 234554003
Signed-off-by: Peng Zhou <Peng.Zhou@mediatek.com>
Change-Id: Idf4f95d2505ef68bb444e3c46c2f2e1e0924140e
(cherry picked from commit f614fb60a1)
According to JEDEC Spec, there is no need to do tuning under HS400 mode
since the Rx signal is aligned with the DS signal. However, MediaTek's IC
need set its "DS delay" internally to ensure it can latch Rx signal
correctly.
In previous version, We provide an "hs400-ds-delay" in device tree to cover
different chipset/PCB design, and it works fine in most cases. But, with
the development of process technology and the big VCore voltage scale
range(may have 0.7V/0.6V/0.55V), it is difficult to find a suitable
"hs400-ds-delay" to cover all of IC corner cases(SSSS/TTTT/FFFF). So that
We must have the ability to do hs400 online tuning.
Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com>
Reviewed-by: Chaotian Jing <chaotian.jing@mediatek.com>
Link: https://lore.kernel.org/r/20210917124803.22871-4-wenbin.mei@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Bug: 234554003
Signed-off-by: Peng Zhou <Peng.Zhou@mediatek.com>
Change-Id: I02670c5e3277b4095a4f3fd89ea6724f8416601d
(cherry picked from commit c4ac38c653)
Use vma->file_ref_count to protect vma->vm_file from destruction during
speculative page fault handling.
Bug: 234527424
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0ebebcafe5f50444e582ec5835eb6005fa85f5b1
Use vma->file_ref_count to protect vma->vm_file from destruction during
speculative page fault handling.
Bug: 234527424
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Icdd558532872095869f9106cc7e4b7e07dc46748
Use vma->file_ref_count to protect vma->vm_file from destruction during
speculative page fault handling.
Bug: 234527424
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I4c826fd5ef45576566e1eb8f8f23d17e620e7fc9
In order to prevent destruction of vma->vm_file while it's being used
during speculative page fault handling, introduce an atomic refcounter.
Bug: 234527424
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0e971156f3e76feb45136bac1582a7eaab8c75df
We've recently added a .data section for the hypervisor, which kmemleak
is eager to parse. This clearly doesn't go well, so add the section to
kmemleak's block list.
Bug: 232768943
Bug: 235903024
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I29d81cb1246c590bd5203d560ea369e5f29d59b0
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
cause pgtable PA size larger than 32bit.
Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
so add a quirk to allow the PA of pgtables support up to bit35.
Signed-off-by: Ning Li <ning.li@mediatek.com>
Link: https://lore.kernel.org/linux-mediatek/20220616120713.12728-2-yf.wang@mediatek.com/
Bug: 235767992
Signed-off-by: Yunfei Wang <yf.wang@mediatek.com>
Change-Id: I5dd226507bfbbbe85cb00aa27d03cd3592740055
Add vendor hook to get signal for vendor-specific tuning.
Conflicts:
drivers/android/vendor_hooks.c
Bug: 184898838
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Change-Id: I83a28b0a6eb413976f4c57f2314d008ad792fa0d
(cherry picked from commit d623f1ff72)
Export is_ashmem_file function which will be used
by the minidump module to get ashmem info.
Bug: 193397560
Change-Id: I5b7816ad4775e5cf2c4f41c28b1c8dacc2c85b7e
Signed-off-by: liuhailong <liuhailong@oppo.com>
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
(cherry picked from commit 7bcfde2601)
In following scenario(diagram), when one thread X running dev_coredumpm()
adds devcd device to the framework which sends uevent notification to
userspace and another thread Y reads this uevent and call to
devcd_data_write() which eventually try to delete the queued timer that
is not initialized/queued yet.
So, debug object reports some warning and in the meantime, timer is
initialized and queued from X path. and from Y path, it gets reinitialized
again and timer->entry.pprev=NULL and try_to_grab_pending() stucks.
To fix this, introduce mutex and a boolean flag to serialize the behaviour.
cpu0(X) cpu1(Y)
dev_coredump() uevent sent to user space
device_add() ======================> user space process Y reads the
uevents writes to devcd fd
which results into writes to
devcd_data_write()
mod_delayed_work()
try_to_grab_pending()
del_timer()
debug_assert_init()
INIT_DELAYED_WORK()
schedule_delayed_work()
debug_object_fixup()
timer_fixup_assert_init()
timer_setup()
do_init_timer()
/*
Above call reinitializes
the timer to
timer->entry.pprev=NULL
and this will be checked
later in timer_pending() call.
*/
timer_pending()
!hlist_unhashed_lockless(&timer->entry)
!h->pprev
/*
del_timer() checks h->pprev and finds
it to be NULL due to which
try_to_grab_pending() stucks.
*/
Bug: 235577024
Change-Id: I5e86abf72e8dff6952ba493fd9f43a26b2b40352
Link: https://lore.kernel.org/lkml/2e1f81e2-428c-f11f-ce92-eb11048cb271@quicinc.com/
Link: https://lore.kernel.org/lkml/1653660220-19197-1-git-send-email-quic_mojha@quicinc.com/
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
The reserved_mem array must be statically allocated because it is used
prior to memblock being aware of all "no-map" or otherwise reserved
regions which have fixed physical addresses. Due to this limitation,
if one architecture/board has a large number of reserved_mem regions,
this limit must be raised for all.
In particular, certain new qcom boards currently have 63 reserved memory
regions, which when new features are added, pushes them over the existing
limit of 64.
A generalized breakdown by region type:
13 for linux-loaded device firmware
9 for guest-vms or inter-vm communication
15 cma heaps/dma-buf heaps
24 for bootloaders/hypervisor/secure-world devices or software
2 misc
Although this number could be reduced by a minor amount by combining
physically adjacent regions, this comes at the cost of losing
documention on what/who the regions are used by. In addition, combining
adjacent regions is not possible if there are phandles in devicetree
refering to the regions in question, such as "memory-region".
Vmlinux size before:
text data bss dec hex filename
31030829 15807732 588524 47427085 2d3ae0d dist/vmlinux
text data bss dec hex filename
31030877 15807668 592108 47430653 2d3bbfd dist/vmlinux
Bug: 229767760
Link: https://lore.kernel.org/linux-devicetree/1650488954-26662-1-git-send-email-quic_pdaly@quicinc.com/T/#u
Change-Id: I2bdc6ad1ecfe273aad3c72390283b6d1247b18c3
Signed-off-by: Patrick Daly <quic_pdaly@quicinc.com>
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
This reverts commit c555553a40d6795e0c5d18b8ee94ac516a0aef09.
Reason for revert: The binaries, and /sbin/ is not even present on Android systems. This patch was never tested :(
Bug: 202192667
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia1c35eba4a89a62ba678d8004742563372d3d920
This fixes the following build error:
ERROR: modules list out of date
Update it with:
cp [...]/out/android13-5.15/common/modules.order common/android/gki_aarch64_fips140_modules
Bug: 188620248
Change-Id: I5e06053001a3ea3cf488e9ad0af8f6e4af2de0a2
Signed-off-by: Eric Biggers <ebiggers@google.com>
There are two tracepoints in dwc3_readl() and dwc3_writel().
This patch will export the tracepoints so that vendor modules
can use them.
Bug: 184920962
Signed-off-by: Ray Chi <raychi@google.com>
Change-Id: I1170d853be1fa1c47afbba133567b1996418d8e8
To use the tracepoint in kernel module, add EXPORT_TRACE_SYMBOL_GPL to
export the dwc3_ep_queue tracepoint.
Bug: 181736013
Change-Id: I211e747e10d232342cbaf877d7ad670c60e3ad0f
Signed-off-by: Oh Eomji <eomji.oh@samsung.com>
DWC3 controller soft reset is important operation for USB functionality.
In case when it fails, currently there is no failure log. Hence add
error log when core soft reset failed.
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 235863377
(cherry picked from commit 859bdc3595)
Change-Id: I60500f66af47d93cf9d60bdecab32e6dc48d4b7c
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
When watchdog or anr occur, we need to read
dev/binderfs/binder_logs/proc/pid or dev/binderfs/binder_logs/state
node to know the time-consuming information of the binder call.
We need to add the time-consuming information of binder transaction.
Bug: 190413570
Signed-off-by: zhang chuang <zhangchuang3@xiaomi.com>
Change-Id: I0423d4e821d5cd725a848584133dc7245cbc233a
(cherry picked from commit eabe9707f2)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[cmllamas: fix trivial merge conflict in vendor_hooks.c]
