The Meegopad T02 is a PC in stick format and doesn't have a battery,
it is reported with a random and constant battery charge but as
discharging to userspace.
Add it to the blacklist to avoid the bogus battery status reporting.
Signed-off-by: Rafael Gandolfi <rafirafi.at@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
vc4's firmware bus DMA limitations") as it turned out to be faulty
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAl5+ZSAACgkQlfZmHno8
x/7fWQf/SODT8sooJto4VFAbsDjXjNPmkqXBvFxYcPVN67ET2pSFdiGpGV4/Zt0+
/f1/niWVvOXL8j4MicEjhQeRwRCznzBHb07PW33ynf6i7u+b3eGr/gbfFckbpSsV
FhN5/5rcH7ebnsekGRG3c0386IGtRZW3xE4Dk2wLcRv3qhgs98y+U8s5vGlaxXG6
KAim6SUlh+FZak58CcVovBUe30HpX9vxuuHUk8mzhhrDEbZqDY2VW4VkhcagnAc8
y6X0mriyv6EoJdDzPQtlq94c/siNKIEbrJ/E5ozUU3ZNAs4nu2KIoru0lhXgaNl9
rMnHqEKCCF1/8gXeN1+t2DHXBfVvkA==
=/iN4
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl6U7aoACgkQh9CWnEQH
BwQcxA//d+oVlxMvuIJ0mN8vrorEUSLJYee1+yxEU5SrDFWey4Bs0JeSwT6DbMf8
bs9AY9hsmmeBW0LDgm6L0aY7FZFV7G2BhnMT3lqfuQ9vGpRYLQEARU4XUtmwq/YA
FEc4eBKPNGgs8+IVQQjLlbx/UuwJG0ocA/CPDJc8TwSMOE0mga6D++Ovd4WLTc9s
7XDTWa3hcbX5YRkHhM0quu+X2v4ed/fDZbM6UBDaqditL+ziKWnFAMrw0WZDDcfm
Go/j4lIjOiQE0MsZUzWsWfFXx8YSr15D5X8zGT5h4EslIQVvzEm6K69+1Bg8BfPF
EAEVxguekifzjVYkTV5TW6aNIH7DjhwGJeov3fqz4fAD+whW3CC+OL/JPQZh4U2L
fm5dGNRrV80HjkGV+pJiBl4uMg8Ezhjpc/b2stsElvCxwVbQLVhsCVvKOVj5g5ip
JELyYJ7N4KkEzlXTQnihAvF+VLBbhGDn0BCI/IZLjsUt2s3QoOIb5rcon+Ouu9/P
CnVNEHe2Pdaq8j2Lom76sbNAtjIDWGwTKeFDRZWk75s/m11Raq6J4r/c9oX0bR5v
GmSftZQ7VgAbbp9ynrgw0+7inroA6iLPnsIJccNiHABxZ4I083UFUlXBYYvWq5hH
eEU2gny6Bp52S0oF7U3UTxQXuGz4bAfiNTTLbG6cGGBwm778TxM=
=gRon
-----END PGP SIGNATURE-----
Merge tag 'tags/bcm2835-dt-fixes-2020-03-27' into devicetree/fixes
This patch is to be squashed into 55c7c06210 ("ARM: dts: bcm283x: Fix
vc4's firmware bus DMA limitations") as it turned out to be faulty
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
- Second patch adds a fixed regulator that controls the SD power and
hooks it up with emmc2.
- Third patch rolls back to the firmware based power driver as the MMIO
version is unstable.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAl5+ZkYACgkQlfZmHno8
x/51Iwf/XKTwPJsNu3qaPeLZP6r3sMUSpIkb09+uF48ecYT2kKltMSWy4AMRILx1
GuPVyfhH9EOL7kf2pui+DotWfZ6V0w8QXmw+h5jmvrSL7HmNj7t+AUvlX765h/9/
tb+6/3Yum+GJwrG7mSmBCXvV4S5ReCdifmNse1WujgX5AfLZ/8SSdLl7/vwl5UTn
xkhGyGjGNwiabqwVZGAbhnv12IBsWPm7KAjpkPZRp6Yuyf9uawgnoNlIh4HDmH78
PBsXVoBlqlfBdroIVjjiUtcrqQIXxm4vcAwlCTXVKYC0boZib226a7D+bjrbVtRY
ou521MEikPI+tnydzQErBq7Ktj0SiA==
=q1oY
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl6U7XMACgkQh9CWnEQH
BwTZFRAAj6RJzy61lcjwEALvCGZqTs/n17Ecpnd7BD+nfv8Ug2umEYrvDalvVOAg
uTPKGM2feA/eWks+bFSgF8auPnHdO+XBm8FmDJAMr8/fN6mP5Fm8pcBqS59U9lOb
ASRzIBjOK06SFkFzMas0AVtLMaRo/DwsASqx8Bc6UHxI9ZMKIaBRHChdaDTiH3md
5JinxSmOkPaAX+wB0rcpVIL/T3pSf5I6DrXCkhU0dsER2NxRiYdvnAdyE12i4emn
FCVplHyUCyzicU/qtwMBNqBfpTVOZ5PT9WAotMN329Csy0D95QKTUPuri0F3qOXW
UeuE9UPex1ZOF3kNhLlFmlZRBaPaQsih2EEQOdKenZWffj5RXLVjGjmAYoHj6rew
7BoEpEiPCAZWPAOyEWg9OqvOd5z7Dj7Xr1ukfGuf1UZ01ZsmTvrUyNIELRPFpRg9
6Z+X2iH/pU9VwvBhloT/8lWKdRF0TAE8PJR5NnXFn2SFKZ+Fue2ubaJ0dMjAeAqK
/mQFod5+QbKcZkG65L2GY6+C1rj3ZVxEx+dUZxtfTQqPDsTPRjl08YjvFgmzT6LD
VhzVnw+dzUPo0BM0MrjxwjryRkdQW1iMijvXzRa7qsYbRW4dZc/kig57Xft6L0zQ
hi9dvfPgJYbEnwn24WYkbksbPt1jTCAwekNm1V5ks9o/mOSogSA=
=Aotf
-----END PGP SIGNATURE-----
Merge tag 'tags/bcm2835-dt-next-2020-03-27' into devicetree/next
- First patch updates RPi4's expgpio's GPIO labels, adding the SD power rail.
- Second patch adds a fixed regulator that controls the SD power and
hooks it up with emmc2.
- Third patch rolls back to the firmware based power driver as the MMIO
version is unstable.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.
This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.
v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
v7: Added Cc stable
Testcase: igt/perf/polling-small-buf
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200403010120.3067-1-ashutosh.dixit@intel.com
(cherry-picked from commit 6352219c39)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fix the following gcc warning:
drivers/power/supply/max14656_charger_detector.c:142:6: warning:
variable ‘ret’ set but not used [-Wunused-but-set-variable]
int ret = 0;
^~~
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The commit c31427d0d2 ("ALSA: hda: No preallocation on x86
platforms") changed CONFIG_SND_HDA_PREALLOC_SIZE setup and its default
to zero for x86, as the preallocation should work almost all cases.
However, this expectation was too naive; some applications try to
allocate as the max buffer size as possible, and it leads to the
memory exhaustion. More badly, the commit changed the kconfig no
longer adjustable for x86, so you can't fix it statically (although it
can be still adjusted via procfs).
So, practically seen, it's more recommended to set a reasonable limit
for x86, too. This patch follows to that experience, and changes the
default to 2048 and allow the kconfig adjustable again.
Fixes: c31427d0d2 ("ALSA: hda: No preallocation on x86 platforms")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223
Link: https://lore.kernel.org/r/20200413201919.24241-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merging 5.7 fixes branch as of April 13, containing two fixes to branch
destined for chrome-platform-5.8.
538b8471fe platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages
5b69c23799 platform/chrome: cros_ec_sensorhub: Off by one in cros_sensorhub_send_sample()
Signed-off-by: Benson Leung <bleung@chromium.org>
We need to drop the inode spinlock while calling nfs4_select_rw_stateid(),
since nfs4_copy_delegation_stateid() could take the delegation lock.
Note that it is safe to do this, since all other calls to
pnfs_update_layout() for that inode will find themselves blocked by
the lock we hold on NFS_LAYOUT_FIRST_LAYOUTGET.
Fixes: fc51b1cf39 ("NFS: Beware when dereferencing the delegation cred")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Don't gate uart1_eb which provides console clock, gating that clock would
make serial stop working if serial driver didn't enable that explicitly.
Fixes: 0e4b8a2349 ("clk: sprd: add clocks support for SC9863A")
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Link: https://lkml.kernel.org/r/20200408020234.31764-1-zhang.lyra@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The newly added function is only built into the kernel if mmp2
is enabled, causing a link error otherwise.
arm-linux-gnueabi-ld: drivers/clk/mmp/clk.o: in function `mmp_register_pll_clks':
clk.c:(.text+0x6dc): undefined reference to `mmp_clk_register_pll'
Move it to a different file to get it to link.
Fixes: 5d34d0b32d ("clk: mmp2: Add support for PLL clock sources")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lkml.kernel.org/r/20200408160518.2798571-1-arnd@arndb.de
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The __clk_hw_register_fixed_rate_with_accuracy() function (with two '_')
does not exist, and apparently never did:
drivers/clk/clk-asm9260.c: In function 'asm9260_acc_init':
drivers/clk/clk-asm9260.c:279:7: error: implicit declaration of function '__clk_hw_register_fixed_rate_with_accuracy'; did you mean 'clk_hw_register_fixed_rate_with_accuracy'? [-Werror=implicit-function-declaration]
279 | hw = __clk_hw_register_fixed_rate_with_accuracy(NULL, NULL, pll_clk,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| clk_hw_register_fixed_rate_with_accuracy
drivers/clk/clk-asm9260.c:279:5: error: assignment to 'struct clk_hw *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
279 | hw = __clk_hw_register_fixed_rate_with_accuracy(NULL, NULL, pll_clk,
| ^
From what I can tell, __clk_hw_register_fixed_rate() is the correct
API here, so use that instead.
Fixes: 728e309674 ("clk: asm9260: Use parent accuracy in fixed rate clk")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lkml.kernel.org/r/20200408155402.2138446-1-arnd@arndb.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Original cgroup v2 eBPF code for filtering device access made it
possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF
filtering. Change
commit 4b7d4d453f ("device_cgroup: Export devcgroup_check_permission")
reverted this, making it required to set it to y.
Since the device filtering (and all the docs) for cgroup v2 is no longer
a "device controller" like it was in v1, someone might compile their
kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF
filter will not be invoked, and all processes will be allowed access
to all devices, no matter what the eBPF filter says.
Signed-off-by: Odin Ugedal <odin@ugedal.com>
Acked-by: Roman Gushchin <guro@fb.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The cleanup in commit 630f289b71 ("asm-generic: make more
kernel-space headers mandatory") did not take into account the recently
added line for hardirq.h in commit acc45648b9 ("m68k: Switch to
asm-generic/hardirq.h"), leading to the following message during the
build:
scripts/Makefile.asm-generic:25: redundant generic-y found in arch/m68k/include/asm/Kbuild: hardirq.h
Fix this by dropping the now redundant line.
Fixes: 630f289b71 ("asm-generic: make more kernel-space headers mandatory")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In case command ring buffer becomes inconsistent, tcmu sets device flag
TCMU_DEV_BIT_BROKEN. If the bit is set, tcmu rejects new commands from LIO
core with TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, and no longer processes
completions from the ring. The reset_ring attribute can be used to
completely clean up the command ring, so after reset_ring the ring no
longer is inconsistent.
Therefore reset_ring also should reset bit TCMU_DEV_BIT_BROKEN to allow
normal processing.
Link: https://lore.kernel.org/r/20200409101026.17872-1-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Creation of the response to READ FULL STATUS fails for FC based
reservations. Reason is the too high loop limit (< 24) in
fc_get_pr_transport_id(). The string representation of FC WWPN is 23 chars
long only ("11:22:33:44:55:66:77:88"). So when i is 23, the loop body is
executed a last time for the ending '\0' of the string and thus hex2bin()
reports an error.
Link: https://lore.kernel.org/r/20200408132610.14623-3-bstroesser@ts.fujitsu.com
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This patch fixes a minor flaw that could be triggered by a PR OUT RESERVE
on iSCSI, if TRANSPORT IDs with and without ISID are used in the same
command. In case an ISCSI Transport ID has no ISID, port_nexus_ptr was not
used to write NULL, so value from previous call might persist. I don't
know if that ever could happen, but with the change the code is cleaner, I
think.
Link: https://lore.kernel.org/r/20200408132610.14623-2-bstroesser@ts.fujitsu.com
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add njavali@marvell.com as new maintainer.
Also add Marvell Upstream email alias to the maintainers list.
Link: https://lore.kernel.org/r/20200403084018.30766-3-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/qla2xxx/qla_dbg.c:2542:7: warning: The scope of the variable 'pbuf'
can be reduced. [variableScope]
drivers/scsi/qla2xxx/qla_init.c:3615:6: warning: Variable 'rc' is assigned a
value that is never used. [unreadVariable]
drivers/scsi/qla2xxx/qla_isr.c:81:11-29: WARNING: dma_alloc_coherent use in
rsp_els already zeroes out memory, so memset is not needed
drivers/scsi/qla2xxx/qla_mbx.c:4889:15-33: WARNING: dma_alloc_coherent use in
els_cmd_map already zeroes out memory, so memset is not needed
[mkp: added newline after variable declaration]
Link: https://lore.kernel.org/r/20200403084018.30766-2-njavali@marvell.com
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The new async dirops callback routines can pass ERR_PTR values to
ceph_mdsc_free_path, which could cause an oops. Make ceph_mdsc_free_path
ignore ERR_PTR values. Also, ensure that the pr_warn messages look sane
even if ceph_mdsc_build_path fails.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
If SATA_HOST is n, build fails:
drivers/scsi/hisi_sas/hisi_sas_main.o: In function
`hisi_sas_fill_ata_reset_cmd': hisi_sas_main.c:(.text+0x2500): undefined
reference to `ata_tf_to_fis'
Select SATA_HOST to fix this.
Link: https://lore.kernel.org/r/20200402085812.32948-1-yuehaibing@huawei.com
Fixes: bd322af15c ("ata: make SATA_PMP option selectable only if any SATA host driver is enabled")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: John Garry <john.garry@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If the request has been marked as canceled, don't try and issue it.
Instead just fill a canceled event and finish the request.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Remove "params.h" include, which has been dropped in GCC 10.
Remove is_a_helper() macro, which is now defined in gimple.h, as seen
when running './scripts/gcc-plugin.sh g++ g++ gcc':
In file included from <stdin>:1:
./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’
852 | inline bool is_a_helper<const ggoto *>::test(const_gimple gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./gcc-plugins/gcc-common.h:125,
from <stdin>:1:
/usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here
1037 | is_a_helper <const ggoto *>::test (const gimple *gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid
meaningless warnings from error() formats used by plugins:
scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’:
scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag]
253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org
[kees: include -Wno-format-diag for plugin builds]
Signed-off-by: Kees Cook <keescook@chromium.org>
With GCC version >= 8, the cgraph_create_edge() macro argument using
"frequency" goes unused. Instead of assigning a temporary variable for
the argument, pass the compute_call_stmt_bb_frequency() call directly
as the macro argument so that it will just not be called when it is
not wanted by the macros.
Silences the warning:
scripts/gcc-plugins/stackleak_plugin.c:54:6: warning: variable ‘frequency’ set but not used [-Wunused-but-set-variable]
Now builds cleanly with gcc-7 and gcc-9. Both boot and pass
STACKLEAK_ERASING LKDTM test.
Signed-off-by: Kees Cook <keescook@chromium.org>
Elm is Acer Chromebook R13. Hana is Lenovo Chromebook. Both uses mt8173
SoC.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200210063523.133333-5-hsinyi@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Fixing several unit name warnings:
Warning (unit_address_vs_reg): /oscillator@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /oscillator@1: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /oscillator@2: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@1: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/cpu_crit@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@1: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /reserved-memory/vpu_dma_mem_region: node has a reg or ranges property, but no unit name
Warning (simple_bus_reg): /soc/pinctrl@10005000: simple-bus unit address format error, expected "1000b000"
Warning (simple_bus_reg): /soc/interrupt-controller@10220000: simple-bus unit address format error, expected "10221000"
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Link: https://lore.kernel.org/r/20200210063523.133333-4-hsinyi@chromium.org
[mb: drop fixes for '_' in property name]
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
We added this for just the regular poll requests in commit a6ba632d2c
("io_uring: retry poll if we got woken with non-matching mask"), we
should do the same for the poll handler used pollable async requests.
Move the re-wait check and arm into a helper, and call it from
io_async_task_func() as well.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Add serial as uart aliases in mt8173.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200210063523.133333-3-hsinyi@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Elm is Acer Chromebook R13. Hana is Lenovo Chromebook. Both uses mt8173
SoC.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200210063523.133333-2-hsinyi@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Split a cluster level cpuidle state into two, so mt8183 variant
boards can adjust parameters for each cluster, and reduce cluster0's
default target residency to 1000us as power measurements showed that
its minimum residency is slightly less than cluster1's 1300us.
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/20200225080752.200952-1-ikjn@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
In order to use GCE function, we need add some informations
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Vram lost counter is wrongly increased by two during baco reset.
V2: assumed vram lost for mode1 reset on all ASICs
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The HD-audio controller does system-suspend and resume operations by
directly calling its helpers __azx_runtime_suspend() and
__azx_runtime_resume(). However, in general, we don't have to resume
always the device fully at the system resume; typically, if a device
has been runtime-suspended, we can leave it to runtime resume.
Usually for achieving this, the driver would call
pm_runtime_force_suspend() and pm_runtime_force_resume() pairs in the
system suspend and resume ops. Unfortunately, this doesn't work for
the resume path in our case. For handling the jack detection at the
system resume, a child codec device may need the (literally) forcibly
resume even if it's been runtime-suspended, and for that, the
controller device must be also resumed even if it's been suspended.
This patch is an attempt to improve the situation. It replaces the
direct __azx_runtime_suspend()/_resume() calls with with
pm_runtime_force_suspend() and pm_runtime_force_resume() with a slight
trick as we've done for the codec side. More exactly:
- azx_has_pm_runtime() check is dropped from azx_runtime_suspend() and
azx_runtime_resume(), so that it can be properly executed from the
system-suspend/resume path
- The WAKEEN handling depends on the card's power state now; it's set
and cleared only for the runtime-suspend
- azx_resume() checks whether any codec may need the forcible resume
beforehand. If the forcible resume is required, it does temporary
PM refcount up/down for actually triggering the runtime resume.
- A new helper function, hda_codec_need_resume(), is introduced for
checking whether the codec needs a forcible runtime-resume, and the
existing code is rewritten with that.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043
Link: https://lore.kernel.org/r/20200413082034.25166-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, when the HD-audio controller driver doesn't detect any
codecs, it tries to abort the probe. But this abort happens at the
delayed probe, i.e. the primary probe call already returned success,
hence the driver is never unbound until user does so explicitly.
As a result, it may leave the HD-audio device in the running state
without the runtime PM. More badly, if the device is a HD-audio bus
that is tied with a GPU, GPU cannot reach to the full power down and
consumes unnecessarily much power.
This patch changes the logic after no-codec situation; it continues
probing without the further codec initialization but keep the
controller driver running normally.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043
Tested-by: Roy Spliet <nouveau@spliet.org>
Link: https://lore.kernel.org/r/20200413082034.25166-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix the following gcc warning:
drivers/gpu/drm/radeon/ci_dpm.c:82:36: warning: ‘defaults_saturn_pro’
defined but not used [-Wunused-const-variable=]
static const struct ci_pt_defaults defaults_saturn_pro =
^~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/radeon/ci_dpm.c:68:36: warning: ‘defaults_bonaire_pro’
defined but not used [-Wunused-const-variable=]
static const struct ci_pt_defaults defaults_bonaire_pro =
^~~~~~~~~~~~~~~~~~~~
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix the following gcc warning:
drivers/gpu/drm/radeon/si_dpm.c:255:33: warning: ‘dte_data_tahiti_le’
defined but not used [-Wunused-const-variable=]
static const struct si_dte_data dte_data_tahiti_le =
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This code is dead, let's remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Let format prefixes take care of printing the module name
through pr_fmt and dev_fmt definitions.
Signed-off-by: Aurabindo Pillai <mail@aurabindo.in>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
snd-hda-intel driver handles the most of its probe task in the delayed
work (either via workqueue or via firmware loader). When an error
happens in the later delayed probe, we can't deregister the device
itself because the probe callback already returned success and the
device was bound. So, for now, we set hda->init_failed flag and make
the rest untouched until the device gets really unbound.
However, this leaves the device up running, keeping the resources
without any use that prevents other operations.
In this patch, we release the resources at first when a probe error
happens in the delayed probe stage, but keeps the top-level object, so
that the PM and other ops can still refer to the object itself.
Also for simplicity, snd_hda_intel object is allocated via devm, so
that we can get rid of the explicit kfree calls.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043
Link: https://lore.kernel.org/r/20200413082034.25166-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
amdgpu uses lots of pr_* calls for printing error messages.
With this prefix, errors shall be more obvious to the end
use regarding its origin, and may help debugging.
Prefix format:
[xxx.xxxxx] amdgpu: ...
Signed-off-by: Aurabindo Pillai <mail@aurabindo.in>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix the following gcc warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_hw_sequencer.c:43:46:
warning: ‘reg_offsets’ defined but not used [-Wunused-const-variable=]
static const struct dce80_hw_seq_reg_offsets reg_offsets[] = {
^~~~~~~~~~~
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Set up a GPU scheduler based on the ring flag rather
than the ring type.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We don't want a GPU scheduler for this ring.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This allows IPs to flag whether a specific ring requires
a GPU scheduler or not. E.g., sometimes instances of an
IP are asymmetric and have different capabilities.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
