On the android12-5.10 branch, commit 4a5cf92412 ("BACKPORT: FROMGIT:
userfaultfd: add UFFDIO_CONTINUE ioctl") added a new call site for the
function validate_range(). Meanwhile, on the 5.10 stable branch, commit
0b591c020d ("userfaultfd: do not untag user pointers") changed the
function signature of validate_range() and updated all call sites
accordingly. However, since these two commits happened on different
branches, the new call site in userfaultfd_continue() has not been
updated accordingly. This has arguably been missed in the merge commit
66379c1ee5 ("Merge tag 'android12-5.10.66_r00' into
android12-5.10").
This patch fixes the following build breakage
./common/fs/userfaultfd.c:1875:32: error: incompatible pointer to integer conversion passing '__u64 *' (aka 'unsigned long long *') to parameter of type '__u64' (aka 'unsigned long long'); remove & [-Werror,-Wint-conversion]
ret = validate_range(ctx->mm, &uffdio_continue.range.start,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./common/fs/userfaultfd.c:1245:14: note: passing argument to parameter 'start' here
__u64 start, __u64 len)
^
1 error generated.
Fixes: 66379c1ee5 ("Merge tag 'android12-5.10.66_r00' into android12-5.10")
Signed-off-by: Aaron Ding <aaronding@google.com>
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Change-Id: I7ad40df213897314c439480f22a2ef4712e84025
(cherry picked from commit 5ec931a853)
Resume cpu need to run cpuset_hotplug_workfn which need take
about several milliseconds, and even more if the system have
more tasks.
This isn't suitable to run in the main task context of resume
cpu.
Due to the cpu which is resuming only have active mask,
but still not rebuild sched domain, make this slow
work run on resuming cpu can not take extra overload to
previous active cpus.
Bug: 203839955
Fixes: 1d3a64fbd2 ("ANDROID: cpu/hotplug: rebuild sched
domains immediately")
Change-Id: Ia7bdd077f982950c02696c3598a41b2482046220
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
isp20 bridge will config gain and image dma address when isp
frame start interrupt event, and frame end update. But no
actual update if frame start and frame end together. One read
back is the same as the start interrupt event, so to update
bridge mi this.
Change-Id: I697128fd60c3e38eb2ed163a5a94df8c4c018241
Signed-off-by: Cai YiWei <cyw@rock-chips.com>
This reverts commit c82dbcbec1.
Reason for revert: use vendor_hook approach instead of adding a new field.
Change-Id: I001dafc1b90cfe4567a13f538c2f8d25a0929504
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.corp-partner.google.com>
To be compatible with GKI, dw-hdmi driver can't call interfaces in
rockchip-drm directly. In order for dp to be usable, get yuv422
format interface should define in rockchip-drm. So hdmi call
get yuv422 format interface in dw_hdmi-rockchip.c.
Fixes: dbd228a254 ("drm/bridge: synopsys: dw-hdmi: Get edid yuv422 info independently")
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: Icc879ff4420357a6becba84371b9e3317583960b
For rk3568, ddr timings adjustment is no longer supported in dmc drive.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Change-Id: I63f0c5fea8c5acf8e6ef8f44b62968deb7bd823e
Add dmc_fsp node for initialize dmc frequency set point on U-Boot.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Change-Id: I9fcd1ae498a64b5a4698c42ad05af96740b59e61
Add ddr parameters for initialize dmc frequency set point.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Change-Id: I3445fa2dbabca5774306cc1052cd3c1d472b6867
The device must be registered last. If there is an error, the device
should not succeed.
Change-Id: Ie342c8bbf30e8a94822dcb2e0417fe1230e4482a
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
When devfreq initially fails, the device can still continue to execute,
but there is no devfreq function.
Change-Id: I2a39a77e0a85cb43854b6adbe0476905abcc9a3b
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
On some platforms(such as px30), vepu and vdpu shared the
same mmu.So when registering the iommu handle function,
there will be overwriting.Results in the reported device mismatch
when page fault.
Signed-off-by: Yandong Lin <yandong.lin@rock-chips.com>
Change-Id: Id07c7f3088c52fcb987797c689296154c670078c
if CONFIG_IOMMU_SUPPORT=n, log:
error: 'const struct iommu_ops' has no member named 'flush_iotlb_all'
if (domain && domain->ops && domain->ops->flush_iotlb_all)
Change-Id: I8268e0b5d5a513d1c55b0c755c479049b13bdeb7
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
Using CONFIG_CPU_XX only compiles the code of matching CPU,
then it can reduce the object file.
Change-Id: Ic19345464c802939d08786ae29b34111c3c5a855
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
move the workaround functions for px30 to the mpp_hack_px30.c.
Change-Id: I9f9880c28fe1d797b0551d116a66294223a5e251
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
For kernel-tiny, remove debug relative code, and reduce the size of module.
Change-Id: Ic78a0839a75c9cebb56fa32e87235bd97be0370a
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
Some functions may dynamically enable and disable their endpoints
regularly throughout their operation, particularly when Set Interface
is employed to switch between Alternate Settings. For instance the
UAC2 function has its respective endpoints for playback & capture
associated with AltSetting 1, in which case those endpoints would not
get enabled until the host activates the AltSetting. And they
conversely become disabled when the interfaces' AltSetting 0 is
chosen.
With the DWC3 FIFO resizing algorithm recently added, every
usb_ep_enable() call results in a call to resize that EP's TXFIFO,
but if the same endpoint is enabled again and again, this incorrectly
leads to FIFO RAM allocation exhaustion as the mechanism did not
account for the possibility that endpoints can be re-enabled many
times.
Example log splat:
dwc3 a600000.dwc3: Fifosize(3717) > RAM size(3462) ep3in depth:217973127
configfs-gadget gadget: u_audio_start_capture:521 Error!
dwc3 a600000.dwc3: request 000000000be13e18 was not queued to ep3in
Add another bit DWC3_EP_TXFIFO_RESIZED to dep->flags to keep track of
whether an EP had already been resized in the current configuration.
If so, bail out of dwc3_gadget_resize_tx_fifos() to avoid the
calculation error resulting from accumulating the EP's FIFO depth
repeatedly. This flag is retained across multiple ep_disable() and
ep_enable() calls and is cleared when GTXFIFOSIZn is reset in
dwc3_gadget_clear_tx_fifos() upon receiving the next Set Config.
Fixes: 9f607a309f ("usb: dwc3: Resize TX FIFOs to meet EP bursting requirements")
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20211021180129.27938-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 876a75cb52https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Bug: 204047971
Change-Id: Ia104c2fa9be36182a23a7e6f923e499ef3bcc3b1
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
In system_heap_do_allocate, we will use uncached heap device to call
dma_map_sgtable & dma_unmap_sgtable to do implicitly flush.
However, device of uncached heap is not set dma_parms, default value(64KB)
is too small for dma_heap buffer, it will cause some warning log below when
CONFIG_DMA_API_DEBUG_SG is enabled.
warning log sample:
|DMA-API: dma_heap system-uncached: mapping sg segment longer than device claims to support [len=1048576] [max=65536]
|WARNING: CPU: 4 PID: 576 at kernel/dma/debug.c:1173 debug_dma_map_sg+0x214/0x438
|......
Bug: 199986022
Change-Id: I97076de329f4a50d035d43d69cb17606064c3151
Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com>
This adds three mailbox nodes for RK3588 SoCs.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Change-Id: I49edf5211a0aab183524aeb37aaed56a2cf2c3ff
This adds HW Spinlock nodes for RK3588 SoCs.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Change-Id: I97c9c7292060b8b805353448cf6c47167bb3981d
This patch is useful for board with totalram size larger than 4GB.
Since swiotlb has memory size limitation, this will calculate the
maximum size locally, as a workaround to fix the orders[0].
With this patch:
[ 3.921612] orders[0] = 6
[ 3.921647] orders[1] = 4
[ 3.921715] orders[2] = 0
Change-Id: I9286f6ea53f679816c9afd378a6cfe620ef1b53e
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Assume p is console task, try_to_wake_up(p) will hold p->pi_lock,
if printk is called in try_to_wake_up(), then printk will call
try_to_wake_up(p) again which cause deadlock on p->pi_lock.
deadlock stack:
Thread #2 2 (Name: cpu1, EL2H) (Suspended : Container)
queued_spin_lock_slowpath() at qspinlock.c:382 0xffffffc0101359a4
queued_spin_lock() at qspinlock.h:85 0xffffffc0111ef72c
do_raw_spin_lock_flags() at spinlock.h:195 0xffffffc0111ef72c
__raw_spin_lock_irqsave() at spinlock_api_smp.h:119 0xffffffc0111ef72c
_raw_spin_lock_irqsave() at spinlock.c:159 0xffffffc0111ef72c
try_to_wake_up() at core.c:3,070 0xffffffc0101059c0
wake_up_process() at core.c:3,275 0xffffffc010103bcc
console_write() at rk_fiq_debugger.c:337 0xffffffc010732a50
fiq_debugger_console_write() at fiq_debugger.c:1,169 0xffffffc010d60004
call_console_drivers() at printk.c:1,912 0xffffffc01013f2d4
console_unlock() at printk.c:2,538 0xffffffc01013f2d4
vprintk_emit() at printk.c:2,061 0xffffffc01013ed48
vprintk_default() at printk.c:2,078 0xffffffc01013f698
vprintk_func() at printk_safe.c:401 0xffffffc010142304
printk() at printk.c:2,109 0xffffffc0111e50a4
report_bug() at bug.c:193 0xffffffc01063e258
bug_handler() at traps.c:907 0xffffffc01009415c
call_break_hook() at debug-monitors.c:325 0xffffffc010085a40
brk_handler() at debug-monitors.c:332 0xffffffc010085a40
do_debug_exception() at fault.c:964 0xffffffc0100af2bc
el1_dbg() at entry-common.c:185 0xffffffc0111e6ba8
el1_sync_handler() at entry-common.c:222 0xffffffc0111e6a04
el1_sync() at 0xffffffc01008240c
brk()
WARN_ON_ONCE()
ttwu_queue_wakelist()
try_to_wake_up()
hrtimer_wakeup()
run_hrtimer()
usleep_range()
console_put()
console_thread()
Change-Id: I76dac4e2a76abb1f75e66677fb7ece2b52a83f25
Signed-off-by: Liang Chen <cl@rock-chips.com>
