From: "Li.Xiubo@freescale.com" <Li.Xiubo@freescale.com>
To: Mark Rutland <mark.rutland@arm.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: Mon, 19 May 2014 04:11:35 +0000 [thread overview]
Message-ID: <00adcdedcfdf4c828d5fd5a8dd7e28bd@BY2PR03MB505.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20140509164719.GE16418@e106331-lin.cambridge.arm.com>
> Subject: Re: [PATCHv4 2/2] regmap: add DT endianness binding support.
>
> 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.
>
Yes, If my understanding is correct, if we need inverting the bytes order,
should be add one property here, regardless of the CPU's endianesses.
> > 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?).
>
Yes, for now the 'reg' is for all registers of the device.
And the 'val' is for all the values and buffers of the device.
@Mark Brown,
Do you have any correction here ?
> 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.
>
@Mark Rutland, @Mark Brown,
Yes, where should I locate the documentation ?
Is Documentation/devicetree/bindings/regmap/ okay ?
Thanks,
BRs
Xiubo
> > + 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.
prev parent reply other threads:[~2014-05-19 4:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 2:04 [PATCHv4 0/2] " 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
2014-05-09 2:04 ` [PATCHv4 2/2] regmap: add DT endianness binding support Xiubo Li
2014-05-09 16:47 ` Mark Rutland
2014-05-19 4:11 ` Li.Xiubo [this message]
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=00adcdedcfdf4c828d5fd5a8dd7e28bd@BY2PR03MB505.namprd03.prod.outlook.com \
--to=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=mark.rutland@arm.com \
--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
all inboxes | Powered by JetHome®