summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-06-05USB: usb-storage: Add new ID to ums-realtekKai-Heng Feng
There is one more Realtek card reader requires ums-realtek to work correctly. Add the device ID to support it. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05Merge tag 'gvt-fixes-2019-06-05' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen
drm-intel-fixes gvt-fixes-2019-06-05 - Fix i915 guest debug build for register command access (Weinan) - Fix guest ring state after execution for hangcheck (Xiaolin) - klocwork static check fixes (Alek) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605084903.GX9684@zhen-hp.sh.intel.com
2019-06-05ARM: dts: imx7d-sdb: Make SW2's voltage fixedAnson Huang
On i.MX7D SDB board, SW2 supplies a lot of peripheral devices, its voltage should be fixed at 1.8V. The commit 43967d9b5a7c ("ARM: dts: imx7d-sdb: Assign corresponding power supply for LDOs") assigns SW2 as the supplier of vdd1p0d, and when its comsumers pcie-phy/mipi-phy try to set the vdd1p0d to 1.0V, regulator core will also set SW2 to its best(min) voltage to 1.5V, and it will lead to board reset. This patch makes SW2's voltage fixed at 1.8V to avoid this issue. Fixes: 43967d9b5a7c ("ARM: dts: imx7d-sdb: Assign corresponding power supply for LDOs") Reported-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: dts: imx8mm: Move usbphy out of soc nodeFabio Estevam
usbphy nodes do not have any register properties and thus shouldn't be placed inside the bus. Move usbphy nodes from soc node to root node in order to fix the following build warnings with W=1: arch/arm64/boot/dts/freescale/imx8mm.dtsi:681.27-687.6: Warning (simple_bus_reg): /soc/bus@32c00000/usbphynop1: missing or empty reg/ranges property arch/arm64/boot/dts/freescale/imx8mm.dtsi:710.27-716.6: Warning (simple_bus_reg): /soc/bus@32c00000/usbphynop2: missing or empty reg/ranges property Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: dts: imx8mm: Pass the 'ranges' propertyFabio Estevam
Pass the 'ranges' property for each one of the AIPS bus in order to fix the following build warnings: arch/arm64/boot/dts/freescale/imx8mm.dtsi:209.23-388.5: Warning (unit_address_vs_reg): /soc/bus@30000000: node has a unit name, but no reg property arch/arm64/boot/dts/freescale/imx8mm.dtsi:390.23-439.5: Warning (unit_address_vs_reg): /soc/bus@30400000: node has a unit name, but no reg property arch/arm64/boot/dts/freescale/imx8mm.dtsi:441.23-658.5: Warning (unit_address_vs_reg): /soc/bus@30800000: node has a unit name, but no reg property arch/arm64/boot/dts/freescale/imx8mm.dtsi:660.23-724.5: Warning (unit_address_vs_reg): /soc/bus@32c00000: node has a unit name, but no reg property This also aligns with imx8mq.dtsi. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: dts: imx8mm: Pass a unit name for the 'soc' nodeFabio Estevam
The 'soc' name needs a unit name to match its 'ranges' property. Pass the unit name in order to fix the following dtc build warning with W=1: arch/arm64/boot/dts/freescale/imx8mm.dtsi:203.6-754.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name This also aligns with imx8mq.dtsi. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: dts: fsl: imx8mq: add the snvs power key nodeAngus Ainslie (Purism)
Add a node for the snvs power key, "disabled" by default. Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05udmabuf: actually unmap the scatterlistLucas Stach
unmap_udmabuf fails to actually unmap the scatterlist, leaving dangling mappings around. Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: http://patchwork.freedesktop.org/patch/msgid/20190604202331.17482-1-l.stach@pengutronix.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-06-05arm64: tegra: Add pin control states for I2C on Tegra186Thierry Reding
Two of the Tegra I2C controllers share pads with the DPAUX controllers. In order for the I2C controllers to use these pads, they have to be set into I2C mode. Use the I2C and off pin control states defined in the DT nodes for DPAUX as "default" and "idle" states, respectively. This ensures that the I2C controller driver can properly configure the pins when it needs to perform I2C transactions. Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-06-05arm64: tegra: Add CPU cache topology for Tegra186Joseph Lo
Tegra186 has two CPU clusters with its own cache hierarchy. This patch adds them with the cache information of each of the CPUs. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-06-05arm64: tegra: Add VCC supply for GPIO expanders on Jetson TX2Thierry Reding
The GPIO expanders on Jetson TX2 are powered by the VDD_1V8 and VDD_3V3_SYS supplies, respectively. Model this in device tree so that the correct supplies are referenced. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-06-05arm64: dts: ls1028a: fix watchdog device nodeChuanhua Han
ls1028a platform uses sp805 watchdog, and use 1/16 platform clock as timer clock, this patch fix device tree node. Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: dts: ls1028a: Enable sata.Peng Ma
Change the sata node to enable sata. Signed-off-by: Peng Ma <peng.ma@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: dts: imx: add i.MX8QXP ocotp supportPeng Fan
Add i.MX8QXP ocotp node Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Anson Huang <anson.huang@nxp.com> Cc: Daniel Baluta <daniel.baluta@nxp.com> Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: dts: imx8qxp: Move watchdog node into scu nodeAnson Huang
i.MX system controller watchdog has pretimeout function which depends on i.MX SCU driver, so it should be a subnode of SCU. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-04net: fix indirect calls helpers for ptype list hooks.Paolo Abeni
As Eric noted, the current wrapper for ptype func hook inside __netif_receive_skb_list_ptype() has no chance of avoiding the indirect call: we enter such code path only for protocols other than ipv4 and ipv6. Instead we can wrap the list_func invocation. v1 -> v2: - use the correct fix tag Fixes: f5737cbadb7d ("net: use indirect calls helpers for ptype hook") Suggested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Edward Cree <ecree@solarflare.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: ipvlan: Fix ipvlan device tso disabled while NETIF_F_IP_CSUM is setMiaohe Lin
There's some NICs, such as hinic, with NETIF_F_IP_CSUM and NETIF_F_TSO on but NETIF_F_HW_CSUM off. And ipvlan device features will be NETIF_F_TSO on with NETIF_F_IP_CSUM and NETIF_F_IP_CSUM both off as IPVLAN_FEATURES only care about NETIF_F_HW_CSUM. So TSO will be disabled in netdev_fix_features. For example: Features for enp129s0f0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: on Fixes: a188222b6ed2 ("net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04scsi: smartpqi: unlock on error in pqi_submit_raid_request_synchronous()Dan Carpenter
We need to drop the "ctrl_info->sync_request_sem" lock before returning. Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Don Brace <don.brace@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-06-04scsi: ufs: Check that space was properly alloced in copy_query_responseAvri Altman
struct ufs_dev_cmd is the main container that supports device management commands. In the case of a read descriptor request, we assume that the proper space was allocated in dev_cmd to hold the returning descriptor. This is no longer true, as there are flows that doesn't use dev_cmd for device management requests, and was wrong in the first place. Fixes: d44a5f98bb49 (ufs: query descriptor API) Signed-off-by: Avri Altman <avri.altman@wdc.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-06-04udp: only choose unbound UDP socket for multicast when not in a VRFTim Beale
By default, packets received in another VRF should not be passed to an unbound socket in the default VRF. This patch updates the IPv4 UDP multicast logic to match the unicast VRF logic (in compute_score()), as well as the IPv6 mcast logic (in __udp_v6_is_mcast_sock()). The particular case I noticed was DHCP discover packets going to the 255.255.255.255 address, which are handled by __udp4_lib_mcast_deliver(). The previous code meant that running multiple different DHCP server or relay agent instances across VRFs did not work correctly - any server/relay agent in the default VRF received DHCP discover packets for all other VRFs. Fixes: 6da5b0f027a8 ("net: ensure unbound datagram socket to be chosen when not in a VRF") Signed-off-by: Tim Beale <timbeale@catalyst.net.nz> Reviewed-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04Merge branch 'net-tls-redo-the-RX-resync-locking'David S. Miller
Jakub Kicinski says: ==================== net/tls: redo the RX resync locking Take two of making sure we don't use a NULL netdev pointer for RX resync. This time using a bit and an open coded wait loop. v2: - fix build warning (DaveM). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net/tls: replace the sleeping lock around RX resync with a bit lockJakub Kicinski
Commit 38030d7cb779 ("net/tls: avoid NULL-deref on resync during device removal") tried to fix a potential NULL-dereference by taking the context rwsem. Unfortunately the RX resync may get called from soft IRQ, so we can't use the rwsem to protect from the device disappearing. Because we are guaranteed there can be only one resync at a time (it's called from strparser) use a bit to indicate resync is busy and make device removal wait for the bit to get cleared. Note that there is a leftover "flags" field in struct tls_context already. Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04Revert "net/tls: avoid NULL-deref on resync during device removal"Jakub Kicinski
This reverts commit 38030d7cb77963ba84cdbe034806e2b81245339f. Unfortunately the RX resync may get called from soft IRQ, so we can't take the rwsem to protect from the device disappearing. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04block: aoe: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: "Ed L. Cashin" <ed.cashin@acm.org> Cc: linux-block@vger.kernel.org Cc: Omar Sandoval <osandov@osandov.com> Acked-by: Justin Sanders <justin@coraid.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-06-04ARM: dts: rockchip: Add pin names for rk3288-veyron jaq, mickey, speedyDouglas Anderson
This is like commit 0ca87bd5baa6 ("ARM: dts: rockchip: Add pin names for rk3288-veyron-jerry") and commit ca3516b32cd9 ("ARM: dts: rockchip: Add pin names for rk3288-veyron-minnie") but for 3 more veyron boards. A few notes: - While there is most certainly duplication between all the veyron boards, it still feels like it is sane to just have each board have a full list of its pin names. The format of "gpio-line-names" does not lend itself to one-off overriding and besides it seems sane to more fully match schematic names. Also note that the extra duplication here is only in source code and is unlikely to ever change (since these boards are shipped). Duplication in the .dtb files is unavoidable. - veyron-jaq and veyron-mighty are very closely related and so I have shared a single list for them both with comments on how they are different. This is just a typo fix on one of the boards, a possible missing signal on one of the boards (or perhaps I was never given the most recent schematics?) and dealing with the fact that one of the two boards has full sized SD. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-04net: dsa: sja1105: Fix link speed not working at 100 Mbps and belowVladimir Oltean
The hardware values for link speed are held in the sja1105_speed_t enum. However they do not increase in the order that sja1105_get_speed_cfg was iterating over them (basically from SJA1105_SPEED_AUTO - 0 - to SJA1105_SPEED_1000MBPS - 1 - skipping the other two). Another bug is that the code in sja1105_adjust_port_config relies on the fact that an invalid link speed is detected by sja1105_get_speed_cfg and returned as -EINVAL. However storing this into an enum that only has positive members will cast it into an unsigned value, and it will miss the negative check. So take the simplest approach and remove the sja1105_get_speed_cfg function and replace it with a simple switch-case statement. Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Suggested-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: phylink: avoid reducing support maskRussell King
Avoid reducing the support mask as a result of the interface type selected for SFP modules, or when setting the link settings through ethtool - this should only change when the supported link modes of the hardware combination change. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05scripts/checkstack.pl: Fix arm64 wrong or unknown architectureGeorge G. Davis
The following error occurs for the `make ARCH=arm64 checkstack` case: aarch64-linux-gnu-objdump -d vmlinux $(find . -name '*.ko') | \ perl ./scripts/checkstack.pl arm64 wrong or unknown architecture "arm64" As suggested by Masahiro Yamada, fix the above error using regular expressions in the same way it was fixed for the `ARCH=x86` case via commit fda9f9903be6 ("scripts/checkstack.pl: automatically handle 32-bit and 64-bit mode for ARCH=x86"). Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-05kbuild: tar-pkg: enable communication with jobserverTrevor Bourget
The buildtar script might want to invoke a make, so tell the parent make to pass the jobserver token pipe to the subcommand by prefixing the command with a +. This addresses the issue seen here: /bin/sh ../scripts/package/buildtar tar-pkg make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. See https://www.gnu.org/software/make/manual/html_node/Job-Slots.html for more information. Signed-off-by: Trevor Bourget <tgb.kernel@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-05kconfig: tests: fix recursive inclusion unit testMasahiro Yamada
Adding SPDX license identifier is pretty safe; however, here is one exception. Since commit ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig"), "make testconfig" would not pass. When Kconfig detects a circular file inclusion, it displays error messages with a file name and a line number prefixed to each line. The unit test checks if Kconfig emits the error messages correctly (this also checks the line number correctness). Now that the test input has the SPDX license identifier at the very top, the line numbers in the expected stderr should be incremented by 1. Fixes: ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-05kbuild: teach kselftest-merge to find nested config filesDan Rue
Current implementation of kselftest-merge only finds config files that are one level deep using `$(srctree)/tools/testing/selftests/*/config`. Often, config files are added in nested directories, and do not get picked up by kselftest-merge. Use `find` to catch all config files under `$(srctree)/tools/testing/selftests` instead. Signed-off-by: Dan Rue <dan.rue@linaro.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-04nvmet: fix data_len to 0 for bdev-backed write_zeroesMinwoo Im
The WRITE ZEROES command has no data transfer so that we need to initialize the struct (nvmet_req *req)->data_len to 0x0. While (nvmet_req *req)->transfer_len is initialized in nvmet_req_init(), data_len will be initialized by nowhere which might cause the failure with status code NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR randomly. It's because nvmet_req_execute() checks like: if (unlikely(req->data_len != req->transfer_len)) { req->error_loc = offsetof(struct nvme_common_command, dptr); nvmet_req_complete(req, NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR); } else req->execute(req); This patch fixes req->data_len not to be a randomly assigned by initializing it to 0x0 when preparing the command in nvmet_bdev_parse_io_cmd(). nvmet_file_parse_io_cmd() which is for file-backed I/O has already initialized the data_len field to 0x0, though. Cc: Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me> Cc: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com> Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
2019-06-04MAINTAINERS: Hand over skd maintainershipBart Van Assche
Since I do no longer have access to any STEC SSDs, hand over maintainership of the skd driver to Damien who still has access to STEC SSDs. Cc: Bart Van Assche <bart.vanassche@wdc.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Hannes Reinecke <hare@suse.com> Acked-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-06-04ASoC: sun4i-i2s: Add offset to RX channel selectMarcus Cooper
Whilst testing the capture functionality of the i2s on the newer SoCs it was noticed that the recording was somewhat distorted. This was due to the offset not being set correctly on the receiver side. Signed-off-by: Marcus Cooper <codekipper@gmail.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-04ASoC: sun4i-i2s: Fix sun8i tx channel offset maskMarcus Cooper
Although not causing any noticeable issues, the mask for the channel offset is covering too many bits. Signed-off-by: Marcus Cooper <codekipper@gmail.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-04ASoC: max98090: remove 24-bit format support if RJ is 0Yu-Hsuan Hsu
The supported formats are S16_LE and S24_LE now. However, by datasheet of max98090, S24_LE is only supported when it is in the right justified mode. We should remove 24-bit format if it is not in that mode to avoid triggering error. Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-04ASoC: da7219: Fix build error without CONFIG_I2CYueHaibing
Fix gcc build error while CONFIG_I2C is not set sound/soc/codecs/da7219.c:2640:1: warning: data definition has no type or storage class module_i2c_driver(da7219_i2c_driver); ^~~~~~~~~~~~~~~~~ sound/soc/codecs/da7219.c:2640:1: error: type defaults to int in declaration of module_i2c_driver [-Werror=implicit-int] sound/soc/codecs/da7219.c:2640:1: warning: parameter names (without types) in function declaration sound/soc/codecs/da7219.c:2629:26: warning: da7219_i2c_driver defined but not used [-Wunused-variable] Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 6d817c0e9fd7 ("ASoC: codecs: Add da7219 codec driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-04ASoC: SOF: Intel: hda: Fix COMPILE_TEST build errorYueHaibing
while building without PCI: sound/soc/sof/intel/hda.o: In function `hda_dsp_probe': hda.c:(.text+0x79c): undefined reference to `pci_ioremap_bar' hda.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `pci_ioremap_bar' hda.c:(.text+0x7c4): undefined reference to `pci_ioremap_bar' hda.c:(.text+0x7c4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `pci_ioremap_bar' Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e13ef82a9ab8 ("ASoC: SOF: add COMPILE_TEST for PCI options") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-04drm/arm/hdlcd: Allow a bit of clock toleranceRobin Murphy
On the Arm Juno platform, the HDLCD pixel clock is constrained to 250KHz resolution in order to avoid the tiny System Control Processor spending aeons trying to calculate exact PLL coefficients. This means that modes like my oddball 1600x1200 with 130.89MHz clock get rejected since the rate cannot be matched exactly. In practice, though, this mode works quite happily with the clock at 131MHz, so let's relax the check to allow a little bit of slop. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2019-06-04drm/arm/hdlcd: Actually validate CRTC modesRobin Murphy
Rather than allowing any old mode through, then subsequently refusing unmatchable clock rates in atomic_check when it's too late to back out and pick a different mode, let's do that validation up-front where it will cause unsupported modes to be correctly pruned in the first place. This also eliminates an issue whereby a perceived clock rate of 0 would cause atomic disable to fail and prevent the module from being unloaded. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2019-06-04drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 timesWen He
This patch trying to fix monitor freeze issue caused by drm error 'flip_done timed out' on LS1028A platform. this set try is make a loop around the second setting CVAL and try like 5 times before giveing up. Signed-off-by: Wen He <wen.he_1@nxp.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2019-06-04drm/komeda: fixing of DMA mapping sg segment warningLowry Li (Arm Technology China)
Fixing the DMA mapping sg segment warning, which shows "DMA-API: mapping sg segment longer than device claims to support [len=921600] [max=65536]". Fixed by setting the max segment size at Komeda driver. This patch depends on: - https://patchwork.freedesktop.org/series/54448/ - https://patchwork.freedesktop.org/series/54449/ - https://patchwork.freedesktop.org/series/54450/ - https://patchwork.freedesktop.org/series/58976/ Changes since v1: - Adds member description - Adds patch denpendency in the comment Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com> Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Reviewed-by: Ayan Kumar Halder <ayan.halder@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2019-06-04arm64: dts: rockchip: add WiFi+BT support on ROCK Pi4 boardAkash Gajjar
Rock Pi 4 has a on board AP6256 WiFi/BT Module. enable wifi and bluetooth support on Rock Pi 4 board. Signed-off-by: Akash Gajjar <akash@openedev.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-04arm64: dts: rockchip: fix isp iommu clocks and power domainHelen Koike
isp iommu requires wrapper variants of the clocks. noc variants are always on and using the wrapper variants will activate {A,H}CLK_ISP{0,1} due to the hierarchy. Tested using the pending isp patch set (which is not upstream yet). Without this patch, streaming from the isp stalls. Also add the respective power domain and remove the "disabled" status. Refer: RK3399 TRM v1.4 Fig. 2-4 RK3399 Clock Architecture Diagram RK3399 TRM v1.4 Fig. 8-1 RK3399 Power Domain Partition Signed-off-by: Helen Koike <helen.koike@collabora.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-04ARM: dts: rockchip: fix pwm-cells for rk3288's pwm3John Keeping
This is the same as the other PWMs on this SoC and uses 3 cells. Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-04habanalabs: Read upper bits of trace buffer from RWPHITomer Tayar
The trace buffer address is 40 bits wide. The end of the buffer is set in the RWP register (lower 32 bits), and in the RWPHI register (upper 8 bits). Currently only the lower 32 bits are read, and this patch fixes it and concatenates the upper 8 bits to the output address. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-06-04drm: don't block fb changes for async plane updatesHelen Koike
In the case of a normal sync update, the preparation of framebuffers (be it calling drm_atomic_helper_prepare_planes() or doing setups with drm_framebuffer_get()) are performed in the new_state and the respective cleanups are performed in the old_state. In the case of async updates, the preparation is also done in the new_state but the cleanups are done in the new_state (because updates are performed in place, i.e. in the current state). The current code blocks async udpates when the fb is changed, turning async updates into sync updates, slowing down cursor updates and introducing regressions in igt tests with errors of type: "CRITICAL: completed 97 cursor updated in a period of 30 flips, we expect to complete approximately 15360 updates, with the threshold set at 7680" Fb changes in async updates were prevented to avoid the following scenario: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1 - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong) Where we have a single call to prepare fb2 but double cleanup call to fb2. To solve the above problems, instead of blocking async fb changes, we place the old framebuffer in the new_state object, so when the code performs cleanups in the new_state it will cleanup the old_fb and we will have the following scenario instead: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 Where calls to prepare/cleanup are balanced. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-6-helen.koike@collabora.com
2019-06-04drm/vc4: fix fb references in async updateHelen Koike
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.19+ Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.koike@collabora.com
2019-06-04drm/msm: fix fb references in async updateHelen Koike
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-4-helen.koike@collabora.com
2019-06-04drm/amd: fix fb references in async updateHelen Koike
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.20+ Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.com
generated by cgit (git 2.34.1) at 2025-09-22 22:11:26 +0000