From patchwork Mon May 11 07:55:07 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 6373791 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8FB269F32E for ; Mon, 11 May 2015 07:55:21 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 84681202E9 for ; Mon, 11 May 2015 07:55:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0128820259 for ; Mon, 11 May 2015 07:55:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752511AbbEKHzS (ORCPT ); Mon, 11 May 2015 03:55:18 -0400 Received: from mail-by2on0093.outbound.protection.outlook.com ([207.46.100.93]:50400 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752224AbbEKHzQ (ORCPT ); Mon, 11 May 2015 03:55:16 -0400 Received: from BLUPR02CA035.namprd02.prod.outlook.com (25.160.23.153) by BN3PR0201MB1028.namprd02.prod.outlook.com (25.161.207.15) with Microsoft SMTP Server (TLS) id 15.1.154.19; Mon, 11 May 2015 07:55:13 +0000 Received: from BY2FFO11FD048.protection.gbl (2a01:111:f400:7c0c::124) by BLUPR02CA035.outlook.office365.com (2a01:111:e400:8ad::25) with Microsoft SMTP Server (TLS) id 15.1.160.19 via Frontend Transport; Mon, 11 May 2015 07:55:13 +0000 Authentication-Results: spf=pass (sender IP is 63.163.107.172) smtp.mailfrom=sandisk.com; odin.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sandisk.com designates 63.163.107.172 as permitted sender) receiver=protection.outlook.com; client-ip=63.163.107.172; helo=milsmgep11.sandisk.com; Received: from milsmgep11.sandisk.com (63.163.107.172) by BY2FFO11FD048.mail.protection.outlook.com (10.1.15.176) with Microsoft SMTP Server id 15.1.160.8 via Frontend Transport; Mon, 11 May 2015 07:55:10 +0000 Received: from MILHUBIP04.sdcorp.global.sandisk.com ( [172.22.12.162]) by milsmgep11.sandisk.com (Symantec Messaging Gateway) with SMTP id E1.46.08453.E5060555; Mon, 11 May 2015 00:55:10 -0700 (PDT) Received: from milsmgip11.sandisk.com (10.177.8.100) by MILHUBIP04.sdcorp.global.sandisk.com (10.177.9.97) with Microsoft SMTP Server id 14.3.224.2; Mon, 11 May 2015 00:55:10 -0700 X-AuditID: ac160a68-f79df6d000002105-1e-5550605e2876 Received: from [10.50.231.58] ( [10.177.8.100]) by milsmgip11.sandisk.com (Symantec Messaging Gateway) with SMTP id B1.E3.19112.C5060555; Mon, 11 May 2015 00:55:10 -0700 (PDT) Message-ID: <5550605B.904@sandisk.com> Date: Mon, 11 May 2015 09:55:07 +0200 From: Bart Van Assche User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christoph Hellwig CC: James Bottomley , "Nicholas A. Bellinger" , Hannes Reinecke , Mike Christie , "linux-scsi@vger.kernel.org" , Felipe Balbi , "Andrzej Pietrasiewicz" Subject: Re: [PATCH v4 3/5] Replace MAX_COMMAND_SIZE with BLK_MAX_CDB References: <554C6E79.7020501@sandisk.com> <554C6EFF.5000400@sandisk.com> <20150511063250.GD30323@lst.de> In-Reply-To: <20150511063250.GD30323@lst.de> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsWyRoxnkW5cQkCowZ1NshazXrazWBy8X2+x Z9EkJouVq48yWfxff5vFovv6DjaLFW+6GS3aVp9hdODwuPprFbPH/e1HmDx232xg8zj84wez R9+WVYwem09Xexy/sZ3J4/MmuQCOKC6blNSczLLUIn27BK6MT1NPshRsFq+YPWEPawPjPOEu Rk4OCQETidOTDrNC2GISF+6tZ+ti5OIQEjjBKDH3y3tGCGcHo8Tr7W2MMB1XHk+ASmxmlLjx chUbSIJXQE1iy9/NLCA2i4CqRMPNDWBxNgEjiW/vZ4LFRQXCJKb9fs4KUS8ocXLmE7C4iICS xNNXZ8EWMAusZZK49IMTxBYWcJW4P+8E2BwhgUyJNY3LmEFsTgEdiTUfV0PVG0gcWTSHFcKW l9j+dg4zxKEvWSVufhGB6FWXOLlkPtMERpFZSFbPQtI+C0n7AkbmVYxiuZk5xbnpqQWGhnrF iXkpmcXZesn5uZsYwfHGlbGDcesk80OMAhyMSjy8Bhf8Q4VYE8uKK3MPMUpwMCuJ8J4yCggV 4k1JrKxKLcqPLyrNSS0+xCjNwaIkztubqxMqJJCeWJKanZpakFoEk2Xi4JRqYBTZsfDKp08B moeyDL+dnq3hK/nux4fC657zLt4xVfHdJ+L0aKP04aicNYW3Ykv+WlkVB/aK7Hm13fZiWEPc 3tsLGxnMgoWyGlvKuDYdcevfws0i+2LnlV9LI9/KcPxVsha8tdHEOWfF8oLawi+FLprrfU2O fH9lM3FmUkvmeafNW669TV9y8r0SS3FGoqEWc1FxIgDe3cN8swIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsXCtZEjRTcuISDU4M8sAYtZL9tZLA7er7fY s2gSk8XK1UeZLP6vv81i0X19B5vFijfdjBZtq88wOnB4XP21itnj/vYjTB67bzaweRz+8YPZ o2/LKkaPzaerPY7f2M7k8XmTXABHFJdNSmpOZllqkb5dAlfGp6knWQo2i1fMnrCHtYFxnnAX IyeHhICJxJXHExghbDGJC/fWs4HYQgIbGSWufrUGsXkF1CS2/N3MAmKzCKhKNNzcAFbDJmAk 8e39TLC4qECYxLTfz1kh6gUlTs58AhYXEVCSePrqLNB8Lg5mgU1MEqc7G8CahQVcJe7POwG1 LFNiTeMyZhCbU0BHYs3H1WAHMQvoSey4/osVwpaX2P52DvMERv5ZSHbMQlI2C0nZAkbmVYxi uZk5xbnpmQWGhnrFiXkpmcXZesn5uZsYwSHPGbmD8elE80OMTBycUg2Md5ymb5vyMyngzwYm IW91H6sLYu0Tl90XmLzqKavJ++i+m3b2Z648OyX0j1P6XLTNAuVQ39Tfqu2LTwZ9K1NzMdje WrZp394c4fMvVazv3W02Dv8b+HNy29eTuzctuCR+7t8Ui5X6RQu5fzzQFwx/8q3o/vW9gtbZ LDEOpy5sTD/59dHNS8LHVJVYijMSDbWYi4oTAft/CKApAgAA X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:63.163.107.172; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(164054003)(189002)(199003)(24454002)(51704005)(479174004)(110136002)(5001960100002)(92566002)(62966003)(77156002)(77096005)(106466001)(19580405001)(19580395003)(36756003)(2950100001)(4001350100001)(189998001)(23746002)(76176999)(54356999)(33656002)(64126003)(86362001)(50986999)(65816999)(65806001)(65956001)(47776003)(46102003)(50466002)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0201MB1028; H:milsmgep11.sandisk.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB1028; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN3PR0201MB1028; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1028; X-Forefront-PRVS: 05739BA1B5 X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2015 07:55:10.7899 (UTC) X-MS-Exchange-CrossTenant-Id: fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d; Ip=[63.163.107.172]; Helo=[milsmgep11.sandisk.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1028 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 05/11/15 08:32, Christoph Hellwig wrote: > I know I suggested this, but as I have some other work to actually kill > BLK_MAX_CDB now we might want to go for the light-weight variant where > we just #define MAX_COMMAND_SIZE to BLK_MAX_CDB for now. > > Sorry for causing this additional work. Actually this makes my job easier because it allows me to drop a whole bunch of changes. Is the patch below what you had in mind ? Thanks, Bart. From: Bart Van Assche Subject: [PATCH v5] Make MAX_COMMAND_SIZE identical to BLK_MAX_CDB Since the two constants MAX_COMMAND_SIZE and BLK_MAX_CDB have the same meaning, define MAX_COMMAND_SIZE as BLK_MAX_CDB. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Nicholas Bellinger Cc: Hannes Reinecke Cc: Mike Christie Cc: Felipe Balbi Cc: Andrzej Pietrasiewicz Reviewed-by: Christoph Hellwig --- drivers/usb/gadget/function/storage_common.h | 3 --- include/scsi/scsi_cmnd.h | 17 +++-------------- 2 files changed, 3 insertions(+), 17 deletions(-) diff --git a/drivers/usb/gadget/function/storage_common.h b/drivers/usb/gadget/function/storage_common.h index 70c8914..45d3b87 100644 --- a/drivers/usb/gadget/function/storage_common.h +++ b/drivers/usb/gadget/function/storage_common.h @@ -65,9 +65,6 @@ do { \ #endif /* DUMP_MSGS */ -/* Length of a SCSI Command Data Block */ -#define MAX_COMMAND_SIZE 16 - /* SCSI Sense Key/Additional Sense Code/ASC Qualifier values */ #define SS_NO_SENSE 0 #define SS_COMMUNICATION_FAILURE 0x040800 diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h index 9fc1aec..6379d07 100644 --- a/include/scsi/scsi_cmnd.h +++ b/include/scsi/scsi_cmnd.h @@ -15,21 +15,10 @@ struct scsi_driver; #include /* - * MAX_COMMAND_SIZE is: - * The longest fixed-length SCSI CDB as per the SCSI standard. - * fixed-length means: commands that their size can be determined - * by their opcode and the CDB does not carry a length specifier, (unlike - * the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly - * true and the SCSI standard also defines extended commands and - * vendor specific commands that can be bigger than 16 bytes. The kernel - * will support these using the same infrastructure used for VARLEN CDB's. - * So in effect MAX_COMMAND_SIZE means the maximum size command scsi-ml - * supports without specifying a cmd_len by ULD's + * MAX_COMMAND_SIZE is the maximum length of a CDB that fits in struct request + * without allocating additional memory. */ -#define MAX_COMMAND_SIZE 16 -#if (MAX_COMMAND_SIZE > BLK_MAX_CDB) -# error MAX_COMMAND_SIZE can not be bigger than BLK_MAX_CDB -#endif +#define MAX_COMMAND_SIZE BLK_MAX_CDB struct scsi_data_buffer { struct sg_table table;