summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-04-20KVM: arm64: Ensure CPU PMU probes before pKVM host de-privilegeWill Deacon
Although pKVM supports CPU PMU emulation for non-protected guests since 722625c6f4c5 ("KVM: arm64: Reenable pmu in Protected Mode"), this relies on the PMU driver probing before the host has de-privileged so that the 'kvm_arm_pmu_available' static key can still be enabled by patching the hypervisor text. As it happens, both of these events hang off device_initcall() but the PMU consistently won the race until 7755cec63ade ("arm64: perf: Move PMUv3 driver to drivers/perf"). Since then, the host will fail to boot when pKVM is enabled: | hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available | kvm [1]: nVHE hyp BUG at: [<ffff8000090366e0>] __kvm_nvhe_handle_host_mem_abort+0x270/0x284! | kvm [1]: Cannot dump pKVM nVHE stacktrace: !CONFIG_PROTECTED_NVHE_STACKTRACE | kvm [1]: Hyp Offset: 0xfffea41fbdf70000 | Kernel panic - not syncing: HYP panic: | PS:a00003c9 PC:0000dbe04b0c66e0 ESR:00000000f2000800 | FAR:fffffbfffddfcf00 HPFAR:00000000010b0bf0 PAR:0000000000000000 | VCPU:0000000000000000 | CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7-00083-g0bce6746d154 #1 | Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x13c/0x33c | nvhe_hyp_panic_handler+0x10c/0x190 | aarch64_insn_patch_text_nosync+0x64/0xc8 | arch_jump_label_transform+0x4c/0x5c | __jump_label_update+0x84/0xfc | jump_label_update+0x100/0x134 | static_key_enable_cpuslocked+0x68/0xac | static_key_enable+0x20/0x34 | kvm_host_pmu_init+0x88/0xa4 | armpmu_register+0xf0/0xf4 | arm_pmu_acpi_probe+0x2ec/0x368 | armv8_pmu_driver_init+0x38/0x44 | do_one_initcall+0xcc/0x240 Fix the race properly by deferring the de-privilege step to device_initcall_sync(). This will also be needed in future when probing IOMMU devices and allows us to separate the pKVM de-privilege logic from the core hypervisor initialisation path. Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Fixes: 7755cec63ade ("arm64: perf: Move PMUv3 driver to drivers/perf") Tested-by: Fuad Tabba <tabba@google.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230420123356.2708-1-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2023-04-20net: libwx: fix memory leak in wx_setup_rx_resourcesZhengchao Shao
When wx_alloc_page_pool() failed in wx_setup_rx_resources(), it doesn't release DMA buffer. Add dma_free_coherent() in the error path to release the DMA buffer. Fixes: 850b971110b2 ("net: libwx: Allocate Rx and Tx resources") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230418065450.2268522-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-20ublk: don't return 0 in case of any failureMing Lei
Commit 2d786e66c966 ("block: ublk: switch to ioctl command encoding") starts to reset local variable of 'ret' as zero, then if any failure happens when handling the three IO commands, 0 can be returned to ublk server. Fix it by returning -EINVAL in case of command handling failure. Cc: Christoph Hellwig <hch@lst.de> Fixes: 2d786e66c966 ("block: ublk: switch to ioctl command encoding") Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20230420091104.1092972-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-04-20Revert "block: Merge bio before checking ->cached_rq"Ming Lei
This reverts commit 23f3e3272e7a4d9fb870485cd6df1e4f9539282c. blk-mq sched bio merge still needs request to grab queue usage counter, so we can't simply call blk_mq_attempt_bio_merge() when queue usage counter isn't held. Fixes: 23f3e3272e7a ("block: Merge bio before checking ->cached_rq") Cc: Xiao Ni <xni@redhat.com> Reported-by: Yi Zhang <yi.zhang@redhat.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20230420112018.1108058-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-04-20Merge tag 'mt76-for-kvalo-2023-04-18' of https://github.com/nbd168/wirelessKalle Valo
mt76 patches for 6.4 - fixes - connac code unification - mt7921 p2p support - mt7996 mesh a-msdu support - mt7996 eht support - mt7996 coredump support
2023-04-20Revert "io_uring/rsrc: disallow multi-source reg buffers"Jens Axboe
This reverts commit edd478269640b360c6f301f2baa04abdda563ef3. There's really no specific need to disallow multiple sources of buffers, and io_uring really should not be mandating this by itself. We should be able to solely rely on GUP making these decisions. As this also stands in the way of a cleanup where io_uring is the odd one out, kill it. Link: https://lore.kernel.org/all/61ded378-51a8-1dcb-b631-fda1903248a9@gmail.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-04-20wifi: rtw88: Update spelling in main.hSimon Horman
Update spelling in comments in main.h Found by inspection. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230418-rtw88-starspell-v1-1-70e52a23979b@kernel.org
2023-04-20wifi: airo: remove ISA_DMA_API dependencyArnd Bergmann
This driver does not actually use the ISA DMA API, it is purely PIO based, so remove the dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417205131.1560074-1-arnd@kernel.org
2023-04-20wifi: rtl8xxxu: Simplify setting the initial gainBitterblue Smith
The goal of writing 0x6954341e / 0x6955341e to REG_OFDM0_XA_AGC_CORE1 appears to be setting the initial gain, which is stored in bits 0..6. Bits 7..31 are the same as what the phy init tables write. Modify only bits 0..6 so that we don't have to care about the values of the others. This way we don't have to add another "else if" for the RTL8192FU. Why we need to change the initial gain from the default 0x20 to 0x1e? Not sure. Some of the vendor drivers change it to 0x1e before scanning and then restore it to the original value after. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/cf91ca69-70e3-4c20-c0b1-e59d452356a1@gmail.com
2023-04-20wifi: rtl8xxxu: Add rtl8xxxu_write{8,16,32}_{set,clear}Bitterblue Smith
Also add rtl8xxxu_write32_mask, rtl8xxxu_write_rfreg_mask. These helper functions make it easier to modify only parts of a register by eliminating the call to the register reading function and the bit manipulations. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/9430b841-1048-b27c-14ec-fca447dc32af@gmail.com
2023-04-20wifi: rtl8xxxu: Don't print the vendor/product/serialBitterblue Smith
Most devices have a vendor name, product name, and serial number in the efuse, but it's pretty useless. It duplicates the information already printed by the USB subsystem: usb 1-4: New USB device found, idVendor=0bda, idProduct=8178, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: New USB device found, idVendor=0bda, idProduct=818b, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial not available. usb 1-4: New USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 002E2DC0041F -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00E04C0001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial: 00E04C0001 Also, that data is not interpreted correctly in all cases: usb 3-1.1.2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1.1.2: Product: 802.11n NIC usb 3-1.1.2: Manufacturer: Realtek usb 3-1.1.2: Vendor: Realtek usb 3-1.1.2: Product: \x03802.11n NI usb 3-1.1.2: Serial: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff Link: https://bugzilla.kernel.org/show_bug.cgi?id=217231 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/a2a7d9df-0529-7890-3522-48dce613753f@gmail.com
2023-04-20wifi: rtw88: Fix memory leak in rtw88_usbLarry Finger
Kmemleak shows the following leak arising from routine in the usb probe routine: unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90 [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore] [<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0 [<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160 [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90 [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0 [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0 [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210 [<ffffffff92b50935>] driver_register+0x55/0xf0 [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore] [<ffffffff92401153>] do_one_initcall+0x43/0x210 [<ffffffff9254f42a>] do_init_module+0x4a/0x200 [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120 [<ffffffff92ee6626>] do_syscall_64+0x56/0x80 [<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The leak was verified to be real by unloading the driver, which resulted in a dangling pointer to the allocation. The allocated memory is freed in rtw_usb_intf_deinit(). Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417160331.23071-1-Larry.Finger@lwfinger.net
2023-04-20wifi: rtw88: call rtw8821c_switch_rf_set() according to chip variantSascha Hauer
We have to call rtw8821c_switch_rf_set() with SWITCH_TO_WLG or SWITCH_TO_BTG according to the chip variant as denoted in rfe_option. The information which argument to use for which variant has been taken from the vendor driver. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-5-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: set pkg_type correctly for specific rtw8821c variantsSascha Hauer
According to the vendor driver the pkg_type has to be set to '1' for some rtw8821c variants. As the pkg_type has been hardcoded to '0', add a field for it in struct rtw_hal and set this correctly in the rtw8821c part. With this parsing of a rtw_table is influenced and check_positive() in phy.c returns true for some cases here. The same is done in the vendor driver. However, this has no visible effect on the driver here. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-4-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: rtw8821c: Fix rfe_option field widthSascha Hauer
On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the vendor driver suggests that the field width of rfe_option is 5 bit, so rfe_option should be masked with 0x1f. Without this the rfe_option comparisons with 2 further down the driver evaluate as false when they should really evaluate as true. The effect is that 2G channels do not work. rfe_option is also used as an array index into rtw8821c_rfe_defs[]. rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support, likely because rfe_option reads as 0x22. As this now becomes 0x2, rtw8821c_rfe_defs[34] is no longer used and can be removed. Note that this might not be the whole truth. In the vendor driver there are indeed places where the unmasked rfe_option value is used. However, the driver has several places where rfe_option is tested with the pattern if (rfe_option == 2 || rfe_option == 0x22) or if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5) has no influence on the code path taken. We therefore mask BIT(5) out from rfe_option entirely until this assumption is proved wrong by some chip variant we do not know yet. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: ValdikSS <iam@valdikss.org.ru> Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-3-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: usb: fix priority queue to endpoint mappingSascha Hauer
The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated. This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver. Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: ValdikSS <iam@valdikss.org.ru> Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-2-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: 8822c: add iface combinationPo-Hao Huang
Allow 8822c to operate two interface concurrently, only 1 AP mode plus 1 station mode under same frequency is supported. Combination of other types will not be added until requested. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121331.18062-1-pkshih@realtek.com
2023-04-20wifi: rtw88: handle station mode concurrent scan with AP modePo-Hao Huang
This patch allows vifs sharing same hardware with the AP mode vif to do scan, do note that this could lead to packet loss or disconnection of the AP's clients. Since we don't have chanctx, update scan info upon set channel so bandwidth changes won't go unnoticed and get misconfigured after scan. Download beacon just before scan starts to allow hardware to get proper content to do beaconing. Last, beacons should only be transmitted in AP's operating channel. Turn related beacon functions off while we're in other channels so the receiving stations won't get confused. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121323.18008-1-pkshih@realtek.com
2023-04-20wifi: rtw88: prevent scan abort with other VIFsPo-Hao Huang
Only abort scan with current scanning VIF. If we have more than one interface, we could call rtw_hw_scan_abort() with the wrong VIF as input. This avoids potential null pointer being accessed when actually the other VIF is scanning. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121312.17954-1-pkshih@realtek.com
2023-04-20wifi: rtw88: refine reserved page flow for AP modePo-Hao Huang
Only gather reserved pages from AP interface after it has started. Or else ieee80211_beacon_get_*() returns NULL and causes other VIFs' reserved pages fail to download. Update location of current reserved page after beacon renews so offsets changed by beacon can be recognized. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121300.17900-1-pkshih@realtek.com
2023-04-20wifi: rtw88: disallow PS during AP modePo-Hao Huang
Firmware can't support PS mode during AP mode, so disallow this case. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-5-pkshih@realtek.com
2023-04-20wifi: rtw88: 8822c: extend reserved page numberPo-Hao Huang
Extend 8822c's reserved page number to accommodate additional required pages. Reserved page is an area of memory in the FIFO dedicated for special purposes. Previously only one interface is supported so 8 pages should suffice, extend it so we can support 2 interfaces concurrently. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-4-pkshih@realtek.com
2023-04-20wifi: rtw88: add port switch for AP modePo-Hao Huang
Switch port settings if AP mode does not start on port 0 because of hardware limitation. For some ICs, beacons on ports other than zero could misbehave and do not issue properly, to fix this we change AP VIFs to port zero when multiple interfaces is active. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-3-pkshih@realtek.com
2023-04-20wifi: rtw88: add bitmap for dynamic port settingsPo-Hao Huang
In order to support multiple interfaces, multiple port settings will be required. Current code always uses port 0 and should be changed. Declare a bitmap with size equal to hardware port number to record the current usage. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-2-pkshih@realtek.com
2023-04-20wifi: rtw89: mac: use regular int as return type of DLE buffer requestPing-Ke Shih
The function to request DLE (data link engine) buffer uses 'u16' as return value that mixes error code, so change it to 'int' as regular error code. Also, treat invalid register value (0xfff) as an error. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414082228.30766-1-pkshih@realtek.com
2023-04-20Merge branch 'for-next/mm' into for-next/coreWill Deacon
* for-next/mm: arm64: mm: always map fixmap at page granularity arm64: mm: move fixmap code to its own file arm64: add FIXADDR_TOT_{START,SIZE} Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"" arm: uaccess: Remove memcpy_page_flushcache() mm,kfence: decouple kfence from page granularity mapping judgement
2023-04-20Merge branch 'for-next/misc' into for-next/coreWill Deacon
* for-next/misc: arm64: kexec: include reboot.h arm64: delete dead code in this_cpu_set_vectors() arm64: kernel: Fix kernel warning when nokaslr is passed to commandline arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step arm64/sme: Fix some comments of ARM SME arm64/signal: Alloc tpidr2 sigframe after checking system_supports_tpidr2() arm64/signal: Use system_supports_tpidr2() to check TPIDR2 arm64: compat: Remove defines now in asm-generic arm64: kexec: remove unnecessary (void*) conversions arm64: armv8_deprecated: remove unnecessary (void*) conversions firmware: arm_sdei: Fix sleep from invalid context BUG
2023-04-20Merge branch 'for-next/kdump' into for-next/coreWill Deacon
* for-next/kdump: arm64: kdump: defer the crashkernel reservation for platforms with no DMA memory zones arm64: kdump: do not map crashkernel region specifically arm64: kdump : take off the protection on crashkernel memory region
2023-04-20Merge branch 'for-next/ftrace' into for-next/coreWill Deacon
* for-next/ftrace: arm64: ftrace: Simplify get_ftrace_plt arm64: ftrace: Add direct call support ftrace: selftest: remove broken trace_direct_tramp ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS ftrace: Store direct called addresses in their ops ftrace: Rename _ftrace_direct_multi APIs to _ftrace_direct APIs ftrace: Remove the legacy _ftrace_direct API ftrace: Replace uses of _ftrace_direct APIs with _ftrace_direct_multi ftrace: Let unregister_ftrace_direct_multi() call ftrace_free_filter()
2023-04-20Merge branch 'for-next/cpufeature' into for-next/coreWill Deacon
* for-next/cpufeature: arm64/cpufeature: Use helper macro to specify ID register for capabilites arm64/cpufeature: Consistently use symbolic constants for min_field_value arm64/cpufeature: Pull out helper for CPUID register definitions
2023-04-20Merge branch 'for-next/asm' into for-next/coreWill Deacon
* for-next/asm: arm64: uaccess: remove unnecessary earlyclobber arm64: uaccess: permit put_{user,kernel} to use zero register arm64: uaccess: permit __smp_store_release() to use zero register arm64: atomics: lse: improve cmpxchg implementation
2023-04-20Merge branch 'for-next/acpi' into for-next/coreWill Deacon
* for-next/acpi: ACPI: AGDI: Improve error reporting for problems during .remove()
2023-04-20i2c: designware: Add doorbell support for MendocinoMario Limonciello
Mendocino and later platform don't use the platform feature mailbox for communication for I2C arbitration, they rely upon ringing a doorbell. Detect the platform by the device ID of the root port and choose the appropriate method. Link: https://lore.kernel.org/linux-i2c/20220916131854.687371-3-jsd@semihalf.com/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mark Hasemeyer <markhas@chromium.org> Tested-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20i2c: designware: Use PCI PSP driver for communicationMario Limonciello
Currently the PSP semaphore communication base address is discovered by using an MSR that is not architecturally guaranteed for future platforms. Also the mailbox that is utilized for communication with the PSP may have other consumers in the kernel, so it's better to make all communication go through a single driver. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20powerpc: Move Power10 feature PPC_MODULE_FEATURE_P10Danny Tsen
Move Power10 feature, PPC_MODULE_FEATURE_P10, definition to be in arch/powerpc/include/asm/cpufeature.h. Signed-off-by: Danny Tsen <dtsen@linux.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: p10-aes-gcm - Remove POWER10_CPU dependencyDanny Tsen
Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Signed-off-by: Danny Tsen <dtsen@linux.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: testmgr - Add some test vectors for cmac(camellia)David Howells
Add some test vectors for 128-bit cmac(camellia) as found in draft-kato-ipsec-camellia-cmac96and128-01 section 6.2. The document also shows vectors for camellia-cmac-96, and for VK with a length greater than 16, but I'm not sure how to express those in testmgr. This also leaves cts(cbc(camellia)) untested, but I can't seem to find any tests for that that I could put into testmgr. Signed-off-by: David Howells <dhowells@redhat.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: Chuck Lever <chuck.lever@oracle.com> cc: Scott Mayhew <smayhew@redhat.com> cc: linux-nfs@vger.kernel.org cc: linux-crypto@vger.kernel.org Link: https://datatracker.ietf.org/doc/pdf/draft-kato-ipsec-camellia-cmac96and128-01 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: cryptd - Add support for cloning hashesHerbert Xu
Allow cryptd hashes to be cloned. The underlying hash will be cloned. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: cryptd - Convert hash to use modern init_tfm/exit_tfmHerbert Xu
The cryptd hash template was still using the obsolete cra_init/cra_exit interface. Make it use the modern ahash init_tfm/exit_tfm instead. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: hmac - Add support for cloningHerbert Xu
Allow hmac to be cloned. The underlying hash can be used directly with a reference count. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: hash - Add crypto_clone_ahash/shashHerbert Xu
This patch adds the helpers crypto_clone_ahash and crypto_clone_shash. They are the hash-specific counterparts of crypto_clone_tfm. This allows code paths that cannot otherwise allocate a hash tfm object to do so. Once a new tfm has been obtained its key could then be changed without impacting other users. Note that only algorithms that implement clone_tfm can be cloned. However, all keyless hashes can be cloned by simply reusing the tfm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: api - Add crypto_clone_tfmHerbert Xu
This patch adds the helper crypto_clone_tfm. The purpose is to allocate a tfm object with GFP_ATOMIC. As we cannot sleep, the object has to be cloned from an existing tfm object. This allows code paths that cannot otherwise allocate a crypto_tfm object to do so. Once a new tfm has been obtained its key could then be changed without impacting other users. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: api - Add crypto_tfm_getHerbert Xu
Add a crypto_tfm_get interface to allow tfm objects to be shared. They can still be freed in the usual way. This should only be done with tfm objects with no keys. You must also not modify the tfm flags in any way once it becomes shared. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/sha - Use local .L symbols for codeArd Biesheuvel
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/crc32 - Use local .L symbols for codeArd Biesheuvel
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/aesni - Use local .L symbols for codeArd Biesheuvel
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/sha256 - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/ghash - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/des3 - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/crc32c - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit (git 2.34.1) at 2025-09-22 21:38:36 +0000