All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "Nishanth Menon" <nm@ti.com>,
	"Ивайло Димитров" <freemangordon@abv.bg>,
	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: Wed, 6 Mar 2013 20:13:15 +0100	[thread overview]
Message-ID: <201303062013.16302@pali> (raw)
In-Reply-To: <20130306175120.GP11806@atomide.com>

[-- Attachment #1: Type: Text/Plain, Size: 2938 bytes --]

On Wednesday 06 March 2013 18:51:21 Tony Lindgren wrote:
> * Pali Rohár <pali.rohar@gmail.com> [130306 06:13]:
> > On Monday 04 March 2013 19:58:06 Tony Lindgren wrote:
> > > * 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
> > 
> > Hi Tony, where are patches for ARM generic SMC handling?
> 
> Sorry don't have the link available, but I recall seeing some
> patch on linux-arm-kernel within past six months that added a
> generic smc function.. Or maybe I was dreaming or something.
> 
> Regards,
> 
> Tony

I am not able to find that patch...

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: pali.rohar@gmail.com (Pali Rohár)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Date: Wed, 6 Mar 2013 20:13:15 +0100	[thread overview]
Message-ID: <201303062013.16302@pali> (raw)
In-Reply-To: <20130306175120.GP11806@atomide.com>

On Wednesday 06 March 2013 18:51:21 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [130306 06:13]:
> > On Monday 04 March 2013 19:58:06 Tony Lindgren wrote:
> > > * 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
> > 
> > Hi Tony, where are patches for ARM generic SMC handling?
> 
> Sorry don't have the link available, but I recall seeing some
> patch on linux-arm-kernel within past six months that added a
> generic smc function.. Or maybe I was dreaming or something.
> 
> Regards,
> 
> Tony

I am not able to find that patch...

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130306/5aec96fc/attachment.sig>

  reply	other threads:[~2013-03-06 19:13 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
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 [this message]
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=201303062013.16302@pali \
    --to=pali.rohar@gmail.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=tony@atomide.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.