On Thu, May 12, 2016 at 06:55:38PM -0500, Leo Li wrote: > 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: > > 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? No, of course not! The driver's usage just appears to be very confused. > It is still confusing to me on what is the intended behavior for the > endianness property in device tree. Previously for regmap binding the What is confusing? If the device is big endian the driver should specify big endian. If the device is little endian the driver should specify little endian. If the device is native endian the driver should specify native endian. Regardless of what the endianness of the device is the driver should always use native endian when talking to the regmap APIs. > default endian is the native-endian if no endian property is not > present. But for bindings of many devices including the No, the default is little endian (it always has been, though for a long time only by accident and now the documentation matches that). If this was causing problems you should have reported it rather than trying to hack around it.
Attachment:
signature.asc
Description: PGP signature
