diff --git a/.mailmap b/.mailmap index 1f23ea6e8ce1..8079e9560748 100644 --- a/.mailmap +++ b/.mailmap @@ -66,7 +66,13 @@ Alex Hung Alex Shi Alex Shi Alex Shi +Alice Mikityanska +Alice Mikityanska +Alice Mikityanska +Alice Mikityanska +Alice Mikityanska Aloka Dixit +Alvin Šipraga Al Viro Al Viro Amit Blay @@ -165,12 +171,14 @@ Boris Brezillon Boris Brezillon Boris Brezillon Brendan Higgins +Brendan Jackman Brian Avery Brian Cain Brian Cain Brian King Brian Silverman Bryan Tan +Burak Emir Cai Huoqing Casey Connolly Casey Connolly @@ -226,6 +234,8 @@ Daniel Lezcano Daniel Lezcano Daniel Thompson Daniele Alessandrelli +Danila Tikhonov +Danila Tikhonov Danilo Krummrich David Brownell David Collins @@ -291,6 +301,7 @@ Frank Rowand Frank Rowand Frank Rowand Frank Zago +Fuad Tabba Gao Xiang Gao Xiang Gao Xiang @@ -373,6 +384,7 @@ Jarkko Sakkinen Jason Gunthorpe Jason Gunthorpe Jason Gunthorpe +Jason Wang Jason Xing Javi Merino @@ -398,6 +410,7 @@ Jens Axboe Jens Axboe Jens Axboe Jens Osterkamp +Jens Wiklander Jernej Skrabec Jesper Dangaard Brouer Jesper Dangaard Brouer @@ -530,13 +543,15 @@ Luca Ceresoli Luca Weiss Lucas De Marchi Lukasz Luba -Luo Jie +Luo Jie +Luo Jie Lance Yang Lance Yang Maciej W. Rozycki Maciej W. Rozycki Maharaja Kennadyrajan Maheshwar Ajja +Maíra Canal Malathi Gottam Manikanta Pubbisetty Manivannan Sadhasivam @@ -582,8 +597,6 @@ Mauro Carvalho Chehab Mauro Carvalho Chehab Mauro Carvalho Chehab Mauro Carvalho Chehab -Maxim Mikityanskiy -Maxim Mikityanskiy Maxime Ripard Maxime Ripard Maxime Ripard @@ -592,8 +605,8 @@ Mayuresh Janorkar Md Sadre Alam Miaoqing Pan Michael Buesch -Michal Grzeschik -Michal Grzeschik +Michael Grzeschik +Michael Grzeschik Michael Riesch Michal Simek Michel Dänzer @@ -640,8 +653,8 @@ Nicholas Piggin Nicholas Piggin Nicholas Piggin Nicholas Piggin -Nick Desaulniers Nicolas Ferre +Nico Pache Nicolas Pitre Nicolas Pitre Nicolas Saenz Julienne @@ -689,6 +702,7 @@ Paulo Alcantara Paulo Alcantara Pavankumar Kondeti Peter A Jonsson +Peter Collingbourne Peter Hilber Peter Oruba Peter Oruba @@ -707,6 +721,10 @@ Qi Zheng Quentin Monnet Quentin Monnet Quentin Perret +Radu Rendec +Radu Rendec +Radu Rendec +Radu Rendec Rae Moar Rafael J. Wysocki Rajeev Nandan @@ -811,6 +829,7 @@ Simon Wunderlich Simon Wunderlich Simon Wunderlich Simon Wunderlich +SJ Park Sricharan Ramabadhran Srinivas Kandagatla Srinivas Kandagatla @@ -820,8 +839,8 @@ Sriram Yagnaraman Stanislav Fomichev Stanislav Fomichev Stefan Wahren -Stéphane Grosjean -Stéphane Grosjean +Stéphane Grosjean +Stéphane Grosjean Stéphane Witzmann Stephen Hemminger Stephen Hemminger diff --git a/CREDITS b/CREDITS index 84793a967a0b..91c51c14e993 100644 --- a/CREDITS +++ b/CREDITS @@ -3626,6 +3626,13 @@ S: 69 rue Dunois S: 75013 Paris S: France +N: Wolfram Sang +E: wsa@kernel.org +W: sang-engineering.com +P: rsa4096/140DE4CC14A029B6 3991 B1EA B9E2 6751 A4F7 645D 140D E4CC 14A0 29B6 +D: I2C Maintainer 2012 - 2026 +S: Berlin, Germany + N: Aleksa Sarai E: cyphar@cyphar.com W: https://www.cyphar.com/ diff --git a/Documentation/ABI/testing/debugfs-vfio b/Documentation/ABI/testing/debugfs-vfio index 70ec2d454686..ed2f29c3a9b4 100644 --- a/Documentation/ABI/testing/debugfs-vfio +++ b/Documentation/ABI/testing/debugfs-vfio @@ -29,3 +29,29 @@ Date: Oct 2025 KernelVersion: 6.18 Contact: Cédric Le Goater Description: Read the migration features of the vfio device. + +What: /sys/kernel/debug/vfio//pci +Date: June 2026 +KernelVersion: 7.2 +Contact: Alex Williamson +Description: This debugfs file directory is used for debugging + VFIO PCI devices. + +What: /sys/kernel/debug/vfio//pci/nointxmask +Date: June 2026 +KernelVersion: 7.2 +Contact: Alex Williamson +Description: Read the nointxmask policy latched for this device. This + policy governs whether the device may use PCI 2.3 style + INTx masking when supported, reporting a value of "N", or + requires APIC level INTx masking, reporting a value of "Y". + +What: /sys/kernel/debug/vfio//pci/disable_idle_d3 +Date: June 2026 +KernelVersion: 7.2 +Contact: Alex Williamson +Description: Read the disable_idle_d3 policy latched for this device. This + policy governs whether the device PM runtime usage count is + kept elevated while the device is bound to the driver and + unused, reporting a value of "Y", or decremented to allow the + device to enter a low power state, reporting a value of "N". diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd index 98a8376a83d2..991765d84201 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -22,7 +22,7 @@ Description: Reading this attribute gives the state of the DbC. It can be one of the following states: disabled, enabled, - initialized, connected or configured. + initialized, connected, configured or suspended. What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor Date: March 2023 diff --git a/Documentation/ABI/testing/sysfs-class-power-bd71828 b/Documentation/ABI/testing/sysfs-class-power-bd71828 index 2d451e1c8336..f9a325e005f3 100644 --- a/Documentation/ABI/testing/sysfs-class-power-bd71828 +++ b/Documentation/ABI/testing/sysfs-class-power-bd71828 @@ -10,3 +10,4 @@ Description: 0 no adjustment of input current limit. This helps for more unusual power sources like solar modules. + ============ =========================================== diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon index b73e6bc28ea5..4fdec63a47d4 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-damon +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -1,26 +1,26 @@ what: /sys/kernel/mm/damon/ Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Interface for Data Access MONitoring (DAMON). Contains files for controlling DAMON. For more details on DAMON itself, please refer to Documentation/admin-guide/mm/damon/index.rst. What: /sys/kernel/mm/damon/admin/ Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Interface for privileged users of DAMON. Contains files for controlling DAMON that aimed to be used by privileged users. What: /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for controlling each DAMON worker thread (kdamond) named '0' to 'N-1' under the kdamonds/ directory. What: /sys/kernel/mm/damon/admin/kdamonds//state Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing 'on' or 'off' to this file makes the kdamond starts or stops, respectively. Reading the file returns the keywords based on the current status. Writing 'commit' to this file @@ -40,33 +40,33 @@ Description: Writing 'on' or 'off' to this file makes the kdamond starts or What: /sys/kernel/mm/damon/admin/kdamonds//pid Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the pid of the kdamond if it is running. What: /sys/kernel/mm/damon/admin/kdamonds//refresh_ms Date: Jul 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the time interval for automatic DAMON status file contents update. Writing '0' disables the update. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts/nr_contexts Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for controlling each DAMON context named '0' to 'N-1' under the contexts/ directory. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//avail_operations Date: Apr 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the available monitoring operations sets on the currently running kernel. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//operations Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a keyword for a monitoring operations set ('vaddr' for virtual address spaces monitoring, 'fvaddr' for fixed virtual address ranges monitoring, and 'paddr' for the physical address @@ -79,42 +79,42 @@ Description: Writing a keyword for a monitoring operations set ('vaddr' for What: /sys/kernel/mm/damon/admin/kdamonds//contexts//addr_unit Date: Aug 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing an integer to this file sets the 'address unit' parameter of the given operations set of the context. Reading the file returns the last-written 'address unit' value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//pause Date: Mar 2026 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a boolean keyword to this file sets the 'pause' request parameter for the context. Reading the file returns the last-written 'pause' value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/sample_us Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the sampling interval of the DAMON context in microseconds as the value. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/aggr_us Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the aggregation interval of the DAMON context in microseconds as the value. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/update_us Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the update interval of the DAMON context in microseconds as the value. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/intrvals_goal/access_bp Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the monitoring intervals auto-tuning target DAMON-observed access events ratio within the given time interval (aggrs in same directory), in bp @@ -122,7 +122,7 @@ Description: Writing a value to this file sets the monitoring intervals What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/intrvals_goal/aggrs Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the time interval to achieve the monitoring intervals auto-tuning target DAMON-observed access events ratio (access_bp in same directory) within. @@ -130,14 +130,14 @@ Description: Writing a value to this file sets the time interval to achieve What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/intrvals_goal/min_sample_us Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the minimum value of auto-tuned sampling interval in microseconds. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/intrvals_goal/max_sample_us Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the maximum value of auto-tuned sampling interval in microseconds. Reading this file returns the value. @@ -145,42 +145,42 @@ Description: Writing a value to this file sets the maximum value of What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/nr_regions/min WDate: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the minimum number of monitoring regions of the DAMON context as the value. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/nr_regions/max Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the maximum number of monitoring regions of the DAMON context as the value. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets/nr_targets Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for controlling each DAMON target of the context named '0' to 'N-1' under the contexts/ directory. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//pid_target Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the pid of the target process if the context is for virtual address spaces monitoring, respectively. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//obsolete_target Date: Oct 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the obsoleteness of the matching parameters commit destination target. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//regions/nr_regions Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for setting each DAMON target memory region of the context named '0' to 'N-1' under the regions/ directory. In @@ -190,181 +190,181 @@ Description: Writing a number 'N' to this file creates the number of What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//regions//start Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the start address of the monitoring region. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//regions//end Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the end address of the monitoring region. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes/nr_schemes Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for controlling each DAMON-based operation scheme of the context named '0' to 'N-1' under the schemes/ directory. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//action Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the action of the scheme. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//target_nid Date: Jun 2024 -Contact: SeongJae Park +Contact: SJ Park Description: Action's target NUMA node id. Supported by only relevant actions. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//apply_interval_us Date: Sep 2023 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a value to this file sets the action apply interval of the scheme in microseconds. Reading this file returns the value. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/sz/min Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the minimum size of the scheme's target regions in bytes. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/sz/max Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the maximum size of the scheme's target regions in bytes. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/nr_accesses/min Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the manimum 'nr_accesses' of the scheme's target regions. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/nr_accesses/max Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the maximum 'nr_accesses' of the scheme's target regions. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/age/min Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the minimum 'age' of the scheme's target regions. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/age/max Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the maximum 'age' of the scheme's target regions. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/ms Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the time quota of the scheme in milliseconds. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/bytes Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the size quota of the scheme in bytes. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/effective_bytes Date: Feb 2024 -Contact: SeongJae Park +Contact: SJ Park Description: Reading from this file gets the effective size quota of the scheme in bytes, which adjusted for the time quota and goals. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/reset_interval_ms Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the quotas charge reset interval of the scheme in milliseconds. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/goals/nr_goals Date: Nov 2023 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for setting automatic tuning of the scheme's aggressiveness named '0' to 'N-1' under the goals/ directory. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/goals//target_metric Date: Feb 2024 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the quota auto-tuning goal metric. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/goals//target_value Date: Nov 2023 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the target value of the goal metric. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/goals//current_value Date: Nov 2023 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the current value of the goal metric. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/goals//nid Date: Apr 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the nid parameter of the goal. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/goals//path Date: Oct 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the path parameter of the goal. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/goal_tuner Date: Mar 2026 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the goal-based effective quota auto-tuning algorithm to use. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/fail_charge_num Date: Mar 2026 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the action-failed memory quota charging ratio numerator. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/fail_charge_denom Date: Mar 2026 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the action-failed memory quota charging ratio denominator. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/weights/sz_permil Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the under-quota limit regions prioritization weight for 'size' in permil. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/weights/nr_accesses_permil Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the under-quota limit regions prioritization weight for 'nr_accesses' in permil. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/weights/age_permil Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the under-quota limit regions prioritization weight for 'age' in permil. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/metric Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the metric of the watermarks for the scheme. The writable/readable keywords for this file are 'none' for disabling the watermarks @@ -373,44 +373,44 @@ Description: Writing to and reading from this file sets and gets the metric What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/interval_us Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the metric check interval of the watermarks for the scheme in microseconds. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/high Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the high watermark of the scheme in permil. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/mid Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the mid watermark of the scheme in permil. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/low Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the low watermark of the scheme in permil. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Directory for DAMON core layer-handled DAMOS filters. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters/nr_filters Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for setting filters of the scheme named '0' to 'N-1' under the core_filters/ directory. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//type Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the type of the memory of the interest. 'anon' for anonymous pages, 'memcg' for specific memory cgroup, 'young' for young pages, @@ -419,62 +419,62 @@ Description: Writing to and reading from this file sets and gets the type of What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//memcg_path Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: If 'memcg' is written to the 'type' file, writing to and reading from this file sets and gets the path to the memory cgroup of the interest. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//addr_start Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: If 'addr' is written to the 'type' file, writing to or reading from this file sets or gets the start address of the address range for the filter. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//addr_end Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: If 'addr' is written to the 'type' file, writing to or reading from this file sets or gets the end address of the address range for the filter. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//min Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: If 'hugepage_size' is written to the 'type' file, writing to or reading from this file sets or gets the minimum size of the hugepage for the filter. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//max Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: If 'hugepage_size' is written to the 'type' file, writing to or reading from this file sets or gets the maximum size of the hugepage for the filter. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//damon_target_idx Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: If 'target' is written to the 'type' file, writing to or reading from this file sets or gets the index of the DAMON monitoring target of the interest. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//matching Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing 'Y' or 'N' to this file sets whether the filter is for the memory of the 'type', or all except the 'type'. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters//allow Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing 'Y' or 'N' to this file sets whether to allow or reject applying the scheme's action to the memory that satisfies the 'type' and the 'matching' of the directory. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//ops_filters Date: Feb 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Directory for DAMON operations set layer-handled DAMOS filters. Files under this directory works same to those of /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//core_filters @@ -482,7 +482,7 @@ Description: Directory for DAMON operations set layer-handled DAMOS filters. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//filters Date: Dec 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Directory for DAMOS filters. Files under this directory works same to those of /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//{core,ops}_filters @@ -491,14 +491,14 @@ Description: Directory for DAMOS filters. Files under this directory works What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//dests/nr_dests Date: Jul 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number 'N' to this file creates the number of directories for setting action destinations of the scheme named '0' to 'N-1' under the dests/ directory. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//dests//id Date: Jul 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the id of the DAMOS action destination. For DAMOS_MIGRATE_{HOT,COLD} actions, the destination node's node id can be written and @@ -506,98 +506,98 @@ Description: Writing to and reading from this file sets and gets the id of What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//dests//weight Date: Jul 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing to and reading from this file sets and gets the weight of the DAMOS action destination to select as the destination of each action among the destinations. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/nr_tried Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the number of regions that the action of the scheme has tried to be applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/sz_tried Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the total size of regions that the action of the scheme has tried to be applied in bytes. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/nr_applied Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the number of regions that the action of the scheme has successfully applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/sz_applied Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the total size of regions that the action of the scheme has successfully applied in bytes. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/sz_ops_filter_passed Date: Dec 2024 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the total size of memory that passed DAMON operations layer-handled filters of the scheme in bytes. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/qt_exceeds Date: Mar 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the number of the exceed events of the scheme's quotas. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/nr_snapshots Date: Dec 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the total number of DAMON snapshots that the scheme has tried to be applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/max_nr_snapshots Date: Dec 2025 -Contact: SeongJae Park +Contact: SJ Park Description: Writing a number to this file sets the upper limit of nr_snapshots that deactivates the scheme when the limit is reached or exceeded. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//tried_regions/total_bytes Date: Jul 2023 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the total amount of memory that corresponding DAMON-based Operation Scheme's action has tried to be applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//tried_regions//start Date: Oct 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the start address of a memory region that corresponding DAMON-based Operation Scheme's action has tried to be applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//tried_regions//end Date: Oct 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the end address of a memory region that corresponding DAMON-based Operation Scheme's action has tried to be applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//tried_regions//nr_accesses Date: Oct 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the 'nr_accesses' of a memory region that corresponding DAMON-based Operation Scheme's action has tried to be applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//tried_regions//age Date: Oct 2022 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the 'age' of a memory region that corresponding DAMON-based Operation Scheme's action has tried to be applied. What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//tried_regions//sz_filter_passed Date: Dec 2024 -Contact: SeongJae Park +Contact: SJ Park Description: Reading this file returns the size of the memory in the region that passed DAMON operations layer-handled filters of the scheme in bytes. diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index f4d2662871ab..be35e9a1ee75 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -338,7 +338,7 @@ the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always specify PCI_IRQ_INTX as well. Drivers that have different interrupt handlers for MSI/MSI-X and -legacy INTx should chose the right one based on the msi_enabled +legacy INTx should choose the right one based on the msi_enabled and msix_enabled flags in the pci_dev structure after calling pci_alloc_irq_vectors. diff --git a/Documentation/PCI/pciebus-howto.rst b/Documentation/PCI/pciebus-howto.rst index 375d9ce171f6..9cc133ccdeec 100644 --- a/Documentation/PCI/pciebus-howto.rst +++ b/Documentation/PCI/pciebus-howto.rst @@ -97,7 +97,7 @@ register its service with the PCI Express Port Bus driver (see section 5.2.1 & 5.2.2). It is important that a service driver initializes the pcie_port_service_driver data structure, included in header file /include/linux/pcieport_if.h, before calling these APIs. -Failure to do so will result an identity mismatch, which prevents +Failure to do so will result in an identity mismatch, which prevents the PCI Express Port Bus driver from loading a service driver. pcie_port_service_register diff --git a/Documentation/admin-guide/cgroup-v1/rdma.rst b/Documentation/admin-guide/cgroup-v1/rdma.rst index e69369b7252e..abddf34d2667 100644 --- a/Documentation/admin-guide/cgroup-v1/rdma.rst +++ b/Documentation/admin-guide/cgroup-v1/rdma.rst @@ -9,6 +9,7 @@ RDMA Controller 1-2. Why RDMA controller needed? 1-3. How is RDMA controller implemented? 2. Usage Examples + 3. RDMA Interface Files 1. Overview =========== @@ -115,3 +116,68 @@ Following resources can be accounted by rdma controller. (d) Delete resource limit:: echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max + +3. RDMA Interface Files +======================== + +The following interface files are available in each non-root RDMA cgroup. + + rdma.max + A read-write file which describes the configured resource limit + for an RDMA/IB device. See the Usage Examples above. + + rdma.current + A read-only file which describes the current resource usage. + + rdma.peak + A read-only nested-keyed file which shows the historical high + watermark of resource usage per device since the cgroup was created. + + An example for mlx4 and ocrdma device follows:: + + mlx4_0 hca_handle=1 hca_object=20 + ocrdma1 hca_handle=0 hca_object=23 + + rdma.events + A read-only nested-keyed file which exists on non-root cgroups + and contains the following keys: + + max + The number of times a process in this cgroup or its + descendants attempted an RDMA resource allocation that + was rejected because a rdma.max limit in the subtree + was reached. This is a hierarchical counter propagated + upward to all ancestor cgroups. A value change in this + file generates a file modified event. + + alloc_fail + The number of RDMA resource allocation attempts that + originated in this cgroup or its descendants and failed + due to a rdma.max limit being reached. This is a + hierarchical counter propagated upward. + + An example for mlx4 device follows:: + + mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=3 hca_object.max=0 hca_object.alloc_fail=0 + + rdma.events.local + Similar to rdma.events but the fields are local to the cgroup, + i.e. not hierarchical. The file modified event generated on this + file reflects only the local events. + + The following nested keys are defined. + + max + The number of times a process in this cgroup or its + descendants attempted an RDMA resource allocation that + was rejected because this cgroup's own rdma.max limit + was reached. + + alloc_fail + The number of RDMA resource allocation attempts + originating from this cgroup that failed due to this + cgroup's or an ancestor's rdma.max limit. + + An example for mlx4 device follows:: + + mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=0 hca_object.max=0 hca_object.alloc_fail=0 diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 993446ab66d0..aed195a71cbf 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1570,7 +1570,7 @@ The following nested keys are defined. sock (npn) Amount of memory used in network transmission buffers - vmalloc (npn) + vmalloc Amount of memory used for vmap backed memory. shmem @@ -1735,7 +1735,7 @@ The following nested keys are defined. Number of pages written from zswap to swap. zswap_incomp - Number of incompressible pages currently stored in zswap + Amount of memory used by incompressible pages currently stored in zswap without compression. These pages could not be compressed to a size smaller than PAGE_SIZE, so they are stored as-is. @@ -2239,9 +2239,12 @@ IO Latency ~~~~~~~~~~ This is a cgroup v2 controller for IO workload protection. You provide a group -with a latency target, and if the average latency exceeds that target the -controller will throttle any peers that have a lower latency target than the -protected workload. +with a latency target, and if the group misses its target the controller will +throttle any peers that have a lower latency target than the protected +workload. How a miss is detected depends on the device: on rotational devices +the average latency over the window must exceed the target, while on +non-rotational devices a miss is counted once enough of the IOs in the window +individually exceed the target. The limits are only applied at the peer level in the hierarchy. This means that in the diagram below, only groups A, B, and C will influence each other, and @@ -2257,10 +2260,13 @@ groups D and F will influence each other. Group G will influence nobody:: So the ideal way to configure this is to set io.latency in groups A, B, and C. Generally you do not want to set a value lower than the latency your device supports. Experiment to find the value that works best for your workload. -Start at higher than the expected latency for your device and watch the -avg_lat value in io.stat for your workload group to get an idea of the -latency you see during normal operation. Use the avg_lat value as a basis for -your real setting, setting at 10-15% higher than the value in io.stat. +Start at higher than the expected latency for your device and, with +blkcg_debug_stats enabled, observe io.stat for your workload group to get an +idea of the latency you see during normal operation. On rotational devices, +use the avg_lat value as a basis for your real setting, setting it 10-15% +higher. On non-rotational devices io.stat reports no average latency; set +the target based on your device and use the missed/total fields to verify it +is being met. How IO Latency Throttling Works ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2298,21 +2304,40 @@ IO Latency Interface Files io.stat If the controller is enabled you will see extra stats in io.stat in - addition to the normal ones. + addition to the normal ones. These debug stats are only emitted when + the blkcg_debug_stats module parameter is enabled (it is disabled by + default). + + The reported latency fields depend on the device. Rotational devices + report avg_lat and win; non-rotational devices report missed and total + instead. missed and total are live counters for the current window and + may change between reads. depth This is the current queue depth for the group. avg_lat - This is an exponential moving average with a decay rate of 1/exp - bound by the sampling interval. The decay rate interval can be - calculated by multiplying the win value in io.stat by the - corresponding number of samples based on the win value. + (Rotational devices only.) This is an exponential moving + average with a decay rate of 1/exp bound by the sampling + interval. The decay rate interval can be calculated by + multiplying the win value in io.stat by the corresponding number + of samples based on the win value. win - The sampling window size in milliseconds. This is the minimum - duration of time between evaluation events. Windows only elapse - with IO activity. Idle periods extend the most recent window. + (Rotational devices only.) The sampling window size in + milliseconds. This is the minimum duration of time between + evaluation events. Windows only elapse with IO activity. Idle + periods extend the most recent window. + + missed + (Non-rotational devices only.) The number of IOs in the + current window whose latency exceeded the target. A group is + considered to be missing its target once missed reaches a + certain ratio of total. + + total + (Non-rotational devices only.) The total number of IOs + accounted in the current window. IO Priority ~~~~~~~~~~~ @@ -2934,7 +2959,8 @@ include/linux/misc_cgroup.h. Misc Interface Files ~~~~~~~~~~~~~~~~~~~~ -Miscellaneous controller provides 3 interface files. If two misc resources (res_a and res_b) are registered then: +Miscellaneous controller provides the following interface files. If two misc +resources (res_a and res_b) are registered then: misc.capacity A read-only flat-keyed file shown only in the root cgroup. It shows diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst index 8fb438bf7781..7c3379b704aa 100644 --- a/Documentation/arch/arm64/cpu-hotplug.rst +++ b/Documentation/arch/arm64/cpu-hotplug.rst @@ -47,11 +47,12 @@ ever have can be described at boot. There are no power-domain considerations as such devices are emulated. CPU Hotplug on virtual systems is supported. It is distinct from physical -CPU Hotplug as all resources are described as ``present``, but CPUs may be -marked as disabled by firmware. Only the CPU's online/offline behaviour is -influenced by firmware. An example is where a virtual machine boots with a -single CPU, and additional CPUs are added once a cloud orchestrator deploys -the workload. +CPU Hotplug as all vCPU resources are statically described in the firmware +configuration tables (e.g. MADT), meaning their maximum possible count is +known at boot. However, vCPUs that are not enabled at boot are not marked +as ``present`` by the kernel until they are hotplugged. An example is where +a virtual machine boots with a single CPU, and additional CPUs are added +once a cloud orchestrator deploys the workload. For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware. @@ -60,16 +61,19 @@ brought online. Firmware can enforce its policy via PSCI's return codes. e.g. ``DENIED``. The ACPI tables must describe all the resources of the virtual machine. CPUs -that firmware wishes to disable either from boot (or later) should not be -``enabled`` in the MADT GICC structures, but should have the ``online capable`` -bit set, to indicate they can be enabled later. The boot CPU must be marked as -``enabled``. The 'always on' GICR structure must be used to describe the -redistributors. +that are hot-pluggable must have the ``online capable`` bit set and the +``enabled`` bit cleared in the MADT GICC structures to indicate they can be +enabled later. The boot CPU must be marked as ``enabled`` with its +``online capable`` bit cleared. The 'always on' GICR structure must be used +to describe the redistributors. CPUs described as ``online capable`` but not ``enabled`` can be set to enabled by the DSDT's Processor object's _STA method. On virtual systems the _STA method -must always report the CPU as ``present``. Changes to the firmware policy can -be notified to the OS via device-check or eject-request. +must always set the ``ACPI_STA_DEVICE_PRESENT`` bit, while toggling the +``ACPI_STA_DEVICE_ENABLED`` bit to reflect its plug status. The kernel will +then dynamically mark the vCPU as ``present`` within the OS when the +``ACPI_STA_DEVICE_ENABLED`` bit becomes set during hot-add. Changes to the +firmware policy can be notified to the OS via device-check or eject-request. CPUs described as ``enabled`` in the static table, should not have their _STA modified dynamically by firmware. Soft-restart features such as kexec will diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index 014aa1c215a1..88b4aa45a206 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -55,10 +55,14 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 | +----------------+-----------------+-----------------+-----------------------------+ +| Ampere | AmpereOne | AC03_CPU_57 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ | Ampere | AmpereOne AC04 | AC04_CPU_10 | AMPERE_ERRATUM_AC03_CPU_38 | +----------------+-----------------+-----------------+-----------------------------+ | Ampere | AmpereOne AC04 | AC04_CPU_23 | AMPERE_ERRATUM_AC04_CPU_23 | +----------------+-----------------+-----------------+-----------------------------+ +| Ampere | AmpereOne AC04 | AC04_CPU_29 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 | +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst index c420a8349bc6..d9928641deb9 100644 --- a/Documentation/arch/riscv/hwprobe.rst +++ b/Documentation/arch/riscv/hwprobe.rst @@ -82,121 +82,121 @@ The following keys are defined: version 1.0 of the RISC-V Vector extension manual. * :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is - supported, as defined in version 1.0 of the Bit-Manipulation ISA - extensions. + supported, as defined in version 1.0 of the Bit-Manipulation ISA + extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined - in version 1.0 of the Bit-Manipulation ISA extensions. + in version 1.0 of the Bit-Manipulation ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined - in version 1.0 of the Bit-Manipulation ISA extensions. + in version 1.0 of the Bit-Manipulation ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as - ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. * :c:macro:`RISCV_HWPROBE_EXT_ZBC` The Zbc extension is supported, as defined - in version 1.0 of the Bit-Manipulation ISA extensions. + in version 1.0 of the Bit-Manipulation ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZBKB` The Zbkb extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZBKC` The Zbkc extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZBKX` The Zbkx extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZKND` The Zknd extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZKNE` The Zkne extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZKNH` The Zknh extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZKSED` The Zksed extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZKSH` The Zksh extension is supported, as - defined in version 1.0 of the Scalar Crypto ISA extensions. + defined in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZKT` The Zkt extension is supported, as defined - in version 1.0 of the Scalar Crypto ISA extensions. + in version 1.0 of the Scalar Crypto ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZVBB`: The Zvbb extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVBC`: The Zvbc extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKB`: The Zvkb extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKG`: The Zvkg extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKNED`: The Zvkned extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKNHA`: The Zvknha extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKNHB`: The Zvknhb extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKSED`: The Zvksed extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKSH`: The Zvksh extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZVKT`: The Zvkt extension is supported as - defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. + defined in version 1.0 of the RISC-V Cryptography Extensions Volume II. * :c:macro:`RISCV_HWPROBE_EXT_ZFH`: The Zfh extension version 1.0 is supported - as defined in the RISC-V ISA manual. + as defined in the RISC-V ISA manual. * :c:macro:`RISCV_HWPROBE_EXT_ZFHMIN`: The Zfhmin extension version 1.0 is - supported as defined in the RISC-V ISA manual. + supported as defined in the RISC-V ISA manual. * :c:macro:`RISCV_HWPROBE_EXT_ZIHINTNTL`: The Zihintntl extension version 1.0 - is supported as defined in the RISC-V ISA manual. + is supported as defined in the RISC-V ISA manual. * :c:macro:`RISCV_HWPROBE_EXT_ZVFH`: The Zvfh extension is supported as - defined in the RISC-V Vector manual starting from commit e2ccd0548d6c - ("Remove draft warnings from Zvfh[min]"). + defined in the RISC-V Vector manual starting from commit e2ccd0548d6c + ("Remove draft warnings from Zvfh[min]"). * :c:macro:`RISCV_HWPROBE_EXT_ZVFHMIN`: The Zvfhmin extension is supported as - defined in the RISC-V Vector manual starting from commit e2ccd0548d6c - ("Remove draft warnings from Zvfh[min]"). + defined in the RISC-V Vector manual starting from commit e2ccd0548d6c + ("Remove draft warnings from Zvfh[min]"). * :c:macro:`RISCV_HWPROBE_EXT_ZFA`: The Zfa extension is supported as - defined in the RISC-V ISA manual starting from commit 056b6ff467c7 - ("Zfa is ratified"). + defined in the RISC-V ISA manual starting from commit 056b6ff467c7 + ("Zfa is ratified"). * :c:macro:`RISCV_HWPROBE_EXT_ZTSO`: The Ztso extension is supported as - defined in the RISC-V ISA manual starting from commit 5618fb5a216b - ("Ztso is now ratified.") + defined in the RISC-V ISA manual starting from commit 5618fb5a216b + ("Ztso is now ratified.") * :c:macro:`RISCV_HWPROBE_EXT_ZACAS`: The Zacas extension is supported as - defined in the Atomic Compare-and-Swap (CAS) instructions manual starting - from commit 5059e0ca641c ("update to ratified"). + defined in the Atomic Compare-and-Swap (CAS) instructions manual starting + from commit 5059e0ca641c ("update to ratified"). * :c:macro:`RISCV_HWPROBE_EXT_ZICNTR`: The Zicntr extension version 2.0 - is supported as defined in the RISC-V ISA manual. + is supported as defined in the RISC-V ISA manual. * :c:macro:`RISCV_HWPROBE_EXT_ZICOND`: The Zicond extension is supported as - defined in the RISC-V Integer Conditional (Zicond) operations extension - manual starting from commit 95cf1f9 ("Add changes requested by Ved - during signoff") + defined in the RISC-V Integer Conditional (Zicond) operations extension + manual starting from commit 95cf1f9 ("Add changes requested by Ved + during signoff") * :c:macro:`RISCV_HWPROBE_EXT_ZIHINTPAUSE`: The Zihintpause extension is - supported as defined in the RISC-V ISA manual starting from commit - d8ab5c78c207 ("Zihintpause is ratified"). + supported as defined in the RISC-V ISA manual starting from commit + d8ab5c78c207 ("Zihintpause is ratified"). * :c:macro:`RISCV_HWPROBE_EXT_ZIHPM`: The Zihpm extension version 2.0 - is supported as defined in the RISC-V ISA manual. + is supported as defined in the RISC-V ISA manual. * :c:macro:`RISCV_HWPROBE_EXT_ZVE32X`: The Vector sub-extension Zve32x is supported, as defined by version 1.0 of the RISC-V Vector extension manual. @@ -214,84 +214,89 @@ The following keys are defined: supported, as defined by version 1.0 of the RISC-V Vector extension manual. * :c:macro:`RISCV_HWPROBE_EXT_ZIMOP`: The Zimop May-Be-Operations extension is - supported as defined in the RISC-V ISA manual starting from commit - 58220614a5f ("Zimop is ratified/1.0"). + supported as defined in the RISC-V ISA manual starting from commit + 58220614a5f ("Zimop is ratified/1.0"). * :c:macro:`RISCV_HWPROBE_EXT_ZCA`: The Zca extension part of Zc* standard - extensions for code size reduction, as ratified in commit 8be3419c1c0 - ("Zcf doesn't exist on RV64 as it contains no instructions") of - riscv-code-size-reduction. + extensions for code size reduction, as ratified in commit 8be3419c1c0 + ("Zcf doesn't exist on RV64 as it contains no instructions") of + riscv-code-size-reduction. * :c:macro:`RISCV_HWPROBE_EXT_ZCB`: The Zcb extension part of Zc* standard - extensions for code size reduction, as ratified in commit 8be3419c1c0 - ("Zcf doesn't exist on RV64 as it contains no instructions") of - riscv-code-size-reduction. + extensions for code size reduction, as ratified in commit 8be3419c1c0 + ("Zcf doesn't exist on RV64 as it contains no instructions") of + riscv-code-size-reduction. * :c:macro:`RISCV_HWPROBE_EXT_ZCD`: The Zcd extension part of Zc* standard - extensions for code size reduction, as ratified in commit 8be3419c1c0 - ("Zcf doesn't exist on RV64 as it contains no instructions") of - riscv-code-size-reduction. + extensions for code size reduction, as ratified in commit 8be3419c1c0 + ("Zcf doesn't exist on RV64 as it contains no instructions") of + riscv-code-size-reduction. * :c:macro:`RISCV_HWPROBE_EXT_ZCF`: The Zcf extension part of Zc* standard - extensions for code size reduction, as ratified in commit 8be3419c1c0 - ("Zcf doesn't exist on RV64 as it contains no instructions") of - riscv-code-size-reduction. + extensions for code size reduction, as ratified in commit 8be3419c1c0 + ("Zcf doesn't exist on RV64 as it contains no instructions") of + riscv-code-size-reduction. * :c:macro:`RISCV_HWPROBE_EXT_ZCMOP`: The Zcmop May-Be-Operations extension is - supported as defined in the RISC-V ISA manual starting from commit - c732a4f39a4 ("Zcmop is ratified/1.0"). + supported as defined in the RISC-V ISA manual starting from commit + c732a4f39a4 ("Zcmop is ratified/1.0"). * :c:macro:`RISCV_HWPROBE_EXT_ZAWRS`: The Zawrs extension is supported as - ratified in commit 98918c844281 ("Merge pull request #1217 from - riscv/zawrs") of riscv-isa-manual. + ratified in commit 98918c844281 ("Merge pull request #1217 from + riscv/zawrs") of riscv-isa-manual. * :c:macro:`RISCV_HWPROBE_EXT_ZAAMO`: The Zaamo extension is supported as - defined in the in the RISC-V ISA manual starting from commit e87412e621f1 - ("integrate Zaamo and Zalrsc text (#1304)"). + defined in the in the RISC-V ISA manual starting from commit e87412e621f1 + ("integrate Zaamo and Zalrsc text (#1304)"). * :c:macro:`RISCV_HWPROBE_EXT_ZALASR`: The Zalasr extension is supported as - frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr. + frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr. * :c:macro:`RISCV_HWPROBE_EXT_ZALRSC`: The Zalrsc extension is supported as - defined in the in the RISC-V ISA manual starting from commit e87412e621f1 - ("integrate Zaamo and Zalrsc text (#1304)"). + defined in the in the RISC-V ISA manual starting from commit e87412e621f1 + ("integrate Zaamo and Zalrsc text (#1304)"). * :c:macro:`RISCV_HWPROBE_EXT_SUPM`: The Supm extension is supported as - defined in version 1.0 of the RISC-V Pointer Masking extensions. + defined in version 1.0 of the RISC-V Pointer Masking extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZFBFMIN`: The Zfbfmin extension is supported as - defined in the RISC-V ISA manual starting from commit 4dc23d6229de - ("Added Chapter title to BF16"). + defined in the RISC-V ISA manual starting from commit 4dc23d6229de + ("Added Chapter title to BF16"). * :c:macro:`RISCV_HWPROBE_EXT_ZVFBFMIN`: The Zvfbfmin extension is supported as - defined in the RISC-V ISA manual starting from commit 4dc23d6229de - ("Added Chapter title to BF16"). + defined in the RISC-V ISA manual starting from commit 4dc23d6229de + ("Added Chapter title to BF16"). * :c:macro:`RISCV_HWPROBE_EXT_ZVFBFWMA`: The Zvfbfwma extension is supported as - defined in the RISC-V ISA manual starting from commit 4dc23d6229de - ("Added Chapter title to BF16"). + defined in the RISC-V ISA manual starting from commit 4dc23d6229de + ("Added Chapter title to BF16"). * :c:macro:`RISCV_HWPROBE_EXT_ZICBOM`: The Zicbom extension is supported, as - ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. * :c:macro:`RISCV_HWPROBE_EXT_ZABHA`: The Zabha extension is supported as - ratified in commit 49f49c842ff9 ("Update to Rafified state") of - riscv-zabha. + ratified in commit 49f49c842ff9 ("Update to Rafified state") of + riscv-zabha. * :c:macro:`RISCV_HWPROBE_EXT_ZICBOP`: The Zicbop extension is supported, as - ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. * :c:macro:`RISCV_HWPROBE_EXT_ZILSD`: The Zilsd extension is supported as - defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating - load/store pair for RV32 with the main manual") of the riscv-isa-manual. + defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating + load/store pair for RV32 with the main manual") of the riscv-isa-manual. * :c:macro:`RISCV_HWPROBE_EXT_ZCLSD`: The Zclsd extension is supported as - defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating - load/store pair for RV32 with the main manual") of the riscv-isa-manual. + defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating + load/store pair for RV32 with the main manual") of the riscv-isa-manual. + + * :c:macro:`RISCV_HWPROBE_EXT_ZICFILP`: The Zicfilp extension is supported, + as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI) + extensions specification, ratified in commit 302a2d45c243 + ("Update build-pdf.yml") of riscv-cfi. * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to - :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was - mistakenly classified as a bitmask rather than a value. + :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was + mistakenly classified as a bitmask rather than a value. * :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`: An enum value describing the performance of misaligned scalar native word accesses on the selected set @@ -326,7 +331,7 @@ The following keys are defined: * :c:macro:`RISCV_HWPROBE_KEY_TIME_CSR_FREQ`: Frequency (in Hz) of `time CSR`. * :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`: An enum value describing the - performance of misaligned vector accesses on the selected set of processors. + performance of misaligned vector accesses on the selected set of processors. * :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_UNKNOWN`: The performance of misaligned vector accesses is unknown. @@ -348,7 +353,7 @@ The following keys are defined: * MIPS * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XMIPSEXECTL`: The xmipsexectl vendor - extension is supported in the MIPS ISA extensions spec. + extension is supported in the MIPS ISA extensions spec. * :c:macro:`RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0`: A bitmask containing the thead vendor extensions that are compatible with the @@ -357,8 +362,8 @@ The following keys are defined: * T-HEAD * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XTHEADVECTOR`: The xtheadvector vendor - extension is supported in the T-Head ISA extensions spec starting from - commit a18c801634 ("Add T-Head VECTOR vendor extension. "). + extension is supported in the T-Head ISA extensions spec starting from + commit a18c801634 ("Add T-Head VECTOR vendor extension. "). * :c:macro:`RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE`: An unsigned int which represents the size of the Zicbom block in bytes. @@ -370,20 +375,20 @@ The following keys are defined: * SIFIVE * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD`: The Xsfqmaccdod vendor - extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication - Extensions Specification. + extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication + Extensions Specification. * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ`: The Xsfqmaccqoq vendor - extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication - Instruction Extensions Specification. + extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication + Instruction Extensions Specification. * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFNRCLIPXFQF`: The Xsfvfnrclipxfqf - vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged - Clip Instructions Extensions Specification. + vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged + Clip Instructions Extensions Specification. * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ`: The Xsfvfwmaccqqq - vendor extension is supported in version 1.0 of Matrix Multiply Accumulate - Instruction Extensions Specification. + vendor extension is supported in version 1.0 of Matrix Multiply Accumulate + Instruction Extensions Specification. * :c:macro:`RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE`: An unsigned int which represents the size of the Zicbop block in bytes. @@ -391,3 +396,8 @@ The following keys are defined: * :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_1`: A bitmask containing additional extensions that are compatible with the :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior. + + * :c:macro:`RISCV_HWPROBE_EXT_ZICFISS`: The Zicfiss extension is supported, + as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI) + extensions specification, ratified in commit 302a2d45c243 + ("Update build-pdf.yml") of riscv-cfi. diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index 45bc5c5cd793..edf8107a7beb 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -479,7 +479,10 @@ for details. To maximize the number of tests passing, the .config of the kernel under test should match the config file fragment in -tools/testing/selftests/bpf as closely as possible. +tools/testing/selftests/bpf as closely as possible. If not possible, +however, you can set ``BPF_STRICT_BUILD=0`` when invoking ``make`` +to tolerate individual compilation failures and continue building +the remaining tests rather than treating each failure as fatal. Finally to ensure support for latest BPF Type Format features - discussed in Documentation/bpf/btf.rst - pahole version 1.16 diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index 0d5c6f659266..638a00d42bc2 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -28,6 +28,7 @@ that goes into great technical depth about the BPF Architecture. classic_vs_extended.rst bpf_iterators bpf_licensing + signing test_debug clang-notes linux-notes diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst index 4c814ff6061e..1004eb0bec61 100644 --- a/Documentation/bpf/kfuncs.rst +++ b/Documentation/bpf/kfuncs.rst @@ -250,6 +250,71 @@ Or:: ... } +2.3.7 __const_map and __map Annotations +--------------------------------------- + +These annotations are used for ``struct bpf_map *`` arguments and distinguish a +verifier-known map from an opaque one. + +``__const_map`` indicates a map must be known at the verification time, i.e. a +concrete map fd the BPF program references directly. + +An example is given below:: + + __bpf_kfunc int bpf_wq_init(struct bpf_wq *wq, void *p__const_map, + unsigned int flags) + { + ... + } + +``__map`` indicates an opaque ``struct bpf_map *`` that may be resolved +at run time. The argument may take either a map fd or a ``PTR_TO_BTF_ID`` +``struct bpf_map`` pointer. + +An example is given below:: + + __bpf_kfunc void *bpf_arena_alloc_pages(void *p__map, ...) + { + ... + } + +2.3.8 __arena and __arena__nullable Annotations +----------------------------------------------- + +Both annotations indicate that the pointer argument points into the +calling program's arena. The JIT rebases the value at the call site so +the kfunc receives a directly dereferenceable kernel address, subject to +the access rules described in :ref:`BPF_kfunc_arena_access` (at most +``GUARD_SZ / 2``, 32 KiB, past the pointer in a single unchecked access). + +With ``__arena`` the rebase is unconditional and the argument is never +NULL: a value whose lower 32 bits are zero arrives as the arena base +address (arena offset 0). The kfunc must not check the argument for NULL. +With ``__arena__nullable`` such a value arrives as NULL instead and the +kfunc must check before dereferencing. + +An example is given below:: + + __bpf_kfunc int bpf_process_item(struct item *item__arena) + { + ... + } + +Calling such a kfunc requires the program to use an arena map and a JIT with +arena argument support (currently x86-64); verification fails otherwise. The +program can pass any value without compromising the kernel. A value that does +not point into the arena is a program bug. + +The suffixes have the same meaning on the arguments of struct_ops stub +functions, with the conversion running in the opposite direction. The +kernel caller passes the kernel arena address and the trampoline converts +it while saving the arguments, so the callback receives an arena pointer +it can dereference directly. With ``__arena`` the kernel caller must not +pass NULL. With ``__arena__nullable`` a NULL kernel pointer arrives as NULL. +However, there is no obligation to prove to the verifier that such a pointer is +non-NULL before use, in-line with existing semantics of arena pointers used in +a program (or obtained from any other source). + .. _BPF_kfunc_nodef: 2.4 Using an existing kernel function @@ -273,22 +338,29 @@ flags on a set of kfuncs as follows:: BTF_KFUNCS_END(bpf_task_set) This set encodes the BTF ID of each kfunc listed above, and encodes the flags -along with it. Ofcourse, it is also allowed to specify no flags. +along with it. It is also allowed to specify no flags. kfunc definitions should also always be annotated with the ``__bpf_kfunc`` -macro. This prevents issues such as the compiler inlining the kfunc if it's a -static kernel function, or the function being elided in an LTO build as it's -not used in the rest of the kernel. Developers should not manually add -annotations to their kfunc to prevent these issues. If an annotation is -required to prevent such an issue with your kfunc, it is a bug and should be -added to the definition of the macro so that other kfuncs are similarly -protected. An example is given below:: +macro. This prevents issues such as the compiler inlining the kfunc, or the +function being elided in an LTO build as it's not used in the rest of the +kernel. Developers should not manually add annotations to their kfunc to prevent +these issues. If an annotation is required to prevent such an issue with your +kfunc, it is a bug and should be added to the definition of the macro so that +other kfuncs are similarly protected. An example is given below:: __bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid) { ... } +Note that kfuncs must not be declared ``static``. A kfunc can be called from a +BPF program ``*.c`` file outside the compilation unit that defines it, so its +externally visible name must remain available for BTF ID lookup. ``static`` +linkage allows the compiler to rename the function, which can break this +BTF-based kfunc resolution. Further note that sparse may warn that an otherwise +unreferenced kfunc should be static. Such warnings should be ignored for kfunc +definitions. + 2.5.1 KF_ACQUIRE flag --------------------- @@ -404,7 +476,7 @@ Example declaration: .. code-block:: c __bpf_kfunc int bpf_task_work_schedule_signal(struct task_struct *task, struct bpf_task_work *tw, - void *map__map, bpf_task_work_callback_t callback, + void *map__const_map, bpf_task_work_callback_t callback, struct bpf_prog_aux *aux) { ... } Example usage in BPF program: @@ -437,6 +509,13 @@ type. An example is shown below:: } late_initcall(init_subsystem); +At kernel build time the ``resolve_btfids`` tool finds all kfuncs declared with +``BTF_KFUNCS_START()`` and emits their BTF annotations into the kernel's BTF. +For each kfunc it emits a ``bpf_kfunc`` BTF decl tag, a ``bpf_fastcall`` decl +tag when the kfunc is flagged ``KF_FASTCALL``, and the ``address_space(1)`` type +attribute on the return value and/or arguments flagged ``KF_ARENA_RET``, +``KF_ARENA_ARG1`` or ``KF_ARENA_ARG2`` (see section 2.8). + 2.7 Specifying no-cast aliases with ___init -------------------------------------------- @@ -480,6 +559,8 @@ In order to accommodate such requirements, the verifier will enforce strict PTR_TO_BTF_ID type matching if two types have the exact same name, with one being suffixed with ``___init``. +.. _BPF_kfunc_arena_access: + 2.8 Accessing arena memory through kfunc arguments -------------------------------------------------- diff --git a/Documentation/bpf/signing.rst b/Documentation/bpf/signing.rst new file mode 100644 index 000000000000..e73eaaebd8b1 --- /dev/null +++ b/Documentation/bpf/signing.rst @@ -0,0 +1,497 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +BPF signing +============ + +This document describes how BPF programs are cryptographically signed, how the +kernel verifies them at load time, and how Linux Security Modules (LSMs) - +including the BPF LSM - use the resulting verdict to enforce policy. It is +written for developers who want to produce signed BPF objects, understand what +the signature actually guarantees, or build a policy on top of it. + +Motivation +========== + +A signed BPF program lets the kernel establish that the bytecode being loaded +originates from a trusted producer and was not modified in transit. On its own +the kernel does not *require* signatures - an unsigned program loads exactly as +before - but it records a verdict (see `The verdict`_) that an LSM can gate on. +This is the building block for policies such as "only run BPF that was signed by +a key in the trusted keyring", as could in the future be enforced by an LSM +such as IPE. + +Signing is orthogonal to the existing permission model: it does not replace the +capability checks or the verifier. A signed load still requires the usual +privileges (``CAP_BPF`` and any program-type-specific capability, subject to +``kernel.unprivileged_bpf_disabled``), and the loader's instructions are still +checked by the verifier like any other program. A valid signature establishes +*origin and integrity*, not safety - it lets a policy trust where the bytecode +came from, it does not let a load skip any check it would otherwise face. + +The hard part is *what* gets signed. A naive scheme would sign a program's +instruction buffer at build time and verify that signature at +``BPF_PROG_LOAD``. That does not survive contact with real BPF objects, because +the bytes the kernel finally loads are not the bytes the developer built and +signed. Between the two, libbpf and the kernel rewrite the program: + +- **map file descriptors** are patched into ``ld_imm64`` instructions + (``BPF_PSEUDO_MAP_FD``), and a map's fd is assigned at load time, so it + differs on every run; +- **CO-RE relocations** rewrite field offsets, sizes and existence flags against + the *running* kernel's BTF, so the result differs from one kernel to the next; +- **kfunc and ksym references** are resolved to ids/addresses in the running + kernel; +- **global data** (``.rodata``/``.data``/``.bss``) is created and seeded as maps + at load. + +So a signature over the original instructions cannot match the relocated +instructions the verifier ends up checking, and the relocated form cannot be +produced ahead of time because it depends on the target kernel. There is no +fixed byte string that is both signable at build time and what the kernel +actually loads - which is why a program cannot simply be signed and loaded +directly. + +The trusted loader +================== + +The solution is to move that setup work *into* a small BPF program - the +**loader** - and sign the loader instead of the individual programs. libbpf's +``gen_loader`` machinery (``bpftool gen skeleton -L``, the "light skeleton") +emits a ``BPF_PROG_TYPE_SYSCALL`` program whose body performs the bpf() syscalls +that create maps, apply relocations, and load the real programs. The payload it +installs - the serialized programs, map descriptions, relocation data and +initial values - lives in a separate array map, the **metadata map** +(``__loader.map``). + +So the unit of trust is the loader, and the signing contract is:: + + Sig(I_loader || D_meta) + +where ``I_loader`` is the loader's instruction stream and ``D_meta`` is the +content of the metadata map. Verifying the loader's signature establishes that +both the loader *and* the payload it is about to install are authentic. The +loader is reproducible: ``gen_loader`` builds it from primitives so the same +object yields the same bytes on any build host. + +Why the loader is signable when the program is not +-------------------------------------------------- + +The loader sidesteps every rewrite listed above, because the bytes that are +signed are *relocation-invariant*: + +- The loader's own instructions are a fixed sequence of bpf() syscalls emitted + by ``gen_loader``; they carry no CO-RE relocations and resolve no ksyms, so + they are identical on every kernel. The metadata map is referenced by *index* + into ``fd_array`` (``BPF_PSEUDO_MAP_IDX_VALUE``), not by a baked-in file + descriptor, so even that reference does not change between build and load. + The loader instruction bytes the kernel verifies are exactly the bytes that + were signed. +- The metadata map is opaque, frozen data - the serialized target programs, + their relocation records, map descriptions and initial values. Its bytes are + identical at build time and at load time, so they are simply appended to the + instructions and covered by the same signature (there is no separate metadata + hash to compute or compare). + +All the host-specific rewriting - creating maps, patching their fds into the +target programs, applying CO-RE, resolving ksyms, seeding global data - still +happens, but it happens *inside the loader at runtime*, on the verified +metadata, **after** the kernel has verified the ``insns || metadata`` signature. +The kernel never has to verify the relocated target programs: it verifies the +loader and its inputs once, and trust transfers to whatever that now-trusted, +deterministic loader installs. The relocation step is moved from "before the +signature can be checked" to "after a trusted program runs" - which is exactly +what makes it signable. + +Because the metadata map is the loader's only untrusted input, two existing map +properties are reused to keep it trustworthy across the load: + +Exclusive maps + A map created with ``excl_prog_hash`` (see ``BPF_MAP_CREATE``) may only be + accessed by a program whose digest matches that hash. The verifier enforces + ``map->excl_prog_sha == prog->digest`` for every map a program uses, so the + metadata map is bound to exactly the signed loader and cannot be shared with + or mutated by another program. + +Frozen maps + The metadata map is frozen (``BPF_MAP_FREEZE``) before the loader is loaded. + Freezing blocks further userspace writes, so the bytes folded into the + signature cannot change before the loader runs. (Freezing does not make the + map read-only to the loader program itself, which still writes created file + descriptors back into the blob's scratch area.) + +Load-time verification +======================= + +Rather than have the loader check its own metadata from within BPF, the kernel +verifies it directly at ``BPF_PROG_LOAD``, with no new UAPI. The mechanism +reuses the existing ``fd_array``: + +#. Userspace creates the metadata map with ``excl_prog_hash`` set to the + loader's digest, populates it, and freezes it. +#. The loader is loaded with ``signature``/``signature_size``/``keyring_id`` + set, the metadata map referenced through ``fd_array``, and ``fd_array_cnt`` + set so the kernel knows the array's length. +#. Signature verification runs inside the verifier (``bpf_check()``), once it + has resolved the ``fd_array`` entries into the program's ``used_maps``. The + maps folded into the signature are therefore the very objects the program + binds - a single resolution of ``fd_array``, not a separate read, so the + verified bytes cannot be swapped for a different map after the check (no + time-of-check/time-of-use window). Each folded map must be exclusive (carry + ``excl_prog_sha``) and a plain array map (``BPF_MAP_TYPE_ARRAY``); only an + array map exposes its value buffer through ``map_direct_value_addr()`` as a + kernel address spanning ``value_size`` bytes. A map that is not exclusive, not + frozen, or not a plain array is rejected, with a verifier log message naming + the offending map. The kernel appends each map's frozen + contents to the instruction buffer and verifies the PKCS#7 signature over the + concatenation ``insns || metadata_0 || metadata_1 || ...`` in ``used_maps`` + order, before it rewrites the (signed) instructions. + +A signed program therefore takes one of exactly two shapes, both fully +supported: + +- **No bound maps** (``fd_array_cnt == 0``): there is nothing to append, so the + kernel verifies the signature over the instructions alone. A valid signature + yields ``BPF_SIG_VERIFIED`` and the program loads. This is the ordinary case + for a directly-loaded signed program with no separate payload; it is *not* + rejected for "missing" metadata, because it has none to cover. +- **Exclusive bound maps** (``fd_array_cnt > 0``): every entry is exclusive and + folded, so the signature covers ``insns || metadata``. + +There is no third shape: a non-exclusive map in a signed program's ``fd_array`` +is rejected rather than silently left out of the signature, so a signed loader +never binds a map its signature does not cover. + +The digest binding (``excl_prog_sha == prog->digest``) is enforced by the +verifier as usual; because that check runs while ``fd_array`` is resolved - +before the verifier would otherwise compute the tag - ``prog->digest`` is +computed up front in the verifier, over the unmodified (signature-covered) +instructions, for any signed load. + +Coverage is then enforced as the verifier resolves instructions, at the point +each object is bound rather than by a count taken afterwards. Once the signature +has been verified, binding any further map is refused: a map reached by a +directly-referenced fd, or a map swapped into an ``fd_array`` slot the loader +reads, is not among those already folded, so it is rejected the moment the +verifier tries to bind it. A BTF is refused outright for a signed program - a +ksym or a BTF fd in ``fd_array``, whether resolved up front or lazily for a +module kfunc, is rejected when it would be bound. Together with the fold rule +above this keeps the verdict binary: a signed program cannot use a map its +signature does not cover, and a different but equally digest-bound map cannot be +substituted at an ``fd_array`` slot. Non-exclusive maps are never folded, so a +signed program cannot use one at all. + +The verdict +=========== + +A program is either unsigned or fully verified - there is no intermediate +state. The outcome is recorded in ``prog->aux->sig.verdict``: + +.. code-block:: c + + enum bpf_sig_verdict { + BPF_SIG_UNSIGNED = 0, + BPF_SIG_VERIFIED, + }; + +``BPF_SIG_VERIFIED`` means the signature is valid and covers the instructions +*and* the frozen contents of every exclusive map the program uses: + +- For an ordinary, directly-loaded signed program the instructions are the whole + artifact and it uses no exclusive maps, so a valid instruction signature is + the complete verification. +- For a signed loader the metadata map is exclusive, so its contents are folded + in and the signature covers ``insns || metadata``. + +There is deliberately no "instructions verified but metadata not" verdict: a +signed loader that fails to cover its metadata is *rejected* (see above), not +recorded with a weaker verdict. ``BPF_SIG_VERIFIED`` therefore always means the +program and everything the signature is responsible for are authentic, which is +what a policy can rely on. + +Alongside the verdict the kernel records which keyring validated the signature; +see `Keyrings`_. + +Enforcement via LSMs +==================== + +Signing only *records* a verdict; an LSM turns it into policy. The verdict and +keyring fields live in ``struct bpf_prog_aux``, so a BPF LSM program can read +them directly (see Documentation/bpf/prog_lsm.rst for writing and attaching BPF +LSM programs); the same fields are equally available to in-tree LSMs. Two hooks +are useful at different points of the load: the dedicated +``security_bpf_prog_load()`` gates admission before the main verification work, +and the existing ``security_bpf_prog()`` observes a program that has fully +loaded. + +Admission: ``security_bpf_prog_load()`` +--------------------------------------- + +This hook gates admission **for every load**, from a single call site inside the +verifier (``bpf_check()``), before the main verification work. It runs after the +optional signature verification, so the verdict and keyring fields are final - the +hook can see whether, and how strongly, the program was signed, which keyring +validated it, the load ``attr``, the BPF token and whether the load came from the +kernel. For a signed load the verdict is ``BPF_SIG_VERIFIED`` here (the signature +has just been checked); for an unsigned load it is ``BPF_SIG_UNSIGNED``. + +This is the place for *coarse admission* that must also see unsigned and +not-yet-verified loads: require a signature at all, restrict the acceptable +keyring, restrict which token/credentials may load BPF, apply per-program-type +rules, or audit every load attempt that makes it past signature verification - +attempts failing the signature or the metadata binding abort before this hook +fires. It is the primary deny point. + +One subtlety: this hook runs *before* the verifier finishes its work, so +``BPF_SIG_VERIFIED`` *here* means only "validly signed" - not "loaded". Allowing +a load at this point lets it *proceed*; it does not guarantee the program will +load. A validly signed program can still be rejected afterwards on two +independent grounds: the verifier may reject it like any other program (unsafe +memory access, bad control flow, resource limits, ...), and the kernel separately +refuses - as the verifier resolves instructions and binds each object - any map +the signature does not cover or any BTF at all, regardless of what this hook +returned. Only after the program has fully loaded, at the next hook +(``security_bpf_prog()``), does ``BPF_SIG_VERIFIED`` carry its full meaning: +validly signed *and* fully verified. + +A more realistic admission policy than "is it signed at all": accept programs +signed by a system keyring, accept a user-keyring signature only if the +key/keyring it was verified against is on an explicit allowlist, and emit a +tamper-evident record of every decision so that even denied attempts are +auditable. (Illustrative - error checking elided.) + +.. code-block:: c + + /* Serials of user keys/keyrings we additionally trust. */ + struct { + __uint(type, BPF_MAP_TYPE_HASH); + __type(key, __s32); /* keyring_serial */ + __type(value, __u8); + __uint(max_entries, 64); + } trusted_user_keys SEC(".maps"); + + /* Audit stream consumed by a userspace logger. */ + struct { + __uint(type, BPF_MAP_TYPE_RINGBUF); + __uint(max_entries, 1 << 16); + } audit SEC(".maps"); + + struct decision { __u32 prog_type, verdict, ktype; __s32 serial, ret; }; + + SEC("lsm/bpf_prog_load") + int BPF_PROG(admit, struct bpf_prog *prog, union bpf_attr *attr, + struct bpf_token *token, bool kernel) + { + __u32 verdict = prog->aux->sig.verdict; + __u32 ktype = prog->aux->sig.keyring_type; + __s32 serial = prog->aux->sig.keyring_serial; + struct decision *d; + int ret = 0; + + if (kernel) + return 0; /* trust in-kernel loads */ + + if (verdict != BPF_SIG_VERIFIED) + ret = -EPERM; /* must be validly signed */ + else if (ktype == BPF_SIG_KEYRING_USER && + !bpf_map_lookup_elem(&trusted_user_keys, &serial)) + ret = -EPERM; /* key/keyring not allowlisted */ + + d = bpf_ringbuf_reserve(&audit, sizeof(*d), 0); + if (d) { + d->prog_type = attr->prog_type; + d->verdict = verdict; + d->ktype = ktype; + d->serial = serial; + d->ret = ret; + bpf_ringbuf_submit(d, 0); /* record allow *and* deny */ + } + return ret; + } + +Observing a verified load: ``security_bpf_prog()`` +-------------------------------------------------- + +There is deliberately no separate "metadata attested" hook. The coverage check +above is enforced by the kernel unconditionally, so a signed loader that fails +to cover its metadata never loads and an LSM never has to re-establish that +fact. To *act on* a program that has successfully and fully loaded, use the +existing ``security_bpf_prog()`` hook (``lsm/bpf_prog``), which fires from +``bpf_prog_new_fd()`` - after the verifier, after the coverage check, and after +``bpf_prog_alloc_id()``. Relative to the admission hook this point is strictly +later and stronger: + +- the program has an id (``prog->aux->id``), so it can be recorded or correlated + with later events; +- ``verdict == BPF_SIG_VERIFIED`` *here* means **fully** verified - a program + that used a map the signature does not cover was already rejected, so it cannot + reach this point; +- it observes only programs that actually loaded; a failed load never mints an + fd, so it never reaches this hook. + +It takes only the ``prog`` and a non-zero return still aborts (the fd is not +handed out), so it can veto as well as observe. One wrinkle: it also fires on +other paths that mint a new program fd - notably ``bpf_prog_get_fd_by_id()`` - +not just on a fresh load. Because the program already has its id here, an LSM +can tell the two apart with a small hash map: the *first* time an id is seen is +the load; a later sighting of the same id is just another fd to a program that +already exists. + +To bound the map and let a reused id read as a fresh load, this can be paired +with ``security_bpf_prog_free()`` (``lsm/bpf_prog_free``), which deletes the +entry on teardown - keyed by the same ``prog`` pointer, since +``bpf_prog_free_id()`` has already cleared ``prog->aux->id`` to ``0`` by the time +that hook runs. (Illustrative - privileged LSM, error checking elided.) + +.. code-block:: c + + struct rec { __u32 id, ktype; __s32 serial; }; + + struct { + __uint(type, BPF_MAP_TYPE_HASH); + __type(key, __u64); /* struct bpf_prog * -- stable id */ + __type(value, struct rec); + __uint(max_entries, 4096); + } live SEC(".maps"); + + SEC("lsm/bpf_prog") /* fires after load and on every later fd */ + int BPF_PROG(observe, struct bpf_prog *prog) + { + __u64 key = (__u64)(unsigned long)prog; + struct rec r; + + if (prog->aux->sig.verdict != BPF_SIG_VERIFIED) + return 0; + if (bpf_map_lookup_elem(&live, &key)) + return 0; /* seen before: a later fd, not a load */ + + /* First sighting == this program just loaded; id is valid here. */ + r.id = prog->aux->id; + r.ktype = prog->aux->sig.keyring_type; + r.serial = prog->aux->sig.keyring_serial; + bpf_map_update_elem(&live, &key, &r, BPF_NOEXIST); + /* ... newly-loaded verified-program action, e.g. record r.id ... */ + return 0; + } + +Putting them together: to *require* verified BPF, deny at the admission hook +unless the verdict is ``BPF_SIG_VERIFIED`` (and, if desired, restrict the +keyring). The kernel then guarantees that any program which actually loads with +that verdict covered all of its exclusive maps, rejecting any that did not - so +a deny-by-default admission policy needs no second enforcement point. Use +``security_bpf_prog()`` to record or finally gate the verified programs once +they carry an id. The ``verdict``, ``keyring_type`` and ``keyring_serial`` fields +let a policy distinguish, for example, "verified and signed by a builtin key" +from "verified by a user key". A policy LSM such as IPE could consume the same +hooks to enforce system policy without writing any BPF, though none implements +this today. + +Keyrings +======== + +``keyring_id`` selects the trusted keyring the PKCS#7 signature is verified +against. The well-known ids ``0`` (builtin), ``VERIFY_USE_SECONDARY_KEYRING`` +and ``VERIFY_USE_PLATFORM_KEYRING`` select the corresponding system keyrings; +any other value is treated as the serial of a user/session key or keyring. +The keyring is looked up first, before the signature bytes are examined, so a +signature naming a non-existent keyring is rejected up front, and a failed +verification aborts the load - so a program that loads successfully with a +signature always has consistent keyring fields recorded. + +Two fields are recorded in ``prog->aux->sig`` for an LSM to inspect: + +``keyring_type`` (``enum bpf_sig_keyring``) + Classified purely from ``keyring_id`` whenever the program is signed: + ``BPF_SIG_KEYRING_BUILTIN``, ``_SECONDARY``, ``_PLATFORM`` for the system + keyrings, or ``_USER`` for a user/session keyring. It is + ``BPF_SIG_KEYRING_NONE`` for an unsigned program. + +``keyring_serial`` (``s32``) + Set **only** on a successful verification, to the serial of the + **user/session key or keyring** that ``keyring_id`` resolved to - the + object the signature was verified against, not the individual asymmetric + key inside it that matched the signer. Passing + ``KEY_SPEC_SESSION_KEYRING``, for example, records the session keyring's + serial. The system keyrings are trusted as a whole and expose no serial + here, so the serial is ``0`` for builtin, secondary and platform + signatures, and ``0`` for unsigned programs. In other words, a non-zero + ``keyring_serial`` is exactly "verified against the user key/keyring with + this serial". + +.. list-table:: + :header-rows: 1 + + * - ``keyring_id`` + - ``keyring_type`` + - ``keyring_serial`` + * - (no signature) + - ``BPF_SIG_KEYRING_NONE`` + - ``0`` + * - ``0`` + - ``BPF_SIG_KEYRING_BUILTIN`` + - ``0`` + * - ``VERIFY_USE_SECONDARY_KEYRING`` + - ``BPF_SIG_KEYRING_SECONDARY`` + - ``0`` + * - ``VERIFY_USE_PLATFORM_KEYRING`` + - ``BPF_SIG_KEYRING_PLATFORM`` + - ``0`` + * - other (a user/session key serial) + - ``BPF_SIG_KEYRING_USER`` + - serial of the resolved key/keyring + +Producing a signed object +========================== + +``bpftool`` generates and signs a light skeleton in one step:: + + bpftool gen skeleton -L -S -k -i \ + obj.bpf.o > obj.lskel.h + +``-L`` selects the light-skeleton (``gen_loader``) backend and ``-S`` enables +signing; ``-k`` and ``-i`` supply the signing key and its X.509 certificate. +``bpftool`` signs ``insns || metadata`` - the exact bytes the kernel +reconstructs - and also computes ``excl_prog_hash`` as the digest of the loader +instructions so the metadata map can be bound to the loader. The signature and +hash are embedded in the generated header; the certificate is used only for +signing and is not included. Loading the skeleton performs the +create/populate/freeze/load sequence described above. + +At runtime the trusted public key must be present in the chosen keyring (for +example added to the session keyring, or built into the kernel's builtin trusted +keyring) for verification to succeed. + +UAPI reference +============== + +``BPF_PROG_LOAD`` (``union bpf_attr``): + +``signature``, ``signature_size`` + Pointer to and length of the PKCS#7 signature blob. + +``keyring_id`` + Trusted keyring selector (see `Keyrings`_). + +``fd_array``, ``fd_array_cnt`` + Array of map (and module BTF) file descriptors bound to the program. + ``fd_array_cnt`` must be set for the kernel to scan the array. When a + signature is present, a BTF entry is rejected outright, and every map must + be exclusive; its frozen contents are folded into the verified buffer, and + a non-exclusive entry is rejected. + +``BPF_MAP_CREATE`` (``union bpf_attr``): + +``excl_prog_hash``, ``excl_prog_hash_size`` + SHA-256 digest of the program permitted to access this (exclusive) map. This + binds the metadata map to the loader; it is not a hash of the map *content*. + The map content is not hashed separately at all - it is covered, as bytes, + by the program signature. + +Notes and limitations +====================== + +- The instructions plus folded metadata are verified as one ``bpf_dynptr``, + which bounds the combined size (currently ~16 MiB); very large objects can + exceed it. +- The metadata container is a single-element array map, accessed through + ``map_direct_value_addr``. diff --git a/Documentation/crypto/libcrypto-blockcipher.rst b/Documentation/crypto/libcrypto-blockcipher.rst index dd5ce2f8b515..fd85e27fab8d 100644 --- a/Documentation/crypto/libcrypto-blockcipher.rst +++ b/Documentation/crypto/libcrypto-blockcipher.rst @@ -6,14 +6,14 @@ Block ciphers AES --- -Support for the AES block cipher. +This API provides support for the AES block cipher. .. kernel-doc:: include/crypto/aes.h DES --- -Support for the DES block cipher. This algorithm is obsolete and is supported -only for backwards compatibility. +This API provides support for the DES block cipher. This algorithm is obsolete +and is supported only for backwards compatibility. .. kernel-doc:: include/crypto/des.h diff --git a/Documentation/crypto/libcrypto-hash.rst b/Documentation/crypto/libcrypto-hash.rst index 4248e6fdc952..fa4c54236af6 100644 --- a/Documentation/crypto/libcrypto-hash.rst +++ b/Documentation/crypto/libcrypto-hash.rst @@ -6,81 +6,83 @@ Hash functions, MACs, and XOFs AES-CMAC and AES-XCBC-MAC ------------------------- -Support for the AES-CMAC and AES-XCBC-MAC message authentication codes. +This API provides support for the AES-CMAC and AES-XCBC-MAC message +authentication codes. .. kernel-doc:: include/crypto/aes-cbc-macs.h BLAKE2b ------- -Support for the BLAKE2b cryptographic hash function. +This API provides support for the BLAKE2b cryptographic hash function. .. kernel-doc:: include/crypto/blake2b.h BLAKE2s ------- -Support for the BLAKE2s cryptographic hash function. +This API provides support for the BLAKE2s cryptographic hash function. .. kernel-doc:: include/crypto/blake2s.h GHASH and POLYVAL ----------------- -Support for the GHASH and POLYVAL universal hash functions. These algorithms -are used only as internal components of other algorithms. +This API provides support for the GHASH and POLYVAL universal hash functions. +These algorithms are used only as internal components of other algorithms. .. kernel-doc:: include/crypto/gf128hash.h MD5 --- -Support for the MD5 cryptographic hash function and HMAC-MD5. This algorithm is -obsolete and is supported only for backwards compatibility. +This API provides support for the MD5 cryptographic hash function and HMAC-MD5. +This algorithm is obsolete and is supported only for backwards compatibility. .. kernel-doc:: include/crypto/md5.h NH -- -Support for the NH universal hash function. This algorithm is used only as an -internal component of other algorithms. +This API provides support for the NH universal hash function. This algorithm is +used only as an internal component of other algorithms. .. kernel-doc:: include/crypto/nh.h Poly1305 -------- -Support for the Poly1305 universal hash function. This algorithm is used only -as an internal component of other algorithms. +This API provides support for the Poly1305 universal hash function. This +algorithm is used only as an internal component of other algorithms. .. kernel-doc:: include/crypto/poly1305.h SHA-1 ----- -Support for the SHA-1 cryptographic hash function and HMAC-SHA1. This algorithm -is obsolete and is supported only for backwards compatibility. +This API provides support for the SHA-1 cryptographic hash function and +HMAC-SHA1. This algorithm is obsolete and is supported only for backwards +compatibility. .. kernel-doc:: include/crypto/sha1.h SHA-2 ----- -Support for the SHA-2 family of cryptographic hash functions, including SHA-224, -SHA-256, SHA-384, and SHA-512. This also includes their corresponding HMACs: -HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512. +This API provides support for the SHA-2 family of cryptographic hash functions, +including SHA-224, SHA-256, SHA-384, and SHA-512. This also includes their +corresponding HMACs: HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512. .. kernel-doc:: include/crypto/sha2.h SHA-3 ----- -The SHA-3 functions are documented in :ref:`sha3`. +The SHA-3 API is documented in :ref:`sha3`. SM3 --- -Support for the SM3 cryptographic hash function. +This API provides support for the SM3 cryptographic hash function. .. kernel-doc:: include/crypto/sm3.h diff --git a/Documentation/crypto/libcrypto-signature.rst b/Documentation/crypto/libcrypto-signature.rst index e80d59fa51b6..2a6dc793f0de 100644 --- a/Documentation/crypto/libcrypto-signature.rst +++ b/Documentation/crypto/libcrypto-signature.rst @@ -6,6 +6,6 @@ Digital signature algorithms ML-DSA ------ -Support for the ML-DSA digital signature algorithm. +This API provides support for the ML-DSA digital signature algorithm. .. kernel-doc:: include/crypto/mldsa.h diff --git a/Documentation/crypto/libcrypto.rst b/Documentation/crypto/libcrypto.rst index a1557d45b0e5..0733e603d229 100644 --- a/Documentation/crypto/libcrypto.rst +++ b/Documentation/crypto/libcrypto.rst @@ -4,8 +4,9 @@ Crypto library ============== -``lib/crypto/`` provides faster and easier access to cryptographic algorithms -than the traditional crypto API. +The Linux kernel's crypto library (``lib/crypto/``) provides kernel-internal +users of cryptographic algorithms with faster and easier access to those +algorithms than the traditional kernel crypto API. Each cryptographic algorithm is supported via a set of dedicated functions. "Crypto agility", where needed, is left to calling code. diff --git a/Documentation/devicetree/bindings/clock/amlogic,t7-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,t7-peripherals-clkc.yaml index 55bb73707d58..a4b214a941ea 100644 --- a/Documentation/devicetree/bindings/clock/amlogic,t7-peripherals-clkc.yaml +++ b/Documentation/devicetree/bindings/clock/amlogic,t7-peripherals-clkc.yaml @@ -24,7 +24,7 @@ properties: const: 1 clocks: - minItems: 14 + minItems: 15 items: - description: input oscillator - description: input sys clk @@ -40,12 +40,13 @@ properties: - description: input gp1 pll - description: input mpll1 - description: input mpll2 + - description: input mpll3 - description: external input rmii oscillator (optional) - description: input video pll0 (optional) - description: external pad input for rtc (optional) clock-names: - minItems: 14 + minItems: 15 items: - const: xtal - const: sys @@ -61,6 +62,7 @@ properties: - const: gp1 - const: mpll1 - const: mpll2 + - const: mpll3 - const: ext_rmii - const: vid_pll0 - const: ext_rtc @@ -97,7 +99,8 @@ examples: <&gp0 1>, <&gp1 1>, <&mpll 4>, - <&mpll 6>; + <&mpll 6>, + <&mpll 8>; clock-names = "xtal", "sys", "fix", @@ -111,6 +114,7 @@ examples: "gp0", "gp1", "mpll1", - "mpll2"; + "mpll2", + "mpll3"; }; }; diff --git a/Documentation/devicetree/bindings/clock/amlogic,t7-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,t7-pll-clkc.yaml index 49c61f65deff..b488d92b7984 100644 --- a/Documentation/devicetree/bindings/clock/amlogic,t7-pll-clkc.yaml +++ b/Documentation/devicetree/bindings/clock/amlogic,t7-pll-clkc.yaml @@ -72,7 +72,7 @@ allOf: contains: enum: - amlogic,t7-gp0-pll - - amlogic,t7-gp1--pll + - amlogic,t7-gp1-pll - amlogic,t7-hifi-pll - amlogic,t7-pcie-pll - amlogic,t7-mpll diff --git a/Documentation/devicetree/bindings/clock/canaan,k230-clk.yaml b/Documentation/devicetree/bindings/clock/canaan,k230-clk.yaml new file mode 100644 index 000000000000..34c93cb5db40 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/canaan,k230-clk.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/canaan,k230-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Canaan Kendryte K230 Clock + +maintainers: + - Xukai Wang + +description: + The Canaan K230 clock controller generates various clocks for SoC + peripherals. See include/dt-bindings/clock/canaan,k230-clk.h for + valid clock IDs. + +properties: + compatible: + const: canaan,k230-clk + + reg: + items: + - description: PLL control registers + - description: Sysclk control registers + + clocks: + items: + - description: Main external reference clock + - description: + External clock which used as the pulse input + for the timer to provide timing signals. + + clock-names: + items: + - const: osc24m + - const: timer-pulse-in + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@91102000 { + compatible = "canaan,k230-clk"; + reg = <0x91102000 0x40>, + <0x91100000 0x108>; + clocks = <&osc24m>, <&timerx_pulse_in>; + clock-names = "osc24m", "timer-pulse-in"; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml index 6f3a8578fe2a..0db5504013d5 100644 --- a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml +++ b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml @@ -37,6 +37,9 @@ properties: '#power-domain-cells': const: 1 + '#reset-cells': + const: 1 + required: - compatible - reg @@ -44,16 +47,27 @@ required: additionalProperties: false -if: - not: - properties: - compatible: - contains: - const: marvell,pxa1908-apmu - -then: - properties: - '#power-domain-cells': false +allOf: + - if: + not: + properties: + compatible: + contains: + const: marvell,pxa1908-apmu + then: + properties: + '#power-domain-cells': false + - if: + not: + properties: + compatible: + contains: + enum: + - marvell,pxa1908-apbc + - marvell,pxa1908-apbcp + then: + properties: + '#reset-cells': false examples: # APMU block: diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml index ef2b1e204430..a177a1934b19 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml @@ -42,12 +42,6 @@ properties: - const: cfg_ahb_clk - const: gcc_disp_gpll0_div_clk_src - '#clock-cells': - const: 1 - - '#power-domain-cells': - const: 1 - power-domains: description: A phandle and PM domain specifier for the CX power domain. @@ -58,18 +52,16 @@ properties: A phandle to an OPP node describing the power domain's performance point. maxItems: 1 - reg: - maxItems: 1 - required: - compatible - - reg - clocks - clock-names - - '#clock-cells' - '#power-domain-cells' -additionalProperties: false +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false examples: - | @@ -101,6 +93,7 @@ examples: power-domains = <&rpmpd SM6125_VDDCX>; #clock-cells = <1>; + #reset-cells = <1>; #power-domain-cells = <1>; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,hawi-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,hawi-gcc.yaml new file mode 100644 index 000000000000..4f428c0f7286 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,hawi-gcc.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,hawi-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on Hawi + +maintainers: + - Vivek Aknurwar + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on Hawi. + + See also: include/dt-bindings/clock/qcom,hawi-gcc.h + +properties: + compatible: + const: qcom,hawi-gcc + + clocks: + items: + - description: Board XO source + - description: Board Always On XO source + - description: Sleep clock source + - description: PCIE 0 Pipe clock source + - description: PCIE 1 Pipe clock source + - description: UFS PHY RX symbol 0 clock + - description: UFS PHY RX symbol 1 clock + - description: UFS PHY TX symbol 0 clock + - description: USB3 PHY wrapper pipe clock + +required: + - compatible + - clocks + - '#power-domain-cells' + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include + clock-controller@100000 { + compatible = "qcom,hawi-gcc"; + reg = <0x00100000 0x1f4200>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>, + <&pcie0_phy>, + <&pcie1_phy>, + <&ufs_mem_phy 0>, + <&ufs_mem_phy 1>, + <&ufs_mem_phy 2>, + <&usb_1_qmpphy>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml index de338c05190f..a4f9af8fa187 100644 --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml @@ -8,7 +8,7 @@ title: Qualcomm CMN PLL Clock Controller on IPQ SoC maintainers: - Bjorn Andersson - - Luo Jie + - Luo Jie description: The CMN (or common) PLL clock controller expects a reference @@ -25,6 +25,7 @@ properties: compatible: enum: - qcom,ipq5018-cmn-pll + - qcom,ipq5332-cmn-pll - qcom,ipq5424-cmn-pll - qcom,ipq6018-cmn-pll - qcom,ipq8074-cmn-pll diff --git a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml index 466c884aa2ba..e868963f659b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml @@ -44,7 +44,7 @@ required: - power-domains - '#power-domain-cells' -unevaluatedProperties: false +additionalProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml index f63149ecf3e1..707b25d2c11e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml @@ -25,6 +25,10 @@ properties: - description: Sleep clock source - description: Camera AHB clock from GCC + interconnects: + items: + - description: Interconnect path to enable the MultiMedia NoC + required: - compatible - clocks @@ -37,12 +41,16 @@ unevaluatedProperties: false examples: - | #include + #include + #include clock-controller@adb0000 { compatible = "qcom,milos-camcc"; reg = <0x0adb0000 0x40000>; clocks = <&bi_tcxo_div2>, <&sleep_clk>, <&gcc GCC_CAMERA_AHB_CLK>; + interconnects = <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS + &mmss_noc SLAVE_MNOC_HF_MEM_NOC QCOM_ICC_TAG_ALWAYS>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml new file mode 100644 index 000000000000..fbcb5d3f3e3d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,milos-gxclkctl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Power Domain Controller on Milos + +maintainers: + - Luca Weiss + +description: | + Qualcomm GX(graphics) is a clock controller which has PLLs, clocks and + Power domains (GDSC). This module provides the power domains control + of gxclkctl on Qualcomm SoCs which helps the recovery of Graphics subsystem. + + See also: + include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h + +properties: + compatible: + enum: + - qcom,milos-gxclkctl + + reg: + maxItems: 1 + + power-domains: + description: + Power domains required for the clock controller to operate + items: + - description: GFX power domain + - description: GPUCC(CX) power domain + + '#power-domain-cells': + const: 1 + +required: + - compatible + - reg + - power-domains + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + soc { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@3d64000 { + compatible = "qcom,milos-gxclkctl"; + reg = <0x0 0x03d64000 0x0 0x6000>; + power-domains = <&rpmhpd RPMHPD_GFX>, + <&gpucc 0>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml index 61473385da2d..480745349a5d 100644 --- a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml @@ -8,7 +8,7 @@ title: Qualcomm NSS Clock & Reset Controller on QCA8386/QCA8084 maintainers: - Bjorn Andersson - - Luo Jie + - Luo Jie description: | Qualcomm NSS clock control module provides the clocks and resets diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index a2c404a57981..d344b3386042 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -19,6 +19,7 @@ properties: enum: - qcom,eliza-rpmh-clk - qcom,glymur-rpmh-clk + - qcom,hawi-rpmh-clk - qcom,kaanapali-rpmh-clk - qcom,milos-rpmh-clk - qcom,nord-rpmh-clk diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml index 7bbf120d928c..5d77029bfaf8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml @@ -20,6 +20,7 @@ description: | include/dt-bindings/clock/qcom,sm8450-videocc.h include/dt-bindings/clock/qcom,sm8650-videocc.h include/dt-bindings/clock/qcom,sm8750-videocc.h + include/dt-bindings/clock/qcom,x1p42100-videocc.h properties: compatible: @@ -32,6 +33,7 @@ properties: - qcom,sm8650-videocc - qcom,sm8750-videocc - qcom,x1e80100-videocc + - qcom,x1p42100-videocc clocks: items: @@ -70,6 +72,7 @@ allOf: - qcom,sm8450-videocc - qcom,sm8550-videocc - qcom,sm8750-videocc + - qcom,x1p42100-videocc then: required: - required-opps diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml index 1ccdf4b0f5dd..08824f848973 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml @@ -17,6 +17,7 @@ description: | See also: - include/dt-bindings/clock/qcom,eliza-tcsr.h - include/dt-bindings/clock/qcom,glymur-tcsr.h + - include/dt-bindings/clock/qcom,hawi-tcsrcc.h - include/dt-bindings/clock/qcom,nord-tcsrcc.h - include/dt-bindings/clock/qcom,sm8550-tcsr.h - include/dt-bindings/clock/qcom,sm8650-tcsr.h @@ -28,6 +29,7 @@ properties: - enum: - qcom,eliza-tcsr - qcom,glymur-tcsr + - qcom,hawi-tcsrcc - qcom,kaanapali-tcsr - qcom,milos-tcsr - qcom,nord-tcsrcc diff --git a/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml index 938a2f1ff3fc..b28614186cc0 100644 --- a/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml @@ -23,6 +23,7 @@ properties: compatible: enum: - qcom,x1e80100-camcc + - qcom,x1p42100-camcc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml index 2197c952e21d..b6ee8c8efd46 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml @@ -60,7 +60,7 @@ examples: clock-output-names = "main", "pll0", "pll1", "pll2", "pll2s", "pll2h", "z", "z2", "i", "m3", "b", "m1", "m2", - "zx", "zs", "hp"; + "zx", "zs", "hp", "ztr", "zt"; }; sdhi2_clk: sdhi2_clk@e615007c { diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml index 12256ae7df90..64c4f24ea3dd 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml @@ -40,6 +40,10 @@ properties: vdd-supply: description: Power supply + reset-gpios: + description: Reset GPIO (active-low) + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml new file mode 100644 index 000000000000..6d1da6a435d3 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/wacom,w9007a-lt03.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wacom W9000-series penabled I2C touchscreen + +maintainers: + - Hendrik Noack + +description: | + The W9000-series are penabled touchscreen controllers by Wacom. + + The firmware of controllers in different devices may differ. This can also + affect the controller's behavior. + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - wacom,w9002 + - wacom,w9007a-lt03 + - wacom,w9007a-v1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: true + + flash-mode-gpios: + maxItems: 1 + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + digitizer@56 { + compatible = "wacom,w9007a-lt03"; + reg = <0x56>; + interrupt-parent = <&gpd1>; + interrupts = <1 IRQ_TYPE_EDGE_RISING>; + + vdd-supply = <&stylus_reg>; + + flash-mode-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpx0 1 GPIO_ACTIVE_LOW>; + + touchscreen-x-mm = <216>; + touchscreen-y-mm = <135>; + touchscreen-inverted-x; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml index 1f135618e3b6..c6f91e7bc8aa 100644 --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml @@ -28,7 +28,6 @@ properties: fan-supply: description: Phandle to the regulator that powers the fan. - $ref: /schemas/types.yaml#/definitions/phandle required: - compatible diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index eb3755bdfdf7..a4d032224dce 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -193,7 +193,6 @@ allOf: - mediatek,mt8183-mmc - mediatek,mt8186-mmc - mediatek,mt8188-mmc - - mediatek,mt8189-mmc - mediatek,mt8195-mmc - mediatek,mt8196-mmc - mediatek,mt8516-mmc @@ -348,6 +347,34 @@ allOf: - const: axi_cg - const: ahb_cg + - if: + properties: + compatible: + contains: + const: mediatek,mt8189-mmc + then: + properties: + clocks: + minItems: 6 + items: + - description: source clock + - description: HCLK which used for host + - description: independent source clock gate + - description: bus clock used for internal register access + - description: peripheral bus clock gate + - description: AXI bus clock gate + - description: crypto clock used for data encrypt/decrypt (optional) + clock-names: + minItems: 6 + items: + - const: source + - const: hclk + - const: source_cg + - const: bus_clk + - const: pclk_cg + - const: axi_cg + - const: crypto + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml index 753f370b7605..6d0b21a10732 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm IPQ packet process engine (PPE) maintainers: - - Luo Jie + - Luo Jie - Lei Wei - Suruchi Agarwal - Pavithra R diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml b/Documentation/devicetree/bindings/net/renesas,ether.yaml index f0a52f47f95a..dd7187f12a67 100644 --- a/Documentation/devicetree/bindings/net/renesas,ether.yaml +++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml @@ -121,8 +121,7 @@ examples: #size-cells = <0>; phy1: ethernet-phy@1 { - compatible = "ethernet-phy-id0022.1537", - "ethernet-phy-ieee802.3-c22"; + compatible = "ethernet-phy-id0022.1537"; reg = <1>; interrupt-parent = <&irqc0>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 9d1349855b42..e8b8131f5f23 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -66,16 +66,34 @@ properties: - const: dma reset-gpio: + deprecated: true description: Should specify the GPIO for controlling the PCI bus device reset signal. It's not polarity aware and defaults to active-low reset sequence (L=reset state, H=operation state) (optional required). + This property is deprecated, instead of referencing this property from the + host bridge node, use the reset-gpios property from the root port node. reset-gpio-active-high: + deprecated: true description: If present then the reset sequence using the GPIO specified in the "reset-gpio" property is reversed (H=reset state, L=operation state) (optional required). + This property is deprecated along with the reset-gpio property above, use + the reset-gpios property from the root port node. type: boolean + pcie@0: + description: + Describe the i.MX6 PCIe Root Port. + type: object + $ref: /schemas/pci/pci-pci-bridge.yaml# + + properties: + reg: + maxItems: 1 + + unevaluatedProperties: false + required: - compatible - reg @@ -236,6 +254,7 @@ unevaluatedProperties: false examples: - | #include + #include #include pcie: pcie@1ffc000 { @@ -262,5 +281,18 @@ examples: <&clks IMX6QDL_CLK_LVDS1_GATE>, <&clks IMX6QDL_CLK_PCIE_REF_125M>; clock-names = "pcie", "pcie_bus", "pcie_phy"; + + pcie_port0: pcie@0 { + compatible = "pciclass,0604"; + device_type = "pci"; + reg = <0x0 0x0 0x0 0x0 0x0>; + bus-range = <0x01 0xff>; + + #address-cells = <3>; + #size-cells = <2>; + ranges; + + reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>; + }; }; ... diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml index 54e2890ae631..394bb46b38e6 100644 --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml @@ -27,16 +27,20 @@ properties: - const: snps,dw-pcie reg: + minItems: 3 items: - description: Controller control and status registers. - description: PCIe configuration registers. - description: Controller application registers. + - description: Internal Address Translation Unit (iATU) registers. reg-names: + minItems: 3 items: - const: dbi - const: config - const: app + - const: atu ranges: maxItems: 1 @@ -95,8 +99,9 @@ examples: #size-cells = <2>; reg = <0xd0e00000 0x1000>, <0xd2000000 0x800000>, - <0xd0a41000 0x1000>; - reg-names = "dbi", "config", "app"; + <0xd0a41000 0x1000>, + <0xd0ec0000 0x1000>; + reg-names = "dbi", "config", "app", "atu"; linux,pci-domain = <0>; max-link-speed = <4>; bus-range = <0x00 0x08>; diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie.yaml index 0b8c78ec4f91..c009a7a52bc6 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.yaml @@ -14,6 +14,7 @@ properties: oneOf: - enum: - airoha,an7583-pcie + - econet,en7528-pcie - mediatek,mt2712-pcie - mediatek,mt7622-pcie - mediatek,mt7629-pcie @@ -226,6 +227,31 @@ allOf: mediatek,pbus-csr: false + - if: + properties: + compatible: + contains: + const: econet,en7528-pcie + then: + properties: + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + resets: false + + reset-names: false + + power-domains: false + + mediatek,pbus-csr: false + + required: + - phys + - phy-names + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml index 3a94a9c1bb15..fb706b1397a3 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml @@ -20,6 +20,7 @@ properties: - const: qcom,pcie-sm8550 - items: - enum: + - qcom,eliza-pcie - qcom,kaanapali-pcie - qcom,sar2130p-pcie - qcom,pcie-sm8650 @@ -91,6 +92,55 @@ required: allOf: - $ref: qcom,pcie-common.yaml# + - if: + properties: + compatible: + contains: + const: qcom,eliza-pcie + then: + properties: + reg: + minItems: 6 + reg-names: + minItems: 6 + + - if: + properties: + compatible: + contains: + const: qcom,eliza-pcie + then: + properties: + clocks: + minItems: 8 + maxItems: 8 + clock-names: + minItems: 8 + maxItems: 8 + + - if: + properties: + compatible: + contains: + const: qcom,eliza-pcie + then: + properties: + interrupts: + minItems: 9 + interrupt-names: + minItems: 9 + + - if: + properties: + compatible: + contains: + const: qcom,eliza-pcie + then: + properties: + resets: + minItems: 2 + reset-names: + minItems: 2 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml b/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml index a67108c48feb..90086909e921 100644 --- a/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml @@ -4,21 +4,27 @@ $id: http://devicetree.org/schemas/pci/renesas,r9a08g045-pcie.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G3S PCIe host controller +title: Renesas RZ/G3S PCIe host controller (and similar SoCs) maintainers: - Claudiu Beznea -description: - Renesas RZ/G3{E,S} PCIe host controllers comply with PCIe - Base Specification 4.0 and support up to 5 GT/s (Gen2) for RZ/G3S and - up to 8 GT/s (Gen3) for RZ/G3E. +description: | + PCIe host controller found in Renesas RZ/G3S and similar SoCs complies + with PCIe Base Specification 4.0 and supports different link speeds + depending on the SoC variant: + - Gen2 (5 GT/s): RZ/G3S + - Gen3 (8 GT/s): RZ/G3E, RZ/V2N properties: compatible: - enum: - - renesas,r9a08g045-pcie # RZ/G3S - - renesas,r9a09g047-pcie # RZ/G3E + oneOf: + - enum: + - renesas,r9a08g045-pcie # RZ/G3S + - renesas,r9a09g047-pcie # RZ/G3E + - items: + - const: renesas,r9a09g056-pcie # RZ/V2N + - const: renesas,r9a09g047-pcie reg: maxItems: 1 @@ -152,6 +158,7 @@ patternProperties: enum: - 0x0033 - 0x0039 + - 0x003b clocks: items: diff --git a/Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml b/Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml index f8b7ca57fff1..ab482488b047 100644 --- a/Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml @@ -30,6 +30,8 @@ properties: device-id: const: 0x2042 + dma-coherent: true + msi-parent: true allOf: @@ -60,5 +62,6 @@ examples: vendor-id = <0x1f1c>; device-id = <0x2042>; cdns,no-bar-match-nbits = <48>; + dma-coherent; msi-parent = <&msi>; }; diff --git a/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml b/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml new file mode 100644 index 000000000000..512b935bf5d1 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/ultrarisc,dp1000-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UltraRISC DP1000 PCIe Host Controller + +description: + UltraRISC DP1000 SoC PCIe host controller is based on the DesignWare PCIe IP. + +maintainers: + - Xincheng Zhang + - Jia Wang + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + const: ultrarisc,dp1000-pcie + + reg: + items: + - description: Data Bus Interface (DBI) registers. + - description: PCIe configuration space region. + + reg-names: + items: + - const: dbi + - const: config + + num-lanes: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [4, 16] + description: Number of lanes to use. + + interrupts: + items: + - description: MSI interrupt + - description: Legacy INTA interrupt + - description: Legacy INTB interrupt + - description: Legacy INTC interrupt + - description: Legacy INTD interrupt + + interrupt-names: + items: + - const: msi + - const: inta + - const: intb + - const: intc + - const: intd + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + +unevaluatedProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie@21000000 { + compatible = "ultrarisc,dp1000-pcie"; + reg = <0x0 0x21000000 0x0 0x01000000>, + <0x0 0x4fff0000 0x0 0x00010000>; + reg-names = "dbi", "config"; + ranges = <0x81000000 0x0 0x4fbf0000 0x0 0x4fbf0000 0x0 0x00400000>, + <0x82000000 0x0 0x40000000 0x0 0x40000000 0x0 0x0fbf0000>, + <0xc3000000 0x40 0x00000000 0x40 0x00000000 0xd 0x00000000>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + device_type = "pci"; + dma-coherent; + bus-range = <0x0 0xff>; + num-lanes = <16>; + interrupt-parent = <&plic>; + interrupts = <43>, <44>, <45>, <46>, <47>; + interrupt-names = "msi", "inta", "intb", "intc", "intd"; + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0x0 0x0 0x0 0x1 &plic 44>, + <0x0 0x0 0x0 0x2 &plic 45>, + <0x0 0x0 0x0 0x3 &plic 46>, + <0x0 0x0 0x0 0x4 &plic 47>; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/sprd,sc2730-regulator.yaml b/Documentation/devicetree/bindings/regulator/sprd,sc2730-regulator.yaml new file mode 100644 index 000000000000..ab945c46b08e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/sprd,sc2730-regulator.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/sprd,sc2730-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Unisoc SC2730 Power Management IC regulators + +maintainers: + - Otto Pflüger + +patternProperties: + "^dcdc-(core|cpu|gen[0-1]|gpu|mem|memq|modem|sram)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + "^ldo-avdd(12|18)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + "^ldo-vdd(18-dcxo|28)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + "^ldo-vdd(emmccore|kpled|ldo[0-2]|sd(core|io)|sim[0-2]|usb33|wcn|wifipa)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + "^ldo-vddcam(a0|a1|d0|d1|io|mot)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + "^ldo-vddrf(1v25|18)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + +additionalProperties: false +... diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml index 2b0a8a93bb21..5ffc40d599c0 100644 --- a/Documentation/devicetree/bindings/riscv/extensions.yaml +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -457,6 +457,13 @@ properties: merged in the riscv-isa-manual by commit dbc79cf28a2 ("Initial seed of zc.adoc to src tree."). + - const: zclsd + description: + The Zclsd extension implements the compressed (16-bit) version of the + Load/Store Pair for RV32. As with Zilsd, this extension was ratified + in commit f88abf1 ("Integrating load/store pair for RV32 with the + main manual") of riscv-isa-manual. + - const: zcmop description: The standard Zcmop extension version 1.0, as ratified in commit @@ -487,6 +494,22 @@ properties: in commit 64074bc ("Update version numbers for Zfh/Zfinx") of riscv-isa-manual. + - const: zicbom + description: + The standard Zicbom extension for base cache management operations as + ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + + - const: zicbop + description: + The standard Zicbop extension for cache-block prefetch instructions + as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of + riscv-CMOs. + + - const: zicboz + description: + The standard Zicboz extension for cache-block zeroing as ratified + in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + - const: ziccamoa description: The standard Ziccamoa extension for main memory (cacheability and @@ -514,6 +537,66 @@ properties: guarantee on LR/SC sequences, as ratified in commit b1d806605f87 ("Updated to ratified state.") of the riscv profiles specification. + - const: zicfilp + description: | + The standard Zicfilp extension for enforcing forward edge + control-flow integrity as ratified in commit 3f8e450 ("merge + pull request #227 from ved-rivos/0709") of riscv-cfi + github repo. + + - const: zicfiss + description: | + The standard Zicfiss extension for enforcing backward edge + control-flow integrity as ratified in commit 3f8e450 ("merge + pull request #227 from ved-rivos/0709") of riscv-cfi + github repo. + + - const: zicntr + description: + The standard Zicntr extension for base counters and timers, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: zicond + description: + The standard Zicond extension for conditional arithmetic and + conditional-select/move operations as ratified in commit 95cf1f9 + ("Add changes requested by Ved during signoff") of riscv-zicond. + + - const: zicsr + description: | + The standard Zicsr extension for control and status register + instructions, as ratified in the 20191213 version of the + unprivileged ISA specification. + + This does not include Chapter 10, "Counters", which documents + special case read-only CSRs, that were moved into the Zicntr and + Zihpm extensions after the ratification of the 20191213 version of + the unprivileged specification. + + - const: zifencei + description: + The standard Zifencei extension for instruction-fetch fence, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: zihintntl + description: + The standard Zihintntl extension for non-temporal locality hints, as + ratified in commit 0dc91f5 ("Zihintntl is ratified") of the + riscv-isa-manual. + + - const: zihintpause + description: + The standard Zihintpause extension for pause hints, as ratified in + commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual. + + - const: zihpm + description: + The standard Zihpm extension for hardware performance counters, as + ratified in the 20191213 version of the unprivileged ISA + specification. + - const: zilsd description: The standard Zilsd extension which provides support for aligned @@ -521,12 +604,10 @@ properties: encodings, as ratified in commit f88abf1 ("Integrating load/store pair for RV32 with the main manual") of riscv-isa-manual. - - const: zclsd + - const: zimop description: - The Zclsd extension implements the compressed (16-bit) version of the - Load/Store Pair for RV32. As with Zilsd, this extension was ratified - in commit f88abf1 ("Integrating load/store pair for RV32 with the - main manual") of riscv-isa-manual. + The standard Zimop extension version 1.0, as ratified in commit + 58220614a5f ("Zimop is ratified/1.0") of the riscv-isa-manual. - const: zk description: @@ -590,87 +671,6 @@ properties: in version 1.0 of RISC-V Cryptography Extensions Volume I specification. - - const: zicbom - description: - The standard Zicbom extension for base cache management operations as - ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. - - - const: zicbop - description: - The standard Zicbop extension for cache-block prefetch instructions - as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of - riscv-CMOs. - - - const: zicboz - description: - The standard Zicboz extension for cache-block zeroing as ratified - in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. - - - const: zicfilp - description: | - The standard Zicfilp extension for enforcing forward edge - control-flow integrity as ratified in commit 3f8e450 ("merge - pull request #227 from ved-rivos/0709") of riscv-cfi - github repo. - - - const: zicfiss - description: | - The standard Zicfiss extension for enforcing backward edge - control-flow integrity as ratified in commit 3f8e450 ("merge - pull request #227 from ved-rivos/0709") of riscv-cfi - github repo. - - - const: zicntr - description: - The standard Zicntr extension for base counters and timers, as - ratified in the 20191213 version of the unprivileged ISA - specification. - - - const: zicond - description: - The standard Zicond extension for conditional arithmetic and - conditional-select/move operations as ratified in commit 95cf1f9 - ("Add changes requested by Ved during signoff") of riscv-zicond. - - - const: zicsr - description: | - The standard Zicsr extension for control and status register - instructions, as ratified in the 20191213 version of the - unprivileged ISA specification. - - This does not include Chapter 10, "Counters", which documents - special case read-only CSRs, that were moved into the Zicntr and - Zihpm extensions after the ratification of the 20191213 version of - the unprivileged specification. - - - const: zifencei - description: - The standard Zifencei extension for instruction-fetch fence, as - ratified in the 20191213 version of the unprivileged ISA - specification. - - - const: zihintpause - description: - The standard Zihintpause extension for pause hints, as ratified in - commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual. - - - const: zihintntl - description: - The standard Zihintntl extension for non-temporal locality hints, as - ratified in commit 0dc91f5 ("Zihintntl is ratified") of the - riscv-isa-manual. - - - const: zihpm - description: - The standard Zihpm extension for hardware performance counters, as - ratified in the 20191213 version of the unprivileged ISA - specification. - - - const: zimop - description: - The standard Zimop extension version 1.0, as ratified in commit - 58220614a5f ("Zimop is ratified/1.0") of the riscv-isa-manual. - - const: ztso description: The standard Ztso extension for total store ordering, as ratified @@ -809,18 +809,18 @@ properties: instructions, as ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto. - - const: zvksh - description: | - The standard Zvksh extension for ShangMi suite: SM3 secure hash - instructions, as ratified in commit 56ed795 ("Update - riscv-crypto-spec-vector.adoc") of riscv-crypto. - - const: zvksg description: The standard Zvksg extension for ShangMi algorithm suite with GCM instructions, as ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto. + - const: zvksh + description: | + The standard Zvksh extension for ShangMi suite: SM3 secure hash + instructions, as ratified in commit 56ed795 ("Update + riscv-crypto-spec-vector.adoc") of riscv-crypto. + - const: zvkt description: The standard Zvkt extension for vector data-independent execution diff --git a/Documentation/devicetree/bindings/rtc/epson,rx6110.txt b/Documentation/devicetree/bindings/rtc/epson,rx6110.txt deleted file mode 100644 index 3dc313e01f77..000000000000 --- a/Documentation/devicetree/bindings/rtc/epson,rx6110.txt +++ /dev/null @@ -1,39 +0,0 @@ -Epson RX6110 Real Time Clock -============================ - -The Epson RX6110 can be used with SPI or I2C busses. The kind of -bus depends on the SPISEL pin and can not be configured via software. - -I2C mode --------- - -Required properties: - - compatible: should be: "epson,rx6110" - - reg : the I2C address of the device for I2C - -Example: - - rtc: rtc@32 { - compatible = "epson,rx6110" - reg = <0x32>; - }; - -SPI mode --------- - -Required properties: - - compatible: should be: "epson,rx6110" - - reg: chip select number - - spi-cs-high: RX6110 needs chipselect high - - spi-cpha: RX6110 works with SPI shifted clock phase - - spi-cpol: RX6110 works with SPI inverse clock polarity - -Example: - - rtc: rtc@3 { - compatible = "epson,rx6110" - reg = <3> - spi-cs-high; - spi-cpha; - spi-cpol; - }; diff --git a/Documentation/devicetree/bindings/rtc/epson,rx6110.yaml b/Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file mode 100644 index 000000000000..55086ac7d1e2 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/epson,rx6110.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/epson,rx6110.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Epson RX6110 Real Time Clock + +description: + The Epson RX6110 can be used with SPI or I2C busses. The kind of bus depends + on the SPISEL pin and cannot be configured via software. + +maintainers: + - Alexandre Belloni + +allOf: + - $ref: rtc.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + const: epson,rx6110 + + reg: + maxItems: 1 + + spi-cs-high: true + spi-cpha: true + spi-cpol: true + +required: + - compatible + - reg + +dependencies: + spi-cs-high: [ spi-cpha, spi-cpol ] + spi-cpha: [ spi-cs-high, spi-cpol ] + spi-cpol: [ spi-cs-high, spi-cpha ] + +unevaluatedProperties: false + +examples: + # I2C mode + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@32 { + compatible = "epson,rx6110"; + reg = <0x32>; + }; + }; + + # SPI mode + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + rtc@3 { + compatible = "epson,rx6110"; + reg = <3>; + spi-cs-high; + spi-cpha; + spi-cpol; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml b/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml index 98d10e680144..9b2796804f07 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml @@ -31,6 +31,7 @@ properties: - epson,rx8025 - isil,isl12057 - epson,rx8130 + - epson,rx8901 - items: - enum: diff --git a/Documentation/devicetree/bindings/rtc/st,m41t93.yaml b/Documentation/devicetree/bindings/rtc/st,m41t93.yaml new file mode 100644 index 000000000000..bdd995c5c1f4 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/st,m41t93.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/st,m41t93.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST M41T93 RTC and compatible + +maintainers: + - Akhilesh Patil + +description: + ST M41T93 is spi based Real Time Clock (RTC) with time, date, + alarm, watchdog, square wave clock output, 8 bit timer and + 7 bytes of user SRAM. + +properties: + compatible: + enum: + - st,m41t93 + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + +required: + - compatible + - reg + +allOf: + - $ref: rtc.yaml + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + rtc@0 { + compatible = "st,m41t93"; + reg = <0>; + #clock-cells = <0>; + spi-max-frequency = <2000000>; + }; + }; + diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index 722176c831aa..f4d0eed98a08 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -30,6 +30,8 @@ properties: - aspeed,ast2500-rtc # ASPEED BMC ast2600 Real-time Clock - aspeed,ast2600-rtc + # ASPEED BMC ast2700 Real-time Clock + - aspeed,ast2700-rtc # Conexant Digicolor Real Time Clock Controller - cnxt,cx92755-rtc # I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml index 2eed2277511f..4988e7ed6e34 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml @@ -21,6 +21,7 @@ properties: - qcom,sc8280xp-lpass-rx-macro - items: - enum: + - qcom,eliza-lpass-rx-macro - qcom,kaanapali-lpass-rx-macro - qcom,sm8650-lpass-rx-macro - qcom,sm8750-lpass-rx-macro diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml index e5e65e226a02..d8682ff2e82c 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml @@ -21,6 +21,7 @@ properties: - qcom,sc8280xp-lpass-tx-macro - items: - enum: + - qcom,eliza-lpass-tx-macro - qcom,kaanapali-lpass-tx-macro - qcom,sm8650-lpass-tx-macro - qcom,sm8750-lpass-tx-macro diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml index 5c42b2b323ee..aea31fbdad37 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml @@ -21,6 +21,7 @@ properties: - qcom,sc8280xp-lpass-va-macro - items: - enum: + - qcom,eliza-lpass-va-macro - qcom,glymur-lpass-va-macro - qcom,kaanapali-lpass-va-macro - qcom,sm8650-lpass-va-macro diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml index d5f22b5cf021..9fedd80532e2 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml @@ -20,6 +20,7 @@ properties: - qcom,sc8280xp-lpass-wsa-macro - items: - enum: + - qcom,eliza-lpass-wsa-macro - qcom,glymur-lpass-wsa-macro - qcom,kaanapali-lpass-wsa-macro - qcom,sm8650-lpass-wsa-macro diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 15f38622b98b..dae440ecab59 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -23,6 +23,7 @@ properties: - const: qcom,sdm845-sndcard - items: - enum: + - qcom,eliza-sndcard - qcom,kaanapali-sndcard - qcom,sm8550-sndcard - qcom,sm8650-sndcard diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5640.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5640.yaml index 2eb631950963..922fe161f4d7 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt5640.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt5640.yaml @@ -135,7 +135,6 @@ properties: required: - compatible - reg - - interrupts unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml index 8ebebcebca16..95a5bd894e93 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml @@ -50,10 +50,15 @@ properties: - enum: - mscc,ocelot-spi - mscc,jaguar2-spi - - renesas,rzn1-spi - sophgo,sg2042-spi - thead,th1520-spi - const: snps,dw-apb-ssi + - description: Vendor controllers which use snps,dwc-ssi-2.00a as fallback + items: + - enum: + - starfive,jhb100-spi + - const: snps,dwc-ssi-2.00a + - const: snps,dwc-ssi-1.01a - description: Intel Keem Bay SPI Controller const: intel,keembay-ssi - description: Intel Mount Evans Integrated Management Complex SPI Controller @@ -88,6 +93,9 @@ properties: - const: ssi_clk - const: pclk + power-domains: + maxItems: 1 + resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml index e82c7f8d0b98..5d86cc87e4fb 100644 --- a/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml +++ b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml @@ -24,7 +24,11 @@ allOf: properties: compatible: - const: spacemit,k1-spi + oneOf: + - const: spacemit,k1-spi + - items: + - const: spacemit,k3-spi + - const: spacemit,k1-spi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spmi/qcom,glymur-spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,glymur-spmi-pmic-arb.yaml index 3b5005b96c6d..1593a1183a36 100644 --- a/Documentation/devicetree/bindings/spmi/qcom,glymur-spmi-pmic-arb.yaml +++ b/Documentation/devicetree/bindings/spmi/qcom,glymur-spmi-pmic-arb.yaml @@ -25,6 +25,7 @@ properties: oneOf: - items: - enum: + - qcom,hawi-spmi-pmic-arb - qcom,kaanapali-spmi-pmic-arb - const: qcom,glymur-spmi-pmic-arb - enum: diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml index e28612510d67..8cfa44dcda58 100644 --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml @@ -87,9 +87,12 @@ examples: amlogic,ao-secure = <&sec_AO>; }; - | + #include + #include + temperature-sensor@20000 { compatible = "amlogic,t7-thermal"; - reg = <0x0 0x20000 0x0 0x50>; + reg = <0x20000 0x50>; interrupts = ; clocks = <&clkc_periphs CLKID_TS>; #thermal-sensor-cells = <0>; diff --git a/Documentation/devicetree/bindings/ufs/qcom,sa8255p-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sa8255p-ufshc.yaml index db165a235cb6..66d73e9025d6 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,sa8255p-ufshc.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,sa8255p-ufshc.yaml @@ -18,7 +18,14 @@ properties: - const: qcom,sa8255p-ufshc reg: - maxItems: 1 + minItems: 1 + maxItems: 2 + + reg-names: + minItems: 1 + items: + - const: std + - const: mcq interrupts: maxItems: 1 diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst index f52ab2df2569..d08cee98e34a 100644 --- a/Documentation/driver-api/ipmi.rst +++ b/Documentation/driver-api/ipmi.rst @@ -495,7 +495,7 @@ tuned to the user's desired performance. The driver supports a hot add and remove of interfaces. This way, interfaces can be added or removed after the kernel is up and running. -This is done using /sys/modules/ipmi_si/parameters/hotmod, which is a +This is done using /sys/module/ipmi_si/parameters/hotmod, which is a write-only parameter. You write a string to this interface. The string has the format:: diff --git a/Documentation/driver-api/uio-howto.rst b/Documentation/driver-api/uio-howto.rst index 907ffa3b38f5..c08472dfbcfe 100644 --- a/Documentation/driver-api/uio-howto.rst +++ b/Documentation/driver-api/uio-howto.rst @@ -246,10 +246,10 @@ the members are required, others are optional. hardware interrupt number. The flags given here will be used in the call to :c:func:`request_irq()`. -- ``int (*mmap)(struct uio_info *info, struct vm_area_struct *vma)``: +- ``int (*mmap_prepare)(struct uio_info *info, struct vm_area_desc *desc)``: Optional. If you need a special :c:func:`mmap()` function, you can set it here. If this pointer is not NULL, your - :c:func:`mmap()` will be called instead of the built-in one. + ``mmap_prepare`` will be called instead of the built-in one. - ``int (*open)(struct uio_info *info, struct inode *inode)``: Optional. You might want to have your own :c:func:`open()`, diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index f3d744c76061..e26efdfbb6b4 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -12,7 +12,7 @@ | arm64: | ok | | csky: | TODO | | hexagon: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | diff --git a/Documentation/filesystems/smb/ksmbd.rst b/Documentation/filesystems/smb/ksmbd.rst index 67cb68ea6e68..672c5d3892ff 100644 --- a/Documentation/filesystems/smb/ksmbd.rst +++ b/Documentation/filesystems/smb/ksmbd.rst @@ -97,7 +97,7 @@ ACLs Partially Supported. only DACLs available, SACLs to allow future support for running as a domain member. Kerberos Supported. -Durable handle v1,v2 Planned for future. +Durable handle v1,v2 Supported. Persistent handle Planned for future. SMB2 notify Planned for future. Sparse file support Supported. @@ -111,7 +111,7 @@ DCE/RPC support Partially Supported. a few calls(NetShareEnumAll, for Witness protocol e.g.) ksmbd/nfsd interoperability Planned for future. The features that ksmbd support are Leases, Notify, ACLs and Share modes. -SMB3.1.1 Compression Planned for future. +SMB3.1.1 Compression Supported. SMB3.1.1 over QUIC Planned for future. Signing/Encryption over RDMA Planned for future. SMB3.1.1 GMAC signing support Planned for future. diff --git a/Documentation/hwmon/ltc4283.rst b/Documentation/hwmon/ltc4283.rst index a650c595bc8f..99b1ee05f629 100644 --- a/Documentation/hwmon/ltc4283.rst +++ b/Documentation/hwmon/ltc4283.rst @@ -256,7 +256,7 @@ these logs can be cleared by writing in the proper reset_history attribute. ``/sys/kernel/debug/i2c/i2c-[X]/[X]-addr/`` contains the following attributes: -======================= ========================================== +============================== ========================================================== power1_failed_fault_log Set to 1 by a power1 fault occurring. power1_good_input_fault_log Set to 1 by a power1 good input fault occurring at PGIO3. in11_fet_short_fault_log Set to 1 when a FET-short fault occurs. @@ -264,4 +264,4 @@ in11_fet_bad_fault_log Set to 1 when a FET-BAD fault occurs. in0_lcrit_fault_log Set to 1 by a VIN undervoltage fault occurring. in0_crit_fault_log Set to 1 by a VIN overvoltage fault occurring. curr1_crit_fault_log Set to 1 by an overcurrent fault occurring. -======================= ========================================== +============================== ========================================================== diff --git a/Documentation/input/userio.rst b/Documentation/input/userio.rst index f780c77931fe..7aaaa629bde0 100644 --- a/Documentation/input/userio.rst +++ b/Documentation/input/userio.rst @@ -5,7 +5,7 @@ The userio Protocol =================== -:Copyright: |copy| 2015 Stephen Chandler Paul +:Copyright: |copy| 2015 Lyude Paul Sponsored by Red Hat @@ -66,8 +66,27 @@ USERIO_CMD_SET_PORT_TYPE ~~~~~~~~~~~~~~~~~~~~~~~~ Sets the type of port we're emulating, where ``data`` is the port type being -set. Can be any of the macros from . For example: SERIO_8042 -would set the port type to be a normal PS/2 port. +set. Can be any of the serio type macros from . For example: +SERIO_8042 would set the port type to be a normal PS/2 port. + +USERIO_CMD_SET_PORT_PROTO +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Sets the protocol of port we're emulating, where ``data`` is the protocol being +set. Can be any of the serio proto macros from . For example: +SERIO_IFORCE would set the port type to be an I-Force serial joystick. + +USERIO_CMD_SET_PORT_ID +~~~~~~~~~~~~~~~~~~~~~~ + +Sets the ``id`` value on the identification of port we're emulating, where +``data`` is the value being set. + +USERIO_CMD_SET_PORT_EXTRA +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Sets the ``extra`` value on the identification of port we're emulating, where +``data`` is the value being set. USERIO_CMD_SEND_INTERRUPT ~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/kbuild/kconfig.rst b/Documentation/kbuild/kconfig.rst index d213c4f599a4..e35dd1d5f9d3 100644 --- a/Documentation/kbuild/kconfig.rst +++ b/Documentation/kbuild/kconfig.rst @@ -59,6 +59,11 @@ Environment variables for ``*config``: This environment variable makes Kconfig warn about all unrecognized symbols in the config input. +``KCONFIG_WARN_CHANGED_INPUT`` + If set to a non-blank value, Kconfig prints optional warnings for + user-provided values that change after Kconfig resolves dependencies + or applies other constraints such as ranges. + ``KCONFIG_WERROR`` If set, Kconfig treats warnings as errors. diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst index 7aa2a8886908..13a79f5d092c 100644 --- a/Documentation/mm/index.rst +++ b/Documentation/mm/index.rst @@ -7,6 +7,19 @@ of Linux. If you are looking for advice on simply allocating memory, see the :ref:`memory_allocation`. For controlling and tuning guides, see the :doc:`admin guide <../admin-guide/mm/index>`. +.. note:: + + Unfortunately, parts of this guide are still incomplete or missing. + While we appreciate contributions, documentation in this area is hard + to get right and requires a lot of attention to detail. New contributors + should reach out to the relevant maintainers early. + + This guide is expected to reflect reality, which requires contributors + to have a detailed understanding. Documentation generated with LLMs + by contributors unfamiliar with these details shifts the real work onto + reviewers, which is why such contributions will be rejected without + further comment. + .. toctree:: :maxdepth: 1 diff --git a/Documentation/netlink/specs/ovpn.yaml b/Documentation/netlink/specs/ovpn.yaml index b0c782e59a32..ac50d1d7c00a 100644 --- a/Documentation/netlink/specs/ovpn.yaml +++ b/Documentation/netlink/specs/ovpn.yaml @@ -118,12 +118,16 @@ attribute-sets: doc: >- The number of seconds after which a keep alive message is sent to the peer + checks: + max: 86400 - name: keepalive-timeout type: u32 doc: >- The number of seconds from the last activity after which the peer is assumed dead + checks: + max: 86400 - name: del-reason type: u32 diff --git a/Documentation/netlink/specs/rt-link.yaml b/Documentation/netlink/specs/rt-link.yaml index 892979da098e..68c26a70bb64 100644 --- a/Documentation/netlink/specs/rt-link.yaml +++ b/Documentation/netlink/specs/rt-link.yaml @@ -1585,31 +1585,31 @@ attribute-sets: type: u32 - name: mode - type: flag + type: u8 - name: guard - type: flag + type: u8 - name: protect - type: flag + type: u8 - name: fast-leave - type: flag + type: u8 - name: learning - type: flag + type: u8 - name: unicast-flood - type: flag + type: u8 - name: proxyarp - type: flag + type: u8 - name: learning-sync - type: flag + type: u8 - name: proxyarp-wifi - type: flag + type: u8 - name: root-id type: binary @@ -1656,34 +1656,34 @@ attribute-sets: type: pad - name: mcast-flood - type: flag + type: u8 - name: mcast-to-ucast - type: flag + type: u8 - name: vlan-tunnel - type: flag + type: u8 - name: bcast-flood - type: flag + type: u8 - name: group-fwd-mask type: u16 - name: neigh-suppress - type: flag + type: u8 - name: isolated - type: flag + type: u8 - name: backup-port type: u32 - name: mrp-ring-open - type: flag + type: u8 - name: mrp-in-open - type: flag + type: u8 - name: mcast-eht-hosts-limit type: u32 @@ -1692,10 +1692,10 @@ attribute-sets: type: u32 - name: locked - type: flag + type: u8 - name: mab - type: flag + type: u8 - name: mcast-n-groups type: u32 @@ -1704,7 +1704,7 @@ attribute-sets: type: u32 - name: neigh-vlan-suppress - type: flag + type: u8 - name: backup-nhid type: u32 diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index 50d92084a49c..cc3f0d16b28f 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -43,12 +43,13 @@ UMEM also has two rings: the FILL ring and the COMPLETION ring. The FILL ring is used by the application to send down addr for the kernel to fill in with RX packet data. References to these frames will then appear in the RX ring once each packet has been received. The -COMPLETION ring, on the other hand, contains frame addr that the -kernel has transmitted completely and can now be used again by user -space, for either TX or RX. Thus, the frame addrs appearing in the -COMPLETION ring are addrs that were previously transmitted using the -TX ring. In summary, the RX and FILL rings are used for the RX path -and the TX and COMPLETION rings are used for the TX path. +COMPLETION ring, on the other hand, contains frame addresses from Tx +descriptors that the kernel has finished processing and that can now be +used again by user space, for either Tx or Rx. This includes frames whose +transmission has completed as well as frames referenced by invalid Tx +descriptors rejected by the kernel. A completion therefore returns +ownership of a frame to user space, but does not by itself guarantee that +the packet was successfully transmitted. The socket is then finally bound with a bind() call to a device and a specific queue id on that device, and it is not until bind is @@ -169,14 +170,15 @@ chunks mode, then the incoming addr will be left untouched. UMEM Completion Ring ~~~~~~~~~~~~~~~~~~~~ -The COMPLETION Ring is used transfer ownership of UMEM frames from +The COMPLETION Ring is used to transfer ownership of UMEM frames from kernel-space to user-space. Just like the FILL ring, UMEM indices are -used. - -Frames passed from the kernel to user-space are frames that has been -sent (TX ring) and can be used by user-space again. - -The user application consumes UMEM addrs from this ring. +used. Frames passed from the kernel to user-space are frames referenced +by Tx descriptors that the kernel has finished processing and can be +used by user-space again. This includes both frames whose transmission +has completed and frames referenced by invalid Tx descriptors that were +rejected and reclaimed by the kernel. A completion entry does not +guarantee successful packet transmission. The user application consumes +UMEM addrs from this ring. RX Ring @@ -504,21 +506,25 @@ will be treated as an invalid descriptor. These are the semantics for producing packets onto AF_XDP Tx ring consisting of multiple frames: -* When an invalid descriptor is found, all the other - descriptors/frames of this packet are marked as invalid and not - completed. The next descriptor is treated as the start of a new - packet, even if this was not the intent (because we cannot guess - the intent). As before, if your program is producing invalid - descriptors you have a bug that must be fixed. +* When an invalid descriptor is found, the complete packet is treated as + invalid. The kernel consumes descriptors through the descriptor marking + the end of the packet and returns all their frame addresses through the + COMPLETION ring. A standalone invalid descriptor is treated as a + one-descriptor invalid packet. The descriptor following the end of the + invalid packet is treated as the start of a new packet. As before, if + your program is producing invalid descriptors you have a bug that must + be fixed. Rejected descriptors are reported in the ``tx_invalid_descs`` + statistic. * Zero length descriptors are treated as invalid descriptors. * For copy mode, the maximum supported number of frames in a packet is - equal to CONFIG_MAX_SKB_FRAGS + 1. If it is exceeded, all - descriptors accumulated so far are dropped and treated as - invalid. To produce an application that will work on any system - regardless of this config setting, limit the number of frags to 18, - as the minimum value of the config is 17. + equal to CONFIG_MAX_SKB_FRAGS + 1. If it is exceeded, all descriptors + through the end of the oversized packet are consumed, treated as invalid, + and their frame addresses are returned through the COMPLETION ring. To + produce an application that will work on any system regardless of this + config setting, limit the number of frags to 18, as the minimum value of + the config is 17. * For zero-copy mode, the limit is up to what the NIC HW supports. Usually at least five on the NICs we have checked. We diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index fde601acd1d2..d2a238f8cc8b 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -433,6 +433,8 @@ exceptions) notifiers run under the instance lock. Please extend this documentation whenever you make explicit assumption about lock being held from a notifier. +Drivers **must not** generate nested notifications of the ops-locked types. + NETDEV_INTERNAL symbol namespace ================================ diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 1ca8c5f73ad0..0aa232b117b5 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -147,11 +147,6 @@ Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel modules as well. This requires pahole v1.22 or later. -Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole v1.26 -or later. Without it, such kfuncs will have incorrect BTF prototypes in -vmlinux, causing BPF programs to fail to load with a "func_proto incompatible -with vmlinux" error. Many sched_ext kfuncs are affected. - It is found in the 'dwarves' or 'pahole' distro packages or from https://fedorapeople.org/~acme/dwarves/. diff --git a/Documentation/process/debugging/kgdb.rst b/Documentation/process/debugging/kgdb.rst index c4d0a9121d52..316b1d74e9c8 100644 --- a/Documentation/process/debugging/kgdb.rst +++ b/Documentation/process/debugging/kgdb.rst @@ -513,7 +513,7 @@ unregister all the kernel hook points. All kgdb I/O drivers can be reconfigured at run time, if ``CONFIG_SYSFS`` and ``CONFIG_MODULES`` are enabled, by echo'ing a new -config string to ``/sys/module//parameter/