build(deps): bump urllib3 from 2.0.7 to 2.2.2 in /drivers/gpu/drm/ci/xfails #60
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
BugLink: https://bugs.launchpad.net/bugs/2015867 Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2016251 Properties: no-test-build Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2018303 Signed-off-by: Tim Gardner <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Cengiz Can <[email protected]> Signed-off-by: Tim Gardner <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
Add zstd to the build dependencies to support compressed zstd modules. BugLink: https://bugs.launchpad.net/bugs/2028568 Signed-off-by: Andrea Righi <[email protected]>
perf now requires libstdc++-dev to build. Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2029220 Properties: no-test-build Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
python3-dev is now required by the regular kernel build process, add it to build-depends. Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2029364 Properties: no-test-build Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2033021 Properties: no-test-build Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2034043 Properties: no-test-build Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Andrea Righi <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2034547 Properties: no-test-build Signed-off-by: Andrea Righi <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
Ignore: yes Signed-off-by: Paolo Pisati <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2035596 Properties: no-test-build Signed-off-by: Paolo Pisati <[email protected]>
…CMDQV BugLink: https://bugs.launchpad.net/bugs/2101185 NVIDIA's Tegra241 Soc has a CMDQ-Virtualization (CMDQV) hardware, extending the standard ARM SMMU v3 IP to support multiple VCMDQs with virtualization capabilities. In terms of command queue, they are very like a standard SMMU CMDQ (or ECMDQs), but only support CS_NONE in the CS field of CMD_SYNC. Add a new tegra241-cmdqv driver, and insert its structure pointer into the existing arm_smmu_device, and then add related function calls in the SMMUv3 driver to interact with the CMDQV driver. In the CMDQV driver, add a minimal part for the in-kernel support: reserve VINTF0 for in-kernel use, and assign some of the VCMDQs to the VINTF0, and select one VCMDQ based on the current CPU ID to execute supported commands. This multi-queue design for in-kernel use gives some limited improvements: up to 20% reduction of invalidation time was measured by a multi-threaded DMA unmap benchmark, compared to a single queue. The other part of the CMDQV driver will be user-space support that gives a hypervisor running on the host OS to talk to the driver for virtualization use cases, allowing VMs to use VCMDQs without trappings, i.e. no VM Exits. This is designed based on IOMMUFD, and its RFC series is also under review. It will provide a guest OS a bigger improvement: 70% to 90% reductions of TLB invalidation time were measured by DMA unmap tests running in a guest, compared to nested SMMU CMDQ (with trappings). As the initial version, the CMDQV driver only supports ACPI configurations. Signed-off-by: Nate Watterson <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Co-developed-by: Nicolin Chen <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/dce50490b2c10b7254fb36aa73ed7ffd812b283a.1724970714.git.nicolinc@nvidia.com Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 918eb5c856f6ce4cf93b4b38e4b5e156905c5943) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 The VCMDQ in the tegra241-cmdqv driver has a guest mode that supports only a few invalidation commands. A batch is initialized with a cmdq, so it has to confirm whether a new command is supported or not. Add a supports_cmd function pointer to the cmdq structure, where the vcmdq driver should hook a command scan function. Add an inline helper too so it can be used by both sides. If a new command is not supported, simply issue the existing batch and re- init it as a new batch. Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/aafb24b881504f18c5d0c7c15f2134e40ad2c486.1724970714.git.nicolinc@nvidia.com Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit f59e854907128ec3d4a82b7fc4efe9be8da2e78e) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 When VCMDQs are assigned to a VINTF owned by a guest (HYP_OWN bit unset), only TLB and ATC invalidation commands are supported by the VCMDQ HW. So, implement the new cmdq->supports_cmd op to scan the input cmd in order to make sure that it is supported by the selected queue. Note that the guest VM shouldn't have HYP_OWN bit being set regardless of guest kernel driver writing it or not, i.e. the hypervisor running in the host OS should wire this bit to zero when trapping a write access to this VINTF_CONFIG register from a guest kernel. Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/8160292337059b91271045800e5c62f7295e2c24.1724970714.git.nicolinc@nvidia.com Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit a9d40285bdefef700ebc7551ef79d2f3e4559e73) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
…r_header BugLink: https://bugs.launchpad.net/bugs/2101185 Kernel test robot reported a few trucation warnings at the snprintf: drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c: In function ‘tegra241_vintf_free_lvcmdq’: drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c:239:56: warning: ‘%u’ directive output may be truncated writing between 1 and 5 bytes into a region of size between 3 and 11 [-Wformat-truncation=] 239 | snprintf(header, hlen, "VINTF%u: VCMDQ%u/LVCMDQ%u: ", | ^~ drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c:239:32: note: directive argument in the range [0, 65535] 239 | snprintf(header, hlen, "VINTF%u: VCMDQ%u/LVCMDQ%u: ", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c:239:9: note: ‘snprintf’ output between 25 and 37 bytes into a destination of size 32 239 | snprintf(header, hlen, "VINTF%u: VCMDQ%u/LVCMDQ%u: ", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 240 | vcmdq->vintf->idx, vcmdq->idx, vcmdq->lidx); Fix by bumping up the size of the header to hold more characters. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit db184a1ced56dde6bbf8cc4d9b936c9f6a510e28) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 The ioremap() function doesn't return error pointers, it returns NULL on error so update the error handling. Also just return directly instead of calling iounmap() on the NULL pointer. Calling iounmap(NULL) doesn't cause a problem on ARM but on other architectures it can trigger a warning so it'a bad habbit. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 086a3c40ebd02a4ac38121cf909326407b2883bc) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 This is likely a typo. Drop it. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Signed-off-by: Nicolin Chen <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/13fd3accb5b7ed6ec11cc6b7435f79f84af9f45f.1725503154.git.nicolinc@nvidia.com Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 2408b81f817ba6c278c5453eb9b43a167f35d471) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
…herent BugLink: https://bugs.launchpad.net/bugs/2101185 It's observed that, when the first 4GB of system memory was reserved, all VCMDQ allocations failed (even with the smallest qsz in the last attempt): arm-smmu-v3: found companion CMDQV device: NVDA200C:00 arm-smmu-v3: option mask 0x10 arm-smmu-v3: failed to allocate queue (0x8000 bytes) for vcmdq0 acpi NVDA200C:00: tegra241_cmdqv: Falling back to standard SMMU CMDQ arm-smmu-v3: ias 48-bit, oas 48-bit (features 0x001e1fbf) arm-smmu-v3: allocated 524288 entries for cmdq arm-smmu-v3: allocated 524288 entries for evtq arm-smmu-v3: allocated 524288 entries for priq This is because the 4GB reserved memory shifted the entire DMA zone from a lower 32-bit range (on a system without the 4GB carveout) to higher range, while the dev->coherent_dma_mask was set to DMA_BIT_MASK(32) by default. The dma_set_mask_and_coherent() call is done in arm_smmu_device_hw_probe() of the SMMU driver. So any DMA allocation from tegra241_cmdqv_probe() must wait until the coherent_dma_mask is correctly set. Move the vintf/vcmdq structure initialization routine into a different op, "init_structures". Call it at the end of arm_smmu_init_structures(), where standard SMMU queues get allocated. Most of the impl_ops aren't ready until vintf/vcmdq structure are init-ed. So replace the full impl_ops with an init_ops in __tegra241_cmdqv_probe(). And switch to tegra241_cmdqv_impl_ops later in arm_smmu_init_structures(). Note that tegra241_cmdqv_impl_ops does not link to the new init_structures op after this switch, since there is no point in having it once it's done. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Reported-by: Matt Ochs <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/530993c3aafa1b0fc3d879b8119e13c629d12e2b.1725503154.git.nicolinc@nvidia.com Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 483e0bd8883a40fd3dd3193997a4014337698d72) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 Fix a sparse warning. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Nicolin Chen <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 89edbe88db2857880b08ce363a2695eec657f51b) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 When configuring a kernel with PAGE_SIZE=4KB, depending on its setting of CONFIG_CMA_ALIGNMENT, VCMDQ_LOG2SIZE_MAX=19 could fail the alignment test and trigger a WARN_ON: WARNING: at drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3646 Call trace: arm_smmu_init_one_queue+0x15c/0x210 tegra241_cmdqv_init_structures+0x114/0x338 arm_smmu_device_probe+0xb48/0x1d90 Fix it by capping max_n_shift to CMDQ_MAX_SZ_SHIFT as SMMUv3 CMDQ does. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit a3799717b881aa0f4e722afb70e7b8ba84ae4f36) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 During boot some of the calls to tegra241_cmdqv_get_cmdq() will happen in preemptible context. As this function calls smp_processor_id(), if CONFIG_DEBUG_PREEMPT is enabled, these calls will trigger a series of "BUG: using smp_processor_id() in preemptible" backtraces. As tegra241_cmdqv_get_cmdq() only calls smp_processor_id() to use the CPU number as a factor to balance out traffic on cmdq usage, it is safe to use raw_smp_processor_id() here. Cc: <[email protected]> Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Signed-off-by: Luis Claudio R. Goncalves <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Tested-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 1f806218164d1bb93f3db21eaf61254b08acdf03) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2101185 The hardware limitation "max=19" actually comes from SMMU Command Queue. So, it'd be more natural for tegra241-cmdqv driver to read it out rather than hardcoding it itself. This is not an issue yet for a kernel on a baremetal system, but a guest kernel setting the queue base/size in form of IPA/gPA might result in a noncontiguous queue in the physical address space, if underlying physical pages backing up the guest RAM aren't contiguous entirely: e.g. 2MB-page backed guest RAM cannot guarantee a contiguous queue if it is 8MB (capped to VCMDQ_LOG2SIZE_MAX=19). This might lead to command errors when HW does linear-read from a noncontiguous queue memory. Adding this extra IDR1.CMDQS cap (in the guest kernel) allows VMM to set SMMU's IDR1.CMDQS=17 for the case mentioned above, so a guest-level queue will be capped to maximum 2MB, ensuring a contiguous queue memory. Fixes: a3799717b881 ("iommu/tegra241-cmdqv: Fix alignment failure at max_n_shift") Reported-by: Ian Kalinowski <[email protected]> Cc: [email protected] Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit e94dc6ddda8dd3770879a132d577accd2cce25f9) Signed-off-by: Magali Lemes <[email protected]> Acked-by: Philip Cox <[email protected]> Acked-by: Massimiliano Pellizzer <[email protected]> Signed-off-by: Magali Lemes <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
…-generic" to "linux-modules-*-generic" BugLink: https://bugs.launchpad.net/bugs/2098554 Linux supports the virtual watchdog timer through the "wdat_wdt" module. In Ubuntu 24.04 LTS on amd64, this module is in the "linux-modules-extra-*-generic" series of packages. These are depended on by the "linux-image-generic" package, but not by the "linux-image-virtual" package. The latter is what is included in Ubuntu Official Cloud Images. Installing "linux-image-virtual" on amd64 should get the "wdat_wdt" module because it's necessary to fully support a common hypervisor. And to be consistent, we should do the same for other architectures too. Signed-off-by: Mehmet Basaran<[email protected]> Acked-by: Stefan Bader <[email protected]> Acked-by: Agathe Porte <[email protected]> Signed-off-by: Stefan Bader <[email protected]> (copied from master) Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2102494 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2107043 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
This is a placeholder commit to separate the Ubuntu kernel source and our patches. Used by kernel_merge_with_upstream() in the linux-pkg repo.
…operly started (#14)
Bumps [urllib3](https://github.com/urllib3/urllib3) from 2.0.7 to 2.2.2. - [Release notes](https://github.com/urllib3/urllib3/releases) - [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst) - [Commits](urllib3/urllib3@2.0.7...2.2.2) --- updated-dependencies: - dependency-name: urllib3 dependency-version: 2.2.2 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
delphix-devops-bot
force-pushed
the
develop
branch
from
8da87df to
084078f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps urllib3 from 2.0.7 to 2.2.2.
Release notes
Sourced from urllib3's releases.
... (truncated)
Changelog
Sourced from urllib3's changelog.
Commits
27e2a5cRelease 2.2.2 (#3406)accff72Merge pull request from GHSA-34jh-p97f-mpxf34be4a5Pin CFFI to a new release candidate instead of a Git commit (#3398)da41058Bump browser-actions/setup-chrome from 1.6.0 to 1.7.1 (#3399)b07a669Bump github/codeql-action from 2.13.4 to 3.25.6 (#3396)b8589ecMeasure coverage with v4 of artifact actions (#3394)f3bdc55Allow triggering CI manually (#3391)5239265Fix HTTP version in debug log (#3316)b34619fBump actions/checkout to 4.1.4 (#3387)9961d14Bump browser-actions/setup-chrome from 1.5.0 to 1.6.0 (#3386)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.