Merge branch 'master' into mm-hotfixes-stable
This commit is contained in:
Andrew Morton
commit
3fbff91afb
2
.gitignore
vendored
2
.gitignore
vendored
@ -51,7 +51,6 @@
|
||||
*.symversions
|
||||
*.tab.[ch]
|
||||
*.tar
|
||||
*.usyms
|
||||
*.xz
|
||||
*.zst
|
||||
Module.symvers
|
||||
@ -112,7 +111,6 @@ modules.order
|
||||
#
|
||||
/include/config/
|
||||
/include/generated/
|
||||
/include/ksym/
|
||||
/arch/*/include/generated/
|
||||
|
||||
# stgit generated dirs
|
||||
|
||||
7
Documentation/ABI/stable/sysfs-platform-wmi-bmof
Normal file
7
Documentation/ABI/stable/sysfs-platform-wmi-bmof
Normal file
@ -0,0 +1,7 @@
|
||||
What: /sys/bus/wmi/devices/05901221-D566-11D1-B2F0-00A0C9062910[-X]/bmof
|
||||
Date: Jun 2017
|
||||
KernelVersion: 4.13
|
||||
Description:
|
||||
Binary MOF metadata used to decribe the details of available ACPI WMI interfaces.
|
||||
|
||||
See Documentation/wmi/devices/wmi-bmof.rst for details.
|
||||
@ -3,19 +3,32 @@ Date: September 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
This file contains the contents of the fan sensor information buffer,
|
||||
which contains fan sensor entries and a terminating character (0xFF).
|
||||
This file contains the contents of the fan sensor information
|
||||
buffer, which contains fan sensor entries and a terminating
|
||||
character (0xFF).
|
||||
|
||||
Each fan sensor entry consists of three bytes with an unknown meaning,
|
||||
interested people may use this file for reverse-engineering.
|
||||
Each fan sensor entry contains:
|
||||
|
||||
- fan type (single byte)
|
||||
- fan speed in RPM (two bytes, little endian)
|
||||
|
||||
See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
|
||||
|
||||
What: /sys/kernel/debug/dell-wmi-ddv-<wmi_device_name>/thermal_sensor_information
|
||||
Date: September 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
This file contains the contents of the thermal sensor information buffer,
|
||||
which contains thermal sensor entries and a terminating character (0xFF).
|
||||
This file contains the contents of the thermal sensor information
|
||||
buffer, which contains thermal sensor entries and a terminating
|
||||
character (0xFF).
|
||||
|
||||
Each thermal sensor entry consists of five bytes with an unknown meaning,
|
||||
interested people may use this file for reverse-engineering.
|
||||
Each thermal sensor entry contains:
|
||||
|
||||
- thermal type (single byte)
|
||||
- current temperature (single byte)
|
||||
- min. temperature (single byte)
|
||||
- max. temperature (single byte)
|
||||
- unknown field (single byte)
|
||||
|
||||
See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
|
||||
|
||||
@ -95,3 +95,25 @@ Description:
|
||||
This file does not exist if the HBA driver does not implement
|
||||
support for the SATA NCQ priority feature, regardless of the
|
||||
device support for this feature.
|
||||
|
||||
|
||||
What: /sys/block/*/device/cdl_supported
|
||||
Date: May, 2023
|
||||
KernelVersion: v6.5
|
||||
Contact: linux-scsi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Indicates if the device supports the command duration
|
||||
limits feature found in some ATA and SCSI devices.
|
||||
|
||||
|
||||
What: /sys/block/*/device/cdl_enable
|
||||
Date: May, 2023
|
||||
KernelVersion: v6.5
|
||||
Contact: linux-scsi@vger.kernel.org
|
||||
Description:
|
||||
(RW) For a device supporting the command duration limits
|
||||
feature, write to the file to turn on or off the feature.
|
||||
By default this feature is turned off.
|
||||
Writing "1" to this file enables the use of command duration
|
||||
limits for read and write commands in the kernel and turns on
|
||||
the feature on the device. Writing "0" disables the feature.
|
||||
|
||||
@ -58,6 +58,54 @@ Description:
|
||||
affinity for this device.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/security/state
|
||||
Date: June, 2023
|
||||
KernelVersion: v6.5
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) Reading this file will display the CXL security state for
|
||||
that device. Such states can be: 'disabled', 'sanitize', when
|
||||
a sanitization is currently underway; or those available only
|
||||
for persistent memory: 'locked', 'unlocked' or 'frozen'. This
|
||||
sysfs entry is select/poll capable from userspace to notify
|
||||
upon completion of a sanitize operation.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/security/sanitize
|
||||
Date: June, 2023
|
||||
KernelVersion: v6.5
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) Write a boolean 'true' string value to this attribute to
|
||||
sanitize the device to securely re-purpose or decommission it.
|
||||
This is done by ensuring that all user data and meta-data,
|
||||
whether it resides in persistent capacity, volatile capacity,
|
||||
or the LSA, is made permanently unavailable by whatever means
|
||||
is appropriate for the media type. This functionality requires
|
||||
the device to be not be actively decoding any HPA ranges.
|
||||
|
||||
|
||||
What /sys/bus/cxl/devices/memX/security/erase
|
||||
Date: June, 2023
|
||||
KernelVersion: v6.5
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) Write a boolean 'true' string value to this attribute to
|
||||
secure erase user data by changing the media encryption keys for
|
||||
all user data areas of the device.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/firmware/
|
||||
Date: April, 2023
|
||||
KernelVersion: v6.5
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) Firmware uploader mechanism. The different files under
|
||||
this directory can be used to upload and activate new
|
||||
firmware for CXL devices. The interfaces under this are
|
||||
documented in sysfs-class-firmware.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/*/devtype
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
|
||||
@ -243,8 +243,8 @@ Description:
|
||||
|
||||
index:
|
||||
Used with HDD and NVME authentication to set the drive index
|
||||
that is being referenced (e.g hdd0, hdd1 etc)
|
||||
This attribute defaults to device 0.
|
||||
that is being referenced (e.g hdd1, hdd2 etc)
|
||||
This attribute defaults to device 1.
|
||||
|
||||
certificate, signature, save_signature:
|
||||
These attributes are used for certificate based authentication. This is
|
||||
|
||||
@ -27,7 +27,18 @@ Description: (RW) Reports the current configuration of the QAT device.
|
||||
|
||||
* sym;asym: the device is configured for running crypto
|
||||
services
|
||||
* asym;sym: identical to sym;asym
|
||||
* dc: the device is configured for running compression services
|
||||
* sym: the device is configured for running symmetric crypto
|
||||
services
|
||||
* asym: the device is configured for running asymmetric crypto
|
||||
services
|
||||
* asym;dc: the device is configured for running asymmetric
|
||||
crypto services and compression services
|
||||
* dc;asym: identical to asym;dc
|
||||
* sym;dc: the device is configured for running symmetric crypto
|
||||
services and compression services
|
||||
* dc;sym: identical to sym;dc
|
||||
|
||||
It is possible to set the configuration only if the device
|
||||
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
|
||||
@ -47,3 +58,38 @@ Description: (RW) Reports the current configuration of the QAT device.
|
||||
dc
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
|
||||
Date: June 2023
|
||||
KernelVersion: 6.5
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RW) This configuration option provides a way to force the device into remaining in
|
||||
the MAX power state.
|
||||
If idle support is enabled the device will transition to the `MIN` power state when
|
||||
idle, otherwise will stay in the MAX power state.
|
||||
Write to the file to enable or disable idle support.
|
||||
|
||||
The values are:
|
||||
|
||||
* 0: idle support is disabled
|
||||
* 1: idle support is enabled
|
||||
|
||||
Default value is 1.
|
||||
|
||||
It is possible to set the pm_idle_enabled value only if the device
|
||||
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
|
||||
|
||||
The following example shows how to change the pm_idle_enabled of
|
||||
a device::
|
||||
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/state
|
||||
up
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
|
||||
1
|
||||
# echo down > /sys/bus/pci/devices/<BDF>/qat/state
|
||||
# echo 0 > /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
|
||||
# echo up > /sys/bus/pci/devices/<BDF>/qat/state
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
|
||||
0
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
@ -1426,6 +1426,17 @@ Description: This entry shows the status of WriteBooster buffer flushing
|
||||
If flushing is enabled, the device executes the flush
|
||||
operation when the command queue is empty.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/wb_flush_threshold
|
||||
What: /sys/bus/platform/devices/*.ufs/wb_flush_threshold
|
||||
Date: June 2023
|
||||
Contact: Lu Hongfei <luhongfei@vivo.com>
|
||||
Description:
|
||||
wb_flush_threshold represents the threshold for flushing WriteBooster buffer,
|
||||
whose value expressed in unit of 10% granularity, such as '1' representing 10%,
|
||||
'2' representing 20%, and so on.
|
||||
If avail_wb_buff < wb_flush_threshold, it indicates that WriteBooster buffer needs to
|
||||
be flushed, otherwise it is not necessary.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version
|
||||
What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version
|
||||
Date: June 2021
|
||||
|
||||
@ -3,5 +3,7 @@ Date: September 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
Reports the Dell ePPID (electronic Dell Piece Part Identification)
|
||||
Reports the Dell ePPID (electronic Piece Part Identification)
|
||||
of the ACPI battery.
|
||||
|
||||
See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
|
||||
|
||||
@ -75,3 +75,12 @@ KernelVersion: 6.4
|
||||
Contact: "Liming Sun <limings@nvidia.com>"
|
||||
Description:
|
||||
The file used to access the BlueField boot fifo.
|
||||
|
||||
What: /sys/bus/platform/devices/MLNXBF04:00/rsh_log
|
||||
Date: May 2023
|
||||
KernelVersion: 6.4
|
||||
Contact: "Liming Sun <limings@nvidia.com>"
|
||||
Description:
|
||||
The file used to write BlueField boot log with the format
|
||||
"[INFO|WARN|ERR|ASSERT ]<msg>". Log level 'INFO' is used by
|
||||
default if not specified.
|
||||
|
||||
@ -88,13 +88,10 @@ commands can be used::
|
||||
# echo 0x104c > functions/pci_epf_ntb/func1/vendorid
|
||||
# echo 0xb00d > functions/pci_epf_ntb/func1/deviceid
|
||||
|
||||
In order to configure NTB specific attributes, a new sub-directory to func1
|
||||
should be created::
|
||||
|
||||
# mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/
|
||||
|
||||
The NTB function driver will populate this directory with various attributes
|
||||
that can be configured by the user::
|
||||
The PCI endpoint framework also automatically creates a sub-directory in the
|
||||
function attribute directory. This sub-directory has the same name as the name
|
||||
of the function device and is populated with the following NTB specific
|
||||
attributes that can be configured by the user::
|
||||
|
||||
# ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/
|
||||
db_count mw1 mw2 mw3 mw4 num_mws
|
||||
|
||||
@ -84,13 +84,10 @@ commands can be used::
|
||||
# echo 0x1957 > functions/pci_epf_vntb/func1/vendorid
|
||||
# echo 0x0809 > functions/pci_epf_vntb/func1/deviceid
|
||||
|
||||
In order to configure NTB specific attributes, a new sub-directory to func1
|
||||
should be created::
|
||||
|
||||
# mkdir functions/pci_epf_vntb/func1/pci_epf_vntb.0/
|
||||
|
||||
The NTB function driver will populate this directory with various attributes
|
||||
that can be configured by the user::
|
||||
The PCI endpoint framework also automatically creates a sub-directory in the
|
||||
function attribute directory. This sub-directory has the same name as the name
|
||||
of the function device and is populated with the following NTB specific
|
||||
attributes that can be configured by the user::
|
||||
|
||||
# ls functions/pci_epf_vntb/func1/pci_epf_vntb.0/
|
||||
db_count mw1 mw2 mw3 mw4 num_mws
|
||||
@ -103,7 +100,7 @@ A sample configuration for NTB function is given below::
|
||||
# echo 1 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/num_mws
|
||||
# echo 0x100000 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/mw1
|
||||
|
||||
A sample configuration for virtual NTB driver for virutal PCI bus::
|
||||
A sample configuration for virtual NTB driver for virtual PCI bus::
|
||||
|
||||
# echo 0x1957 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_vid
|
||||
# echo 0x080A > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_pid
|
||||
|
||||
@ -290,7 +290,7 @@ PCI_IRQ_MSI or PCI_IRQ_MSIX flags.
|
||||
List of device drivers MSI(-X) APIs
|
||||
===================================
|
||||
|
||||
The PCI/MSI subystem has a dedicated C file for its exported device driver
|
||||
The PCI/MSI subsystem has a dedicated C file for its exported device driver
|
||||
APIs — `drivers/pci/msi/api.c`. The following functions are exported:
|
||||
|
||||
.. kernel-doc:: drivers/pci/msi/api.c
|
||||
|
||||
@ -364,7 +364,7 @@ Note, however, not all failures are truly "permanent". Some are
|
||||
caused by over-heating, some by a poorly seated card. Many
|
||||
PCI error events are caused by software bugs, e.g. DMA's to
|
||||
wild addresses or bogus split transactions due to programming
|
||||
errors. See the discussion in powerpc/eeh-pci-error-recovery.txt
|
||||
errors. See the discussion in Documentation/powerpc/eeh-pci-error-recovery.rst
|
||||
for additional detail on real-life experience of the causes of
|
||||
software errors.
|
||||
|
||||
|
||||
@ -16,62 +16,61 @@ Overview
|
||||
About this guide
|
||||
----------------
|
||||
|
||||
This guide describes the basics of the PCI Express Advanced Error
|
||||
This guide describes the basics of the PCI Express (PCIe) Advanced Error
|
||||
Reporting (AER) driver and provides information on how to use it, as
|
||||
well as how to enable the drivers of endpoint devices to conform with
|
||||
PCI Express AER driver.
|
||||
well as how to enable the drivers of Endpoint devices to conform with
|
||||
the PCIe AER driver.
|
||||
|
||||
|
||||
What is the PCI Express AER Driver?
|
||||
-----------------------------------
|
||||
What is the PCIe AER Driver?
|
||||
----------------------------
|
||||
|
||||
PCI Express error signaling can occur on the PCI Express link itself
|
||||
or on behalf of transactions initiated on the link. PCI Express
|
||||
PCIe error signaling can occur on the PCIe link itself
|
||||
or on behalf of transactions initiated on the link. PCIe
|
||||
defines two error reporting paradigms: the baseline capability and
|
||||
the Advanced Error Reporting capability. The baseline capability is
|
||||
required of all PCI Express components providing a minimum defined
|
||||
required of all PCIe components providing a minimum defined
|
||||
set of error reporting requirements. Advanced Error Reporting
|
||||
capability is implemented with a PCI Express advanced error reporting
|
||||
capability is implemented with a PCIe Advanced Error Reporting
|
||||
extended capability structure providing more robust error reporting.
|
||||
|
||||
The PCI Express AER driver provides the infrastructure to support PCI
|
||||
Express Advanced Error Reporting capability. The PCI Express AER
|
||||
driver provides three basic functions:
|
||||
The PCIe AER driver provides the infrastructure to support PCIe Advanced
|
||||
Error Reporting capability. The PCIe AER driver provides three basic
|
||||
functions:
|
||||
|
||||
- Gathers the comprehensive error information if errors occurred.
|
||||
- Reports error to the users.
|
||||
- Performs error recovery actions.
|
||||
|
||||
AER driver only attaches root ports which support PCI-Express AER
|
||||
capability.
|
||||
The AER driver only attaches to Root Ports and RCECs that support the PCIe
|
||||
AER capability.
|
||||
|
||||
|
||||
User Guide
|
||||
==========
|
||||
|
||||
Include the PCI Express AER Root Driver into the Linux Kernel
|
||||
-------------------------------------------------------------
|
||||
Include the PCIe AER Root Driver into the Linux Kernel
|
||||
------------------------------------------------------
|
||||
|
||||
The PCI Express AER Root driver is a Root Port service driver attached
|
||||
to the PCI Express Port Bus driver. If a user wants to use it, the driver
|
||||
has to be compiled. Option CONFIG_PCIEAER supports this capability. It
|
||||
depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and
|
||||
CONFIG_PCIEAER = y.
|
||||
The PCIe AER driver is a Root Port service driver attached
|
||||
via the PCIe Port Bus driver. If a user wants to use it, the driver
|
||||
must be compiled. It is enabled with CONFIG_PCIEAER, which
|
||||
depends on CONFIG_PCIEPORTBUS.
|
||||
|
||||
Load PCI Express AER Root Driver
|
||||
--------------------------------
|
||||
Load PCIe AER Root Driver
|
||||
-------------------------
|
||||
|
||||
Some systems have AER support in firmware. Enabling Linux AER support at
|
||||
the same time the firmware handles AER may result in unpredictable
|
||||
the same time the firmware handles AER would result in unpredictable
|
||||
behavior. Therefore, Linux does not handle AER events unless the firmware
|
||||
grants AER control to the OS via the ACPI _OSC method. See the PCI FW 3.0
|
||||
grants AER control to the OS via the ACPI _OSC method. See the PCI Firmware
|
||||
Specification for details regarding _OSC usage.
|
||||
|
||||
AER error output
|
||||
----------------
|
||||
|
||||
When a PCIe AER error is captured, an error message will be output to
|
||||
console. If it's a correctable error, it is output as a warning.
|
||||
console. If it's a correctable error, it is output as an info message.
|
||||
Otherwise, it is printed as an error. So users could choose different
|
||||
log level to filter out correctable error messages.
|
||||
|
||||
@ -82,9 +81,9 @@ Below shows an example::
|
||||
0000:50:00.0: [20] Unsupported Request (First)
|
||||
0000:50:00.0: TLP Header: 04000001 00200a03 05010000 00050100
|
||||
|
||||
In the example, 'Requester ID' means the ID of the device who sends
|
||||
the error message to root port. Pls. refer to pci express specs for
|
||||
other fields.
|
||||
In the example, 'Requester ID' means the ID of the device that sent
|
||||
the error message to the Root Port. Please refer to PCIe specs for other
|
||||
fields.
|
||||
|
||||
AER Statistics / Counters
|
||||
-------------------------
|
||||
@ -96,65 +95,56 @@ Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
|
||||
Developer Guide
|
||||
===============
|
||||
|
||||
To enable AER aware support requires a software driver to configure
|
||||
the AER capability structure within its device and to provide callbacks.
|
||||
To enable error recovery, a software driver must provide callbacks.
|
||||
|
||||
To support AER better, developers need understand how AER does work
|
||||
firstly.
|
||||
To support AER better, developers need to understand how AER works.
|
||||
|
||||
PCI Express errors are classified into two types: correctable errors
|
||||
and uncorrectable errors. This classification is based on the impacts
|
||||
PCIe errors are classified into two types: correctable errors
|
||||
and uncorrectable errors. This classification is based on the impact
|
||||
of those errors, which may result in degraded performance or function
|
||||
failure.
|
||||
|
||||
Correctable errors pose no impacts on the functionality of the
|
||||
interface. The PCI Express protocol can recover without any software
|
||||
interface. The PCIe protocol can recover without any software
|
||||
intervention or any loss of data. These errors are detected and
|
||||
corrected by hardware. Unlike correctable errors, uncorrectable
|
||||
corrected by hardware.
|
||||
|
||||
Unlike correctable errors, uncorrectable
|
||||
errors impact functionality of the interface. Uncorrectable errors
|
||||
can cause a particular transaction or a particular PCI Express link
|
||||
can cause a particular transaction or a particular PCIe link
|
||||
to be unreliable. Depending on those error conditions, uncorrectable
|
||||
errors are further classified into non-fatal errors and fatal errors.
|
||||
Non-fatal errors cause the particular transaction to be unreliable,
|
||||
but the PCI Express link itself is fully functional. Fatal errors, on
|
||||
but the PCIe link itself is fully functional. Fatal errors, on
|
||||
the other hand, cause the link to be unreliable.
|
||||
|
||||
When AER is enabled, a PCI Express device will automatically send an
|
||||
error message to the PCIe root port above it when the device captures
|
||||
When PCIe error reporting is enabled, a device will automatically send an
|
||||
error message to the Root Port above it when it captures
|
||||
an error. The Root Port, upon receiving an error reporting message,
|
||||
internally processes and logs the error message in its PCI Express
|
||||
capability structure. Error information being logged includes storing
|
||||
internally processes and logs the error message in its AER
|
||||
Capability structure. Error information being logged includes storing
|
||||
the error reporting agent's requestor ID into the Error Source
|
||||
Identification Registers and setting the error bits of the Root Error
|
||||
Status Register accordingly. If AER error reporting is enabled in Root
|
||||
Error Command Register, the Root Port generates an interrupt if an
|
||||
Status Register accordingly. If AER error reporting is enabled in the Root
|
||||
Error Command Register, the Root Port generates an interrupt when an
|
||||
error is detected.
|
||||
|
||||
Note that the errors as described above are related to the PCI Express
|
||||
Note that the errors as described above are related to the PCIe
|
||||
hierarchy and links. These errors do not include any device specific
|
||||
errors because device specific errors will still get sent directly to
|
||||
the device driver.
|
||||
|
||||
Configure the AER capability structure
|
||||
--------------------------------------
|
||||
|
||||
AER aware drivers of PCI Express component need change the device
|
||||
control registers to enable AER. They also could change AER registers,
|
||||
including mask and severity registers. Helper function
|
||||
pci_enable_pcie_error_reporting could be used to enable AER. See
|
||||
section 3.3.
|
||||
|
||||
Provide callbacks
|
||||
-----------------
|
||||
|
||||
callback reset_link to reset pci express link
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
callback reset_link to reset PCIe link
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This callback is used to reset the pci express physical link when a
|
||||
fatal error happens. The root port aer service driver provides a
|
||||
default reset_link function, but different upstream ports might
|
||||
have different specifications to reset pci express link, so all
|
||||
upstream ports should provide their own reset_link functions.
|
||||
This callback is used to reset the PCIe physical link when a
|
||||
fatal error happens. The Root Port AER service driver provides a
|
||||
default reset_link function, but different Upstream Ports might
|
||||
have different specifications to reset the PCIe link, so
|
||||
Upstream Port drivers may provide their own reset_link functions.
|
||||
|
||||
Section 3.2.2.2 provides more detailed info on when to call
|
||||
reset_link.
|
||||
@ -162,24 +152,24 @@ reset_link.
|
||||
PCI error-recovery callbacks
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The PCI Express AER Root driver uses error callbacks to coordinate
|
||||
The PCIe AER Root driver uses error callbacks to coordinate
|
||||
with downstream device drivers associated with a hierarchy in question
|
||||
when performing error recovery actions.
|
||||
|
||||
Data struct pci_driver has a pointer, err_handler, to point to
|
||||
pci_error_handlers who consists of a couple of callback function
|
||||
pointers. AER driver follows the rules defined in
|
||||
pci-error-recovery.txt except pci express specific parts (e.g.
|
||||
reset_link). Pls. refer to pci-error-recovery.txt for detailed
|
||||
pointers. The AER driver follows the rules defined in
|
||||
pci-error-recovery.rst except PCIe-specific parts (e.g.
|
||||
reset_link). Please refer to pci-error-recovery.rst for detailed
|
||||
definitions of the callbacks.
|
||||
|
||||
Below sections specify when to call the error callback functions.
|
||||
The sections below specify when to call the error callback functions.
|
||||
|
||||
Correctable errors
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Correctable errors pose no impacts on the functionality of
|
||||
the interface. The PCI Express protocol can recover without any
|
||||
the interface. The PCIe protocol can recover without any
|
||||
software intervention or any loss of data. These errors do not
|
||||
require any recovery actions. The AER driver clears the device's
|
||||
correctable error status register accordingly and logs these errors.
|
||||
@ -190,12 +180,12 @@ Non-correctable (non-fatal and fatal) errors
|
||||
If an error message indicates a non-fatal error, performing link reset
|
||||
at upstream is not required. The AER driver calls error_detected(dev,
|
||||
pci_channel_io_normal) to all drivers associated within a hierarchy in
|
||||
question. for example::
|
||||
question. For example::
|
||||
|
||||
EndPoint<==>DownstreamPort B<==>UpstreamPort A<==>RootPort
|
||||
Endpoint <==> Downstream Port B <==> Upstream Port A <==> Root Port
|
||||
|
||||
If Upstream port A captures an AER error, the hierarchy consists of
|
||||
Downstream port B and EndPoint.
|
||||
If Upstream Port A captures an AER error, the hierarchy consists of
|
||||
Downstream Port B and Endpoint.
|
||||
|
||||
A driver may return PCI_ERS_RESULT_CAN_RECOVER,
|
||||
PCI_ERS_RESULT_DISCONNECT, or PCI_ERS_RESULT_NEED_RESET, depending on
|
||||
@ -212,36 +202,11 @@ to reset the link. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER
|
||||
and reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
|
||||
to mmio_enabled.
|
||||
|
||||
helper functions
|
||||
----------------
|
||||
::
|
||||
|
||||
int pci_enable_pcie_error_reporting(struct pci_dev *dev);
|
||||
|
||||
pci_enable_pcie_error_reporting enables the device to send error
|
||||
messages to root port when an error is detected. Note that devices
|
||||
don't enable the error reporting by default, so device drivers need
|
||||
call this function to enable it.
|
||||
|
||||
::
|
||||
|
||||
int pci_disable_pcie_error_reporting(struct pci_dev *dev);
|
||||
|
||||
pci_disable_pcie_error_reporting disables the device to send error
|
||||
messages to root port when an error is detected.
|
||||
|
||||
::
|
||||
|
||||
int pci_aer_clear_nonfatal_status(struct pci_dev *dev);`
|
||||
|
||||
pci_aer_clear_nonfatal_status clears non-fatal errors in the uncorrectable
|
||||
error status register.
|
||||
|
||||
Frequent Asked Questions
|
||||
------------------------
|
||||
|
||||
Q:
|
||||
What happens if a PCI Express device driver does not provide an
|
||||
What happens if a PCIe device driver does not provide an
|
||||
error recovery handler (pci_driver->err_handler is equal to NULL)?
|
||||
|
||||
A:
|
||||
@ -257,24 +222,6 @@ A:
|
||||
Fatal error recovery will fail if the errors are reported by the
|
||||
upstream ports who are attached by the service driver.
|
||||
|
||||
Q:
|
||||
How does this infrastructure deal with driver that is not PCI
|
||||
Express aware?
|
||||
|
||||
A:
|
||||
This infrastructure calls the error callback functions of the
|
||||
driver when an error happens. But if the driver is not aware of
|
||||
PCI Express, the device might not report its own errors to root
|
||||
port.
|
||||
|
||||
Q:
|
||||
What modifications will that driver need to make it compatible
|
||||
with the PCI Express AER Root driver?
|
||||
|
||||
A:
|
||||
It could call the helper functions to enable AER in devices and
|
||||
cleanup uncorrectable status register. Pls. refer to section 3.3.
|
||||
|
||||
|
||||
Software error injection
|
||||
========================
|
||||
@ -296,5 +243,5 @@ from:
|
||||
|
||||
https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
|
||||
|
||||
More information about aer-inject can be found in the document comes
|
||||
with its source code.
|
||||
More information about aer-inject can be found in the document in
|
||||
its source code.
|
||||
|
||||
@ -67,6 +67,16 @@ Optional feature parameters:
|
||||
Perform the replacement only if bio->bi_opf has all the
|
||||
selected flags set.
|
||||
|
||||
random_read_corrupt <probability>
|
||||
During <down interval>, replace random byte in a read bio
|
||||
with a random value. probability is an integer between
|
||||
0 and 1000000000 meaning 0% to 100% probability of corruption.
|
||||
|
||||
random_write_corrupt <probability>
|
||||
During <down interval>, replace random byte in a write bio
|
||||
with a random value. probability is an integer between
|
||||
0 and 1000000000 meaning 0% to 100% probability of corruption.
|
||||
|
||||
Examples:
|
||||
|
||||
Replaces the 32nd byte of READ bios with the value 1::
|
||||
|
||||
@ -25,7 +25,7 @@ mode it calculates and verifies the integrity tag internally. In this
|
||||
mode, the dm-integrity target can be used to detect silent data
|
||||
corruption on the disk or in the I/O path.
|
||||
|
||||
There's an alternate mode of operation where dm-integrity uses bitmap
|
||||
There's an alternate mode of operation where dm-integrity uses a bitmap
|
||||
instead of a journal. If a bit in the bitmap is 1, the corresponding
|
||||
region's data and integrity tags are not synchronized - if the machine
|
||||
crashes, the unsynchronized regions will be recalculated. The bitmap mode
|
||||
@ -38,6 +38,15 @@ the device. But it will only format the device if the superblock contains
|
||||
zeroes. If the superblock is neither valid nor zeroed, the dm-integrity
|
||||
target can't be loaded.
|
||||
|
||||
Accesses to the on-disk metadata area containing checksums (aka tags) are
|
||||
buffered using dm-bufio. When an access to any given metadata area
|
||||
occurs, each unique metadata area gets its own buffer(s). The buffer size
|
||||
is capped at the size of the metadata area, but may be smaller, thereby
|
||||
requiring multiple buffers to represent the full metadata area. A smaller
|
||||
buffer size will produce a smaller resulting read/write operation to the
|
||||
metadata area for small reads/writes. The metadata is still read even in
|
||||
a full write to the data covered by a single buffer.
|
||||
|
||||
To use the target for the first time:
|
||||
|
||||
1. overwrite the superblock with zeroes
|
||||
@ -93,7 +102,7 @@ journal_sectors:number
|
||||
device. If the device is already formatted, the value from the
|
||||
superblock is used.
|
||||
|
||||
interleave_sectors:number
|
||||
interleave_sectors:number (default 32768)
|
||||
The number of interleaved sectors. This values is rounded down to
|
||||
a power of two. If the device is already formatted, the value from
|
||||
the superblock is used.
|
||||
@ -102,20 +111,16 @@ meta_device:device
|
||||
Don't interleave the data and metadata on the device. Use a
|
||||
separate device for metadata.
|
||||
|
||||
buffer_sectors:number
|
||||
The number of sectors in one buffer. The value is rounded down to
|
||||
a power of two.
|
||||
buffer_sectors:number (default 128)
|
||||
The number of sectors in one metadata buffer. The value is rounded
|
||||
down to a power of two.
|
||||
|
||||
The tag area is accessed using buffers, the buffer size is
|
||||
configurable. The large buffer size means that the I/O size will
|
||||
be larger, but there could be less I/Os issued.
|
||||
|
||||
journal_watermark:number
|
||||
journal_watermark:number (default 50)
|
||||
The journal watermark in percents. When the size of the journal
|
||||
exceeds this watermark, the thread that flushes the journal will
|
||||
be started.
|
||||
|
||||
commit_time:number
|
||||
commit_time:number (default 10000)
|
||||
Commit time in milliseconds. When this time passes, the journal is
|
||||
written. The journal is also written immediately if the FLUSH
|
||||
request is received.
|
||||
@ -163,11 +168,10 @@ journal_mac:algorithm(:key) (the key is optional)
|
||||
the journal. Thus, modified sector number would be detected at
|
||||
this stage.
|
||||
|
||||
block_size:number
|
||||
The size of a data block in bytes. The larger the block size the
|
||||
block_size:number (default 512)
|
||||
The size of a data block in bytes. The larger the block size the
|
||||
less overhead there is for per-block integrity metadata.
|
||||
Supported values are 512, 1024, 2048 and 4096 bytes. If not
|
||||
specified the default block size is 512 bytes.
|
||||
Supported values are 512, 1024, 2048 and 4096 bytes.
|
||||
|
||||
sectors_per_bit:number
|
||||
In the bitmap mode, this parameter specifies the number of
|
||||
@ -209,6 +213,12 @@ table and swap the tables with suspend and resume). The other arguments
|
||||
should not be changed when reloading the target because the layout of disk
|
||||
data depend on them and the reloaded target would be non-functional.
|
||||
|
||||
For example, on a device using the default interleave_sectors of 32768, a
|
||||
block_size of 512, and an internal_hash of crc32c with a tag size of 4
|
||||
bytes, it will take 128 KiB of tags to track a full data area, requiring
|
||||
256 sectors of metadata per data area. With the default buffer_sectors of
|
||||
128, that means there will be 2 buffers per metadata area, or 2 buffers
|
||||
per 16 MiB of data.
|
||||
|
||||
Status line:
|
||||
|
||||
@ -286,7 +296,8 @@ The layout of the formatted block device:
|
||||
Each run contains:
|
||||
|
||||
* tag area - it contains integrity tags. There is one tag for each
|
||||
sector in the data area
|
||||
sector in the data area. The size of this area is always 4KiB or
|
||||
greater.
|
||||
* data area - it contains data sectors. The number of data sectors
|
||||
in one run must be a power of two. log2 of this value is stored
|
||||
in the superblock.
|
||||
|
||||
@ -1,17 +1,17 @@
|
||||
acpi= [HW,ACPI,X86,ARM64]
|
||||
acpi= [HW,ACPI,X86,ARM64,RISCV64]
|
||||
Advanced Configuration and Power Interface
|
||||
Format: { force | on | off | strict | noirq | rsdt |
|
||||
copy_dsdt }
|
||||
force -- enable ACPI if default was off
|
||||
on -- enable ACPI but allow fallback to DT [arm64]
|
||||
on -- enable ACPI but allow fallback to DT [arm64,riscv64]
|
||||
off -- disable ACPI if default was on
|
||||
noirq -- do not use ACPI for IRQ routing
|
||||
strict -- Be less tolerant of platforms that are not
|
||||
strictly ACPI specification compliant.
|
||||
rsdt -- prefer RSDT over (default) XSDT
|
||||
copy_dsdt -- copy DSDT to memory
|
||||
For ARM64, ONLY "acpi=off", "acpi=on" or "acpi=force"
|
||||
are available
|
||||
For ARM64 and RISCV64, ONLY "acpi=off", "acpi=on" or
|
||||
"acpi=force" are available
|
||||
|
||||
See also Documentation/power/runtime_pm.rst, pci=noacpi
|
||||
|
||||
|
||||
68
Documentation/admin-guide/perf/cxl.rst
Normal file
68
Documentation/admin-guide/perf/cxl.rst
Normal file
@ -0,0 +1,68 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======================================
|
||||
CXL Performance Monitoring Unit (CPMU)
|
||||
======================================
|
||||
|
||||
The CXL rev 3.0 specification provides a definition of CXL Performance
|
||||
Monitoring Unit in section 13.2: Performance Monitoring.
|
||||
|
||||
CXL components (e.g. Root Port, Switch Upstream Port, End Point) may have
|
||||
any number of CPMU instances. CPMU capabilities are fully discoverable from
|
||||
the devices. The specification provides event definitions for all CXL protocol
|
||||
message types and a set of additional events for things commonly counted on
|
||||
CXL devices (e.g. DRAM events).
|
||||
|
||||
CPMU driver
|
||||
===========
|
||||
|
||||
The CPMU driver registers a perf PMU with the name pmu_mem<X>.<Y> on the CXL bus
|
||||
representing the Yth CPMU for memX.
|
||||
|
||||
/sys/bus/cxl/device/pmu_mem<X>.<Y>
|
||||
|
||||
The associated PMU is registered as
|
||||
|
||||
/sys/bus/event_sources/devices/cxl_pmu_mem<X>.<Y>
|
||||
|
||||
In common with other CXL bus devices, the id has no specific meaning and the
|
||||
relationship to specific CXL device should be established via the device parent
|
||||
of the device on the CXL bus.
|
||||
|
||||
PMU driver provides description of available events and filter options in sysfs.
|
||||
|
||||
The "format" directory describes all formats of the config (event vendor id,
|
||||
group id and mask) config1 (threshold, filter enables) and config2 (filter
|
||||
parameters) fields of the perf_event_attr structure. The "events" directory
|
||||
describes all documented events show in perf list.
|
||||
|
||||
The events shown in perf list are the most fine grained events with a single
|
||||
bit of the event mask set. More general events may be enable by setting
|
||||
multiple mask bits in config. For example, all Device to Host Read Requests
|
||||
may be captured on a single counter by setting the bits for all of
|
||||
|
||||
* d2h_req_rdcurr
|
||||
* d2h_req_rdown
|
||||
* d2h_req_rdshared
|
||||
* d2h_req_rdany
|
||||
* d2h_req_rdownnodata
|
||||
|
||||
Example of usage::
|
||||
|
||||
$#perf list
|
||||
cxl_pmu_mem0.0/clock_ticks/ [Kernel PMU event]
|
||||
cxl_pmu_mem0.0/d2h_req_rdshared/ [Kernel PMU event]
|
||||
cxl_pmu_mem0.0/h2d_req_snpcur/ [Kernel PMU event]
|
||||
cxl_pmu_mem0.0/h2d_req_snpdata/ [Kernel PMU event]
|
||||
cxl_pmu_mem0.0/h2d_req_snpinv/ [Kernel PMU event]
|
||||
-----------------------------------------------------------
|
||||
|
||||
$# perf stat -a -e cxl_pmu_mem0.0/clock_ticks/ -e cxl_pmu_mem0.0/d2h_req_rdshared/
|
||||
|
||||
Vendor specific events may also be available and if so can be used via
|
||||
|
||||
$# perf stat -a -e cxl_pmu_mem0.0/vid=VID,gid=GID,mask=MASK/
|
||||
|
||||
The driver does not support sampling so "perf record" is unsupported.
|
||||
It only supports system-wide counting so attaching to a task is
|
||||
unsupported.
|
||||
@ -21,3 +21,4 @@ Performance monitor support
|
||||
alibaba_pmu
|
||||
nvidia-pmu
|
||||
meson-ddr-pmu
|
||||
cxl
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
Intel Uncore Frequency Scaling
|
||||
==============================
|
||||
|
||||
:Copyright: |copy| 2022 Intel Corporation
|
||||
:Copyright: |copy| 2022-2023 Intel Corporation
|
||||
|
||||
:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
|
||||
|
||||
@ -58,3 +58,58 @@ Each package_*_die_* contains the following attributes:
|
||||
|
||||
``current_freq_khz``
|
||||
This attribute is used to get the current uncore frequency.
|
||||
|
||||
SoCs with TPMI (Topology Aware Register and PM Capsule Interface)
|
||||
-----------------------------------------------------------------
|
||||
|
||||
An SoC can contain multiple power domains with individual or collection
|
||||
of mesh partitions. This partition is called fabric cluster.
|
||||
|
||||
Certain type of meshes will need to run at the same frequency, they will
|
||||
be placed in the same fabric cluster. Benefit of fabric cluster is that it
|
||||
offers a scalable mechanism to deal with partitioned fabrics in a SoC.
|
||||
|
||||
The current sysfs interface supports controls at package and die level.
|
||||
This interface is not enough to support more granular control at
|
||||
fabric cluster level.
|
||||
|
||||
SoCs with the support of TPMI (Topology Aware Register and PM Capsule
|
||||
Interface), can have multiple power domains. Each power domain can
|
||||
contain one or more fabric clusters.
|
||||
|
||||
To represent controls at fabric cluster level in addition to the
|
||||
controls at package and die level (like systems without TPMI
|
||||
support), sysfs is enhanced. This granular interface is presented in the
|
||||
sysfs with directories names prefixed with "uncore". For example:
|
||||
uncore00, uncore01 etc.
|
||||
|
||||
The scope of control is specified by attributes "package_id", "domain_id"
|
||||
and "fabric_cluster_id" in the directory.
|
||||
|
||||
Attributes in each directory:
|
||||
|
||||
``domain_id``
|
||||
This attribute is used to get the power domain id of this instance.
|
||||
|
||||
``fabric_cluster_id``
|
||||
This attribute is used to get the fabric cluster id of this instance.
|
||||
|
||||
``package_id``
|
||||
This attribute is used to get the package id of this instance.
|
||||
|
||||
The other attributes are same as presented at package_*_die_* level.
|
||||
|
||||
In most of current use cases, the "max_freq_khz" and "min_freq_khz"
|
||||
is updated at "package_*_die_*" level. This model will be still supported
|
||||
with the following approach:
|
||||
|
||||
When user uses controls at "package_*_die_*" level, then every fabric
|
||||
cluster is affected in that package and die. For example: user changes
|
||||
"max_freq_khz" in the package_00_die_00, then "max_freq_khz" for uncore*
|
||||
directory with the same package id will be updated. In this case user can
|
||||
still update "max_freq_khz" at each uncore* level, which is more restrictive.
|
||||
Similarly, user can update "min_freq_khz" at "package_*_die_*" level
|
||||
to apply at each uncore* level.
|
||||
|
||||
Support for "current_freq_khz" is available only at each fabric cluster
|
||||
level (i.e., in uncore* directory).
|
||||
|
||||
124
Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
Normal file
124
Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
Normal file
@ -0,0 +1,124 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/ata/rockchip,dwc-ahci.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Synopsys DWC AHCI SATA controller for Rockchip devices
|
||||
|
||||
maintainers:
|
||||
- Serge Semin <fancer.lancer@gmail.com>
|
||||
|
||||
description:
|
||||
This document defines device tree bindings for the Synopsys DWC
|
||||
implementation of the AHCI SATA controller found in Rockchip
|
||||
devices.
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- rockchip,rk3568-dwc-ahci
|
||||
- rockchip,rk3588-dwc-ahci
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- rockchip,rk3568-dwc-ahci
|
||||
- rockchip,rk3588-dwc-ahci
|
||||
- const: snps,dwc-ahci
|
||||
|
||||
ports-implemented:
|
||||
const: 1
|
||||
|
||||
sata-port@0:
|
||||
$ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
patternProperties:
|
||||
"^sata-port@[1-9a-e]$": false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- ports-implemented
|
||||
|
||||
allOf:
|
||||
- $ref: snps,dwc-ahci-common.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- rockchip,rk3588-dwc-ahci
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 5
|
||||
clock-names:
|
||||
items:
|
||||
- const: sata
|
||||
- const: pmalive
|
||||
- const: rxoob
|
||||
- const: ref
|
||||
- const: asic
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- rockchip,rk3568-dwc-ahci
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 3
|
||||
clock-names:
|
||||
items:
|
||||
- const: sata
|
||||
- const: pmalive
|
||||
- const: rxoob
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/rockchip,rk3588-cru.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/ata/ahci.h>
|
||||
#include <dt-bindings/phy/phy.h>
|
||||
|
||||
sata@fe210000 {
|
||||
compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci";
|
||||
reg = <0xfe210000 0x1000>;
|
||||
clocks = <&cru ACLK_SATA0>, <&cru CLK_PMALIVE0>,
|
||||
<&cru CLK_RXOOB0>, <&cru CLK_PIPEPHY0_REF>,
|
||||
<&cru CLK_PIPEPHY0_PIPE_ASIC_G>;
|
||||
clock-names = "sata", "pmalive", "rxoob", "ref", "asic";
|
||||
interrupts = <GIC_SPI 273 IRQ_TYPE_LEVEL_HIGH 0>;
|
||||
ports-implemented = <0x1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sata-port@0 {
|
||||
reg = <0>;
|
||||
hba-port-cap = <HBA_PORT_FBSCP>;
|
||||
phys = <&combphy0_ps PHY_TYPE_SATA>;
|
||||
phy-names = "sata-phy";
|
||||
snps,rx-ts-max = <32>;
|
||||
snps,tx-ts-max = <32>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -31,11 +31,11 @@ properties:
|
||||
PM-alive clock, RxOOB detection clock, embedded PHYs reference (Rx/Tx)
|
||||
clock, etc.
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
maxItems: 6
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
maxItems: 6
|
||||
items:
|
||||
oneOf:
|
||||
- description: Application APB/AHB/AXI BIU clock
|
||||
@ -48,6 +48,10 @@ properties:
|
||||
const: pmalive
|
||||
- description: RxOOB detection clock
|
||||
const: rxoob
|
||||
- description: PHY Transmit Clock
|
||||
const: asic
|
||||
- description: PHY Receive Clock
|
||||
const: rbc
|
||||
- description: SATA Ports reference clock
|
||||
const: ref
|
||||
|
||||
|
||||
@ -13,6 +13,15 @@ description:
|
||||
This document defines device tree bindings for the generic Synopsys DWC
|
||||
implementation of the AHCI SATA controller.
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- snps,dwc-ahci
|
||||
- snps,spear-ahci
|
||||
required:
|
||||
- compatible
|
||||
|
||||
allOf:
|
||||
- $ref: snps,dwc-ahci-common.yaml#
|
||||
|
||||
@ -23,10 +32,6 @@ properties:
|
||||
const: snps,dwc-ahci
|
||||
- description: SPEAr1340 AHCI SATA device
|
||||
const: snps,spear-ahci
|
||||
- description: Rockhip RK3568 AHCI controller
|
||||
items:
|
||||
- const: rockchip,rk3568-dwc-ahci
|
||||
- const: snps,dwc-ahci
|
||||
|
||||
patternProperties:
|
||||
"^sata-port@[0-9a-e]$":
|
||||
|
||||
@ -24,12 +24,20 @@ properties:
|
||||
deprecated: true
|
||||
description: Kept only for ABI backward compatibility
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,ipq4019-qce
|
||||
- qcom,sm8150-qce
|
||||
- const: qcom,qce
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,ipq6018-qce
|
||||
- qcom,ipq8074-qce
|
||||
- qcom,msm8996-qce
|
||||
- qcom,qcm2290-qce
|
||||
- qcom,sdm845-qce
|
||||
- qcom,sm6115-qce
|
||||
- const: qcom,ipq4019-qce
|
||||
- const: qcom,qce
|
||||
|
||||
@ -46,16 +54,12 @@ properties:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: iface clocks register interface.
|
||||
- description: bus clocks data transfer interface.
|
||||
- description: core clocks rest of the crypto block.
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: iface
|
||||
- const: bus
|
||||
- const: core
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
iommus:
|
||||
minItems: 1
|
||||
@ -89,9 +93,37 @@ allOf:
|
||||
enum:
|
||||
- qcom,crypto-v5.1
|
||||
- qcom,crypto-v5.4
|
||||
- qcom,ipq4019-qce
|
||||
|
||||
- qcom,ipq6018-qce
|
||||
- qcom,ipq8074-qce
|
||||
- qcom,msm8996-qce
|
||||
- qcom,sdm845-qce
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 3
|
||||
clock-names:
|
||||
items:
|
||||
- const: iface
|
||||
- const: bus
|
||||
- const: core
|
||||
required:
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,qcm2290-qce
|
||||
- qcom,sm6115-qce
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 1
|
||||
clock-names:
|
||||
items:
|
||||
- const: core
|
||||
required:
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
@ -0,0 +1,70 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/starfive,jh7110-crypto.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: StarFive Cryptographic Module
|
||||
|
||||
maintainers:
|
||||
- Jia Jie Ho <jiajie.ho@starfivetech.com>
|
||||
- William Qiu <william.qiu@starfivetech.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: starfive,jh7110-crypto
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Hardware reference clock
|
||||
- description: AHB reference clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: hclk
|
||||
- const: ahb
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
dmas:
|
||||
items:
|
||||
- description: TX DMA channel
|
||||
- description: RX DMA channel
|
||||
|
||||
dma-names:
|
||||
items:
|
||||
- const: tx
|
||||
- const: rx
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- resets
|
||||
- dmas
|
||||
- dma-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
crypto: crypto@16000000 {
|
||||
compatible = "starfive,jh7110-crypto";
|
||||
reg = <0x16000000 0x4000>;
|
||||
clocks = <&clk 15>, <&clk 16>;
|
||||
clock-names = "hclk", "ahb";
|
||||
interrupts = <28>;
|
||||
resets = <&reset 3>;
|
||||
dmas = <&dma 1 2>,
|
||||
<&dma 0 2>;
|
||||
dma-names = "tx", "rx";
|
||||
};
|
||||
...
|
||||
@ -13,6 +13,7 @@ properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sdx55-pcie-ep
|
||||
- qcom,sdx65-pcie-ep
|
||||
- qcom,sm8450-pcie-ep
|
||||
|
||||
reg:
|
||||
@ -109,6 +110,7 @@ allOf:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sdx55-pcie-ep
|
||||
- qcom,sdx65-pcie-ep
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
|
||||
@ -47,7 +47,7 @@ examples:
|
||||
|
||||
pcie-ep@f8000000 {
|
||||
compatible = "rockchip,rk3399-pcie-ep";
|
||||
reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0x80000000 0x0 0x20000>;
|
||||
reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0xfa000000 0x0 0x2000000>;
|
||||
reg-names = "apb-base", "mem-base";
|
||||
clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
|
||||
<&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
|
||||
@ -63,6 +63,8 @@ examples:
|
||||
phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
|
||||
phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
|
||||
rockchip,max-outbound-regions = <16>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pcie_clkreqnb_cpm>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
||||
@ -31,8 +31,14 @@ properties:
|
||||
- const: pipe
|
||||
|
||||
resets:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
reset-names:
|
||||
minItems: 1
|
||||
items:
|
||||
- description: exclusive PHY reset line
|
||||
- const: phy
|
||||
- const: apb
|
||||
|
||||
rockchip,enable-ssc:
|
||||
type: boolean
|
||||
@ -78,6 +84,32 @@ required:
|
||||
- rockchip,pipe-phy-grf
|
||||
- "#phy-cells"
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: rockchip,rk3568-naneng-combphy
|
||||
then:
|
||||
properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
reset-names:
|
||||
maxItems: 1
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: rockchip,rk3588-naneng-combphy
|
||||
then:
|
||||
properties:
|
||||
resets:
|
||||
minItems: 2
|
||||
reset-names:
|
||||
minItems: 2
|
||||
required:
|
||||
- reset-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
@ -37,7 +37,8 @@ right representation of the pin.
|
||||
Optional properties:
|
||||
- GENERIC_PINCONFIG: generic pinconfig options to use:
|
||||
- bias-disable, bias-pull-down, bias-pull-up, drive-open-drain,
|
||||
input-schmitt-enable, input-debounce, output-low, output-high.
|
||||
drive-push-pull input-schmitt-enable, input-debounce, output-low,
|
||||
output-high.
|
||||
- for microchip,sama7g5-pinctrl only:
|
||||
- slew-rate: 0 - disabled, 1 - enabled (default)
|
||||
- atmel,drive-strength: 0 or 1 for low drive, 2 for medium drive and 3 for
|
||||
|
||||
@ -0,0 +1,78 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-aon.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVIDIA Tegra234 AON Pinmux Controller
|
||||
|
||||
maintainers:
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
- Jon Hunter <jonathanh@nvidia.com>
|
||||
|
||||
$ref: nvidia,tegra234-pinmux-common.yaml
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: nvidia,tegra234-pinmux-aon
|
||||
|
||||
patternProperties:
|
||||
"^pinmux(-[a-z0-9-]+)?$":
|
||||
type: object
|
||||
|
||||
# pin groups
|
||||
additionalProperties:
|
||||
properties:
|
||||
nvidia,pins:
|
||||
items:
|
||||
enum: [ can0_dout_paa0, can0_din_paa1, can1_dout_paa2,
|
||||
can1_din_paa3, can0_stb_paa4, can0_en_paa5,
|
||||
soc_gpio49_paa6, can0_err_paa7, can1_stb_pbb0,
|
||||
can1_en_pbb1, soc_gpio50_pbb2, can1_err_pbb3,
|
||||
spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
|
||||
spi2_cs0_pcc3, touch_clk_pcc4, uart3_tx_pcc5,
|
||||
uart3_rx_pcc6, gen2_i2c_scl_pcc7, gen2_i2c_sda_pdd0,
|
||||
gen8_i2c_scl_pdd1, gen8_i2c_sda_pdd2,
|
||||
sce_error_pee0, vcomp_alert_pee1,
|
||||
ao_retention_n_pee2, batt_oc_pee3, power_on_pee4,
|
||||
soc_gpio26_pee5, soc_gpio27_pee6, bootv_ctl_n_pee7,
|
||||
hdmi_cec_pgg0,
|
||||
# drive groups
|
||||
drive_touch_clk_pcc4, drive_uart3_rx_pcc6,
|
||||
drive_uart3_tx_pcc5, drive_gen8_i2c_sda_pdd2,
|
||||
drive_gen8_i2c_scl_pdd1, drive_spi2_mosi_pcc2,
|
||||
drive_gen2_i2c_scl_pcc7, drive_spi2_cs0_pcc3,
|
||||
drive_gen2_i2c_sda_pdd0, drive_spi2_sck_pcc0,
|
||||
drive_spi2_miso_pcc1, drive_can1_dout_paa2,
|
||||
drive_can1_din_paa3, drive_can0_dout_paa0,
|
||||
drive_can0_din_paa1, drive_can0_stb_paa4,
|
||||
drive_can0_en_paa5, drive_soc_gpio49_paa6,
|
||||
drive_can0_err_paa7, drive_can1_stb_pbb0,
|
||||
drive_can1_en_pbb1, drive_soc_gpio50_pbb2,
|
||||
drive_can1_err_pbb3, drive_sce_error_pee0,
|
||||
drive_batt_oc_pee3, drive_bootv_ctl_n_pee7,
|
||||
drive_power_on_pee4, drive_soc_gpio26_pee5,
|
||||
drive_soc_gpio27_pee6, drive_ao_retention_n_pee2,
|
||||
drive_vcomp_alert_pee1, drive_hdmi_cec_pgg0 ]
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
|
||||
|
||||
pinmux@c300000 {
|
||||
compatible = "nvidia,tegra234-pinmux-aon";
|
||||
reg = <0xc300000 0x4000>;
|
||||
|
||||
pinctrl-names = "cec";
|
||||
pinctrl-0 = <&cec_state>;
|
||||
|
||||
cec_state: pinmux-cec {
|
||||
cec {
|
||||
nvidia,pins = "hdmi_cec_pgg0";
|
||||
nvidia,function = "gp";
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@ -0,0 +1,66 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-common.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVIDIA Tegra234 Pinmux Controller
|
||||
|
||||
maintainers:
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
- Jon Hunter <jonathanh@nvidia.com>
|
||||
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- description: pinmux registers
|
||||
|
||||
patternProperties:
|
||||
"^pinmux(-[a-z0-9-]+)?$":
|
||||
type: object
|
||||
|
||||
# pin groups
|
||||
additionalProperties:
|
||||
$ref: nvidia,tegra-pinmux-common.yaml
|
||||
# We would typically use unevaluatedProperties here but that has the
|
||||
# downside that all the properties in the common bindings become valid
|
||||
# for all chip generations. In this case, however, we want the per-SoC
|
||||
# bindings to be able to override which of the common properties are
|
||||
# allowed, since not all pinmux generations support the same sets of
|
||||
# properties. This way, the common bindings define the format of the
|
||||
# properties but the per-SoC bindings define which of them apply to a
|
||||
# given chip.
|
||||
additionalProperties: false
|
||||
properties:
|
||||
nvidia,function:
|
||||
enum: [ gp, uartc, i2c8, spi2, i2c2, can1, can0, rsvd0, eth0, eth2,
|
||||
eth1, dp, eth3, i2c4, i2c7, i2c9, eqos, pe2, pe1, pe0, pe3,
|
||||
pe4, pe5, pe6, pe7, pe8, pe9, pe10, qspi0, qspi1, qpsi,
|
||||
sdmmc1, sce, soc, gpio, hdmi, ufs0, spi3, spi1, uartb, uarte,
|
||||
usb, extperiph2, extperiph1, i2c3, vi0, i2c5, uarta, uartd,
|
||||
i2c1, i2s4, i2s6, aud, spi5, touch, uartj, rsvd1, wdt, tsc,
|
||||
dmic3, led, vi0_alt, i2s5, nv, extperiph3, extperiph4, spi4,
|
||||
ccla, i2s1, i2s2, i2s3, i2s8, rsvd2, dmic5, dca, displayb,
|
||||
displaya, vi1, dcb, dmic1, dmic4, i2s7, dmic2, dspk0, rsvd3,
|
||||
tsc_alt, istctrl, vi1_alt, dspk1, igpu ]
|
||||
|
||||
# out of the common properties, only these are allowed for Tegra234
|
||||
nvidia,pins: true
|
||||
nvidia,pull: true
|
||||
nvidia,tristate: true
|
||||
nvidia,schmitt: true
|
||||
nvidia,enable-input: true
|
||||
nvidia,open-drain: true
|
||||
nvidia,lock: true
|
||||
nvidia,drive-type: true
|
||||
nvidia,io-hv: true
|
||||
|
||||
required:
|
||||
- nvidia,pins
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: true
|
||||
...
|
||||
@ -0,0 +1,139 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVIDIA Tegra234 Pinmux Controller
|
||||
|
||||
maintainers:
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
- Jon Hunter <jonathanh@nvidia.com>
|
||||
|
||||
$ref: nvidia,tegra234-pinmux-common.yaml
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: nvidia,tegra234-pinmux
|
||||
|
||||
patternProperties:
|
||||
"^pinmux(-[a-z0-9-]+)?$":
|
||||
type: object
|
||||
|
||||
# pin groups
|
||||
additionalProperties:
|
||||
properties:
|
||||
nvidia,pins:
|
||||
items:
|
||||
enum: [ dap6_sclk_pa0, dap6_dout_pa1, dap6_din_pa2,
|
||||
dap6_fs_pa3, dap4_sclk_pa4, dap4_dout_pa5,
|
||||
dap4_din_pa6, dap4_fs_pa7, soc_gpio08_pb0,
|
||||
qspi0_sck_pc0, qspi0_cs_n_pc1,
|
||||
qspi0_io0_pc2, qspi0_io1_pc3, qspi0_io2_pc4,
|
||||
qspi0_io3_pc5, qspi1_sck_pc6, qspi1_cs_n_pc7,
|
||||
qspi1_io0_pd0, qspi1_io1_pd1, qspi1_io2_pd2,
|
||||
qspi1_io3_pd3, eqos_txc_pe0, eqos_td0_pe1,
|
||||
eqos_td1_pe2, eqos_td2_pe3, eqos_td3_pe4,
|
||||
eqos_tx_ctl_pe5, eqos_rd0_pe6, eqos_rd1_pe7,
|
||||
eqos_rd2_pf0, eqos_rd3_pf1, eqos_rx_ctl_pf2,
|
||||
eqos_rxc_pf3, eqos_sma_mdio_pf4, eqos_sma_mdc_pf5,
|
||||
soc_gpio13_pg0, soc_gpio14_pg1, soc_gpio15_pg2,
|
||||
soc_gpio16_pg3, soc_gpio17_pg4, soc_gpio18_pg5,
|
||||
soc_gpio19_pg6, soc_gpio20_pg7, soc_gpio21_ph0,
|
||||
soc_gpio22_ph1, soc_gpio06_ph2, uart4_tx_ph3,
|
||||
uart4_rx_ph4, uart4_rts_ph5, uart4_cts_ph6,
|
||||
soc_gpio41_ph7, soc_gpio42_pi0, soc_gpio43_pi1,
|
||||
soc_gpio44_pi2, gen1_i2c_scl_pi3, gen1_i2c_sda_pi4,
|
||||
cpu_pwr_req_pi5, soc_gpio07_pi6,
|
||||
sdmmc1_clk_pj0, sdmmc1_cmd_pj1, sdmmc1_dat0_pj2,
|
||||
sdmmc1_dat1_pj3, sdmmc1_dat2_pj4, sdmmc1_dat3_pj5,
|
||||
pex_l0_clkreq_n_pk0, pex_l0_rst_n_pk1,
|
||||
pex_l1_clkreq_n_pk2, pex_l1_rst_n_pk3,
|
||||
pex_l2_clkreq_n_pk4, pex_l2_rst_n_pk5,
|
||||
pex_l3_clkreq_n_pk6, pex_l3_rst_n_pk7,
|
||||
pex_l4_clkreq_n_pl0, pex_l4_rst_n_pl1,
|
||||
pex_wake_n_pl2, soc_gpio34_pl3, dp_aux_ch0_hpd_pm0,
|
||||
dp_aux_ch1_hpd_pm1, dp_aux_ch2_hpd_pm2,
|
||||
dp_aux_ch3_hpd_pm3, soc_gpio55_pm4, soc_gpio36_pm5,
|
||||
soc_gpio53_pm6, soc_gpio38_pm7, dp_aux_ch3_n_pn0,
|
||||
soc_gpio39_pn1, soc_gpio40_pn2, dp_aux_ch1_p_pn3,
|
||||
dp_aux_ch1_n_pn4, dp_aux_ch2_p_pn5, dp_aux_ch2_n_pn6,
|
||||
dp_aux_ch3_p_pn7, extperiph1_clk_pp0,
|
||||
extperiph2_clk_pp1, cam_i2c_scl_pp2, cam_i2c_sda_pp3,
|
||||
soc_gpio23_pp4, soc_gpio24_pp5, soc_gpio25_pp6,
|
||||
pwr_i2c_scl_pp7, pwr_i2c_sda_pq0, soc_gpio28_pq1,
|
||||
soc_gpio29_pq2, soc_gpio30_pq3, soc_gpio31_pq4,
|
||||
soc_gpio32_pq5, soc_gpio33_pq6, soc_gpio35_pq7,
|
||||
soc_gpio37_pr0, soc_gpio56_pr1, uart1_tx_pr2,
|
||||
uart1_rx_pr3, uart1_rts_pr4, uart1_cts_pr5,
|
||||
soc_gpio61_pw0, soc_gpio62_pw1, gpu_pwr_req_px0,
|
||||
cv_pwr_req_px1, gp_pwm2_px2, gp_pwm3_px3, uart2_tx_px4,
|
||||
uart2_rx_px5, uart2_rts_px6, uart2_cts_px7, spi3_sck_py0,
|
||||
spi3_miso_py1, spi3_mosi_py2, spi3_cs0_py3,
|
||||
spi3_cs1_py4, uart5_tx_py5, uart5_rx_py6,
|
||||
uart5_rts_py7, uart5_cts_pz0, usb_vbus_en0_pz1,
|
||||
usb_vbus_en1_pz2, spi1_sck_pz3, spi1_miso_pz4,
|
||||
spi1_mosi_pz5, spi1_cs0_pz6, spi1_cs1_pz7,
|
||||
spi5_sck_pac0, spi5_miso_pac1, spi5_mosi_pac2,
|
||||
spi5_cs0_pac3, soc_gpio57_pac4, soc_gpio58_pac5,
|
||||
soc_gpio59_pac6, soc_gpio60_pac7, soc_gpio45_pad0,
|
||||
soc_gpio46_pad1, soc_gpio47_pad2, soc_gpio48_pad3,
|
||||
ufs0_ref_clk_pae0, ufs0_rst_n_pae1,
|
||||
pex_l5_clkreq_n_paf0, pex_l5_rst_n_paf1,
|
||||
pex_l6_clkreq_n_paf2, pex_l6_rst_n_paf3,
|
||||
pex_l7_clkreq_n_pag0, pex_l7_rst_n_pag1,
|
||||
pex_l8_clkreq_n_pag2, pex_l8_rst_n_pag3,
|
||||
pex_l9_clkreq_n_pag4, pex_l9_rst_n_pag5,
|
||||
pex_l10_clkreq_n_pag6, pex_l10_rst_n_pag7,
|
||||
sdmmc1_comp, eqos_comp, qspi_comp,
|
||||
# drive groups
|
||||
drive_soc_gpio08_pb0, drive_soc_gpio36_pm5,
|
||||
drive_soc_gpio53_pm6, drive_soc_gpio55_pm4,
|
||||
drive_soc_gpio38_pm7, drive_soc_gpio39_pn1,
|
||||
drive_soc_gpio40_pn2, drive_dp_aux_ch0_hpd_pm0,
|
||||
drive_dp_aux_ch1_hpd_pm1, drive_dp_aux_ch2_hpd_pm2,
|
||||
drive_dp_aux_ch3_hpd_pm3, drive_dp_aux_ch1_p_pn3,
|
||||
drive_dp_aux_ch1_n_pn4, drive_dp_aux_ch2_p_pn5,
|
||||
drive_dp_aux_ch2_n_pn6, drive_dp_aux_ch3_p_pn7,
|
||||
drive_dp_aux_ch3_n_pn0, drive_pex_l2_clkreq_n_pk4,
|
||||
drive_pex_wake_n_pl2, drive_pex_l1_clkreq_n_pk2,
|
||||
drive_pex_l1_rst_n_pk3, drive_pex_l0_clkreq_n_pk0,
|
||||
drive_pex_l0_rst_n_pk1, drive_pex_l2_rst_n_pk5,
|
||||
drive_pex_l3_clkreq_n_pk6, drive_pex_l3_rst_n_pk7,
|
||||
drive_pex_l4_clkreq_n_pl0, drive_pex_l4_rst_n_pl1,
|
||||
drive_soc_gpio34_pl3, drive_pex_l5_clkreq_n_paf0,
|
||||
drive_pex_l5_rst_n_paf1, drive_pex_l6_clkreq_n_paf2,
|
||||
drive_pex_l6_rst_n_paf3, drive_pex_l10_clkreq_n_pag6,
|
||||
drive_pex_l10_rst_n_pag7, drive_pex_l7_clkreq_n_pag0,
|
||||
drive_pex_l7_rst_n_pag1, drive_pex_l8_clkreq_n_pag2,
|
||||
drive_pex_l8_rst_n_pag3, drive_pex_l9_clkreq_n_pag4,
|
||||
drive_pex_l9_rst_n_pag5, drive_sdmmc1_clk_pj0,
|
||||
drive_sdmmc1_cmd_pj1, drive_sdmmc1_dat3_pj5,
|
||||
drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3,
|
||||
drive_sdmmc1_dat0_pj2 ]
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
|
||||
|
||||
pinmux@2430000 {
|
||||
compatible = "nvidia,tegra234-pinmux";
|
||||
reg = <0x2430000 0x17000>;
|
||||
|
||||
pinctrl-names = "pex_rst";
|
||||
pinctrl-0 = <&pex_rst_c5_out_state>;
|
||||
|
||||
pex_rst_c5_out_state: pinmux-pex-rst-c5-out {
|
||||
pexrst {
|
||||
nvidia,pins = "pex_l5_rst_n_paf1";
|
||||
nvidia,schmitt = <TEGRA_PIN_DISABLE>;
|
||||
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
|
||||
nvidia,io-hv = <TEGRA_PIN_ENABLE>;
|
||||
nvidia,tristate = <TEGRA_PIN_DISABLE>;
|
||||
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
127
Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml
Normal file
127
Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml
Normal file
@ -0,0 +1,127 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5018-tlmm.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm IPQ5018 TLMM pin controller
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
||||
|
||||
description:
|
||||
Top Level Mode Multiplexer pin controller in Qualcomm IPQ5018 SoC.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,ipq5018-tlmm
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
interrupt-controller: true
|
||||
"#interrupt-cells": true
|
||||
gpio-controller: true
|
||||
"#gpio-cells": true
|
||||
gpio-ranges: true
|
||||
wakeup-parent: true
|
||||
|
||||
gpio-reserved-ranges:
|
||||
minItems: 1
|
||||
maxItems: 24
|
||||
|
||||
gpio-line-names:
|
||||
maxItems: 47
|
||||
|
||||
patternProperties:
|
||||
"-state$":
|
||||
oneOf:
|
||||
- $ref: "#/$defs/qcom-ipq5018-tlmm-state"
|
||||
- patternProperties:
|
||||
"-pins$":
|
||||
$ref: "#/$defs/qcom-ipq5018-tlmm-state"
|
||||
additionalProperties: false
|
||||
|
||||
$defs:
|
||||
qcom-ipq5018-tlmm-state:
|
||||
type: object
|
||||
description:
|
||||
Pinctrl node's client devices use subnodes for desired pin configuration.
|
||||
Client device subnodes use below standard properties.
|
||||
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
pins:
|
||||
description:
|
||||
List of gpio pins affected by the properties specified in this
|
||||
subnode.
|
||||
items:
|
||||
pattern: "^gpio([0-9]|[1-3][0-9]|4[0-6])$"
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
|
||||
function:
|
||||
description:
|
||||
Specify the alternative function to be configured for the specified
|
||||
pins.
|
||||
|
||||
enum: [ atest_char, audio_pdm0, audio_pdm1, audio_rxbclk, audio_rxd,
|
||||
audio_rxfsync, audio_rxmclk, audio_txbclk, audio_txd,
|
||||
audio_txfsync, audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart0,
|
||||
blsp0_uart1, blsp1_i2c0, blsp1_i2c1, blsp1_spi0, blsp1_spi1,
|
||||
blsp1_uart0, blsp1_uart1, blsp1_uart2, blsp2_i2c0, blsp2_i2c1,
|
||||
blsp2_spi, blsp2_spi0, blsp2_spi1, btss, burn0, burn1, cri_trng,
|
||||
cri_trng0, cri_trng1, cxc_clk, cxc_data, dbg_out, eud_gpio,
|
||||
gcc_plltest, gcc_tlmm, gpio, led0, led2, mac0, mac1, mdc, mdio,
|
||||
pcie0_clk, pcie0_wake, pcie1_clk, pcie1_wake, pll_test,
|
||||
prng_rosc, pwm0, pwm1, pwm2, pwm3, qdss_cti_trig_in_a0,
|
||||
qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, qdss_cti_trig_in_b1,
|
||||
qdss_cti_trig_out_a0, qdss_cti_trig_out_a1,
|
||||
qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a,
|
||||
qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
|
||||
qdss_tracedata_a, qdss_tracedata_b, qspi_clk, qspi_cs,
|
||||
qspi_data, reset_out, sdc1_clk, sdc1_cmd, sdc1_data, wci_txd,
|
||||
wci_rxd, wsa_swrm, wsi_clk3, wsi_data3, wsis_reset, xfem ]
|
||||
|
||||
required:
|
||||
- pins
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
tlmm: pinctrl@1000000 {
|
||||
compatible = "qcom,ipq5018-tlmm";
|
||||
reg = <0x01000000 0x300000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-ranges = <&tlmm 0 0 47>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
uart-w-state {
|
||||
rx-pins {
|
||||
pins = "gpio33";
|
||||
function = "blsp1_uart1";
|
||||
bias-pull-down;
|
||||
};
|
||||
|
||||
tx-pins {
|
||||
pins = "gpio34";
|
||||
function = "blsp1_uart1";
|
||||
bias-pull-down;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@ -53,6 +53,7 @@ $defs:
|
||||
Pinctrl node's client devices use subnodes for desired pin configuration.
|
||||
Client device subnodes use below standard properties.
|
||||
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
pins:
|
||||
@ -86,19 +87,9 @@ $defs:
|
||||
rx0, rx1, sdc_clk, sdc_cmd, sdc_data, sdc_rclk, tsens_max,
|
||||
wci20, wci21, wsa_swrm ]
|
||||
|
||||
bias-pull-down: true
|
||||
bias-pull-up: true
|
||||
bias-disable: true
|
||||
drive-strength: true
|
||||
input-enable: true
|
||||
output-high: true
|
||||
output-low: true
|
||||
|
||||
required:
|
||||
- pins
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
|
||||
|
||||
|
||||
@ -49,6 +49,7 @@ properties:
|
||||
- qcom,pm8921-gpio
|
||||
- qcom,pm8941-gpio
|
||||
- qcom,pm8950-gpio
|
||||
- qcom,pm8953-gpio
|
||||
- qcom,pm8994-gpio
|
||||
- qcom,pm8998-gpio
|
||||
- qcom,pma8084-gpio
|
||||
@ -175,6 +176,7 @@ allOf:
|
||||
- qcom,pm8350b-gpio
|
||||
- qcom,pm8550ve-gpio
|
||||
- qcom,pm8950-gpio
|
||||
- qcom,pm8953-gpio
|
||||
- qcom,pmi632-gpio
|
||||
then:
|
||||
properties:
|
||||
@ -434,6 +436,7 @@ $defs:
|
||||
- gpio1-gpio44 for pm8921
|
||||
- gpio1-gpio36 for pm8941
|
||||
- gpio1-gpio8 for pm8950 (hole on gpio3)
|
||||
- gpio1-gpio8 for pm8953 (hole on gpio3 and gpio6)
|
||||
- gpio1-gpio22 for pm8994
|
||||
- gpio1-gpio26 for pm8998
|
||||
- gpio1-gpio22 for pma8084
|
||||
|
||||
@ -45,6 +45,7 @@ $defs:
|
||||
Pinctrl node's client devices use subnodes for desired pin configuration.
|
||||
Client device subnodes use below standard properties.
|
||||
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
pins:
|
||||
@ -81,19 +82,9 @@ $defs:
|
||||
uim2_data, uim2_present, uim2_reset, usb_phy, vfr_1,
|
||||
vsense_trigger, wlan1_adc0, wlan1_adc1 ]
|
||||
|
||||
bias-pull-down: true
|
||||
bias-pull-up: true
|
||||
bias-disable: true
|
||||
drive-strength: true
|
||||
input-enable: true
|
||||
output-high: true
|
||||
output-low: true
|
||||
|
||||
required:
|
||||
- pins
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
|
||||
|
||||
|
||||
@ -55,6 +55,7 @@ $defs:
|
||||
Pinctrl node's client devices use subnodes for desired pin configuration.
|
||||
Client device subnodes use below standard properties.
|
||||
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
pins:
|
||||
@ -104,20 +105,9 @@ $defs:
|
||||
usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac,
|
||||
vsense_trigger ]
|
||||
|
||||
bias-bus-hold: true
|
||||
bias-disable: true
|
||||
bias-pull-down: true
|
||||
bias-pull-up: true
|
||||
drive-strength: true
|
||||
input-enable: true
|
||||
output-high: true
|
||||
output-low: true
|
||||
|
||||
required:
|
||||
- pins
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
@ -85,7 +85,7 @@ $defs:
|
||||
qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14,
|
||||
dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem,
|
||||
dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto,
|
||||
dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0,
|
||||
dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, pcie_clkreq,
|
||||
dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25,
|
||||
sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2,
|
||||
qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3,
|
||||
|
||||
137
Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml
Normal file
137
Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml
Normal file
@ -0,0 +1,137 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/pinctrl/qcom,sdx75-tlmm.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Technologies, Inc. SDX75 TLMM block
|
||||
|
||||
maintainers:
|
||||
- Rohit Agarwal <quic_rohiagar@quicinc.com>
|
||||
|
||||
description:
|
||||
Top Level Mode Multiplexer pin controller in Qualcomm SDX75 SoC.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sdx75-tlmm
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts: true
|
||||
interrupt-controller: true
|
||||
"#interrupt-cells": true
|
||||
gpio-controller: true
|
||||
|
||||
gpio-reserved-ranges:
|
||||
minItems: 1
|
||||
maxItems: 67
|
||||
|
||||
gpio-line-names:
|
||||
maxItems: 133
|
||||
|
||||
"#gpio-cells": true
|
||||
gpio-ranges: true
|
||||
wakeup-parent: true
|
||||
|
||||
patternProperties:
|
||||
"-state$":
|
||||
oneOf:
|
||||
- $ref: "#/$defs/qcom-sdx75-tlmm-state"
|
||||
- patternProperties:
|
||||
"-pins$":
|
||||
$ref: "#/$defs/qcom-sdx75-tlmm-state"
|
||||
additionalProperties: false
|
||||
|
||||
$defs:
|
||||
qcom-sdx75-tlmm-state:
|
||||
type: object
|
||||
description:
|
||||
Pinctrl node's client devices use subnodes for desired pin configuration.
|
||||
Client device subnodes use below standard properties.
|
||||
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
pins:
|
||||
description:
|
||||
List of gpio pins affected by the properties specified in this
|
||||
subnode.
|
||||
items:
|
||||
oneOf:
|
||||
- pattern: "^gpio([0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2])$"
|
||||
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk, sdc2_cmd, sdc2_data ]
|
||||
minItems: 1
|
||||
maxItems: 36
|
||||
|
||||
function:
|
||||
description:
|
||||
Specify the alternative function to be configured for the specified
|
||||
pins.
|
||||
enum: [ adsp_ext, atest_char, audio_ref_clk, bimc_dte, char_exec, coex_uart2,
|
||||
coex_uart, cri_trng, cri_trng0, cri_trng1, dbg_out_clk, ddr_bist,
|
||||
ddr_pxi0, ebi0_wrcdc, ebi2_a, ebi2_lcd, ebi2_lcd_te, emac0_mcg,
|
||||
emac0_ptp, emac1_mcg, emac1_ptp, emac_cdc, emac_pps_in, eth0_mdc,
|
||||
eth0_mdio, eth1_mdc, eth1_mdio, ext_dbg, gcc_125_clk, gcc_gp1_clk,
|
||||
gcc_gp2_clk, gcc_gp3_clk, gcc_plltest, gpio, i2s_mclk, jitter_bist,
|
||||
ldo_en, ldo_update, m_voc, mgpi_clk, native_char, native_tsens,
|
||||
native_tsense, nav_dr_sync, nav_gpio, pa_indicator, pci_e,
|
||||
pcie0_clkreq_n, pcie1_clkreq_n, pcie2_clkreq_n, pll_bist_sync,
|
||||
pll_clk_aux, pll_ref_clk, pri_mi2s, prng_rosc, qdss_cti, qdss_gpio,
|
||||
qlink0_b_en, qlink0_b_req, qlink0_l_en, qlink0_l_req, qlink0_wmss,
|
||||
qlink1_l_en, qlink1_l_req, qlink1_wmss, qup_se0, qup_se1_l2_mira,
|
||||
qup_se1_l2_mirb, qup_se1_l3_mira, qup_se1_l3_mirb, qup_se2, qup_se3,
|
||||
qup_se4, qup_se5, qup_se6, qup_se7, qup_se8, rgmii_rx_ctl, rgmii_rxc,
|
||||
rgmii_rxd, rgmii_tx_ctl, rgmii_txc, rgmii_txd, sd_card, sdc1_tb,
|
||||
sdc2_tb_trig, sec_mi2s, sgmii_phy_intr0_n, sgmii_phy_intr1_n,
|
||||
spmi_coex, spmi_vgi, tgu_ch0_trigout, tmess_prng0, tmess_prng1,
|
||||
tmess_prng2, tmess_prng3, tri_mi2s, uim1_clk, uim1_data, uim1_present,
|
||||
uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset,
|
||||
usb2phy_ac_en, vsense_trigger_mirnat]
|
||||
|
||||
required:
|
||||
- pins
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
tlmm: pinctrl@f100000 {
|
||||
compatible = "qcom,sdx75-tlmm";
|
||||
reg = <0x0f100000 0x300000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-ranges = <&tlmm 0 0 133>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
gpio-wo-state {
|
||||
pins = "gpio1";
|
||||
function = "gpio";
|
||||
};
|
||||
|
||||
uart-w-state {
|
||||
rx-pins {
|
||||
pins = "gpio12";
|
||||
function = "qup_se1_l2_mira";
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
tx-pins {
|
||||
pins = "gpio13";
|
||||
function = "qup_se1_l3_mira";
|
||||
bias-disable;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@ -62,6 +62,7 @@ $defs:
|
||||
Pinctrl node's client devices use subnodes for desired pin configuration.
|
||||
Client device subnodes use below standard properties.
|
||||
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
pins:
|
||||
@ -102,19 +103,9 @@ $defs:
|
||||
wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk,
|
||||
wsa_data ]
|
||||
|
||||
bias-pull-down: true
|
||||
bias-pull-up: true
|
||||
bias-disable: true
|
||||
drive-strength: true
|
||||
input-enable: true
|
||||
output-high: true
|
||||
output-low: true
|
||||
|
||||
required:
|
||||
- pins
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -23,6 +23,9 @@ description: |
|
||||
two cores, each of which has two hyperthreads, could be described as
|
||||
having four harts.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/cpu.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
@ -61,7 +64,7 @@ properties:
|
||||
hart. These values originate from the RISC-V Privileged
|
||||
Specification document, available from
|
||||
https://riscv.org/specifications/
|
||||
$ref: "/schemas/types.yaml#/definitions/string"
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
enum:
|
||||
- riscv,sv32
|
||||
- riscv,sv39
|
||||
@ -89,15 +92,18 @@ properties:
|
||||
Due to revisions of the ISA specification, some deviations
|
||||
have arisen over time.
|
||||
Notably, riscv,isa was defined prior to the creation of the
|
||||
Zicsr and Zifencei extensions and thus "i" implies
|
||||
"zicsr_zifencei".
|
||||
Zicntr, Zicsr, Zifencei and Zihpm extensions and thus "i"
|
||||
implies "zicntr_zicsr_zifencei_zihpm".
|
||||
|
||||
While the isa strings in ISA specification are case
|
||||
insensitive, letters in the riscv,isa string must be all
|
||||
lowercase to simplify parsing.
|
||||
$ref: "/schemas/types.yaml#/definitions/string"
|
||||
lowercase.
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
|
||||
|
||||
# RISC-V has multiple properties for cache op block sizes as the sizes
|
||||
# differ between individual CBO extensions
|
||||
cache-op-block-size: false
|
||||
# RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
|
||||
timebase-frequency: false
|
||||
|
||||
@ -120,7 +126,7 @@ properties:
|
||||
- interrupt-controller
|
||||
|
||||
cpu-idle-states:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
items:
|
||||
maxItems: 1
|
||||
description: |
|
||||
@ -137,7 +143,7 @@ required:
|
||||
- riscv,isa
|
||||
- interrupt-controller
|
||||
|
||||
additionalProperties: true
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
@ -26,6 +26,7 @@ properties:
|
||||
- qcom,msm8994-ufshc
|
||||
- qcom,msm8996-ufshc
|
||||
- qcom,msm8998-ufshc
|
||||
- qcom,sa8775p-ufshc
|
||||
- qcom,sc8280xp-ufshc
|
||||
- qcom,sdm845-ufshc
|
||||
- qcom,sm6350-ufshc
|
||||
@ -70,6 +71,10 @@ properties:
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
qcom,ice:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the Inline Crypto Engine node
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
@ -105,6 +110,7 @@ allOf:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,msm8998-ufshc
|
||||
- qcom,sa8775p-ufshc
|
||||
- qcom,sc8280xp-ufshc
|
||||
- qcom,sm8250-ufshc
|
||||
- qcom,sm8350-ufshc
|
||||
@ -187,6 +193,26 @@ allOf:
|
||||
|
||||
# TODO: define clock bindings for qcom,msm8994-ufshc
|
||||
|
||||
- if:
|
||||
properties:
|
||||
qcom,ice:
|
||||
maxItems: 1
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
clocks:
|
||||
minItems: 8
|
||||
maxItems: 8
|
||||
else:
|
||||
properties:
|
||||
reg:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
clocks:
|
||||
minItems: 9
|
||||
maxItems: 11
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
@ -54,7 +54,7 @@ properties:
|
||||
const: ufs-phy
|
||||
|
||||
samsung,sysreg:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description: Should be phandle/offset pair. The phandle to the syscon node
|
||||
which indicates the FSYSx sysreg interface and the offset of
|
||||
the control register for UFS io coherency setting.
|
||||
|
||||
@ -113,6 +113,7 @@ available subsections can be seen below.
|
||||
xillybus
|
||||
zorro
|
||||
hte/index
|
||||
wmi
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
||||
21
Documentation/driver-api/wmi.rst
Normal file
21
Documentation/driver-api/wmi.rst
Normal file
@ -0,0 +1,21 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
==============
|
||||
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.
|
||||
|
||||
.. kernel-doc:: include/linux/wmi.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/platform/x86/wmi.c
|
||||
:export:
|
||||
@ -13,7 +13,7 @@
|
||||
| csky: | ok |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
| loongarch: | TODO |
|
||||
| loongarch: | ok |
|
||||
| m68k: | TODO |
|
||||
| microblaze: | TODO |
|
||||
| mips: | ok |
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
| csky: | ok |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
| loongarch: | TODO |
|
||||
| loongarch: | ok |
|
||||
| m68k: | TODO |
|
||||
| microblaze: | ok |
|
||||
| mips: | ok |
|
||||
|
||||
@ -46,7 +46,7 @@ Supported adapters:
|
||||
* Intel Emmitsburg (PCH)
|
||||
* Intel Alder Lake (PCH)
|
||||
* Intel Raptor Lake (PCH)
|
||||
* Intel Meteor Lake (SOC)
|
||||
* Intel Meteor Lake (SOC and PCH)
|
||||
|
||||
Datasheets: Publicly available at the Intel website
|
||||
|
||||
|
||||
@ -150,6 +150,12 @@ the UTS_MACHINE variable, and on some architectures also the kernel config.
|
||||
The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian
|
||||
architecture.
|
||||
|
||||
KDOCFLAGS
|
||||
---------
|
||||
Specify extra (warning/error) flags for kernel-doc checks during the build,
|
||||
see scripts/kernel-doc for which flags are supported. Note that this doesn't
|
||||
(currently) apply to documentation builds.
|
||||
|
||||
ARCH
|
||||
----
|
||||
Set ARCH to the architecture to be built.
|
||||
|
||||
58
Documentation/powerpc/dexcr.rst
Normal file
58
Documentation/powerpc/dexcr.rst
Normal file
@ -0,0 +1,58 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
==========================================
|
||||
DEXCR (Dynamic Execution Control Register)
|
||||
==========================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The DEXCR is a privileged special purpose register (SPR) introduced in
|
||||
PowerPC ISA 3.1B (Power10) that allows per-cpu control over several dynamic
|
||||
execution behaviours. These behaviours include speculation (e.g., indirect
|
||||
branch target prediction) and enabling return-oriented programming (ROP)
|
||||
protection instructions.
|
||||
|
||||
The execution control is exposed in hardware as up to 32 bits ('aspects') in
|
||||
the DEXCR. Each aspect controls a certain behaviour, and can be set or cleared
|
||||
to enable/disable the aspect. There are several variants of the DEXCR for
|
||||
different purposes:
|
||||
|
||||
DEXCR
|
||||
A privileged SPR that can control aspects for userspace and kernel space
|
||||
HDEXCR
|
||||
A hypervisor-privileged SPR that can control aspects for the hypervisor and
|
||||
enforce aspects for the kernel and userspace.
|
||||
UDEXCR
|
||||
An optional ultravisor-privileged SPR that can control aspects for the ultravisor.
|
||||
|
||||
Userspace can examine the current DEXCR state using a dedicated SPR that
|
||||
provides a non-privileged read-only view of the userspace DEXCR aspects.
|
||||
There is also an SPR that provides a read-only view of the hypervisor enforced
|
||||
aspects, which ORed with the userspace DEXCR view gives the effective DEXCR
|
||||
state for a process.
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
The DEXCR is currently unconfigurable. All threads are run with the
|
||||
NPHIE aspect enabled.
|
||||
|
||||
|
||||
coredump and ptrace
|
||||
===================
|
||||
|
||||
The userspace values of the DEXCR and HDEXCR (in this order) are exposed under
|
||||
``NT_PPC_DEXCR``. These are each 64 bits and readonly, and are intended to
|
||||
assist with core dumps. The DEXCR may be made writable in future. The top 32
|
||||
bits of both registers (corresponding to the non-userspace bits) are masked off.
|
||||
|
||||
If the kernel config ``CONFIG_CHECKPOINT_RESTORE`` is enabled, then
|
||||
``NT_PPC_HASHKEYR`` is available and exposes the HASHKEYR value of the process
|
||||
for reading and writing. This is a tradeoff between increased security and
|
||||
checkpoint/restore support: a process should normally have no need to know its
|
||||
secret key, but restoring a process requires setting its original key. The key
|
||||
therefore appears in core dumps, and an attacker may be able to retrieve it from
|
||||
a coredump and effectively bypass ROP protection on any threads that share this
|
||||
key (potentially all threads from the same parent that have not run ``exec()``).
|
||||
@ -15,6 +15,7 @@ powerpc
|
||||
cxl
|
||||
cxlflash
|
||||
dawr-power9
|
||||
dexcr
|
||||
dscr
|
||||
eeh-pci-error-recovery
|
||||
elf_hwcaps
|
||||
|
||||
@ -60,6 +60,8 @@ openssl & libcrypto 1.0.0 openssl version
|
||||
bc 1.06.95 bc --version
|
||||
Sphinx\ [#f1]_ 1.7 sphinx-build --version
|
||||
cpio any cpio --version
|
||||
GNU tar 1.28 tar --version
|
||||
gtags (optional) 6.6.5 gtags --version
|
||||
====================== =============== ========================================
|
||||
|
||||
.. [#f1] Sphinx is needed only to build the Kernel documentation
|
||||
@ -174,6 +176,18 @@ You will need openssl to build kernels 3.7 and higher if module signing is
|
||||
enabled. You will also need openssl development packages to build kernels 4.3
|
||||
and higher.
|
||||
|
||||
Tar
|
||||
---
|
||||
|
||||
GNU tar is needed if you want to enable access to the kernel headers via sysfs
|
||||
(CONFIG_IKHEADERS).
|
||||
|
||||
gtags / GNU GLOBAL (optional)
|
||||
-----------------------------
|
||||
|
||||
The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
|
||||
tag files through ``make gtags``. This is due to its use of the gtags
|
||||
``-C (--directory)`` flag.
|
||||
|
||||
System utilities
|
||||
****************
|
||||
|
||||
@ -64,6 +64,19 @@ The following keys are defined:
|
||||
* :c:macro:`RISCV_HWPROBE_IMA_C`: The C extension is supported, as defined
|
||||
by version 2.2 of the RISC-V ISA manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_IMA_V`: The V extension is supported, as defined by
|
||||
version 1.0 of the RISC-V Vector extension manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is
|
||||
supported, as defined in version 1.0 of the Bit-Manipulation ISA
|
||||
extensions.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined
|
||||
in version 1.0 of the Bit-Manipulation ISA extensions.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
|
||||
in version 1.0 of the Bit-Manipulation ISA extensions.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
|
||||
information about the selected set of processors.
|
||||
|
||||
|
||||
@ -10,6 +10,7 @@ RISC-V architecture
|
||||
hwprobe
|
||||
patch-acceptance
|
||||
uabi
|
||||
vector
|
||||
|
||||
features
|
||||
|
||||
|
||||
132
Documentation/riscv/vector.rst
Normal file
132
Documentation/riscv/vector.rst
Normal file
@ -0,0 +1,132 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========================================
|
||||
Vector Extension Support for RISC-V Linux
|
||||
=========================================
|
||||
|
||||
This document briefly outlines the interface provided to userspace by Linux in
|
||||
order to support the use of the RISC-V Vector Extension.
|
||||
|
||||
1. prctl() Interface
|
||||
---------------------
|
||||
|
||||
Two new prctl() calls are added to allow programs to manage the enablement
|
||||
status for the use of Vector in userspace. The intended usage guideline for
|
||||
these interfaces is to give init systems a way to modify the availability of V
|
||||
for processes running under its domain. Calling thess interfaces is not
|
||||
recommended in libraries routines because libraries should not override policies
|
||||
configured from the parant process. Also, users must noted that these interfaces
|
||||
are not portable to non-Linux, nor non-RISC-V environments, so it is discourage
|
||||
to use in a portable code. To get the availability of V in an ELF program,
|
||||
please read :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the
|
||||
auxiliary vector.
|
||||
|
||||
* prctl(PR_RISCV_V_SET_CONTROL, unsigned long arg)
|
||||
|
||||
Sets the Vector enablement status of the calling thread, where the control
|
||||
argument consists of two 2-bit enablement statuses and a bit for inheritance
|
||||
mode. Other threads of the calling process are unaffected.
|
||||
|
||||
Enablement status is a tri-state value each occupying 2-bit of space in
|
||||
the control argument:
|
||||
|
||||
* :c:macro:`PR_RISCV_V_VSTATE_CTRL_DEFAULT`: Use the system-wide default
|
||||
enablement status on execve(). The system-wide default setting can be
|
||||
controlled via sysctl interface (see sysctl section below).
|
||||
|
||||
* :c:macro:`PR_RISCV_V_VSTATE_CTRL_ON`: Allow Vector to be run for the
|
||||
thread.
|
||||
|
||||
* :c:macro:`PR_RISCV_V_VSTATE_CTRL_OFF`: Disallow Vector. Executing Vector
|
||||
instructions under such condition will trap and casuse the termination of the thread.
|
||||
|
||||
arg: The control argument is a 5-bit value consisting of 3 parts, and
|
||||
accessed by 3 masks respectively.
|
||||
|
||||
The 3 masks, PR_RISCV_V_VSTATE_CTRL_CUR_MASK,
|
||||
PR_RISCV_V_VSTATE_CTRL_NEXT_MASK, and PR_RISCV_V_VSTATE_CTRL_INHERIT
|
||||
represents bit[1:0], bit[3:2], and bit[4]. bit[1:0] accounts for the
|
||||
enablement status of current thread, and the setting at bit[3:2] takes place
|
||||
at next execve(). bit[4] defines the inheritance mode of the setting in
|
||||
bit[3:2].
|
||||
|
||||
* :c:macro:`PR_RISCV_V_VSTATE_CTRL_CUR_MASK`: bit[1:0]: Account for the
|
||||
Vector enablement status for the calling thread. The calling thread is
|
||||
not able to turn off Vector once it has been enabled. The prctl() call
|
||||
fails with EPERM if the value in this mask is PR_RISCV_V_VSTATE_CTRL_OFF
|
||||
but the current enablement status is not off. Setting
|
||||
PR_RISCV_V_VSTATE_CTRL_DEFAULT here takes no effect but to set back
|
||||
the original enablement status.
|
||||
|
||||
* :c:macro:`PR_RISCV_V_VSTATE_CTRL_NEXT_MASK`: bit[3:2]: Account for the
|
||||
Vector enablement setting for the calling thread at the next execve()
|
||||
system call. If PR_RISCV_V_VSTATE_CTRL_DEFAULT is used in this mask,
|
||||
then the enablement status will be decided by the system-wide
|
||||
enablement status when execve() happen.
|
||||
|
||||
* :c:macro:`PR_RISCV_V_VSTATE_CTRL_INHERIT`: bit[4]: the inheritance
|
||||
mode for the setting at PR_RISCV_V_VSTATE_CTRL_NEXT_MASK. If the bit
|
||||
is set then the following execve() will not clear the setting in both
|
||||
PR_RISCV_V_VSTATE_CTRL_NEXT_MASK and PR_RISCV_V_VSTATE_CTRL_INHERIT.
|
||||
This setting persists across changes in the system-wide default value.
|
||||
|
||||
Return value:
|
||||
* 0 on success;
|
||||
* EINVAL: Vector not supported, invalid enablement status for current or
|
||||
next mask;
|
||||
* EPERM: Turning off Vector in PR_RISCV_V_VSTATE_CTRL_CUR_MASK if Vector
|
||||
was enabled for the calling thread.
|
||||
|
||||
On success:
|
||||
* A valid setting for PR_RISCV_V_VSTATE_CTRL_CUR_MASK takes place
|
||||
immediately. The enablement status specified in
|
||||
PR_RISCV_V_VSTATE_CTRL_NEXT_MASK happens at the next execve() call, or
|
||||
all following execve() calls if PR_RISCV_V_VSTATE_CTRL_INHERIT bit is
|
||||
set.
|
||||
* Every successful call overwrites a previous setting for the calling
|
||||
thread.
|
||||
|
||||
* prctl(PR_RISCV_V_GET_CONTROL)
|
||||
|
||||
Gets the same Vector enablement status for the calling thread. Setting for
|
||||
next execve() call and the inheritance bit are all OR-ed together.
|
||||
|
||||
Note that ELF programs are able to get the availability of V for itself by
|
||||
reading :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the
|
||||
auxiliary vector.
|
||||
|
||||
Return value:
|
||||
* a nonnegative value on success;
|
||||
* EINVAL: Vector not supported.
|
||||
|
||||
2. System runtime configuration (sysctl)
|
||||
-----------------------------------------
|
||||
|
||||
To mitigate the ABI impact of expansion of the signal stack, a
|
||||
policy mechanism is provided to the administrators, distro maintainers, and
|
||||
developers to control the default Vector enablement status for userspace
|
||||
processes in form of sysctl knob:
|
||||
|
||||
* /proc/sys/abi/riscv_v_default_allow
|
||||
|
||||
Writing the text representation of 0 or 1 to this file sets the default
|
||||
system enablement status for new starting userspace programs. Valid values
|
||||
are:
|
||||
|
||||
* 0: Do not allow Vector code to be executed as the default for new processes.
|
||||
* 1: Allow Vector code to be executed as the default for new processes.
|
||||
|
||||
Reading this file returns the current system default enablement status.
|
||||
|
||||
At every execve() call, a new enablement status of the new process is set to
|
||||
the system default, unless:
|
||||
|
||||
* PR_RISCV_V_VSTATE_CTRL_INHERIT is set for the calling process, and the
|
||||
setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not
|
||||
PR_RISCV_V_VSTATE_CTRL_DEFAULT. Or,
|
||||
|
||||
* The setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not
|
||||
PR_RISCV_V_VSTATE_CTRL_DEFAULT.
|
||||
|
||||
Modifying the system default enablement status does not affect the enablement
|
||||
status of any existing process of thread that do not make an execve() call.
|
||||
@ -1,3 +1,4 @@
|
||||
===================
|
||||
ARECA FIRMWARE SPEC
|
||||
===================
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======================================
|
||||
README file for the dc395x SCSI driver
|
||||
======================================
|
||||
==================
|
||||
dc395x SCSI driver
|
||||
==================
|
||||
|
||||
Status
|
||||
------
|
||||
@ -11,13 +11,10 @@ be safe to use. Testing with hard disks has not been done to any
|
||||
great degree and caution should be exercised if you want to attempt
|
||||
to use this driver with hard disks.
|
||||
|
||||
This is a 2.5 only driver. For a 2.4 driver please see the original
|
||||
driver (which this driver started from) at
|
||||
http://www.garloff.de/kurt/linux/dc395/
|
||||
|
||||
Problems, questions and patches should be submitted to the mailing
|
||||
list. Details on the list, including archives, are available at
|
||||
http://lists.twibble.org/mailman/listinfo/dc395x/
|
||||
This driver is evolved from `the original 2.4 driver
|
||||
<https://web.archive.org/web/20140129181343/http://www.garloff.de/kurt/linux/dc395/>`_.
|
||||
Problems, questions and patches should be submitted to the `Linux SCSI
|
||||
mailing list <linux-scsi@vger.kernel.org>`_.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
==========================================
|
||||
README file for the Linux g_NCR5380 driver
|
||||
==========================================
|
||||
================
|
||||
g_NCR5380 driver
|
||||
================
|
||||
|
||||
Copyright |copy| 1993 Drew Eckhard
|
||||
|
||||
|
||||
@ -4,6 +4,38 @@
|
||||
SCSI Subsystem
|
||||
==============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
scsi
|
||||
|
||||
SCSI driver APIs
|
||||
================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
scsi_mid_low_api
|
||||
scsi_eh
|
||||
|
||||
SCSI driver parameters
|
||||
======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
scsi-parameters
|
||||
link_power_management_policy
|
||||
|
||||
SCSI host adapter drivers
|
||||
=========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@ -25,7 +57,6 @@ SCSI Subsystem
|
||||
hpsa
|
||||
hptiop
|
||||
libsas
|
||||
link_power_management_policy
|
||||
lpfc
|
||||
megaraid
|
||||
ncr53c8xx
|
||||
@ -33,12 +64,8 @@ SCSI Subsystem
|
||||
ppa
|
||||
qlogicfas
|
||||
scsi-changer
|
||||
scsi_eh
|
||||
scsi_fc_transport
|
||||
scsi-generic
|
||||
scsi_mid_low_api
|
||||
scsi-parameters
|
||||
scsi
|
||||
sd-parameters
|
||||
smartpqi
|
||||
st
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==========================
|
||||
Notes on Management Module
|
||||
==========================
|
||||
=================================
|
||||
Megaraid Common Management Module
|
||||
=================================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================================================
|
||||
The Linux NCR53C8XX/SYM53C8XX drivers README file
|
||||
=================================================
|
||||
===========================
|
||||
NCR53C8XX/SYM53C8XX drivers
|
||||
===========================
|
||||
|
||||
Written by Gerard Roudier <groudier@free.fr>
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
========================================
|
||||
README for the SCSI media changer driver
|
||||
========================================
|
||||
=========================
|
||||
SCSI media changer driver
|
||||
=========================
|
||||
|
||||
This is a driver for SCSI Medium Changer devices, which are listed
|
||||
with "Type: Medium Changer" in /proc/scsi/scsi.
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=======================================
|
||||
Notes on Linux SCSI Generic (sg) driver
|
||||
=======================================
|
||||
========================
|
||||
SCSI Generic (sg) driver
|
||||
========================
|
||||
|
||||
20020126
|
||||
|
||||
Introduction
|
||||
============
|
||||
The SCSI Generic driver (sg) is one of the four "high level" SCSI device
|
||||
drivers along with sd, st and sr (disk, tape and CDROM respectively). Sg
|
||||
drivers along with sd, st and sr (disk, tape and CD-ROM respectively). Sg
|
||||
is more generalized (but lower level) than its siblings and tends to be
|
||||
used on SCSI devices that don't fit into the already serviced categories.
|
||||
Thus sg is used for scanners, CD writers and reading audio CDs digitally
|
||||
@ -22,7 +22,7 @@ and examples.
|
||||
|
||||
Major versions of the sg driver
|
||||
===============================
|
||||
There are three major versions of sg found in the linux kernel (lk):
|
||||
There are three major versions of sg found in the Linux kernel (lk):
|
||||
- sg version 1 (original) from 1992 to early 1999 (lk 2.2.5) .
|
||||
It is based in the sg_header interface structure.
|
||||
- sg version 2 from lk 2.2.6 in the 2.2 series. It is based on
|
||||
@ -33,34 +33,24 @@ There are three major versions of sg found in the linux kernel (lk):
|
||||
|
||||
Sg driver documentation
|
||||
=======================
|
||||
The most recent documentation of the sg driver is kept at the Linux
|
||||
Documentation Project's (LDP) site:
|
||||
The most recent documentation of the sg driver is kept at
|
||||
|
||||
- http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO
|
||||
- https://sg.danny.cz/sg/
|
||||
|
||||
This describes the sg version 3 driver found in the lk 2.4 series.
|
||||
|
||||
The LDP renders documents in single and multiple page HTML, postscript
|
||||
and pdf. This document can also be found at:
|
||||
Documentation (large version) for the version 2 sg driver found in the
|
||||
lk 2.2 series can be found at
|
||||
|
||||
- http://sg.danny.cz/sg/p/sg_v3_ho.html
|
||||
|
||||
Documentation for the version 2 sg driver found in the lk 2.2 series can
|
||||
be found at http://sg.danny.cz/sg/. A larger version
|
||||
is at: http://sg.danny.cz/sg/p/scsi-generic_long.txt.
|
||||
- https://sg.danny.cz/sg/p/scsi-generic_long.txt.
|
||||
|
||||
The original documentation for the sg driver (prior to lk 2.2.6) can be
|
||||
found at http://www.torque.net/sg/p/original/SCSI-Programming-HOWTO.txt
|
||||
and in the LDP archives.
|
||||
found in the LDP archives at
|
||||
|
||||
A changelog with brief notes can be found in the
|
||||
/usr/src/linux/include/scsi/sg.h file. Note that the glibc maintainers copy
|
||||
and edit this file (removing its changelog for example) before placing it
|
||||
in /usr/include/scsi/sg.h . Driver debugging information and other notes
|
||||
can be found at the top of the /usr/src/linux/drivers/scsi/sg.c file.
|
||||
- https://tldp.org/HOWTO/archived/SCSI-Programming-HOWTO/index.html
|
||||
|
||||
A more general description of the Linux SCSI subsystem of which sg is a
|
||||
part can be found at http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO .
|
||||
part can be found at https://www.tldp.org/HOWTO/SCSI-2.4-HOWTO .
|
||||
|
||||
|
||||
Example code and utilities
|
||||
@ -73,8 +63,8 @@ There are two packages of sg utilities:
|
||||
and earlier
|
||||
========= ==========================================================
|
||||
|
||||
Both packages will work in the lk 2.4 series however sg3_utils offers more
|
||||
capabilities. They can be found at: http://sg.danny.cz/sg/sg3_utils.html and
|
||||
Both packages will work in the lk 2.4 series. However, sg3_utils offers more
|
||||
capabilities. They can be found at: https://sg.danny.cz/sg/sg3_utils.html and
|
||||
freecode.com
|
||||
|
||||
Another approach is to look at the applications that use the sg driver.
|
||||
@ -83,7 +73,7 @@ These include cdrecord, cdparanoia, SANE and cdrdao.
|
||||
|
||||
Mapping of Linux kernel versions to sg driver versions
|
||||
======================================================
|
||||
Here is a list of linux kernels in the 2.4 series that had new version
|
||||
Here is a list of Linux kernels in the 2.4 series that had the new version
|
||||
of the sg driver:
|
||||
|
||||
- lk 2.4.0 : sg version 3.1.17
|
||||
@ -92,10 +82,10 @@ of the sg driver:
|
||||
- lk 2.4.17 : sg version 3.1.22
|
||||
|
||||
.. [#] There were 3 changes to sg version 3.1.20 by third parties in the
|
||||
next six linux kernel versions.
|
||||
next six Linux kernel versions.
|
||||
|
||||
For reference here is a list of linux kernels in the 2.2 series that had
|
||||
new version of the sg driver:
|
||||
For reference here is a list of Linux kernels in the 2.2 series that had
|
||||
the new version of the sg driver:
|
||||
|
||||
- lk 2.2.0 : original sg version [with no version number]
|
||||
- lk 2.2.6 : sg version 2.1.31
|
||||
@ -106,9 +96,8 @@ new version of the sg driver:
|
||||
- lk 2.2.17 : sg version 2.1.39
|
||||
- lk 2.2.20 : sg version 2.1.40
|
||||
|
||||
The lk 2.5 development series has recently commenced and it currently
|
||||
contains sg version 3.5.23 which is functionally equivalent to sg
|
||||
version 3.1.22 found in lk 2.4.17.
|
||||
The lk 2.5 development series currently contains sg version 3.5.23
|
||||
which is functionally equivalent to sg version 3.1.22 found in lk 2.4.17.
|
||||
|
||||
|
||||
Douglas Gilbert
|
||||
|
||||
@ -6,30 +6,28 @@ SCSI subsystem documentation
|
||||
|
||||
The Linux Documentation Project (LDP) maintains a document describing
|
||||
the SCSI subsystem in the Linux kernel (lk) 2.4 series. See:
|
||||
http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single
|
||||
https://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single
|
||||
and multiple page HTML renderings as well as postscript and pdf.
|
||||
It can also be found at:
|
||||
http://web.archive.org/web/%2E/http://www.torque.net/scsi/SCSI-2.4-HOWTO
|
||||
|
||||
Notes on using modules in the SCSI subsystem
|
||||
============================================
|
||||
The scsi support in the linux kernel can be modularized in a number of
|
||||
The SCSI support in the Linux kernel can be modularized in a number of
|
||||
different ways depending upon the needs of the end user. To understand
|
||||
your options, we should first define a few terms.
|
||||
|
||||
The scsi-core (also known as the "mid level") contains the core of scsi
|
||||
support. Without it you can do nothing with any of the other scsi drivers.
|
||||
The scsi core support can be a module (scsi_mod.o), or it can be built into
|
||||
the kernel. If the core is a module, it must be the first scsi module
|
||||
The scsi-core (also known as the "mid level") contains the core of SCSI
|
||||
support. Without it you can do nothing with any of the other SCSI drivers.
|
||||
The SCSI core support can be a module (scsi_mod.o), or it can be built into
|
||||
the kernel. If the core is a module, it must be the first SCSI module
|
||||
loaded, and if you unload the modules, it will have to be the last one
|
||||
unloaded. In practice the modprobe and rmmod commands (and "autoclean")
|
||||
unloaded. In practice the modprobe and rmmod commands
|
||||
will enforce the correct ordering of loading and unloading modules in
|
||||
the SCSI subsystem.
|
||||
|
||||
The individual upper and lower level drivers can be loaded in any order
|
||||
once the scsi core is present in the kernel (either compiled in or loaded
|
||||
as a module). The disk driver (sd_mod.o), cdrom driver (sr_mod.o),
|
||||
tape driver [1]_ (st.o) and scsi generics driver (sg.o) represent the upper
|
||||
once the SCSI core is present in the kernel (either compiled in or loaded
|
||||
as a module). The disk driver (sd_mod.o), CD-ROM driver (sr_mod.o),
|
||||
tape driver [1]_ (st.o) and SCSI generics driver (sg.o) represent the upper
|
||||
level drivers to support the various assorted devices which can be
|
||||
controlled. You can for example load the tape driver to use the tape drive,
|
||||
and then unload it once you have no further need for the driver (and release
|
||||
@ -44,4 +42,3 @@ built into the kernel.
|
||||
|
||||
.. [1] There is a variant of the st driver for controlling OnStream tape
|
||||
devices. Its module name is osst.o .
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
================
|
||||
SCSI FC Tansport
|
||||
================
|
||||
=================
|
||||
SCSI FC Transport
|
||||
=================
|
||||
|
||||
Date: 11/18/2008
|
||||
|
||||
@ -556,5 +556,5 @@ The following people have contributed to this document:
|
||||
|
||||
|
||||
James Smart
|
||||
james.smart@emulex.com
|
||||
james.smart@broadcom.com
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========================================
|
||||
The Linux SYM-2 driver documentation file
|
||||
=========================================
|
||||
============
|
||||
SYM-2 driver
|
||||
============
|
||||
|
||||
Written by Gerard Roudier <groudier@free.fr>
|
||||
|
||||
|
||||
@ -71,3 +71,4 @@ Storage interfaces
|
||||
scheduler/index
|
||||
mhi/index
|
||||
peci/index
|
||||
wmi/index
|
||||
|
||||
188
Documentation/trace/fprobetrace.rst
Normal file
188
Documentation/trace/fprobetrace.rst
Normal file
@ -0,0 +1,188 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==========================
|
||||
Fprobe-based Event Tracing
|
||||
==========================
|
||||
|
||||
.. Author: Masami Hiramatsu <mhiramat@kernel.org>
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Fprobe event is similar to the kprobe event, but limited to probe on
|
||||
the function entry and exit only. It is good enough for many use cases
|
||||
which only traces some specific functions.
|
||||
|
||||
This document also covers tracepoint probe events (tprobe) since this
|
||||
is also works only on the tracepoint entry. User can trace a part of
|
||||
tracepoint argument, or the tracepoint without trace-event, which is
|
||||
not exposed on tracefs.
|
||||
|
||||
As same as other dynamic events, fprobe events and tracepoint probe
|
||||
events are defined via `dynamic_events` interface file on tracefs.
|
||||
|
||||
Synopsis of fprobe-events
|
||||
-------------------------
|
||||
::
|
||||
|
||||
f[:[GRP1/][EVENT1]] SYM [FETCHARGS] : Probe on function entry
|
||||
f[MAXACTIVE][:[GRP1/][EVENT1]] SYM%return [FETCHARGS] : Probe on function exit
|
||||
t[:[GRP2/][EVENT2]] TRACEPOINT [FETCHARGS] : Probe on tracepoint
|
||||
|
||||
GRP1 : Group name for fprobe. If omitted, use "fprobes" for it.
|
||||
GRP2 : Group name for tprobe. If omitted, use "tracepoints" for it.
|
||||
EVENT1 : Event name for fprobe. If omitted, the event name is
|
||||
"SYM__entry" or "SYM__exit".
|
||||
EVENT2 : Event name for tprobe. If omitted, the event name is
|
||||
the same as "TRACEPOINT", but if the "TRACEPOINT" starts
|
||||
with a digit character, "_TRACEPOINT" is used.
|
||||
MAXACTIVE : Maximum number of instances of the specified function that
|
||||
can be probed simultaneously, or 0 for the default value
|
||||
as defined in Documentation/trace/fprobe.rst
|
||||
|
||||
FETCHARGS : Arguments. Each probe can have up to 128 args.
|
||||
ARG : Fetch "ARG" function argument using BTF (only for function
|
||||
entry or tracepoint.) (\*1)
|
||||
@ADDR : Fetch memory at ADDR (ADDR should be in kernel)
|
||||
@SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
|
||||
$stackN : Fetch Nth entry of stack (N >= 0)
|
||||
$stack : Fetch stack address.
|
||||
$argN : Fetch the Nth function argument. (N >= 1) (\*2)
|
||||
$retval : Fetch return value.(\*3)
|
||||
$comm : Fetch current task comm.
|
||||
+|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*4)(\*5)
|
||||
\IMM : Store an immediate value to the argument.
|
||||
NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
|
||||
FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
|
||||
(u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types
|
||||
(x8/x16/x32/x64), "char", "string", "ustring", "symbol", "symstr"
|
||||
and bitfield are supported.
|
||||
|
||||
(\*1) This is available only when BTF is enabled.
|
||||
(\*2) only for the probe on function entry (offs == 0).
|
||||
(\*3) only for return probe.
|
||||
(\*4) this is useful for fetching a field of data structures.
|
||||
(\*5) "u" means user-space dereference.
|
||||
|
||||
For the details of TYPE, see :ref:`kprobetrace documentation <kprobetrace_types>`.
|
||||
|
||||
BTF arguments
|
||||
-------------
|
||||
BTF (BPF Type Format) argument allows user to trace function and tracepoint
|
||||
parameters by its name instead of ``$argN``. This feature is available if the
|
||||
kernel is configured with CONFIG_BPF_SYSCALL and CONFIG_DEBUG_INFO_BTF.
|
||||
If user only specify the BTF argument, the event's argument name is also
|
||||
automatically set by the given name. ::
|
||||
|
||||
# echo 'f:myprobe vfs_read count pos' >> dynamic_events
|
||||
# cat dynamic_events
|
||||
f:fprobes/myprobe vfs_read count=count pos=pos
|
||||
|
||||
It also chooses the fetch type from BTF information. For example, in the above
|
||||
example, the ``count`` is unsigned long, and the ``pos`` is a pointer. Thus, both
|
||||
are converted to 64bit unsigned long, but only ``pos`` has "%Lx" print-format as
|
||||
below ::
|
||||
|
||||
# cat events/fprobes/myprobe/format
|
||||
name: myprobe
|
||||
ID: 1313
|
||||
format:
|
||||
field:unsigned short common_type; offset:0; size:2; signed:0;
|
||||
field:unsigned char common_flags; offset:2; size:1; signed:0;
|
||||
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
|
||||
field:int common_pid; offset:4; size:4; signed:1;
|
||||
|
||||
field:unsigned long __probe_ip; offset:8; size:8; signed:0;
|
||||
field:u64 count; offset:16; size:8; signed:0;
|
||||
field:u64 pos; offset:24; size:8; signed:0;
|
||||
|
||||
print fmt: "(%lx) count=%Lu pos=0x%Lx", REC->__probe_ip, REC->count, REC->pos
|
||||
|
||||
If user unsures the name of arguments, ``$arg*`` will be helpful. The ``$arg*``
|
||||
is expanded to all function arguments of the function or the tracepoint. ::
|
||||
|
||||
# echo 'f:myprobe vfs_read $arg*' >> dynamic_events
|
||||
# cat dynamic_events
|
||||
f:fprobes/myprobe vfs_read file=file buf=buf count=count pos=pos
|
||||
|
||||
BTF also affects the ``$retval``. If user doesn't set any type, the retval type is
|
||||
automatically picked from the BTF. If the function returns ``void``, ``$retval``
|
||||
is rejected.
|
||||
|
||||
Usage examples
|
||||
--------------
|
||||
Here is an example to add fprobe events on ``vfs_read()`` function entry
|
||||
and exit, with BTF arguments.
|
||||
::
|
||||
|
||||
# echo 'f vfs_read $arg*' >> dynamic_events
|
||||
# echo 'f vfs_read%return $retval' >> dynamic_events
|
||||
# cat dynamic_events
|
||||
f:fprobes/vfs_read__entry vfs_read file=file buf=buf count=count pos=pos
|
||||
f:fprobes/vfs_read__exit vfs_read%return arg1=$retval
|
||||
# echo 1 > events/fprobes/enable
|
||||
# head -n 20 trace | tail
|
||||
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
|
||||
# | | | ||||| | |
|
||||
sh-70 [000] ...1. 335.883195: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08
|
||||
sh-70 [000] ..... 335.883208: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
|
||||
sh-70 [000] ...1. 335.883220: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08
|
||||
sh-70 [000] ..... 335.883224: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
|
||||
sh-70 [000] ...1. 335.883232: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c687a count=1 pos=0xffffc900005aff08
|
||||
sh-70 [000] ..... 335.883237: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
|
||||
sh-70 [000] ...1. 336.050329: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08
|
||||
sh-70 [000] ..... 336.050343: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
|
||||
|
||||
You can see all function arguments and return values are recorded as signed int.
|
||||
|
||||
Also, here is an example of tracepoint events on ``sched_switch`` tracepoint.
|
||||
To compare the result, this also enables the ``sched_switch`` traceevent too.
|
||||
::
|
||||
|
||||
# echo 't sched_switch $arg*' >> dynamic_events
|
||||
# echo 1 > events/sched/sched_switch/enable
|
||||
# echo 1 > events/tracepoints/sched_switch/enable
|
||||
# echo > trace
|
||||
# head -n 20 trace | tail
|
||||
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
|
||||
# | | | ||||| | |
|
||||
sh-70 [000] d..2. 3912.083993: sched_switch: prev_comm=sh prev_pid=70 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
|
||||
sh-70 [000] d..3. 3912.083995: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffff88800664e100 next=0xffffffff828229c0 prev_state=1
|
||||
<idle>-0 [000] d..2. 3912.084183: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=16 next_prio=120
|
||||
<idle>-0 [000] d..3. 3912.084184: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffffffff828229c0 next=0xffff888004208000 prev_state=0
|
||||
rcu_preempt-16 [000] d..2. 3912.084196: sched_switch: prev_comm=rcu_preempt prev_pid=16 prev_prio=120 prev_state=I ==> next_comm=swapper/0 next_pid=0 next_prio=120
|
||||
rcu_preempt-16 [000] d..3. 3912.084196: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffff888004208000 next=0xffffffff828229c0 prev_state=1026
|
||||
<idle>-0 [000] d..2. 3912.085191: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=16 next_prio=120
|
||||
<idle>-0 [000] d..3. 3912.085191: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffffffff828229c0 next=0xffff888004208000 prev_state=0
|
||||
|
||||
As you can see, the ``sched_switch`` trace-event shows *cooked* parameters, on
|
||||
the other hand, the ``sched_switch`` tracepoint probe event shows *raw*
|
||||
parameters. This means you can access any field values in the task
|
||||
structure pointed by the ``prev`` and ``next`` arguments.
|
||||
|
||||
For example, usually ``task_struct::start_time`` is not traced, but with this
|
||||
traceprobe event, you can trace it as below.
|
||||
::
|
||||
|
||||
# echo 't sched_switch comm=+1896(next):string start_time=+1728(next):u64' > dynamic_events
|
||||
# head -n 20 trace | tail
|
||||
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
|
||||
# | | | ||||| | |
|
||||
sh-70 [000] d..3. 5606.686577: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="rcu_preempt" usage=1 start_time=245000000
|
||||
rcu_preempt-16 [000] d..3. 5606.686602: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="sh" usage=1 start_time=1596095526
|
||||
sh-70 [000] d..3. 5606.686637: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
|
||||
<idle>-0 [000] d..3. 5606.687190: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="rcu_preempt" usage=1 start_time=245000000
|
||||
rcu_preempt-16 [000] d..3. 5606.687202: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
|
||||
<idle>-0 [000] d..3. 5606.690317: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
|
||||
kworker/0:1-14 [000] d..3. 5606.690339: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
|
||||
<idle>-0 [000] d..3. 5606.692368: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
|
||||
|
||||
Currently, to find the offset of a specific field in the data structure,
|
||||
you need to build kernel with debuginfo and run `perf probe` command with
|
||||
`-D` option. e.g.
|
||||
::
|
||||
|
||||
# perf probe -D "__probestub_sched_switch next->comm:string next->start_time"
|
||||
p:probe/__probestub_sched_switch __probestub_sched_switch+0 comm=+1896(%cx):string start_time=+1728(%cx):u64
|
||||
|
||||
And replace the ``%cx`` with the ``next``.
|
||||
@ -324,6 +324,12 @@ of ftrace. Here is a list of some of the key files:
|
||||
"set_graph_function", or "set_graph_notrace".
|
||||
(See the section "dynamic ftrace" below for more details.)
|
||||
|
||||
available_filter_functions_addrs:
|
||||
|
||||
Similar to available_filter_functions, but with address displayed
|
||||
for each function. The displayed address is the patch-site address
|
||||
and can differ from /proc/kallsyms address.
|
||||
|
||||
dyn_ftrace_total_info:
|
||||
|
||||
This file is for debugging purposes. The number of functions that
|
||||
@ -1359,6 +1365,19 @@ Options for function_graph tracer:
|
||||
only a closing curly bracket "}" is displayed for
|
||||
the return of a function.
|
||||
|
||||
funcgraph-retval
|
||||
When set, the return value of each traced function
|
||||
will be printed after an equal sign "=". By default
|
||||
this is off.
|
||||
|
||||
funcgraph-retval-hex
|
||||
When set, the return value will always be printed
|
||||
in hexadecimal format. If the option is not set and
|
||||
the return value is an error code, it will be printed
|
||||
in signed decimal format; otherwise it will also be
|
||||
printed in hexadecimal format. By default, this option
|
||||
is off.
|
||||
|
||||
sleep-time
|
||||
When running function graph tracer, to include
|
||||
the time a task schedules out in its function.
|
||||
@ -2704,6 +2723,119 @@ It is default disabled.
|
||||
0) 1.757 us | } /* kmem_cache_free() */
|
||||
0) 2.861 us | } /* putname() */
|
||||
|
||||
The return value of each traced function can be displayed after
|
||||
an equal sign "=". When encountering system call failures, it
|
||||
can be verfy helpful to quickly locate the function that first
|
||||
returns an error code.
|
||||
|
||||
- hide: echo nofuncgraph-retval > trace_options
|
||||
- show: echo funcgraph-retval > trace_options
|
||||
|
||||
Example with funcgraph-retval::
|
||||
|
||||
1) | cgroup_migrate() {
|
||||
1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
|
||||
1) | cgroup_migrate_execute() {
|
||||
1) | cpu_cgroup_can_attach() {
|
||||
1) | cgroup_taskset_first() {
|
||||
1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
|
||||
1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
|
||||
1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */
|
||||
1) 2.335 us | } /* cpu_cgroup_can_attach = -22 */
|
||||
1) 4.369 us | } /* cgroup_migrate_execute = -22 */
|
||||
1) 7.143 us | } /* cgroup_migrate = -22 */
|
||||
|
||||
The above example shows that the function cpu_cgroup_can_attach
|
||||
returned the error code -22 firstly, then we can read the code
|
||||
of this function to get the root cause.
|
||||
|
||||
When the option funcgraph-retval-hex is not set, the return value can
|
||||
be displayed in a smart way. Specifically, if it is an error code,
|
||||
it will be printed in signed decimal format, otherwise it will
|
||||
printed in hexadecimal format.
|
||||
|
||||
- smart: echo nofuncgraph-retval-hex > trace_options
|
||||
- hexadecimal: echo funcgraph-retval-hex > trace_options
|
||||
|
||||
Example with funcgraph-retval-hex::
|
||||
|
||||
1) | cgroup_migrate() {
|
||||
1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
|
||||
1) | cgroup_migrate_execute() {
|
||||
1) | cpu_cgroup_can_attach() {
|
||||
1) | cgroup_taskset_first() {
|
||||
1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
|
||||
1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
|
||||
1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */
|
||||
1) 2.335 us | } /* cpu_cgroup_can_attach = 0xffffffea */
|
||||
1) 4.369 us | } /* cgroup_migrate_execute = 0xffffffea */
|
||||
1) 7.143 us | } /* cgroup_migrate = 0xffffffea */
|
||||
|
||||
At present, there are some limitations when using the funcgraph-retval
|
||||
option, and these limitations will be eliminated in the future:
|
||||
|
||||
- Even if the function return type is void, a return value will still
|
||||
be printed, and you can just ignore it.
|
||||
|
||||
- Even if return values are stored in multiple registers, only the
|
||||
value contained in the first register will be recorded and printed.
|
||||
To illustrate, in the x86 architecture, eax and edx are used to store
|
||||
a 64-bit return value, with the lower 32 bits saved in eax and the
|
||||
upper 32 bits saved in edx. However, only the value stored in eax
|
||||
will be recorded and printed.
|
||||
|
||||
- In certain procedure call standards, such as arm64's AAPCS64, when a
|
||||
type is smaller than a GPR, it is the responsibility of the consumer
|
||||
to perform the narrowing, and the upper bits may contain UNKNOWN values.
|
||||
Therefore, it is advisable to check the code for such cases. For instance,
|
||||
when using a u8 in a 64-bit GPR, bits [63:8] may contain arbitrary values,
|
||||
especially when larger types are truncated, whether explicitly or implicitly.
|
||||
Here are some specific cases to illustrate this point:
|
||||
|
||||
**Case One**:
|
||||
|
||||
The function narrow_to_u8 is defined as follows::
|
||||
|
||||
u8 narrow_to_u8(u64 val)
|
||||
{
|
||||
// implicitly truncated
|
||||
return val;
|
||||
}
|
||||
|
||||
It may be compiled to::
|
||||
|
||||
narrow_to_u8:
|
||||
< ... ftrace instrumentation ... >
|
||||
RET
|
||||
|
||||
If you pass 0x123456789abcdef to this function and want to narrow it,
|
||||
it may be recorded as 0x123456789abcdef instead of 0xef.
|
||||
|
||||
**Case Two**:
|
||||
|
||||
The function error_if_not_4g_aligned is defined as follows::
|
||||
|
||||
int error_if_not_4g_aligned(u64 val)
|
||||
{
|
||||
if (val & GENMASK(31, 0))
|
||||
return -EINVAL;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
It could be compiled to::
|
||||
|
||||
error_if_not_4g_aligned:
|
||||
CBNZ w0, .Lnot_aligned
|
||||
RET // bits [31:0] are zero, bits
|
||||
// [63:32] are UNKNOWN
|
||||
.Lnot_aligned:
|
||||
MOV x0, #-EINVAL
|
||||
RET
|
||||
|
||||
When passing 0x2_0000_0000 to it, the return value may be recorded as
|
||||
0x2_0000_0000 instead of 0.
|
||||
|
||||
You can put some comments on specific functions by using
|
||||
trace_printk() For example, if you want to put a comment inside
|
||||
the __might_sleep() function, you just have to include
|
||||
|
||||
@ -13,6 +13,7 @@ Linux Tracing Technologies
|
||||
kprobes
|
||||
kprobetrace
|
||||
uprobetracer
|
||||
fprobetrace
|
||||
tracepoints
|
||||
events
|
||||
events-kmem
|
||||
|
||||
@ -66,6 +66,8 @@ Synopsis of kprobe_events
|
||||
(\*3) this is useful for fetching a field of data structures.
|
||||
(\*4) "u" means user-space dereference. See :ref:`user_mem_access`.
|
||||
|
||||
.. _kprobetrace_types:
|
||||
|
||||
Types
|
||||
-----
|
||||
Several types are supported for fetchargs. Kprobe tracer will access memory
|
||||
|
||||
@ -180,3 +180,81 @@ dummy_load_1ms_pd_init, which had the following code (on purpose)::
|
||||
return 0;
|
||||
|
||||
}
|
||||
|
||||
User-space interface
|
||||
---------------------------
|
||||
|
||||
Timerlat allows user-space threads to use timerlat infra-structure to
|
||||
measure scheduling latency. This interface is accessible via a per-CPU
|
||||
file descriptor inside $tracing_dir/osnoise/per_cpu/cpu$ID/timerlat_fd.
|
||||
|
||||
This interface is accessible under the following conditions:
|
||||
|
||||
- timerlat tracer is enable
|
||||
- osnoise workload option is set to NO_OSNOISE_WORKLOAD
|
||||
- The user-space thread is affined to a single processor
|
||||
- The thread opens the file associated with its single processor
|
||||
- Only one thread can access the file at a time
|
||||
|
||||
The open() syscall will fail if any of these conditions are not met.
|
||||
After opening the file descriptor, the user space can read from it.
|
||||
|
||||
The read() system call will run a timerlat code that will arm the
|
||||
timer in the future and wait for it as the regular kernel thread does.
|
||||
|
||||
When the timer IRQ fires, the timerlat IRQ will execute, report the
|
||||
IRQ latency and wake up the thread waiting in the read. The thread will be
|
||||
scheduled and report the thread latency via tracer - as for the kernel
|
||||
thread.
|
||||
|
||||
The difference from the in-kernel timerlat is that, instead of re-arming
|
||||
the timer, timerlat will return to the read() system call. At this point,
|
||||
the user can run any code.
|
||||
|
||||
If the application rereads the file timerlat file descriptor, the tracer
|
||||
will report the return from user-space latency, which is the total
|
||||
latency. If this is the end of the work, it can be interpreted as the
|
||||
response time for the request.
|
||||
|
||||
After reporting the total latency, timerlat will restart the cycle, arm
|
||||
a timer, and go to sleep for the following activation.
|
||||
|
||||
If at any time one of the conditions is broken, e.g., the thread migrates
|
||||
while in user space, or the timerlat tracer is disabled, the SIG_KILL
|
||||
signal will be sent to the user-space thread.
|
||||
|
||||
Here is an basic example of user-space code for timerlat::
|
||||
|
||||
int main(void)
|
||||
{
|
||||
char buffer[1024];
|
||||
int timerlat_fd;
|
||||
int retval;
|
||||
long cpu = 0; /* place in CPU 0 */
|
||||
cpu_set_t set;
|
||||
|
||||
CPU_ZERO(&set);
|
||||
CPU_SET(cpu, &set);
|
||||
|
||||
if (sched_setaffinity(gettid(), sizeof(set), &set) == -1)
|
||||
return 1;
|
||||
|
||||
snprintf(buffer, sizeof(buffer),
|
||||
"/sys/kernel/tracing/osnoise/per_cpu/cpu%ld/timerlat_fd",
|
||||
cpu);
|
||||
|
||||
timerlat_fd = open(buffer, O_RDONLY);
|
||||
if (timerlat_fd < 0) {
|
||||
printf("error opening %s: %s\n", buffer, strerror(errno));
|
||||
exit(1);
|
||||
}
|
||||
|
||||
for (;;) {
|
||||
retval = read(timerlat_fd, buffer, 1024);
|
||||
if (retval < 0)
|
||||
break;
|
||||
}
|
||||
|
||||
close(timerlat_fd);
|
||||
exit(0);
|
||||
}
|
||||
|
||||
96
Documentation/wmi/acpi-interface.rst
Normal file
96
Documentation/wmi/acpi-interface.rst
Normal file
@ -0,0 +1,96 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
==================
|
||||
ACPI WMI interface
|
||||
==================
|
||||
|
||||
The ACPI WMI interface is a proprietary extension of the ACPI specification made
|
||||
by Microsoft to allow hardware vendors to embed WMI (Windows Management Instrumentation)
|
||||
objects inside their ACPI firmware. Typical functions implemented over ACPI WMI
|
||||
are hotkey events on modern notebooks and configuration of BIOS options.
|
||||
|
||||
PNP0C14 ACPI device
|
||||
-------------------
|
||||
|
||||
Discovery of WMI objects is handled by defining ACPI devices with a PNP ID
|
||||
of ``PNP0C14``. These devices will contain a set of ACPI buffers and methods
|
||||
used for mapping and execution of WMI methods and/or queries. If there exist
|
||||
multiple of such devices, then each device is required to have a
|
||||
unique ACPI UID.
|
||||
|
||||
_WDG buffer
|
||||
-----------
|
||||
|
||||
The ``_WDG`` buffer is used to discover WMI objects and is required to be
|
||||
static. Its internal structure consists of data blocks with a size of 20 bytes,
|
||||
containing the following data:
|
||||
|
||||
======= =============== =====================================================
|
||||
Offset Size (in bytes) Content
|
||||
======= =============== =====================================================
|
||||
0x00 16 128 bit Variant 2 object GUID.
|
||||
0x10 2 2 character method ID or single byte notification ID.
|
||||
0x12 1 Object instance count.
|
||||
0x13 1 Object flags.
|
||||
======= =============== =====================================================
|
||||
|
||||
The WMI object flags control whether the method or notification ID is used:
|
||||
|
||||
- 0x1: Data block usage is expensive and must be explicitly enabled/disabled.
|
||||
- 0x2: Data block contains WMI methods.
|
||||
- 0x4: Data block contains ASCIZ string.
|
||||
- 0x8: Data block describes a WMI event, use notification ID instead
|
||||
of method ID.
|
||||
|
||||
Each WMI object GUID can appear multiple times inside a system.
|
||||
The method/notification ID is used to construct the ACPI method names used for
|
||||
interacting with the WMI object.
|
||||
|
||||
WQxx ACPI methods
|
||||
-----------------
|
||||
|
||||
If a data block does not contain WMI methods, then its content can be retrieved
|
||||
by this required ACPI method. The last two characters of the ACPI method name
|
||||
are the method ID of the data block to query. Their single parameter is an
|
||||
integer describing the instance which should be queried. This parameter can be
|
||||
omitted if the data block contains only a single instance.
|
||||
|
||||
WSxx ACPI methods
|
||||
-----------------
|
||||
|
||||
Similar to the ``WQxx`` ACPI methods, except that it is optional and takes an
|
||||
additional buffer as its second argument. The instance argument also cannot
|
||||
be omitted.
|
||||
|
||||
WMxx ACPI methods
|
||||
-----------------
|
||||
|
||||
Used for executing WMI methods associated with a data block. The last two
|
||||
characters of the ACPI method name are the method ID of the data block
|
||||
containing the WMI methods. Their first parameter is a integer describing the
|
||||
instance which methods should be executed. The second parameter is an integer
|
||||
describing the WMI method ID to execute, and the third parameter is a buffer
|
||||
containing the WMI method parameters. If the data block is marked as containing
|
||||
an ASCIZ string, then this buffer should contain an ASCIZ string. The ACPI
|
||||
method will return the result of the executed WMI method.
|
||||
|
||||
WExx ACPI methods
|
||||
-----------------
|
||||
|
||||
Used for optionally enabling/disabling WMI events, the last two characters of
|
||||
the ACPI method are the notification ID of the data block describing the WMI
|
||||
event as hexadecimal value. Their first parameter is an integer with a value
|
||||
of 0 if the WMI event should be disabled, other values will enable
|
||||
the WMI event.
|
||||
|
||||
WCxx ACPI methods
|
||||
-----------------
|
||||
Similar to the ``WExx`` ACPI methods, except that it controls data collection
|
||||
instead of events and thus the last two characters of the ACPI method name are
|
||||
the method ID of the data block to enable/disable.
|
||||
|
||||
_WED ACPI method
|
||||
----------------
|
||||
|
||||
Used to retrieve additional WMI event data, its single parameter is a integer
|
||||
holding the notification ID of the event.
|
||||
296
Documentation/wmi/devices/dell-wmi-ddv.rst
Normal file
296
Documentation/wmi/devices/dell-wmi-ddv.rst
Normal file
@ -0,0 +1,296 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
============================================
|
||||
Dell DDV WMI interface driver (dell-wmi-ddv)
|
||||
============================================
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Many Dell notebooks made after ~2020 support a WMI-based interface for
|
||||
retrieving various system data like battery temperature, ePPID, diagostic data
|
||||
and fan/thermal sensor data.
|
||||
|
||||
This interface is likely used by the `Dell Data Vault` software on Windows,
|
||||
so it was called `DDV`. Currently the ``dell-wmi-ddv`` driver supports
|
||||
version 2 and 3 of the interface, with support for new interface versions
|
||||
easily added.
|
||||
|
||||
.. warning:: The interface is regarded as internal by Dell, so no vendor
|
||||
documentation is available. All knowledge was thus obtained by
|
||||
trial-and-error, please keep that in mind.
|
||||
|
||||
Dell ePPID (electronic Piece Part Identification)
|
||||
=================================================
|
||||
|
||||
The Dell ePPID is used to uniquely identify components in Dell machines,
|
||||
including batteries. It has a form similar to `CC-PPPPPP-MMMMM-YMD-SSSS-FFF`
|
||||
and contains the following information:
|
||||
|
||||
* Country code of origin (CC).
|
||||
* Part number with the first character being a filling number (PPPPPP).
|
||||
* Manufacture Identification (MMMMM).
|
||||
* Manufacturing Year/Month/Date (YMD) in base 36, with Y being the last digit
|
||||
of the year.
|
||||
* Manufacture Sequence Number (SSSS).
|
||||
* Optional Firmware Version/Revision (FFF).
|
||||
|
||||
The `eppidtool <https://pypi.org/project/eppidtool>`_ python utility can be used
|
||||
to decode and display this information.
|
||||
|
||||
All information regarding the Dell ePPID was gathered using Dell support
|
||||
documentation and `this website <https://telcontar.net/KBK/Dell/date_codes>`_.
|
||||
|
||||
WMI interface description
|
||||
=========================
|
||||
|
||||
The WMI interface description can be decoded from the embedded binary MOF (bmof)
|
||||
data using the `bmfdec <https://github.com/pali/bmfdec>`_ utility:
|
||||
|
||||
::
|
||||
|
||||
[WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x409"), Description("WMI Function"), guid("{8A42EA14-4F2A-FD45-6422-0087F7A7E608}")]
|
||||
class DDVWmiMethodFunction {
|
||||
[key, read] string InstanceName;
|
||||
[read] boolean Active;
|
||||
|
||||
[WmiMethodId(1), Implemented, read, write, Description("Return Battery Design Capacity.")] void BatteryDesignCapacity([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(2), Implemented, read, write, Description("Return Battery Full Charge Capacity.")] void BatteryFullChargeCapacity([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(3), Implemented, read, write, Description("Return Battery Manufacture Name.")] void BatteryManufactureName([in] uint32 arg2, [out] string argr);
|
||||
[WmiMethodId(4), Implemented, read, write, Description("Return Battery Manufacture Date.")] void BatteryManufactureDate([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(5), Implemented, read, write, Description("Return Battery Serial Number.")] void BatterySerialNumber([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(6), Implemented, read, write, Description("Return Battery Chemistry Value.")] void BatteryChemistryValue([in] uint32 arg2, [out] string argr);
|
||||
[WmiMethodId(7), Implemented, read, write, Description("Return Battery Temperature.")] void BatteryTemperature([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(8), Implemented, read, write, Description("Return Battery Current.")] void BatteryCurrent([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(9), Implemented, read, write, Description("Return Battery Voltage.")] void BatteryVoltage([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(10), Implemented, read, write, Description("Return Battery Manufacture Access(MA code).")] void BatteryManufactureAceess([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(11), Implemented, read, write, Description("Return Battery Relative State-Of-Charge.")] void BatteryRelativeStateOfCharge([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(12), Implemented, read, write, Description("Return Battery Cycle Count")] void BatteryCycleCount([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(13), Implemented, read, write, Description("Return Battery ePPID")] void BatteryePPID([in] uint32 arg2, [out] string argr);
|
||||
[WmiMethodId(14), Implemented, read, write, Description("Return Battery Raw Analytics Start")] void BatteryeRawAnalyticsStart([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(15), Implemented, read, write, Description("Return Battery Raw Analytics")] void BatteryeRawAnalytics([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
|
||||
[WmiMethodId(16), Implemented, read, write, Description("Return Battery Design Voltage.")] void BatteryDesignVoltage([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(17), Implemented, read, write, Description("Return Battery Raw Analytics A Block")] void BatteryeRawAnalyticsABlock([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
|
||||
[WmiMethodId(18), Implemented, read, write, Description("Return Version.")] void ReturnVersion([in] uint32 arg2, [out] uint32 argr);
|
||||
[WmiMethodId(32), Implemented, read, write, Description("Return Fan Sensor Information")] void FanSensorInformation([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
|
||||
[WmiMethodId(34), Implemented, read, write, Description("Return Thermal Sensor Information")] void ThermalSensorInformation([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
|
||||
};
|
||||
|
||||
Each WMI method takes an ACPI buffer containing a 32-bit index as input argument,
|
||||
with the first 8 bit being used to specify the battery when using battery-related
|
||||
WMI methods. Other WMI methods may ignore this argument or interpret it
|
||||
differently. The WMI method output format varies:
|
||||
|
||||
* if the function has only a single output, then an ACPI object
|
||||
of the corresponding type is returned
|
||||
* if the function has multiple outputs, when an ACPI package
|
||||
containing the outputs in the same order is returned
|
||||
|
||||
The format of the output should be thoroughly checked, since many methods can
|
||||
return malformed data in case of an error.
|
||||
|
||||
The data format of many battery-related methods seems to be based on the
|
||||
`Smart Battery Data Specification`, so unknown battery-related methods are
|
||||
likely to follow this standard in some way.
|
||||
|
||||
WMI method GetBatteryDesignCapacity()
|
||||
-------------------------------------
|
||||
|
||||
Returns the design capacity of the battery in mAh as an u16.
|
||||
|
||||
WMI method BatteryFullCharge()
|
||||
------------------------------
|
||||
|
||||
Returns the full charge capacity of the battery in mAh as an u16.
|
||||
|
||||
WMI method BatteryManufactureName()
|
||||
-----------------------------------
|
||||
|
||||
Returns the manufacture name of the battery as an ASCII string.
|
||||
|
||||
WMI method BatteryManufactureDate()
|
||||
-----------------------------------
|
||||
|
||||
Returns the manufacture date of the battery as an u16.
|
||||
The date is encoded in the following manner:
|
||||
|
||||
- bits 0 to 4 contain the manufacture day.
|
||||
- bits 5 to 8 contain the manufacture month.
|
||||
- bits 9 to 15 contain the manufacture year biased by 1980.
|
||||
|
||||
.. note::
|
||||
The data format needs to be verified on more machines.
|
||||
|
||||
WMI method BatterySerialNumber()
|
||||
--------------------------------
|
||||
|
||||
Returns the serial number of the battery as an u16.
|
||||
|
||||
WMI method BatteryChemistryValue()
|
||||
----------------------------------
|
||||
|
||||
Returns the chemistry of the battery as an ASCII string.
|
||||
Known values are:
|
||||
|
||||
- "Li-I" for Li-Ion
|
||||
|
||||
WMI method BatteryTemperature()
|
||||
-------------------------------
|
||||
|
||||
Returns the temperature of the battery in tenth degree kelvin as an u16.
|
||||
|
||||
WMI method BatteryCurrent()
|
||||
---------------------------
|
||||
|
||||
Returns the current flow of the battery in mA as an s16.
|
||||
Negative values indicate discharging.
|
||||
|
||||
WMI method BatteryVoltage()
|
||||
---------------------------
|
||||
|
||||
Returns the voltage flow of the battery in mV as an u16.
|
||||
|
||||
WMI method BatteryManufactureAccess()
|
||||
-------------------------------------
|
||||
|
||||
Returns a manufacture-defined value as an u16.
|
||||
|
||||
WMI method BatteryRelativeStateOfCharge()
|
||||
-----------------------------------------
|
||||
|
||||
Returns the capacity of the battery in percent as an u16.
|
||||
|
||||
WMI method BatteryCycleCount()
|
||||
------------------------------
|
||||
|
||||
Returns the cycle count of the battery as an u16.
|
||||
|
||||
WMI method BatteryePPID()
|
||||
-------------------------
|
||||
|
||||
Returns the ePPID of the battery as an ASCII string.
|
||||
|
||||
WMI method BatteryeRawAnalyticsStart()
|
||||
--------------------------------------
|
||||
|
||||
Performs an analysis of the battery and returns a status code:
|
||||
|
||||
- ``0x0``: Success
|
||||
- ``0x1``: Interface not supported
|
||||
- ``0xfffffffe``: Error/Timeout
|
||||
|
||||
.. note::
|
||||
The meaning of this method is still largely unknown.
|
||||
|
||||
WMI method BatteryeRawAnalytics()
|
||||
---------------------------------
|
||||
|
||||
Returns a buffer usually containg 12 blocks of analytics data.
|
||||
Those blocks contain:
|
||||
- block number starting with 0 (u8)
|
||||
- 31 bytes of unknown data
|
||||
|
||||
.. note::
|
||||
The meaning of this method is still largely unknown.
|
||||
|
||||
WMI method BatteryDesignVoltage()
|
||||
---------------------------------
|
||||
|
||||
Returns the design voltage of the battery in mV as an u16.
|
||||
|
||||
WMI method BatteryeRawAnalyticsABlock()
|
||||
---------------------------------------
|
||||
|
||||
Returns a single block of analytics data, with the second byte
|
||||
of the index being used for selecting the block number.
|
||||
|
||||
*Supported since WMI interface version 3!*
|
||||
|
||||
.. note::
|
||||
The meaning of this method is still largely unknown.
|
||||
|
||||
WMI method ReturnVersion()
|
||||
--------------------------
|
||||
|
||||
Returns the WMI interface version as an u32.
|
||||
|
||||
WMI method FanSensorInformation()
|
||||
---------------------------------
|
||||
|
||||
Returns a buffer containg fan sensor entries, terminated
|
||||
with a single ``0xff``.
|
||||
Those entries contain:
|
||||
|
||||
- fan type (u8)
|
||||
- fan speed in RPM (little endian u16)
|
||||
|
||||
WMI method ThermalSensorInformation()
|
||||
-------------------------------------
|
||||
|
||||
Returns a buffer containing thermal sensor entries, terminated
|
||||
with a single ``0xff``.
|
||||
Those entries contain:
|
||||
|
||||
- thermal type (u8)
|
||||
- current temperature (s8)
|
||||
- min. temperature (s8)
|
||||
- max. temperature (s8)
|
||||
- unknown field (u8)
|
||||
|
||||
.. note::
|
||||
TODO: Find out what the meaning of the last byte is.
|
||||
|
||||
ACPI battery matching algorithm
|
||||
===============================
|
||||
|
||||
The algorithm used to match ACPI batteries to indices is based on information
|
||||
which was found inside the logging messages of the OEM software.
|
||||
|
||||
Basically for each new ACPI battery, the serial numbers of the batteries behind
|
||||
indices 1 till 3 are compared with the serial number of the ACPI battery.
|
||||
Since the serial number of the ACPI battery can either be encoded as a normal
|
||||
integer or as a hexadecimal value, both cases need to be checked. The first
|
||||
index with a matching serial number is then selected.
|
||||
|
||||
A serial number of 0 indicates that the corresponding index is not associated
|
||||
with an actual battery, or that the associated battery is not present.
|
||||
|
||||
Some machines like the Dell Inspiron 3505 only support a single battery and thus
|
||||
ignore the battery index. Because of this the driver depends on the ACPI battery
|
||||
hook mechanism to discover batteries.
|
||||
|
||||
.. note::
|
||||
The ACPI battery matching algorithm currently used inside the driver is
|
||||
outdated and does not match the algorithm described above. The reasons for
|
||||
this are differences in the handling of the ToHexString() ACPI opcode between
|
||||
Linux and Windows, which distorts the serial number of ACPI batteries on many
|
||||
machines. Until this issue is resolved, the driver cannot use the above
|
||||
algorithm.
|
||||
|
||||
Reverse-Engineering the DDV WMI interface
|
||||
=========================================
|
||||
|
||||
1. Find a supported Dell notebook, usually made after ~2020.
|
||||
2. Dump the ACPI tables and search for the WMI device (usually called "ADDV").
|
||||
3. Decode the corresponding bmof data and look at the ASL code.
|
||||
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
|
||||
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).
|
||||
|
||||
Alternatively:
|
||||
|
||||
1. Load the ``dell-wmi-ddv`` driver, use the ``force`` module param
|
||||
if necessary.
|
||||
2. Use the debugfs interface to access the raw fan/thermal sensor buffer data.
|
||||
3. Compare the data with the built-in UEFI diagnostics.
|
||||
|
||||
In case the DDV WMI interface version available on your Dell notebook is not
|
||||
supported or you are seeing unknown fan/thermal sensors, please submit a
|
||||
bugreport on `bugzilla <https://bugzilla.kernel.org>`_ so they can be added
|
||||
to the ``dell-wmi-ddv`` driver.
|
||||
|
||||
See Documentation/admin-guide/reporting-issues.rst for further information.
|
||||
22
Documentation/wmi/devices/index.rst
Normal file
22
Documentation/wmi/devices/index.rst
Normal file
@ -0,0 +1,22 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
=============================
|
||||
Driver-specific Documentation
|
||||
=============================
|
||||
|
||||
This section provides information about various devices supported by
|
||||
the Linux kernel, their protocols and driver details.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:numbered:
|
||||
:glob:
|
||||
|
||||
*
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
=======
|
||||
|
||||
* :ref:`genindex`
|
||||
25
Documentation/wmi/devices/wmi-bmof.rst
Normal file
25
Documentation/wmi/devices/wmi-bmof.rst
Normal file
@ -0,0 +1,25 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
==============================
|
||||
WMI embedded Binary MOF driver
|
||||
==============================
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Many machines embed WMI Binary MOF (Managed Object Format) metadata used to
|
||||
describe the details of their ACPI WMI interfaces. The data can be decoded
|
||||
with tools like `bmfdec <https://github.com/pali/bmfdec>`_ to obtain a
|
||||
human readable WMI interface description, which is useful for developing
|
||||
new WMI drivers.
|
||||
|
||||
The Binary MOF data can be retrieved from the ``bmof`` sysfs attribute of the
|
||||
associated WMI device. Please note that multiple WMI devices containing Binary
|
||||
MOF data can exist on a given system.
|
||||
|
||||
WMI interface
|
||||
=============
|
||||
|
||||
The Binary MOF WMI device is identified by the WMI GUID ``05901221-D566-11D1-B2F0-00A0C9062910``.
|
||||
The Binary MOF can be obtained by doing a WMI data block query. The result is
|
||||
then returned as an ACPI buffer with a variable size.
|
||||
19
Documentation/wmi/index.rst
Normal file
19
Documentation/wmi/index.rst
Normal file
@ -0,0 +1,19 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
=============
|
||||
WMI Subsystem
|
||||
=============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
acpi-interface
|
||||
devices/index
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
||||
Indices
|
||||
=======
|
||||
|
||||
* :ref:`genindex`
|
||||
70
MAINTAINERS
70
MAINTAINERS
@ -406,6 +406,13 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: drivers/acpi/arm64
|
||||
|
||||
ACPI FOR RISC-V (ACPI/riscv)
|
||||
M: Sunil V L <sunilvl@ventanamicro.com>
|
||||
L: linux-acpi@vger.kernel.org
|
||||
L: linux-riscv@lists.infradead.org
|
||||
S: Maintained
|
||||
F: drivers/acpi/riscv/
|
||||
|
||||
ACPI PCC(Platform Communication Channel) MAILBOX DRIVER
|
||||
M: Sudeep Holla <sudeep.holla@arm.com>
|
||||
L: linux-acpi@vger.kernel.org
|
||||
@ -449,6 +456,8 @@ F: include/linux/acpi_viot.h
|
||||
ACPI WMI DRIVER
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
S: Orphan
|
||||
F: Documentation/driver-api/wmi.rst
|
||||
F: Documentation/wmi/
|
||||
F: drivers/platform/x86/wmi.c
|
||||
F: include/uapi/linux/wmi.h
|
||||
|
||||
@ -2938,7 +2947,6 @@ F: Documentation/devicetree/bindings/arm/ti/k3.yaml
|
||||
F: Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
|
||||
F: arch/arm64/boot/dts/ti/Makefile
|
||||
F: arch/arm64/boot/dts/ti/k3-*
|
||||
F: include/dt-bindings/pinctrl/k3.h
|
||||
|
||||
ARM/TOSHIBA VISCONTI ARCHITECTURE
|
||||
M: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
|
||||
@ -5195,6 +5203,13 @@ S: Maintained
|
||||
F: drivers/cxl/
|
||||
F: include/uapi/linux/cxl_mem.h
|
||||
|
||||
COMPUTE EXPRESS LINK PMU (CPMU)
|
||||
M: Jonathan Cameron <jonathan.cameron@huawei.com>
|
||||
L: linux-cxl@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/admin-guide/perf/cxl.rst
|
||||
F: drivers/perf/cxl_pmu.c
|
||||
|
||||
CONEXANT ACCESSRUNNER USB DRIVER
|
||||
L: accessrunner-general@lists.sourceforge.net
|
||||
S: Orphan
|
||||
@ -5725,10 +5740,7 @@ DC395x SCSI driver
|
||||
M: Oliver Neukum <oliver@neukum.org>
|
||||
M: Ali Akcaagac <aliakc@web.de>
|
||||
M: Jamie Lenehan <lenehan@twibble.org>
|
||||
L: dc395x@twibble.org
|
||||
S: Maintained
|
||||
W: http://twibble.org/dist/dc395x/
|
||||
W: http://lists.twibble.org/mailman/listinfo/dc395x/
|
||||
F: Documentation/scsi/dc395x.rst
|
||||
F: drivers/scsi/dc395x.*
|
||||
|
||||
@ -5838,6 +5850,7 @@ M: Armin Wolf <W_Armin@gmx.de>
|
||||
S: Maintained
|
||||
F: Documentation/ABI/testing/debugfs-dell-wmi-ddv
|
||||
F: Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
|
||||
F: Documentation/wmi/devices/dell-wmi-ddv.rst
|
||||
F: drivers/platform/x86/dell/dell-wmi-ddv.c
|
||||
|
||||
DELL WMI DESCRIPTOR DRIVER
|
||||
@ -8712,6 +8725,9 @@ F: drivers/input/touchscreen/resistive-adc-touch.c
|
||||
GENERIC STRING LIBRARY
|
||||
R: Andy Shevchenko <andy@kernel.org>
|
||||
S: Maintained
|
||||
F: include/linux/string.h
|
||||
F: include/linux/string_choices.h
|
||||
F: include/linux/string_helpers.h
|
||||
F: lib/string.c
|
||||
F: lib/string_helpers.c
|
||||
F: lib/test-string_helpers.c
|
||||
@ -10867,7 +10883,6 @@ S: Maintained
|
||||
F: drivers/net/ethernet/sgi/ioc3-eth.c
|
||||
|
||||
IOMAP FILESYSTEM LIBRARY
|
||||
M: Christoph Hellwig <hch@infradead.org>
|
||||
M: Darrick J. Wong <djwong@kernel.org>
|
||||
L: linux-xfs@vger.kernel.org
|
||||
L: linux-fsdevel@vger.kernel.org
|
||||
@ -11448,7 +11463,13 @@ F: arch/mips/include/uapi/asm/kvm*
|
||||
F: arch/mips/kvm/
|
||||
|
||||
KERNEL VIRTUAL MACHINE FOR POWERPC (KVM/powerpc)
|
||||
M: Michael Ellerman <mpe@ellerman.id.au>
|
||||
R: Nicholas Piggin <npiggin@gmail.com>
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
L: kvm@vger.kernel.org
|
||||
S: Maintained (Book3S 64-bit HV)
|
||||
S: Odd fixes (Book3S 64-bit PR)
|
||||
S: Orphan (Book3E and 32-bit)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
|
||||
F: arch/powerpc/include/asm/kvm*
|
||||
F: arch/powerpc/include/uapi/asm/kvm*
|
||||
@ -11981,11 +12002,12 @@ F: lib/linear_ranges.c
|
||||
F: lib/test_linear_ranges.c
|
||||
|
||||
LINUX FOR POWER MACINTOSH
|
||||
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
S: Odd Fixes
|
||||
S: Orphan
|
||||
F: arch/powerpc/platforms/powermac/
|
||||
F: drivers/macintosh/
|
||||
X: drivers/macintosh/adb-iop.c
|
||||
X: drivers/macintosh/via-macii.c
|
||||
|
||||
LINUX FOR POWERPC (32-BIT AND 64-BIT)
|
||||
M: Michael Ellerman <mpe@ellerman.id.au>
|
||||
@ -13728,6 +13750,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git
|
||||
F: Documentation/ABI/stable/sysfs-bus-mhi
|
||||
F: Documentation/mhi/
|
||||
F: drivers/bus/mhi/
|
||||
F: drivers/pci/endpoint/functions/pci-epf-mhi.c
|
||||
F: include/linux/mhi.h
|
||||
|
||||
MICROBLAZE ARCHITECTURE
|
||||
@ -16780,7 +16803,7 @@ PIN CONTROLLER - QUALCOMM
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pinctrl/qcom,*.txt
|
||||
F: Documentation/devicetree/bindings/pinctrl/qcom,*
|
||||
F: drivers/pinctrl/qcom/
|
||||
|
||||
PIN CONTROLLER - RENESAS
|
||||
@ -18904,6 +18927,16 @@ F: include/linux/wait.h
|
||||
F: include/uapi/linux/sched.h
|
||||
F: kernel/sched/
|
||||
|
||||
SCSI LIBSAS SUBSYSTEM
|
||||
R: John Garry <john.g.garry@oracle.com>
|
||||
R: Jason Yan <yanaijie@huawei.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/scsi/libsas/
|
||||
F: include/scsi/libsas.h
|
||||
F: include/scsi/sas_ata.h
|
||||
F: Documentation/scsi/libsas.rst
|
||||
|
||||
SCSI RDMA PROTOCOL (SRP) INITIATOR
|
||||
M: Bart Van Assche <bvanassche@acm.org>
|
||||
L: linux-rdma@vger.kernel.org
|
||||
@ -20238,6 +20271,13 @@ F: Documentation/devicetree/bindings/clock/starfive,jh71*.yaml
|
||||
F: drivers/clk/starfive/clk-starfive-jh71*
|
||||
F: include/dt-bindings/clock/starfive?jh71*.h
|
||||
|
||||
STARFIVE CRYPTO DRIVER
|
||||
M: Jia Jie Ho <jiajie.ho@starfivetech.com>
|
||||
M: William Qiu <william.qiu@starfivetech.com>
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/crypto/starfive*
|
||||
F: drivers/crypto/starfive/
|
||||
|
||||
STARFIVE JH71X0 PINCTRL DRIVERS
|
||||
M: Emil Renner Berthing <kernel@esmil.dk>
|
||||
M: Jianlong Huang <jianlong.huang@starfivetech.com>
|
||||
@ -22227,6 +22267,13 @@ F: Documentation/filesystems/vfat.rst
|
||||
F: fs/fat/
|
||||
F: tools/testing/selftests/filesystems/fat/
|
||||
|
||||
VFIO CDX DRIVER
|
||||
M: Nipun Gupta <nipun.gupta@amd.com>
|
||||
M: Nikhil Agarwal <nikhil.agarwal@amd.com>
|
||||
L: kvm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/vfio/cdx/*
|
||||
|
||||
VFIO DRIVER
|
||||
M: Alex Williamson <alex.williamson@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
@ -22889,6 +22936,13 @@ L: linux-wireless@vger.kernel.org
|
||||
S: Odd fixes
|
||||
F: drivers/net/wireless/legacy/wl3501*
|
||||
|
||||
WMI BINARY MOF DRIVER
|
||||
L: platform-drivers-x86@vger.kernel.org
|
||||
S: Orphan
|
||||
F: Documentation/ABI/stable/sysfs-platform-wmi-bmof
|
||||
F: Documentation/wmi/devices/wmi-bmof.rst
|
||||
F: drivers/platform/x86/wmi-bmof.c
|
||||
|
||||
WOLFSON MICROELECTRONICS DRIVERS
|
||||
L: patches@opensource.cirrus.com
|
||||
S: Supported
|
||||
|
||||
94
Makefile
94
Makefile
@ -38,6 +38,10 @@ __all:
|
||||
# descending is started. They are now explicitly listed as the
|
||||
# prepare rule.
|
||||
|
||||
this-makefile := $(lastword $(MAKEFILE_LIST))
|
||||
export abs_srctree := $(realpath $(dir $(this-makefile)))
|
||||
export abs_objtree := $(CURDIR)
|
||||
|
||||
ifneq ($(sub_make_done),1)
|
||||
|
||||
# Do not use make's built-in rules and variables
|
||||
@ -185,20 +189,8 @@ $(if $(abs_objtree),, \
|
||||
|
||||
# $(realpath ...) resolves symlinks
|
||||
abs_objtree := $(realpath $(abs_objtree))
|
||||
else
|
||||
abs_objtree := $(CURDIR)
|
||||
endif # ifneq ($(KBUILD_OUTPUT),)
|
||||
|
||||
ifeq ($(abs_objtree),$(CURDIR))
|
||||
# Suppress "Entering directory ..." unless we are changing the work directory.
|
||||
MAKEFLAGS += --no-print-directory
|
||||
else
|
||||
need-sub-make := 1
|
||||
endif
|
||||
|
||||
this-makefile := $(lastword $(MAKEFILE_LIST))
|
||||
abs_srctree := $(realpath $(dir $(this-makefile)))
|
||||
|
||||
ifneq ($(words $(subst :, ,$(abs_srctree))), 1)
|
||||
$(error source directory cannot contain spaces or colons)
|
||||
endif
|
||||
@ -211,9 +203,25 @@ need-sub-make := 1
|
||||
$(this-makefile): ;
|
||||
endif
|
||||
|
||||
export abs_srctree abs_objtree
|
||||
export sub_make_done := 1
|
||||
|
||||
endif # sub_make_done
|
||||
|
||||
ifeq ($(abs_objtree),$(CURDIR))
|
||||
# Suppress "Entering directory ..." if we are at the final work directory.
|
||||
no-print-directory := --no-print-directory
|
||||
else
|
||||
# Recursion to show "Entering directory ..."
|
||||
need-sub-make := 1
|
||||
endif
|
||||
|
||||
ifeq ($(filter --no-print-directory, $(MAKEFLAGS)),)
|
||||
# If --no-print-directory is unset, recurse once again to set it.
|
||||
# You may end up recursing into __sub-make twice. This is needed due to the
|
||||
# behavior change in GNU Make 4.4.1.
|
||||
need-sub-make := 1
|
||||
endif
|
||||
|
||||
ifeq ($(need-sub-make),1)
|
||||
|
||||
PHONY += $(MAKECMDGOALS) __sub-make
|
||||
@ -223,18 +231,12 @@ $(filter-out $(this-makefile), $(MAKECMDGOALS)) __all: __sub-make
|
||||
|
||||
# Invoke a second make in the output directory, passing relevant variables
|
||||
__sub-make:
|
||||
$(Q)$(MAKE) -C $(abs_objtree) -f $(abs_srctree)/Makefile $(MAKECMDGOALS)
|
||||
$(Q)$(MAKE) $(no-print-directory) -C $(abs_objtree) \
|
||||
-f $(abs_srctree)/Makefile $(MAKECMDGOALS)
|
||||
|
||||
endif # need-sub-make
|
||||
endif # sub_make_done
|
||||
else # need-sub-make
|
||||
|
||||
# We process the rest of the Makefile if this is the final invocation of make
|
||||
ifeq ($(need-sub-make),)
|
||||
|
||||
# Do not print "Entering directory ...",
|
||||
# but we want to display it when entering to the output directory
|
||||
# so that IDEs/editors are able to understand relative filenames.
|
||||
MAKEFLAGS += --no-print-directory
|
||||
|
||||
ifeq ($(abs_srctree),$(abs_objtree))
|
||||
# building in the source tree
|
||||
@ -1199,28 +1201,12 @@ endif
|
||||
export KBUILD_VMLINUX_LIBS
|
||||
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
|
||||
|
||||
# Recurse until adjust_autoksyms.sh is satisfied
|
||||
PHONY += autoksyms_recursive
|
||||
ifdef CONFIG_TRIM_UNUSED_KSYMS
|
||||
# For the kernel to actually contain only the needed exported symbols,
|
||||
# we have to build modules as well to determine what those symbols are.
|
||||
# (this can be evaluated only once include/config/auto.conf has been included)
|
||||
KBUILD_MODULES := 1
|
||||
|
||||
autoksyms_recursive: $(build-dir) modules.order
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
|
||||
"$(MAKE) -f $(srctree)/Makefile autoksyms_recursive"
|
||||
endif
|
||||
|
||||
autoksyms_h := $(if $(CONFIG_TRIM_UNUSED_KSYMS), include/generated/autoksyms.h)
|
||||
|
||||
quiet_cmd_autoksyms_h = GEN $@
|
||||
cmd_autoksyms_h = mkdir -p $(dir $@); \
|
||||
$(CONFIG_SHELL) $(srctree)/scripts/gen_autoksyms.sh $@
|
||||
|
||||
$(autoksyms_h):
|
||||
$(call cmd,autoksyms_h)
|
||||
|
||||
# '$(AR) mPi' needs 'T' to workaround the bug of llvm-ar <= 14
|
||||
quiet_cmd_ar_vmlinux.a = AR $@
|
||||
cmd_ar_vmlinux.a = \
|
||||
@ -1229,7 +1215,7 @@ quiet_cmd_ar_vmlinux.a = AR $@
|
||||
$(AR) mPiT $$($(AR) t $@ | sed -n 1p) $@ $$($(AR) t $@ | grep -F -f $(srctree)/scripts/head-object-list.txt)
|
||||
|
||||
targets += vmlinux.a
|
||||
vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt autoksyms_recursive FORCE
|
||||
vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
|
||||
$(call if_changed,ar_vmlinux.a)
|
||||
|
||||
PHONY += vmlinux_o
|
||||
@ -1285,7 +1271,7 @@ scripts: scripts_basic scripts_dtc
|
||||
PHONY += prepare archprepare
|
||||
|
||||
archprepare: outputmakefile archheaders archscripts scripts include/config/kernel.release \
|
||||
asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
|
||||
asm-generic $(version_h) include/generated/utsrelease.h \
|
||||
include/generated/compile.h include/generated/autoconf.h remove-stale-files
|
||||
|
||||
prepare0: archprepare
|
||||
@ -1567,6 +1553,8 @@ modules_sign_only := y
|
||||
endif
|
||||
endif
|
||||
|
||||
endif # CONFIG_MODULES
|
||||
|
||||
modinst_pre :=
|
||||
ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
|
||||
modinst_pre := __modinst_pre
|
||||
@ -1577,18 +1565,18 @@ PHONY += __modinst_pre
|
||||
__modinst_pre:
|
||||
@rm -rf $(MODLIB)/kernel
|
||||
@rm -f $(MODLIB)/source
|
||||
@mkdir -p $(MODLIB)/kernel
|
||||
@mkdir -p $(MODLIB)
|
||||
ifdef CONFIG_MODULES
|
||||
@ln -s $(abspath $(srctree)) $(MODLIB)/source
|
||||
@if [ ! $(objtree) -ef $(MODLIB)/build ]; then \
|
||||
rm -f $(MODLIB)/build ; \
|
||||
ln -s $(CURDIR) $(MODLIB)/build ; \
|
||||
fi
|
||||
@sed 's:^\(.*\)\.o$$:kernel/\1.ko:' modules.order > $(MODLIB)/modules.order
|
||||
endif
|
||||
@cp -f modules.builtin $(MODLIB)/
|
||||
@cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/
|
||||
|
||||
endif # CONFIG_MODULES
|
||||
|
||||
###
|
||||
# Cleaning is done on three levels.
|
||||
# make clean Delete most generated files
|
||||
@ -1930,6 +1918,13 @@ help:
|
||||
@echo ' clean - remove generated files in module directory only'
|
||||
@echo ''
|
||||
|
||||
__external_modules_error:
|
||||
@echo >&2 '***'
|
||||
@echo >&2 '*** The present kernel disabled CONFIG_MODULES.'
|
||||
@echo >&2 '*** You cannot build or install external modules.'
|
||||
@echo >&2 '***'
|
||||
@false
|
||||
|
||||
endif # KBUILD_EXTMOD
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
@ -1966,13 +1961,10 @@ else # CONFIG_MODULES
|
||||
# Modules not configured
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
modules modules_install:
|
||||
@echo >&2 '***'
|
||||
@echo >&2 '*** The present kernel configuration has modules disabled.'
|
||||
@echo >&2 '*** To use the module feature, please run "make menuconfig" etc.'
|
||||
@echo >&2 '*** to enable CONFIG_MODULES.'
|
||||
@echo >&2 '***'
|
||||
@exit 1
|
||||
PHONY += __external_modules_error
|
||||
|
||||
modules modules_install: __external_modules_error
|
||||
@:
|
||||
|
||||
KBUILD_MODULES :=
|
||||
|
||||
@ -2045,7 +2037,7 @@ clean: $(clean-dirs)
|
||||
-o -name '*.dtb.S' -o -name '*.dtbo.S' \
|
||||
-o -name '*.dt.yaml' \
|
||||
-o -name '*.dwo' -o -name '*.lst' \
|
||||
-o -name '*.su' -o -name '*.mod' -o -name '*.usyms' \
|
||||
-o -name '*.su' -o -name '*.mod' \
|
||||
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
|
||||
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
|
||||
-o -name '*.asn1.[ch]' \
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
|
||||
#include <asm/dwarf.h>
|
||||
|
||||
#define ASM_NL ` /* use '`' to mark new line in macro */
|
||||
#define __ALIGN .align 4
|
||||
#define __ALIGN_STR __stringify(__ALIGN)
|
||||
|
||||
#ifdef __ASSEMBLY__
|
||||
|
||||
.macro ST2 e, o, off
|
||||
@ -28,10 +32,6 @@
|
||||
#endif
|
||||
.endm
|
||||
|
||||
#define ASM_NL ` /* use '`' to mark new line in macro */
|
||||
#define __ALIGN .align 4
|
||||
#define __ALIGN_STR __stringify(__ALIGN)
|
||||
|
||||
/* annotation for data we want in DCCM - if enabled in .config */
|
||||
.macro ARCFP_DATA nm
|
||||
#ifdef CONFIG_ARC_HAS_DCCM
|
||||
|
||||
@ -26,8 +26,8 @@
|
||||
|
||||
#include "sha1.h"
|
||||
|
||||
asmlinkage void sha1_transform_neon(void *state_h, const char *data,
|
||||
unsigned int rounds);
|
||||
asmlinkage void sha1_transform_neon(struct sha1_state *state_h,
|
||||
const u8 *data, int rounds);
|
||||
|
||||
static int sha1_neon_update(struct shash_desc *desc, const u8 *data,
|
||||
unsigned int len)
|
||||
@ -39,8 +39,7 @@ static int sha1_neon_update(struct shash_desc *desc, const u8 *data,
|
||||
return sha1_update_arm(desc, data, len);
|
||||
|
||||
kernel_neon_begin();
|
||||
sha1_base_do_update(desc, data, len,
|
||||
(sha1_block_fn *)sha1_transform_neon);
|
||||
sha1_base_do_update(desc, data, len, sha1_transform_neon);
|
||||
kernel_neon_end();
|
||||
|
||||
return 0;
|
||||
@ -54,9 +53,8 @@ static int sha1_neon_finup(struct shash_desc *desc, const u8 *data,
|
||||
|
||||
kernel_neon_begin();
|
||||
if (len)
|
||||
sha1_base_do_update(desc, data, len,
|
||||
(sha1_block_fn *)sha1_transform_neon);
|
||||
sha1_base_do_finalize(desc, (sha1_block_fn *)sha1_transform_neon);
|
||||
sha1_base_do_update(desc, data, len, sha1_transform_neon);
|
||||
sha1_base_do_finalize(desc, sha1_transform_neon);
|
||||
kernel_neon_end();
|
||||
|
||||
return sha1_base_finish(desc, out);
|
||||
|
||||
@ -21,8 +21,8 @@
|
||||
|
||||
#include "sha256_glue.h"
|
||||
|
||||
asmlinkage void sha256_block_data_order_neon(u32 *digest, const void *data,
|
||||
unsigned int num_blks);
|
||||
asmlinkage void sha256_block_data_order_neon(struct sha256_state *digest,
|
||||
const u8 *data, int num_blks);
|
||||
|
||||
static int crypto_sha256_neon_update(struct shash_desc *desc, const u8 *data,
|
||||
unsigned int len)
|
||||
@ -34,8 +34,7 @@ static int crypto_sha256_neon_update(struct shash_desc *desc, const u8 *data,
|
||||
return crypto_sha256_arm_update(desc, data, len);
|
||||
|
||||
kernel_neon_begin();
|
||||
sha256_base_do_update(desc, data, len,
|
||||
(sha256_block_fn *)sha256_block_data_order_neon);
|
||||
sha256_base_do_update(desc, data, len, sha256_block_data_order_neon);
|
||||
kernel_neon_end();
|
||||
|
||||
return 0;
|
||||
@ -50,9 +49,8 @@ static int crypto_sha256_neon_finup(struct shash_desc *desc, const u8 *data,
|
||||
kernel_neon_begin();
|
||||
if (len)
|
||||
sha256_base_do_update(desc, data, len,
|
||||
(sha256_block_fn *)sha256_block_data_order_neon);
|
||||
sha256_base_do_finalize(desc,
|
||||
(sha256_block_fn *)sha256_block_data_order_neon);
|
||||
sha256_block_data_order_neon);
|
||||
sha256_base_do_finalize(desc, sha256_block_data_order_neon);
|
||||
kernel_neon_end();
|
||||
|
||||
return sha256_base_finish(desc, out);
|
||||
|
||||
@ -20,8 +20,8 @@
|
||||
MODULE_ALIAS_CRYPTO("sha384-neon");
|
||||
MODULE_ALIAS_CRYPTO("sha512-neon");
|
||||
|
||||
asmlinkage void sha512_block_data_order_neon(u64 *state, u8 const *src,
|
||||
int blocks);
|
||||
asmlinkage void sha512_block_data_order_neon(struct sha512_state *state,
|
||||
const u8 *src, int blocks);
|
||||
|
||||
static int sha512_neon_update(struct shash_desc *desc, const u8 *data,
|
||||
unsigned int len)
|
||||
@ -33,8 +33,7 @@ static int sha512_neon_update(struct shash_desc *desc, const u8 *data,
|
||||
return sha512_arm_update(desc, data, len);
|
||||
|
||||
kernel_neon_begin();
|
||||
sha512_base_do_update(desc, data, len,
|
||||
(sha512_block_fn *)sha512_block_data_order_neon);
|
||||
sha512_base_do_update(desc, data, len, sha512_block_data_order_neon);
|
||||
kernel_neon_end();
|
||||
|
||||
return 0;
|
||||
@ -49,9 +48,8 @@ static int sha512_neon_finup(struct shash_desc *desc, const u8 *data,
|
||||
kernel_neon_begin();
|
||||
if (len)
|
||||
sha512_base_do_update(desc, data, len,
|
||||
(sha512_block_fn *)sha512_block_data_order_neon);
|
||||
sha512_base_do_finalize(desc,
|
||||
(sha512_block_fn *)sha512_block_data_order_neon);
|
||||
sha512_block_data_order_neon);
|
||||
sha512_base_do_finalize(desc, sha512_block_data_order_neon);
|
||||
kernel_neon_end();
|
||||
|
||||
return sha512_base_finish(desc, out);
|
||||
|
||||
@ -202,6 +202,7 @@ config ARM64
|
||||
select HAVE_FTRACE_MCOUNT_RECORD
|
||||
select HAVE_FUNCTION_TRACER
|
||||
select HAVE_FUNCTION_ERROR_INJECTION
|
||||
select HAVE_FUNCTION_GRAPH_RETVAL if HAVE_FUNCTION_GRAPH_TRACER
|
||||
select HAVE_FUNCTION_GRAPH_TRACER
|
||||
select HAVE_GCC_PLUGINS
|
||||
select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && \
|
||||
|
||||
@ -12,8 +12,9 @@
|
||||
#include <crypto/internal/simd.h>
|
||||
#include <crypto/sha2.h>
|
||||
#include <crypto/sha256_base.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/string.h>
|
||||
#include <linux/types.h>
|
||||
|
||||
MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash for arm64");
|
||||
MODULE_AUTHOR("Andy Polyakov <appro@openssl.org>");
|
||||
|
||||
@ -316,12 +316,12 @@
|
||||
_for n, 0, 15, _sve_str_p \n, \nxbase, \n - 16
|
||||
cbz \save_ffr, 921f
|
||||
_sve_rdffr 0
|
||||
_sve_str_p 0, \nxbase
|
||||
_sve_ldr_p 0, \nxbase, -16
|
||||
b 922f
|
||||
921:
|
||||
str xzr, [x\nxbase] // Zero out FFR
|
||||
_sve_pfalse 0 // Zero out FFR
|
||||
922:
|
||||
_sve_str_p 0, \nxbase
|
||||
_sve_ldr_p 0, \nxbase, -16
|
||||
mrs x\nxtmp, fpsr
|
||||
str w\nxtmp, [\xpfpsr]
|
||||
mrs x\nxtmp, fpcr
|
||||
|
||||
@ -192,4 +192,26 @@ static inline bool arch_syscall_match_sym_name(const char *sym,
|
||||
}
|
||||
#endif /* ifndef __ASSEMBLY__ */
|
||||
|
||||
#ifndef __ASSEMBLY__
|
||||
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
|
||||
struct fgraph_ret_regs {
|
||||
/* x0 - x7 */
|
||||
unsigned long regs[8];
|
||||
|
||||
unsigned long fp;
|
||||
unsigned long __unused;
|
||||
};
|
||||
|
||||
static inline unsigned long fgraph_ret_regs_return_value(struct fgraph_ret_regs *ret_regs)
|
||||
{
|
||||
return ret_regs->regs[0];
|
||||
}
|
||||
|
||||
static inline unsigned long fgraph_ret_regs_frame_pointer(struct fgraph_ret_regs *ret_regs)
|
||||
{
|
||||
return ret_regs->fp;
|
||||
}
|
||||
#endif /* ifdef CONFIG_FUNCTION_GRAPH_TRACER */
|
||||
#endif
|
||||
|
||||
#endif /* __ASM_FTRACE_H */
|
||||
|
||||
@ -200,6 +200,19 @@ int main(void)
|
||||
#endif
|
||||
#ifdef CONFIG_FUNCTION_TRACER
|
||||
DEFINE(FTRACE_OPS_FUNC, offsetof(struct ftrace_ops, func));
|
||||
#endif
|
||||
BLANK();
|
||||
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
|
||||
DEFINE(FGRET_REGS_X0, offsetof(struct fgraph_ret_regs, regs[0]));
|
||||
DEFINE(FGRET_REGS_X1, offsetof(struct fgraph_ret_regs, regs[1]));
|
||||
DEFINE(FGRET_REGS_X2, offsetof(struct fgraph_ret_regs, regs[2]));
|
||||
DEFINE(FGRET_REGS_X3, offsetof(struct fgraph_ret_regs, regs[3]));
|
||||
DEFINE(FGRET_REGS_X4, offsetof(struct fgraph_ret_regs, regs[4]));
|
||||
DEFINE(FGRET_REGS_X5, offsetof(struct fgraph_ret_regs, regs[5]));
|
||||
DEFINE(FGRET_REGS_X6, offsetof(struct fgraph_ret_regs, regs[6]));
|
||||
DEFINE(FGRET_REGS_X7, offsetof(struct fgraph_ret_regs, regs[7]));
|
||||
DEFINE(FGRET_REGS_FP, offsetof(struct fgraph_ret_regs, fp));
|
||||
DEFINE(FGRET_REGS_SIZE, sizeof(struct fgraph_ret_regs));
|
||||
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
|
||||
DEFINE(FTRACE_OPS_DIRECT_CALL, offsetof(struct ftrace_ops, direct_call));
|
||||
#endif
|
||||
|
||||
@ -330,22 +330,23 @@ SYM_FUNC_END(ftrace_stub_graph)
|
||||
*/
|
||||
SYM_CODE_START(return_to_handler)
|
||||
/* save return value regs */
|
||||
sub sp, sp, #64
|
||||
stp x0, x1, [sp]
|
||||
stp x2, x3, [sp, #16]
|
||||
stp x4, x5, [sp, #32]
|
||||
stp x6, x7, [sp, #48]
|
||||
sub sp, sp, #FGRET_REGS_SIZE
|
||||
stp x0, x1, [sp, #FGRET_REGS_X0]
|
||||
stp x2, x3, [sp, #FGRET_REGS_X2]
|
||||
stp x4, x5, [sp, #FGRET_REGS_X4]
|
||||
stp x6, x7, [sp, #FGRET_REGS_X6]
|
||||
str x29, [sp, #FGRET_REGS_FP] // parent's fp
|
||||
|
||||
mov x0, x29 // parent's fp
|
||||
bl ftrace_return_to_handler// addr = ftrace_return_to_hander(fp);
|
||||
mov x30, x0 // restore the original return address
|
||||
mov x0, sp
|
||||
bl ftrace_return_to_handler // addr = ftrace_return_to_hander(regs);
|
||||
mov x30, x0 // restore the original return address
|
||||
|
||||
/* restore return value regs */
|
||||
ldp x0, x1, [sp]
|
||||
ldp x2, x3, [sp, #16]
|
||||
ldp x4, x5, [sp, #32]
|
||||
ldp x6, x7, [sp, #48]
|
||||
add sp, sp, #64
|
||||
ldp x0, x1, [sp, #FGRET_REGS_X0]
|
||||
ldp x2, x3, [sp, #FGRET_REGS_X2]
|
||||
ldp x4, x5, [sp, #FGRET_REGS_X4]
|
||||
ldp x6, x7, [sp, #FGRET_REGS_X6]
|
||||
add sp, sp, #FGRET_REGS_SIZE
|
||||
|
||||
ret
|
||||
SYM_CODE_END(return_to_handler)
|
||||
|
||||
@ -64,6 +64,7 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
|
||||
struct uprobe_task *utask = current->utask;
|
||||
|
||||
WARN_ON_ONCE(current->thread.trap_no != UPROBE_TRAP_NR);
|
||||
current->thread.trap_no = utask->autask.saved_trap_no;
|
||||
|
||||
instruction_pointer_set(regs, utask->vaddr + auprobe->insn_size);
|
||||
|
||||
@ -101,6 +102,8 @@ void arch_uprobe_abort_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
|
||||
{
|
||||
struct uprobe_task *utask = current->utask;
|
||||
|
||||
current->thread.trap_no = utask->autask.saved_trap_no;
|
||||
|
||||
/*
|
||||
* Task has received a fatal signal, so reset back to probed
|
||||
* address.
|
||||
|
||||
@ -1,6 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
generated-y += syscall_table.h
|
||||
generic-y += agp.h
|
||||
generic-y += export.h
|
||||
generic-y += kvm_para.h
|
||||
generic-y += mcs_spinlock.h
|
||||
generic-y += vtime.h
|
||||
|
||||
@ -1,3 +0,0 @@
|
||||
/* EXPORT_DATA_SYMBOL != EXPORT_SYMBOL here */
|
||||
#define KSYM_FUNC(name) @fptr(name)
|
||||
#include <asm-generic/export.h>
|
||||
@ -170,7 +170,7 @@ RestRR: \
|
||||
__PAGE_ALIGNED_DATA
|
||||
|
||||
.global empty_zero_page
|
||||
EXPORT_DATA_SYMBOL_GPL(empty_zero_page)
|
||||
EXPORT_SYMBOL_GPL(empty_zero_page)
|
||||
empty_zero_page:
|
||||
.skip PAGE_SIZE
|
||||
|
||||
|
||||
@ -87,7 +87,7 @@
|
||||
|
||||
.align 32768 // align on 32KB boundary
|
||||
.global ia64_ivt
|
||||
EXPORT_DATA_SYMBOL(ia64_ivt)
|
||||
EXPORT_SYMBOL(ia64_ivt)
|
||||
ia64_ivt:
|
||||
/////////////////////////////////////////////////////////////////////////////////////////
|
||||
// 0x0000 Entry 0 (size 64 bundles) VHPT Translation (8,20,47)
|
||||
|
||||
@ -5,6 +5,7 @@ config LOONGARCH
|
||||
select ACPI
|
||||
select ACPI_GENERIC_GSI if ACPI
|
||||
select ACPI_MCFG if ACPI
|
||||
select ACPI_PPTT if ACPI
|
||||
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
|
||||
select ARCH_BINFMT_ELF_STATE
|
||||
select ARCH_ENABLE_MEMORY_HOTPLUG
|
||||
@ -49,6 +50,8 @@ config LOONGARCH
|
||||
select ARCH_SUPPORTS_ACPI
|
||||
select ARCH_SUPPORTS_ATOMIC_RMW
|
||||
select ARCH_SUPPORTS_HUGETLBFS
|
||||
select ARCH_SUPPORTS_LTO_CLANG
|
||||
select ARCH_SUPPORTS_LTO_CLANG_THIN
|
||||
select ARCH_SUPPORTS_NUMA_BALANCING
|
||||
select ARCH_USE_BUILTIN_BSWAP
|
||||
select ARCH_USE_CMPXCHG_LOCKREF
|
||||
@ -81,9 +84,12 @@ config LOONGARCH
|
||||
select GENERIC_SCHED_CLOCK
|
||||
select GENERIC_SMP_IDLE_THREAD
|
||||
select GENERIC_TIME_VSYSCALL
|
||||
select GENERIC_VDSO_TIME_NS
|
||||
select GPIOLIB
|
||||
select HAS_IOPORT
|
||||
select HAVE_ARCH_AUDITSYSCALL
|
||||
select HAVE_ARCH_JUMP_LABEL
|
||||
select HAVE_ARCH_JUMP_LABEL_RELATIVE
|
||||
select HAVE_ARCH_MMAP_RND_BITS if MMU
|
||||
select HAVE_ARCH_SECCOMP_FILTER
|
||||
select HAVE_ARCH_TRACEHOOK
|
||||
@ -91,6 +97,7 @@ config LOONGARCH
|
||||
select HAVE_ASM_MODVERSIONS
|
||||
select HAVE_CONTEXT_TRACKING_USER
|
||||
select HAVE_C_RECORDMCOUNT
|
||||
select HAVE_DEBUG_KMEMLEAK
|
||||
select HAVE_DEBUG_STACKOVERFLOW
|
||||
select HAVE_DMA_CONTIGUOUS
|
||||
select HAVE_DYNAMIC_FTRACE
|
||||
@ -104,6 +111,7 @@ config LOONGARCH
|
||||
select HAVE_FTRACE_MCOUNT_RECORD
|
||||
select HAVE_FUNCTION_ARG_ACCESS_API
|
||||
select HAVE_FUNCTION_ERROR_INJECTION
|
||||
select HAVE_FUNCTION_GRAPH_RETVAL if HAVE_FUNCTION_GRAPH_TRACER
|
||||
select HAVE_FUNCTION_GRAPH_TRACER
|
||||
select HAVE_FUNCTION_TRACER
|
||||
select HAVE_GENERIC_VDSO
|
||||
@ -121,6 +129,7 @@ config LOONGARCH
|
||||
select HAVE_PERF_REGS
|
||||
select HAVE_PERF_USER_STACK_DUMP
|
||||
select HAVE_REGS_AND_STACK_ACCESS_API
|
||||
select HAVE_RETHOOK
|
||||
select HAVE_RSEQ
|
||||
select HAVE_SAMPLE_FTRACE_DIRECT
|
||||
select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
|
||||
@ -163,14 +172,6 @@ config 32BIT
|
||||
config 64BIT
|
||||
def_bool y
|
||||
|
||||
config CPU_HAS_FPU
|
||||
bool
|
||||
default y
|
||||
|
||||
config CPU_HAS_PREFETCH
|
||||
bool
|
||||
default y
|
||||
|
||||
config GENERIC_BUG
|
||||
def_bool y
|
||||
depends on BUG
|
||||
@ -243,6 +244,15 @@ config SCHED_OMIT_FRAME_POINTER
|
||||
config AS_HAS_EXPLICIT_RELOCS
|
||||
def_bool $(as-instr,x:pcalau12i \$t0$(comma)%pc_hi20(x))
|
||||
|
||||
config AS_HAS_FCSR_CLASS
|
||||
def_bool $(as-instr,movfcsr2gr \$t0$(comma)\$fcsr0)
|
||||
|
||||
config AS_HAS_LSX_EXTENSION
|
||||
def_bool $(as-instr,vld \$vr0$(comma)\$a0$(comma)0)
|
||||
|
||||
config AS_HAS_LASX_EXTENSION
|
||||
def_bool $(as-instr,xvld \$xr0$(comma)\$a0$(comma)0)
|
||||
|
||||
menu "Kernel type and options"
|
||||
|
||||
source "kernel/Kconfig.hz"
|
||||
@ -374,6 +384,13 @@ config EFI_STUB
|
||||
This kernel feature allows the kernel to be loaded directly by
|
||||
EFI firmware without the use of a bootloader.
|
||||
|
||||
config SCHED_SMT
|
||||
bool "SMT scheduler support"
|
||||
default y
|
||||
help
|
||||
Improves scheduler's performance when there are multiple
|
||||
threads in one physical core.
|
||||
|
||||
config SMP
|
||||
bool "Multi-Processing support"
|
||||
help
|
||||
@ -483,6 +500,43 @@ config ARCH_STRICT_ALIGN
|
||||
to run kernel only on systems with h/w unaligned access support in
|
||||
order to optimise for performance.
|
||||
|
||||
config CPU_HAS_FPU
|
||||
bool
|
||||
default y
|
||||
|
||||
config CPU_HAS_LSX
|
||||
bool "Support for the Loongson SIMD Extension"
|
||||
depends on AS_HAS_LSX_EXTENSION
|
||||
help
|
||||
Loongson SIMD Extension (LSX) introduces 128 bit wide vector registers
|
||||
and a set of SIMD instructions to operate on them. When this option
|
||||
is enabled the kernel will support allocating & switching LSX
|
||||
vector register contexts. If you know that your kernel will only be
|
||||
running on CPUs which do not support LSX or that your userland will
|
||||
not be making use of it then you may wish to say N here to reduce
|
||||
the size & complexity of your kernel.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config CPU_HAS_LASX
|
||||
bool "Support for the Loongson Advanced SIMD Extension"
|
||||
depends on CPU_HAS_LSX
|
||||
depends on AS_HAS_LASX_EXTENSION
|
||||
help
|
||||
Loongson Advanced SIMD Extension (LASX) introduces 256 bit wide vector
|
||||
registers and a set of SIMD instructions to operate on them. When this
|
||||
option is enabled the kernel will support allocating & switching LASX
|
||||
vector register contexts. If you know that your kernel will only be
|
||||
running on CPUs which do not support LASX or that your userland will
|
||||
not be making use of it then you may wish to say N here to reduce
|
||||
the size & complexity of your kernel.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config CPU_HAS_PREFETCH
|
||||
bool
|
||||
default y
|
||||
|
||||
config KEXEC
|
||||
bool "Kexec system call"
|
||||
select KEXEC_CORE
|
||||
@ -592,6 +646,9 @@ config ARCH_MMAP_RND_BITS_MIN
|
||||
config ARCH_MMAP_RND_BITS_MAX
|
||||
default 18
|
||||
|
||||
config ARCH_SUPPORTS_UPROBES
|
||||
def_bool y
|
||||
|
||||
menu "Power management options"
|
||||
|
||||
config ARCH_SUSPEND_POSSIBLE
|
||||
|
||||
@ -46,8 +46,8 @@ ld-emul = $(64bit-emul)
|
||||
cflags-y += -mabi=lp64s
|
||||
endif
|
||||
|
||||
cflags-y += -G0 -pipe -msoft-float
|
||||
LDFLAGS_vmlinux += -G0 -static -n -nostdlib
|
||||
cflags-y += -pipe -msoft-float
|
||||
LDFLAGS_vmlinux += -static -n -nostdlib
|
||||
|
||||
# When the assembler supports explicit relocation hint, we must use it.
|
||||
# GCC may have -mexplicit-relocs off by default if it was built with an old
|
||||
@ -56,13 +56,18 @@ LDFLAGS_vmlinux += -G0 -static -n -nostdlib
|
||||
# When the assembler does not supports explicit relocation hint, we can't use
|
||||
# it. Disable it if the compiler supports it.
|
||||
#
|
||||
# If you've seen "unknown reloc hint" message building the kernel and you are
|
||||
# now wondering why "-mexplicit-relocs" is not wrapped with cc-option: the
|
||||
# combination of a "new" assembler and "old" compiler is not supported. Either
|
||||
# upgrade the compiler or downgrade the assembler.
|
||||
# The combination of a "new" assembler and "old" GCC is not supported, given
|
||||
# the rarity of this combo and the extra complexity needed to make it work.
|
||||
# Either upgrade the compiler or downgrade the assembler; the build will error
|
||||
# out if it is the case (by probing for the model attribute; all supported
|
||||
# compilers in this case would have support).
|
||||
#
|
||||
# Also, -mdirect-extern-access is useful in case of building with explicit
|
||||
# relocs, for avoiding unnecessary GOT accesses. It is harmless to not have
|
||||
# support though.
|
||||
ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS
|
||||
cflags-y += -mexplicit-relocs
|
||||
KBUILD_CFLAGS_KERNEL += -mdirect-extern-access
|
||||
cflags-y += $(call cc-option,-mexplicit-relocs)
|
||||
KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access)
|
||||
else
|
||||
cflags-y += $(call cc-option,-mno-explicit-relocs)
|
||||
KBUILD_AFLAGS_KERNEL += -Wa,-mla-global-with-pcrel
|
||||
@ -107,7 +112,7 @@ KBUILD_CFLAGS += -isystem $(shell $(CC) -print-file-name=include)
|
||||
KBUILD_LDFLAGS += -m $(ld-emul)
|
||||
|
||||
ifdef CONFIG_LOONGARCH
|
||||
CHECKFLAGS += $(shell $(CC) $(KBUILD_CFLAGS) -dM -E -x c /dev/null | \
|
||||
CHECKFLAGS += $(shell $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -dM -E -x c /dev/null | \
|
||||
grep -E -vw '__GNUC_(MINOR_|PATCHLEVEL_)?_' | \
|
||||
sed -e "s/^\#define /-D'/" -e "s/ /'='/" -e "s/$$/'/" -e 's/\$$/&&/g')
|
||||
endif
|
||||
|
||||
@ -5,7 +5,6 @@ generic-y += mcs_spinlock.h
|
||||
generic-y += parport.h
|
||||
generic-y += early_ioremap.h
|
||||
generic-y += qrwlock.h
|
||||
generic-y += qspinlock.h
|
||||
generic-y += rwsem.h
|
||||
generic-y += segment.h
|
||||
generic-y += user.h
|
||||
|
||||
@ -8,11 +8,14 @@
|
||||
#ifndef _ASM_LOONGARCH_ACPI_H
|
||||
#define _ASM_LOONGARCH_ACPI_H
|
||||
|
||||
#include <asm/suspend.h>
|
||||
|
||||
#ifdef CONFIG_ACPI
|
||||
extern int acpi_strict;
|
||||
extern int acpi_disabled;
|
||||
extern int acpi_pci_disabled;
|
||||
extern int acpi_noirq;
|
||||
extern int pptt_enabled;
|
||||
|
||||
#define acpi_os_ioremap acpi_os_ioremap
|
||||
void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size);
|
||||
@ -30,6 +33,14 @@ static inline bool acpi_has_cpu_in_madt(void)
|
||||
}
|
||||
|
||||
extern struct list_head acpi_wakeup_device_list;
|
||||
extern struct acpi_madt_core_pic acpi_core_pic[NR_CPUS];
|
||||
|
||||
extern int __init parse_acpi_topology(void);
|
||||
|
||||
static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
|
||||
{
|
||||
return acpi_core_pic[cpu_logical_map(cpu)].processor_id;
|
||||
}
|
||||
|
||||
#endif /* !CONFIG_ACPI */
|
||||
|
||||
@ -37,12 +48,10 @@ extern struct list_head acpi_wakeup_device_list;
|
||||
|
||||
extern int loongarch_acpi_suspend(void);
|
||||
extern int (*acpi_suspend_lowlevel)(void);
|
||||
extern void loongarch_suspend_enter(void);
|
||||
|
||||
static inline unsigned long acpi_get_wakeup_address(void)
|
||||
{
|
||||
#ifdef CONFIG_SUSPEND
|
||||
extern void loongarch_wakeup_start(void);
|
||||
return (unsigned long)loongarch_wakeup_start;
|
||||
#endif
|
||||
return 0UL;
|
||||
|
||||
@ -270,6 +270,399 @@
|
||||
fld.d $f31, \tmp, THREAD_FPR31 - THREAD_FPR0
|
||||
.endm
|
||||
|
||||
.macro lsx_save_data thread tmp
|
||||
li.w \tmp, THREAD_FPR0
|
||||
PTR_ADD \tmp, \thread, \tmp
|
||||
vst $vr0, \tmp, THREAD_FPR0 - THREAD_FPR0
|
||||
vst $vr1, \tmp, THREAD_FPR1 - THREAD_FPR0
|
||||
vst $vr2, \tmp, THREAD_FPR2 - THREAD_FPR0
|
||||
vst $vr3, \tmp, THREAD_FPR3 - THREAD_FPR0
|
||||
vst $vr4, \tmp, THREAD_FPR4 - THREAD_FPR0
|
||||
vst $vr5, \tmp, THREAD_FPR5 - THREAD_FPR0
|
||||
vst $vr6, \tmp, THREAD_FPR6 - THREAD_FPR0
|
||||
vst $vr7, \tmp, THREAD_FPR7 - THREAD_FPR0
|
||||
vst $vr8, \tmp, THREAD_FPR8 - THREAD_FPR0
|
||||
vst $vr9, \tmp, THREAD_FPR9 - THREAD_FPR0
|
||||
vst $vr10, \tmp, THREAD_FPR10 - THREAD_FPR0
|
||||
vst $vr11, \tmp, THREAD_FPR11 - THREAD_FPR0
|
||||
vst $vr12, \tmp, THREAD_FPR12 - THREAD_FPR0
|
||||
vst $vr13, \tmp, THREAD_FPR13 - THREAD_FPR0
|
||||
vst $vr14, \tmp, THREAD_FPR14 - THREAD_FPR0
|
||||
vst $vr15, \tmp, THREAD_FPR15 - THREAD_FPR0
|
||||
vst $vr16, \tmp, THREAD_FPR16 - THREAD_FPR0
|
||||
vst $vr17, \tmp, THREAD_FPR17 - THREAD_FPR0
|
||||
vst $vr18, \tmp, THREAD_FPR18 - THREAD_FPR0
|
||||
vst $vr19, \tmp, THREAD_FPR19 - THREAD_FPR0
|
||||
vst $vr20, \tmp, THREAD_FPR20 - THREAD_FPR0
|
||||
vst $vr21, \tmp, THREAD_FPR21 - THREAD_FPR0
|
||||
vst $vr22, \tmp, THREAD_FPR22 - THREAD_FPR0
|
||||
vst $vr23, \tmp, THREAD_FPR23 - THREAD_FPR0
|
||||
vst $vr24, \tmp, THREAD_FPR24 - THREAD_FPR0
|
||||
vst $vr25, \tmp, THREAD_FPR25 - THREAD_FPR0
|
||||
vst $vr26, \tmp, THREAD_FPR26 - THREAD_FPR0
|
||||
vst $vr27, \tmp, THREAD_FPR27 - THREAD_FPR0
|
||||
vst $vr28, \tmp, THREAD_FPR28 - THREAD_FPR0
|
||||
vst $vr29, \tmp, THREAD_FPR29 - THREAD_FPR0
|
||||
vst $vr30, \tmp, THREAD_FPR30 - THREAD_FPR0
|
||||
vst $vr31, \tmp, THREAD_FPR31 - THREAD_FPR0
|
||||
.endm
|
||||
|
||||
.macro lsx_restore_data thread tmp
|
||||
li.w \tmp, THREAD_FPR0
|
||||
PTR_ADD \tmp, \thread, \tmp
|
||||
vld $vr0, \tmp, THREAD_FPR0 - THREAD_FPR0
|
||||
vld $vr1, \tmp, THREAD_FPR1 - THREAD_FPR0
|
||||
vld $vr2, \tmp, THREAD_FPR2 - THREAD_FPR0
|
||||
vld $vr3, \tmp, THREAD_FPR3 - THREAD_FPR0
|
||||
vld $vr4, \tmp, THREAD_FPR4 - THREAD_FPR0
|
||||
vld $vr5, \tmp, THREAD_FPR5 - THREAD_FPR0
|
||||
vld $vr6, \tmp, THREAD_FPR6 - THREAD_FPR0
|
||||
vld $vr7, \tmp, THREAD_FPR7 - THREAD_FPR0
|
||||
vld $vr8, \tmp, THREAD_FPR8 - THREAD_FPR0
|
||||
vld $vr9, \tmp, THREAD_FPR9 - THREAD_FPR0
|
||||
vld $vr10, \tmp, THREAD_FPR10 - THREAD_FPR0
|
||||
vld $vr11, \tmp, THREAD_FPR11 - THREAD_FPR0
|
||||
vld $vr12, \tmp, THREAD_FPR12 - THREAD_FPR0
|
||||
vld $vr13, \tmp, THREAD_FPR13 - THREAD_FPR0
|
||||
vld $vr14, \tmp, THREAD_FPR14 - THREAD_FPR0
|
||||
vld $vr15, \tmp, THREAD_FPR15 - THREAD_FPR0
|
||||
vld $vr16, \tmp, THREAD_FPR16 - THREAD_FPR0
|
||||
vld $vr17, \tmp, THREAD_FPR17 - THREAD_FPR0
|
||||
vld $vr18, \tmp, THREAD_FPR18 - THREAD_FPR0
|
||||
vld $vr19, \tmp, THREAD_FPR19 - THREAD_FPR0
|
||||
vld $vr20, \tmp, THREAD_FPR20 - THREAD_FPR0
|
||||
vld $vr21, \tmp, THREAD_FPR21 - THREAD_FPR0
|
||||
vld $vr22, \tmp, THREAD_FPR22 - THREAD_FPR0
|
||||
vld $vr23, \tmp, THREAD_FPR23 - THREAD_FPR0
|
||||
vld $vr24, \tmp, THREAD_FPR24 - THREAD_FPR0
|
||||
vld $vr25, \tmp, THREAD_FPR25 - THREAD_FPR0
|
||||
vld $vr26, \tmp, THREAD_FPR26 - THREAD_FPR0
|
||||
vld $vr27, \tmp, THREAD_FPR27 - THREAD_FPR0
|
||||
vld $vr28, \tmp, THREAD_FPR28 - THREAD_FPR0
|
||||
vld $vr29, \tmp, THREAD_FPR29 - THREAD_FPR0
|
||||
vld $vr30, \tmp, THREAD_FPR30 - THREAD_FPR0
|
||||
vld $vr31, \tmp, THREAD_FPR31 - THREAD_FPR0
|
||||
.endm
|
||||
|
||||
.macro lsx_save_all thread tmp0 tmp1
|
||||
fpu_save_cc \thread, \tmp0, \tmp1
|
||||
fpu_save_csr \thread, \tmp0
|
||||
lsx_save_data \thread, \tmp0
|
||||
.endm
|
||||
|
||||
.macro lsx_restore_all thread tmp0 tmp1
|
||||
lsx_restore_data \thread, \tmp0
|
||||
fpu_restore_cc \thread, \tmp0, \tmp1
|
||||
fpu_restore_csr \thread, \tmp0
|
||||
.endm
|
||||
|
||||
.macro lsx_save_upper vd base tmp off
|
||||
vpickve2gr.d \tmp, \vd, 1
|
||||
st.d \tmp, \base, (\off+8)
|
||||
.endm
|
||||
|
||||
.macro lsx_save_all_upper thread base tmp
|
||||
li.w \tmp, THREAD_FPR0
|
||||
PTR_ADD \base, \thread, \tmp
|
||||
lsx_save_upper $vr0, \base, \tmp, (THREAD_FPR0-THREAD_FPR0)
|
||||
lsx_save_upper $vr1, \base, \tmp, (THREAD_FPR1-THREAD_FPR0)
|
||||
lsx_save_upper $vr2, \base, \tmp, (THREAD_FPR2-THREAD_FPR0)
|
||||
lsx_save_upper $vr3, \base, \tmp, (THREAD_FPR3-THREAD_FPR0)
|
||||
lsx_save_upper $vr4, \base, \tmp, (THREAD_FPR4-THREAD_FPR0)
|
||||
lsx_save_upper $vr5, \base, \tmp, (THREAD_FPR5-THREAD_FPR0)
|
||||
lsx_save_upper $vr6, \base, \tmp, (THREAD_FPR6-THREAD_FPR0)
|
||||
lsx_save_upper $vr7, \base, \tmp, (THREAD_FPR7-THREAD_FPR0)
|
||||
lsx_save_upper $vr8, \base, \tmp, (THREAD_FPR8-THREAD_FPR0)
|
||||
lsx_save_upper $vr9, \base, \tmp, (THREAD_FPR9-THREAD_FPR0)
|
||||
lsx_save_upper $vr10, \base, \tmp, (THREAD_FPR10-THREAD_FPR0)
|
||||
lsx_save_upper $vr11, \base, \tmp, (THREAD_FPR11-THREAD_FPR0)
|
||||
lsx_save_upper $vr12, \base, \tmp, (THREAD_FPR12-THREAD_FPR0)
|
||||
lsx_save_upper $vr13, \base, \tmp, (THREAD_FPR13-THREAD_FPR0)
|
||||
lsx_save_upper $vr14, \base, \tmp, (THREAD_FPR14-THREAD_FPR0)
|
||||
lsx_save_upper $vr15, \base, \tmp, (THREAD_FPR15-THREAD_FPR0)
|
||||
lsx_save_upper $vr16, \base, \tmp, (THREAD_FPR16-THREAD_FPR0)
|
||||
lsx_save_upper $vr17, \base, \tmp, (THREAD_FPR17-THREAD_FPR0)
|
||||
lsx_save_upper $vr18, \base, \tmp, (THREAD_FPR18-THREAD_FPR0)
|
||||
lsx_save_upper $vr19, \base, \tmp, (THREAD_FPR19-THREAD_FPR0)
|
||||
lsx_save_upper $vr20, \base, \tmp, (THREAD_FPR20-THREAD_FPR0)
|
||||
lsx_save_upper $vr21, \base, \tmp, (THREAD_FPR21-THREAD_FPR0)
|
||||
lsx_save_upper $vr22, \base, \tmp, (THREAD_FPR22-THREAD_FPR0)
|
||||
lsx_save_upper $vr23, \base, \tmp, (THREAD_FPR23-THREAD_FPR0)
|
||||
lsx_save_upper $vr24, \base, \tmp, (THREAD_FPR24-THREAD_FPR0)
|
||||
lsx_save_upper $vr25, \base, \tmp, (THREAD_FPR25-THREAD_FPR0)
|
||||
lsx_save_upper $vr26, \base, \tmp, (THREAD_FPR26-THREAD_FPR0)
|
||||
lsx_save_upper $vr27, \base, \tmp, (THREAD_FPR27-THREAD_FPR0)
|
||||
lsx_save_upper $vr28, \base, \tmp, (THREAD_FPR28-THREAD_FPR0)
|
||||
lsx_save_upper $vr29, \base, \tmp, (THREAD_FPR29-THREAD_FPR0)
|
||||
lsx_save_upper $vr30, \base, \tmp, (THREAD_FPR30-THREAD_FPR0)
|
||||
lsx_save_upper $vr31, \base, \tmp, (THREAD_FPR31-THREAD_FPR0)
|
||||
.endm
|
||||
|
||||
.macro lsx_restore_upper vd base tmp off
|
||||
ld.d \tmp, \base, (\off+8)
|
||||
vinsgr2vr.d \vd, \tmp, 1
|
||||
.endm
|
||||
|
||||
.macro lsx_restore_all_upper thread base tmp
|
||||
li.w \tmp, THREAD_FPR0
|
||||
PTR_ADD \base, \thread, \tmp
|
||||
lsx_restore_upper $vr0, \base, \tmp, (THREAD_FPR0-THREAD_FPR0)
|
||||
lsx_restore_upper $vr1, \base, \tmp, (THREAD_FPR1-THREAD_FPR0)
|
||||
lsx_restore_upper $vr2, \base, \tmp, (THREAD_FPR2-THREAD_FPR0)
|
||||
lsx_restore_upper $vr3, \base, \tmp, (THREAD_FPR3-THREAD_FPR0)
|
||||
lsx_restore_upper $vr4, \base, \tmp, (THREAD_FPR4-THREAD_FPR0)
|
||||
lsx_restore_upper $vr5, \base, \tmp, (THREAD_FPR5-THREAD_FPR0)
|
||||
lsx_restore_upper $vr6, \base, \tmp, (THREAD_FPR6-THREAD_FPR0)
|
||||
lsx_restore_upper $vr7, \base, \tmp, (THREAD_FPR7-THREAD_FPR0)
|
||||
lsx_restore_upper $vr8, \base, \tmp, (THREAD_FPR8-THREAD_FPR0)
|
||||
lsx_restore_upper $vr9, \base, \tmp, (THREAD_FPR9-THREAD_FPR0)
|
||||
lsx_restore_upper $vr10, \base, \tmp, (THREAD_FPR10-THREAD_FPR0)
|
||||
lsx_restore_upper $vr11, \base, \tmp, (THREAD_FPR11-THREAD_FPR0)
|
||||
lsx_restore_upper $vr12, \base, \tmp, (THREAD_FPR12-THREAD_FPR0)
|
||||
lsx_restore_upper $vr13, \base, \tmp, (THREAD_FPR13-THREAD_FPR0)
|
||||
lsx_restore_upper $vr14, \base, \tmp, (THREAD_FPR14-THREAD_FPR0)
|
||||
lsx_restore_upper $vr15, \base, \tmp, (THREAD_FPR15-THREAD_FPR0)
|
||||
lsx_restore_upper $vr16, \base, \tmp, (THREAD_FPR16-THREAD_FPR0)
|
||||
lsx_restore_upper $vr17, \base, \tmp, (THREAD_FPR17-THREAD_FPR0)
|
||||
lsx_restore_upper $vr18, \base, \tmp, (THREAD_FPR18-THREAD_FPR0)
|
||||
lsx_restore_upper $vr19, \base, \tmp, (THREAD_FPR19-THREAD_FPR0)
|
||||
lsx_restore_upper $vr20, \base, \tmp, (THREAD_FPR20-THREAD_FPR0)
|
||||
lsx_restore_upper $vr21, \base, \tmp, (THREAD_FPR21-THREAD_FPR0)
|
||||
lsx_restore_upper $vr22, \base, \tmp, (THREAD_FPR22-THREAD_FPR0)
|
||||
lsx_restore_upper $vr23, \base, \tmp, (THREAD_FPR23-THREAD_FPR0)
|
||||
lsx_restore_upper $vr24, \base, \tmp, (THREAD_FPR24-THREAD_FPR0)
|
||||
lsx_restore_upper $vr25, \base, \tmp, (THREAD_FPR25-THREAD_FPR0)
|
||||
lsx_restore_upper $vr26, \base, \tmp, (THREAD_FPR26-THREAD_FPR0)
|
||||
lsx_restore_upper $vr27, \base, \tmp, (THREAD_FPR27-THREAD_FPR0)
|
||||
lsx_restore_upper $vr28, \base, \tmp, (THREAD_FPR28-THREAD_FPR0)
|
||||
lsx_restore_upper $vr29, \base, \tmp, (THREAD_FPR29-THREAD_FPR0)
|
||||
lsx_restore_upper $vr30, \base, \tmp, (THREAD_FPR30-THREAD_FPR0)
|
||||
lsx_restore_upper $vr31, \base, \tmp, (THREAD_FPR31-THREAD_FPR0)
|
||||
.endm
|
||||
|
||||
.macro lsx_init_upper vd tmp
|
||||
vinsgr2vr.d \vd, \tmp, 1
|
||||
.endm
|
||||
|
||||
.macro lsx_init_all_upper tmp
|
||||
not \tmp, zero
|
||||
lsx_init_upper $vr0 \tmp
|
||||
lsx_init_upper $vr1 \tmp
|
||||
lsx_init_upper $vr2 \tmp
|
||||
lsx_init_upper $vr3 \tmp
|
||||
lsx_init_upper $vr4 \tmp
|
||||
lsx_init_upper $vr5 \tmp
|
||||
lsx_init_upper $vr6 \tmp
|
||||
lsx_init_upper $vr7 \tmp
|
||||
lsx_init_upper $vr8 \tmp
|
||||
lsx_init_upper $vr9 \tmp
|
||||
lsx_init_upper $vr10 \tmp
|
||||
lsx_init_upper $vr11 \tmp
|
||||
lsx_init_upper $vr12 \tmp
|
||||
lsx_init_upper $vr13 \tmp
|
||||
lsx_init_upper $vr14 \tmp
|
||||
lsx_init_upper $vr15 \tmp
|
||||
lsx_init_upper $vr16 \tmp
|
||||
lsx_init_upper $vr17 \tmp
|
||||
lsx_init_upper $vr18 \tmp
|
||||
lsx_init_upper $vr19 \tmp
|
||||
lsx_init_upper $vr20 \tmp
|
||||
lsx_init_upper $vr21 \tmp
|
||||
lsx_init_upper $vr22 \tmp
|
||||
lsx_init_upper $vr23 \tmp
|
||||
lsx_init_upper $vr24 \tmp
|
||||
lsx_init_upper $vr25 \tmp
|
||||
lsx_init_upper $vr26 \tmp
|
||||
lsx_init_upper $vr27 \tmp
|
||||
lsx_init_upper $vr28 \tmp
|
||||
lsx_init_upper $vr29 \tmp
|
||||
lsx_init_upper $vr30 \tmp
|
||||
lsx_init_upper $vr31 \tmp
|
||||
.endm
|
||||
|
||||
.macro lasx_save_data thread tmp
|
||||
li.w \tmp, THREAD_FPR0
|
||||
PTR_ADD \tmp, \thread, \tmp
|
||||
xvst $xr0, \tmp, THREAD_FPR0 - THREAD_FPR0
|
||||
xvst $xr1, \tmp, THREAD_FPR1 - THREAD_FPR0
|
||||
xvst $xr2, \tmp, THREAD_FPR2 - THREAD_FPR0
|
||||
xvst $xr3, \tmp, THREAD_FPR3 - THREAD_FPR0
|
||||
xvst $xr4, \tmp, THREAD_FPR4 - THREAD_FPR0
|
||||
xvst $xr5, \tmp, THREAD_FPR5 - THREAD_FPR0
|
||||
xvst $xr6, \tmp, THREAD_FPR6 - THREAD_FPR0
|
||||
xvst $xr7, \tmp, THREAD_FPR7 - THREAD_FPR0
|
||||
xvst $xr8, \tmp, THREAD_FPR8 - THREAD_FPR0
|
||||
xvst $xr9, \tmp, THREAD_FPR9 - THREAD_FPR0
|
||||
xvst $xr10, \tmp, THREAD_FPR10 - THREAD_FPR0
|
||||
xvst $xr11, \tmp, THREAD_FPR11 - THREAD_FPR0
|
||||
xvst $xr12, \tmp, THREAD_FPR12 - THREAD_FPR0
|
||||
xvst $xr13, \tmp, THREAD_FPR13 - THREAD_FPR0
|
||||
xvst $xr14, \tmp, THREAD_FPR14 - THREAD_FPR0
|
||||
xvst $xr15, \tmp, THREAD_FPR15 - THREAD_FPR0
|
||||
xvst $xr16, \tmp, THREAD_FPR16 - THREAD_FPR0
|
||||
xvst $xr17, \tmp, THREAD_FPR17 - THREAD_FPR0
|
||||
xvst $xr18, \tmp, THREAD_FPR18 - THREAD_FPR0
|
||||
xvst $xr19, \tmp, THREAD_FPR19 - THREAD_FPR0
|
||||
xvst $xr20, \tmp, THREAD_FPR20 - THREAD_FPR0
|
||||
xvst $xr21, \tmp, THREAD_FPR21 - THREAD_FPR0
|
||||
xvst $xr22, \tmp, THREAD_FPR22 - THREAD_FPR0
|
||||
xvst $xr23, \tmp, THREAD_FPR23 - THREAD_FPR0
|
||||
xvst $xr24, \tmp, THREAD_FPR24 - THREAD_FPR0
|
||||
xvst $xr25, \tmp, THREAD_FPR25 - THREAD_FPR0
|
||||
xvst $xr26, \tmp, THREAD_FPR26 - THREAD_FPR0
|
||||
xvst $xr27, \tmp, THREAD_FPR27 - THREAD_FPR0
|
||||
xvst $xr28, \tmp, THREAD_FPR28 - THREAD_FPR0
|
||||
xvst $xr29, \tmp, THREAD_FPR29 - THREAD_FPR0
|
||||
xvst $xr30, \tmp, THREAD_FPR30 - THREAD_FPR0
|
||||
xvst $xr31, \tmp, THREAD_FPR31 - THREAD_FPR0
|
||||
.endm
|
||||
|
||||
.macro lasx_restore_data thread tmp
|
||||
li.w \tmp, THREAD_FPR0
|
||||
PTR_ADD \tmp, \thread, \tmp
|
||||
xvld $xr0, \tmp, THREAD_FPR0 - THREAD_FPR0
|
||||
xvld $xr1, \tmp, THREAD_FPR1 - THREAD_FPR0
|
||||
xvld $xr2, \tmp, THREAD_FPR2 - THREAD_FPR0
|
||||
xvld $xr3, \tmp, THREAD_FPR3 - THREAD_FPR0
|
||||
xvld $xr4, \tmp, THREAD_FPR4 - THREAD_FPR0
|
||||
xvld $xr5, \tmp, THREAD_FPR5 - THREAD_FPR0
|
||||
xvld $xr6, \tmp, THREAD_FPR6 - THREAD_FPR0
|
||||
xvld $xr7, \tmp, THREAD_FPR7 - THREAD_FPR0
|
||||
xvld $xr8, \tmp, THREAD_FPR8 - THREAD_FPR0
|
||||
xvld $xr9, \tmp, THREAD_FPR9 - THREAD_FPR0
|
||||
xvld $xr10, \tmp, THREAD_FPR10 - THREAD_FPR0
|
||||
xvld $xr11, \tmp, THREAD_FPR11 - THREAD_FPR0
|
||||
xvld $xr12, \tmp, THREAD_FPR12 - THREAD_FPR0
|
||||
xvld $xr13, \tmp, THREAD_FPR13 - THREAD_FPR0
|
||||
xvld $xr14, \tmp, THREAD_FPR14 - THREAD_FPR0
|
||||
xvld $xr15, \tmp, THREAD_FPR15 - THREAD_FPR0
|
||||
xvld $xr16, \tmp, THREAD_FPR16 - THREAD_FPR0
|
||||
xvld $xr17, \tmp, THREAD_FPR17 - THREAD_FPR0
|
||||
xvld $xr18, \tmp, THREAD_FPR18 - THREAD_FPR0
|
||||
xvld $xr19, \tmp, THREAD_FPR19 - THREAD_FPR0
|
||||
xvld $xr20, \tmp, THREAD_FPR20 - THREAD_FPR0
|
||||
xvld $xr21, \tmp, THREAD_FPR21 - THREAD_FPR0
|
||||
xvld $xr22, \tmp, THREAD_FPR22 - THREAD_FPR0
|
||||
xvld $xr23, \tmp, THREAD_FPR23 - THREAD_FPR0
|
||||
xvld $xr24, \tmp, THREAD_FPR24 - THREAD_FPR0
|
||||
xvld $xr25, \tmp, THREAD_FPR25 - THREAD_FPR0
|
||||
xvld $xr26, \tmp, THREAD_FPR26 - THREAD_FPR0
|
||||
xvld $xr27, \tmp, THREAD_FPR27 - THREAD_FPR0
|
||||
xvld $xr28, \tmp, THREAD_FPR28 - THREAD_FPR0
|
||||
xvld $xr29, \tmp, THREAD_FPR29 - THREAD_FPR0
|
||||
xvld $xr30, \tmp, THREAD_FPR30 - THREAD_FPR0
|
||||
xvld $xr31, \tmp, THREAD_FPR31 - THREAD_FPR0
|
||||
.endm
|
||||
|
||||
.macro lasx_save_all thread tmp0 tmp1
|
||||
fpu_save_cc \thread, \tmp0, \tmp1
|
||||
fpu_save_csr \thread, \tmp0
|
||||
lasx_save_data \thread, \tmp0
|
||||
.endm
|
||||
|
||||
.macro lasx_restore_all thread tmp0 tmp1
|
||||
lasx_restore_data \thread, \tmp0
|
||||
fpu_restore_cc \thread, \tmp0, \tmp1
|
||||
fpu_restore_csr \thread, \tmp0
|
||||
.endm
|
||||
|
||||
.macro lasx_save_upper xd base tmp off
|
||||
/* Nothing */
|
||||
.endm
|
||||
|
||||
.macro lasx_save_all_upper thread base tmp
|
||||
/* Nothing */
|
||||
.endm
|
||||
|
||||
.macro lasx_restore_upper xd base tmp0 tmp1 off
|
||||
vld \tmp0, \base, (\off+16)
|
||||
xvpermi.q \xd, \tmp1, 0x2
|
||||
.endm
|
||||
|
||||
.macro lasx_restore_all_upper thread base tmp
|
||||
li.w \tmp, THREAD_FPR0
|
||||
PTR_ADD \base, \thread, \tmp
|
||||
/* Save $vr31 ($xr31 lower bits) with xvpickve2gr */
|
||||
xvpickve2gr.d $r17, $xr31, 0
|
||||
xvpickve2gr.d $r18, $xr31, 1
|
||||
lasx_restore_upper $xr0, \base, $vr31, $xr31, (THREAD_FPR0-THREAD_FPR0)
|
||||
lasx_restore_upper $xr1, \base, $vr31, $xr31, (THREAD_FPR1-THREAD_FPR0)
|
||||
lasx_restore_upper $xr2, \base, $vr31, $xr31, (THREAD_FPR2-THREAD_FPR0)
|
||||
lasx_restore_upper $xr3, \base, $vr31, $xr31, (THREAD_FPR3-THREAD_FPR0)
|
||||
lasx_restore_upper $xr4, \base, $vr31, $xr31, (THREAD_FPR4-THREAD_FPR0)
|
||||
lasx_restore_upper $xr5, \base, $vr31, $xr31, (THREAD_FPR5-THREAD_FPR0)
|
||||
lasx_restore_upper $xr6, \base, $vr31, $xr31, (THREAD_FPR6-THREAD_FPR0)
|
||||
lasx_restore_upper $xr7, \base, $vr31, $xr31, (THREAD_FPR7-THREAD_FPR0)
|
||||
lasx_restore_upper $xr8, \base, $vr31, $xr31, (THREAD_FPR8-THREAD_FPR0)
|
||||
lasx_restore_upper $xr9, \base, $vr31, $xr31, (THREAD_FPR9-THREAD_FPR0)
|
||||
lasx_restore_upper $xr10, \base, $vr31, $xr31, (THREAD_FPR10-THREAD_FPR0)
|
||||
lasx_restore_upper $xr11, \base, $vr31, $xr31, (THREAD_FPR11-THREAD_FPR0)
|
||||
lasx_restore_upper $xr12, \base, $vr31, $xr31, (THREAD_FPR12-THREAD_FPR0)
|
||||
lasx_restore_upper $xr13, \base, $vr31, $xr31, (THREAD_FPR13-THREAD_FPR0)
|
||||
lasx_restore_upper $xr14, \base, $vr31, $xr31, (THREAD_FPR14-THREAD_FPR0)
|
||||
lasx_restore_upper $xr15, \base, $vr31, $xr31, (THREAD_FPR15-THREAD_FPR0)
|
||||
lasx_restore_upper $xr16, \base, $vr31, $xr31, (THREAD_FPR16-THREAD_FPR0)
|
||||
lasx_restore_upper $xr17, \base, $vr31, $xr31, (THREAD_FPR17-THREAD_FPR0)
|
||||
lasx_restore_upper $xr18, \base, $vr31, $xr31, (THREAD_FPR18-THREAD_FPR0)
|
||||
lasx_restore_upper $xr19, \base, $vr31, $xr31, (THREAD_FPR19-THREAD_FPR0)
|
||||
lasx_restore_upper $xr20, \base, $vr31, $xr31, (THREAD_FPR20-THREAD_FPR0)
|
||||
lasx_restore_upper $xr21, \base, $vr31, $xr31, (THREAD_FPR21-THREAD_FPR0)
|
||||
lasx_restore_upper $xr22, \base, $vr31, $xr31, (THREAD_FPR22-THREAD_FPR0)
|
||||
lasx_restore_upper $xr23, \base, $vr31, $xr31, (THREAD_FPR23-THREAD_FPR0)
|
||||
lasx_restore_upper $xr24, \base, $vr31, $xr31, (THREAD_FPR24-THREAD_FPR0)
|
||||
lasx_restore_upper $xr25, \base, $vr31, $xr31, (THREAD_FPR25-THREAD_FPR0)
|
||||
lasx_restore_upper $xr26, \base, $vr31, $xr31, (THREAD_FPR26-THREAD_FPR0)
|
||||
lasx_restore_upper $xr27, \base, $vr31, $xr31, (THREAD_FPR27-THREAD_FPR0)
|
||||
lasx_restore_upper $xr28, \base, $vr31, $xr31, (THREAD_FPR28-THREAD_FPR0)
|
||||
lasx_restore_upper $xr29, \base, $vr31, $xr31, (THREAD_FPR29-THREAD_FPR0)
|
||||
lasx_restore_upper $xr30, \base, $vr31, $xr31, (THREAD_FPR30-THREAD_FPR0)
|
||||
lasx_restore_upper $xr31, \base, $vr31, $xr31, (THREAD_FPR31-THREAD_FPR0)
|
||||
/* Restore $vr31 ($xr31 lower bits) with xvinsgr2vr */
|
||||
xvinsgr2vr.d $xr31, $r17, 0
|
||||
xvinsgr2vr.d $xr31, $r18, 1
|
||||
.endm
|
||||
|
||||
.macro lasx_init_upper xd tmp
|
||||
xvinsgr2vr.d \xd, \tmp, 2
|
||||
xvinsgr2vr.d \xd, \tmp, 3
|
||||
.endm
|
||||
|
||||
.macro lasx_init_all_upper tmp
|
||||
not \tmp, zero
|
||||
lasx_init_upper $xr0 \tmp
|
||||
lasx_init_upper $xr1 \tmp
|
||||
lasx_init_upper $xr2 \tmp
|
||||
lasx_init_upper $xr3 \tmp
|
||||
lasx_init_upper $xr4 \tmp
|
||||
lasx_init_upper $xr5 \tmp
|
||||
lasx_init_upper $xr6 \tmp
|
||||
lasx_init_upper $xr7 \tmp
|
||||
lasx_init_upper $xr8 \tmp
|
||||
lasx_init_upper $xr9 \tmp
|
||||
lasx_init_upper $xr10 \tmp
|
||||
lasx_init_upper $xr11 \tmp
|
||||
lasx_init_upper $xr12 \tmp
|
||||
lasx_init_upper $xr13 \tmp
|
||||
lasx_init_upper $xr14 \tmp
|
||||
lasx_init_upper $xr15 \tmp
|
||||
lasx_init_upper $xr16 \tmp
|
||||
lasx_init_upper $xr17 \tmp
|
||||
lasx_init_upper $xr18 \tmp
|
||||
lasx_init_upper $xr19 \tmp
|
||||
lasx_init_upper $xr20 \tmp
|
||||
lasx_init_upper $xr21 \tmp
|
||||
lasx_init_upper $xr22 \tmp
|
||||
lasx_init_upper $xr23 \tmp
|
||||
lasx_init_upper $xr24 \tmp
|
||||
lasx_init_upper $xr25 \tmp
|
||||
lasx_init_upper $xr26 \tmp
|
||||
lasx_init_upper $xr27 \tmp
|
||||
lasx_init_upper $xr28 \tmp
|
||||
lasx_init_upper $xr29 \tmp
|
||||
lasx_init_upper $xr30 \tmp
|
||||
lasx_init_upper $xr31 \tmp
|
||||
.endm
|
||||
|
||||
.macro not dst src
|
||||
nor \dst, \src, zero
|
||||
.endm
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user