Sync with floral_defconfig
CONFIG_BUG_ON_DATA_CORRUPTION
CONFIG_SCHED_STACK_END_CHECK
CONFIG_DEFAULT_MMAP_MIN_ADDR to 32768
Change-Id: I11a8fc79a47da62e4f3df04da4614e6fcfc8e247
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
With large eMMC cards, it is possible to create general purpose
partitions that are bigger than 4GB. The size member of the mmc_part
struct is only an unsigned int which overflows for gp partitions larger
than 4GB. Change this to a u64 to handle the overflow.
Change-Id: I95594ae67987bc3f9599bc4a13952eb59c43e813
Signed-off-by: Bradley Bolen <bradleybolen@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from f3d7c2292d)
When it is the initialized probe, getting or setting the Ethernet address
from the vendor partition will fail. The function for reading/writting
vendor partition is not registered and changed this to stmmac_open to
ensure the operation worked.
Change-Id: Id9401e7ffcbc16a266ecb69b3777499919c50ed6
Signed-off-by: David Wu <david.wu@rock-chips.com>
Default pull state of pwm2 and pwm3 pin are up, keep them
when pwm2 and pwm3 are used for pwm regulator. And remove
the pull down config for pwm2 and pwm3, they are not used.
Change-Id: Id8c4767627bd00d224aec734f4a1cacb619c79aa
Signed-off-by: David Wu <david.wu@rock-chips.com>
vb2_fop_release should be called before v4l2_pipeline_pm_use,
otherwise it causes system crash when start stream with v4l2-ctl command,
and stop stream unexpected with ctrl+c.
Change-Id: Ia46078aaf1e436fdc10272ef778b4d8b11589520
Signed-off-by: Wang Panzhenzhuan <randy.wang@rock-chips.com>
The default state of pwm2/pwm3 pin is a pull up, we need to keep it
for the second global reset issue, when pwm2/pwm3 used for the regulator
Change-Id: Ic57e26338f7f546e3f784bd34790ed9b027d78de
Signed-off-by: Xiao Ya peng <yp.xiao@rock-chips.com>
The source files are under drivers/gpu/arm/mali400.
Change-Id: I4ee1055cf3f630e2d609ab72e26c36daf51cddbb
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Add SYS_STATUS_REBOOT for dmc so that the frequency and voltage will
change when reboot.
Change-Id: If26c704bfda361d03cf3a8b0e16781902ddf7e12
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
There is an reboot frequency event if don't add property 'rockchip,reboot-freq'
in cpu opp table node.
Change-Id: I79a56d62c70d99f60840cd3304622799aaa66476
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
The reboot and fb notifiers are also need for some platfroms when enable
dmcfreq.
Change-Id: I7a02e43ebfff6f8cdccd050a30a9e6c270fc5b5e
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
the OTG_SWITCH supply OTG, it doesn't need to be on When the driver initializes.
Signed-off-by: shengfei Xu <xsf@rock-chips.com>
Change-Id: I44f4fa618f66f18fa552353c425c7baa6831ab0c
stack frame size of 4416 bytes in function 'atags_to_fdt'
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I07d22e8ca0006b8797a0cfaf42d93e46fdd4ee5c
Some clk gates on Rockchip SoCs are part of the SGRF (secure general
register files) and thus only controllable from secure mode, with the
most prominent example being the watchdog.
In most cases we still want to define this as a real clock though,
to have complete clock tree and not reference the generic base-clock
from the devicetree.
So far we've just defined this as factor-1-1 clocks in the clock init,
so define a special clock-type for it so that this definition can be
part of the general tree-definition and save some boilerplate code.
Change-Id: I19ba9125781812dccb5703a9d914253ef54de7c5
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
(cherry picked from commit b3b723d8c4)
There is not need to set dev name without address.
Fixes: 76f27bdd76 ("drm: bridge: dw-hdmi: using extcon instead of switch")
Change-Id: I2c23e29ad8f7b4a0b05b2237ae319e14c69a1cb1
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
caused a bootup regression due to lack of entropy at bootup together
with arguably broken user space that was asking for secure random
numbers when it really didn't need to.
See commit 72dbcf7215 (Revert "ext4: make __ext4_get_inode_loc plug").
This aims to solve the issue by actively generating entropy noise using
the CPU cycle counter when waiting for the random number generator to
initialize. This only works when you have a high-frequency time stamp
counter available, but that's the case on all modern x86 CPU's, and on
most other modern CPU's too.
What we do is to generate jitter entropy from the CPU cycle counter
under a somewhat complex load: calling the scheduler while also
guaranteeing a certain amount of timing noise by also triggering a
timer.
I'm sure we can tweak this, and that people will want to look at other
alternatives, but there's been a number of papers written on jitter
entropy, and this should really be fairly conservative by crediting one
bit of entropy for every timer-induced jump in the cycle counter. Not
because the timer itself would be all that unpredictable, but because
the interaction between the timer and the loop is going to be.
Even if (and perhaps particularly if) the timer actually happens on
another CPU, the cacheline interaction between the loop that reads the
cycle counter and the timer itself firing is going to add perturbations
to the cycle counter values that get mixed into the entropy pool.
As Thomas pointed out, with a modern out-of-order CPU, even quite simple
loops show a fair amount of hard-to-predict timing variability even in
the absense of external interrupts. But this tries to take that further
by actually having a fairly complex interaction.
This is not going to solve the entropy issue for architectures that have
no CPU cycle counter, but it's not clear how (and if) that is solvable,
and the hardware in question is largely starting to be irrelevant. And
by doing this we can at least avoid some of the even more contentious
approaches (like making the entropy waiting time out in order to avoid
the possibly unbounded waiting).
Change-Id: I77f527785e5d3fa90c14c8887201c2c0ae8b85db
Cc: Ahmed Darwish <darwish.07@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Nicholas Mc Guire <hofrat@opentech.at>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 50ee7529ec)
Base the Change-Id: I14ae67d0bfa76d2581eebae100ebf6bad15f8614
One task attach once instead of each fd translate.
Change-Id: I158ef1ee32f9e7a62dc45de3f25de4decee8c112
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
The current driver set CC pull up current to 180uA, but FUSB302B was
designed with 80uA for sink detection which means it only guarantee
FUSB302B will works well with that setting. So we change the CC pull
up current to 80uA.
Change-Id: I5bcb0caaffafbcdf7972396b64f296606bbf3986
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
We found that the Type-C OTG cable was plugged in while the system
was suspending, it may fail to detect the Type-C OTG cable after
resume. That's because the fusb302 registers will fail to operate
during suspend, this will cause the fusb302 CC logic to be abnormal.
So we should not operate queue_work function while the suspend.
Change-Id: Idc675c25de5452ec39513eb484cfaa75534790cd
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
4.19 kernel will check mode valid before encoder atomic check
when resolution switch. Because when checking mode the
detailed color format and color depth are not considered, some
mode can be mistaken for unsupported, such as 4K-60HZ YUV420 10 bits.
So bus width should be set 8 bits when check mode valid.
Change-Id: I0869868b73060bc0f539243d7fccb6c775141ec4
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
some broadcom bt chip need bt host wake is high level when power on,
like ap6356
Change-Id: I509268b84d22b8c17a0996cdd3b2c3e4e05af1bb
Signed-off-by: Weiguo Hu <hwg@rock-chips.com>
