By Kai Germaschewski:

 "Well, I have another solution, which doesn't need additional Makefile
  magic or anything.

  I just put the module name into each .o file where <linux/module.h> is
  included. Putting it into the section .gnu.linkonce.modname has the effect
  that even for multi-part modules, we only end up with one copy of the
  name.

  Caveat: I'm using the preprocessor macro KBUILD_MODNAME to know what to
  put into .gnu.linkonce.modname. The following used to happen:

  (drivers/isdn/eicon/Makefile)

  divas-objs := common.o Divas_mod.o ...
  eicon-objs := common.o eicon_mod.o ...

  Divas_mod.o is compiled with -DKBUILD_MODNAME=divas
  eicon_mod.o is compiled with -DKBUILD_MODNAME=eicon
  common.o is compiled with -DKBUILD_MODNAME=divas_eicon

  So in the case above, both divas.o and eicon.o would end up with
  a .gnu.linkonce.modname section containing "divas_eicon"

  My fix to this is to not define KBUILD_MODNAME when compiling an object
  whilch will be linked into more than one module - so common.o gets no
  .gnu.linkonce.modname section at all. Works fine here.

  Now, doing this I remove one of the reasons why we would need modules
  linked as '.ko' ;), but it seems much cleaner than generating a temporary
  file, using objcopy etc."

On the v850, the elf toolchain uses a `_' prefix for all user symbols
(I'm not sure why, since most toolchains seem to have dropped this sort
of thing).

The attached patch adds the ability to deal with this, if the macro
MODULE_SYMBOL_PREFIX is defined by <asm/module.h>.  This only affects
places where symbol names come from the user, e.g., EXPORT_SYMBOL, or
the explicit symbol-names used in kernel/module.c itself.

[Tweaked a little by Rusty, original by Miles Bader]

This patch allows the new depmod to generate the USB & PCI hotplug
tables.  Greg Banks and I are (slowly) working on a better solution, but
allows the old-style "modules.pcimap" etc.  to be generated in the short
term.

This patch adds a "__mod_XXX_table" symbol which is an alias to the
module table, rather than a pointer.  This makes it relatively trivial
to extract the table.  Previously, it required a pointer dereference,
which means the relocations must be applied, which is why the old depmod
needs so much of modutils (ie.  it basically links the whole module in
order to find the table).

The old depmod can still be invoked using "-F System.map" to generate
the tables (there'll be lots of other warnings, and it will generate a
completely bogus modules.dep, but the tables should be OK.)

Two fixes.  Firstly, set ALLOC on the right section so we actually
keep the symbol names and don't deref a freed section, and secondly
get the symbol size (more) correct.

From Andrew Morton

into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5

Currently, uart_get_divisor() and uart_get_baud_rate() take a tty
structure.  We really want them to take a termios structure so we
can avoid passing a tty structure all  the way down to the low level
drivers.

In order to do this, we need to be able to convert a termios
structure to a numeric baud rate - we provide tty_termios_baud_rate() in
tty_io.c for this purpose.  It performs a subset of the
tty_get_baud_rate() functionality, but without any "alt_speed"
kludge.

We finally export uart_get_baud_rate() and uart_get_divisor() to for
low level drivers to use.  We now have all the functions in place
to support ports which want to have access to the real baud rate
rather than a divisor value.

uart_get_divisor() calculates the divisor for standard uarts, and
will eventually become a helper function for low level port drivers.

This is another step towards moving the divisor calculations into
the low level drivers, thereby allowing the faster baud rates
mentioned in the previous cset.  Moving this field to uart_port
means that the low level drivers do not have to know about the
uart_state structure.

We provide a new function, uart_get_baud_rate(), to return the
desired numeric baud rate from the uart_port and tty structures.
This allows us to:

1. localise the 38400 alternate speed kludge to one area.
2. support faster baud rates than the usual baud_base / desired_rate
   calculations in the future (eventually allowing the use of the
   magic divisors in 8250.c.)

We originally checked for failure by checking if the returned code
was non-zero.  Strictly, it should be a negative value.

Patch from Randolph Chung, slightly modified by rmk.

When displaying the details of memory mapped serial ports, we want to show
some sane base value.  The cookie returned from ioremap can be meaningless
to users (and developers), especially when the cookie could be a dynamically
allocated virtual address.

The more useful cookie is the value passed into ioremap.  We already have
support for handling this cookie internally - we haven't allowed the PCI
probe module to hand it to the higher levels until now.

Patch from Zwane Mwaikambo, fixed by rmk, comments by rmk.

SIIG cards have parallel ports in addition to serial ports.  We therefore
probe the cards in parport_serial.c and call the serial specific probe
functions in 8250_pci.c

This is the second half of a patch that was applied in 2.5.50 to
parport_serial by others without the corresponding 8250_pci.c changes.

During initialisation of 8250 serial, we scan a list of ISA ports and
register any ports.  We then perform PNPBIOS scanning, which re-registers
ttyS0.  Unfortunately, if devfs is enabled, devfs reports an error because
we try to create two tts/0 entries.

Therefore, when adding a new port we check that it has not been detected
before attempting to probe the port and register it with devfs (via the
tty layer.)

Currently scsi_register_host silently fixes up missing initializations
of max_sectors and release.  Add some printks complaining about this
so we can get rid of it sooner or later.

The same for sr (I didn't actually had a chance to actually test this,
but it's the same change as in sd).

This is the final patch to make sd work properly in a hotplug
enviroment.  Add a bitmap for currently used disks so that we
can properly reuse dev_t when a disk is hot-unplugged.

While at that add support for the eight additional majors
allocated to sd in the latest devices.txt [1].

If only register_blkdev finally died we could nuke almost all
knowledge of majors/minors from sd...

[1] http://www.lanana.org/docs/device-list/devices.txt

(1) move all bdev methods in one place instead of spreading them all
    around the file
(2) consistant naming: everything is sd_<operation> now
(3) use scsi_device_get/scsi_device_put
(4) remove bogus checks scsi_disk->device set, since 2.5.4x it always is
(5) clean up some coding style issues

Two new helpers: scsi_device_get and scsi_device_put that get/release a
reference to the underlying HBA driver and increment/decrement
->access_count.  Cleanup ->attach/->detach routines in the upper layer
drivers a bit to consolidate the error pathes once we're cleaning them
up.

->attach and ->detach in upper layer drivers are mandatory now (not
having them would be rather pointless).

(note that the sd.c changes are not in this patch, it'll be part of
my next, bigger patch)

I have attached an updated combined patch of my previously posted sysfs
changes. 

This patch is against linux-scsi.bkbits.net/scsi-misc-2.5

This patch contains these updates:
	- update to osst.c to support sysfs cleanups.
	- oops fix in osst.c detach if no device attached. A better
	  method than this quick fix is needed.
	- removed scsi_bus_hotplug function do to bug and not really
	  needed now as default gives path data. If needed in future can
	  be added with better definition.

-andmike

into mulgrave.(none):/home/jejb/BK/scsi-misc-new-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

into kroah.com:/home/linux/linux/BK/gregkh-2.5

1-fix-lowlat:

QA found that running all four ports at 460800 would drop data. I
traced it to data being dropped in the read callback because the flip
buffers were full. Turning on the low latency flag fixed things.

2-fix-taint

A side-effect of turning on low latency; the interrupt context from
the callback is now passed through to the tty layer, passing it on to
calls back into usb-serial.c. Which causes deadlocks when trying to
re-acquire the per-port semaphore. We've already talked about this.
This patch is my work-around for the usb-serial.c brokenness.
Basically, implemement a buffering scheme, and schedule a software
interrupt to handle the data handoff to the tty layer sometime later.
urb_pool_size defaults to 8, but is a module parameter and can be
modified at runtime.
The buffering is needed so that the driver can run while data is
waiting to be processed, but I could have used the tty layer
scheduling instead of doing my own by turning off low latency.
However, I looked at the tty layer and it seems to me that there's
nothing preventing a really fast device from flipping one buffer,
flipping the next, and flipping back to the still full buffer from
before (actually, the flip just gets scheduled for later), so my
driver needs to be able to hold onto buffered data and schedule them
for processing later anyway. So, might as well leave low_latency on.


diff -Naur linux-2.5.49-0-virgin/drivers/usb/serial/whiteheat.c linux-2.5.49-1-fix-
lowlat/drivers/usb/serial/whiteheat.c

Attached is a patch that changes the 2.5.x disconnect to be similar to
2.4.x disconnect. This doesn't fix the race, but does shrink the
window such that I've never seen it trigger, even under testing
designed to do that.

There doesn't seem to be a good way to fix the race. The fix should be
to have _disconnect force any sleeping semaphore holders to run to
completion between the end of the loop in the patch below and the spot
where the underlying memory is freed, but I don't see a way to do
that.


diff -Naur linux-2.5.49-2-fix-taint/drivers/usb/serial/usb-serial.c linux-2.5.49-3-fix-drvdata/drivers/usb/serial/usb-
serial.c

This patch cleans up the vicam_decode_color function by removing
unused/useless variables and combining the two "x" loops inside the
y loop into one. It also reduces the number of times that the "x"
loop occurs from 512 to 320 which should provide a decent speed
increase. It also fixes a bug in the y loop that wrote beyond its bound.

After a little absence, here's a patch to bring the Philips Webcam driver up
to version 8.9 (skipping 8.8 which has been available as a download on my
website for a while).

This patch is against 2.5.49, and includes some of the following:
* New USB IDs for Logitech and Visionite webcams.
* Better URB link/unlink sequence when opening/closing device
  and switching resolutions.
* Adding probe for CCD/CMOS sensor type.
* Removed remnants of YUV420 palette stuff.

Also updated the description in 'Kconfig'.