Commit 0ad5b053 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'char-misc-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

Pull char/misc driver updates from Greg KH:
 "Here is the big set of char/misc/other driver patches for 5.7-rc1.

  Lots of things in here, and it's later than expected due to some
  reverts to resolve some reported issues. All is now clean with no
  reported problems in linux-next.

  Included in here is:
   - interconnect updates
   - mei driver updates
   - uio updates
   - nvmem driver updates
   - soundwire updates
   - binderfs updates
   - coresight updates
   - habanalabs updates
   - mhi new bus type and core
   - extcon driver updates
   - some Kconfig cleanups
   - other small misc driver cleanups and updates

  As mentioned, all have been in linux-next for a while, and with the
  last two reverts, all is calm and good"

* tag 'char-misc-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (174 commits)
  Revert "driver core: platform: Initialize dma_parms for platform devices"
  Revert "amba: Initialize dma_parms for amba devices"
  amba: Initialize dma_parms for amba devices
  driver core: platform: Initialize dma_parms for platform devices
  bus: mhi: core: Drop the references to mhi_dev in mhi_destroy_device()
  bus: mhi: core: Initialize bhie field in mhi_cntrl for RDDM capture
  bus: mhi: core: Add support for reading MHI info from device
  misc: rtsx: set correct pcr_ops for rts522A
  speakup: misc: Use dynamic minor numbers for speakup devices
  mei: me: add cedar fork device ids
  coresight: do not use the BIT() macro in the UAPI header
  Documentation: provide IBM contacts for embargoed hardware
  nvmem: core: remove nvmem_sysfs_get_groups()
  nvmem: core: use is_bin_visible for permissions
  nvmem: core: use device_register and device_unregister
  nvmem: core: add root_only member to nvmem device struct
  extcon: axp288: Add wakeup support
  extcon: Mark extcon_get_edev_name() function as exported symbol
  extcon: palmas: Hide error messages if gpio returns -EPROBE_DEFER
  dt-bindings: extcon: usbc-cros-ec: convert extcon-usbc-cros-ec.txt to yaml format
  ...
parents ff2ae607 885a6471
......@@ -43,6 +43,20 @@ Description: Allows the root user to read or write directly through the
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/data64
Date: Jan 2020
KernelVersion: 5.6
Contact: oded.gabbay@gmail.com
Description: Allows the root user to read or write 64 bit data directly
through the device's PCI bar. Writing to this file generates a
write transaction while reading from the file generates a read
transaction. This custom interface is needed (instead of using
the generic Linux user-space PCI mapping) because the DDR bar
is very small compared to the DDR memory and only the driver can
move the bar before and after the transaction.
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/device
Date: Jan 2019
KernelVersion: 5.1
......
What: /sys/bus/coresight/devices/<cti-name>/enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable/Disable the CTI hardware.
What: /sys/bus/coresight/devices/<cti-name>/powered
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Indicate if the CTI hardware is powered.
What: /sys/bus/coresight/devices/<cti-name>/ctmid
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Display the associated CTM ID
What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Number of devices connected to triggers on this CTI
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Name of connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Input trigger signals from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Functional types for the input trigger signals
from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Output trigger signals to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Functional types for the output trigger signals
to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Select the index for inen and outen registers.
What: /sys/bus/coresight/devices/<cti-name>/regs/inen
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIINEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/outen
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIOUTEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/gate
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write CTIGATE register.
What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write ASICCTL register.
What: /sys/bus/coresight/devices/<cti-name>/regs/intack
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write the INTACK register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appset
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Set CTIAPPSET register to activate channel. Read back to
determine current value of register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appclear
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write APPCLEAR register to deactivate channel.
What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write APPPULSE to pulse a channel active for one clock
cycle.
What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read current status of channel inputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of channel outputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of input trigger signals
What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of output trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Attach a CTI input trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Detach a CTI input trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Attach a CTI output trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Detach a CTI output trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable CTIGATE for single channel (W) or list enabled
channels through the gate (R).
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Disable CTIGATE for single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Activate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Deactivate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Pulse a single channel - activate for a single clock cycle.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) List of output triggers filtered across all connections.
What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable or disable trigger output signal filtering.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) show channels with at least one attached trigger signal.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) show channels with no attached trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Write channel number to select a channel to view, read to
see selected channel number.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read to see input triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read to see output triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Clear all channel / trigger programming.
......@@ -40,3 +40,11 @@ Description: (RW) Trigger window switch for the MSC's buffer, in
triggering a window switch for the buffer. Returns an error in any
other operating mode or attempts to write something other than "1".
What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/stop_on_full
Date: March 2020
KernelVersion: 5.7
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure whether trace stops when the last available window
becomes full (1/y/Y) or wraps around and continues until the next
window becomes available again (0/n/N).
What: /sys/devices/*/<our-device>/nvmem
Date: December 2017
Contact: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Description: read-only access to the efuse on the Ingenic JZ4780 SoC
The SoC has a one time programmable 8K efuse that is
split into segments. The driver supports read only.
The segments are
0x000 64 bit Random Number
0x008 128 bit Ingenic Chip ID
0x018 128 bit Customer ID
0x028 3520 bit Reserved
0x1E0 8 bit Protect Segment
0x1E1 2296 bit HDMI Key
0x300 2048 bit Security boot key
Users: any user space application which wants to read the Chip
and Customer ID
......@@ -54,6 +54,9 @@ If you make a mistake with the syntax, the write will fail thus::
<debugfs>/dynamic_debug/control
-bash: echo: write error: Invalid argument
Note, for systems without 'debugfs' enabled, the control file can be
found in ``/proc/dynamic_debug/control``.
Viewing Dynamic Debug Behaviour
===============================
......
This diff is collapsed.
......@@ -45,6 +45,10 @@ its hardware characteristcs.
- Coresight Address Translation Unit (CATU)
"arm,coresight-catu", "arm,primecell";
- Coresight Cross Trigger Interface (CTI):
"arm,coresight-cti", "arm,primecell";
See coresight-cti.yaml for full CTI definitions.
* reg: physical base address and length of the register
set(s) of the component.
......@@ -72,6 +76,9 @@ its hardware characteristcs.
* reg-names: the only acceptable values are "stm-base" and
"stm-stimulus-base", each corresponding to the areas defined in "reg".
* Required properties for Coresight Cross Trigger Interface (CTI)
See coresight-cti.yaml for full CTI definitions.
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators and non-configurable funnels:
......
ChromeOS EC USB Type-C cable and accessories detection
On ChromeOS systems with USB Type C ports, the ChromeOS Embedded Controller is
able to detect the state of external accessories such as display adapters
or USB devices when said accessories are attached or detached.
The node for this device must be under a cros-ec node like google,cros-ec-spi
or google,cros-ec-i2c.
Required properties:
- compatible: Should be "google,extcon-usbc-cros-ec".
- google,usb-port-id: Specifies the USB port ID to use.
Example:
cros-ec@0 {
compatible = "google,cros-ec-i2c";
...
extcon {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <0>;
};
}
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/extcon/extcon-usbc-cros-ec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ChromeOS EC USB Type-C cable and accessories detection
maintainers:
- Benson Leung <bleung@chromium.org>
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
description: |
On ChromeOS systems with USB Type C ports, the ChromeOS Embedded Controller is
able to detect the state of external accessories such as display adapters
or USB devices when said accessories are attached or detached.
The node for this device must be under a cros-ec node like google,cros-ec-spi
or google,cros-ec-i2c.
properties:
compatible:
const: google,extcon-usbc-cros-ec
google,usb-port-id:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
description: the port id
minimum: 0
maximum: 255
required:
- compatible
- google,usb-port-id
additionalProperties: false
examples:
- |
spi0 {
#address-cells = <1>;
#size-cells = <0>;
cros-ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
usbc_extcon0: extcon0 {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <0>;
};
usbc_extcon1: extcon1 {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <1>;
};
};
};
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,bcm-voter.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm BCM-Voter Interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
description: |
The Bus Clock Manager (BCM) is a dedicated hardware accelerator that manages
shared system resources by aggregating requests from multiple Resource State
Coordinators (RSC). Interconnect providers are able to vote for aggregated
thresholds values from consumers by communicating through their respective
RSCs.
properties:
compatible:
enum:
- qcom,bcm-voter
required:
- compatible
additionalProperties: false
examples:
# Example 1: apps bcm_voter on SDM845 SoC should be defined inside &apps_rsc node
# as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt
- |
apps_bcm_voter: bcm_voter {
compatible = "qcom,bcm-voter";
};
# Example 2: disp bcm_voter on SDM845 should be defined inside &disp_rsc node
# as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt
- |
disp_bcm_voter: bcm_voter {
compatible = "qcom,bcm-voter";
};
...
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,osm-l3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Operating State Manager (OSM) L3 Interconnect Provider
maintainers:
- Sibi Sankar <sibis@codeaurora.org>
description:
L3 cache bandwidth requirements on Qualcomm SoCs is serviced by the OSM.
The OSM L3 interconnect provider aggregates the L3 bandwidth requests
from CPU/GPU and relays it to the OSM.
properties:
compatible:
enum:
- qcom,sc7180-osm-l3
- qcom,sdm845-osm-l3
reg:
maxItems: 1
clocks:
items:
- description: xo clock
- description: alternate clock
clock-names:
items:
- const: xo
- const: alternate
'#interconnect-cells':
const: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#interconnect-cells'
additionalProperties: false
examples:
- |
#define GPLL0 165
#define RPMH_CXO_CLK 0
osm_l3: interconnect@17d41000 {
compatible = "qcom,sdm845-osm-l3";
reg = <0x17d41000 0x1400>;
clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
clock-names = "xo", "alternate";
#interconnect-cells = <1>;
};
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,sc7180.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm SC7180 Network-On-Chip Interconnect
maintainers:
- Odelu Kukatla <okukatla@codeaurora.org>
description: |
SC7180 interconnect providers support system bandwidth requirements through
RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
able to communicate with the BCM through the Resource State Coordinator (RSC)
associated with each execution environment. Provider nodes must point to at
least one RPMh device child node pertaining to their RSC and each provider
can map to multiple RPMh resources.
properties:
reg:
maxItems: 1
compatible:
enum:
- qcom,sc7180-aggre1-noc
- qcom,sc7180-aggre2-noc
- qcom,sc7180-camnoc-virt
- qcom,sc7180-compute-noc
- qcom,sc7180-config-noc
- qcom,sc7180-dc-noc
- qcom,sc7180-gem-noc
- qcom,sc7180-ipa-virt
- qcom,sc7180-mc-virt
- qcom,sc7180-mmss-noc
- qcom,sc7180-npu-noc
- qcom,sc7180-qup-virt
- qcom,sc7180-system-noc
'#interconnect-cells':
const: 1
qcom,bcm-voters:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
List of phandles to qcom,bcm-voter nodes that are required by
this interconnect to send RPMh commands.
qcom,bcm-voter-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: |
Names for each of the qcom,bcm-voters specified.
required:
- compatible
- reg
- '#interconnect-cells'
- qcom,bcm-voters
additionalProperties: false
examples:
- |
#include <dt-bindings/interconnect/qcom,sc7180.h>
config_noc: interconnect@1500000 {
compatible = "qcom,sc7180-config-noc";
reg = <0 0x01500000 0 0x28000>;
#interconnect-cells = <1>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
system_noc: interconnect@1620000 {
compatible = "qcom,sc7180-system-noc";
reg = <0 0x01620000 0 0x17080>;
#interconnect-cells = <1>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
mmss_noc: interconnect@1740000 {
compatible = "qcom,sc7180-mmss-noc";
reg = <0 0x01740000 0 0x1c100>;
#interconnect-cells = <1>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
Qualcomm SDM845 Network-On-Chip interconnect driver binding
-----------------------------------------------------------
SDM845 interconnect providers support system bandwidth requirements through
RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
able to communicate with the BCM through the Resource State Coordinator (RSC)
associated with each execution environment. Provider nodes must reside within
an RPMh device node pertaining to their RSC and each provider maps to a single
RPMh resource.
Required properties :
- compatible : shall contain only one of the following:
"qcom,sdm845-rsc-hlos"
- #interconnect-cells : should contain 1
Examples:
apps_rsc: rsc {
rsc_hlos: interconnect {
compatible = "qcom,sdm845-rsc-hlos";
#interconnect-cells = <1>;
};
};
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,sdm845.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm SDM845 Network-On-Chip Interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
description: |
SDM845 interconnect providers support system bandwidth requirements through
RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
able to communicate with the BCM through the Resource State Coordinator (RSC)
associated with each execution environment. Provider nodes must point to at
least one RPMh device child node pertaining to their RSC and each provider
can map to multiple RPMh resources.
properties:
reg:
maxItems: 1
compatible:
enum:
- qcom,sdm845-aggre1-noc
- qcom,sdm845-aggre2-noc
- qcom,sdm845-config-noc
- qcom,sdm845-dc-noc
- qcom,sdm845-gladiator-noc
- qcom,sdm845-mem-noc
- qcom,sdm845-mmss-noc
- qcom,sdm845-system-noc
'#interconnect-cells':
const: 1
qcom,bcm-voters:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
List of phandles to qcom,bcm-voter nodes that are required by
this interconnect to send RPMh commands.
qcom,bcm-voter-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: |
Names for each of the qcom,bcm-voters specified.
required:
- compatible
- reg
- '#interconnect-cells'
- qcom,bcm-voters
additionalProperties: false
examples:
- |
#include <dt-bindings/interconnect/qcom,sdm845.h>
mem_noc: interconnect@1380000 {
compatible = "qcom,sdm845-mem-noc";
reg = <0 0x01380000 0 0x27200>;
#interconnect-cells = <1>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
mmss_noc: interconnect@1740000 {
compatible = "qcom,sdm845-mmss-noc";
reg = <0 0x01740000 0 0x1c1000>;
#interconnect-cells = <1>;
qcom,bcm-voter-names = "apps", "disp";
qcom,bcm-voters = <&apps_bcm_voter>, <&disp_bcm_voter>;
};
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/nvmem/ingenic,jz4780-efuse.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ingenic JZ EFUSE driver bindings
maintainers:
- PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
allOf:
- $ref: "nvmem.yaml#"
properties:
compatible:
enum:
- ingenic,jz4780-efuse
reg:
maxItems: 1
clocks:
# Handle for the ahb for the efuse.
maxItems: 1
required:
- compatible
- reg
- clocks
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/jz4780-cgu.h>
efuse@134100d0 {
compatible = "ingenic,jz4780-efuse";
reg = <0x134100d0 0x2c>;
clocks = <&cgu JZ4780_CLK_AHB2>;
};
...
......@@ -156,22 +156,27 @@ Below shows the SoundWire stream states and state transition diagram. ::
+-----------+ +------------+ +----------+ +----------+
| ALLOCATED +---->| CONFIGURED +---->| PREPARED +---->| ENABLED |
| STATE | | STATE | | STATE | | STATE |
+-----------+ +------------+ +----------+ +----+-----+
^
|
|
v
+----------+ +------------+ +----+-----+
+-----------+ +------------+ +---+--+---+ +----+-----+
^ ^ ^
| | |
__| |___________ |
| | |
v | v
+----------+ +-----+------+ +-+--+-----+
| RELEASED |<----------+ DEPREPARED |<-------+ DISABLED |
| STATE | | STATE | | STATE |
+----------+ +------------+ +----------+
NOTE: State transition between prepare and deprepare is supported in Spec
but not in the software (subsystem)
NOTE: State transitions between ``SDW_STREAM_ENABLED`` and
``SDW_STREAM_DISABLED`` are only relevant when then INFO_PAUSE flag is
supported at the ALSA/ASoC level. Likewise the transition between
``SDW_DISABLED_STATE`` and ``SDW_PREPARED_STATE`` depends on the
INFO_RESUME flag.
NOTE2: Stream state transition checks need to be handled by caller
framework, for example ALSA/ASoC. No checks for stream transition exist in
SoundWire subsystem.
NOTE2: The framework implements basic state transition checks, but
does not e.g. check if a transition from DISABLED to ENABLED is valid
on a specific platform. Such tests need to be added at the ALSA/ASoC
level.
Stream State Operations
-----------------------
......@@ -246,6 +251,9 @@ SDW_STREAM_PREPARED
Prepare state of stream. Operations performed before entering in this state:
(0) Steps 1 and 2 are omitted in the case of a resume operation,
where the bus bandwidth is known.
(1) Bus parameters such as bandwidth, frame shape, clock frequency,
are computed based on current stream as well as already active
stream(s) on Bus. Re-computation is required to accommodate current
......@@ -270,9 +278,11 @@ Prepare state of stream. Operations performed before entering in this state:
After all above operations are successful, stream state is set to
``SDW_STREAM_PREPARED``.
Bus implements below API for PREPARE state which needs to be called once per
stream. From ASoC DPCM framework, this stream state is linked to
.prepare() operation.
Bus implements below API for PREPARE state which needs to be called
once per stream. From ASoC DPCM framework, this stream state is linked
to .prepare() operation. Since the .trigger() operations may not
follow the .prepare(), a direct transition from
``SDW_STREAM_PREPARED`` to ``SDW_STREAM_DEPREPARED`` is allowed.
.. code-block:: c
......@@ -332,6 +342,14 @@ Bus implements below API for DISABLED state which needs to be called once
per stream. From ASoC DPCM framework, this stream state is linked to
.trigger() stop operation.
When the INFO_PAUSE flag is supported, a direct transition to
``SDW_STREAM_ENABLED`` is allowed.
For resume operations where ASoC will use the .prepare() callback, the
stream can transition from ``SDW_STREAM_DISABLED`` to
``SDW_STREAM_PREPARED``, with all required settings restored but
without updating the bandwidth and bit allocation.
.. code-block:: c
int sdw_disable_stream(struct sdw_stream_runtime * stream);
......@@ -353,9 +371,18 @@ state:
After all above operations are successful, stream state is set to
``SDW_STREAM_DEPREPARED``.
Bus implements below API for DEPREPARED state which needs to be called once
per stream. From ASoC DPCM framework, this stream state is linked to
.trigger() stop operation.
Bus implements below API for DEPREPARED state which needs to be called
once per stream. ALSA/ASoC do not have a concept of 'deprepare', and
the mapping from this stream state to ALSA/ASoC operation may be
implementation specific.
When the INFO_PAUSE flag is supported, the stream state is linked to
the .hw_free() operation - the stream is not deprepared on a
TRIGGER_STOP.
Other implementations may transition to the ``SDW_STREAM_DEPREPARED``
state on TRIGGER_STOP, should they require a transition through the
``SDW_STREAM_PREPARED`` state.
.. code-block:: c
......
......@@ -134,6 +134,7 @@ needed).
scsi/index
misc-devices/index
scheduler/index
mhi/index
Architecture-agnostic documentation
-----------------------------------
......
.. SPDX-License-Identifier: GPL-2.0
===
MHI
===
.. toctree::
:maxdepth: 1
mhi
topology
.. only:: subproject and html
Indices
=======
* :ref:`genindex`
.. SPDX-License-Identifier: GPL-2.0
==========================
MHI (Modem Host Interface)
==========================
This document provides information about the MHI protocol.
Overview
========
MHI is a protocol developed by Qualcomm Innovation Center, Inc. It is used
by the host processors to control and communicate with modem devices over high
speed peripheral buses or shared memory. Even though MHI can be easily adapted
to any peripheral buses, it is primarily used with PCIe based devices. MHI
provides logical channels over the physical buses and allows transporting the
modem protocols, such as IP data packets, modem control messages, and
diagnostics over at least one of those logical channels. Also, the MHI
protocol provides data acknowledgment feature and manages the power state of the
modems via one or more logical channels.
MHI Internals
=============
MMIO
----
MMIO (Memory mapped IO) consists of a set of registers in the device hardware,
which are mapped to the host memory space by the peripheral buses like PCIe.
Following are the major components of MMIO register space:
MHI control registers: Access to MHI configurations registers
MHI BHI registers: BHI (Boot Host Interface) registers are used by the host
for downloading the firmware to the device before MHI initialization.
Channel Doorbell array: Channel Doorbell (DB) registers used by the host to
notify the device when there is new work to do.
Event Doorbell array: Associated with event context array, the Event Doorbell
(DB) registers are used by the host to notify the device when new events are
available.
Debug registers: A set of registers and counters used by the device to expose
debugging information like performance, functional, and stability to the host.
Data structures
---------------
All data structures used by MHI are in the host system memory. Using the
physical interface, the device accesses those data structures. MHI data
structures and data buffers in the host system memory regions are mapped for
the device.
Channel context array: All channel configurations are organized in channel
context data array.
Transfer rings: Used by the host to schedule work items for a channel. The
transfer rings are organized as a circular queue of Transfer Descriptors (TD).
Event context array: All event configurations are organized in the event context
data array.
Event rings: Used by the device to send completion and state transition messages
to the host
Command context array: All command configurations are organized in command
context data array.
Command rings: Used by the host to send MHI commands to the device. The command
rings are organized as a circular queue of Command Descriptors (CD).
Channels
--------
MHI channels are logical, unidirectional data pipes between a host and a device.
The concept of channels in MHI is similar to endpoints in USB. MHI supports up
to 256 channels. However, specific device implementations may support less than
the maximum number of channels allowed.
Two unidirectional channels with their associated transfer rings form a
bidirectional data pipe, which can be used by the upper-layer protocols to
transport application data packets (such as IP packets, modem control messages,
diagnostics messages, and so on). Each channel is associated with a single
transfer ring.
Transfer rings
--------------
Transfers between the host and device are organized by channels and defined by
Transfer Descriptors (TD). TDs are managed through transfer rings, which are
defined for each channel between the device and host and reside in the host
memory. TDs consist of one or more ring elements (or transfer blocks)::
[Read Pointer (RP)] ----------->[Ring Element] } TD
[Write Pointer (WP)]- [Ring Element]
- [Ring Element]
--------->[Ring Element]
[Ring Element]
Below is the basic usage of transfer rings:
* Host allocates memory for transfer ring.
* Host sets the base pointer, read pointer, and write pointer in corresponding
channel context.
* Ring is considered empty when RP == WP.
* Ring is considered full when WP + 1 == RP.
* RP indicates the next element to be serviced by the device.
* When the host has a new buffer to send, it updates the ring element with
buffer information, increments the WP to the next element and rings the
associated channel DB.
Event rings
-----------
Events from the device to host are organized in event rings and defined by Event
Descriptors (ED). Event rings are used by the device to report events such as
data transfer completion status, command completion status, and state changes
to the host. Event rings are the array of EDs that resides in the host
memory. EDs consist of one or more ring elements (or transfer blocks)::
[Read Pointer (RP)] ----------->[Ring Element] } ED
[Write Pointer (WP)]- [Ring Element]
- [Ring Element]
--------->[Ring Element]
[Ring Element]
Below is the basic usage of event rings:
* Host allocates memory for event ring.
* Host sets the base pointer, read pointer, and write pointer in corresponding
channel context.
* Both host and device has a local copy of RP, WP.
* Ring is considered empty (no events to service) when WP + 1 == RP.
* Ring is considered full of events when RP == WP.
* When there is a new event the device needs to send, the device updates ED
pointed by RP, increments the RP to the next element and triggers the
interrupt.
Ring Element
------------
A Ring Element is a data structure used to transfer a single block
of data between the host and the device. Transfer ring element types contain a
single buffer pointer, the size of the buffer, and additional control
information. Other ring element types may only contain control and status
information. For single buffer operations, a ring descriptor is composed of a
single element. For large multi-buffer operations (such as scatter and gather),
elements can be chained to form a longer descriptor.
MHI Operations
==============
MHI States
----------
MHI_STATE_RESET
~~~~~~~~~~~~~~~
MHI is in reset state after power-up or hardware reset. The host is not allowed
to access device MMIO register space.
MHI_STATE_READY
~~~~~~~~~~~~~~~
MHI is ready for initialization. The host can start MHI initialization by
programming MMIO registers.
MHI_STATE_M0
~~~~~~~~~~~~
MHI is running and operational in the device. The host can start channels by
issuing channel start command.
MHI_STATE_M1
~~~~~~~~~~~~
MHI operation is suspended by the device. This state is entered when the
device detects inactivity at the physical interface within a preset time.
MHI_STATE_M2
~~~~~~~~~~~~
MHI is in low power state. MHI operation is suspended and the device may
enter lower power mode.
MHI_STATE_M3
~~~~~~~~~~~~
MHI operation stopped by the host. This state is entered when the host suspends
MHI operation.
MHI Initialization
------------------
After system boots, the device is enumerated over the physical interface.
In the case of PCIe, the device is enumerated and assigned BAR-0 for
the device's MMIO register space. To initialize the MHI in a device,
the host performs the following operations:
* Allocates the MHI context for event, channel and command arrays.
* Initializes the context array, and prepares interrupts.
* Waits until the device enters READY state.
* Programs MHI MMIO registers and sets device into MHI_M0 state.
* Waits for the device to enter M0 state.
MHI Data Transfer
-----------------
MHI data transfer is initiated by the host to transfer data to the device.
Following are the sequence of operations performed by the host to transfer
data to device:
* Host prepares TD with buffer information.
* Host increments the WP of the corresponding channel transfer ring.
* Host rings the channel DB register.
* Device wakes up to process the TD.
* Device generates a completion event for the processed TD by updating ED.
* Device increments the RP of the corresponding event ring.
* Device triggers IRQ to wake up the host.
* Host wakes up and checks the event ring for completion event.
* Host updates the WP of the corresponding event ring to indicate that the
data transfer has been completed successfully.
.. SPDX-License-Identifier: GPL-2.0
============
MHI Topology
============
This document provides information about the MHI topology modeling and
representation in the kernel.
MHI Controller
--------------
MHI controller driver manages the interaction with the MHI client devices
such as the external modems and WiFi chipsets. It is also the MHI bus master
which is in charge of managing the physical link between the host and device.
It is however not involved in the actual data transfer as the data transfer
is taken care by the physical bus such as PCIe. Each controller driver exposes
channels and events based on the client device type.
Below are the roles of the MHI controller driver:
* Turns on the physical bus and establishes the link to the device
* Configures IRQs, IOMMU, and IOMEM
* Allocates struct mhi_controller and registers with the MHI bus framework
with channel and event configurations using mhi_register_controller.
* Initiates power on and shutdown sequence
* Initiates suspend and resume power management operations of the device.
MHI Device
----------
MHI device is the logical device which binds to a maximum of two MHI channels
for bi-directional communication. Once MHI is in powered on state, the MHI
core will create MHI devices based on the channel configuration exposed
by the controller. There can be a single MHI device for each channel or for a
couple of channels.
Each supported device is enumerated in::
/sys/bus/mhi/devices/
MHI Driver
----------
MHI driver is the client driver which binds to one or more MHI devices. The MHI
driver sends and receives the upper-layer protocol packets like IP packets,
modem control messages, and diagnostics messages over MHI. The MHI core will
bind the MHI devices to the MHI driver.
Each supported driver is enumerated in::
/sys/bus/mhi/drivers/
Below are the roles of the MHI driver:
* Registers the driver with the MHI bus framework using mhi_driver_register.
* Prepares the device for transfer by calling mhi_prepare_for_transfer.
* Initiates data transfer by calling mhi_queue_transfer.
* Once the data transfer is finished, calls mhi_unprepare_from_transfer to
end data transfer.
......@@ -246,7 +246,8 @@ an involved disclosed party. The current ambassadors list:
============= ========================================================
ARM Grant Likely <grant.likely@arm.com>
AMD Tom Lendacky <tom.lendacky@amd.com>
IBM
IBM Z Christian Borntraeger <borntraeger@de.ibm.com>
IBM Power Anton Blanchard <anton@linux.ibm.com>
Intel Tony Luck <tony.luck@intel.com>
Qualcomm Trilok Soni <tsoni@codeaurora.org>
......
.. SPDX-License-Identifier: GPL-2.0
=============================================
CoreSight Embedded Cross Trigger (CTI & CTM).
=============================================
:Author: Mike Leach <mike.leach@linaro.org>
:Date: November 2019
Hardware Description
--------------------
The CoreSight Cross Trigger Interface (CTI) is a hardware device that takes
individual input and output hardware signals known as triggers to and from
devices and interconnects them via the Cross Trigger Matrix (CTM) to other
devices via numbered channels, in order to propagate events between devices.
e.g.::
0000000 in_trigs :::::::
0 C 0----------->: : +======>(other CTI channel IO)
0 P 0<-----------: : v
0 U 0 out_trigs : : Channels ***** :::::::
0000000 : CTI :<=========>*CTM*<====>: CTI :---+
####### in_trigs : : (id 0-3) ***** ::::::: v
# ETM #----------->: : ^ #######
# #<-----------: : +---# ETR #
####### out_trigs ::::::: #######
The CTI driver enables the programming of the CTI to attach triggers to
channels. When an input trigger becomes active, the attached channel will
become active. Any output trigger attached to that channel will also
become active. The active channel is propagated to other CTIs via the CTM,
activating connected output triggers there, unless filtered by the CTI
channel gate.
It is also possible to activate a channel using system software directly
programming registers in the CTI.
The CTIs are registered by the system to be associated with CPUs and/or other
CoreSight devices on the trace data path. When these devices are enabled the
attached CTIs will also be enabled. By default/on power up the CTIs have
no programmed trigger/channel attachments, so will not affect the system
until explicitly programmed.
The hardware trigger connections between CTIs and devices is implementation
defined, unless the CPU/ETM combination is a v8 architecture, in which case
the connections have an architecturally defined standard layout.
The hardware trigger signals can also be connected to non-CoreSight devices
(e.g. UART), or be propagated off chip as hardware IO lines.
All the CTI devices are associated with a CTM. On many systems there will be a
single effective CTM (one CTM, or multiple CTMs all interconnected), but it is
possible that systems can have nets of CTIs+CTM that are not interconnected by
a CTM to each other. On these systems a CTM index is declared to associate
CTI devices that are interconnected via a given CTM.
Sysfs files and directories
---------------------------
The CTI devices appear on the existing CoreSight bus alongside the other
CoreSight devices::
>$ ls /sys/bus/coresight/devices
cti_cpu0 cti_cpu2 cti_sys0 etm0 etm2 funnel0 replicator0 tmc_etr0
cti_cpu1 cti_cpu3 cti_sys1 etm1 etm3 funnel1 tmc_etf0 tpiu0
The ``cti_cpu<N>`` named CTIs are associated with a CPU, and any ETM used by
that core. The ``cti_sys<N>`` CTIs are general system infrastructure CTIs that
can be associated with other CoreSight devices, or other system hardware
capable of generating or using trigger signals.::
>$ ls /sys/bus/coresight/devices/etm0/cti_cpu0
channels ctmid enable nr_trigger_cons mgmt power powered regs
subsystem triggers0 triggers1 uevent
*Key file items are:-*
* ``enable``: enables/disables the CTI. Read to determine current state.
If this shows as enabled (1), but ``powered`` shows unpowered (0), then
the enable indicates a request to enabled when the device is powered.
* ``ctmid`` : associated CTM - only relevant if system has multiple CTI+CTM
clusters that are not interconnected.
* ``nr_trigger_cons`` : total connections - triggers<N> directories.
* ``powered`` : Read to determine if the CTI is currently powered.
*Sub-directories:-*
* ``triggers<N>``: contains list of triggers for an individual connection.
* ``channels``: Contains the channel API - CTI main programming interface.
* ``regs``: Gives access to the raw programmable CTI regs.
* ``mgmt``: the standard CoreSight management registers.
triggers<N> directories
~~~~~~~~~~~~~~~~~~~~~~~
Individual trigger connection information. This describes trigger signals for
CoreSight and non-CoreSight connections.
Each triggers directory has a set of parameters describing the triggers for
the connection.
* ``name`` : name of connection
* ``in_signals`` : input trigger signal indexes used in this connection.
* ``in_types`` : functional types for in signals.
* ``out_signals`` : output trigger signals for this connection.
* ``out_types`` : functional types for out signals.
e.g::
>$ ls ./cti_cpu0/triggers0/
in_signals in_types name out_signals out_types
>$ cat ./cti_cpu0/triggers0/name
cpu0
>$ cat ./cti_cpu0/triggers0/out_signals
0-2
>$ cat ./cti_cpu0/triggers0/out_types
pe_edbgreq pe_dbgrestart pe_ctiirq
>$ cat ./cti_cpu0/triggers0/in_signals
0-1
>$ cat ./cti_cpu0/triggers0/in_types
pe_dbgtrigger pe_pmuirq
If a connection has zero signals in either the 'in' or 'out' triggers then
those parameters will be omitted.
Channels API Directory
~~~~~~~~~~~~~~~~~~~~~~
This provides an easy way to attach triggers to channels, without needing
the multiple register operations that are required if manipulating the
'regs' sub-directory elements directly.
A number of files provide this API::
>$ ls ./cti_sys0/channels/
chan_clear chan_inuse chan_xtrigs_out trigin_attach
chan_free chan_pulse chan_xtrigs_reset trigin_detach
chan_gate_disable chan_set chan_xtrigs_sel trigout_attach
chan_gate_enable chan_xtrigs_in trig_filter_enable trigout_detach
trigout_filtered
Most access to these elements take the form::
echo <chan> [<trigger>] > /<device_path>/<operation>
where the optional <trigger> is only needed for trigXX_attach | detach
operations.
e.g.::
>$ echo 0 1 > ./cti_sys0/channels/trigout_attach
>$ echo 0 > ./cti_sys0/channels/chan_set
Attaches trigout(1) to channel(0), then activates channel(0) generating a
set state on cti_sys0.trigout(1)
*API operations*
* ``trigin_attach, trigout_attach``: Attach a channel to a trigger signal.
* ``trigin_detach, trigout_detach``: Detach a channel from a trigger signal.
* ``chan_set``: Set the channel - the set state will be propagated around
the CTM to other connected devices.
* ``chan_clear``: Clear the channel.
* ``chan_pulse``: Set the channel for a single CoreSight clock cycle.
* ``chan_gate_enable``: Write operation sets the CTI gate to propagate
(enable) the channel to other devices. This operation takes a channel
number. CTI gate is enabled for all channels by default at power up. Read
to list the currently enabled channels on the gate.
* ``chan_gate_disable``: Write channel number to disable gate for that
channel.
* ``chan_inuse``: Show the current channels attached to any signal
* ``chan_free``: Show channels with no attached signals.
* ``chan_xtrigs_sel``: write a channel number to select a channel to view,
read to show the selected channel number.
* ``chan_xtrigs_in``: Read to show the input triggers attached to
the selected view channel.
* ``chan_xtrigs_out``:Read to show the output triggers attached to
the selected view channel.
* ``trig_filter_enable``: Defaults to enabled, disable to allow potentially
dangerous output signals to be set.
* ``trigout_filtered``: Trigger out signals that are prevented from being
set if filtering ``trig_filter_enable`` is enabled. One use is to prevent
accidental ``EDBGREQ`` signals stopping a core.
* ``chan_xtrigs_reset``: Write 1 to clear all channel / trigger programming.
Resets device hardware to default state.
The example below attaches input trigger index 1 to channel 2, and output
trigger index 6 to the same channel. It then examines the state of the
channel / trigger connections using the appropriate sysfs attributes.
The settings mean that if either input trigger 1, or channel 2 go active then
trigger out 6 will go active. We then enable the CTI, and use the software
channel control to activate channel 2. We see the active channel on the
``choutstatus`` register and the active signal on the ``trigoutstatus``
register. Finally clearing the channel removes this.
e.g.::
.../cti_sys0/channels# echo 2 1 > trigin_attach
.../cti_sys0/channels# echo 2 6 > trigout_attach
.../cti_sys0/channels# cat chan_free
0-1,3
.../cti_sys0/channels# cat chan_inuse
2
.../cti_sys0/channels# echo 2 > chan_xtrigs_sel
.../cti_sys0/channels# cat chan_xtrigs_trigin
1
.../cti_sys0/channels# cat chan_xtrigs_trigout
6
.../cti_sys0/# echo 1 > enable
.../cti_sys0/channels# echo 2 > chan_set
.../cti_sys0/channels# cat ../regs/choutstatus
0x4
.../cti_sys0/channels# cat ../regs/trigoutstatus
0x40
.../cti_sys0/channels# echo 2 > chan_clear
.../cti_sys0/channels# cat ../regs/trigoutstatus
0x0
.../cti_sys0/channels# cat ../regs/choutstatus
0x0
......@@ -491,8 +491,21 @@ interface provided for that purpose by the generic STM API::
Details on how to use the generic STM API can be found here:- :doc:`../stm` [#second]_.
The CTI & CTM Modules
---------------------
The CTI (Cross Trigger Interface) provides a set of trigger signals between
individual CTIs and components, and can propagate these between all CTIs via
channels on the CTM (Cross Trigger Matrix).
A separate documentation file is provided to explain the use of these devices.
(:doc:`coresight-ect`) [#fourth]_.
.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
.. [#second] Documentation/trace/stm.rst
.. [#third] https://github.com/Linaro/perf-opencsd
.. [#fourth] Documentation/trace/coresight/coresight-ect.rst
......@@ -1693,12 +1693,15 @@ F: arch/arm/mach-ep93xx/micro9.c
ARM/CORESIGHT FRAMEWORK AND DRIVERS
M: Mathieu Poirier <mathieu.poirier@linaro.org>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Mike Leach <mike.leach@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/hwtracing/coresight/*
F: include/dt-bindings/arm/coresight-cti-dt.h
F: Documentation/trace/coresight/*
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
F: Documentation/devicetree/bindings/arm/coresight-cti.yaml
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
F: tools/perf/arch/arm/util/pmu.c
F: tools/perf/arch/arm/util/auxtrace.c
......@@ -10993,6 +10996,16 @@ M: Vladimir Vid <vladimir.vid@sartura.hr>
S: Maintained
F: arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
MHI BUS
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
M: Hemant Kumar <hemantk@codeaurora.org>
L: linux-arm-msm@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git
F: Documentation/mhi/
F: drivers/bus/mhi/
F: include/linux/mhi.h
MICROBLAZE ARCHITECTURE
M: Michal Simek <monstr@monstr.eu>
W: http://www.monstr.eu/fdt/
......
......@@ -52,7 +52,8 @@ CONFIG_NET_PCI=y
CONFIG_YELLOWFIN=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_RTC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_EXT2_FS=y
CONFIG_REISERFS_FS=m
CONFIG_ISO9660_FS=y
......
......@@ -2,7 +2,6 @@
#ifndef _FLASH_H
#define _FLASH_H
#define FLASH_MINOR 160 /* MAJOR is 10 - miscdevice */
#define CMD_WRITE_DISABLE 0
#define CMD_WRITE_ENABLE 0x28
#define CMD_WRITE_BASE64K_ENABLE 0x47
......
......@@ -57,7 +57,8 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_HW_RANDOM is not set
CONFIG_EFI_RTC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_EFI=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_AGP=m
......
......@@ -94,7 +94,8 @@ CONFIG_SERIAL_8250_NR_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_HW_RANDOM is not set
CONFIG_EFI_RTC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_EFI=y
CONFIG_RAW_DRIVER=m
CONFIG_HPET=y
CONFIG_AGP=m
......
......@@ -82,7 +82,8 @@ CONFIG_SERIAL_8250_NR_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_HW_RANDOM is not set
CONFIG_EFI_RTC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_EFI=y
CONFIG_RAW_DRIVER=m
CONFIG_HPET=y
CONFIG_AGP=m
......
......@@ -86,7 +86,8 @@ CONFIG_SERIAL_8250_NR_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_HW_RANDOM is not set
CONFIG_EFI_RTC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_EFI=y
CONFIG_RAW_DRIVER=m
CONFIG_HPET=y
CONFIG_AGP=m
......
......@@ -68,7 +68,8 @@ CONFIG_SERIAL_8250_NR_UARTS=8
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_HW_RANDOM is not set
CONFIG_EFI_RTC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_EFI=y
CONFIG_I2C_CHARDEV=y
CONFIG_AGP=y
CONFIG_AGP_HP_ZX1=y
......
......@@ -23,8 +23,6 @@
#define RNG_VERSION "1.0.0"
#define RNG_MODULE_NAME "hw_random"
#define RNG_MISCDEV_MINOR 183 /* official */
/* Changed at init time, in the non-modular case, and at module load
* time, in the module case. Presumably, the module subsystem
* protects against a module being loaded twice at the same time.
......@@ -104,7 +102,7 @@ static const struct file_operations rng_chrdev_ops = {
/* rng_init shouldn't be called more than once at boot time */
static struct miscdevice rng_miscdev = {
RNG_MISCDEV_MINOR,
HWRNG_MINOR,
RNG_MODULE_NAME,
&rng_chrdev_ops,
};
......
......@@ -18,7 +18,7 @@
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/mount.h>
#include <linux/parser.h>
#include <linux/fs_parser.h>
#include <linux/radix-tree.h>
#include <linux/sched.h>
#include <linux/seq_file.h>
......@@ -48,26 +48,30 @@ static dev_t binderfs_dev;
static DEFINE_MUTEX(binderfs_minors_mutex);
static DEFINE_IDA(binderfs_minors);
enum {
enum binderfs_param {
Opt_max,
Opt_stats_mode,
Opt_err
};
enum binderfs_stats_mode {
STATS_NONE,
STATS_GLOBAL,
binderfs_stats_mode_unset,
binderfs_stats_mode_global,
};
static const match_table_t tokens = {
{ Opt_max, "max=%d" },
{ Opt_stats_mode, "stats=%s" },
{ Opt_err, NULL }
static const struct constant_table binderfs_param_stats[] = {
{ "global", binderfs_stats_mode_global },
{}
};
static inline struct binderfs_info *BINDERFS_I(const struct inode *inode)
const struct fs_parameter_spec binderfs_fs_parameters[] = {
fsparam_u32("max", Opt_max),
fsparam_enum("stats", Opt_stats_mode, binderfs_param_stats),
{}
};
static inline struct binderfs_info *BINDERFS_SB(const struct super_block *sb)
{
return inode->i_sb->s_fs_info;
return sb->s_fs_info;
}
bool is_binderfs_device(const struct inode *inode)
......@@ -246,7 +250,7 @@ static long binder_ctl_ioctl(struct file *file, unsigned int cmd,
static void binderfs_evict_inode(struct inode *inode)
{
struct binder_device *device = inode->i_private;
struct binderfs_info *info = BINDERFS_I(inode);
struct binderfs_info *info = BINDERFS_SB(inode->i_sb);
clear_inode(inode);
......@@ -264,97 +268,84 @@ static void binderfs_evict_inode(struct inode *inode)
}
}
/**
* binderfs_parse_mount_opts - parse binderfs mount options
* @data: options to set (can be NULL in which case defaults are used)
*/
static int binderfs_parse_mount_opts(char *data,
struct binderfs_mount_opts *opts)
static int binderfs_fs_context_parse_param(struct fs_context *fc,
struct fs_parameter *param)
{
char *p, *stats;
opts->max = BINDERFS_MAX_MINOR;
opts->stats_mode = STATS_NONE;
while ((p = strsep(&data, ",")) != NULL) {
substring_t args[MAX_OPT_ARGS];
int token;
int max_devices;
if (!*p)
continue;
token = match_token(p, tokens, args);
switch (token) {
case Opt_max:
if (match_int(&args[0], &max_devices) ||
(max_devices < 0 ||
(max_devices > BINDERFS_MAX_MINOR)))
return -EINVAL;
opts->max = max_devices;
break;
case Opt_stats_mode:
if (!capable(CAP_SYS_ADMIN))
return -EINVAL;
int opt;
struct binderfs_mount_opts *ctx = fc->fs_private;
struct fs_parse_result result;
stats = match_strdup(&args[0]);
if (!stats)
return -ENOMEM;
opt = fs_parse(fc, binderfs_fs_parameters, param, &result);
if (opt < 0)
return opt;
if (strcmp(stats, "global") != 0) {
kfree(stats);
return -EINVAL;
}
switch (opt) {
case Opt_max:
if (result.uint_32 > BINDERFS_MAX_MINOR)
return invalfc(fc, "Bad value for '%s'", param->key);
opts->stats_mode = STATS_GLOBAL;
kfree(stats);
break;
default:
pr_err("Invalid mount options\n");
return -EINVAL;
}
ctx->max = result.uint_32;
break;
case Opt_stats_mode:
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
ctx->stats_mode = result.uint_32;
break;
default:
return invalfc(fc, "Unsupported parameter '%s'", param->key);
}
return 0;
}
static int binderfs_remount(struct super_block *sb, int *flags, char *data)
static int binderfs_fs_context_reconfigure(struct fs_context *fc)
{
int prev_stats_mode, ret;
struct binderfs_info *info = sb->s_fs_info;
struct binderfs_mount_opts *ctx = fc->fs_private;
struct binderfs_info *info = BINDERFS_SB(fc->root->d_sb);
prev_stats_mode = info->mount_opts.stats_mode;
ret = binderfs_parse_mount_opts(data, &info->mount_opts);
if (ret)
return ret;
if (prev_stats_mode != info->mount_opts.stats_mode) {
pr_err("Binderfs stats mode cannot be changed during a remount\n");
info->mount_opts.stats_mode = prev_stats_mode;
return -EINVAL;
}
if (info->mount_opts.stats_mode != ctx->stats_mode)
return invalfc(fc, "Binderfs stats mode cannot be changed during a remount");
info->mount_opts.stats_mode = ctx->stats_mode;
info->mount_opts.max = ctx->max;
return 0;
}
static int binderfs_show_mount_opts(struct seq_file *seq, struct dentry *root)
static int binderfs_show_options(struct seq_file *seq, struct dentry *root)
{
struct binderfs_info *info;
struct binderfs_info *info = BINDERFS_SB(root->d_sb);
info = root->d_sb->s_fs_info;
if (info->mount_opts.max <= BINDERFS_MAX_MINOR)
seq_printf(seq, ",max=%d", info->mount_opts.max);
if (info->mount_opts.stats_mode == STATS_GLOBAL)
switch (info->mount_opts.stats_mode) {
case binderfs_stats_mode_unset:
break;
case binderfs_stats_mode_global:
seq_printf(seq, ",stats=global");
break;
}
return 0;
}
static void binderfs_put_super(struct super_block *sb)
{
struct binderfs_info *info = sb->s_fs_info;
if (info && info->ipc_ns)
put_ipc_ns(info->ipc_ns);
kfree(info);
sb->s_fs_info = NULL;
}
static const struct super_operations binderfs_super_ops = {
.evict_inode = binderfs_evict_inode,
.remount_fs = binderfs_remount,
.show_options = binderfs_show_mount_opts,
.show_options = binderfs_show_options,
.statfs = simple_statfs,
.put_super = binderfs_put_super,
};
static inline bool is_binderfs_control_device(const struct dentry *dentry)
......@@ -653,10 +644,11 @@ static int init_binder_logs(struct super_block *sb)
return ret;
}
static int binderfs_fill_super(struct super_block *sb, void *data, int silent)
static int binderfs_fill_super(struct super_block *sb, struct fs_context *fc)
{
int ret;
struct binderfs_info *info;
struct binderfs_mount_opts *ctx = fc->fs_private;
struct inode *inode = NULL;
struct binderfs_device device_info = { 0 };
const char *name;
......@@ -689,16 +681,14 @@ static int binderfs_fill_super(struct super_block *sb, void *data, int silent)
info->ipc_ns = get_ipc_ns(current->nsproxy->ipc_ns);
ret = binderfs_parse_mount_opts(data, &info->mount_opts);
if (ret)
return ret;
info->root_gid = make_kgid(sb->s_user_ns, 0);
if (!gid_valid(info->root_gid))
info->root_gid = GLOBAL_ROOT_GID;
info->root_uid = make_kuid(sb->s_user_ns, 0);
if (!uid_valid(info->root_uid))
info->root_uid = GLOBAL_ROOT_UID;
info->mount_opts.max = ctx->max;
info->mount_opts.stats_mode = ctx->stats_mode;
inode = new_inode(sb);
if (!inode)
......@@ -730,36 +720,54 @@ static int binderfs_fill_super(struct super_block *sb, void *data, int silent)
name++;
}
if (info->mount_opts.stats_mode == STATS_GLOBAL)
if (info->mount_opts.stats_mode == binderfs_stats_mode_global)
return init_binder_logs(sb);
return 0;
}
static struct dentry *binderfs_mount(struct file_system_type *fs_type,
int flags, const char *dev_name,
void *data)
static int binderfs_fs_context_get_tree(struct fs_context *fc)
{
return mount_nodev(fs_type, flags, data, binderfs_fill_super);
return get_tree_nodev(fc, binderfs_fill_super);
}
static void binderfs_kill_super(struct super_block *sb)
static void binderfs_fs_context_free(struct fs_context *fc)
{
struct binderfs_info *info = sb->s_fs_info;
struct binderfs_mount_opts *ctx = fc->fs_private;
kill_litter_super(sb);
kfree(ctx);
}
if (info && info->ipc_ns)
put_ipc_ns(info->ipc_ns);
static const struct fs_context_operations binderfs_fs_context_ops = {
.free = binderfs_fs_context_free,
.get_tree = binderfs_fs_context_get_tree,
.parse_param = binderfs_fs_context_parse_param,
.reconfigure = binderfs_fs_context_reconfigure,
};
kfree(info);
static int binderfs_init_fs_context(struct fs_context *fc)
{
struct binderfs_mount_opts *ctx = fc->fs_private;
ctx = kzalloc(sizeof(struct binderfs_mount_opts), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
ctx->max = BINDERFS_MAX_MINOR;
ctx->stats_mode = binderfs_stats_mode_unset;
fc->fs_private = ctx;
fc->ops = &binderfs_fs_context_ops;
return 0;
}
static struct file_system_type binder_fs_type = {
.name = "binder",
.mount = binderfs_mount,
.kill_sb = binderfs_kill_super,
.fs_flags = FS_USERNS_MOUNT,
.name = "binder",
.init_fs_context = binderfs_init_fs_context,
.parameters = binderfs_fs_parameters,
.kill_sb = kill_litter_super,
.fs_flags = FS_USERNS_MOUNT,
};
int __init init_binderfs(void)
......
......@@ -22,8 +22,6 @@
#include "charlcd.h"
#define LCD_MINOR 156
#define DEFAULT_LCD_BWIDTH 40
#define DEFAULT_LCD_HWIDTH 64
......
......@@ -57,8 +57,6 @@
#include "charlcd.h"
#define KEYPAD_MINOR 185
#define LCD_MAXBYTES 256 /* max burst write */
#define KEYPAD_BUFFER 64
......
......@@ -201,5 +201,6 @@ config DA8XX_MSTPRI
peripherals.
source "drivers/bus/fsl-mc/Kconfig"
source "drivers/bus/mhi/Kconfig"
endmenu
......@@ -34,3 +34,6 @@ obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
obj-$(CONFIG_DA8XX_MSTPRI) += da8xx-mstpri.o
# MHI
obj-$(CONFIG_MHI_BUS) += mhi/
# SPDX-License-Identifier: GPL-2.0
#
# MHI bus
#
# Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.
#
config MHI_BUS
tristate "Modem Host Interface (MHI) bus"
help
Bus driver for MHI protocol. Modem Host Interface (MHI) is a
communication protocol used by the host processors to control
and communicate with modem devices over a high speed peripheral
bus or shared memory.
# core layer
obj-y += core/
obj-$(CONFIG_MHI_BUS) := mhi.o
mhi-y := init.o main.o pm.o boot.o
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -7,28 +7,6 @@ menu "Character devices"
source "drivers/tty/Kconfig"
config DEVMEM
bool "/dev/mem virtual device support"
default y
help
Say Y here if you want to support the /dev/mem device.
The /dev/mem device is used to access areas of physical
memory.
When in doubt, say "Y".
config DEVKMEM
bool "/dev/kmem virtual device support"
# On arm64, VMALLOC_START < PAGE_OFFSET, which confuses kmem read/write
depends on !ARM64
help
Say Y here if you want to support the /dev/kmem device. The
/dev/kmem device is rarely used, but can be used for certain
kind of kernel debugging operations.
When in doubt, say "N".
source "drivers/tty/serial/Kconfig"
source "drivers/tty/serdev/Kconfig"
config TTY_PRINTK
tristate "TTY driver to output user messages via printk"
depends on EXPERT && TTY
......@@ -113,8 +91,6 @@ config PPDEV
If unsure, say N.
source "drivers/tty/hvc/Kconfig"
config VIRTIO_CONSOLE
tristate "Virtio console"
depends on VIRTIO && TTY
......@@ -220,89 +196,6 @@ config NWFLASH
source "drivers/char/hw_random/Kconfig"
config NVRAM
tristate "/dev/nvram support"
depends on X86 || HAVE_ARCH_NVRAM_OPS
default M68K || PPC
---help---
If you say Y here and create a character special file /dev/nvram
with major number 10 and minor number 144 using mknod ("man mknod"),
you get read and write access to the non-volatile memory.
/dev/nvram may be used to view settings in NVRAM or to change them
(with some utility). It could also be used to frequently
save a few bits of very important data that may not be lost over
power-off and for which writing to disk is too insecure. Note
however that most NVRAM space in a PC belongs to the BIOS and you
should NEVER idly tamper with it. See Ralf Brown's interrupt list
for a guide to the use of CMOS bytes by your BIOS.
This memory is conventionally called "NVRAM" on PowerPC machines,
"CMOS RAM" on PCs, "NVRAM" on Ataris and "PRAM" on Macintoshes.
To compile this driver as a module, choose M here: the
module will be called nvram.
#
# These legacy RTC drivers just cause too many conflicts with the generic
# RTC framework ... let's not even try to coexist any more.
#
if RTC_LIB=n
config RTC
tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
depends on ALPHA
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
will get access to the real time clock (or hardware clock) built
into your computer.
Every PC has such a clock built in. It can be used to generate
signals from as low as 1Hz up to 8192Hz, and can also be used
as a 24 hour alarm. It reports status information via the file
/proc/driver/rtc and its behaviour is set by various ioctls on
/dev/rtc.
If you run Linux on a multiprocessor machine and said Y to
"Symmetric Multi Processing" above, you should say Y here to read
and set the RTC in an SMP compatible fashion.
If you think you have a use for such a device (such as periodic data
sampling), then say Y here, and read <file:Documentation/admin-guide/rtc.rst>
for details.
To compile this driver as a module, choose M here: the
module will be called rtc.
config JS_RTC
tristate "Enhanced Real Time Clock Support"
depends on SPARC32 && PCI
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
will get access to the real time clock (or hardware clock) built
into your computer.
Every PC has such a clock built in. It can be used to generate
signals from as low as 1Hz up to 8192Hz, and can also be used
as a 24 hour alarm. It reports status information via the file
/proc/driver/rtc and its behaviour is set by various ioctls on
/dev/rtc.
If you think you have a use for such a device (such as periodic data
sampling), then say Y here, and read <file:Documentation/admin-guide/rtc.rst>
for details.
To compile this driver as a module, choose M here: the
module will be called js-rtc.
config EFI_RTC
bool "EFI Real Time Clock Services"
depends on IA64
endif # RTC_LIB
config DTLK
tristate "Double Talk PC internal speech card support"
depends on ISA
......@@ -431,6 +324,48 @@ config NSC_GPIO
pc8736x_gpio drivers. If those drivers are built as
modules, this one will be too, named nsc_gpio
config DEVMEM
bool "/dev/mem virtual device support"
default y
help
Say Y here if you want to support the /dev/mem device.
The /dev/mem device is used to access areas of physical
memory.
When in doubt, say "Y".
config DEVKMEM
bool "/dev/kmem virtual device support"
# On arm64, VMALLOC_START < PAGE_OFFSET, which confuses kmem read/write
depends on !ARM64
help
Say Y here if you want to support the /dev/kmem device. The
/dev/kmem device is rarely used, but can be used for certain
kind of kernel debugging operations.
When in doubt, say "N".
config NVRAM
tristate "/dev/nvram support"
depends on X86 || HAVE_ARCH_NVRAM_OPS
default M68K || PPC
---help---
If you say Y here and create a character special file /dev/nvram
with major number 10 and minor number 144 using mknod ("man mknod"),
you get read and write access to the non-volatile memory.
/dev/nvram may be used to view settings in NVRAM or to change them
(with some utility). It could also be used to frequently
save a few bits of very important data that may not be lost over
power-off and for which writing to disk is too insecure. Note
however that most NVRAM space in a PC belongs to the BIOS and you
should NEVER idly tamper with it. See Ralf Brown's interrupt list
for a guide to the use of CMOS bytes by your BIOS.
This memory is conventionally called "NVRAM" on PowerPC machines,
"CMOS RAM" on PCs, "NVRAM" on Ataris and "PRAM" on Macintoshes.
To compile this driver as a module, choose M here: the
module will be called nvram.
config RAW_DRIVER
tristate "RAW driver (/dev/raw/rawN)"
depends on BLOCK
......@@ -452,6 +387,14 @@ config MAX_RAW_DEVS
Default is 256. Increase this number in case you need lots of
raw devices.
config DEVPORT
bool "/dev/port character device"
depends on ISA || PCI
default y
help
Say Y here if you want to support the /dev/port device. The /dev/port
device is similar to /dev/mem, but for I/O ports.
config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
......@@ -511,14 +454,6 @@ config TELCLOCK
/sys/devices/platform/telco_clock, with a number of files for
controlling the behavior of this hardware.
config DEVPORT
bool "/dev/port character device"
depends on ISA || PCI
default y
help
Say Y here if you want to support the /dev/port device. The /dev/port
device is similar to /dev/mem, but for I/O ports.
source "drivers/s390/char/Kconfig"
source "drivers/char/xillybus/Kconfig"
......
......@@ -20,9 +20,7 @@ obj-$(CONFIG_APM_EMULATION) += apm-emulation.o
obj-$(CONFIG_DTLK) += dtlk.o
obj-$(CONFIG_APPLICOM) += applicom.o
obj-$(CONFIG_SONYPI) += sonypi.o
obj-$(CONFIG_RTC) += rtc.o
obj-$(CONFIG_HPET) += hpet.o
obj-$(CONFIG_EFI_RTC) += efirtc.o
obj-$(CONFIG_XILINX_HWICAP) += xilinx_hwicap/
obj-$(CONFIG_NVRAM) += nvram.o
obj-$(CONFIG_TOSHIBA) += toshiba.o
......@@ -46,9 +44,6 @@ obj-$(CONFIG_TCG_TPM) += tpm/
obj-$(CONFIG_PS3_FLASH) += ps3flash.o
obj-$(CONFIG_JS_RTC) += js-rtc.o
js-rtc-y = rtc.o
obj-$(CONFIG_XILLYBUS) += xillybus/
obj-$(CONFIG_POWERNV_OP_PANEL) += powernv-op-panel.o
obj-$(CONFIG_ADI) += adi.o
......@@ -53,7 +53,6 @@
#define MAX_BOARD 8 /* maximum of pc board possible */
#define MAX_ISA_BOARD 4
#define LEN_RAM_IO 0x800
#define AC_MINOR 157
#ifndef PCI_VENDOR_ID_APPLICOM
#define PCI_VENDOR_ID_APPLICOM 0x1389
......
This diff is collapsed.
......@@ -75,7 +75,7 @@ struct vma_data {
enum mspec_page_type type; /* Type of pages allocated. */
unsigned long vm_start; /* Original (unsplit) base. */
unsigned long vm_end; /* Original (unsplit) end. */
unsigned long maddr[0]; /* Array of MSPEC addresses. */
unsigned long maddr[]; /* Array of MSPEC addresses. */
};
/*
......
......@@ -14,7 +14,6 @@
#define NUM_PRESSES_REBOOT 2 /* How many presses to activate shutdown */
#define BUTTON_DELAY 30 /* How many jiffies for sequence to end */
#define VERSION "0.3" /* Driver version number */
#define BUTTON_MINOR 158 /* Major 10, Minor 158, /dev/nwbutton */
/* Structure definitions: */
......
......@@ -576,7 +576,7 @@ static const struct file_operations flash_fops =
static struct miscdevice flash_miscdev =
{
FLASH_MINOR,
NWFLASH_MINOR,
"nwflash",
&flash_fops
};
......
......@@ -731,8 +731,9 @@ static void monitor_card(struct timer_list *t)
}
switch (dev->mstate) {
case M_CARDOFF: {
unsigned char flags0;
case M_CARDOFF:
DEBUGP(4, dev, "M_CARDOFF\n");
flags0 = inb(REG_FLAGS0(iobase));
if (flags0 & 0x02) {
......@@ -755,6 +756,7 @@ static void monitor_card(struct timer_list *t)
dev->mdelay = T_50MSEC;
}
break;
}
case M_FETCH_ATR:
DEBUGP(4, dev, "M_FETCH_ATR\n");
xoutb(0x80, REG_FLAGS0(iobase));
......
......@@ -355,14 +355,19 @@ static int pp_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
struct pp_struct *pp = file->private_data;
struct parport *port;
void __user *argp = (void __user *)arg;
struct ieee1284_info *info;
unsigned char reg;
unsigned char mask;
int mode;
s32 time32[2];
s64 time64[2];
struct timespec64 ts;
int ret;
/* First handle the cases that don't take arguments. */
switch (cmd) {
case PPCLAIM:
{
struct ieee1284_info *info;
int ret;
if (pp->flags & PP_CLAIMED) {
dev_dbg(&pp->pdev->dev, "you've already got it!\n");
return -EINVAL;
......@@ -513,15 +518,6 @@ static int pp_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
port = pp->pdev->port;
switch (cmd) {
struct ieee1284_info *info;
unsigned char reg;
unsigned char mask;
int mode;
s32 time32[2];
s64 time64[2];
struct timespec64 ts;
int ret;
case PPRSTATUS:
reg = parport_read_status(port);
if (copy_to_user(argp, &reg, sizeof(reg)))
......
This diff is collapsed.
......@@ -61,8 +61,6 @@
#include <linux/mutex.h>
#include <linux/toshiba.h>
#define TOSH_MINOR_DEV 181
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jonathan Buzzard <jonathan@buzzard.org.uk>");
MODULE_DESCRIPTION("Toshiba laptop SMM driver");
......
......@@ -112,7 +112,7 @@ struct port_buffer {
unsigned int sgpages;
/* sg is used if spages > 0. sg must be the last in is struct */
struct scatterlist sg[0];
struct scatterlist sg[];
};
/*
......
This diff is collapsed.
This diff is collapsed.
......@@ -1406,6 +1406,7 @@ const char *extcon_get_edev_name(struct extcon_dev *edev)
{
return !edev ? NULL : edev->name;
}
EXPORT_SYMBOL_GPL(extcon_get_edev_name);
static int __init extcon_class_init(void)
{
......
......@@ -206,7 +206,7 @@ config FW_CFG_SYSFS_CMDLINE
config INTEL_STRATIX10_SERVICE
tristate "Intel Stratix10 Service Layer"
depends on ARCH_STRATIX10 && HAVE_ARM_SMCCC
depends on (ARCH_STRATIX10 || ARCH_AGILEX) && HAVE_ARM_SMCCC
default n
help
Intel Stratix10 service layer runs at privileged exception level,
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment