On 10/08/2021 08:35, Joakim Zhang wrote:
Introduce "reverse-data" property for nvmem provider to reverse buffer.
Signed-off-by: Joakim Zhang <qiangqing.zhang@xxxxxxx>
---
Documentation/devicetree/bindings/nvmem/nvmem.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index b8dc3d2b6e92..bc745083fc64 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -61,6 +61,11 @@ patternProperties:
description:
Size in bit within the address range specified by reg.
+ reverse-data:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Reverse the data that read from the storage device.
+
This new property is only going to solve one of the reverse order issue
here.
If I remember correctly we have mac-address stored in various formats
ex: from old thread I can see
Type 1: Octets in ASCII without delimiters. (Swapped/non-Swapped)
Type 2: Octets in ASCII with delimiters like (":", ",", ".", "-"... so
on) (Swapped/non-Swapped)
Type 3: Is the one which stores mac address in Type1/2 but this has to
be incremented to be used on other instances of eth.
Type 4: Octets as bytes/u8, swapped/non-swapped
I think its right time to consider adding compatibles to nvmem-cells to
be able to specify encoding information and handle post processing.
Lets see what Rob would say on this approach.
--srini
required:
- reg
