On Wed, May 10, 2000 at 03:27:40PM -0600, Pat LaVarre wrote:
> > >>> ... 05/10/00 11:00AM >>>
> >
> > > I trust the Linux stack by now has come into compliance
> > > here? The class-specific Get Max LUN response has to bless
> > > a LUN before it goes to the device in a CBW?
> >
> > We don't use Get Max LUN, mostly because it's not guaranteed to always be
> > available. CBI devices don't have it -- probing is generally considered
> > the only reliable way to go.
>
> Probing via bCBWLUN is flatly non compliant for a BBB host,
> via "6.2.2 Meaningful CBW" and the second page of "6.4 Device Error Handling".
>
> We're not questioning this claim? Or saying the text is ambiguous?
> We're just saying compliance at this level of detail just doesn't matter much?
> Or that BBB devices have established a different de facto standard?
> Or that CBI/BBB isn't a distinction worth making here?
Well, there are several responses to this:
(1) It would seem you're right... it is an invalid CBW
(2) BBB devices have generally established a de facto standard of behavior
in this case
(3) It's hard to use a feature when it really isn't guaranteed to be around
(i.e. CB or CBI devices)
> I've seen people claim that precise interoperability standards are
> more holy in Linux culture than in other development cultures
> ... that I could expect Linux to provoke less "not specified" device
> behaviours ... false claim?
Generally true. However, note that LUN probing in the history of SCSI and
USB/SCSI bridges has been a trouble spot for years, and shows no sign of
getting better. There are still SCSI devices manufacturered today which
respond to all LUNs even tho they really are a single-lun device. This is
a case where we've been burned by the standard too often, and now don't
really trust it.
> > > > I mean, if you want me to reset the device, then don't STALL,
> > > > go into indefinite NAK on all bulk endpoints.
> > >
> > > Eh???
> > >
> > > The host doesn't understand indefinite NAK until after a timeout.
> >
> > Why not?
>
> Are my words somehow painfully unclear here?
>
> NAK can't be said to be indefinite until after timeout, can it?
>
> What does "indefinite" mean?
Good question. As far as I can tell, it's as long as you want it to be.
Section 2.3.2.4 of the CBI Spec calls it "set dependent". And the
BBB spec just doesn't say how long a device can NAK for before we consider
it dead.
> > ... you shouldn't _have_ to reset a device during
> > what might be considered normal operation
>
> Agreed.
>
> Except this sounds as if we should consider non-compliant host
> behaviour to be normal operation? Am I missing something here?
Again, the driver is written to the defacto standard.
> I said this was rude when first I saw it invented by the bridge vendor.
>
> Can't tell you how pleased I am to have a chance to say "I told you so"
> to the people with whom I disagreed. I imagine they'd answer that
> they succeeded in forcing a reset to follow non-compliant host behaviour.
> I'd answer that forcing people to do things is no way to make friends,
> and we'd part still disagreeing.
Well, there is one piece of good news -- this gives me a good and easy way
to test the Bulk-only transport reset code.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Senior Engineer, QCP Inc. Work: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
