From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266287AbUHYXhm (ORCPT ); Wed, 25 Aug 2004 19:37:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266291AbUHYXhk (ORCPT ); Wed, 25 Aug 2004 19:37:40 -0400 Received: from fw.osdl.org ([65.172.181.6]:63941 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S266281AbUHYXff (ORCPT ); Wed, 25 Aug 2004 19:35:35 -0400 Date: Wed, 25 Aug 2004 16:35:27 -0700 (PDT) From: Linus Torvalds To: Benjamin Herrenschmidt cc: Hidetoshi Seto , Linux Kernel list , linux-ia64@vger.kernel.org Subject: Re: [RFC&PATCH 1/2] PCI Error Recovery (readX_check) In-Reply-To: <1093476204.2170.55.camel@gaston> Message-ID: References: <412AD123.8050605@jp.fujitsu.com> <1093417267.2170.47.camel@gaston> <1093476204.2170.55.camel@gaston> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 26 Aug 2004, Benjamin Herrenschmidt wrote: > > Yup, but then, the user have to take care that behind a single "error > checking" entity (a bridge for example), all devices have such drivers > that honor the bridge-level locking and not their own. Yes. I suspect that this all matters in places where you have pretty strict hardware controls anyway, so it's likely not a big deal. > On ppc64, I think we always have 1 bridge = 1 slot though, makes things > easier (well, provided we don't start to try playing with error coming > from slots on the g5). Yes, I'd assume that most high-end hardware (ie the kind that people have who care about these things in the first place) wants to minimize the number of shared error reporting bridges anyway. Linus