People ask how to write the CIS on a SmartMedia card using an sddr09
reader/writer.  The patch below documents the required command (but does
not add the code).

Two years ago or so I used this to fix the CIS on a card that my camera no
longer wanted to accept.  A Linux utility to do this might be useful, but
the problem always is that we do not really have a good mechanism.

How does one tell a driver that it has to do something special?  Add yet
another ioctl?

The main item in this patch is the conversion of the UHCI driver from
using the old usb.h logging macros to the new driver-model dev_xxx
macros.

There are a few other minor changes too: updated version number, author,
copyright, and maintainer information, removed some unneeded error
messages, added some line breaks, added a convenience macro for the device
pointer.

On Fri, 20 Feb 2004, Gustavo Guillermo wrote:

> Ok, I tested the patch, The camera works, just as in the old Kernel,
> Thanks, I'm including as an atachment the /proc/bus/usb/devices from
> kernel 2.4.x and 2.6.x, and the kernel log for 2.4.x, but ooops, I forgot
> to biold 2.4.x with full debug, if someone need it I will do.
>
> Please include this FIX in the Next Release.

Greg, I now feel confident that this patch should be applied.

On Thu, 19 Feb 2004, Agustin De Igartua wrote:

> Initializing USB Mass Storage driver...
> usb-storage: This device (04e6,0002,0100 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h
>    Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>scsi0 : SCSI emulation for USB Mass Storage devices

Thank you for sending this in.  Greg, here's the patch.

This adds some minor improvements to the UHCI root hub code.  The only
important change is that it handles the overcurrent indicator bits on VIA
controllers properly; they are reported using the opposite sense from
Intel controllers.



	Report the OverCurrent status bits in the /proc debugging file
	and spontaneously change the use of whitespace.

	Remove unused variable in uhci_hub_status_data().

	Report OverCurrent status for VIA controllers properly (the
	meaning of the status bit is inverted with respect to Intel
	controllers).

	Save the port status I/O address in a variable rather than
	recalculating it many times.

	Merge code for handling SetHubFeature and ClearHubFeature since
	we don't implement either one.

	Remove some unnecessary comments.

	Remove redundant min_t calculation.

This patch is from David Brownell.

UHCI root hub updates ... minor bugfixes and cleanups, improving
conformance with the USB hub specification.

 - UHCI doesn't support any kind of power switching; so modify the
   hub descriptor to stop claiming it does!  Likewise fail attempts
   to disable power on any port.

 - Intel defined both overcurrent status overcurrent-change bits, but
   the current code only knows about one.  Modify hub descriptor to
   report per-port overcurrent protection; and use both bits.

 - Modify the port status set/clear macros to know about the bits
   that must always be written as zero, and the write-to-clear bits.
   Update callers which wrote "set" instead of "clear".

 - Rewrote code returning port status; magic numbers are gone.

 - Driver can't really support 8 root hub ports; don't try.

Also moves the #define DEBUG earlier so that it can kick in any of
the various debug macros ... like pr_debug() and dev_dbg().

[USB] ehci-hcd detects microframe transaction scheduling collisions

This detects TT schedule collisions for split periodic transactions
on USB 2.0 hubs, handling both isochronous and interrupt transfers
but not supporting the "wrap around to the next frame" modes for
either transfer type.

The ISO scheduler is modified to use that support for full speed
transfers ... though nothing will yet ask it to do that.

It also tracks schedule depth, to help avoid accepting ISO URBs
which need more time than currently remains unscheduled.

[USB] ehci, rename some iso data structures

Rename some data and functions used by EHCI to manage ISO transactions,
since they currently assume only high speed transfers.  Much of the same
infrastructure will be used for full speed ISO, with split transactions.

[USB] start ehci split transaction support

Updates split ISO transaction descriptor structure, add bitmask #defines;
it's groundwork for full speed ISO support in EHCI.  Updates periodic
schedule scanning, and bandwidth calculations accordingly.

Fixes bandwidth calculation to behave when the periodic schedule has
entries of multiple types ... as will be more common as ISO support
starts to be used here.

[USB] usbtest, two more control queueing subtests

 From Alan Stern.  This adds two more "short control read" test cases,
 both padding the "expected" transfer to end-of-packet.  We need both
 hosts and devices/gadgets to behave correctly here.

[USB] usbcore avoids RNDIS configuration.

Modifies the "choose a configuration" heuristic to recognize the other
case that 2.4 handled:  RNDIS, a MSFT protocol that's sometimes used as
the first/default configuration (as specified by MSFT) on cable modems.
CDC Ethernet is vendor-neutral, and preferred (except by MSFT).

The initial version didn't catch RNDIS because it cloaks its ethernet
links as a kind of CDC ACM (modem) device.

[USB] hub driver turns on multi-TT mode

This turns on the multi-tt mode in hubs that support it; the Cypress
"TetraHub" products are appearing at retail now, complete with some
of the first Mini-B connectors I've seen shipping.

This will be important for hooking up lots of full speed isochronous
devices (audio, video, etc).

[USB] minor usb_sg_wait() cleanups

  - count urb completions correctly when there's a non-recoverable
    fault during scatterlist submission ... prevents a hang (seen
    only with already-faulty usb-storage devices).

  - don't local_irq_{save,restore}() when not needed

On 15 Feb 2004, Frank D. Cringle wrote:

> Hi,
>
> my syslog requests that I send this message.  See below regarding
> usb-storage: This device ... has an unneeded SubClass entry in unusual_devs.h

> Feb 15 00:11:16 dagger usb-storage: This device (07cf,1001,1000 S 05 P 00) has an unneeded SubClass entry in unusual_devs.h
> Feb 15 00:11:16 dagger Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>

Thank you for sending this in.

Greg, it looks like an earlier patch changed too much.  Here is the fix.
Also included in this patch:

	Moved several entries that were in the wrong positions.

	Removed an entry (0x08ca, 0x2011) that could never be used
	because the preceding entry always would take precedence.

This patch fixes up a small endian-ness bug from mid-January.

This patch (a regeneration of as185) reduces the amount of auto-sensing we
do even further.  It also zeros-out the sense buffer in those cases where
we do auto-sense and get back no error.

This patch (a regeneration of as173) saves the residue value of a command
when doing an auto-sense.

Not that it really matters much -- almost nobody looks at that value.  But
it's definately incorrect the way it is, and this fixes it.

This patch addresses a problem common among digital cameras that use the
CB transport.  Namely, too much auto-sensing confuses them; particularly
auto-sensing after INQUIRY.

I've made some traces of a Windows 2000 driver to see what it does (data
sent to Andries Brouwer for inclusion on his web site; I'll announce
when it's ready for viewing).  Basically, it almost never sends REQUEST
SENSE unless it received a STALL from the device.

That's a pretty bogus way to operate, because it means that Windows has no
way to tell when the device has finished executing a command if the
command doesn't involve an IN transfer.  Even after a lengthy WRITE,
Windows continues to transmit more commands without regard for whether or
not they will get overwritten in the device's internal buffer (and hence
not executed).  Indeed, exactly that happened with some of the commands in
one of my traces.

To be safe, we must follow every non-IN transfer with an auto-sense, but
IN transfers that don't stall can be considered to have succeeded.
That's what this patch does.  It reduces auto-sensing by a considerable
factor, probably close to half.  It also fixes the problem with INQUIRY,
since INQUIRY involves an IN data transfer.

I recall something like this had to be changed a while ago, but it looks
like it's still not right.  A STALL during either the command or data
phase of a CB[I] command should indicate a failure.

This patch is an attempt to cope with Genesys Logic's, shall we say,
creative approach to implementing the USB protocols.  Their high-speed
mass storage devices sometimes add an excess 0-length packet to the end of
a data phase transmission.  Of course we don't read that packet as part of
the data phase; we see it as a 0-length CSW message.  The real CSW follows
immediately after.  (Or sometimes a STALL follows immediately after, with
the real CSW coming after that!)

The patch checks the results of the first attempt to read the CSW.  If it
sees a normal packet (not a STALL) with length 0, it retries the read.
Reports from two users indicate that it improves the performance of their
USB-2 DVD drives.

Contrary to the UHCI specification document, in real controllers the "HC
Halted" bit in the status register cannot be cleared by writing a 1.  It
will persist for as long as the controller is halted.  Hence the bit needs
to be masked away before checking whether or not the controller initiated
an interrupt.

Without this patch, other devices sharing the same IRQ line might not get
serviced while the host controller is suspended, because the always-on
status bit would cause the UHCI driver to report that it had handled the
interrupt.

This patch is an amalgam of 9 contributions from Stephen Hemminger.  It
begins the process of straightening out the use of semaphores and locking
in the UHCI driver by removing unneeded irqsaves and irqrestores.  It
also removes an unnecessary list node and makes a couple of other small
changes.



clear_next_interrupt only called in IRQ context don't need irqsave/restore

Since uhci_finish_completion is only called from IRQ routine,
the irqsave/irqrestore is redundant and unnecessary.

UHCI transfer_result is only called from IRQ context
so irqsave/restore is unnecessary here.

uhci_finish_urb is always called from irq so
no need for irqsave/irqrestore.

uhci_add_complete only called from IRQ context

The complete_list element in the urb private data is redundant,
since it is only used when the urb is on the complete list.
And given the state transitions, an urb can't be on the complete list
and any other list (remove, or urb_list).
Therefore just use urb_list to link the complete_list

Use list_move_tail to move between remove (or urb_list) and the complete_list.

Save irq state in uhci_stop so that the irqsave/irqrestore's
in all the free_pending and remove_pending code can be eliminated.

Since uhci_stop now saves IRQ state, the free/remove pending routines
no longer need irqsave/irqrestore.

Randy, thanks for forwarding this to me.

> Johannes,
>
> When I compile base kernel 2.6.1 with PAGE_SIZE=64KB on an IA64
> platform, there is an error.
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> drivers/built-in.o(.init.text+0x168a2): In function `uhci_hcd_init':
> : undefined reference to `__you_cannot_kmalloc_that_much'
> make: *** [.tmp_vmlinux1] Error 1
>
> That's because ERRBUF_LEN (equal to PAGE_SIZE*8) is too long when
> PAGE_SIZE=64KB. Actually, there was a similar error found by Tony. See
> http://marc.theaimsgroup.com/?l=linux-ia64&m=105604765306485&w=2.
>
> Could you change the definition of ERRBUF_LEN to a fixed value? For
> example, 32*1024?
>
> Yanmin

Yanmin, I'm the new maintainer for the UHCI driver.  Yep, that's a
definite error.  This will fix it.

Also included in this patch: change some confusing references from "high
speed" to "full speed" and add proper hyphenation.

This patch evens out the distribution of interrupt transfers for the UHCI
driver.  It insures that no frame must handle interrupt queues for more
than two different periods, thus improving the bandwidth utilization.

It also simplifies the initialization code by replacing a multi-nested
"if" statement with a simple bit-operation (thanks to Eric Piel for
suggesting this approach).

This patch removes an unneeded "status" field from the UHCI driver's
URB-private data structure.  The driver had been storing the status of
completed URBs there rather than in the URBs themselves.  This not only is
wasteful of space but is also a cause of bugs, since the USB core relies
on urb->status for proper synchronization with the driver.

The patch also takes care of a number of small things that have been
bugging me for ages:

	Close a small loophole by allowing an URB to be unlinked even
	before the uhci_urb_enqueue() procedure has started.

	Remove some fossil code from back when interrupt URBs were
	automagically resubmitted.

	Giveback unlinked URBs in the order they were unlinked.

	Don't set urb->status for dequeued URBs; the core has already
	set it for us.

	Rename uhci_remove_pending_qhs to uhci_remove_pending_urbps.
	(That has _really_ bothered me!)

- swapRGB is already initialized to 0
- change "swapRGB_on == 1" to match in-source documentation
- submit urb with GFP_ATOMIC (interrupt context) - this made driver
   unusable because of "might_sleep" messages.
- group some "case"s
- release vdev on fail
- remove "kfree(0)" checking

This patch adds a couple of new PIDs for the ftdi_sio driver and
changes the name of the USB-UIRT device to avoid the "/" character,
as that appears as a directory separator in the sysfs namespace.

The line that IMHO triggers the bug is this:

"writecount += usblp->writeurb->transfer_buffer_length;"

It uses "usblp->writeurb->transfer_buffer_length" before initializing it,
assuming that it will be zero on the first run. If it is not zero, but instead
random *negative* garbage from memory, the loop will start printing endless data
from user-space data.

[USB] EHCI updates

Update periodic schedule scanning
	- fix shutdown sometimes-hangs (Bernd Porr)
	- resolve the "whole frame at once" FIXME
	- try harder to avoid rescanning
	- don't delegate interrupt qh handling to a buggy helper routine
	- describe more of the relevant iso tuning parameters

One-liners:
	- URB_NO_INTERRUPT hint affects ISO
	- show correct data toggle in sysfs debug files
	- FIXME is resolved by Linus' 20msec delay

Move ide-dma.c:__ide_dma_off() outside of #ifdef CONFIG_BLK_DEV_IDEDMA_PCI,
so it can be used for all DMA capable hosts.  Remove ide_hwif_t->ide_dma_off.

->ide_dma_count() was introduced in kernel 2.5.35 and was meant to add support
for host FIFO counters (for VDMA), but is only a wrapper for ->ide_dma_begin()
(even for siimage.c b/c SIIMAGE_VIRTUAL_DMAPIO is undefined).

Moreover it should be possible to add VDMA code directly to ->ide_dma_begin().

Use __ide_dma_{good,bad}_drive() directly and remove these wrappers.

I see only pros of removing OnStream support:
 - SCSI osst.c driver is actively maintained by Willem Riede <wrlk@riede.org>
 - there is no functionality loss (OnStream IDE drives don't support DSC)
 - ide-tape.c driver is too ugly & complicated even without OnStream support
 - long term benefits (2.7.x plans on unifying storage drivers)

From: Willem Riede <wrlk@riede.org>

From: Glenn Wurster <gwurster@scs.carleton.ca>

This fixes a small merge error in aty128fb resulting in a compile
failure.