Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758930Ab1CCWXo (ORCPT ); Thu, 3 Mar 2011 17:23:44 -0500 Received: from kroah.org ([198.145.64.141]:58093 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758263Ab1CCWXn (ORCPT ); Thu, 3 Mar 2011 17:23:43 -0500 Date: Thu, 3 Mar 2011 14:22:26 -0800 From: Greg KH To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org Subject: Re: [REVIEW] NVM Express driver Message-ID: <20110303222226.GA30966@kroah.com> References: <20110303204749.GY3663@linux.intel.com> <20110303211336.GA32645@kroah.com> <20110303214104.GZ3663@linux.intel.com> <20110303215155.GA30451@kroah.com> <20110303220735.GA3663@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110303220735.GA3663@linux.intel.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2302 Lines: 52 On Thu, Mar 03, 2011 at 05:07:35PM -0500, Matthew Wilcox wrote: > On Thu, Mar 03, 2011 at 01:51:55PM -0800, Greg KH wrote: > > Heh, no, well, submit_io should just go through the block layer and not > > be a separate ioctl, right? > > Just like with SG_IO, there are reasons to do I/Os without going through > the block layer. Ok, that makes sense. > > > There's a bit of an impedence mismatch there. Think of this as > > > being drive firmware instead of controller firmware. This isn't for > > > request_firmware() kind of uses, it's for some admin tool to come along > > > and tell the drive "Oh, here's some new firmware for you". > > > > That's fine, request_firmware will work wonderfully for that. > > How would the driver know that it should call request_firmware()? > Do it every 60 seconds in case somebody's downloaded some new firmware? Ick, no, just use the function provided that lets you create a firmware request and be notified when it is written to, request_firmware_nowait(). That is what it is there for. > > > If you look at the spec [1], you'll see there are a number of firmware > > > slots in the device, and it's up to the managability utility to decide > > > which one to replace or activate. I dno't think you want to pull all > > > that gnarly decision making code into the kernel, do you? > > > > > > [1] http://download.intel.com/standards/nvmhci/NVM_Express_1_0_Gold.pdf > > > > No, just export multiple "slots" as firmware devices ready to be filled > > in by userspace whenever it wants/needs to. The management utility can > > just dump the firmware to those sysfs files when it determines it needs > > to update the firmware, no decision making in the kernel at all. > > OK ... glad we decided to limit the number of slots. I still don't see > (in Documentation/firmware_class/README) how this works for user-initiated > firmware updates rather than kernel-initiated. I didn't even realize we had a firmware README file... Anyway, just use request_firmware_nowait(), you will be fine. thanks, greg k-h -- 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/