[VLAN]: Fix early vlan adding leads to not functional device
OK, I can see what's happening here. eth0 doesn't detect link-up until
after a few seconds, so when the vlan interface is opened immediately
after eth0 has been opened, it inherits the link-down state. Subsequently
the vlan interface is never properly activated and are thus unable to
transmit any packets.
dev->state bits are not supposed to be manipulated directly. Something
similar is probably needed for the netif_device_present() bit, although
I don't know how this is meant to work for a virtual device.
Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Hund [Mon, 27 Jun 2005 20:44:22 +0000 (22:44 +0200)]
[PATCH] USB: add ldusb driver
The following driver provides complete interrupt-in and interrupt-out
reports (raw data) to a user program. Until now it uses the
HIDIOCGDEVINFO ioctl call, because I don't know better :-(. Perhaps, it
will be ok for you - and I will be happy, if you assign 8 minor numbers.
I have tested it in several environments and it works very well for me.
However, it has a problem with two or more devices at the same hub, if
the two or more devices need 1 ms interrupt-in transfers. Unfortunately
more than one interrupt-in transfer every ms isn't possible (ehci
driver?). This is why the min_interrupt_in_interval and
min_interrupt_out_interval are increased to 2 ms (see the corresponding
module parameters). This way, I can use two devices simultaneously at
the same hub.
Signed-off-by: Michael Hund <mhund@ld-didactic.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
brian@murphy.dk [Wed, 29 Jun 2005 23:53:29 +0000 (16:53 -0700)]
[PATCH] USB: fix usb reference count bug in cdc-acm driver
This increases the reference count on the usb cdc acm control interface
which is referred to by the tty interface provided by the driver. This
allows the deferred removal of the tty after the physical device is
disconnected if the tty is held open at the time of disconnection.
This adds another CDC descriptor type to <linux/usb_cdc.h>; the main claim
to fame for this is that some Motorola phones include it. It's not currently
needed by any driver code; included for completeness.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A patch re-organizing some parts of root hub initialization deleted the
code initializing the bus-neutral reboot/shutdown notifier for OHCI.
This patch just restores that deleted code.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The recent "pm_message_t" changes removed functionality from the Linux
PM framework. This patch removes it from the OMAP OHCI too, removing
the distinction between (previous) PM_SUSPEND_MEM and PM_SUSPEND_DISK
state transitions ... now the only suspend semantics supportable are
what was previously PM_SUSPEND_DISK (4) and is now "PMSG_SUSPEND" (3).
This defect was found automatically by Coverity Prevent, a static analysis
tool.
(akpm: this code should be shot. Field `bitmap' doesn't exist in struct
usb_hub_descriptor. And this .c file is #included in
drivers/usb/host/ohci-hcd.c, and someone somewhere #defines `bitmap' to
`DeviceRemovable'.
>From a maintainability POV it would be better to memset the whole array
beforehand - I changed the patch to do that)
Michael Downey [Mon, 27 Jun 2005 17:48:26 +0000 (11:48 -0600)]
[PATCH] USB: add driver for Keyspan Digital Remote
This driver is a basic keypress input driver for the Keyspan Digital
Remote with part number UIA-11. Currently there is an older remote with
part number UIA-10 which isn't supported by this driver. Support for
the older UIA-10 could be added but a binary file is required to be
download to the device, and I don't have that file. I also don't have a
UIA-10 device so I wouldn't be able to test any of the changes.
Signed-off-by: Michael Downey <downey@zymeta.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Morton [Mon, 27 Jun 2005 00:18:46 +0000 (17:18 -0700)]
[PATCH] USB: net2280 warning fix
drivers/usb/gadget/net2280.c: In function 'show_registers':
drivers/usb/gadget/net2280.c:1501: warning: assignment discards qualifiers from pointer target type
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Olav Kongas [Thu, 23 Jun 2005 17:25:36 +0000 (20:25 +0300)]
[PATCH] USB: Fix kmalloc's flags type in USB
Greg,
This patch fixes the kmalloc() flags argument type in USB
subsystem; hopefully all of its occurences. The patch was
made against patch-2.6.12-git2 from Jun 20.
Cleanup of flags for kmalloc() in USB subsystem.
Signed-off-by: Olav Kongas <ok@artecdesign.ee> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Olav Kongas [Thu, 23 Jun 2005 17:12:24 +0000 (20:12 +0300)]
[PATCH] USB: isp116x-hcd cleanup
Sorry that it took so long. Here comes a cleanup patch that
addresses the remarks by Alexey Dobriyan about
gregkh-usb-usb-isp116x-hcd-add.patch EXCEPT the remark about
the typecasting of mem_flags argument for kcalloc; this will
be addressed in a later patch.
OlavCleanup of isp116x-hcd.
Signed off by: Olav Kongas <ok@artecdesign.ee> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Pete Zaitcev [Sat, 25 Jun 2005 21:32:59 +0000 (14:32 -0700)]
[PATCH] USB: Patch to make usbmon to print control setup packets
Make usbmon to print Setup packets of Control transfers. This is useful
when debugging enumeration issues.
This is a change to the trace format which is not fully compatible.
A parser has to look at the data length word now. If that word is
a character like 's', read setup packet before proceeding with data.
I decided not to bump the API tag for this because not many such
parsers exist at this point.
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Duncan Sands [Thu, 23 Jun 2005 07:37:56 +0000 (09:37 +0200)]
[PATCH] USB ATM: fix line resync logic
We map states 0x00 and 0x10 to the ATM_PHY_SIG_LOST flag. The current logic fails to
resync the line if we get state 0x10 followed by 0x00, since we only resync the line
when the state is 0x00 and the flag changed. Doubly fixed by (1) always resyncing the
line when the state is 0x00 even if the state didn't change, and (2) keeping track of
the last state, not just the flag. We do (2) as well as (1) in order to get better log
messages.
This is a tweaked version of the original patch by Aurelio Arroyo.
Ian Abbott [Mon, 20 Jun 2005 15:45:42 +0000 (16:45 +0100)]
[PATCH] USB ftdi_sio: reduce device id table clutter
ftdi_sio: Use a single usb_device_id table and detect the type of chip
programatically. The table also flags devices requiring special
initialization. The patch makes the driver about 10K smaller and makes
it easier to add new device IDs.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sam Ravnborg [Tue, 12 Jul 2005 04:13:56 +0000 (21:13 -0700)]
[NET]: move config options out to individual protocols
Move the protocol specific config options out to the specific protocols.
With this change net/Kconfig now starts to become readable and serve as a
good basis for further re-structuring.
The menu structure is left almost intact, except that indention is
fixed in most cases. Most visible are the INET changes where several
"depends on INET" are replaced with a single ifdef INET / endif pair.
Several new files were created to accomplish this change - they are
small but serve the purpose that config options are now distributed
out where they belongs.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Tue, 12 Jul 2005 04:03:49 +0000 (21:03 -0700)]
[NET]: add a top-level Networking menu to *config
Create a new top-level menu named "Networking" thus moving
net related options and protocol selection way from the drivers
menu and up on the top-level where they belong.
To implement this all architectures has to source "net/Kconfig" before
drivers/*/Kconfig in their Kconfig file. This change has been
implemented for all architectures.
Device drivers for ordinary NIC's are still to be found
in the Device Drivers section, but Bluetooth, IrDA and ax25
are located with their corresponding menu entries under the new
networking menu item.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Olaf Kirch [Tue, 12 Jul 2005 04:01:42 +0000 (21:01 -0700)]
[IPV4]: Prevent oops when printing martian source
In some cases, we may be generating packets with a source address that
qualifies as martian. This can happen when we're in the middle of setting
up the network, and netfilter decides to reject a packet with an RST.
The IPv4 routing code would try to print a warning and oops, because
locally generated packets do not have a valid skb->mac.raw pointer
at this point.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Evgeniy Polyakov [Thu, 30 Jun 2005 18:52:38 +0000 (22:52 +0400)]
[PATCH] w1: fix CRC calculation on bigendian platforms.
In the 2.6.13-rc1 code the "rn" structure is in the wrong-endianness
when passed to w1_attach_slave_device(). This causes problems like the
family and crc being swapped around.
Adrian Bunk [Thu, 30 Jun 2005 22:17:27 +0000 (00:17 +0200)]
[PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSOR
On Thu, Jun 30, 2005 at 11:47:09PM +0200, Sebastian Pigulak wrote:
> I've tried patching linux-2.6.13-RC1 with patch-2.6.13-rc1-git2 and
> building atxp1(it allows Vcore voltage changing) into the kernel.
> Unfortunately, the kernel compilation stops with:
>
> LD init/built-in.o
> LD vmlinux
> drivers/built-in.o(.text+0x92298): In function `atxp1_detect':
> : undefined reference to `i2c_which_vrm'
> drivers/built-in.o(.text+0x921ae): In function `atxp1_attach_adapter':
> : undefined reference to `i2c_detect'
> make: *** [vmlinux] B??d 1
> ==> ERROR: Build Failed. Aborting...
>
> Could someone have a look at the module and possibly fix it up?
SENSORS_ATXP1 must select I2C_SENSOR.
Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Sat, 25 Jun 2005 09:37:40 +0000 (11:37 +0200)]
[PATCH] I2C: Clarify the usage of i2c-dev.h
Upon suggestion by Nils Roeder, here is an update to the i2c
documentation to clarify which header files user-space applications
relying on the i2c-dev interface should include.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The I2C stack has long had "id" fields, of rather dubious utility, in
many data structures. This removes mention of one of them from the
documentation about how to write an I2C driver, so that only drivers
that really need to use them (probably old/legacy code) will have any
reason to use this field.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 1 Jul 2005 12:28:15 +0000 (14:28 +0200)]
[PATCH] I2C: m41t00: fix incorrect kfree
Here is a simple path fixing an incorrect kfree in the m41t00 i2c chip
driver. The current code happens to work by accident, but the freed
pointer isn't the one which was allocated in the first place, which
could cause problems later.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 24 Jun 2005 19:14:16 +0000 (21:14 +0200)]
[PATCH] I2C: New max6875 driver may corrupt EEPROMs
After a careful code analysis on the new max6875 driver
(drivers/i2c/chips/max6875.c), I have come to the conclusion that this
driver may cause EEPROM corruptions if used on random systems.
The EEPROM part of the MAX6875 chip is accessed using rather uncommon
I2C sequences. What is seen by the MAX6875 as reads can be seen by a
standard EEPROM (24C02) as writes. If you check the detection method
used by the driver, you'll find that the first SMBus command it will
send on the bus is i2c_smbus_write_byte_data(client, 0x80, 0x40). For
the MAX6875 it makes an internal pointer point to a specific offset of
the EEPROM waiting for a subsequent read command, so it's not an actual
data write operation, but for a standard EEPROM, this instead means
writing value 0x40 to offset 0x80. Blame Philips and Intel for the
obscure protocol.
Since the MAX6875 and the standard, common 24C02 EEPROMs share two I2C
addresses (0x50 and 0x52), loading the max6875 driver on a system with
standard EEPROMs at either address will trigger a write on these
EEPROMs, which will lead to their corruption if they happen not to be
write protected. This kind of EEPROMs can be found on memory modules
(SPD), ethernet adapters (MAC address), laptops (proprietary data) and
displays (EDID/DDC). Most of these are hopefully write-protected, but
not all of them.
For this reason, I would recommend that the max6875 driver be
neutralized, in a way that nobody can corrupt his/her EEPROMs by just
loading the driver. This means either deleting the driver completely, or
not listing any default address for it. I'd like this to be done before
2.6.13-rc1 is released.
Additionally, the max6875 driver lacks the 24RF08 corruption preventer
present in the eeprom driver, which means that loading this driver in a
system with such a chip would corrupt it as well.
Here is a proposed quick patch addressing the issue, although I wouldn't
mind a complete removal if it makes everyone feel safer. I think Ben
has plans to replace this driver by a much simplified one anyway.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Thu, 23 Jun 2005 20:18:08 +0000 (22:18 +0200)]
[PATCH] I2C: Strip trailing whitespace from strings
Here is a simple patch originally from Denis Vlasenko, which strips a
useless trailing whitespace from 8 strings in 4 i2c drivers. Please
apply, thanks.
This includes various small cleanups and fixes to the TPS 6501x driver that
came mostly from review feedback by Jean Delvare; thanks Jean! Also some
goofy whitespace gets fixed.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Denis Vlasenko [Wed, 22 Jun 2005 07:25:13 +0000 (10:25 +0300)]
[PATCH] I2C: Coding style cleanups to via686a
On Wednesday 22 June 2005 08:17, Greg KH wrote:
> [PATCH] I2C: Coding style cleanups to via686a
>
> The via686a hardware monitoring driver has infamous coding style at the
> moment. I'd like to clean up the mess before I start working on other
> changes to this driver. Is the following patch acceptable? No code
> change, only coding style (indentation, alignments, trailing white
> space, a few parentheses and a typo).
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nice.
You missed some. This one is on top of your patch:
Current assign_irq_vector() will panic if interrupt vectors is running
out. But I think how to handle the case of lack of interrupt vectors
should be handled by the caller of this function. For example, some
PCI devices can raise the interrupt signal via both MSI and I/O
APIC. So even if the driver for these device fails to allocate a
vector for MSI, the driver still has a chance to use I/O APIC based
interrupt. But currently there is no chance for these driver to use
I/O APIC based interrupt because kernel will panic when
assign_irq_vector() fails to allocate interrupt vector.
The following patch changes assign_irq_vector() for ia64 to return
-ENOSPC on error instead of panic (as i386 and x86_64 versions do).
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
David S. Miller [Sun, 10 Jul 2005 23:55:48 +0000 (16:55 -0700)]
[SPARC64]: Pass regs and entry/exit boolean to syscall_trace()
Also fix a bug in 32-bit syscall tracing. We forgot to update
this code when we moved over to the convention that all 32-bit
syscall arguments are zero extended by default.
Signed-off-by: David S. Miller <davem@davemloft.net>
Stephen Rothwell [Sun, 10 Jul 2005 13:12:01 +0000 (23:12 +1000)]
[PATCH] remove asm-xtensa/ipc.h
Now that sys_ipc has been removed from xtensa, asm/ipc.h is no longer
needed for that architecture. Not tested, but obviously correct. This
file is included only from arch code and this patch also removes the only
inclusion.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ben Collins [Sun, 10 Jul 2005 00:01:23 +0000 (20:01 -0400)]
[PATCH] Sync up ieee-1394
Lots of this patch is trivial code cleanups (static vars were being
intialized to 0, etc).
There's also some fixes for ISO transmits (max buffer handling).
Aswell, we have a few fixes to disable IRM capabilites correctly. We've
also disabled, by default some generally unused EXPORT symbols for the
sake of cleanliness in the kernel. However, instead of removing them
completely, we felt it necessary to have a config option that allowed
them to be enabled for the many projects outside of the main kernel tree
that use our API for driver development.
The primary reason for this patch is to revert a MODE6->MODE10 RBC
conversion patch from the SCSI maintainers. The new conversions handled
directly in the scsi layer do not seem to work for SBP2. This patch
reverts to our old working code so that users can enjoy using Firewire
disks and dvd drives again.
We are working with the SCSI maintainers to resolve this issue outside
of the main kernel tree. We'll merge the patch once the SCSI layer's
handling of the MODE10 conversion is working for us.
Tony Lindgren [Sun, 10 Jul 2005 18:58:08 +0000 (19:58 +0100)]
[PATCH] ARM: 2798/1: OMAP update 2/11: Change ARM Kconfig to support omap1 and omap2
Patch from Tony Lindgren
This patch by Paul Mundt and other OMAP developers modifies
ARM specific Kconfig to allow sharing code between OMAP1 and
OMAP2 architectures.
In order to share code between OMAP1 and OMAP2, all OMAP1
specific code is moved into mach-omap1 directory in the
following patch. A new mach-omap2 directory will be added
later on.
Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[PATCH] ARM: 2796/1: Fix ARMv5[TEJ] check in MMU initalization
Patch from Deepak Saxena
The code in mm-armv.c checks for the condition (cpu_architecture()<= ARMv5)
in a few places but should be checking for ARMv5TEJ as the MMU is shared
across all v5 variations.
Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
projects / linux-beck.git / log