Support for the Sharp LH7A404 OHCI, another non-PCI implementation.
This uses a platform_device and a workaround for a register read
problem.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Add byteswapping.  Original version partially worked on PPC with Net2280,
this version applies to the latest RNDIS code but hasn't been retested on
big-endian.  Ping should be working in at least one one direction.

Also added a handful of other things from my BK:  track suspend/resume
(to eventually implement wake-on-lan), give a better rndis error
message, and add missing declarations for PM-related OIDs (usage is
#ifdeffed out by previous patch).

    From:	   Jon Neal <jon@ballardtech.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This makes net2280 behave more correctly with respect to
usb suspend and resume processing.

So for example gadget zero autoresume testing works.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This adds hub_set_power_budget(), mostly so that HCDs for low
powered ports (cell phone, PDA, etc) can more easily report their
true power budgets.  It's not always 500mA per root hub port; this
makes dummy_hcd report the minimum, 8mA.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

into kroah.com:/home/greg/linux/BK/usb-2.6

Stop downgrade_write() from under-adjusting the rwsem counter in optimised
rw-semaphores.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into evo.osdl.org:/home/torvalds/v2.6/linux

Signed off by: Jesse Brandeburg

From: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>

Handle going-away devices.

This patch fixes an incorrect MCA check as well as a leak on probe
failure in at1700.

This patch frees the netdev on failure in mc32_probe in 3c527.

"Gee it works better if you turn the chip on before programming it"

The ioctl to ethtool change broke that little detail...


I made the changes, Jeff agreed in principle, Red Hat owns them and I know
no reason they can't be contributed under the GPL v2 or later.

Requires: ethtool change

Several ethernet drivers have been broken by the ethtool support because
the ioctl code used to power the interface up and down as needed. Rather
than add this to each driver call Jeff Garzik suggested we add hooks
for before/after ethtool processing.

This patch implements them which makes fixing the PM stuff easier,
as the epic100 patch to follow will show. It also cleans up the
via-velocity driver pm/ethtool logic a great deal. As per Jeff's
request the before handler is allowed to fail the operation.

--

The contribution herein included is a creation of Red Hat Inc. It is hereby
submitted under the license of the existing files and as a derivative work
thereof. I know of no reason for not having the right to submit the
work herein included.

(Bluff your way in legalese ;))

Adrian Bunk noticed that the tda1004x DVB frontend driver was broken and
sent a small patch that at least made the driver work again.

There was a discussion afterwards about the kernel syscall interface,
but at the end, the tda1004x DVB frontend driver is still non-functional.

This re-applies the temporary band-aid.

The paca struct contains a pointer to the current task, which is used
for the `current' macro.  For some reason, this field is a u64, and
every time we use it we need a cast, because it is really a pointer.
This patch cleans things up a little by making it a pointer to struct
task_struct and removing the casts.  It also removes a now-incorrect
comment which said that r13 contains current (it now holds
&paca[smp_processor_id()]).
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Occasionally the ppc64 kernel emulates a usermode instruction, for
example in the alignment exception handler.  Kumar Gala pointed out
(in the context of the ppc32 kernel) that if the instruction was being
single-stepped, and we end up emulating the instruction, we should
then send the process a SIGTRAP as if it had not been emulated and the
process had then taken a single-step exception.  This patch implements
this for ppc64.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into evo.osdl.org:/home/torvalds/v2.6/linux

into evo.osdl.org:/home/torvalds/v2.6/linux

into kernel.bkbits.net:/home/davem/net-2.6

This partially reverts one of the changes in an earlier patch,
starting to document where Microsoft's spec is lying.  Needed
to interop with Windows ME.


The Windows ME implementation of RNDIS relies on a message that
Microsoft's specification says isn't used.  Restore this (removed
in earlier cleanup), and start collecting comments specifically
on where MSFT violates its own specifications.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Tao Huang wrote:
> I'm writing udc driver for S3C2410. I found RNDIS almost not call my
> driver's free_request and free_buffer. So after run my driver about 3
> hours the system will out of memory.
>
> This patch will fix the memory leak.
>
> There will still have memory leak when driver unload, but I don't known
> where is the proper place to fix it.
> 1) rndis.c should free resp_queue when it unload
> 2) ether.c should free tx_reqs and rx_reqs when it unload (as
> eth_reset_config)

Thanks ... this is a nice patch to have.


From:          Tao Huang <huangt@star-net.cn>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

NDIS devices have a generic attribute get/set API where the attributes
are identified by 32 bit "OIDs".  This fixes some problems with the OIDs
supported by the original RNDIS patch:

  - It included OIDs not found in the RNDIS spec.  These have been
    removed.  As a rule, these weren't exported in the "OIDs I support"
    list, and only a couple wouldn't fail those accesses, so this mostly
    changes what debug printk appears.

  - OIDs used for optional 802.3 statistics were partially supported.
    They're all in the OID list now, but the support is #ifdeffed out.
    (Those statistics were mostly just made up, anyway!)

  - "Required" OIDs for suspend, resume, and wakeup support weren't
    listed.  Their messages are now defined, but support is #ifdeffed
    out.  Seems the docs aren't entirely accurate, and Windows can
    behave reasonably without them.  (This area needs help from someone
    who knows MS-Windows power management.)

There are also a few minor cleanups, more reasonable default volume level
for debug messages (never at KERN_INFO, keepalives only if VERBOSE), and
dumping of all bytes of some undocumented messages Windows XP has been
seen emitting shortly before the host suspended itself.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Given the problems that Dan Scholnik has reported, we should combine the
unusual_devs.h entries for the Casio QV cameras into one.  The new
NEED_OVERRIDE flag will prevent complaints about unnecessary overrides,
and Dan says the same subclass and protocol values should work for all the
cameras.  If they don't we'll hear about it soon enough!


On Tue, 1 Jun 2004, Dan Scholnik wrote:
> On Tue, 2004-06-01 at 14:14, Alan Stern wrote:
> > On Tue, 1 Jun 2004, Dan Scholnik wrote:
> >
> > > Up until the 2.6 kernels, there was one entry for all the QV cameras
> > > with both US_SC_8070 and US_PR_CB that I think seemed to work fine for
> > > everyone.  As far as I know the only problem was all the folks emailing
> > > the log entry stating that the Casio entry wasn't needed.  So, you could
> > > revert back to that, or revert back to the 2.6.3ish version (pre-as190)
> > > that had the overrides just for product IDs 1001-9009.  I'm not really
> > > an expert on Casio's cameras, I'm afraid, just the one model I own which
> > > is 4-5 years old now.
> > >
> > > I'll be happy to prepare a patch any way you choose to go.
> >
> > How does this work for you?
> >
> > Alan Stern
>
> Works fine for me; that's I think exactly how it was from the beginning
> until 2.6 and the later 2.4 kernels when all the changes were made.
> Just cross your fingers that it doesn't somehow break newer Casios, as
> it would seem every camera they ever made falls under that entry.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The hub driver is very careless about returning resources when an error
occurs while installing a new device.  This patch attempts to put some
order back into the situation.  Details:

	Since usb_new_device() allocates neither the device structure
	nor the device address, it shouldn't release either one.

	Because usb_new_device() no longer releases the device structure,
	usb_register_root_hub() doesn't need to take an extra reference
	to it.

	Since the device address selection and TT setup code is used
	only for new devices, not ones being reset, move that code from
	hub_port_init() to hub_port_connect_change().  By the same token,
	hub_port_init() doesn't have to release the device address or
	the device structure.

	Just to make things look better, move the failure code in
	hub_port_init() to the end of the routine.  And when disabling
	endpoint 0, disable both the IN and OUT parts of the endpoint.

	In hub_port_connect_change(), make all the failure paths
	execute the same code so that resources are always released.
	These resources comprise: the pointer from the parent to the
	new child device, the HCD state for ep0, the device's address,
	and the device structure itself -- in short, everything that's
	set up before calling usb_new_device().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch adds checking for the SET-FEATURE request that actually does a
port reset.  Without the check, the hub driver just assumes that the port
reset command actually was transferred okay.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

proc_resetdevice is called with dev->serialize held.
usb_reset_device takes dev->serialize and then calls
__usb_reset_device.  To avoid deadlock, proc_resetdevice
should call __usb_reset_device directly.
Signed-off-by: Duncan Sands <baldrick@free.fr>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

proc_resetdevice is called with dev->serialize held.
usb_reset_device takes dev->serialize and then calls
__usb_reset_device.  To avoid deadlock, proc_resetdevice
should call __usb_reset_device directly.
Signed-off-by: Duncan Sands <baldrick@free.fr>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Updates i386 defconfig.  I simply ran `make oldconfig' and selected `m' where
it was available, otherwise `y'.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Forgot to update the top-level makefile to invoke the new reference_init
script.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The attached patch enables the pwc driver included with kernel 2.6.7-rc2

It also removes the warnings during compilation.
However, note that I blindly duplicated the release approach used by
other usb camera drivers, replacing the current no-op.

The driver works for me with a Logitech QuickCam Notebook Pro and
GnomeMeeting.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

> Send me a patch to back those changes out to fix your device and I'll
> apply it.  If the author is around to realize this, that should wake
> them up :)

Ok, here you are! :)
Attached is a patch for linux-2.6.7-rc2. (though the patch hasn't changed
since -rc1)

Again a short description:
(the patch removes most of the changes done in linux-2.6.2)
1. Removed the local buffer of cyberjack_write, because something goes wrong
upon a write-request bigger than the buffer. Without this, a write-request
stalls with error -3.
2. Removed some usb_clear_halt() lines. Without this, the device doesn't even
open and returns -7.

It works for my cyberjack pinpad USB card reader on
- nforce2 chipset
- VIA KM266 chipset
- AMD Irongate chipset
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch fixes a simple logic error in usb_get_descriptor().  It also
takes the opportunity to make the subroutine a little easier to read.
Please apply.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The attached patch enables the pwc driver included with kernel 2.6.7-rc2

It also removes the warnings during compilation.
However, note that I blindly duplicated the release approach used by
other usb camera drivers, replacing the current no-op.

The driver works for me with a Logitech QuickCam Notebook Pro and
GnomeMeeting.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch started life from Alan Stern as as274, and has been heavily
modified.  It narrows the case where a clear_halt() is issued after a
failed GetMaxLUN command to only a STALL case.

Since the only legimate responses to a GetMaxLUN are STALL or data,
anything else is now considered a fatal error and we give up on the device.
Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

> Send me a patch to back those changes out to fix your device and I'll
> apply it.  If the author is around to realize this, that should wake
> them up :)

Ok, here you are! :)
Attached is a patch for linux-2.6.7-rc2. (though the patch hasn't changed
since -rc1)

Again a short description:
(the patch removes most of the changes done in linux-2.6.2)
1. Removed the local buffer of cyberjack_write, because something goes wrong
upon a write-request bigger than the buffer. Without this, a write-request
stalls with error -3.
2. Removed some usb_clear_halt() lines. Without this, the device doesn't even
open and returns -7.

It works for my cyberjack pinpad USB card reader on
- nforce2 chipset
- VIA KM266 chipset
- AMD Irongate chipset
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>