From patchwork Fri Aug 12 11:56:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Yan X-Patchwork-Id: 9276843 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 03AE260231 for ; Fri, 12 Aug 2016 11:56:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E8825289B1 for ; Fri, 12 Aug 2016 11:56:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DD2F7289B4; Fri, 12 Aug 2016 11:56:18 +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 8C057289B1 for ; Fri, 12 Aug 2016 11:56:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752569AbcHLL4R (ORCPT ); Fri, 12 Aug 2016 07:56:17 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:33911 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752175AbcHLL4P (ORCPT ); Fri, 12 Aug 2016 07:56:15 -0400 Received: by mail-pf0-f193.google.com with SMTP id g202so1466000pfb.1; Fri, 12 Aug 2016 04:56:15 -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=+R0+/8sKcrxsojfdtJyINnjSlhUx4NF2zsjoHkvBvZ8=; b=gVKZmGtqSxde6LGXKmRUgN8RcnHcNZLGdQby4P3m2Zw+o4RxyhDdyAknhdGDTMrGv0 Pt+XHNN6mgG5v1AnFsa+0cqqn/heSdoXBgmhA25dL+j+al8UFG4c75jc60iLgZIIKok7 HqcaSoFTklJGh+wkuXnYk4IOtSPqG2fzbyMUFfNDXBosxjh+EJTeQn1HQIDMpA4sfmuS d5Zap7fFBzPfoVdX3AsA0qIDm0Ep0BAaiRv3I8v0d20S4f+y0QmQzCLhkSr7OmyT35ws OVyxcztUnRVTgSQMK/OxEAKXQs68RVncD6XeVt051jvfTH9YeCOP1/JKk1Zr1magU6K9 UW+g== 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=+R0+/8sKcrxsojfdtJyINnjSlhUx4NF2zsjoHkvBvZ8=; b=JPajZWOMLoBdy+/jEDGFVTRWxXEix2hI3NTqTAxuBoF2x5Kluj8086NbGuC5yRvurf xSDe3Ly3XHK2KCO+ni68s4zS797iuNWSR1dpM+7uStANgQpj2McXfMkTr2C/g7MDf4tW UB0LCwqus0a6RW3GDC0rlgO18KRRZvACV3lI0V2+ugfsZc4jCehJIfRToNgG4yE1AB1L V9opdI5HVAWXVLwc4rWKeUSV2aPkkHpl0KvfavkSWg068RrNqHervdmPRQvmf+O47hLZ oqQ2Yf0MH58UNJywI6NGEI2JCa2o6CkPMcFCBJsEYcpTG+hat7ZTMRhhc3hqh3DCx1K0 l67g== X-Gm-Message-State: AEkoouu4QrLreWIoUZbWGPqV1raKvNGMEWxRQmXyg10ZCZqV0ynCditSp6THZoO94LwKCA== X-Received: by 10.98.85.134 with SMTP id j128mr26670198pfb.6.1471002975069; Fri, 12 Aug 2016 04:56:15 -0700 (PDT) Received: from localhost.localdomain ([2404:c805:e00:4700:ae22:bff:fe29:e60c]) by smtp.gmail.com with ESMTPSA id l128sm12601008pfl.21.2016.08.12.04.56.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 04:56:14 -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 1/2] libata-scsi: use dev->max_sectors from libata-core appropriately Date: Fri, 12 Aug 2016 19:56:06 +0800 Message-Id: <911c68378b91bf275a4bbed5717b4639641d7029.1471002480.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. For cdrom devices, since they are not supposed to have any VPD, and neither will the SCSI cdrom (sr) driver touch any of the max sectors limits, we are hence setting the limit directly in libata-scsi. 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. Also note that ATA_HORKAGE_MAX_SEC_LBA48 is not supposed to work automatically anyway, even when max_hw_sectors is as high as 65535, since the effective max_sectors will be set by the SCSI disk driver. Signed-off-by: Tom Yan diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index be9c76c..4e2d8e7 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; + /* + * We are setting the limit here merely because CD/DVD device does not + * have Block Limits VPD. + * + * Supposedly dev->max_sectors should be left shifted by + * (ilog2(sdev->sector_size) - 9). But since ATAPI class device has a + * static logical sector size of 512 (ATA_SECT_SIZE), the shift became + * unnecessary. + */ + q->limits.max_dev_sectors = dev->max_sectors; + /* Make max_dev_sectors effective by adjusting max_sectors accordingly, + while leave max_hw_sectors, which is supposed to be host controller + limit, untouched. */ + blk_queue_max_hw_sectors(q, queue_max_hw_sectors(q)); + /* 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