All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Nishanth Menon <nm@ti.com>
Cc: "Ивайло Димитров" <freemangordon@abv.bg>,
	pali.rohar@gmail.com, linux@arm.linux.org.uk,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Date: Mon, 4 Mar 2013 10:58:06 -0800	[thread overview]
Message-ID: <20130304185806.GS11806@atomide.com> (raw)
In-Reply-To: <CAGo_u6omQdSzpfthHNAU1UvgSvkgq3ZC6g1Ha9oi0nc9QJ71nA@mail.gmail.com>

* Nishanth Menon <nm@ti.com> [130301 06:42]:
> On Fri, Mar 1, 2013 at 1:47 AM, Ивайло Димитров <freemangordon@abv.bg> wrote:
> >
> > They look similar, but they are not equivalent :). The first major difference is here (code taken from omap-smc.S)
> >
> >> ENTRY(omap_smc2)
> >>          stmfd   sp!, {r4-r12, lr}
> >>          mov     r3, r2
> >>          mov     r2, r1
> >>          mov     r1, #0x0        @ Process ID
> >>          mov     r6, #0xff
> >>          mov     r12, #0x00      @ Secure Service ID
> >
> > Always zero, while RX51 PPA expects a real value. I wonder if it is a bug, but anyway I don't see the id parameter (R0) used.
> >
> >>          mov     r7, #0
> >>          mcr     p15, 0, r7, c7, c5, 6
> >
> > According to ARM TRM, this is "Invalidate entire branch predictor array"(IIUC). NFC why it is needed here, but this will not work on RX-51 until IBE bit in ACR is set.
> >
> >>          dsb
> >>          dmb
> >>          smc     #0
> >
> > RX-51 needs smc #1 ;)
> >
> >>          ldmfd   sp!, {r4-r12, pc}
> >
> >
> > The next major difference is that RX-51 expects parameter count passed in R3[0] to be the count of the remaining parameters +1, but omap_secure_dispatcher (in omap-secure.c) is passing the exact count of the remaining parameters.
> >
> > I guess all of the above problems can be fixed/workarounded, but I wonder does it worth. Not to say that I don't have BB around to test if the code still works if I make changes to omap2-secure.c/omap-smc.S :)
> >
> >
> 
> Yep, that was my point - instead of introducing new functions,
> extending the existing functions to handle new requirements is better
> solution, IMHO.

I think there have been patches posted for ARM generic SMC
handling. Might be worth looking at those a bit and see if
this can be made generic. I think only the SMC call numbering
is different for various SoCs?

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Date: Mon, 4 Mar 2013 10:58:06 -0800	[thread overview]
Message-ID: <20130304185806.GS11806@atomide.com> (raw)
In-Reply-To: <CAGo_u6omQdSzpfthHNAU1UvgSvkgq3ZC6g1Ha9oi0nc9QJ71nA@mail.gmail.com>

* Nishanth Menon <nm@ti.com> [130301 06:42]:
> On Fri, Mar 1, 2013 at 1:47 AM, ?????? ???????? <freemangordon@abv.bg> wrote:
> >
> > They look similar, but they are not equivalent :). The first major difference is here (code taken from omap-smc.S)
> >
> >> ENTRY(omap_smc2)
> >>          stmfd   sp!, {r4-r12, lr}
> >>          mov     r3, r2
> >>          mov     r2, r1
> >>          mov     r1, #0x0        @ Process ID
> >>          mov     r6, #0xff
> >>          mov     r12, #0x00      @ Secure Service ID
> >
> > Always zero, while RX51 PPA expects a real value. I wonder if it is a bug, but anyway I don't see the id parameter (R0) used.
> >
> >>          mov     r7, #0
> >>          mcr     p15, 0, r7, c7, c5, 6
> >
> > According to ARM TRM, this is "Invalidate entire branch predictor array"(IIUC). NFC why it is needed here, but this will not work on RX-51 until IBE bit in ACR is set.
> >
> >>          dsb
> >>          dmb
> >>          smc     #0
> >
> > RX-51 needs smc #1 ;)
> >
> >>          ldmfd   sp!, {r4-r12, pc}
> >
> >
> > The next major difference is that RX-51 expects parameter count passed in R3[0] to be the count of the remaining parameters +1, but omap_secure_dispatcher (in omap-secure.c) is passing the exact count of the remaining parameters.
> >
> > I guess all of the above problems can be fixed/workarounded, but I wonder does it worth. Not to say that I don't have BB around to test if the code still works if I make changes to omap2-secure.c/omap-smc.S :)
> >
> >
> 
> Yep, that was my point - instead of introducing new functions,
> extending the existing functions to handle new requirements is better
> solution, IMHO.

I think there have been patches posted for ARM generic SMC
handling. Might be worth looking at those a bit and see if
this can be made generic. I think only the SMC call numbering
is different for various SoCs?

Regards,

Tony

  reply	other threads:[~2013-03-04 18:58 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01  7:47 [PATCH] arm: omap: RX-51: ARM errata 430973 workaround Ивайло Димитров
2013-03-01 14:38 ` Nishanth Menon
2013-03-01 14:38   ` Nishanth Menon
2013-03-04 18:58   ` Tony Lindgren [this message]
2013-03-04 18:58     ` Tony Lindgren
2013-03-06 14:09     ` Pali Rohár
2013-03-06 14:09       ` Pali Rohár
2013-03-06 17:51       ` Tony Lindgren
2013-03-06 17:51         ` Tony Lindgren
2013-03-06 19:13         ` Pali Rohár
2013-03-06 19:13           ` Pali Rohár
2013-03-24 14:26           ` Pali Rohár
2013-03-24 14:26             ` Pali Rohár
2013-03-27 20:56             ` Tony Lindgren
2013-03-27 20:56               ` Tony Lindgren
2013-03-27 20:56               ` Tony Lindgren
2013-03-27 21:05               ` Pali Rohár
2013-03-27 21:05                 ` Pali Rohár
2013-03-27 21:12                 ` Tony Lindgren
2013-03-27 21:12                   ` Tony Lindgren
2013-03-28  9:50               ` Russell King - ARM Linux
2013-03-28  9:50                 ` Russell King - ARM Linux
2013-03-28 10:07                 ` Santosh Shilimkar
2013-03-28 10:07                   ` Santosh Shilimkar
2013-03-28 15:53                   ` Tony Lindgren
2013-03-28 15:53                     ` Tony Lindgren
  -- strict thread matches above, loose matches on Subject: below --
2013-03-30 22:31 Ивайло Димитров
2013-03-31  7:37 ` Pavel Machek
2013-03-31  7:37   ` Pavel Machek
2013-03-28  5:30 Ивайло Димитров
2013-03-28 15:58 ` Tony Lindgren
2013-03-28 15:58   ` Tony Lindgren
2013-03-28 15:58   ` Tony Lindgren
2013-03-06  9:32 Ивайло Димитров
2013-03-01 10:09 Ивайло Димитров
2013-03-01 23:51 ` Aaro Koskinen
2013-03-01 23:51   ` Aaro Koskinen
2013-03-01 23:51   ` Aaro Koskinen
2013-02-28  9:42 Pali Rohár
2013-02-28  9:42 ` Pali Rohár
2013-02-28  9:42 ` Pali Rohár
2013-02-28 14:40 ` Nishanth Menon
2013-02-28 14:40   ` Nishanth Menon
2013-02-28 14:40   ` Nishanth Menon
2013-03-01  9:43 ` Peter De Schrijver
2013-03-01  9:43   ` Peter De Schrijver
2013-03-30 18:36 ` Pavel Machek
2013-03-30 18:36   ` Pavel Machek

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=20130304185806.GS11806@atomide.com \
    --to=tony@atomide.com \
    --cc=freemangordon@abv.bg \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nm@ti.com \
    --cc=pali.rohar@gmail.com \
    /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.