From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] of: change fixup of dma-ranges size to error
Date: Thu, 6 Apr 2017 11:37:16 -0700 [thread overview]
Message-ID: <58E68ADC.6040603@gmail.com> (raw)
In-Reply-To: <CAL_Jsq+GLBtaezUiTbm0DAA2+MjcvxAcCsS-qJrr05YcTO5tdw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/06/17 07:03, Rob Herring wrote:
> On Thu, Apr 6, 2017 at 1:18 AM, <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>>
>> of_dma_get_range() has workaround code to fixup a device tree that
>> incorrectly specified a mask instead of a size for property
>> dma-ranges. That device tree was fixed a year ago in v4.6, so
>> the workaround is no longer needed. Leave a data validation
>> check in place, but no longer do the fixup. Move the check
>> one level deeper in the call stack so that other possible users
>> of dma-ranges will also be protected.
>>
>> The fix to the device tree was in
>> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree").
>
> NACK.
> This was by design. You can't represent a size of 2^64 or 2^32.
I agree that being unable to represent a size of 2^32 in a u32 and
a size of 2^64 in a u64 is the underlying issue.
But the code to convert a mask to a size is _not_ design, it is a
hack that temporarily worked around a device tree that did not follow
the dma-ranges binding in the ePAPR.
That device tree was corrected a year ago to provide a size instead of
a mask.
> Well, technically you can for the latter, but then you have to grow
> #size-cells to 2 for an otherwise all 32-bit system which seems kind
> of pointless and wasteful. You could further restrict this to only
> allow ~0 and not just any case with bit 0 set.
>
> I'm pretty sure AMD is not the only system. There were 32-bit systems too.
I examined all instances of property dma-ranges in in tree dts files in
Linux 4.11-rc1. There are none that incorrectly specify mask instead of
size.
#size-cells only changes to 2 for the dma-ranges property and the ranges
property when size is 2^32, so that is a very small amount of space.
The patch does not allow for a size of 2^64. If a system requires a
size of 2^64 then the type of size needs to increase to be larger
than a u64. If you would like for the code to be defensive and
detect a device tree providing a size of 2^64 then I can add a
check to of_dma_get_range() to return -EINVAL if #size-cells > 2.
When that error triggers, the type of size can be changed.
>
> Rob
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list@gmail.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] of: change fixup of dma-ranges size to error
Date: Thu, 6 Apr 2017 11:37:16 -0700 [thread overview]
Message-ID: <58E68ADC.6040603@gmail.com> (raw)
In-Reply-To: <CAL_Jsq+GLBtaezUiTbm0DAA2+MjcvxAcCsS-qJrr05YcTO5tdw@mail.gmail.com>
On 04/06/17 07:03, Rob Herring wrote:
> On Thu, Apr 6, 2017 at 1:18 AM, <frowand.list@gmail.com> wrote:
>> From: Frank Rowand <frank.rowand@sony.com>
>>
>> of_dma_get_range() has workaround code to fixup a device tree that
>> incorrectly specified a mask instead of a size for property
>> dma-ranges. That device tree was fixed a year ago in v4.6, so
>> the workaround is no longer needed. Leave a data validation
>> check in place, but no longer do the fixup. Move the check
>> one level deeper in the call stack so that other possible users
>> of dma-ranges will also be protected.
>>
>> The fix to the device tree was in
>> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree").
>
> NACK.
> This was by design. You can't represent a size of 2^64 or 2^32.
I agree that being unable to represent a size of 2^32 in a u32 and
a size of 2^64 in a u64 is the underlying issue.
But the code to convert a mask to a size is _not_ design, it is a
hack that temporarily worked around a device tree that did not follow
the dma-ranges binding in the ePAPR.
That device tree was corrected a year ago to provide a size instead of
a mask.
> Well, technically you can for the latter, but then you have to grow
> #size-cells to 2 for an otherwise all 32-bit system which seems kind
> of pointless and wasteful. You could further restrict this to only
> allow ~0 and not just any case with bit 0 set.
>
> I'm pretty sure AMD is not the only system. There were 32-bit systems too.
I examined all instances of property dma-ranges in in tree dts files in
Linux 4.11-rc1. There are none that incorrectly specify mask instead of
size.
#size-cells only changes to 2 for the dma-ranges property and the ranges
property when size is 2^32, so that is a very small amount of space.
The patch does not allow for a size of 2^64. If a system requires a
size of 2^64 then the type of size needs to increase to be larger
than a u64. If you would like for the code to be defensive and
detect a device tree providing a size of 2^64 then I can add a
check to of_dma_get_range() to return -EINVAL if #size-cells > 2.
When that error triggers, the type of size can be changed.
>
> Rob
>
next prev parent reply other threads:[~2017-04-06 18:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 6:18 [PATCH] of: change fixup of dma-ranges size to error frowand.list-Re5JQEeQqe8AvxtiuMwx3w
2017-04-06 6:18 ` frowand.list
[not found] ` <1491459529-31391-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-06 14:03 ` Rob Herring
2017-04-06 14:03 ` Rob Herring
[not found] ` <CAL_Jsq+GLBtaezUiTbm0DAA2+MjcvxAcCsS-qJrr05YcTO5tdw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-06 18:37 ` Frank Rowand [this message]
2017-04-06 18:37 ` Frank Rowand
[not found] ` <58E68ADC.6040603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-06 22:41 ` Rob Herring
2017-04-06 22:41 ` Rob Herring
[not found] ` <CAL_Jsq+VreUFtA8ozs0Jcz45PTc-jTT=CEKuezeU7QYviiN-Jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-07 5:18 ` Frank Rowand
2017-04-07 5:18 ` Frank Rowand
[not found] ` <58E72123.4040607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-07 17:09 ` Rob Herring
2017-04-07 17:09 ` Rob Herring
[not found] ` <CAL_Jsq+8PoR5ikPbTbHgd-8rkGFmvorLrS9hHpmkVynkh69e-A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-07 23:26 ` Frank Rowand
2017-04-07 23:26 ` Frank Rowand
[not found] ` <58E82008.7000102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-10 11:48 ` Sricharan R
2017-04-10 11:48 ` Sricharan R
[not found] ` <19a2a28f-8338-970e-3b5f-05be3362fb9a-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-04-10 11:59 ` Frank Rowand
2017-04-10 11:59 ` Frank Rowand
2017-04-10 13:11 ` Robin Murphy
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=58E68ADC.6040603@gmail.com \
--to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.