aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-07-19i40e: improve locking of mac_filter_hashStefan Assmann1-3/+20
i40e_config_vf_promiscuous_mode() calls i40e_getnum_vf_vsi_vlan_filters() without acquiring the mac_filter_hash_lock spinlock. This is unsafe because mac_filter_hash may get altered in another thread while i40e_getnum_vf_vsi_vlan_filters() traverses the hashes. Simply adding the spinlock in i40e_getnum_vf_vsi_vlan_filters() is not possible as it already gets called in i40e_get_vlan_list_sync() with the spinlock held. Therefore adding a wrapper that acquires the spinlock and call the correct function where appropriate. Fixes: 37d318d7805f ("i40e: Remove scheduling while atomic possibility") Fix-suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-19spi: fsi: Reduce max transfer size to 8 bytesEddie James1-103/+22
Security changes have forced the SPI controllers to be limited to 8 byte reads. Refactor the sequencing to just handle 8 bytes at a time. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210716133915.14697-2-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2021-07-19bnxt_en: Fix PTP capability discoveryMichael Chan1-1/+5
The current PTP initialization logic does not account for firmware reset that may cause PTP capability to change. The valid pointer bp->ptp_cfg is used to indicate that the device is capable of PTP and that it has been initialized. So we must clean up bp->ptp_cfg and free it if the firmware after reset does not support PTP. Fixes: 93cb62d98e9c ("bnxt_en: Enable hardware PTP support") Cc: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: Move bnxt_ptp_init() to bnxt_open()Michael Chan3-25/+16
The device needs to be in ifup state for PTP to function, so move bnxt_ptp_init() to bnxt_open(). This means that the PHC will be registered during bnxt_open(). This also makes firmware reset work correctly. PTP configurations may change after firmware upgrade or downgrade. bnxt_open() will be called after firmware reset, so it will work properly. bnxt_ptp_start() is now incorporated into bnxt_ptp_init(). We now also need to call bnxt_ptp_clear() in bnxt_close(). Fixes: 93cb62d98e9c ("bnxt_en: Enable hardware PTP support") Cc: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: Check abort error state in bnxt_half_open_nic()Somnath Kotur1-0/+6
bnxt_half_open_nic() is called during during ethtool self test and is protected by rtnl_lock. Firmware reset can be happening at the same time. Only critical portions of the entire firmware reset sequence are protected by the rtnl_lock. It is possible that bnxt_half_open_nic() can be called when the firmware reset sequence is aborting. In that case, bnxt_half_open_nic() needs to check if the ABORT_ERR flag is set and abort if it is. The ethtool self test will fail but the NIC will be brought to a consistent IF_DOWN state. Without this patch, if bnxt_half_open_nic() were to continue in this error state, it may crash like this: bnxt_en 0000:82:00.1 enp130s0f1np1: FW reset in progress during close, FW reset will be aborted Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... Process ethtool (pid: 333327, stack limit = 0x0000000046476577) Call trace: bnxt_alloc_mem+0x444/0xef0 [bnxt_en] bnxt_half_open_nic+0x24/0xb8 [bnxt_en] bnxt_self_test+0x2dc/0x390 [bnxt_en] ethtool_self_test+0xe0/0x1f8 dev_ethtool+0x1744/0x22d0 dev_ioctl+0x190/0x3e0 sock_ioctl+0x238/0x480 do_vfs_ioctl+0xc4/0x758 ksys_ioctl+0x84/0xb8 __arm64_sys_ioctl+0x28/0x38 el0_svc_handler+0xb0/0x180 el0_svc+0x8/0xc Fixes: a1301f08c5ac ("bnxt_en: Check abort error state in bnxt_open_nic().") Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: Validate vlan protocol ID on RX packetsMichael Chan1-5/+16
Only pass supported VLAN protocol IDs for stripped VLAN tags to the stack. The stack will hit WARN() if the protocol ID is unsupported. Existing firmware sets up the chip to strip 0x8100, 0x88a8, 0x9100. Only the 1st two protocols are supported by the kernel. Fixes: a196e96bb68f ("bnxt_en: clean up VLAN feature bit handling") Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: fix error path of FW resetSomnath Kotur1-10/+21
When bnxt_open() fails in the firmware reset path, the driver needs to gracefully abort, but it is executing code that should be invoked only in the success path. Define a function to abort FW reset and consolidate all error paths to call this new function. Fixes: dab62e7c2de7 ("bnxt_en: Implement faster recovery for firmware fatal error.") Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: Add missing check for BNXT_STATE_ABORT_ERR in bnxt_fw_rset_task()Michael Chan1-0/+4
In the BNXT_FW_RESET_STATE_POLL_VF state in bnxt_fw_reset_task() after all VFs have unregistered, we need to check for BNXT_STATE_ABORT_ERR after we acquire the rtnl_lock. If the flag is set, we need to abort. Fixes: 230d1f0de754 ("bnxt_en: Handle firmware reset.") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: Refresh RoCE capabilities in bnxt_ulp_probe()Michael Chan1-4/+5
The capabilities can change after firmware upgrade/downgrade, so we should get the up-to-date RoCE capabilities everytime bnxt_ulp_probe() is called. Fixes: 2151fe0830fd ("bnxt_en: Handle RESET_NOTIFY async event from firmware.") Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: reject ETS settings that will starve a TCEdwin Peer1-1/+9
ETS proportions are presented to HWRM_QUEUE_COS2BW_CFG as minimum bandwidth constraints. Thus, zero is a legal value for a given TC. However, if all the other TCs sum up to 100%, then at least one hardware queue will starve, resulting in guaranteed TX timeouts. Reject such nonsensical configurations. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19bnxt_en: don't disable an already disabled PCI deviceKalesh AP1-1/+2
If device is already disabled in reset path and PCI io error is detected before the device could be enabled, driver could call pci_disable_device() for already disabled device. Fix this problem by calling pci_disable_device() only if the device is already enabled. Fixes: 6316ea6db93d ("bnxt_en: Enable AER support.") Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-19ACPI: utils: Fix reference counting in for_each_acpi_dev_match()Andy Shevchenko3-9/+5
Currently it's possible to iterate over the dangling pointer in case the device suddenly disappears. This may happen becase callers put it at the end of a loop. Instead, let's move that call inside acpi_dev_get_next_match_dev(). Fixes: 803abec64ef9 ("media: ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver") Fixes: bf263f64e804 ("media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macro") Fixes: edbd1bc4951e ("efi/dev-path-parser: Switch to use for_each_acpi_dev_match()") Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-07-19ACPI: Kconfig: Fix table override from built-in initrdRobert Richter1-1/+1
During a rework of initramfs code the INITRAMFS_COMPRESSION config option was removed in commit 65e00e04e5ae. A leftover as a dependency broke the config option ACPI_TABLE_OVERRIDE_VIA_ BUILTIN_INITRD that is used to enable the overriding of ACPI tables from built-in initrd. Fixing the dependency. Fixes: 65e00e04e5ae ("initramfs: refactor the initramfs build rules") Signed-off-by: Robert Richter <rrichter@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-07-19Revert "drm/i915: Propagate errors on awaiting already signaled fences"Jason Ekstrand1-6/+2
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Error propagation along fences sound like a good idea, but as your bug shows, surprising consequences, since propagating errors across security boundaries is not a good thing. What we do have is track the hangs on the ctx, and report information to userspace using RESET_STATS. That's how arb_robustness works. Also, if my understanding is still correct, the EIO from execbuf is when your context is banned (because not recoverable or too many hangs). And in all these cases it's up to userspace to figure out what is all impacted and should be reported to the application, that's not on the kernel to guess and automatically propagate. What's more, we're also building more features on top of ctx error reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the userspace fence wait also relies on that mechanism. So it is the path going forward for reporting gpu hangs and resets to userspace. So all together that's why I think we should just bury this idea again as not quite the direction we want to go to, hence why I think the revert is the right option here. For backporters: Please note that you _must_ have a backport of https://lore.kernel.org/dri-devel/20210602164149.391653-2-jason@jlekstrand.net/ for otherwise backporting just this patch opens up a security bug. v2: Augment commit message. Also restore Jason's sob that I accidentally lost. v3: Add a note for backporters Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reported-by: Marcin Slusarz <marcin.slusarz@intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Cc: Jason Ekstrand <jason.ekstrand@intel.com> Cc: Marcin Slusarz <marcin.slusarz@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-3-jason@jlekstrand.net (cherry picked from commit 93a2711cddd5760e2f0f901817d71c93183c3b87) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-07-19drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"Jason Ekstrand4-276/+88
This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser"). The justification for this commit in the git history was a vague comment about getting it out from under the struct_mutex. While this may improve perf for some workloads on Gen7 platforms where we rely on the command parser for features such as indirect rendering, no numbers were provided to prove such an improvement. It claims to closed two gitlab/bugzilla issues but with no explanation whatsoever as to why or what bug it's fixing. Meanwhile, by moving command parsing off to an async callback, it leaves us with a problem of what to do on error. When things were synchronous, EXECBUFFER2 would fail with an error code if parsing failed. When moving it to async, we needed another way to handle that error and the solution employed was to set an error on the dma_fence and then trust that said error gets propagated to the client eventually. Moving back to synchronous will help us untangle the fence error propagation mess. This also reverts most of 0edbb9ba1bfe ("drm/i915: Move cmd parser pinning to execbuffer") which is a refactor of some of our allocation paths for asynchronous parsing. Now that everything is synchronous, we don't need it. v2 (Daniel Vetter): - Add stabel Cc and Fixes tag Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Cc: <stable@vger.kernel.org> # v5.6+ Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-2-jason@jlekstrand.net (cherry picked from commit 93b713304188844b8514074dc13ffd56d12235d3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-07-19Merge tag 'gvt-fixes-2021-07-15' of https://github.com/intel/gvt-linux into drm-intel-fixesRodrigo Vivi1-0/+15
gvt-fixes-2021-07-15 - Fix shadow ppgtt invalidation with proper D3 state tracking (Colin) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210715022237.GX12150@zhen-hp.sh.intel.com
2021-07-19drm/stm: dsi: compute the transition time from LP to HS and backAntonio Borneo1-4/+13
The driver uses a conservative set of hardcoded values for the maximum time delay of the transitions between LP and HS, either for data and clock lanes. By using the info in STM32MP157 datasheet, valid also for other ST devices, compute the actual delay from the lane's bps. Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Reviewed-by: Philippe Cornu <philippe.cornu@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713144941.3599-1-antonio.borneo@foss.st.com
2021-07-19drm/stm: ltdc: Silence -EPROBE_DEFER till bridge attachedJagan Teki1-3/+5
As dw-mipi-dsi supported all possible ways to find the DSI devices. It can take multiple iterations for ltdc to find all components attached to the DSI bridge. The current ltdc driver failed to find the endpoint as it returned -EINVAL for the first iteration itself. This leads to following error: [    3.099289] [drm:ltdc_load] *ERROR* init encoder endpoint 0 So, check the return value and cleanup the encoder only if it's not -EPROBE_DEFER. This make all components in the attached DSI bridge found properly. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210704135914.268308-1-jagan@amarulasolutions.com
2021-07-19spi: imx: Simplify logic in spi_imx_push()Uwe Kleine-König1-8/+3
For each usage of fifo_words it is clear if ->dynamic_burst is true or not. This can be used to simplify the function a bit. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20210716173927.2050620-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-19spi: pxa2xx: Reuse int_stop_and_reset() in couple of placesAndy Shevchenko1-9/+3
Reuse int_stop_and_reset() in couple of places. While at it, change the order of the int_stop_and_reset() and pxa2xx_spi_off() to be in align with the similar flow in int_error_stop(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210719074842.36060-3-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-19spi: pxa2xx: Reset DMA bits in CR1 in reset_sccr1()Andy Shevchenko1-1/+1
In order to allow reset_sccr1() to be reused in DMA paths, reset DMA bits in CR1 in this function. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210719074842.36060-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-19spi: pxa2xx: Convert reset_sccr1() to use pxa2xx_spi_update()Andy Shevchenko1-9/+7
Convert reset_sccr1() to use pxa2xx_spi_update(). It will help for further improvements. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210719074842.36060-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-19regulator: Fix a couple of spelling mistakes in KconfigColin Ian King1-2/+2
There are a couple of spelling mistakes in the Kconfig text. Fix them. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210719103429.15544-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-19spi: cadence: Correct initialisation of runtime PM againMarek Vasut1-5/+9
The original implementation of RPM handling in probe() was mostly correct, except it failed to call pm_runtime_get_*() to activate the hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM"), breaks the implementation further, to the point where the system using this hard IP on ZynqMP hangs on boot, because it accesses hardware which is gated off. Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM") and instead add missing pm_runtime_get_noresume() and move the RPM disabling all the way to the end of probe(). That makes ZynqMP not hang on boot yet again. Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210716182133.218640-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-19printk: index: Add indexing support to dev_printkChris Down1-3/+3
While for most kinds of issues we have counters, tracepoints, or metrics with a stable interface which can reliably be used to indicate issues, in order to react to production issues quickly we sometimes need to work with the interface which most kernel developers naturally use when developing: printk, and printk-esques like dev_printk. dev_printk is by far the most likely custom subsystem printk to benefit from the printk indexing infrastructure, since niche device issues brought about by production changes, firmware upgrades, and the like are one of the most common things that we need printk infrastructure's assistance to monitor. Often these errors were never expected to practically manifest in reality, and exhibit in code without extensive (or any) metrics present. As such, there are typically very few options for issue detection available to those with large fleets at the time the incident happens, and we thus benefit strongly from monitoring netconsole in these instances. As such, add the infrastructure for dev_printk to be indexed in the printk index. Even on a minimal kernel config, the coverage of the base kernel's printk index is significantly improved: Before: [root@ktst ~]# wc -l /sys/kernel/debug/printk/index/vmlinux 4497 /sys/kernel/debug/printk/index/vmlinux After: [root@ktst ~]# wc -l /sys/kernel/debug/printk/index/vmlinux 5573 /sys/kernel/debug/printk/index/vmlinux In terms of implementation, in order to trivially disambiguate them, dev_printk is now a macro which wraps _dev_printk. Signed-off-by: Chris Down <chris@chrisdown.name> Cc: Petr Mladek <pmladek@suse.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Petr Mladek <pmladek@suse.com> Tested-by: Petr Mladek <pmladek@suse.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/959c7aed1017cb2c9de922e0a820d397e29c6a5a.1623775748.git.chris@chrisdown.name
2021-07-19Drivers: hv: vmbus: Fix duplicate CPU assignments within a deviceHaiyang Zhang1-32/+64
The vmbus module uses a rotational algorithm to assign target CPUs to a device's channels. Depending on the timing of different device's channel offers, different channels of a device may be assigned to the same CPU. For example on a VM with 2 CPUs, if NIC A and B's channels are offered in the following order, NIC A will have both channels on CPU0, and NIC B will have both channels on CPU1 -- see below. This kind of assignment causes RSS load that is spreading across different channels to end up on the same CPU. Timing of channel offers: NIC A channel 0 NIC B channel 0 NIC A channel 1 NIC B channel 1 VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd} Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd Rel_ID=14, target_cpu=0 Rel_ID=17, target_cpu=0 VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea} Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea Rel_ID=16, target_cpu=1 Rel_ID=18, target_cpu=1 Update the vmbus CPU assignment algorithm to avoid duplicate CPU assignments within a device. The new algorithm iterates num_online_cpus + 1 times. The existing rotational algorithm to find "next NUMA & CPU" is still here. But if the resulting CPU is already used by the same device, it will try the next CPU. In the last iteration, it assigns the channel to the next available CPU like the existing algorithm. This is not normally expected, because during device probe, we limit the number of channels of a device to be <= number of online CPUs. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Tested-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-19drivers: hv: Decouple Hyper-V clock/timer code from VMbus driversMichael Kelley3-8/+14
Hyper-V clock/timer code in hyperv_timer.c is mostly independent from other VMbus drivers, but building for ARM64 without hyperv_timer.c shows some remaining entanglements. A default implementation of hv_read_reference_counter can just read a Hyper-V synthetic register and be independent of hyperv_timer.c, so move this code out and into hv_common.c. Then it can be used by the timesync driver even if hyperv_timer.c isn't built on a particular architecture. If hyperv_timer.c *is* built, it can override with a faster implementation. Also provide stubs for stimer functions called by the VMbus driver when hyperv_timer.c isn't built. No functional changes. Signed-off-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/1626220906-22629-1-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-19clk: renesas: r9a07g044: Add clock and reset entries for ADCLad Prabhakar1-0/+6
Add clock and reset entries for ADC block in CPG driver. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210719085840.21842-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: r9a07g044: Add clock and reset entries for CANFDLad Prabhakar1-0/+4
Add clock and reset entries for CANFD in CPG driver. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210715182123.23372-6-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: Rename renesas-rzg2l-cpg.[ch] to rzg2l-cpg.[ch]Geert Uytterhoeven4-3/+3
Rename renesas-rzg2l-cpg.c and renesas-rzg2l-cpg.h to rzg2l-cpg.c resp. rzg2l-cpg.h, for consistency with other (sub)drivers. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/edc442daaedffcf10e835ff479d906fcae0e59db.1626268821.git.geert+renesas@glider.be
2021-07-19clk: renesas: r9a07g044: Add GPIO clock and reset entriesLad Prabhakar1-0/+5
Add GPIO clock and reset entries in CPG driver. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210712194422.12405-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: r9a07g044: Add SSIF-2 clock and reset entriesBiju Das1-0/+20
Add SSIF-2 clock and reset entries in CPG driver. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210702135010.5937-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: r9a07g044: Add USB clocks/resetsBiju Das1-0/+12
Add clock/reset entries for USB PHY control, USB2.0 host and device. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210630073013.22415-5-biju.das.jz@bp.renesas.com [geert: s/usb0_device/usb0_func] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: r9a07g044: Add DMAC clocks/resetsBiju Das1-0/+8
Add DMAC clock and reset entries in CPG driver. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210626081344.5783-10-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: r9a07g044: Add I2C clocks/resetsBiju Das1-0/+12
Add I2C{0,1,2,3} clock and reset entries. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210626081344.5783-9-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: r8a779a0: Add the DSI clocksKieran Bingham1-1/+3
The DSI clock is incorrectly defined as a fixed clock. This demonstrates itself as the dsi-encoders failing to correctly enable and start their PPI and HS clocks internally, and causes failures. Move the DSI parent clock to match the updates in the BSP, which resolves the initialisation procedures. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Fixes: 17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U") Link: https://lore.kernel.org/r/20210622232711.3219697-3-kieran.bingham@ideasonboard.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: r8a779a0: Add the DU clockKieran Bingham1-0/+1
The DU clock is added to the S3D1 clock parent. The Renesas BSP lists S2D1 as the clock parent, however there is no S2 clock on this platform. S3D1 is chosen as a best effort guess and demonstrates functionality but is not guaranteed to be correct. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Link: https://lore.kernel.org/r/20210622232711.3219697-2-kieran.bingham@ideasonboard.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: rzg2: Rename i2c-dvfs to iic-pmicGeert Uytterhoeven4-4/+4
As RZ/G2 SoCs do not support DVFS, the "iic-dvfs" module was renamed to "iic-pmic" in the RZ/G Series, 2nd Generation User’s Manual: Hardware Rev. 1.00. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/3e549b41989ff2797b998a1c749c9f607845f44a.1624016693.git.geert+renesas@glider.be
2021-07-19clk: renesas: rzg2l: Fix off-by-one check in rzg2l_cpg_clk_src_twocell_get()Lad Prabhakar1-1/+1
Fix clock index out of range check for module clocks in rzg2l_cpg_clk_src_twocell_get(). Fixes: ef3c613ccd68 ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210617155432.18827-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: rzg2l: Avoid mixing error pointers and NULLDan Carpenter1-1/+1
These functions accidentally return both error pointers and NULL when there is an error. It doesn't cause a problem but it is confusing and seems unintentional. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/YMtY7nOtqEvTokh7@mwanda Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: rzg2l: Fix a double free on errorDan Carpenter1-7/+1
The "pll_clk" and "clock" pointers are allocated with devm_kzalloc() so freeing them with kfree() will lead to a double free. This would only happen if probe failed, and the system is not bootable. Fixes: ef3c613ccd68 ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/YMtYs7LVveYH4eRe@mwanda Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: rzg2l: Fix return value and unused assignmentYang Li1-4/+2
Currently the function returns NULL on error, so exact error code is lost. This patch changes return convention of the function to use ERR_PTR() on error instead. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/1623896524-102058-1-git-send-email-yang.lee@linux.alibaba.com [geert: Drop curly braces] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19clk: renesas: rzg2l: Remove unneeded semicolonYang Li1-1/+1
Eliminate the following coccicheck warning: ./drivers/clk/renesas/renesas-rzg2l-cpg.c:299:2-3: Unneeded semicolon Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/1623749970-38020-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-07-19iio: light: si1145: remove redundant continue statementColin Ian King1-1/+0
The continue statement at the end of a for-loop has no effect, remove it. Addresses-Coverity: ("Continue has no effect") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210617081312.151746-1-colin.king@canonical.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: core: Support reading extended name as labelPaul Cercueil1-4/+7
The point of this new change is to make the IIO tree actually parsable. Before, given this attribute as a filename: in_voltage0_aux_sample_rate Userspace had no way to know if the attribute name was "aux_sample_rate" with no extended name, or "sample_rate" with "aux" as the extended name, or just "rate" with "aux_sample" as the extended name. This was somewhat possible to deduce when there was more than one attribute present for a given channel, e.g: in_voltage0_aux_sample_rate in_voltage0_aux_frequency There, it was possible to deduce that "aux" was the extended name. But even with more than one attribute, this wasn't very robust, as two attributes starting with the same prefix (e.g. "sample_rate" and "sample_size") would result in the first part of the prefix being interpreted as being part of the extended name. To address the issue, knowing that channels will never have both a label and an extended name, set the channel's label to the extended name. In this case, the label's attribute will also have the extended name in its filename, but we can live with that - userspace can open in_voltage0_<prefix>_label and verify that it returns <prefix> to obtain the extended name. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20210618123005.49867-3-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: core: Forbid use of both labels and extended namesPaul Cercueil1-0/+22
Extended names are a problem for user-space as they make the filenames in sysfs sometimes not parsable. They are now deprecated in favor of labels. This change makes sure that a device driver won't provide both labels and extended names for its channels. It has never been the case and we don't want it to happen. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210618123005.49867-2-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19Add startup time for each chip using inv_mpu6050 driverBaptiste Mansuy3-19/+36
Add startup time for each chip familly. This allows a better behaviour of the gyro and the accel. The gyro has now the time to stabilise itself thus making initial data discarding for gyro irrelevant. Signed-off-by: Baptiste Mansuy <bmansuy@invensense.com> Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Link: https://lore.kernel.org/r/20210621085731.9212-1-bmansuy@invensense.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: accel: adxl345: convert probe to device-managed functionsAlexandru Ardelean4-33/+9
This driver has two parts, one for i2c and one for spi, since the chip can operate with both wire protocols. The core file has a common adxl345_core_remove() function which puts the chip into a powerdown state. This can be implemented with a devm_add_action_or_reset() hook. Doing that means we can register the IIO device with devm_iio_device_register() and get rid of the adxl345_core_remove() function. The dev_set_drvdata() call can be removed as there is no other user of this private data anymore. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210624080441.8710-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: light: tcs3414: convert probe to device-managed routinesAlexandru Ardelean1-29/+19
This change converts the driver to use only device-managed init routines in the probe function of the driver. This way, we no longer need the tcs3414_remove() hook. We still need to keep the i2c_set_clientdata() call, as that's being used for the PM routines. And lastly, a devm_add_action_or_reset() hook is added to call the powerdown handler when the chip is uninitialized or the probe fails. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210624080534.9209-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: potentiometer: max5481: convert probe to device-managedAlexandru Ardelean1-13/+9
The change converts the probe function to use the devm_iio_device_register() function. Before calling that, we need to register an action to store the wiper back to non-volatile memory when the device is de-registered. We don't need to do this if the probe fails, because the only place where the probe can fail now is devm_iio_device_register() and that shouldn't create an IIO device (for userspace to poke at) if it fails. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210624080641.9953-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>