Commit 069a0f32 authored by Greg Kroah-Hartman's avatar Greg Kroah-Hartman

Merge 4.12-rc5 into char-misc-next

We want the char/misc driver fixes in here as well.
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parents aca4e68a 32c1431e
...@@ -59,20 +59,28 @@ button driver uses the following 3 modes in order not to trigger issues. ...@@ -59,20 +59,28 @@ button driver uses the following 3 modes in order not to trigger issues.
If the userspace hasn't been prepared to ignore the unreliable "opened" If the userspace hasn't been prepared to ignore the unreliable "opened"
events and the unreliable initial state notification, Linux users can use events and the unreliable initial state notification, Linux users can use
the following kernel parameters to handle the possible issues: the following kernel parameters to handle the possible issues:
A. button.lid_init_state=open: A. button.lid_init_state=method:
When this option is specified, the ACPI button driver reports the
initial lid state using the returning value of the _LID control method
and whether the "opened"/"closed" events are paired fully relies on the
firmware implementation.
This option can be used to fix some platforms where the returning value
of the _LID control method is reliable but the initial lid state
notification is missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
B. button.lid_init_state=open:
When this option is specified, the ACPI button driver always reports the When this option is specified, the ACPI button driver always reports the
initial lid state as "opened" and whether the "opened"/"closed" events initial lid state as "opened" and whether the "opened"/"closed" events
are paired fully relies on the firmware implementation. are paired fully relies on the firmware implementation.
This may fix some platforms where the returning value of the _LID This may fix some platforms where the returning value of the _LID
control method is not reliable and the initial lid state notification is control method is not reliable and the initial lid state notification is
missing. missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
If the userspace has been prepared to ignore the unreliable "opened" events If the userspace has been prepared to ignore the unreliable "opened" events
and the unreliable initial state notification, Linux users should always and the unreliable initial state notification, Linux users should always
use the following kernel parameter: use the following kernel parameter:
B. button.lid_init_state=ignore: C. button.lid_init_state=ignore:
When this option is specified, the ACPI button driver never reports the When this option is specified, the ACPI button driver never reports the
initial lid state and there is a compensation mechanism implemented to initial lid state and there is a compensation mechanism implemented to
ensure that the reliable "closed" notifications can always be delievered ensure that the reliable "closed" notifications can always be delievered
......
...@@ -873,6 +873,15 @@ ...@@ -873,6 +873,15 @@
dscc4.setup= [NET] dscc4.setup= [NET]
dt_cpu_ftrs= [PPC]
Format: {"off" | "known"}
Control how the dt_cpu_ftrs device-tree binding is
used for CPU feature discovery and setup (if it
exists).
off: Do not use it, fall back to legacy cpu table.
known: Do not pass through unknown features to guests
or userspace, only those that the kernel is aware of.
dump_apple_properties [X86] dump_apple_properties [X86]
Dump name and content of EFI device properties on Dump name and content of EFI device properties on
x86 Macs. Useful for driver authors to determine x86 Macs. Useful for driver authors to determine
......
.. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>` .. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>`
.. |intel_pstate| replace:: :doc:`intel_pstate <intel_pstate>`
======================= =======================
CPU Performance Scaling CPU Performance Scaling
...@@ -75,7 +76,7 @@ feedback registers, as that information is typically specific to the hardware ...@@ -75,7 +76,7 @@ feedback registers, as that information is typically specific to the hardware
interface it comes from and may not be easily represented in an abstract, interface it comes from and may not be easily represented in an abstract,
platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers
to bypass the governor layer and implement their own performance scaling to bypass the governor layer and implement their own performance scaling
algorithms. That is done by the ``intel_pstate`` scaling driver. algorithms. That is done by the |intel_pstate| scaling driver.
``CPUFreq`` Policy Objects ``CPUFreq`` Policy Objects
...@@ -174,13 +175,13 @@ necessary to restart the scaling governor so that it can take the new online CPU ...@@ -174,13 +175,13 @@ necessary to restart the scaling governor so that it can take the new online CPU
into account. That is achieved by invoking the governor's ``->stop`` and into account. That is achieved by invoking the governor's ``->stop`` and
``->start()`` callbacks, in this order, for the entire policy. ``->start()`` callbacks, in this order, for the entire policy.
As mentioned before, the ``intel_pstate`` scaling driver bypasses the scaling As mentioned before, the |intel_pstate| scaling driver bypasses the scaling
governor layer of ``CPUFreq`` and provides its own P-state selection algorithms. governor layer of ``CPUFreq`` and provides its own P-state selection algorithms.
Consequently, if ``intel_pstate`` is used, scaling governors are not attached to Consequently, if |intel_pstate| is used, scaling governors are not attached to
new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked
to register per-CPU utilization update callbacks for each policy. These to register per-CPU utilization update callbacks for each policy. These
callbacks are invoked by the CPU scheduler in the same way as for scaling callbacks are invoked by the CPU scheduler in the same way as for scaling
governors, but in the ``intel_pstate`` case they both determine the P-state to governors, but in the |intel_pstate| case they both determine the P-state to
use and change the hardware configuration accordingly in one go from scheduler use and change the hardware configuration accordingly in one go from scheduler
context. context.
...@@ -257,7 +258,7 @@ are the following: ...@@ -257,7 +258,7 @@ are the following:
``scaling_available_governors`` ``scaling_available_governors``
List of ``CPUFreq`` scaling governors present in the kernel that can List of ``CPUFreq`` scaling governors present in the kernel that can
be attached to this policy or (if the ``intel_pstate`` scaling driver is be attached to this policy or (if the |intel_pstate| scaling driver is
in use) list of scaling algorithms provided by the driver that can be in use) list of scaling algorithms provided by the driver that can be
applied to this policy. applied to this policy.
...@@ -274,7 +275,7 @@ are the following: ...@@ -274,7 +275,7 @@ are the following:
the CPU is actually running at (due to hardware design and other the CPU is actually running at (due to hardware design and other
limitations). limitations).
Some scaling drivers (e.g. ``intel_pstate``) attempt to provide Some scaling drivers (e.g. |intel_pstate|) attempt to provide
information more precisely reflecting the current CPU frequency through information more precisely reflecting the current CPU frequency through
this attribute, but that still may not be the exact current CPU this attribute, but that still may not be the exact current CPU
frequency as seen by the hardware at the moment. frequency as seen by the hardware at the moment.
...@@ -284,13 +285,13 @@ are the following: ...@@ -284,13 +285,13 @@ are the following:
``scaling_governor`` ``scaling_governor``
The scaling governor currently attached to this policy or (if the The scaling governor currently attached to this policy or (if the
``intel_pstate`` scaling driver is in use) the scaling algorithm |intel_pstate| scaling driver is in use) the scaling algorithm
provided by the driver that is currently applied to this policy. provided by the driver that is currently applied to this policy.
This attribute is read-write and writing to it will cause a new scaling This attribute is read-write and writing to it will cause a new scaling
governor to be attached to this policy or a new scaling algorithm governor to be attached to this policy or a new scaling algorithm
provided by the scaling driver to be applied to it (in the provided by the scaling driver to be applied to it (in the
``intel_pstate`` case), as indicated by the string written to this |intel_pstate| case), as indicated by the string written to this
attribute (which must be one of the names listed by the attribute (which must be one of the names listed by the
``scaling_available_governors`` attribute described above). ``scaling_available_governors`` attribute described above).
...@@ -619,7 +620,7 @@ This file is located under :file:`/sys/devices/system/cpu/cpufreq/` and controls ...@@ -619,7 +620,7 @@ This file is located under :file:`/sys/devices/system/cpu/cpufreq/` and controls
the "boost" setting for the whole system. It is not present if the underlying the "boost" setting for the whole system. It is not present if the underlying
scaling driver does not support the frequency boost mechanism (or supports it, scaling driver does not support the frequency boost mechanism (or supports it,
but provides a driver-specific interface for controlling it, like but provides a driver-specific interface for controlling it, like
``intel_pstate``). |intel_pstate|).
If the value in this file is 1, the frequency boost mechanism is enabled. This If the value in this file is 1, the frequency boost mechanism is enabled. This
means that either the hardware can be put into states in which it is able to means that either the hardware can be put into states in which it is able to
......
...@@ -6,6 +6,7 @@ Power Management ...@@ -6,6 +6,7 @@ Power Management
:maxdepth: 2 :maxdepth: 2
cpufreq cpufreq
intel_pstate
.. only:: subproject and html .. only:: subproject and html
......
This diff is collapsed.
This diff is collapsed.
...@@ -36,7 +36,7 @@ Optional properties: ...@@ -36,7 +36,7 @@ Optional properties:
control gpios control gpios
- threshold: allows setting the "click"-threshold in the range - threshold: allows setting the "click"-threshold in the range
from 20 to 80. from 0 to 80.
- gain: allows setting the sensitivity in the range from 0 to - gain: allows setting the sensitivity in the range from 0 to
31. Note that lower values indicate higher 31. Note that lower values indicate higher
......
...@@ -16,6 +16,11 @@ Required properties: ...@@ -16,6 +16,11 @@ Required properties:
- reg: Base address of PMIC on Hi6220 SoC. - reg: Base address of PMIC on Hi6220 SoC.
- interrupt-controller: Hi655x has internal IRQs (has own IRQ domain). - interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
- pmic-gpios: The GPIO used by PMIC IRQ. - pmic-gpios: The GPIO used by PMIC IRQ.
- #clock-cells: From common clock binding; shall be set to 0
Optional properties:
- clock-output-names: From common clock binding to override the
default output clock name
Example: Example:
pmic: pmic@f8000000 { pmic: pmic@f8000000 {
...@@ -24,4 +29,5 @@ Example: ...@@ -24,4 +29,5 @@ Example:
interrupt-controller; interrupt-controller;
#interrupt-cells = <2>; #interrupt-cells = <2>;
pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
#clock-cells = <0>;
} }
...@@ -18,6 +18,8 @@ Optional properties: ...@@ -18,6 +18,8 @@ Optional properties:
"ext_clock" (External clock provided to the card). "ext_clock" (External clock provided to the card).
- post-power-on-delay-ms : Delay in ms after powering the card and - post-power-on-delay-ms : Delay in ms after powering the card and
de-asserting the reset-gpios (if any) de-asserting the reset-gpios (if any)
- power-off-delay-us : Delay in us after asserting the reset-gpios (if any)
during power off of the card.
Example: Example:
......
...@@ -26,6 +26,10 @@ Optional properties: ...@@ -26,6 +26,10 @@ Optional properties:
- interrupt-controller : Indicates the switch is itself an interrupt - interrupt-controller : Indicates the switch is itself an interrupt
controller. This is used for the PHY interrupts. controller. This is used for the PHY interrupts.
#interrupt-cells = <2> : Controller uses two cells, number and flag #interrupt-cells = <2> : Controller uses two cells, number and flag
- eeprom-length : Set to the length of an EEPROM connected to the
switch. Must be set if the switch can not detect
the presence and/or size of a connected EEPROM,
otherwise optional.
- mdio : Container of PHY and devices on the switches MDIO - mdio : Container of PHY and devices on the switches MDIO
bus. bus.
- mdio? : Container of PHYs and devices on the external MDIO - mdio? : Container of PHYs and devices on the external MDIO
......
...@@ -15,6 +15,10 @@ Optional properties: ...@@ -15,6 +15,10 @@ Optional properties:
- phy-reset-active-high : If present then the reset sequence using the GPIO - phy-reset-active-high : If present then the reset sequence using the GPIO
specified in the "phy-reset-gpios" property is reversed (H=reset state, specified in the "phy-reset-gpios" property is reversed (H=reset state,
L=operation state). L=operation state).
- phy-reset-post-delay : Post reset delay in milliseconds. If present then
a delay of phy-reset-post-delay milliseconds will be observed after the
phy-reset-gpios has been toggled. Can be omitted thus no delay is
observed. Delay is in range of 1ms to 1000ms. Other delays are invalid.
- phy-supply : regulator that powers the Ethernet PHY. - phy-supply : regulator that powers the Ethernet PHY.
- phy-handle : phandle to the PHY device connected to this device. - phy-handle : phandle to the PHY device connected to this device.
- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory. - fixed-link : Assume a fixed link. See fixed-link.txt in the same directory.
......
...@@ -247,7 +247,6 @@ bias-bus-hold - latch weakly ...@@ -247,7 +247,6 @@ bias-bus-hold - latch weakly
bias-pull-up - pull up the pin bias-pull-up - pull up the pin
bias-pull-down - pull down the pin bias-pull-down - pull down the pin
bias-pull-pin-default - use pin-default pull state bias-pull-pin-default - use pin-default pull state
bi-directional - pin supports simultaneous input/output operations
drive-push-pull - drive actively high and low drive-push-pull - drive actively high and low
drive-open-drain - drive with open drain drive-open-drain - drive with open drain
drive-open-source - drive with open source drive-open-source - drive with open source
...@@ -260,7 +259,6 @@ input-debounce - debounce mode with debound time X ...@@ -260,7 +259,6 @@ input-debounce - debounce mode with debound time X
power-source - select between different power supplies power-source - select between different power supplies
low-power-enable - enable low power mode low-power-enable - enable low power mode
low-power-disable - disable low power mode low-power-disable - disable low power mode
output-enable - enable output on pin regardless of output value
output-low - set the pin to output mode with low level output-low - set the pin to output mode with low level
output-high - set the pin to output mode with high level output-high - set the pin to output mode with high level
slew-rate - set the slew rate slew-rate - set the slew rate
......
...@@ -10,6 +10,7 @@ Required properties: ...@@ -10,6 +10,7 @@ Required properties:
- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc; - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
- "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs; - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs;
- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs; - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
- "amlogic,meson8-usb": The DWC2 USB controller instance in Amlogic Meson8 SoCs;
- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs; - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs; - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
- "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs; - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
......
...@@ -15,7 +15,7 @@ It has been tested with the following devices: ...@@ -15,7 +15,7 @@ It has been tested with the following devices:
The driver allows configuration of the touch screen via a set of sysfs files: The driver allows configuration of the touch screen via a set of sysfs files: