rate and bus traffic. As the interrupt register is read after checking
hcca_done_head, there was a small chance of dropping a done list.
Ignore OHCI_WDH interrupt bit if hcca_done_head is zero so that OHCI_WDH
is processed later.
http://mail-index.netbsd.org/tech-kern/2003/09/25/0006.html
This adds a device (atabus) between IDE controllers and wd or atapibus, to
have each ATA channel show up in the device tree. Later there will be atabus
devices in /dev, so that we can do IOCTL on them.
Each atabus has its own kernel thread, to handle operations that needs polling,
e.g. reset and others.
Device probing on each bus it defered to the atabus thread creation.
This allows to do the reset and basic device probes in parallel, which reduce
boot time on systems with several pciide controllers.
* Implement read for ulpt.
* If the device is not opened for reading, occasionally drain any
data the printer might have (but don't hammer the printer with reads).
* Lower the buffer size to one page.
The driver seems to work with more printers now.
* introduce fsetown(), fgetown(), fownsignal() - this sets/retrieves/signals
the owner of descriptor, according to appropriate sematics
of TIOCSPGRP/FIOSETOWN/SIOCSPGRP/TIOCGPGRP/FIOGETOWN/SIOCGPGRP ioctl; use
these routines instead of custom code where appropriate
* make every place handling TIOCSPGRP/TIOCGPGRP handle also FIOSETOWN/FIOGETOWN
properly, and remove the translation of FIO[SG]OWN to TIOC[SG]PGRP
in sys_ioctl() & sys_fcntl()
* also remove the socket-specific hack in sys_ioctl()/sys_fcntl() and
pass the ioctls down to soo_ioctl() as any other ioctl
change discussed on tech-kern@
* We were never calling the callback function when we got a UFI CCI(!).
* We were passing a bogus residual count on non-UFI CCIs.
* After a REQUEST SENSE, the UFI CCI may include the ASC/ASCQ from the sense
information -- don't consider this a failure.
In addition, remove a horrible hack that was causing us to drop sense
information on the floor and return empty INQUIRY responses, often in the case
where there is a UNIT ATTENTION pending during the INQUIRY. (Some drives send
the data and then fail, some don't.)
This eliminates the need for quirks for the Y-E DATA FlashBuster.
These changes work on:
umass0: SAMSUNG SFD-321U [FW 0C], rev 1.10/2.10, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus1 drive 0: <SMSC, USB FDC, 2.10> disk removable
umass0: TEAC TEAC FD-05PUB, rev 1.10/0.00, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus0 drive 0: <TEAC, FD-05PUB, 1026> disk removable
umass0: Y-E DATA FlashBuster-U, rev 1.00/3.04, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus0 drive 0: <Y-E DATA, USB-FDU, 3.04> disk removable
support it, we'll just get an ILLEGAL REQUEST and ignore it. Furthermore,
on the PQI Travel Flash at least, it works just fine without. These seem to
have been added in omnibus changes for particular devices, along with other
"quirks" that are now gone. Adios, we won't cry for you.
My Imation USB FlashGO! adapter responds to a Get Max Lun request with a
stall. With uhci, this does the expected thing. With ohci, it was returning
a "data underrun" error because we weren't setting "buffer rounding" (i.e.
USBD_SHORT_XFER_OK), and the underrun was taking priority. This happened with
both the ohci in a Mac cube and the builtin ohci on the S3C2410.
So, set USBD_SHORT_XFER_OK on the Get Max Lun. Now I get a stall reported and
umass attaches correctly.
* Mark the actual Handspring Visor as type "VISOR" and all others
"PALM4" (notably, the Sony Clie 41 changes from Visor-type to
Palm4-type).
* For Palm4-type devices, use the GET_PALM_CONNECTION_INFORMATION
query instead of the GET_CONNECTION_INFORMATION query, and interpret
the returned data structure appropriately. This permits attaching a
ucom device to newer devices such as the Tungsten T that do not
support the Visor-style query (data structure definition gleaned
from the Linux 2.4.21 visor.c).
* Crank down UVISORBUFSIZE from 1024 to 64 to avoid a problem where
the Palm device and the USB host controller deadlock. The USB host
controller is expecting an early-end-of-transmission packet with 0
data, and the Palm doesn't send one because it's already
communicated the amount of data it's going to send in a header
(which ucom/uvisor are oblivious to). This is the problem that has
been known on the pilot-link lists as the "[Free]BSD USB problem",
but not understood.
XXX It would be better for the Palm protocol to be handled entirely
in userland via ugen, since the serial protocol abstraction isn't
really adequate for the amount of structure that's here, and the
64-byte limit is just a workaround. The pilot-link tools aren't up
to the task yet, though.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
