kernel/linux.git/Documentation, branch v6.1.20

usb: gadget: uvc: Make bSourceID read/write

2023-03-11T12:55:38+00:00

[ Upstream commit b3c839bd8a07d303bc59a900d55dd35c7826562c ] At the moment, the UVC function graph is hardcoded IT -> PU -> OT. To add XU support we need the ability to insert the XU descriptors into the chain. To facilitate that, make the output terminal's bSourceID attribute writeable so that we can configure its source. Signed-off-by: Daniel Scally Link: https://lore.kernel.org/r/20230206161802.892954-2-dan.scally@ideasonboard.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

mm: memcontrol: deprecate charge moving

2023-03-10T08:34:26+00:00

commit da34a8484d162585e22ed8c1e4114aa2f60e3567 upstream. Charge moving mode in cgroup1 allows memory to follow tasks as they migrate between cgroups. This is, and always has been, a questionable thing to do - for several reasons. First, it's expensive. Pages need to be identified, locked and isolated from various MM operations, and reassigned, one by one. Second, it's unreliable. Once pages are charged to a cgroup, there isn't always a clear owner task anymore. Cache isn't moved at all, for example. Mapped memory is moved - but if trylocking or isolating a page fails, it's arbitrarily left behind. Frequent moving between domains may leave a task's memory scattered all over the place. Third, it isn't really needed. Launcher tasks can kick off workload tasks directly in their target cgroup. Using dedicated per-workload groups allows fine-grained policy adjustments - no need to move tasks and their physical pages between control domains. The feature was never forward-ported to cgroup2, and it hasn't been missed. Despite it being a niche usecase, the maintenance overhead of supporting it is enormous. Because pages are moved while they are live and subject to various MM operations, the synchronization rules are complicated. There are lock_page_memcg() in MM and FS code, which non-cgroup people don't understand. In some cases we've been able to shift code and cgroup API calls around such that we can rely on native locking as much as possible. But that's fragile, and sometimes we need to hold MM locks for longer than we otherwise would (pte lock e.g.). Mark the feature deprecated. Hopefully we can remove it soon. And backport into -stable kernels so that people who develop against earlier kernels are warned about this deprecation as early as possible. [akpm@linux-foundation.org: fix memory.rst underlining] Link: https://lkml.kernel.org/r/Y5COd+qXwk/S+n8N@cmpxchg.org Signed-off-by: Johannes Weiner Acked-by: Shakeel Butt Acked-by: Hugh Dickins Acked-by: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

docs: gdbmacros: print newest record

2023-03-10T08:34:26+00:00

commit f2e4cca2f670c8e52fbb551a295f2afc9aa2bd72 upstream. @head_id points to the newest record, but the printing loop exits when it increments to this value (before printing). Exit the printing loop after the newest record has been printed. The python-based function in scripts/gdb/linux/dmesg.py already does this correctly. Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer") Cc: stable@vger.kernel.org Signed-off-by: John Ogness Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20221229134339.197627-1-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman

Documentation/hw-vuln: Document the interaction between IBRS and STIBP

2023-03-10T08:34:14+00:00

commit e02b50ca442e88122e1302d4dbc1b71a4808c13f upstream. Explain why STIBP is needed with legacy IBRS as currently implemented (KERNEL_IBRS) and why STIBP is not needed when enhanced IBRS is enabled. Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS") Signed-off-by: KP Singh Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230227060541.1939092-2-kpsingh@kernel.org Signed-off-by: Greg Kroah-Hartman

KVM: s390: disable migration mode when dirty tracking is disabled

2023-03-10T08:34:05+00:00

commit f2d3155e2a6bac44d16f04415a321e8707d895c6 upstream. Migration mode is a VM attribute which enables tracking of changes in storage attributes (PGSTE). It assumes dirty tracking is enabled on all memslots to keep a dirty bitmap of pages with changed storage attributes. When enabling migration mode, we currently check that dirty tracking is enabled for all memslots. However, userspace can disable dirty tracking without disabling migration mode. Since migration mode is pointless with dirty tracking disabled, disable migration mode whenever userspace disables dirty tracking on any slot. Also update the documentation to clarify that dirty tracking must be enabled when enabling migration mode, which is already enforced by the code in kvm_s390_vm_start_migration(). Also highlight in the documentation for KVM_S390_GET_CMMA_BITS that it can now fail with -EINVAL when dirty tracking is disabled while migration mode is on. Move all the error codes to a table so this stays readable. To disable migration mode, slots_lock should be held, which is taken in kvm_set_memory_region() and thus held in kvm_arch_prepare_memory_region(). Restructure the prepare code a bit so all the sanity checking is done before disabling migration mode. This ensures migration mode isn't disabled when some sanity check fails. Cc: stable@vger.kernel.org Fixes: 190df4a212a7 ("KVM: s390: CMMA tracking, ESSA emulation, migration mode") Signed-off-by: Nico Boehr Reviewed-by: Janosch Frank Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20230127140532.230651-2-nrb@linux.ibm.com Message-Id: <20230127140532.230651-2-nrb@linux.ibm.com> [frankja@linux.ibm.com: fixed commit message typo, moved api.rst error table upwards] Signed-off-by: Janosch Frank Signed-off-by: Greg Kroah-Hartman

docs/scripts/gdb: add necessary make scripts_gdb step

2023-03-10T08:33:58+00:00

[ Upstream commit 6b219431037bf98c9efd49716aea9b68440477a3 ] In order to debug the kernel successfully with gdb you need to run 'make scripts_gdb' nowadays. This was changed with the following commit: Commit 67274c083438340ad16c ("scripts/gdb: delay generation of gdb constants.py") In order to have a complete guide for beginners this remark should be added to the offial documentation. Signed-off-by: Jakob Koschel Link: https://lore.kernel.org/r/20230112-documentation-gdb-v2-1-292785c43dc9@gmail.com Signed-off-by: Jonathan Corbet Signed-off-by: Sasha Levin

bpf, docs: Fix modulo zero, division by zero, overflow, and underflow

2023-03-10T08:33:50+00:00

[ Upstream commit 0eb9d19e2201068260e439a5c96dc85f9f3722a2 ] Fix modulo zero, division by zero, overflow, and underflow. Also clarify how a negative immediate value is used in unsigned division. Signed-off-by: Dave Thaler Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20230124001218.827-1-dthaler1968@googlemail.com Signed-off-by: Sasha Levin

ASoC: dt-bindings: meson: fix gx-card codec node regex

2023-03-10T08:33:19+00:00

[ Upstream commit 480b26226873c88e482575ceb0d0a38d76e1be57 ] 'codec' is a valid node name when there is a single codec in the link. Fix the node regular expression to apply this. Fixes: fd00366b8e41 ("ASoC: meson: gx: add sound card dt-binding documentation") Signed-off-by: Jerome Brunet Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20230202183653.486216-3-jbrunet@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

dt-bindings: display: mediatek: Fix the fallback for mediatek,mt8186-disp-ccorr

2023-03-10T08:33:18+00:00

[ Upstream commit 137272ef1b0f17a1815fec00d583515a0163f85e ] The mt8186-disp-ccorr is not fully compatible with the mt8183-disp-ccorr implementation. It causes a crash when system resumes if it binds to the device. We should use mt8192-disp-ccorr as fallback of mt8186-disp-ccorr. Fixes: 8a26ea19d4dc ("dt-bindings: display: mediatek: add MT8186 SoC binding") Signed-off-by: Allen-KH Cheng Reviewed-by: Rob Herring Reviewed-by: Matthias Brugger Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230118091829.755-10-allen-kh.cheng@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin

hwmon: (ftsteutates) Fix scaling of measurements

2023-03-10T08:33:10+00:00

[ Upstream commit ca8fd8c16a8b77dfcf7f6ce52d2c863220693a78 ] A user complained that the ftsteutates driver was displaying bogus values since its introduction. This happens because the sensor measurements need to be scaled in order to produce meaningful results: - the fan speed needs to be multiplied by 60 since its in RPS - the temperature is in degrees celsius and needs an offset of 64 - the voltage is in 1/256 of 3.3V The offical datasheet says the voltage needs to be divided by 256, but this is likely an off-by-one-error, since even the BIOS devides by 255 (otherwise 3.3V could not be measured). The voltage channels additionally need a board-specific multiplier, however this can be done by the driver since its board-specific. The reason the missing scaling of measurements is the way Fujitsu used this driver when it was still out-of-tree. Back then, all scaling was done in userspace by libsensors, even the generic one. Tested on a Fujitsu DS3401-B1. Fixes: 08426eda58e0 ("hwmon: Add driver for FTS BMC chip "Teutates"") Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20221224041855.83981-2-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin