Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765473AbXJZRCl (ORCPT ); Fri, 26 Oct 2007 13:02:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757358AbXJZRC1 (ORCPT ); Fri, 26 Oct 2007 13:02:27 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]:26951 "EHLO wx-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765322AbXJZRCZ convert rfc822-to-8bit (ORCPT ); Fri, 26 Oct 2007 13:02:25 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Qs+/s60WyhmuoQI+73wxysaDcAjJSn4q8XsRPnbFAu97yFwpGENG9ydvfHs5ZAdrO7lJqPiAK9fo4vPxDbvCN7GquQy7hOgbDn5pTVDHGc2tpBe6G8bmw4uYjrrLqPMIpgeF1t3doKlWGx7oXhqyPkT9Gnwx9l/1UlTaLNnISY0= Message-ID: Date: Fri, 26 Oct 2007 10:02:24 -0700 From: "Dan Williams" To: "Haavard Skinnemoen" Subject: Re: [PATCH] DMA: Correct invalid assumptions in the Kconfig text Cc: "Shannon Nelson" , linux-kernel@vger.kernel.org, "David Brownell" , kernel@avr32linux.org, linux-arm-kernel@lists.arm.linux.org.uk In-Reply-To: <20071025113240.466b69ba@siona> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <1193218705-16685-1-git-send-email-hskinnemoen@atmel.com> <20071024201616.02f87b20@siona> <20071025113240.466b69ba@siona> X-Google-Sender-Auth: 8e20531ad43e63b4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1403 Lines: 42 On 10/25/07, Haavard Skinnemoen wrote: > On Wed, 24 Oct 2007 20:16:16 +0200 > Haavard Skinnemoen wrote: > > > [handwaving about API extensions] > > Oh, and we definitely need a way to report errors. Looks like the > existing drivers want this as well -- I couldn't help but notice this > in the iop-adma driver: > > static irqreturn_t iop_adma_err_handler(int irq, void *data) > { > (...) > > BUG(); > } > > That's a panic waiting to happen, isn't it? Yes, and it should have a comment, because for now this is deliberate. This was primarily driven by the fact that MD has no way of recovering from hardware errors during software-memcpy or software-xor_blocks so there was no where to plug-in accelerated-memcpy/xor error recovery. I can foresee other clients wanting to have this information reported but async_tx based clients are supposed to be blissfully unaware of under the covers hardware acceleration. One idea is to pass an error-pointer as the parameter to callback routines, but that would hamper the client's ability to recover the context of the failure... > > H?vard -- Dan - 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/