devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Xiubo Li <Li.Xiubo@freescale.com>
Cc: "broonie@kernel.org" <broonie@kernel.org>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv4 2/2] regmap: add DT endianness binding support.
Date: Fri, 9 May 2014 17:47:19 +0100	[thread overview]
Message-ID: <20140509164719.GE16418@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <1399601073-19278-3-git-send-email-Li.Xiubo@freescale.com>

On Fri, May 09, 2014 at 03:04:33AM +0100, Xiubo Li wrote:
> For many drivers which will support rich endianness of CPU<-->Dev
> need define DT properties by itself without the binding support.
> 
> The endianness using regmap:
> Index    CPU       Device     Endianess flag for DT bool property
> ------------------------------------------------------------
> 1        LE        LE         -
> 2        LE        BE         'big-endian-{val,reg}'
> 3        BE        BE         -
> 4        BE        LE         'little-endian-{val,reg}'

Get rid of the CPU column. It has precisely _nothing_ to do with the
device.

If you happen to have a device that can be integrated with varying
endianness, the endianness should be described regardless of whether
this happens to be the same as the CPU endianness. The kernel can then
choose to do the right thing regardless.

Assuming LE or BE by default is sane if most implementations are one
rather than the other. Probing and figuring it out dynamically is also
fine. Assuming that it's the same as the kernel is broken in general,
and should be avoided -- those cases _require_ a *-endian property to
work if the CPU can function in either endianness.

> Please see the following documetation for detail:
>     Documentation/devicetree/bindings/endianness/endianness.txt

I don't think this is sufficient. That document describes the preferred
idiom, not the meaning w.r.t. a specific binding.

[...]

> +	case REGMAP_ENDIAN_REG:
> +		if (of_property_read_bool(np, "big-endian-reg"))
> +			*endian = REGMAP_ENDIAN_BIG;
> +		else if (of_property_read_bool(np, "little-endian-reg"))
> +			*endian = REGMAP_ENDIAN_LITTLE;

While this follows the guidelines you've added, context is still
required to understand precisely what this means. We need a binding
document describing what *-endian-reg means for this binding (i.e. what
does -reg cover? All registers? some? buffers?).

Imagine I added a little-endian-foo property. You'd be able to reason
that something is little endian, but you'd have no idea of precisely
what without reading documentation or code. As not everyone wants to
read several thousand lines of Linux kernel code to write a dts we
require documentation.

> +	case REGMAP_ENDIAN_VAL:
> +		if (of_property_read_bool(np, "big-endian-val"))
> +			*endian = REGMAP_ENDIAN_BIG;
> +		else if (of_property_read_bool(np, "little-endian-val"))
> +			*endian = REGMAP_ENDIAN_LITTLE;

Likewise.

Cheers,
Mark.

  reply	other threads:[~2014-05-09 16:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09  2:04 [PATCHv4 0/2] add DT endianness binding support Xiubo Li
2014-05-09  2:04 ` [PATCHv4 1/2] dt/bindings: Add the DT binding documentation for endianness Xiubo Li
2014-05-09 16:32   ` Mark Rutland
2014-05-09 17:02     ` Mark Brown
2014-05-09 18:12       ` Mark Rutland
     [not found] ` <1399601073-19278-1-git-send-email-Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2014-05-09  2:04   ` [PATCHv4 2/2] regmap: add DT endianness binding support Xiubo Li
2014-05-09 16:47     ` Mark Rutland [this message]
2014-05-19  4:11       ` Li.Xiubo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140509164719.GE16418@e106331-lin.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=Li.Xiubo@freescale.com \
    --cc=Pawel.Moll@arm.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).