If the device is unidirectional, just ignore parameters in the other direction.
(XXX We need a better way of dealing with this.)
Only set curaltidx if we're setting usemode.
This makes both the Altec Lansing speaker set and the Telex bidirectional frob
work again.
* Only match an alternate which is in the same direction.
* Use 16-bit ulaw and alaw conversions for output, if possible.
* Store the interface handle in the `alternate' table, so we use the right
interface when creating pipes for devices with both play and record.
Record doesn't seem to actually return any data from the Telex frob, but at
least it doesn't crash or return EIO now.
XXXXXXXX
This is a big f*cking hack. Play and record need to be separated completely
if this code is ever going to even pretend to support full duplex.
PUC_PORT_TYPE_COM, use it to store the clock frequency (with 8 lower bits
to 0, used for real flags if needed).
Update all descriptions to set flags to 0 for LPT or COM_FREQ for COM.
Add support for the VScom PCI-800H 8 port serial adapter (which uses
a 14.7456 Mhz crystal instead of the standart 1.8432Mhz :)
XXX now that we can pass other frequency than COM_FREQ, the VScom PCI-800
entry could probably be updated to DTRT - does anyone have one ?
the EZ-USB chip. After downloading the firmware the device detaches
and then reattaches as a composite device (audio + HID).
XXX For now there is no firmware committed since the vendor (Silicon
XXX Portals) has not yet agreed that we can redistribute their firmware.
at tcds in files.alpha for now, and add a new `xasc at tcds' to files.pmax.
after pmax has moved fully to MI scsi (and `asc' is MI scsi), we should move
the device asc, etc., lines to files.tc.
It's probably not really a compiler bug- somebody pointed out
that it was the kernel making strings readonly. But I do think it's
a bug. The actual code was really more like:
char *revname;
...
revname = "2X00";
...
revname[1] = '2'; <<<<<<<<< BOOOM
The variable revname is not a const. If I had said
const char *revname = "2X00"
...
revname[1] = '2';
that would indeed be breaking const rules.
char *foo = "XXXX";
...
foo[1] = 'Y';
blow up (in the kernel) with the 2nd assignment. Work around it here-
it's probably just as well- I was spending more in cpu instructions doing
the assignment than I was saving in string space (it would have been
cheap on a pdp11 or a 68k- but the address loads and assignments on something
like sparc or alpha way outweigh the savings in space. Tsk.).