[PATCH] i2o: 64-bit fixes

From: Markus Lidel <Markus.Lidel@shadowconnect.com>

Fix 64-bit problems.

[PATCH] I2O subsystem fixing and cleanup for 2.6 - i2o-passthru.patch

From: Markus Lidel <Markus.Lidel@shadowconnect.com>

* Add a pass-thru ioctl to i2o_config, which is needed to work with the
  Adaptec management software.

[PATCH] I2O subsystem fixing and cleanup for 2.6 - i2o-config-clean.patch

From: Markus Lidel <Markus.Lidel@shadowconnect.com>

* Changes the formating of the header in i2o_config.c

[PATCH] Module ref counting for vt console drivers

From: Herbert Xu <herbert@gondor.apana.org.au>

The following patch adds basic module reference counting to vt console
drivers.  Currently modules like fbcon are not counted at all.

[PATCH] ia64 cpu hotplug: core

From: Ashok Raj <ashok.raj@intel.com>

Supports basic ability to enable hotplug functions for IA64.
Code is just evolving, and there are several loose ends to tie up.

What this code drop does
- Support logical online and offline
- Handles interrupt migration without loss of interrupts.
- Handles stress fine > 24+ hrs with make -j/ftp/rcp workloads
- Handles irq migration from a dying cpu without loss of interrupts.

What needs to be done
- Boot CPU removal support, with platform level authentication
- Putting cpu being removed in BOOT_RENDEZ mode.

[PATCH] Revisited: ia64-cpu-hotplug-cpu_present.patch

From: Paul Jackson <pj@sgi.com>

With a hotplug capable kernel, there is a requirement to distinguish a
possible CPU from one actually present.  The set of possible CPU numbers
doesn't change during a single system boot, but the set of present CPUs
changes as CPUs are physically inserted into or removed from a system.  The
cpu_possible_map does not change once initialized at boot, but the
cpu_present_map changes dynamically as CPUs are inserted or removed.

Paul Jackson <pj@sgi.com> provided an expanded explanation:

Ashok's cpu hot plug patch adds a cpu_present_map, resulting in the following
cpu maps being available.  All the following maps are fixed size bitmaps of
size NR_CPUS.

#ifdef CONFIG_HOTPLUG_CPU
cpu_possible_map - map with all NR_CPUS bits set
cpu_present_map - map with bit 'cpu' set iff cpu is populated
cpu_online_map - map with bit 'cpu' set iff cpu available to scheduler
#else
cpu_possible_map - map with bit 'cpu' set iff cpu is populated
cpu_present_map - copy of cpu_possible_map
cpu_online_map - map with bit 'cpu' set iff cpu available to scheduler
#endif

In either case, NR_CPUS is fixed at compile time, as the static size of these
bitmaps.  The cpu_possible_map is fixed at boot time, as the set of CPU id's
that it is possible might ever be plugged in at anytime during the life of
that system boot.  The cpu_present_map is dynamic(*), representing which CPUs
are currently plugged in.  And cpu_online_map is the dynamic subset of
cpu_present_map, indicating those CPUs available for scheduling.

If HOTPLUG is enabled, then cpu_possible_map is forced to have all NR_CPUS
bits set, otherwise it is just the set of CPUs that ACPI reports present at
boot.

If HOTPLUG is enabled, then cpu_present_map varies dynamically, depending on
what ACPI reports as currently plugged in, otherwise cpu_present_map is just a
copy of cpu_possible_map.

(*) Well, cpu_present_map is dynamic in the hotplug case.  If not hotplug,
    it's the same as cpu_possible_map, hence fixed at boot.

[PATCH] ia64 cpu hotplug: /proc rework

From: Ashok Raj <ashok.raj@intel.com>

Changes proc entries for cpu hotplug to be created via the cpu hotplug
notifier callbacks.  Also fixed a bug in the removal code that did not remove
proc entries as expected.

[PATCH] ia64 cpu hotplug: IRQ affinity work

From: Ashok Raj <ashok.raj@intel.com>

irq affinity setting via /proc was forcing iosapic rte programming by force.
The correct way to do this is to perform this when a interrupt is pending.

[PATCH] ia64 cpu hotplug: sysfs additions

From: Ashok Raj <ashok.raj@intel.com>

Creation of sysfs via topology_init() creates sysfs entries.  The creation of
the online control file is created separately when the cpu_up is invoked in
arch independent code.

[PATCH] ia64 cpu hotplug: init section fixes

From: Ashok Raj <ashok.raj@intel.com>

Contains changes from __init to __devinit to support cpu hotplug Changes only
arch/ia64 portions of the kernel tree.

[PATCH] ia64 cpu hotplug: core kernel initialisation

From: Ashok Raj <ashok.raj@intel.com>

This patch changes __init to __devinit to init_idle so that when a new cpu
arrives, it can call these functions at a later time.

[PATCH] swap speedups and fix

From: Andrea Arcangeli <andrea@suse.de>

I don't think we need an install_swap_bdev/remove_swap_bdev anymore, we should
use the swap_info->bdev, not the swap_bdevs.  the swap_info already has a
->bdev field, the only point of remove_swap_bdev/install_swap_bdev was to
unplug all devices as efficiently as possible, we don't need that anymore with
the page parameter.

Plus the semaphore should be a rwsem to allow parallel unplug from multiple
pages.

After that I don't need to take the semaphore anymore during swapon, no
swapcache with swp_type() pointing to such bdev, will be allowed until swapon
is complete (SWP_ACTIVE is set a lot later after setting p->bdev).

In swapoff I only need a dummy serialization with the readers, after
try_to_unuse is complete:

  err = try_to_unuse(type);
  current->flags &= ~PF_SWAPOFF;

  /* wait for any unplug function to finish */
  down_write(&swap_unplug_sem);
  up_write(&swap_unplug_sem);

that's all, no other locking and no install_swap_bdev/remove_swap_bdev.

(and the swap_bdevs[] compression code was busted)

[PATCH] blk_run_page(): we don't trust bh->b_page

We don't trust bh->b_page to point to the right thing across all filesystems,
so revert this bit.

[PATCH] blk_run_page(): fixup for swap_unplug_io_fn()

[PATCH] Add blk_run_page()

From: Andrea Arcangeli <andrea@suse.de>

From: Jens Axboe

Add blk_run_page() API.  This is so that we can pass the target page all the
way down to (for example) the swap unplug function.  So swap can work out
which blockdevs back this particular page.

[PATCH] rmap-5-swap_unplug-page-revert

Revert the pre-2.6.6 per-address-space unplugging changes.  This removes a
swapper_space exceptionality, syncs things with Andrea and provides for
simplification of the swap unplug function.

[PATCH] rename rmap_lock to page_map_lock

Sync this up with Andrea's patches.

[PATCH] filtered wakeups: apply to buffer_head functions

From: William Lee Irwin III <wli@holomorphy.com>

This patch implements wake-one semantics for buffer_head wakeups in a single
step.  The buffer_head being waited on is passed to the waiter's wakeup
function by the waker, and the wakeup function compares that to the a pointer
stored in its on-stack structure and checking the readiness of the bit there
also.  Wake-one semantics are achieved by using WQ_FLAG_EXCLUSIVE in the
codepaths waiting to acquire the bit for mutual exclusion.

[PATCH] filtered wakeups: apply to pagecache functions

From: William Lee Irwin III <wli@holomorphy.com>

This patch implements wake-one semantics for page wakeups in a single step.
Discrimination between distinct pages is achieved by passing the page to the
wakeup function, which compares it to a pointer in its own on-stack structure
containing the waitqueue element and the page.  Bit discrimination is achieved
by storing the bit number in that same structure and testing the bit in the
wakeup function.  Wake-one semantics are achieved by using WQ_FLAG_EXCLUSIVE
in the codepaths waiting to acquire the bit for mutual exclusion.

[PATCH] filtered wakeups: wakeup enhancements

From: William Lee Irwin III <wli@holomorphy.com>

This patch provides an additional argument to __wake_up_common() so that the
information wakefunc.patch made waiters ready to receive may be passed to them
by wakers.  This is provided as a separate patch so that the overhead of the
additional argument to __wake_up_common() can be measured in isolation.  No
change in performance was observable here.

[PATCH] filtered wakeups

From: William Lee Irwin III <wli@holomorphy.com>

This patch series is solving the "thundering herd" problem that occurs in the
mainline implementation of hashed waitqueues.  There are two sources of
spurious wakeups in such arrangements:

(a) Hash collisions that place waiters on different objects on the same
    waitqueue, which wakes threads falsely when any of the objects hashed to
    the same queue receives a wakeup.  i.e.  loss of information about which
    object a wakeup event is related to.

(b) Loss of information about which object a given waiter is waiting on.
    This precludes wake-one semantics for mutual exclusion scenarios.  For
    instance, a lock bit may be slept on.  If there are any waiters on the
    object, a lock bit release event must wake at least one of them so as to
    prevent deadlock.  But without information as to which waiter is waiting
    on which object, we must resort to waking all waiters who could possibly
    be waiting on it.  Now, as the lock bit provides mutual exclusion, only
    one of the waiters woken can proceed, and the remainder will go back to
    sleep and wait for another event, creating unnecessary system load.  Once
    wake-one semantics are established, only one of the waiters waiting to
    acquire a lock bit need to be woken, which measurably reduces system load
    and improves efficiency (i.e.  it's the subject of the benchmarking I've
    been sending to you).

Even beyond the measurable efficiency gains, there are reasons of robustness
and responsiveness to motivate addressing the issue of thundering herds.  In a
real-life scenario I've been personally involved in resolving, the thundering
herd issue caused powerful modern SMP machines with fast IO systems to be
unresponsive to user input for a minute at a time or more.  Analogues of these
patches for the distro kernels involved fully resolved the issue to the
customer's satisfaction and obviated workarounds to limit the pagecache's
size.

The latest spin of these patches basically shoves more pieces of the logic
into the wakeup functions, with some efficiency gains from sharing the hot
codepath with the rest of the kernel, and a slightly larger diff than the
patches with the newly-introduced entrypoint.  Writing these was motivated by
the push to insulate sched.c from more of the details of wakeup semantics by
putting more of the logic into the wakeup functions.  In order to accomplish
this while still solving (b), the wakeup functions grew a new argument for
communication about what object a wakeup event is related to to be passed by
the waker.

=========

This patch provides an additional argument to wakeup functions so that
information may be passed from the waker to the waiter.  This is provided as a
separate patch so that the overhead of the additional argument can be measured
in isolation.  No change in performance was observable here.

[PATCH] do_mounts_rd-malloc-fix

gcc-3.4.0 sez:

init/do_mounts_rd.c:309: warning: conflicting types for built-in function 'malloc'

[PATCH] VM accounting fix

From: Hugh Dickins <hugh@veritas.com>

Stas Sergeev <stsp@aknet.ru> wrote:

   mprotect() fails to merge VMAs because one VMA can end up with
   VM_ACCOUNT flag set, and another without that flag.  That makes several
   apps of mine to malfuncate.

Great find!  Someone has got their test the wrong way round.  Since that
VM_MAYACCT macro is being used in one place only, and just hiding what it's
actually about, fold it into its callsite.

[PATCH] revert the process-migration-speedup patch

David Mosberger asked that this be backed out:

"I do not believe that flushing the TLB before migration is be the right thing
to do on ia64 machines which support global TLB purges (i.e., all but SGI's
machines)."

It was of huge benefit for the SGI machines, so work is ongoing.

[PATCH] MSEC_TO_JIFFIES to msec_to_jiffies

Switch all users of MSEC[S]_TO_JIFFIES and JIFFIES_TO_MSEC[S] over to use
jiffies_to_msecs() and msecs_to_jiffies().  Withdraw MSECS_TO_JIFFIES() and
JIFFIES_TO_MSECS() from the kernel API.

[PATCH] Covert drivers to use msec_to_jiffies

Remove various private implementations of msecs_to_jiffies() and
jiffies_to_msecs().

There are various uppercase versions which should be consolidated.

[PATCH] MSEC_TO_JIFFIES consolidation

From: Ingo Molnar <mingo@elte.hu>

We have various different implementations of MSEC[S]_TO_JIFFIES and
JIFFIES_TO_MSEC[S].  We recently had a compile-time clash in USB.

Fix all that up.

- The SCTP version was very inefficient.  Hopefully this version is accurate
  enough.

- Optimise for the HZ=100 and HZ=1000 cases

- This version does round-up, so sleep(9 milliseconds) works OK on 100HZ.

- We still have lots of jiffies_to_msec and msec_to_jiffies implementations.

From: William Lee Irwin III <wli@holomorphy.com>

  Optimize the cases where HZ is a divisor of 1000 or vice-versa in
  JIFFIES_TO_MSECS() and MSECS_TO_JIFFIES() by allowing the nonvanishing(!)
  integral ratios to appear as a parenthesized expressions eligible for
  constant folding optimizations.

From: me

  Use typesafe inlines for the jiffies-to-millisecond conversion functions.

  This means that milliseconds officially takes the type `unsigned int'.
  All current callers seem to be OK with that.

  Drivers need to be fixed up to use this instead of their private versions.

[PATCH] sched: add missing local_irq_enable()

From: Nick Piggin <nickpiggin@yahoo.com.au>

this_rq_lock does a local_irq_disable, and sched_yield() needs to undo that.

[PATCH] Fix page double-freeing race

This has been there for nearly two years.  See bugzilla #1403

vmscan.c does, in two places:

spin_lock(zone->lru_lock)
page = lru_to_page(&zone->inactive_list);
if (page_count(page) == 0) {
/* erk, it's being freed by __page_cache_release() or
 * release_pages()
 */
put_it_back_on_the_lru();

} else {

--> window 1 <--

page_cache_get(page);
put_in_on_private_list();
}
spin_unlock(zone->lru_lock)

use_the_private_list();

page_cache_release(page);

whereas __page_cache_release() and release_pages() do:

if (put_page_testzero(page)) {

--> window 2 <--

spin_lock(lru->lock);
if (page_count(page) == 0) {
remove_it_from_the_lru();
really_free_the_page()
}
spin_unlock(zone->lru_lock)
}

The race occurs if the vmscan.c path sees page_count()==1 and then the
page_cache_release() path happens in that few-instruction "window 1" before
vmscan's page_cache_get().

The page_cache_release() path does put_page_testzero(), which returns true.
Then this CPU takes an interrupt...

The vmscan.c path then does page_cache_get(), taking the refcount to one.
Then it uses the page and does page_cache_release(), taking the refcount to
zero and the page is really freed.

Now, the CPU running page_cache_release() returns from the interrupt, takes
the LRU lock, sees the page still has a refcount of zero and frees it again.
Boom.

The patch fixes this by closing "window 1".  We provide a
"get_page_testone()" which grabs a ref on the page and returns true if the
refcount was previously zero.  If that happens the vmscan.c code simply drops
the page's refcount again and leaves the page on the LRU.

All this happens under the zone->lru_lock, which is also taken by
__page_cache_release() and release_pages(), so the vmscan code knows that the
page has not been returned to the page allocator yet.

In terms of implementation, the page counts are now offset by one: a free page
has page->_count of -1.  This is so that we can use atomic_add_negative() and
atomic_inc_and_test() to provide put_page_testzero() and get_page_testone().

The macros hide all of this so the public interpretation of page_count() and
set_page_count() remains unaltered.

The compiler can usually constant-fold the offsetting of page->count.  This
patch increases an x86 SMP kernel's text by 32 bytes.

The patch renames page->count to page->_count to break callers who aren't
using the macros.

This patch requires that the architecture implement atomic_add_negative().  It
is currently present on

arm
arm26
i386
ia64
mips
ppc
s390
v850
x86_64

ppc implements this as

#define atomic_add_negative(a, v) (atomic_add_return((a), (v)) < 0)

and atomic_add_return() is implemented on

alpha
cris
h8300
ia64
m68knommu
mips
parisc
ppc
ppc
ppc64
s390
sh
sparc
v850

so we're looking pretty good.

[PATCH] sparc64: implement atomic_add_negative()

[PATCH] ia64 atomic_inc_and_test fix

From: David Mosberger <davidm@napali.hpl.hp.com>

[PATCH] alpha: atomic_inc_and_test()

From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>

It seems atomic_inc_and_test() is missing on alpha.

[PATCH] Implement atomic_inc_and_test() on various architectures

It's easy to do when the arch provides atomic_inc_return().

[PATCH] Implement atomic_add_negative() on various architectures

Lots of architectures have atomic_add_return() and no atomic_add_negative().

We can implement the latter in terms of the former.

[PATCH] Make users of page->count use the provided macros

I'm about to change the meaning (and name) of page->count.  Go through and fix
up all those places which are open-coding references to it.

Merge redhat.com:/spare/repo/linux-2.6
into redhat.com:/spare/repo/net-drivers-2.6

Merge bk://kernel.bkbits.net/gregkh/linux/i2c-2.6
into ppc970.osdl.org:/home/torvalds/v2.6/linux

Merge bk://kernel.bkbits.net/gregkh/linux/driver-2.6
into ppc970.osdl.org:/home/torvalds/v2.6/linux

Merge bk://kernel.bkbits.net/gregkh/linux/usb-2.6
into ppc970.osdl.org:/home/torvalds/v2.6/linux

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

Merge kroah.com:/home/greg/linux/BK/bleed-2.6
into kroah.com:/home/greg/linux/BK/i2c-2.6

[PATCH] I2C: Missed ixp42x -> ixp4xx conversion

Forgot to include this with my original patch a few weeks ago...

[PATCH] I2C: "probe" module param broken for it87 in Linux 2.6.6

Jean Delvare <khali@linux-fr.org> writes:
> So I'd suggest that you simply use the standard exit sequence in the
> it87 driver (the second one in your current patch). A patch for the 2.4
> driver would be appreciated as well.

OK.  I've attached a new version of the patch against linux-2.6.6.
I'll send a patch against current lm_sensors CVS removing the extra
exit command in a separate mail.

Greg KH <greg@kroah.com> writes:
> On Wed, May 12, 2004 at 04:38:03PM +0200, Bj?rn Mork wrote:
>> + if (!it87_find(&addr)) {
>> + printk("it87.o: new ISA address: 0x%04x\n", addr);
>
> That printk is wrong (no KERN_ level, or dev_printk() style use).
> Please fix it in your next revision of this patch.

Errh, I just added it to document my sloppyness.  It was never meant
to be in the patch I sent you.  Sorry.  Removed in the attached patch.
The style of these drivers seem to be "just working, making no noise"
so I assume informational printk's are unwanted.

[PATCH] I2C: ICH6/6300ESB i2c support

This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus).
In order to add this support I needed to patch pci_ids.h with the SMBus
DID's.  To keep things orginized I renumbered the ICH6 and ESB entries
in pci_ids.h.  I then patched the piix IDE and i810 audio drivers to
reflect the updated #define's.  I also removed an error from irq.c;
there was a reference to a 6300ESB DID that does not exist.

USB: convert visor to use module_param()

USB: convert pl2303 to use module_param()

USB: change usbserial core to use module_param()

Merge bk://linux-acpi.bkbits.net/linux-acpi-release-2.6.6
into ppc970.osdl.org:/home/torvalds/v2.6/linux

[PATCH] USB: hcd-pci suspend tweak

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.

[PATCH] sysfs_rename_dir-cleanup

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)

[PATCH] add ibmasm driver warning message

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

[PATCH] USB: ohci resume fix

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.

[PATCH] USB: compile fix for usbfs snooping

USB: remove get_usb_serial() as it's pretty much unneeded

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.

USB: remove serial_paranoia_check() function

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

USB: removed port_paranoia_check() call for usb serial drivers.

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

USB: remove magic number field from struct usb_serial as it's pretty useless.

USB: remove magic number field from usb_serial_port as it's pretty useless.

[PATCH] USB: usbhid calls itself "hid"

[PATCH] USB: Merge support for Keyspan UPR-112 USB serial adapter from 2.4 to 2.6

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

USB: add snooping capability to usbfs for control messages.

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

[PATCH] USB: fix ohci-hcd build error

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

[PATCH] USB: Don't delete interfaces until all are unbound

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.

[PATCH] USB: Patch to remove interface indices from devio.c

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

[PATCH] USB: missing probe() diagnostics for CDC Ethernet

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.

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

[PATCH] kobject/sysfs race fix

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

[PATCH] fix dev_printk to work even in the absence of an attached driver

[PATCH] kobject_set_name - error handling

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.

[PATCH] USB: cosmetic fixes for cdc-acm

[PATCH] USB: OHCI root hub suspend/resume/wakeup

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.

[PATCH] USB: khubd turns port power back on after reset

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.

[PATCH] USB: OHCI cleanups

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

[PATCH] USB: OHCI resume/reset stops deadlocking in PM code

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.

[PATCH] USB: fixes of assumptions about waitqueues

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

[PATCH] USB: more functional HCD PCI PM glue

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

[PATCH] USB: Accept devices with funky interface/altsetting numbers

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.

[PATCH] USB: EHCI power management updates

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.

[PATCH] USB Gadget: Fix file-storage gadget Request Sense length

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.

[PATCH] USB: fix media/dsbr100.c unused variable.

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

[PATCH] USB: Add class support to drivers/usb/misc/tiglusb.c

[PATCH] Add class support to drivers/net/wan/cosa.c

This patch adds sysfs class support to the Cosa driver. I have verified it
compiles but do not have the hardware to test it. If someone could that
would be helpful.

[PATCH] I2C: Rename hardware monitoring I2C class

Quoting myself:

> Mmm, I once proposed that I2C_ADAP_CLASS_SMBUS would be better renamed
> I2C_ADAP_CLASS_SENSORS (so I2C_CLASS_SENSORS now). What about that? I
> think it would be great to embed that change into your patch, so that
> the name changes only once.
>
> BTW, if HWMON is prefered to SENSORS, this is fine with me too, I
> have no strong preference.

Below is a patch that does that. I finally went for HWMON. Yes, it's
big, but it's actually nothing more than
s/I2C_CLASS_SMBUS/I2C_CLASS_HWMON/ (thanks perl -wip :)).

[PATCH] I2C: new i2c video decoder calls: saa7111 driver

Attached patch implements the i2c calls in the saa7111 driver.

The driver is still compatible with old behaviour, so the zr36067 driver
(the original user of the saa7111 module) doesn't need any changes.  I'll
probably gradually make everything use DECODER_INIT instead of 0 (that was
a nice hack back then) somewhere later.

Can I just remove '0' later on? Or are there official ABI rules for
stable kernel versions?

[PATCH] I2C: new i2c video decoder calls

Attached patch adds three new calls to the i2c video decoder API.  The changes
were requested by Michael (CC'ed) and approved by Gerd Knorr (v4l maintainer,
CC'ed).

Short explanation:

* INIT is a general initialization call with optional initialization data.
  Reason for this is that several i2c decoders (or general: clients) are being
  used by several adapters (main drivers), and in some cases, one adapter
  simply needs different settings than the other, either because the adapter
  is completely different or because the card was reverse engineered in a way
  that doesn't allow multiple adapters to run using the same original
  initialization data.  Michael faces such a problem right now.  Both he and
  me lack time to properly sit together and work out the exact details or a
  proper way to merge.

* VBI_BYPASS and GPIO set specific pins on the decoder.  This will be used
  in the saa7111 driver.  My driver (zr36067, original user of the saa7111
  driver) doesn't use any of this, but Michael's does.

[PATCH] I2C: kill duplicate includes in i2c bus drivers

Following a suggestion of Arthur Othieno, here is a trivial patch that
kills duplicate inclusions of config.h in four i2c bus drivers.

At first I was thinking of also removing inclusions of config.h wherever
it doesn't seem to be necessary but Eugene doesn't seem to think it's a
good idea. So I may give it a try later (in 2.7), but for now this
simple patch will be enough.

Module attributes: fix build error if CONFIG_MODULE_UNLOAD=n

Thanks to Andrew Morton for pointing this out to me.

USB: make functions static in usb drivers that should be

Thanks to Tridge's findstatic.pl script for helping find these.

[PATCH] M68k superfluous whitespace

M68k: Remove superfluous whitespace that hurts my eyes with `let
c_space_errors=1' in vim. This includes correcting trailing whitespace and
spaces in front of tabs. `diff -urNbB' shows no difference before/after.

[netdrvr dmfe] netpoll support

[netdrvr gt961000eth] remove useless MOD_{INC,DEC}_USE_COUNT

*grr* - this one slipped in after my last round of audits it seems.

[PATCH] 8139too not running s3 suspend/resume pci fix

From: "Adrian Yee" <brewt-linux-kernel@brewt.org>

Having an 8139 based device in my notebook, I often switch between it and
wireless.  The problem is that the 8139too driver does not save/restore the
pci configuration of the card if the device isn't running.  This simple
patch moves the save/restore code so that the code runs regardless of
whether or not the device is running.

I looked at other drivers and they all seem to do the same thing.  Is there
a reason why this isn't done like in the patch?

[PATCH] lance.c: fix for card with signature 0x52 0x49

From: Vesselin Kostadiov <vesselin@alphawave.com.au>

Problem: The lance.c driver did not work with my Racal Interlan EtherBlaster
card.

More info: I found that my card has a signature 0x52 0x49 that was not
recognized by the driver.

Explanation: Following your suggestion I created a static table with possible
signatures, not too different from the table in ni65.c.  The updated code
compares the first byte of the cards signature with the first byte of the
signatures from the table.  It this succeeds then it reads the second byte and
compares the whole signature with the values from the table.  This way the
minimal I/O reads approach is maintained.

Side effect: The previous version would missdetect cards with signatures 0x52
0x57 and 0x57 0x44.  This has been fixed as well.

[PATCH] kill warning in r8169

[libata] Maintainer annotations

In MAINTAINERS and in individual low-level drivers.

[libata] preparation for writeback caching support

* bug fix: make sure 'nsect' member of struct ata_queued_cmd is
initialized each time a cmd is re-used.  Only affects PIO data xfers,
which nobody uses.
* slightly change the way a device's flags are printed out.  currently
the only flag is 'lba48', but soon 'wcache' will appear also.
* add WB-cache-related constants and macros to linux/ata.h

[ACPI] handle _CRS outside _PRS -- even when non-zero
avoid sharing IRQ12
http://bugzilla.kernel.org/show_bug.cgi?id=2665

[PATCH] radeon: fix overlapping copyarea

This fixes a corruption problem with overlapping copyarea()'s
in the radeon driver.

[PATCH] ppc64: extra barrier in I/O operations

At the moment, on PPC64, the instruction we use for wmb() doesn't
order cacheable stores vs. non-cacheable stores.  (It does order
cacheable vs. cacheable and non-cacheable vs. non-cacheable.)  This
causes problems in the sort of driver code that writes stuff into
memory, does a wmb(), then a writel to the device to start a DMA
operation to read the stuff it has just written to memory.

This patch solves the problem by adding a sync instruction before the
store in the write* and out* macros.  The sync is a full barrier that
orders all loads and stores, cacheable or not.  The patch also moves
the eieio instruction that we had after the store to before the load
in the read* and in* macros.  With the sync before the store, we don't
need an eieio as well in a sequence of stores, but we still need an
eieio between a store and a load.

I think it is better to do this than to turn wmb() into a full memory
barrier (a sync instruction) because the full barrier is slow and
isn't needed with the sync in the write*/out* macros.  This way,
write*/out* are fully ordered with respect to preceding loads and
stores, which is what driver writers expect, and we avoid penalizing
users of wmb() who are only doing cacheable stores.

Merge bk://drm.bkbits.net/drm-2.6
into ppc970.osdl.org:/home/torvalds/v2.6/linux