- 27 Jan, 2020 40 commits
-
-
Eli Britstein authored
[ Upstream commit 2ecba2d1 ] The csum calculation is different for IPv4/6. For VLAN packets, tc_skb_protocol returns the VLAN protocol rather than the packet's one (e.g. IPv4/6), so csum is not calculated. Furthermore, VLAN may not be stripped so csum is not calculated in this case too. Calculate the csum for those cases. Fixes: d8b9605d ("net: sched: fix skb->protocol use in case of accelerated vlan path") Signed-off-by:
Eli Britstein <elibr@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Pablo Neira Ayuso authored
[ Upstream commit a01cbae5 ] Use the element from the loop iteration, not the same element we want to deactivate otherwise this branch always evaluates true. Fixes: 6c03ae21 ("netfilter: nft_set_hash: add non-resizable hashtable implementation") Reported-by:
Florian Westphal <fw@strlen.de> Tested-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Pablo Neira Ayuso authored
[ Upstream commit 3b02b0ad ] Call jhash_1word() for the 4-bytes key case from the insertion and deactivation path, otherwise big endian arch set lookups fail. Fixes: 446a8268 ("netfilter: nft_set_hash: add lookup variant for fixed size hashtable") Reported-by:
-
Surabhi Vishnoi authored
[ Upstream commit 761156ff ] The length of wmi tlv command for management tx send is calculated incorrectly in case of protected management frames as there is addition of IEEE80211_CCMP_MIC_LEN twice. This leads to improper behaviour of firmware as the wmi tlv mgmt tx send command for protected mgmt frames is formed wrongly. Fix the length calculation of wmi tlv command for mgmt tx send in case of protected management frames by adding the IEEE80211_CCMP_MIC_LEN only once. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 Fixes: 1807da49 "ath10k: wmi: add management tx by reference support over wmi" Signed-off-by:
Surabhi Vishnoi <svishnoi@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Axel Lin authored
[ Upstream commit c25d4788 ] The wm831x_dcdc_ilim entries needs to be uA because it is used to compare with min_uA and max_uA. While at it also make the array const and change to use unsigned int. Fixes: e4ee831f ("regulator: Add WM831x DC-DC buck convertor support") Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Vladimir Murzin authored
[ Upstream commit d410a8a4 ] To access PRBARn, where n is referenced as a binary number: MRC p15, 0, <Rt>, c6, c8+n[3:1], 4*n[0] ; Read PRBARn into Rt MCR p15, 0, <Rt>, c6, c8+n[3:1], 4*n[0] ; Write Rt into PRBARn To access PRLARn, where n is referenced as a binary number: MRC p15, 0, <Rt>, c6, c8+n[3:1], 4*n[0]+1 ; Read PRLARn into Rt MCR p15, 0, <Rt>, c6, c8+n[3:1], 4*n[0]+1 ; Write Rt into PRLARn For PR{B,L}AR4, n is 4, n[0] is 0, n[3:1] is 2, while current encoding done with n[0] set to 1 which is wrong. Use proper encoding instead. Fixes: 046835b4 ("ARM: 8757/1: NOMMU: Support PMSAv8 MPU") Signed-off-by:
Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Vladimir Murzin authored
[ Upstream commit 9db043d3 ] arm64 has got relaxation on GIC version check at early boot stage due to update of the GIC architecture let's align ARM with that. To help backports (even though the code was correct at the time of writing) Fixes: e59941b9 ("ARM: 8527/1: virt: enable GICv3 system registers") Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit ca70ea43 ] MCPM does a soft reset of the CPUs and uses common cpu_resume() routine to perform low-level platform initialization. This results in a try to install HYP stubs for the second time for each CPU and results in false HYP/SVC mode mismatch detection. The HYP stubs are already installed at the beginning of the kernel initialization on the boot CPU (head.S) or in the secondary_startup() for other CPUs. To fix this issue MCPM code should use a cpu_resume() routine without HYP stubs installation. This change fixes HYP/SVC mode mismatch on Samsung Exynos5422-based Odroid XU3/XU4/HC1 boards. Fixes: 3721924c ("ARM: 8081/1: MCPM: provide infrastructure to allow for MCPM loopback") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Tested-by:
Anand Moon <linux.amoon@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 18b3af44 ] A change made in the final version of IOMMU debugfs support replaced the public function iommu_debugfs_new_driver_dir() by the public dentry iommu_debugfs_dir in <linux/iommu.h>, but forgot to update both the implementation in iommu-debugfs.c, and the patch description. Fix this by exporting iommu_debugfs_dir, and removing the reference to and implementation of iommu_debugfs_new_driver_dir(). Fixes: bad614b2 ("iommu: Enable debugfs exposure of IOMMU driver internals") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit 1e20186e ] We need to handle mmc_of_parse() errors during probe otherwise the MMC driver could start without proper initialization (e.g. power sequence). Fixes: 476bf3d6 ("mmc: sdhci-brcmstb: Add driver for Broadcom BRCMSTB SoCs") Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 5085607d ] If a bulk layout recall or a metadata server reboot coincides with a umount, then holding a reference to an inode is unsafe unless we also hold a reference to the super block. Fixes: fd9a8d71 ("NFSv4.1: Fix bulk recall and destroy of layouts") Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Mattias Jacobsson authored
[ Upstream commit c355ec65 ] In the function wmi_dev_match() the variable id is dereferenced without first performing a NULL check. The variable can for example be NULL if a WMI driver is registered without specifying the id_table field in struct wmi_driver. Add a NULL check and return that the driver can't handle the device if the variable is NULL. Fixes: 844af950 ("platform/x86: wmi: Turn WMI into a bus driver") Signed-off-by:
Mattias Jacobsson <2pi@mok.nu> Signed-off-by:
Darren Hart (VMware) <dvhart@infradead.org> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit b9307420 ] While freeing interrupt handlers in error path, don't assume that all requested interrupts are per-processor interrupts and properly release standard interrupts too. Reported-by:
Krzysztof Kozlowski <krzk@kernel.org> Fixes: 56a94f13 ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier") Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit e7e7e0d7 ] If the clock tree is not fully populated when the timer-sun5i init code is called, attempts to get the clock rate for the timer would fail and return 0. Make the init code for both clock events and clocksource check the returned clock rate and fail gracefully if the result is 0, instead of causing a divide by 0 exception later on. Fixes: 4a59058f ("clocksource/drivers/sun5i: Refactor the current code") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Alexander Shishkin authored
[ Upstream commit c60f83b8 ] Currently, the address range calculation for file-based filters works as long as the vma that maps the matching part of the object file starts from offset zero into the file (vm_pgoff==0). Otherwise, the resulting filter range would be off by vm_pgoff pages. Another related problem is that in case of a partially matching vma, that is, a vma that matches part of a filter region, the filter range size wouldn't be adjusted. Fix the arithmetics around address filter range calculations, taking into account vma offset, so that the entire calculation is done before the filter configuration is passed to the PMU drivers instead of having those drivers do the final bit of arithmetics. Based on the patch by Adrian Hunter <adrian.hunter.intel.com>. Reported-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Tested-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by:
Peter Zijlstra <peterz@infradead.org> Cc: Jiri Olsa <jolsa@redhat.com> Fixes: 375637bc ("perf/core: Introduce address range filtering") Link: http://lkml.kernel.org/r/20190215115655.63469-3-alexander.shishkin@linux.intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Alexander Shishkin authored
[ Upstream commit 18736eef ] When a child event is allocated in the inherit_event() path, the VMA based filter offsets are not copied from the parent, even though the address space mapping of the new task remains the same, which leads to no trace for the new task until exec. Reported-by:
Mansour Alharthi <malharthi9@gatech.edu> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 6f9449be ] Fix a soft lockup when NFS client delegation recovery is attempted but the inode is in the process of being freed. When the igrab(inode) call fails, and we have to restart the recovery process, we need to ensure that we won't attempt to recover the same delegation again. Fixes: 45870d69 ("NFSv4.1: Test delegation stateids when server...") Signed-off-by:
-
Michael Ellerman authored
[ Upstream commit 8cfaf106 ] In cpufeatures_process_feature(), if a provided CPU feature is unknown and enable_unknown is false, we erroneously print that the feature is being enabled and return true, even though no feature has been enabled, and may also set feature bits based on the last entry in the match table. Fix this so that we only set feature bits from the match table if we have actually enabled a feature from that table, and when failing to enable an unknown feature, always print the "not enabling" message and return false. Coincidentally, some older gccs (<GCC 7), when invoked with -fsanitize-coverage=trace-pc, cause a spurious uninitialised variable warning in this function: arch/powerpc/kernel/dt_cpu_ftrs.c: In function ‘cpufeatures_process_feature’: arch/powerpc/kernel/dt_cpu_ftrs.c:686:7: warning: ‘m’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (m->cpu_ftr_bit_mask) An upcoming patch will enable support for kcov, which requires this option. This patch avoids the warning. Fixes: 5a61ef74 ("powerpc/64s: Support new device tree binding for discovering CPU features") Reported-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [ajd: add commit message] Signed-off-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit e8edc32d ] Clang warns: drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c:2472:11: warning: implicit conversion from enumeration type 'enum halmac_cmd_process_status' to different enumeration type 'enum halmac_ret_status' [-Wenum-conversion] return HALMAC_CMD_PROCESS_ERROR; ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. Fix this by using the proper enum for allocation failures, HALMAC_RET_MALLOC_FAIL, which is used in the rest of this file. Fixes: e4b08e16 ("staging: r8822be: check kzalloc return or bail") Link: https://github.com/ClangBuiltLinux/linux/issues/375Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 40cc394b ] In the rare and unsupported case of a hostname list nfs_parse_devname will modify dev_name. There is no need to modify dev_name as the all that is being computed is the length of the hostname, so the computed length can just be shorted. Fixes: dc045898 ("NFS: Use common device name parsing logic for NFSv4 and NFSv2/v3") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Russell King authored
[ Upstream commit 9c2054a5 ] When a DSA port is added to a bridge and brought up, the resulting STP state programmed into the hardware depends on the order that these operations are performed. However, the Linux bridge code believes that the port is in disabled mode. If the DSA port is first added to a bridge and then brought up, it will be in blocking mode. If it is brought up and then added to the bridge, it will be in disabled mode. This difference is caused by DSA always setting the STP mode in dsa_port_enable() whether or not this port is part of a bridge. Since bridge always sets the STP state when the port is added, brought up or taken down, it is unnecessary for us to manipulate the STP state. Apparently, this code was copied from Rocker, and the very next day a similar fix for Rocker was merged but was not propagated to DSA. See e47172ab ("rocker: put port in FORWADING state after leaving bridge") Fixes: b73adef6 ("net: dsa: integrate with SWITCHDEV for HW bridging") Signed-off-by:
Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 8d166720 ] The apq8016 driver leaves the of-node refcount at aborting from the loop of for_each_child_of_node() in the error path. Not only the iterator node of for_each_child_of_node(), the children nodes referred from it for codec and cpu have to be properly unreferenced. Fixes: bdb052e8 ("ASoC: qcom: add apq8016 sound card support") Cc: Patrick Lai <plai@codeaurora.org> Cc: Banajit Goswami <bgoswami@codeaurora.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 36003d4c ] Commit 4c06c4e6 ("driver core: Fix possible supplier PM-usage counter imbalance") introduced a regression that causes suppliers to be suspended prematurely for device links added during consumer driver probe if the initial PM-runtime status of the consumer is "suspended" and the consumer is resumed after adding the link and before pm_runtime_put_suppliers() is called. In that case, pm_runtime_put_suppliers() will drop the rpm_active refcount for the link by one and (since rpm_active is equal to two after the preceding consumer resume) the supplier's PM-runtime usage counter will be decremented, which may cause the supplier to suspend even though the consumer's PM-runtime status is "active". For this reason, partially revert commit 4c06c4e6 as the problem it tried to fix needs to be addressed somewhat differently, and change pm_runtime_get_suppliers() and pm_runtime_put_suppliers() so that the latter only drops rpm_active references acquired by the former. [This requires adding a new field to struct device_link, but I coulnd't find a cleaner way to address the issue that would work in all cases.] This causes pm_runtime_put_suppliers() to effectively ignore device links added during consumer probe, so device_link_add() doesn't need to worry about ensuring that suppliers will remain active after pm_runtime_put_suppliers() for links created with DL_FLAG_RPM_ACTIVE set and it only needs to bump up rpm_active by one for those links, so pm_runtime_active_link() is not necessary any more. Fixes: 4c06c4e6 ("driver core: Fix possible supplier PM-usage counter imbalance") Reported-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 785cf1ee ] The NOUVEAU_GETPARAM_PCI_DEVICE case is missing a break statement and falls through to the following NOUVEAU_GETPARAM_BUS_TYPE case and may end up re-assigning the getparam->value to an undesired value. Fix this by adding in the missing break. Detected by CoverityScan, CID#1460507 ("Missing break in switch") Fixes: 359088d5 ("drm/nouveau: remove trivial cases of nvxx_device() usage") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit b1d03fc3 ] Currently the uninitialized values in the array reply are printed out when exec is false and nvkm_pmu_send has not updated the array. Avoid confusion by only dumping out these values if they have been actually updated. Detected by CoverityScan, CID#1271291 ("Uninitialized scaler variable") Fixes: ebb58dc2 ("drm/nouveau/pmu: rename from pwr (no binary change)") Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 13649101 ] Currently, the expression for calculating RON is always going to result in zero no matter the value of ram->mr[1] because the ! operator has higher precedence than the shift >> operator. I believe the missing parentheses around the expression before appying the ! operator will result in the desired result. [ Note, not tested ] Detected by CoveritScan, CID#1324005 ("Operands don't affect result") Fixes: c25bf7b6 ("drm/nouveau/bios/ramcfg: Separate out RON pull value") Signed-off-by:
-
Leon Romanovsky authored
[ Upstream commit 56642837 ] fpga_qpn was assigned but never used and compilation with W=1 produced the following warning: drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c: In function _mlx5_fpga_event_: drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c:320:6: warning: variable _fpga_qpn_ set but not used [-Wunused-but-set-variable] u32 fpga_qpn; ^~~~~~~~ Fixes: 98db16ba ("net/mlx5: FPGA, Handle QP error event") Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Vinod Koul authored
[ Upstream commit a968b5e9 ] RGMII_ID specifies that we should have internal delay, so resurrect the delay addition routine but under the RGMII_ID mode. Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode") Tested-by:
Michal Vokáč <michal.vokac@ysoft.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Axel Lin authored
[ Upstream commit a5455c91 ] Fix off-by-one while iterating current_limits array. The valid index should be 0 ~ n_current_limits -1. Fixes: c90456e3 ("regulator: pv88090: new regulator driver") Signed-off-by:
-
Axel Lin authored
[ Upstream commit 3c413f59 ] Fix off-by-one while iterating current_limits array. The valid index should be 0 ~ n_current_limits -1. Fixes: 99cf3af5 ("regulator: pv88080: new regulator driver") Signed-off-by:
-
Axel Lin authored
[ Upstream commit 7cd415f8 ] Fix off-by-one while iterating current_limits array. The valid index should be 0 ~ n_current_limits -1. Fixes: f307a7e9 ("regulator: pv88060: new regulator driver") Signed-off-by:
-
Arend van Spriel authored
[ Upstream commit aaf6a5e8 ] Since we moved the drivers debugfs directory under ieee80211 debugfs the debugfs entries need to be added after wiphy_register() has been called. For most part that has been done accordingly, but for the debugfs entries added by SDIO it was not and failed silently. This patch fixes that by adding a bus-layer callback for it. Fixes: 856d5a01 ("brcmfmac: allocate struct brcmf_pub instance using wiphy_new()") Reported-by:
Russel King <linux@armlinux.org.uk> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 0742a338 ] 'rv' is the correct return value, pass it upstream instead of 0 Fixes: 17d80d56 ("USB: autosuspend for cdc-wdm") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Robin Murphy authored
[ Upstream commit 3e5daee5 ] Using dma_dev->dev for mappings before it's assigned with the correct device is unlikely to work as expected, and with future dma-direct changes, passing a NULL device may end up crashing entirely. I don't know enough about this hardware or the mv_xor_prep_dma_interrupt() operation to implement the appropriate error-handling logic that would have revealed those dma_map_single() calls failing on arm64 for as long as the driver has been enabled there, but moving the assignment earlier will at least make the current code operate as intended. Fixes: 22843545 ("dma: mv_xor: Add support for DMA_INTERRUPT") Reported-by:
John David Anglin <dave.anglin@bell.net> Tested-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com> Tested-by:
-
Nicholas Mc Guire authored
[ Upstream commit e4b08e16 ] The kzalloc() in halmac_parse_psd_data_88xx() can fail and return NULL so check the psd_set->data after allocation and if allocation failed return HALMAC_CMD_PROCESS_ERROR. Signed-off-by:
-
Alexey Kardashevskiy authored
[ Upstream commit a67614cc ] The SPAPR TCE KVM device references all hardware IOMMU tables assigned to some IOMMU group to ensure that in-kernel KVM acceleration of H_PUT_TCE can work. The tables are references when an IOMMU group gets registered with the VFIO KVM device by the KVM_DEV_VFIO_GROUP_ADD ioctl; KVM_DEV_VFIO_GROUP_DEL calls into the dereferencing code in kvm_spapr_tce_release_iommu_group() which walks through the list of LIOBNs, finds a matching IOMMU table and calls kref_put() when found. However that code stops after the very first successful derefencing leaving other tables referenced till the SPAPR TCE KVM device is destroyed which normally happens on guest reboot or termination so if we do hotplug and unplug in a loop, we are leaking IOMMU tables here. This removes a premature return to let kvm_spapr_tce_release_iommu_group() find and dereference all attached tables. Fixes: 121f80ba ("KVM: PPC: VFIO: Add in-kernel acceleration for VFIO") Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 780feae7 ] Fix coccinelle warning: ./drivers/net/phy/mdio_bus.c:51:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44 ./drivers/net/phy/mdio_bus.c:52:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44 fix this by using IS_ERR before PTR_ERR Fixes: bafbdd52 ("phylib: Add device reset GPIO support") Signed-off-by:
-
Vadim Pasternak authored
[ Upstream commit ff066653 ] Fix tps53679_probe() by using dynamically allocated "pmbus_driver_info" structure instead of static. Usage of static structures causes overwritten of the field "vrm_version", in case the system is equipped with several tps53679 devices with the different "vrm_version". In such case the last probed device overwrites this field for all others. Fixes: 61052652 ("hwmon: (pmbus) Add support for Texas Instruments tps53679 device") Signed-off-by:
Vadim Pasternak <vadimp@mellanox.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Eric Auger authored
[ Upstream commit 0cfd027b ] pci_map_rom/pci_get_rom_size() performs memory access in the ROM. In case the Memory Space accesses were disabled, readw() is likely to trigger a synchronous external abort on some platforms. In case memory accesses were disabled, re-enable them before the call and disable them back again just after. Fixes: 89e1f7d4 ("vfio: Add PCI device driver") Signed-off-by:
Eric Auger <eric.auger@redhat.com> Suggested-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Jacopo Mondi authored
[ Upstream commit 5c88ee02 ] Since the removal of the stale soc_camera headers, Migo-R board fails to build due to missing dma-mapping include directive. Include missing dma-mapping.h header in Migo-R board file to fix the build error. Fixes: a50c7738 ("media: sh: migor: Remove stale soc_camera include") Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
