This adds standard gadget_is_*() calls.  Gadget drivers using
those calls can get rid of some inlined #ifdefs, and will also
be able to do more "late binding" to their hardware.


Define gadget_is_*() calls, to help do late binding to USB controllers.

Current gadget drivers expect to know at compile time what hardware
they'll bind to.  That's not very friendly to a generic PDA distro,
which might prefer to defer such choices to run time.

These macros let drivers change that code from inlined #ifdefs (ugh) to
normal C statements (looks much nicer), so making those "what hardware"
policy choices at run time gets easier.

Paulo Marques wrote:

> David Woodhouse wrote:
>
>> On Thu, 2004-03-04 at 12:33 +0000, Paulo Marques wrote:
>>
>>> Yes, unfortunately it did went into 2.6.4-rc1. However it is already
>>> corrected in 2.6.4-rc2. Luckily it didn't went into any "non-rc"
>>> official release.

> >>> Please try 2.6.4-rc2, and check to see if the bug went away...

>>
>> Seems to work; thanks. Does this need backporting to 2.4 too?
>>
>
>
> Unfortunately this isn't over yet.
>
> I got suspicious about this bug fix, because I *did* test my patch
> before submitting it and the kernel that didn't work before, worked fine
> with my patch.
>
> But now it seems that it is the other way around. After a few digging I
> found out the problem:
>
> The application that I was testing with uses the usblp handle with
> non-blocking I/O .
>
> So my patch does work for non-blocking I/O uses of the port, but wrecks
> the normal blocking mode.
>
> I've already produced a version that works for both cases. I'll just
> clean it up a bit and submit it to 2.4 and 2.6 kernels.


Here it is.

The patch is only one line for 2.6.4-rc2. (I also did a little formatting
adjustment to better comply with CodingStyle)

For the 2.4.26-pre1 kernel, I also backported the return codes correction patch
from Oliver Neukum.


The problem with the write function was that, in non-blocking mode, after
submitting the first urb, the function would return with -EAGAIN, not reporting
to the application that in fact it had already sent "transfer_length" bytes.
This way the application would have to send the data *again* causing lots of
errors.

It did return the correct amount with my first patch, because the writecount was
being updated on the end of the loop. However this was wrong for blocking I/O.

The "transfer_length" local variable is still needed because if we used the
transfer_buffer_length field from the urb, then on a second call to write, if
the urb was still pending (in non-blocking mode), the write would return an
incorrect amount of data written.

Anyway, this time I tested it using blocking and non-blocking I/O and it works
for both cases. Even better, this patch only changes the behaviour for
non-blocking I/O, and keeps the same behaviour for the more usual blocking I/O
(at least on kernel 2.6).

This patch contains minute updates for the hpusbscsi, mdc800, and microtek
drivers.  Only two things are worth noting.  In the mdc800 driver I
removed some unnecessary calls to usb_driver_claim_interface(),
usb_driver_release_interface(), and usb_set_interface().  Likewise, in the
microtek driver I removed an unnecessary call to usb_set_interface().

*** linux-2.6.3/drivers/usb/storage/unusual_devs.h	2004-02-18 04:59:06.000000000 +0100

This removes several controller-specific #define, and
converts to using the config_buf utilities.  Depends
on the patch I submitted yesterday.  Looking simpler!


Simplify "gadget zero" compile-time configuration.

This removes several controller-specific compile-time config options;
the others are about to be autoconfigured.

 - HIGHSPEED replaced by CONFIG_USB_GADGET_DUALSPEED
 - Default to self-powered operation
 - There's no UI for remote wakeup

It also uses the new config_buf utilities, so it's a bit easier to see
what's really going on (this driver implements four configurations).

Deepak's recent dma_pool changes accidentally assumed that
all HCDs use DMA.  The fix is simple:  use kmalloc/kfree
when there's no DMA.

This includes some small updates to "usbtest", mostly
from Martin Diehl.  Please merge.



usbtest updates, supporting new firmware

    - Support the new usbtest_fw-20040305 EZ-USB firmware,
      which renumerates and handles full speed ISO transfers.
      (From Martin Diehl.)

    - Minor cleanups:  use dev_dbg(), let some slightly-off
      devices work in the control queueing test.

    - Be pickier about unlink tests:  insist that async
      and sync unlinks give the appropriate fault code.

This gets rid of an often-bogus diagnostic, and lets
at least the unlink test code recover reasonably when
it hits that brief window while another CPU has gotten
the complete() callback but hasn't yet resubmitted.



Return distinct code when unlinking an urb that's not linked.

This lets drivers handle this fault sanely, when they need to.
Gets rid of annoying non-error messages about drivers that unlink
in disconnect() even when the urb isn't linked.

This is the first several autoconfig patches; please merge.
This particular one abstracts dual-speed (high and full)
support.


Support some more autoconfiguration for gadget drivers.

    Run-time:
	* Add gadget->is_dualspeed flag for controllers to set.
	* Tested by "ethernet" gadget, to decide whether certain
	  operations are errors or not.
	* Turned on by net2280.

    Compile-time
	* Generic CONFIG_USB_GADGET_DUALSPEED, not net2280-specific.
	* Used by "ethernet" gadget, to decide whether to
	  include extra code and data for dual-speed support.
	* Turned on by net2280.

The basic idea behind this, and other autoconfig patches yet to come,
is minimizing the controller-specific compile-time configuration
needed by gadget drivers.

Some doc updates, mostly from Alan Stern, clarifying
quetions folk have asked recently about unlinking
and about iso transfers.

 net2280_remove() is called by net2280_probe() so it
 shouldn't be marked as __exit;

When sending the patch to remove USB_SCANNER, I forgot to remove the
MAINTAINERS entry.

In 2.6, USB_STORAGE selects SCSI, so there's no longer a need for this
comment.

the same error code path as in the other drivers.
In addition I added the endianness macros. They save cycles
in interrupt.

  -use endian macros
  -use GFP_KERNEL where SLAB_ATOMIC is not needed
  -fix count bug in open() error path

this fixes
- a leak in the error code path of open()
- removes SLAB_ATOMIC where it isn't needed
- uses le16_to_cpu (yes Pete, unaligned access is taken care of)

- don't pass buffers allocated on stack to the sync helpers
- check errors in probe
- fix count in open
- proper macros

This patch makes the usb-midi driver use usb_ifnum_to_if(), thereby
removing assumptions about which interface is stored in which array entry.
Similarly, it stores the bAlternateSetting value rather than the array
index for an altsetting entry.

Like the earlier patch for the audio driver, this also changes the driver
to use the in-memory rawdescriptor buffer rather than reading a
configuration descriptor from the device.  Unlike that earlier patch, this
time there's no question that the deallocation of the buffer is done
correctly.  (I suspect the audio driver just left out a call to kfree.)

you forgot to drop a spinlock before you report an error. A deadlock
will occur.

Arghh - while trying to follow this I just realized the pl2303 is DMA'ing
to the stack - not good!
Could you please just try with the patch below. I'm not sure if this might
cause the MA620 trouble but it's definedly a bug and maybe it improves
things for you...

Marc-Christian Petersen wrote:
>
> I think the attached patch is needed to stop showing us USB Gadget support if
> Support for USB is disabled.

No it isn't.  But maybe the attached patch would clarify what's
really going on:  CONFIG_USB is the host side, and CONFIG_USB_GADGET
is the peripheral side.

Somehow I sent you a version of this code with a misplaced
semicolon ... it makes for awkward failures!

Please merge.  Bad semicolon!

Some of the 480 Mbit/sec USB host-to-host links have ALI
chips in them.  They seem to work with no problem, given
this patch, even when the ends talk different speed.

a few more IDs added, could you please apply it?

We have rewritten the brlvger (Tieman Voyager USB Braille display) driver
so that it works from user-space through usbfs. It appears to work just as
well as the in-kernel driver.

The brlvger driver in the 2.6.x kernel is now obsolete and should be
removed. The attached patch against 2.6.3 does this. Please apply.
NB: The following files are completely deleted:
    Documentation/usb/brlvger.txt
    drivers/usb/misc/brlvger.c
    include/linux/brlvger.h

The new Voyager driver is available (stil under GPL) as part of BRLTTY,
starting with version 3.5pre1 (http://mielke.cc/brltty).
Thanks to Dave Mielke who implemented BRLTTY's usbfs functionality, among
lots of other stuff.

On Mon, 8 Mar 2004, Greg KH wrote:

> Oh, could you look at drivers/isdn/hisax/hfc_usb.c if you get a chance?
> I tried to figure out the mess there with regards to act_altsetting, but
> gave up :(

You're right, it is a mess.  Beats me why they didn't use a plain old
"for" statement to do that altsetting loop.  Probably the most confusing
part is where the code needlessly resets intf->act_altsetting.

Anyway, this patch sets things right.  I haven't tried to compile it, but
any errors ought to be pretty small, obvious, and easy to fix.

My intention was to go through the files under driver/usb (in alphabetical
order!) and then do the ones outside that subtree -- I've got a little
list.  But it's no problem to take care of this one first.

Some systems don't save the internal state of the UHCI registers across a
PM suspend/resume cycle very well.  This patch saves & restores the
Frame Number and the Framelist Base Address registers (in addition to the
Interrupt Enable register, which was added separately in a recent patch.)

This patch updates the USB audio class driver to use the usb_ifnum_to_if()
and usb_altnum_to_altsetting() routines, thereby removing assumptions
about which interface or altsetting is stored in which array entry.

It also simplifies the driver's probe() routine by using the raw
configuration descriptor already loaded into memory instead of reading the
descriptor from the device.  Now, either the current driver has a bug and
never deallocates the buffer used to hold the descriptor, or else I've
introduced a double-free error.  There's no obvious place where the buffer
gets freed, but it's hard to be certain.

It would be good if someone could try out this patch.  I can't test it,
not having any USB audio devices handy.  If the double-free error is
present, it will show up when the device is disconnected and the
configuration data is released.

This patch makes the necessary updates to the bluetty, cdc-acm, and usblp
class drivers for the new interface/altsetting paradigm.  The changes are
quite small.

Unfortunately, the audio and usb-midi drivers are in much worse shape.
They will require more in-depth hacking, to come later...

The attached patch updates wanXL card driver. Please apply to Linux 2.6.
Thanks.

Changes:
* fixed initialization kernel panic, introduced with recent alloc_netdev()
  wan patch,
* wanxl_rx_intr() port# now checked before accessing port structure,
* cleanups etc.
--
Krzysztof Halasa, B*FH

* Add National DP83840 PHY rev b/c setup.  Only rev a was being setup.

From: Joe Perches <joe@perches.com>

Use %08llx for a dma_addr_t, not the recently-added %llx.

The carmel driver will want to use this rather
than muck around in queue internals directly.

Declarations come before statements, please.

Current gcc warns about this too, bless them:

crypto/arc4.c: In function `arc4_crypt':
crypto/arc4.c:65: warning: ISO C90 forbids mixed declarations and code

From: Zwane Mwaikambo <zwane@linuxpower.ca>

It looks like a block request snuck through before we had initialised the
motor_off_timer timers.  So I pushed the timer init earlier.

From: Marc-Christian Petersen <m.c.p@wolk-project.de>

OSS Sound Driver Forte needs ac97_codec.