linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: pali.rohar@gmail.com (Pali Rohár)
To: linux-arm-kernel@lists.infradead.org
Subject: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
Date: Fri, 29 May 2015 00:27:21 +0200	[thread overview]
Message-ID: <201505290027.21231@pali> (raw)
In-Reply-To: <20150528222412.GM30984@atomide.com>

On Friday 29 May 2015 00:24:13 Tony Lindgren wrote:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [150528 13:28]:
> > On 28 May 2015 at 18:01, Tony Lindgren <tony@atomide.com> wrote:
> > > For failed device access you get an interrupt
> > 
> > Well for failed reads you get a bus error, and "catching" those
> > (e.g. using the existing exception mechanism used to catch MMU
> > faults) is the whole issue.
> > 
> > Though now that you mention it, it is true that for writes you
> > won't get any fault (at least on the DM814x and AM335x the posting
> > point appears to be the async bridge from MPUSS to the L3
> > interconnect) but an interconnect error irq instead. It may be
> > easier to make some kind of harmless write (e.g. to the version
> > register), wait a bit, and check if the write triggered an
> > interconnect error.
> > 
> > Feels hackish though: you'd need to be sure you waited long enough
> > (though using a read from another device on the same L4
> > interconnect should be a reliable barrier in this case), and
> > drivers for receiving/interpreting interconnect errors are not
> > implemented yet on all SoCs (for some, like the AM335x, TI didn't
> > even bother publishing the relevant data in its TRM). Interconnect
> > errors can also be lost in some cases (multiple errors involving
> > the same target in a short time window) though that problem
> > shouldn't arise in this particular case.
> 
> Hmm I believe the interrupt happens immediately trying to access an
> invalid device. But maybe I'm thinking about just errors if a device
> is not powered or clocked. So obviously some experiments need to be
> done :)
> 
> The advantage here would be that the l3 driver actually already knows
> quite a bit about the devices on the bus.
> 
> > Also, presumably interconnect error reporting is unavailable on HS
> > devices given the fact that all interconnect registers seemed to be
> > inaccessible?
> 
> Oh OK yeah then that would not work for Pali's case. I guess it just
> needs to be tested.
> 
> Regards,
> 
> Tony

Ok, thanks for info. Do you have some quick small patches for testing? 
Or some pointers what is needed to modify and how?

-- 
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/20150529/f1493a36/attachment-0001.sig>

  reply	other threads:[~2015-05-28 22:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20131206213613.GA19648@earth.universe>
     [not found] ` <201502111339.54480@pali>
     [not found]   ` <CAALWOA_ngoSKjB=ZQ264Va37bBK7v41Ei45SyoYLiMdanTKnxQ@mail.gmail.com>
     [not found]     ` <201502112128.44852@pali>
2015-02-11 20:40       ` runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot) Nishanth Menon
2015-02-18 21:14         ` Pali Rohár
2015-05-28  7:37         ` Pali Rohár
2015-05-28 16:01           ` Tony Lindgren
2015-05-28 20:26             ` Matthijs van Duin
2015-05-28 22:24               ` Tony Lindgren
2015-05-28 22:27                 ` Pali Rohár [this message]
2015-05-29  0:15                   ` Tony Lindgren
2015-05-29  0:58                 ` Matthijs van Duin
2015-05-29  1:35                   ` Matthijs van Duin
2015-05-29 15:50                     ` Tony Lindgren
2015-05-29 18:16                       ` Tony Lindgren
2015-05-30 15:22                       ` Matthijs van Duin
2015-06-01 17:58                         ` Tony Lindgren
2015-06-01 20:32                           ` Matthijs van Duin
2015-06-01 20:52                             ` Tony Lindgren
2015-06-02  4:21                               ` Matthijs van Duin
2015-02-19 18:20     ` Pali Rohár
2015-02-19 20:25       ` Matthijs van Duin
2015-02-19 21:10       ` Aaro Koskinen

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=201505290027.21231@pali \
    --to=pali.rohar@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).