dev_err() can be replace with dev_err_probe() which will check if error
code is -EPROBE_DEFER.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dev_err() can be replace with dev_err_probe() which will check if error
code is -EPROBE_DEFER.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dev_err() can be replace with dev_err_probe() which will check if error
code is -EPROBE_DEFER.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dev_err() can be replace with dev_err_probe() which will check if error
code is -EPROBE_DEFER.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dev_err() can be replace with dev_err_probe() which will check if error
code is -EPROBE_DEFER.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge the mmc fixes for v6.0rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.1.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This loop intends to retry a max of 10 times, with some implicit
termination based on the SD_{R,}OCR_S18A bit. Unfortunately, the
termination condition depends on the value reported by the SD card
(*rocr), which may or may not correctly reflect what we asked it to do.
Needless to say, it's not wise to rely on the card doing what we expect;
we should at least terminate the loop regardless. So, check both the
input and output values, so we ensure we will terminate regardless of
the SD card behavior.
Note that SDIO learned a similar retry loop in commit 0797e5f145
("mmc: core: Fixup signal voltage switch"), but that used the 'ocr'
result, and so the current pre-terminating condition looks like:
rocr & ocr & R4_18V_PRESENT
(i.e., it doesn't have the same bug.)
This addresses a number of crash reports seen on ChromeOS that look
like the following:
... // lots of repeated: ...
<4>[13142.846061] mmc1: Skipping voltage switch
<4>[13143.406087] mmc1: Skipping voltage switch
<4>[13143.964724] mmc1: Skipping voltage switch
<4>[13144.526089] mmc1: Skipping voltage switch
<4>[13145.086088] mmc1: Skipping voltage switch
<4>[13145.645941] mmc1: Skipping voltage switch
<3>[13146.153969] INFO: task halt:30352 blocked for more than 122 seconds.
...
Fixes: f2119df6b7 ("mmc: sd: add support for signal voltage switch procedure")
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220914014010.2076169-1-briannorris@chromium.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Arne Wendt writes:
Cheap clone controllers may (falsely) report as having a user
calibration for the analog sticks in place, but return
wrong/impossible values for the actual calibration data.
In the present case at mine, the controller reports having a
user calibration in place and successfully executes the read
commands. The reported user calibration however is
min = center = max = 0.
This pull request addresses problems of this kind by checking the
provided user calibration-data for plausibility (min < center < max)
and falling back to the default values if implausible.
I'll note that I was experiencing a crash because of this bug when using
the GuliKit KingKong 2 controller. The crash manifests as a divide by
zero error in the kernel logs:
kernel: divide error: 0000 [#1] PREEMPT SMP NOPTI
Link: https://github.com/nicman23/dkms-hid-nintendo/pull/25
Link: https://github.com/DanielOgorchock/linux/issues/36
Co-authored-by: Arne Wendt <arne.wendt@tuhh.de>
Signed-off-by: Johnothan King <johnothanking@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/gvpL2G6VwXGJPvxX5KRiu9pVjvTivgayug_jdKDY6zfuAaAqncP9BkKLosjwUXNlgVVTMfJSKfwPF1K79cKAkwGComyC21vCV3q9B3EXNkE=@protonmail.com
Let's enable ACPI_HMAT, ACPI_HOTPLUG_MEMORY, MEMORY_HOTPLUG
and MEMORY_HOTREMOVE for more test coverage, also there are
useful for heterogeneous memory scene.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220629093524.34801-1-wangkefeng.wang@huawei.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The selection of PMUs enabled in the defconfig is currently a bit random
and does not include a number of those provided by Arm and present in a
fairly wide range of SoCs. Improve coverage and defconfig utility by
enabling all the Arm provided PMUs by default.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: James Clark <james.clark@arm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20220919162753.3079869-1-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Now, register_pernet_subsys() and register_netdevice_notifier() are both
after sock_register(). It can create PF_PACKET socket and process socket
once sock_register() successfully. It is possible PF_PACKET socket is
creating but register_pernet_subsys() and register_netdevice_notifier()
are not registered yet. Thus net->packet.sklist_lock and net->packet.sklist
will be accessed without initialization that is done in packet_net_init().
Although this is a low probability scenario.
Move register_pernet_subsys() and register_netdevice_notifier() to the
front in packet_init(). Correspondingly, adjust the unregister process
in packet_exit().
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If aq_nic_stop() fails, aq_ndev_close() returns err without calling
aq_nic_deinit() to release the relevant memory and resource, which
will lead to a memory leak.
We can fix it by deleting the if condition judgment and goto statement to
call aq_nic_deinit() directly after aq_nic_stop() to fix the memory leak.
Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Return value directly from pskb_trim_rcsum() instead of
getting value from redundant variable err.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jinpeng Cui <cui.jinpeng2@zte.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Nathan reports that the build fails when using clang and LTO:
| In file included from kernel/bounds.c:10:
| In file included from ./include/linux/page-flags.h:10:
| In file included from ./include/linux/bug.h:5:
| In file included from ./arch/arm64/include/asm/bug.h:26:
| In file included from ./include/asm-generic/bug.h:5:
| In file included from ./include/linux/compiler.h:248:
| In file included from ./arch/arm64/include/asm/rwonce.h:11:
| ./arch/arm64/include/asm/alternative-macros.h:224:2: error: call to undeclared function 'BUILD_BUG_ON'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
| BUILD_BUG_ON(feature >= ARM64_NCAPS);
| ^
| ./arch/arm64/include/asm/alternative-macros.h:241:2: error: call to undeclared function 'BUILD_BUG_ON'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
| BUILD_BUG_ON(feature >= ARM64_NCAPS);
| ^
| 2 errors generated.
... the problem being that when LTO is enabled, <asm/rwonce.h> includes
<asm/alternative-macros.h>, and causes a circular include dependency
through <linux/bug.h>. This manifests as BUILD_BUG_ON() not being
defined when used within <asm/alternative-macros.h>.
This patch avoids the problem and simplifies the include dependencies by
using compiletime_assert() instead of BUILD_BUG_ON().
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Fixes: 21fb26bfb0 ("arm64: alternatives: add alternative_has_feature_*()")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: http://lore.kernel.org/r/YyigTrxhE3IRPzjs@dev-arch.thelio-3990X
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220920140044.1709073-1-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The mmc subsystem supports triggering leds on card activity, document
the trigger value here. The value is a pattern in this case.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
To: linux-leds@vger.kernel.org
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Rob Herring <robh@kernel.org>
LEDs would behave differently depending on the blink hardware
acceleration configuration. This commit will make LEDs respond exactly
the same independently of the hardware acceleration status.
In other words, if you had two pca963x, side by side, one with blink
hardware acceleration "ON" and the other "OFF; and performed some
arbitrary sequence of API calls (e.g. turn on/off, change brightness,
change blink mode, etc.) you probably would end with not matching LED
states.
'pca963x software blink' and 'leds-gpio' behavior were used as
reference.
Actual chip used to validate this change: pca9634
Some of the unmatched behaviors being fixed are (when hw blink was "ON")
- Leds would stop blinking when the brightness was changed.
- Leds would persist their blinking mode even after being
turned off (brightness = 0).
- Leds would only blink if another led was solid (pca963x will be
forced out of low power)
Signed-off-by: Bernardo Rodrigues <bernardocrodrigues@live.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Coccinelle reports a warning:
WARNING: use scnprintf or sprintf
This LWN article explains the rationale for this change:
https: //lwn.net/Articles/69419/
Ie. snprintf() returns what *would* be the resulting length,
while scnprintf() returns the actual length.
Adding to that, there has also been some slow migration from snprintf to scnprintf,
here's the shift in usage in the past 3.5 years, in all fs/ files:
v5.0 v6.0-rc6
--------------------------------------
snprintf() uses: 63 213
scnprintf() uses: 374 186
No intended change in behavior.
[ mingo: Improved the changelog & reviewed the usage sites. ]
Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The entries in the .parainstructions sections are 8 byte aligned and the
corresponding C struct paravirt_patch_site makes the array offset 16
bytes.
Though the pushed entries are only using 12 bytes, __parainstructions_end
is therefore 4 bytes short.
That works by chance because it's only used in a loop:
for (p = start; p < end; p++)
But this falls flat when calculating the number of elements:
n = end - start
That's obviously off by one.
Ensure that the gap is filled and the last entry is occupying 16 bytes.
[ bp: Add the proper struct and section names. ]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20220915111142.992398801@infradead.org
It is useful for the debugging to print also the used HDA codec NIDs
used for the given HDMI device. With the dynamic converter assignment
the converter NID is changed dynamically.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220921093349.82680-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The is_posix_acl_xattr() helper was added in 0c5fd887d2 ("acl: move
idmapped mount fixup into vfs_{g,s}etxattr()") to remove the open-coded
checks for POSIX ACLs. We missed to update two locations. Switch them to
use the helper.
Cc: Seth Forshee (DigitalOcean) <sforshee@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Reviewed-by: Seth Forshee (DigitalOcean) <sforshee@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Range size of 0x2b4 was incorrect since there isn't 173 configurable
pins for muxing. Additionally there is a non-addressable region in the
mapping which requires splitting into two ranges.
main_pmx0 -> 67 pins
main_pmx1 -> 3 pins
Fixes: d361ed8845 ("arm64: dts: ti: Add support for J7200 SoC")
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20220919205723.8342-1-mranostay@ti.com
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them.
It is less verbose and it improves the semantic.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
The ubifs_compress() function does not compress the data When the
data length is short than 128 bytes or the compressed data length
is not ideal.It cause that the compressed length of the truncated
data in the truncate_data_node() function may be greater than the
length of the raw data read from the flash.
The above two lengths are transferred to the ubifs_encrypt()
function as parameters. This may lead to assertion fails and then
the file system becomes read-only.
This patch use the actual length of the data in the memory as the
input parameter for assert comparison, which avoids the problem.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216213
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
there is an unexpected word 'a' in the comments that need to be dropped
file - drivers/mtd/ubi/vmt.c
line - 626,779
* Returns zero if volume is all right and a a negative error code if not.
changed to:
* Returns zero if volume is all right and a negative error code if not.
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Various spelling mistakes in comments.
Detected with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Richard Weinberger <richard@nod.at>
There are a typo(dont't) in comments.
Fix it.
Signed-off-by: Zhang Jiaming <jiaming@nfschina.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Delete the redundant word 'a'.
Delete the redundant word 'the'.
Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
This condition was accidentally changed from "if (status < 0)" to
"if (status)". The platform_get_irq() function returns non-zero
positive values on success so, unfortunately, the driver could not be
used. Change the condition back to how it was.
Fixes: f4ca8c88c2 ("spi: omap2-mcspi: Switch to use dev_err_probe() helper")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/Yyq8Q/kd301wVzg8@kili
Signed-off-by: Mark Brown <broonie@kernel.org>
Just fix compile error without any logic changes.
sound/soc/sunxi/sun50i-dmic.c:62:1: error: ‘static’ is not at beginning of declaration [-Werror=old-style-declaration]
62 | const static struct dmic_rate dmic_rate_s[] = {
| ^~~~~
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
Link: https://lore.kernel.org/r/20220921033819.2188233-1-zengheng4@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add devicetree parameters to control the insertion, release and press
debounce times.
Signed-off-by: Astrid Rost <astrid.rost@axis.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220921081834.22009-3-astrid.rost@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
This patchset was submitted earlier in April 2022 as part of the
"ASoC: SOF: add INTEL_IPC4 plumbing" series. As requested the SKL/KBL
support is moved to a different series.
This update adds minor style fixes and the ops that were missing at
the time. SKL and KBL daily tests have been running for several months
and helped identify missing sequences in the SOF driver for HDaudio
links, or platform differences that the driver did not account for
(number of pipelines, etc).
Note that this capability is not recommended for any distribution, it
is ONLY for SOF IPC4 CI tests on HDaudio devices, we will not extend
this SKL/KBL support for I2S devices based on ES8336 or Chromebooks
which are ONLY supported by the AVS driver.
Merge series from V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com>:
This series consists of
1.Make ACP core code generic for newer SOC transition
2.Add support for Rembrandt plaform
3.Adding amd HS functionality to the sof core
4.increase SRAM inbox and outbox size to 1024
Merge series from Mario Limonciello <mario.limonciello@amd.com>:
Another model from ASUS and Lenovo have been identified that
don't include anything in ACPI tables to indicate they require the
ACP6x DMIC driver to be loaded.
This series adds them both to the quirk list.
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Remove the repeated ';' from code, it is not
needed.
Signed-off-by: Li zeming <zeming@nfschina.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
[rw: Massaged commit message a bit]
Signed-off-by: Richard Weinberger <richard@nod.at>
Some Pro Controller compatible controllers do not support home LED, and
will fail when setting it. Currently this leads to probe failure.
Change the code that fails probing to deregistering home LED.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Daniel J. Ogorchock <djogorchock@gmail.com>
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
[bentiss: changed "dflt" to "default"]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20220415100432.23453-1-icenowy@aosc.io
Commit 91a178258a ("netfilter: rpfilter: Convert
rpfilter_lookup_reverse to new dev helper") removed the need for the
'ret' variable. This went unnoticed because of the __maybe_unused
annotation.
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
When the SPDX-License-Identifier tag has been added, the corresponding
license text has not been removed.
Remove it now.
Also, in xt_connmark.h, move the copyright text at the top of the file
which is a much more common pattern.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Florian Westphal <fw@strlen.de>
The previous commit changed the way the rescheduling delay is computed
which has a side effect: the bias is now represented as much as the
other entries in the rescheduling delay which makes the logic to kick in
only with very large sets, as the initial interval is very large
(INT_MAX).
Revisit the GC initial bias to allow more frequent GC for smaller sets
while still avoiding wakeups when a machine is mostly idle. We're moving
from a large initial value to pretending we have 100 entries expiring at
the upper bound. This way only a few entries having a small timeout
won't impact much the rescheduling delay and non-idle machines will have
enough entries to lower the delay when needed. This also improves
readability as the initial bias is now linked to what is computed
instead of being an arbitrary large value.
Fixes: 2cfadb761d ("netfilter: conntrack: revisit gc autotuning")
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Commit 2cfadb761d ("netfilter: conntrack: revisit gc autotuning")
changed the eviction rescheduling to the use average expiry of scanned
entries (within 1-60s) by doing:
for (...) {
expires = clamp(nf_ct_expires(tmp), ...);
next_run += expires;
next_run /= 2;
}
The issue is the above will make the average ('next_run' here) more
dependent on the last expiration values than the firsts (for sets > 2).
Depending on the expiration values used to compute the average, the
result can be quite different than what's expected. To fix this we can
do the following:
for (...) {
expires = clamp(nf_ct_expires(tmp), ...);
next_run += (expires - next_run) / ++count;
}
Fixes: 2cfadb761d ("netfilter: conntrack: revisit gc autotuning")
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
meson NFC driver only uses common clock interfaces, which triggers kernel test
robot errors when using legacy clocks with HAVE_LEGACY_CLK on.
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Liang Yang <liang.yang@amlogic.com>
[miquel.raynal@bootlin.com: Rephrase the commit log]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220907080405.28240-6-liang.yang@amlogic.com
simply use devm_platform_ioremap_resource_byname() instead of two steps:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0) and
reg_base = devm_ioremap_resource(dev, res)
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Liang Yang <liang.yang@amlogic.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220907080405.28240-4-liang.yang@amlogic.com
EMMC and NAND have the same clock control register named 'SD_EMMC_CLOCK'
which is defined in EMMC port internally. bit0~5 of 'SD_EMMC_CLOCK' is
the divider and bit6~7 is the mux for fix pll and xtal. At the beginning,
a common MMC and NAND sub-clock was discussed and planed to be implemented
as NFC clock provider, but now this series of patches of a common MMC and
NAND sub-clock are never being accepted. the reasons for giving up are:
1. EMMC and NAND, which are mutually exclusive anyway
2. coupling the EMMC and NAND.
3. it seems that a common MMC and NAND sub-clock is over engineered.
and let us see the link fot more information:
https://lore.kernel.org/all/20220121074508.42168-5-liang.yang@amlogic.com
so The meson nfc can't work now, let us rework the clock.
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Liang Yang <liang.yang@amlogic.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220907080405.28240-3-liang.yang@amlogic.com
