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>
The div offset of some clocks are different from their mux offset
and the COMPOSITE clock-type require that div and mux offset are
the same, so add a new COMPOSITE_DIV_OFFSET clock-type to handle
that.
Change-Id: I1c97f7464c3c80ea6dbd7d4052565dd4e35c0931
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Avoid clang warning:
s/select.c:594:5: warning: stack frame size of 1056 bytes in function 'core_sys_select' [-Wframe-larger-than=]
int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp,
^
net/core/ethtool.c:2628:5: warning: stack frame size of 1216 bytes in function 'dev_ethtool' [-Wframe-larger-than=]
int dev_ethtool(struct net *net, struct ifreq *ifr)
^
Change-Id: Id2d961993e9823fe74854d33cd24d28869a541ef
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
drivers/net/wireless/rockchip_wlan/rtl8723cs/os_dep/linux/ioctl_cfg80211.c:3876:20: warning: implicit conversion from enumeration type 'enum mlme_auth_type' to different enumeration type 'enum nl80211_auth_type' [-Wenum-conversion]
sme->auth_type = MLME_AUTHTYPE_SAE;
~ ^~~~~~~~~~~~~~~~~
MLME_AUTHTYPE_SAE == NL80211_AUTHTYPE_SAE, so this fix is safe.
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: Ia3fc1afc6375cc86168c0d9a744e0817df9614c7
drivers/net/wireless/rockchip_wlan/rtl8723cs/os_dep/linux/rtw_cfgvendor.c:177:25: warning: implicit conversion from 'unsigned int' to 'u16' (aka 'unsigned short') changes value from 4718624 to 32 [-Wconstant-conversion]
kflags = in_atomic() ? GFP_ATOMIC : GFP_KERNEL;
~ ^~~~~~~~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I2ade593775f56ef2276ff9e13aed5c0bb70132d6
drivers/net/wireless/rockchip_wlan/rtl8822bs/os_dep/linux/rtw_cfgvendor.c:177:25: warning: implicit conversion from 'unsigned int' to 'u16' (aka 'unsigned short') changes value from 4718624 to 32 [-Wconstant-conversion]
kflags = in_atomic() ? GFP_ATOMIC : GFP_KERNEL;
~ ^~~~~~~~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I4b648f20f665f563d7af7130d983918ff4889100
drivers/video/rockchip/rga2/rga2_mmu_info.c:326:20: warning: explicitly assigning value of variable of type 'uint32_t' (aka 'unsigned int') to itself [-Wself-assign]
stride = stride;
~~~~~~ ^ ~~~~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I8143bbe53f4e106c6b875e2db562d11240d7de34
