linux/include/uapi, branch rpi-mipi

media: pisp_be: Use clamp() and define max sizes

2025-06-23T12:07:11Z

Use the clamp() from minmax.h and provide a define for the max size as they will be used in sequent patches. Signed-off-by: Jacopo Mondi

Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y

2025-06-03T14:15:42Z

wifi: cfg80211: allow IR in 20 MHz configurations

2025-05-29T09:02:23Z

[ Upstream commit cf4bd1608882792d4742e27a819493312904a680 ] Some regulatory bodies doesn't allow IR (initiate radioation) on a specific subband, but allows it for channels with a bandwidth of 20 MHz. Add a channel flag that indicates that, and consider it in cfg80211_reg_check_beaconing. While on it, fix the kernel doc of enum nl80211_reg_rule_flags and change it to use BIT(). Signed-off-by: Anjaneyulu Co-developed-by: Somashekhar Puttagangaiah Signed-off-by: Somashekhar Puttagangaiah Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308225541.d3ab352a73ff.I8a8f79e1c9eb74936929463960ee2a324712fe51@changeid [fix typo] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

bpf: Allow pre-ordering for bpf cgroup progs

2025-05-29T09:02:17Z

[ Upstream commit 4b82b181a26cff8bf7adc3a85a88d121d92edeaf ] Currently for bpf progs in a cgroup hierarchy, the effective prog array is computed from bottom cgroup to upper cgroups (post-ordering). For example, the following cgroup hierarchy root cgroup: p1, p2 subcgroup: p3, p4 have BPF_F_ALLOW_MULTI for both cgroup levels. The effective cgroup array ordering looks like p3 p4 p1 p2 and at run time, progs will execute based on that order. But in some cases, it is desirable to have root prog executes earlier than children progs (pre-ordering). For example, - prog p1 intends to collect original pkt dest addresses. - prog p3 will modify original pkt dest addresses to a proxy address for security reason. The end result is that prog p1 gets proxy address which is not what it wants. Putting p1 to every child cgroup is not desirable either as it will duplicate itself in many child cgroups. And this is exactly a use case we are encountering in Meta. To fix this issue, let us introduce a flag BPF_F_PREORDER. If the flag is specified at attachment time, the prog has higher priority and the ordering with that flag will be from top to bottom (pre-ordering). For example, in the above example, root cgroup: p1, p2 subcgroup: p3, p4 Let us say p2 and p4 are marked with BPF_F_PREORDER. The final effective array ordering will be p2 p4 p3 p1 Suggested-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20250224230116.283071-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability

2025-05-29T09:02:04Z

[ Upstream commit 803f97298e7de9242eb677a1351dcafbbcc9117e ] PASID usage requires PASID support in both device and IOMMU. Since the iommu drivers always enable the PASID capability for the device if it is supported, this extends the IOMMU_GET_HW_INFO to report the PASID capability to userspace. Also, enhances the selftest accordingly. Link: https://patch.msgid.link/r/20250321180143.8468-5-yi.l.liu@intel.com Cc: Bjorn Helgaas Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Zhangfei Gao #aarch64 platform Tested-by: Nicolin Chen Signed-off-by: Yi Liu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y

2025-05-20T11:30:18Z

types: Complement the aligned types with signed 64-bit one

2025-05-18T06:24:56Z

[ Upstream commit e4ca0e59c39442546866f3dd514a3a5956577daf ] Some user may want to use aligned signed 64-bit type. Provide it for them. Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20240903180218.3640501-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron Stable-dep-of: 1bb942287e05 ("iio: accel: adxl355: Make timestamp 64-bit aligned using aligned_s64") Signed-off-by: Sasha Levin

Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y

2025-05-06T13:14:05Z

accel/ivpu: Fix the NPU's DPU frequency calculation

2025-05-02T05:58:56Z

[ Upstream commit 6c2b75404d33caa46a582f2791a70f92232adb71 ] Fix the frequency returned to the user space by the DRM_IVPU_PARAM_CORE_CLOCK_RATE GET_PARAM IOCTL. The kernel driver returned CPU frequency for MTL and bare PLL frequency for LNL - this was inconsistent and incorrect for both platforms. With this fix the driver returns maximum frequency of the NPU data processing unit (DPU) for all HW generations. This is what user space always expected. Also do not set CPU frequency in boot params - the firmware does not use frequency passed from the driver, it was only used by the early pre-production firmware. With that we can remove CPU frequency calculation code. Show NPU frequency in FREQ_CHANGE interrupt when frequency tracking is enabled. Fixes: 8a27ad81f7d3 ("accel/ivpu: Split IP and buttress code") Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: Andrzej Kacprowski Signed-off-by: Maciej Falkowski Reviewed-by: Jeff Hugo Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250401155912.4049340-2-maciej.falkowski@linux.intel.com Signed-off-by: Sasha Levin

Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y

2025-04-25T21:42:09Z