From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161016AbbE2Pun (ORCPT ); Fri, 29 May 2015 11:50:43 -0400 Received: from muru.com ([72.249.23.125]:54635 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbbE2Pud (ORCPT ); Fri, 29 May 2015 11:50:33 -0400 Date: Fri, 29 May 2015 08:50:31 -0700 From: Tony Lindgren To: Matthijs van Duin Cc: Pali =?utf-8?B?Um9ow6Fy?= , "linux-arm-kernel@lists.infradead.org" , Sebastian Reichel , linux-omap , Aaro Koskinen , Pavel Machek , lkml , Nishanth Menon Subject: Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot) Message-ID: <20150529155030.GO30984@atomide.com> References: <201502111339.54480@pali> <201502112128.44852@pali> <20150528073740.GD16509@pali> <20150528160113.GH30984@atomide.com> <20150528222412.GM30984@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Matthijs van Duin [150528 18:37]: > On 29 May 2015 at 02:58, Matthijs van Duin wrote: > > It is only guaranteed to happen immediately (before the next > > instruction is executed) if the error occurs before the posting-point > > of the write. However, in that case the error is reported in-band to > > the cpu, resulting in a (synchronous) bus error which takes precedence > > over the out-of-band error irq (if any is signalled). > > OK, all this was actually assuming linux uses device-type mappings for > device mappings, which was also the impression I got from > build_mem_type_table() in arch/arm/mm/mmu.c (although it's a bit of a > maze). A quick test however seems to imply otherwise: > > ~# ./bogus-dev-write > Bus error > > So... linux actually uses strongly-ordered mappings? I really didn't > expect that, given the performance implications (especially on a > strictly in-order cpu like the Cortex-A8 which will really just sit > there picking its nose until the write completes) and I think I recall > having seen an OCP barrier being used somewhere in driver code... I believe some TI kernels use strongly-ordered mappings, mainline kernel does not. Which kernel version are you using? > Well, in that case everything I said is technically still true, except > the posting point is the peripheral itself. That also means the > interconnect error reporting mechanism is not really useful for > probing since you'll get a bus error before any error irq is > delivered. Hmm if that's the case then yes we can't use the error irq. However, what I've seen so far is that we only get the bus error if the l3_* drivers are configured. I guess some more testing is needed. > So I'd say you're back at having to trap that bus error using the > exception handling mechanism, which I still suspect shouldn't be hard > to do. And in that case it makes sense to do that in the bootloader to avoid adding any custom early boot code to Linux kernel. > Or perhaps you could probe the device using a DMA access and combine > that with the interconnect error reporting irq... ;-) Heh too many dependencies :) Tony