From: Timur Tabi <timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: "grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding
Date: Fri, 28 Feb 2014 11:07:31 -0600 [thread overview]
Message-ID: <5310C253.40804@codeaurora.org> (raw)
In-Reply-To: <20140228162114.GA30996-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
On 02/28/2014 10:21 AM, Will Deacon wrote:
>>> > >+- calxeda,smmu-secure-config-access : Enable proper handling of buggy
>>> > >+ implementations that always use secure access to
>>> > >+ SMMU configuration registers. In this case non-secure
>>> > >+ aliases of secure registers have to be used during
>>> > >+ SMMU configuration.
>> >
>> >I'm confused. Why does this property have a "calxeda" prefix? How is
>> >it a Calxeda-specific property?
> Because they wired up their SMMU backwards. It's basically an
> implementation-specific erratum workaround.
Hmmmm....
Other than making the same wiring mistake, is there any reason any other
ARM chip would need this property set?
The reason I ask is that it's kinda weird (well, to me at least) that we
have an property named for a specific SoC, but the implementation and
documentation tries so hard to hide that fact. I would think that the
binding document would provide some explanation as to why the property
has a "calxeda" prefix.
WARNING: multiple messages have this Message-ID (diff)
From: timur@codeaurora.org (Timur Tabi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding
Date: Fri, 28 Feb 2014 11:07:31 -0600 [thread overview]
Message-ID: <5310C253.40804@codeaurora.org> (raw)
In-Reply-To: <20140228162114.GA30996@mudshark.cambridge.arm.com>
On 02/28/2014 10:21 AM, Will Deacon wrote:
>>> > >+- calxeda,smmu-secure-config-access : Enable proper handling of buggy
>>> > >+ implementations that always use secure access to
>>> > >+ SMMU configuration registers. In this case non-secure
>>> > >+ aliases of secure registers have to be used during
>>> > >+ SMMU configuration.
>> >
>> >I'm confused. Why does this property have a "calxeda" prefix? How is
>> >it a Calxeda-specific property?
> Because they wired up their SMMU backwards. It's basically an
> implementation-specific erratum workaround.
Hmmmm....
Other than making the same wiring mistake, is there any reason any other
ARM chip would need this property set?
The reason I ask is that it's kinda weird (well, to me at least) that we
have an property named for a specific SoC, but the implementation and
documentation tries so hard to hide that fact. I would think that the
binding document would provide some explanation as to why the property
has a "calxeda" prefix.
next prev parent reply other threads:[~2014-02-28 17:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-21 17:16 [PATCH 0/5] iommu/arm-smmu: updates for 3.15 Will Deacon
2014-02-21 17:16 ` Will Deacon
[not found] ` <1393002992-24561-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-02-21 17:16 ` [PATCH 1/5] iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS Will Deacon
2014-02-21 17:16 ` Will Deacon
2014-02-21 17:16 ` [PATCH 2/5] iommu/arm-smmu: support buggy implementations with secure cfg accesses Will Deacon
2014-02-21 17:16 ` Will Deacon
2014-02-21 17:16 ` [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding Will Deacon
2014-02-21 17:16 ` Will Deacon
2014-02-21 18:57 ` Sergei Shtylyov
2014-02-21 18:57 ` Sergei Shtylyov
[not found] ` <1393002992-24561-4-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-02-28 16:17 ` Timur Tabi
2014-02-28 16:17 ` Timur Tabi
[not found] ` <CAOZdJXUfAygZqw9s5qOECLjyo=B0VaD29iesbWzDeMbbyVTgqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-02-28 16:21 ` Will Deacon
2014-02-28 16:21 ` Will Deacon
[not found] ` <20140228162114.GA30996-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2014-02-28 17:07 ` Timur Tabi [this message]
2014-02-28 17:07 ` Timur Tabi
[not found] ` <5310C253.40804-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-03-04 10:08 ` Will Deacon
2014-03-04 10:08 ` Will Deacon
[not found] ` <20140304100837.GB8766-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2014-03-04 13:20 ` Timur Tabi
2014-03-04 13:20 ` Timur Tabi
2014-02-21 17:16 ` [PATCH 4/5] iommu/arm-smmu: clean up use of `flags' in page table handling code Will Deacon
2014-02-21 17:16 ` Will Deacon
2014-02-21 17:16 ` [PATCH 5/5] iommu/arm-smmu: provide option to dsb macro when publishing tables Will Deacon
2014-02-21 17:16 ` Will Deacon
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=5310C253.40804@codeaurora.org \
--to=timur-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@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.