dt-bindings: mtd-physmap: Add endianness supports
Subsystems (2)
PATCH v6 1/2 dt-bindings: mtd-physmap: Add endianness supports
Connection between flash and controller is not necessary to be always of same type. It may varies from platform to platform.
Adding endianness (optional) property to provide connection type information.
---
Changes for v2: updated subject
Changes for v3: fixed typo for "big-endian"
Changes for v4: Moved binding definition in mtd-physmap.txt as discussed at https://patchwork.ozlabs.org/patch/842543/
Changes for v5: Sending as it is
Changes for v6: Updated binding when endianness property is absent
Documentation/devicetree/bindings/mtd/mtd-physmap.txt | 5 +++++ 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/mtd/mtd-physmap.txt +5 -0
@@ -41,6 +41,11 @@ additional (optional) property is defined: - erase-size : The chip's physical erase block size in bytes. + The device tree may optionally contain endianness property. + little-endian or big-endian : It represents connection between controller and + flash. If this property is absent, connection is described + by the CFI_DEFAULT_ENDIAN. + The device tree may optionally contain sub-nodes describing partitions of the address space. See partition.txt for more detail.
Signature · 1 line
2.14.1
PATCH v6 1/2 dt-bindings: mtd-physmap: Add endianness supports
Hi Boris,
Quoted 20 lines
-----Original Message-----
From: Prabhakar Kushwaha
Sent: Monday, March 12, 2018 1:41 PM
To: linux-mtd at lists.infradead.org; devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com; shawnguo at kernel.org
Cc: boris.brezillon at free-electrons.com; computersforpeace at gmail.com; oss at buserror.net; Leo Li <[email protected]>; linux-arm- kernel at lists.infradead.org; Prabhakar Kushwaha <[email protected]>
Subject: [PATCH 1/2][v6] dt-bindings: mtd-physmap: Add endianness supportsConnection between flash and controller is not necessary to be always of same type. It may varies from platform to platform.
Adding endianness (optional) property to provide connection type information.
Signed-off-by Prabhakar Kushwaha <[email protected]>Reviewed-by Rob Herring <[email protected]>
Quoted 8 lines
---
Changes for v2: updated subject
Changes for v3: fixed typo for "big-endian"
Changes for v4: Moved binding definition in mtd-physmap.txt as discussed at
https://patchwork.ozlabs.org/patch/842543/
Changes for v5: Sending as it is
Changes for v6: Updated binding when endianness property is absent
I hope this version is good enough to be accepted.
May I go ahead and send device tree changes for other NXP SoCs.
--pk
PATCH v6 1/2 dt-bindings: mtd-physmap: Add endianness supports
In reply to Prabhakar KushwahaQuoted 24 lines · On Mon, 12 Mar 2018 13:41:28 +0530 Prabhakar Kushwaha…
Connection between flash and controller is not necessary to be always of same type. It may varies from platform to platform.
Adding endianness (optional) property to provide connection type information.
Signed-off-by Prabhakar Kushwaha <[email protected]>Reviewed-by Rob Herring <[email protected]>---
Changes for v2: updated subject
Changes for v3: fixed typo for "big-endian"
Changes for v4: Moved binding definition in mtd-physmap.txt as discussed at https://patchwork.ozlabs.org/patch/842543/
Changes for v5: Sending as it is
Changes for v6: Updated binding when endianness property is absentDocumentation/devicetree/bindings/mtd/mtd-physmap.txt | 5 +++++ 1 file changed, 5 insertions(+)Documentation/devicetree/bindings/mtd/mtd-physmap.txt +0
-0
Documentation/devicetree/bindings/mtd/mtd-physmap.txt additional (optional) property is defined: · line 45
Quoted 5 lines
Documentation/devicetree/bindings/mtd/mtd-physmap.txt +2
-0@@ -41,6 +41,11 @@ additional (optional) property is defined: - erase-size : The chip's physical erase block size in bytes. + The device tree may optionally contain endianness property. + little-endian or big-endian : It represents connection between controller and
You still haven't answered the comments I made on your v5. To me, this does not represent how the controller and chip pins are connected, but how the chip was programmed and which endianness should be used by the controller to correctly read the data back. Maybe I'm wrong, hence my question.
Documentation/devicetree/bindings/mtd/mtd-physmap.txt additional (optional) property is defined: · line 47
Quoted 2 lines
Documentation/devicetree/bindings/mtd/mtd-physmap.txt +2
-0+ flash. If this property is absent, connection is described + by the CFI_DEFAULT_ENDIAN.
Nope, you can't refer to linux-specific config options in a DT binding, because those bindings are supposed to be OS-agnostic. Maybe something like "If this property is missing, the endianness is chosen by the system (potentially based on extra configuration options).".
Rob, any suggestion other suggestion?
Regards,
Boris
Signature · 3 lines
Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH v6 1/2 dt-bindings: mtd-physmap: Add endianness supports
Hi Boris,
Quoted 55 lines
-----Original Message-----
From: Boris Brezillon [mailto:boris.brezillon at bootlin.com]
Sent: Friday, March 23, 2018 2:04 PM
To: Prabhakar Kushwaha <[email protected]>;
robh at kernel.org
Cc: linux-mtd at lists.infradead.org; devicetree at vger.kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; boris.brezillon at free- electrons.com; computersforpeace at gmail.com; oss at buserror.net; Leo Li <[email protected]>; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH 1/2][v6] dt-bindings: mtd-physmap: Add endianness supportsQuoted 6 lines · On Mon, 12 Mar 2018 13:41:28 +0530 Prabhakar Kushwaha…
Connection between flash and controller is not necessary to be always of same type. It may varies from platform to platform.
Adding endianness (optional) property to provide connection type information.
Quoted 8 lines
Signed-off-by Prabhakar Kushwaha <[email protected]>Reviewed-by Rob Herring <[email protected]>---
Changes for v2: updated subject
Changes for v3: fixed typo for "big-endian"
Changes for v4: Moved binding definition in mtd-physmap.txt as discussed athttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
Quoted 1 line
chwork.ozlabs.org%2Fpatch%2F842543%2F&data=02%7C01%7Cprabhakar.ku shwah
Quoted 1 line
a%40nxp.com%7C4e3c62614d144bdbb76408d59098d999%7C686ea1d3bc2b4c 6fa92cd
Quoted 1 line
99c5c301635%7C0%7C0%7C636573908516332353&sdata=Od7aqu%2BqV4RHB EmT08UOb
Quoted 16 lines
H2EFGgWmGfftCRKlOlj1kY%3D&reserved=0
Changes for v5: Sending as it is
Changes for v6: Updated binding when endianness property is absentDocumentation/devicetree/bindings/mtd/mtd-physmap.txt | 5 +++++ 1 file changed, 5 insertions(+)Documentation/devicetree/bindings/mtd/mtd-physmap.txt +0
-0@@ -41,6 +41,11 @@ additional (optional) property is defined: - erase-size : The chip's physical erase block size in bytes.
Quoted 10 lines
Documentation/devicetree/bindings/mtd/mtd-physmap.txt additional (optional) property is defined: · line 46
Quoted 3 lines
Documentation/devicetree/bindings/mtd/mtd-physmap.txt +3
-0+ The device tree may optionally contain endianness property. + little-endian or big-endian : It represents connection between + controller andYou still haven't answered the comments I made on your v5. To me, this does not represent how the controller and chip pins are connected, but how the chip was programmed and which endianness should be used by the controller to correctly read the data back. Maybe I'm wrong, hence my question.
NXP's ARM SoC has IFC module which interface with NOR flash. Here IFC is big endian module connected with NOR flash. As SoC has ARM processor(Littler Endian), CONFIG_MTD_CFI_BE_BYTE_SWAP needs to be enabled to make sure data is read correctly. This is the reason, I wrote about connection between controller and flash.
In a way, I agree with you. It is not about connection. It is about how controller read the data (inherently ARM processor)
So I am planning to write below text
little-endian or big-endian: It represents endianness of controller for correct data reading from flash.
If this property is missing, the endianness is chosen by the system (potentially based
on extra configuration options).
please let me know if above definition requires more changes.
Regards,
Prabhakar
PATCH v6 1/2 dt-bindings: mtd-physmap: Add endianness supports
Quoted 72 lines · On Tue, 27 Mar 2018 12:06:41 +0000 Prabhakar Kushwaha…
Hi Boris,
Quoted 55 lines
-----Original Message-----
From: Boris Brezillon [mailto:boris.brezillon at bootlin.com]
Sent: Friday, March 23, 2018 2:04 PM
To: Prabhakar Kushwaha <[email protected]>;
robh at kernel.org
Cc: linux-mtd at lists.infradead.org; devicetree at vger.kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; boris.brezillon at free- electrons.com; computersforpeace at gmail.com; oss at buserror.net; Leo Li <[email protected]>; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH 1/2][v6] dt-bindings: mtd-physmap: Add endianness supportsQuoted 6 lines · On Mon, 12 Mar 2018 13:41:28 +0530 Prabhakar Kushwaha…
Connection between flash and controller is not necessary to be always of same type. It may varies from platform to platform.
Adding endianness (optional) property to provide connection type information.
Quoted 8 lines
Signed-off-by Prabhakar Kushwaha <[email protected]>Reviewed-by Rob Herring <[email protected]>---
Changes for v2: updated subject
Changes for v3: fixed typo for "big-endian"
Changes for v4: Moved binding definition in mtd-physmap.txt as discussed athttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
Quoted 1 line
chwork.ozlabs.org%2Fpatch%2F842543%2F&data=02%7C01%7Cprabhakar.ku shwah
Quoted 1 line
a%40nxp.com%7C4e3c62614d144bdbb76408d59098d999%7C686ea1d3bc2b4c 6fa92cd
Quoted 1 line
99c5c301635%7C0%7C0%7C636573908516332353&sdata=Od7aqu%2BqV4RHB EmT08UOb
Quoted 16 lines
H2EFGgWmGfftCRKlOlj1kY%3D&reserved=0
Changes for v5: Sending as it is
Changes for v6: Updated binding when endianness property is absentDocumentation/devicetree/bindings/mtd/mtd-physmap.txt | 5 +++++ 1 file changed, 5 insertions(+)Documentation/devicetree/bindings/mtd/mtd-physmap.txt +0
-0@@ -41,6 +41,11 @@ additional (optional) property is defined: - erase-size : The chip's physical erase block size in bytes.Quoted 10 lines
Documentation/devicetree/bindings/mtd/mtd-physmap.txt additional (optional) property is defined: · line 46
Quoted 3 lines
Documentation/devicetree/bindings/mtd/mtd-physmap.txt +3
-0+ The device tree may optionally contain endianness property. + little-endian or big-endian : It represents connection between + controller andYou still haven't answered the comments I made on your v5. To me, this does not represent how the controller and chip pins are connected, but how the chip was programmed and which endianness should be used by the controller to correctly read the data back. Maybe I'm wrong, hence my question.
NXP's ARM SoC has IFC module which interface with NOR flash. Here IFC is big endian module connected with NOR flash. As SoC has ARM processor(Littler Endian),
CONFIG_MTD_CFI_BE_BYTE_SWAPneeds to be enabled to make sure data is read correctly. This is the reason, I wrote about connection between controller and flash.
Quoted 5 lines
In a way, I agree with you. It is not about connection. It is about how controller read the data (inherently ARM processor)
So I am planning to write below text
little-endian or big-endian: It represents endianness of controller for correct data reading from flash.
"
Represents the endianness that should be used by the controller to properly read/write data from/to the flash.
"
Quoted 2 lines
If this property is missing, the endianness is chosen by the system (potentially based
on extra configuration options).
This part is good.
Quoted 5 lines
please let me know if above definition requires more changes.
Regards,
Prabhakar
Signature · 3 lines
Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH v6 1/2 dt-bindings: mtd-physmap: Add endianness supports
In reply to Prabhakar KushwahaQuoted 22 lines · Prabhakar Kushwaha
Hi Boris,
Quoted 12 lines
-----Original Message-----
From: Boris Brezillon [mailto:boris.brezillon at bootlin.com]
Sent: Friday, March 23, 2018 2:04 PM
To: Prabhakar Kushwaha <[email protected]>;
robh at kernel.org
Cc: linux-mtd at lists.infradead.org; devicetree at vger.kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; boris.brezillon at free- electrons.com; computersforpeace at gmail.com; oss at buserror.net; Leo Li <[email protected]>; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH 1/2][v6] dt-bindings: mtd-physmap: Add endianness supportsQuoted 7 lines
You still haven't answered the comments I made on your v5. To me, this does
not represent how the controller and chip pins are connected, but how the chip was programmed and which endianness should be used by the controller to correctly read the data back. Maybe I'm wrong, hence my question.
Quoted 8 lines
NXP's ARM SoC has IFC module which interface with NOR flash. Here IFC is big endian module connected with NOR flash.
As SoC has ARM processor(Littler Endian),CONFIG_MTD_CFI_BE_BYTE_SWAPneeds to be enabled to make sure data is read correctly.
This is the reason, I wrote about connection between controller and flash.In a way, I agree with you. It is not about connection. It is about how controller read the data (inherently ARM processor)
It is not about anything inherent to ARM (which, like PPC, is a bi-endian arch). It's about the programming model of IFC on certain SoCs.
-Scott