On Thu, May 12, 2016 at 11:31 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Mon, May 09, 2016 at 10:58:08AM +0000, Yao Yuan wrote: > >> For example, if DSPI controller register is BE, so I set big-endian in DT. >> That means we should R/W the DSPI controller register with big-endian. >> Then I can think all of the value we R/W to/from DSPI controller register, we can >> Think they are the BE. >> So that we can understand it easy. > >> That means no matter core is LE or BE, we both need get the value from DSPI register >> with big endian. > > That's not how regmap is intended to be used, the intention is that the > driver will interact with native endian values and regmap will hide the > endianness changes. You could mask this with some cpu_to_be() and > be_to_cpu() usage but I'm not sure it's a great idea or what it's buying > you. So you do agree that the DSPI driver shouldn't use the regmap APIs? It is still confusing to me on what is the intended behavior for the endianness property in device tree. Previously for regmap binding the default endian is the native-endian if no endian property is not present. But for bindings of many devices including the Documentation/devicetree/bindings/common-properties.txt file, the default endian is the endian when the device is first used in the dts binding. For example, the FSL/NXP IFC device was first used as a big-endian device for PowerPC SoCs. The default endian should be big-endian no matter if it is used on PowerPC or ARM later. It shouldn't be default to little-endian on an ARM SoC. Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
