Retrieve the Caching mode page

PATCH Luben Tuikov 5 participants 8 messages Dec 8, 2010 SCSI

Share & tools

Luben Tuikov

author

2010-12-08 00:09 UTC #0 lore raw

Quoted 63 lines · Luben Tuikov

--- On Wed, 11/24/10, Luben Tuikov
<[email protected]>
Quoted 2 lines · wrote:
CBI/BBB isn't supposed to be, nor is designed to
support
Quoted 1 line
SAM-modern devices. So while REQUEST LUN /may/ work on
some
Quoted 1 line
devices which implement it in their firmware, it is
NOT a
Quoted 1 line
requirement for those devices as they are not required
to
Quoted 1 line
adhere to any SAM version. Those transport protocols
define
Quoted 1 line
a class-specific request to get the maximum LUN, and
another
Quoted 1 line
to reset the target port (instead of I_T Reset or LU
Reset).
Quoted 1 line
They also do not support SCSI Status completion of
the
Quoted 1 line
command, nor Autosense. They also do not provide TMFs.
They
Quoted 1 line
provide none of the SCSI transport protocol services
in
Quoted 1 line
support of the Execute Command procedure call. The
SCSI
Quoted 1 line
layer shouldn't be trying to guess their "SCSI
version", and
Quoted 1 line
or treat them as real SCSI devices sending REPORT
LUNs, etc.
Quoted 3 lines
commands.
Newer, modern transport protocols over USB, are part
of
Quoted 1 line
SAM, and it is devices who connect via those protocols
that
Quoted 1 line
are being disadvantaged, due to the adoption
(assumption) of
Quoted 4 lines
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
Quoted 1 line
other) or hybrid (usb-storage). In the former case,
the
Quoted 1 line
device is a SCSI device, in the latter, only basic
commands
Quoted 3 lines
should be attempted.
This isn't to say that firmware for those devices
wouldn't
Quoted 1 line
be buggy. Of course it will, and most will probably
port
Quoted 1 line
their legacy FW over to the new SPTL, but the
protocol
Quoted 1 line
requirements are there by design (i.e. there is no
longer
Quoted 1 line
Get Max Lun class-specific request, the application
client
Quoted 1 line
has to send REPORT LUNS, and FW has to answer it) and
we
Quoted 2 lines
have to accommodate that.

Quoted 7 lines

Quoted 1 line
It is in this spirit that this patch doesn't change
wire
Quoted 1 line
behavior, but simply parses data returned by a
command
Quoted 1 line
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.

Thanks,
Luben

Greg KH

2010-12-08 00:12 UTC #1 lore raw

Quoted 68 lines · Luben Tuikov

Quoted 67 lines · Luben Tuikov
--- On Wed, 11/24/10, Luben Tuikov
<[email protected]>
Quoted 2 lines · wrote:
CBI/BBB isn't supposed to be, nor is designed to
support
Quoted 1 line
SAM-modern devices. So while REQUEST LUN /may/ work on
some
Quoted 1 line
devices which implement it in their firmware, it is
NOT a
Quoted 1 line
requirement for those devices as they are not required
to
Quoted 1 line
adhere to any SAM version. Those transport protocols
define
Quoted 1 line
a class-specific request to get the maximum LUN, and
another
Quoted 1 line
to reset the target port (instead of I_T Reset or LU
Reset).
Quoted 1 line
They also do not support SCSI Status completion of
the
Quoted 1 line
command, nor Autosense. They also do not provide TMFs.
They
Quoted 1 line
provide none of the SCSI transport protocol services
in
Quoted 1 line
support of the Execute Command procedure call. The
SCSI
Quoted 1 line
layer shouldn't be trying to guess their "SCSI
version", and
Quoted 1 line
or treat them as real SCSI devices sending REPORT
LUNs, etc.
Quoted 3 lines
commands.
Newer, modern transport protocols over USB, are part
of
Quoted 1 line
SAM, and it is devices who connect via those protocols
that
Quoted 1 line
are being disadvantaged, due to the adoption
(assumption) of
Quoted 4 lines
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
Quoted 1 line
other) or hybrid (usb-storage). In the former case,
the
Quoted 1 line
device is a SCSI device, in the latter, only basic
commands
Quoted 3 lines
should be attempted.
This isn't to say that firmware for those devices
wouldn't
Quoted 1 line
be buggy. Of course it will, and most will probably
port
Quoted 1 line
their legacy FW over to the new SPTL, but the
protocol
Quoted 1 line
requirements are there by design (i.e. there is no
longer
Quoted 1 line
Get Max Lun class-specific request, the application
client
Quoted 1 line
has to send REPORT LUNS, and FW has to answer it) and
we
Quoted 3 lines
have to accommodate that.
It is in this spirit that this patch doesn't change
wire
Quoted 1 line
behavior, but simply parses data returned by a
command

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
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?

thanks,

greg k-h

James Bottomley

2010-12-08 05:05 UTC #2 lore raw

Quoted 71 lines · Greg KH

Quoted 70 lines · Luben Tuikov
Quoted 69 lines · Luben Tuikov
--- On Wed, 11/24/10, Luben Tuikov
<ltuikov-/[email protected]>
Quoted 2 lines · wrote:
CBI/BBB isn't supposed to be, nor is designed to
support
Quoted 1 line
SAM-modern devices. So while REQUEST LUN /may/ work on
some
Quoted 1 line
devices which implement it in their firmware, it is
NOT a
Quoted 1 line
requirement for those devices as they are not required
to
Quoted 1 line
adhere to any SAM version. Those transport protocols
define
Quoted 1 line
a class-specific request to get the maximum LUN, and
another
Quoted 1 line
to reset the target port (instead of I_T Reset or LU
Reset).
Quoted 1 line
They also do not support SCSI Status completion of
the
Quoted 1 line
command, nor Autosense. They also do not provide TMFs.
They
Quoted 1 line
provide none of the SCSI transport protocol services
in
Quoted 1 line
support of the Execute Command procedure call. The
SCSI
Quoted 1 line
layer shouldn't be trying to guess their "SCSI
version", and
Quoted 1 line
or treat them as real SCSI devices sending REPORT
LUNs, etc.
Quoted 3 lines
commands.
Newer, modern transport protocols over USB, are part
of
Quoted 1 line
SAM, and it is devices who connect via those protocols
that
Quoted 1 line
are being disadvantaged, due to the adoption
(assumption) of
Quoted 4 lines
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
Quoted 1 line
other) or hybrid (usb-storage). In the former case,
the
Quoted 1 line
device is a SCSI device, in the latter, only basic
commands
Quoted 3 lines
should be attempted.
This isn't to say that firmware for those devices
wouldn't
Quoted 1 line
be buggy. Of course it will, and most will probably
port
Quoted 1 line
their legacy FW over to the new SPTL, but the
protocol
Quoted 1 line
requirements are there by design (i.e. there is no
longer
Quoted 1 line
Get Max Lun class-specific request, the application
client
Quoted 1 line
has to send REPORT LUNS, and FW has to answer it) and
we
Quoted 3 lines
have to accommodate that.
It is in this spirit that this patch doesn't change
wire
Quoted 1 line
behavior, but simply parses data returned by a
command
Quoted 1 line
already supported by older protocols.

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
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.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Luben Tuikov

author

2010-12-08 08:01 UTC #3 lore raw

Quoted 114 lines · James Bottomley

Quoted 1 line · Greg KH
On Tue, Dec 07, 2010 at 04:02:26PM -0800, Luben Tuikov
Quoted 1 line · wrote:
Quoted 1 line
--- On Sun, 12/5/10, Luben Tuikov <[email protected]>
Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines
--- On Wed, 11/24/10, Luben Tuikov
<[email protected]>
Quoted 2 lines · wrote:
CBI/BBB isn't supposed to be, nor is
designed to
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
support
Quoted 1 line
SAM-modern devices. So while REQUEST
LUN /may/ work on
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
some
Quoted 1 line
devices which implement it in their
firmware, it is
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
NOT a
Quoted 1 line
requirement for those devices as they
are not required
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to
Quoted 1 line
adhere to any SAM version. Those
transport protocols
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
define
Quoted 1 line
a class-specific request to get the
maximum LUN, and
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
another
Quoted 1 line
to reset the target port (instead of
I_T Reset or LU
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Reset).
Quoted 1 line
They also do not support SCSI Status
completion of
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
command, nor Autosense. They also do
not provide TMFs.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
They
Quoted 1 line
provide none of the SCSI transport
protocol services
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
in
Quoted 1 line
support of the Execute Command
procedure call. The
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
SCSI
Quoted 1 line
layer shouldn't be trying to guess
their "SCSI
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
version", and
Quoted 1 line
or treat them as real SCSI devices
sending REPORT
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
LUNs, etc.
Quoted 3 lines
commands.
Newer, modern transport protocols over
USB, are part
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
of
Quoted 1 line
SAM, and it is devices who connect via
those protocols
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
that
Quoted 1 line
are being disadvantaged, due to the
adoption
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
(assumption) of
Quoted 3 lines
CBI/BBB well into the SCSI layer.
To this effect, the transport protocol
can tell upper
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
layers if the device is true SCSI (new
usb transports
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
or
Quoted 1 line
other) or hybrid (usb-storage). In the
former case,
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
device is a SCSI device, in the latter,
only basic
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
commands
Quoted 3 lines
should be attempted.
This isn't to say that firmware for
those devices
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
wouldn't
Quoted 1 line
be buggy. Of course it will, and most
will probably
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
port
Quoted 1 line
their legacy FW over to the new SPTL,
but the
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
protocol
Quoted 1 line
requirements are there by design (i.e.
there is no
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
longer
Quoted 1 line
Get Max Lun class-specific request, the
application
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
client
Quoted 1 line
has to send REPORT LUNS, and FW has to
answer it) and
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
we
Quoted 3 lines
have to accommodate that.
It is in this spirit that this patch
doesn't change
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
wire
Quoted 1 line
behavior, but simply parses data
returned by a
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
command
Quoted 1 line
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.
Quoted 1 line
Quoted 1 line
Will anyone pick up this patch, or should I stop
posting it every
Quoted 1 line
Quoted 1 line
week? Please let me know--it's been posted here 6
times in the last 6
Quoted 3 lines
Quoted 1 line
weeks.
James, this is all you. Any thoughts?

Quoted 9 lines

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

Alan Stern

2010-12-08 15:16 UTC #4 lore raw

In reply to James Bottomley

Quoted 4 lines · James Bottomley

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

The original reason for adding the skip_ms_page_8 flag still applies. To assume it is no longer an issue would not be safe -- there's no reason to believe that the buggy devices it was meant for have all been retired.

Quoted 2 lines

... but it's only USB
stuff, so suppose I'm OK with finding out in the field.

With USB there's often no other choice.

Alan Stern

James Bottomley

2010-12-08 15:43 UTC #5 lore raw

Quoted 12 lines · Alan Stern

Quoted 4 lines · James Bottomley
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
The original reason for adding the skip_ms_page_8 flag still applies. To assume it is no longer an issue would not be safe -- there's no reason to believe that the buggy devices it was meant for have all been retired.

Quoted 4 lines

Quoted 2 lines
... but it's only USB
stuff, so suppose I'm OK with finding out in the field.
With USB there's often no other choice.

So the translation is that there's a possibility it will crash USB devices but the only way to find out is to release it and see.

My problem is that it only takes one bug report from one failing device (which I'm sure some kind soul will dig out of the attic or wherever they threw it) for this to be a regression and then I get to revert the patch ... unless we have a working backup plan?

I think it's easy to put in and easy to revert ... we'll pick up a bit of flack if the failing device doesn't appear for some time, but I'm OK with risking that.

James

Alan Stern

2010-12-08 15:57 UTC #6 lore raw

Quoted 13 lines · James Bottomley

Quoted 12 lines · Alan Stern
Quoted 4 lines · James Bottomley
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
The original reason for adding the skip_ms_page_8 flag still applies. To assume it is no longer an issue would not be safe -- there's no reason to believe that the buggy devices it was meant for have all been retired.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
... but it's only USB
stuff, so suppose I'm OK with finding out in the field.
With USB there's often no other choice.
So the translation is that there's a possibility it will crash USB devices but the only way to find out is to release it and see.

In the strictest sense, there's always a possibility that any change will crash _some_ device somewhere. In this case I believe the probability is very low. Luben's patch does not change the commands sent to a USB device; it only changes the kernel's interpretation of the data sent back. Unless things are terribly badly broken, this won't hurt.

Quoted 8 lines

My problem is that it only takes one bug report from one failing device (which I'm sure some kind soul will dig out of the attic or wherever they threw it) for this to be a regression and then I get to revert the patch ... unless we have a working backup plan?
I think it's easy to put in and easy to revert ... we'll pick up a bit of flack if the failing device doesn't appear for some time, but I'm OK with risking that.

IMO the risk is extremely small.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Matthew Wilcox

2010-12-08 16:00 UTC #7 lore raw

Quoted 6 lines · Alan Stern

In the strictest sense, there's always a possibility that any change will crash _some_ device somewhere. In this case I believe the probability is very low. Luben's patch does not change the commands sent to a USB device; it only changes the kernel's interpretation of the data sent back. Unless things are terribly badly broken, this won't hurt.

It doesn't change the _discovery_ commands sent to the device, but (I think ...) it will change the subsequent commands sent to the device; eg we'll now send it SYNCHRONISE CACHE when we wouldn't have before. I think it's low-risk too, and am in favour of seeing this patch applied.

Signature · 4 lines

Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."