From 748e4f3d702def1a4bff191e0cf93b6a05340f01 Mon Sep 17 00:00:00 2001
From: hc <hc@nodka.com>
Date: Fri, 10 May 2024 07:41:34 +0000
Subject: [PATCH] add gpio led uart
---
kernel/Documentation/devicetree/bindings/common-properties.txt | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/kernel/Documentation/devicetree/bindings/common-properties.txt b/kernel/Documentation/devicetree/bindings/common-properties.txt
index a3448bf..98a2813 100644
--- a/kernel/Documentation/devicetree/bindings/common-properties.txt
+++ b/kernel/Documentation/devicetree/bindings/common-properties.txt
@@ -5,30 +5,29 @@
----------
The Devicetree Specification does not define any properties related to hardware
-byteswapping, but endianness issues show up frequently in porting Linux to
+byte swapping, but endianness issues show up frequently in porting drivers to
different machine types. This document attempts to provide a consistent
-way of handling byteswapping across drivers.
+way of handling byte swapping across drivers.
Optional properties:
- big-endian: Boolean; force big endian register accesses
unconditionally (e.g. ioread32be/iowrite32be). Use this if you
- know the peripheral always needs to be accessed in BE mode.
+ know the peripheral always needs to be accessed in big endian (BE) mode.
- little-endian: Boolean; force little endian register accesses
unconditionally (e.g. readl/writel). Use this if you know the
- peripheral always needs to be accessed in LE mode.
+ peripheral always needs to be accessed in little endian (LE) mode.
- native-endian: Boolean; always use register accesses matched to the
endianness of the kernel binary (e.g. LE vmlinux -> readl/writel,
- BE vmlinux -> ioread32be/iowrite32be). In this case no byteswaps
+ BE vmlinux -> ioread32be/iowrite32be). In this case no byte swaps
will ever be performed. Use this if the hardware "self-adjusts"
register endianness based on the CPU's configured endianness.
If a binding supports these properties, then the binding should also
specify the default behavior if none of these properties are present.
In such cases, little-endian is the preferred default, but it is not
-a requirement. The of_device_is_big_endian() and of_fdt_is_big_endian()
-helper functions do assume that little-endian is the default, because
-most existing (PCI-based) drivers implicitly default to LE by using
-readl/writel for MMIO accesses.
+a requirement. Some implementations assume that little-endian is
+the default, because most existing (PCI-based) drivers implicitly
+default to LE for their MMIO accesses.
Examples:
Scenario 1 : CPU in LE mode & device in LE mode.
--
Gitblit v1.6.2