K5160

[Bjørn Mork]

Bjørn Mork <bjorn at mork.no> writes:

> The Windows driver sends a "reset function" request after the "get NTB
> parameters" request.  The Linux driver doesn't do that.  Might make a
> difference.  And it sends another "reset function" request just when
> you'd think the setup was complete, restarting it all.  Don't know why
> it does that.  Makes no sense to me.  But we could try it just for
> completeness. 

I had to reread the spec to see if there is any reasons there for us to
do this, but I still cannot see any.  Assuming the device is conforming
to spec that is, which it clearly isn't.  So we can add the reset to
replicate Windows behaviour in case some buggy firmware expects it, but
that is the only reason.

Rereading the NCM spec regarding device behaviour on "set interface" was
far more interesting. I can recommend Huawei to review the section
"7.2 Using Alternate Settings to Reset an NCM Function".  In short, the
device is supposed to reset all relevant settins to default when the
host selects altsetting 0.  And one of those defaults is:
  "reset the NTB format to NTB-16"

So there you have it.  The device should never operate in NTB-32 unless
the host/driver explicitly selected that mode.

But whatever.  If Windows selects NTB-32, then we might have to do the
same. It will complicate the driver - unnecessarily IMHO.  But I am
hoping that we can avoid configuring any vendor or devices specific
quirks for this, though.  Let's cross fingers that Huawei at least have
implemented a working "get NTB format" (required for devices supporting
NTB-32), so that we can automatically detect devices refusing to operate
in NTB-16 mode.



Bjørn