Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
Extension
.yaml
Size
11196 bytes
Lines
366
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: configuration, schema, or hardware description
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/mmc/mmc-controller-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: MMC Controller & Slots Common Properties

maintainers:
  - Ulf Hansson <ulf.hansson@linaro.org>

description:
  These properties are common to multiple MMC host controllers and the
  possible slots or ports for multi-slot controllers.

properties:
  "#address-cells":
    const: 1
    description:
      The cell is the SDIO function number if a function subnode is used.

  "#size-cells":
    const: 0

  # Card Detection.
  # If none of these properties are supplied, the host native card
  # detect will be used. Only one of them should be provided.

  broken-cd:
    $ref: /schemas/types.yaml#/definitions/flag
    description:
      There is no card detection available; polling must be used.

  cd-gpios:
    maxItems: 1
    description:
      The card detection will be done using the GPIO provided.

  non-removable:
    $ref: /schemas/types.yaml#/definitions/flag
    description:
      Non-removable slot (like eMMC); assume always present.

  # *NOTE* on CD and WP polarity. To use common for all SD/MMC host
  # controllers line polarity properties, we have to fix the meaning
  # of the "normal" and "inverted" line levels. We choose to follow
  # the SDHCI standard, which specifies both those lines as "active
  # low." Therefore, using the "cd-inverted" property means, that the
  # CD line is active high, i.e. it is high, when a card is
  # inserted. Similar logic applies to the "wp-inverted" property.
  #
  # CD and WP lines can be implemented on the hardware in one of two
  # ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or
  # as dedicated pins. Polarity of dedicated pins can be specified,
  # using *-inverted properties. GPIO polarity can also be specified
  # using the GPIO_ACTIVE_LOW flag. This creates an ambiguity in the
  # latter case. We choose to use the XOR logic for GPIO CD and WP
  # lines.  This means, the two properties are "superimposed," for
  # example leaving the GPIO_ACTIVE_LOW flag clear and specifying the
  # respective *-inverted property results in a
  # double-inversion and actually means the "normal" line polarity is
  # in effect.
  wp-inverted:
    $ref: /schemas/types.yaml#/definitions/flag
    description:
      The Write Protect line polarity is inverted.

  cd-inverted:
    $ref: /schemas/types.yaml#/definitions/flag
    description:

Annotation

Implementation Notes