On Sun, Jun 22, 2003 at 12:49:17PM -0700, Matthew Dharm wrote:
> On Sun, Jun 22, 2003 at 08:58:00AM -0500, James Bottomley wrote:
> > On Sat, 2003-06-21 at 23:24, Matthew Dharm wrote:
> > > On Sat, Jun 21, 2003 at 09:54:46PM -0500, James Bottomley wrote:
> > > >         }
> > > > -       n = buffer[3] + 4;
> > > > +       n = rc;
> > > >         cd->cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176;
> > > 
> > > This bit isn't right.  n is supposed to point to the start of the page
> > > data, not the page header.  The header is a different size if the command
> > > is 6-byte or 10-byte.
> > 
> > Yes it is.
> > 
> > That's why I eliminated the dbd bit.  Your patch was calculating the
> > offsets past the dbd headers.  However, if you tell the mode sense not
> > to send any dbd headers (which are pointless, because the routine isn't
> > interested in them), then you don't have to skip past them. and the mode
> > data begins just past the mode header.
> 
> But (as I read it -- remember I'm not an expert), the old sr.c code didn't
> set the DBD bit, just like the new code.  So whatever formula applied to
> the old code should apply to the new code, yes?

Okay, according to my copy of the SCSI-2 spec:

 A disable block descriptors (DBD) bit of zero indicates that the target
 may return zero or more block descriptors in the returned MODE SENSE data
 (see 8.3.3), at the target's discretion. A DBD bit of one specifies that
 the target shall not return any block descriptors in the returned MODE
 SENSE data.

The code James sent sets DBD to 0 -- I like that, as many usb-storage
devices choke when DBD is set to 1.  I believe in avoiding the DBD bit as
much as possible, and James seems to have eliminated it.

However, DBD==0 means that a block descriptor is likely to be returned --
so we need to add in the size of the block descriptor header.

Matt

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

Hi.  I have my back hairs caught in my computer fan.
                                        -- Customer
User Friendly, 8/20/1998

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to