diff options
Diffstat (limited to 'Documentation')
168 files changed, 5663 insertions, 992 deletions
diff --git a/Documentation/ABI/stable/sysfs-bus-nvmem b/Documentation/ABI/stable/sysfs-bus-nvmem index aa89adf18bc5..0ae8cb074acf 100644 --- a/Documentation/ABI/stable/sysfs-bus-nvmem +++ b/Documentation/ABI/stable/sysfs-bus-nvmem @@ -11,7 +11,7 @@ Description: Read returns '0' or '1' for read-write or read-only modes respectively. Write parses one of 'YyTt1NnFf0', or [oO][NnFf] for "on" - and "off", i.e. what kstrbool() supports. + and "off", i.e. what kstrtobool() supports. Note: This file is only present if CONFIG_NVMEM_SYSFS is enabled. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-acm b/Documentation/ABI/testing/configfs-usb-gadget-acm index d21092d75a05..25e68be9eb66 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-acm +++ b/Documentation/ABI/testing/configfs-usb-gadget-acm @@ -6,3 +6,10 @@ Description: This item contains just one readonly attribute: port_num. It contains the port number of the /dev/ttyGS<n> device associated with acm function's instance "name". + +What: /config/usb-gadget/gadget/functions/acm.name/protocol +Date: Aug 2024 +KernelVersion: 6.13 +Description: + Reported bInterfaceProtocol for the ACM device. For legacy + reasons, this defaults to 1 (USB_CDC_ACM_PROTO_AT_V25TER). diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index c4ba92f004c3..64188a85592b 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -30,4 +30,12 @@ Description: req_number the number of pre-allocated requests for both capture and playback function_name name of the interface + p_it_name playback input terminal name + p_it_ch_name playback channels name + p_ot_name playback output terminal name + p_fu_vol_name playback mute/volume functional unit name + c_it_name capture input terminal name + c_it_ch_name capture channels name + c_ot_name capture output terminal name + c_fu_vol_name capture mute/volume functional unit name ===================== ======================================= diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index a2bf4fd82a5b..133e995c3e92 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -35,6 +35,17 @@ Description: req_number the number of pre-allocated requests for both capture and playback function_name name of the interface + if_ctrl_name topology control name + clksrc_in_name input clock name + clksrc_out_name output clock name + p_it_name playback input terminal name + p_it_ch_name playback input first channel name + p_ot_name playback output terminal name + p_fu_vol_name playback mute/volume function unit name + c_it_name capture input terminal name + c_it_ch_name capture input first channel name + c_ot_name capture output terminal name + c_fu_vol_name capture mute/volume functional unit name c_terminal_type code of the capture terminal type p_terminal_type code of the playback terminal type ===================== ======================================= diff --git a/Documentation/ABI/testing/debugfs-iio-ad9467 b/Documentation/ABI/testing/debugfs-iio-ad9467 new file mode 100644 index 000000000000..0352fca1f7f2 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-iio-ad9467 @@ -0,0 +1,39 @@ +What: /sys/kernel/debug/iio/iio:deviceX/calibration_table_dump +KernelVersion: 6.11 +Contact: linux-iio@vger.kernel.org +Description: + This dumps the calibration table that was filled during the + digital interface tuning process. + +What: /sys/kernel/debug/iio/iio:deviceX/in_voltage_test_mode_available +KernelVersion: 6.11 +Contact: linux-iio@vger.kernel.org +Description: + List all the available test tones: + - off + - midscale_short + - pos_fullscale + - neg_fullscale + - checkerboard + - prbs23 + - prbs9 + - one_zero_toggle + - user + - bit_toggle + - sync + - one_bit_high + - mixed_bit_frequency + - ramp + + Note that depending on the actual device being used, some of the + above might not be available (and they won't be listed when + reading the file). + +What: /sys/kernel/debug/iio/iio:deviceX/in_voltageY_test_mode +KernelVersion: 6.11 +Contact: linux-iio@vger.kernel.org +Description: + Writing to this file will initiate one of available test tone on + channel Y. Reading it, shows which test is running. In cases + where an IIO backend is available and supports the test tone, + additional information about the data correctness is given. diff --git a/Documentation/ABI/testing/debugfs-iio-backend b/Documentation/ABI/testing/debugfs-iio-backend new file mode 100644 index 000000000000..01ab94469432 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-iio-backend @@ -0,0 +1,20 @@ +What: /sys/kernel/debug/iio/iio:deviceX/backendY/name +KernelVersion: 6.11 +Contact: linux-iio@vger.kernel.org +Description: + Name of Backend Y connected to device X. + +What: /sys/kernel/debug/iio/iio:deviceX/backendY/direct_reg_access +KernelVersion: 6.11 +Contact: linux-iio@vger.kernel.org +Description: + Directly access the registers of backend Y. Typical usage is: + + Reading address 0x50 + echo 0x50 > direct_reg_access + cat direct_reg_access + + Writing address 0x50 + echo 0x50 0x3 > direct_reg_access + //readback address 0x50 + cat direct_reg_access diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 7cee78ad4108..89943c2d54e8 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -523,13 +523,27 @@ Description: What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_i_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_q_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_capacitance_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias -What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias -What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_intensityY_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_proximity_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_temp_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibbias +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_calibbias +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_calibbias KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -541,6 +555,10 @@ Description: What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available +What: /sys/bus/iio/devices/iio:deviceX/in_temp_calibbias_available +What: /sys/bus/iio/devices/iio:deviceX/in_proximity_calibbias_available +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibbias_available +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_calibbias_available KernelVersion: 5.8 Contact: linux-iio@vger.kernel.org Description: @@ -549,25 +567,34 @@ Description: - a small discrete set of values like "0 2 4 6 8" - a range specified as "[min step max]" -What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_capacitance_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_both_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ir_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale -What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_calibscale +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_calibscale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -575,6 +602,20 @@ Description: production inaccuracies). If shared across all channels, <type>_calibscale is used. +What: /sys/bus/iio/devices/iio:deviceX/in_illuminanceY_calibscale_available +What: /sys/bus/iio/devices/iio:deviceX/in_intensityY_calibscale_available +What: /sys/bus/iio/devices/iio:deviceX/in_proximityY_calibscale_available +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale_available +KernelVersion: 4.8 +Contact: linux-iio@vger.kernel.org +Description: + Available values of calibscale. Maybe expressed as either of: + + - a small discrete set of values like "1 8 16" + - a range specified as "[min step max]" + + If shared across all channels, <type>_calibscale_available is used. + What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender @@ -708,6 +749,7 @@ Description: 2.5kohm_to_gnd: connected to ground via a 2.5kOhm resistor, 6kohm_to_gnd: connected to ground via a 6kOhm resistor, 20kohm_to_gnd: connected to ground via a 20kOhm resistor, + 42kohm_to_gnd: connected to ground via a 42kOhm resistor, 90kohm_to_gnd: connected to ground via a 90kOhm resistor, 100kohm_to_gnd: connected to ground via an 100kOhm resistor, 125kohm_to_gnd: connected to ground via an 125kOhm resistor, @@ -2289,3 +2331,11 @@ KernelVersion: 6.7 Contact: linux-iio@vger.kernel.org Description: List of available timeout value for tap gesture confirmation. + +What: /sys/.../iio:deviceX/in_shunt_resistor +What: /sys/.../iio:deviceX/in_current_shunt_resistor +What: /sys/.../iio:deviceX/in_power_shunt_resistor +KernelVersion: 6.10 +Contact: linux-iio@vger.kernel.org +Description: + The value of current sense resistor in Ohms. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 deleted file mode 100644 index 6d2d2b094941..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 +++ /dev/null @@ -1,17 +0,0 @@ -What: /sys/bus/iio/devices/iio:deviceX/in_power_shunt_resistor -Date: March 2017 -KernelVersion: 4.12 -Contact: linux-iio@vger.kernel.org -Description: The value of the shunt resistor used to compute power drain on - common input voltage pin (RS+). In Ohms. - -What: /sys/bus/iio/devices/iio:deviceX/in_current_shunt_resistor -Date: March 2017 -KernelVersion: 4.12 -Contact: linux-iio@vger.kernel.org -Description: The value of the shunt resistor used to compute current flowing - between RS+ and RS- voltage sense inputs. In Ohms. - -These attributes describe a single physical component, exposed as two distinct -attributes as it is used to calculate two different values: power load and -current flowing between RS+ and RS- inputs. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 index 469a7c00fad4..a95547e874f1 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 @@ -15,17 +15,3 @@ Description: Set the relative humidity. This value is sent to the sensor for humidity compensation. Default value: 50000 (50 % relative humidity) - -What: /sys/bus/iio/devices/iio:deviceX/in_resistance_calibbias -Date: August 2021 -KernelVersion: 5.15 -Contact: Andreas Klinger <ak@it-klinger.de> -Description: - Set the bias value for the resistance which is used for - calculation of in_concentration_input as follows: - - x = (in_resistance_raw - in_resistance_calibbias) * 0.65 - - in_concentration_input = 500 / (1 + e^x) - - Default value: 30000 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac b/Documentation/ABI/testing/sysfs-bus-iio-dac new file mode 100644 index 000000000000..810eaac5533c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-dac @@ -0,0 +1,61 @@ +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_toggle_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Toggle enable. Write 1 to enable toggle or 0 to disable it. This + is useful when one wants to change the DAC output codes. For + autonomous toggling, the way it should be done is: + + - disable toggle operation; + - change out_currentY_rawN, where N is the integer value of the symbol; + - enable toggle operation. + +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_rawN +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + This attribute has the same meaning as out_currentY_raw. It is + specific to toggle enabled channels and refers to the DAC output + code in INPUT_N (_rawN), where N is the integer value of the symbol. + The same scale and offset as in out_currentY_raw applies. + +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_symbol +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Performs a SW switch to a predefined output symbol. This attribute + is specific to toggle enabled channels and allows switching between + multiple predefined symbols. Each symbol corresponds to a different + output, denoted as out_currentY_rawN, where N is the integer value + of the symbol. Writing an integer value N will select out_currentY_rawN. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_toggle_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Toggle enable. Write 1 to enable toggle or 0 to disable it. This + is useful when one wants to change the DAC output codes. For + autonomous toggling, the way it should be done is: + + - disable toggle operation; + - change out_voltageY_rawN, where N is the integer value of the symbol; + - enable toggle operation. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_rawN +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + This attribute has the same meaning as out_currentY_raw. It is + specific to toggle enabled channels and refers to the DAC output + code in INPUT_N (_rawN), where N is the integer value of the symbol. + The same scale and offset as in out_currentY_raw applies. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_symbol +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Performs a SW switch to a predefined output symbol. This attribute + is specific to toggle enabled channels and allows switching between + multiple predefined symbols. Each symbol corresponds to a different + output, denoted as out_voltageY_rawN, where N is the integer value + of the symbol. Writing an integer value N will select out_voltageY_rawN. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 index 1c35971277ba..ae95a5477382 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 +++ b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 @@ -53,34 +53,3 @@ KernelVersion: 5.18 Contact: linux-iio@vger.kernel.org Description: Returns the available values for the dither phase. - -What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_toggle_en -KernelVersion: 5.18 -Contact: linux-iio@vger.kernel.org -Description: - Toggle enable. Write 1 to enable toggle or 0 to disable it. This is - useful when one wants to change the DAC output codes. The way it should - be done is: - - - disable toggle operation; - - change out_voltageY_raw0 and out_voltageY_raw1; - - enable toggle operation. - -What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw0 -What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw1 -KernelVersion: 5.18 -Contact: linux-iio@vger.kernel.org -Description: - It has the same meaning as out_voltageY_raw. This attribute is - specific to toggle enabled channels and refers to the DAC output - code in INPUT_A (_raw0) and INPUT_B (_raw1). The same scale and offset - as in out_voltageY_raw applies. - -What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_symbol -KernelVersion: 5.18 -Contact: linux-iio@vger.kernel.org -Description: - Performs a SW toggle. This attribute is specific to toggle - enabled channels and allows to toggle between out_voltageY_raw0 - and out_voltageY_raw1 through software. Writing 0 will select - out_voltageY_raw0 while 1 selects out_voltageY_raw1. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 index 31dbb390573f..c431f0a13cf5 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 +++ b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 @@ -3,7 +3,7 @@ KernelVersion: Contact: linux-iio@vger.kernel.org Description: Reading this returns the valid values that can be written to the - on_altvoltage0_mode attribute: + filter_mode attribute: - auto -> Adjust bandpass filter to track changes in input clock rate. - manual -> disable/unregister the clock rate notifier / input clock tracking. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc b/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc index 8916f7ec6507..8dbca113112d 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc +++ b/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc @@ -13,12 +13,3 @@ Description: available for reading data. However, samples can be occasionally skipped or repeated, depending on the beat between the capture and conversion rates. - -What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistor -Date: December 2015 -KernelVersion: 4.4 -Contact: linux-iio@vger.kernel.org -Description: - The value of the shunt resistor may be known only at runtime fom an - eeprom content read by a client application. This attribute allows to - set its value in ohms. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index cad6c3dc1f9c..fdedf1ea944b 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -579,6 +579,12 @@ Description: When ATGC is on, it controls age threshold to bypass GCing young candidates whose age is not beyond the threshold, by default it was initialized as 604800 seconds (equals to 7 days). +What: /sys/fs/f2fs/<disk>/atgc_enabled +Date: Feb 2024 +Contact: "Jinbao Liu" <liujinbao1@xiaomi.com> +Description: It represents whether ATGC is on or off. The value is 1 which + indicates that ATGC is on, and 0 indicates that it is off. + What: /sys/fs/f2fs/<disk>/gc_reclaimed_segments Date: July 2021 Contact: "Daeho Jeong" <daehojeong@google.com> @@ -763,3 +769,53 @@ Date: November 2023 Contact: "Chao Yu" <chao@kernel.org> Description: It controls to enable/disable IO aware feature for background discard. By default, the value is 1 which indicates IO aware is on. + +What: /sys/fs/f2fs/<disk>/blkzone_alloc_policy +Date: July 2024 +Contact: "Yuanhong Liao" <liaoyuanhong@vivo.com> +Description: The zone UFS we are currently using consists of two parts: + conventional zones and sequential zones. It can be used to control which part + to prioritize for writes, with a default value of 0. + + ======================== ========================================= + value description + blkzone_alloc_policy = 0 Prioritize writing to sequential zones + blkzone_alloc_policy = 1 Only allow writing to sequential zones + blkzone_alloc_policy = 2 Prioritize writing to conventional zones + ======================== ========================================= + +What: /sys/fs/f2fs/<disk>/migration_window_granularity +Date: September 2024 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Controls migration window granularity of garbage collection on large + section. it can control the scanning window granularity for GC migration + in a unit of segment, while migration_granularity controls the number + of segments which can be migrated at the same turn. + +What: /sys/fs/f2fs/<disk>/reserved_segments +Date: September 2024 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: In order to fine tune GC behavior, we can control the number of + reserved segments. + +What: /sys/fs/f2fs/<disk>/gc_no_zoned_gc_percent +Date: September 2024 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: If the percentage of free sections over total sections is above this + number, F2FS do not garbage collection for zoned devices through the + background GC thread. the default number is "60". + +What: /sys/fs/f2fs/<disk>/gc_boost_zoned_gc_percent +Date: September 2024 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: If the percentage of free sections over total sections is under this + number, F2FS boosts garbage collection for zoned devices through the + background GC thread. the default number is "25". + +What: /sys/fs/f2fs/<disk>/gc_valid_thresh_ratio +Date: September 2024 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: It controls the valid block ratio threshold not to trigger excessive GC + for zoned deivces. The initial value of it is 95(%). F2FS will stop the + background GC thread from intiating GC for sections having valid blocks + exceeding the ratio. diff --git a/Documentation/admin-guide/device-mapper/delay.rst b/Documentation/admin-guide/device-mapper/delay.rst index 917ba8c33359..4d667228e744 100644 --- a/Documentation/admin-guide/device-mapper/delay.rst +++ b/Documentation/admin-guide/device-mapper/delay.rst @@ -3,29 +3,52 @@ dm-delay ======== Device-Mapper's "delay" target delays reads and/or writes -and maps them to different devices. +and/or flushs and optionally maps them to different devices. -Parameters:: +Arguments:: <device> <offset> <delay> [<write_device> <write_offset> <write_delay> [<flush_device> <flush_offset> <flush_delay>]] -With separate write parameters, the first set is only used for reads. +Table line has to either have 3, 6 or 9 arguments: + +3: apply offset and delay to read, write and flush operations on device + +6: apply offset and delay to device, also apply write_offset and write_delay + to write and flush operations on optionally different write_device with + optionally different sector offset + +9: same as 6 arguments plus define flush_offset and flush_delay explicitely + on/with optionally different flush_device/flush_offset. + Offsets are specified in sectors. + Delays are specified in milliseconds. + Example scripts =============== :: - #!/bin/sh - # Create device delaying rw operation for 500ms - echo "0 `blockdev --getsz $1` delay $1 0 500" | dmsetup create delayed + # + # Create mapped device named "delayed" delaying read, write and flush operations for 500ms. + # + dmsetup create delayed --table "0 `blockdev --getsz $1` delay $1 0 500" :: + #!/bin/sh + # + # Create mapped device delaying write and flush operations for 400ms and + # splitting reads to device $1 but writes and flushs to different device $2 + # to different offsets of 2048 and 4096 sectors respectively. + # + dmsetup create delayed --table "0 `blockdev --getsz $1` delay $1 2048 0 $2 4096 400" +:: #!/bin/sh - # Create device delaying only write operation for 500ms and - # splitting reads and writes to different devices $1 $2 - echo "0 `blockdev --getsz $1` delay $1 0 0 $2 0 500" | dmsetup create delayed + # + # Create mapped device delaying reads for 50ms, writes for 100ms and flushs for 333ms + # onto the same backing device at offset 0 sectors. + # + dmsetup create delayed --table "0 `blockdev --getsz $1` delay $1 0 50 $2 0 100 $1 0 333" diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst b/Documentation/admin-guide/device-mapper/dm-crypt.rst index 48a48bd09372..9f8139ff97d6 100644 --- a/Documentation/admin-guide/device-mapper/dm-crypt.rst +++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst @@ -160,6 +160,10 @@ iv_large_sectors The <iv_offset> must be multiple of <sector_size> (in 512 bytes units) if this flag is specified. +integrity_key_size:<bytes> + Use an integrity key of <bytes> size instead of using an integrity key size + of the digest size of the used HMAC algorithm. + Module parameters:: max_read_size diff --git a/Documentation/admin-guide/device-mapper/vdo.rst b/Documentation/admin-guide/device-mapper/vdo.rst index c69ac186863a..a14e6d3e787c 100644 --- a/Documentation/admin-guide/device-mapper/vdo.rst +++ b/Documentation/admin-guide/device-mapper/vdo.rst @@ -251,7 +251,12 @@ The messages are: by the vdostats userspace program to interpret the output buffer. - dump: + config: + Outputs useful vdo configuration information. Mostly used + by users who want to recreate a similar VDO volume and + want to know the creation configuration used. + + dump: Dumps many internal structures to the system log. This is not always safe to run, so it should only be used to debug a hung vdo. Optional parameters to specify structures to diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bb48ae24ae69..1518343bbe22 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2677,6 +2677,23 @@ Default is Y (on). + kvm.enable_virt_at_load=[KVM,ARM64,LOONGARCH,MIPS,RISCV,X86] + If enabled, KVM will enable virtualization in hardware + when KVM is loaded, and disable virtualization when KVM + is unloaded (if KVM is built as a module). + + If disabled, KVM will dynamically enable and disable + virtualization on-demand when creating and destroying + VMs, i.e. on the 0=>1 and 1=>0 transitions of the + number of VMs. + + Enabling virtualization at module lode avoids potential + latency for creation of the 0=>1 VM, as KVM serializes + virtualization enabling across all online CPUs. The + "cost" of enabling virtualization when KVM is loaded, + is that doing so may interfere with using out-of-tree + hypervisors that want to "own" virtualization hardware. + kvm.enable_vmware_backdoor=[KVM] Support VMware backdoor PV interface. Default is false (don't support). diff --git a/Documentation/arch/arm/mem_alignment.rst b/Documentation/arch/arm/mem_alignment.rst index aa22893b62bc..64bd77959300 100644 --- a/Documentation/arch/arm/mem_alignment.rst +++ b/Documentation/arch/arm/mem_alignment.rst @@ -12,7 +12,7 @@ ones. Of course this is a bad idea to rely on the alignment trap to perform unaligned memory access in general. If those access are predictable, you -are better to use the macros provided by include/asm/unaligned.h. The +are better to use the macros provided by include/linux/unaligned.h. The alignment trap can fixup misaligned access for the exception cases, but at a high performance cost. It better be rare. diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index 9eb5e70b4888..65bfab1b1861 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -146,6 +146,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 | @@ -186,6 +188,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V1 | #1619801 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 | @@ -289,3 +293,5 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 | +----------------+-----------------+-----------------+-----------------------------+ +| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/arch/loongarch/irq-chip-model.rst b/Documentation/arch/loongarch/irq-chip-model.rst index 7988f4192363..6dd48256e39f 100644 --- a/Documentation/arch/loongarch/irq-chip-model.rst +++ b/Documentation/arch/loongarch/irq-chip-model.rst @@ -85,6 +85,38 @@ to CPUINTC directly:: | Devices | +---------+ +Advanced Extended IRQ model +=========================== + +In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt go +to CPUINTC directly, CPU UARTS interrupts go to LIOINTC, PCH-MSI interrupts go +to AVECINTC, and then go to CPUINTC directly, while all other devices interrupts +go to PCH-PIC/PCH-LPC and gathered by EIOINTC, and then go to CPUINTC directly:: + + +-----+ +-----------------------+ +-------+ + | IPI | --> | CPUINTC | <-- | Timer | + +-----+ +-----------------------+ +-------+ + ^ ^ ^ + | | | + +---------+ +----------+ +---------+ +-------+ + | EIOINTC | | AVECINTC | | LIOINTC | <-- | UARTs | + +---------+ +----------+ +---------+ +-------+ + ^ ^ + | | + +---------+ +---------+ + | PCH-PIC | | PCH-MSI | + +---------+ +---------+ + ^ ^ ^ + | | | + +---------+ +---------+ +---------+ + | Devices | | PCH-LPC | | Devices | + +---------+ +---------+ +---------+ + ^ + | + +---------+ + | Devices | + +---------+ + ACPI-related definitions ======================== diff --git a/Documentation/arch/s390/vfio-ap.rst b/Documentation/arch/s390/vfio-ap.rst index ea744cbc8687..eba1991fbdba 100644 --- a/Documentation/arch/s390/vfio-ap.rst +++ b/Documentation/arch/s390/vfio-ap.rst @@ -999,6 +999,36 @@ the vfio_ap mediated device to which it is assigned as long as each new APQN resulting from plugging it in references a queue device bound to the vfio_ap device driver. +Driver Features +=============== +The vfio_ap driver exposes a sysfs file containing supported features. +This exists so third party tools (like Libvirt and mdevctl) can query the +availability of specific features. + +The features list can be found here: /sys/bus/matrix/devices/matrix/features + +Entries are space delimited. Each entry consists of a combination of +alphanumeric and underscore characters. + +Example: +cat /sys/bus/matrix/devices/matrix/features +guest_matrix dyn ap_config + +the following features are advertised: + +---------------+---------------------------------------------------------------+ +| Flag | Description | ++==============+===============================================================+ +| guest_matrix | guest_matrix attribute exists. It reports the matrix of | +| | adapters and domains that are or will be passed through to a | +| | guest when the mdev is attached to it. | ++--------------+---------------------------------------------------------------+ +| dyn | Indicates hot plug/unplug of AP adapters, domains and control | +| | domains for a guest to which the mdev is attached. | ++------------+-----------------------------------------------------------------+ +| ap_config | ap_config interface for one-shot modifications to mdev config | ++--------------+---------------------------------------------------------------+ + Limitations =========== Live guest migration is not supported for guests using AP devices without diff --git a/Documentation/core-api/cleanup.rst b/Documentation/core-api/cleanup.rst new file mode 100644 index 000000000000..527eb2f8ec6e --- /dev/null +++ b/Documentation/core-api/cleanup.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Scope-based Cleanup Helpers +=========================== + +.. kernel-doc:: include/linux/cleanup.h + :doc: scope-based cleanup helpers diff --git a/Documentation/core-api/folio_queue.rst b/Documentation/core-api/folio_queue.rst new file mode 100644 index 000000000000..1fe7a9bc4b8d --- /dev/null +++ b/Documentation/core-api/folio_queue.rst @@ -0,0 +1,212 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +=========== +Folio Queue +=========== + +:Author: David Howells <dhowells@redhat.com> + +.. Contents: + + * Overview + * Initialisation + * Adding and removing folios + * Querying information about a folio + * Querying information about a folio_queue + * Folio queue iteration + * Folio marks + * Lockless simultaneous production/consumption issues + + +Overview +======== + +The folio_queue struct forms a single segment in a segmented list of folios +that can be used to form an I/O buffer. As such, the list can be iterated over +using the ITER_FOLIOQ iov_iter type. + +The publicly accessible members of the structure are:: + + struct folio_queue { + struct folio_queue *next; + struct folio_queue *prev; + ... + }; + +A pair of pointers are provided, ``next`` and ``prev``, that point to the +segments on either side of the segment being accessed. Whilst this is a +doubly-linked list, it is intentionally not a circular list; the outward +sibling pointers in terminal segments should be NULL. + +Each segment in the list also stores: + + * an ordered sequence of folio pointers, + * the size of each folio and + * three 1-bit marks per folio, + +but hese should not be accessed directly as the underlying data structure may +change, but rather the access functions outlined below should be used. + +The facility can be made accessible by:: + + #include <linux/folio_queue.h> + +and to use the iterator:: + + #include <linux/uio.h> + + +Initialisation +============== + +A segment should be initialised by calling:: + + void folioq_init(struct folio_queue *folioq); + +with a pointer to the segment to be initialised. Note that this will not +necessarily initialise all the folio pointers, so care must be taken to check +the number of folios added. + + +Adding and removing folios +========================== + +Folios can be set in the next unused slot in a segment struct by calling one +of:: + + unsigned int folioq_append(struct folio_queue *folioq, + struct folio *folio); + + unsigned int folioq_append_mark(struct folio_queue *folioq, + struct folio *folio); + +Both functions update the stored folio count, store the folio and note its +size. The second function also sets the first mark for the folio added. Both +functions return the number of the slot used. [!] Note that no attempt is made +to check that the capacity wasn't overrun and the list will not be extended +automatically. + +A folio can be excised by calling:: + + void folioq_clear(struct folio_queue *folioq, unsigned int slot); + +This clears the slot in the array and also clears all the marks for that folio, +but doesn't change the folio count - so future accesses of that slot must check +if the slot is occupied. + + +Querying information about a folio +================================== + +Information about the folio in a particular slot may be queried by the +following function:: + + struct folio *folioq_folio(const struct folio_queue *folioq, + unsigned int slot); + +If a folio has not yet been set in that slot, this may yield an undefined +pointer. The size of the folio in a slot may be queried with either of:: + + unsigned int folioq_folio_order(const struct folio_queue *folioq, + unsigned int slot); + + size_t folioq_folio_size(const struct folio_queue *folioq, + unsigned int slot); + +The first function returns the size as an order and the second as a number of +bytes. + + +Querying information about a folio_queue +======================================== + +Information may be retrieved about a particular segment with the following +functions:: + + unsigned int folioq_nr_slots(const struct folio_queue *folioq); + + unsigned int folioq_count(struct folio_queue *folioq); + + bool folioq_full(struct folio_queue *folioq); + +The first function returns the maximum capacity of a segment. It must not be +assumed that this won't vary between segments. The second returns the number +of folios added to a segments and the third is a shorthand to indicate if the +segment has been filled to capacity. + +Not that the count and fullness are not affected by clearing folios from the +segment. These are more about indicating how many slots in the array have been +initialised, and it assumed that slots won't get reused, but rather the segment +will get discarded as the queue is consumed. + + +Folio marks +=========== + +Folios within a queue can also have marks assigned to them. These marks can be +used to note information such as if a folio needs folio_put() calling upon it. +There are three marks available to be set for each folio. + +The marks can be set by:: + + void folioq_mark(struct folio_queue *folioq, unsigned int slot); + void folioq_mark2(struct folio_queue *folioq, unsigned int slot); + void folioq_mark3(struct folio_queue *folioq, unsigned int slot); + +Cleared by:: + + void folioq_unmark(struct folio_queue *folioq, unsigned int slot); + void folioq_unmark2(struct folio_queue *folioq, unsigned int slot); + void folioq_unmark3(struct folio_queue *folioq, unsigned int slot); + +And the marks can be queried by:: + + bool folioq_is_marked(const struct folio_queue *folioq, unsigned int slot); + bool folioq_is_marked2(const struct folio_queue *folioq, unsigned int slot); + bool folioq_is_marked3(const struct folio_queue *folioq, unsigned int slot); + +The marks can be used for any purpose and are not interpreted by this API. + + +Folio queue iteration +===================== + +A list of segments may be iterated over using the I/O iterator facility using +an ``iov_iter`` iterator of ``ITER_FOLIOQ`` type. The iterator may be +initialised with:: + + void iov_iter_folio_queue(struct iov_iter *i, unsigned int direction, + const struct folio_queue *folioq, + unsigned int first_slot, unsigned int offset, + size_t count); + +This may be told to start at a particular segment, slot and offset within a +queue. The iov iterator functions will follow the next pointers when advancing +and prev pointers when reverting when needed. + + +Lockless simultaneous production/consumption issues +=================================================== + +If properly managed, the list can be extended by the producer at the head end +and shortened by the consumer at the tail end simultaneously without the need +to take locks. The ITER_FOLIOQ iterator inserts appropriate barriers to aid +with this. + +Care must be taken when simultaneously producing and consuming a list. If the +last segment is reached and the folios it refers to are entirely consumed by +the IOV iterators, an iov_iter struct will be left pointing to the last segment +with a slot number equal to the capacity of that segment. The iterator will +try to continue on from this if there's another segment available when it is +used again, but care must be taken lest the segment got removed and freed by +the consumer before the iterator was advanced. + +It is recommended that the queue always contain at least one segment, even if +that segment has never been filled or is entirely spent. This prevents the +head and tail pointers from collapsing. + + +API Function Reference +====================== + +.. kernel-doc:: include/linux/folio_queue.h diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index e18a2ffe0787..6a875743dd4b 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -35,7 +35,9 @@ Library functionality that is used throughout the kernel. kobject kref + cleanup assoc_array + folio_queue xarray maple_tree idr diff --git a/Documentation/core-api/protection-keys.rst b/Documentation/core-api/protection-keys.rst index bf28ac0401f3..7eb7c6023e09 100644 --- a/Documentation/core-api/protection-keys.rst +++ b/Documentation/core-api/protection-keys.rst @@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on: * Intel server CPUs, Skylake and later * Intel client CPUs, Tiger Lake (11th Gen Core) and later * Future AMD CPUs + * arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE) +x86_64 +====== Pkeys work by dedicating 4 previously Reserved bits in each page table entry to a "protection key", giving 16 possible keys. @@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is theoretically space in the PAE PTEs. These permissions are enforced on data access only and have no effect on instruction fetches. +arm64 +===== + +Pkeys use 3 bits in each page table entry, to encode a "protection key index", +giving 8 possible keys. + +Protections for each key are defined with a per-CPU user-writable system +register (POR_EL0). This is a 64-bit register encoding read, write and execute +overlay permissions for each protection key index. + +Being a CPU register, POR_EL0 is inherently thread-local, potentially giving +each thread a different set of protections from every other thread. + +Unlike x86_64, the protection key permissions also apply to instruction +fetches. + Syscalls ======== @@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys:: int pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey); -Before a pkey can be used, it must first be allocated with -pkey_alloc(). An application calls the WRPKRU instruction -directly in order to change access permissions to memory covered -with a key. In this example WRPKRU is wrapped by a C function -called pkey_set(). +Before a pkey can be used, it must first be allocated with pkey_alloc(). An +application writes to the architecture specific CPU register directly in order +to change access permissions to memory covered with a key. In this example +this is wrapped by a C function called pkey_set(). :: int real_prot = PROT_READ|PROT_WRITE; @@ -64,9 +82,9 @@ is no longer in use:: munmap(ptr, PAGE_SIZE); pkey_free(pkey); -.. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions. - An example implementation can be found in - tools/testing/selftests/x86/protection_keys.c. +.. note:: pkey_set() is a wrapper around writing to the CPU register. + Example implementations can be found in + tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h Behavior ======== @@ -96,3 +114,7 @@ with a read():: The kernel will send a SIGSEGV in both cases, but si_code will be set to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when the plain mprotect() permissions are violated. + +Note that kernel accesses from a kthread (such as io_uring) will use a default +value for the protection key register and so will not be consistent with +userspace's value of the register or mprotect(). diff --git a/Documentation/core-api/unaligned-memory-access.rst b/Documentation/core-api/unaligned-memory-access.rst index 1ee82419d8aa..5ceeb80eb539 100644 --- a/Documentation/core-api/unaligned-memory-access.rst +++ b/Documentation/core-api/unaligned-memory-access.rst @@ -203,7 +203,7 @@ Avoiding unaligned accesses =========================== The easiest way to avoid unaligned access is to use the get_unaligned() and -put_unaligned() macros provided by the <asm/unaligned.h> header file. +put_unaligned() macros provided by the <linux/unaligned.h> header file. Going back to an earlier example of code that potentially causes unaligned access:: diff --git a/Documentation/devicetree/bindings/arm/cirrus/cirrus,ep9301.yaml b/Documentation/devicetree/bindings/arm/cirrus/cirrus,ep9301.yaml new file mode 100644 index 000000000000..170aad5dd7ed --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cirrus/cirrus,ep9301.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/cirrus/cirrus,ep9301.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic EP93xx platforms + +description: + The EP93xx SoC is a ARMv4T-based with 200 MHz ARM9 CPU. + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + - Nikita Shubin <nikita.shubin@maquefel.me> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: The TS-7250 is a compact, full-featured Single Board + Computer (SBC) based upon the Cirrus EP9302 ARM9 CPU + items: + - const: technologic,ts7250 + - const: cirrus,ep9301 + + - description: The Liebherr BK3 is a derivate from ts7250 board + items: + - const: liebherr,bk3 + - const: cirrus,ep9301 + + - description: EDB302 is an evaluation board by Cirrus Logic, + based on a Cirrus Logic EP9302 CPU + items: + - const: cirrus,edb9302 + - const: cirrus,ep9301 + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/ata/cirrus,ep9312-pata.yaml b/Documentation/devicetree/bindings/ata/cirrus,ep9312-pata.yaml new file mode 100644 index 000000000000..8130923fdc72 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/cirrus,ep9312-pata.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/cirrus,ep9312-pata.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic EP9312 PATA controller + +maintainers: + - Damien Le Moal <dlemoal@kernel.org> + +properties: + compatible: + oneOf: + - const: cirrus,ep9312-pata + - items: + - const: cirrus,ep9315-pata + - const: cirrus,ep9312-pata + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + ide@800a0000 { + compatible = "cirrus,ep9312-pata"; + reg = <0x800a0000 0x38>; + interrupt-parent = <&vic1>; + interrupts = <8>; + pinctrl-names = "default"; + pinctrl-0 = <&ide_default_pins>; + }; diff --git a/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml b/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml new file mode 100644 index 000000000000..faca0cb3f154 --- /dev/null +++ b/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/elgin,jg10309-01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Elgin JG10309-01 SPI-controlled display + +maintainers: + - Fabio Estevam <festevam@gmail.com> + +description: | + The Elgin JG10309-01 SPI-controlled display is used on the RV1108-Elgin-r1 + board and is a custom display. + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + const: elgin,jg10309-01 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 24000000 + + spi-cpha: true + + spi-cpol: true + +required: + - compatible + - reg + - spi-cpha + - spi-cpol + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + display@0 { + compatible = "elgin,jg10309-01"; + reg = <0>; + spi-max-frequency = <24000000>; + spi-cpha; + spi-cpol; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2m.yaml b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2m.yaml new file mode 100644 index 000000000000..871b76ddf90f --- /dev/null +++ b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2m.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/cirrus,ep9301-dma-m2m.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic ep93xx SoC DMA controller + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + - Nikita Shubin <nikita.shubin@maquefel.me> + +allOf: + - $ref: dma-controller.yaml# + +properties: + compatible: + oneOf: + - const: cirrus,ep9301-dma-m2m + - items: + - enum: + - cirrus,ep9302-dma-m2m + - cirrus,ep9307-dma-m2m + - cirrus,ep9312-dma-m2m + - cirrus,ep9315-dma-m2m + - const: cirrus,ep9301-dma-m2m + + reg: + items: + - description: m2m0 channel registers + - description: m2m1 channel registers + + clocks: + items: + - description: m2m0 channel gate clock + - description: m2m1 channel gate clock + + clock-names: + items: + - const: m2m0 + - const: m2m1 + + interrupts: + items: + - description: m2m0 channel interrupt + - description: m2m1 channel interrupt + + '#dma-cells': + const: 2 + description: | + The first cell is the unique device channel number as indicated by this + table for ep93xx: + + 10: SPI controller + 11: IDE controller + + The second cell is the DMA direction line number: + + 1: Memory to device + 2: Device to memory + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/cirrus,ep9301-syscon.h> + dma-controller@80000100 { + compatible = "cirrus,ep9301-dma-m2m"; + reg = <0x80000100 0x0040>, + <0x80000140 0x0040>; + clocks = <&syscon EP93XX_CLK_M2M0>, + <&syscon EP93XX_CLK_M2M1>; + clock-names = "m2m0", "m2m1"; + interrupt-parent = <&vic0>; + interrupts = <17>, <18>; + #dma-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2p.yaml b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2p.yaml new file mode 100644 index 000000000000..d14c31553543 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2p.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/cirrus,ep9301-dma-m2p.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic ep93xx SoC M2P DMA controller + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + - Nikita Shubin <nikita.shubin@maquefel.me> + +allOf: + - $ref: dma-controller.yaml# + +properties: + compatible: + oneOf: + - const: cirrus,ep9301-dma-m2p + - items: + - enum: + - cirrus,ep9302-dma-m2p + - cirrus,ep9307-dma-m2p + - cirrus,ep9312-dma-m2p + - cirrus,ep9315-dma-m2p + - const: cirrus,ep9301-dma-m2p + + reg: + items: + - description: m2p0 channel registers + - description: m2p1 channel registers + - description: m2p2 channel registers + - description: m2p3 channel registers + - description: m2p4 channel registers + - description: m2p5 channel registers + - description: m2p6 channel registers + - description: m2p7 channel registers + - description: m2p8 channel registers + - description: m2p9 channel registers + + clocks: + items: + - description: m2p0 channel gate clock + - description: m2p1 channel gate clock + - description: m2p2 channel gate clock + - description: m2p3 channel gate clock + - description: m2p4 channel gate clock + - description: m2p5 channel gate clock + - description: m2p6 channel gate clock + - description: m2p7 channel gate clock + - description: m2p8 channel gate clock + - description: m2p9 channel gate clock + + clock-names: + items: + - const: m2p0 + - const: m2p1 + - const: m2p2 + - const: m2p3 + - const: m2p4 + - const: m2p5 + - const: m2p6 + - const: m2p7 + - const: m2p8 + - const: m2p9 + + interrupts: + items: + - description: m2p0 channel interrupt + - description: m2p1 channel interrupt + - description: m2p2 channel interrupt + - description: m2p3 channel interrupt + - description: m2p4 channel interrupt + - description: m2p5 channel interrupt + - description: m2p6 channel interrupt + - description: m2p7 channel interrupt + - description: m2p8 channel interrupt + - description: m2p9 channel interrupt + + '#dma-cells': + const: 2 + description: | + The first cell is the unique device channel number as indicated by this + table for ep93xx: + + 0: I2S channel 1 + 1: I2S channel 2 (unused) + 2: AC97 channel 1 (unused) + 3: AC97 channel 2 (unused) + 4: AC97 channel 3 (unused) + 5: I2S channel 3 (unused) + 6: UART1 (unused) + 7: UART2 (unused) + 8: UART3 (unused) + 9: IRDA (unused) + + The second cell is the DMA direction line number: + + 1: Memory to device + 2: Device to memory + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/cirrus,ep9301-syscon.h> + dma-controller@80000000 { + compatible = "cirrus,ep9301-dma-m2p"; + reg = <0x80000000 0x0040>, + <0x80000040 0x0040>, + <0x80000080 0x0040>, + <0x800000c0 0x0040>, + <0x80000240 0x0040>, + <0x80000200 0x0040>, + <0x800002c0 0x0040>, + <0x80000280 0x0040>, + <0x80000340 0x0040>, + <0x80000300 0x0040>; + clocks = <&syscon EP93XX_CLK_M2P0>, + <&syscon EP93XX_CLK_M2P1>, + <&syscon EP93XX_CLK_M2P2>, + <&syscon EP93XX_CLK_M2P3>, + <&syscon EP93XX_CLK_M2P4>, + <&syscon EP93XX_CLK_M2P5>, + <&syscon EP93XX_CLK_M2P6>, + <&syscon EP93XX_CLK_M2P7>, + <&syscon EP93XX_CLK_M2P8>, + <&syscon EP93XX_CLK_M2P9>; + clock-names = "m2p0", "m2p1", + "m2p2", "m2p3", + "m2p4", "m2p5", + "m2p6", "m2p7", + "m2p8", "m2p9"; + interrupt-parent = <&vic0>; + interrupts = <7>, <8>, <9>, <10>, <11>, <12>, <13>, <14>, <15>, <16>; + #dma-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml index d5cfa32ea52d..072b3c0c5fd0 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml +++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml @@ -37,6 +37,11 @@ properties: GPIO pin (output) used to control VBUS. If skipped, no such control takes place. + port: + $ref: /schemas/graph.yaml#/properties/port + description: + A port node to link the usb controller for the dual role switch. + required: - compatible - interrupts @@ -58,5 +63,11 @@ examples: interrupt-parent = <&msmgpio>; interrupts = <78 IRQ_TYPE_LEVEL_HIGH>; vbus-gpios = <&msmgpio 148 GPIO_ACTIVE_HIGH>; + + port { + endpoint { + remote-endpoint = <&usb1_drd_sw>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt deleted file mode 100644 index dfc14f71e81f..000000000000 --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt +++ /dev/null @@ -1,21 +0,0 @@ -USB GPIO Extcon device - -This is a virtual device used to generate USB cable states from the USB ID pin -connected to a GPIO pin. - -Required properties: -- compatible: Should be "linux,extcon-usb-gpio" - -Either one of id-gpio or vbus-gpio must be present. Both can be present as well. -- id-gpio: gpio for USB ID pin. See gpio binding. -- vbus-gpio: gpio for USB VBUS pin. - -Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below: - extcon_usb1 { - compatible = "linux,extcon-usb-gpio"; - id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>; - } - - &omap_dwc3_1 { - extcon = <&extcon_usb1>; - }; diff --git a/Documentation/devicetree/bindings/extcon/linux,extcon-usb-gpio.yaml b/Documentation/devicetree/bindings/extcon/linux,extcon-usb-gpio.yaml new file mode 100644 index 000000000000..8856107bdd33 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/linux,extcon-usb-gpio.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/linux,extcon-usb-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: USB GPIO Extcon device + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: + This is a virtual device used to generate USB cable states from the USB ID pin + connected to a GPIO pin. + +properties: + compatible: + const: linux,extcon-usb-gpio + + id-gpios: + description: gpio for USB ID pin. See gpio binding. + vbus-gpios: + description: gpio for USB VBUS pin. + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + extcon_usb1 { + compatible = "linux,extcon-usb-gpio"; + id-gpios = <&gpio6 1 GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml index daadfb4926c3..3a1079d6ee20 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml @@ -73,9 +73,10 @@ examples: reg-names = "data", "dir", "intr"; gpio-controller; #gpio-cells = <2>; - interrupt-controller; - interrupt-parent = <&vic1>; - interrupts = <27>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&vic1>; + interrupts = <27>; }; gpio@80840004 { @@ -87,6 +88,7 @@ examples: gpio-controller; #gpio-cells = <2>; interrupt-controller; + #interrupt-cells = <2>; interrupt-parent = <&vic1>; interrupts = <27>; }; @@ -127,6 +129,7 @@ examples: gpio-controller; #gpio-cells = <2>; interrupt-controller; + #interrupt-cells = <2>; interrupts-extended = <&vic0 19>, <&vic0 20>, <&vic0 21>, <&vic0 22>, <&vic1 15>, <&vic1 16>, diff --git a/Documentation/devicetree/bindings/hwlock/sprd,hwspinlock-r3p0.yaml b/Documentation/devicetree/bindings/hwlock/sprd,hwspinlock-r3p0.yaml new file mode 100644 index 000000000000..abe11df25761 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/sprd,hwspinlock-r3p0.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwlock/sprd,hwspinlock-r3p0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Spreadtrum hardware spinlock + +maintainers: + - Orson Zhai <orsonzhai@gmail.com> + - Baolin Wang <baolin.wang7@gmail.com> + - Chunyan Zhang <zhang.lyra@gmail.com> + +properties: + compatible: + const: sprd,hwspinlock-r3p0 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: enable + + '#hwlock-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#hwlock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/sprd,sc9860-clk.h> + + hwlock@40500000 { + compatible = "sprd,hwspinlock-r3p0"; + reg = <0x40500000 0x1000>; + clocks = <&aon_gate CLK_SPLK_EB>; + clock-names = "enable"; + #hwlock-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/hwlock/sprd-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/sprd-hwspinlock.txt deleted file mode 100644 index 581db9d941ba..000000000000 --- a/Documentation/devicetree/bindings/hwlock/sprd-hwspinlock.txt +++ /dev/null @@ -1,23 +0,0 @@ -SPRD Hardware Spinlock Device Binding -------------------------------------- - -Required properties : -- compatible : should be "sprd,hwspinlock-r3p0". -- reg : the register address of hwspinlock. -- #hwlock-cells : hwlock users only use the hwlock id to represent a specific - hwlock, so the number of cells should be <1> here. -- clock-names : Must contain "enable". -- clocks : Must contain a phandle entry for the clock in clock-names, see the - common clock bindings. - -Please look at the generic hwlock binding for usage information for consumers, -"Documentation/devicetree/bindings/hwlock/hwlock.txt" - -Example of hwlock provider: - hwspinlock@40500000 { - compatible = "sprd,hwspinlock-r3p0"; - reg = <0 0x40500000 0 0x1000>; - #hwlock-cells = <1>; - clock-names = "enable"; - clocks = <&clk_aon_apb_gates0 22>; - }; diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl380.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl380.yaml new file mode 100644 index 000000000000..f1ff5ff4f478 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl380.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/adi,adxl380.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADXL380/382 3-Axis Digital Accelerometer + +maintainers: + - Ramona Gradinariu <ramona.gradinariu@analog.com> + - Antoniu Miclaus <antoniu.miclaus@analog.com> + +description: | + The ADXL380/ADXL382 is a low noise density, low power, 3-axis + accelerometer with selectable measurement ranges. The ADXL380 + supports the ±4 g, ±8 g, and ±16 g ranges, and the ADXL382 supports + ±15 g, ±30 g, and ±60 g ranges. + + https://www.analog.com/en/products/adxl380.html + +properties: + compatible: + enum: + - adi,adxl380 + - adi,adxl382 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - enum: [INT0, INT1] + - const: INT1 + + vddio-supply: true + + vsupply-supply: true + +required: + - compatible + - reg + - interrupts + - interrupt-names + - vddio-supply + - vsupply-supply + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@54 { + compatible = "adi,adxl380"; + reg = <0x54>; + vddio-supply = <&vddio>; + vsupply-supply = <&vsupply>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT0"; + }; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "adi,adxl380"; + reg = <0>; + spi-max-frequency = <8000000>; + vddio-supply = <&vddio>; + vsupply-supply = <&vsupply>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT0"; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml index 6ddb03f61bd9..951a3a2ba8fc 100644 --- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml +++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml @@ -16,6 +16,7 @@ properties: - kionix,kxcj91008 - kionix,kxtj21009 - kionix,kxtf9 + - kionix,kx022-1020 - kionix,kx023-1025 reg: diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml new file mode 100644 index 000000000000..310f046e139f --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml @@ -0,0 +1,254 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad4695.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices Easy Drive Multiplexed SAR Analog to Digital Converters + +maintainers: + - Michael Hennerich <Michael.Hennerich@analog.com> + - Nuno Sá <nuno.sa@analog.com> + +description: | + A family of similar multi-channel analog to digital converters with SPI bus. + + * https://www.analog.com/en/products/ad4695.html + * https://www.analog.com/en/products/ad4696.html + * https://www.analog.com/en/products/ad4697.html + * https://www.analog.com/en/products/ad4698.html + +$ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + enum: + - adi,ad4695 + - adi,ad4696 + - adi,ad4697 + - adi,ad4698 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 80000000 + + spi-cpol: true + spi-cpha: true + + spi-rx-bus-width: + minimum: 1 + maximum: 4 + + avdd-supply: + description: Analog power supply. + + vio-supply: + description: I/O pin power supply. + + ldo-in-supply: + description: Internal LDO Input. Mutually exclusive with vdd-supply. + + vdd-supply: + description: Core power supply. Mutually exclusive with ldo-in-supply. + + ref-supply: + description: + External reference voltage. Mutually exclusive with refin-supply. + + refin-supply: + description: + Internal reference buffer input. Mutually exclusive with ref-supply. + + com-supply: + description: Common voltage supply for pseudo-differential analog inputs. + + adi,no-ref-current-limit: + $ref: /schemas/types.yaml#/definitions/flag + description: + When this flag is present, the REF Overvoltage Reduced Current protection + is disabled. + + adi,no-ref-high-z: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable this flag if the ref-supply requires Reference Input High-Z Mode + to be disabled for proper operation. + + cnv-gpios: + description: The Convert Input (CNV). If omitted, CNV is tied to SPI CS. + maxItems: 1 + + reset-gpios: + description: The Reset Input (RESET). Should be configured GPIO_ACTIVE_LOW. + maxItems: 1 + + interrupts: + minItems: 1 + items: + - description: Signal coming from the BSY_ALT_GP0 pin (ALERT or BUSY). + - description: Signal coming from the GP2 pin (ALERT). + - description: Signal coming from the GP3 pin (BUSY). + + interrupt-names: + minItems: 1 + items: + - const: gp0 + - const: gp2 + - const: gp3 + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + The first cell is the GPn number: 0 to 3. + The second cell takes standard GPIO flags. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^in(?:[13579]|1[135])-supply$": + description: + Optional voltage supply for odd numbered channels when they are used as + the negative input for a pseudo-differential channel. + + "^channel@[0-9a-f]$": + type: object + $ref: adc.yaml + unevaluatedProperties: false + description: + Describes each individual channel. In addition the properties defined + below, bipolar from adc.yaml is also supported. + + properties: + reg: + maximum: 15 + + common-mode-channel: + description: + Describes the common mode channel for single channels. 0xFF is REFGND + and OxFE is COM. Macros are available for these values in + dt-bindings/iio/adi,ad4695.h. Values 1 to 15 correspond to INx inputs. + Only odd numbered INx inputs can be used as common mode channels. + enum: [1, 3, 5, 7, 9, 11, 13, 15, 0xFE, 0xFF] + default: 0xFF + + adi,no-high-z: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable this flag if the input pin requires the Analog Input High-Z + Mode to be disabled for proper operation. + + required: + - reg + + allOf: + # bipolar mode can't be used with REFGND + - if: + properties: + common-mode-channel: + const: 0xFF + then: + properties: + bipolar: false + +required: + - compatible + - reg + - avdd-supply + - vio-supply + +allOf: + - oneOf: + - required: + - ldo-in-supply + - required: + - vdd-supply + + - oneOf: + - required: + - ref-supply + - required: + - refin-supply + + # the internal reference buffer always requires high-z mode + - if: + required: + - refin-supply + then: + properties: + adi,no-ref-high-z: false + + # limit channels for 8-channel chips + - if: + properties: + compatible: + contains: + enum: + - adi,ad4697 + - adi,ad4698 + then: + patternProperties: + "^in(?:9|1[135])-supply$": false + "^channel@[0-7]$": + properties: + reg: + maximum: 7 + common-mode-channel: + enum: [1, 3, 5, 7, 0xFE, 0xFF] + "^channel@[8-9a-f]$": false + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/iio/adi,ad4695.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad4695"; + reg = <0>; + spi-cpol; + spi-cpha; + spi-max-frequency = <80000000>; + avdd-supply = <&power_supply>; + ldo-in-supply = <&power_supply>; + vio-supply = <&io_supply>; + refin-supply = <&supply_5V>; + com-supply = <&supply_2V5>; + in3-supply = <&supply_2V5>; + reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + + #address-cells = <1>; + #size-cells = <0>; + + /* Pseudo-differential channel between IN0 and REFGND. */ + channel@0 { + reg = <0>; + }; + + /* Pseudo-differential channel between IN1 and COM. */ + channel@1 { + reg = <1>; + common-mode-channel = <AD4695_COMMON_MODE_COM>; + bipolar; + }; + + /* Pseudo-differential channel between IN2 and IN3. */ + channel@2 { + reg = <2>; + common-mode-channel = <3>; + bipolar; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml index 190889c7b62a..66dd1c549bd3 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml @@ -39,11 +39,21 @@ properties: clocks: maxItems: 1 - description: phandle to the master clock (mclk) + description: + Optionally, either a crystal can be attached externally between MCLK1 and + MCLK2 pins, or an external CMOS-compatible clock can drive the MCLK2 + pin. If absent, internal 4.92MHz clock is used, which can be made + available on MCLK2 pin. clock-names: - items: - - const: mclk + enum: + - xtal + - mclk + + "#clock-cells": + const: 0 + description: + If present when internal clock is used, configured as clock provider. interrupts: maxItems: 1 @@ -134,8 +144,6 @@ patternProperties: required: - compatible - reg - - clocks - - clock-names - interrupts - dvdd-supply - avdd-supply @@ -156,6 +164,18 @@ allOf: then: patternProperties: "^channel@[0-9a-f]+$": false + - if: + anyOf: + - required: + - clocks + - required: + - clock-names + then: + properties: + "#clock-cells": false + required: + - clocks + - clock-names unevaluatedProperties: false @@ -201,8 +221,7 @@ examples: spi-max-frequency = <1000000>; spi-cpol; spi-cpha; - clocks = <&ad7192_mclk>; - clock-names = "mclk"; + #clock-cells = <0>; interrupts = <25 0x2>; interrupt-parent = <&gpio>; aincom-supply = <&aincom>; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml index 899b777017ce..bd19abb867d9 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml @@ -15,10 +15,17 @@ description: | * https://www.analog.com/en/products/ad7381.html * https://www.analog.com/en/products/ad7383.html * https://www.analog.com/en/products/ad7384.html + * https://www.analog.com/en/products/ad7386.html + * https://www.analog.com/en/products/ad7387.html + * https://www.analog.com/en/products/ad7388.html * https://www.analog.com/en/products/ad7380-4.html * https://www.analog.com/en/products/ad7381-4.html * https://www.analog.com/en/products/ad7383-4.html * https://www.analog.com/en/products/ad7384-4.html + * https://www.analog.com/en/products/ad7386-4.html + * https://www.analog.com/en/products/ad7387-4.html + * https://www.analog.com/en/products/ad7388-4.html + $ref: /schemas/spi/spi-peripheral-props.yaml# @@ -29,10 +36,16 @@ properties: - adi,ad7381 - adi,ad7383 - adi,ad7384 + - adi,ad7386 + - adi,ad7387 + - adi,ad7388 - adi,ad7380-4 - adi,ad7381-4 - adi,ad7383-4 - adi,ad7384-4 + - adi,ad7386-4 + - adi,ad7387-4 + - adi,ad7388-4 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml index 00fdaed11cbd..69408cae3db9 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml @@ -35,65 +35,83 @@ properties: avcc-supply: true + vdrive-supply: + description: + Determines the voltage level at which the interface logic pins will + operate. + + refin-supply: + description: + The voltage supply for optional external reference voltage. + interrupts: + description: + The BUSY pin falling edge indicates that the conversion is over, and thus + new data is available. maxItems: 1 adi,conversion-start-gpios: description: - Must be the device tree identifier of the CONVST pin. - This logic input is used to initiate conversions on the analog - input channels. As the line is active high, it should be marked - GPIO_ACTIVE_HIGH. - maxItems: 1 + Must be the device tree identifier of the CONVST pin(s). This logic input + is used to initiate conversions on the analog input channels. As the line + is active high, it should be marked GPIO_ACTIVE_HIGH. + minItems: 1 + maxItems: 2 reset-gpios: description: - Must be the device tree identifier of the RESET pin. If specified, - it will be asserted during driver probe. As the line is active high, - it should be marked GPIO_ACTIVE_HIGH. + Must be the device tree identifier of the RESET pin. If specified, it will + be asserted during driver probe. On the AD7606x, as the line is active + high, it should be marked GPIO_ACTIVE_HIGH. On the AD7616, as the line is + active low, it should be marked GPIO_ACTIVE_LOW. maxItems: 1 standby-gpios: description: - Must be the device tree identifier of the STBY pin. This pin is used - to place the AD7606 into one of two power-down modes, Standby mode or + Must be the device tree identifier of the STBY pin. This pin is used to + place the AD7606 into one of two power-down modes, Standby mode or Shutdown mode. As the line is active low, it should be marked GPIO_ACTIVE_LOW. maxItems: 1 adi,first-data-gpios: description: - Must be the device tree identifier of the FRSTDATA pin. - The FRSTDATA output indicates when the first channel, V1, is - being read back on either the parallel, byte or serial interface. - As the line is active high, it should be marked GPIO_ACTIVE_HIGH. + Must be the device tree identifier of the FRSTDATA pin. The FRSTDATA + output indicates when the first channel, V1, is being read back on either + the parallel, byte or serial interface. As the line is active high, it + should be marked GPIO_ACTIVE_HIGH. maxItems: 1 adi,range-gpios: description: - Must be the device tree identifier of the RANGE pin. The polarity on - this pin determines the input range of the analog input channels. If - this pin is tied to a logic high, the analog input range is ±10V for - all channels. If this pin is tied to a logic low, the analog input range + Must be the device tree identifier of the RANGE pin. The state on this + pin determines the input range of the analog input channels. If this pin + is tied to a logic high, the analog input range is ±10V for all channels. + On the AD760X, if this pin is tied to a logic low, the analog input range is ±5V for all channels. As the line is active high, it should be marked - GPIO_ACTIVE_HIGH. - maxItems: 1 + GPIO_ACTIVE_HIGH. On the AD7616, there are 2 pins, and if the 2 pins are + tied to a logic high, software mode is enabled, otherwise one of the 3 + possible range values is selected. + minItems: 1 + maxItems: 2 adi,oversampling-ratio-gpios: description: - Must be the device tree identifier of the over-sampling - mode pins. As the line is active high, it should be marked - GPIO_ACTIVE_HIGH. + Must be the device tree identifier of the over-sampling mode pins. As the + line is active high, it should be marked GPIO_ACTIVE_HIGH. On the AD7606X + parts that support it, if all 3 pins are tied to a logic high, software + mode is enabled. maxItems: 3 adi,sw-mode: description: - Software mode of operation, so far available only for ad7616 and ad7606b. - It is enabled when all three oversampling mode pins are connected to - high level. The device is configured by the corresponding registers. If the - adi,oversampling-ratio-gpios property is defined, then the driver will set the - oversampling gpios to high. Otherwise, it is assumed that the pins are hardwired - to VDD. + Software mode of operation, so far available only for AD7616 and AD7606B. + It is enabled when all three oversampling mode pins are connected to high + level for the AD7606B, or both the range selection are connected to high + level for the AD7616. The device is configured by the corresponding + registers. If the adi,oversampling-ratio-gpios property is defined, then + the driver will set the oversampling gpios to high. Otherwise, it is + assumed that the pins are hardwired to VDD. type: boolean required: @@ -101,12 +119,57 @@ required: - reg - spi-cpha - avcc-supply + - vdrive-supply - interrupts - adi,conversion-start-gpios allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# + - if: + properties: + compatible: + contains: + const: adi,ad7616 + then: + properties: + adi,first-data-gpios: false + standby-gpios: false + adi,range-gpios: + maxItems: 2 + else: + properties: + adi,range-gpios: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - adi,ad7605-4 + - adi,ad7616 + then: + properties: + adi,oversampling-ratio-gpios: false + + - if: + properties: + compatible: + contains: + enum: + - adi,ad7605-4 + - adi,ad7606-4 + - adi,ad7606-6 + - adi,ad7606-8 + then: + properties: + adi,sw-mode: false + else: + properties: + adi,conversion-start-gpios: + maxItems: 1 + unevaluatedProperties: false examples: @@ -125,6 +188,7 @@ examples: spi-cpha; avcc-supply = <&adc_vref>; + vdrive-supply = <&vdd_supply>; interrupts = <25 IRQ_TYPE_EDGE_FALLING>; interrupt-parent = <&gpio>; @@ -136,7 +200,6 @@ examples: <&gpio 23 GPIO_ACTIVE_HIGH>, <&gpio 26 GPIO_ACTIVE_HIGH>; standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>; - adi,sw-mode; }; }; ... diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml index eecd5fbab695..2606c0c5dfc6 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml @@ -28,6 +28,9 @@ properties: - adi,ad9265 - adi,ad9434 - adi,ad9467 + - adi,ad9643 + - adi,ad9649 + - adi,ad9652 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,pac1921.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,pac1921.yaml new file mode 100644 index 000000000000..12e56b1b3d3f --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/microchip,pac1921.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/microchip,pac1921.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PAC1921 High-Side Power/Current Monitor with Anaog Output + +maintainers: + - Matteo Martelli <matteomartelli3@gmail.com> + +description: | + The PAC1921 is a power/current monitoring device with an analog output + and I2C/SMBus interface. + + Datasheet can be found here: + https://ww1.microchip.com/downloads/en/DeviceDoc/PAC1921-Data-Sheet-DS20005293E.pdf + +properties: + compatible: + const: microchip,pac1921 + + reg: + maxItems: 1 + + vdd-supply: true + + "#io-channel-cells": + const: 1 + + shunt-resistor-micro-ohms: + description: + Value in micro Ohms of the shunt resistor connected between + the SENSE+ and SENSE- inputs, across which the current is measured. + Value is needed to compute the scaling of the measured current. + + label: + description: Unique name to identify which device this is. + + read-integrate-gpios: + description: + READ/INT input pin to control the current state of the device, either in + the INTEGRATE state when driven high, or in the READ state when driven low. + When not connected the pin is floating and it can be overridden by the + INT_EN register bit after asserting the READ/INT_OVR register bit. + maxItems: 1 + +required: + - compatible + - reg + - vdd-supply + - shunt-resistor-micro-ohms + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + adc@4c { + compatible = "microchip,pac1921"; + reg = <0x4c>; + vdd-supply = <&vdd>; + #io-channel-cells = <1>; + label = "vbat"; + shunt-resistor-micro-ohms = <10000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml index aa24b841393c..fd93ed3991e0 100644 --- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml @@ -17,6 +17,9 @@ properties: - const: rockchip,rk3399-saradc - const: rockchip,rk3588-saradc - items: + - const: rockchip,rk3576-saradc + - const: rockchip,rk3588-saradc + - items: - enum: - rockchip,px30-saradc - rockchip,rk3308-saradc diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml index cab0d425eaa4..c3a116427dc3 100644 --- a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml +++ b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml @@ -18,18 +18,39 @@ properties: - sd-modulator - ads1201 + '#io-backend-cells': + const: 0 + '#io-channel-cells': const: 0 + vref-supply: + description: Phandle to the vref input analog reference voltage. + +dependencies: + vref-supply: [ '#io-backend-cells' ] + required: - compatible - - '#io-channel-cells' + +anyOf: + - required: ['#io-backend-cells'] + - required: ['#io-channel-cells'] additionalProperties: false examples: - | - ads1202: adc { + // Backend binding example. SD modulator configured as an IIO backend device + ads1201_0: adc { + compatible = "sd-modulator"; + vref-supply = <&vdd_adc>; + #io-backend-cells = <0>; + }; + + - | + // Legacy binding example. SD modulator configured as an IIO channel provider + ads1201_1: adc { compatible = "sd-modulator"; #io-channel-cells = <0>; }; diff --git a/Documentation/devicetree/bindings/iio/adc/sophgo,cv1800b-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/sophgo,cv1800b-saradc.yaml new file mode 100644 index 000000000000..f652b98615f7 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/sophgo,cv1800b-saradc.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/sophgo,cv1800b-saradc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: + Sophgo CV1800B SoC 3 channels Successive Approximation Analog to + Digital Converters + +maintainers: + - Thomas Bonnefille <thomas.bonnefille@bootlin.com> + +description: + Datasheet at https://github.com/sophgo/sophgo-doc/releases + +properties: + compatible: + const: sophgo,cv1800b-saradc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^channel@[0-2]$": + $ref: adc.yaml + + properties: + reg: + items: + - minimum: 0 + maximum: 2 + + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - clocks + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/sophgo,cv1800.h> + #include <dt-bindings/interrupt-controller/irq.h> + adc@30f0000 { + compatible = "sophgo,cv1800b-saradc"; + reg = <0x030f0000 0x1000>; + clocks = <&clk CLK_SARADC>; + interrupts = <100 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + }; + + channel@1 { + reg = <1>; + }; + + channel@2 { + reg = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml index ec34c48d4878..ef9dcc365eab 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml @@ -54,7 +54,9 @@ properties: It's not present on stm32f4. It's required on stm32h7 and stm32mp1. - clock-names: true + clock-names: + minItems: 1 + maxItems: 2 st,max-clk-rate-hz: description: diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 2722edab1d9a..c24ac98bbb3d 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -102,9 +102,11 @@ patternProperties: items: minimum: 0 maximum: 7 + deprecated: true st,adc-channel-names: description: List of single-ended channel names. + deprecated: true st,filter-order: description: | @@ -118,6 +120,12 @@ patternProperties: "#io-channel-cells": const: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + st,adc-channel-types: description: | Single-ended channel input type. @@ -128,6 +136,7 @@ patternProperties: items: enum: [ SPI_R, SPI_F, MANCH_R, MANCH_F ] $ref: /schemas/types.yaml#/definitions/non-unique-string-array + deprecated: true st,adc-channel-clk-src: description: | @@ -139,6 +148,7 @@ patternProperties: items: enum: [ CLKIN, CLKOUT, CLKOUT_F, CLKOUT_R ] $ref: /schemas/types.yaml#/definitions/non-unique-string-array + deprecated: true st,adc-alt-channel: description: @@ -147,6 +157,7 @@ patternProperties: If not set, channel n is connected to SPI input n. If set, channel n is connected to SPI input n + 1. type: boolean + deprecated: true st,filter0-sync: description: @@ -165,11 +176,60 @@ patternProperties: - compatible - reg - interrupts - - st,adc-channels - - st,adc-channel-names - st,filter-order - "#io-channel-cells" + patternProperties: + "^channel@[0-7]$": + type: object + $ref: adc.yaml + unevaluatedProperties: false + description: Represents the external channels which are connected to the DFSDM. + + properties: + reg: + maximum: 7 + + label: + description: + Unique name to identify which channel this is. + + st,adc-channel-type: + description: | + Single-ended channel input type. + - "SPI_R": SPI with data on rising edge (default) + - "SPI_F": SPI with data on falling edge + - "MANCH_R": manchester codec, rising edge = logic 0, falling edge = logic 1 + - "MANCH_F": manchester codec, rising edge = logic 1, falling edge = logic 0 + $ref: /schemas/types.yaml#/definitions/string + enum: [ SPI_R, SPI_F, MANCH_R, MANCH_F ] + + st,adc-channel-clk-src: + description: | + Conversion clock source. + - "CLKIN": external SPI clock (CLKIN x) + - "CLKOUT": internal SPI clock (CLKOUT) (default) + - "CLKOUT_F": internal SPI clock divided by 2 (falling edge). + - "CLKOUT_R": internal SPI clock divided by 2 (rising edge). + $ref: /schemas/types.yaml#/definitions/string + enum: [ CLKIN, CLKOUT, CLKOUT_F, CLKOUT_R ] + + st,adc-alt-channel: + description: + Must be defined if two sigma delta modulators are + connected on same SPI input. + If not set, channel n is connected to SPI input n. + If set, channel n is connected to SPI input n + 1. + type: boolean + + io-backends: + description: + Used to pipe external sigma delta modulator or internal ADC backend to DFSDM channel. + maxItems: 1 + + required: + - reg + allOf: - if: properties: @@ -199,9 +259,19 @@ patternProperties: description: From common IIO binding. Used to pipe external sigma delta modulator or internal ADC output to DFSDM channel. + deprecated: true - required: - - io-channels + if: + required: + - st,adc-channels + then: + required: + - io-channels + + patternProperties: + "^channel@[0-7]$": + required: + - io-backends - if: properties: @@ -298,6 +368,7 @@ examples: #address-cells = <1>; #size-cells = <0>; + // Example 1: Audio use case with generic binding dfsdm0: filter@0 { compatible = "st,stm32-dfsdm-dmic"; reg = <0>; @@ -305,12 +376,18 @@ examples: dmas = <&dmamux1 101 0x400 0x01>; dma-names = "rx"; #io-channel-cells = <1>; - st,adc-channels = <1>; - st,adc-channel-names = "dmic0"; - st,adc-channel-types = "SPI_R"; - st,adc-channel-clk-src = "CLKOUT"; + #address-cells = <1>; + #size-cells = <0>; st,filter-order = <5>; + channel@1 { + reg = <1>; + label = "dmic0"; + st,adc-channel-type = "SPI_R"; + st,adc-channel-clk-src = "CLKOUT"; + st,adc-alt-channel; + }; + asoc_pdm0: dfsdm-dai { compatible = "st,stm32h7-dfsdm-dai"; #sound-dai-cells = <0>; @@ -318,19 +395,34 @@ examples: }; }; - dfsdm_pdm1: filter@1 { + // Example 2: Analog use case with generic binding + dfsdm1: filter@1 { compatible = "st,stm32-dfsdm-adc"; reg = <1>; interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; dmas = <&dmamux1 102 0x400 0x01>; dma-names = "rx"; - #io-channel-cells = <1>; - st,adc-channels = <2 3>; - st,adc-channel-names = "in2", "in3"; - st,adc-channel-types = "SPI_R", "SPI_R"; - st,adc-channel-clk-src = "CLKOUT_F", "CLKOUT_F"; - io-channels = <&sd_adc2 &sd_adc3>; st,filter-order = <1>; + #io-channel-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + + channel@2 { + reg = <2>; + label = "in2"; + st,adc-channel-type = "SPI_F"; + st,adc-channel-clk-src = "CLKOUT"; + st,adc-alt-channel; + io-backends = <&sd_adc2>; + }; + + channel@3 { + reg = <3>; + label = "in3"; + st,adc-channel-type = "SPI_R"; + st,adc-channel-clk-src = "CLKOUT"; + io-backends = <&sd_adc3>; + }; }; }; diff --git a/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml index d40689f233f2..1caa896fce82 100644 --- a/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml @@ -37,6 +37,17 @@ description: | 3 | batt_dischrg_i 4 | ts_v + AXP717 + ------ + 0 | batt_v + 1 | ts_v + 2 | vbus_v + 3 | vsys_v + 4 | pmic_temp + 5 | batt_chrg_i + 6 | vmid_v + 7 | bkup_batt_v + AXP813 ------ 0 | pmic_temp @@ -52,6 +63,7 @@ properties: oneOf: - const: x-powers,axp209-adc - const: x-powers,axp221-adc + - const: x-powers,axp717-adc - const: x-powers,axp813-adc - items: diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2664.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2664.yaml new file mode 100644 index 000000000000..33490853497b --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2664.yaml @@ -0,0 +1,181 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ltc2664.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices LTC2664 DAC + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + - Kim Seer Paller <kimseer.paller@analog.com> + +description: | + Analog Devices LTC2664 4 channel, 12-/16-Bit, +-10V DAC + https://www.analog.com/media/en/technical-documentation/data-sheets/2664fa.pdf + +properties: + compatible: + enum: + - adi,ltc2664 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 50000000 + + vcc-supply: + description: Analog Supply Voltage Input. + + v-pos-supply: + description: Positive Supply Voltage Input. + + v-neg-supply: + description: Negative Supply Voltage Input. + + iovcc-supply: + description: Digital Input/Output Supply Voltage. + + ref-supply: + description: + Reference Input/Output. The voltage at the REF pin sets the full-scale + range of all channels. If not provided the internal reference is used and + also provided on the VREF pin. + + reset-gpios: + description: + Active-low Asynchronous Clear Input. A logic low at this level-triggered + input clears the part to the reset code and range determined by the + hardwired option chosen using the MSPAN pins. The control registers are + cleared to zero. + maxItems: 1 + + adi,manual-span-operation-config: + description: + This property must mimic the MSPAN pin configurations. By tying the MSPAN + pins (MSP2, MSP1 and MSP0) to GND and/or VCC, any output range can be + hardware-configured with different mid-scale or zero-scale reset options. + The hardware configuration is latched during power on reset for proper + operation. + 0 - MPS2=GND, MPS1=GND, MSP0=GND (+-10V, reset to 0V) + 1 - MPS2=GND, MPS1=GND, MSP0=VCC (+-5V, reset to 0V) + 2 - MPS2=GND, MPS1=VCC, MSP0=GND (+-2.5V, reset to 0V) + 3 - MPS2=GND, MPS1=VCC, MSP0=VCC (0V to 10, reset to 0V) + 4 - MPS2=VCC, MPS1=GND, MSP0=GND (0V to 10V, reset to 5V) + 5 - MPS2=VCC, MPS1=GND, MSP0=VCC (0V to 5V, reset to 0V) + 6 - MPS2=VCC, MPS1=VCC, MSP0=GND (0V to 5V, reset to 2.5V) + 7 - MPS2=VCC, MPS1=VCC, MSP0=VCC (0V to 5V, reset to 0V, enables SoftSpan) + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + default: 7 + + io-channels: + description: + ADC channel to monitor voltages and temperature at the MUXOUT pin. + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^channel@[0-3]$": + $ref: dac.yaml + type: object + additionalProperties: false + + properties: + reg: + description: The channel number representing the DAC output channel. + maximum: 3 + + adi,toggle-mode: + description: + Set the channel as a toggle enabled channel. Toggle operation enables + fast switching of a DAC output between two different DAC codes without + any SPI transaction. + type: boolean + + output-range-microvolt: + description: + This property is only allowed when SoftSpan is enabled. If not present, + [0, 5000000] is the default output range. + oneOf: + - items: + - const: 0 + - enum: [5000000, 10000000] + - items: + - const: -5000000 + - const: 5000000 + - items: + - const: -10000000 + - const: 10000000 + - items: + - const: -2500000 + - const: 2500000 + + required: + - reg + + allOf: + - if: + not: + properties: + adi,manual-span-operation-config: + const: 7 + then: + patternProperties: + "^channel@[0-3]$": + properties: + output-range-microvolt: false + +required: + - compatible + - reg + - spi-max-frequency + - vcc-supply + - iovcc-supply + - v-pos-supply + - v-neg-supply + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + compatible = "adi,ltc2664"; + reg = <0>; + spi-max-frequency = <10000000>; + + vcc-supply = <&vcc>; + iovcc-supply = <&vcc>; + ref-supply = <&vref>; + v-pos-supply = <&vpos>; + v-neg-supply = <&vneg>; + + io-channels = <&adc 0>; + + #address-cells = <1>; + #size-cells = <0>; + channel@0 { + reg = <0>; + adi,toggle-mode; + output-range-microvolt = <(-10000000) 10000000>; + }; + + channel@1 { + reg = <1>; + output-range-microvolt= <0 10000000>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml new file mode 100644 index 000000000000..c8c434c10643 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ltc2672.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices LTC2672 DAC + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + - Kim Seer Paller <kimseer.paller@analog.com> + +description: | + Analog Devices LTC2672 5 channel, 12-/16-Bit, 300mA DAC + https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2672.pdf + +properties: + compatible: + enum: + - adi,ltc2672 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 50000000 + + vcc-supply: + description: Analog Supply Voltage Input. + + v-neg-supply: + description: Negative Supply Voltage Input. + + vdd0-supply: + description: Positive Supply Voltage Input for DAC OUT0. + + vdd1-supply: + description: Positive Supply Voltage Input for DAC OUT1. + + vdd2-supply: + description: Positive Supply Voltage Input for DAC OUT2. + + vdd3-supply: + description: Positive Supply Voltage Input for DAC OUT3. + + vdd4-supply: + description: Positive Supply Voltage Input for DAC OUT4. + + iovcc-supply: + description: Digital Input/Output Supply Voltage. + + ref-supply: + description: + Reference Input/Output. The voltage at the REF pin sets the full-scale + range of all channels. If not provided the internal reference is used and + also provided on the VREF pin. + + reset-gpios: + description: + Active Low Asynchronous Clear Input. A logic low at this level triggered + input clears the device to the default reset code and output range, which + is zero-scale with the outputs off. The control registers are cleared to + zero. + maxItems: 1 + + adi,rfsadj-ohms: + description: + If FSADJ is tied to VCC, an internal RFSADJ (20 kΩ) is selected, which + results in nominal output ranges. When an external resistor of 19 kΩ to + 41 kΩ can be used instead by connecting the resistor between FSADJ and GND + it controls the scaling of the ranges, and the internal resistor is + automatically disconnected. + minimum: 19000 + maximum: 41000 + default: 20000 + + io-channels: + description: + ADC channel to monitor voltages and currents at the MUX pin. + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^channel@[0-4]$": + $ref: dac.yaml + type: object + additionalProperties: false + + properties: + reg: + description: The channel number representing the DAC output channel. + maximum: 4 + + adi,toggle-mode: + description: + Set the channel as a toggle enabled channel. Toggle operation enables + fast switching of a DAC output between two different DAC codes without + any SPI transaction. + type: boolean + + output-range-microamp: + items: + - const: 0 + - enum: [3125000, 6250000, 12500000, 25000000, 50000000, 100000000, + 200000000, 300000000] + + required: + - reg + - output-range-microamp + +required: + - compatible + - reg + - spi-max-frequency + - vcc-supply + - iovcc-supply + - v-neg-supply + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + compatible = "adi,ltc2672"; + reg = <0>; + spi-max-frequency = <10000000>; + + vcc-supply = <&vcc>; + iovcc-supply = <&vcc>; + ref-supply = <&vref>; + v-neg-supply = <&vneg>; + + io-channels = <&adc 0>; + + #address-cells = <1>; + #size-cells = <0>; + channel@0 { + reg = <0>; + adi,toggle-mode; + output-range-microamp = <0 3125000>; + }; + + channel@1 { + reg = <1>; + output-range-microamp = <0 6250000>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/dac.yaml b/Documentation/devicetree/bindings/iio/dac/dac.yaml new file mode 100644 index 000000000000..daa40724e1cf --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/dac.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/dac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IIO Common Properties for DAC Channels + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + +description: + A few properties are defined in a common way for DAC channels. + +properties: + $nodename: + pattern: "^channel(@[0-9a-f]+)?$" + description: + A channel index should match reg. + + reg: + maxItems: 1 + + label: + description: Unique name to identify which channel this is. + + output-range-microamp: + maxItems: 2 + minItems: 2 + description: + Specify the channel output full scale range in microamperes. + + output-range-microvolt: + maxItems: 2 + minItems: 2 + description: + Specify the channel output full scale range in microvolts. + +anyOf: + - oneOf: + - required: + - reg + - output-range-microamp + - required: + - reg + - output-range-microvolt + - required: + - reg + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml index aa6a3193b4e0..5f950ee9aec7 100644 --- a/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml +++ b/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml @@ -17,6 +17,7 @@ description: | applications. https://www.analog.com/en/products/adf4377.html + https://www.analog.com/en/products/adf4378.html properties: compatible: @@ -73,6 +74,15 @@ required: allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# + - if: + properties: + compatible: + contains: + enum: + - adi,adf4378 + then: + properties: + clk2-enable-gpios: false unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml b/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml new file mode 100644 index 000000000000..ed0ea938f7f8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/humidity/sciosense,ens210.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ScioSense ENS210 temperature and humidity sensor + +maintainers: + - Joshua Felmeden <jfelmeden@thegoodpenguin.co.uk> + +description: | + Temperature and Humidity sensor. + + Datasheet: + https://www.sciosense.com/wp-content/uploads/2024/04/ENS21x-Datasheet.pdf + https://www.sciosense.com/wp-content/uploads/2023/12/ENS210-Datasheet.pdf + +properties: + compatible: + oneOf: + - items: + - enum: + - sciosense,ens210a + - sciosense,ens211 + - sciosense,ens212 + - sciosense,ens213a + - sciosense,ens215 + - const: sciosense,ens210 + - const: sciosense,ens210 + + reg: + maxItems: 1 + + vdd-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + temperature-sensor@43 { + compatible = "sciosense,ens210"; + reg = <0x43>; + }; + }; +... + diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml index 7de1b0e721ca..877e955d4ebd 100644 --- a/Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml +++ b/Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml @@ -14,7 +14,9 @@ description: properties: compatible: - const: liteon,ltrf216a + enum: + - liteon,ltr308 + - liteon,ltrf216a reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bh1745.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bh1745.yaml new file mode 100644 index 000000000000..44896795c67e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/rohm,bh1745.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/rohm,bh1745.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BH1745 colour sensor + +maintainers: + - Mudit Sharma <muditsharma.info@gmail.com> + +description: + BH1745 is an I2C colour sensor with red, green, blue and clear + channels. It has a programmable active low interrupt pin. + Interrupt occurs when the signal from the selected interrupt + source channel crosses set interrupt threshold high/low level. + +properties: + compatible: + const: rohm,bh1745 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: true + +required: + - compatible + - reg + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + colour-sensor@38 { + compatible = "rohm,bh1745"; + reg = <0x38>; + interrupt-parent = <&gpio>; + interrupts = <19 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vdd>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27034anuc.yaml index 30a109a1bf3b..29c90ca5b258 100644 --- a/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml +++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27034anuc.yaml @@ -1,23 +1,22 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/iio/light/rohm,bu27034.yaml# +$id: http://devicetree.org/schemas/iio/light/rohm,bu27034anuc.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: ROHM BU27034 ambient light sensor +title: ROHM BU27034ANUC ambient light sensor maintainers: - Matti Vaittinen <mazziesaccount@gmail.com> description: | - ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes + ROHM BU27034ANUC is an ambient light sensor with 2 channels and 2 photo diodes capable of detecting a very wide range of illuminance. Typical application is adjusting LCD and backlight power of TVs and mobile phones. - https://fscdn.rohm.com/en/products/databook/datasheet/ic/sensor/light/bu27034nuc-e.pdf properties: compatible: - const: rohm,bu27034 + const: rohm,bu27034anuc reg: maxItems: 1 @@ -37,7 +36,7 @@ examples: #size-cells = <0>; light-sensor@38 { - compatible = "rohm,bu27034"; + compatible = "rohm,bu27034anuc"; reg = <0x38>; vdd-supply = <&vdd>; }; diff --git a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml index f6e22dc9814a..e4341fdced98 100644 --- a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml +++ b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml @@ -18,10 +18,15 @@ allOf: properties: compatible: - enum: - - sensortek,stk3310 - - sensortek,stk3311 - - sensortek,stk3335 + oneOf: + - enum: + - sensortek,stk3310 + - sensortek,stk3311 + - sensortek,stk3335 + - items: + - enum: + - sensortek,stk3013 + - const: sensortek,stk3310 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml index 9790f75fc669..e8ca9a234027 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml +++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml @@ -18,12 +18,15 @@ properties: - asahi-kasei,ak09911 - asahi-kasei,ak09912 - asahi-kasei,ak09916 + - items: + # ak09918 is register compatible with ak09912. + - const: asahi-kasei,ak09918 + - const: asahi-kasei,ak09912 - enum: - ak8975 - ak8963 - ak09911 - ak09912 - - ak09916 deprecated: true reg: diff --git a/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml b/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml index 2867ab6bf9b0..a3838ab0c524 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml +++ b/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml @@ -36,6 +36,9 @@ properties: interrupts: maxItems: 1 + mount-matrix: + description: an optional 3x3 mounting rotation matrix. + additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/iio/pressure/sensirion,sdp500.yaml b/Documentation/devicetree/bindings/iio/pressure/sensirion,sdp500.yaml new file mode 100644 index 000000000000..813239f6879a --- /dev/null +++ b/Documentation/devicetree/bindings/iio/pressure/sensirion,sdp500.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/pressure/sensirion,sdp500.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: sdp500/sdp510 pressure sensor with I2C bus interface + +maintainers: + - Petar Stoykov <petar.stoykov@prodrive-technologies.com> + +description: | + Pressure sensor from Sensirion with I2C bus interface. + There is no software difference between sdp500 and sdp510. + +properties: + compatible: + oneOf: + - items: + - const: sensirion,sdp510 + - const: sensirion,sdp500 + - const: sensirion,sdp500 + + reg: + maxItems: 1 + + vdd-supply: true + +required: + - compatible + - reg + - vdd-supply + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + pressure@40 { + compatible = "sensirion,sdp500"; + reg = <0x40>; + vdd-supply = <&foo>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/proximity/awinic,aw96103.yaml b/Documentation/devicetree/bindings/iio/proximity/awinic,aw96103.yaml new file mode 100644 index 000000000000..7a83ceced11c --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/awinic,aw96103.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/awinic,aw96103.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Awinic's AW96103 capacitive proximity sensor and similar + +maintainers: + - Wang Shuaijie <wangshuaijie@awinic.com> + +description: | + Awinic's AW96103/AW96105 proximity sensor. + The specific absorption rate (SAR) is a metric that measures + the degree of absorption of electromagnetic radiation emitted by + wireless devices, such as mobile phones and tablets, by human tissue. + In mobile phone applications, the proximity sensor is primarily + used to detect the proximity of the human body to the phone. When the + phone approaches the human body, it will actively reduce the transmit + power of the antenna to keep the SAR within a safe range. Therefore, + we also refer to the proximity sensor as a SAR sensor. + +properties: + compatible: + enum: + - awinic,aw96103 + - awinic,aw96105 + + reg: + maxItems: 1 + + interrupts: + description: + Generated by the device to announce that a close/far + proximity event has happened. + maxItems: 1 + + vcc-supply: true + +required: + - compatible + - reg + - interrupts + - vcc-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + proximity@12 { + compatible = "awinic,aw96103"; + reg = <0x12>; + interrupt-parent = <&gpio>; + interrupts = <23 IRQ_TYPE_EDGE_FALLING>; + vcc-supply = <&pp1800_prox>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml new file mode 100644 index 000000000000..64ce8bc8bd36 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/tyhx,hx9023s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TYHX HX9023S capacitive proximity sensor + +maintainers: + - Yasin Lee <yasin.lee.x@gmail.com> + +description: | + TYHX HX9023S proximity sensor. Datasheet can be found here: + http://www.tianyihexin.com/ueditor/php/upload/file/20240614/1718336303992081.pdf + +properties: + compatible: + const: tyhx,hx9023s + + reg: + maxItems: 1 + + interrupts: + description: + Generated by device to announce preceding read request has finished + and data is available or that a close/far proximity event has happened. + maxItems: 1 + + vdd-supply: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^channel@[0-4]$": + $ref: /schemas/iio/adc/adc.yaml + type: object + unevaluatedProperties: false + + properties: + reg: + minimum: 0 + maximum: 4 + description: The channel number. + +required: + - compatible + - reg + - vdd-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + proximity@2a { + compatible = "tyhx,hx9023s"; + reg = <0x2a>; + interrupt-parent = <&pio>; + interrupts = <16 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&pp1800_prox>; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + single-channel = <0>; + }; + channel@1 { + reg = <1>; + single-channel = <1>; + }; + channel@2 { + reg = <2>; + single-channel = <2>; + }; + channel@3 { + reg = <3>; + diff-channels = <1 0>; + }; + channel@4 { + reg = <4>; + diff-channels = <2 0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/input/adi,adp5588.yaml b/Documentation/devicetree/bindings/input/adi,adp5588.yaml index 26ea66834ae2..336bc352579a 100644 --- a/Documentation/devicetree/bindings/input/adi,adp5588.yaml +++ b/Documentation/devicetree/bindings/input/adi,adp5588.yaml @@ -49,7 +49,10 @@ properties: interrupt-controller: description: This property applies if either keypad,num-rows lower than 8 or - keypad,num-columns lower than 10. + keypad,num-columns lower than 10. This property is optional if + keypad,num-rows or keypad,num-columns are not specified as the + device is then configured to be used purely for gpio during which + interrupts may or may not be utilized. '#interrupt-cells': const: 2 @@ -65,13 +68,23 @@ properties: minItems: 1 maxItems: 2 +dependencies: + keypad,num-rows: + - linux,keymap + - keypad,num-columns + keypad,num-columns: + - linux,keymap + - keypad,num-rows + linux,keymap: + - keypad,num-rows + - keypad,num-columns + - interrupts + interrupt-controller: + - interrupts + required: - compatible - reg - - interrupts - - keypad,num-rows - - keypad,num-columns - - linux,keymap unevaluatedProperties: false @@ -108,4 +121,19 @@ examples: >; }; }; + + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + gpio@34 { + compatible = "adi,adp5588"; + reg = <0x34>; + + #gpio-cells = <2>; + gpio-controller; + }; + }; + ... diff --git a/Documentation/devicetree/bindings/input/cirrus,ep9307-keypad.yaml b/Documentation/devicetree/bindings/input/cirrus,ep9307-keypad.yaml new file mode 100644 index 000000000000..a0d2460c55ab --- /dev/null +++ b/Documentation/devicetree/bindings/input/cirrus,ep9307-keypad.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/cirrus,ep9307-keypad.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus ep93xx keypad + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + +allOf: + - $ref: /schemas/input/matrix-keymap.yaml# + +description: + The KPP is designed to interface with a keypad matrix with 2-point contact + or 3-point contact keys. The KPP is designed to simplify the software task + of scanning a keypad matrix. The KPP is capable of detecting, debouncing, + and decoding one or multiple keys pressed simultaneously on a keypad. + +properties: + compatible: + oneOf: + - const: cirrus,ep9307-keypad + - items: + - enum: + - cirrus,ep9312-keypad + - cirrus,ep9315-keypad + - const: cirrus,ep9307-keypad + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + debounce-delay-ms: + description: | + Time in microseconds that key must be pressed or + released for state change interrupt to trigger. + + cirrus,prescale: + description: row/column counter pre-scaler load value + $ref: /schemas/types.yaml#/definitions/uint16 + maximum: 1023 + +required: + - compatible + - reg + - interrupts + - clocks + - linux,keymap + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/input/input.h> + #include <dt-bindings/clock/cirrus,ep9301-syscon.h> + keypad@800f0000 { + compatible = "cirrus,ep9307-keypad"; + reg = <0x800f0000 0x0c>; + interrupt-parent = <&vic0>; + interrupts = <29>; + clocks = <&eclk EP93XX_CLK_KEYPAD>; + pinctrl-names = "default"; + pinctrl-0 = <&keypad_default_pins>; + linux,keymap = <KEY_UP>, + <KEY_DOWN>, + <KEY_VOLUMEDOWN>, + <KEY_HOME>, + <KEY_RIGHT>, + <KEY_LEFT>, + <KEY_ENTER>, + <KEY_VOLUMEUP>, + <KEY_F6>, + <KEY_F8>, + <KEY_F9>, + <KEY_F10>, + <KEY_F1>, + <KEY_F2>, + <KEY_F3>, + <KEY_POWER>; + }; diff --git a/Documentation/devicetree/bindings/input/goodix,gt7986u.yaml b/Documentation/devicetree/bindings/input/goodix,gt7986u.yaml deleted file mode 100644 index a7d42a5d6128..000000000000 --- a/Documentation/devicetree/bindings/input/goodix,gt7986u.yaml +++ /dev/null @@ -1,71 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/input/goodix,gt7986u.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: GOODIX GT7986U SPI HID Touchscreen - -maintainers: - - Charles Wang <charles.goodix@gmail.com> - -description: Supports the Goodix GT7986U touchscreen. - This touch controller reports data packaged according to the HID protocol, - but is incompatible with Microsoft's HID-over-SPI protocol. - -allOf: - - $ref: /schemas/spi/spi-peripheral-props.yaml# - -properties: - compatible: - enum: - - goodix,gt7986u - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - reset-gpios: - maxItems: 1 - - goodix,hid-report-addr: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - The register address for retrieving HID report data. - This address is related to the device firmware and may - change after a firmware update. - - spi-max-frequency: true - -additionalProperties: false - -required: - - compatible - - reg - - interrupts - - reset-gpios - - goodix,hid-report-addr - -examples: - - | - #include <dt-bindings/interrupt-controller/irq.h> - #include <dt-bindings/gpio/gpio.h> - - spi { - #address-cells = <1>; - #size-cells = <0>; - - touchscreen@0 { - compatible = "goodix,gt7986u"; - reg = <0>; - interrupt-parent = <&gpio>; - interrupts = <25 IRQ_TYPE_LEVEL_LOW>; - reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>; - spi-max-frequency = <10000000>; - goodix,hid-report-addr = <0x22c8c>; - }; - }; - -... diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt deleted file mode 100644 index a644408b33b8..000000000000 --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt +++ /dev/null @@ -1,50 +0,0 @@ -Rotary encoder DT bindings - -Required properties: -- gpios: a spec for at least two GPIOs to be used, most significant first - -Optional properties: -- linux,axis: the input subsystem axis to map to this rotary encoder. - Defaults to 0 (ABS_X / REL_X) -- rotary-encoder,steps: Number of steps in a full turnaround of the - encoder. Only relevant for absolute axis. Defaults to 24 which is a - typical value for such devices. -- rotary-encoder,relative-axis: register a relative axis rather than an - absolute one. Relative axis will only generate +1/-1 events on the input - device, hence no steps need to be passed. -- rotary-encoder,rollover: Automatic rollover when the rotary value becomes - greater than the specified steps or smaller than 0. For absolute axis only. -- rotary-encoder,steps-per-period: Number of steps (stable states) per period. - The values have the following meaning: - 1: Full-period mode (default) - 2: Half-period mode - 4: Quarter-period mode -- wakeup-source: Boolean, rotary encoder can wake up the system. -- rotary-encoder,encoding: String, the method used to encode steps. - Supported are "gray" (the default and more common) and "binary". - -Deprecated properties: -- rotary-encoder,half-period: Makes the driver work on half-period mode. - This property is deprecated. Instead, a 'steps-per-period ' value should - be used, such as "rotary-encoder,steps-per-period = <2>". - -See Documentation/input/devices/rotary-encoder.rst for more information. - -Example: - - rotary@0 { - compatible = "rotary-encoder"; - gpios = <&gpio 19 1>, <&gpio 20 0>; /* GPIO19 is inverted */ - linux,axis = <0>; /* REL_X */ - rotary-encoder,encoding = "gray"; - rotary-encoder,relative-axis; - }; - - rotary@1 { - compatible = "rotary-encoder"; - gpios = <&gpio 21 0>, <&gpio 22 0>; - linux,axis = <1>; /* ABS_Y */ - rotary-encoder,steps = <24>; - rotary-encoder,encoding = "binary"; - rotary-encoder,rollover; - }; diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.yaml b/Documentation/devicetree/bindings/input/rotary-encoder.yaml new file mode 100644 index 000000000000..e315aab7f584 --- /dev/null +++ b/Documentation/devicetree/bindings/input/rotary-encoder.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/rotary-encoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rotary encoder + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: + See Documentation/input/devices/rotary-encoder.rst for more information. + +properties: + compatible: + const: rotary-encoder + + gpios: + minItems: 2 + + linux,axis: + default: 0 + description: + the input subsystem axis to map to this rotary encoder. + Defaults to 0 (ABS_X / REL_X) + + rotary-encoder,steps: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 24 + description: + Number of steps in a full turnaround of the + encoder. Only relevant for absolute axis. Defaults to 24 which is a + typical value for such devices. + + rotary-encoder,relative-axis: + $ref: /schemas/types.yaml#/definitions/flag + description: + register a relative axis rather than an + absolute one. Relative axis will only generate +1/-1 events on the input + device, hence no steps need to be passed. + + rotary-encoder,rollover: + $ref: /schemas/types.yaml#/definitions/int32 + description: + Automatic rollover when the rotary value becomes + greater than the specified steps or smaller than 0. For absolute axis only. + + rotary-encoder,steps-per-period: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 1 + enum: [1, 2, 4] + description: | + Number of steps (stable states) per period. + The values have the following meaning: + 1: Full-period mode (default) + 2: Half-period mode + 4: Quarter-period mode + + wakeup-source: true + + rotary-encoder,encoding: + $ref: /schemas/types.yaml#/definitions/string + description: the method used to encode steps. + enum: [gray, binary] + + rotary-encoder,half-period: + $ref: /schemas/types.yaml#/definitions/flag + deprecated: true + description: + Makes the driver work on half-period mode. + This property is deprecated. Instead, a 'steps-per-period ' value should + be used, such as "rotary-encoder,steps-per-period = <2>". + +required: + - compatible + - gpios + +additionalProperties: false + +examples: + - | + rotary { + compatible = "rotary-encoder"; + gpios = <&gpio 19 1>, <&gpio 20 0>; /* GPIO19 is inverted */ + linux,axis = <0>; /* REL_X */ + rotary-encoder,encoding = "gray"; + rotary-encoder,relative-axis; + }; + diff --git a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt b/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt deleted file mode 100644 index afa38dc069f0..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt +++ /dev/null @@ -1,71 +0,0 @@ -* Analog Devices AD7879(-1)/AD7889(-1) touchscreen interface (SPI/I2C) - -Required properties: -- compatible : for SPI slave, use "adi,ad7879" - for I2C slave, use "adi,ad7879-1" -- reg : SPI chipselect/I2C slave address - See spi-bus.txt for more SPI slave properties -- interrupts : touch controller interrupt -- touchscreen-max-pressure : maximum reported pressure -- adi,resistance-plate-x : total resistance of X-plate (for pressure - calculation) -Optional properties: -- touchscreen-swapped-x-y : X and Y axis are swapped (boolean) -- adi,first-conversion-delay : 0-12: In 128us steps (starting with 128us) - 13 : 2.560ms - 14 : 3.584ms - 15 : 4.096ms - This property has to be a '/bits/ 8' value -- adi,acquisition-time : 0: 2us - 1: 4us - 2: 8us - 3: 16us - This property has to be a '/bits/ 8' value -- adi,median-filter-size : 0: disabled - 1: 4 measurements - 2: 8 measurements - 3: 16 measurements - This property has to be a '/bits/ 8' value -- adi,averaging : 0: 2 middle values (1 if median disabled) - 1: 4 middle values - 2: 8 middle values - 3: 16 values - This property has to be a '/bits/ 8' value -- adi,conversion-interval: : 0 : convert one time only - 1-255: 515us + val * 35us (up to 9.440ms) - This property has to be a '/bits/ 8' value -- gpio-controller : Switch AUX/VBAT/GPIO pin to GPIO mode - -Example: - - touchscreen0@2c { - compatible = "adi,ad7879-1"; - reg = <0x2c>; - interrupt-parent = <&gpio1>; - interrupts = <13 IRQ_TYPE_EDGE_FALLING>; - touchscreen-max-pressure = <4096>; - adi,resistance-plate-x = <120>; - adi,first-conversion-delay = /bits/ 8 <3>; - adi,acquisition-time = /bits/ 8 <1>; - adi,median-filter-size = /bits/ 8 <2>; - adi,averaging = /bits/ 8 <1>; - adi,conversion-interval = /bits/ 8 <255>; - }; - - touchscreen1@1 { - compatible = "adi,ad7879"; - spi-max-frequency = <5000000>; - reg = <1>; - spi-cpol; - spi-cpha; - gpio-controller; - interrupt-parent = <&gpio1>; - interrupts = <13 IRQ_TYPE_EDGE_FALLING>; - touchscreen-max-pressure = <4096>; - adi,resistance-plate-x = <120>; - adi,first-conversion-delay = /bits/ 8 <3>; - adi,acquisition-time = /bits/ 8 <1>; - adi,median-filter-size = /bits/ 8 <2>; - adi,averaging = /bits/ 8 <1>; - adi,conversion-interval = /bits/ 8 <255>; - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/adi,ad7879.yaml b/Documentation/devicetree/bindings/input/touchscreen/adi,ad7879.yaml new file mode 100644 index 000000000000..caa5fa3cc3f1 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/adi,ad7879.yaml @@ -0,0 +1,150 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/adi,ad7879.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD7879(-1)/AD7889(-1) touchscreen interface (SPI/I2C) + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +properties: + compatible: + description: | + for SPI slave, use "adi,ad7879" + for I2C slave, use "adi,ad7879-1" + enum: + - adi,ad7879 + - adi,ad7879-1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + touchscreen-max-pressure: + $ref: /schemas/types.yaml#/definitions/uint32 + description: maximum reported pressure + + adi,resistance-plate-x: + $ref: /schemas/types.yaml#/definitions/uint32 + description: total resistance of X-plate (for pressure calculation) + + touchscreen-swapped-x-y: + $ref: /schemas/types.yaml#/definitions/flag + description: X and Y axis are swapped (boolean) + + adi,first-conversion-delay: + $ref: /schemas/types.yaml#/definitions/uint8 + default: 0 + minimum: 0 + maximum: 15 + description: | + 0-12: In 128us steps (starting with 128us) + 13 : 2.560ms + 14 : 3.584ms + 15 : 4.096ms + This property has to be a '/bits/ 8' value + + adi,acquisition-time: + $ref: /schemas/types.yaml#/definitions/uint8 + default: 0 + enum: [0, 1, 2, 3] + description: | + 0: 2us + 1: 4us + 2: 8us + 3: 16us + This property has to be a '/bits/ 8' value + + adi,median-filter-size: + $ref: /schemas/types.yaml#/definitions/uint8 + default: 0 + enum: [0, 1, 2, 3] + description: | + 0: disabled + 1: 4 measurements + 2: 8 measurements + 3: 16 measurements + This property has to be a '/bits/ 8' value + + adi,averaging: + $ref: /schemas/types.yaml#/definitions/uint8 + default: 0 + enum: [0, 1, 2, 3] + description: | + 0: 2 middle values (1 if median disabled) + 1: 4 middle values + 2: 8 middle values + 3: 16 values + This property has to be a '/bits/ 8' value + + adi,conversion-interval: + $ref: /schemas/types.yaml#/definitions/uint8 + default: 0 + description: | + 0 : convert one time only + 1-255: 515us + val * 35us (up to 9.440ms) + This property has to be a '/bits/ 8' value + + gpio-controller: true + + "#gpio-cells": + const: 1 + +required: + - compatible + - reg + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen0@2c { + compatible = "adi,ad7879-1"; + reg = <0x2c>; + interrupt-parent = <&gpio1>; + interrupts = <13 IRQ_TYPE_EDGE_FALLING>; + touchscreen-max-pressure = <4096>; + adi,resistance-plate-x = <120>; + adi,first-conversion-delay = /bits/ 8 <3>; + adi,acquisition-time = /bits/ 8 <1>; + adi,median-filter-size = /bits/ 8 <2>; + adi,averaging = /bits/ 8 <1>; + adi,conversion-interval = /bits/ 8 <255>; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen1@1 { + compatible = "adi,ad7879"; + reg = <1>; + spi-max-frequency = <5000000>; + gpio-controller; + #gpio-cells = <1>; + interrupt-parent = <&gpio1>; + interrupts = <13 IRQ_TYPE_EDGE_FALLING>; + touchscreen-max-pressure = <4096>; + adi,resistance-plate-x = <120>; + adi,first-conversion-delay = /bits/ 8 <3>; + adi,acquisition-time = /bits/ 8 <1>; + adi,median-filter-size = /bits/ 8 <2>; + adi,averaging = /bits/ 8 <1>; + adi,conversion-interval = /bits/ 8 <255>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt deleted file mode 100644 index 399c87782935..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt +++ /dev/null @@ -1,107 +0,0 @@ -Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046 -SPI driven touch screen controllers. - -The node for this driver must be a child node of a SPI controller, hence -all mandatory properties described in - - Documentation/devicetree/bindings/spi/spi-bus.txt - -must be specified. - -Additional required properties: - - compatible Must be one of the following, depending on the - model: - "ti,tsc2046" - "ti,ads7843" - "ti,ads7845" - "ti,ads7846" - "ti,ads7873" - - interrupts An interrupt node describing the IRQ line the chip's - !PENIRQ pin is connected to. - vcc-supply A regulator node for the supply voltage. - - -Optional properties: - - ti,vref-delay-usecs vref supply delay in usecs, 0 for - external vref (u16). - ti,vref-mv The VREF voltage, in millivolts (u16). - Set to 0 to use internal references - (ADS7846). - ti,keep-vref-on set to keep vref on for differential - measurements as well - ti,settle-delay-usec Settling time of the analog signals; - a function of Vcc and the capacitance - on the X/Y drivers. If set to non-zero, - two samples are taken with settle_delay - us apart, and the second one is used. - ~150 uSec with 0.01uF caps (u16). - ti,penirq-recheck-delay-usecs If set to non-zero, after samples are - taken this delay is applied and penirq - is rechecked, to help avoid false - events. This value is affected by the - material used to build the touch layer - (u16). - ti,x-plate-ohms Resistance of the X-plate, - in Ohms (u16). - ti,y-plate-ohms Resistance of the Y-plate, - in Ohms (u16). - ti,x-min Minimum value on the X axis (u16). - ti,y-min Minimum value on the Y axis (u16). - ti,debounce-tol Tolerance used for filtering (u16). - ti,debounce-rep Additional consecutive good readings - required after the first two (u16). - ti,pendown-gpio-debounce Platform specific debounce time for the - pendown-gpio (u32). - pendown-gpio GPIO handle describing the pin the !PENIRQ - line is connected to. - ti,hsync-gpios GPIO line to poll for hsync - wakeup-source use any event on touchscreen as wakeup event. - (Legacy property support: "linux,wakeup") - touchscreen-size-x General touchscreen binding, see [1]. - touchscreen-size-y General touchscreen binding, see [1]. - touchscreen-max-pressure General touchscreen binding, see [1]. - touchscreen-min-pressure General touchscreen binding, see [1]. - touchscreen-average-samples General touchscreen binding, see [1]. - touchscreen-inverted-x General touchscreen binding, see [1]. - touchscreen-inverted-y General touchscreen binding, see [1]. - touchscreen-swapped-x-y General touchscreen binding, see [1]. - -[1] All general touchscreen properties are described in - Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt. - -Deprecated properties: - - ti,swap-xy swap x and y axis - ti,x-max Maximum value on the X axis (u16). - ti,y-max Maximum value on the Y axis (u16). - ti,pressure-min Minimum reported pressure value - (threshold) - u16. - ti,pressure-max Maximum reported pressure value (u16). - ti,debounce-max Max number of additional readings per - sample (u16). - -Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC:: - - spi_controller { - tsc2046@0 { - reg = <0>; /* CS0 */ - compatible = "ti,tsc2046"; - interrupt-parent = <&gpio1>; - interrupts = <8 0>; /* BOOT6 / GPIO 8 */ - spi-max-frequency = <1000000>; - pendown-gpio = <&gpio1 8 0>; - vcc-supply = <®_vcc3>; - - ti,x-min = /bits/ 16 <0>; - ti,x-max = /bits/ 16 <8000>; - ti,y-min = /bits/ 16 <0>; - ti,y-max = /bits/ 16 <4800>; - ti,x-plate-ohms = /bits/ 16 <40>; - ti,pressure-max = /bits/ 16 <255>; - - wakeup-source; - }; - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml index 8cf371b99f19..e4dbbafb3779 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml @@ -666,7 +666,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - touch@56 { + touchscreen@56 { compatible = "azoteq,iqs7210a"; reg = <0x56>; irq-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; @@ -704,7 +704,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - touch@56 { + touchscreen@56 { compatible = "azoteq,iqs7211e"; reg = <0x56>; irq-gpios = <&gpio 4 (GPIO_ACTIVE_LOW | diff --git a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt deleted file mode 100644 index ca304357c374..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt +++ /dev/null @@ -1,34 +0,0 @@ -* Toradex Colibri VF50 Touchscreen driver - -Required Properties: -- compatible must be toradex,vf50-touchscreen -- io-channels: adc channels being used by the Colibri VF50 module - IIO ADC for Y-, X-, Y+, X+ connections -- xp-gpios: FET gate driver for input of X+ -- xm-gpios: FET gate driver for input of X- -- yp-gpios: FET gate driver for input of Y+ -- ym-gpios: FET gate driver for input of Y- -- interrupts: pen irq interrupt for touch detection, signal from X plate -- pinctrl-names: "idle", "default" -- pinctrl-0: pinctrl node for pen/touch detection, pinctrl must provide - pull-up resistor on X+, X-. -- pinctrl-1: pinctrl node for X/Y and pressure measurement (ADC) state pinmux -- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y values - -Example: - - touchctrl: vf50_touchctrl { - compatible = "toradex,vf50-touchscreen"; - io-channels = <&adc1 0>,<&adc0 0>, - <&adc0 1>,<&adc1 2>; - xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; - xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>; - yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; - ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>; - interrupt-parent = <&gpio0>; - interrupts = <8 IRQ_TYPE_LEVEL_LOW>; - pinctrl-names = "idle","default"; - pinctrl-0 = <&pinctrl_touchctrl_idle>, <&pinctrl_touchctrl_gpios>; - pinctrl-1 = <&pinctrl_touchctrl_default>, <&pinctrl_touchctrl_gpios>; - vf50-ts-min-pressure = <200>; - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index 51d48d4130d3..70a922e213f2 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -126,7 +126,7 @@ examples: i2c { #address-cells = <1>; #size-cells = <0>; - edt-ft5x06@38 { + touchscreen@38 { compatible = "edt,edt-ft5406"; reg = <0x38>; interrupt-parent = <&gpio2>; diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml index 2a2d86cfd104..eb4992f708b7 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml @@ -69,7 +69,7 @@ examples: i2c { #address-cells = <1>; #size-cells = <0>; - gt928@5d { + touchscreen@5d { compatible = "goodix,gt928"; reg = <0x5d>; interrupt-parent = <&gpio>; diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml new file mode 100644 index 000000000000..604921733d2c --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml @@ -0,0 +1,183 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/ti,ads7843.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI's SPI driven touch screen controllers + +maintainers: + - Alexander Stein <alexander.stein@ew.tq-group.com> + - Dmitry Torokhov <dmitry.torokhov@gmail.com> + - Marek Vasut <marex@denx.de> + +description: + TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046 SPI driven touch screen + controllers. + +properties: + compatible: + enum: + - ti,ads7843 + - ti,ads7845 + - ti,ads7846 + - ti,ads7873 + - ti,tsc2046 + + interrupts: + maxItems: 1 + + pendown-gpio: + maxItems: 1 + description: + GPIO handle describing the pin the !PENIRQ line is connected to. + + vcc-supply: + description: + A regulator node for the supply voltage. + + wakeup-source: true + + ti,debounce-max: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Max number of additional readings per sample. + + ti,debounce-rep: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Additional consecutive good readings required after the first two. + + ti,debounce-tol: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Tolerance used for filtering. + + ti,hsync-gpios: + maxItems: 1 + description: + GPIO line to poll for hsync. + + ti,keep-vref-on: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set to keep Vref on for differential measurements as well. + + ti,pendown-gpio-debounce: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Platform specific debounce time for the pendown-gpio. + + ti,penirq-recheck-delay-usecs: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + If set to non-zero, after samples are taken this delay is applied and + penirq is rechecked, to help avoid false events. This value is + affected by the material used to build the touch layer. + + ti,pressure-max: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Maximum reported pressure value. + + ti,pressure-min: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Minimum reported pressure value (threshold). + + ti,settle-delay-usec: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Settling time of the analog signals; a function of Vcc and the + capacitance on the X/Y drivers. If set to non-zero, two samples are + taken with settle_delay us apart, and the second one is used. ~150 + uSec with 0.01uF caps. + + ti,swap-xy: + deprecated: true + $ref: /schemas/types.yaml#/definitions/flag + description: + Swap x and y axis. + + ti,vref-delay-usecs: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Vref supply delay in usecs, 0 for external Vref. + + ti,vref-mv: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + The VREF voltage, in millivolts. + Set to 0 to use internal references (ADS7846). + + ti,x-plate-ohms: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Resistance of the X-plate, in Ohms. + + ti,x-max: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Maximum value on the X axis. + + ti,x-min: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Minimum value on the X axis. + + ti,y-plate-ohms: + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Resistance of the Y-plate, in Ohms. + + ti,y-max: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Maximum value on the Y axis. + + ti,y-min: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint16 + description: + Minimum value on the Y axis. + +required: + - compatible + - reg + +allOf: + - $ref: touchscreen.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + +examples: + - | + spi{ + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@0 { + compatible = "ti,tsc2046"; + reg = <0>; /* CS0 */ + interrupt-parent = <&gpio1>; + interrupts = <8 0>; /* BOOT6 / GPIO 8 */ + pendown-gpio = <&gpio1 8 0>; + spi-max-frequency = <1000000>; + vcc-supply = <®_vcc3>; + wakeup-source; + + ti,pressure-max = /bits/ 16 <255>; + ti,x-max = /bits/ 16 <8000>; + ti,x-min = /bits/ 16 <0>; + ti,x-plate-ohms = /bits/ 16 <40>; + ti,y-max = /bits/ 16 <4800>; + ti,y-min = /bits/ 16 <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/toradex,vf50-touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/toradex,vf50-touchscreen.yaml new file mode 100644 index 000000000000..5094c5183c74 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/toradex,vf50-touchscreen.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/toradex,vf50-touchscreen.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toradex Colibri VF50 Touchscreen + +maintainers: + - Dmitry Torokhov <dmitry.torokhov@gmail.com> + - Sanchayan Maity <maitysanchayan@gmail.com> + +properties: + compatible: + const: toradex,vf50-touchscreen + + interrupts: + maxItems: 1 + + io-channels: + maxItems: 4 + description: + adc channels being used by the Colibri VF50 module + IIO ADC for Y-, X-, Y+, X+ connections + + xp-gpios: + description: FET gate driver for input of X+ + + xm-gpios: + description: FET gate driver for input of X- + + yp-gpios: + description: FET gate driver for input of Y+ + + ym-gpios: + description: FET gate driver for input of Y- + + vf50-ts-min-pressure: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 50 + maximum: 2000 + description: pressure level at which to stop measuring X/Y values + +required: + - compatible + - io-channels + - xp-gpios + - xm-gpios + - yp-gpios + - ym-gpios + - interrupts + - vf50-ts-min-pressure + +allOf: + - $ref: touchscreen.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + + touchscreen { + compatible = "toradex,vf50-touchscreen"; + interrupt-parent = <&gpio0>; + interrupts = <8 IRQ_TYPE_LEVEL_LOW>; + io-channels = <&adc1 0>, <&adc0 0>, <&adc0 1>, <&adc1 2>; + xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; + xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>; + yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; + ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>; + pinctrl-names = "idle", "default"; + pinctrl-0 = <&pinctrl_touchctrl_idle>, <&pinctrl_touchctrl_gpios>; + pinctrl-1 = <&pinctrl_touchctrl_default>, <&pinctrl_touchctrl_gpios>; + vf50-ts-min-pressure = <200>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml b/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml index b1507463a03e..3f663ce3e44e 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml @@ -16,6 +16,7 @@ maintainers: allOf: - $ref: touchscreen.yaml# + - $ref: ../input.yaml# properties: $nodename: @@ -79,6 +80,15 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 2] + linux,keycodes: + description: + This property specifies an array of keycodes assigned to the + touch-keys that can be present in some touchscreen configurations. + If the touch-keys are enabled, controller firmware will assign some + touch sense lines to those keys. + minItems: 1 + maxItems: 8 + touchscreen-size-x: true touchscreen-size-y: true touchscreen-fuzz-x: true diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml index fd15ab5014fb..4b08be72bbd7 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml @@ -4,14 +4,14 @@ $id: http://devicetree.org/schemas/interconnect/qcom,msm8939.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm MSM8939 Network-On-Chip interconnect +title: Qualcomm MSM8937/MSM8939/MSM8976 Network-On-Chip interconnect maintainers: - Konrad Dybcio <konradybcio@kernel.org> -description: | - The Qualcomm MSM8939 interconnect providers support adjusting the - bandwidth requirements between the various NoC fabrics. +description: + The Qualcomm MSM8937/MSM8939/MSM8976 interconnect providers support + adjusting the bandwidth requirements between the various NoC fabrics. allOf: - $ref: qcom,rpm-common.yaml# @@ -19,9 +19,15 @@ allOf: properties: compatible: enum: + - qcom,msm8937-bimc + - qcom,msm8937-pcnoc + - qcom,msm8937-snoc - qcom,msm8939-bimc - qcom,msm8939-pcnoc - qcom,msm8939-snoc + - qcom,msm8976-bimc + - qcom,msm8976-pcnoc + - qcom,msm8976-snoc reg: maxItems: 1 @@ -39,7 +45,10 @@ patternProperties: properties: compatible: - const: qcom,msm8939-snoc-mm + enum: + - qcom,msm8937-snoc-mm + - qcom,msm8939-snoc-mm + - qcom,msm8976-snoc-mm required: - compatible @@ -60,12 +69,6 @@ examples: compatible = "qcom,msm8939-snoc"; reg = <0x00580000 0x14000>; #interconnect-cells = <1>; - }; - - bimc: interconnect@400000 { - compatible = "qcom,msm8939-bimc"; - reg = <0x00400000 0x62000>; - #interconnect-cells = <1>; snoc_mm: interconnect-snoc { compatible = "qcom,msm8939-snoc-mm"; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml index 732e9fa001a4..343ff62d7b65 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml @@ -13,8 +13,7 @@ description: | The Qualcomm MSM8953 interconnect providers support adjusting the bandwidth requirements between the various NoC fabrics. - See also: - - dt-bindings/interconnect/qcom,msm8953.h + See also: include/dt-bindings/interconnect/qcom,msm8953.h properties: compatible: diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml index 2cd1f5590fd9..189f5900ee50 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml @@ -26,6 +26,7 @@ properties: - items: - enum: - qcom,qcm2290-cpu-bwmon + - qcom,sa8775p-cpu-bwmon - qcom,sc7180-cpu-bwmon - qcom,sc7280-cpu-bwmon - qcom,sc8280xp-cpu-bwmon @@ -39,6 +40,7 @@ properties: - const: qcom,sdm845-bwmon # BWMON v4, unified register space - items: - enum: + - qcom,sa8775p-llcc-bwmon - qcom,sc7180-llcc-bwmon - qcom,sc8280xp-llcc-bwmon - qcom,sm6350-cpu-bwmon diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 9318b845ec35..1b9164dc162f 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -71,7 +71,7 @@ properties: - qcom,sdx65-system-noc - qcom,sm8150-aggre1-noc - qcom,sm8150-aggre2-noc - - qcom,sm8150-camnoc-noc + - qcom,sm8150-camnoc-virt - qcom,sm8150-compute-noc - qcom,sm8150-config-noc - qcom,sm8150-dc-noc @@ -113,6 +113,9 @@ allOf: properties: compatible: enum: + - qcom,sc8180x-camnoc-virt + - qcom,sc8180x-mc-virt + - qcom,sc8180x-qup-virt - qcom,sdx65-mc-virt - qcom,sm8250-qup-virt then: diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml index 199b34fdbefc..7ff4efc4758a 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml @@ -82,9 +82,6 @@ allOf: enum: - fsl,ls1043a-extirq - fsl,ls1046a-extirq - - fsl,ls1088a-extirq - - fsl,ls2080a-extirq - - fsl,lx2160a-extirq then: properties: interrupt-map: @@ -95,6 +92,29 @@ allOf: - const: 0xf - const: 0 + - if: + properties: + compatible: + contains: + enum: + - fsl,ls1088a-extirq + - fsl,ls2080a-extirq + - fsl,lx2160a-extirq +# The driver(drivers/irqchip/irq-ls-extirq.c) have not use standard DT +# function to parser interrupt-map. So it doesn't consider '#address-size' +# in parent interrupt controller, such as GIC. +# +# When dt-binding verify interrupt-map, item data matrix is spitted at +# incorrect position. Remove interrupt-map restriction because it always +# wrong. + + then: + properties: + interrupt-map-mask: + items: + - const: 0xf + - const: 0 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml index 72c1d9e82c89..8a1369df4ecb 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml @@ -17,9 +17,15 @@ description: | properties: compatible: - enum: - - mediatek,mt8195-adsp-mbox - - mediatek,mt8186-adsp-mbox + oneOf: + - enum: + - mediatek,mt8186-adsp-mbox + - mediatek,mt8195-adsp-mbox + - items: + - enum: + - mediatek,mt8188-adsp-mbox + - const: mediatek,mt8186-adsp-mbox + "#mbox-cells": const: 0 diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index 05e4e1d51713..2d66770ed361 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -24,7 +24,9 @@ properties: compatible: items: - enum: + - qcom,qcs8300-ipcc - qcom,qdu1000-ipcc + - qcom,sa8255p-ipcc - qcom,sa8775p-ipcc - qcom,sc7280-ipcc - qcom,sc8280xp-ipcc diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml index 01b00d89a992..df45ff56d444 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml @@ -113,7 +113,7 @@ properties: msi-parent: deprecated: true - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 description: Describes the MSI controller node handling message interrupts for the MC. When there is no translation diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml index c27a8f33d8d7..0840a3d92513 100644 --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml @@ -26,6 +26,7 @@ properties: - mdsp - sdsp - cdsp + - cdsp1 memory-region: maxItems: 1 @@ -81,7 +82,7 @@ patternProperties: iommus: minItems: 1 - maxItems: 3 + maxItems: 10 qcom,nsessions: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/mtd/technologic,nand.yaml b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml new file mode 100644 index 000000000000..f9d87c46094b --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/technologic,nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Technologic Systems NAND controller + +maintainers: + - Nikita Shubin <nikita.shubin@maquefel.me> + +allOf: + - $ref: nand-controller.yaml + +properties: + compatible: + oneOf: + - const: technologic,ts7200-nand + - items: + - enum: + - technologic,ts7300-nand + - technologic,ts7260-nand + - technologic,ts7250-nand + - const: technologic,ts7200-nand + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + nand-controller@60000000 { + compatible = "technologic,ts7200-nand"; + reg = <0x60000000 0x8000000>; + #address-cells = <1>; + #size-cells = <0>; + nand@0 { + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml index 23dfe0838dca..63bee5b542f5 100644 --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml @@ -26,6 +26,7 @@ properties: - brcm,asp-v2.1-mdio - brcm,asp-v2.2-mdio - brcm,unimac-mdio + - brcm,bcm6846-mdio reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/net/cirrus,ep9301-eth.yaml b/Documentation/devicetree/bindings/net/cirrus,ep9301-eth.yaml new file mode 100644 index 000000000000..ad0915307095 --- /dev/null +++ b/Documentation/devicetree/bindings/net/cirrus,ep9301-eth.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/cirrus,ep9301-eth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EP93xx SoC Ethernet Controller + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + - Nikita Shubin <nikita.shubin@maquefel.me> + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + oneOf: + - const: cirrus,ep9301-eth + - items: + - enum: + - cirrus,ep9302-eth + - cirrus,ep9307-eth + - cirrus,ep9312-eth + - cirrus,ep9315-eth + - const: cirrus,ep9301-eth + + reg: + items: + - description: The physical base address and size of IO range + + interrupts: + items: + - description: Combined signal for various interrupt events + + phy-handle: true + + mdio: + $ref: mdio.yaml# + unevaluatedProperties: false + description: optional node for embedded MDIO controller + +required: + - compatible + - reg + - interrupts + - phy-handle + +additionalProperties: false + +examples: + - | + ethernet@80010000 { + compatible = "cirrus,ep9301-eth"; + reg = <0x80010000 0x10000>; + interrupt-parent = <&vic1>; + interrupts = <7>; + phy-handle = <&phy0>; + }; diff --git a/Documentation/devicetree/bindings/net/ti,cc1352p7.yaml b/Documentation/devicetree/bindings/net/ti,cc1352p7.yaml index 3dde10de4630..4f4253441547 100644 --- a/Documentation/devicetree/bindings/net/ti,cc1352p7.yaml +++ b/Documentation/devicetree/bindings/net/ti,cc1352p7.yaml @@ -29,6 +29,12 @@ properties: reset-gpios: maxItems: 1 + bootloader-backdoor-gpios: + maxItems: 1 + description: | + gpios to enable bootloader backdoor in cc1352p7 bootloader to allow + flashing new firmware. + vdds-supply: true required: @@ -46,6 +52,7 @@ examples: clocks = <&sclk_hf 0>, <&sclk_lf 25>; clock-names = "sclk_hf", "sclk_lf"; reset-gpios = <&pio 35 GPIO_ACTIVE_LOW>; + bootloader-backdoor-gpios = <&pio 36 GPIO_ACTIVE_LOW>; vdds-supply = <&vdds>; }; }; diff --git a/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml index bbe89ea9590c..e95c21628281 100644 --- a/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml @@ -34,6 +34,7 @@ properties: and length of the AXI DMA controller IO space, unless axistream-connected is specified, in which case the reg attribute of the node referenced by it is used. + minItems: 1 maxItems: 2 interrupts: @@ -181,7 +182,7 @@ examples: clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; phy-mode = "mii"; - reg = <0x00 0x40000000 0x00 0x40000>; + reg = <0x40000000 0x40000>; xlnx,rxcsum = <0x2>; xlnx,rxmem = <0x800>; xlnx,txcsum = <0x2>; diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml index 70fb2ad25103..1b20b49eee79 100644 --- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml @@ -15,6 +15,7 @@ description: | allOf: - $ref: nvmem.yaml# + - $ref: nvmem-deprecated-cells.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml index e21c06e9a741..b2cb76cf9053 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml @@ -14,7 +14,7 @@ maintainers: description: | This binding represents the on-chip eFuse OTP controller found on i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, - i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN i.MX8MP and i.MX93 SoCs. + i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN i.MX8MP and i.MX93/5 SoCs. allOf: - $ref: nvmem.yaml# @@ -36,6 +36,7 @@ properties: - fsl,imx8mq-ocotp - fsl,imx8mm-ocotp - fsl,imx93-ocotp + - fsl,imx95-ocotp - const: syscon - items: - enum: diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml index 3b40f7880774..382507060651 100644 --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml @@ -21,6 +21,7 @@ oneOf: - $ref: fixed-layout.yaml - $ref: kontron,sl28-vpd.yaml - $ref: onie,tlv-layout.yaml + - $ref: u-boot,env.yaml properties: compatible: true diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml index 9c36afc7084b..56a8f55d4a09 100644 --- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml +++ b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml @@ -1,10 +1,10 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# +$id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: U-Boot environment variables +title: U-Boot environment variables layout description: | U-Boot uses environment variables to store device parameters and @@ -21,9 +21,6 @@ description: | This binding allows marking storage device (as containing env data) and specifying used format. - Right now only flash partition case is covered but it may be extended to e.g. - UBI volumes in the future. - Variables can be defined as NVMEM device subnodes. maintainers: @@ -42,6 +39,7 @@ properties: const: brcm,env reg: + description: Partition offset and size for env on top of MTD maxItems: 1 bootcmd: @@ -58,6 +56,17 @@ properties: description: The first argument is a MAC address offset. const: 1 +allOf: + - if: + properties: + $nodename: + not: + contains: + pattern: "^partition@[0-9a-f]+$" + then: + properties: + reg: false + additionalProperties: false examples: @@ -101,3 +110,23 @@ examples: }; }; }; + - | + partition@0 { + reg = <0x0 0x100000>; + label = "ubi"; + compatible = "linux,ubi"; + + volumes { + ubi-volume-u-boot-env { + volname = "env"; + + nvmem-layout { + compatible = "u-boot,env"; + + ethaddr { + #nvmem-cell-cells = <1>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml index 92bfe25f0571..3b2aa605a551 100644 --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml @@ -17,6 +17,7 @@ maintainers: allOf: - $ref: nvmem.yaml# + - $ref: nvmem-deprecated-cells.yaml# properties: compatible: @@ -32,6 +33,8 @@ properties: patternProperties: "^.*@[0-9a-f]+$": type: object + $ref: layouts/fixed-cell.yaml + unevaluatedProperties: false properties: st,non-secure-otp: diff --git a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml index f4b1ca2fb562..ce665a2779b7 100644 --- a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml +++ b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml @@ -87,6 +87,12 @@ properties: maximum: 119 default: 100 + nxp,sim: + description: + The system integration module (SIM) provides system control and chip + configuration registers. + $ref: /schemas/types.yaml#/definitions/phandle + required: - compatible - reg @@ -110,6 +116,17 @@ allOf: required: - fsl,anatop + - if: + properties: + compatible: + const: fsl,imx7ulp-usbphy + then: + required: + - nxp,sim + else: + properties: + nxp,sim: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt index 128b55be67b7..27f1797be963 100644 --- a/Documentation/devicetree/bindings/power/wakeup-source.txt +++ b/Documentation/devicetree/bindings/power/wakeup-source.txt @@ -25,7 +25,7 @@ List of legacy properties and respective binding document 2. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt 3. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt Documentation/devicetree/bindings/mfd/tc3589x.txt - Documentation/devicetree/bindings/input/touchscreen/ads7846.txt + Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml 4. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml 5. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml 6. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt diff --git a/Documentation/devicetree/bindings/pwm/cirrus,ep9301-pwm.yaml b/Documentation/devicetree/bindings/pwm/cirrus,ep9301-pwm.yaml new file mode 100644 index 000000000000..903210ef9c31 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/cirrus,ep9301-pwm.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/cirrus,ep9301-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic ep93xx PWM controller + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + - Nikita Shubin <nikita.shubin@maquefel.me> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + oneOf: + - const: cirrus,ep9301-pwm + - items: + - enum: + - cirrus,ep9302-pwm + - cirrus,ep9307-pwm + - cirrus,ep9312-pwm + - cirrus,ep9315-pwm + - const: cirrus,ep9301-pwm + + reg: + maxItems: 1 + + clocks: + items: + - description: SoC PWM clock + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/cirrus,ep9301-syscon.h> + pwm@80910000 { + compatible = "cirrus,ep9301-pwm"; + reg = <0x80910000 0x10>; + clocks = <&syscon EP93XX_CLK_PWM>; + #pwm-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml index 73fda7565cd1..d7fad7b3c2c6 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,sdx75-mpss-pas - qcom,sm8550-adsp-pas - qcom,sm8550-cdsp-pas - qcom,sm8550-mpss-pas @@ -113,6 +114,7 @@ allOf: properties: compatible: enum: + - qcom,sdx75-mpss-pas - qcom,sm8650-mpss-pas then: properties: @@ -146,6 +148,7 @@ allOf: properties: compatible: enum: + - qcom,sdx75-mpss-pas - qcom,sm8550-mpss-pas - qcom,sm8650-mpss-pas then: diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml new file mode 100644 index 000000000000..2bd0752b6ba9 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml @@ -0,0 +1,125 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI K3 M4F processor subsystems + +maintainers: + - Hari Nagalla <hnagalla@ti.com> + - Mathieu Poirier <mathieu.poirier@linaro.org> + +description: | + Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3 + family with a M4F core. Typically safety oriented applications may use + the M4F core in isolation without an IPC. Where as some industrial and + home automation applications, may use the M4F core as a remote processor + with IPC communications. + +$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# + +properties: + compatible: + enum: + - ti,am64-m4fss + + power-domains: + maxItems: 1 + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + + reg: + items: + - description: IRAM internal memory region + - description: DRAM internal memory region + + reg-names: + items: + - const: iram + - const: dram + + resets: + maxItems: 1 + + firmware-name: + maxItems: 1 + description: Name of firmware to load for the M4F core + + mboxes: + description: + OMAP Mailbox specifier denoting the sub-mailbox, to be used for + communication with the remote processor. This property should match + with the sub-mailbox node used in the firmware image. + maxItems: 1 + + memory-region: + description: + phandle to the reserved memory nodes to be associated with the + remoteproc device. Optional memory regions available for firmware + specific purposes. + (see reserved-memory/reserved-memory.yaml in dtschema project) + maxItems: 8 + items: + - description: regions used for DMA allocations like vrings, vring buffers + and memory dedicated to firmware's specific purposes. + additionalItems: true + +required: + - compatible + - reg + - reg-names + - ti,sci + - ti,sci-dev-id + - ti,sci-proc-ids + - resets + - firmware-name + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 { + compatible = "shared-dma-pool"; + reg = <0x00 0x9cb00000 0x00 0x100000>; + no-map; + }; + + mcu_m4fss_memory_region: m4f-memory@9cc00000 { + compatible = "shared-dma-pool"; + reg = <0x00 0x9cc00000 0x00 0xe00000>; + no-map; + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + mailbox0_cluster0: mailbox-0 { + #mbox-cells = <1>; + }; + + remoteproc@5000000 { + compatible = "ti,am64-m4fss"; + reg = <0x00 0x5000000 0x00 0x30000>, + <0x00 0x5040000 0x00 0x10000>; + reg-names = "iram", "dram"; + resets = <&k3_reset 9 1>; + firmware-name = "am62-mcu-m4f0_0-fw"; + mboxes = <&mailbox0_cluster0>, <&mbox_m4_0>; + memory-region = <&mcu_m4fss_dma_memory_region>, + <&mcu_m4fss_memory_region>; + ti,sci = <&dmsc>; + ti,sci-dev-id = <9>; + ti,sci-proc-ids = <0x18 0xff>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml index 6f13da11f593..ee63c03949c9 100644 --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml @@ -62,6 +62,7 @@ properties: patternProperties: "^r(.*)@[0-9a-f]+$": type: object + additionalProperties: false description: | The RPU is located in the Low Power Domain of the Processor Subsystem. Each processor includes separate L1 instruction and data caches and diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml index 5ade5dfad048..cda8ad7c1203 100644 --- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml +++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml @@ -22,6 +22,9 @@ properties: interrupts: maxItems: 1 + "#clock-cells": + const: 0 + trickle-resistor-ohms: enum: - 3000 diff --git a/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml new file mode 100644 index 000000000000..f3d20e976965 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/sprd,sc2731-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Spreadtrum SC2731 Real Time Clock + +maintainers: + - Orson Zhai <orsonzhai@gmail.com> + - Baolin Wang <baolin.wang7@gmail.com> + - Chunyan Zhang <zhang.lyra@gmail.com> + +properties: + compatible: + const: sprd,sc2731-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: rtc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + pmic { + #address-cells = <1>; + #size-cells = <0>; + + rtc@280 { + compatible = "sprd,sc2731-rtc"; + reg = <0x280>; + interrupt-parent = <&sc2731_pmic>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt b/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt deleted file mode 100644 index 1f5754299d31..000000000000 --- a/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt +++ /dev/null @@ -1,26 +0,0 @@ -Spreadtrum SC27xx Real Time Clock - -Required properties: -- compatible: should be "sprd,sc2731-rtc". -- reg: address offset of rtc register. -- interrupts: rtc alarm interrupt. - -Example: - - sc2731_pmic: pmic@0 { - compatible = "sprd,sc2731"; - reg = <0>; - spi-max-frequency = <26000000>; - interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; - interrupt-controller; - #interrupt-cells = <2>; - #address-cells = <1>; - #size-cells = <0>; - - rtc@280 { - compatible = "sprd,sc2731-rtc"; - reg = <0x280>; - interrupt-parent = <&sc2731_pmic>; - interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml index 7a0fab721cf1..aae06e570c22 100644 --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml @@ -53,6 +53,28 @@ properties: override default rtc_ck parent clock phandle of the new parent clock of rtc_ck maxItems: 1 +patternProperties: + "^rtc-[a-z]+-[0-9]+$": + type: object + $ref: /schemas/pinctrl/pinmux-node.yaml + description: | + Configuration of STM32 RTC pins description. STM32 RTC is able to output + some signals on specific pins: + - LSCO (Low Speed Clock Output) that allow to output LSE clock on a pin. + - Alarm out that allow to send a pulse on a pin when alarm A of the RTC + expires. + additionalProperties: false + properties: + function: + enum: + - lsco + - alarm-a + pins: + enum: + - out1 + - out2 + - out2_rmp + allOf: - if: properties: @@ -68,6 +90,9 @@ allOf: clock-names: false + patternProperties: + "^rtc-[a-z]+-[0-9]+$": false + required: - st,syscfg @@ -83,6 +108,9 @@ allOf: minItems: 2 maxItems: 2 + patternProperties: + "^rtc-[a-z]+-[0-9]+$": false + required: - clock-names - st,syscfg diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index fffd759c603f..7330a7200831 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -38,12 +38,13 @@ properties: - dallas,ds1672 # Extremely Accurate I²C RTC with Integrated Crystal and SRAM - dallas,ds3232 + # SD2405AL Real-Time Clock + - dfrobot,sd2405al # EM Microelectronic EM3027 RTC - emmicro,em3027 # I2C-BUS INTERFACE REAL TIME CLOCK MODULE - epson,rx8010 # I2C-BUS INTERFACE REAL TIME CLOCK MODULE - - epson,rx8025 - epson,rx8035 # I2C-BUS INTERFACE REAL TIME CLOCK MODULE with Battery Backed RAM - epson,rx8111 @@ -52,10 +53,6 @@ properties: - epson,rx8581 # Android Goldfish Real-time Clock - google,goldfish-rtc - # Intersil ISL1208 Low Power RTC with Battery Backed SRAM - - isil,isl1208 - # Intersil ISL1218 Low Power RTC with Battery Backed SRAM - - isil,isl1218 # Mvebu Real-time Clock - marvell,orion-rtc # Maxim DS1742/DS1743 Real-time Clock @@ -68,8 +65,6 @@ properties: - microcrystal,rv8523 # NXP LPC32xx SoC Real-time Clock - nxp,lpc3220-rtc - # Real-time Clock Module - - pericom,pt7c4338 # I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC - ricoh,r2025sd # I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml index 6a7be42da523..4b78de6b46a2 100644 --- a/Documentation/devicetree/bindings/serial/8250_omap.yaml +++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml @@ -76,6 +76,7 @@ properties: clock-frequency: true current-speed: true overrun-throttle-ms: true + wakeup-source: true required: - compatible diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml index eb2992a447d7..f466c38518c4 100644 --- a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml +++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml @@ -23,13 +23,20 @@ properties: - const: atmel,at91sam9260-dbgu - const: atmel,at91sam9260-usart - items: - - const: microchip,sam9x60-usart + - enum: + - microchip,sam9x60-usart + - microchip,sam9x7-usart - const: atmel,at91sam9260-usart - items: - const: microchip,sam9x60-dbgu - const: microchip,sam9x60-usart - const: atmel,at91sam9260-dbgu - const: atmel,at91sam9260-usart + - items: + - const: microchip,sam9x7-dbgu + - const: atmel,at91sam9260-dbgu + - const: microchip,sam9x7-usart + - const: atmel,at91sam9260-usart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml index ff61ffdcad1d..1b02f0b197ff 100644 --- a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml +++ b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml @@ -36,6 +36,7 @@ properties: - mediatek,mt7622-uart - mediatek,mt7623-uart - mediatek,mt7629-uart + - mediatek,mt7981-uart - mediatek,mt7986-uart - mediatek,mt7988-uart - mediatek,mt8127-uart diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index afc7c05898a1..51d9fb0f4763 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -46,6 +46,7 @@ properties: - items: - enum: - renesas,scif-r8a774a1 # RZ/G2M + - renesas,scif-r8a774a3 # RZ/G2M v3.0 - renesas,scif-r8a774b1 # RZ/G2N - renesas,scif-r8a774c0 # RZ/G2E - renesas,scif-r8a774e1 # RZ/G2H diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 0f0131026911..788c80e47831 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -56,14 +56,8 @@ properties: maxItems: 5 clock-names: - description: N = 0 is allowed for SoCs without internal baud clock mux. minItems: 2 - items: - - const: uart - - pattern: '^clk_uart_baud[0-3]$' - - pattern: '^clk_uart_baud[0-3]$' - - pattern: '^clk_uart_baud[0-3]$' - - pattern: '^clk_uart_baud[0-3]$' + maxItems: 5 dmas: items: @@ -103,18 +97,45 @@ allOf: compatible: contains: enum: - - samsung,s5pv210-uart + - samsung,s3c6400-uart then: properties: clocks: - minItems: 2 + minItems: 3 maxItems: 3 + + clock-names: + items: + - const: uart + - const: clk_uart_baud2 + - const: clk_uart_baud3 + + else: + properties: clock-names: minItems: 2 items: - const: uart - - pattern: '^clk_uart_baud[0-1]$' - - pattern: '^clk_uart_baud[0-1]$' + - const: clk_uart_baud0 + - const: clk_uart_baud1 + - const: clk_uart_baud2 + - const: clk_uart_baud3 + + - if: + properties: + compatible: + contains: + enum: + - samsung,s5pv210-uart + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + minItems: 3 + maxItems: 3 - if: properties: @@ -129,10 +150,9 @@ allOf: properties: clocks: maxItems: 2 + clock-names: - items: - - const: uart - - const: clk_uart_baud0 + maxItems: 2 - if: properties: @@ -146,6 +166,12 @@ allOf: properties: reg-io-width: false + clocks: + maxItems: 2 + + clock-names: + maxItems: 2 + unevaluatedProperties: false examples: @@ -163,3 +189,19 @@ examples: <&clocks SCLK_UART>; samsung,uart-fifosize = <16>; }; + - | + #include <dt-bindings/clock/google,gs101.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + serial_0: serial@10a00000 { + compatible = "google,gs101-uart"; + reg = <0x10a00000 0xc0>; + clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0>, + <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>; + clock-names = "uart", "clk_uart_baud0"; + interrupts = <GIC_SPI 634 IRQ_TYPE_LEVEL_HIGH 0>; + pinctrl-0 = <&uart0_bus>; + pinctrl-names = "default"; + samsung,uart-fifosize = <256>; + }; diff --git a/Documentation/devicetree/bindings/soc/cirrus/cirrus,ep9301-syscon.yaml b/Documentation/devicetree/bindings/soc/cirrus/cirrus,ep9301-syscon.yaml new file mode 100644 index 000000000000..7cb1b4114985 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/cirrus/cirrus,ep9301-syscon.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/cirrus/cirrus,ep9301-syscon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic EP93xx Platforms System Controller + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + - Nikita Shubin <nikita.shubin@maquefel.me> + +description: | + Central resources are controlled by a set of software-locked registers, + which can be used to prevent accidental accesses. Syscon generates + the various bus and peripheral clocks and controls the system startup + configuration. + + The System Controller (Syscon) provides: + - Clock control + - Power management + - System configuration management + + Syscon registers are common for all EP93xx SoC's, through some actual peripheral + may be missing depending on actual SoC model. + +properties: + compatible: + oneOf: + - items: + - enum: + - cirrus,ep9302-syscon + - cirrus,ep9307-syscon + - cirrus,ep9312-syscon + - cirrus,ep9315-syscon + - const: cirrus,ep9301-syscon + - const: syscon + - items: + - const: cirrus,ep9301-syscon + - const: syscon + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + clocks: + items: + - description: reference clock + +patternProperties: + '^pins-': + type: object + description: pin node + $ref: /schemas/pinctrl/pinmux-node.yaml + + properties: + function: + enum: [ spi, ac97, i2s, pwm, keypad, pata, lcd, gpio ] + + groups: + enum: [ ssp, ac97, i2s_on_ssp, i2s_on_ac97, pwm1, gpio1agrp, + gpio2agrp, gpio3agrp, gpio4agrp, gpio6agrp, gpio7agrp, + rasteronsdram0grp, rasteronsdram3grp, keypadgrp, idegrp ] + + required: + - function + - groups + + unevaluatedProperties: false + +required: + - compatible + - reg + - "#clock-cells" + - clocks + +additionalProperties: false + +examples: + - | + syscon@80930000 { + compatible = "cirrus,ep9301-syscon", "syscon"; + reg = <0x80930000 0x1000>; + + #clock-cells = <1>; + clocks = <&xtali>; + + spi_default_pins: pins-spi { + function = "spi"; + groups = "ssp"; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml index 453d493c941f..4693e85aed37 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml @@ -40,6 +40,20 @@ properties: - const: sclk - const: lrclk + dmas: + items: + - description: out DMA channel + - description: in DMA channel + + dma-names: + items: + - const: tx + - const: rx + + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - '#sound-dai-cells' @@ -61,6 +75,8 @@ examples: <&syscon 30>, <&syscon 31>; clock-names = "mclk", "sclk", "lrclk"; + dmas = <&dma0 0 1>, <&dma0 0 2>; + dma-names = "tx", "rx"; }; ... diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml index 7735e08d35ba..ab3206ffa4af 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml @@ -102,7 +102,7 @@ properties: default: 2 interrupts: - anyOf: + oneOf: - minItems: 1 items: - description: TX interrupt diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 1d3acdc0c733..2e2e01493a5f 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -30,6 +30,7 @@ properties: - qcom,apq8096-sndcard - qcom,qcm6490-idp-sndcard - qcom,qcs6490-rb3gen2-sndcard + - qcom,qrb4210-rb2-sndcard - qcom,qrb5165-rb5-sndcard - qcom,sc7180-qdsp6-sndcard - qcom,sc8280xp-sndcard diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 3bc93c59535e..6d0d1514cd42 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -302,7 +302,7 @@ allOf: reg-names: items: enum: - - scu + - sru - ssi - adg # for Gen2/Gen3 diff --git a/Documentation/devicetree/bindings/spi/cirrus,ep9301-spi.yaml b/Documentation/devicetree/bindings/spi/cirrus,ep9301-spi.yaml new file mode 100644 index 000000000000..73980a27dc00 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/cirrus,ep9301-spi.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/cirrus,ep9301-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EP93xx SoC SPI controller + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + - Nikita Shubin <nikita.shubin@maquefel.me> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + oneOf: + - const: cirrus,ep9301-spi + - items: + - enum: + - cirrus,ep9302-spi + - cirrus,ep9307-spi + - cirrus,ep9312-spi + - cirrus,ep9315-spi + - const: cirrus,ep9301-spi + + reg: + items: + - description: SPI registers region + + interrupts: + maxItems: 1 + + clocks: + items: + - description: SPI Controller reference clock source + + dmas: + items: + - description: rx DMA channel + - description: tx DMA channel + + dma-names: + items: + - const: rx + - const: tx + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/clock/cirrus,ep9301-syscon.h> + spi@808a0000 { + compatible = "cirrus,ep9301-spi"; + reg = <0x808a0000 0x18>; + interrupt-parent = <&vic1>; + interrupts = <21>; + clocks = <&syscon EP93XX_CLK_SPI>; + dmas = <&dma1 10 2>, <&dma1 10 1>; + dma-names = "rx", "tx"; + cs-gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 0108d7507215..9bf0fb17a05e 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -101,8 +101,6 @@ properties: - domintech,dmard09 # DMARD10: 3-axis Accelerometer - domintech,dmard10 - # Elgin SPI-controlled LCD - - elgin,jg10309-01 # MMA7660FC: 3-Axis Orientation/Motion Detection Sensor - fsl,mma7660 # MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer diff --git a/Documentation/devicetree/bindings/usb/fsl,ls1028a.yaml b/Documentation/devicetree/bindings/usb/fsl,ls1028a.yaml new file mode 100644 index 000000000000..a44bdf391887 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/fsl,ls1028a.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/fsl,ls1028a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale layerscape SuperSpeed DWC3 USB SoC controller + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +select: + properties: + compatible: + contains: + enum: + - fsl,ls1028a-dwc3 + required: + - compatible + +properties: + compatible: + items: + - enum: + - fsl,ls1028a-dwc3 + - const: snps,dwc3 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: snps,dwc3.yaml# + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb@fe800000 { + compatible = "fsl,ls1028a-dwc3", "snps,dwc3"; + reg = <0xfe800000 0x100000>; + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt deleted file mode 100644 index afc30e98b123..000000000000 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ /dev/null @@ -1,110 +0,0 @@ -MSM SoC HSUSB controllers - -EHCI - -Required properties: -- compatible: Should contain "qcom,ehci-host" -- regs: offset and length of the register set in the memory map -- usb-phy: phandle for the PHY device - -Example EHCI controller device node: - - ehci: ehci@f9a55000 { - compatible = "qcom,ehci-host"; - reg = <0xf9a55000 0x400>; - usb-phy = <&usb_otg>; - }; - -USB PHY with optional OTG: - -Required properties: -- compatible: Should contain: - "qcom,usb-otg-ci" for chipsets with ChipIdea 45nm PHY - "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY - -- regs: Offset and length of the register set in the memory map -- interrupts: interrupt-specifier for the OTG interrupt. - -- clocks: A list of phandle + clock-specifier pairs for the - clocks listed in clock-names -- clock-names: Should contain the following: - "phy" USB PHY reference clock - "core" Protocol engine clock - "iface" Interface bus clock - "alt_core" Protocol engine clock for targets with asynchronous - reset methodology. (optional) - -- vdccx-supply: phandle to the regulator for the vdd supply for - digital circuit operation. -- v1p8-supply: phandle to the regulator for the 1.8V supply -- v3p3-supply: phandle to the regulator for the 3.3V supply - -- resets: A list of phandle + reset-specifier pairs for the - resets listed in reset-names -- reset-names: Should contain the following: - "phy" USB PHY controller reset - "link" USB LINK controller reset - -- qcom,otg-control: OTG control (VBUS and ID notifications) can be one of - 1 - PHY control - 2 - PMIC control - -Optional properties: -- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" - -- switch-gpio: A phandle + gpio-specifier pair. Some boards are using Dual - SPDT USB Switch, witch is controlled by GPIO to de/multiplex - D+/D- USB lines between connectors. - -- qcom,phy-init-sequence: PHY configuration sequence values. This is related to Device - Mode Eye Diagram test. Start address at which these values will be - written is ULPI_EXT_VENDOR_SPECIFIC. Value of -1 is reserved as - "do not overwrite default value at this address". - For example: qcom,phy-init-sequence = < -1 0x63 >; - Will update only value at address ULPI_EXT_VENDOR_SPECIFIC + 1. - -- qcom,phy-num: Select number of pyco-phy to use, can be one of - 0 - PHY one, default - 1 - Second PHY - Some platforms may have configuration to allow USB - controller work with any of the two HSPHYs present. - -- qcom,vdd-levels: This property must be a list of three integer values - (no, min, max) where each value represents either a voltage - in microvolts or a value corresponding to voltage corner. - -- qcom,manual-pullup: If present, vbus is not routed to USB controller/phy - and controller driver therefore enables pull-up explicitly - before starting controller using usbcmd run/stop bit. - -- extcon: phandles to external connector devices. First phandle - should point to external connector, which provide "USB" - cable events, the second should point to external connector - device, which provide "USB-HOST" cable events. If one of - the external connector devices is not required empty <0> - phandle should be specified. - -Example HSUSB OTG controller device node: - - usb@f9a55000 { - compatible = "qcom,usb-otg-snps"; - reg = <0xf9a55000 0x400>; - interrupts = <0 134 0>; - dr_mode = "peripheral"; - - clocks = <&gcc GCC_XO_CLK>, <&gcc GCC_USB_HS_SYSTEM_CLK>, - <&gcc GCC_USB_HS_AHB_CLK>; - - clock-names = "phy", "core", "iface"; - - vddcx-supply = <&pm8841_s2_corner>; - v1p8-supply = <&pm8941_l6>; - v3p3-supply = <&pm8941_l24>; - - resets = <&gcc GCC_USB2A_PHY_BCR>, <&gcc GCC_USB_HS_BCR>; - reset-names = "phy", "link"; - - qcom,otg-control = <1>; - qcom,phy-init-sequence = < -1 0x63 >; - qcom,vdd-levels = <1 5 7>; - }; diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index aef42dacc202..18758efb8d29 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -52,6 +52,7 @@ properties: - qcom,sm8550-dwc3 - qcom,sm8650-dwc3 - qcom,x1e80100-dwc3 + - qcom,x1e80100-dwc3-mp - const: qcom,dwc3 reg: @@ -289,6 +290,7 @@ allOf: - qcom,sc8280xp-dwc3 - qcom,sc8280xp-dwc3-mp - qcom,x1e80100-dwc3 + - qcom,x1e80100-dwc3-mp then: properties: clocks: @@ -428,6 +430,21 @@ allOf: contains: enum: - qcom,ipq5332-dwc3 + then: + properties: + interrupts: + maxItems: 3 + interrupt-names: + items: + - const: pwr_event + - const: dp_hs_phy_irq + - const: dm_hs_phy_irq + + - if: + properties: + compatible: + contains: + enum: - qcom,x1e80100-dwc3 then: properties: @@ -486,6 +503,7 @@ allOf: contains: enum: - qcom,sc8180x-dwc3-mp + - qcom,x1e80100-dwc3-mp then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 95ff9791baea..653a89586f4e 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -13,10 +13,9 @@ properties: compatible: oneOf: - const: ti,j721e-usb - - const: ti,am64-usb - items: - - const: ti,j721e-usb - const: ti,am64-usb + - const: ti,j721e-usb reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 56d180f9c1cc..b320a39de7fe 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -368,6 +368,8 @@ patternProperties: description: Devantech, Ltd. "^dfi,.*": description: DFI Inc. + "^dfrobot,.*": + description: DFRobot Corporation "^dh,.*": description: DH electronics GmbH "^difrnce,.*": @@ -1539,6 +1541,8 @@ patternProperties: description: Turing Machines, Inc. "^tyan,.*": description: Tyan Computer Corporation + "^tyhx,.*": + description: NanjingTianyihexin Electronics Ltd. "^u-blox,.*": description: u-blox "^u-boot,.*": diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 94b3492dc301..de2cb8de6112 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -180,6 +180,7 @@ modpost modules-only.symvers modules.builtin modules.builtin.modinfo +modules.builtin.ranges modules.nsdeps modules.order modversions.h* diff --git a/Documentation/driver-api/cxl/access-coordinates.rst b/Documentation/driver-api/cxl/access-coordinates.rst new file mode 100644 index 000000000000..b07950ea30c9 --- /dev/null +++ b/Documentation/driver-api/cxl/access-coordinates.rst @@ -0,0 +1,91 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +================================== +CXL Access Coordinates Computation +================================== + +Shared Upstream Link Calculation +================================ +For certain CXL region construction with endpoints behind CXL switches (SW) or +Root Ports (RP), there is the possibility of the total bandwidth for all +the endpoints behind a switch being more than the switch upstream link. +A similar situation can occur within the host, upstream of the root ports. +The CXL driver performs an additional pass after all the targets have +arrived for a region in order to recalculate the bandwidths with possible +upstream link being a limiting factor in mind. + +The algorithm assumes the configuration is a symmetric topology as that +maximizes performance. When asymmetric topology is detected, the calculation +is aborted. An asymmetric topology is detected during topology walk where the +number of RPs detected as a grandparent is not equal to the number of devices +iterated in the same iteration loop. The assumption is made that subtle +asymmetry in properties does not happen and all paths to EPs are equal. + +There can be multiple switches under an RP. There can be multiple RPs under +a CXL Host Bridge (HB). There can be multiple HBs under a CXL Fixed Memory +Window Structure (CFMWS). + +An example hierarchy: + +> CFMWS 0 +> | +> _________|_________ +> | | +> ACPI0017-0 ACPI0017-1 +> GP0/HB0/ACPI0016-0 GP1/HB1/ACPI0016-1 +> | | | | +> RP0 RP1 RP2 RP3 +> | | | | +> SW 0 SW 1 SW 2 SW 3 +> | | | | | | | | +> EP0 EP1 EP2 EP3 EP4 EP5 EP6 EP7 + +Computation for the example hierarchy: + +Min (GP0 to CPU BW, + Min(SW 0 Upstream Link to RP0 BW, + Min(SW0SSLBIS for SW0DSP0 (EP0), EP0 DSLBIS, EP0 Upstream Link) + + Min(SW0SSLBIS for SW0DSP1 (EP1), EP1 DSLBIS, EP1 Upstream link)) + + Min(SW 1 Upstream Link to RP1 BW, + Min(SW1SSLBIS for SW1DSP0 (EP2), EP2 DSLBIS, EP2 Upstream Link) + + Min(SW1SSLBIS for SW1DSP1 (EP3), EP3 DSLBIS, EP3 Upstream link))) + +Min (GP1 to CPU BW, + Min(SW 2 Upstream Link to RP2 BW, + Min(SW2SSLBIS for SW2DSP0 (EP4), EP4 DSLBIS, EP4 Upstream Link) + + Min(SW2SSLBIS for SW2DSP1 (EP5), EP5 DSLBIS, EP5 Upstream link)) + + Min(SW 3 Upstream Link to RP3 BW, + Min(SW3SSLBIS for SW3DSP0 (EP6), EP6 DSLBIS, EP6 Upstream Link) + + Min(SW3SSLBIS for SW3DSP1 (EP7), EP7 DSLBIS, EP7 Upstream link)))) + +The calculation starts at cxl_region_shared_upstream_perf_update(). A xarray +is created to collect all the endpoint bandwidths via the +cxl_endpoint_gather_bandwidth() function. The min() of bandwidth from the +endpoint CDAT and the upstream link bandwidth is calculated. If the endpoint +has a CXL switch as a parent, then min() of calculated bandwidth and the +bandwidth from the SSLBIS for the switch downstream port that is associated +with the endpoint is calculated. The final bandwidth is stored in a +'struct cxl_perf_ctx' in the xarray indexed by a device pointer. If the +endpoint is direct attached to a root port (RP), the device pointer would be an +RP device. If the endpoint is behind a switch, the device pointer would be the +upstream device of the parent switch. + +At the next stage, the code walks through one or more switches if they exist +in the topology. For endpoints directly attached to RPs, this step is skipped. +If there is another switch upstream, the code takes the min() of the current +gathered bandwidth and the upstream link bandwidth. If there's a switch +upstream, then the SSLBIS of the upstream switch. + +Once the topology walk reaches the RP, whether it's direct attached endpoints +or walking through the switch(es), cxl_rp_gather_bandwidth() is called. At +this point all the bandwidths are aggregated per each host bridge, which is +also the index for the resulting xarray. + +The next step is to take the min() of the per host bridge bandwidth and the +bandwidth from the Generic Port (GP). The bandwidths for the GP is retrieved +via ACPI tables SRAT/HMAT. The min bandwidth are aggregated under the same +ACPI0017 device to form a new xarray. + +Finally, the cxl_region_update_bandwidth() is called and the aggregated +bandwidth from all the members of the last xarray is updated for the +access coordinates residing in the cxl region (cxlr) context. diff --git a/Documentation/driver-api/cxl/index.rst b/Documentation/driver-api/cxl/index.rst index 12b82725d322..965ba90e8fb7 100644 --- a/Documentation/driver-api/cxl/index.rst +++ b/Documentation/driver-api/cxl/index.rst @@ -8,6 +8,7 @@ Compute Express Link :maxdepth: 1 memory-devices + access-coordinates maturity-map diff --git a/Documentation/driver-api/wmi.rst b/Documentation/driver-api/wmi.rst index 6ca58c8249e5..4e8dbdb1fc67 100644 --- a/Documentation/driver-api/wmi.rst +++ b/Documentation/driver-api/wmi.rst @@ -7,12 +7,11 @@ WMI Driver API The WMI driver core supports a more modern bus-based interface for interacting with WMI devices, and an older GUID-based interface. The latter interface is considered to be deprecated, so new WMI drivers should generally avoid it since -it has some issues with multiple WMI devices and events sharing the same GUIDs -and/or notification IDs. The modern bus-based interface instead maps each -WMI device to a :c:type:`struct wmi_device <wmi_device>`, so it supports -WMI devices sharing GUIDs and/or notification IDs. Drivers can then register -a :c:type:`struct wmi_driver <wmi_driver>`, which will be bound to compatible -WMI devices by the driver core. +it has some issues with multiple WMI devices sharing the same GUID. +The modern bus-based interface instead maps each WMI device to a +:c:type:`struct wmi_device <wmi_device>`, so it supports WMI devices sharing the +same GUID. Drivers can then register a :c:type:`struct wmi_driver <wmi_driver>` +which will be bound to compatible WMI devices by the driver core. .. kernel-doc:: include/linux/wmi.h :internal: diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst index d270a0aa8d55..2bbf68b56b0d 100644 --- a/Documentation/filesystems/9p.rst +++ b/Documentation/filesystems/9p.rst @@ -48,11 +48,66 @@ For server running on QEMU host with virtio transport:: mount -t 9p -o trans=virtio <mount_tag> /mnt/9 -where mount_tag is the tag associated by the server to each of the exported +where mount_tag is the tag generated by the server to each of the exported mount points. Each 9P export is seen by the client as a virtio device with an associated "mount_tag" property. Available mount tags can be seen by reading /sys/bus/virtio/drivers/9pnet_virtio/virtio<n>/mount_tag files. +USBG Usage +========== + +To mount a 9p FS on a USB Host accessible via the gadget at runtime:: + + mount -t 9p -o trans=usbg,aname=/path/to/fs <device> /mnt/9 + +To mount a 9p FS on a USB Host accessible via the gadget as root filesystem:: + + root=<device> rootfstype=9p rootflags=trans=usbg,cache=loose,uname=root,access=0,dfltuid=0,dfltgid=0,aname=/path/to/rootfs + +where <device> is the tag associated by the usb gadget transport. +It is defined by the configfs instance name. + +USBG Example +============ + +The USB host exports a filesystem, while the gadget on the USB device +side makes it mountable. + +Diod (9pfs server) and the forwarder are on the development host, where +the root filesystem is actually stored. The gadget is initialized during +boot (or later) on the embedded board. Then the forwarder will find it +on the USB bus and start forwarding requests. + +In this case the 9p requests come from the device and are handled by the +host. The reason is that USB device ports are normally not available on +PCs, so a connection in the other direction would not work. + +When using the usbg transport, for now there is no native usb host +service capable to handle the requests from the gadget driver. For +this we have to use the extra python tool p9_fwd.py from tools/usb. + +Just start the 9pfs capable network server like diod/nfs-ganesha e.g.:: + + $ diod -f -n -d 0 -S -l 0.0.0.0:9999 -e $PWD + +Optionaly scan your bus if there are more then one usbg gadgets to find their path:: + + $ python $kernel_dir/tools/usb/p9_fwd.py list + + Bus | Addr | Manufacturer | Product | ID | Path + --- | ---- | ---------------- | ---------------- | --------- | ---- + 2 | 67 | unknown | unknown | 1d6b:0109 | 2-1.1.2 + 2 | 68 | unknown | unknown | 1d6b:0109 | 2-1.1.3 + +Then start the python transport:: + + $ python $kernel_dir/tools/usb/p9_fwd.py --path 2-1.1.2 connect -p 9999 + +After that the gadget driver can be used as described above. + +One use-case is to use it as an alternative to NFS root booting during +the development of embedded Linux devices. + Options ======= @@ -68,6 +123,7 @@ Options virtio connect to the next virtio channel available (from QEMU with trans_virtio module) rdma connect to a specified RDMA channel + usbg connect to a specified usb gadget channel ======== ============================================ uname=name user name to attempt mount as on the remote server. The diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst index 8e6c721d2330..b93115ab8748 100644 --- a/Documentation/filesystems/iomap/operations.rst +++ b/Documentation/filesystems/iomap/operations.rst @@ -208,7 +208,7 @@ The filesystem must arrange to `cancel such `reservations <https://lore.kernel.org/linux-xfs/20220817093627.GZ3600936@dread.disaster.area/>`_ because writeback will not consume the reservation. -The ``iomap_file_buffered_write_punch_delalloc`` can be called from a +The ``iomap_write_delalloc_release`` can be called from a ``->iomap_end`` function to find all the clean areas of the folios caching a fresh (``IOMAP_F_NEW``) delalloc mapping. It takes the ``invalidate_lock``. diff --git a/Documentation/filesystems/nfs/index.rst b/Documentation/filesystems/nfs/index.rst index 8536134f31fd..95c2c009874c 100644 --- a/Documentation/filesystems/nfs/index.rst +++ b/Documentation/filesystems/nfs/index.rst @@ -8,6 +8,7 @@ NFS client-identifier exporting + localio pnfs rpc-cache rpc-server-gss diff --git a/Documentation/filesystems/nfs/localio.rst b/Documentation/filesystems/nfs/localio.rst new file mode 100644 index 000000000000..bd1967e2eab3 --- /dev/null +++ b/Documentation/filesystems/nfs/localio.rst @@ -0,0 +1,357 @@ +=========== +NFS LOCALIO +=========== + +Overview +======== + +The LOCALIO auxiliary RPC protocol allows the Linux NFS client and +server to reliably handshake to determine if they are on the same +host. Select "NFS client and server support for LOCALIO auxiliary +protocol" in menuconfig to enable CONFIG_NFS_LOCALIO in the kernel +config (both CONFIG_NFS_FS and CONFIG_NFSD must also be enabled). + +Once an NFS client and server handshake as "local", the client will +bypass the network RPC protocol for read, write and commit operations. +Due to this XDR and RPC bypass, these operations will operate faster. + +The LOCALIO auxiliary protocol's implementation, which uses the same +connection as NFS traffic, follows the pattern established by the NFS +ACL protocol extension. + +The LOCALIO auxiliary protocol is needed to allow robust discovery of +clients local to their servers. In a private implementation that +preceded use of this LOCALIO protocol, a fragile sockaddr network +address based match against all local network interfaces was attempted. +But unlike the LOCALIO protocol, the sockaddr-based matching didn't +handle use of iptables or containers. + +The robust handshake between local client and server is just the +beginning, the ultimate use case this locality makes possible is the +client is able to open files and issue reads, writes and commits +directly to the server without having to go over the network. The +requirement is to perform these loopback NFS operations as efficiently +as possible, this is particularly useful for container use cases +(e.g. kubernetes) where it is possible to run an IO job local to the +server. + +The performance advantage realized from LOCALIO's ability to bypass +using XDR and RPC for reads, writes and commits can be extreme, e.g.: + +fio for 20 secs with directio, qd of 8, 16 libaio threads: + - With LOCALIO: + 4K read: IOPS=979k, BW=3825MiB/s (4011MB/s)(74.7GiB/20002msec) + 4K write: IOPS=165k, BW=646MiB/s (678MB/s)(12.6GiB/20002msec) + 128K read: IOPS=402k, BW=49.1GiB/s (52.7GB/s)(982GiB/20002msec) + 128K write: IOPS=11.5k, BW=1433MiB/s (1503MB/s)(28.0GiB/20004msec) + + - Without LOCALIO: + 4K read: IOPS=79.2k, BW=309MiB/s (324MB/s)(6188MiB/20003msec) + 4K write: IOPS=59.8k, BW=234MiB/s (245MB/s)(4671MiB/20002msec) + 128K read: IOPS=33.9k, BW=4234MiB/s (4440MB/s)(82.7GiB/20004msec) + 128K write: IOPS=11.5k, BW=1434MiB/s (1504MB/s)(28.0GiB/20011msec) + +fio for 20 secs with directio, qd of 8, 1 libaio thread: + - With LOCALIO: + 4K read: IOPS=230k, BW=898MiB/s (941MB/s)(17.5GiB/20001msec) + 4K write: IOPS=22.6k, BW=88.3MiB/s (92.6MB/s)(1766MiB/20001msec) + 128K read: IOPS=38.8k, BW=4855MiB/s (5091MB/s)(94.8GiB/20001msec) + 128K write: IOPS=11.4k, BW=1428MiB/s (1497MB/s)(27.9GiB/20001msec) + + - Without LOCALIO: + 4K read: IOPS=77.1k, BW=301MiB/s (316MB/s)(6022MiB/20001msec) + 4K write: IOPS=32.8k, BW=128MiB/s (135MB/s)(2566MiB/20001msec) + 128K read: IOPS=24.4k, BW=3050MiB/s (3198MB/s)(59.6GiB/20001msec) + 128K write: IOPS=11.4k, BW=1430MiB/s (1500MB/s)(27.9GiB/20001msec) + +FAQ +=== + +1. What are the use cases for LOCALIO? + + a. Workloads where the NFS client and server are on the same host + realize improved IO performance. In particular, it is common when + running containerised workloads for jobs to find themselves + running on the same host as the knfsd server being used for + storage. + +2. What are the requirements for LOCALIO? + + a. Bypass use of the network RPC protocol as much as possible. This + includes bypassing XDR and RPC for open, read, write and commit + operations. + b. Allow client and server to autonomously discover if they are + running local to each other without making any assumptions about + the local network topology. + c. Support the use of containers by being compatible with relevant + namespaces (e.g. network, user, mount). + d. Support all versions of NFS. NFSv3 is of particular importance + because it has wide enterprise usage and pNFS flexfiles makes use + of it for the data path. + +3. Why doesn’t LOCALIO just compare IP addresses or hostnames when + deciding if the NFS client and server are co-located on the same + host? + + Since one of the main use cases is containerised workloads, we cannot + assume that IP addresses will be shared between the client and + server. This sets up a requirement for a handshake protocol that + needs to go over the same connection as the NFS traffic in order to + identify that the client and the server really are running on the + same host. The handshake uses a secret that is sent over the wire, + and can be verified by both parties by comparing with a value stored + in shared kernel memory if they are truly co-located. + +4. Does LOCALIO improve pNFS flexfiles? + + Yes, LOCALIO complements pNFS flexfiles by allowing it to take + advantage of NFS client and server locality. Policy that initiates + client IO as closely to the server where the data is stored naturally + benefits from the data path optimization LOCALIO provides. + +5. Why not develop a new pNFS layout to enable LOCALIO? + + A new pNFS layout could be developed, but doing so would put the + onus on the server to somehow discover that the client is co-located + when deciding to hand out the layout. + There is value in a simpler approach (as provided by LOCALIO) that + allows the NFS client to negotiate and leverage locality without + requiring more elaborate modeling and discovery of such locality in a + more centralized manner. + +6. Why is having the client perform a server-side file OPEN, without + using RPC, beneficial? Is the benefit pNFS specific? + + Avoiding the use of XDR and RPC for file opens is beneficial to + performance regardless of whether pNFS is used. Especially when + dealing with small files its best to avoid going over the wire + whenever possible, otherwise it could reduce or even negate the + benefits of avoiding the wire for doing the small file I/O itself. + Given LOCALIO's requirements the current approach of having the + client perform a server-side file open, without using RPC, is ideal. + If in the future requirements change then we can adapt accordingly. + +7. Why is LOCALIO only supported with UNIX Authentication (AUTH_UNIX)? + + Strong authentication is usually tied to the connection itself. It + works by establishing a context that is cached by the server, and + that acts as the key for discovering the authorisation token, which + can then be passed to rpc.mountd to complete the authentication + process. On the other hand, in the case of AUTH_UNIX, the credential + that was passed over the wire is used directly as the key in the + upcall to rpc.mountd. This simplifies the authentication process, and + so makes AUTH_UNIX easier to support. + +8. How do export options that translate RPC user IDs behave for LOCALIO + operations (eg. root_squash, all_squash)? + + Export options that translate user IDs are managed by nfsd_setuser() + which is called by nfsd_setuser_and_check_port() which is called by + __fh_verify(). So they get handled exactly the same way for LOCALIO + as they do for non-LOCALIO. + +9. How does LOCALIO make certain that object lifetimes are managed + properly given NFSD and NFS operate in different contexts? + + See the detailed "NFS Client and Server Interlock" section below. + +RPC +=== + +The LOCALIO auxiliary RPC protocol consists of a single "UUID_IS_LOCAL" +RPC method that allows the Linux NFS client to verify the local Linux +NFS server can see the nonce (single-use UUID) the client generated and +made available in nfs_common. This protocol isn't part of an IETF +standard, nor does it need to be considering it is Linux-to-Linux +auxiliary RPC protocol that amounts to an implementation detail. + +The UUID_IS_LOCAL method encodes the client generated uuid_t in terms of +the fixed UUID_SIZE (16 bytes). The fixed size opaque encode and decode +XDR methods are used instead of the less efficient variable sized +methods. + +The RPC program number for the NFS_LOCALIO_PROGRAM is 400122 (as assigned +by IANA, see https://www.iana.org/assignments/rpc-program-numbers/ ): +Linux Kernel Organization 400122 nfslocalio + +The LOCALIO protocol spec in rpcgen syntax is:: + + /* raw RFC 9562 UUID */ + #define UUID_SIZE 16 + typedef u8 uuid_t<UUID_SIZE>; + + program NFS_LOCALIO_PROGRAM { + version LOCALIO_V1 { + void + NULL(void) = 0; + + void + UUID_IS_LOCAL(uuid_t) = 1; + } = 1; + } = 400122; + +LOCALIO uses the same transport connection as NFS traffic. As such, +LOCALIO is not registered with rpcbind. + +NFS Common and Client/Server Handshake +====================================== + +fs/nfs_common/nfslocalio.c provides interfaces that enable an NFS client +to generate a nonce (single-use UUID) and associated short-lived +nfs_uuid_t struct, register it with nfs_common for subsequent lookup and +verification by the NFS server and if matched the NFS server populates +members in the nfs_uuid_t struct. The NFS client then uses nfs_common to +transfer the nfs_uuid_t from its nfs_uuids to the nn->nfsd_serv +clients_list from the nfs_common's uuids_list. See: +fs/nfs/localio.c:nfs_local_probe() + +nfs_common's nfs_uuids list is the basis for LOCALIO enablement, as such +it has members that point to nfsd memory for direct use by the client +(e.g. 'net' is the server's network namespace, through it the client can +access nn->nfsd_serv with proper rcu read access). It is this client +and server synchronization that enables advanced usage and lifetime of +objects to span from the host kernel's nfsd to per-container knfsd +instances that are connected to nfs client's running on the same local +host. + +NFS Client and Server Interlock +=============================== + +LOCALIO provides the nfs_uuid_t object and associated interfaces to +allow proper network namespace (net-ns) and NFSD object refcounting: + + We don't want to keep a long-term counted reference on each NFSD's + net-ns in the client because that prevents a server container from + completely shutting down. + + So we avoid taking a reference at all and rely on the per-cpu + reference to the server (detailed below) being sufficient to keep + the net-ns active. This involves allowing the NFSD's net-ns exit + code to iterate all active clients and clear their ->net pointers + (which are needed to find the per-cpu-refcount for the nfsd_serv). + + Details: + + - Embed nfs_uuid_t in nfs_client. nfs_uuid_t provides a list_head + that can be used to find the client. It does add the 16-byte + uuid_t to nfs_client so it is bigger than needed (given that + uuid_t is only used during the initial NFS client and server + LOCALIO handshake to determine if they are local to each other). + If that is really a problem we can find a fix. + + - When the nfs server confirms that the uuid_t is local, it moves + the nfs_uuid_t onto a per-net-ns list in NFSD's nfsd_net. + + - When each server's net-ns is shutting down - in a "pre_exit" + handler, all these nfs_uuid_t have their ->net cleared. There is + an rcu_synchronize() call between pre_exit() handlers and exit() + handlers so any caller that sees nfs_uuid_t ->net as not NULL can + safely manage the per-cpu-refcount for nfsd_serv. + + - The client's nfs_uuid_t is passed to nfsd_open_local_fh() so it + can safely dereference ->net in a private rcu_read_lock() section + to allow safe access to the associated nfsd_net and nfsd_serv. + +So LOCALIO required the introduction and use of NFSD's percpu_ref to +interlock nfsd_destroy_serv() and nfsd_open_local_fh(), to ensure each +nn->nfsd_serv is not destroyed while in use by nfsd_open_local_fh(), and +warrants a more detailed explanation: + + nfsd_open_local_fh() uses nfsd_serv_try_get() before opening its + nfsd_file handle and then the caller (NFS client) must drop the + reference for the nfsd_file and associated nn->nfsd_serv using + nfs_file_put_local() once it has completed its IO. + + This interlock working relies heavily on nfsd_open_local_fh() being + afforded the ability to safely deal with the possibility that the + NFSD's net-ns (and nfsd_net by association) may have been destroyed + by nfsd_destroy_serv() via nfsd_shutdown_net() -- which is only + possible given the nfs_uuid_t ->net pointer managemenet detailed + above. + +All told, this elaborate interlock of the NFS client and server has been +verified to fix an easy to hit crash that would occur if an NFSD +instance running in a container, with a LOCALIO client mounted, is +shutdown. Upon restart of the container and associated NFSD the client +would go on to crash due to NULL pointer dereference that occurred due +to the LOCALIO client's attempting to nfsd_open_local_fh(), using +nn->nfsd_serv, without having a proper reference on nn->nfsd_serv. + +NFS Client issues IO instead of Server +====================================== + +Because LOCALIO is focused on protocol bypass to achieve improved IO +performance, alternatives to the traditional NFS wire protocol (SUNRPC +with XDR) must be provided to access the backing filesystem. + +See fs/nfs/localio.c:nfs_local_open_fh() and +fs/nfsd/localio.c:nfsd_open_local_fh() for the interface that makes +focused use of select nfs server objects to allow a client local to a +server to open a file pointer without needing to go over the network. + +The client's fs/nfs/localio.c:nfs_local_open_fh() will call into the +server's fs/nfsd/localio.c:nfsd_open_local_fh() and carefully access +both the associated nfsd network namespace and nn->nfsd_serv in terms of +RCU. If nfsd_open_local_fh() finds that the client no longer sees valid +nfsd objects (be it struct net or nn->nfsd_serv) it returns -ENXIO +to nfs_local_open_fh() and the client will try to reestablish the +LOCALIO resources needed by calling nfs_local_probe() again. This +recovery is needed if/when an nfsd instance running in a container were +to reboot while a LOCALIO client is connected to it. + +Once the client has an open nfsd_file pointer it will issue reads, +writes and commits directly to the underlying local filesystem (normally +done by the nfs server). As such, for these operations, the NFS client +is issuing IO to the underlying local filesystem that it is sharing with +the NFS server. See: fs/nfs/localio.c:nfs_local_doio() and +fs/nfs/localio.c:nfs_local_commit(). + +Security +======== + +Localio is only supported when UNIX-style authentication (AUTH_UNIX, aka +AUTH_SYS) is used. + +Care is taken to ensure the same NFS security mechanisms are used +(authentication, etc) regardless of whether LOCALIO or regular NFS +access is used. The auth_domain established as part of the traditional +NFS client access to the NFS server is also used for LOCALIO. + +Relative to containers, LOCALIO gives the client access to the network +namespace the server has. This is required to allow the client to access +the server's per-namespace nfsd_net struct. With traditional NFS, the +client is afforded this same level of access (albeit in terms of the NFS +protocol via SUNRPC). No other namespaces (user, mount, etc) have been +altered or purposely extended from the server to the client. + +Testing +======= + +The LOCALIO auxiliary protocol and associated NFS LOCALIO read, write +and commit access have proven stable against various test scenarios: + +- Client and server both on the same host. + +- All permutations of client and server support enablement for both + local and remote client and server. + +- Testing against NFS storage products that don't support the LOCALIO + protocol was also performed. + +- Client on host, server within a container (for both v3 and v4.2). + The container testing was in terms of podman managed containers and + includes successful container stop/restart scenario. + +- Formalizing these test scenarios in terms of existing test + infrastructure is on-going. Initial regular coverage is provided in + terms of ktest running xfstests against a LOCALIO-enabled NFS loopback + mount configuration, and includes lockdep and KASAN coverage, see: + https://evilpiepirate.org/~testdashboard/ci?user=snitzer&branch=snitm-nfs-next + https://github.com/koverstreet/ktest + +- Various kdevops testing (in terms of "Chuck's BuildBot") has been + performed to regularly verify the LOCALIO changes haven't caused any + regressions to non-LOCALIO NFS use cases. + +- All of Hammerspace's various sanity tests pass with LOCALIO enabled + (this includes numerous pNFS and flexfiles tests). diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 8435e8621cc0..c3e58856f75b 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -181,7 +181,7 @@ Bridge Operations Bridge Connector Helper ----------------------- -.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c +.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c :doc: overview @@ -204,7 +204,7 @@ MIPI-DSI bridge operation Bridge Connector Helper Reference --------------------------------- -.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c +.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c :export: Panel-Bridge Helper Reference diff --git a/Documentation/iio/ad4000.rst b/Documentation/iio/ad4000.rst new file mode 100644 index 000000000000..de8fd3ae6e62 --- /dev/null +++ b/Documentation/iio/ad4000.rst @@ -0,0 +1,131 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= +AD4000 driver +============= + +Device driver for Analog Devices Inc. AD4000 series of ADCs. + +Supported devices +================= + +* `AD4000 <https://www.analog.com/AD4000>`_ +* `AD4001 <https://www.analog.com/AD4001>`_ +* `AD4002 <https://www.analog.com/AD4002>`_ +* `AD4003 <https://www.analog.com/AD4003>`_ +* `AD4004 <https://www.analog.com/AD4004>`_ +* `AD4005 <https://www.analog.com/AD4005>`_ +* `AD4006 <https://www.analog.com/AD4006>`_ +* `AD4007 <https://www.analog.com/AD4007>`_ +* `AD4008 <https://www.analog.com/AD4008>`_ +* `AD4010 <https://www.analog.com/AD4010>`_ +* `AD4011 <https://www.analog.com/AD4011>`_ +* `AD4020 <https://www.analog.com/AD4020>`_ +* `AD4021 <https://www.analog.com/AD4021>`_ +* `AD4022 <https://www.analog.com/AD4022>`_ +* `ADAQ4001 <https://www.analog.com/ADAQ4001>`_ +* `ADAQ4003 <https://www.analog.com/ADAQ4003>`_ + +Wiring connections +------------------ + +Devices of the AD4000 series can be connected to the SPI host controller in a +few different modes. + +CS mode, 3-wire turbo mode +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Datasheet "3-wire" mode is what most resembles standard SPI connection which, +for these devices, comprises of connecting the controller CS line to device CNV +pin and other SPI lines as usual. This configuration is (misleadingly) called +"CS Mode, 3-Wire Turbo Mode" connection in datasheets. +NOTE: The datasheet definition of 3-wire mode for the AD4000 series is NOT the +same of standard spi-3wire mode. +This is the only connection mode that allows configuration register access but +it requires the SPI controller to support the ``SPI_MOSI_IDLE_HIGH`` feature. + +Omit the ``adi,sdi-pin`` property in device tree to select this mode. + +:: + + +-------------+ + + ----------------------------------| SDO | + | | | + | +-------------------| CS | + | v | | + | +--------------------+ | HOST | + | | CNV | | | + +--->| SDI AD4000 SDO |-------->| SDI | + | SCK | | | + +--------------------+ | | + ^ | | + +--------------------| SCLK | + +-------------+ + +CS mode, 3-wire, without busy indicator +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Another wiring configuration supported as "3-wire" mode has the SDI pin +hard-wired to digital input/output interface supply (VIO). In this setup, the +controller is not required to support ``SPI_MOSI_IDLE_HIGH`` but register access +is not possible. This connection mode saves one wire and works with any SPI +controller. + +Set the ``adi,sdi-pin`` device tree property to ``"high"`` to select this mode. + +:: + + +-------------+ + +--------------------| CS | + v | | + VIO +--------------------+ | HOST | + | | CNV | | | + +--->| SDI AD4000 SDO |-------->| SDI | + | SCK | | | + +--------------------+ | | + ^ | | + +--------------------| SCLK | + +-------------+ + +Alternatively, a GPIO may be connected to the device CNV pin. This is similar to +the previous wiring configuration but saves the use of a CS line. + +:: + + +-------------+ + +--------------------| GPIO | + v | | + VIO +--------------------+ | HOST | + | | CNV | | | + +--->| SDI AD4000 SDO |-------->| SDI | + | SCK | | | + +--------------------+ | | + ^ | | + +--------------------| SCLK | + +-------------+ + +CS mode, 4-wire without busy indicator +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In datasheet "4-wire" mode, the controller CS line is connected to the ADC SDI +pin and a GPIO is connected to the ADC CNV pin. This connection mode may better +suit scenarios where multiple ADCs can share one CNV trigger. + +Set ``adi,sdi-pin`` to ``"cs"`` to select this mode. + + +:: + + +-------------+ + + ----------------------------------| CS | + | | | + | +-------------------| GPIO | + | v | | + | +--------------------+ | HOST | + | | CNV | | | + +--->| SDI AD4000 SDO |-------->| SDI | + | SCK | | | + +--------------------+ | | + ^ | | + +--------------------| SCLK | + +-------------+ diff --git a/Documentation/iio/ad4695.rst b/Documentation/iio/ad4695.rst new file mode 100644 index 000000000000..33ed29b7c98a --- /dev/null +++ b/Documentation/iio/ad4695.rst @@ -0,0 +1,167 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= +AD4695 driver +============= + +ADC driver for Analog Devices Inc. AD4695 and similar devices. The module name +is ``ad4695``. + + +Supported devices +================= + +The following chips are supported by this driver: + +* `AD4695 <https://www.analog.com/AD4695>`_ +* `AD4696 <https://www.analog.com/AD4696>`_ +* `AD4697 <https://www.analog.com/AD4697>`_ +* `AD4698 <https://www.analog.com/AD4698>`_ + + +Supported features +================== + +SPI wiring modes +---------------- + +The driver currently supports the following SPI wiring configuration: + +4-wire mode +^^^^^^^^^^^ + +In this mode, CNV and CS are tied together and there is a single SDO line. + +.. code-block:: + + +-------------+ +-------------+ + | CS |<-+------| CS | + | CNV |<-+ | | + | ADC | | HOST | + | | | | + | SDI |<--------| SDO | + | SDO |-------->| SDI | + | SCLK |<--------| SCLK | + +-------------+ +-------------+ + +To use this mode, in the device tree, omit the ``cnv-gpios`` and +``spi-rx-bus-width`` properties. + +Channel configuration +--------------------- + +Since the chip supports multiple ways to configure each channel, this must be +described in the device tree based on what is actually wired up to the inputs. + +There are three typical configurations: + +An ``INx`` pin is used as the positive input with the ``REFGND``, ``COM`` or +the next ``INx`` pin as the negative input. + +Pairing with REFGND +^^^^^^^^^^^^^^^^^^^ + +Each ``INx`` pin can be used as a pseudo-differential input in conjunction with +the ``REFGND`` pin. The device tree will look like this: + +.. code-block:: + + channel@0 { + reg = <0>; /* IN0 */ + }; + +If no other channel properties are needed (e.g. ``adi,no-high-z``), the channel +node can be omitted entirely. + +This will appear on the IIO bus as the ``voltage0`` channel. The processed value +(*raw × scale*) will be the voltage present on the ``IN0`` pin relative to +``REFGND``. (Offset is always 0 when pairing with ``REFGND``.) + +Pairing with COM +^^^^^^^^^^^^^^^^ + +Each ``INx`` pin can be used as a pseudo-differential input in conjunction with +the ``COM`` pin. The device tree will look like this: + +.. code-block:: + + com-supply = <&vref_div_2>; + + channel@1 { + reg = <1>; /* IN1 */ + common-mode-channel = <AD4695_COMMON_MODE_COM>; + bipolar; + }; + +This will appear on the IIO bus as the ``voltage1`` channel. The processed value +(*(raw + offset) × scale*) will be the voltage measured on the ``IN1`` pin +relative to ``REFGND``. (The offset is determined by the ``com-supply`` voltage.) + +The macro comes from: + +.. code-block:: + + #include <dt-bindings/iio/adi,ad4695.h> + +Pairing two INx pins +^^^^^^^^^^^^^^^^^^^^ + +An even-numbered ``INx`` pin and the following odd-numbered ``INx`` pin can be +used as a pseudo-differential input. The device tree for using ``IN2`` as the +positive input and ``IN3`` as the negative input will look like this: + +.. code-block:: + + in3-supply = <&vref_div_2>; + + channel@2 { + reg = <2>; /* IN2 */ + common-mode-channel = <3>; /* IN3 */ + bipolar; + }; + +This will appear on the IIO bus as the ``voltage2`` channel. The processed value +(*(raw + offset) × scale*) will be the voltage measured on the ``IN1`` pin +relative to ``REFGND``. (Offset is determined by the ``in3-supply`` voltage.) + +VCC supply +---------- + +The chip supports being powered by an external LDO via the ``VCC`` input or an +internal LDO via the ``LDO_IN`` input. The driver looks at the device tree to +determine which is being used. If ``ldo-supply`` is present, then the internal +LDO is used. If ``vcc-supply`` is present, then the external LDO is used and +the internal LDO is disabled. + +Reference voltage +----------------- + +The chip supports an external reference voltage via the ``REF`` input or an +internal buffered reference voltage via the ``REFIN`` input. The driver looks +at the device tree to determine which is being used. If ``ref-supply`` is +present, then the external reference voltage is used and the internal buffer is +disabled. If ``refin-supply`` is present, then the internal buffered reference +voltage is used. + +Gain/offset calibration +----------------------- + +System calibration is supported using the channel gain and offset registers via +the ``calibscale`` and ``calibbias`` attributes respectively. + +Unimplemented features +---------------------- + +- Additional wiring modes +- Threshold events +- Oversampling +- GPIO support +- CRC support + +Device buffers +============== + +This driver supports hardware triggered buffers. This uses the "advanced +sequencer" feature of the chip to trigger a burst of conversions. + +Also see :doc:`iio_devbuf` for more general information. diff --git a/Documentation/iio/ad7380.rst b/Documentation/iio/ad7380.rst new file mode 100644 index 000000000000..9c784c1e652e --- /dev/null +++ b/Documentation/iio/ad7380.rst @@ -0,0 +1,130 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= +AD7380 driver +============= + +ADC driver for Analog Devices Inc. AD7380 and similar devices. The module name +is ``ad7380``. + + +Supported devices +================= + +The following chips are supported by this driver: + +* `AD7380 <https://www.analog.com/en/products/ad7380.html>`_ +* `AD7381 <https://www.analog.com/en/products/ad7381.html>`_ +* `AD7383 <https://www.analog.com/en/products/ad7383.html>`_ +* `AD7384 <https://www.analog.com/en/products/ad7384.html>`_ +* `AD7386 <https://www.analog.com/en/products/ad7386.html>`_ +* `AD7387 <https://www.analog.com/en/products/ad7387.html>`_ +* `AD7388 <https://www.analog.com/en/products/ad7388.html>`_ +* `AD7380-4 <https://www.analog.com/en/products/ad7380-4.html>`_ +* `AD7381-4 <https://www.analog.com/en/products/ad7381-4.html>`_ +* `AD7383-4 <https://www.analog.com/en/products/ad7383-4.html>`_ +* `AD7384-4 <https://www.analog.com/en/products/ad7384-4.html>`_ +* `AD7386-4 <https://www.analog.com/en/products/ad7386-4.html>`_ +* `AD7387-4 <https://www.analog.com/en/products/ad7387-4.html>`_ +* `AD7388-4 <https://www.analog.com/en/products/ad7388-4.html>`_ + + +Supported features +================== + +SPI wiring modes +---------------- + +ad738x ADCs can output data on several SDO lines (1/2/4). The driver currently +supports only 1 SDO line. + +Reference voltage +----------------- + +2 possible reference voltage sources are supported: + +- Internal reference (2.5V) +- External reference (2.5V to 3.3V) + +The source is determined by the device tree. If ``refio-supply`` is present, +then the external reference is used, else the internal reference is used. + +Oversampling and resolution boost +--------------------------------- + +This family supports 2 types of oversampling: normal average and rolling +average. Only normal average is supported by the driver, as rolling average can +be achieved by processing a captured data buffer. The following ratios are +available: 1 (oversampling disabled)/2/4/8/16/32. + +When the on-chip oversampling function is enabled the performance of the ADC can +exceed the default resolution. To accommodate the performance boost achievable, +it is possible to enable an additional two bits of resolution. Because the +resolution boost feature can only be enabled when oversampling is enabled and +oversampling is not as useful without the resolution boost, the driver +automatically enables the resolution boost if and only if oversampling is +enabled. + +Since the resolution boost feature causes 16-bit chips to now have 18-bit data +which means the storagebits has to change from 16 to 32 bits, we use the new +ext_scan_type feature to allow changing the scan_type at runtime. Unfortunately +libiio does not support it. So when enabling or disabling oversampling, user +must restart iiod using the following command: + +.. code-block:: bash + + root:~# systemctl restart iiod + +Channel selection and sequencer (single-end chips only) +------------------------------------------------------- + +Single-ended chips of this family (ad7386/7/8(-4)) have a 2:1 multiplexer in +front of each ADC. They also include additional configuration registers that +allow for either manual selection or automatic switching (sequencer mode), of +the multiplexer inputs. + +From an IIO point of view, all inputs are exported, i.e ad7386/7/8 +export 4 channels and ad7386-4/7-4/8-4 export 8 channels. + +Inputs ``AinX0`` of multiplexers correspond to the first half of IIO channels (i.e +0-1 or 0-3) and inputs ``AinX1`` correspond to second half (i.e 2-3 or 4-7). +Example for AD7386/7/8 (2 channels parts): + +.. code-block:: + + IIO | AD7386/7/8 + | +---------------------------- + | | _____ ______ + | | | | | | + voltage0 | AinA0 --|--->| | | | + | | | mux |----->| ADCA |--- + voltage2 | AinA1 --|--->| | | | + | | |_____| |_____ | + | | _____ ______ + | | | | | | + voltage1 | AinB0 --|--->| | | | + | | | mux |----->| ADCB |--- + voltage3 | AinB1 --|--->| | | | + | | |_____| |______| + | | + | +---------------------------- + + +When enabling sequencer mode, the effective sampling rate is divided by two. + +Unimplemented features +---------------------- + +- 2/4 SDO lines +- Rolling average oversampling +- Power down mode +- CRC indication +- Alert + + +Device buffers +============== + +This driver supports IIO triggered buffers. + +See :doc:`iio_devbuf` for more information. diff --git a/Documentation/iio/adxl380.rst b/Documentation/iio/adxl380.rst new file mode 100644 index 000000000000..376dee5fe1dd --- /dev/null +++ b/Documentation/iio/adxl380.rst @@ -0,0 +1,233 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +ADXL380 driver +=============== + +This driver supports Analog Device's ADXL380/382 on SPI/I2C bus. + +1. Supported devices +==================== + +* `ADXL380 <https://www.analog.com/ADXL380>`_ +* `ADXL382 <https://www.analog.com/ADXL382>`_ + +The ADXL380/ADXL382 is a low noise density, low power, 3-axis accelerometer with +selectable measurement ranges. The ADXL380 supports the ±4 g, ±8 g, and ±16 g +ranges, and the ADXL382 supports ±15 g, ±30 g, and ±60 g ranges. + +2. Device attributes +==================== + +Accelerometer measurements are always provided. + +Temperature data are also provided. This data can be used to monitor the +internal system temperature or to improve the temperature stability of the +device via calibration. + +Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``, +where X is the IIO index of the device. Under these folders reside a set of +device files, depending on the characteristics and features of the hardware +device in questions. These files are consistently generalized and documented in +the IIO ABI documentation. + +The following tables show the adxl380 related device files, found in the +specific device folder path ``/sys/bus/iio/devices/iio:deviceX``. + ++---------------------------------------------------+----------------------------------------------------------+ +| 3-Axis Accelerometer related device files | Description | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_scale | Scale for the accelerometer channels. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_filter_high_pass_3db_frequency | Low pass filter bandwidth. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_filter_high_pass_3db_frequency_available | Available low pass filter bandwidth configurations. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_filter_low_pass_3db_frequency | High pass filter bandwidth. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_filter_low_pass_3db_frequency_available | Available high pass filter bandwidth configurations. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_x_raw | Raw X-axis accelerometer channel value. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_y_calibbias | y-axis acceleration offset correction | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_y_raw | Raw Y-axis accelerometer channel value. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. | ++---------------------------------------------------+----------------------------------------------------------+ +| in_accel_z_raw | Raw Z-axis accelerometer channel value. | ++---------------------------------------------------+----------------------------------------------------------+ + ++----------------------------------+--------------------------------------------+ +| Temperature sensor related files | Description | ++----------------------------------+--------------------------------------------+ +| in_temp_raw | Raw temperature channel value. | ++----------------------------------+--------------------------------------------+ +| in_temp_offset | Offset for the temperature sensor channel. | ++----------------------------------+--------------------------------------------+ +| in_temp_scale | Scale for the temperature sensor channel. | ++----------------------------------+--------------------------------------------+ + ++------------------------------+----------------------------------------------+ +| Miscellaneous device files | Description | ++------------------------------+----------------------------------------------+ +| name | Name of the IIO device. | ++------------------------------+----------------------------------------------+ +| sampling_frequency | Currently selected sample rate. | ++------------------------------+----------------------------------------------+ +| sampling_frequency_available | Available sampling frequency configurations. | ++------------------------------+----------------------------------------------+ + +Channels processed values +------------------------- + +A channel value can be read from its _raw attribute. The value returned is the +raw value as reported by the devices. To get the processed value of the channel, +apply the following formula: + +.. code-block:: bash + + processed value = (_raw + _offset) * _scale + +Where _offset and _scale are device attributes. If no _offset attribute is +present, simply assume its value is 0. + +The adis16475 driver offers data for 2 types of channels, the table below shows +the measurement units for the processed value, which are defined by the IIO +framework: + ++-------------------------------------+---------------------------+ +| Channel type | Measurement unit | ++-------------------------------------+---------------------------+ +| Acceleration on X, Y, and Z axis | Meters per Second squared | ++-------------------------------------+---------------------------+ +| Temperature | Millidegrees Celsius | ++-------------------------------------+---------------------------+ + +Usage examples +-------------- + +Show device name: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat name + adxl382 + +Show accelerometer channels value: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw + -1771 + root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw + 282 + root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw + -1523 + root:/sys/bus/iio/devices/iio:device0> cat in_accel_scale + 0.004903325 + +- X-axis acceleration = in_accel_x_raw * in_accel_scale = −8.683788575 m/s^2 +- Y-axis acceleration = in_accel_y_raw * in_accel_scale = 1.38273765 m/s^2 +- Z-axis acceleration = in_accel_z_raw * in_accel_scale = -7.467763975 m/s^2 + +Set calibration offset for accelerometer channels: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias + 0 + + root:/sys/bus/iio/devices/iio:device0> echo 50 > in_accel_x_calibbias + root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias + 50 + +Set sampling frequency: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency + 16000 + root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency_available + 16000 32000 64000 + + root:/sys/bus/iio/devices/iio:device0> echo 32000 > sampling_frequency + root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency + 32000 + +Set low pass filter bandwidth for accelerometer channels: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency + 32000 + root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency_available + 32000 8000 4000 2000 + + root:/sys/bus/iio/devices/iio:device0> echo 2000 > in_accel_filter_low_pass_3db_frequency + root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency + 2000 + +3. Device buffers +================= + +This driver supports IIO buffers. + +All devices support retrieving the raw acceleration and temperature measurements +using buffers. + +Usage examples +-------------- + +Select channels for buffer read: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_x_en + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_y_en + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_z_en + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_temp_en + +Set the number of samples to be stored in the buffer: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length + +Enable buffer readings: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable + +Obtain buffered data: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0 + ... + 002bc300 f7 e7 00 a8 fb c5 24 80 f7 e7 01 04 fb d6 24 80 |......$.......$.| + 002bc310 f7 f9 00 ab fb dc 24 80 f7 c3 00 b8 fb e2 24 80 |......$.......$.| + 002bc320 f7 fb 00 bb fb d1 24 80 f7 b1 00 5f fb d1 24 80 |......$...._..$.| + 002bc330 f7 c4 00 c6 fb a6 24 80 f7 a6 00 68 fb f1 24 80 |......$....h..$.| + 002bc340 f7 b8 00 a3 fb e7 24 80 f7 9a 00 b1 fb af 24 80 |......$.......$.| + 002bc350 f7 b1 00 67 fb ee 24 80 f7 96 00 be fb 92 24 80 |...g..$.......$.| + 002bc360 f7 ab 00 7a fc 1b 24 80 f7 b6 00 ae fb 76 24 80 |...z..$......v$.| + 002bc370 f7 ce 00 a3 fc 02 24 80 f7 c0 00 be fb 8b 24 80 |......$.......$.| + 002bc380 f7 c3 00 93 fb d0 24 80 f7 ce 00 d8 fb c8 24 80 |......$.......$.| + 002bc390 f7 bd 00 c0 fb 82 24 80 f8 00 00 e8 fb db 24 80 |......$.......$.| + 002bc3a0 f7 d8 00 d3 fb b4 24 80 f8 0b 00 e5 fb c3 24 80 |......$.......$.| + 002bc3b0 f7 eb 00 c8 fb 92 24 80 f7 e7 00 ea fb cb 24 80 |......$.......$.| + 002bc3c0 f7 fd 00 cb fb 94 24 80 f7 e3 00 f2 fb b8 24 80 |......$.......$.| + ... + +See ``Documentation/iio/iio_devbuf.rst`` for more information about how buffered +data is structured. + +4. IIO Interfacing Tools +======================== + +See ``Documentation/iio/iio_tools.rst`` for the description of the available IIO +interfacing tools. diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst index 9cb4c50cb20d..dfcf9618568a 100644 --- a/Documentation/iio/index.rst +++ b/Documentation/iio/index.rst @@ -18,8 +18,12 @@ Industrial I/O Kernel Drivers .. toctree:: :maxdepth: 1 + ad4000 + ad4695 + ad7380 ad7944 adis16475 adis16480 + adxl380 bno055 ep93xx_adc diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 9c8d1d046ea5..1796b3eba37b 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -22,6 +22,11 @@ modules.builtin.modinfo This file contains modinfo from all modules that are built into the kernel. Unlike modinfo of a separate module, all fields are prefixed with module name. +modules.builtin.ranges +---------------------- +This file contains address offset ranges (per ELF section) for all modules +that are built into the kernel. Together with System.map, it can be used +to associate module names with symbols. Environment variables ===================== @@ -129,6 +134,11 @@ KBUILD_OUTPUT ------------- Specify the output directory when building the kernel. +This variable can also be used to point to the kernel output directory when +building external modules against a pre-built kernel in a separate build +directory. Please note that this does NOT specify the output directory for the +external modules themselves. + The output directory can also be specified using "O=...". Setting "O=..." takes precedence over KBUILD_OUTPUT. diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 71b38a7670f3..43037be96a16 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -70,7 +70,11 @@ applicable everywhere (see syntax). Every menu entry can have at most one prompt, which is used to display to the user. Optionally dependencies only for this prompt can be added - with "if". + with "if". If a prompt is not present, the config option is a non-visible + symbol, meaning its value cannot be directly changed by the user (such as + altering the value in ``.config``) and the option will not appear in any + config menus. Its value can only be set via "default" and "select" (see + below). - default value: "default" <expr> ["if" <expr>] diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index be43990f1e7f..7964e0c245ae 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -1665,6 +1665,5 @@ Credits TODO ==== -- Describe how kbuild supports shipped files with _shipped. - Generating offset header files. - Add more variables to chapters 7 or 9? diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst index 131863142cbb..cd5a54d91e6d 100644 --- a/Documentation/kbuild/modules.rst +++ b/Documentation/kbuild/modules.rst @@ -4,41 +4,12 @@ Building External Modules This document describes how to build an out-of-tree kernel module. -.. Table of Contents - - === 1 Introduction - === 2 How to Build External Modules - --- 2.1 Command Syntax - --- 2.2 Options - --- 2.3 Targets - --- 2.4 Building Separate Files - === 3. Creating a Kbuild File for an External Module - --- 3.1 Shared Makefile - --- 3.2 Separate Kbuild file and Makefile - --- 3.3 Binary Blobs - --- 3.4 Building Multiple Modules - === 4. Include Files - --- 4.1 Kernel Includes - --- 4.2 Single Subdirectory - --- 4.3 Several Subdirectories - === 5. Module Installation - --- 5.1 INSTALL_MOD_PATH - --- 5.2 INSTALL_MOD_DIR - === 6. Module Versioning - --- 6.1 Symbols From the Kernel (vmlinux + modules) - --- 6.2 Symbols and External Modules - --- 6.3 Symbols From Another External Module - === 7. Tips & Tricks - --- 7.1 Testing for CONFIG_FOO_BAR - - - -1. Introduction -=============== +Introduction +============ "kbuild" is the build system used by the Linux kernel. Modules must use kbuild to stay compatible with changes in the build infrastructure and -to pick up the right flags to "gcc." Functionality for building modules +to pick up the right flags to the compiler. Functionality for building modules both in-tree and out-of-tree is provided. The method for building either is similar, and all modules are initially developed and built out-of-tree. @@ -48,11 +19,11 @@ in building out-of-tree (or "external") modules. The author of an external module should supply a makefile that hides most of the complexity, so one only has to type "make" to build the module. This is easily accomplished, and a complete example will be presented in -section 3. +section `Creating a Kbuild File for an External Module`_. -2. How to Build External Modules -================================ +How to Build External Modules +============================= To build external modules, you must have a prebuilt kernel available that contains the configuration and header files used in the build. @@ -69,12 +40,12 @@ NOTE: "modules_prepare" will not build Module.symvers even if CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be executed to make module versioning work. -2.1 Command Syntax -================== +Command Syntax +-------------- The command to build an external module is:: - $ make -C <path_to_kernel_src> M=$PWD + $ make -C <path_to_kernel_dir> M=$PWD The kbuild system knows that an external module is being built due to the "M=<dir>" option given in the command. @@ -88,15 +59,18 @@ executed to make module versioning work. $ make -C /lib/modules/`uname -r`/build M=$PWD modules_install -2.2 Options -=========== +Options +------- - ($KDIR refers to the path of the kernel source directory.) + ($KDIR refers to the path of the kernel source directory, or the path + of the kernel output directory if the kernel was built in a separate + build directory.) make -C $KDIR M=$PWD -C $KDIR - The directory where the kernel source is located. + The directory that contains the kernel and relevant build + artifacts used for building an external module. "make" will actually change to the specified directory when executing and will change back when finished. @@ -106,8 +80,8 @@ executed to make module versioning work. directory where the external module (kbuild file) is located. -2.3 Targets -=========== +Targets +------- When building an external module, only a subset of the "make" targets are available. @@ -129,7 +103,8 @@ executed to make module versioning work. modules_install Install the external module(s). The default location is /lib/modules/<kernel_release>/updates/, but a prefix may - be added with INSTALL_MOD_PATH (discussed in section 5). + be added with INSTALL_MOD_PATH (discussed in section + `Module Installation`_). clean Remove all generated files in the module directory only. @@ -137,8 +112,8 @@ executed to make module versioning work. help List the available targets for external modules. -2.4 Building Separate Files -=========================== +Building Separate Files +----------------------- It is possible to build single files that are part of a module. This works equally well for the kernel, a module, and even for @@ -152,8 +127,8 @@ executed to make module versioning work. make -C $KDIR M=$PWD ./ -3. Creating a Kbuild File for an External Module -================================================ +Creating a Kbuild File for an External Module +============================================= In the last section we saw the command to build a module for the running kernel. The module is not actually built, however, because a @@ -180,10 +155,9 @@ module 8123.ko, which is built from the following files:: 8123_if.c 8123_if.h 8123_pci.c - 8123_bin.o_shipped <= Binary blob -3.1 Shared Makefile -------------------- +Shared Makefile +--------------- An external module always includes a wrapper makefile that supports building the module using "make" with no arguments. @@ -198,7 +172,7 @@ module 8123.ko, which is built from the following files:: ifneq ($(KERNELRELEASE),) # kbuild part of makefile obj-m := 8123.o - 8123-y := 8123_if.o 8123_pci.o 8123_bin.o + 8123-y := 8123_if.o 8123_pci.o else # normal makefile @@ -207,10 +181,6 @@ module 8123.ko, which is built from the following files:: default: $(MAKE) -C $(KDIR) M=$$PWD - # Module specific targets - genbin: - echo "X" > 8123_bin.o_shipped - endif The check for KERNELRELEASE is used to separate the two parts @@ -221,19 +191,18 @@ module 8123.ko, which is built from the following files:: line; the second pass is by the kbuild system, which is initiated by the parameterized "make" in the default target. -3.2 Separate Kbuild File and Makefile -------------------------------------- +Separate Kbuild File and Makefile +--------------------------------- - In newer versions of the kernel, kbuild will first look for a - file named "Kbuild," and only if that is not found, will it - then look for a makefile. Utilizing a "Kbuild" file allows us - to split up the makefile from example 1 into two files: + Kbuild will first look for a file named "Kbuild", and if it is not + found, it will then look for "Makefile". Utilizing a "Kbuild" file + allows us to split up the "Makefile" from example 1 into two files: Example 2:: --> filename: Kbuild obj-m := 8123.o - 8123-y := 8123_if.o 8123_pci.o 8123_bin.o + 8123-y := 8123_if.o 8123_pci.o --> filename: Makefile KDIR ?= /lib/modules/`uname -r`/build @@ -241,68 +210,13 @@ module 8123.ko, which is built from the following files:: default: $(MAKE) -C $(KDIR) M=$$PWD - # Module specific targets - genbin: - echo "X" > 8123_bin.o_shipped - The split in example 2 is questionable due to the simplicity of each file; however, some external modules use makefiles consisting of several hundred lines, and here it really pays off to separate the kbuild part from the rest. - The next example shows a backward compatible version. - - Example 3:: - - --> filename: Kbuild - obj-m := 8123.o - 8123-y := 8123_if.o 8123_pci.o 8123_bin.o - - --> filename: Makefile - ifneq ($(KERNELRELEASE),) - # kbuild part of makefile - include Kbuild - - else - # normal makefile - KDIR ?= /lib/modules/`uname -r`/build - - default: - $(MAKE) -C $(KDIR) M=$$PWD - - # Module specific targets - genbin: - echo "X" > 8123_bin.o_shipped - - endif - - Here the "Kbuild" file is included from the makefile. This - allows an older version of kbuild, which only knows of - makefiles, to be used when the "make" and kbuild parts are - split into separate files. - -3.3 Binary Blobs ----------------- - - Some external modules need to include an object file as a blob. - kbuild has support for this, but requires the blob file to be - named <filename>_shipped. When the kbuild rules kick in, a copy - of <filename>_shipped is created with _shipped stripped off, - giving us <filename>. This shortened filename can be used in - the assignment to the module. - - Throughout this section, 8123_bin.o_shipped has been used to - build the kernel module 8123.ko; it has been included as - 8123_bin.o:: - - 8123-y := 8123_if.o 8123_pci.o 8123_bin.o - - Although there is no distinction between the ordinary source - files and the binary file, kbuild will pick up different rules - when creating the object file for the module. - -3.4 Building Multiple Modules -============================= +Building Multiple Modules +------------------------- kbuild supports building multiple modules with a single build file. For example, if you wanted to build two modules, foo.ko @@ -315,8 +229,8 @@ module 8123.ko, which is built from the following files:: It is that simple! -4. Include Files -================ +Include Files +============= Within the kernel, header files are kept in standard locations according to the following rule: @@ -334,19 +248,19 @@ according to the following rule: include/scsi; and architecture specific headers are located under arch/$(SRCARCH)/include/. -4.1 Kernel Includes -------------------- +Kernel Includes +--------------- To include a header file located under include/linux/, simply use:: #include <linux/module.h> - kbuild will add options to "gcc" so the relevant directories + kbuild will add options to the compiler so the relevant directories are searched. -4.2 Single Subdirectory ------------------------ +Single Subdirectory +------------------- External modules tend to place header files in a separate include/ directory where their source is located, although this @@ -360,15 +274,11 @@ according to the following rule: --> filename: Kbuild obj-m := 8123.o - ccflags-y := -Iinclude - 8123-y := 8123_if.o 8123_pci.o 8123_bin.o - - Note that in the assignment there is no space between -I and - the path. This is a limitation of kbuild: there must be no - space present. + ccflags-y := -I $(src)/include + 8123-y := 8123_if.o 8123_pci.o -4.3 Several Subdirectories --------------------------- +Several Subdirectories +---------------------- kbuild can handle files that are spread over several directories. Consider the following example:: @@ -407,8 +317,8 @@ according to the following rule: file is located. -5. Module Installation -====================== +Module Installation +=================== Modules which are included in the kernel are installed in the directory: @@ -419,8 +329,8 @@ And external modules are installed in: /lib/modules/$(KERNELRELEASE)/updates/ -5.1 INSTALL_MOD_PATH --------------------- +INSTALL_MOD_PATH +---------------- Above are the default directories but as always some level of customization is possible. A prefix can be added to the @@ -434,8 +344,8 @@ And external modules are installed in: calling "make." This has effect when installing both in-tree and out-of-tree modules. -5.2 INSTALL_MOD_DIR -------------------- +INSTALL_MOD_DIR +--------------- External modules are by default installed to a directory under /lib/modules/$(KERNELRELEASE)/updates/, but you may wish to @@ -448,8 +358,8 @@ And external modules are installed in: => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/ -6. Module Versioning -==================== +Module Versioning +================= Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used as a simple ABI consistency check. A CRC value of the full prototype @@ -461,8 +371,8 @@ module. Module.symvers contains a list of all exported symbols from a kernel build. -6.1 Symbols From the Kernel (vmlinux + modules) ------------------------------------------------ +Symbols From the Kernel (vmlinux + modules) +------------------------------------------- During a kernel build, a file named Module.symvers will be generated. Module.symvers contains all exported symbols from @@ -486,8 +396,8 @@ build. 1) It lists all exported symbols from vmlinux and all modules. 2) It lists the CRC if CONFIG_MODVERSIONS is enabled. -6.2 Symbols and External Modules --------------------------------- +Symbols and External Modules +---------------------------- When building an external module, the build system needs access to the symbols from the kernel to check if all external symbols @@ -496,8 +406,8 @@ build. tree. During the MODPOST step, a new Module.symvers file will be written containing all exported symbols from that external module. -6.3 Symbols From Another External Module ----------------------------------------- +Symbols From Another External Module +------------------------------------ Sometimes, an external module uses exported symbols from another external module. Kbuild needs to have full knowledge of @@ -537,11 +447,11 @@ build. initialization of its symbol tables. -7. Tips & Tricks -================ +Tips & Tricks +============= -7.1 Testing for CONFIG_FOO_BAR ------------------------------- +Testing for CONFIG_FOO_BAR +-------------------------- Modules often need to check for certain `CONFIG_` options to decide if a specific feature is included in the module. In @@ -553,9 +463,3 @@ build. ext2-y := balloc.o bitmap.o dir.o ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o - - External modules have traditionally used "grep" to check for - specific `CONFIG_` settings directly in .config. This usage is - broken. As introduced before, external modules should use - kbuild for building and can therefore use the same methods as - in-tree modules when testing for `CONFIG_` definitions. diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst index 2365c9a3c1f0..ce3e98458339 100644 --- a/Documentation/mm/damon/maintainer-profile.rst +++ b/Documentation/mm/damon/maintainer-profile.rst @@ -7,26 +7,26 @@ The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR' section of 'MAINTAINERS' file. The mailing lists for the subsystem are damon@lists.linux.dev and -linux-mm@kvack.org. Patches should be made against the mm-unstable `tree -<https://git.kernel.org/akpm/mm/h/mm-unstable>` whenever possible and posted to -the mailing lists. +linux-mm@kvack.org. Patches should be made against the `mm-unstable tree +<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ whenever possible and posted +to the mailing lists. SCM Trees --------- There are multiple Linux trees for DAMON development. Patches under development or testing are queued in `damon/next -<https://git.kernel.org/sj/h/damon/next>` by the DAMON maintainer. +<https://git.kernel.org/sj/h/damon/next>`_ by the DAMON maintainer. Sufficiently reviewed patches will be queued in `mm-unstable -<https://git.kernel.org/akpm/mm/h/mm-unstable>` by the memory management +<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ by the memory management subsystem maintainer. After more sufficient tests, the patches will be queued -in `mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>` , and finally +in `mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>`_, and finally pull-requested to the mainline by the memory management subsystem maintainer. -Note again the patches for mm-unstable `tree -<https://git.kernel.org/akpm/mm/h/mm-unstable>` are queued by the memory +Note again the patches for `mm-unstable tree +<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ are queued by the memory management subsystem maintainer. If the patches requires some patches in -damon/next `tree <https://git.kernel.org/sj/h/damon/next>` which not yet merged +`damon/next tree <https://git.kernel.org/sj/h/damon/next>`_ which not yet merged in mm-unstable, please make sure the requirement is clearly specified. Submit checklist addendum @@ -37,25 +37,25 @@ When making DAMON changes, you should do below. - Build changes related outputs including kernel and documents. - Ensure the builds introduce no new errors or warnings. - Run and ensure no new failures for DAMON `selftests - <https://github.com/awslabs/damon-tests/blob/master/corr/run.sh#L49>` and + <https://github.com/damonitor/damon-tests/blob/master/corr/run.sh#L49>`_ and `kunittests - <https://github.com/awslabs/damon-tests/blob/master/corr/tests/kunit.sh>`. + <https://github.com/damonitor/damon-tests/blob/master/corr/tests/kunit.sh>`_. Further doing below and putting the results will be helpful. - Run `damon-tests/corr - <https://github.com/awslabs/damon-tests/tree/master/corr>` for normal + <https://github.com/damonitor/damon-tests/tree/master/corr>`_ for normal changes. - Run `damon-tests/perf - <https://github.com/awslabs/damon-tests/tree/master/perf>` for performance + <https://github.com/damonitor/damon-tests/tree/master/perf>`_ for performance changes. Key cycle dates --------------- Patches can be sent anytime. Key cycle dates of the `mm-unstable -<https://git.kernel.org/akpm/mm/h/mm-unstable>` and `mm-stable -<https://git.kernel.org/akpm/mm/h/mm-stable>` trees depend on the memory +<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ and `mm-stable +<https://git.kernel.org/akpm/mm/h/mm-stable>`_ trees depend on the memory management subsystem maintainer. Review cadence @@ -72,13 +72,13 @@ Mailing tool Like many other Linux kernel subsystems, DAMON uses the mailing lists (damon@lists.linux.dev and linux-mm@kvack.org) as the major communication channel. There is a simple tool called `HacKerMaiL -<https://github.com/damonitor/hackermail>` (``hkml``), which is for people who +<https://github.com/damonitor/hackermail>`_ (``hkml``), which is for people who are not very familiar with the mailing lists based communication. The tool could be particularly helpful for DAMON community members since it is developed and maintained by DAMON maintainer. The tool is also officially announced to support DAMON and general Linux kernel development workflow. -In other words, `hkml <https://github.com/damonitor/hackermail>` is a mailing +In other words, `hkml <https://github.com/damonitor/hackermail>`_ is a mailing tool for DAMON community, which DAMON maintainer is committed to support. Please feel free to try and report issues or feature requests for the tool to the maintainer. @@ -98,8 +98,8 @@ slots, and attendees should reserve one of those at least 24 hours before the time slot, by reaching out to the maintainer. Schedules and available reservation time slots are available at the Google `doc -<https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`. +<https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`_. There is also a public Google `calendar -<https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>` +<https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>`_ that has the events. Anyone can subscribe it. DAMON maintainer will also provide periodic reminder to the mailing list (damon@lists.linux.dev). diff --git a/Documentation/networking/napi.rst b/Documentation/networking/napi.rst index 7bf7b95c4f7a..dfa5d549be9c 100644 --- a/Documentation/networking/napi.rst +++ b/Documentation/networking/napi.rst @@ -144,9 +144,8 @@ IRQ should only be unmasked after a successful call to napi_complete_done(): napi_schedule_irqoff() is a variant of napi_schedule() which takes advantage of guarantees given by being invoked in IRQ context (no need to -mask interrupts). Note that PREEMPT_RT forces all interrupts -to be threaded so the interrupt may need to be marked ``IRQF_NO_THREAD`` -to avoid issues on real-time kernel configurations. +mask interrupts). napi_schedule_irqoff() will fall back to napi_schedule() if +IRQs are threaded (such as if ``PREEMPT_RT`` is enabled). Instance to queue mapping ------------------------- diff --git a/Documentation/networking/tcp_ao.rst b/Documentation/networking/tcp_ao.rst index e96e62d1dab3..d5b6d0df63c3 100644 --- a/Documentation/networking/tcp_ao.rst +++ b/Documentation/networking/tcp_ao.rst @@ -9,7 +9,7 @@ segments between trusted peers. It adds a new TCP header option with a Message Authentication Code (MAC). MACs are produced from the content of a TCP segment using a hashing function with a password known to both peers. The intent of TCP-AO is to deprecate TCP-MD5 providing better security, -key rotation and support for variety of hashing algorithms. +key rotation and support for a variety of hashing algorithms. 1. Introduction =============== @@ -164,9 +164,9 @@ A: It should not, no action needs to be performed [7.5.2.e]:: is not available, no action is required (RNextKeyID of a received segment needs to match the MKT’s SendID). -Q: How current_key is set and when does it change? It is a user-triggered -change, or is it by a request from the remote peer? Is it set by the user -explicitly, or by a matching rule? +Q: How is current_key set, and when does it change? Is it a user-triggered +change, or is it triggered by a request from the remote peer? Is it set by the +user explicitly, or by a matching rule? A: current_key is set by RNextKeyID [6.1]:: @@ -233,8 +233,8 @@ always have one current_key [3.3]:: Q: Can a non-TCP-AO connection become a TCP-AO-enabled one? -A: No: for already established non-TCP-AO connection it would be impossible -to switch using TCP-AO as the traffic key generation requires the initial +A: No: for an already established non-TCP-AO connection it would be impossible +to switch to using TCP-AO, as the traffic key generation requires the initial sequence numbers. Paraphrasing, starting using TCP-AO would require re-establishing the TCP connection. @@ -292,7 +292,7 @@ no transparency is really needed and modern BGP daemons already have Linux provides a set of ``setsockopt()s`` and ``getsockopt()s`` that let userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs -``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used +``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used. It is not allowed to add a key on an established non-TCP-AO connection as well as to remove the last key from TCP-AO connection. @@ -361,7 +361,7 @@ not implemented. 4. ``setsockopt()`` vs ``accept()`` race ======================================== -In contrast with TCP-MD5 established connection which has just one key, +In contrast with an established TCP-MD5 connection which has just one key, TCP-AO connections may have many keys, which means that accepted connections on a listen socket may have any amount of keys as well. As copying all those keys on a first properly signed SYN would make the request socket bigger, that @@ -374,7 +374,7 @@ keys from sockets that were already established, but not yet ``accept()``'ed, hanging in the accept queue. The reverse is valid as well: if userspace adds a new key for a peer on -a listener socket, the established sockets in accept queue won't +a listener socket, the established sockets in the accept queue won't have the new keys. At this moment, the resolution for the two races: @@ -382,7 +382,7 @@ At this moment, the resolution for the two races: and ``setsockopt(TCP_AO_DEL_KEY)`` vs ``accept()`` is delegated to userspace. This means that it's expected that userspace would check the MKTs on the socket that was returned by ``accept()`` to verify that any key rotation that -happened on listen socket is reflected on the newly established connection. +happened on the listen socket is reflected on the newly established connection. This is a similar "do-nothing" approach to TCP-MD5 from the kernel side and may be changed later by introducing new flags to ``tcp_ao_add`` diff --git a/Documentation/networking/tproxy.rst b/Documentation/networking/tproxy.rst index 00dc3a1a66b4..7f7c1ff6f159 100644 --- a/Documentation/networking/tproxy.rst +++ b/Documentation/networking/tproxy.rst @@ -17,7 +17,7 @@ The idea is that you identify packets with destination address matching a local socket on your box, set the packet mark to a certain value:: # iptables -t mangle -N DIVERT - # iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT + # iptables -t mangle -A PREROUTING -p tcp -m socket --transparent -j DIVERT # iptables -t mangle -A DIVERT -j MARK --set-mark 1 # iptables -t mangle -A DIVERT -j ACCEPT diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 3fc63f27c226..00f1ed7c59c3 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -64,6 +64,7 @@ GNU tar 1.28 tar --version gtags (optional) 6.6.5 gtags --version mkimage (optional) 2017.01 mkimage --version Python (optional) 3.5.x python3 --version +GNU AWK (optional) 5.1.0 gawk --version ====================== =============== ======================================== .. [#f1] Sphinx is needed only to build the Kernel documentation @@ -192,6 +193,12 @@ platforms. The tool is available via the ``u-boot-tools`` package or can be built from the U-Boot source code. See the instructions at https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux +GNU AWK +------- + +GNU AWK is needed if you want kernel builds to generate address range data for +builtin modules (CONFIG_BUILTIN_MODULE_RANGES). + System utilities **************** diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index c9edf9e7362d..1ae71e31591c 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -355,6 +355,8 @@ just do it. As a result, a sequence of smaller series gets merged quicker and with better review coverage. Re-posting large series also increases the mailing list traffic. +.. _rcs: + Local variable ordering ("reverse xmas tree", "RCS") ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -391,6 +393,21 @@ APIs and helpers, especially scoped iterators. However, direct use of ``__free()`` within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function. +Clean-up patches +~~~~~~~~~~~~~~~~ + +Netdev discourages patches which perform simple clean-ups, which are not in +the context of other work. For example: + +* Addressing ``checkpatch.pl`` warnings +* Addressing :ref:`Local variable ordering<rcs>` issues +* Conversions to device-managed APIs (``devm_`` helpers) + +This is because it is felt that the churn that such changes produce comes +at a greater cost than the value of such clean-ups. + +Conversely, spelling and grammar fixes are not discouraged. + Resending after review ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst index 12637530d68f..fe9d8bcfbd2b 100644 --- a/Documentation/process/maintainer-soc.rst +++ b/Documentation/process/maintainer-soc.rst @@ -30,10 +30,13 @@ tree as a dedicated branch covering multiple subsystems. The main SoC tree is housed on git.kernel.org: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/ +Maintainers +----------- + Clearly this is quite a wide range of topics, which no one person, or even small group of people are capable of maintaining. Instead, the SoC subsystem -is comprised of many submaintainers, each taking care of individual platforms -and driver subdirectories. +is comprised of many submaintainers (platform maintainers), each taking care of +individual platforms and driver subdirectories. In this regard, "platform" usually refers to a series of SoCs from a given vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers operate on a vendor level, responsible for multiple product lines. For several reasons, @@ -43,14 +46,43 @@ MAINTAINERS file. Most of these submaintainers have their own trees where they stage patches, sending pull requests to the main SoC tree. These trees are usually, but not -always, listed in MAINTAINERS. The main SoC maintainers can be reached via the -alias soc@kernel.org if there is no platform-specific maintainer, or if they -are unresponsive. +always, listed in MAINTAINERS. What the SoC tree is not, however, is a location for architecture-specific code changes. Each architecture has its own maintainers that are responsible for architectural details, CPU errata and the like. +Submitting Patches for Given SoC +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All typical platform related patches should be sent via SoC submaintainers +(platform-specific maintainers). This includes also changes to per-platform or +shared defconfigs (scripts/get_maintainer.pl might not provide correct +addresses in such case). + +Submitting Patches to the Main SoC Maintainers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The main SoC maintainers can be reached via the alias soc@kernel.org only in +following cases: + +1. There are no platform-specific maintainers. + +2. Platform-specific maintainers are unresponsive. + +3. Introducing a completely new SoC platform. Such new SoC work should be sent + first to common mailing lists, pointed out by scripts/get_maintainer.pl, for + community review. After positive community review, work should be sent to + soc@kernel.org in one patchset containing new arch/foo/Kconfig entry, DTS + files, MAINTAINERS file entry and optionally initial drivers with their + Devicetree bindings. The MAINTAINERS file entry should list new + platform-specific maintainers, who are going to be responsible for handling + patches for the platform from now on. + +Note that the soc@kernel.org is usually not the place to discuss the patches, +thus work sent to this address should be already considered as acceptable by +the community. + Information for (new) Submaintainers ------------------------------------ diff --git a/Documentation/rust/general-information.rst b/Documentation/rust/general-information.rst index e3f388ef4ee4..6146b49b6a98 100644 --- a/Documentation/rust/general-information.rst +++ b/Documentation/rust/general-information.rst @@ -15,6 +15,8 @@ but not `std <https://doc.rust-lang.org/std/>`_. Crates for use in the kernel must opt into this behavior using the ``#![no_std]`` attribute. +.. _rust_code_documentation: + Code documentation ------------------ @@ -22,10 +24,17 @@ Rust kernel code is documented using ``rustdoc``, its built-in documentation generator. The generated HTML docs include integrated search, linked items (e.g. types, -functions, constants), source code, etc. They may be read at (TODO: link when -in mainline and generated alongside the rest of the documentation): +functions, constants), source code, etc. They may be read at: + + https://rust.docs.kernel.org + +For linux-next, please see: + + https://rust.docs.kernel.org/next/ - http://kernel.org/ +There are also tags for each main release, e.g.: + + https://rust.docs.kernel.org/6.10/ The docs can also be easily generated and read locally. This is quite fast (same order as compiling the code itself) and no special tools or environment @@ -75,7 +84,7 @@ should provide as-safe-as-possible abstractions as needed. .. code-block:: rust/bindings/ - (rust/helpers.c) + (rust/helpers/) include/ -----+ <-+ | | @@ -112,7 +121,7 @@ output files in the ``rust/bindings/`` directory. For parts of the C header that ``bindgen`` does not auto generate, e.g. C ``inline`` functions or non-trivial macros, it is acceptable to add a small -wrapper function to ``rust/helpers.c`` to make it available for the Rust side as +wrapper function to ``rust/helpers/`` to make it available for the Rust side as well. Abstractions @@ -142,3 +151,11 @@ configuration: #[cfg(CONFIG_X="y")] // Enabled as a built-in (`y`) #[cfg(CONFIG_X="m")] // Enabled as a module (`m`) #[cfg(not(CONFIG_X))] // Disabled + +For other predicates that Rust's ``cfg`` does not support, e.g. expressions with +numerical comparisons, one may define a new Kconfig symbol: + +.. code-block:: kconfig + + config RUSTC_VERSION_MIN_107900 + def_bool y if RUSTC_VERSION >= 107900 diff --git a/Documentation/rust/index.rst b/Documentation/rust/index.rst index 46d35bd395cf..55dcde9e9e7e 100644 --- a/Documentation/rust/index.rst +++ b/Documentation/rust/index.rst @@ -25,13 +25,27 @@ support is still in development/experimental, especially for certain kernel configurations. +Code documentation +------------------ + +Given a kernel configuration, the kernel may generate Rust code documentation, +i.e. HTML rendered by the ``rustdoc`` tool. + .. only:: rustdoc and html - You can also browse `rustdoc documentation <rustdoc/kernel/index.html>`_. + This kernel documentation was built with `Rust code documentation + <rustdoc/kernel/index.html>`_. .. only:: not rustdoc and html - This documentation does not include rustdoc generated information. + This kernel documentation was not built with Rust code documentation. + +A pregenerated version is provided at: + + https://rust.docs.kernel.org + +Please see the :ref:`Code documentation <rust_code_documentation>` section for +more details. .. toctree:: :maxdepth: 1 diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst index 8e3ad9678719..2d107982c87b 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -39,8 +39,8 @@ of the box, e.g.:: Debian ****** -Debian Unstable (Sid), outside of the freeze period, provides recent Rust -releases and thus it should generally work out of the box, e.g.:: +Debian Testing and Debian Unstable (Sid), outside of the freeze period, provide +recent Rust releases and thus they should generally work out of the box, e.g.:: apt install rustc rust-src bindgen rustfmt rust-clippy diff --git a/Documentation/scheduler/sched-ext.rst b/Documentation/scheduler/sched-ext.rst index 6c0d70e2e27d..7b59bbd2e564 100644 --- a/Documentation/scheduler/sched-ext.rst +++ b/Documentation/scheduler/sched-ext.rst @@ -66,7 +66,7 @@ BPF scheduler and reverts all tasks back to CFS. .. code-block:: none # make -j16 -C tools/sched_ext - # tools/sched_ext/scx_simple + # tools/sched_ext/build/bin/scx_simple local=0 global=3 local=5 global=24 local=9 global=44 diff --git a/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst b/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst index f1e9ab18206c..472761938682 100644 --- a/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst +++ b/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst @@ -87,6 +87,38 @@ PCH-LPC/PCH-MSI，然后被EIOINTC统一收集，再直接到达CPUINTC:: | Devices | +---------+ +高级扩展IRQ模型 +=============== + +在这种模型里面，IPI（Inter-Processor Interrupt）和CPU本地时钟中断直接发送到CPUINTC， +CPU串口（UARTs）中断发送到LIOINTC，PCH-MSI中断发送到AVECINTC，而后通过AVECINTC直接 +送达CPUINTC，而其他所有设备的中断则分别发送到所连接的PCH-PIC/PCH-LPC，然后由EIOINTC +统一收集，再直接到达CPUINTC:: + + +-----+ +-----------------------+ +-------+ + | IPI | --> | CPUINTC | <-- | Timer | + +-----+ +-----------------------+ +-------+ + ^ ^ ^ + | | | + +---------+ +----------+ +---------+ +-------+ + | EIOINTC | | AVECINTC | | LIOINTC | <-- | UARTs | + +---------+ +----------+ +---------+ +-------+ + ^ ^ + | | + +---------+ +---------+ + | PCH-PIC | | PCH-MSI | + +---------+ +---------+ + ^ ^ ^ + | | | + +---------+ +---------+ +---------+ + | Devices | | PCH-LPC | | Devices | + +---------+ +---------+ +---------+ + ^ + | + +---------+ + | Devices | + +---------+ + ACPI相关的定义 ============== diff --git a/Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst b/Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst index 29c33e7e0855..fbe0989a8ce5 100644 --- a/Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst +++ b/Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst @@ -175,7 +175,7 @@ field2会导致非对齐访问，这并不是不合理的。你会期望field2 避免非对齐访问 ============== -避免非对齐访问的最简单方法是使用<asm/unaligned.h>头文件提供的get_unaligned()和 +避免非对齐访问的最简单方法是使用<linux/unaligned.h>头文件提供的get_unaligned()和 put_unaligned()宏。 回到前面的一个可能导致非对齐访问的代码例子:: diff --git a/Documentation/usb/functionfs-desc.rst b/Documentation/usb/functionfs-desc.rst new file mode 100644 index 000000000000..39649774da54 --- /dev/null +++ b/Documentation/usb/functionfs-desc.rst @@ -0,0 +1,39 @@ +====================== +FunctionFS Descriptors +====================== + +Some of the descriptors that can be written to the FFS gadget are +described below. Device and configuration descriptors are handled +by the composite gadget and are not written by the user to the +FFS gadget. + +Descriptors are written to the "ep0" file in the FFS gadget +following the descriptor header. + +.. kernel-doc:: include/uapi/linux/usb/functionfs.h + :doc: descriptors + +Interface Descriptors +--------------------- + +Standard USB interface descriptors may be written. The class/subclass of the +most recent interface descriptor determines what type of class-specific +descriptors are accepted. + +Class-Specific Descriptors +-------------------------- + +Class-specific descriptors are accepted only for the class/subclass of the +most recent interface descriptor. The following are some of the +class-specific descriptors that are supported. + +DFU Functional Descriptor +~~~~~~~~~~~~~~~~~~~~~~~~~ + +When the interface class is USB_CLASS_APP_SPEC and the interface subclass +is USB_SUBCLASS_DFU, a DFU functional descriptor can be provided. +The DFU functional descriptor is a described in the USB specification for +Device Firmware Upgrade (DFU), version 1.1 as of this writing. + +.. kernel-doc:: include/uapi/linux/usb/functionfs.h + :doc: usb_dfu_functional_descriptor diff --git a/Documentation/usb/functionfs.rst b/Documentation/usb/functionfs.rst index d05a775bc45b..f7487b0d8057 100644 --- a/Documentation/usb/functionfs.rst +++ b/Documentation/usb/functionfs.rst @@ -25,6 +25,8 @@ interface numbers starting from zero). The FunctionFS changes them as needed also handling situation when numbers differ in different configurations. +For more information about FunctionFS descriptors see :doc:`functionfs-desc` + When descriptors and strings are written "ep#" files appear (one for each declared endpoint) which handle communication on a single endpoint. Again, FunctionFS takes care of the real diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index b086c7ab72f0..bf555c2270f5 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -765,6 +765,17 @@ The uac2 function provides these attributes in its function directory: req_number the number of pre-allocated request for both capture and playback function_name name of the interface + if_ctrl_name topology control name + clksrc_in_name input clock name + clksrc_out_name output clock name + p_it_name playback input terminal name + p_it_ch_name playback input first channel name + p_ot_name playback output terminal name + p_fu_vol_name playback function unit name + c_it_name capture input terminal name + c_it_ch_name capture input first channel name + c_ot_name capture output terminal name + c_fu_vol_name capture functional unit name c_terminal_type code of the capture terminal type p_terminal_type code of the playback terminal type ================ ==================================================== @@ -957,6 +968,14 @@ The uac1 function provides these attributes in its function directory: req_number the number of pre-allocated requests for both capture and playback function_name name of the interface + p_it_name playback input terminal name + p_it_ch_name playback channels name + p_ot_name playback output terminal name + p_fu_vol_name playback mute/volume functional unit name + c_it_name capture input terminal name + c_it_ch_name capture channels name + c_ot_name capture output terminal name + c_fu_vol_name capture mute/volume functional unit name ================ ==================================================== The attributes have sane default values. diff --git a/Documentation/usb/index.rst b/Documentation/usb/index.rst index 27955dad95e1..826492c813ac 100644 --- a/Documentation/usb/index.rst +++ b/Documentation/usb/index.rst @@ -11,6 +11,7 @@ USB support dwc3 ehci functionfs + functionfs-desc gadget_configfs gadget_hid gadget_multi diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index b3be87489108..e32471977d0a 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -4214,7 +4214,9 @@ whether or not KVM_CAP_X86_USER_SPACE_MSR's KVM_MSR_EXIT_REASON_FILTER is enabled. If KVM_MSR_EXIT_REASON_FILTER is enabled, KVM will exit to userspace on denied accesses, i.e. userspace effectively intercepts the MSR access. If KVM_MSR_EXIT_REASON_FILTER is not enabled, KVM will inject a #GP into the guest -on denied accesses. +on denied accesses. Note, if an MSR access is denied during emulation of MSR +load/stores during VMX transitions, KVM ignores KVM_MSR_EXIT_REASON_FILTER. +See the below warning for full details. If an MSR access is allowed by userspace, KVM will emulate and/or virtualize the access in accordance with the vCPU model. Note, KVM may still ultimately @@ -4229,9 +4231,22 @@ filtering. In that mode, ``KVM_MSR_FILTER_DEFAULT_DENY`` is invalid and causes an error. .. warning:: - MSR accesses as part of nested VM-Enter/VM-Exit are not filtered. - This includes both writes to individual VMCS fields and reads/writes - through the MSR lists pointed to by the VMCS. + MSR accesses that are side effects of instruction execution (emulated or + native) are not filtered as hardware does not honor MSR bitmaps outside of + RDMSR and WRMSR, and KVM mimics that behavior when emulating instructions + to avoid pointless divergence from hardware. E.g. RDPID reads MSR_TSC_AUX, + SYSENTER reads the SYSENTER MSRs, etc. + + MSRs that are loaded/stored via dedicated VMCS fields are not filtered as + part of VM-Enter/VM-Exit emulation. + + MSRs that are loaded/store via VMX's load/store lists _are_ filtered as part + of VM-Enter/VM-Exit emulation. If an MSR access is denied on VM-Enter, KVM + synthesizes a consistency check VM-Exit(EXIT_REASON_MSR_LOAD_FAIL). If an + MSR access is denied on VM-Exit, KVM synthesizes a VM-Abort. In short, KVM + extends Intel's architectural list of MSRs that cannot be loaded/saved via + the VM-Enter/VM-Exit MSR list. It is platform owner's responsibility to + to communicate any such restrictions to their end users. x2APIC MSR accesses cannot be filtered (KVM silently ignores filters that cover any x2APIC MSRs). @@ -8082,6 +8097,14 @@ KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS By default, KVM emulates MONITOR/MWAIT (if guest CPUID on writes to MISC_ENABLE if KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT is disabled. + +KVM_X86_QUIRK_SLOT_ZAP_ALL By default, KVM invalidates all SPTEs in + fast way for memslot deletion when VM type + is KVM_X86_DEFAULT_VM. + When this quirk is disabled or when VM type + is other than KVM_X86_DEFAULT_VM, KVM zaps + only leaf SPTEs that are within the range of + the memslot being deleted. =================================== ============================================ 7.32 KVM_CAP_MAX_VCPU_ID diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 02880d5552d5..20a9a37d1cdd 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -11,6 +11,8 @@ The acquisition orders for mutexes are as follows: - cpus_read_lock() is taken outside kvm_lock +- kvm_usage_lock is taken outside cpus_read_lock() + - kvm->lock is taken outside vcpu->mutex - kvm->lock is taken outside kvm->slots_lock and kvm->irq_lock @@ -24,6 +26,13 @@ The acquisition orders for mutexes are as follows: are taken on the waiting side when modifying memslots, so MMU notifiers must not take either kvm->slots_lock or kvm->slots_arch_lock. +cpus_read_lock() vs kvm_lock: + +- Taking cpus_read_lock() outside of kvm_lock is problematic, despite that + being the official ordering, as it is quite easy to unknowingly trigger + cpus_read_lock() while holding kvm_lock. Use caution when walking vm_list, + e.g. avoid complex operations when possible. + For SRCU: - ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections @@ -227,10 +236,16 @@ time it will be set using the Dirty tracking mechanism described above. :Type: mutex :Arch: any :Protects: - vm_list - - kvm_usage_count + +``kvm_usage_lock`` +^^^^^^^^^^^^^^^^^^ + +:Type: mutex +:Arch: any +:Protects: - kvm_usage_count - hardware virtualization enable/disable -:Comment: KVM also disables CPU hotplug via cpus_read_lock() during - enable/disable. +:Comment: Exists to allow taking cpus_read_lock() while kvm_usage_count is + protected, which simplifies the virtualization enabling logic. ``kvm->mn_invalidate_lock`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -290,11 +305,12 @@ time it will be set using the Dirty tracking mechanism described above. wakeup. ``vendor_module_lock`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^ :Type: mutex :Arch: x86 :Protects: loading a vendor module (kvm_amd or kvm_intel) -:Comment: Exists because using kvm_lock leads to deadlock. cpu_hotplug_lock is - taken outside of kvm_lock, e.g. in KVM's CPU online/offline callbacks, and - many operations need to take cpu_hotplug_lock when loading a vendor module, - e.g. updating static calls. +:Comment: Exists because using kvm_lock leads to deadlock. kvm_lock is taken + in notifiers, e.g. __kvmclock_cpufreq_notifier(), that may be invoked while + cpu_hotplug_lock is held, e.g. from cpufreq_boost_trigger_state(), and many + operations need to take cpu_hotplug_lock when loading a vendor module, e.g. + updating static calls. diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index 27942446f406..584000b743f3 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -217,6 +217,8 @@ remote UML and other VM instances. +-----------+--------+------------------------------------+------------+ | fd | vector | dependent on fd type | varies | +-----------+--------+------------------------------------+------------+ +| vde | vector | dep. on VDE VPN: Virt.Net Locator | varies | ++-----------+--------+------------------------------------+------------+ | tuntap | legacy | none | ~ 500Mbit | +-----------+--------+------------------------------------+------------+ | daemon | legacy | none | ~ 450Mbit | @@ -573,6 +575,41 @@ https://github.com/NetSys/bess/wiki/Built-In-Modules-and-Ports BESS transport does not require any special privileges. +VDE vector transport +-------------------- + +Virtual Distributed Ethernet (VDE) is a project whose main goal is to provide a +highly flexible support for virtual networking. + +http://wiki.virtualsquare.org/#/tutorials/vdebasics + +Common usages of VDE include fast prototyping and teaching. + +Examples: + + ``vecX:transport=vde,vnl=tap://tap0`` + +use tap0 + + ``vecX:transport=vde,vnl=slirp://`` + +use slirp + + ``vec0:transport=vde,vnl=vde:///tmp/switch`` + +connect to a vde switch + + ``vecX:transport=\"vde,vnl=cmd://ssh remote.host //tmp/sshlirp\"`` + +connect to a remote slirp (instant VPN: convert ssh to VPN, it uses sshlirp) +https://github.com/virtualsquare/sshlirp + + ``vec0:transport=vde,vnl=vxvde://234.0.0.1`` + +connect to a local area cloud (all the UML nodes using the same +multicast address running on hosts in the same multicast domain (LAN) +will be automagically connected together to a virtual LAN. + Configuring Legacy transports ============================= diff --git a/Documentation/watchdog/convert_drivers_to_kernel_api.rst b/Documentation/watchdog/convert_drivers_to_kernel_api.rst index a1c3f038ce0e..e83609a5d007 100644 --- a/Documentation/watchdog/convert_drivers_to_kernel_api.rst +++ b/Documentation/watchdog/convert_drivers_to_kernel_api.rst @@ -75,7 +75,6 @@ Example conversion:: -static const struct file_operations s3c2410wdt_fops = { - .owner = THIS_MODULE, - - .llseek = no_llseek, - .write = s3c2410wdt_write, - .unlocked_ioctl = s3c2410wdt_ioctl, - .open = s3c2410wdt_open, diff --git a/Documentation/wmi/devices/dell-wmi-ddv.rst b/Documentation/wmi/devices/dell-wmi-ddv.rst index 2fcdfcf03327..e0c20af30948 100644 --- a/Documentation/wmi/devices/dell-wmi-ddv.rst +++ b/Documentation/wmi/devices/dell-wmi-ddv.rst @@ -8,7 +8,7 @@ Introduction ============ Many Dell notebooks made after ~2020 support a WMI-based interface for -retrieving various system data like battery temperature, ePPID, diagostic data +retrieving various system data like battery temperature, ePPID, diagnostic data and fan/thermal sensor data. This interface is likely used by the `Dell Data Vault` software on Windows, @@ -277,7 +277,7 @@ Reverse-Engineering the DDV WMI interface 4. Try to deduce the meaning of a certain WMI method by comparing the control flow with other ACPI methods (_BIX or _BIF for battery related methods for example). -5. Use the built-in UEFI diagostics to view sensor types/values for fan/thermal +5. Use the built-in UEFI diagnostics to view sensor types/values for fan/thermal related methods (sometimes overwriting static ACPI data fields can be used to test different sensor type values, since on some machines this data is not reinitialized upon a warm reset). |