Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3514519pxu; Mon, 30 Nov 2020 05:01:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJw+MB4I5L5/MKqEetwdBj9SmxxN26VdoASY2hECw/tU6ariadJfSgUtfwJXS3OcRmCKm1xU X-Received: by 2002:a17:906:f0c3:: with SMTP id dk3mr20395085ejb.366.1606741296384; Mon, 30 Nov 2020 05:01:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606741296; cv=none; d=google.com; s=arc-20160816; b=tCwhdqaAUI6FQ3BU+sPsC8yux8FKyjRpe2os+PSzbruBtKlbKJxGqqC9iaGc5FqkhE tOxjUzzgEzDdGp8MyUXYbzf6uGVb2WN54iRn4FyC5CbNfxQW4GORtgmF8dFc0q58gpFv tJGr/b8aZi3IvaFdEK3k6KA3BR/RSLDr4uT89wzU8RqZqdE96WLWwKPsiuTlsFoW84dT M5baQAZTMOm+VYFEv8Xj9BO/ffB/td3eZ9nOHApDHYbY1BTjmBtvBRUaHtS+96nWdUWc yXOqRKDwgwrgEKfk+dQsimw8IESQMJ/2KksQWIXExR+KEujRc9zMxOchHYvEEv3w9q0W mddw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Vg3n+IuU9ZcsoQzQk8Ka2pVBr6m3bE+iD+eMp/f0Hxc=; b=fjXjEJlmBDbomPJkij3EaNv6AxdCMNdU9R42i0kZGXpunk0ixblYqPicwZ2QesdCpY qDgTUVI47F5e6MObOmVOCCxh04257sV051wLwgsZraJpgEP4UuecAU9T3Ul9qVJV8RS+ LNnS+qeOts1PqCdfBjWwaUR+lZ3UA/Gx8WRNWKosv1ceTMrpV2eOSYgXcbW5UdyVgcDP 4Y9vZQtw2lkcx4gUAnkFmezFd5exGJF1MYSg9PFCjP46nmo7u8N9b7CIBULDOwwSZexb lj6rspm08K/NXnkctuo+wOL6yB2Im8qZsZc47T3aVaXPoJWczKG7t1xGWq9BfyAiR68c RSbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Alnzhb53; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u11si10204909eja.365.2020.11.30.05.01.10; Mon, 30 Nov 2020 05:01:36 -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=@gmail.com header.s=20161025 header.b=Alnzhb53; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726103AbgK3M7l (ORCPT + 99 others); Mon, 30 Nov 2020 07:59:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725870AbgK3M7k (ORCPT ); Mon, 30 Nov 2020 07:59:40 -0500 Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C7C7C0613D2; Mon, 30 Nov 2020 04:59:00 -0800 (PST) Received: by mail-oi1-x244.google.com with SMTP id k26so14047273oiw.0; Mon, 30 Nov 2020 04:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vg3n+IuU9ZcsoQzQk8Ka2pVBr6m3bE+iD+eMp/f0Hxc=; b=Alnzhb53QFrmqVeWrFNGe8xNSkczZlMYgnBL/68PDBtKDAzwKfcN/xKeYozvQiw5IX cC33RXYBPpm+47zktxK3ld5msXcyZ5a6YLzAYwi+MVvlwOyGkgm1nrJav0x9D/dUn+oh 3zdt/22zqVEZr3hzjcRhgQnG7iDsuUlm68mIPoffOvOqAOp7HaJRrj/5EZRpURRx1jR/ dzG2623f+QgI0kNsK59gcZfxzhjY1cdPo/YqPo4eefxpLvt8+8a9CufPmBpH6KRiqi8t vMjVzvOg78YnpKzr01ozVMKpV787LCmtkFBlc+bK9zSP9YiDJQePls55Fk778X3QyMdy Y7Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vg3n+IuU9ZcsoQzQk8Ka2pVBr6m3bE+iD+eMp/f0Hxc=; b=tODq2lCP0AdUN4ujRqCAP2CWv/788ueKtAgFp7QxkOBNy3331JePg+XxBLf97X2UyF Pq5UsNY3ElrA9kIUn7R3Ov3ralji93w3z6PXi2aldBfVaTgGTJdIeS46M6nP3UynLwyp h2S7obd2RLR5xV1YX+u9JG7d5ObGbK6XEYiMy5cyD2GcaoLMp19fIHOvRf3P8qy37Ye+ Ij/RCytzZ1INrAREPkr8npe14qHvG2IrlXZ7aN7aByfUFLEfhphUWlf/+YXeiilAD/Gx lq48R+ci7n7SzUEj0MAhuZ5WDkamolWggWaDgppTLvhRaO7jNJvAB2fzA+vO9RT3brqx UrfQ== X-Gm-Message-State: AOAM533+6sfhQm4LTMTSE8IWx0VKzeG4OqJkOkGG91NWnWL1edY3YJHA JKFIdyVYGZ6r3B5HgBzuLYwsiFubsiRIkzEEqVTrHwJDzhc= X-Received: by 2002:aca:4847:: with SMTP id v68mr9342704oia.164.1606741139454; Mon, 30 Nov 2020 04:58:59 -0800 (PST) MIME-Version: 1.0 References: <09992cec-65e4-2757-aae6-8fb02a42f961@redhat.com> <20201128154849.3193-1-tom.ty89@gmail.com> <20201128154849.3193-2-tom.ty89@gmail.com> <5e62c383-22ea-6df6-5acc-5e9f381d4632@redhat.com> In-Reply-To: <5e62c383-22ea-6df6-5acc-5e9f381d4632@redhat.com> From: Tom Yan Date: Mon, 30 Nov 2020 20:58:37 +0800 Message-ID: Subject: Re: [PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host() To: Hans de Goede Cc: Christoph Hellwig , Greg KH , linux-usb , Mathias Nyman , Linux Kernel Mailing List , linux-pci@vger.kernel.org, Lu Baolu Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It's merely a moving of comment moving for/and a no-behavioral-change adaptation for the reversion. Similar has been done in the equivalent patch for the UAS driver (and the reason is stated there). On Mon, 30 Nov 2020 at 17:50, Hans de Goede wrote: > > 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"); > > >