This patch continues the work of as209 by converting the rest of usbcore
to use cur_altsetting in place of act_altsetting.  The changes required
are fairly small, just in the sysfs attributes and hub configuration.

On Sat, 21 Feb 2004, Greg KH wrote:

> > One thing that would be good, whether this change gets made or not, is to
> > remove all assumptions from drivers about the order in which interfaces
> > are stored (use usb_ifnum_to_if()) and the order in which altsettings are
> > stored (replace intf.act_altsetting with a pointer and create
> > usb_altnum_to_alt() analogous to usb_ifnum_to_if()).  There are plenty of
> > drivers that will need to be fixed up.
>
> I'd be glad to take patches to fix up any drivers that still have this
> problem right now.

Here's a start.  This patch begins the conversion process by adding
usbcore support for cur_altsetting and deprecating act_altsetting.

So long as we assumed that altsetting numbers range from 0 to
num_altsetting-1 and that the number matches its index in the altsetting
array, there was no harm in using act_altsetting.  But without that
assumption act_altsetting is merely an invitation to errors.  Although the
kerneldoc says that act_altsetting is the _index_ of the active
altsetting, it's all too easy to confuse it with the _number_ of the
active altsetting.  Using cur_altsetting instead (a pointer rather than a
number) will prevent that confusion.

Until all the drivers have been converted to use cur_altsetting, the core
will have to maintain act_altsetting in parallel with it.  Eventually we
will be able to remove act_altsetting, but fixing all the drivers will
take a while.

Included in this patch:

	Add cur_altsetting to struct usb_interface and deprecate
	act_altsetting.

	Add comments and kerneldoc explaining the changes.  Also remove
	the comments in front of struct usb_host_config (they seem to
	have been left behind when usb_ch9.h was split out) and add
	kerneldoc for that structure.

	Add usb_altnum_to_altsetting() to help look up altsettings based
	on their number.

	Convert the usb_set_interface(), usb_set_configuration(), and
	usb_reset_configuration() routines to support cur_altsetting
	and act_altsetting in parallel.  Convert a few others to use
	cur_altsetting rather than act_altsetting.

	Rename a few local variables to make their meaning a little
	clearer.  It would be nice to change struct usb_host_interface
	to something like usb_host_altsetting, but that's a patch for
	another time.

On Fri, 27 Feb 2004, Greg KH wrote:

> On Wed, Feb 25, 2004 at 10:05:37AM -0500, Alan Stern wrote:
>
> > Why would anyone want to do this, you ask?  Well the USB subsystem does it
> > already.  Each USB device can have several configurations, only one of
> > which is active at any time.  Corresponding to each configuration is a set
> > of struct devices, and they (together with their embedded kobjects) are
> > allocated and initialized when the USB device is first detected.  The
> > struct devices are add()'ed and del()'ed as configurations are activated
> > and deactivated, leading to just the sort of call sequence shown above.
>
> Then we need to fix this.

The driver model does not support repeated device_add(), device_del(),
device_add(), device_del(), ... calls for the same device.  But that's
what happens to an interface's embedded struct device when we change
configurations.

Accordingly, this patch changes the device_add()/device_del() calls for
interfaces to device_register()/device_unregister().  When the interface
is unregistered the new code waits for the release method to run, so that
it will be safe to re-register the interface should the former
configuration be reinstated.

Greg, please check this out to make sure I haven't made some dumb mistake.
It works on my system and it fixes a memory leak in the USB system.

Teach gadget/usbstring to expect UTF-8 strings, not ISO-8859/1 ones.
This just gets rid of an API issue:  no hacks needed for non-Western
languages, and multi-language support will be lots easier.

Current drivers won't notice the API change, they use US-ASCII (which
is a strict superset of both encodings).

Future drivers may want to teach utf8_to_utf16le() about the four-byte
encodings, so they can emit surrogate pairs for those Unicode characters.

In the slave_configure routine it's already too late for the host's
max_sector value to affect the scsi_device.  It's necessary to set the
queue value directly.  This revised patch takes care of that.

Hi... here is a patch for the vendor/device codes for the
Samsung SPH-i500 Palm phone.

here is an unusual_devs.h entry which makes two different USB MP3 players
work with Linux' USB storage driver. They share a core chip, the t33520 USB
flash card controller by Trumpion microelectronics. They also share the same
ID 0x090a:0x1001, which is a "generic" ID for t33520 devices using bulk-only
protocol (0x1002 is for CB).

About the MP3 players:
  - I own an apparently unbranded one (sold in masses on ebay.de) which
    needs US_FL_MODE_XLATE (and used to need US_FL_START_STOP before its
    removal).
  - Theodore Kilgore (who created the 0x090a:0x1001 record in the
    Linux-USB device overwiew) has a "Trumpion Digital Research MYMP3"
    which needs US_FL_MODE_XLATE and an explicit US_PR_BULK.
Of course the different players report the same firmware rev. 1.00,
despite their obviously different behaviour. Ugh.

There are more players with this ID, the "Kaser Yofun 100 MP-3" (also
rev. 1.00) being one. The proposed entry may or may not help them, but
it shouldn't break working ones in any case. It is not unlikely they too
will need US_FL_MODE_XLATE.

Below you'll find my /proc/bus/usb/devices with mounted MP3 player and a
patch against 2.4.25-rc3. Please apply.



 ----------------8<-------------------------8<--------------------

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB UHCI Root Hub
S:  SerialNumber=e400
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=090a ProdID=1001 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 60mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=255ms

 ----------------8<-------------------------8<--------------------

Please apply the attached patches instead. People have tried it on several
different Pentax cameras (including 330 GS)

Here's a small patch changing the GNU-style initializers to C99
initializers. The patch is against the current BK.

`debug', indeed.

I have attached a patch which contains a driver and documentation for
the MicroTouch (14-206) USB Capacitive Touchscreen controller.  It based
on some older code that I have been using for quite some time now (since
2.4.17).  This new version has been completely re-written, and now uses
Linux Input.  Greg, It would be great to possibly get it into 2.6.4.
Please let me know if I have it all wrong...

Unfortunately, the X11 mouse driver only seems capable of handling
relative data rather than absolute.  Hopefully some one will create a
suitable X11 driver capable of accepting absolute data from Linux
Input.  If anyone is aware of one, please let me know.  Otherwise, I
will most likely begin some work on a patch for GPM.

Calibration support will be on the way soon, but I'm not sure of the
best way to implement.  Perhaps some abstract functions could come
available in evdev which can call vendor specific commands for the
calibration within this driver (and perhaps others).

I have altered kbtab.c a bit in anticipation of an XFree86 4.3 driver
that can accept the pressure data (as a third axis) by listening on the
event interface.

I have set it so that if the option kb_pressure_click is -1 it  reports
pressure rather than clicks.

I've taken the old GATOS version of the ati_remote driver and done
some cleanup/rework of it while porting to 2.6 kernels.

This is a minor update to the patch I sent out about a week ago.
The key change is to use the I/O watchdog while doing ISO streaming.
Bernd Porr reports that a VT8235 system needs that; it seems like
IDE activity can interfere with the delivery of USB IRQs.


EHCI periodic scheduling updates.

 - Initial version of full speed ISO transaction support.  This
   should handle OUT transactions, such as those for usb speakers.
   For now, it's controlled using an EXPERIMENTAL config option:

   * I've run into interesting differences in how different USB 2.0
     hub silicon (the transaction translators) handle some older
     audio devices.  Needs more investigation.

   * Interrupt transfer scheduling doesn't yet cope well with schedules
     where every slot already has activity.  For now, don't plug in
     devices like hubs, mice, or keyboards while EHCI is streaming.

 - Protect freelist for highspeed ITDs, using spinlock.  Could be
   an issue for some drivers.

 - Kick in the I/O watchdog timer (5 msec) for periodic transfers.
   In this case, IDE activity on a VT8235 lost the IRQs which should
   have kept the ISO stream active.  Queues shorter than 5 msec are
   not going to work on all USB hosts.

 - Simplified the ISO scheduler:  doesn't attempt to re-schedule
   after lossage, or to short-circuit scanning.  (Rescheduling will
   probably come back later ... for now, the "hard" error here is
   highlighting problems that need attention.)

Adds two new gadget-side utility functions, to support a declarative
style of managing usb configuration descriptors.  The functions fill
buffers from null-terminated vectors of usb descriptors, which are
simple to build or update.

The "ethernet" gadget driver currently has the most interesting config
descriptors.  This uses those functions to replace some complex code with
simpler static declarations; result, it's cleaner.  (And it'll be easier
to add RNDIS configurations later, too.)

Memory savings (or cost, depending on config) was less than 50 bytes;
nothing worth worrying about.

New Zaurus ID, from Sven Trampel <Sven.Trampel@surf-club.de>

On Fri, 27 Feb 2004, Lenar Lõhmus wrote:

> Hi,
>
> Got this:
>
> usb 3-1: new full speed USB device using address 3
> usb-storage: This device (0686,400b,0001 S 06 P 50) has an unneeded SubClass entry in unusual_devs.h
> Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>

Well, Martin Pool notwithstanding (see

http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107642806303815&w=2

), it sure looks like this doesn't need an unusual_devs.h entry.

Greg, please apply this patch.

I tried using the kl5kusb105 driver for a 3Com PalmConnect USB device I
had lying around.

It oopses during device detection. There is a nested loop using the same
loop counter as the outer loop - causing the code after the nested loop
is first executed to have an invalid counter. The counter is then used
as an array index, causing a NULL deref.

Fix attached.

Nothing in life is assured...

This patch tightens up the conditions under which an auto-sense will be
cleared.  It also fixes the comment associated with the code.

This one-liner removes an unneeded macro.

This patch changes some error checking so that some bogus devices (like the
Fuji Finepix 1400) will work.

This is basically relaxing a test on a field that the spec says "should
always be zero"

Our friends at sony are at it again.  The DSC-T1 needs a new entry.  Note
that it's the same VID & PID as the last entry, but different version.

This patch is from Stephen Hemminger.  I modified it slightly to place the
new elements at the end of the complete_list instead of at the front.

On Tue, 24 Feb 2004, Stephen Hemminger wrote:

> Since the remove_list and complete_list now use the same element for
> linking, it is possible to use the list_splice inline to avoid
> having to loop over all the urb's

On Mon, 23 Feb 2004, Stephen Hemminger wrote:
> Bulk and interrupt urb's share common irq processing, why does the
> code try to obfuscate it?

Quite right; this is needless complexity.  (But note you left in a couple
of lines that should have been deleted.)

This patch changes the result code returned by the UHCI driver for a
certain class of errors.  Under a number of circumstances a USB device is
obliged to send a response packet within a fairly short turn-around time,
typically 1 - 10 microseconds depending on the bus speed.  Failure to do
so is a protocol error and should be reported as such, not as a timeout,
which is really a higher-level concept.  I believe the EHCI driver already
does this.

I trust nobody will object to the update this patch adds to
Documentation/usb/error-codes.txt, making this more explicit.

In a vaguely related change, the patch corrects the terminology in a few
comments.  The parts of a control transfer are called "stages", not
"phases".

On Mon, 23 Feb 2004, Chip Salzenberg wrote:

> It works ... perfectly!  I can now suspend and resume my A30 with
> impunity, and the USB keyboard works fine after each resume.
>
> Thanks much, Alan.
>
> (Now if I could just get the alsa guys to fix snd-intel8x0...)

This patch re-initializes the UHCI Interrupt Enable register following a
PM resume.  Apparently some systems clear the register during suspend,
which causes obvious problems later on.

On Mon, 23 Feb 2004, Stephen Hemminger wrote:

> Great, the kernel with this patch ran successfully all weekend.  Looks like no
> more races in the unlink path.

Wonderful.  Thanks a lot for all your SMP testing, it's been a big help.


This patch corrects an error in the dequeueing code for UHCI.  Improper
locking caused it to hang in the oddball case where an URB was unlinked
even before it had been queued.

On Tue, 24 Feb 2004, Matthew Dharm wrote:

> We should also put a comment into the unusual_devs.h file to make sure
> nobody tries to remove the protocol override in the future.

How about this?

On Thu, 19 Feb 2004, Evan Felix wrote:

> I plugged a Cyclades AlterPath BIO USb device into my linux 2.6.2 laptop
> and it asked me to send you this:
>
>
> hub 1-1.2:1.0: new USB device on port 3, assigned address 6
> hub 1-1.2.3:1.0: USB hub found
> hub 1-1.2.3:1.0: 4 ports detected
> hub 1-1.2.3:1.0: new USB device on port 1, assigned address 7
> hub 1-1.2.3:1.0: new USB device on port 2, assigned address 8
> Initializing USB Mass Storage driver...
> usb-storage: This device (05dc,0001,0001 S 06 P 50) has an unneeded
> SubClass entry 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
>   Vendor: Lexar     Model: Jumpshot USB CF   Rev: 0001
>   Type:   Direct-Access                      ANSI SCSI revision: 02

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

This patch is the first of several planned fixes for the cyclades
multiserial cards driver.

Its mostly a sync with in-house driver:

- Prevent users from opening non-existing Z ports
- Implement special XON/XOFF character handling in Z cards
- Prevent data-loss on Z cards
- Throttling fix for Z card
- Only throttle if CTS/RTS are set
- Fix accounting of received data

Kudos to Cyclades R&D