Hi Greg, Could you help pulling c749301ebee82eb5e97dec14b6ab31a4aabe37a6 into the stable branches in which 17b49bcbf8351d3dbe57204468ac34f033ed60bc has been pulled? Thanks! Regards, Tom On Sat, 27 Nov 2021 at 05:21, Tom Yan <tom.ty89@xxxxxxxxx> wrote: > > Ahh, looks like the required change to sd > (c749301ebee82eb5e97dec14b6ab31a4aabe37a6) has been added to upstream > but somehow got missed when 17b49bcbf8351d3dbe57204468ac34f033ed60bc > was pulled into stable... > > On Sat, 27 Nov 2021 at 05:11, Tom Yan <tom.ty89@xxxxxxxxx> wrote: > > > > Hi, > > > > So with 17b49bcbf8351d3dbe57204468ac34f033ed60bc (upstream), > > scsi_mode_sense now returns -EINVAL if len < 8, yet in sd, the first mode > > sense attempted by sd_read_cache_type() is done with (first_)len being > > 4, which results in the failure of the attempt. > > > > Since the commit is merged into stable, my SATA drive (that has > > volatile write cache) is assumed to be a "write through" drive after I > > upgraded from 5.15.4 to 5.15.5, as libata sets use_10_for_ms to 1. > > > > Since sd does not (get to) determine which mode sense command to use, > > should scsi_mode_sense at least accept a special value 0 (which > > first_len would be set to), which is use to refers to the minimum len > > to use for mode sense 6 and 10 respectively (i.e. 4 or 8)? > > > > Regards, > > Tom
