aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-19arm64: mm: Permit PTE SW bits to change in live mappingsRyan Roberts2-1/+3
Previously pgattr_change_is_safe() was overly-strict and complained (e.g. "[ 116.262743] __check_safe_pte_update: unsafe attribute change: 0x0560000043768fc3 -> 0x0160000043768fc3") if it saw any SW bits change in a live PTE. There is no such restriction on SW bits in the Arm ARM. Until now, no SW bits have been updated in live mappings via the set_ptes() route. PTE_DIRTY would be updated live, but this is handled by ptep_set_access_flags() which does not call pgattr_change_is_safe(). However, with the introduction of uffd-wp for arm64, there is core-mm code that does ptep_get(); pte_clear_uffd_wp(); set_ptes(); which triggers this false warning. Silence this warning by masking out the SW bits during checks. The bug isn't technically in the highlighted commit below, but that's where bisecting would likely lead as its what made the bug user-visible. Signed-off-by: Ryan Roberts <[email protected]> Fixes: 5b32510af77b ("arm64/mm: Add uffd write-protect support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-06-19spi: spi-cadence: Enable spi refclk in slave modeAmit Kumar Mahapatra1-7/+7
When spi-cadence is configured as a slave, it requires the SPI refclk to detect the synchronization start condition while communicating with the master. However, the spi-cadence driver never enables the SPI refclk in slave mode, causing the refclk to remain disabled if the "clk_ignore_unused" kernel parameter is not passed through bootargs. As a result, the slave cannot detect data sent by the master, leading to communication failure. Update driver to enable the SPI refclk in both master and slave configurations. Fixes: b1b90514eaa3 ("spi: spi-cadence: Add support for Slave mode") Signed-off-by: Amit Kumar Mahapatra <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-19ASoC: dt-bindings: ak4619: Add initial DT bindingKuninori Morimoto1-0/+62
Add Asahi Kasei ak4619 audio codec bindings. Signed-off-by: Kuninori Morimoto <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-19ASoC: Add ak4619 codec supportKhanh Le3-0/+919
Add support for the Asahi Kasei AK4619 audio codec. [Kuninori cleanuped and adjusted to upstream code] Signed-off-by: Khanh Le <[email protected]> Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-19selftests: openvswitch: Set value to nla flags.Adrian Moreno1-1/+1
Netlink flags, although they don't have payload at the netlink level, are represented as having "True" as value in pyroute2. Without it, trying to add a flow with a flag-type action (e.g: pop_vlan) fails with the following traceback: Traceback (most recent call last): File "[...]/ovs-dpctl.py", line 2498, in <module> sys.exit(main(sys.argv)) ^^^^^^^^^^^^^^ File "[...]/ovs-dpctl.py", line 2487, in main ovsflow.add_flow(rep["dpifindex"], flow) File "[...]/ovs-dpctl.py", line 2136, in add_flow reply = self.nlm_request( ^^^^^^^^^^^^^^^^^ File "[...]/pyroute2/netlink/nlsocket.py", line 822, in nlm_request return tuple(self._genlm_request(*argv, **kwarg)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "[...]/pyroute2/netlink/generic/__init__.py", line 126, in nlm_request return tuple(super().nlm_request(*argv, **kwarg)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "[...]/pyroute2/netlink/nlsocket.py", line 1124, in nlm_request self.put(msg, msg_type, msg_flags, msg_seq=msg_seq) File "[...]/pyroute2/netlink/nlsocket.py", line 389, in put self.sendto_gate(msg, addr) File "[...]/pyroute2/netlink/nlsocket.py", line 1056, in sendto_gate msg.encode() File "[...]/pyroute2/netlink/__init__.py", line 1245, in encode offset = self.encode_nlas(offset) ^^^^^^^^^^^^^^^^^^^^^^^^ File "[...]/pyroute2/netlink/__init__.py", line 1560, in encode_nlas nla_instance.setvalue(cell[1]) File "[...]/pyroute2/netlink/__init__.py", line 1265, in setvalue nlv.setvalue(nla_tuple[1]) ~~~~~~~~~^^^ IndexError: list index out of range Signed-off-by: Adrian Moreno <[email protected]> Acked-by: Aaron Conole <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: dsa: mt7530: add support for bridge port isolationMatthias Schiffer2-2/+17
Remove a pair of ports from the port matrix when both ports have the isolated flag set. Signed-off-by: Matthias Schiffer <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Arınç ÜNAL <[email protected]> Tested-by: Arınç ÜNAL <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: dsa: mt7530: factor out bridge join/leave logicMatthias Schiffer1-57/+48
As preparation for implementing bridge port isolation, move the logic to add and remove bits in the port matrix into a new helper mt7530_update_port_member(), which is called from mt7530_port_bridge_join() and mt7530_port_bridge_leave(). Another part of the preparation is using dsa_port_offloads_bridge_dev() instead of dsa_port_offloads_bridge() to check for bridge membership, as we don't have a struct dsa_bridge in mt7530_port_bridge_flags(). The port matrix setting is slightly streamlined, now always first setting the mt7530_port's pm field and then writing the port matrix from that field into the hardware register, instead of duplicating the bit manipulation for both the struct field and the register. mt7530_port_bridge_join() was previously using |= to update the port matrix with the port bitmap, which was unnecessary, as pm would only have the CPU port set before joining a bridge; a simple assignment can be used for both joining and leaving (and will also work when individual bits are added/removed in port_bitmap with regard to the previous port matrix, which is what happens with port isolation). No functional change intended. Signed-off-by: Matthias Schiffer <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Arınç ÜNAL <[email protected]> Tested-by: Arınç ÜNAL <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19octeontx2-pf: Fix linking objects into multiple modulesGeetha sowjanya3-2/+10
This patch fixes the below build warning messages that are caused due to linking same files to multiple modules by exporting the required symbols. "scripts/Makefile.build:244: drivers/net/ethernet/marvell/octeontx2/nic/Makefile: otx2_devlink.o is added to multiple modules: rvu_nicpf rvu_nicvf scripts/Makefile.build:244: drivers/net/ethernet/marvell/octeontx2/nic/Makefile: otx2_dcbnl.o is added to multiple modules: rvu_nicpf rvu_nicvf" Fixes: 8e67558177f8 ("octeontx2-pf: PFC config support with DCBx"). Signed-off-by: Geetha sowjanya <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19drm/xe: Use ttm_uncached for BO with NEEDS_UC flagMichal Wajdeczko1-0/+9
We should honor requested uncached mode also at the TTM layer. Otherwise, we risk losing updates to the memory based interrupts source or status vectors, as those require uncached memory. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Matt Roper <[email protected]> Acked-by: Thomas Hellström <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-19Merge branch 'net-drop-rx-socket-tracepoint'David S. Miller16-51/+65
Yan Zhai says: ==================== net: pass receive socket to drop tracepoint We set up our production packet drop monitoring around the kfree_skb tracepoint. While this tracepoint is extremely valuable for diagnosing critical problems, it also has some limitation with drops on the local receive path: this tracepoint can only inspect the dropped skb itself, but such skb might not carry enough information to: 1. determine in which netns/container this skb gets dropped 2. determine by which socket/service this skb oughts to be received The 1st issue is because skb->dev is the only member field with valid netns reference. But skb->dev can get cleared or reused. For example, tcp_v4_rcv will clear skb->dev and in later processing it might be reused for OFO tree. The 2nd issue is because there is no reference on an skb that reliably points to a receiving socket. skb->sk usually points to the local sending socket, and it only points to a receive socket briefly after early demux stage, yet the socket can get stolen later. For certain drop reason like TCP OFO_MERGE, Zerowindow, UDP at PROTO_MEM error, etc, it is hard to infer which receiving socket is impacted. This cannot be overcome by simply looking at the packet header, because of complications like sk lookup programs. In the past, single purpose tracepoints like trace_udp_fail_queue_rcv_skb, trace_sock_rcvqueue_full, etc are added as needed to provide more visibility. This could be handled in a more generic way. In this change set we propose a new 'sk_skb_reason_drop' call as a drop-in replacement for kfree_skb_reason at various local input path. It accepts an extra receiving socket argument. Both issues above can be resolved via this new argument. V4->V5: rename rx_skaddr to rx_sk to be more clear visually, suggested by Jesper Dangaard Brouer. V3->V4: adjusted the TP_STRUCT field order to align better, suggested by Steven Rostedt. V2->V3: fixed drop_monitor function signatures; fixed a few uninitialized sks; Added a few missing report tags from test bots (also noticed by Dan Carpenter and Simon Horman). V1->V2: instead of using skb->cb, directly add the needed argument to trace_kfree_skb tracepoint. Also renamed functions as Eric Dumazet suggested. ==================== Signed-off-by: David S. Miller <[email protected]>
2024-06-19af_packet: use sk_skb_reason_drop to free rx packetsYan Zhai1-5/+5
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving socket to the tracepoint. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Yan Zhai <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19udp: use sk_skb_reason_drop to free rx packetsYan Zhai2-10/+10
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving socket to the tracepoint. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Yan Zhai <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19tcp: use sk_skb_reason_drop to free rx packetsYan Zhai5-9/+9
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving socket to the tracepoint. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Yan Zhai <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: raw: use sk_skb_reason_drop to free rx packetsYan Zhai2-6/+6
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving socket to the tracepoint. Signed-off-by: Yan Zhai <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19ping: use sk_skb_reason_drop to free rx packetsYan Zhai1-1/+1
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving socket to the tracepoint. Signed-off-by: Yan Zhai <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: introduce sk_skb_reason_drop functionYan Zhai2-12/+20
Long used destructors kfree_skb and kfree_skb_reason do not pass receiving socket to packet drop tracepoints trace_kfree_skb. This makes it hard to track packet drops of a certain netns (container) or a socket (user application). The naming of these destructors are also not consistent with most sk/skb operating functions, i.e. functions named "sk_xxx" or "skb_xxx". Introduce a new functions sk_skb_reason_drop as drop-in replacement for kfree_skb_reason on local receiving path. Callers can now pass receiving sockets to the tracepoints. kfree_skb and kfree_skb_reason are still usable but they are now just inline helpers that call sk_skb_reason_drop. Note it is not feasible to do the same to consume_skb. Packets not dropped can flow through multiple receive handlers, and have multiple receiving sockets. Leave it untouched for now. Suggested-by: Eric Dumazet <[email protected]> Signed-off-by: Yan Zhai <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: add rx_sk to trace_kfree_skbYan Zhai4-9/+15
skb does not include enough information to find out receiving sockets/services and netns/containers on packet drops. In theory skb->dev tells about netns, but it can get cleared/reused, e.g. by TCP stack for OOO packet lookup. Similarly, skb->sk often identifies a local sender, and tells nothing about a receiver. Allow passing an extra receiving socket to the tracepoint to improve the visibility on receiving drops. Signed-off-by: Yan Zhai <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19drm/panfrost: Add support for Mali on the MT8188 SoCAngeloGioacchino Del Regno1-0/+10
MediaTek MT8188 has a Mali-G57 MC3 (Valhall-JM): add a new compatible and platform data using the same supplies and the same power domain lists as MT8183 (one regulator, three power domains). Reviewed-by: Chen-Yu Tsai <[email protected]> Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-19dt-bindings: gpu: mali-bifrost: Add compatible for MT8188 SoCAngeloGioacchino Del Regno1-1/+4
Add a compatible for the MediaTek MT8188 SoC, with an integrated ARM Mali G57 MC3 (Valhall-JM) GPU. Acked-by: Conor Dooley <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-19riscv: dts: microchip: add an initial devicetree for the BeagleV FireConor Dooley3-0/+306
Add an initial devicetree for the BeagleV Fire. This devicetree differs from that in the BeagleBoard BSP as it has a different memory configuration, however it will boot on the same FPGA images. PCI is disabled for now, as the Linux PCI driver (and the binding) assume which root port instance is in use. This will need to be fixed before PCI can be enabled. Link: https://www.beagleboard.org/boards/beaglev-fire Co-developed-by: Jamie Gibbons <[email protected]> Signed-off-by: Jamie Gibbons <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-19dt-bindings: riscv: microchip: document beaglev-fireConor Dooley1-0/+1
The BeagleV Fire is a BeagleBone Black form-factor board with a PolarFire SoC. Link: https://www.beagleboard.org/boards/beaglev-fire Acked-by: Rob Herring <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-19ata: ahci: Do not enable LPM if no LPM states are supported by the HBANiklas Cassel1-0/+8
LPM consists of HIPM (host initiated power management) and DIPM (device initiated power management). ata_eh_set_lpm() will only enable HIPM if both the HBA and the device supports it. However, DIPM will be enabled as long as the device supports it. The HBA will later reject the device's request to enter a power state that it does not support (Slumber/Partial/DevSleep) (DevSleep is never initiated by the device). For a HBA that doesn't support any LPM states, simply don't set a LPM policy such that all the HIPM/DIPM probing/enabling will be skipped. Not enabling HIPM or DIPM in the first place is safer than relying on the device following the AHCI specification and respecting the NAK. (There are comments in the code that some devices misbehave when receiving a NAK.) Performing this check in ahci_update_initial_lpm_policy() also has the advantage that a HBA that doesn't support any LPM states will take the exact same code paths as a port that is external/hot plug capable. Side note: the port in ata_port_dbg() has not been given a unique id yet, but this is not overly important as the debug print is disabled unless explicitly enabled using dynamic debug. A follow-up series will make sure that the unique id assignment will be done earlier. For now, the important thing is that the function returns before setting the LPM policy. Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Cc: [email protected] Reviewed-by: Mario Limonciello <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]>
2024-06-19riscv: dts: starfive: Set EMMC vqmmc maximum voltage to 3.3V on JH7110 boardsShengyu Qu1-1/+1
Currently, for JH7110 boards with EMMC slot, vqmmc voltage for EMMC is fixed to 1.8V, while the spec needs it to be 3.3V on low speed mode and should support switching to 1.8V when using higher speed mode. Since there are no other peripherals using the same voltage source of EMMC's vqmmc(ALDO4) on every board currently supported by mainline kernel, regulator-max-microvolt of ALDO4 should be set to 3.3V. Cc: [email protected] Signed-off-by: Shengyu Qu <[email protected]> Fixes: 7dafcfa79cc9 ("riscv: dts: starfive: enable DCDC1&ALDO4 node in axp15060") Signed-off-by: Conor Dooley <[email protected]>
2024-06-19crypto: mips/poly1305 - add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
With ARCH=mips, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in arch/mips/crypto/poly1305-mips.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-06-19MIPS: ip30: ip30-console: Add missing includeJiaxun Yang1-0/+1
Include linux/processor.h to fix build error: arch/mips/sgi-ip30/ip30-console.c: In function ‘prom_putchar’: arch/mips/sgi-ip30/ip30-console.c:21:17: error: implicit declaration of function ‘cpu_relax’ [-Werror=implicit-function-declaration] 21 | cpu_relax(); Cc: [email protected] Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-06-19octeontx2-pf: Add error handling to VLAN unoffload handlingSimon Horman1-1/+4
otx2_sq_append_skb makes used of __vlan_hwaccel_push_inside() to unoffload VLANs - push them from skb meta data into skb data. However, it omitts a check for __vlan_hwaccel_push_inside() returning NULL. Found by inspection based on [1] and [2]. Compile tested only. [1] Re: [PATCH net-next v1] net: stmmac: Enable TSO on VLANs https://lore.kernel.org/all/[email protected]/ [2] Re: [PATCH net-next v2] net: stmmac: Enable TSO on VLANs https://lore.kernel.org/all/CANn89i+11L5=tKsa7V7Aeyxaj6nYGRwy35PAbCRYJ73G+b25sg@mail.gmail.com/ Fixes: fd9d7859db6c ("octeontx2-pf: Implement ingress/egress VLAN offload") Signed-off-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19ASoC: cs35l56: Accept values greater than 0 as IRQ numbersSimon Trimmer1-1/+1
IRQ lookup functions such as those in ACPI can return error values when an IRQ is not defined. The i2c core driver converts the error codes to a value of 0 and the SPI bus driver passes them unaltered to client device drivers. The cs35l56 driver should only accept positive non-zero values as IRQ numbers. Signed-off-by: Simon Trimmer <[email protected]> Fixes: 8a731fd37f8b ("ASoC: cs35l56: Move utility functions to shared file") Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-19drm/i915/gt: Fix potential UAF by revoke of fence registersJanusz Krzysztofik1-0/+1
CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ... In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it. The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021 Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: [email protected] # v5.8+ Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-19riscv: dts: starfive: Update flash partition layoutMatthias Brugger1-5/+2
Up to now, the describe flash partition layout has some gaps. Use the whole flash chip by getting rid of the gaps. Suggested-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Matthias Brugger <[email protected]> Reviewed-by: Emil Renner Berthing <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-19riscv: dts: thead: th1520: Add PMU event nodeInochi Amaoto1-0/+81
T-HEAD th1520 uses standard C910 chip and its pmu is already supported by OpenSBI. Add the pmu event description for T-HEAD th1520 SoC. Signed-off-by: Inochi Amaoto <[email protected]> Link: https://www.xrvm.com/product/xuantie/4240217381324001280?spm=xrvm.27140568.0.0.7f979b29nzIa1m Reviewed-by: Guo Ren <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-19riscv: dts: starfive: add Star64 board devicetreeHenry Bell2-0/+62
The Pine64 Star64 is a development board based on the Starfive JH7110 SoC. The board features: - JH7110 SoC - 4/8 GiB LPDDR4 DRAM - AXP15060 PMIC - 40 pin GPIO header - 1x USB 3.0 host port - 3x USB 2.0 host port - 1x eMMC slot - 1x MicroSD slot - 1x QSPI Flash - 2x 1Gbps Ethernet port - 1x HDMI port - 1x 4-lane DSI - 1x 2-lane CSI - 1x PCIe 2.0 x1 lane Signed-off-by: Henry Bell <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-19dt-bindings: riscv: starfive: add Star64 board compatibleHenry Bell1-0/+1
Add pine64,star64 to JH7110 compatibility. The Pine64 Star64 is a development board based on the Starfive JH7110 SoC. The board features: - JH7110 SoC - 4/8 GiB LPDDR4 DRAM - AXP15060 PMIC - 40 pin GPIO header - 1x USB 3.0 host port - 3x USB 2.0 host port - 1x eMMC slot - 1x MicroSD slot - 1x QSPI Flash - 2x 1Gbps Ethernet port - 1x HDMI port - 1x 4-lane DSI - 1x 2-lane CSI - 1x PCIe 2.0 x1 lane Signed-off-by: Henry Bell <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-19Merge branch 'am65x-ptp'David S. Miller4-15/+145
Diogo Ivo says ==================== Enable PTP timestamping/PPS for AM65x SR1.0 devices This patch series enables support for PTP in AM65x SR1.0 devices. This feature relies heavily on the Industrial Ethernet Peripheral (IEP) hardware module, which implements a hardware counter through which time is kept. This hardware block is the basis for exposing a PTP hardware clock to userspace and for issuing timestamps for incoming/outgoing packets, allowing for time synchronization. The IEP also has compare registers that fire an interrupt when the counter reaches the value stored in a compare register. This feature allows us to support PPS events in the kernel. The changes are separated into five patches: - PATCH 01/05: Register SR1.0 devices with the IEP infrastructure to expose a PHC clock to userspace, allowing time to be adjusted using standard PTP tools. The code for issuing/ collecting packet timestamps is already present in the current state of the driver, so only this needs to be done. - PATCH 02/05: Remove unnecessary spinlock synchronization. - PATCH 03/05: Document IEP interrupt in DT binding. - PATCH 04/05: Add support for IEP compare event/interrupt handling to enable PPS events. - PATCH 05/05: Add the interrupts to the IOT2050 device tree. Currently every compare event generates two interrupts, the first corresponding to the actual event and the second being a spurious but otherwise harmless interrupt. The root cause of this has been identified and has been solved in the platform's SDK. A forward port of the SDK's patches also fixes the problem in upstream but is not included here since it's upstreaming is out of the scope of this series. If someone from TI would be willing to chime in and help get the interrupt changes upstream that would be great! Signed-off-by: Diogo Ivo <[email protected]> --- Changes in v4: - Remove unused 'flags' variables in patch 02/05 - Add patch 03/05 describing IEP interrupt in DT binding - Link to v3: https://lore.kernel.org/r/[email protected] Changes in v3: - Collect Reviewed-by tags - Add patch 02/04 removing spinlocks from IEP driver - Use mutex-based synchronization when accessing HW registers - Link to v2: https://lore.kernel.org/r/[email protected] Changes in v2: - Collect Reviewed-by tags - PATCH 01/03: Limit line length to 80 characters - PATCH 02/03: Proceed with limited functionality if getting IRQ fails, limit line length to 80 characters - Link to v1: https://lore.kernel.org/r/[email protected] ==================== Signed-off-by: David S. Miller <[email protected]>
2024-06-19arm64: dts: ti: iot2050: Add IEP interrupts for SR1.0 devicesDiogo Ivo1-0/+12
Add the interrupts needed for PTP Hardware Clock support via IEP in SR1.0 devices. Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Diogo Ivo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: ti: icss-iep: Enable compare eventsDiogo Ivo1-0/+74
The IEP module supports compare events, in which a value is written to a hardware register and when the IEP counter reaches the written value an interrupt is generated. Add handling for this interrupt in order to support PPS events. Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19dt-bindings: net: Add IEP interruptDiogo Ivo1-0/+9
The IEP interrupt is used in order to support both capture events, where an incoming external signal gets timestamped on arrival, and compare events, where an interrupt is generated internally when the IEP counter reaches a programmed value. Signed-off-by: Diogo Ivo <[email protected]> Acked-by: Conor Dooley <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: ti: icss-iep: Remove spinlock-based synchronizationDiogo Ivo1-14/+0
As all sources of concurrency in hardware register access occur in non-interrupt context eliminate spinlock-based synchronization and rely on the mutex-based synchronization that is already present. Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: ti: icssg-prueth: Enable PTP timestamping support for SR1.0 devicesDiogo Ivo1-1/+50
Enable PTP support for AM65x SR1.0 devices by registering with the IEP infrastructure in order to expose a PTP clock to userspace. Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19Merge branch 'virtio_net-csum-xdp-fixes'David S. Miller1-3/+29
Heng Qi says: ==================== virtio_net: fixes for checksum offloading and XDP handling This series of patches aim to address two specific issues identified in the virtio_net driver related to checksum offloading and XDP processing of fully checksummed packets. The first patch corrects the handling of checksum offloading in the driver. The second patch addresses an issue where the XDP program had no trouble with fully checksummed packets. ==================== Signed-off-by: David S. Miller <[email protected]>
2024-06-19virtio_net: fixing XDP for fully checksummed packets handlingHeng Qi1-1/+19
The XDP program can't correctly handle partially checksummed packets, but works fine with fully checksummed packets. If the device has already validated fully checksummed packets, then the driver doesn't need to re-validate them, saving CPU resources. Additionally, the driver does not drop all partially checksummed packets when VIRTIO_NET_F_GUEST_CSUM is not negotiated. This is not a bug, as the driver has always done this. Fixes: 436c9453a1ac ("virtio-net: keep vnet header zeroed after processing XDP") Signed-off-by: Heng Qi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19virtio_net: checksum offloading handling fixHeng Qi1-2/+10
In virtio spec 0.95, VIRTIO_NET_F_GUEST_CSUM was designed to handle partially checksummed packets, and the validation of fully checksummed packets by the device is independent of VIRTIO_NET_F_GUEST_CSUM negotiation. However, the specification erroneously stated: "If VIRTIO_NET_F_GUEST_CSUM is not negotiated, the device MUST set flags to zero and SHOULD supply a fully checksummed packet to the driver." This statement is inaccurate because even without VIRTIO_NET_F_GUEST_CSUM negotiation, the device can still set the VIRTIO_NET_HDR_F_DATA_VALID flag. Essentially, the device can facilitate the validation of these packets' checksums - a process known as RX checksum offloading - removing the need for the driver to do so. This scenario is currently not implemented in the driver and requires correction. The necessary specification correction[1] has been made and approved in the virtio TC vote. [1] https://lists.oasis-open.org/archives/virtio-comment/202401/msg00011.html Fixes: 4f49129be6fa ("virtio-net: Set RXCSUM feature if GUEST_CSUM is available") Signed-off-by: Heng Qi <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: usb: ax88179_178a: improve reset checkJose Ignacio Tornos Martinez1-5/+13
After ecf848eb934b ("net: usb: ax88179_178a: fix link status when link is set to down/up") to not reset from usbnet_open after the reset from usbnet_probe at initialization stage to speed up this, some issues have been reported. It seems to happen that if the initialization is slower, and some time passes between the probe operation and the open operation, the second reset from open is necessary too to have the device working. The reason is that if there is no activity with the phy, this is "disconnected". In order to improve this, the solution is to detect when the phy is "disconnected", and we can use the phy status register for this. So we will only reset the device from reset operation in this situation, that is, only if necessary. The same bahavior is happening when the device is stopped (link set to down) and later is restarted (link set to up), so if the phy keeps working we only need to enable the mac again, but if enough time passes between the device stop and restart, reset is necessary, and we can detect the situation checking the phy status register too. cc: [email protected] # 6.6+ Fixes: ecf848eb934b ("net: usb: ax88179_178a: fix link status when link is set to down/up") Reported-by: Yongqin Liu <[email protected]> Reported-by: Antje Miederhöfer <[email protected]> Reported-by: Arne Fitzenreiter <[email protected]> Tested-by: Yongqin Liu <[email protected]> Tested-by: Antje Miederhöfer <[email protected]> Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19rds:Simplify the allocation of slab cachesHongfu Li2-6/+2
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create to simplify the creation of SLAB caches. Signed-off-by: Hongfu Li <[email protected]> Reviewed-by: Zhu Yanjun <[email protected]> Reviewed-by: Allison Henderson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19x86/resctrl: Don't try to free nonexistent RMIDsDave Martin1-1/+2
Commit 6791e0ea3071 ("x86/resctrl: Access per-rmid structures by index") adds logic to map individual monitoring groups into a global index space used for tracking allocated RMIDs. Attempts to free the default RMID are ignored in free_rmid(), and this works fine on x86. With arm64 MPAM, there is a latent bug here however: on platforms with no monitors exposed through resctrl, each control group still gets a different monitoring group ID as seen by the hardware, since the CLOSID always forms part of the monitoring group ID. This means that when removing a control group, the code may try to free this group's default monitoring group RMID for real. If there are no monitors however, the RMID tracking table rmid_ptrs[] would be a waste of memory and is never allocated, leading to a splat when free_rmid() tries to dereference the table. One option would be to treat RMID 0 as special for every CLOSID, but this would be ugly since bookkeeping still needs to be done for these monitoring group IDs when there are monitors present in the hardware. Instead, add a gating check of resctrl_arch_mon_capable() in free_rmid(), and just do nothing if the hardware doesn't have monitors. This fix mirrors the gating checks already present in mkdir_rdt_prepare_rmid_alloc() and elsewhere. No functional change on x86. [ bp: Massage commit message. ] Fixes: 6791e0ea3071 ("x86/resctrl: Access per-rmid structures by index") Signed-off-by: Dave Martin <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Reinette Chatre <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-06-19drm: bridge: simple-bridge: use devm_drm_bridge_add in probeMarc Gonzalez1-12/+1
simple_bridge_probe() calls drm_bridge_add() Thus, drm_bridge_remove() must be called in the remove() callback. If we call devm_drm_bridge_add() instead, then drm_bridge_remove() will be called automatically at device release, and the remove() callback is no longer required. Signed-off-by: Marc Gonzalez <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-19KVM: arm64: nv: Use GFP_KERNEL_ACCOUNT for sysreg_masks allocationOliver Upton1-1/+1
Of course, userspace is in the driver's seat for struct kvm and associated allocations. Make sure the sysreg_masks allocation participates in kmem accounting. Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-19Merge drm/drm-next into drm-intel-nextJani Nikula11735-239989/+768908
Sync to v6.10-rc3. Signed-off-by: Jani Nikula <[email protected]>
2024-06-19KVM: arm64: nv: Add handling of NXS-flavoured TLBI operationsMarc Zyngier2-0/+119
Latest kid on the block: NXS (Non-eXtra-Slow) TLBI operations. Let's add those in bulk (NSH, ISH, OSH, both normal and range) as they directly map to their XS (the standard ones) counterparts. Not a lot to say about them, they are basically useless. Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-19KVM: arm64: nv: Add handling of range-based TLBI operationsMarc Zyngier3-6/+108
We already support some form of range operation by handling FEAT_TTL, but so far the "arbitrary" range operations are unsupported. Let's fix that. For EL2 S1, this is simple enough: we just map both NSH, ISH and OSH instructions onto the ISH version for EL1. For TLBI instructions affecting EL1 S1, we use the same model as their non-range counterpart to invalidate in the context of the correct VMID. For TLBI instructions affecting S2, we interpret the data passed by the guest to compute the range and use that to tear-down part of the shadow S2 range and invalidate the TLBs. Finally, we advertise FEAT_TLBIRANGE if the host supports it. Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-19KVM: arm64: nv: Add handling of outer-shareable TLBI operationsMarc Zyngier3-1/+29
Our handling of outer-shareable TLBIs is pretty basic: we just map them to the existing inner-shareable ones, because we really don't have anything else. The only significant change is that we can now advertise FEAT_TLBIOS support if the host supports it. Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.