You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge tag 'char-misc-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc updates from Greg KH:
"Here is the big set of char/misc driver patches for 4.17-rc1.
There are a lot of little things in here, nothing huge, but all
important to the different hardware types involved:
- thunderbolt driver updates
- parport updates (people still care...)
- nvmem driver updates
- mei updates (as always)
- hwtracing driver updates
- hyperv driver updates
- extcon driver updates
- ... and a handful of even smaller driver subsystem and individual
driver updates
All of these have been in linux-next with no reported issues"
* tag 'char-misc-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (149 commits)
hwtracing: Add HW tracing support menu
intel_th: Add ACPI glue layer
intel_th: Allow forcing host mode through drvdata
intel_th: Pick up irq number from resources
intel_th: Don't touch switch routing in host mode
intel_th: Use correct method of finding hub
intel_th: Add SPDX GPL-2.0 header to replace GPLv2 boilerplate
stm class: Make dummy's master/channel ranges configurable
stm class: Add SPDX GPL-2.0 header to replace GPLv2 boilerplate
MAINTAINERS: Bestow upon myself the care for drivers/hwtracing
hv: add SPDX license id to Kconfig
hv: add SPDX license to trace
Drivers: hv: vmbus: do not mark HV_PCIE as perf_device
Drivers: hv: vmbus: respect what we get from hv_get_synint_state()
/dev/mem: Avoid overwriting "err" in read_mem()
eeprom: at24: use SPDX identifier instead of GPL boiler-plate
eeprom: at24: simplify the i2c functionality checking
eeprom: at24: fix a line break
eeprom: at24: tweak newlines
eeprom: at24: refactor at24_probe()
...
This commit is contained in:
@@ -132,3 +132,10 @@ KernelVersion: 4.16
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Monitor bit associated with channel
|
||||
Users: Debugging tools and userspace drivers
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/ring
|
||||
Date: January. 2018
|
||||
KernelVersion: 4.16
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Binary file created by uio_hv_generic for ring buffer
|
||||
Users: Userspace drivers
|
||||
|
||||
@@ -1,3 +1,26 @@
|
||||
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
|
||||
Date: Jun 2018
|
||||
KernelVersion: 4.17
|
||||
Contact: thunderbolt-software@lists.01.org
|
||||
Description: Holds a comma separated list of device unique_ids that
|
||||
are allowed to be connected automatically during system
|
||||
startup (e.g boot devices). The list always contains
|
||||
maximum supported number of unique_ids where unused
|
||||
entries are empty. This allows the userspace software
|
||||
to determine how many entries the controller supports.
|
||||
If there are multiple controllers, each controller has
|
||||
its own ACL list and size may be different between the
|
||||
controllers.
|
||||
|
||||
System BIOS may have an option "Preboot ACL" or similar
|
||||
that needs to be selected before this list is taken into
|
||||
consideration.
|
||||
|
||||
Software always updates a full list in each write.
|
||||
|
||||
If a device is authorized automatically during boot its
|
||||
boot attribute is set to 1.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../domainX/security
|
||||
Date: Sep 2017
|
||||
KernelVersion: 4.13
|
||||
@@ -12,6 +35,9 @@ Description: This attribute holds current Thunderbolt security level
|
||||
minimum. User needs to authorize each device.
|
||||
dponly: Automatically tunnel Display port (and USB). No
|
||||
PCIe tunnels are created.
|
||||
usbonly: Automatically tunnel USB controller of the
|
||||
connected Thunderbolt dock (and Display Port). All
|
||||
PCIe links downstream of the dock are removed.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../authorized
|
||||
Date: Sep 2017
|
||||
@@ -38,6 +64,13 @@ Description: This attribute is used to authorize Thunderbolt devices
|
||||
the device did not contain a key at all, and
|
||||
EKEYREJECTED if the challenge response did not match.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../boot
|
||||
Date: Jun 2018
|
||||
KernelVersion: 4.17
|
||||
Contact: thunderbolt-software@lists.01.org
|
||||
Description: This attribute contains 1 if Thunderbolt device was already
|
||||
authorized on boot and 0 otherwise.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../key
|
||||
Date: Sep 2017
|
||||
KernelVersion: 4.13
|
||||
|
||||
@@ -45,3 +45,12 @@ Contact: Tomas Winkler <tomas.winkler@intel.com>
|
||||
Description: Display the driver HBM protocol version.
|
||||
|
||||
The HBM protocol version supported by the driver.
|
||||
|
||||
What: /sys/class/mei/meiN/tx_queue_limit
|
||||
Date: Jan 2018
|
||||
KernelVersion: 4.16
|
||||
Contact: Tomas Winkler <tomas.winkler@intel.com>
|
||||
Description: Configure tx queue limit
|
||||
|
||||
Set maximal number of pending writes
|
||||
per opened session.
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
What: /sys/bus/platform/devices/[..]/fsi-master-gpio/external_mode
|
||||
Date: Feb 2018
|
||||
KernelVersion: 4.17
|
||||
Contact: jk@ozlabs.org
|
||||
Description:
|
||||
Controls access arbitration for GPIO-based FSI master. A
|
||||
value of 0 (the default) sets normal mode, where the
|
||||
driver performs FSI bus transactions, 1 sets external mode,
|
||||
where the FSI bus is driven externally (for example, by
|
||||
a debug device).
|
||||
@@ -21,11 +21,11 @@ vulnerable to DMA attacks.
|
||||
Security levels and how to use them
|
||||
-----------------------------------
|
||||
Starting with Intel Falcon Ridge Thunderbolt controller there are 4
|
||||
security levels available. The reason for these is the fact that the
|
||||
connected devices can be DMA masters and thus read contents of the host
|
||||
memory without CPU and OS knowing about it. There are ways to prevent
|
||||
this by setting up an IOMMU but it is not always available for various
|
||||
reasons.
|
||||
security levels available. Intel Titan Ridge added one more security level
|
||||
(usbonly). The reason for these is the fact that the connected devices can
|
||||
be DMA masters and thus read contents of the host memory without CPU and OS
|
||||
knowing about it. There are ways to prevent this by setting up an IOMMU but
|
||||
it is not always available for various reasons.
|
||||
|
||||
The security levels are as follows:
|
||||
|
||||
@@ -52,6 +52,11 @@ The security levels are as follows:
|
||||
USB. No PCIe tunneling is done. In BIOS settings this is
|
||||
typically called *Display Port Only*.
|
||||
|
||||
usbonly
|
||||
The firmware automatically creates tunnels for the USB controller and
|
||||
Display Port in a dock. All PCIe links downstream of the dock are
|
||||
removed.
|
||||
|
||||
The current security level can be read from
|
||||
``/sys/bus/thunderbolt/devices/domainX/security`` where ``domainX`` is
|
||||
the Thunderbolt domain the host controller manages. There is typically
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
Samsung micro-USB 11-pin connector
|
||||
==================================
|
||||
|
||||
Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
|
||||
It is present in multiple Samsung mobile devices.
|
||||
It has additional pins to route MHL traffic simultanously with USB.
|
||||
|
||||
The bindings are superset of usb-connector bindings for micro-USB connector[1].
|
||||
|
||||
Required properties:
|
||||
- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
|
||||
- type: must be "micro".
|
||||
|
||||
Required nodes:
|
||||
- any data bus to the connector should be modeled using the OF graph bindings
|
||||
specified in bindings/graph.txt, unless the bus is between parent node and
|
||||
the connector. Since single connector can have multpile data buses every bus
|
||||
has assigned OF graph port number as follows:
|
||||
0: High Speed (HS),
|
||||
3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
|
||||
|
||||
[1]: bindings/connector/usb-connector.txt
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines
|
||||
connected to HDMI-MHL bridge (sii8620):
|
||||
|
||||
muic-max77843@66 {
|
||||
...
|
||||
usb_con: connector {
|
||||
compatible = "samsung,usb-connector-11pin", "usb-b-connector";
|
||||
label = "micro-USB";
|
||||
type = "micro";
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@3 {
|
||||
reg = <3>;
|
||||
usb_con_mhl: endpoint {
|
||||
remote-endpoint = <&sii8620_mhl>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,75 @@
|
||||
USB Connector
|
||||
=============
|
||||
|
||||
USB connector node represents physical USB connector. It should be
|
||||
a child of USB interface controller.
|
||||
|
||||
Required properties:
|
||||
- compatible: describes type of the connector, must be one of:
|
||||
"usb-a-connector",
|
||||
"usb-b-connector",
|
||||
"usb-c-connector".
|
||||
|
||||
Optional properties:
|
||||
- label: symbolic name for the connector,
|
||||
- type: size of the connector, should be specified in case of USB-A, USB-B
|
||||
non-fullsize connectors: "mini", "micro".
|
||||
|
||||
Required nodes:
|
||||
- any data bus to the connector should be modeled using the OF graph bindings
|
||||
specified in bindings/graph.txt, unless the bus is between parent node and
|
||||
the connector. Since single connector can have multpile data buses every bus
|
||||
has assigned OF graph port number as follows:
|
||||
0: High Speed (HS), present in all connectors,
|
||||
1: Super Speed (SS), present in SS capable connectors,
|
||||
2: Sideband use (SBU), present in USB-C.
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
1. Micro-USB connector with HS lines routed via controller (MUIC):
|
||||
|
||||
muic-max77843@66 {
|
||||
...
|
||||
usb_con: connector {
|
||||
compatible = "usb-b-connector";
|
||||
label = "micro-USB";
|
||||
type = "micro";
|
||||
};
|
||||
};
|
||||
|
||||
2. USB-C connector attached to CC controller (s2mm005), HS lines routed
|
||||
to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
|
||||
DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
|
||||
|
||||
ccic: s2mm005@33 {
|
||||
...
|
||||
usb_con: connector {
|
||||
compatible = "usb-c-connector";
|
||||
label = "USB-C";
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
usb_con_hs: endpoint {
|
||||
remote-endpoint = <&max77865_usbc_hs>;
|
||||
};
|
||||
};
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
usb_con_ss: endpoint {
|
||||
remote-endpoint = <&usbdrd_phy_ss>;
|
||||
};
|
||||
};
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
usb_con_sbu: endpoint {
|
||||
remote-endpoint = <&dp_aux>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,151 @@
|
||||
FSI bus & engine generic device tree bindings
|
||||
=============================================
|
||||
|
||||
The FSI bus is probe-able, so the OS is able to enumerate FSI slaves, and
|
||||
engines within those slaves. However, we have a facility to match devicetree
|
||||
nodes to probed engines. This allows for fsi engines to expose non-probeable
|
||||
busses, which are then exposed by the device tree. For example, an FSI engine
|
||||
that is an I2C master - the I2C bus can be described by the device tree under
|
||||
the engine's device tree node.
|
||||
|
||||
FSI masters may require their own DT nodes (to describe the master HW itself);
|
||||
that requirement is defined by the master's implementation, and is described by
|
||||
the fsi-master-* binding specifications.
|
||||
|
||||
Under the masters' nodes, we can describe the bus topology using nodes to
|
||||
represent the FSI slaves and their slave engines. As a basic outline:
|
||||
|
||||
fsi-master {
|
||||
/* top-level of FSI bus topology, bound to an FSI master driver and
|
||||
* exposes an FSI bus */
|
||||
|
||||
fsi-slave@<link,id> {
|
||||
/* this node defines the FSI slave device, and is handled
|
||||
* entirely with FSI core code */
|
||||
|
||||
fsi-slave-engine@<addr> {
|
||||
/* this node defines the engine endpoint & address range, which
|
||||
* is bound to the relevant fsi device driver */
|
||||
...
|
||||
};
|
||||
|
||||
fsi-slave-engine@<addr> {
|
||||
...
|
||||
};
|
||||
|
||||
};
|
||||
};
|
||||
|
||||
Note that since the bus is probe-able, some (or all) of the topology may
|
||||
not be described; this binding only provides an optional facility for
|
||||
adding subordinate device tree nodes as children of FSI engines.
|
||||
|
||||
FSI masters
|
||||
-----------
|
||||
|
||||
FSI master nodes declare themselves as such with the "fsi-master" compatible
|
||||
value. It's likely that an implementation-specific compatible value will
|
||||
be needed as well, for example:
|
||||
|
||||
compatible = "fsi-master-gpio", "fsi-master";
|
||||
|
||||
Since the master nodes describe the top-level of the FSI topology, they also
|
||||
need to declare the FSI-standard addressing scheme. This requires two cells for
|
||||
addresses (link index and slave ID), and no size:
|
||||
|
||||
#address-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
|
||||
An optional boolean property can be added to indicate that a particular master
|
||||
should not scan for connected devices at initialization time. This is
|
||||
necessary in cases where a scan could cause arbitration issues with other
|
||||
masters that may be present on the bus.
|
||||
|
||||
no-scan-on-init;
|
||||
|
||||
FSI slaves
|
||||
----------
|
||||
|
||||
Slaves are identified by a (link-index, slave-id) pair, so require two cells
|
||||
for an address identifier. Since these are not a range, no size cells are
|
||||
required. For an example, a slave on link 1, with ID 2, could be represented
|
||||
as:
|
||||
|
||||
cfam@1,2 {
|
||||
reg = <1 2>;
|
||||
[...];
|
||||
}
|
||||
|
||||
Each slave provides an address-space, under which the engines are accessible.
|
||||
That address space has a maximum of 23 bits, so we use one cell to represent
|
||||
addresses and sizes in the slave address space:
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
|
||||
FSI engines (devices)
|
||||
---------------------
|
||||
|
||||
Engines are identified by their address under the slaves' address spaces. We
|
||||
use a single cell for address and size. Engine nodes represent the endpoint
|
||||
FSI device, and are passed to those FSI device drivers' ->probe() functions.
|
||||
|
||||
For example, for a slave using a single 0x400-byte page starting at address
|
||||
0xc00:
|
||||
|
||||
engine@c00 {
|
||||
reg = <0xc00 0x400>;
|
||||
};
|
||||
|
||||
|
||||
Full example
|
||||
------------
|
||||
|
||||
Here's an example that illustrates:
|
||||
- an FSI master
|
||||
- connected to an FSI slave
|
||||
- that contains an engine that is an I2C master
|
||||
- connected to an I2C EEPROM
|
||||
|
||||
The FSI master may be connected to additional slaves, and slaves may have
|
||||
additional engines, but they don't necessarily need to be describe in the
|
||||
device tree if no extra platform information is required.
|
||||
|
||||
/* The GPIO-based FSI master node, describing the top level of the
|
||||
* FSI bus
|
||||
*/
|
||||
gpio-fsi {
|
||||
compatible = "fsi-master-gpio", "fsi-master";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* A FSI slave (aka. CFAM) at link 0, ID 0. */
|
||||
cfam@0,0 {
|
||||
reg = <0 0>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
/* FSI engine at 0xc00, using a single page. In this example,
|
||||
* it's an I2C master controller, so subnodes describe the
|
||||
* I2C bus.
|
||||
*/
|
||||
i2c-controller@c00 {
|
||||
reg = <0xc00 0x400>;
|
||||
|
||||
/* Engine-specific data. In this case, we're describing an
|
||||
* I2C bus, so we're conforming to the generic I2C binding
|
||||
*/
|
||||
compatible = "some-vendor,fsi-i2c-controller";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
/* I2C endpoint device: an Atmel EEPROM */
|
||||
eeprom@50 {
|
||||
compatible = "atmel,24c256";
|
||||
reg = <0x50>;
|
||||
pagesize = <64>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -109,9 +109,50 @@ lpc: lpc@1e789000 {
|
||||
};
|
||||
};
|
||||
|
||||
BMC Node Children
|
||||
==================
|
||||
|
||||
|
||||
Host Node Children
|
||||
==================
|
||||
|
||||
LPC Host Interface Controller
|
||||
-------------------
|
||||
|
||||
The LPC Host Interface Controller manages functions exposed to the host such as
|
||||
LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
|
||||
management and bus snoop configuration.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: One of:
|
||||
"aspeed,ast2400-lpc-ctrl";
|
||||
"aspeed,ast2500-lpc-ctrl";
|
||||
|
||||
- reg: contains offset/length values of the host interface controller
|
||||
memory regions
|
||||
|
||||
- clocks: contains a phandle to the syscon node describing the clocks.
|
||||
There should then be one cell representing the clock to use
|
||||
|
||||
- memory-region: A phandle to a reserved_memory region to be used for the LPC
|
||||
to AHB mapping
|
||||
|
||||
- flash: A phandle to the SPI flash controller containing the flash to
|
||||
be exposed over the LPC to AHB mapping
|
||||
|
||||
Example:
|
||||
|
||||
lpc-host@80 {
|
||||
lpc_ctrl: lpc-ctrl@0 {
|
||||
compatible = "aspeed,ast2500-lpc-ctrl";
|
||||
reg = <0x0 0x80>;
|
||||
clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
|
||||
memory-region = <&flash_memory>;
|
||||
flash = <&spi>;
|
||||
};
|
||||
};
|
||||
|
||||
LPC Host Controller
|
||||
-------------------
|
||||
|
||||
|
||||
@@ -11,17 +11,32 @@ Required properties:
|
||||
"fsl,imx6ul-ocotp" (i.MX6UL),
|
||||
"fsl,imx7d-ocotp" (i.MX7D/S),
|
||||
followed by "syscon".
|
||||
- #address-cells : Should be 1
|
||||
- #size-cells : Should be 1
|
||||
- reg: Should contain the register base and length.
|
||||
- clocks: Should contain a phandle pointing to the gated peripheral clock.
|
||||
|
||||
Optional properties:
|
||||
- read-only: disable write access
|
||||
|
||||
Example:
|
||||
Optional Child nodes:
|
||||
|
||||
- Data cells of ocotp:
|
||||
Detailed bindings are described in bindings/nvmem/nvmem.txt
|
||||
|
||||
Example:
|
||||
ocotp: ocotp@21bc000 {
|
||||
compatible = "fsl,imx6q-ocotp", "syscon";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "fsl,imx6sx-ocotp", "syscon";
|
||||
reg = <0x021bc000 0x4000>;
|
||||
clocks = <&clks IMX6QDL_CLK_IIM>;
|
||||
read-only;
|
||||
clocks = <&clks IMX6SX_CLK_OCOTP>;
|
||||
|
||||
tempmon_calib: calib@38 {
|
||||
reg = <0x38 4>;
|
||||
};
|
||||
|
||||
tempmon_temp_grade: temp-grade@20 {
|
||||
reg = <0x20 4>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
Device tree bindings for Low Power General Purpose Register found in i.MX6Q/D
|
||||
Secure Non-Volatile Storage.
|
||||
and i.MX7 Secure Non-Volatile Storage.
|
||||
|
||||
This DT node should be represented as a sub-node of a "syscon",
|
||||
"simple-mfd" node.
|
||||
@@ -8,6 +8,7 @@ Required properties:
|
||||
- compatible: should be one of the fallowing variants:
|
||||
"fsl,imx6q-snvs-lpgpr" for Freescale i.MX6Q/D/DL/S
|
||||
"fsl,imx6ul-snvs-lpgpr" for Freescale i.MX6UL
|
||||
"fsl,imx7d-snvs-lpgpr" for Freescale i.MX7D/S
|
||||
|
||||
Example:
|
||||
snvs: snvs@020cc000 {
|
||||
|
||||
@@ -709,6 +709,11 @@ The vmbus device regions are mapped into uio device resources:
|
||||
3) Network receive buffer region
|
||||
4) Network send buffer region
|
||||
|
||||
If a subchannel is created by a request to host, then the uio_hv_generic
|
||||
device driver will create a sysfs binary file for the per-channel ring buffer.
|
||||
For example:
|
||||
/sys/bus/vmbus/devices/3811fe4d-0fa0-4b62-981a-74fc1084c757/channels/21/ring
|
||||
|
||||
Further information
|
||||
===================
|
||||
|
||||
|
||||
+6
-1
@@ -6212,6 +6212,11 @@ F: Documentation/hw_random.txt
|
||||
F: drivers/char/hw_random/
|
||||
F: include/linux/hw_random.h
|
||||
|
||||
HARDWARE TRACING FACILITIES
|
||||
M: Alexander Shishkin <alexander.shishkin@linux.intel.com>
|
||||
S: Maintained
|
||||
F: drivers/hwtracing/
|
||||
|
||||
HARDWARE SPINLOCK CORE
|
||||
M: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
M: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
@@ -8140,7 +8145,7 @@ F: drivers/*/*/*pasemi*
|
||||
LINUX KERNEL DUMP TEST MODULE (LKDTM)
|
||||
M: Kees Cook <keescook@chromium.org>
|
||||
S: Maintained
|
||||
F: drivers/misc/lkdtm*
|
||||
F: drivers/misc/lkdtm/*
|
||||
|
||||
LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)
|
||||
M: Alan Stern <stern@rowland.harvard.edu>
|
||||
|
||||
@@ -902,6 +902,9 @@ BUILD_INTERRUPT3(hyperv_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
|
||||
BUILD_INTERRUPT3(hyperv_reenlightenment_vector, HYPERV_REENLIGHTENMENT_VECTOR,
|
||||
hyperv_reenlightenment_intr)
|
||||
|
||||
BUILD_INTERRUPT3(hv_stimer0_callback_vector, HYPERV_STIMER0_VECTOR,
|
||||
hv_stimer0_vector_handler)
|
||||
|
||||
#endif /* CONFIG_HYPERV */
|
||||
|
||||
ENTRY(page_fault)
|
||||
|
||||
@@ -1140,6 +1140,9 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
|
||||
|
||||
apicinterrupt3 HYPERV_REENLIGHTENMENT_VECTOR \
|
||||
hyperv_reenlightenment_vector hyperv_reenlightenment_intr
|
||||
|
||||
apicinterrupt3 HYPERV_STIMER0_VECTOR \
|
||||
hv_stimer0_callback_vector hv_stimer0_vector_handler
|
||||
#endif /* CONFIG_HYPERV */
|
||||
|
||||
idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
|
||||
|
||||
@@ -40,6 +40,7 @@ typedef struct {
|
||||
#endif
|
||||
#if IS_ENABLED(CONFIG_HYPERV)
|
||||
unsigned int irq_hv_reenlightenment_count;
|
||||
unsigned int hyperv_stimer0_count;
|
||||
#endif
|
||||
} ____cacheline_aligned irq_cpustat_t;
|
||||
|
||||
|
||||
@@ -106,9 +106,10 @@
|
||||
|
||||
#if IS_ENABLED(CONFIG_HYPERV)
|
||||
#define HYPERV_REENLIGHTENMENT_VECTOR 0xee
|
||||
#define HYPERV_STIMER0_VECTOR 0xed
|
||||
#endif
|
||||
|
||||
#define LOCAL_TIMER_VECTOR 0xed
|
||||
#define LOCAL_TIMER_VECTOR 0xec
|
||||
|
||||
#define NR_VECTORS 256
|
||||
|
||||
|
||||
@@ -173,6 +173,19 @@ void hv_remove_kexec_handler(void);
|
||||
void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
|
||||
void hv_remove_crash_handler(void);
|
||||
|
||||
/*
|
||||
* Routines for stimer0 Direct Mode handling.
|
||||
* On x86/x64, there are no percpu actions to take.
|
||||
*/
|
||||
void hv_stimer0_vector_handler(struct pt_regs *regs);
|
||||
void hv_stimer0_callback_vector(void);
|
||||
int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void));
|
||||
void hv_remove_stimer0_irq(int irq);
|
||||
|
||||
static inline void hv_enable_stimer0_percpu_irq(int irq) {}
|
||||
static inline void hv_disable_stimer0_percpu_irq(int irq) {}
|
||||
|
||||
|
||||
#if IS_ENABLED(CONFIG_HYPERV)
|
||||
extern struct clocksource *hyperv_cs;
|
||||
extern void *hv_hypercall_pg;
|
||||
|
||||
@@ -77,6 +77,9 @@
|
||||
/* Crash MSR available */
|
||||
#define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE (1 << 10)
|
||||
|
||||
/* stimer Direct Mode is available */
|
||||
#define HV_X64_STIMER_DIRECT_MODE_AVAILABLE (1 << 19)
|
||||
|
||||
/*
|
||||
* Feature identification: EBX indicates which flags were specified at
|
||||
* partition creation. The format is the same as the partition creation
|
||||
|
||||
@@ -37,6 +37,7 @@ EXPORT_SYMBOL_GPL(ms_hyperv);
|
||||
|
||||
#if IS_ENABLED(CONFIG_HYPERV)
|
||||
static void (*vmbus_handler)(void);
|
||||
static void (*hv_stimer0_handler)(void);
|
||||
static void (*hv_kexec_handler)(void);
|
||||
static void (*hv_crash_handler)(struct pt_regs *regs);
|
||||
|
||||
@@ -69,6 +70,41 @@ void hv_remove_vmbus_irq(void)
|
||||
EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
|
||||
EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
|
||||
|
||||
/*
|
||||
* Routines to do per-architecture handling of stimer0
|
||||
* interrupts when in Direct Mode
|
||||
*/
|
||||
|
||||
__visible void __irq_entry hv_stimer0_vector_handler(struct pt_regs *regs)
|
||||
{
|
||||
struct pt_regs *old_regs = set_irq_regs(regs);
|
||||
|
||||
entering_irq();
|
||||
inc_irq_stat(hyperv_stimer0_count);
|
||||
if (hv_stimer0_handler)
|
||||
hv_stimer0_handler();
|
||||
ack_APIC_irq();
|
||||
|
||||
exiting_irq();
|
||||
set_irq_regs(old_regs);
|
||||
}
|
||||
|
||||
int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void))
|
||||
{
|
||||
*vector = HYPERV_STIMER0_VECTOR;
|
||||
*irq = 0; /* Unused on x86/x64 */
|
||||
hv_stimer0_handler = handler;
|
||||
return 0;
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(hv_setup_stimer0_irq);
|
||||
|
||||
void hv_remove_stimer0_irq(int irq)
|
||||
{
|
||||
/* We have no way to deallocate the interrupt gate */
|
||||
hv_stimer0_handler = NULL;
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq);
|
||||
|
||||
void hv_setup_kexec_handler(void (*handler)(void))
|
||||
{
|
||||
hv_kexec_handler = handler;
|
||||
@@ -257,6 +293,10 @@ static void __init ms_hyperv_init_platform(void)
|
||||
alloc_intr_gate(HYPERV_REENLIGHTENMENT_VECTOR,
|
||||
hyperv_reenlightenment_vector);
|
||||
|
||||
/* Setup the IDT for stimer0 */
|
||||
if (ms_hyperv.misc_features & HV_X64_STIMER_DIRECT_MODE_AVAILABLE)
|
||||
alloc_intr_gate(HYPERV_STIMER0_VECTOR,
|
||||
hv_stimer0_callback_vector);
|
||||
#endif
|
||||
}
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user