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

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

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

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

I needed this to get an APM + UHCI config to behave on resume.
Applies against your BK of last night ... OHCI and EHCI do
some of this manually, they could be simplified later.

o The following patch cleans up sysfs_rename_dir(). It now checks the
  return code of kobject_set_name() and propagates the error code to its
  callers. Because of this there are changes in the following two APIs. Both
  return int instead of void.

int sysfs_rename_dir(struct kobject * kobj, const char *new_name)
int kobject_rename(struct kobject * kobj, char *new_name)

[note, I changed this a bit to be nicer on the system log, greg k-h]

Prakash K. Cheemplavam wrote:
> David Brownell wrote:
>
>>> There appear lines like

> >>> usb usb2: string descriptor 0 read error: -108

>>> bug or feature? They weren't there with 2.6.6-mm1. I have no usb2.0
>>> stuff to actually test. My usb1 stuff seems to work though.
>>
>> Bug; minor, since the only real symptom seems to be messages like
>> that.  Ignore them for now, I'll make a patch soonish.
>
> Ok, good. Thanks for the explanation of what is going on, though I don't
> can make too much out of it. ;-)

The short version is:  it's missing this patch.

It also could hide real bugs, and that's not good.  And the name
implies that a reference is grabbed, and that's not true at all.

If this is hiding real problems, we need to find them.

Pretty useless stuff.  If this was hiding anything real, we need to find out.

Following patch merges the support for Keyspan UPR-112 USB serial adapter
from 2.4 to 2.6.

Also fix up some of the other printk() calls to be dev_* calls.

"Matt H." <lkml@lpbproductions.com> wrote:
>
> Just attempted to compile 2.6.6-mm2 and got this error
>
>    CC [M]  drivers/usb/core/driverfs.o
>    CC [M]  drivers/usb/core/hcd-pci.o
>    LD [M]  drivers/usb/core/usbcore.o
>    LD      drivers/usb/host/built-in.o
>    CC [M]  drivers/usb/host/ehci-hcd.o
>    CC [M]  drivers/usb/host/ohci-hcd.o
>  In file included from drivers/usb/host/ohci-hcd.c:129:
>  drivers/usb/host/ohci-hub.c: In function `ohci_rh_resume':
>  drivers/usb/host/ohci-hub.c:313: error: `hcd' undeclared (first use in this
>  function)

hm, not sure what's happened there...

On Thu, 13 May 2004, Duncan Sands wrote:

> No, but the pointer for another (previous) interface may just have been
> set to NULL, causing an Oops when usb_ifnum_to_if loops over all
> interfaces.

Of course!  I trust you won't mind me changing your suggested fix
slightly.  This should do an equally good job of repairing things, and it
will prevent other possible invalid references as well.

> I went ahead and created a patch to change all the places where devio.c
> uses an interface index.  Now it always uses just the interface number.
> Does this look all right to you?  I don't have a convenient way to test
> it.

Hi Alan, thanks for doing this.  It looks and works OK.  I added some name
changes: all struct usb_interface pointers are now called intf; and, when
reasonable, variables holding interface numbers are now all called ifnum.
This drowns your original changes in a sea of churning names, I hope you
don't mind.

This patch should help correct the "missing diagnostics with
CONFIG_USB_DEBUG during CDC Ethernet probe()" issue.  Some
folk are having problems with firmware that doesn't respond
properly to descriptor fetches -- which is unnecessarily
confusing because the diagnostics aren't being printed.

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

The following patch fixes the race involved between unregistering a kobject
and simultaneously opeing a corresponding attribute file in sysfs.

Ideally sysfs should take a ref.  to the kobject as long as it has dentries
referring to the kobjects, but because of current limitations in
module/kobject ref counting, sysfs's pinning of kobject leads to
hang/delays in rmmod of certain modules.  The patch checks for unhashed
dentries in check_perm() while opening a sysfs file.  If the dentry is
still hashed then it goes ahead and takes the ref to kobject.  This done
under the per dentry lock.  It does this in the inline routine
sysfs_get_kobject(dentry).

1) kobject_set_name-cleanup-01.patch

This patch corrects the following by checking the reutrn code from
kobject_set_name().

bus_add_driver()
bus_register()
sys_dev_register()



o The following patch cleansup the kobject_set_name() users. Basically checking
  return code from kobject_set_name(). There can be error returns like -ENOMEM
  or -EFAULT from kobject_set_name() if the name length exceeds KOBJ_NAME_LEN.

This patch goes on top of the previous two, and the hcd-0506 patch:

  - Moves root hub suspend/resume code out of PCI-specific bus glue
    into generic hub code.  That way it's easy to re-use it even
    for non-PCI implementations like SA1111, OMAP, and LH7A404.
    (Plus, given CONFIG_USB_SUSPEND, it can be invoked with sysfs.)

  - Root hub suspend is a lot more careful, as is root hub resume.
    Pending transactions are now shut down more consistently; and
    more registers are re-initialized on resume.

  - The PCI bus glue is now left with truly generic PCI stuff, plus
    some PMAC-specific stuff (which doesn't include irq disabling
    any more, hcd-0506 moves that up a level in the stack).

  - Remote wakeup support is basically working for the root hub.
    (given CONFIG_USB_SUSPEND to suspend devices and enable it).

  - Idle HCs will now automatically suspend themselves, and resume
    as necessary.  This saves a certain amount of power on most
    systems, and matches what UHCI has been doing for a while.

The large size of this patch is mostly because of moving that
root hub suspend/resume code out of the PCI-specific glue.

This goes with the OHCI anti-deadlock patch, and is what
ensures that when a root hub loses power during suspend,
khubd can turn port power back on so devices can enumerate.

This splits out a few obvious fixes, to help shrink a PM patch:

  - when the HC is quiescing, don't schedule any more EDs
    or re-activate any after unlink completion.

  - when the HC is suspended, don't access registers through
    sysfs either.

  - simplify locking and call for donelist processing

System-wide PM resume now happily deadlocks if one of the
resuming devices tries to remove devices which vanished
during the suspend(*).  IMO that's unreasonable both
because devices can/do vanish, and because 2.4 didn't
deadlock in those cases; but no patch to fix that has been
merged.  The result is that ever since merging the "new" PM
code, some OHCI-based systems deadlock on resume.

So this patch handles the "lost power during resume" case
differently:  it doesn't disconnect the root hub (or its
children) directly.  Instead, it does part of that work
immediately, and defers the rest to khubd:

  - add a "pending" list for live urbs, and use it after reset
    to abort pending URBs (and reclaim "live" EDs/TDs)
  - immediately mark all devices NOTATTACHED, so any operations
    on the devices before khubd handles the disconnects, including
    resume() callbacks, will fail
  - kick root hub so it can do the cleanup

It also handles "fminterval" init/reinit a bit better, mostly
to work better in some remote wakeup scenarios addressed in
later patches:

   - save any initial value the boot firmware provided
   - use it during initialization (and eventually, remote wakeup)

Other changes:

  - use better jiffies calculation for scheduled delays
  - the allocator does more of the one-time initialization
  - initialize hcd.can_wakeup according to boot firmware
  - move some inlines to the header
  - minor cleanups


(*) http://marc.theaimsgroup.com/?l=linux-kernel&m=106606272103414&w=2
     reported against 2.6.0-test7.

quoting Linus:

--
> so there is no need to recheck the bit in do/while loop, because
> there is no false wakeups now.

You should never assume this. You should assume that there are _always_
false wakeups.

Why? Because Linux has always allowed people to leave wait-queues active,
without being "atomic". For example, the tty read/write layer used to
(still does?)  add itself on the wait-queue _once_, and then leave itself
on the wait-queue while in a loop it does copies from/to user space.
--

Unfortunately, this means us. Here's the first fix. Comments?

  - make sure timeouts are observed even if somebody left us on a queue

This patch makes the usbcore PCI suspend/resume logic behave
much better.  In particular:

  - Even HCs without PCI PM support will normally be able
    to support global suspend, saving power ... and will
    need to resume later.  Let them try to suspend; lots
    of not-that-old USB controllers don't have PM caps.

  - Saner order for the boilerplate PCI stuff.  It also
    explicitly disables the IRQ and DMA, which aren't
    available in D1/D2/D3 states anyway.

  - Uses pci_enable_wake() when the root hub supports
    remote wakeup.  Didn't fully work in one test setup;
    that controller's PME# was evidently ignored.  (Not
    enabled unless CONFIG_USB_SUSPEND.)

It worked for me with brief tests with the current 2.6.6-rc
uhci-hcd with one old UHCI; more extensive ones with various
OHCIs (using patches which I'll post soonish); and not at all
with EHCI (where PM hasn't ever worked).

Those of you who've been having PM problems might find
this helpful as-is, though I think that unless you're
using UHCI you'll also need an HCD patch.

- Dave

Now that all the USB drivers have been audited, we can safely accept
devices that have noncompliant numbering for their interfaces or
altsettings.  This patch skips bad or duplicate descriptors, allows gaps
in the numbering, accepts more or fewer interfaces than bNumInterfaces,
and logs warnings describing all these things.  Also, the debugging log
messages have been improved by David Brownell.

This should please a sizeable group of users.

This patch updates EHCI suspend/resume so that its essential
components work on a few different implementations:

   - make root hub suspend/resume work
   - make remote wakeup work (given CONFIG_USB_SUSPEND patch)
   - separate root hub suspend/resume from PCI suspend/resume
   - say if controller supports remote wakeup (on this system)
   - sysfs register dump unavailable if controller is suspended

Plus a handful of minor cleanups.  Please merge, along with the
"hcd-0506.patch" I sent last week.

Tested by modifying sysfs power/state files, since ACPI doesn't
work on this system (so I can't test system suspend/resume):

  - For root hub(*) ... suspend/resume works, also remote wakeup
  - PCI controller ... suspend/resume works, remote wakeup
    signals PME# (according to "lspci -vv"), but that's ignored
    on my test sytem

Regardless of whether USB was active, "echo 1 > /proc/acpi/sleep"
produced a system that wouldn't resume, and the same result
came from "echo standby > /sys/power/state".  So that's about
as far as I can take this testing for now.

- Dave

(*) Doing this relies on the CONFIG_USB_SUSPEND patch.  Otherwise
     no USB devices respond to sysfs power/state updates.  The
     PCI suspend/resume is a superset of this.

On Fri, 7 May 2004, kernel@metro.cx wrote:
> Hi All,
>
> I don't know where else to report this, but I found a very very very
> minor bug in the usb gadgets drivers, specifically the file_storage.c
> mass storage driver.
>
> In the function do_request_sense(..) it says:
>
> buf[7] = 18 - 7;                        // Additional sense length
>
> Whereas (according to page 38 of the USB mass storage class, UFI command spec,
> http://www.usb.org/developers/devclass_docs#approved) this clearly neads
> to be equal to 10, not 11.
>
> I checked with the 2.6.5 source, it is still there. Hope someone will find this usefull, although most USB hosts seem to ignore length bits alltogether anyway....
>
> Koen Martens

You are quite right; thank you for pointing this out.  Greg, please apply
the patch below.

drivers/usb/media/dsbr100.c: In function `usb_dsbr100_probe':
drivers/usb/media/dsbr100.c:239: warning: unused variable `videodev'