- 20 Nov, 2019 40 commits
-
-
Marcel Ziswiler authored
[ Upstream commit 8a1ecc01 ] There is one too many zeroes in the Power I2C base address. Fix this. Signed-off-by:
Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Robert Jarzmik authored
[ Upstream commit 24a610eb ] The RTC controller is fed by an external fixed 32kHz clock. Yet the driver wants to acquire this clock, even though it doesn't make any use of it, ie. doesn't get the rate to make calculation. Therefore, use the exported 32.768kHz clock in the PXA clock tree to make the driver happy and working. Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit 1d18c2cd ] If ov772x_power_on() is unable to get GPIO rstb, the clock is left undisabled. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Sakari Ailus authored
[ Upstream commit 4d471563 ] pm_runtime_get_if_in_use() returns -EINVAL if runtime PM is disabled. This should not be considered an error. Generally the driver has enabled runtime PM already so getting this error due to runtime PM being disabled will not happen. Instead of checking for lesser or equal to zero, check for zero only. Address this for drivers where this pattern exists. This patch has been produced using the following command: $ git grep -l pm_runtime_get_if_in_use -- drivers/media/i2c/ | \ xargs perl -i -pe 's/(pm_runtime_get_if_in_use\(.*\)) \<\= 0/!$1/' Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit be5a1509 ] While decoding you need to make sure you do not get values < 0 or > 255. Note that since this code will also be used in userspace utilities the clamp macro isn't used since that is kernel-only. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Sara Sharon authored
[ Upstream commit 1a19c139 ] When we receive TX response, we may release a few packets due to a hole that was closed in the transmission window. However, if that frame failed, we will mark all the released frames as failed and will send multiple BARs. This affects statistics badly, and cause unnecessary frames transmission. Instead, mark all the following packets as success, with the desired result of sending a bar for the failed frame only. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 84f26025 ] There's no point in warning here, the user will just get an error back to the debugfs file write, and warning just makes it seem like there's an internal consistency problem when in reality the user just happened to hit this at a bad time. Remove the warning. Fixes: f45f979d ("iwlwifi: mvm: disable dbg data collect when fw isn't alive") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sara Sharon authored
[ Upstream commit 7891965d ] We need to drop packets with errors (such as replay, MIC, ICV, conversion, duplicate and so on). Drop invalid packets, put the status bits in the metadata and move the enum definition to the correct place (FW API header). Signed-off-by:
-
Vijay Immanuel authored
[ Upstream commit 030e46e4 ] When a read request is retried for the remaining partial data, the response may restart from read response first or read response only. So support those cases. Do not advance the comp psn beyond the current wqe's last_psn as that could skip over an entire read wqe and will cause the req_retry() logic to set an incorrect req psn. An example sequence is as follows: Write PSN 40 -- this is the current WQE. Read request PSN 41 Write PSN 42 Receive ACK PSN 42 -- this will complete the current WQE for PSN 40, and set the comp psn to 42 which is a problem because the read request at PSN 41 has been skipped over. So when req_retry() tries to retransmit the read request, it sets the req psn to 42 which is incorrect. When retrying a read request, calculate the number of psns completed based on the dma resid instead of the wqe first_psn. The wqe first_psn could have moved if the read request was retried multiple times. Set the reth length to the dma resid to handle read retries for the remaining partial data. Signed-off-by:
Vijay Immanuel <vijayi@attalasystems.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Vijay Immanuel authored
[ Upstream commit 4e4c53df ] Error retries can occur due to timeouts, NAKs or receiving packets beyond the current read request. Avoid back-to-back retries due to packet processing, by only retrying the initial attempt immediately. Subsequent retries must be due to timeouts. Continue to process completion packets after scheduling a retry. Signed-off-by:
-
Patryk Małek authored
[ Upstream commit 5907cf6c ] To prevent VF from deleting MAC address that was assigned by the PF we need to check for that scenario when we try to delete a MAC address from a VF. Signed-off-by:
Patryk Małek <patryk.malek@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Lihong Yang authored
[ Upstream commit babbcc60 ] If a VF is being removed, there is no need to continue with the workqueue sync for the adminq task, thus cancel it. Without this call, when VFs are created and removed right away, there might be a chance for the driver to crash with events stuck in the adminq. Signed-off-by:
Lihong Yang <lihong.yang@intel.com> Tested-by:
-
Patryk Małek authored
[ Upstream commit 5cba17b1 ] Hold the rtnl lock when we're clearing interrupt scheme in i40e_shutdown and in i40e_remove. Signed-off-by:
-
Patryk Małek authored
[ Upstream commit 3bd77e2a ] With current implementation of i40evf_set_features when user sets any offload via ethtool we set I40EVF_FLAG_AQ_ENABLE_VLAN_STRIPPING as a required aq which triggers driver to call i40evf_enable_vlan_stripping. This shouldn't take place. This patches fixes it by setting the flag only when VLAN offload is turned on. Signed-off-by:
-
Jan Sokolowski authored
[ Upstream commit e78d9a39 ] If our card has been put in an unstable state due to other drivers interacting with it, speed settings might be incorrect. If incorrect, forcefully reset them on open to known default values. Signed-off-by:
Jan Sokolowski <jan.sokolowski@intel.com> Tested-by:
-
Lihong Yang authored
[ Upstream commit e65aae08 ] Set IFF_UNICAST_FLT flag for the VF to prevent it from entering promiscuous mode when macvlan is added to the VF. Signed-off-by:
-
Mitch Williams authored
[ Upstream commit 7eb74ff8 ] Caught by GCC 8. When we provide a length for strncpy, we should not include the terminating null. So we must tell it one less than the size of the destination buffer. Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Paul M Stillwell Jr authored
[ Upstream commit 3c818910 ] A PF can send any number of queues to the VF and the VF may not be able to support that many. Check to see that the number of queues is less than or equal to the max number of queues the VF can have. Signed-off-by:
Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by:
-
Marek Szyprowski authored
[ Upstream commit f8f3b7fc ] Regulators, which are marked as 'on-in-suspend' seems to be critical for board operation, thus they must not be disabled anytime. This can be only assured by marking them as 'always-on', because otherwise some actions of their clients might result in turning them off. This patch restores suspend/resume operation on Peach-Pit Chromebook board. It partially reverts 'always-on' property removal done by the commit mentioned in the Fixes tag. Fixes: 665c441e ("ARM: dts: exynos: Remove unneded always-on for regulators on Peach boards") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Alan Tull authored
[ Upstream commit c8da1d15 ] DesignWare I2C controller was observed running at 105.93kHz rather than the specified 100kHz. Adjust device tree settings to bring it within spec (a slightly conservative 98 MHz). Signed-off-by:
Alan Tull <atull@kernel.org> Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
Rick Farrington authored
[ Upstream commit b943f17e ] In lio_enable_irq, the pkt_in_done count register was being cleared to zero. However, there could be some completed instructions which were not yet processed due to budget and limit constraints. So, only write this register with the number of actual completions that were processed. Signed-off-by:
Rick Farrington <ricardo.farrington@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 64858773 ] This patch adds missing properties to the CODEC and sound nodes, so the audio will work also on Snow rev5 Chromebook. This patch is an extension to the commit e9eefc3f ("ARM: dts: exynos: Add missing clock and DAI properties to the max98095 node in Snow Chromebook") and commit 6ab56993 ("ARM: dts: exynos: Enable HDMI audio on Snow Chromebook"). It has been reported that such changes work fine on the rev5 board too. Signed-off-by:
-
Andrzej Hajda authored
[ Upstream commit 21cb5a27 ] HDMI-HPD was set active low, moreover by default pincontrol chip sets pull-down on the pin. As a result HDMI driver assumes TV is always connected regardless of actual state. The patch fixes it. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Andrzej Hajda authored
[ Upstream commit 620375c8 ] HDMI-DDC for unknown reasons doesn't work with Exynos I2C controllers. Fortunately i2c-gpio comes to the rescue. Signed-off-by:
-
Tuomas Tynkkynen authored
[ Upstream commit feef7918 ] Setting GPIO 21 high seems to be required to enable power to USB ports on the WNDR3400v3. As there is already similar code for WNR3500L, make the existing USB power GPIO code generic and use that. Signed-off-by:
Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/20259/ Cc: Rafał Miłecki <zajec5@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Paul Cercueil authored
[ Upstream commit 556a36a7 ] Using postcore_initcall() makes the driver try to initialize way too early. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Akshu Agrawal authored
[ Upstream commit a1b1e988 ] 25Mhz MCLK which was earlier used was of spread type. Thus, we were not getting accurate rate. The 48Mhz system clk is of non-spread type and we are changing to it to get accurate rate. Signed-off-by:
Akshu Agrawal <akshu.agrawal@amd.com> Reviewed-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Jerome Brunet authored
[ Upstream commit dadfab72 ] Return value of request_irq() was irgnored. Fix this and report the failure if any Fixes: 6dc4fa17 ("ASoC: meson: add axg fifo base driver") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
-
Charles Keepax authored
[ Upstream commit e33ffbd9 ] If the CPU DAI does not initialise rate_max, say if using using KNOT or CONTINUOUS, then the rate_max field will be initialised to 0. A value of zero in the rate_max field of the hardware runtime will cause the sound card to support no sample rates at all. Obviously this is not desired, just a different mechanism is being used to apply the constraints. As such update the setting of rate_max in dpcm_init_runtime_hw to be consistent with the non-DPCM cases and set rate_max to UINT_MAX if nothing is defined on the CPU DAI. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Charles Keepax authored
[ Upstream commit a5cd7e9c ] devm_pinctrl_get will only return NULL in the case that pinctrl is not built into the kernel and all the pinctrl functions used by the DAPM core are appropriately stubbed for that case. There is no need to error out of snd_soc_dapm_new_control_unlocked if pinctrl isn't built into the kernel, so change the IS_ERR_OR_NULL to just an IS_ERR. Signed-off-by:
-
Anirudh Venkataramanan authored
[ Upstream commit 9ea47d81 ] Remove the "ice" prefix for the driver version string and bump version to 0.7.1-k. Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by:
-
Bob Peterson authored
[ Upstream commit 4f36cb36 ] The GFS2_RDF_UPTODATE flag in the rgrp is used to determine when a rgrp buffer is valid. It's cleared when the glock is invalidated, signifying that the buffer data is now invalid. But before this patch, function update_rgrp_lvb was setting the flag when it determined it had a valid lvb. But that's an invalid assumption: just because you have a valid lvb doesn't mean you have valid buffers. After all, another node may have made the lvb valid, and this node just fetched it from the glock via dlm. Consider this scenario: 1. The file system is mounted with RGRPLVB option. 2. In gfs2_inplace_reserve it locks the rgrp glock EX, but thanks to GL_SKIP, it skips the gfs2_rgrp_bh_get. 3. Since loops == 0 and the allocation target (ap->target) is bigger than the largest known chunk of blocks in the rgrp (rs->rs_rbm.rgd->rd_extfail_pt) it skips that rgrp and bypasses the call to gfs2_rgrp_bh_get there as well. 4. update_rgrp_lvb sees the lvb MAGIC number is valid, so bypasses gfs2_rgrp_bh_get, but it still sets sets GFS2_RDF_UPTODATE due to this invalid assumption. 5. The next time update_rgrp_lvb is called, it sees the bit is set and just returns 0, assuming both the lvb and rgrp are both uptodate. But since this is a smaller allocation, or space has been freed by another node, thus adjusting the lvb values, it decides to use the rgrp for allocations, with invalid rd_free due to the fact it was never updated. This patch changes update_rgrp_lvb so it doesn't set the UPTODATE flag anymore. That way, it has no choice but to fetch the latest values. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Anirudh Venkataramanan authored
[ Upstream commit fd2a9817 ] Once reset is issued, the driver loses all control queue interfaces. Exercising control queue operations during reset is incorrect and may result in long timeouts. This patch introduces a new field 'reset_ongoing' in the hw structure. This is set to 1 by the core driver when it receives a reset interrupt. ice_sq_send_cmd checks reset_ongoing before actually issuing the control queue operation. If a reset is in progress, it returns a soft error code (ICE_ERR_RESET_PENDING) to the caller. The caller may or may not have to take any action based on this return. Once the driver knows that the reset is done, it has to set reset_ongoing back to 0. This will allow control queue operations to be posted to the hardware again. This "bail out" logic was specifically added to ice_sq_send_cmd (which is pretty low level function) so that we have one solution in one place that applies to all types of control queues. Signed-off-by:
-
Dan Nowlin authored
[ Upstream commit ff2b1321 ] Align Request Resource Ownership AQ command (0x0008) to the latest specification. This includes: - Correcting the resource IDs for the Global Cfg and Change locks. - new enum ICE_CHANGE_LOCK_RES_ID - new enum ICE_GLOBAL_CFG_LOCK_RES_ID - Altering the flow for Global Config Lock to allow only the first PF to download the package. Signed-off-by:
Dan Nowlin <dan.nowlin@intel.com> Signed-off-by:
-
Sven Eckelmann authored
[ Upstream commit 34d5629d ] Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in the RX and TX path. These filtered channel can in theory still be used by the hardware but the signal strength is reduced so much that it makes no sense. There is already a DT property to limit the available channels but ath10k has to manually call this functionality to limit the currrently set wiphy channels further. Signed-off-by:
Sven Eckelmann <sven.eckelmann@openmesh.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Dedy Lansky authored
[ Upstream commit 4405b632 ] Check rx_buff_mgmt is allocated before accessing its internal fields. Signed-off-by:
Dedy Lansky <dlansky@codeaurora.org> Signed-off-by:
Maya Erez <merez@codeaurora.org> Signed-off-by:
-
Maya Erez authored
[ Upstream commit df2b5388 ] In enhanced DMA ring 0 is used for RX ring, hence TX ring 0 is an unused element in ring_tx and ring2cid_tid arrays. Initialize ring2cid_tid CID to WIL6210_MAX_CID to prevent a false match of CID 0. Go over the ring_tx and ring2cid_tid from wil_get_min_tx_ring_id and on to prevent access to index 0 in eDMA. Signed-off-by:
-
Maya Erez authored
[ Upstream commit 596bdbcc ] use_rx_hw_reordering is already set to true in wil_set_capabilities for Talyn-MB devices. Remove its setting from wil_priv_init to prevent its activation for older chips. Similarly, move the setting of use_compressed_rx_status to wil_set_capabilities. Signed-off-by:
-
Dedy Lansky authored
[ Upstream commit 9a65064a ] Delivering a looped-back multicast packet to network stack can cause higher layer protocols to fail like for example IPv6 DAD. In STA mode, upon receiving Rx multicast packet, check if the source MAC address is equal to our own MAC address and if so drop the packet. Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit d9c52fd1 ] Tx99 is typically configured via a monitor mode interface, which does not get added to the driver as a vif. Since the code currently expects a configured virtual interface for tx99, enabling tx99 via debugfs fails. Since the vif is not needed anyway, remove all checks for it. Signed-off-by:
Felix Fietkau <nbd@nbd.name> [kvalo@codeaurora.org: s/CPTCFG/CONFIG/] Signed-off-by:
-
