summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-02-09Revert "drm/amd/display: disable S/G display on DCN 2.1.0"Alex Deucher
This reverts commit 2404f9b0ea0153c3fddb0c4d7a43869dc8608f6f. Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). We have a parameter to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. Having this enabled seems like the lesser of to evils. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-09Revert "drm/amd/display: disable S/G display on DCN 3.1.2/3"Alex Deucher
This reverts commit f081cd4ca2658752a8c0e2353d50aec80d07c65f. Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). We have a parameter to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. Having this enabled seems like the lesser of to evils. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-09drm/amdgpu: add S/G display parameterAlex Deucher
Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). Add a option to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. v2: fix typo Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-09Merge tag 'nvme-6.2-2023-02-09' of git://git.infradead.org/nvme into block-6.2Jens Axboe
Pull NVMe fix from Christoph: "nvme fixes for Linux 6.2 - fix a static checker warning for a variable introduces in the last pull request (Tom Rix)" * tag 'nvme-6.2-2023-02-09' of git://git.infradead.org/nvme: nvme-auth: mark nvme_auth_wq static
2023-02-09block: Merge bio before checking ->cached_rqXiao Ni
It checks if plug->cached_rq is empty before merging bio. But the merge action doesn't have relationship with plug->cached_rq, it trys to merge bio with requests within plug->mq_list. Now it checks if ->cached_rq is empty before merging bio. If it's empty, it will miss the merge chances. So move the merge function before checking ->cached_rq. Signed-off-by: Xiao Ni <xni@redhat.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20230209031930.27354-1-xni@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-09Revert "blk-cgroup: simplify blkg freeing from initialization failure paths"Christoph Hellwig
It turns out this was too soon. blkg_conf_prep does to funky locking games with the queue lock for this to work properly. This reverts commit 27b642b07a4a5eb44dffa94a5171ce468bdc46f9. Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230209053523.437927-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-09blk-cgroup: delay calling blkcg_exit_disk until disk_releaseChristoph Hellwig
While del_gendisk ensures there is no outstanding I/O on the queue, it can't prevent block layer users from building new I/O. This leads to a NULL ->root_blkg reference in bio_associate_blkg when allocating a new bio on a shut down file system. Delay freeing the blk-cgroup subsystems from del_gendisk until disk_release to make sure the blkg and throttle information is still avaіlable for bio submitters, even if those bios will immediately fail. This now can cause a case where disk_release is called on a disk that hasn't been added. That's mostly harmless, except for a case in blk_throttl_exit that now needs to check for a NULL ->td pointer. Fixes: 178fa7d49815 ("blk-cgroup: delay blk-cgroup initialization until add_disk") Reported-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20230208063514.171485-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-09EDAC/amd64: Remove early_channel_count()Yazen Ghannam
The early_channel_count() function seems to have been useful in the past for knowing how many EDAC mci structures to populate. However, this is no longer needed as the maximum channel count for a system is used instead. Remove the early_channel_count() helper functions and related code. Use the size of the channel layer when iterating over channel structures. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-6-yazen.ghannam@amd.com
2023-02-09EDAC/amd64: Remove PCI Function 0Yazen Ghannam
PCI Function 0 is used on Family 17h and later only to read the "dhar" value. This value is printed and provided through a module-specific debug sysfs file. The value is not used for any Family 17h and later code, and it does not have any apparent debug value on these systems. Remove "dhar", Function 0 PCI IDs, and all related code. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-5-yazen.ghannam@amd.com
2023-02-09Merge tag 'at91-dt-6.3-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/dt AT91 device tree updates for 6.3 #2 It contains: - cleanups arround flexcom nodes on SAM9X60 SoC as follows: - preserve same ID for flexcoms and the embedded nodes (e.g. flx4 will embed uart4, spi4, i2c4 but not e.g. uart1, spi2, i2c3); - SoC specific bindings were moved from board specific file to SoC specific file - DMA bindings for all flexcom nodes were added - SoC file was filled with missing flexcom nodes - new SAM9X60 Curiosity board that contains 1 uSDcard interface, 1 SDcard interface, 1 USB device interface, 2 USB Type-A interfaces, 2 CAN interfaces, 1 10/100 Ethernet interface, 1 LCD RGB666 interface, 1 Gb DDR2, 4 Gb NAND Flash, 2Kb EEPROM, leds, button, power regulators, UART and JTAG connectors * tag 'at91-dt-6.3-2' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: dts: at91: sam9x60_curiosity: Add device tree for sam9x60 curiosity board dt-bindings: arm: at91: Add info on sam9x60 curiosity ARM: dts: at91: sam9x60: Add missing flexcom definitions ARM: dts: at91: sam9x60: Add DMA bindings for the flexcom nodes ARM: dts: at91: sam9x60: Specify the FIFO size for the Flexcom UART ARM: dts: at91: sam9x60: fix spi4 node ARM: dts: at91: sam9x60: move flexcom definitions ARM: dts: at91: sam9x60: Fix the label numbering for the flexcom functions Link: https://lore.kernel.org/r/20230209084930.289721-1-claudiu.beznea@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09arm64: dts: uniphier: Fix property name in PXs3 USB nodeKunihiko Hayashi
The property "snps,usb2_gadget_lpm_disable" is wrong. It should be fixed to "snps,usb2-gadget-lpm-disable". Cc: stable@vger.kernel.org Fixes: 19fee1a1096d ("arm64: dts: uniphier: Add USB-device support for PXs3 reference board") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207021429.28925-1-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09arm64: dts: uniphier: Add syscon-uhs-mode to SD nodeKunihiko Hayashi
Add sociopnext,syscon-uhs-mode prpperty to the SD node to refer the handle of the control logic node. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-9-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09arm64: dts: uniphier: Add syscon compatible string to soc-glue-debugKunihiko Hayashi
Add "syscon" compatible string to the nodes for soc-glue-debug according to the DT schema. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-8-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09arm64: dts: uniphier: Add missing reg properties for glue layer nodesKunihiko Hayashi
The nodes for some glue layers don't include necessary reg properties. Add the properties according to the DT schema. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-7-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09arm64: dts: uniphier: Align node names for SoC-dependent controller and PHYs ↵Kunihiko Hayashi
with bindings The node names for SoC-dependent controllers and PHYs should be generic ones according to the DT schemas. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-6-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09ARM: dts: uniphier: Add syscon-uhs-mode to SD nodeKunihiko Hayashi
Add sociopnext,syscon-uhs-mode prpperty to the SD node to refer the handle of the control logic node. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-5-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09ARM: dts: uniphier: Add syscon compatible string to soc-glue-debugKunihiko Hayashi
Add "syscon" compatible string to the nodes for soc-glue-debug according to the DT schema. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-4-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09ARM: dts: uniphier: Add missing reg properties for glue layerKunihiko Hayashi
The nodes for glue layers should include "reg" property. Add the property according to the DT schema. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-3-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09ARM: dts: uniphier: Align node names for SoC-dependent controller and PHYs ↵Kunihiko Hayashi
with bindings The node names for SoC-dependent controllers and PHYs should be generic ones according to the DT schemas. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20230207023514.29783-2-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09Merge tag 'aspeed-6.3-devicetree' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/dt ASPEED device tree updates for 6.3 - New machines * Ufispace NCPLite AST2600 BMC * Facebook Greatlakes AST2600 BMC - Updates for ethanolx, bletchley and tyan s8036 * tag 'aspeed-6.3-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc: ARM: dts: aspeed: p10bmc: Enable UART2 ARM: dts: aspeed: Add device tree for Ufispace NCPLite BMC dt-bindings: arm: aspeed: document Ufispace NCPLite BMC dt-bindings: vendor-prefixes: Add prefix for Ufi Space arm: dts: aspeed: tyan s8036: Enable kcs interrupts ARM: dts: aspeed: bletchley: Enable wdtrst1 ARM: dts: aspeed: bletchley: Rename flash1 label ARM: dts: aspeed: ethanolx: Add BIOS flash chip ARM: dts: aspeed: ethanolx: Enable CTS/RTS pins on UART1 ARM: dts: aspeed: ethanolx: Add label for the master partition ARM: dts: aspeed: ethanolx: Correct EEPROM device name ARM: dts: aspeed: ethanolx: Enable VUART ARM: dts: aspeed: greatlakes: Add Facebook greatlakes (AST2600) BMC dt-bindings: arm: aspeed: add Facebook Greatlakes board Link: https://lore.kernel.org/r/CACPK8XdbffU5yRSZF-zR2xv-+6aJK+hEXP8TOkW=SvS+nNTGxg@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-09usb: core: add quirk for Alcor Link AK9563 smartcard readerMark Pearson
The Alcor Link AK9563 smartcard reader used on some Lenovo platforms doesn't work. If LPM is enabled the reader will provide an invalid usb config descriptor. Added quirk to disable LPM. Verified fix on Lenovo P16 G1 and T14 G3 Tested-by: Miroslav Zatko <mzatko@mirexoft.com> Tested-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Cc: stable@vger.kernel.org Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230208181223.1092654-1-mpearson-lenovo@squebb.ca Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-09usb: typec: altmodes/displayport: Fix probe pin assign checkPrashant Malani
While checking Pin Assignments of the port and partner during probe, we don't take into account whether the peripheral is a plug or receptacle. This manifests itself in a mode entry failure on certain docks and dongles with captive cables. For instance, the Startech.com Type-C to DP dongle (Model #CDP2DP) advertises its DP VDO as 0x405. This would fail the Pin Assignment compatibility check, despite it supporting Pin Assignment C as a UFP. Update the check to use the correct DP Pin Assign macros that take the peripheral's receptacle bit into account. Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") Cc: stable@vger.kernel.org Reported-by: Diana Zigterman <dzigterman@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20230208205318.131385-1-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-09Revert "usb: gadget: u_ether: Do not make UDC parent of the net device"Paul Cercueil
This reverts commit 321b59870f850a10dbb211ecd2bd87b41497ea6f. This commit broke USB networking on Ingenic SoCs and maybe elsewhere. The actual reason is unknown; and while a proper fix would be better, we're sitting at -rc7 now, so a revert is justified - and we can work on re-introducing this change for 6.3. Fixes: 321b59870f85 ("usb: gadget: u_ether: Do not make UDC parent of the net device") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20230209105626.10597-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-09ARM: dts: exynos: correct max98090 DAI argument in SnowKrzysztof Kozlowski
The max98090 has only one DAI and does not take argument to DAI phandles: exynos5250-snow-rev5.dtb: audio-codec@10: #sound-dai-cells:0:0: 0 was expected Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20230208160424.371678-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09arm64: efi: Force the use of SetVirtualAddressMap() on eMAG and Altra Max ↵Darren Hart
machines Commit 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") identifies the Altra family via the family field in the type#1 SMBIOS record. eMAG and Altra Max machines are similarly affected but not detected with the strict strcmp test. The type1_family smbios string is not an entirely reliable means of identifying systems with this issue as OEMs can, and do, use their own strings for these fields. However, until we have a better solution, capture the bulk of these systems by adding strcmp matching for "eMAG" and "Altra Max". Fixes: 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") Cc: <stable@vger.kernel.org> # 6.1.x Cc: Alexandru Elisei <alexandru.elisei@gmail.com> Signed-off-by: Darren Hart <darren@os.amperecomputing.com> Tested-by: Justin He <justin.he@arm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-02-09ARM: dts: s5pv210: add "gpios" suffix to wlf,ldo1ena on AriesKrzysztof Kozlowski
The GPIOs properties should end with "gpios" suffix and Linux gpiolib already handles both names, so switch to preferred one. Link: https://lore.kernel.org/r/20230208172634.404452-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: add "gpios" suffix to wlf,ldo1ena on ArndaleKrzysztof Kozlowski
The GPIOs properties should end with "gpios" suffix and Linux gpiolib already handles both names, so switch to preferred one. Link: https://lore.kernel.org/r/20230208172634.404452-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: add "gpios" suffix to wlf,ldo1ena on MidasKrzysztof Kozlowski
The GPIOs properties should end with "gpios" suffix and Linux gpiolib already handles both names, so switch to preferred one. While touching the lines, replace open-coded GPIO_ACTIVE_HIGH flag. Tested-by: Henrik Grimler <henrik@grimler.se> Link: https://lore.kernel.org/r/20230208172634.404452-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: correct SPI nor compatible in SMDK5250Krzysztof Kozlowski
SPI NOR flash compatible should come with generic jedec,spi-nor fallback and proper vendor prefix: exynos5250-smdk5250.dtb: /soc/spi@12d30000/flash@0: failed to match any schema with compatible: ['w25x80'] Link: https://lore.kernel.org/r/20230208164942.387390-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: correct SPI nor compatible in SMDKv310Krzysztof Kozlowski
SPI NOR flash compatible should come with generic jedec,spi-nor fallback and proper vendor prefix: exynos4210-smdkv310.dtb: /soc/spi@13940000/flash@0: failed to match any schema with compatible: ['w25x80'] Link: https://lore.kernel.org/r/20230208164942.387390-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: move I2C10 out of soc node on ArndaleKrzysztof Kozlowski
I2C10 is represented as i2c-gpio device, thus it is not really a part of soc MMIO bus: exynos5250-arndale.dtb: soc: i2c-10: {'pinctrl-names': ['default'], ... } should not be valid under {'type': 'object'} Link: https://lore.kernel.org/r/20230207210020.677007-7-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: drop redundant address/size cells from I2C10 on ArndaleKrzysztof Kozlowski
I2C10 does not have any children because it is used in HDMI DDC, so drop redundant address/size-cells. Link: https://lore.kernel.org/r/20230207210020.677007-6-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: drop default status from I2C10 on ArndaleKrzysztof Kozlowski
status=okay is by default for new nodes. Link: https://lore.kernel.org/r/20230207210020.677007-5-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: align status led name with bindings on Origen4210Krzysztof Kozlowski
The "status" is a reserved keyword and LED nodes should have generic prefix: exynos4210-origen.dtb: leds: status: {'gpios': [[76, 3, 1]], 'function': ['heartbeat'], 'linux,default-trigger': ['heartbeat']} is not of type 'array' Link: https://lore.kernel.org/r/20230207210020.677007-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09EDAC/amd64: Remove PCI Function 6Yazen Ghannam
PCI Function 6 is used on Family 17h and later to access scrub registers. With scrub access removed, this function has no other use. Remove all Function 6 PCI IDs and related code. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-4-yazen.ghannam@amd.com
2023-02-09EDAC/amd64: Remove scrub rate control for Family 17h and laterYazen Ghannam
The scrub registers on AMD Family 17h and later may be inaccessible to the OS. Furthermore, hardware designers recommend that the scrubbing feature is managed by the firmware. Remove support for the sdram_scrub_rate interface for AMD Family 17h systems and later by not setting the scrub function pointers. The EDAC MC core will then not expose the scrub files in sysfs. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-3-yazen.ghannam@amd.com
2023-02-09EDAC/amd64: Don't set up EDAC PCI control on Family 17h+Yazen Ghannam
EDAC PCI control is used to detect/report legacy PCI errors like "Parity" and "SERROR". Modern AMD systems use PCIe Advanced Error Reporting (AER), and legacy PCI errors should not be reported. Remove EDAC PCI control setup on AMD Family 17h and later systems. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-2-yazen.ghannam@amd.com
2023-02-09selftests: forwarding: lib: quote the sysctl valuesHangbin Liu
When set/restore sysctl value, we should quote the value as some keys may have multi values, e.g. net.ipv4.ping_group_range Fixes: f5ae57784ba8 ("selftests: forwarding: lib: Add sysctl_set(), sysctl_restore()") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20230208032110.879205-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-09net: mscc: ocelot: fix all IPv6 getting trapped to CPU when PTP timestamping ↵Vladimir Oltean
is used While running this selftest which usually passes: ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [ OK ] TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] if I start PTP timestamping then run it again (debug prints added by me), the unknown IPv6 MC traffic is seen by the CPU port even when it should have been dropped: ~/selftests/drivers/net/dsa# ptp4l -i swp0 -2 -P -m ptp4l[225.410]: selected /dev/ptp1 as PTP clock [ 225.445746] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_add: port 0 adding L2 PTP trap [ 225.453815] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP event trap [ 225.462703] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP general trap [ 225.471768] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP event trap [ 225.480651] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP general trap ptp4l[225.488]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[225.488]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ^C ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [FAIL] reception succeeded, but should have failed TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] The PGID_MCIPV6 is configured correctly to not flood to the CPU, I checked that. Furthermore, when I disable back PTP RX timestamping (ptp4l doesn't do that when it exists), packets are RX filtered again as they should be: ~/selftests/drivers/net/dsa# hwstamp_ctl -i swp0 -r 0 [ 218.202854] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_del: port 0 removing L2 PTP trap [ 218.212656] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP event trap [ 218.222975] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP general trap [ 218.233133] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP event trap [ 218.242251] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP general trap current settings: tx_type 1 rx_filter 12 new settings: tx_type 1 rx_filter 0 ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [ OK ] TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] So it's clear that something in the PTP RX trapping logic went wrong. Looking a bit at the code, I can see that there are 4 typos, which populate "ipv4" VCAP IS2 key filter fields for IPv6 keys. VCAP IS2 keys of type OCELOT_VCAP_KEY_IPV4 and OCELOT_VCAP_KEY_IPV6 are handled by is2_entry_set(). OCELOT_VCAP_KEY_IPV4 looks at &filter->key.ipv4, and OCELOT_VCAP_KEY_IPV6 at &filter->key.ipv6. Simply put, when we populate the wrong key field, &filter->key.ipv6 fields "proto.mask" and "proto.value" remain all zeroes (or "don't care"). So is2_entry_set() will enter the "else" of this "if" condition: if (msk == 0xff && (val == IPPROTO_TCP || val == IPPROTO_UDP)) and proceed to ignore the "proto" field. The resulting rule will match on all IPv6 traffic, trapping it to the CPU. This is the reason why the local_termination.sh selftest sees it, because control traps are stronger than the PGID_MCIPV6 used for flooding (from the forwarding data path). But the problem is in fact much deeper. We trap all IPv6 traffic to the CPU, but if we're bridged, we set skb->offload_fwd_mark = 1, so software forwarding will not take place and IPv6 traffic will never reach its destination. The fix is simple - correct the typos. I was intentionally inaccurate in the commit message about the breakage occurring when any PTP timestamping is enabled. In fact it only happens when L4 timestamping is requested (HWTSTAMP_FILTER_PTP_V2_EVENT or HWTSTAMP_FILTER_PTP_V2_L4_EVENT). But ptp4l requests a larger RX timestamping filter than it needs for "-2": HWTSTAMP_FILTER_PTP_V2_EVENT. I wanted people skimming through git logs to not think that the bug doesn't affect them because they only use ptp4l in L2 mode. Fixes: 96ca08c05838 ("net: mscc: ocelot: set up traps for PTP packets") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230207183117.1745754-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-09rds: rds_rm_zerocopy_callback() use list_first_entry()Pietro Borrello
rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Use list_first_entry() to actually access the first element of the rs_zcookie_queue list. Fixes: 9426bbc6de99 ("rds: use list structure to track information for zerocopy completion notification") Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it> Link: https://lore.kernel.org/r/20230202-rds-zerocopy-v3-1-83b0df974f9a@diag.uniroma1.it Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-09udf: Avoid directory type conversion failure due to ENOMEMJan Kara
When converting directory from in-ICB to normal format, the last iteration through the directory fixing up directory enteries can fail due to ENOMEM. We do not expect this iteration to fail since the directory is already verified to be correct and it is difficult to undo the conversion at this point. So just use GFP_NOFAIL to make sure the small allocation cannot fail. Reported-by: syzbot+111eaa994ff74f8d440f@syzkaller.appspotmail.com Fixes: 0aba4860b0d0 ("udf: Allocate name buffer in directory iterator on heap") Signed-off-by: Jan Kara <jack@suse.cz>
2023-02-09drm/vc4: crtc: Increase setup cost in core clock calculation to handle ↵Dom Cobley
extreme reduced blanking The formula that determines the core clock requirement based on pixel clock and blanking has been determined experimentally to minimise the clock while supporting all modes we've seen. A new reduced blanking mode (4kp60 at 533MHz rather than the standard 594MHz) has been seen that doesn't produce a high enough clock and results in "flip_done timed out" error. Increase the setup cost in the formula to make this work. The result is a reduced blanking mode increases by up to 7MHz while leaving the standard timing mode untouched Link: https://github.com/raspberrypi/linux/issues/4446 Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127145558.446123-1-maxime@cerno.tech
2023-02-09drm/vc4: hdmi: Always enable GCP with AVMUTE clearedDom Cobley
Issue is some displays go blank at the point of firmware to kms handover. Plugging/unplugging hdmi cable, power cycling display, or switching standby off/on typically resolve this case. Finally managed to find a display that suffers from this, and track down the issue. The firmware uses AVMUTE in normal operation. It will set AVMUTE before disabling hdmi clocks and phy. It will clear AVMUTE after clocks and phy are set up for a new hdmi mode. But with the hdmi handover from firmware to kms, AVMUTE will be set by firmware. kms driver typically has no GCP packet (except for deep colour modes). The spec isn't clear on whether to consider the AVMUTE as continuing indefinitely in the absence of a GCP packet, or to consider that state to have ended. Most displays behave as we want, but there are a number (from multiple manufacturers) which need to see AVMUTE cleared before displaying a picture. Lets just always enable GCP packet with AVMUTE cleared. That resolves the issue on problematic displays. From HDMI 1.4 spec: A CD field of zero (Color Depth not indicated) shall be used whenever the Sink does not indicate support for Deep Color. This value may also be used in Deep Color mode to transmit a GCP indicating only non-Deep Color information (e.g. AVMUTE). So use CD=0 where we were previously not enabling a GCP. Link: https://forum.libreelec.tv/thread/24780-le-10-0-1-rpi4-no-picture-after-update-from-le-10-0-0 Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127161219.457058-1-maxime@cerno.tech
2023-02-09drm/vc4: Fix YUV plane handling when planes are in different buffersDave Stevenson
YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxime@cerno.tech
2023-02-09Merge tag 'amd-drm-fixes-6.2-2023-02-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.2-2023-02-08: amdgpu: - Flickering fixes for DCN 2.1, 3.1.2/3 - Re-enable S/G display on DCN 3.1.4 - Properly fix S/G display with AGP aperture enabled - Fix cursor offset with 180 rotation - SMU13 fixes - Use TGID for GPUVM traces - Fix oops on in fence error path - Don't run IB tests on hw rings when sw rings are in use Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209045321.565132-1-alexander.deucher@amd.com
2023-02-08Merge tag 'ipsec-2023-02-08' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== ipsec 2023-02-08 1) Fix policy checks for nested IPsec tunnels when using xfrm interfaces. From Benedict Wong. 2) Fix netlink message expression on 32=>64-bit messages translators. From Anastasia Belova. 3) Prevent potential spectre v1 gadget in xfrm_xlate32_attr. From Eric Dumazet. 4) Always consistently use time64_t in xfrm_timer_handler. From Eric Dumazet. 5) Fix KCSAN reported bug: Multiple cpus can update use_time at the same time. From Eric Dumazet. 6) Fix SCP copy from IPv4 to IPv6 on interfamily tunnel. From Christian Hopps. * tag 'ipsec-2023-02-08' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: fix bug with DSCP copy to v6 from v4 tunnel xfrm: annotate data-race around use_time xfrm: consistently use time64_t in xfrm_timer_handler() xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() xfrm: compat: change expression for switch in xfrm_xlate64 Fix XFRM-I support for nested ESP tunnels ==================== Link: https://lore.kernel.org/r/20230208114322.266510-1-steffen.klassert@secunet.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-08net: txgbe: Update support email addressJiawen Wu
Update new email address for Wangxun 10Gb NIC support team. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://lore.kernel.org/r/20230208023035.3371250-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-08arm64: dts: qcom: sc7280: Power herobrine's 3.3 eDP/TS rail more properlyDouglas Anderson
This is the equivalent of commit f5b4811e8758 ("arm64: dts: qcom: sc7180: Add trogdor eDP/touchscreen regulator off-on-time") and commit 23ff866987de ("arm64: dts: qcom: sc7180: Start the trogdor eDP/touchscreen regulator on"), but for herobrine instead of trogdor. The motivations for herobrine are the same as for trogdor. NOTES: * Currently for herobrine all boards are eDP, not MIPI. If/when we have herobrine derivatives that are MIPI they we can evaluate whether the same off-on-delay makes sense for them. For trogdor we didn't add the delay to MIPI panels because the problem was found late and nobody had complained about it. For herobrine defaulting to assuming the same 500ms makes sense and if we find we need to optimize later we can. * Currently there are no oddball herobrine boards like homestar where the panel really likes to be power cycled. If we have an oddball board it will need to split the eDP and touchscreen rail anyway (like homestar did) and we'll have to delete the "regulator-boot-on" from that board. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230207163550.1.I5ff72b7746d5fca8f10ea61351bde4150ed1a7f8@changeid
2023-02-08arm64: dts: qcom: pmk8550: fix PON compatibleNeil Armstrong
The right compatible is qcom,pmk8350-pon, it matches the reg resources associated to the node and the subnodes compatible properties. Fixes: e9c0a4e48489 ("arm64: dts: qcom: Add PMK8550 pmic dtsi") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230207-topic-sm8550-upstream-sm8550-dt-fix-v1-2-698d132ab285@linaro.org
2023-02-08arm64: dts: qcom: sm8550: fix DSI controller compatibleNeil Armstrong
Add missing sm8550 soc specific compatible before fallback to match the updated bindings. Fixes: d7da51db5b81 ("arm64: dts: qcom: sm8550: add display hardware devices") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230207-topic-sm8550-upstream-sm8550-dt-fix-v1-1-698d132ab285@linaro.org
generated by cgit (git 2.34.1) at 2025-09-12 16:30:20 +0000