Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3391214pxu; Mon, 30 Nov 2020 01:54:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJzqpu51jJFNodOKWoT7lf6UkCqTfKKaKNVKXfp7SUe+vyE8P8iBA8D56FC1Lj5URedYO8Y4 X-Received: by 2002:a17:907:3d8b:: with SMTP id he11mr19326562ejc.207.1606730082883; Mon, 30 Nov 2020 01:54:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606730082; cv=none; d=google.com; s=arc-20160816; b=Kxhj/ZMWy3t21t/xMfzaC2yvHXmueRlRJ7c1nJxQOyuygm1WoII4OyDFXRqXH76ZXd S06IwOLI25KlHaSQpDp3pvpQM2QE/GNohkouRBy2iNqwM6x1SQnv25OUaCW0lUBlejAt xRqmLsehnusoU7awBNmH8tWTfEgD6Xu3v1UK/dcnMeJvqL9uNDRSQbuc7rWwA3b7yZYn f6l/6CRt8/wqNwTQ+OO/mUJ2hPMD74h71Kd51hPzn8eLSEr0GDjldi2GXFFRiYz9Mj6Z gT5Ih3Hpx5oe2Zx9sbYH92uSzTrtTnVgnjDaeidcC/ewd0ekhLcWutCOtKMjLLXNK88Z +Ovg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=hDeO7EwYb3PJHalWL3SGE459q+xe/amBDuL37VCHP+Q=; b=mD+Y+1TF3tzAo6ZG3ZZNuqu2/rkhtwGDXlNMgC+EktRxpRymxnAqCoNolnVNwk3Pbp TPzdQR6RolmKM1l8mCcOQMEl54eT9HPi0fTllhyvmZwe791pmYjTOaNnTYImDht8E3+p VhCGz+zXmi6ss1Fr/qvlxupzWsXepSMEZpqJGHraZ3ovK8Vj6NW2BR4H41ioU2/R65xl /yPpCLRL6s7wzYHCprY5p7gcldtaoALTQTDbKbij1Xe9zBG18F8ev5LcxlkQVxwIblc5 QrNzToK3KKR0qYr+YRokKwJfpfasAQRsG8LgSolMoX4cTjklSWXa2RV+LQlh0DOouSgZ HL8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="XTtxXH/2"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r19si10147027ejz.538.2020.11.30.01.54.19; Mon, 30 Nov 2020 01:54:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="XTtxXH/2"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727099AbgK3JwU (ORCPT + 99 others); Mon, 30 Nov 2020 04:52:20 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:24659 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727272AbgK3JwU (ORCPT ); Mon, 30 Nov 2020 04:52:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606729853; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hDeO7EwYb3PJHalWL3SGE459q+xe/amBDuL37VCHP+Q=; b=XTtxXH/2YgbrBQmAruywqC0JBkX31+W4TCjvHRUJ9ftN9hoGa3JQwPLg+gSANX8bNSS7JU dpHDRvHN2AQvF80k+Uhx6DpiICogRoVNtRi3BC11uuACcVirQhfUxPdCZ8cq97YHMLE1ta jco7k3m++Fo/9iPBcAuepC/ujazSUYo= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-469-w_QJXRzMOAyW2qsb1IJ87w-1; Mon, 30 Nov 2020 04:50:51 -0500 X-MC-Unique: w_QJXRzMOAyW2qsb1IJ87w-1 Received: by mail-ed1-f69.google.com with SMTP id w24so2864053edt.11 for ; Mon, 30 Nov 2020 01:50:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hDeO7EwYb3PJHalWL3SGE459q+xe/amBDuL37VCHP+Q=; b=nKDTUpcjbAxGlrCiN/G1vX7cCEizZ3YlOqDIXmIiL8vlmn+8QUuyyvAqjpFu8+ZMAM 4pncuAINy2BBuGQ7TfJm4V0L2QO8Bfsqt27byLSkbJyfUnMKvxZeGa5m7rjkCi/WwlRH Ok41UG2Z8EUabNIzEyAmY1COEFcLOkpxq8eH+ZYX3W4K/UzHKtE3iGX2jNK732Jl3ri9 BvTfmNuyj9eXNbK424fYBKV3eYbTKBbJgJyoDkIO+8593RCeMtZxj+JrqWvrI1AU6dH/ tZP6BBqNjGUy4qaTUJ/qJ3kIS7rH4+z4BUaKEiTssxYIpslrJpx3Ys9H5zHhUhtVZ3Aj iIlg== X-Gm-Message-State: AOAM531NtAIgWEGGdxaUNJHkEzmuS4kNIGulRtex2ROqPEE9J7juFkI8 2arPf25bmauEEZBrBS7e068tA5qvEDZ2+AoDbmY042wJXhrOvCE7IicEWKbaZ12/jiqx4r0CNAj D2fOuKExsKO2i4YKanZEa972r X-Received: by 2002:a17:906:7118:: with SMTP id x24mr9059516ejj.333.1606729849833; Mon, 30 Nov 2020 01:50:49 -0800 (PST) X-Received: by 2002:a17:906:7118:: with SMTP id x24mr9059506ejj.333.1606729849647; Mon, 30 Nov 2020 01:50:49 -0800 (PST) Received: from x1.localdomain (2001-1c00-0c0c-fe00-d2ea-f29d-118b-24dc.cable.dynamic.v6.ziggo.nl. [2001:1c00:c0c:fe00:d2ea:f29d:118b:24dc]) by smtp.gmail.com with ESMTPSA id b15sm8816140edv.85.2020.11.30.01.50.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Nov 2020 01:50:48 -0800 (PST) Subject: Re: [PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host() To: Tom Yan , hch@lst.de, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org Cc: mathias.nyman@intel.com, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, baolu.lu@linux.intel.com References: <09992cec-65e4-2757-aae6-8fb02a42f961@redhat.com> <20201128154849.3193-1-tom.ty89@gmail.com> <20201128154849.3193-2-tom.ty89@gmail.com> From: Hans de Goede Message-ID: <5e62c383-22ea-6df6-5acc-5e9f381d4632@redhat.com> Date: Mon, 30 Nov 2020 10:50:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201128154849.3193-2-tom.ty89@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 11/28/20 4:48 PM, Tom Yan wrote: > While the change only seemed to have caused issue on uas drives, we > probably want to avoid it in the usb-storage driver as well, until > we are sure it is the right thing to do. > > Signed-off-by: Tom Yan This seems to do a whole lot more then just dropping back from scsi_add_host_with_dma() to scsi_add_host(). This has way more lines then the orginal commit. IMHO it would be best to just revert commit 0154012f8018bba4d9971d1007c12ffd48539ddb and then submit these changes as a separate patch (which would be 5.11 material then). That separate patch could then also have a proper commit message explaining the other changes you are making, which is also not unimportant. Regards, Hans > --- > drivers/usb/storage/scsiglue.c | 40 +++++++++++++++++----------------- > drivers/usb/storage/usb.c | 3 +-- > 2 files changed, 21 insertions(+), 22 deletions(-) > > diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c > index 560efd1479ba..6539bae1c188 100644 > --- a/drivers/usb/storage/scsiglue.c > +++ b/drivers/usb/storage/scsiglue.c > @@ -92,7 +92,7 @@ static int slave_alloc (struct scsi_device *sdev) > static int slave_configure(struct scsi_device *sdev) > { > struct us_data *us = host_to_us(sdev->host); > - struct device *dev = sdev->host->dma_dev; > + struct device *dev = us->pusb_dev->bus->sysdev; > > /* > * Many devices have trouble transferring more than 32KB at a time, > @@ -120,6 +120,25 @@ static int slave_configure(struct scsi_device *sdev) > * better throughput on most devices. > */ > blk_queue_max_hw_sectors(sdev->request_queue, 2048); > + } else { > + /* > + * Limit the total size of a transfer to 120 KB. > + * > + * Some devices are known to choke with anything larger. It seems like > + * the problem stems from the fact that original IDE controllers had > + * only an 8-bit register to hold the number of sectors in one transfer > + * and even those couldn't handle a full 256 sectors. > + * > + * Because we want to make sure we interoperate with as many devices as > + * possible, we will maintain a 240 sector transfer size limit for USB > + * Mass Storage devices. > + * > + * Tests show that other operating have similar limits with Microsoft > + * Windows 7 limiting transfers to 128 sectors for both USB2 and USB3 > + * and Apple Mac OS X 10.11 limiting transfers to 256 sectors for USB2 > + * and 2048 for USB3 devices. > + */ > + blk_queue_max_hw_sectors(sdev->request_queue, 240); > } > > /* > @@ -627,25 +646,6 @@ static const struct scsi_host_template usb_stor_host_template = { > .sg_tablesize = SG_MAX_SEGMENTS, > > > - /* > - * Limit the total size of a transfer to 120 KB. > - * > - * Some devices are known to choke with anything larger. It seems like > - * the problem stems from the fact that original IDE controllers had > - * only an 8-bit register to hold the number of sectors in one transfer > - * and even those couldn't handle a full 256 sectors. > - * > - * Because we want to make sure we interoperate with as many devices as > - * possible, we will maintain a 240 sector transfer size limit for USB > - * Mass Storage devices. > - * > - * Tests show that other operating have similar limits with Microsoft > - * Windows 7 limiting transfers to 128 sectors for both USB2 and USB3 > - * and Apple Mac OS X 10.11 limiting transfers to 256 sectors for USB2 > - * and 2048 for USB3 devices. > - */ > - .max_sectors = 240, > - > /* emulated HBA */ > .emulated = 1, > > diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c > index c2ef367cf257..f177da4ff1bc 100644 > --- a/drivers/usb/storage/usb.c > +++ b/drivers/usb/storage/usb.c > @@ -1050,8 +1050,7 @@ int usb_stor_probe2(struct us_data *us) > usb_autopm_get_interface_no_resume(us->pusb_intf); > snprintf(us->scsi_name, sizeof(us->scsi_name), "usb-storage %s", > dev_name(dev)); > - result = scsi_add_host_with_dma(us_to_host(us), dev, > - us->pusb_dev->bus->sysdev); > + result = scsi_add_host(us_to_host(us), dev); > if (result) { > dev_warn(dev, > "Unable to add the scsi host\n"); >