[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. 

From: James Morris <jmorris@redhat.com>

The patch below fixes an error handling flaw, where we need to return a
Netfilter verdict from the function rather than a standard error code.

From: James Morris <jmorris@redhat.com>

The avc_init function is only called during kernel init, so it can be
marked with __init.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch changes the mode bits on the selinuxfs enforce node so that
non-root processes can read it.  This is necessary to allow non-root
userspace policy enforcers to check the enforcing flag upon a permission
failure as well.  A process must still have the appropriate SELinux
permission in order to read the node.

From: James Morris <jmorris@redhat.com>

devfs is passing an empty string to do_mount when it expects a page.

From: James Morris <jmorris@redhat.com>

This patch implements context mount support within SELinux.

Three new mount options are provided:

context=%s
  Label the entire filesystem with the specified security context during
  mount and change the labeling behavior to 'mountpoint labeling'.  The
  /proc/self/attr/fscreate attribute will be ignored for file creation on
  the filesystem, although policy-specified transitions will still work
  normally.  This also sets the aggregate filesystem security context.

fscontext=%s
  Set the label of the aggregate filesystem to the specified security
  context, so that SELinux policy controls over the filesystem itself may
  be reinstated.  Only works for filesystems without EA labeling support,
  and is not valid if 'context' has been specified.

defcontext=%s
  Set the default security context for files created in this filesystem to
  the specified security context (as opposed to the current global default).
  Only works for filesystems without EA labeling support, and is not
  valid if 'context' has been specified.

To set the context or fscontext options, the security policy must specify
appropriate permissions for the filesystem relabelfrom and filesystem
relabelto controls.  For the defcontext option, the filesystem relablefrom
and filesystem assoicate controls are invoked.

The security mount options are parsed out and stripped from the normal
mount option data so that no normal filesystems need to be aware of them.

Filesystems with binary mount option data (e.g. NFS, SMBFS, AFS, Coda)
need to be handled as special cases: only NFS is supprted at this stage
per the previous patch.

From: James Morris <jmorris@redhat.com>

This patch modifies the kernel's NFS mount data structure to include SELinux
context mount data.  It allows NFS fileystems to be labeled on a
per-mountpoint basis, and should not affect existing versions of userspace
mount.

(A patch to the userspace mount code is available at
http://people.redhat.com/jmorris/selinux/context_mounts/)

From: James Morris <jmorris@redhat.com>

This series of patches adds support for SELinux 'context mounts', which
allows filesystems to be assigned security context information at mount time.
 For example, some filesystems do not support extended attributes (e.g.  NFS,
vfat), and this feature allows security contexts to be assigned to them on a
per-mountpoint basis.  It is also useful when the existing labeling on a
filesystem is untrusted or unwanted for some reason (e.g.  removable media),
and needs to be overridden with a safe default.

The first patch below consists of infrastructure changes to the kernel:

- A new LSM hook has been added, sb_copy_data, which allows the security
  module to copy security-specific mount data once the superblock has been
  setup by the filesystem.

- The sb_kern_mount hook has been modified to take this security data as a
  parameter, and would typically be used at that point to configure the
  security parameters of the filesystem being mounted.

- Allocation and freeing of the security data has been implemented in the
  core fs code as it is cleaner than trying to do it purely via LSM hooks,
  and should make maintenance easier.  This code will be compiled away if LSM
  is not enabled.

This fixes pSeries LPAR (logical partitioned) machines.  We weren't
initialising the pci_dma_ops stuff.

This updates the PowerMac-only platinumfb driver to use the new mac-io
device infrastructure.  It also switch allocation to the new
framebuffer_alloc/release and fix a couple of bugs.

This adds a limit on how much of the framebuffer is ioremap'ed by
radeonfb, thus enabling it to work with 128Mb VRAM or more on an x86
with 900Mb of lowmem in the linear mapping.

It also adds a significant amount of debug messages and adds a CONFIG
option to enable the debugging output, that should help with diagnosing
new problems. Among others, it dumps the connector info as I understand
them (so far, they give "strange" informations on laptops, I need more
data on more various laptops to see if there's a pattern I can really use
to figure out on which connector the LVDS is)

Regarding the "lid closed at boot", ultimately, we may want to default
to the VGA output in those cases, though I'm not sure what logic to use
here. Maybe we could standardize some way for the platform to provide
this "environment" information to the driver, but i wouldn't rely on it.

More reliably, if we can find out that there is an LVDS output, and
LVDS is disabled, just ignore the flat panel...

We could assume any mobility chip has LVDS, which is true, but that would
still cause a problem for laptops with an additional DVI output (only
Macs so far afaik).