From: tony@atomide•com (Tony Lindgren)
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: Thu, 28 May 2015 15:24:13 -0700 [thread overview]
Message-ID: <20150528222412.GM30984@atomide.com> (raw)
In-Reply-To: <CAALWOA8Pfc_zbN9MoHwR=njPBpFU56WObYMbGv9N7ktzy+RSeQ@mail.gmail.com>
* 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
next prev parent reply other threads:[~2015-05-28 22:24 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 [this message]
2015-05-28 22:27 ` Pali Rohár
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=20150528222412.GM30984@atomide.com \
--to=tony@atomide$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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