Here's 3 patches that adds USB-IP functionality code to the kernel tree. It is against 2.6.27-rc4, and has been added to the -staging tree. If there are no major objections, I'll also queue it up in the usb tree for submission into 2.6.28. The code is based on Takahiro's great work that has been sitting outside of the kernel for many many years now. Brian Merrell took the most recent version of the code, cleaned it up and sent it to me. I did more cleanup and split the patch into 3 pieces, mak...

From: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> This adds the USB IP client driver Brian Merrell cleaned up a lot of this code and submitted it for inclusion. Greg also did a lot of cleanup. Signed-off-by: Brian G. Merrell <bgmerrell@novell.com> Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/ip/Kconfig | 10 drivers/usb/ip/Makefile | 3 drivers/usb/ip/stub.h ...

From: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> This adds the common functions needed by both the host and client side of the USB/IP code. Brian Merrell cleaned up a lot of this code and submitted it for inclusion. Greg also did a lot of cleanup. Signed-off-by: Brian G. Merrell <bgmerrell@novell.com> Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/Kconfig | 2 driv...

This patch adds the Intel Ibex Peak (PCH) SMBus Controller DeviceIDs. Changes are reflected in i2c-i801.c in response to updates to pci_ids.h. The SMBus Controller is now referred to as PCI_DEVICE_ID_INTEL_PCH_SMBUS, a change to the old naming convention of PCI_DEVICE_ID_INTEL_PCH_x. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- linux-2.6/Documentation/i2c/busses/i2c-i801.orig 2008-08-28 10:11:27.000000000 -0700 +++ linux-2.6/Documentation/i2c/busses/i2c-i801 2008-08-28 10:25:24....

Esteemed kernel hackers, To follow is my third pass at MIPS watch register support. This version has been tested on: * MIPS 4KEc (mips32) with a single set of watch registers watchhi not reporting I, R, and W conditions. * MIPS 4KEc (mips32r2) with four sets of watch registers. * R5000 SGI O2 (mips4 64bit) with no watch register support. The patches are against 2.6.27-rc4 Changes from the previous version: * Agreement from gdb maintainers that the ptrace interface is workable...

Here we hook up the scheduler. Whenever we switch to a new process, we check to see if the watch registers should be installed, and do it if needed. Signed-off-by: David Daney <ddaney@avtrex.com> --- include/asm-mips/system.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-mips/system.h b/include/asm-mips/system.h index a944eda..cd30f83 100644 --- a/include/asm-mips/system.h +++ b/include/asm-mips/system.h @@ -20,6 +20,7 @@ #include <asm/cmp...

Probe for watch register characteristics, and report them in /proc/cpuinfo. Signed-off-by: David Daney <ddaney@avtrex.com> --- arch/mips/kernel/cpu-probe.c | 2 ++ arch/mips/kernel/proc.c | 10 ++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index 335a6ae..d0d07b8 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -21,6 +21,7 @@ #include <asm/fpu.h> #...

This is automatically set for all MIPS32 and MIPS64 processors. Signed-off-by: David Daney <ddaney@avtrex.com> --- arch/mips/Kconfig | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 4da736e..f5b3fca 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1272,6 +1272,13 @@ config CPU_SUPPORTS_32BIT_KERNEL config CPU_SUPPORTS_64BIT_KERNEL bool +# +# Set to y for ptrace access to watch registers. +# +...

The CPA test code uses _PAGE_UNUSED1, so make sure its obvious. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/mm/pageattr-test.c | 6 +++--- include/asm-x86/pgtable.h | 2 ++ 2 files changed, 5 insertions(+), 3 deletions(-) =================================================================== --- a/arch/x86/mm/pageattr-test.c +++ b/arch/x86/mm/pageattr-test.c @@ -32,7 +32,7 @@ GPS = (1<<30) }; -#define PAGE_TESTBIT __pgprot(_PAGE_...

From: Brice Goglin <Brice.Goglin@inria.fr> I think we should rather have some kind of generic thing in the IRQ layer that allows specifying the usage model of the device's interrupts, so that the IRQ layer can choose a default affinities. I never notice any of this complete insanity on sparc64 because we flat spread out all of the interrupts across the machine. What we don't want it drivers choosing IRQ affinity settings, they have no idea about NUMA topology, what NUMA node the PCI cont...

can you send out whole boot log? with "debug initcall_debug" http://people.redhat.com/mingo/tip.git/readme.txt YH --

so could let BAR res register at first, or even pnp? v2: insert e820 reserve resources before pnp_system_init Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/e820.c | 20 ++++++++++++++++++-- arch/x86/pci/i386.c | 3 +++ include/asm-x86/e820.h | 1 + 3 files changed, 22 insertions(+), 2 deletions(-) Index: linux-2.6/arch/x86/kernel/e820.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820.c ++...

On Thu, Aug 28, 2008 at 1:40 PM, Linus Torvalds David, can you test attached patch? also you may try to revert the old patch. YH

great - i've done the revert of a2bd7274b471 and have applied your patch and pushed it out into -tip. David, could you please test whether tip/master works for you out of box? Ingo --

Now that file capabilities can be turned off at boot, go ahead and compile them into the kernel by default by making CONFIG_SECURITY_FILE_CAPABILITIES=y the default. Note that the boot flag no_file_caps must be specified to turn file capabilities off, as by default they are on. So the default behavior is in fact changed. Signed-off-by: Serge Hallyn <serue@us.ibm.com> --- security/Kconfig | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/security/Kconfig b/...

so could let BAR res register at first, or even pnp? Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/e820.c | 20 ++++++++++++++++++-- arch/x86/pci/i386.c | 3 +++ include/asm-x86/e820.h | 1 + 3 files changed, 22 insertions(+), 2 deletions(-) Index: linux-2.6/arch/x86/kernel/e820.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820.c +++ linux-2.6/arch/x86/kernel/e820.c @@ -1271,13 +1271,15 @@ ...

My thinking is that if we run into a region which is reserved in e820 but points to a real BAR, we would want to keep that BAR pinned, since a legitimate BIOS might use this mechanism to indicate that the device implemented by that BAR is used by SMM or ACPI. If not, in most cases we will only have wasted some address space. The sucky case, of course, would be an uninitialized BAR pointing into unusable address space which happens to be reserved in e820. This seems very difficult to I s...

I believe you are right. I think the key bit here is that if the IO or MEM bit is enabled, it's likely to be initialized. The PCI specs say that BARs should come out of reset initialized to zero, but I know for a fact that at least several Broadcom chips don't -- however, the combination of BAR and enable bits should be enough of a sentry. -hpa --

On Thu, 28 Aug 2008 09:24:42 -0700 (PDT) Good point :) The Kconfig system doesn't presently know the name of the module, but that could be added. eg: config BMAC tristate "BMAC (G3 ethernet) support" depends on PPC_PMAC && PPC32 + modulename bmac select CRC32 help Say Y for support of BMAC Ethernet interfaces. These are used on G3 computers. - To compile this driver as a module, choose M here: the module - will be called bmac. Any sane organisation would ...

Sorry for being destructive, but 6 years after ALSA went into the kernel we are slightly approaching the point where all applications support ALSA. The application you list on your webpage is UML host sound support, and I'm wondering why you don't fix that instead of working on a cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. ...

I think that's probably another bad example... I would think serial port emulation would be better handled by ptys, and/or a specific serial port emulation module. The big problem with using ptys for serial port emulation is that they currently don't handle BREAK at all. -hpa --

Why? Because there is a lot of complexity in the tty layer, and there is no point in replicating the entire tty layer with all its ioctls through a fragile user-space emulator. For cases like this, a pty is easier (your daemon opens /dev/ptmx, and then symlinks the appropriate Indeed. It would be nice to fix, because it would make implementing serial ports as ptys+userspace a much more capable replacement. It's not trivial, though, because the interpretation of the BREAK has to be done...

Hi Neil, Commit 2b25000bf5157c28d8591f03f0575248a8cbd900 ("Restore force switch of md array to readonly at reboot time.") causes a reboot/shutdown to hang indefinitely on my box. Reverting this single commit makes the problem go away. It was first released with 2.6.27-rc3, I believe, and so this is a regression vs 2.6.26 (Rafael CCed). I think the problem might be because my rootfs is on a RAID5 and my distro fails to stop it completely before halt/reboot. Please let me know if there's an...

Hi, kmemcheck is the kernel patch that detects use of uninitialized memory. kmemcheck reports eagerly, that is, any load of uninitialized memory will be reported, even though the bits in question will be thrown away later (before they are used in making a decision). One problem that we have encountered (which generates a false positive report) is that of bitfield accesses. In particular, whenever a bit of a bitfield is set (or cleared), the whole byte may be loaded before the specific bit is t...

Ok, that's constructive :-P Can we skip the type and always assume that it should be __u8/uint8_t? I read somewhere that bitfields should anyway always be 1 byte wide if the bitfield should be "portable". Would it help (to make this less horrible) to omit the type declaration and have just the bitfield members as arguments to the macro? Thanks, Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as i...