aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-16xhci: Fix incorrect tracking of free space on transfer ringsMathias Nyman1-1/+28
This incorrect tracking caused unnecessary ring expansion in some usecases which over days of use consume a lot of memory. xhci driver tries to keep track of free transfer blocks (TRBs) on the ring buffer, but failed to add back some cancelled transfers that were turned into no-op operations instead of just moving past them. This can happen if there are several queued pending transfers which then are cancelled in reverse order. Solve this by counting the numer of steps we move the dequeue pointer once we complete a transfer, and add it to the number of free trbs instead of just adding the trb number of the current transfer. This way we ensure we count the no-op trbs on the way as well. Fixes: 55f6153d8cc8 ("xhci: remove extra loop in interrupt context") Cc: [email protected] Reported-by: Miller Hunter <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217242 Tested-by: Miller Hunter <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-05-16xhci-pci: Only run d3cold avoidance quirk for s2idleMario Limonciello2-3/+11
Donghun reports that a notebook that has an AMD Ryzen 5700U but supports S3 has problems with USB after resuming from suspend. The issue was bisected down to commit d1658268e439 ("usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir"). As this issue only happens on S3, narrow the broken D3cold quirk to only run in s2idle. Fixes: d1658268e439 ("usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir") Reported-and-tested-by: Donghun Yoon <[email protected]> Cc: [email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-05-17powerpc/iommu: Incorrect DDW Table is referenced for SR-IOV deviceGaurav Batra2-5/+12
For an SR-IOV device, while enabling DDW, a new table is created and added at index 1 in the group. In the below 2 scenarios, the table is incorrectly referenced at index 0 (which is where the table is for default DMA window). 1. When adding DDW This issue is exposed with "slub_debug". Error thrown out from dma_iommu_dma_supported() Warning: IOMMU offset too big for device mask mask: 0xffffffff, table offset: 0x800000000000000 2. During Dynamic removal of the PCI device. Error is from iommu_tce_table_put() since a NULL table pointer is passed in. Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Cc: [email protected] # v5.15+ Signed-off-by: Gaurav Batra <[email protected]> Reviewed-by: Brian King <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2023-05-17powerpc/iommu: DMA address offset is incorrectly calculated with 2MB TCEsGaurav Batra1-4/+7
When DMA window is backed by 2MB TCEs, the DMA address for the mapped page should be the offset of the page relative to the 2MB TCE. The code was incorrectly setting the DMA address to the beginning of the TCE range. Mellanox driver is reporting timeout trying to ENABLE_HCA for an SR-IOV ethernet port, when DMA window is backed by 2MB TCEs. Fixes: 387273118714 ("powerps/pseries/dma: Add support for 2M IOMMU page size") Cc: [email protected] # v5.16+ Signed-off-by: Gaurav Batra <[email protected]> Reviewed-by: Greg Joyce <[email protected]> Reviewed-by: Brian King <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2023-05-17powerpc/iommu: Remove iommu_del_device()Jason Gunthorpe4-72/+0
Now that power calls iommu_device_register() and populates its groups using iommu_ops->device_group it should not be calling iommu_group_remove_device(). The core code owns the groups and all the other related iommu data, it will clean it up automatically. Remove the bus notifiers and explicit calls to iommu_group_remove_device(). Fixes: a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains") Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2023-05-16arm64: mte: Do not set PG_mte_tagged if tags were not initializedPeter Collingbourne1-5/+2
The mte_sync_page_tags() function sets PG_mte_tagged if it initializes page tags. Then we return to mte_sync_tags(), which sets PG_mte_tagged again. At best, this is redundant. However, it is possible for mte_sync_page_tags() to return without having initialized tags for the page, i.e. in the case where check_swap is true (non-compound page), is_swap_pte(old_pte) is false and pte_is_tagged is false. So at worst, we set PG_mte_tagged on a page with uninitialized tags. This can happen if, for example, page migration causes a PTE for an untagged page to be replaced. If the userspace program subsequently uses mprotect() to enable PROT_MTE for that page, the uninitialized tags will be exposed to userspace. Fix it by removing the redundant call to set_page_mte_tagged(). Fixes: e059853d14ca ("arm64: mte: Fix/clarify the PG_mte_tagged semantics") Signed-off-by: Peter Collingbourne <[email protected]> Cc: <[email protected]> # 6.1 Link: https://linux-review.googlesource.com/id/Ib02d004d435b2ed87603b858ef7480f7b1463052 Reviewed-by: Catalin Marinas <[email protected]> Reviewed-by: Alexandru Elisei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2023-05-16arm64: Also reset KASAN tag if page is not PG_mte_taggedPeter Collingbourne1-2/+3
Consider the following sequence of events: 1) A page in a PROT_READ|PROT_WRITE VMA is faulted. 2) Page migration allocates a page with the KASAN allocator, causing it to receive a non-match-all tag, and uses it to replace the page faulted in 1. 3) The program uses mprotect() to enable PROT_MTE on the page faulted in 1. As a result of step 3, we are left with a non-match-all tag for a page with tags accessible to userspace, which can lead to the same kind of tag check faults that commit e74a68468062 ("arm64: Reset KASAN tag in copy_highpage with HW tags only") intended to fix. The general invariant that we have for pages in a VMA with VM_MTE_ALLOWED is that they cannot have a non-match-all tag. As a result of step 2, the invariant is broken. This means that the fix in the referenced commit was incomplete and we also need to reset the tag for pages without PG_mte_tagged. Fixes: e5b8d9218951 ("arm64: mte: reset the page tag in page->flags") Cc: <[email protected]> # 5.15 Link: https://linux-review.googlesource.com/id/I7409cdd41acbcb215c2a7417c1e50d37b875beff Signed-off-by: Peter Collingbourne <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2023-05-16arm64: perf: Mark all accessor functions inlineGeert Uytterhoeven1-3/+3
When just including <asm/arm_pmuv3.h>: arch/arm64/include/asm/arm_pmuv3.h:31:13: error: ‘write_pmevtypern’ defined but not used [-Werror=unused-function] 31 | static void write_pmevtypern(int n, unsigned long val) | ^~~~~~~~~~~~~~~~ arch/arm64/include/asm/arm_pmuv3.h:24:13: error: ‘write_pmevcntrn’ defined but not used [-Werror=unused-function] 24 | static void write_pmevcntrn(int n, unsigned long val) | ^~~~~~~~~~~~~~~ arch/arm64/include/asm/arm_pmuv3.h:16:22: error: ‘read_pmevcntrn’ defined but not used [-Werror=unused-function] 16 | static unsigned long read_pmevcntrn(int n) | ^~~~~~~~~~~~~~ Fix this by adding the missing "inline" keywords to the three accessor functions that lack them. Fixes: df29ddf4f04b ("arm64: perf: Abstract system register accesses away") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Acked-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/d53a19043c0c3bd25f6c203e73a2fb08a9661824.1683561482.git.geert+renesas@glider.be Signed-off-by: Will Deacon <[email protected]>
2023-05-16ARM: perf: Mark all accessor functions inlineGeert Uytterhoeven1-3/+3
When just including <asm/arm_pmuv3.h>: arch/arm/include/asm/arm_pmuv3.h:110:13: error: ‘write_pmevtypern’ defined but not used [-Werror=unused-function] 110 | static void write_pmevtypern(int n, unsigned long val) | ^~~~~~~~~~~~~~~~ arch/arm/include/asm/arm_pmuv3.h:103:13: error: ‘write_pmevcntrn’ defined but not used [-Werror=unused-function] 103 | static void write_pmevcntrn(int n, unsigned long val) | ^~~~~~~~~~~~~~~ arch/arm/include/asm/arm_pmuv3.h:95:22: error: ‘read_pmevcntrn’ defined but not used [-Werror=unused-function] 95 | static unsigned long read_pmevcntrn(int n) | ^~~~~~~~~~~~~~ Fix this by adding the missing "inline" keywords to the three accessor functions that lack them. Fixes: 009d6dc87a56 ("ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Mark Rutland <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/3a7d9bc7470aa2d85696ee9765c74f8c03fb5454.1683561482.git.geert+renesas@glider.be Signed-off-by: Will Deacon <[email protected]>
2023-05-16arm64: vdso: Pass (void *) to virt_to_page()Linus Walleij1-1/+1
Like the other calls in this function virt_to_page() expects a pointer, not an integer. However since many architectures implement virt_to_pfn() as a macro, this function becomes polymorphic and accepts both a (unsigned long) and a (void *). Fix this up with an explicit cast. Signed-off-by: Linus Walleij <[email protected]> Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2023-May/832583.html Signed-off-by: Will Deacon <[email protected]>
2023-05-16arm64/mm: mark private VM_FAULT_X defines as vm_fault_tMin-Hua Chen1-2/+2
This patch fixes several sparse warnings for fault.c: arch/arm64/mm/fault.c:493:24: sparse: warning: incorrect type in return expression (different base types) arch/arm64/mm/fault.c:493:24: sparse: expected restricted vm_fault_t arch/arm64/mm/fault.c:493:24: sparse: got int arch/arm64/mm/fault.c:501:32: sparse: warning: incorrect type in return expression (different base types) arch/arm64/mm/fault.c:501:32: sparse: expected restricted vm_fault_t arch/arm64/mm/fault.c:501:32: sparse: got int arch/arm64/mm/fault.c:503:32: sparse: warning: incorrect type in return expression (different base types) arch/arm64/mm/fault.c:503:32: sparse: expected restricted vm_fault_t arch/arm64/mm/fault.c:503:32: sparse: got int arch/arm64/mm/fault.c:511:24: sparse: warning: incorrect type in return expression (different base types) arch/arm64/mm/fault.c:511:24: sparse: expected restricted vm_fault_t arch/arm64/mm/fault.c:511:24: sparse: got int arch/arm64/mm/fault.c:670:13: sparse: warning: restricted vm_fault_t degrades to integer arch/arm64/mm/fault.c:670:13: sparse: warning: restricted vm_fault_t degrades to integer arch/arm64/mm/fault.c:713:39: sparse: warning: restricted vm_fault_t degrades to integer Reported-by: kernel test robot <[email protected]> Signed-off-by: Min-Hua Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2023-05-16x86/show_trace_log_lvl: Ensure stack pointer is aligned, againVernon Lovejoy1-2/+5
The commit e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") tried to align the stack pointer in show_trace_log_lvl(), otherwise the "stack < stack_info.end" check can't guarantee that the last read does not go past the end of the stack. However, we have the same problem with the initial value of the stack pointer, it can also be unaligned. So without this patch this trivial kernel module #include <linux/module.h> static int init(void) { asm volatile("sub $0x4,%rsp"); dump_stack(); asm volatile("add $0x4,%rsp"); return -EAGAIN; } module_init(init); MODULE_LICENSE("GPL"); crashes the kernel. Fixes: e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") Signed-off-by: Vernon Lovejoy <[email protected]> Signed-off-by: Oleg Nesterov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Josh Poimboeuf <[email protected]>
2023-05-16vmlinux.lds.h: Discard .note.gnu.property sectionJosh Poimboeuf1-1/+8
When tooling reads ELF notes, it assumes each note entry is aligned to the value listed in the .note section header's sh_addralign field. The kernel-created ELF notes in the .note.Linux and .note.Xen sections are aligned to 4 bytes. This causes the toolchain to set those sections' sh_addralign values to 4. On the other hand, the GCC-created .note.gnu.property section has an sh_addralign value of 8 for some reason, despite being based on struct Elf32_Nhdr which only needs 4-byte alignment. When the mismatched input sections get linked together into the vmlinux .notes output section, the higher alignment "wins", resulting in an sh_addralign of 8, which confuses tooling. For example: $ readelf -n .tmp_vmlinux.btf ... readelf: .tmp_vmlinux.btf: Warning: note with invalid namesz and/or descsz found at offset 0x170 readelf: .tmp_vmlinux.btf: Warning: type: 0x4, namesize: 0x006e6558, descsize: 0x00008801, alignment: 8 In this case readelf thinks there's alignment padding where there is none, so it starts reading an ELF note in the middle. With newer toolchains (e.g., latest Fedora Rawhide), a similar mismatch triggers a build failure when combined with CONFIG_X86_KERNEL_IBT: btf_encoder__encode: btf__dedup failed! Failed to encode BTF libbpf: failed to find '.BTF' ELF section in vmlinux FAILED: load BTF from vmlinux: No data available make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255 This latter error was caused by pahole crashing when it encountered the corrupt .notes section. This crash has been fixed in dwarves version 1.25. As Tianyi Liu describes: "Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is enabled, pahole needs to call cus__merge_and_process_cu to merge compile units, at which point there should only be one unspecified type (used to represent some compilation information) in the global context. However, when the kernel is compiled without LTO, if pahole calls cus__merge_and_process_cu due to alignment issues with notes, multiple unspecified types may appear after merging the cus, and older versions of pahole only support up to one. This is why pahole 1.24 crashes, while newer versions support multiple. However, the latest version of pahole still does not solve the problem of incorrect LTO recognition, so compiling the kernel may be slower than normal." Even with the newer pahole, the note section misaligment issue still exists and pahole is misinterpreting the LTO note. Fix it by discarding the .note.gnu.property section. While GNU properties are important for user space (and VDSO), they don't seem to have any use for vmlinux. (In fact, they're already getting (inadvertently) stripped from vmlinux when CONFIG_DEBUG_INFO_BTF is enabled. The BTF data is extracted from vmlinux.o with "objcopy --only-section=.BTF" into .btf.vmlinux.bin.o. That file doesn't have .note.gnu.property, so when it gets modified and linked back into the main object, the linker automatically strips it (see "How GNU properties are merged" in the ld man page).) Reported-by: Daniel Xu <[email protected]> Link: https://lkml.kernel.org/bpf/[email protected] Debugged-by: Tianyi Liu <[email protected]> Suggested-by: Joan Bruguera Micó <[email protected]> Link: https://lore.kernel.org/r/20230418214925.ay3jpf2zhw75kgmd@treble Signed-off-by: Josh Poimboeuf <[email protected]>
2023-05-16arm64: dts: imx8: fix USB 3.0 Gadget Failure in QM & QXPB0 at super speedFrank Li1-0/+1
Resolve USB 3.0 gadget failure for QM and QXPB0 in super speed mode with single IN and OUT endpoints, like mass storage devices, due to incorrect ACTUAL_MEM_SIZE in ep_cap2 (32k instead of actual 18k). Implement dt property cdns,on-chip-buff-size to override ep_cap2 and set it to 18k for imx8QM and imx8QXP chips. No adverse effects for 8QXP C0. Cc: [email protected] Fixes: dce49449e04f ("usb: cdns3: allocate TX FIFO size according to composite EP number") Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2023-05-16dt-binding: cdns,usb3: Fix cdns,on-chip-buff-size typeFrank Li1-1/+1
In cdns3-gadget.c, 'cdns,on-chip-buff-size' was read using device_property_read_u16(). It resulted in 0 if a 32bit value was used in dts. This commit fixes the dt binding doc to declare it as u16. Cc: [email protected] Fixes: 68989fe1c39d ("dt-bindings: usb: Convert cdns-usb3.txt to YAML schema") Signed-off-by: Frank Li <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2023-05-16irqchip/mbigen: Unify the error handling in mbigen_of_create_domain()Kefeng Wang1-13/+18
Dan Carpenter reported that commit fea087fc291b "irqchip/mbigen: move to use bus_get_dev_root()" leads to the following Smatch static checker warning: drivers/irqchip/irq-mbigen.c:258 mbigen_of_create_domain() error: potentially dereferencing uninitialized 'child'. It should not cause a problem on real hardware, but better to fix the warning, let's move the bus_get_dev_root() out of the loop, and unify the error handling to silence it. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-16irqchip/meson-gpio: Mark OF related data as maybe unusedKrzysztof Kozlowski1-1/+1
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/irqchip/irq-meson-gpio.c:153:34: error: ‘meson_irq_gpio_matches’ defined but not used [-Werror=unused-const-variable=] Acked-by: Martin Blumenstingl <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-16irqchip/mips-gic: Use raw spinlock for gic_lockJiaxun Yang1-15/+15
Since we may hold gic_lock in hardirq context, use raw spinlock makes more sense given that it is for low-level interrupt handling routine and the critical section is small. Fixes BUG: [ 0.426106] ============================= [ 0.426257] [ BUG: Invalid wait context ] [ 0.426422] 6.3.0-rc7-next-20230421-dirty #54 Not tainted [ 0.426638] ----------------------------- [ 0.426766] swapper/0/1 is trying to lock: [ 0.426954] ffffffff8104e7b8 (gic_lock){....}-{3:3}, at: gic_set_type+0x30/08 Fixes: 95150ae8b330 ("irqchip: mips-gic: Implement irq_set_type callback") Cc: [email protected] Signed-off-by: Jiaxun Yang <[email protected]> Reviewed-by: Serge Semin <[email protected]> Tested-by: Serge Semin <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-16irqchip/mips-gic: Don't touch vl_map if a local interrupt is not routableJiaxun Yang1-0/+2
When a GIC local interrupt is not routable, it's vl_map will be used to control some internal states for core (providing IPTI, IPPCI, IPFDC input signal for core). Overriding it will interfere core's intetrupt controller. Do not touch vl_map if a local interrupt is not routable, we are not going to remap it. Before dd098a0e0319 (" irqchip/mips-gic: Get rid of the reliance on irq_cpu_online()"), if a local interrupt is not routable, then it won't be requested from GIC Local domain, and thus gic_all_vpes_irq_cpu_online won't be called for that particular interrupt. Fixes: dd098a0e0319 (" irqchip/mips-gic: Get rid of the reliance on irq_cpu_online()") Cc: [email protected] Signed-off-by: Jiaxun Yang <[email protected]> Reviewed-by: Serge Semin <[email protected]> Tested-by: Serge Semin <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-16irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issuesDouglas Anderson3-2/+27
Some Chromebooks with Mediatek SoCs have a problem where the firmware doesn't properly save/restore certain GICR registers. Newer Chromebooks should fix this issue and we may be able to do firmware updates for old Chromebooks. At the moment, the only known issue with these Chromebooks is that we can't enable "pseudo NMIs" since the priority register can be lost. Enabling "pseudo NMIs" on Chromebooks with the problematic firmware causes crashes and freezes. Let's detect devices with this problem and then disable "pseudo NMIs" on them. We'll detect the problem by looking for the presence of the "mediatek,broken-save-restore-fw" property in the GIC device tree node. Any devices with fixed firmware will not have this property. Our detection plan works because we never bake a Chromebook's device tree into firmware. Instead, device trees are always bundled with the kernel. We'll update the device trees of all affected Chromebooks and then we'll never enable "pseudo NMI" on a kernel that is bundled with old device trees. When a firmware update is shipped that fixes this issue it will know to patch the device tree to remove the property. In order to make this work, the quick detection mechanism of the GICv3 code is extended to be able to look for properties in addition to looking at "compatible". Reviewed-by: Julius Werner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/20230515131353.v2.2.I88dc0a0eb1d9d537de61604cd8994ecc55c0cac1@changeid
2023-05-16dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs ↵Douglas Anderson1-0/+6
w/ broken FW When trying to turn on the "pseudo NMI" kernel feature in Linux, it was discovered that all Mediatek-based Chromebooks that ever shipped (at least ones with GICv3) had a firmware bug where they wouldn't save certain GIC "GICR" registers properly. If a processor ever entered a suspend/idle mode where the GICR registers lost state then they'd be reset to their default state. As a result of the bug, if you try to enable "pseudo NMIs" on the affected devices then certain interrupts will unexpectedly get promoted to be "pseudo NMIs" and cause crashes / freezes / general mayhem. ChromeOS is looking to start turning on "pseudo NMIs" in production to make crash reports more actionable. To do so, we will release firmware updates for at least some of the affected Mediatek Chromebooks. However, even when we update the firmware of a Chromebook it's always possible that a user will end up booting with old firmware. We need to be able to detect when we're running with firmware that will crash and burn if pseudo NMIs are enabled. The current plan is: * Update the device trees of all affected Chromebooks to include the 'mediatek,broken-save-restore-fw' property. The kernel can use this to know not to enable certain features like "pseudo NMI". NOTE: device trees for Chromebooks are never baked into the firmware but are bundled with the kernel. A kernel will never be configured to use "pseudo NMIs" and be bundled with an old device tree. * When we get a fixed firmware for one of these Chromebooks, it will patch the device tree to remove this property. For some details, you can also see the public bug <https://issuetracker.google.com/281831288> Reviewed-by: Julius Werner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/20230515131353.v2.1.Iabe67a827e206496efec6beb5616d5a3b99c1e65@changeid
2023-05-16drm/pl111: Fix FB depth on IMPD-1 framebufferLinus Walleij4-12/+12
The last argument to the function drm_fbdev_dma_setup() was changed from desired BPP to desired depth. In our case the desired depth was 15 but BPP was 16, so we specified 16 as BPP and we relied on the FB emulation core to select a format with a suitable depth for the limited bandwidth and end up with e.g. XRGB1555 like in the past: [drm] Initialized pl111 1.0.0 20170317 for c1000000.display on minor 0 drm-clcd-pl111 c1000000.display: [drm] requested bpp 16, scaled depth down to 15 drm-clcd-pl111 c1000000.display: enable IM-PD1 CLCD connectors Console: switching to colour frame buffer device 80x30 drm-clcd-pl111 c1000000.display: [drm] fb0: pl111drmfb frame buffer device However the current code will fail at that: [drm] Initialized pl111 1.0.0 20170317 for c1000000.display on minor 0 drm-clcd-pl111 c1000000.display: [drm] bpp/depth value of 16/16 not supported drm-clcd-pl111 c1000000.display: [drm] No compatible format found drm-clcd-pl111 c1000000.display: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-12) Fix this by passing the desired depth of 15 for the IM/PD-1 display instead of 16 to drm_fbdev_dma_setup(). The desired depth is however in turn used for bandwidth limiting calculations and that was done with a simple / integer division, whereas we now have to modify that to use DIV_ROUND_UP() so that we get DIV_ROUND_UP(15, 2) = 2 not 15/2 = 1. After this the display works again on the Integrator/AP IM/PD-1. Cc: Emma Anholt <[email protected]> Cc: [email protected] Suggested-by: Thomas Zimmermann <[email protected]> Fixes: 37c90d589dc0 ("drm/fb-helper: Fix single-probe color-format selection") Link: https://lore.kernel.org/dri-devel/[email protected]/ Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-16net: bcmgenet: Restore phy_stop() depending upon suspend/closeFlorian Fainelli1-3/+5
Removing the phy_stop() from bcmgenet_netif_stop() ended up causing warnings from the PHY library that phy_start() is called from the RUNNING state since we are no longer stopping the PHY state machine during bcmgenet_suspend(). Restore the call to phy_stop() but make it conditional on being called from the close or suspend path. Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine") Fixes: 93e0401e0fc0 ("net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()") Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-05-16spi: dw: Replace spi->chip_select references with function callsAmit Kumar Mahapatra1-4/+4
New set/get APIs for accessing spi->chip_select were introduced by 'commit 9e264f3f85a5 ("spi: Replace all spi->chip_select and spi->cs_gpiod references with function call")', but the 'commit 2c8606040a80 ("spi: dw: Add support for AMD Pensando Elba SoC")' uses the old interface by directly accessing spi->chip_select. So, replace all spi->chip_select references in the driver with new get/set APIs. Signed-off-by: Amit Kumar Mahapatra <[email protected] Acked-by: Serge Semin <[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]
2023-05-16regulator: Fix error checking for debugfs_create_dirOsama Muhammad1-2/+2
This patch fixes the error checking in core.c in debugfs_create_dir. The correct way to check if an error occurred is 'IS_ERR' inline function. Signed-off-by: Osama Muhammad <[email protected] Suggested-by: Ivan Orlov <[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]
2023-05-16tpm/tpm_tis: Disable interrupts for more Lenovo devicesJerry Snitselaar1-0/+16
The P360 Tiny suffers from an irq storm issue like the T490s, so add an entry for it to tpm_tis_dmi_table, and force polling. There also previously was a report from the previous attempt to enable interrupts that involved a ThinkPad L490. So an entry is added for it as well. Cc: [email protected] Reported-by: Peter Zijlstra <[email protected]> # P360 Tiny Closes: https://lore.kernel.org/linux-integrity/[email protected]/ Signed-off-by: Jerry Snitselaar <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2023-05-16tpm: Prevent hwrng from activating during resumeJarkko Sakkinen3-0/+15
Set TPM_CHIP_FLAG_SUSPENDED in tpm_pm_suspend() and reset in tpm_pm_resume(). While the flag is set, tpm_hwrng() gives back zero bytes. This prevents hwrng from racing during resume. Cc: [email protected] Fixes: 6e592a065d51 ("tpm: Move Linux RNG connection to hwrng") Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2023-05-16tpm_tis: Use tpm_chip_{start,stop} decoration inside tpm_tis_resumeJarkko Sakkinen1-24/+19
Before sending a TPM command, CLKRUN protocol must be disabled. This is not done in the case of tpm1_do_selftest() call site inside tpm_tis_resume(). Address this by decorating the calls with tpm_chip_{start,stop}, which should be always used to arm and disarm the TPM chip for transmission. Finally, move the call to the main TPM driver callback as the last step because it should arm the chip by itself, if it needs that type of functionality. Cc: [email protected] Reported-by: Jason A. Donenfeld <[email protected]> Closes: https://lore.kernel.org/linux-integrity/CS68AWILHXS4.3M36M1EKZLUMS@suppilovahvero/ Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2023-05-16power: supply: mt6360: add a check of devm_work_autocancel in ↵Kang Chen1-1/+3
mt6360_charger_probe devm_work_autocancel may fail, add a check and return early. Fixes: 0402e8ebb8b86 ("power: supply: mt6360_charger: add MT6360 charger support") Signed-off-by: Kang Chen <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>
2023-05-16power: supply: sbs-charger: Fix INHIBITED bit for Status regDaisuke Nojiri1-1/+1
CHARGE_INHIBITED bit position of the ChargerStatus register is actually 0 not 1. This patch corrects it. Fixes: feb583e37f8a8 ("power: supply: add sbs-charger driver") Signed-off-by: Daisuke Nojiri <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>
2023-05-15Merge patch series "can: bxcan: add support for single peripheral configuration"Marc Kleine-Budde5-15/+168
Dario Binacchi <[email protected]> says: The series adds support for managing bxCAN controllers in single peripheral configuration. Unlike stm32f4 SOCs, where bxCAN controllers are only in dual peripheral configuration, stm32f7 SOCs contain three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. The driver has been tested on the stm32f769i-discovery board with a kernel version 5.19.0-rc2 in loopback + silent mode: | ip link set can[0-2] type can bitrate 125000 loopback on listen-only on | ip link set up can[0-2] | candump can[0-2] -L & | cansend can[0-2] 300#AC.AB.AD.AE.75.49.AD.D1 Changes in v2: - s/fiter/filter/ in the commit message - Replace struct bxcan_mb::primary with struct bxcan_mb::cfg. - Move after the patch "can: bxcan: add support for single peripheral configuration". - Add node gcan3. - Rename gcan as gcan1. - Add property "st,can-secondary" to can2 node. - Drop patch "dt-bindings: mfd: stm32f7: add binding definition for CAN3" because it has been accepted. - Add patch "ARM: dts: stm32f429: put can2 in secondary mode". - Add patch "dt-bindings: net: can: add "st,can-secondary" property". v1: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15ARM: dts: stm32: add CAN support on stm32f746Dario Binacchi1-0/+47
Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. ------------------------------------------------------------------------- | features | CAN1 | CAN2 | CAN 3 | ------------------------------------------------------------------------- | SRAM | 512-byte shared between CAN1 & CAN2 | 512-byte | ------------------------------------------------------------------------- | Filters | 26 filters shared between CAN1 & CAN2 | 14 filters | ------------------------------------------------------------------------- Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15can: bxcan: add support for single peripheral configurationDario Binacchi1-11/+23
Add support for bxCAN controller in single peripheral configuration: - primary bxCAN - dedicated Memory Access Controller unit - 512-byte SRAM memory - 14 filter banks Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15ARM: dts: stm32: add pin map for CAN controller on stm32f7Dario Binacchi1-0/+82
Add pin configurations for using CAN controller on stm32f7. Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15ARM: dts: stm32f429: put can2 in secondary modeDario Binacchi1-0/+1
This is a preparation patch for the upcoming support to manage CAN peripherals in single configuration. The addition ensures backwards compatibility. Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15dt-bindings: net: can: add "st,can-secondary" propertyDario Binacchi1-4/+15
On the stm32f7 Socs the can peripheral can be in single or dual configuration. In the dual configuration, in turn, it can be in primary or secondary mode. The addition of the 'st,can-secondary' property allows you to specify this mode in the dual configuration. CAN peripheral nodes in single configuration contain neither "st,can-primary" nor "st,can-secondary". Signed-off-by: Dario Binacchi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15can: CAN_BXCAN should depend on ARCH_STM32Geert Uytterhoeven1-1/+1
The STMicroelectronics STM32 basic extended CAN Controller (bxCAN) is only present on STM32 SoCs. Hence drop the "|| OF" part from its dependency rule, to prevent asking the user about this driver when configuring a kernel without STM32 SoC support. Fixes: f00647d8127be4d3 ("can: bxcan: add support for ST bxCAN controller") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/all/40095112efd1b2214e4223109fd9f0c6d0158a2d.1680609318.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15can: dev: fix missing CAN XL support in can_put_echo_skb()Oliver Hartkopp1-1/+2
can_put_echo_skb() checks for the enabled IFF_ECHO flag and the correct ETH_P type of the given skbuff. When implementing the CAN XL support the new check for ETH_P_CANXL has been forgotten. Fixes: fb08cba12b52 ("can: canxl: update CAN infrastructure for CAN XL frames") Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flagOliver Hartkopp1-1/+1
The control message provided by J1939 support MSG_CMSG_COMPAT but blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user space on 64 bit kernels. Link: https://github.com/hartkopp/can-isotp/issues/59 Cc: Oleksij Rempel <[email protected]> Suggested-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Tested-by: Oleksij Rempel <[email protected]> Acked-by: Oleksij Rempel <[email protected]> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15can: isotp: recvmsg(): allow MSG_CMSG_COMPAT flagOliver Hartkopp1-1/+1
The control message provided by isotp support MSG_CMSG_COMPAT but blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user space on 64 bit kernels. Link: https://github.com/hartkopp/can-isotp/issues/59 Cc: Oleksij Rempel <[email protected]> Suggested-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Fixes: 42bf50a1795a ("can: isotp: support MSG_TRUNC flag when reading from socket") Link: https://lore.kernel.org/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR valueYun Lu2-1/+4
When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a probability of failure, which shows "authentication with ... timed out". Through debugging, it was found that the RCR register has been inexplicably modified to an incorrect value, resulting in the nic not being able to receive authenticated frames. To fix this problem, add regrcr in rtl8xxxu_priv struct, and store the RCR value every time the register is written, and use it the next time the register need to be modified. Signed-off-by: Yun Lu <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-15wifi: brcmfmac: Check for probe() id argument being NULLHans de Goede3-0/+27
The probe() id argument may be NULL in 2 scenarios: 1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe the device. 2. If a user tries to manually bind the driver from sysfs then the sdio / pcie / usb probe() function gets called with NULL as id argument. 1. Is being hit by users causing the following oops on resume and causing wifi to stop working: BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020 Workgueue: events_unbound async_run_entry_fn RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac] <snip> Call Trace: <TASK> brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887] ? pci_pm_resume+0x5b/0xf0 ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x47/0x150 device_resume+0xa2/0x1f0 async_resume+0x1d/0x30 <snip> Fix this by checking for id being NULL. In the PCI and USB cases try a manual lookup of the id so that manually binding the driver through sysfs and more importantly brcmf_pcie_probe() on resume will work. For the SDIO case there is no helper to do a manual sdio_device_id lookup, so just directly error out on a NULL id there. Fixes: da6d9c8ecd00 ("wifi: brcmfmac: add firmware vendor info in driver info") Reported-by: Felix <[email protected]> Link: https://lore.kernel.org/regressions/[email protected]/ Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-15wifi: rtw88: correct qsel_to_ep[] type as intPing-Ke Shih1-1/+1
qsel_to_ep[] can be assigned negative value, so change type from 'u8' to 'int'. Otherwise, Smatch static checker warns: drivers/net/wireless/realtek/rtw88/usb.c:219 rtw_usb_parse() warn: assigning (-22) to unsigned variable 'rtwusb->qsel_to_ep[8]' Cc: [email protected] Fixes: a6f187f92bcc ("wifi: rtw88: usb: fix priority queue to endpoint mapping") Reported-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/linux-wireless/[email protected]/ Cc: Sascha Hauer <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Acked-by: Sascha Hauer <[email protected]> Tested-by: Larry Finger <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-15cpufreq: ACPI: Prevent a warning when another frequency driver is loadedPetr Pavlu2-2/+2
The recent change to use platform devices to load ACPI PPC and PCC drivers caused that a misleading warning is reported when a respective module cannot be loaded because another CPU frequency driver is already registered: kernel: acpi-cpufreq: probe of acpi-cpufreq failed with error -17 Address it by changing the return code in acpi-cpufreq and pcc-cpufreq for this case from -EEXIST to -ENODEV which silences the warning in call_driver_probe(). The change has also a benefit for users of init_module() as this return code is propagated out from the syscall. The previous -EEXIST code made the callers, such as kmod, wrongly believe that the module was already loaded instead of that it failed to load. Fixes: 691a63712347 ("ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers") Reported-by: Kevin Locke <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Petr Pavlu <[email protected]> Tested-by: Kevin Locke <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-05-16ASoC: SOF: Intel: hda-mlink: fixes and extensionsMark Brown2-9/+101
Merge series from Pierre-Louis Bossart <[email protected]>: With additional testing with multiple links and multiple DAI types, we found a couple of mistakes with refcounts, base address, missing initialization. A new helper was also added due to a change in the SoundWire programming sequences, with the host driver in charge of setting up the DMA channel mapping instead of the firmware.
2023-05-15bpf: netdev: init the offload table earlierJakub Kicinski1-1/+1
Some netdevices may get unregistered before late_initcall(), we have to move the hashtable init earlier. Fixes: f1fc43d03946 ("bpf: Move offload initialization into late_initcall") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217399 Signed-off-by: Jakub Kicinski <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2023-05-15platform/mellanox: mlxbf-pmc: fix sscanf() error checkingDan Carpenter1-3/+2
The sscanf() function never returns negatives. It returns the number of items successfully read. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-05-15platform/x86/amd/pmf: Fix CnQF and auto-mode after resumeMario Limonciello1-7/+25
After suspend/resume cycle there is an error message and auto-mode or CnQF stops working. [ 5741.447511] amd-pmf AMDI0100:00: SMU cmd failed. err: 0xff [ 5741.447523] amd-pmf AMDI0100:00: AMD_PMF_REGISTER_RESPONSE:ff [ 5741.447527] amd-pmf AMDI0100:00: AMD_PMF_REGISTER_ARGUMENT:7 [ 5741.447531] amd-pmf AMDI0100:00: AMD_PMF_REGISTER_MESSAGE:16 [ 5741.447540] amd-pmf AMDI0100:00: [AUTO_MODE] avg power: 0 mW mode: QUIET This is because the DRAM address used for accessing metrics table needs to be refreshed after a suspend resume cycle. Add a resume callback to reset this again. Fixes: 1a409b35c995 ("platform/x86/amd/pmf: Get performance metrics from PMFW") Signed-off-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-05-15platform/x86: asus-wmi: Ignore WMI events with codes 0x7B, 0xC0Alexandru Sorodoc1-0/+2
On ASUS GU604V the key 0x7B is issued when the charger is connected or disconnected, and key 0xC0 is issued when an external display is connected or disconnected. This commit maps them to KE_IGNORE to slience kernel messages about unknown keys, such as: kernel: asus_wmi: Unknown key code 0x7b Signed-off-by: Alexandru Sorodoc <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-05-15powerpc/crypto: Fix aes-gcm-p10 build when VSX=nMichael Ellerman1-1/+1
When VSX is disabled, eg. microwatt_defconfig, the build fails with: In function ‘enable_kernel_vsx’, inlined from ‘vsx_begin’ at arch/powerpc/crypto/aes-gcm-p10-glue.c:68:2, inlined from ‘p10_aes_gcm_crypt.constprop’ at arch/powerpc/crypto/aes-gcm-p10-glue.c:244:2: ... arch/powerpc/include/asm/switch_to.h:86:9: note: in expansion of macro ‘BUILD_BUG’ 86 | BUILD_BUG(); | ^~~~~~~~~ Fix it by making the p10-aes-gcm code depend on VSX. Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/20230515124731.122962-1-mpe%40ellerman.id.au
Powered by cgit, Gruvboxed by Blaster4385.