[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171114194432.GB28152@atomide.com>
Date: Tue, 14 Nov 2017 11:44:32 -0800
From: Tony Lindgren <tony@...mide.com>
To: Tero Kristo <t-kristo@...com>
Cc: Joonsoo Kim <iamjoonsoo.kim@....com>, Pavel Machek <pavel@....cz>,
pali.rohar@...il.com, sre@...nel.org,
kernel list <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-omap@...r.kernel.org, khilman@...nel.org,
aaro.koskinen@....fi, ivo.g.dimitrov.75@...il.com,
patrikbachan@...il.com, serge@...lyn.com, abcloriens@...il.com,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Vlastimil Babka <vbabka@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Russell King <linux@...linux.org.uk>
Subject: Re: n900 in next-20170901
* Tero Kristo <t-kristo@...com> [171114 19:34]:
> I guess you could just use rx51_secure_dispatcher and ditch the
> save_secure_ram_context call completely (and most of the other related
> code)? That one would handle the cache also in a clean manner.
>
> Something like:
>
> rx51_secure_dispatcher(25, 0, FLAG_START_CRITICAL, 4,
> __pa(omap3_secure_ram_storage), 0, 1, 1);
That's different, as rx51_secure_dispatcher does the following:
- Use arguments + 1 instead of 4, we currently use just 4
- Disables local_irq and fiq, we are not doing that now
- Flushes and invalidates cache range, we are not doing that
- Calls omap_smc3 that only does mov r6, #0xff, and does not
do mov r2, #4
- Missing nops after it's done
This just based on a quick look I did earlier. So just
because of the extra work it does we don't want to do it
even if it worked :)
Regards,
Tony
Powered by blists - more mailing lists