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
Update Galaxy list of symbols with ones that are already in the .xml
file to manage symbols by used our modules
Bug: 173174399
Signed-off-by: Jeehong Kim <jhez.kim@samsung.com>
Change-Id: I0b26dff0c0075ba74fbbb3948f4e71c636f3a6cb
This patch adds to upload initial symbol list for Exynosauto SoC.
To find what has updated from GKI symbol easily, this list does not
include full list of symbol. So, nothing has added to GKI ABI symbols.
Bug: 172885440
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I41cc355687a5ba859ad601b8f1efdad13e52f20f
Add the following symbols to QCOM allowed-list:
-- __irq_set_handler
-- irq_set_handler_data
Bug: 172879351
Change-Id: I6869b60b4893a3f9447d0fb6e7977e0685477386
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Before 5.10-rc1, the upstream kernel blocked any compat calls into XFRM
code with EOPNOTSUPP, however Android kernels had been patching this
check out and made userspace match the 64-bit kernel netlink format
instead.
When the new XFRM_USER_COMPAT feature landed, it added a similar check
in two places which returns EOPNOTSUPP only if the XFRM_USER_COMPAT
feature is disabled, however that is currently always the case for
Android kernels and we do not want to filter these callers.
While we work to remove the userspace compatibility mess, disable the
filtering of compat calls when XFRM_USER_COMPAT is disabled. If the
XFRM_USER_COMPAT feature is enabled, nothing changes.
Bug: 163141236
Bug: 172541864
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Ifbea109070650dfcb4f93a3cc692c18a8d11ab44
Fix build-break for non GKI builds caused by using the
_rcuidle() variant of a vendor hook.
Fixes: bad091cc4b ("ANDROID: vendor_hooks: Add vendor hooks for
getting printk messages")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I0dffaf7e0df198a63578818f7c155671efe382b5
Fix this link error:
ERROR: modpost: "rcu_idle_enter" [drivers/acpi/processor.ko] undefined!
ERROR: modpost: "rcu_idle_exit" [drivers/acpi/processor.ko] undefined!
when CONFIG_ACPI_PROCESSOR is built as module. PeterZ says that in light
of ARM needing those soon too, they should simply be exported.
Link: https://lore.kernel.org/linux-pm/20200921103741.GC5901@zn.tnic/
Bug: 172034763
Change-Id: I26d516d11edbce673f52df6474f6695c5a1e2b07
(cherry picked from commit 3ad1c8ef083bef96ec922688966484be1039e6b5)
Fixes: 1fecfdbb7acc ("ACPI: processor: Take over RCU-idle for C3-BM idle")
Reported-by: Sven Joachim <svenjoac@gmx.de>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Paul E. McKenney <paulmckrcu@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
This problem will happened if handle_IPI is called from idle CPU.
Use trace_android_vh_ipi_stop_rcuidle() to fix this issue
Bug: 171683158
Change-Id: Ic49fc1ddc19a54415dec3f28b68f42fa258ffeea
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
The new android_rvh_nf_conn_alloc hook was not declared properly
so kernelci builds break if !CONFIG_ANDROID_VENDOR_HOOKS.
Fixes: 01435b2e91 ("ANDROID: GKI: net: add vendor hooks
for 'struct nf_conn' lifecycle")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I1208dc440836687a9c5621323ff1cf5a5bec862b
This is useful for debuggers, and is already the default for clang
(incidentally). Make sure it is on for all users/compilers.
Bug: 160841764
Change-Id: Ibb9a0c6900728d4cce3eccb57fb4c38268a89f24
Signed-off-by: Alistair Delva <adelva@google.com>
Indirect calls can happen when RCU is not watching, so we need to wake
it up again for the CFI shadow and __module_address. As these calls can
happen anywhere, use rcu_nmi_enter() similarly to kernel_text_address(),
and switch to rcu_read_lock_sched() for shadow access.
Bug: 169017431
Change-Id: Iebb857df898e644b4952a62d86fa5ff9852b5711
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
slab does this already, and I want to use this in a memory allocation
tracker in drm for stuff that's tied to the lifetime of a drm_device,
not the underlying struct device. Kinda like devres, but for drm.
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-2-daniel.vetter@ffwll.ch
(cherry picked from commit fd7cb5753ef49964ea9db5121c3fc9a4ec21ed8e)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: I10790befc779311a5f2ee441e4d073e51a5a7a62
Provide the user-to-kernel translator under XFRM_USER_COMPAT, that
creates for 32-bit xfrm-user message a 64-bit translation.
The translation is afterwards reused by xfrm_user code just as if
userspace had sent 64-bit message.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5106f4a8acff480e244300bc5097c0ad7048c3a2)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: If15999b86e4704b75307fbcc3d7f0c8d8bc89e7a
Currently nlmsg_unicast() is used by functions that dump structures that
can be different in size for compat tasks, see dump_one_state() and
dump_one_policy().
The following nlmsg_unicast() users exist today in xfrm:
Function | Message can be different
| in size on compat
-------------------------------------------|------------------------------
xfrm_get_spdinfo() | N
xfrm_get_sadinfo() | N
xfrm_get_sa() | Y
xfrm_alloc_userspi() | Y
xfrm_get_policy() | Y
xfrm_get_ae() | N
Besides, dump_one_state() and dump_one_policy() can be used by filtered
netlink dump for XFRM_MSG_GETSA, XFRM_MSG_GETPOLICY.
Just as for xfrm multicast, allocate frag_list for compat skb journey
down to recvmsg() which will give user the desired skb according to
syscall bitness.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5f3eea6b7e8f58cf5c8a9d4b9679dc19e9e67ba3)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Id1a606ddd9d7dfe73a448eeb252b1bfd8dbd2fcb
Provide the kernel-to-user translator under XFRM_USER_COMPAT, that
creates for 64-bit xfrm-user message a 32-bit translation and puts it
in skb's frag_list. net/compat.c layer provides MSG_CMSG_COMPAT to
decide if the message should be taken from skb or frag_list.
(used by wext-core which has also an ABI difference)
Kernel sends 64-bit xfrm messages to the userspace for:
- multicast (monitor events)
- netlink dumps
Wire up the translator to xfrm_nlmsg_multicast().
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5461fc0c8d9f23956b99f5907f69726a293ccb67)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Id8b59587d60feb9b9f0ce96be9d140d694573fe3
Add a skeleton for xfrm_compat module and provide API to register it in
xfrm_state.ko. struct xfrm_translator will have function pointers to
translate messages received from 32-bit userspace or to be sent to it
from 64-bit kernel.
module_get()/module_put() are used instead of rcu_read_lock() as the
module will vmalloc() memory for translation.
The new API is registered with xfrm_state module, not with xfrm_user as
the former needs translator for user_policy set by setsockopt() and
xfrm_user already uses functions from xfrm_state.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit c9e7c76d70fa50582ca96759829c93d0dd024662)
[adelva: Edited around some context changes]
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Ic825c6a0367fa192cc3f7af6b7d2682ef8f9d58b
The KMI was changed by several patches on October 31. Update the
generation number to notify all tools of this.
Bug: 161946584
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5d96ec5e4fe3ead9aedf19bdedf731b3ee28746a
Bump the userspace-facing value of SW_MAX from 0x10 to 0x3f, allowing
out-of-tree input drivers to use the increased space to send input codes
to userspace safely.
Note, there are no new reserved input code values, so any out-of-tree
numbers are not guaranteed to ever remain stable over time, but this
allows those drivers to work properly before they get merged upstream to
claim a reserved number.
Be aware that if you use this increased numberspace, your values will
change going forward to new Android and kernel versions, you have been
warned.
This gives us the free-space for 0x2f new values, which should be enough
for a few years grace-period :)
This changes the CRC of a number of functions, but no variable sizes
have changed:
Leaf changes summary: 36 artifacts changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 36 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
36 functions with some sub-type change:
[C] 'function cec_adapter* cec_allocate_adapter(const cec_adap_ops*, void*, const char*, u32, u8)' at cec-core.c:253:1 has some sub-type changes:
[C] 'function void cec_delete_adapter(cec_adapter*)' at cec-core.c:431:1 has some sub-type changes:
[C] 'function void cec_received_msg_ts(cec_adapter*, cec_msg*, ktime_t)' at cec-adap.c:1036:1 has some sub-type changes:
[C] 'function int cec_register_adapter(cec_adapter*, device*)' at cec-core.c:342:1 has some sub-type changes:
[C] 'function void cec_s_phys_addr(cec_adapter*, unsigned short int, bool)' at cec.h:279:1 has some sub-type changes:
[C] 'function void cec_s_phys_addr_from_edid(cec_adapter*, const edid*)' at cec-adap.c:1616:1 has some sub-type changes:
[C] 'function void cec_transmit_attempt_done_ts(cec_adapter*, u8, ktime_t)' at cec-adap.c:688:1 has some sub-type changes:
[C] 'function void cec_transmit_done_ts(cec_adapter*, u8, u8, u8, u8, u8, ktime_t)' at cec-adap.c:591:1 has some sub-type changes:
[C] 'function void cec_unregister_adapter(cec_adapter*)' at cec-core.c:412:1 has some sub-type changes:
[C] 'function input_dev* devm_input_allocate_device(device*)' at input.h:352:1 has some sub-type changes:
[C] 'function void input_alloc_absinfo(input_dev*)' at input.h:466:1 has some sub-type changes:
[C] 'function input_dev* input_allocate_device()' at input.h:351:1 has some sub-type changes:
[C] 'function void input_close_device(input_handle*)' at input.h:404:1 has some sub-type changes:
[C] 'function void input_event(input_dev*, unsigned int, unsigned int, int)' at input.h:411:1 has some sub-type changes:
[C] 'function int input_ff_create(input_dev*, unsigned int)' at input.h:555:1 has some sub-type changes:
[C] 'function int input_ff_create_memless(input_dev*, void*, int (input_dev*, void*, ff_effect*)*)' at input.h:564:1 has some sub-type changes:
[C] 'function void input_ff_destroy(input_dev*)' at input.h:556:1 has some sub-type changes:
[C] 'function void input_free_device(input_dev*)' at input.h:353:1 has some sub-type changes:
[C] 'function void input_mt_destroy_slots(input_dev*)' at mt.h:78:1 has some sub-type changes:
[C] 'function int input_mt_get_slot_by_key(input_dev*, int)' at mt.h:122:1 has some sub-type changes:
[C] 'function int input_mt_init_slots(input_dev*, unsigned int, unsigned int)' at mt.h:76:1 has some sub-type changes:
[C] 'function void input_mt_report_pointer_emulation(input_dev*, bool)' at mt.h:104:1 has some sub-type changes:
[C] 'function bool input_mt_report_slot_state(input_dev*, unsigned int, bool)' at mt.h💯1 has some sub-type changes:
[C] 'function void input_mt_sync_frame(input_dev*)' at mt.h:107:1 has some sub-type changes:
[C] 'function int input_open_device(input_handle*)' at input.h:403:1 has some sub-type changes:
[C] 'function int input_register_device(input_dev*)' at input.h:376:1 has some sub-type changes:
[C] 'function int input_register_handle(input_handle*)' at input.h:397:1 has some sub-type changes:
[C] 'function int input_register_handler(input_handler*)' at input.h:387:1 has some sub-type changes:
[C] 'function void input_set_abs_params(input_dev*, unsigned int, int, int, int, int)' at input.h:467:1 has some sub-type changes:
[C] 'function void input_set_capability(input_dev*, unsigned int, unsigned int)' at input.h:449:1 has some sub-type changes:
[C] 'function void input_unregister_device(input_dev*)' at input.h:377:1 has some sub-type changes:
[C] 'function void input_unregister_handle(input_handle*)' at input.h:398:1 has some sub-type changes:
[C] 'function void input_unregister_handler(input_handler*)' at input.h:388:1 has some sub-type changes:
[C] 'function int snd_jack_new(snd_card*, const char*, int, snd_jack**, bool, bool)' at jack.c:198:1 has some sub-type changes:
[C] 'function void snd_jack_report(snd_jack*, int)' at jack.c:340:1 has some sub-type changes:
[C] 'function int snd_jack_set_key(snd_jack*, snd_jack_types, int)' at jack.c:317:1 has some sub-type changes:
Bug: 170534200
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I28c8b49ac37f42d3ff89554e18fe042a44f5704a
Leaf changes summary: 3380 artifacts changed (154 filtered out)
Changed leaf types summary: 282 (120 filtered out) leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 3052 Changed (32 filtered out), 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 46 Changed (2 filtered out), 0 Added variable
3052 functions with some sub-type change:
46 Changed variables:
'struct dentry_operations at dcache.h:139:1' changed:
type size hasn't changed
1 data member insertion:
'void (const path*, path*)* dentry_operations::d_canonical_path', at offset 832 (in bits) at dcache.h:154:1
there are data member changes:
'u64 dentry_operations::android_kabi_reserved1' offset changed from 832 to 896 (in bits) (by +64 bits)
'u64 dentry_operations::android_kabi_reserved2' offset changed from 896 to 960 (in bits) (by +64 bits)
'u64 dentry_operations::android_kabi_reserved3' offset changed from 960 to 1024 (in bits) (by +64 bits)
'u64 dentry_operations::android_kabi_reserved4' offset changed from 1024 to 1088 (in bits) (by +64 bits)
3330 impacted interfaces
'struct inet_connection_sock at inet_connection_sock.h:87:1' changed (indirectly):
type size changed from 11840 to 11904 (in bits)
there are data member changes:
type 'struct inet_sock' of 'inet_connection_sock::icsk_inet' changed:
type size changed from 8320 to 8384 (in bits)
there are data member changes:
type 'struct sock' of 'inet_sock::sk' changed:
type size changed from 6656 to 6720 (in bits)
1 data member insertion:
'u64 sock::android_vendor_data1', at offset 6656 (in bits) at sock.h:526:1
422 impacted interfaces
'ipv6_pinfo* inet_sock::pinet6' offset changed from 6656 to 6720 (in bits) (by +64 bits)
'__be32 inet_sock::inet_saddr' offset changed from 6720 to 6784 (in bits) (by +64 bits)
'__s16 inet_sock::uc_ttl' offset changed from 6752 to 6816 (in bits) (by +64 bits)
'__u16 inet_sock::cmsg_flags' offset changed from 6768 to 6832 (in bits) (by +64 bits)
'__be16 inet_sock::inet_sport' offset changed from 6784 to 6848 (in bits) (by +64 bits)
'__u16 inet_sock::inet_id' offset changed from 6800 to 6864 (in bits) (by +64 bits)
'ip_options_rcu* inet_sock::inet_opt' offset changed from 6848 to 6912 (in bits) (by +64 bits)
'int inet_sock::rx_dst_ifindex' offset changed from 6912 to 6976 (in bits) (by +64 bits)
'__u8 inet_sock::tos' offset changed from 6944 to 7008 (in bits) (by +64 bits)
'__u8 inet_sock::min_ttl' offset changed from 6952 to 7016 (in bits) (by +64 bits)
'__u8 inet_sock::mc_ttl' offset changed from 6960 to 7024 (in bits) (by +64 bits)
'__u8 inet_sock::pmtudisc' offset changed from 6968 to 7032 (in bits) (by +64 bits)
'__u8 inet_sock::nodefrag' offset changed from 6976 to 7040 (in bits) (by +64 bits)
'__u8 inet_sock::rcv_tos' offset changed from 6992 to 7056 (in bits) (by +64 bits)
'__u8 inet_sock::convert_csum' offset changed from 7000 to 7064 (in bits) (by +64 bits)
'int inet_sock::uc_index' offset changed from 7008 to 7072 (in bits) (by +64 bits)
'int inet_sock::mc_index' offset changed from 7040 to 7104 (in bits) (by +64 bits)
'__be32 inet_sock::mc_addr' offset changed from 7072 to 7136 (in bits) (by +64 bits)
'ip_mc_socklist* inet_sock::mc_list' offset changed from 7104 to 7168 (in bits) (by +64 bits)
'inet_cork_full inet_sock::cork' offset changed from 7168 to 7232 (in bits) (by +64 bits)
2 impacted interfaces
'request_sock_queue inet_connection_sock::icsk_accept_queue' offset changed from 8320 to 8384 (in bits) (by +64 bits)
'inet_bind_bucket* inet_connection_sock::icsk_bind_hash' offset changed from 8960 to 9024 (in bits) (by +64 bits)
'unsigned long int inet_connection_sock::icsk_timeout' offset changed from 9024 to 9088 (in bits) (by +64 bits)
'timer_list inet_connection_sock::icsk_retransmit_timer' offset changed from 9088 to 9152 (in bits) (by +64 bits)
'timer_list inet_connection_sock::icsk_delack_timer' offset changed from 9536 to 9600 (in bits) (by +64 bits)
'__u32 inet_connection_sock::icsk_rto' offset changed from 9984 to 10048 (in bits) (by +64 bits)
'__u32 inet_connection_sock::icsk_pmtu_cookie' offset changed from 10016 to 10080 (in bits) (by +64 bits)
'const tcp_congestion_ops* inet_connection_sock::icsk_ca_ops' offset changed from 10048 to 10112 (in bits) (by +64 bits)
'const inet_connection_sock_af_ops* inet_connection_sock::icsk_af_ops' offset changed from 10112 to 10176 (in bits) (by +64 bits)
'const tcp_ulp_ops* inet_connection_sock::icsk_ulp_ops' offset changed from 10176 to 10240 (in bits) (by +64 bits)
'void* inet_connection_sock::icsk_ulp_data' offset changed from 10240 to 10304 (in bits) (by +64 bits)
'void (sock*, typedef u32)* inet_connection_sock::icsk_clean_acked' offset changed from 10304 to 10368 (in bits) (by +64 bits)
'hlist_node inet_connection_sock::icsk_listen_portaddr_node' offset changed from 10368 to 10432 (in bits) (by +64 bits)
'unsigned int (sock*, typedef u32)* inet_connection_sock::icsk_sync_mss' offset changed from 10496 to 10560 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_ca_dst_locked' offset changed from 10560 to 10624 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_retransmits' offset changed from 10568 to 10632 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_pending' offset changed from 10576 to 10640 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_backoff' offset changed from 10584 to 10648 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_syn_retries' offset changed from 10592 to 10656 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_probes_out' offset changed from 10600 to 10664 (in bits) (by +64 bits)
'__u16 inet_connection_sock::icsk_ext_hdr_len' offset changed from 10608 to 10672 (in bits) (by +64 bits)
'struct {__u8 pending; __u8 quick; __u8 pingpong; __u8 blocked; __u32 ato; unsigned long int timeout; __u32 lrcvtime; __u16 last_seg_size; __u16 rcv_mss;} inet_connection_sock::icsk_ack' offset changed from 10624 to 10688 (in bits) (by +64 bits)
'struct {int enabled; int search_high; int search_low; int probe_size; u32 probe_timestamp;} inet_connection_sock::icsk_mtup' offset changed from 10816 to 10880 (in bits) (by +64 bits)
'u32 inet_connection_sock::icsk_user_timeout' offset changed from 10976 to 11040 (in bits) (by +64 bits)
'u64 inet_connection_sock::icsk_ca_priv[13]' offset changed from 11008 to 11072 (in bits) (by +64 bits)
2 impacted interfaces
'struct module at module.h:354:1' changed:
type size hasn't changed
1 data member insertion:
'bool module::using_gplonly_symbols', at offset 2688 (in bits) at module.h:385:1
there are data member changes:
anonymous data member union {module_kabi_preserve_1 m1; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide201; union {};} at offset 6848 (in bits) became data member 'u64 module::android_kabi_reserved1'
'bool module::sig_ok' offset changed from 2688 to 2696 (in bits) (by +8 bits)
'bool module::async_probe_requested' offset changed from 2696 to 2704 (in bits) (by +8 bits)
3330 impacted interfaces
'struct nf_conn at nf_conntrack.h:58:1' changed:
type size changed from 2048 to 2240 (in bits)
3 data member insertions:
'u64 nf_conn::android_kabi_reserved1', at offset 2048 (in bits) at nf_conntrack.h:111:1
'u64 nf_conn::android_kabi_reserved2', at offset 2112 (in bits) at nf_conntrack.h:112:1
'u64 nf_conn::android_vendor_data1', at offset 2176 (in bits) at nf_conntrack.h:114:1
422 impacted interfaces
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iec13bb17711b4337d6810b6eac45f755497c6ed8
Some vendors want to add things to 'struct skb_shared_info', so give
them an array to place their data.
Bug: 171013716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ifaa5942550794b747e9624124c785a0bc85dfe17
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: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I67a9be129150690f8c1961accf7d5cdf0d5d50cc
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: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I303d237116f2f1ef6035af98f00436278ec1c23b
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: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9ed93e8bffef3cd8fbde4d62fc14596764a85304
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: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8fdea13b185fba26010e2a2bf397d7982a8fa16e
Allows FUSE to report to inotify that it is acting
as a layered filesystem. The userspace component
returns a string representing the location of the
underlying file. If the string cannot be resolved
into a path, the top level path is returned instead.
Bug: 23904372
Bug: 171780975
Test: inotify on cuttlefish
Change-Id: Iabdca0bbedfbff59e9c820c58636a68ef9683d9f
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Alessio Balsini <balsini@google.com>
Inotify does not currently know when a filesystem
is acting as a wrapper around another fs. This means
that inotify watchers will miss any modifications to
the base file, as well as any made in a separate
stacked fs that points to the same file.
d_canonical_path solves this problem by allowing the fs
to map a dentry to a path in the lower fs. Inotify
can use it to find the appropriate place to watch to
be informed of all changes to a file.
Test: HiKey/X15 + Pie + android-mainline,
and HiKey + AOSP Maser + android-mainline,
directories under /sdcard created,
output of mount is right,
CTS test collecting device infor works
Bug: 171780975
Change-Id: I09563baffad1711a045e45c1bd0bd8713c2cc0b6
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[astrachan: Folded 34df4102216e ("ANDROID: fsnotify: Notify lower fs of
open") into this patch]
Signed-off-by: Alistair Strachan <astrachan@google.com>
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Signed-off-by: Alessio Balsini <balsini@google.com>
'struct fscrypt_operations' is only used by fs/crypto/ (which is always
built-in) and by three filesystems (which are either built-in to GKI, in
the case of ext4 and f2fs, or aren't supported by Android, in the case
of ubifs). The only way a loadable module could use fscrypt_operations
is if the module were a filesystem that used fs/crypto/, which isn't
possible since KMI symbol list doesn't include anything in fs/crypto/.
However, any change to struct fscrypt_operations changes the symbol CRC
of most of the KMI functions exported by any files fs/*.c that include
<linux/fscrypt.h>. This is because the definition of fscrypt_operations
is visible to them, and in principle it's possible to get to
fscrypt_operations from most VFS structs (e.g. inode->i_sb->s_cop), even
though there's no reason to do so outside the crypto code.
Work around this by putting the definition of struct fscrypt_operations
behind #ifdef FSCRYPT_NEED_OPS, and only defining this in the files that
actually need the definition. (It could be moved into a separate header
instead, but this way keeps the diff from upstream smaller.)
This will cause a one-time CRC change of all the affected KMI functions,
but afterwards any changes to fscrypt_operations won't "break the KMI".
Bug: 170265596
Test: re-generated the ABI, changed struct fscrypt_operations (and
struct fscrypt_info as well, just in case), re-generated the ABI
again, and verified it didn't change.
Change-Id: Ib5dd49550aec81a64b3d6077a0aeb5747be908ff
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit db96212bde as it is
not needed if we are able to update the Android KABI.
Fixes: db96212bde ("ANDROID: GKI: fix ABI breakage in module.h")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic6f4f449e554240457e1f94c49b53fa158f0d00e
Update Galaxy list of symbols with ones that are already in the .xml
file to make further patches much smaller and easier to review.
Bug: 171954519
Cc: Jeehong Kim <jhez.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic30a89e6254cddb7669a473e06263d2aef8f9703
DYNAMIC_MINORS value has been set to 64.
Due to this reason, we are facing a module loading fail problem of
device driver like below.
[ 45.712771] pdic_misc_init - return error : -16
We need to increase this value for registering more misc devices.
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Bug: 171370390
Link: https://lore.kernel.org/lkml/20201029070552.GA3062343@kroah.com/
Change-Id: I04ab486ce7674dde3118506c3d783f0e4e211bac
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
