summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-07-09dt-bindings: drop stale Anson Huang from maintainersKrzysztof Kozlowski
Emails to Anson Huang bounce: Diagnostic-Code: smtp; 550 5.4.1 Recipient address rejected: Access denied. Add IMX platform maintainers for bindings which would become orphaned. Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Reviewed-by: Fabio Estevam <festevam@gmail.com> Acked-by: Peng Fan <peng.fan@nxp.com> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # for I2C Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for IIO Acked-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20240617065828.9531-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-07-09kbuild: verify dtoverlay files against schemaDmitry Baryshkov
Currently only the single part device trees are validated against DT schema. For the multipart DT files only the base DTB is validated. Extend the fdtoverlay commands to validate the resulting DTB file against schema. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240527-dtbo-check-schema-v1-1-ee1094f88f74@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-07-09dt-bindings: clock: drop obsolete stericsson,abx500.txtStanislav Jakubek
These bindings are already (better) described in mfd/stericsson,ab8500.yaml, drop these now obsolete bindings. Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/Zm7I2Zbq1JNPoEJp@standask-GA-A55M-S2HP Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-07-09Merge tag 'zynqmp-soc2-for-6.11' of https://github.com/Xilinx/linux-xlnx ↵Arnd Bergmann
into soc/drivers arm64: Xilinx SoC changes for 6.11 Timer - Fix u32 overflow issue in 32-bit width PWM mode. Event manager: - rename cpu_number1 to dummy_cpu_number Power: - Add cb event for subsystem restart - check return status of get_api_version() Firmware: - Move FIRMWARE_VERSION_MASK to xlnx-zynqmp.h * tag 'zynqmp-soc2-for-6.11' of https://github.com/Xilinx/linux-xlnx: drivers: soc: xilinx: check return status of get_api_version() firmware: xilinx: Move FIRMWARE_VERSION_MASK to xlnx-zynqmp.h soc: xilinx: Add cb event for subsystem restart soc: xilinx: rename cpu_number1 to dummy_cpu_number pwm: xilinx: Fix u32 overflow issue in 32-bit width PWM mode. Link: https://lore.kernel.org/r/CAHTX3dKMtqgNpkEvrw0p2w+SPN83Ai1_kzhefUGOO5rMkPaH_w@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ti: omap: MAINTAINERS: move Benoît Cousson to CREDITSKrzysztof Kozlowski
Last email from Benoît Cousson was in 2014 [1], so remove him from maintainers of the TI OMAP platform. Stale maintainer entries hide information whether subsystem needs help, has a bus-factor or is even orphaned. Benoît Cousson, thank you for TI OMAP contributions and maintenance. [1] https://lore.kernel.org/all/?q=f%3Abcousson%40baylibre.com Acked-by: Benoît Cousson <bcousson@baylibre.com> Cc: Benoît Cousson <bcousson@baylibre.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240612084038.18519-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09amazon: MAINTAINERS: change to odd fixes and Tsahee Zidenberg to CREDITSKrzysztof Kozlowski
Last email from Tsahee Zidenberg was in 2016 [1], so move Tsahee from Amazon platform maintainers to credits (thank you for your contributions and maintenance!). Stale maintainer entries hide information whether subsystem needs help, has a bus-factor or is even orphaned. The Amazon platform still has active maintainer - Antoine Tenart - however there was no maintenance activities coming from Antoine. All my patches from last 4 years related to Amazon remained unanswered - no acks, no picks - so document the actual not active status of the platform by changing it to Odd Fixes. [1] https://lore.kernel.org/all/?q=f%3Atsahee%40annapurnalabs.com Cc: Tsahee Zidenberg <tsahee@annapurnalabs.com> Cc: Antoine Tenart <atenart@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240612084038.18519-2-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09MAINTAINERS: thead: add git treeDrew Fustini
Add git tree for T-Head device tree files and, in the future, drivers for the T-Head TH1520 SoC. Signed-off-by: Drew Fustini <drew@pdp7.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240704180913.2516959-1-drew@pdp7.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09Merge tag 'imx-soc-6.11' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/arm i.MX SoC change for 6.11: - Remove redundant EDAC_SUPPORT selection from ARCH_LAYERSCAPE * tag 'imx-soc-6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: layerscape: remove redundant EDAC_SUPPORT selection Link: https://lore.kernel.org/r/20240702142153.413061-1-shawnguo2@yeah.net Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: Use software nodes for the ADS7846 touchscreenLinus Walleij
Convert the Spitz to use software nodes to describe GPIOs for the ADS7846 touchscreen. As part of the conversion switch from the custom wait_for_sync() callback to defining hsync GPIO that can be used by the ads7846 driver to detect hsync. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-11-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: Use software nodes to describe LED GPIOsDmitry Torokhov
Convert Spitz to use software nodes for specifying GPIOs for the LEDs. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-10-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: Use software nodes to describe MMC GPIOsDmitry Torokhov
Convert Spitz to use software nodes for specifying GPIOs for the MMC. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-9-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: Use software nodes to describe LCD GPIOsDmitry Torokhov
Convert Spitz to use software nodes for specifying GPIOs for the LCD. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-8-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: Use software nodes to describe audio GPIOsDmitry Torokhov
Convert Spitz to use software nodes for specifying GPIOs for the audio chip. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-7-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: Use software nodes to describe SPI CS linesLinus Walleij
Convert the Spitz to use software nodes for specifying SPI CS. Because the SPI core can figure out the number of chipselects from the number of GPIO handles specified in properties, setting "num-cs" property is no longer needed. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-6-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: Simplify instantiating SPI controllerDmitry Torokhov
platform_device_register_full() to instantiate SPI controller in one go instead of allocating it, creating a software node, and registering the platform device as separate steps. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-5-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: pxa/gumstix: convert vbus gpio to use software nodesDmitry Torokhov
Switch vbus gpios from using a custom GPIO lookup table to software properties using PROPERTY_ENTRY_GPIO() constructs which closely mimic device tree gpio properties. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-4-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: pxa: consolidate GPIO chip platform dataDmitry Torokhov
The platform data for the GPIO controllers for the boards using non-DT setup is the same between PXA25x (gumstix) and PXA27x (Spitz) devices. Move it into devices.c to consolidate code. It will help with conversion to software nodes/properties. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240628180852.1738922-3-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09ARM: spitz: fix GPIO assignment for backlightDmitry Torokhov
GPIOs controlling backlight on Spitz and Akita are coming from GPIO expanders, not the pxa27xx-gpio block, correct it. Additionally GPIO lookup tables operate with pin numbers rather than legacy GPIO numbers, fix that as well. Use raw numbers instead of legacy GPIO names to avoid confusion. Fixes: ee0c8e494cc3 ("backlight: corgi: Convert to use GPIO descriptors") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20240628180852.1738922-2-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09Merge tag 'tegra-for-6.11-arm-core' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/arm ARM: tegra: Core changes for v6.11-rc1 Uses software nodes to describe rfkill instead of using a GPIO lookup table. * tag 'tegra-for-6.11-arm-core' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: paz00: Use software nodes to describe GPIOs for WiFi rfkill Link: https://lore.kernel.org/r/20240628210818.3627404-2-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09platform: cznic: turris-omnia-mcu: Depend on WATCHDOGMarek Behún
Add depend on WATCHDOG, otherwise modpost fails with ERROR: modpost: "watchdog_init_timeout" [drivers/platform/cznic/turris-omnia-mcu.ko] undefined! ERROR: modpost: "devm_watchdog_register_device" [drivers/platform/cznic/turris-omnia-mcu.ko] undefined! Fixes: ab89fb5fb92c ("platform: cznic: turris-omnia-mcu: Add support for MCU watchdog") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407040711.g19y3cWq-lkp@intel.com/ Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20240708114002.4285-3-kabel@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09platform: cznic: turris-omnia-mcu: Depend on OFMarek Behún
Add depend on OF, otherwise the compilation fails with error: no member named 'of_gpio_n_cells' in 'struct gpio_chip' error: no member named 'of_xlate' in 'struct gpio_chip' Fixes: dfa556e45ae9 ("platform: cznic: turris-omnia-mcu: Add support for MCU connected GPIOs") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407031646.trNSwajF-lkp@intel.com/ Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20240708114002.4285-2-kabel@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-09net: phy: microchip: lan937x: add support for 100BaseTX PHYOleksij Rempel
Add support of 100BaseTX PHY build in to LAN9371 and LAN9372 switches. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://patch.msgid.link/20240706154201.1456098-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-07-09vdpa/mlx5: Don't enable non-active VQs in .set_vq_ready()Dragos Tatulea
VQ indices in the range [cur_num_qps, max_vqs) represent queues that have not yet been activated. .set_vq_ready should not activate these VQs. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-24-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Don't reset VQs more than necessaryDragos Tatulea
The vdpa device can be reset many times in sequence without any significant state changes in between. Previously this was not a problem: VQs were torn down only on first reset. But after VQ pre-creation was introduced, each reset will delete and re-create the hardware VQs and their associated resources. To solve this problem, avoid resetting hardware VQs if the VQs are still in a blank state. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-23-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Re-create HW VQs under certain conditionsDragos Tatulea
There are a few conditions under which the hardware VQs need a full teardown and setup: - VQ size changed to something else than default value. Hardware VQ size modification is not supported. - User turns off certain device features: mergeable buffers, checksum virtio 1.0 compliance. In these cases, the TIR and RQT need to be re-created. Add a needs_teardown configuration variable and set it when detecting the above scenarios. On next DRIVER_OK, the resources will be torn down first. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-22-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Pre-create hardware VQs at vdpa .dev_add timeDragos Tatulea
Currently, hardware VQs are created right when the vdpa device gets into DRIVER_OK state. That is easier because most of the VQ state is known by then. This patch switches to creating all VQs and their associated resources at device creation time. The motivation is to reduce the vdpa device live migration downtime by moving the expensive operation of creating all the hardware VQs and their associated resources out of downtime on the destination VM. The VQs are now created in a blank state. The VQ configuration will happen later, on DRIVER_OK. Then the configuration will be applied when the VQs are moved to the Ready state. When .set_vq_ready() is called on a VQ before DRIVER_OK, special care is needed: now that the VQ is already created a resume_vq() will be triggered too early when no mr has been configured yet. Skip calling resume_vq() in this case, let it be handled during DRIVER_OK. For virtio-vdpa, the device configuration is done earlier during .vdpa_dev_add() by vdpa_register_device(). Avoid calling setup_vq_resources() a second time in that case. On a 64 CPU, 256 GB VM with 1 vDPA device of 16 VQps, the full VQ resource creation + resume time was ~370ms. Now it's down to 60 ms (only VQ config and resume). The measurements were done on a ConnectX6DX based vDPA device. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-21-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Use suspend/resume during VQP changeDragos Tatulea
Resume a VQ if it is already created when the number of VQ pairs increases. This is done in preparation for VQ pre-creation which is coming in a later patch. It is necessary because calling setup_vq() on an already created VQ will return early and will not enable the queue. For symmetry, suspend a VQ instead of tearing it down when the number of VQ pairs decreases. But only if the resume operation is supported. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-20-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Forward error in suspend/resume deviceDragos Tatulea
Start using the suspend/resume_vq() error return codes previously added. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-19-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com>
2024-07-09vdpa/mlx5: Consolidate all VQ modify to Ready to use resume_vq()Dragos Tatulea
There are a few more places modifying the VQ to Ready directly. Let's consolidate them into resume_vq(). The redundant warnings for resume_vq() errors can also be dropped. There is one special case that needs to be handled for virtio-vdpa: the initialized flag must be set to true earlier in setup_vq() so that resume_vq() doesn't return early. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-18-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Add error code for suspend/resume VQDragos Tatulea
Instead of blindly calling suspend/resume_vqs(), make then return error codes. To keep compatibility, keep suspending or resuming VQs on error and return the last error code. The assumption here is that the error code would be the same. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-17-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Accept Init -> Ready VQ transition in resume_vq()Dragos Tatulea
Until now resume_vq() was used only for the suspend/resume scenario. This change also allows calling resume_vq() to bring it from Init to Ready state (VQ initialization). Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-16-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com>
2024-07-09vdpa/mlx5: Allow creation of blank VQsDragos Tatulea
Based on the filled flag, create VQs that are filled or blank. Blank VQs will be filled in later through VQ modify. Downstream patches will make use of this to pre-create blank VQs at vdpa device creation. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-15-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com>
2024-07-09vdpa/mlx5: Set mkey modified flags on all VQsDragos Tatulea
Otherwise, when virtqueues are moved from INIT to READY the latest mkey will not be set appropriately. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-14-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Start off rqt_size with max VQPsDragos Tatulea
Currently rqt_size is initialized during device flag configuration. That's because it is the earliest moment when device knows if MQ (multi queue) is on or off. Shift this configuration earlier to device creation time. This implies that non-MQ devices will have a larger RQT size. But the configuration will still be correct. This is done in preparation for the pre-creation of hardware virtqueues at device add time. When that change will be added, RQT will be created at device creation time so it needs to be initialized to its max size. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-13-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Set an initial size on the VQDragos Tatulea
The virtqueue size is a pre-requisite for setting up any virtqueue resources. For the upcoming optimization of creating virtqueues at device add, the virtqueue size has to be configured. The queue size check in setup_vq() will always be false. So remove it. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-12-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Add support for modifying the VQ features fieldDragos Tatulea
This is done in preparation for the pre-creation of hardware virtqueues at device add time. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-11-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Add support for modifying the virtio_version VQ fieldDragos Tatulea
This is done in preparation for the pre-creation of hardware virtqueues at device add time. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-10-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Rename init_mvqsDragos Tatulea
Function is used to set default values, so name it accordingly. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-9-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com>
2024-07-09vdpa/mlx5: Clear and reinitialize software VQ data on resetDragos Tatulea
The hardware VQ configuration is mirrored by data in struct mlx5_vdpa_virtqueue . Instead of clearing just a few fields at reset, fully clear the struct and initialize with the appropriate default values. As clear_vqs_ready() is used only during reset, get rid of it. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-8-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Initialize and reset device with one queue pairDragos Tatulea
The virtio spec says that a vdpa device should start off with one queue pair. The driver is already compliant. This patch moves the initialization to device add and reset times. This is done in preparation for the pre-creation of hardware virtqueues at device add time. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-7-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com>
2024-07-09vdpa/mlx5: Remove duplicate suspend codeDragos Tatulea
Use the dedicated suspend_vqs() function instead. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-6-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Iterate over active VQs during suspend/resumeDragos Tatulea
No need to iterate over max number of VQs. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-5-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Drop redundant check in teardown_virtqueues()Dragos Tatulea
The check is done inside teardown_vq(). Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-4-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Drop redundant codeDragos Tatulea
Originally, the second loop initialized the CVQ. But (acde3929492b ("vdpa/mlx5: Use consistent RQT size") initialized all the queues in the first loop, so the second iteration in init_mvqs() is never called because the first one will iterate up to max_vqs. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-3-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Make setup/teardown_vq_resources() symmetricalDragos Tatulea
... by changing the setup_vq_resources() parameter type. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-2-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09vdpa/mlx5: Clarify meaning thorough function renameDragos Tatulea
setup_driver()/teardown_driver() are a bit vague. These functions are used for virtqueue resources. Same for alloc_resources()/teardown_resources(): they represent fixed resources that are meant to exist during the device lifetime. Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-1-560c491078df@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09virtio-fs: improved request latencies when Virtio queue is fullPeter-Jan Gootzen
Currently, when the Virtio queue is full, a work item is scheduled to execute in 1ms that retries adding the request to the queue. This is a large amount of time on the scale on which a virtio-fs device can operate. When using a DPU this is around 30-40us baseline without going to a remote server (4k, QD=1). This patch changes the retrying behavior to immediately filling the Virtio queue up again when a completion has been received. This reduces the 99.9th percentile latencies in our tests by 60x and slightly increases the overall throughput, when using a workload IO depth 2x the size of the Virtio queue and a DPU-powered virtio-fs device (NVIDIA BlueField DPU). Signed-off-by: Peter-Jan Gootzen <pgootzen@nvidia.com> Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by: Yoray Zack <yorayz@nvidia.com> Message-Id: <20240517190435.152096-3-pgootzen@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-07-09virtio-fs: let -ENOMEM bubble up or burst gentlyPeter-Jan Gootzen
Currently, when the enqueueing of a request or forget operation fails with -ENOMEM, the enqueueing is retried after a timeout. This patch removes this behavior and treats -ENOMEM in these scenarios like any other error. By bubbling up the error to user space in the case of a request, and by dropping the operation in case of a forget. This behavior matches that of the FUSE layer above, and also simplifies the error handling. The latter will come in handy for upcoming patches that optimize the retrying of operations in case of -ENOSPC. Signed-off-by: Peter-Jan Gootzen <pgootzen@nvidia.com> Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by: Yoray Zack <yorayz@nvidia.com> Message-Id: <20240517190435.152096-2-pgootzen@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-07-09vDPA: add missing MODULE_DESCRIPTION() macrosJeff Johnson
With ARCH=x86, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/vdpa/vdpa.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/vdpa/ifcvf/ifcvf.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Message-Id: <20240611-md-drivers-vdpa-v1-1-efaf2de15152@quicinc.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09virtio: add missing MODULE_DESCRIPTION() macrosJeff Johnson
With ARCH=sh, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/virtio/virtio.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/virtio/virtio_ring.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Message-Id: <20240702-md-sh-drivers-virtio-v1-1-cf7325ab6ccc@quicinc.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-23 17:40:34 +0000