Commit f7128c7533 ("ANDROID: sched: Add vendor hooks for update_topology")
was intended for the modules to get informed when topology
initialization had completed.
However that is not sufficient, the module could be insmoded after
the hook was invoked.
For such situations create a flag for modules to detect that topology
initialization is completed.
Bug: 187234873
Change-Id: I2ed4dff9c921e3de67dd11049c80f38e3c1a64fd
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
With CONFIG_LTO_CLANG_FULL, LLVM drops all CFI jump table symbols
from vmlinux, which doesn't affect kernel functionality, but can
make stack traces and other kernel output that prints out jump
table addresses harder to read.
This change works around the issue for now by adding a script that
tells kallsyms about the missing jump table symbols, even though
they don't actually exist in the symbol table, and generates a
linker script to add the missing symbols to kernel modules.
Bug: 186152035
Bug: 187415564
Change-Id: Ic3c51751c756f2f5fb2a31229e16c3397eb6e666
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Revert most of commit 25a6f60b717d ("BACKPORT: bio: limit bio max size")
because it has been reported to cause data corruption and because it has
been reverted upstream. See also
https://lore.kernel.org/linux-block/1620571445.2k94orj8ee.none@localhost/T/#t
Cc: Changheun Lee <nanich.lee@samsung.com>
Cc: Jaegeuk Kim <jaegeuk@google.com>
Bug: 182716953
Change-Id: I79bf39d1d1a0c13cb30ff4b0f1da2b43e1c817f0
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Currently, most of the thermal_zones are IRQ capable and they do not need
to be updated while resuming. To improve the system performance and reduce
the resume time. Add a vendor function to check if the thermal_zone is
not IRQ capable and needs to be updated.
Bug: 170905417
Test: boot and vendor function worked properly.
Change-Id: I9389985bba29b551a7a20b55e1ed26b6c4da9b3d
Signed-off-by: David Chao <davidchao@google.com>
Currently, when reading the following properties under
ucsi-source-psy-*, src_pdos array is accessed but it only checks
for the condition num_pdos > 0.
- voltage_max
- voltage_now
- current_max
In the case if a PPM passes num_pdos greater than UCSI_MAX_PDOS,
an OOB access can be made. Fix it by checking the upper bound for
src_pdos which is UCSI_MAX_PDOS.
This issue is detected by enabling UBSAN.
Bug: 186400956
Fixes: 992a60ed0d ("usb: typec: ucsi: register with power_supply class")
Fixes: 4dbc6a4ef0 ("usb: typec: ucsi: save power data objects in PD mode")
Change-Id: Id0aca674208b23329be089671cba873baca930cf
Signed-off-by: Subbaraman Narayanamurthy <quic_subbaram@quicinc.com>
Not_Supported Message is acceptable in VDM AMS. Redirect the VDM state
machine to VDM_STATE_DONE when receiving Not_Supported and finish the
VDM AMS.
Also, after the loop in vdm_state_machine_work, add more conditions of
VDM states to clear the vdm_sm_running flag because those are all
stopping states when leaving the loop.
In addition, finish the VDM AMS if the port partner responds BUSY.
Fixes: 8dea75e113 ("usb: typec: tcpm: Protocol Error handling")
Fixes: 8d3a0578ad ("usb: typec: tcpm: Respond Wait if VDM state machine is running")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Kyle Tso <kyletso@google.com>
Link: https://lore.kernel.org/r/20210507062300.1945009-3-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f1fbd950b5https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia52ad69f054b2211924ec3815b5a3d2cc09d8b88
When extcon is used in combination with dwc3, it is assumed that the dwc3
registers are untouched and as such are only configured if VBUS is valid
or ID is tied to ground.
In case VBUS is not valid or ID is floating, the registers are not
configured as such during driver initialization, causing a wrong
default state during boot.
If the registers are not in a default state, because they are for
instance touched by a boot loader, this can cause for a kernel error.
Signed-off-by: Marcel Hamer <marcel@solidxs.se>
Link: https://lore.kernel.org/r/20210427122118.1948340-1-marcel@solidxs.se
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e17b02d497https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic460a111f59e5a4fd77db0402fb297e53bbc1d9e
device_for_each_child_node() bumps a reference counting of a returned variable.
We have to balance it whenever we return to the caller.
Fixes: c1b0bc2dab ("usb: typec: Add support for UCSI interface")
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210504222337.3151726-1-andy.shevchenko@gmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b9a0866a5bhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7c18e76218fa750ccb62839689e4e4f469a8913e
If an error is received when issuing a start or update transfer
command, the error handler will stop all active requests (including
the current USB request), and call dwc3_gadget_giveback() to notify
function drivers of the requests which have been stopped. Avoid
returning an error for kick transfer during EP queue, to remove
duplicate cleanup operations on the request being queued.
Fixes: 8d99087c2d ("usb: dwc3: gadget: Properly handle failed kick_transfer")
cc: stable@vger.kernel.org
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1620410119-24971-1-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 18ffa988dbhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I78dd14dab53a4e48ef2aaa16f16397ed2361f597
As part of commit e81a7018d9 ("usb: dwc3: allocate gadget structure
dynamically") the dwc3_gadget_release() was added which will free
the dwc->gadget structure upon the device's removal when
usb_del_gadget_udc() is called in dwc3_gadget_exit().
However, simply freeing the gadget results a dangling pointer
situation: the endpoints created in dwc3_gadget_init_endpoints()
have their dep->endpoint.ep_list members chained off the list_head
anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed,
the first dwc3_ep in the list now has a dangling prev pointer and
likewise for the next pointer of the dwc3_ep at the tail of the list.
The dwc3_gadget_free_endpoints() that follows will result in a
use-after-free when it calls list_del().
This was caught by enabling KASAN and performing a driver unbind.
The recent commit 568262bf54 ("usb: dwc3: core: Add shutdown
callback for dwc3") also exposes this as a panic during shutdown.
There are a few possibilities to fix this. One could be to perform
a list_del() of the gadget->ep_list itself which removes it from
the rest of the dwc3_ep chain.
Another approach is what this patch does, by splitting up the
usb_del_gadget_udc() call into its separate "del" and "put"
components. This allows dwc3_gadget_free_endpoints() to be
called before the gadget is finally freed with usb_put_gadget().
Fixes: e81a7018d9 ("usb: dwc3: allocate gadget structure dynamically")
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bb9c74a5bdhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0062f1ccdda604938d8e2f68de4ae27360397d9f
The dwc2 gadget support maps and unmaps DMA buffers as necessary. When
mapping and unmapping it uses the direction of the endpoint to select
the direction of the DMA transfer, but this fails for Control OUT
transfers because the unmap occurs after the endpoint direction has
been reversed for the status phase.
A possible solution would be to unmap the buffer before the direction
is changed, but a safer, less invasive fix is to remember the buffer
direction independently of the endpoint direction.
Fixes: fe0b94abcd ("usb: dwc2: gadget: manage ep0 state in software")
Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Link: https://lore.kernel.org/r/20210506112200.2893922-1-phil@raspberrypi.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 75a41ce46bhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1cdc8528842a33cadb0e05852b95670360db8ad3
The device event corresponding to End of Periodic Frame is only
found on older IP revisions (2.10a and prior, according to a
cursory SNPS databook search). On revisions 2.30a and newer,
including DWC3.1, the same event value and corresponding DEVTEN
bit were repurposed to indicate that the link has gone into
suspend state (U3 or L2/L1).
EOPF events had never been enabled before in this driver, and
going forward we expect current and future DWC3-based devices
won't likely to be using such old DWC3 IP revisions either.
Hence rather than keeping the deprecated EOPF macro names let's
rename them to indicate their usage for suspend events.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210428090111.3370-2-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6f26ebb79ahttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8351dd713ce0e60b2212a22a3b51d1139ae89779
commit 72704f876f ("dwc3: gadget: Implement the suspend entry event
handler") introduced (nearly 5 years ago!) an interrupt handler for
U3/L1-L2 suspend events. The problem is that these events aren't
currently enabled in the DEVTEN register so the handler is never
even invoked. Fix this simply by enabling the corresponding bit
in dwc3_gadget_enable_irq() using the same revision check as found
in the handler.
Fixes: 72704f876f ("dwc3: gadget: Implement the suspend entry event handler")
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210428090111.3370-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d1d90dd272https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia54cb4045149139ee7f21f9e4c6dc31e2ef52971
This reverts commit fb4c1c2e9f.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7b12040440bc2bedfbabc71d60339cb843e59570
This reverts commit 2e8b3b0b8e.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I03a41fc3ba455ded7274f2a6b5566bb369a75a86
This reverts commit 22163a8ec8.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie256b7f1ed5b19f4600ff4c3681efaea5046adda
This reverts commit 1bbcc985d1.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I88427586de4df897c39bb3d48e8cba86ebf5c4bb
This reverts commit 1f2ef5a0f7.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I461f44ec54102dcf06ba73959a79172615cdb8fa
This reverts commit 9efd5df078.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia22b608e4d017c6056e481d2ec819074b35810cf
This reverts commit 25ed8827cf.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9928cdc06a26b9db3052b93067c557011e53f735
This reverts commit 85a5a6875c.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibe7639f73acc11b356f6b2f8f76011844c7f451b
This reverts commit f8e71c667e.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6684b40d913a86b79899220cba823a74aea5923f
This reverts commit 2fa0387fa2.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If6aba0f06d169907827ca1f76b52adc75c84c124
Changes in 5.10.35
mips: Do not include hi and lo in clobber list for R6
netfilter: conntrack: Make global sysctls readonly in non-init netns
net: usb: ax88179_178a: initialize local variables before use
igb: Enable RSS for Intel I211 Ethernet Controller
bpf: Fix masking negation logic upon negative dst register
bpf: Fix leakage of uninitialized bpf stack under speculation
net: qrtr: Avoid potential use after free in MHI send
perf data: Fix error return code in perf_data__create_dir()
capabilities: require CAP_SETFCAP to map uid 0
perf ftrace: Fix access to pid in array when setting a pid filter
tools/cgroup/slabinfo.py: updated to work on current kernel
driver core: add a min_align_mask field to struct device_dma_parameters
swiotlb: add a IO_TLB_SIZE define
swiotlb: factor out an io_tlb_offset helper
swiotlb: factor out a nr_slots helper
swiotlb: clean up swiotlb_tbl_unmap_single
swiotlb: refactor swiotlb_tbl_map_single
swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single
swiotlb: respect min_align_mask
nvme-pci: set min_align_mask
ovl: fix leaked dentry
ovl: allow upperdir inside lowerdir
ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX
USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet
USB: Add reset-resume quirk for WD19's Realtek Hub
platform/x86: thinkpad_acpi: Correct thermal sensor allocation
perf/core: Fix unconditional security_locked_down() call
vfio: Depend on MMU
Linux 5.10.35
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iff7d5abe7b821f453bbe4d9dad94dfd35fe0a082
The inflight of partition 0 doesn't include inflight IOs to all
sub-partitions, since currently mq calculates inflight of specific
partition by simply camparing the value of the partition pointer.
Thus the following case is possible:
$ cat /sys/block/vda/inflight
0 0
$ cat /sys/block/vda/vda1/inflight
0 128
While single queue device (on a previous version, e.g. v3.10) has no
this issue:
$cat /sys/block/sda/sda3/inflight
0 33
$cat /sys/block/sda/inflight
0 33
Partition 0 should be specially handled since it represents the whole
disk. This issue is introduced since commit bf0ddaba65 ("blk-mq: fix
sysfs inflight counter").
Besides, this patch can also fix the inflight statistics of part 0 in
/proc/diskstats. Before this patch, the inflight statistics of part 0
doesn't include that of sub partitions. (I have marked the 'inflight'
field with asterisk.)
$cat /proc/diskstats
259 0 nvme0n1 45974469 0 367814768 6445794 1 0 1 0 *0* 111062 6445794 0 0 0 0 0 0
259 2 nvme0n1p1 45974058 0 367797952 6445727 0 0 0 0 *33* 111001 6445727 0 0 0 0 0 0
This is introduced since commit f299b7c7a9 ("blk-mq: provide internal
in-flight variant").
Fixes: bf0ddaba65 ("blk-mq: fix sysfs inflight counter")
Fixes: f299b7c7a9 ("blk-mq: provide internal in-flight variant")
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
[axboe: adapt for 5.11 partition change]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Bug: 187355247
Change-Id: I378b2cb7312a5e47d5e2ec7301dc392e6e7336d0
(cherry picked from commit b0d97557eb)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Set KMI_GENERATION=4 for 5/7 KMI update
Leaf changes summary: 2821 artifacts changed
Changed leaf types summary: 17 leaf types changed
Removed/Changed/Added functions summary: 1 Removed, 2752 Changed, 1 Added function
Removed/Changed/Added variables summary: 0 Removed, 49 Changed, 1 Added variable
1 Removed function:
[D] 'function file* filp_open(const char*, int, umode_t)'
1 Added function:
[A] 'function int __traceiter_android_vh_of_i2c_get_board_info(void*, device_node*, const char**)'
2752 functions with some sub-type change:
[C] 'function void* PDE_DATA(const inode*)' at generic.c:799:1 has some sub-type changes:
CRC (modversions) changed from 0x53dbf80f to 0x27c5b1f0
[C] 'function void __ClearPageMovable(page*)' at compaction.c:138:1 has some sub-type changes:
CRC (modversions) changed from 0xc7c1f13e to 0x22571ed2
[C] 'function void __SetPageMovable(page*, address_space*)' at compaction.c:130:1 has some sub-type changes:
CRC (modversions) changed from 0x3b98a825 to 0x5f77584f
... 2749 omitted; 2752 symbols have only CRC changes
1 Added variable:
[A] 'tracepoint __tracepoint_android_vh_of_i2c_get_board_info'
49 Changed variables:
[C] 'bus_type amba_bustype' was changed at bus.c:215:1:
CRC (modversions) changed from 0x33a71197 to 0xabc9cec3
[C] 'const address_space_operations balloon_aops' was changed at balloon_compaction.c:253:1:
CRC (modversions) changed from 0x50598639 to 0xb8eca1a2
[C] 'const clk_ops clk_fixed_factor_ops' was changed at clk-fixed-factor.c:60:1:
CRC (modversions) changed from 0xaa612693 to 0xdbcf0d4e
... 46 omitted; 49 symbols have only CRC changes
'enum android_debug_symbol at android_debug_symbols.h:9:1' changed:
type size hasn't changed
7 enumerator insertions:
'android_debug_symbol::ADS_TOTAL_CMA' value '7'
'android_debug_symbol::ADS_SLAB_CACHES' value '8'
'android_debug_symbol::ADS_SLAB_MUTEX' value '9'
'android_debug_symbol::ADS_MIN_LOW_PFN' value '10'
'android_debug_symbol::ADS_MAX_PFN' value '11'
'android_debug_symbol::ADS_PAGE_OWNER_ENABLED' value '12'
'android_debug_symbol::ADS_SLUB_DEBUG' value '13'
1 enumerator change:
'android_debug_symbol::ADS_END' from value '7' to '14' at android_debug_symbols.h:9:1
one impacted interface
'enum binder_work_type at binder_internal.h:174:1' changed:
type size hasn't changed
1 enumerator insertion:
'binder_work_type::BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT' value '3'
5 enumerator changes:
'binder_work_type::BINDER_WORK_RETURN_ERROR' from value '3' to '4' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_NODE' from value '4' to '5' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_DEAD_BINDER' from value '5' to '6' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_DEAD_BINDER_AND_CLEAR' from value '6' to '7' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_CLEAR_DEATH_NOTIFICATION' from value '7' to '8' at binder_internal.h:174:1
5 impacted interfaces
'struct binder_alloc at binder_alloc.h:96:1' changed:
type size changed from 1024 to 1088 (in bits)
1 data member insertion:
'bool oneway_spam_detected', at offset 1024 (in bits) at binder_alloc.h:115:1
5 impacted interfaces
'struct binder_buffer at binder_alloc.h:40:1' changed:
type size hasn't changed
1 data member insertion:
'unsigned int oneway_spam_suspect', at offset 4 (in bits) at binder_alloc.h:50:1
there are data member changes:
'unsigned int debug_id' offset changed (by +1 bits)
4 impacted interfaces
'struct binder_proc at binder_internal.h:436:1' changed:
type size changed from 4480 to 4672 (in bits)
1 data member insertion:
'bool oneway_spam_detection_enabled', at offset 4608 (in bits) at binder_internal.h:471:1
there are data member changes:
type 'struct binder_stats' of 'binder_proc::stats' changed:
type size changed from 1664 to 1696 (in bits)
there are data member changes:
type 'atomic_t[19]' of 'binder_stats::br' changed:
type name changed from 'atomic_t[19]' to 'atomic_t[20]'
array type size changed from 608 to 640
array type subrange 1 changed length from 19 to 20
3 ('atomic_t bc[19]' .. 'atomic_t obj_deleted[7]') offsets changed (by +32 bits)
5 impacted interfaces
7 ('list_head delivered_death' .. 'dentry* debugfs_entry') offsets changed (by +64 bits)
type 'struct binder_alloc' of 'binder_proc::alloc' changed, as reported earlier
and offset changed from 3264 to 3328 (in bits) (by +64 bits)
4 ('binder_context* context' .. 'dentry* binderfs_entry') offsets changed (by +128 bits)
5 impacted interfaces
'struct binder_stats at binder_internal.h:157:1' changed:
details were reported earlier
'struct binder_thread at binder_internal.h:507:1' changed (indirectly):
type size changed from 3264 to 3328 (in bits)
there are data member changes:
type 'struct binder_stats' of 'binder_thread::stats' changed, as reported earlier
2 ('atomic_t tmp_ref' .. 'bool is_dead') offsets changed (by +32 bits)
'task_struct* task' offset changed (by +64 bits)
4 impacted interfaces
'struct dwc3 at core.h:1080:1' changed:
type size changed from 9216 to 9984 (in bits)
5 data member insertions:
'mutex mutex', at offset 2624 (in bits) at core.h:1115:1
'u64 android_kabi_reserved1', at offset 9728 (in bits) at core.h:1302:1
'u64 android_kabi_reserved2', at offset 9792 (in bits) at core.h:1303:1
'u64 android_kabi_reserved3', at offset 9856 (in bits) at core.h:1304:1
'u64 android_kabi_reserved4', at offset 9920 (in bits) at core.h:1305:1
there are data member changes:
type 'struct dwc3_request' of 'dwc3::ep0_usb_req' changed:
type size changed from 1472 to 1600 (in bits)
2 data member insertions:
'u64 android_kabi_reserved1', at offset 1472 (in bits) at core.h:947:1
'u64 android_kabi_reserved2', at offset 1536 (in bits) at core.h:948:1
2 impacted interfaces
2 ('completion ep0_in_setup' .. 'spinlock_t lock') offsets changed (by +128 bits)
53 ('device* dev' .. 'u8 num_eps') offsets changed (by +384 bits)
type 'struct dwc3_hwparams' of 'dwc3::hwparams' changed:
type size changed from 288 to 448 (in bits)
3 data member insertions:
'u32 hwparams9', at offset 288 (in bits) at core.h:872:1
'u64 android_kabi_reserved1', at offset 320 (in bits) at core.h:874:1
'u64 android_kabi_reserved2', at offset 384 (in bits) at core.h:875:1
2 impacted interfaces
and offset changed from 8512 to 8896 (in bits) (by +384 bits)
13 ('dentry* root' .. 'u16 imod_interval') offsets changed (by +512 bits)
2 impacted interfaces
'struct dwc3_ep at core.h:696:1' changed:
type size changed from 1664 to 1792 (in bits)
2 data member insertions:
'u64 android_kabi_reserved1', at offset 1664 (in bits) at core.h:761:1
'u64 android_kabi_reserved2', at offset 1728 (in bits) at core.h:762:1
2 impacted interfaces
'struct dwc3_event_buffer at core.h:646:1' changed:
type size changed from 384 to 448 (in bits)
1 data member insertion:
'u64 android_kabi_reserved1', at offset 384 (in bits) at core.h:666:1
2 impacted interfaces
'struct dwc3_hwparams at core.h:851:1' changed:
details were reported earlier
'struct dwc3_request at core.h:902:1' changed:
details were reported earlier
'struct mod_arch_specific at module.h:17:1' changed:
type size changed from 256 to 448 (in bits)
4 data member insertions:
'const Elf64_Rela* text_relocations', at offset 256 (in bits) at module.h:25:1
'const Elf64_Rela* rodata_relocations', at offset 320 (in bits) at module.h:26:1
'int num_text_relocations', at offset 384 (in bits) at module.h:27:1
'int num_rodata_relocations', at offset 416 (in bits) at module.h:28:1
2074 impacted interfaces
'struct module at module.h:367:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct mod_arch_specific' of 'module::arch' changed, as reported earlier
41 ('unsigned long int taints' .. 'u64 android_kabi_reserved4') offsets changed (by +192 bits)
2074 impacted interfaces
'struct queue_limits at blkdev.h:318:1' changed:
type size changed from 896 to 960 (in bits)
1 data member insertion:
'unsigned int bio_max_bytes', at offset 0 (in bits) at blkdev.h:319:1
there are data member changes:
27 ('unsigned long int bounce_pfn' .. 'blk_zoned_model zoned') offsets changed (by +64 bits)
2075 impacted interfaces
'struct request_queue at blkdev.h:396:1' changed (indirectly):
type size changed from 15104 to 15168 (in bits)
there are data member changes:
type 'struct queue_limits' of 'request_queue::limits' changed, as reported earlier
27 ('unsigned int required_elevator_features' .. 'u64 write_hints[5]') offsets changed (by +64 bits)
2074 impacted interfaces
'struct rproc_ops at remoteproc.h:380:1' changed:
type size hasn't changed
there are data member changes:
type 'void* (rproc*, typedef u64, typedef size_t)*' of 'rproc_ops::da_to_va' changed:
pointer type changed from: 'void* (rproc*, typedef u64, typedef size_t)*' to: 'void* (rproc*, typedef u64, typedef size_t, bool*)*'
17 impacted interfaces
Bug: 187507598
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I70911d8a70cb00828dcc6ce601e97a5a4ef1eace
bio size can grow up to 4GB when muli-page bvec is enabled.
but sometimes it would lead to inefficient behaviors.
in case of large chunk direct I/O, - 32MB chunk read in user space -
all pages for 32MB would be merged to a bio structure if the pages
physical addresses are contiguous. it makes some delay to submit
until merge complete. bio max size should be limited to a proper size.
When 32MB chunk read with direct I/O option is coming from userspace,
kernel behavior is below now in do_direct_IO() loop. it's timeline.
| bio merge for 32MB. total 8,192 pages are merged.
| total elapsed time is over 2ms.
|------------------ ... ----------------------->|
| 8,192 pages merged a bio.
| at this time, first bio submit is done.
| 1 bio is split to 32 read request and issue.
|--------------->
|--------------->
|--------------->
......
|--------------->
|--------------->|
total 19ms elapsed to complete 32MB read done from device. |
If bio max size is limited with 1MB, behavior is changed below.
| bio merge for 1MB. 256 pages are merged for each bio.
| total 32 bio will be made.
| total elapsed time is over 2ms. it's same.
| but, first bio submit timing is fast. about 100us.
|--->|--->|--->|---> ... -->|--->|--->|--->|--->|
| 256 pages merged a bio.
| at this time, first bio submit is done.
| and 1 read request is issued for 1 bio.
|--------------->
|--------------->
|--------------->
......
|--------------->
|--------------->|
total 17ms elapsed to complete 32MB read done from device. |
As a result, read request issue timing is faster if bio max size is limited.
Current kernel behavior with multipage bvec, super large bio can be created.
And it lead to delay first I/O request issue.
Signed-off-by: Changheun Lee <nanich.lee@samsung.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20210503095203.29076-1-nanich.lee@samsung.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Bug: 182716953
(cherry picked from commit cd2c7545ae)
Change-Id: Ie3876daa495535dc7f856ed9a281e65d72a437c1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
"dev_name" for I2C devices won't have any value set, unless they are
instantiated thru ACPI interface. As a result of this, I2C driver will
assign some dynamic name in the format "%d-%04x" (e.g. 1-001f), and
further this device names are used for kernel wakelocks.
This dynamic names are difficult to associate with actual device and
hence it will help to have an ability where vendor can assign the
device name through vendor hooks.
Bug: 147496295
Signed-off-by: Manish Varma <varmam@google.com>
Change-Id: Idb417ef5330002063a9763544f9f0364f9581276
When async binder buffer got exhausted, some normal oneway transactions
will also be discarded and may cause system or application failures. By
that time, the binder debug information we dump may not be relevant to
the root cause. And this issue is difficult to debug if without the
backtrace of the thread sending spam.
This change will send BR_ONEWAY_SPAM_SUSPECT to userspace when oneway
spamming is detected, request to dump current backtrace. Oneway spamming
will be reported only once when exceeding the threshold (target process
dips below 80% of its oneway space, and current process is responsible
for either more than 50 transactions, or more than 50% of the oneway
space). And the detection will restart when the async buffer has
returned to a healthy state.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Hang Lu <hangl@codeaurora.org>
Link: https://lore.kernel.org/r/1617961246-4502-3-git-send-email-hangl@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 181190340
Change-Id: Id3d2526099bc89f04d8ad3ad6e48141b2a8f2515
(cherry picked from commit a7dc1e6f99)
Signed-off-by: Hang Lu <hangl@codeaurora.org>
The fips140.ko module relies on ELF metadata that is normally discarded
by the module loader. In order to reduce the impact of the associated
changes on non-FIPS140 kernels, the module loader will be modified to
simply copy this metadata if it encounters a module whose name is
'fips140'. For this to work, we need a couple of fields in struct
mod_arch_specific so that this module can find this data at module init
time.
Adding these fields will change the type signature of struct module, and
hence affect the stable ABI. The FIPS140 module build depends on LTO,
and so its Kconfig symbol can only be enabled if LTO is enabled as well.
This implies that adding these mod_arch_specific fields conditionally,
based on CONFIG_CRYPTO_FIPS140_INTEGRITY_CHECK, would result in an ABI
fork between LTO and !LTO builds, which is obviously undesirable.
So let's just add these fields unconditionally. This will take 24 bytes
of kernel memory per module, but given that the size of struct module
(which is the only place where struct mod_arch_specific is allocated) is
rounded up to cacheline size (128 bytes on arm64), and this change does
not push it over the edge, the net result is that no additional memory
is used (struct module is currently 1 KiB)
Bug: 153614920
Change-Id: Ia617762f37c0bf7324e899b72fd317e382e39c03
Signed-off-by: Ard Biesheuvel <ardb@google.com>
A number of systems want access to the zram flip_open functionality,
which is now called filp_open_block() to remove any possiblity of bad
drivers trying to access filesystems directly.
Fix up the two symbol lists that were referring to the wrong symbol.
Bug: 157965270
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I368da14ca739b6048dd88a38fca4af8b7f02714d
Try to mitigate potential future driver core api changes by adding
padding to a number of dwc3 structures.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1826d885e3acf1f378d0e30b1ca2ddc56b16a9e4
DWC_usb32 IP introduces a new behavior when handling NoStream event for
IN endpoints. If the controller is capable of DEV_TXF_FLUSH_BYPASS, then
the driver does not need to force to restart stream for IN endpoints.
The controller will generate ERDY and restart the stream periodically.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/65c3070c666cd6b8beeee62d7f8e3e704ebf2d32.1619134559.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 16710380d3https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9271d4cfb20cfe0fd35c4886911fc7fa9bbc7b95
According to the programming guide, to switch mode for DRD controller,
the driver needs to do the following.
To switch from device to host:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(host mode)
3. Reset the host with USBCMD.HCRESET
4. Then follow up with the initializing host registers sequence
To switch from host to device:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(device mode)
3. Reset the device with DCTL.CSftRst
4. Then follow up with the initializing registers sequence
Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of
switching from host to device. John Stult reported a lockup issue seen
with HiKey960 platform without these steps[1]. Similar issue is observed
with Ferry's testing platform[2].
So, apply the required steps along with some fixes to Yu Chen's and John
Stultz's version. The main fixes to their versions are the missing wait
for clocks synchronization before clearing GCTL.CoreSoftReset and only
apply DCTL.CSftRst when switching from host to device.
[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/
[2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
Fixes: 41ce1456e1 ("usb: dwc3: core: make dwc3_set_mode() work properly")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ferry Toth <fntoth@gmail.com>
Cc: Wesley Cheng <wcheng@codeaurora.org>
Cc: <stable@vger.kernel.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Tested-by: Wesley Cheng <wcheng@codeaurora.org>
Signed-off-by: Yu Chen <chenyu56@huawei.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f88359e158https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1a7726f207adbcb96b9693d77605282fd00fe151
Add symbols which will be used by the minidump module to
the debug symbol driver.
Bug: 184707701
Change-Id: I4cfdc59e0fcab89ad4df4fcb4de4a706a9c84cf8
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
Add __bitmap_andnot and cpumask_any_but to symbol list.
Bug: 187463586
Change-Id: I936ee9778040ba96a3937e21da0c886b2929df7c
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
To free the fifo buffer allocated by __kfifo_alloc we need to use
__kfifo_free. This change adds the __kfifo_free symbol to the
qcom symbol list.
Bug: 184180643
Change-Id: I2d8a719be61af59cd0c7fd59b8d6957a0e5050e0
Signed-off-by: Siddharth Gupta <quic_sidgup@quicinc.com>
commit b2b12db535 upstream.
VFIO_IOMMU_TYPE1 does not compile with !MMU:
../drivers/vfio/vfio_iommu_type1.c: In function 'follow_fault_pfn':
../drivers/vfio/vfio_iommu_type1.c:536:22: error: implicit declaration of function 'pte_write'; did you mean 'vfs_write'? [-Werror=implicit-function-declaration]
So require it.
Suggested-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Message-Id: <0-v1-02cb5500df6e+78-vfio_no_mmu_jgg@nvidia.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 08ef1af4de upstream.
Currently, the lockdown state is queried unconditionally, even though
its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in
attr.sample_type. While that doesn't matter in case of the Lockdown LSM,
it causes trouble with the SELinux's lockdown hook implementation.
SELinux implements the locked_down hook with a check whether the current
task's type has the corresponding "lockdown" class permission
("integrity" or "confidentiality") allowed in the policy. This means
that calling the hook when the access control decision would be ignored
generates a bogus permission check and audit record.
Fix this by checking sample_type first and only calling the hook when
its result would be honored.
Fixes: b0c8fdc7fd ("lockdown: Lock down perf when in confidentiality mode")
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Link: https://lkml.kernel.org/r/20210224215628.192519-1-omosnace@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6759e18e5c upstream.
On recent Thinkpad platforms it was reported that temp sensor 11 was
always incorrectly displaying 66C. It turns out the reason for this is
that this location in EC RAM is not a temperature sensor but is the
power supply ID (offset 0xC2).
Based on feedback from the Lenovo firmware team the EC RAM version can
be determined and for the current version (3) only the 0x78 to 0x7F
range is used for temp sensors. I don't have any details for earlier
versions so I have left the implementation unaltered there.
Note - in this block only 0x78 and 0x79 are officially designated (CPU &
GPU sensors). The use of the other locations in the block will vary from
platform to platform; but the existing logic to detect a sensor presence
holds.
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ca91fd8c76 upstream.
Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
Information of this hub:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5
D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=5487 Rev= 1.47
S: Manufacturer=Dell Inc.
S: Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the specified port of the hub. The port
seems to be in an unknown state so the hub_activate during resume
fails the hub_port_status, then the hub will fail to work.
The quirky hub needs the reset-resume quirk to function correctly.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
