Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754147Ab3DLJej (ORCPT ); Fri, 12 Apr 2013 05:34:39 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:47945 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982Ab3DLJef (ORCPT ); Fri, 12 Apr 2013 05:34:35 -0400 Date: Fri, 12 Apr 2013 11:33:33 +0200 From: Johan Hovold To: Jean-Christophe PLAGNIOL-VILLARD , Nicolas Ferre Cc: rtc-linux@googlegroups.com, Andrew Victor , Alessandro Zummo , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Johan Hovold Subject: Re: [rtc-linux] Re: [PATCH v2 0/5] ARM: at91: fix hanged boot Message-ID: <20130412093333.GF21305@localhost> References: <20130311180611.GF8797@localhost> <1363025279-17615-1-git-send-email-jhovold@gmail.com> <20130411155505.GD21305@localhost> <20130411165414.GC25242@game.jcrosoft.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130411165414.GC25242@game.jcrosoft.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3890 Lines: 81 On Thu, Apr 11, 2013 at 06:54:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 17:55 Thu 11 Apr , Johan Hovold wrote: > > On Mon, Mar 11, 2013 at 07:07:54PM +0100, Johan Hovold wrote: > > > These patches fix a few severe issues affecting most AT91 SOCs where > > > boot can hang after a non-general reset, and where the only way to get > > > the system booting again is to do a general reset -- something which > > > could require physically removing any backup battery. > > > > Have you had time to look at these patches yet, Nicolas? > > > > I don't think not having decided on the path forward for DT-support for > > rtc-at91sam9 needs to be a blocker. The rtt-nodes will be needed in any > > case. > > > > I could respin the series on top of the DT-patch for rtc-at91rm9200, and > > add interrupt and status-disabled properties to the DT-nodes as well. > for this this is still a no go > > this way too much ugly I understand that you prefer fixing every bootloader. I was just making sure everyone agrees that that is the best solution. The two interrupt masks has to be cleared before the kernel enables the system interrupt; either it needs to be done by the bootloader or by the at91 arch code. The various bootloaders may not know anything about RTT or RTC, but have all made sure interrupts are disabled before executing the kernel. That is, they have fulfilled the requirement that interrupts must be disabled. So the trade-off seems to be: Either we fix this once and for all using the infrastructure already in place in the kernel (DT), or risk further (apparently) bricked systems as there are bound to be bootloaders that won't get updated. [...] > > > The problems stem from the fact that the RTC and RTT-peripherals are > > > powered by backup power (VDDBU) and are not reset on wake-up, user, > > > watchdog or software reset. Consequently, RTC and RTT-alarms and their > > > interrupts may be enabled at boot, leading to a system lock-up when an > > > interrupt arrives on the shared system-interrupt line before the > > > appropriate handler (e.g. RTC-driver) has been installed. > > > > > > The easiest way to trigger this is to simply wake up from an RTC-alarm > > > on at91sam9g45. The RTC-driver currently does not disable interrupts at > > > shutdown so even after a clean shut-down the system will always hang > > > after waking up. > > > > > > The first patch fixes this very general case of RTC-wake up after a > > > clean shutdown in the RTC-driver and is marked for stable as it is > > > perfectly straight-forward. [ Note that the other, RTT-based, AT91 > > > RTC-driver already disables its interrupts at shutdown. ] And what about this patch? If it's decided that every bootloader needs to be updated, then perhaps it's better to risk bricked systems also after a clean shutdown to enforce those updates? Should we then remove the corresponding disable of interrupts at shutdown from the rtc-at91sam9 driver by the same logic? > > > The more general problem can be triggered, for example, by doing a > > > user-reset while updating the RTC-time or if an RTC or RTT-alarm goes > > > off after a non-clean shutdown. > > > > > > To fix this I propose that arch-code should mask the relevant interrupts > > > before enabling the system interrupt at early boot, and this is what > > > the fifth patch does. To access the RTC-registers I choose to revert a > > > recent patch that moved the register definitions to drivers/rtc. > > > > > > Arguably, the relevant interrupts could also be disabled in bootloaders, > > > but I suggest fixing it in the kernel once and for all. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/