From patchwork Fri Aug 12 14:27:03 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Yan X-Patchwork-Id: 9277085 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6DFB5600CB for ; Fri, 12 Aug 2016 14:27:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5E90E28A2F for ; Fri, 12 Aug 2016 14:27:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 535A228A31; Fri, 12 Aug 2016 14:27:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E727828A2F for ; Fri, 12 Aug 2016 14:27:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752385AbcHLO1T (ORCPT ); Fri, 12 Aug 2016 10:27:19 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34200 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752147AbcHLO1S (ORCPT ); Fri, 12 Aug 2016 10:27:18 -0400 Received: by mail-pf0-f196.google.com with SMTP id g202so1640597pfb.1; Fri, 12 Aug 2016 07:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=e9a0+B0vD/pPzh0mhcxjPi2tjeeze7jESy17EQRLkSc=; b=A7LA7b24CqCpt4qKCZ1Idq05NfkhIQHm5BS2cc1knpVR01hDeMd/D+/KpzyfJRrHVT +VPSSoecYY67m/PvJ+zZp6c/fmEVGFnfpisGckFrD92EUcpxf7/d4EMxwFV7FDbOzk9H 3JBAiyeB9pVYKmparXM5eo12fXq8zbf8ksvmMCaNcHtg7oZSanLU9U7fUP47NBRqDJlk ImA/f4lgGoMwZemGGG6YBjiaRQ7dEo5dlmb/9apgr1krD15bq/XbYT1ger4IzJi1b1r7 Dh6C3fxmq+8Y9Qgg+aULxZycus8H+AtfgBw2hDS1xuFlPrVMaZZfNDiGVM8m0NQJSF6k G4Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=e9a0+B0vD/pPzh0mhcxjPi2tjeeze7jESy17EQRLkSc=; b=TkZd3C2ePo0VEFEE0hbaPDGDUhqKRzd8CW8qcpfRKNxyfFQYGGk1ZN0jeS4002QR5k jnyArWQFE+kjwwFfr9TI2U0IgwS9R5oIWG5xj6XYygf8JJ0XrmGSJmdZG6pIWIBoSE/M FedZO/5T1+7TvGHUPGpz/4rdncjDHJYDF+SQjvFItMiivS2PxfJqHkc8dJ8gG7zJbeDe UhbPHM9omwa8yQnW4PnOzdUBZ2Ijoug3kdOkpGJirFcHYFGsfBo8Z+4GjNFhUQqEDe0j OeMEYsDx9SLE4YPZDrQxED32bkzdoW5YSxI5J3kcCGD+nlaHGm7ovIqdzT4t61D3Y6e7 6eAA== X-Gm-Message-State: AEkoouuAPM95ypQMiOXhzkyOwsRtM9DCrTTm+nxP3DIcawMPhLbKPKMITgLfjaufPcwXnw== X-Received: by 10.98.158.78 with SMTP id s75mr27635781pfd.137.1471012037534; Fri, 12 Aug 2016 07:27:17 -0700 (PDT) Received: from localhost.localdomain ([2404:c805:e00:4700:ae22:bff:fe29:e60c]) by smtp.gmail.com with ESMTPSA id 18sm13614816pfn.33.2016.08.12.07.27.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 07:27:17 -0700 (PDT) From: tom.ty89@gmail.com X-Google-Original-From: me To: tj@kernel.org, martin.petersen@oracle.com Cc: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-block@vger.kernel.org, Tom Yan Subject: [PATCH v2 1/2] libata-scsi: use dev->max_sectors from libata-core appropriately Date: Fri, 12 Aug 2016 22:27:03 +0800 Message-Id: <60518e90d462d4cbb1c528914eac64e2fe124717.1471011949.git.tom.ty89@gmail.com> X-Mailer: git-send-email 2.9.2 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Tom Yan Currently we use dev->max_sectors to set max_hw_sectors, which is actually supposed to be a host controller limit (that get set by the host controller driver like ahci, and if not it would be the fallback SCSI_DEFAULT_MAX_SECTORS). That means we have been doing the wrong thing. Therefore, use it to set the correct request queue limit that is used to report device limit: max_dev_sectors. For disk devices, it is reported through the Maximum Transfer Length field on the Block Limits VPD to the SCSI disk driver, which will then set and make use of max_dev_sectors. Note that when max_dev_sectors is larger than max_hw_sectors, it does not have any effect. Therefore, setting dev->max_sectors to ATA_MAX_SECTORS_LBA48 will only have some effect when the host driver has set max_hw_sectors to a value that is as large as that. This should not matter for typical devices, since according to our past experience, 1024 (the current SCSI_DEFAULT_MAX_SECTORS) is a decent and safe value for max_sectors. ATA_MAX_SECTORS_LBA48 has actually appeared to be too large for some devices. For cdrom devices, there is a different story. Since a few ATAPI devices needed ATA_HORKAGE_MAX_SEC_LBA48 to work. Therefore, max_hw_sectors must be set to match with that, so that the effective max_sectors can be set to ATA_MAX_SECTORS_LBA48. Signed-off-by: Tom Yan diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 223a770..39374236 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -2639,6 +2639,11 @@ int ata_dev_configure(struct ata_device *dev) dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_1024, dev->max_sectors); + /* For disk devices, max sectors set here will only be used as + * max_dev_sectors. We should never expect max sectors horkage + * that sets the value larger than BLK_DEF_MAX_SECTORS to work + * for non-ATAPI devices. */ + if (dev->horkage & ATA_HORKAGE_MAX_SEC_LBA48) dev->max_sectors = ATA_MAX_SECTORS_LBA48; diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index be9c76c..13f518b 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1204,14 +1204,26 @@ static int ata_scsi_dev_config(struct scsi_device *sdev, if (!ata_id_has_unload(dev->id)) dev->flags |= ATA_DFLAG_NO_UNLOAD; - /* configure max sectors */ - blk_queue_max_hw_sectors(q, dev->max_sectors); - if (dev->class == ATA_DEV_ATAPI) { void *buf; sdev->sector_size = ATA_SECT_SIZE; + /* + * max_hw_sectors is supposed to be host controller limit, it is + * changed here only to make sure ATA_HORKAGE_MAX_SEC_LBA48 that + * is needed by a few ATAPI devices works. + * + * Unlike the SCSI disk driver, the SCSI cdrom (sr) driver will + * not further change max_sectors. Therefore, the value that is + * also set here is guaranteed to be the effective one. + * + * For disk devices, we should only report dev->max_sectors in + * the Maximum Transfer Length field on the Block Limits VPD + * (which CD/DVD devices are not supposed to have). + */ + blk_queue_max_hw_sectors(q, dev->max_sectors); + /* set DMA padding */ blk_queue_update_dma_pad(q, ATA_DMA_PAD_SZ - 1); @@ -2310,6 +2322,13 @@ static unsigned int ata_scsiop_inq_b0(struct ata_scsi_args *args, u8 *rbuf) put_unaligned_be16(min_io_sectors, &rbuf[6]); /* + * Maximum transfer length. + * + * This will be used by the SCSI disk driver to set max_dev_sectors. + */ + put_unaligned_be32(args->dev->max_sectors, &rbuf[8]); + + /* * Optimal unmap granularity. * * The ATA spec doesn't even know about a granularity or alignment