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.
next prev parent 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).