From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id D51E9DDE26 for ; Sun, 17 Feb 2008 21:22:52 +1100 (EST) Subject: Re: Could the DTS experts look at this? From: David Woodhouse To: Scott Wood In-Reply-To: <47B1EF39.5000703@freescale.com> References: <47ACE630.8090101@pikatech.com> <20080211001451.GA11572@localhost.localdomain> <47AFB593.30805@pikatech.com> <20080211031110.GD11572@localhost.localdomain> <47AFC5E3.20101@pikatech.com> <20080211235958.GD18348@localhost.localdomain> <47B0F142.40206@pikatech.com> <20080212002030.GE18348@localhost.localdomain> <47B0EB23.9040101@pikatech.com> <20080212185251.GB4042@loki.buserror.net> <47B1EF39.5000703@freescale.com> Content-Type: text/plain Date: Sun, 17 Feb 2008 10:22:41 +0000 Message-Id: <1203243761.31173.170.camel@pmac.infradead.org> Mime-Version: 1.0 Cc: LinuxPPC-dev , Sean MacLennan List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2008-02-12 at 13:10 -0600, Scott Wood wrote: > Hmm? All I meant was that it'd be nice if there were an option in the > Linux mtd code to disable the "look for another chip and cause a machine > check if it isn't there" functionality. It was an aside from the > dts-variant issue. Yeah, maybe -- although the probe code is hairy enough already; I'm not massively keen on adding to it. Or even looking at it hard, if the truth be told. Alternatively, perhaps we should catch the machine check and recover (like we do for failing I/O accesses on ppc32). -- dwmw2