[In your first email on this topic you identified commit d74ffae8b8dd as being relevant to the discussion. You therefore should have CC'ed the commit's author, Yoshihiro Shimoda.] On Tue, Sep 01, 2020 at 11:49:15AM +0800, Tom Yan wrote: > The uas driver relies on the scsi driver > (https://github.com/torvalds/linux/blob/v5.8/drivers/scsi/scsi_lib.c#L1796) > for max_sector setting and clamping (except when US_FL_MAX_SECTORS_64 > or US_FL_MAX_SECTORS_240 is set, where the clamping will be > overridden): > https://github.com/torvalds/linux/blob/v5.8/drivers/usb/storage/uas.c#L816 > > They (uas and scsiglue/bot) call `blk_queue_max_hw_sectors` in > different functions btw (`uas_slave_alloc` vs `slave_configure`, > instead of `slave_alloc`, that is). I suppose we should do all the > clamping and setting in `uas_slave_configure` instead as well? The only difference is that in the slave_configure callback we know what type of device we're dealing with (the INQUIRY information is available) whereas in slave_alloc we don't. So for example, the test in usb-storage's slave_configure for TYPE_TAPE could not be made in slave_alloc. > I faintly remember I asked about it but allow me to ask again, should > we really NOT raise max_sectors to 2048 blocks for **SS UAS** drives > like we do for SS BOT drives? There's no reason for uas to use a smaller value of max_sectors than usb-storage. > > And yes, the clamping is necessary. > > As I mentioned, if the clamping is done against the max mapping size > of `bus->sysdev`, max_sectors will not be actually lowered in both > cases (XHCI_NO_64BIT_SUPPORT or not). So basically it does nothing, at > least on my devices. Allow me to confirm, is that a correct/expected > behaviour? Yes. Although your devices and system are fine, others may encounter difficulty. Alan Stern
