Adds ANDROID_OEM_DATA and ANDROID_OEM_DATA_ARRAY macros
to add OEM-specific fields to kernel data structures
to enable value-added features implemented in vendor modules.
Fields defined with these macros must not be used by
SoC vendors who must use the ANDROID_VENDOR_DATA* macros
to add vendor fields.
Bug: 156285741
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I93a8a182a17854cc4f0a86835e833bf9b00ea0b8
Add support for matching the new PMUs. For now, this just wires them up
as generic PMUv3 such that people writing DTs for new SoCs can do the
right thing, and at least have architectural and raw events be usable.
We can come back and fill in event maps for sysfs and/or perf tools at
a later date.
Change-Id: I0c0839f6fff87934e97708176f783514bdee7f58
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 29cc4ceeac1274ab8363a11b81ebd99f3b023985
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf)
Bug: 176519087
Link: https://lore.kernel.org/linux-arm-kernel/20200225190125.GA2781@bogus/T/#mdaa003324f263cc9541d412f7ba6b9519d6603fe
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Change-Id: I335d4c9a9bfcfcfeb18b096cfe660209d3b62820
xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and
drop_endpoint() to handle its own sw bandwidth management.
It stores bandwidth data into an internal table every time
add_endpoint() is called, and drops those in drop_endpoint().
But when bandwidth allocation fails at one endpoint, all earlier
allocation from the same interface could still remain at the table.
This patch moves bandwidth management codes to check_bandwidth() and
reset_bandwidth() path. To do so, this patch also adds those functions
to xhci_driver_overrides and lets mtk-xhci to release all failed
endpoints in reset_bandwidth() path.
Fixes: 08e469de87 ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT")
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/20210113180444.v6.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid
Cc: stable <stable@vger.kernel.org>
(cherry picked from commit 1d69f9d901ef14d81c3b004e3282b8cc7b456280
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I211875090c3b8080292a415fdb182fd4b8ac9729
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We add a vendor hook for util to freq calculation in schedutil,
so we need to do corresponding change for energy calculation.
android_vh_em_pd_energy
adjust energy calculation
Bug: 178021064
Signed-off-by: Yun Hsiang <yun.hsiang@mediatek.com>
Change-Id: Iae772cf07881602eea3f27aeb75fba753e7c2635
Currently, the frequency is calculated by max freq * 1.25 * util / max cap.
Add a vendor hook to adjust the frequency when the calculation
overestimate.
android_vh_map_util_freq
adjust util to freq calculation
Bug: 177845438
Signed-off-by: Yun Hsiang <yun.hsiang@mediatek.com>
Change-Id: I9aa9079f00af7d3380b19f2fe21b75cddd107d15
In the Scudo memory allocator [1] we would like to be able to detect
use-after-free vulnerabilities involving large allocations by issuing
mprotect(PROT_NONE) on the memory region used for the allocation when it
is deallocated. Later on, after the memory region has been "quarantined"
for a sufficient period of time we would like to be able to use it for
another allocation by issuing mprotect(PROT_READ|PROT_WRITE).
Before this patch, after removing the write protection, any writes to the
memory region would result in page faults and entering the copy-on-write
code path, even in the usual case where the pages are only referenced by a
single PTE, harming performance unnecessarily. Make it so that any pages
in anonymous mappings that are only referenced by a single PTE are
immediately made writable during the mprotect so that we can avoid the
page faults.
This program shows the critical syscall sequence that we intend to use in
the allocator:
#include <string.h>
#include <sys/mman.h>
enum { kSize = 131072 };
int main(int argc, char **argv) {
char *addr = (char *)mmap(0, kSize, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
for (int i = 0; i != 100000; ++i) {
memset(addr, i, kSize);
mprotect((void *)addr, kSize, PROT_NONE);
mprotect((void *)addr, kSize, PROT_READ | PROT_WRITE);
}
}
The effect of this patch on the above program was measured on a
DragonBoard 845c by taking the median real time execution time of 10 runs.
Before: 3.19s
After: 0.79s
The effect was also measured using one of the microbenchmarks that
we normally use to benchmark the allocator [2], after modifying it
to make the appropriate mprotect calls [3]. With an allocation size
of 131072 bytes to trigger the allocator's "large allocation" code
path the per-iteration time was measured as follows:
Before: 33364ns
After: 6886ns
This patch means that we do more work during the mprotect call itself
in exchange for less work when the pages are accessed. In the worst
case, the pages are not accessed at all. The effect of this patch in
such cases was measured using the following program:
#include <string.h>
#include <sys/mman.h>
enum { kSize = 131072 };
int main(int argc, char **argv) {
char *addr = (char *)mmap(0, kSize, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
memset(addr, 1, kSize);
for (int i = 0; i != 100000; ++i) {
#ifdef PAGE_FAULT
memset(addr + (i * 4096) % kSize, i, 4096);
#endif
mprotect((void *)addr, kSize, PROT_NONE);
mprotect((void *)addr, kSize, PROT_READ | PROT_WRITE);
}
}
With PAGE_FAULT undefined (0 pages touched after removing write
protection) the median real time execution time of 100 runs was measured
as follows:
Before: 0.325928s
After: 0.365493s
With PAGE_FAULT defined (1 page touched) the measurements were
as follows:
Before: 0.441516s
After: 0.380251s
So it seems that even with a single page fault the new approach is faster.
I saw similar results if I adjusted the programs to use a larger mapping
size. With kSize = 1048576 I get these numbers with PAGE_FAULT undefined:
Before: 1.563078s
After: 1.607476s
i.e. around 3%.
And these with PAGE_FAULT defined:
Before: 1.684663s
After: 1.683272s
i.e. about the same.
What I think we may conclude from these results is that for smaller
mappings the advantage of the previous approach, although measurable, is
wiped out by a single page fault. I think we may expect that there should
be at least one access resulting in a page fault (under the previous
approach) after making the pages writable, since the program presumably
made the pages writable for a reason.
For larger mappings we may guesstimate that the new approach wins if the
density of future page faults is > 0.4%. But for the mappings that are
large enough for density to matter (not just the absolute number of page
faults) it doesn't seem like the increase in mprotect latency would be
very large relative to the total mprotect execution time.
Link: https://lkml.kernel.org/r/20201230004134.1185017-1-pcc@google.com
Link: https://linux-review.googlesource.com/id/I98d75ef90e20330c578871c87494d64b1df3f1b8
Link: [1] https://source.android.com/devices/tech/debug/scudo
Link: [2] https://cs.android.com/android/platform/superproject/+/master:bionic/benchmarks/stdlib_benchmark.cpp;l=53;drc=e8693e78711e8f45ccd2b610e4dbe0b94d551cc9
Link: [3] https://github.com/pcc/llvm-project/commit/scudo-mprotect-secondary
Signed-off-by: Peter Collingbourne <pcc@google.com>
[pcc: resolved minor conflict]
Cc: Kostya Kortchinsky <kostyak@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit 2a9e75c907fa2de626d77dd4051fc038f0dbaf52
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 135772972
Change-Id: I98d75ef90e20330c578871c87494d64b1df3f1b8
Vendor hooks required explicitly defining macros or inline functions
to handle the non-GKI build case (!CONFIG_ANDROID_VENDOR_HOOKS). Added
support for generating them automatically so the macros are no longer
required.
Both models are now supported so we can transition.
Bug: 177416721
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I01acc389d315a5d509b0c48116854342a42e1058
If get_acc_dev() fails to obtain a reference to the current device,
acc_disconnect() will attempt to put_acc_dev() with the resulting NULL
pointer, leading to a crash:
| Unable to handle kernel NULL pointer dereference at virtual address 00000074
| [...]
| [<c0abb288>] (acc_disconnect) from [<c0a91a38>] (android_disconnect+0x1c/0x7c)
| [<c0a91a38>] (android_disconnect) from [<c0a93958>] (usb_gadget_udc_reset+0x10/0x34)
| [<c0a93958>] (usb_gadget_udc_reset) from [<c0a4a9c4>] (dwc3_gadget_reset_interrupt+0x88/0x4fc)
| [<c0a4a9c4>] (dwc3_gadget_reset_interrupt) from [<c0a491f8>] (dwc3_process_event_buf+0x60/0x3e4)
| [<c0a491f8>] (dwc3_process_event_buf) from [<c0a49180>] (dwc3_thread_interrupt+0x24/0x3c)
| [<c0a49180>] (dwc3_thread_interrupt) from [<c02b3404>] (irq_thread_fn+0x1c/0x58)
| [<c02b3404>] (irq_thread_fn) from [<c02b326c>] (irq_thread+0x1ec/0x2f4)
| [<c02b326c>] (irq_thread) from [<c0260804>] (kthread+0x1a8/0x1ac)
| [<c0260804>] (kthread) from [<c0200138>] (ret_from_fork+0x14/0x3c)
Follow the pattern used elsewhere, and return early if we fail to obtain
a reference.
Bug: 173789633
Reported-by: YongQin Liu <yongqin.liu@linaro.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I37a2bff5bc1b6b8269788d08191181763bf0e896
Signed-off-by: Giuliano Procida <gprocida@google.com>
Using bitfields for shared variables is a "bad idea", as they require
a non-atomic read-modify-write to be generated by the compiler, which can
cause updates to unrelated bits in the same word to disappear.
Ensure the 'online' and 'disconnected' members of 'struct acc_dev' are
placed in separate variables by declaring them each as 'int'.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ia6031d82a764e83b2cc3502fbe5fb273511da752
Signed-off-by: Giuliano Procida <gprocida@google.com>
Tearing down and freeing the 'acc_dev' structure when there is
potentially asynchronous work queued involving its member fields is
likely to lead to use-after-free issues.
Cancel any pending work before freeing the structure.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I68a91274aea18034637b738d558d043ac74fadf4
Signed-off-by: Giuliano Procida <gprocida@google.com>
If acc_setup() is called when there is already an allocated instance,
misc_register() will fail but the error path leaves a dangling pointer
to freed memory in the global 'acc_dev' state.
Fix this by ensuring that the refcount is zero before we start, and then
using a cmpxchg() from NULL to serialise any concurrent initialisers.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I2c26289dcce7dbc493964516c49b05d04aaa6839
Signed-off-by: Giuliano Procida <gprocida@google.com>
acc_release() attempts to synchronise with acc_open() using an atomic
'open_excl' member in 'struct acc_dev'. Unfortunately, acc_release()
prematurely resets this atomic variable to zero, meaning there is a
potential race on 'dev->disconnected':
acc_open() acc_release()
atomic_xchg(open_excl), 0)
atomic_xchg(open_excl, 1)
dev->disconnected = 0; dev->disconnected = 1;
Fix the race by ensuring that the 'disconnected' field is written
before clearing 'open_excl' in acc_release().
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ib9a21f2305f6d70de3e760da62dbfdd66889200a
Signed-off-by: Giuliano Procida <gprocida@google.com>
Add refcounting to track the lifetime of the global 'acc_dev' structure,
as the underlying function directories can be removed while references
still exist to the dev node.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I248408e890d01167706c329146d63b64a6456df6
Signed-off-by: Giuliano Procida <gprocida@google.com>
The '_acc_dev' global variable is a fancy use-after-free factory. Wrap
it in some get()/put() functions in preparation for introducing some
refcounting.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I4c839627648c209341a81efa0c001c8d71b878d4
Signed-off-by: Giuliano Procida <gprocida@google.com>
acc_alloc_inst() assigns to a local 'dev' variable, but then never uses
it. Remove the redundant assignment, and the local variable along with
it.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ide9c2e89fb12b846eb8739b302d1b742fc7eb6b5
Signed-off-by: Giuliano Procida <gprocida@google.com>
Remove some useless print statements, as they can trivially be used to
spam the console and don't report anything meaningful.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I28052010fc3ec033a2c99efeb3f6c919d54d75c2
Signed-off-by: Giuliano Procida <gprocida@google.com>
Neither acc_gadget_bind() nor acc_gadget_register_driver() exist, so
remove the stale comments that refer to them.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: If396ba3bcac3ca59c48e5a5faa0a8520534ed625
Signed-off-by: Giuliano Procida <gprocida@google.com>
In case of poweroff charging mode, accessory function instance
is not created and due to this, _acc_dev will be NULL. If target
is connected to Accessory dock in poweroff charging mode, there
is a chance dev pointer is accessed, which is NULL. Hence add a
check before processing control request and return error if it is
NULL.
Bug: 141002587
Change-Id: I4f1deb9d764b8c0bd1d7837cbc43a2933167f568
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Giuliano Procida <gprocida@google.com>
pte_accessible() is used by ptep_clear_flush() to figure out whether TLB
invalidation is necessary when unmapping pages for reclaim. Although our
implementation is correct according to the architecture, returning true
only for valid, young ptes in the absence of racing page-table
modifications, this is in fact flawed due to lazy invalidation of old
ptes in ptep_clear_flush_young() where we elide the expensive DSB
instruction for completing the TLB invalidation.
Rather than penalise the aging path, adjust pte_accessible() to return
true for any valid pte, even if the access flag is cleared.
Bug: 176475096
Change-Id: Ifd7919b4e9b790a94802b0115f93a9a260757036
Cc: <stable@vger.kernel.org>
Fixes: 76c714be0e ("arm64: pgtable: implement pte_accessible()")
Reported-by: Yu Zhao <yuzhao@google.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Reviewed-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20201120143557.6715-2-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 07509e10dcc77627f8b6a57381e878fe269958d3)
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
This patch is for updating GKI allowed symbol list without adding any
new symbol. Next patch will introduce newly added symbols for Exynosauto
SoC GKI vendor modules. To avoid unnecessary symbols, this patch also
adds "preserved by --additions-only" even though we don't need them
anymore.
Bug: 176138611
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I9fa9eb313ef1e2aeb8c853bae1c8cde18cdd9188
f_accessory: fix CTS test stuck since CTS 9.0.
- Refine acc_read() process.
The data length that user (test program) wants to read is different
from they really requested. This will cause the test flow stuck on the
2nd or the 3rd transfers in accessory test.
(By connecting 2 phones with CtsVerifier.apk and
CtsVerifierUSBCompanion.apk installed.)
Bug: 174729307
Change-Id: I5367c8075ed37534e8bed94b60cc79135ae5aebc
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
This patch is the first trial to upload GKI symbol list for running
android as VM on type1 hypervisor. Unlike traditional device driver,
para-virtualized drivers for hypervisor tend to use more core symbols.
- ioremap_cache: to skip cached mapping for io remap
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 1 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
1 Added function:
[A] 'function void* ioremap_cache(long long unsigned int, unsigned long int)'
Bug: 175289068
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: Ia3f0073065ad2da481cce10dd882d7de093b1de3
This patch is for updating GKI allowed symbol list without adding a new
symbol. Next patch will introduce newly added symbols for Exynosauto
SoC GKI vendor modules.
Bug: 175289068
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I035373ee8f980cd5c03c967d5d2b684150e7fc74
This symbol is needed for certain vendor modules which cannot rely on
only the sysfs interface for uclamp alone.
Bug: 170697030
Signed-off-by: J. Avila <elavila@google.com>
Change-Id: Ic904ade83a45d259cfc95501e6b81e6c5a0e90a0
(cherry picked from commit 0edac9cb95fb2fa292a4b25ac77b125cde28b674)
NULL pointer dereference is observed while exporting the dmabuf but
failed to allocate the 'struct file' which results into the dropping
of the allocated dentry corresponding to this file in the dmabuf fs,
which is ending up in dma_buf_release() and accessing the
uninitialzed dentry->d_fsdata.
Call stack on 5.4 is below:
dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88
__dentry_kill+0x294/0x31c fs/dcache.c:584
dentry_kill fs/dcache.c:673 [inline]
dput+0x250/0x380 fs/dcache.c:859
path_put+0x24/0x40 fs/namei.c:485
alloc_file_pseudo+0x1a4/0x200
fs/file_table.c:235
dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline]
dma_buf_export+0x25c/0x3ec
drivers/dma-buf/dma-buf.c:585
Fix this by checking for the valid pointer in the dentry->d_fsdata.
cherry picked from commit 19a508bd1ad8e444de86873bf2f2b2ab8edd6552
Bug: 175512919
Link: https://patchwork.freedesktop.org/patch/391319/
Change-Id: I3856a387d1902fd2b39b016e81283f082089131c
Cc: <stable@vger.kernel.org> [5.7+]
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Export memblock_end_of_DRAM() so that module drivers can know
the physical end address of memory blocks that system booted with.
Bug: 174547201
Change-Id: Ib0c90b736f16d1abbf47d4f3288443c35f9e17b4
Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
A number of kthread-related functions indirectly take task_struct->pi_lock
while holding worker->lock in the call chain like this:
spin_lock(&worker->lock)
kthread_insert_work
wake_up_process
try_to_wake_up
raw_spin_lock_irqsave(&p->pi_lock, flags)
This lock dependency exists whenever kthread_insert_work is called either
directly or indirectly via __kthread_queue_delayed_work in the following
functions:
kthread_queue_work
kthread_delayed_work_timer_fn
kthread_queue_delayed_work
kthread_flush_work
kthread_mod_delayed_work
This creates possibilities for circular dependencies like the one reported
at [1]. Break this lock dependency by moving task wakeup after worker->lock
has been released.
[1]: https://lore.kernel.org/lkml/CAJuCfpG4NkhpQvZjgXZ_3gm6Hf1QgN_eUOQ8iX9Cv1k9whLwSQ@mail.gmail.com
Reported-by: Ke Wang <ke.wang@unisoc.com>
Reported-by: Shakeel Butt <shakeelb@google.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Shakeel Butt <shakeelb@google.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Link: https://lkml.org/lkml/2020/5/4/1148
Cherry picked instead of commit 461daba06bdcb9c7a3f92b9bbd110e1f7d093ffc
as an alternative solution for the lockdep error that does not break KMI.
Bug: 174875976
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I2478847f66c85dca953846cd77955928d690c97c
commit bce1305c0ece3dc549663605e567655dd701752c upstream.
It appears that a ReportSize value of zero is legal, even if a bit
non-sensical. Most of the HID code seems to handle that gracefully,
except when computing the total size in bytes. When fed as input to
memset, this leads to some funky outcomes.
Detect the corner case and correctly compute the size.
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bce1305c0ece3dc549663605e567655dd701752c)
Change-Id: I5ab5febc22b8d5d8c5d398c3ff93f73cb3c90e05
Signed-off-by: Todd Kjos <tkjos@google.com>
commit 35556bed836f8dc07ac55f69c8d17dce3e7f0e25 upstream.
When calling into hid_map_usage(), the passed event code is
blindly stored as is, even if it doesn't fit in the associated bitmap.
This event code can come from a variety of sources, including devices
masquerading as input devices, only a bit more "programmable".
Instead of taking the event code at face value, check that it actually
fits the corresponding bitmap, and if it doesn't:
- spit out a warning so that we know which device is acting up
- NULLify the bitmap pointer so that we catch unexpected uses
Code paths that can make use of untrusted inputs can now check
that the mapping was indeed correct and bail out if not.
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 35556bed836f8dc07ac55f69c8d17dce3e7f0e25)
Change-Id: Ie4dc11f43ed1eae2d09feaf9cff17d6d16cf9987
Signed-off-by: Todd Kjos <tkjos@google.com>
When merging configuration fragments, it might be of interest to
identify mismatches (redefinitions) programmatically. Hence add the
option -s (strict mode) to instruct merge_config.sh to bail out in
case any redefinition has been detected.
With strict mode, warnings are emitted as before, but the script
terminates with rc=1. If -y is set to define "builtin having
precedence over modules", fragments are still allowed to set =m (while
the base config has =y). Strict mode will tolerate that as demotions
from =y to =m are ignored when setting -y.
Bug: 174454795
Link: https://lore.kernel.org/linux-kbuild/20201202151238.3776616-1-maennich@google.com/
Cc: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Ib982a87811956e48b718a15680f06474a39dc19d
(cherry picked from commit 32164038495558fbc6d47f36033bac3014f53b8e)
After LLVM rG9e33c096476a ("[ELF] Keep orphan section names
(.rodata.foo .text.foo) unchanged if !hasSectionsCommand"), LLD splits
compound literals to separate sections with -fdata-sections, which
it always enables with LTO. Merge these sections to allow LLVM to be
upgraded.
Bug: 174047799
Change-Id: I858c5fcc48283d5528c1d3e2b2d7a3c72f9e03d6
Link: https://github.com/ClangBuiltLinux/linux/issues/958
Suggested-by: Danny Lin <danny@kdrag0n.dev>
Suggested-by: Fangrui Song <maskray@google.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Update the android/abi_gki_aarch64_qcom with recent symbol additions.
Simple change and no need to update the .xml file, as no new symbol
addition.
Bug: 174275677
Signed-off-by: Archana Sriram <apsrir@codeaurora.org>
Signed-off-by: Kamal Agrawal <kamaagra@codeaurora.org>
Change-Id: Ic96fc5d11ab8d21fadbf85658e374e06dde14d0f
