Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754009AbbGXDJe (ORCPT ); Thu, 23 Jul 2015 23:09:34 -0400 Received: from g4t3427.houston.hp.com ([15.201.208.55]:36371 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753226AbbGXDJb convert rfc822-to-8bit (ORCPT ); Thu, 23 Jul 2015 23:09:31 -0400 From: "Elliott, Robert (Server Storage)" To: Spencer Baugh , Christoph Hellwig CC: "Nicholas A. Bellinger" , "open list:TARGET SUBSYSTEM" , "open list:TARGET SUBSYSTEM" , open list , Joern Engel , Brian Bunker Subject: RE: [PATCH] target: add support for START_STOP_UNIT SCSI opcode Thread-Topic: [PATCH] target: add support for START_STOP_UNIT SCSI opcode Thread-Index: AQHQxAHE1evDkE8pXkaPjkYYeb1L2Z3ozgkAgADXjACAAEJ5cA== Date: Fri, 24 Jul 2015 03:06:12 +0000 Message-ID: <94D0CD8314A33A4D9D801C0FE68B40295AA06D79@G9W0745.americas.hpqcorp.net> References: <1437516477-30554-1-git-send-email-sbaugh@catern.com> <20150723093618.GA5382@infradead.org> <877fpqfr19.fsf@ponos.purestorage.com> In-Reply-To: <877fpqfr19.fsf@ponos.purestorage.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.192.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2820 Lines: 82 > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- > owner@vger.kernel.org] On Behalf Of Spencer Baugh > Sent: Thursday, July 23, 2015 5:28 PM > To: Christoph Hellwig ; Spencer Baugh > ... > Subject: Re: [PATCH] target: add support for START_STOP_UNIT SCSI opcode > > From: Brian Bunker > > AIX servers using VIOS servers that virtualize FC cards will have a > problem booting without support for START_STOP_UNIT. > > v2: Cite sb3r36 exactly, clean up if conditions > > Signed-off-by: Brian Bunker > Signed-off-by: Spencer Baugh ... > v2: Cite sb3r36 exactly, clean up if conditions > ... > diff --git a/drivers/target/target_core_sbc.c > b/drivers/target/target_core_sbc.c > index e318ddb..85c3c0a 100644 > --- a/drivers/target/target_core_sbc.c > +++ b/drivers/target/target_core_sbc.c > @@ -154,6 +154,38 @@ sbc_emulate_readcapacity_16(struct se_cmd *cmd) > return 0; > } > > +static sense_reason_t > +sbc_emulate_startstop(struct se_cmd *cmd) > +{ > + unsigned char *cdb = cmd->t_task_cdb; > + > + /* > + * See sb3r36 section 5.25 Global typo in this patch - sb3 should be sbc3. Editorial comment: Note that the officially published versions of the ISO and ANSI standards don't carry that revision number r36; they just have the standard name and year. SBC-3 revision 36 became "ANSI INCITS 514-2014 Information technology - SCSI Block Commands - 3 (SBC-3)". T10 isn't really obligated to keep making particular working drafts available, although the ones that have been assigned version descriptors (in SPC-n) are more likely to stick around. For SBC-3, only revisions 35 and 36 earned those. Section numbers are quite volatile, too, so you might be better off including the section name. It's starting to become standardese, but this kind of wording might be better: "See the SBC-3 START STOP UNIT command description (e.g., sbc3r36 5.25)" > + /* From SBC-3: > + * Immediate bit should be set since there is nothing to complete > + * POWER CONDITION MODIFIER 0h > + */ > + if (!(cdb[1] & 1) || (cdb[2] | cdb[3])) > + return TCM_INVALID_CDB_FIELD; Technical comment: The application client is not obligated to set the IMMED bit here. In fact, that's an unusual choice. Using the IMMED bit means the application client must handle the initial status for the command, then poll for the functional results with REQUEST SENSE and TEST UNIT READY commands, which is much more complicated. -- 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/