[PW_SID:1154107] Enable Bluetooth and WiFi on K3 Pico ITX - #2555
[PW_SID:1154107] Enable Bluetooth and WiFi on K3 Pico ITX#2555linux-riscv-bot wants to merge 12 commits into
Conversation
…_RWX When CONFIG_STRICT_MODULE_RWX is not set, execmem cannot create temporary writable mappings for read-only executable pages. In this case, the execmem ranges must already have writable permissions. Currently EXECMEM_KPROBES unconditionally uses PAGE_KERNEL_READ_EXEC, which causes kprobe instruction slot writes to trigger page faults on systems where CONFIG_STRICT_MODULE_RWX is not enabled. Fix this by using PAGE_KERNEL_EXEC when CONFIG_STRICT_MODULE_RWX is not available. Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260814082742.148403-2-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
patch_map() always creates a temporary writable mapping via fixmap for kernel text addresses, even when CONFIG_STRICT_KERNEL_RWX is disabled and the kernel text is already mapped with _PAGE_WRITE. This is unnecessary overhead at best, and on minimal configurations it can cause page faults. Skip the fixmap path for kernel text when CONFIG_STRICT_KERNEL_RWX is not enabled, since the text pages are already writable in that case. The module text path is already gated on CONFIG_STRICT_MODULE_RWX and is kept unchanged. Reported-by: Klara Modin <klara@kasm.eu> Closes: https://lore.kernel.org/all/ant_8TaBbov_GS4i@soda.int.kasm.eu/ Reported-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Closes: https://lore.kernel.org/all/CA+V-a8tQK8rih9SGGTyqrEBGpNkx4H0eX2YccCRrgkVAPr+EBg@mail.gmail.com/ Tested-by: Klara Modin <klarasmodin@gmail.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20260814082742.148403-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
This reverts commit 3033b2b. The reverted patch is userspace-visible behavior change, not a bug fix. The two variables here (pmm and pmlen) control two independent features: pmm is the _hardware_ pointer masking mode that applies while executing in userspace. pmlen is the shift amount that the _kernel_ uses when untagging addresses; PMLEN_0 means no untagging occurs, so the kernel does not accept tagged addresses in syscall arguments. It is valid (as documented and tested by the self test) to enable pointer masking without enabling the tagged address ABI. This separation is necessary to allow userspace to create an execution environment similar to what the kernel supports on arm64 by default, where TBI is enabled but the tagged address ABI is not. (On arm64, there is no equivalent to PR_PMLEN_MASK because TBI is always enabled.) Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Link: https://patch.msgid.link/20260820014551.1979772-1-samuel.holland@sifive.com Cc: stable@vger.kernel.org Fixes: 3033b2b ("riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set") Signed-off-by: Paul Walmsley <pjw@kernel.org>
Prefer the convenient string choice 'str_disabled_enabled()' helper over hardcoded strings in 'setup_global_riscv_enable()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://patch.msgid.link/20260819160546.3219942-1-dmantipov@yandex.ru Signed-off-by: Paul Walmsley <pjw@kernel.org>
The vendor-extension handlers reached from hwprobe_one_pair() (hwprobe_isa_vendor_ext_thead_0() and friends) only OR the present bits into pair->value via VENDOR_EXTENSION_SUPPORTED() and clear their own missing bits; they assume the caller has already zeroed pair->value. That holds for hwprobe_get_values() (it zeroes each pair) and hwprobe_get_cpus() (it re-initializes its scratch pair per key), but not for complete_hwprobe_vdso_data(), which reuses a single pair across all keys without re-zeroing. A vendor key therefore inherits stale bits from the previously probed key, and the wrong value is cached in the vDSO all_cpu_hwprobe_values[] and handed to userspace on the fast patih. Zero pair->value once at the top of hwprobe_one_pair() so every handler starts from a clean value regardless of the caller, and drop the now redundant zeroing in the *_BLOCK_SIZE cases. hwprobe_isa_ext0() keeps its own zeroing because hwprobe_ext0_has() calls it directly, bypassing hwprobe_one_pair(). Fixes: a5ea53d ("riscv: hwprobe: Add thead vendor extension probing") Signed-off-by: Andy Chiu <tchiu@tenstorrent.com> Reviewed-by: Jesse Taube <jtaubepe@redhat.com> Link: https://patch.msgid.link/20260725001614.2578617-2-tchiu@tenstorrent.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
x86 did this in commit b0a848f ("x86/bugs: Make i386 use GENERIC_BUG_RELATIVE_POINTERS") powerpc did this in commit 1baa1f7 ("powerpc: Allow relative pointers in bug table entries") Similar as x86 and powerpc does, make RV32 use GENERIC_BUG_RELATIVE_POINTERS for "there is only one code path." and "less #ifdef is more better". Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20260221024255.3552-1-jszhang@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
On the SpacemiT K3 SoC, the combo phy provides 8 lines that can either be used for PCIe or USB3, depending on its configuration (spacemit,apmu). This configuration is defined at the board level, and assigning a phy line to a USB3 controller while it is configured as PCIe results in an "Invalid PHY mode" error. Move the USB phy definitions at the board level, as it is done for the submitted PCIe controller [1]. [1] https://lore.kernel.org/20260727094726.890179-3-inochiama@gmail.com/ Fixes: 46380e4 ("riscv: dts: spacemit: k3: add USB controller and USB phy support") Cc: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
…oard The SpacemiT K3 has 4 USB3 controllers labelled A to D. On the K3 Pico-ITX board, the controllers B and C are used in USB2 mode only respectively for the M.2 B-Key slot and for the RTL8852BE Bluetooth controller. Add the two controller nodes. On the K3 Pico-ITX board, enable the controllers nodes and add the two corresponding USB2 PHY nodes. Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
…oard On the K3 Pico-ITX board, by default the GPIO pin that connects to the RTL8852BE Bluetooth enable signal is driven low, resulting in impossibility to use Bluetooth. Add a DT node to expose it as an RFKILL device, which lets the Bluetooth driver or userspace toggle it as required. Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
… board On the K3 Pico-ITX board, by default the GPIO pin that connects to the RTL8852BE WLAN enable signal is driven low, resulting in impossibility to connect to any network. Add a DT node to expose it as an RFKILL device, which lets the WLAN driver or userspace toggle it as required. Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
…TX board The SpacemiT K3 Pico-ITX board has a RTL8852BE Bluetooth and WLAN controller connected through PCIe and USB. For the WLAN part, enable CFG80211, MAC80211, RTW89 and RTW89_8852BE as modules. For the Bluetooth, enable CONFIG_BT and CONFIG_BT_HCIBTUSB as modules. Both also require RFKILL and RFKILL_GPIO. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 1: "[v3,1/5] riscv: dts: spacemit: k3: move USB3 phy to board level" |
|
Patch 2: "[v3,2/5] riscv: dts: spacemit: k3: add USB3 B and C controllers for Pico-ITX board" |
|
Patch 2: "[v3,2/5] riscv: dts: spacemit: k3: add USB3 B and C controllers for Pico-ITX board" |
|
Patch 2: "[v3,2/5] riscv: dts: spacemit: k3: add USB3 B and C controllers for Pico-ITX board" |
|
Patch 2: "[v3,2/5] riscv: dts: spacemit: k3: add USB3 B and C controllers for Pico-ITX board" |
|
Patch 2: "[v3,2/5] riscv: dts: spacemit: k3: add USB3 B and C controllers for Pico-ITX board" |
|
Patch 2: "[v3,2/5] riscv: dts: spacemit: k3: add USB3 B and C controllers for Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 4: "[v3,4/5] riscv: dts: spacemit: k3: add rfkill node for WLAN on the K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
|
Patch 5: "[v3,5/5] riscv64: defconfig: Enable BT and WLAN support for SpacemiT K3 Pico-ITX board" |
9ed823f to
a54e736
Compare
PR for series 1154107 applied to workflow__riscv__fixes
Name: Enable Bluetooth and WiFi on K3 Pico ITX
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=1154107
Version: 3