[ 3.5.y.z extended stable ] Patch "libata: Use integer return value for atapi_command_packet_set" has been added to staging queue

Luis Henriques luis.henriques at canonical.com
Thu Apr 11 09:09:13 UTC 2013

This is a note to let you know that I have just added a patch titled

    libata: Use integer return value for atapi_command_packet_set

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:


If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see



>From eb0289d567d6240398d866badb148c330e9f00b6 Mon Sep 17 00:00:00 2001
From: Shan Hai <shan.hai at windriver.com>
Date: Mon, 18 Mar 2013 10:30:43 +0800
Subject: [PATCH] libata: Use integer return value for atapi_command_packet_set

commit d8668fcb0b257d9fdcfbe5c172a99b8d85e1cd82 upstream.

The function returns type of ATAPI drives so it should return integer value.
The commit 4dce8ba94c7 (libata: Use 'bool' return value for ata_id_XXX) since
v2.6.39 changed the type of return value from int to bool, the change would
cause all of the ATAPI class drives to be treated as TYPE_TAPE and the
max_sectors of the drives to be set to 65535 because of the commit
f8d8e5799b7(libata: increase 128 KB / cmd limit for ATAPI tape drives), for the
function would return true for all ATAPI class drives and the TYPE_TAPE is
defined as 0x01.

Signed-off-by: Shan Hai <shan.hai at windriver.com>
Signed-off-by: Jeff Garzik <jgarzik at redhat.com>
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
 include/linux/ata.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/ata.h b/include/linux/ata.h
index 32df2b6..5856c9e 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -937,7 +937,7 @@ static inline int atapi_cdb_len(const u16 *dev_id)

-static inline bool atapi_command_packet_set(const u16 *dev_id)
+static inline int atapi_command_packet_set(const u16 *dev_id)
 	return (dev_id[ATA_ID_CONFIG] >> 8) & 0x1f;

More information about the kernel-team mailing list