Re: [PATCH repost 3] [SCSI] Retrieve the Caching mode page

[Luben Tuikov]

--- On Tue, 12/7/10, James Bottomley <James.Bottomley@xxxxxxx> wrote:
> Greg KH wrote:
> > On Tue, Dec 07, 2010 at 04:02:26PM -0800, Luben Tuikov
> wrote:
> > > --- On Sun, 12/5/10, Luben Tuikov <ltuikov@xxxxxxxxx>
> wrote:
> > > > --- On Wed, 11/24/10, Luben Tuikov
> > > > <ltuikov@xxxxxxxxx>
> > > > wrote:
> > > > > 
> > > > > CBI/BBB isn't supposed to be, nor is
> designed to
> > > > support
> > > > > SAM-modern devices. So while REQUEST
> LUN /may/ work on
> > > > some
> > > > > devices which implement it in their
> firmware, it is
> > > > NOT a
> > > > > requirement for those devices as they
> are not required
> > > > to
> > > > > adhere to any SAM version. Those
> transport protocols
> > > > define
> > > > > a class-specific request to get the
> maximum LUN, and
> > > > another
> > > > > to reset the target port (instead of
> I_T Reset or LU
> > > > Reset).
> > > > > They also do not support SCSI Status
> completion of
> > > > the
> > > > > command, nor Autosense. They also do
> not provide TMFs.
> > > > They
> > > > > provide none of the SCSI transport
> protocol services
> > > > in
> > > > > support of the Execute Command
> procedure call. The
> > > > SCSI
> > > > > layer shouldn't be trying to guess
> their "SCSI
> > > > version", and
> > > > > or treat them as real SCSI devices
> sending REPORT
> > > > LUNs, etc.
> > > > > commands.
> > > > > 
> > > > > Newer, modern transport protocols over
> USB, are part
> > > > of
> > > > > SAM, and it is devices who connect via
> those protocols
> > > > that
> > > > > are being disadvantaged, due to the
> adoption
> > > > (assumption) of
> > > > > CBI/BBB well into the SCSI layer.
> > > > > 
> > > > > To this effect, the transport protocol
> can tell upper
> > > > > layers if the device is true SCSI (new
> usb transports
> > > > or
> > > > > other) or hybrid (usb-storage). In the
> former case,
> > > > the
> > > > > device is a SCSI device, in the latter,
> only basic
> > > > commands
> > > > > should be attempted.
> > > > > 
> > > > > This isn't to say that firmware for
> those devices
> > > > wouldn't
> > > > > be buggy. Of course it will, and most
> will probably
> > > > port
> > > > > their legacy FW over to the new SPTL,
> but the
> > > > protocol
> > > > > requirements are there by design (i.e.
> there is no
> > > > longer
> > > > > Get Max Lun class-specific request, the
> application
> > > > client
> > > > > has to send REPORT LUNS, and FW has to
> answer it) and
> > > > we
> > > > > have to accommodate that.
> > > > > 
> > > > > It is in this spirit that this patch
> doesn't change
> > > > wire
> > > > > behavior, but simply parses data
> returned by a
> > > > command
> > > > > already supported by older protocols.
> > > > 
> > > > Did anyone pick up this patch?
> > > 
> > > It's been over 6 weeks now that this patch's been
> in these mailing lists.
> > > Will anyone pick up this patch, or should I stop
> posting it every
> > > week? Please let me know--it's been posted here 6
> times in the last 6
> > > weeks.
> > 
> > James, this is all you.  Any thoughts?
> 
> Well, not other than I've already said:  I think it
> looks OK, so I
> marked it for my merge window queue.  I'd still rather
> like USB people
> to confirm that the original reason why this was done (to
> prevent device
> crashes on the mode sense) is no longer an issue ... but
> it's only USB
> stuff, so suppose I'm OK with finding out in the field.

Check their responses above in this thread. The USB people seem to be okay with it. The thread is archived here: http://marc.info/?t=129044508400003&r=1&w=2.

   Luben

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/