- 10 May, 2020 32 commits
-
-
Daniel Vetter authored
commit 26b1d3b5 upstream. The -modesetting ddx has a totally broken idea of how atomic works: - doesn't disable old connectors, assuming they get auto-disable like with the legacy setcrtc - assumes ASYNC_FLIP is wired through for the atomic ioctl - not a single call to TEST_ONLY Iow the implementation is a 1:1 translation of legacy ioctls to atomic, which is a) broken b) pointless. We already have bugs in both i915 and amdgpu-DC where this prevents us from enabling neat features. If anyone ever cares about atomic in X we can easily add a new atomic level (req->value == 2) for X to get back the shiny toys. Since these broken versions of -modesetting have been shipping, there's really no other way to get out of this bind. v2: - add an informational dmesg output (Rob, Ajax) - reorder after the DRIVER_ATOMIC check to avoid useless noise (Ilia) - allow req->value > 2 so that X can do another attempt at atomic in the future v3: Go with paranoid, insist that the X should be first (suggested by Rob) Cc: Ilia Mirkin <imirkin@alum.mit.edu> References: https://gitlab.freedesktop.org/xorg/xserver/issues/629 References: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180 References: abbc0697 ("drm/fb: revert the i915 Actually configure untiled displays from master") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1) Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> (v1) Cc: Michel Dänzer <michel@daenzer.net> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Acked-by:
Adam Jackson <ajax@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Rob Clark <robdclark@gmail.com> Acked-by:
Rob Clark <robdclark@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190905185318.31363-1-daniel.vetter@ffwll.ch Cc: Yves-Alexis Perez <corsac@debian.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
commit 526f3d96 upstream. Commit 018d26fc ("cgroup, netclassid: periodically release file_lock on classid") added a second cond_resched to write_classid indirectly by update_classid_task. Remove the one in write_classid. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Dmitry Yakunin <zeil@yandex-team.ru> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Thomas Pedersen authored
commit 30b2f0be upstream. commit 08a5bdde ("mac80211: consider QoS Null frames for STA_NULLFUNC_ACKED") Fixed a bug where we failed to take into account a nullfunc frame can be either non-QoS or QoS. It turns out there is at least one more bug in ieee80211_sta_tx_notify(), introduced in commit 7b6ddeaf ("mac80211: use QoS NDP for AP probing"), where we forgot to check for the QoS variant and so assumed the QoS nullfunc frame never went out Fix this by adding a helper ieee80211_is_any_nullfunc() which consolidates the check for non-QoS and QoS nullfunc frames. Replace existing compound conditionals and add a couple more missing checks for QoS variant. Signed-off-by:
Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20200114055940.18502-3-thomas@adapt-ip.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Hans de Goede authored
commit 1d6f8c5b upstream. Commit 1f27dbd8 ("platform/x86: GPD pocket fan: Allow somewhat lower/higher temperature limits") changed the module-param sanity check to accept temperature limits between 20 and 90 degrees celcius. But the error message printed when the module params are outside this range was not updated. This commit updates the error message to match the new min and max value for the temp-limits. Reported-by:
Pavel Machek <pavel@denx.de> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Takashi Iwai authored
commit 977dfef4 upstream. The commit 3c6fd1f0 ("ALSA: hda: Add driver blacklist") added a new blacklist for the devices that are known to have empty codecs, and one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f). However, it turned out that the very same PCI SSID is used for the previous model that does have the valid HD-audio codecs and the change broke the sound on it. Since the empty codec problem appear on the certain AMD platform (PCI ID 1022:1487), this patch changes the blacklist matching to both PCI ID and SSID using pci_match_id(). Also, the entry that was removed by the previous fix for ASUS ROG Zenigh II is re-added. Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Nick Desaulniers authored
commit 7312b706 upstream. Similar to commit 38e45d81 ("sparc64: implement ioremap_uc") define ioremap_uc for hexagon to avoid errors from -Wimplicit-function-definition. Link: http://lkml.kernel.org/r/20191209222956.239798-2-ndesaulniers@google.com Link: https://github.com/ClangBuiltLinux/linux/issues/797 Fixes: e537654b ("lib: devres: add a helper function for ioremap_uc") Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Suggested-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Brian Cain <bcain@codeaurora.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Tuowen Zhao <ztuowen@gmail.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alexios Zavras <alexios.zavras@intel.com> Cc: Allison Randal <allison@lohutok.net> Cc: Will Deacon <will@kernel.org> Cc: Richard Fontana <rfontana@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Christoph Hellwig authored
commit ac32292c upstream. Use ioremap as the main implemented function, and defined ioremap_nocache to it as a deprecated alias. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Tuowen Zhao authored
commit a8ff78f7 upstream. Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci in MTRR. This will cause the system to hang during boot. If possible, this bug could be corrected with a firmware update. This patch use devm_ioremap_uc to overwrite/ignore the MTRR settings by forcing the use of strongly uncachable pages for intel-lpss. The BIOS bug is present on Dell XPS 13 7390 2-in-1: [ 0.001734] 5 base 4000000000 mask 6000000000 write-combining 4000000000-7fffffffff : PCI Bus 0000:00 4000000000-400fffffff : 0000:00:02.0 (i915) 4010000000-4010000fff : 0000:00:15.0 (intel-lpss-pci) Link: https://bugzilla.kernel.org/show_bug.cgi?id=203485 Cc: <stable@vger.kernel.org> # v4.19+ Tested-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Tuowen Zhao <ztuowen@gmail.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Roman Gilg <subdiff@gmail.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Tuowen Zhao authored
[ Upstream commit e537654b ] Implement a resource managed strongly uncachable ioremap function. Cc: <stable@vger.kernel.org> # v4.19+ Tested-by:
Luis Chamberlain <mcgrof@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Aaron Ma authored
commit 5932d260 upstream. On ARCTURUS and RENOIR, powerplay is not supported yet. When plug in or unplug power jack, ACPI event will issue. Then kernel NULL pointer BUG will be triggered. Check for NULL pointers before calling. Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jere Leppänen authored
commit 12dfd78e upstream. When starting shutdown in sctp_sf_do_dupcook_a(), get the value for SHUTDOWN Cumulative TSN Ack from the new association, which is reconstructed from the cookie, instead of the old association, which the peer doesn't have anymore. Otherwise the SHUTDOWN is either ignored or replied to with an ABORT by the peer because CTSN Ack doesn't match the peer's Initial TSN. Fixes: bdf6fa52 ("sctp: handle association restarts when the socket is closed.") Signed-off-by:
Jere Leppänen <jere.leppanen@nokia.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Doug Berger authored
[ Upstream commit 3554e54a ] The driver is designed to drop Rx packets and reclaim the buffers when an allocation fails, and the network interface needs to safely handle this packet loss. Therefore, an allocation failure of Rx SKBs is relatively benign. However, the output of the warning message occurs with a high scheduling priority that can cause excessive jitter/latency for other high priority processing. This commit suppresses the warning messages to prevent scheduling problems while retaining the failure count in the statistics of the network interface. Signed-off-by:
Doug Berger <opendmb@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Doug Berger authored
[ Upstream commit ecaeceb8 ] The driver is designed to drop Rx packets and reclaim the buffers when an allocation fails, and the network interface needs to safely handle this packet loss. Therefore, an allocation failure of Rx SKBs is relatively benign. However, the output of the warning message occurs with a high scheduling priority that can cause excessive jitter/latency for other high priority processing. This commit suppresses the warning messages to prevent scheduling problems while retaining the failure count in the statistics of the network interface. Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 5990cdee ] 0day reports over and over on an powerpc randconfig with clang: lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions Remove the superfluous casts, which have been done previously for x86 and arm32 in commit dea632ca ("lib/mpi: fix build with clang") and commit 7b7c1df2 ("lib/mpi/longlong.h: fix building with 32-bit x86"). Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://github.com/ClangBuiltLinux/linux/issues/991 Link: https://lore.kernel.org/r/20200413195041.24064-1-natechancellor@gmail.comSigned-off-by:
-
Jeremie Francois (on alpha) authored
[ Upstream commit e461bc9f ] Sed broke on some strings as it used colon as a separator. I made it more robust by using \001, which is legit POSIX AFAIK. E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01" failed with: sed: -e expression #1, char 55: unknown option to `s' Signed-off-by:
Jeremie Francois (on alpha) <jeremie.francois@gmail.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Philipp Rudo authored
[ Upstream commit 8ebf6da9 ] Switching tracers include instruction patching. To prevent that a instruction is patched while it's read the instruction patching is done in stop_machine 'context'. This also means that any function called during stop_machine must not be traced. Thus add 'notrace' to all functions called within stop_machine. Fixes: 1ec2772e ("s390/diag: add a statistic for diagnose calls") Fixes: 38f2c691 ("s390: improve wait logic of stop_machine") Fixes: 4ecf0a43 ("processor: get rid of cpu_relax_yield") Signed-off-by:
Philipp Rudo <prudo@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Ronnie Sahlberg authored
[ Upstream commit fada37f6 ] We use a spinlock while we are reading and accessing the destination address for a server. We need to also use this spinlock to protect when we are modifying this address from reconn_set_ipaddr(). Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Matthias Blankertz authored
[ Upstream commit 54cb6221 ] Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2 - the same logic as in rsnd_ssi_start. The attempt to disable these SSIs was harmless, but caused a "status check failed" message to be printed for every SSI in the multi-SSI setup. The disabling of interrupts is still performed, as they are enabled for all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the EN bit for an SSI where it was not set by rsnd_ssi_start. Signed-off-by:
Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200417153017.1744454-3-matthias.blankertz@cetitec.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Matthias Blankertz authored
[ Upstream commit 0c258657 ] The master SSI of a multi-SSI setup was attached both to the RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream. This is not correct wrt. the meaning of being "parent" in the rest of the SSI code, where it seems to indicate an SSI that provides clock and word sync but is not transmitting/receiving audio data. Not treating the multi-SSI master as parent allows removal of various special cases to the rsnd_ssi_is_parent conditions introduced in commit a09fb3f2 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode"). It also fixes the issue that operations performed via rsnd_dai_call() were performed twice for the master SSI. This caused some "status check failed" spam when stopping a multi-SSI stream as the driver attempted to stop the master SSI twice. Signed-off-by:
-
Julien Beraud authored
[ Upstream commit 91a2559c ] In fine adjustement mode, which is the current default, the sub-second increment register is the number of nanoseconds that will be added to the clock when the accumulator overflows. At each clock cycle, the value of the addend register is added to the accumulator. Currently, we use 20ns = 1e09ns / 50MHz as this value whatever the frequency of the ptp clock actually is. The adjustment is then done on the addend register, only incrementing every X clock cycles X being the ratio between 50MHz and ptp_clock_rate (addend = 2^32 * 50MHz/ptp_clock_rate). This causes the following issues : - In case the frequency of the ptp clock is inferior or equal to 50MHz, the addend value calculation will overflow and the default addend value will be set to 0, causing the clock to not work at all. (For instance, for ptp_clock_rate = 50MHz, addend = 2^32). - The resolution of the timestamping clock is limited to 20ns while it is not needed, thus limiting the accuracy of the timestamping to 20ns. Fix this by setting sub-second increment to 2e09ns / ptp_clock_rate. It will allow to reach the minimum possible frequency for ptp_clk_ref, which is 5MHz for GMII 1000Mps Full-Duplex by setting the sub-second-increment to a higher value. For instance, for 25MHz, it gives ssinc = 80ns and default_addend = 2^31. It will also allow to use a lower value for sub-second-increment, thus improving the timestamping accuracy with frequencies higher than 100MHz, for instance, for 200MHz, ssinc = 10ns and default_addend = 2^31. v1->v2: - Remove modifications to the calculation of default addend, which broke compatibility with clock frequencies for which 2000000000 / ptp_clk_freq is not an integer. - Modify description according to discussions. Signed-off-by:
Julien Beraud <julien.beraud@orolia.com> Signed-off-by:
-
Julien Beraud authored
[ Upstream commit 15ce3060 ] There are 2 registers to write to enable a ptp ref clock coming from the fpga. One that enables the usage of the clock from the fpga for emac0 and emac1 as a ptp ref clock, and the other to allow signals from the fpga to reach emac0 and emac1. Currently, if the dwmac-socfpga has phymode set to PHY_INTERFACE_MODE_MII, PHY_INTERFACE_MODE_GMII, or PHY_INTERFACE_MODE_SGMII, both registers will be written and the ptp ref clock will be set as coming from the fpga. Separate the 2 register writes to only enable signals from the fpga to reach emac0 or emac1 when ptp ref clock is not coming from the fpga. Signed-off-by:
-
Xiyu Yang authored
[ Upstream commit 7717cbec ] i2400mu_bus_bm_wait_for_ack() invokes usb_get_urb(), which increases the refcount of the "notif_urb". When i2400mu_bus_bm_wait_for_ack() returns, local variable "notif_urb" becomes invalid, so the refcount should be decreased to keep refcount balanced. The issue happens in all paths of i2400mu_bus_bm_wait_for_ack(), which forget to decrease the refcnt increased by usb_get_urb(), causing a refcnt leak. Fix this issue by calling usb_put_urb() before the i2400mu_bus_bm_wait_for_ack() returns. Signed-off-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by:
Xin Tan <tanxin.ctf@gmail.com> Signed-off-by:
-
Sandeep Raghuraman authored
[ Upstream commit bbc25dad ] Initialize thermal controller fields in the PowerPlay table for Hawaii GPUs, so that fan speeds are reported. Signed-off-by:
Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit 326b5092 ] If we don't find any pcm, pcm will point at address at an offset from the the list head and not a meaningful structure. Fix this by returning correct pcm if found and NULL if not. Found with coccinelle. Signed-off-by:
Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20200415162849.308-1-amadeuszx.slawinski@linux.intel.comSigned-off-by:
-
Matthias Blankertz authored
[ Upstream commit b94e1647 ] The HDMI?_SEL register maps up to four stereo SSI data lanes onto the sdata[0..3] inputs of the HDMI output block. The upper half of the register contains four blocks of 4 bits, with the most significant controlling the sdata3 line and the least significant the sdata0 line. The shift calculation has an off-by-one error, causing the parent SSI to be mapped to sdata3, the first multi-SSI child to sdata0 and so forth. As the parent SSI transmits the stereo L/R channels, and the HDMI core expects it on the sdata0 line, this causes no audio to be output when playing stereo audio on a multichannel capable HDMI out, and multichannel audio has permutated channels. Fix the shift calculation to map the parent SSI to sdata0, the first child to sdata1 etc. Signed-off-by:
-
Matthias Blankertz authored
[ Upstream commit a09fb3f2 ] The parent SSI of a multi-SSI setup must be fully setup, started and stopped since it is also part of the playback/capture setup. So only skip the SSI (as per commit 203cdf51 ("ASoC: rsnd: SSI parent cares SWSP bit") and commit 597b046f ("ASoC: rsnd: control SSICR::EN correctly")) if the SSI is parent outside of a multi-SSI setup. Signed-off-by:
-
Thinh Nguyen authored
[ Upstream commit d94ea531 ] Currently the calculation of max packet size limit for IN endpoints is too restrictive. This prevents a matching of a capable hardware endpoint during configuration. Below is the minimum recommended HW configuration to support a particular endpoint setup from the databook: For OUT endpoints, the databook recommended the minimum RxFIFO size to be at least 3x MaxPacketSize + 3x setup packets size (8 bytes each) + clock crossing margin (16 bytes). For IN endpoints, the databook recommended the minimum TxFIFO size to be at least 3x MaxPacketSize for endpoints that support burst. If the endpoint doesn't support burst or when the device is operating in USB 2.0 mode, a minimum TxFIFO size of 2x MaxPacketSize is recommended. Base on these recommendations, we can calculate the MaxPacketSize limit of each endpoint. This patch revises the IN endpoint MaxPacketSize limit and also sets the MaxPacketSize limit for OUT endpoints. Reference: Databook 3.30a section 3.2.2 and 3.2.3 Signed-off-by:
Thinh Nguyen <thinhn@synopsys.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Sebastian Reichel authored
[ Upstream commit aa781273 ] As mentioned slightly out of patch context in the code, there is no reset routine for the chip. On boards where the chip is supplied by a fixed regulator, it might not even be resetted during (e.g. watchdog) reboot and can be in any state. If the device is probed with VAG enabled, the driver's probe routine will generate a loud pop sound when ANA_POWER is being programmed. Avoid this by properly disabling just the VAG bit and waiting the required power down time. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by:
Fabio Estevam <festivem@gmail.com> Link: https://lore.kernel.org/r/20200414181140.145825-1-sebastian.reichel@collabora.comSigned-off-by:
-
Tyler Hicks authored
[ Upstream commit b87080ea ] After successfully running the IPC msgque test once, subsequent runs result in a test failure: $ sudo ./run_kselftest.sh TAP version 13 1..1 # selftests: ipc: msgque # Failed to get stats for IPC queue with id 0 # Failed to dump queue: -22 # Bail out! # # Pass 0 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0 not ok 1 selftests: ipc: msgque # exit=1 The dump_queue() function loops through the possible message queue index values using calls to msgctl(kern_id, MSG_STAT, ...) where kern_id represents the index value. The first time the test is ran, the initial index value of 0 is valid and the test is able to complete. The index value of 0 is not valid in subsequent test runs and the loop attempts to try index values of 1, 2, 3, and so on until a valid index value is found that corresponds to the message queue created earlier in the test. The msgctl() syscall returns -1 and sets errno to EINVAL when invalid index values are used. The test failure is caused by incorrectly comparing errno to -EINVAL when cycling through possible index values. Fix invalid test failures on subsequent runs of the msgque test by correctly comparing errno values to a non-negated EINVAL. Fixes: 3a665531 ("selftests: IPC message queue copy feature test") Signed-off-by:
Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit b3677fc3 ] Function pcm_new_ver can fail, so we should check it's return value and handle possible error. Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200327204729.397-6-amadeuszx.slawinski@linux.intel.comSigned-off-by:
-
Alexey Kardashevskiy authored
commit dead1c84 upstream. The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing which reads "assigned-addresses" of every PCI device and initializes the device resources. However if the property is missing or zero sized, then there is no fallback of any kind and the PCI resources remain undiscovered, i.e. pdev->resource[] array remains empty. This adds a fallback which parses the "reg" property in pretty much same way except it marks resources as "unset" which later make Linux assign those resources proper addresses. This has an effect when: 1. a hypervisor failed to assign any resource for a device; 2. /chosen/linux,pci-probe-only=0 is in the DT so the system may try assigning a resource. Neither is likely to happen under PowerVM. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
-
Jia He authored
commit 0b841030 upstream. Ning Bo reported an abnormal 2-second gap when booting Kata container [1]. The unconditional timeout was caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of connecting from the client side. The vhost vsock client tries to connect an initializing virtio vsock server. The abnormal flow looks like: host-userspace vhost vsock guest vsock ============== =========== ============ connect() --------> vhost_transport_send_pkt_work() initializing | vq->private_data==NULL | will not be queued V schedule_timeout(2s) vhost_vsock_start() <--------- device ready set vq->private_data wait for 2s and failed connect() again vq->private_data!=NULL recv connecting pkt Details: 1. Host userspace sends a connect pkt, at that time, guest vsock is under initializing, hence the vhost_vsock_start has not been called. So vq->private_data==NULL, and the pkt is not been queued to send to guest 2. Then it sleeps for 2s 3. After guest vsock finishes initializing, vq->private_data is set 4. When host userspace wakes up after 2s, send connecting pkt again, everything is fine. As suggested by Stefano Garzarella, this fixes it by additional kicking the send_pkt worker in vhost_vsock_start once the virtio device is started. This makes the pending pkt sent again. After this patch, kata-runtime (with vsock enabled) boot time is reduced from 3s to 1s on a ThunderX2 arm64 server. [1] https://github.com/kata-containers/runtime/issues/1917Reported-by:
Ning Bo <n.b@live.com> Suggested-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
Jia He <justin.he@arm.com> Link: https://lore.kernel.org/r/20200501043840.186557-1-justin.he@arm.comSigned-off-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
-
- 06 May, 2020 8 commits
-
-
Greg Kroah-Hartman authored
-
Martin Blumenstingl authored
commit ddca1092 upstream. The recent commit 0d84c3e6 ("mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discard") makes use of the ->card_busy() op for SD cards. This uncovered that the ->card_busy() op in the Meson SDIO driver was never working right: while polling the busy status with ->card_busy() meson_mx_mmc_card_busy() reads only one of the two MESON_MX_SDIO_IRQC register values 0x1f001f10 or 0x1f003f10. This translates to "three out of four DAT lines are HIGH" and "all four DAT lines are HIGH", which is interpreted as "the card is busy". It turns out that no situation can be observed where all four DAT lines are LOW, meaning the card is not busy anymore. Upon further research the 3.10 vendor driver for this controller does not implement the ->card_busy() op. Remove the ->card_busy() op from the meson-mx-sdio driver since it is not working. At the time of writing this patch it is not clear what's needed to make the ->card_busy() implementation work with this specific controller hardware. For all use-cases which have previously worked the MMC_CAP_WAIT_WHILE_BUSY flag is now taking over, even if we don't have a ->card_busy() op anymore. Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@googlemail.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Martin Blumenstingl authored
commit e53b868b upstream. The Meson SDIO controller uses the DAT0 lane for hardware busy detection. Set MMC_CAP_WAIT_WHILE_BUSY accordingly. This fixes the following error observed with Linux 5.7 (pre-rc-1): mmc1: Card stuck being busy! __mmc_poll_for_busy blk_update_request: I/O error, dev mmcblk1, sector 17111080 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by:
-
Veerabhadrarao Badiganti authored
commit 9d8cb586 upstream. MSM sd host controller is capable of HW busy detection of device busy signaling over DAT0 line. And it requires the R1B response for commands that have this response associated with them. So set the below two host capabilities for qcom SDHC. - MMC_CAP_WAIT_WHILE_BUSY - MMC_CAP_NEED_RSP_BUSY Recent development of the mmc core in regards to this, revealed this as being a potential bug, hence the stable tag. Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.orgSigned-off-by:
-
Adrian Hunter authored
commit 1a8eb6b3 upstream. BIOS writers have begun the practice of setting 40 ohm eMMC driver strength even though the eMMC may not support it, on the assumption that the kernel will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH [offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid. This is done to avoid changing the value for different boards. Putting aside the merits of this approach, it is clear the eMMC's mask of supported driver strengths is more reliable than the value provided by BIOS. Add validation accordingly. Signed-off-by:
-
Marek Behún authored
commit bb32e198 upstream. For some reason the Host Control2 register of the Xenon SDHCI controller sometimes reports the bit representing 1.8V signaling as 0 when read after it was written as 1. Subsequent read reports 1. This causes the sdhci_start_signal_voltage_switch function to report 1.8V regulator output did not become stable When CONFIG_PM is enabled, the host is suspended and resumend many times, and in each resume the switch to 1.8V is called, and so the kernel log reports this message annoyingly often. Do an empty read of the Host Control2 register in Xenon's .voltage_switch method to circumvent this. This patch fixes this particular problem on Turris MOX. Signed-off-by:
Marek Behún <marek.behun@nic.cz> Fixes: 8d876bf4 ("mmc: sdhci-xenon: wait 5ms after set 1.8V...") Cc: stable@vger.kernel.org # v4.16+ Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.czSigned-off-by:
-
Douglas Anderson authored
commit b1ac62a7 upstream. Open-coding a timeout loop invariably leads to errors with handling the timeout properly in one corner case or another. In the case of cqhci we might report "CQE stuck on" even if it wasn't stuck on. You'd just need this sequence of events to happen in cqhci_off(): 1. Call ktime_get(). 2. Something happens to interrupt the CPU for > 100 us (context switch or interrupt). 3. Check time and; set "timed_out" to true since > 100 us. 4. Read CQHCI_CTL. 5. Both "reg & CQHCI_HALT" and "timed_out" are true, so break. 6. Since "timed_out" is true, falsely print the error message. Rather than fixing the polling loop, use readx_poll_timeout() like many people do. This has been time tested to handle the corner cases. Fixes: a4080225 ("mmc: cqhci: support for command queue enabled host") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
-
Qu Wenruo authored
commit fcc99734 upstream. [BUG] One run of btrfs/063 triggered the following lockdep warning: ============================================ WARNING: possible recursive locking detected 5.6.0-rc7-custom+ #48 Not tainted -------------------------------------------- kworker/u24:0/7 is trying to acquire lock: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs] but task is already holding lock: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(sb_internal#2); lock(sb_internal#2); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by kworker/u24:0/7: #0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80 #1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80 #2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs] #3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs] stack backtrace: CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] Call Trace: dump_stack+0xc2/0x11a __lock_acquire.cold+0xce/0x214 lock_acquire+0xe6/0x210 __sb_start_write+0x14e/0x290 start_transaction+0x66c/0x890 [btrfs] btrfs_join_transaction+0x1d/0x20 [btrfs] find_free_extent+0x1504/0x1a50 [btrfs] btrfs_reserve_extent+0xd5/0x1f0 [btrfs] btrfs_alloc_tree_block+0x1ac/0x570 [btrfs] btrfs_copy_root+0x213/0x580 [btrfs] create_reloc_root+0x3bd/0x470 [btrfs] btrfs_init_reloc_root+0x2d2/0x310 [btrfs] record_root_in_trans+0x191/0x1d0 [btrfs] btrfs_record_root_in_trans+0x90/0xd0 [btrfs] start_transaction+0x16e/0x890 [btrfs] btrfs_join_transaction+0x1d/0x20 [btrfs] btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs] finish_ordered_fn+0x15/0x20 [btrfs] btrfs_work_helper+0x116/0x9a0 [btrfs] process_one_work+0x632/0xb80 worker_thread+0x80/0x690 kthread+0x1a3/0x1f0 ret_from_fork+0x27/0x50 It's pretty hard to reproduce, only one hit so far. [CAUSE] This is because we're calling btrfs_join_transaction() without re-using the current running one: btrfs_finish_ordered_io() |- btrfs_join_transaction() <<< Call #1 |- btrfs_record_root_in_trans() |- btrfs_reserve_extent() |- btrfs_join_transaction() <<< Call #2 Normally such btrfs_join_transaction() call should re-use the existing one, without trying to re-start a transaction. But the problem is, in btrfs_join_transaction() call #1, we call btrfs_record_root_in_trans() before initializing current::journal_info. And in btrfs_join_transaction() call #2, we're relying on current::journal_info to avoid such deadlock. [FIX] Call btrfs_record_root_in_trans() after we have initialized current::journal_info. CC: stable@vger.kernel.org # 4.4+ Signed-off-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
