Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754670AbXJIRGU (ORCPT ); Tue, 9 Oct 2007 13:06:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752776AbXJIRGI (ORCPT ); Tue, 9 Oct 2007 13:06:08 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:59901 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752773AbXJIRGG (ORCPT ); Tue, 9 Oct 2007 13:06:06 -0400 Date: Tue, 9 Oct 2007 10:06:43 -0700 From: "Darrick J. Wong" To: Andrew Vasquez Cc: James Smart , linux-scsi , linux-kernel , Alexis Bruemmer , James Bottomley Subject: Re: [PATCH] aic94xx: Use request_firmware() to provide SAS address if the adapter lacks one Message-ID: <20071009170643.GE16003@tree.beaverton.ibm.com> References: <20071008212553.GI16752@tree.beaverton.ibm.com> <20071008224832.GB11993@plap3.qlogic.org> <20071008235009.GB16003@tree.beaverton.ibm.com> <20071009001240.GA13922@plap3.qlogic.org> <470B9E50.2090205@emulex.com> <20071009164147.GB19854@plap3.qlogic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071009164147.GB19854@plap3.qlogic.org> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1664 Lines: 37 On Tue, Oct 09, 2007 at 09:41:47AM -0700, Andrew Vasquez wrote: > On Tue, 09 Oct 2007, James Smart wrote: > > > Why do you prefer request_firmware() vs something over sysfs ? > > > > Does environments like the kdump kernel also have access to data needed > > by request_firmware() ? Assuming the driver-loading parts of the kdump kernel's initrd are the same (udev, bunch of modules, firmwares, etc) as the regular kernel's initrd, this shouldn't be a problem. In the specific case of aic94xx, one needs request_firmware() and associated infrastructure to load firmware blobs into the controller in order to issue any I/O at all. > There's already much in the way of automation and infrastructure > present in supporting the request_firwmare() interfaces (perhaps not > the best of names) which can provide for a level of flexibility beyond > a basic 'soft_port_name' interface. > > Though I don't see why both can't coexist cleanly -- I take it the use > case you are considering is: software recognizes no valid WWPN > available, query via request_firmware() fails, software halts > initialization (rather than fail), and awaits the admin to poke > '0x123456.. > /sys/.../fc_host/soft_port_name', causing a ping to the > driver and continuation of initialization with requested portname? Hmm... could we use such a sysfs attribute to reassign adapter WWNs at arbitrary times? Is that even a good idea? --D - 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/