- 12 Feb, 2019 40 commits
-
-
YueHaibing authored
[ Upstream commit fa89a459 ] gcc warn this: net/ipv6/xfrm6_tunnel.c:143 __xfrm6_tunnel_alloc_spi() warn: always true condition '(spi <= 4294967295) => (0-u32max <= u32max)' 'spi' is u32, which always not greater than XFRM6_TUNNEL_SPI_MAX because of wrap around. So the second forloop will never reach. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Johannes Berg authored
[ Upstream commit efc38dd7 ] Due to the alignment handling, it actually matters where in the code we add the 4 bytes for the presence bitmap to the length; the first field is the timestamp with 8 byte alignment so we need to add the space for the extra vendor namespace presence bitmap *before* we do any alignment for the fields. Move the presence bitmap length accounting to the right place to fix the alignment for the data properly. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit 05a4ab82 ] With the following piece of code, the following compilation warning is encountered: if (_IOC_DIR(ioc) != _IOC_NONE) { int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ; if (!access_ok(verify, ioarg, _IOC_SIZE(ioc))) { drivers/platform/test/dev.c: In function 'my_ioctl': drivers/platform/test/dev.c:219:7: warning: unused variable 'verify' [-Wunused-variable] int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ; This patch fixes it by referencing 'type' in the macro allthough doing nothing with it. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Eric Yang authored
[ Upstream commit 12750d16 ] [Why] YCbCr420 packing format uses two chanels for luma, and 1 channel for both chroma component. Our previous implementation did not account for this and results in every other pixel having very high luma value, showing greyish color instead of black. YCbCr444 = <Y1, Cb1, Cr1>; <Y2, Cb2, Cr2> ..... YCbCr420 = <Y1, Y2, Cb1>; <Y3, Y4, Cr1> ..... [How] Program the second channel with the black color value for luma as well. Signed-off-by:
Eric Yang <Eric.Yang2@amd.com> Reviewed-by:
Hugo Hu <Hugo.Hu@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 28ac03b9 ] On some systems that actually have the bluetooth controller wired up with an extra clock signal, it's possible the bluetooth controller probes before the clock provider. clk_get would return a defer probe error, which was not handled by this driver. Handle this properly, so that these systems can work reliably. Tested-by:
Ondrej Jirman <megous@megous.com> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Paul Hsieh authored
[ Upstream commit bd4905a9 ] [WHY] On customer board, there is one pluse (1v , < 1ms) on DDC_CLK pin when plug / unplug DP cable. Driver will read it and config DP to HDMI/DVI dongle. [HOW] If there is a real dongle, DDC_CLK should be always pull high. Try to read again to recovery this special case. Retry times = 3. Need additional 3ms to detect DP passive dongle(3 failures) Signed-off-by:
Paul Hsieh <paul.hsieh@amd.com> Reviewed-by:
-
Huazhong Tan authored
[ Upstream commit ae6017a7 ] In the hns3_nic_uninit_vector_data(), the procedure of uninitializing the tqp_vector's IRQ has not set affinity_notify to NULL and changes its init flag. This patch fixes it. And for simplificaton, local variable tqp_vector is used instead of priv->tqp_vector[i]. Fixes: 424eb834 ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dennis Zhou authored
[ Upstream commit 6ab7d47b ] From Michael Cree: "Bisection lead to commit b38d08f3 ("percpu: restructure locking") as being the cause of lockups at initial boot on the kernel built for generic Alpha. On a suggestion by Tejun Heo that: So, the only thing I can think of is that it's calling spin_unlock_irq() while irq handling isn't set up yet. Can you please try the followings? 1. Convert all spin_[un]lock_irq() to spin_lock_irqsave/unlock_irqrestore()." Fixes: b38d08f3 ("percpu: restructure locking") Reported-and-tested-by:
Michael Cree <mcree@orcon.net.nz> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Dennis Zhou <dennis@kernel.org> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 866053bb ] To avoid this warning: CC /tmp/build/perf/util/s390-cpumsf.o util/s390-cpumsf.c: In function 's390_cpumsf_samples': util/s390-cpumsf.c:508:3: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'off_t' [-Wformat=] pr_err("[%#08" PRIx64 "] Invalid AUX trailer entry TOD clock base\n", ^ Now the various Android cross toolchains used in the perf tools container test builds are all clean and we can remove this: export EXTRA_MAKE_ARGS="WERROR=0" Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Thomas Richter <tmricht@linux.ibm.com> Link: https://lkml.kernel.org/n/tip-5rav4ccyb0sjciysz2i4p3sx@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 0afcf29b ] Reducing this noise when cross building to the Android NDK: util/header.c: In function 'perf_header__fprintf_info': util/header.c:2710:45: warning: pointer targets in passing argument 1 of 'ctime' differ in signedness [-Wpointer-sign] fprintf(fp, "# captured on : %s", ctime(&st.st_ctime)); ^ In file included from util/../perf.h:5:0, from util/evlist.h:11, from util/header.c:22: /opt/android-ndk-r15c/platforms/android-26/arch-arm/usr/include/time.h:81:14: note: expected 'const time_t *' but argument is of type 'long unsigned int *' extern char* ctime(const time_t*) __LIBC_ABI_PUBLIC__; ^ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lkml.kernel.org/n/tip-6bz74zp080yhmtiwb36enso9@git.kernel.orgSigned-off-by:
-
Bin Liu authored
[ Upstream commit 54578ee8 ] Since the runtime PM support was added in musb, dsps relies on the timer calling otg_timer() to activate the usb subsystem. However the driver doesn't enable the timer for peripheral port, then the peripheral port is unable to be enumerated by a host if the other usb port is disabled or in peripheral mode too. So let's start the timer for peripheral port too. Fixes: ea2f35c0 ("usb: musb: Fix sleeping function called from invalid context for hdrc glue") Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Bin Liu authored
[ Upstream commit 6010abf2 ] Due to lack of ID pin interrupt event on AM335x devices, the musb dsps driver uses polling to detect usb device attach for dual-role port. But in the case if a micro-A cable adapter is attached without a USB device attached to the cable, the musb state machine gets stuck in a_wait_vrise state waiting for the MUSB_CONNECT interrupt which won't happen due to the usb device is not attached. The state is stuck in a_wait_vrise even after the micro-A cable is detached, which could cause VBUS retention if then the dual-role port is attached to a host port. To fix the problem, make a_wait_vrise as a transient state, then move the state to either a_wait_bcon for host port or a_idle state for dual-role port, if no usb device is attached to the port. Signed-off-by:
-
Mark Rutland authored
[ Upstream commit 0d640732 ] When we emulate an MMIO instruction, we advance the CPU state within decode_hsr(), before emulating the instruction effects. Having this logic in decode_hsr() is opaque, and advancing the state before emulation is problematic. It gets in the way of applying consistent single-step logic, and it prevents us from being able to fail an MMIO instruction with a synchronous exception. Clean this up by only advancing the CPU state *after* the effects of the instruction are emulated. Cc: Peter Maydell <peter.maydell@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Christoffer Dall <christoffer.dall@arm.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Nicholas Mc Guire authored
[ Upstream commit 5f30b2e8 ] kzalloc() return should always be checked - notably in example code where this may be seen as reference. On failure of allocation in livepatch_fix1_dummy_alloc() respectively dummy_alloc() previous allocation is freed (thanks to Petr Mladek <pmladek@suse.com> for catching this) and NULL returned. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Fixes: 439e7271 ("livepatch: introduce shadow variable API") Acked-by:
Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Acked-by:
Miroslav Benes <mbenes@suse.cz> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Doug Smythies authored
[ Upstream commit 66354690 ] This script is supposed to be allowed to run with regular user privileges if a previously captured trace is being post processed. Commit fbe31388 (tools/power/x86/intel_pstate_tracer: Free the trace buffer memory) introduced a bug that breaks that option. Commit 35459105 (tools/power/x86/intel_pstate_tracer: Add optional setting of trace buffer memory allocation) moved the code but kept the bug. This patch fixes the issue. Fixes: 35459105 (tools/power/x86/intel_pstate_tracer: Add optional ...) Signed-off-by:
Doug Smythies <dsmythies@telus.net> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Michael Chan authored
[ Upstream commit 36d65be9 ] When bringing up a device, the code checks to see if the number of MSIX has changed. pci_disable_msix() should be called first before changing the number of reserved NQs/CMPL rings. This ensures that the MSIX vectors associated with the NQs/CMPL rings are still properly mapped when pci_disable_msix() masks the vectors. This patch will prevent errors when RDMA support is added for the new 57500 chips. When the RDMA driver shuts down, the number of NQs is decreased and we must use the new sequence to prevent MSIX errors. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Fabrizio Castro authored
[ Upstream commit 51243b73 ] Similarly to R-Car E3, RZ/G2E doesn't come with automatic transmission registers, as such it is not considered compatible with the existing fallback bindings. Add SoC specific binding compatibility to allow for later support for automatic transmission. Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit bef0b897 ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. In this case the 'target' buffer is coming from a list of build-ids that are expected to have a len of at most (SBUILD_ID_SIZE - 1) chars, so probably we're safe, but since we're using strncpy() here, use strlcpy() instead to provide the intended safety checking without the using the problematic strncpy() function. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: util/probe-file.c: In function 'probe_cache__open.isra.5': util/probe-file.c:427:3: error: 'strncpy' specified bound 41 equals destination size [-Werror=stringop-truncation] strncpy(sbuildid, target, SBUILD_ID_SIZE); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: 1f3736c9 ("perf probe: Show all cached probes") Link: https://lkml.kernel.org/n/tip-l7n8ggc9kl38qtdlouke5yp5@git.kernel.orgSigned-off-by:
-
Ethan Lien authored
[ Upstream commit 3cd24c69 ] Snapshot is expected to be fast. But if there are writers steadily creating dirty pages in our subvolume, the snapshot may take a very long time to complete. To fix the problem, we use tagged writepage for snapshot flusher as we do in the generic write_cache_pages(), so we can omit pages dirtied after the snapshot command. This does not change the semantics regarding which data get to the snapshot, if there are pages being dirtied during the snapshotting operation. There's a sync called before snapshot is taken in old/new case, any IO in flight just after that may be in the snapshot but this depends on other system effects that might still sync the IO. We do a simple snapshot speed test on a Intel D-1531 box: fio --ioengine=libaio --iodepth=32 --bs=4k --rw=write --size=64G --direct=0 --thread=1 --numjobs=1 --time_based --runtime=120 --filename=/mnt/sub/testfile --name=job1 --group_reporting & sleep 5; time btrfs sub snap -r /mnt/sub /mnt/snap; killall fio original: 1m58sec patched: 6.54sec This is the best case for this patch since for a sequential write case, we omit nearly all pages dirtied after the snapshot command. For a multi writers, random write test: fio --ioengine=libaio --iodepth=32 --bs=4k --rw=randwrite --size=64G --direct=0 --thread=1 --numjobs=4 --time_based --runtime=120 --filename=/mnt/sub/testfile --name=job1 --group_reporting & sleep 5; time btrfs sub snap -r /mnt/sub /mnt/snap; killall fio original: 15.83sec patched: 10.35sec The improvement is smaller compared to the sequential write case, since we omit only half of the pages dirtied after snapshot command. Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
Ethan Lien <ethanlien@synology.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 75725880 ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: util/header.c: In function 'perf_event__synthesize_event_update_unit': util/header.c:3586:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] strncpy(ev->data, evsel->unit, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/header.c:3579:16: note: length computed here size_t size = strlen(evsel->unit); ^~~~~~~~~~~~~~~~~~~ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: a6e52817 ("perf tools: Add event_update event unit type") Link: https://lkml.kernel.org/n/tip-fiikh5nay70bv4zskw2aa858@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit fca5085c ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: In function 'decompress_kmodule', inlined from 'dso__decompress_kmodule_fd' at util/dso.c:305:9: util/dso.c:298:3: error: 'strncpy' destination unchanged after copying no bytes [-Werror=stringop-truncation] strncpy(pathname, tmpbuf, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC /tmp/build/perf/util/values.o CC /tmp/build/perf/util/debug.o cc1: all warnings being treated as errors Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: c9a8a613 ("perf tools: Move the temp file processing into decompress_kmodule") Link: https://lkml.kernel.org/n/tip-tl2hdxj64tt4k8btbi6a0ugw@git.kernel.orgSigned-off-by:
-
Adrian Hunter authored
[ Upstream commit 741dad88 ] Fix inconsistent use of tabs and spaces error: # perf test 16 -v 16: Setup struct perf_event_attr : --- start --- test child forked, pid 20224 File "/usr/libexec/perf-core/tests/attr.py", line 119 log.warning("expected %s=%s, got %s" % (t, self[t], other[t])) ^ TabError: inconsistent use of tabs and spaces in indentation test child finished with -1 ---- end ---- Setup struct perf_event_attr: FAILED! Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20181122140456.16817-1-adrian.hunter@intel.comSigned-off-by:
-
Beomho Seo authored
[ Upstream commit 31e93364 ] Commit 391f93f2 ("serial: core: Rework hw-assited flow control support") has changed the way the autoCTS mode is handled. According to that change, serial drivers which enable H/W autoCTS mode must set UPSTAT_AUTOCTS to prevent the serial core from inadvertently disabling TX. This patch adds proper handling of UPSTAT_AUTOCTS flag. Signed-off-by:
Beomho Seo <beomho.seo@samsung.com> [mszyprow: rephrased commit message] Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 71ab1c03 ] On (H)SCIF, sci_submit_rx() is called in the receive interrupt handler. Hence if DMA submission fails, the interrupt handler should resume handling reception using PIO, else no more data is received. Make sci_submit_rx() return an error indicator, so the receive interrupt handler can act appropriately. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit dd1f2250 ] Some callers of sci_submit_rx() hold the port spinlock, others don't. During fallback to PIO, the driver needs to obtain the port spinlock. If the lock was already held, spinlock recursion is detected, causing a deadlock: BUG: spinlock recursion on CPU#0. Fix this by adding a flag parameter to sci_submit_rx() for the caller to indicate the port spinlock is already held, so spinlock recursion can be avoided. Move the spin_lock_irqsave() up, so all DMA disable steps are protected, which is safe as the recently introduced dmaengine_terminate_async() can be called in atomic context. Signed-off-by:
-
Anand Jain authored
[ Upstream commit a9261d41 ] It's not that impossible to imagine that a device OR a btrfs image is copied just by using the dd or the cp command. Which in case both the copies of the btrfs will have the same fsid. If on the system with automount enabled, the copied FS gets scanned. We have a known bug in btrfs, that we let the device path be changed after the device has been mounted. So using this loop hole the new copied device would appears as if its mounted immediately after it's been copied. For example: Initially.. /dev/mmcblk0p4 is mounted as / $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 29.2G 0 disk |-mmcblk0p4 179:4 0 4G 0 part / |-mmcblk0p2 179:2 0 500M 0 part /boot |-mmcblk0p3 179:3 0 256M 0 part [SWAP] `-mmcblk0p1 179:1 0 256M 0 part /boot/efi $ btrfs fi show Label: none uuid: 07892354-ddaa-4443-90ea-f76a06accaba Total devices 1 FS bytes used 1.40GiB devid 1 size 4.00GiB used 3.00GiB path /dev/mmcblk0p4 Copy mmcblk0 to sda $ dd if=/dev/mmcblk0 of=/dev/sda And immediately after the copy completes the change in the device superblock is notified which the automount scans using btrfs device scan and the new device sda becomes the mounted root device. $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 14.9G 0 disk |-sda4 8:4 1 4G 0 part / |-sda2 8:2 1 500M 0 part |-sda3 8:3 1 256M 0 part `-sda1 8:1 1 256M 0 part mmcblk0 179:0 0 29.2G 0 disk |-mmcblk0p4 179:4 0 4G 0 part |-mmcblk0p2 179:2 0 500M 0 part /boot |-mmcblk0p3 179:3 0 256M 0 part [SWAP] `-mmcblk0p1 179:1 0 256M 0 part /boot/efi $ btrfs fi show / Label: none uuid: 07892354-ddaa-4443-90ea-f76a06accaba Total devices 1 FS bytes used 1.40GiB devid 1 size 4.00GiB used 3.00GiB path /dev/sda4 The bug is quite nasty that you can't either unmount /dev/sda4 or /dev/mmcblk0p4. And the problem does not get solved until you take sda out of the system on to another system to change its fsid using the 'btrfstune -u' command. Signed-off-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
-
Fabrizio Castro authored
[ Upstream commit 1d6e81a2 ] HS-USB found in RZ/G2E (a.k.a. r8a774c0) is very similar to the one found in R-Car E3 (a.k.a. r8a77990), as it needs to release the PLL reset by the UGCTRL register like R-Car E3, therefore add r8a774c0 support in a similar fashion to what was done for the r8a77990. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit 0c901c05 ] Modifty the JZ4740 driver to retrieve card detect and write protect GPIO pins from GPIO descriptors instead of hard-coded global numbers. Augment the only board file using this in the process and cut down on passed in platform data. Preserve the code setting the caps2 flags for CD and WP as active low or high since the slot GPIO code currently ignores the gpiolib polarity inversion semantice and uses the raw accessors to read the GPIO lines, but set the right polarity flags in the descriptor table for jz4740. Cc: Paul Cercueil <paul@crapouillou.net> Cc: linux-mips@linux-mips.org Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Paul Burton <paul.burton@mips.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Adrian Hunter authored
[ Upstream commit 0e6e7c2f ] Always check the wait condition before returning timeout. Signed-off-by:
Zhoujie Wu <zjwu@marvell.com> Signed-off-by:
-
Adrian Hunter authored
[ Upstream commit 9f0ea0bd ] Always check the wait condition before returning timeout. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Adrian Hunter authored
[ Upstream commit ea6d0273 ] Always check the wait condition before returning timeout. Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit e03e303e ] We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put} helpers to let memstick host support runtime pm. The rpm count may go down to zero before the memstick host powers on, so the host can be runtime suspended. So before doing card detection, increment the rpm count to avoid the host gets runtime suspended. Balance the rpm count after card detection is done. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by:
-
Nicholas Mc Guire authored
[ Upstream commit b0d06f1c ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignments to init.name are not safe if not checked. On error meson_mx_mmc_register_clks() returns negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Michal Suchanek authored
[ Upstream commit f6000a4e ] The bcm2835 mmc host tends to lock up for unknown reason so reset it on timeout. The upper mmc block layer tries retransimitting with single blocks which tends to work out after a long wait. This is better than giving up and leaving the machine broken for no obvious reason. Fixes: 660fc733 ("mmc: bcm2835: Add new driver for the sdhost controller.") Signed-off-by:
Michal Suchanek <msuchanek@suse.de> Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Phil Elwell authored
[ Upstream commit 07d40576 ] If the user issues an "mmc extcsd read", the SD controller receives what it thinks is a SEND_IF_COND command with an unexpected data block. The resulting operations leave the FSM stuck in READWAIT, a state which persists until the MMC framework resets the controller, by which point the root filesystem is likely to have been unmounted. A less heavyweight solution is to detect the condition and nudge the FSM by asserting the (self-clearing) FORCE_DATA_MODE bit. Link: https://github.com/raspberrypi/linux/issues/2728Signed-off-by:
Phil Elwell <phil@raspberrypi.org> Signed-off-by:
-
Suraj Jitindar Singh authored
[ Upstream commit 693ac10a ] The kvm capability KVM_CAP_SPAPR_TCE_VFIO is used to indicate the availability of in kernel tce acceleration for vfio. However it is currently the case that this is only available on a powernv machine, not for a pseries machine. Thus make this capability dependent on having the cpu feature CPU_FTR_HVMODE. [paulus@ozlabs.org - fixed compilation for Book E.] Signed-off-by:
Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit add68836 ] eukrea-tlv320.c machine driver runs on non-DT platforms and include <asm/mach-types.h> header file in order to be able to use some machine_is_eukrea_xxx() macros. Building it for ARM64 causes the following build error: sound/soc/fsl/eukrea-tlv320.c:28:10: fatal error: asm/mach-types.h: No such file or directory Avoid this error by not allowing to build the SND_SOC_EUKREA_TLV320 driver when ARM64 is selected. This is needed in preparation for the i.MX8M support. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 88af3209 ] WARNING: vmlinux.o(.text+0x19f90): Section mismatch in reference from the function littleton_init_lcd() to the function .init.text:pxa_set_fb_info() The function littleton_init_lcd() references the function __init pxa_set_fb_info(). This is often because littleton_init_lcd lacks a __init annotation or the annotation of pxa_set_fb_info is wrong. WARNING: vmlinux.o(.text+0xf824): Section mismatch in reference from the function zeus_register_ohci() to the function .init.text:pxa_set_ohci_info() The function zeus_register_ohci() references the function __init pxa_set_ohci_info(). This is often because zeus_register_ohci lacks a __init annotation or the annotation of pxa_set_ohci_info is wrong. WARNING: vmlinux.o(.text+0xf95c): Section mismatch in reference from the function cm_x300_init_u2d() to the function .init.text:pxa3xx_set_u2d_info() The function cm_x300_init_u2d() references the function __init pxa3xx_set_u2d_info(). This is often because cm_x300_init_u2d lacks a __init annotation or the annotation of pxa3xx_set_u2d_info is wrong. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Stanislav Fomichev authored
[ Upstream commit a0517a0f ] For some reason, my older GCC (< 4.8) isn't smart enough to optimize the !__builtin_constant_p() branch in bpf_htons, I see: error: implicit declaration of function '__builtin_bswap16' Let's use __bpf_constant_htons as suggested by Daniel Borkmann. I tried to use simple htons, but it produces the following: test_progs.c:54:17: error: braced-group within expression allowed only inside a function .eth.h_proto = htons(ETH_P_IP), Signed-off-by:
Stanislav Fomichev <sdf@google.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Joey Zhang authored
[ Upstream commit e4a7dca5 ] In the ioctl_event_ctl() SWITCHTEC_IOCTL_EVENT_IDX_ALL case, we call event_ctl() several times with the same "ctl" struct. Each call clobbers ctl.flags, which leads to the problem that we may not actually enable or disable all events as the user requested. Preserve the event flag value with a temporary variable. Fixes: 52eabba5 ("switchtec: Add IOCTLs to the Switchtec driver") Signed-off-by:
Joey Zhang <joey.zhang@microchip.com> Signed-off-by:
Wesley Sheng <wesley.sheng@microchip.com> [bhelgaas: changelog] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
-
