From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Date: Sun, 02 Mar 2014 20:59:11 +0000 Subject: Re: [PATCH 1/2] iommu: Add driver for Renesas VMSA-compatible IPMMU Message-Id: <9614296.npf9XYVJ8Q@avalon> List-Id: References: <1393601099-4413-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> <1393601099-4413-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Geert Uytterhoeven Cc: Laurent Pinchart , iommu@lists.linux-foundation.org, Linux-sh list , Ben Dooks Hi Geert, Thank you for the review. On Friday 28 February 2014 18:48:22 Geert Uytterhoeven wrote: > On Fri, Feb 28, 2014 at 4:24 PM, Laurent Pinchart wrote: > > +/* > > + * VMSA that states in section B3.6.3 "Control of Secure or Non-secure > > memory > > VMSA states > > > + * access, Long-descriptor format" that the NStable bit being set in a > > table + * descriptor will result in the NStable and NS bits of all child > > entries being + * ignored and considered as being set. The IPMMU seems > > not to comply with this, + * as it generates a secure access page fault > > if any of the NStable and NS bits + * isn't set when running in > > non-secure mode. > > + */ > > > > + /* > > + * TTBCR > > + * We use long descriptor, with inner-shareable WBWA tables and > > allocate > > descriptors > > > + * the whole 32-bit VA space to TTBR0. > > + */ > > > > + /* > > + * Clear the error status flags. Unlike traditionnal interrupt > > flag > > traditional > > Sorry, only comments on the comments ;-) I'll of course assume this means that the driver is perfect ;-) I'll fix all this in v2. -- Regards, Laurent Pinchart