LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [GIT PATCH] PCI patches for 2.6.24
@ 2008-02-01 23:11 Greg KH
2008-02-02 0:42 ` Andrew Morton
2008-02-02 11:13 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Ingo Molnar
0 siblings, 2 replies; 23+ messages in thread
From: Greg KH @ 2008-02-01 23:11 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, linux-pci, pcihpd-discuss
Here are a bunch of PCI patches against your 2.6.24 git tree.
Some general cleanups, minor tweaks, and a bit of PCI hotplug updates,
and some PCI Express updates for new features, if your hardware happens
to support it.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/
All of these have been in the -mm releases for a while.
The full patches will be sent to the linux-pci mailing list, if anyone
wants to see them.
thanks,
greg k-h
-------------
Documentation/pci.txt | 37 +--
arch/alpha/Kconfig | 5 -
arch/arm/Kconfig | 5 -
arch/frv/Kconfig | 5 -
arch/m32r/Kconfig | 5 -
arch/m68k/Kconfig | 5 -
arch/mips/Kconfig | 5 -
arch/sh/drivers/pci/Kconfig | 5 -
arch/sparc64/Kconfig | 5 -
arch/x86/Kconfig | 5 -
arch/x86/kernel/quirks.c | 43 +-
arch/x86/pci/fixup.c | 22 +-
arch/xtensa/Kconfig | 5 -
drivers/ata/pata_cs5520.c | 2 +-
drivers/i2c/busses/scx200_acb.c | 2 +-
drivers/ide/pci/cs5520.c | 10 +-
drivers/ide/setup-pci.c | 6 +-
drivers/pci/bus.c | 18 +-
drivers/pci/dmar.c | 20 +-
drivers/pci/hotplug/Kconfig | 4 +-
drivers/pci/hotplug/Makefile | 4 +-
drivers/pci/hotplug/acpiphp.h | 1 -
drivers/pci/hotplug/acpiphp_glue.c | 5 +-
drivers/pci/hotplug/fakephp.c | 39 ++-
drivers/pci/hotplug/ibmphp_core.c | 11 +-
drivers/pci/hotplug/pci_hotplug_core.c | 4 +-
drivers/pci/hotplug/pciehp.h | 9 +-
drivers/pci/hotplug/pciehp_core.c | 33 +-
drivers/pci/hotplug/pciehp_ctrl.c | 27 +-
drivers/pci/hotplug/pciehp_hpc.c | 314 ++++++++-----
drivers/pci/hotplug/pciehp_pci.c | 43 +-
drivers/pci/hotplug/rpaphp.h | 1 -
drivers/pci/hotplug/rpaphp_pci.c | 14 -
drivers/pci/hotplug/rpaphp_slot.c | 47 +-
drivers/pci/hotplug/shpchp_hpc.c | 2 +-
drivers/pci/intel-iommu.c | 2 +-
drivers/pci/msi.c | 94 ++--
drivers/pci/pci-acpi.c | 7 +-
drivers/pci/pci-driver.c | 4 +-
drivers/pci/pci-sysfs.c | 11 +-
drivers/pci/pci.c | 93 +++-
drivers/pci/pci.h | 16 +-
drivers/pci/pcie/Kconfig | 20 +
drivers/pci/pcie/Makefile | 3 +
drivers/pci/pcie/aer/aerdrv_acpi.c | 24 +-
drivers/pci/pcie/aspm.c | 802 ++++++++++++++++++++++++++++++++
drivers/pci/pcie/portdrv_core.c | 5 +-
drivers/pci/probe.c | 80 ++--
drivers/pci/proc.c | 17 +-
drivers/pci/quirks.c | 483 +++++++++++--------
drivers/pci/remove.c | 10 +-
drivers/pci/rom.c | 6 +-
drivers/pci/setup-bus.c | 64 ++-
drivers/pci/setup-res.c | 7 +-
drivers/pci/syscall.c | 5 -
drivers/scsi/lpfc/lpfc_init.c | 3 +-
drivers/scsi/qla2xxx/qla_def.h | 1 +
drivers/scsi/qla2xxx/qla_os.c | 21 +-
drivers/usb/host/pci-quirks.c | 22 +-
include/linux/aspm.h | 44 ++
include/linux/pci-acpi.h | 11 +-
include/linux/pci.h | 367 ++++++++++-----
include/linux/pci_regs.h | 8 +
63 files changed, 2101 insertions(+), 897 deletions(-)
create mode 100644 drivers/pci/pcie/aspm.c
create mode 100644 include/linux/aspm.h
---------------
Adrian Bunk (7):
PCI: make pci_restore_bars() static
PCI: drivers/pci/rom.c: #if 0 two functions
PCI: drivers/pci/: remove unused exports
PCI: always export pci_scan_single_device
PCI: remove additional pci_scan_child_bus() prototype
PCI: drivers/pci/msi.c: move arch hooks to the top
PCI: Kconfig help: don't refer to the PCI-HOWTO
Alex Chiang (3):
PCI: hotplug: acpiphp: Remove unused variable from acpiphp
PCI: hotplug: pci_hotplug_core whitespace fix
PCI: hotplug: Link fakephp last
Andrew Morton (1):
PCI: drivers/pci/quirks.c: coding-style cleanup
Andrew Patterson (3):
PCI ACPI: Added a function to register _OSC with only PCIe devices.
PCI ACPI: AER driver should only register PCIe devices with _OSC
PCI: Run ACPI _OSC method on root bridges only
Auke Kok (1):
PCI: quirk_vialatency: Omit reading pci revision ID
Benjamin Herrenschmidt (5):
PCI: Fix bus resource assignment on 32 bits with 64b resources
PCI: Fix warning in setup-res.c on 32-bit platforms with 64-bit resources
PCI: Add pci_enable_device_{io,mem} intefaces
PCI: Remove users of pci_enable_device_bars()
PCI: Remove pci_enable_device_bars()
Diego Woitasen (1):
PCI: remove unneeded lock_kernel() in drivers/pci/syscall.c.
Fenghua Yu (1):
PCI: More Sanity checks for DMAR
Grant Grundler (1):
PCI: Remove pci_enable_device_bars() from documentation
Greg Kroah-Hartman (3):
PCI: fix codingstyle issues in drivers/pci/pci.h
PCI: fix codingstyle issues in include/linux/pci.h
PCI: make pci_bus a struct device
Ian Abbott (1):
PCI: Fix fakephp deadlock
Ivan Kokshaysky (1):
PCI: fix for quirk_e100_interrupt()
Jan Engelhardt (1):
PCI: constify function pointer tables
Jean Delvare (1):
PCI: Unhide the SMBus on the HP xw4100
Joe Perches (2):
PCI: Add missing "space" in printk messages
PCI: Spelling fixes
Joonwoo Park (1):
PCI: hotplug: Switch to pci_get_bus_and_slot
Kenji Kaneshige (6):
PCI Hotplug: pciehp: remove needless members from struct controller
PCI Hotplug: pciehp: remove needless hp_slot calculation
PCI Hotplug: pciehp: use generic function to find ext capability
pciehp: wait for 1000ms before LED operation after power off
pciehp: workaround against Bad DLLP during power off
pciehp: block new requests from the device before power off
Kristen Carlson Accardi (1):
PCI: hotplug: remove Experimental
Lee Schermerhorn (1):
PCI: Mem Policy: fix mempolicy usage in pci driver
Lennert Buytenhek (1):
PCI: get rid of pci_dev::{vendor,device}_compatible fields
Linas Vepstas (2):
pci hotplug: fix rpaphp directory naming
PCI: export pci_restore_msi_state()
MUNEDA Takahiro (2):
PCI Hotplug: acpiphp: fix trivial typos
PCI Hotplug: acpiphp: remove unneeded acpi_get_name function call
Mark Lord (4):
PCIE: fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks (and others?) in conjunction with modparam of pciehp_force=1.
PCI: more fixes for PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks (and others?) in conjunction with modparam of pciehp_force=1
PCIE: Make use of the previously split out pcie_init_enable_events() function
PCIe: fix double initialization bug
Mathieu Segaud (1):
PCI: Convert drivers/pci/proc.c to use unlocked_ioctl
Rolf Eike Beer (1):
PCI Hotplug: PCIeHP: Fix some whitespace damage
Sebastien Dugue (1):
PCI: quirk: enable MSI Mapping on HT1000
Shane Huang (1):
PCI: modify SB700 SATA MSI quirk
Shaohua Li (6):
pcie port driver: correctly detect native PME feature
pcie: utilize pcie transaction pending bit
PCI: fix typo in pci_save_pcix_state
PCI: correctly initialize a structure for pcie_save_pcix_state()
PCI: avoid save the same type of cap multiple times
PCI: PCIE ASPM support
Tim Yamin (1):
PCI: VIA CX700 quirk to disable PCI Bus Parking
bjorn.helgaas@hp.com (3):
PCI: print quirk name in debug messages
PCI: use dev_printk in quirk messages
PCI: use dev_printk in x86 quirk messages
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PATCH] PCI patches for 2.6.24
2008-02-01 23:11 [GIT PATCH] PCI patches for 2.6.24 Greg KH
@ 2008-02-02 0:42 ` Andrew Morton
2008-02-02 0:49 ` Greg KH
2008-02-02 11:13 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Ingo Molnar
1 sibling, 1 reply; 23+ messages in thread
From: Andrew Morton @ 2008-02-02 0:42 UTC (permalink / raw)
To: Greg KH
Cc: torvalds, linux-kernel, linux-pci, pcihpd-discuss, Li, Shaohua,
yanmin.zhang
On Fri, 1 Feb 2008 15:11:47 -0800
Greg KH <gregkh@suse.de> wrote:
> PCI: PCIE ASPM support
drivers/built-in.o: In function `pci_scan_slot':
drivers/pci/probe.c:1016: undefined reference to `pcie_aspm_init_link_state'
drivers/built-in.o: In function `pci_stop_dev':
drivers/pci/remove.c:36: undefined reference to `pcie_aspm_exit_link_state'
drivers/built-in.o: In function `pci_set_power_state':
drivers/pci/pci.c:524: undefined reference to `pcie_aspm_pm_state_change'
make: *** [.tmp_vmlinux1] Error 1
http://userweb.kernel.org/~akpm/config-vmm.txt
Needs this, I guess:
--- a/drivers/pci/pcie/Kconfig~fix-gregkh-pci-pci-pcie-aspm-support
+++ a/drivers/pci/pcie/Kconfig
@@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
#
config PCIEASPM
bool "PCI Express ASPM support(Experimental)"
- depends on PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL && PCIEPORTBUS
default y
help
This enables PCI Express ASPM (Active State Power Management) and
_
Also, that ASPM patch unnecessarily adds a pile of macros:
+#ifdef CONFIG_PCIEASPM
+extern void pcie_aspm_init_link_state(struct pci_dev *pdev);
+extern void pcie_aspm_exit_link_state(struct pci_dev *pdev);
+extern void pcie_aspm_pm_state_change(struct pci_dev *pdev);
+extern void pci_disable_link_state(struct pci_dev *pdev, int state);
+#else
+#define pcie_aspm_init_link_state(pdev) do {} while (0)
+#define pcie_aspm_exit_link_state(pdev) do {} while (0)
+#define pcie_aspm_pm_state_change(pdev) do {} while (0)
+#define pci_disable_link_state(pdev, state) do {} while (0)
+#endif
Please don't do this.
A static inline function is cleaner and provides typechecking. It also
provides an access to the caller's argument and can avoid unused-varaiable
warnings.
The only reason to use a macro in this situation is if the caller's
argument is for some reason not defined if !CONFIG_PCIEASPM.
Greg, please check for this in your reviewing - reject macros *by default*.
They are inferior.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PATCH] PCI patches for 2.6.24
2008-02-02 0:42 ` Andrew Morton
@ 2008-02-02 0:49 ` Greg KH
2008-02-02 1:07 ` Andrew Morton
0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2008-02-02 0:49 UTC (permalink / raw)
To: Andrew Morton
Cc: torvalds, linux-kernel, linux-pci, pcihpd-discuss, Li, Shaohua,
yanmin.zhang
On Fri, Feb 01, 2008 at 04:42:06PM -0800, Andrew Morton wrote:
> On Fri, 1 Feb 2008 15:11:47 -0800
> Greg KH <gregkh@suse.de> wrote:
>
> > PCI: PCIE ASPM support
>
> drivers/built-in.o: In function `pci_scan_slot':
> drivers/pci/probe.c:1016: undefined reference to `pcie_aspm_init_link_state'
> drivers/built-in.o: In function `pci_stop_dev':
> drivers/pci/remove.c:36: undefined reference to `pcie_aspm_exit_link_state'
> drivers/built-in.o: In function `pci_set_power_state':
> drivers/pci/pci.c:524: undefined reference to `pcie_aspm_pm_state_change'
> make: *** [.tmp_vmlinux1] Error 1
>
> http://userweb.kernel.org/~akpm/config-vmm.txt
>
>
> Needs this, I guess:
>
>
> --- a/drivers/pci/pcie/Kconfig~fix-gregkh-pci-pci-pcie-aspm-support
> +++ a/drivers/pci/pcie/Kconfig
> @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
> #
> config PCIEASPM
> bool "PCI Express ASPM support(Experimental)"
> - depends on PCI && EXPERIMENTAL
> + depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> default y
> help
> This enables PCI Express ASPM (Active State Power Management) and
> _
Oops, sorry, I'll add that to my queue for the next round.
>
> Also, that ASPM patch unnecessarily adds a pile of macros:
>
> +#ifdef CONFIG_PCIEASPM
> +extern void pcie_aspm_init_link_state(struct pci_dev *pdev);
> +extern void pcie_aspm_exit_link_state(struct pci_dev *pdev);
> +extern void pcie_aspm_pm_state_change(struct pci_dev *pdev);
> +extern void pci_disable_link_state(struct pci_dev *pdev, int state);
> +#else
> +#define pcie_aspm_init_link_state(pdev) do {} while (0)
> +#define pcie_aspm_exit_link_state(pdev) do {} while (0)
> +#define pcie_aspm_pm_state_change(pdev) do {} while (0)
> +#define pci_disable_link_state(pdev, state) do {} while (0)
> +#endif
>
> Please don't do this.
>
> A static inline function is cleaner and provides typechecking. It also
> provides an access to the caller's argument and can avoid unused-varaiable
> warnings.
>
> The only reason to use a macro in this situation is if the caller's
> argument is for some reason not defined if !CONFIG_PCIEASPM.
>
> Greg, please check for this in your reviewing - reject macros *by default*.
> They are inferior.
Ick, missed that, again, my appologies. In cleaning up pci.h I saw a
few places like this, I'll fix that next go-around also.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PATCH] PCI patches for 2.6.24
2008-02-02 0:49 ` Greg KH
@ 2008-02-02 1:07 ` Andrew Morton
0 siblings, 0 replies; 23+ messages in thread
From: Andrew Morton @ 2008-02-02 1:07 UTC (permalink / raw)
To: Greg KH
Cc: torvalds, linux-kernel, linux-pci, pcihpd-discuss, shaohua.li,
yanmin.zhang
On Fri, 1 Feb 2008 16:49:16 -0800
Greg KH <gregkh@suse.de> wrote:
> > --- a/drivers/pci/pcie/Kconfig~fix-gregkh-pci-pci-pcie-aspm-support
> > +++ a/drivers/pci/pcie/Kconfig
> > @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
> > #
> > config PCIEASPM
> > bool "PCI Express ASPM support(Experimental)"
> > - depends on PCI && EXPERIMENTAL
> > + depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> > default y
> > help
> > This enables PCI Express ASPM (Active State Power Management) and
> > _
>
> Oops, sorry, I'll add that to my queue for the next round.
Was "default y" appropriate?
^ permalink raw reply [flat|nested] 23+ messages in thread
* [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24)
2008-02-01 23:11 [GIT PATCH] PCI patches for 2.6.24 Greg KH
2008-02-02 0:42 ` Andrew Morton
@ 2008-02-02 11:13 ` Ingo Molnar
2008-02-02 15:51 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
2008-02-02 18:44 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Greg KH
1 sibling, 2 replies; 23+ messages in thread
From: Ingo Molnar @ 2008-02-02 11:13 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Andrew Morton, linux-kernel, linux-pci, pcihpd-discuss
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
* Greg KH <gregkh@suse.de> wrote:
> PCI: Remove users of pci_enable_device_bars()
> PCI: Remove pci_enable_device_bars()
simple allyesconfig testing found a build failure due to last night's
PCI merge, on 32-bit x86:
drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one':
drivers/scsi/lpfc/lpfc_init.c:1897: error: implicit declaration of function 'pci_enable_device_bars'
fix attached.
( This call has been introduced upstream 3 weeks ago by commit
8a4df120b07, but the PCI tree has apparently not been fully re-tested
with Linus-latest since that point. )
Ingo
-------------->
Subject: pci: pci_enable_device_bars() fix
From: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
drivers/scsi/lpfc/lpfc_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/scsi/lpfc/lpfc_init.c
===================================================================
--- linux.orig/drivers/scsi/lpfc/lpfc_init.c
+++ linux/drivers/scsi/lpfc/lpfc_init.c
@@ -1894,7 +1894,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev,
uint16_t iotag;
int bars = pci_select_bars(pdev, IORESOURCE_MEM);
- if (pci_enable_device_bars(pdev, bars))
+ if (pci_enable_device_io(pdev))
goto out;
if (pci_request_selected_regions(pdev, bars, LPFC_DRIVER_NAME))
goto out_disable_device;
[-- Attachment #2: config --]
[-- Type: text/plain, Size: 46137 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Sat Feb 2 11:53:47 2008
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_ARCH_SUPPORTS_OPROFILE=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
# CONFIG_BOOTPARAM_SUPPORT is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
# CONFIG_CGROUP_NS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_KMOD is not set
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
CONFIG_BLK_DEV_BSG=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=m
# CONFIG_DEFAULT_AS is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_CLASSIC_RCU=y
# CONFIG_PREEMPT_RCU is not set
#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
# CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
# CONFIG_VMI is not set
CONFIG_LGUEST_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
CONFIG_MGEODE_LX=y
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_VM86=y
CONFIG_TOSHIBA=m
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_NEED_NODE_MEMMAP_SIZE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
#
# Memory hotplug is currently incompatible with Software Suspend
#
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
CONFIG_EFI=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_SCHED_HRTICK is not set
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_COMPAT_VDSO=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management options
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
CONFIG_PM_DEBUG=y
CONFIG_PM_VERBOSE=y
CONFIG_CAN_PM_TRACE=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_VIDEO=m
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
CONFIG_X86_APM_BOOT=y
CONFIG_APM=y
CONFIG_APM_IGNORE_USER_SUSPEND=y
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
CONFIG_PCI_GODIRECT=y
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_DIRECT=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCI_LEGACY is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_GEODE_MFGPT_TIMER=y
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=m
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
CONFIG_TCP_CONG_HTCP=y
CONFIG_TCP_CONG_HSTCP=m
# CONFIG_TCP_CONG_HYBLA is not set
CONFIG_TCP_CONG_VEGAS=y
# CONFIG_TCP_CONG_SCALABLE is not set
CONFIG_TCP_CONG_LP=m
# CONFIG_TCP_CONG_VENO is not set
CONFIG_TCP_CONG_YEAH=m
# CONFIG_TCP_CONG_ILLINOIS is not set
# CONFIG_DEFAULT_BIC is not set
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
CONFIG_DEFAULT_RENO=y
CONFIG_DEFAULT_TCP_CONG="reno"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
# CONFIG_IPV6_ROUTER_PREF is not set
CONFIG_IPV6_OPTIMISTIC_DAD=y
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_SIT is not set
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_ADVANCED is not set
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
# CONFIG_NETFILTER_NETLINK_LOG is not set
CONFIG_NF_CONNTRACK=m
# CONFIG_NF_CONNTRACK_SECMARK is not set
# CONFIG_NF_CONNTRACK_FTP is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_SIP is not set
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
# CONFIG_NETFILTER_XT_TARGET_SECMARK is not set
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
CONFIG_NETFILTER_XT_MATCH_POLICY=m
# CONFIG_NETFILTER_XT_MATCH_STATE is not set
#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_FILTER=m
# CONFIG_IP_NF_TARGET_REJECT is not set
# CONFIG_IP_NF_TARGET_LOG is not set
CONFIG_IP_NF_TARGET_ULOG=m
# CONFIG_NF_NAT is not set
# CONFIG_IP_NF_MANGLE is not set
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_IPTABLES=m
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
CONFIG_IP6_NF_FILTER=m
# CONFIG_IP6_NF_TARGET_LOG is not set
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP_DCCP=m
CONFIG_IP_DCCP_ACKVEC=y
#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=m
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
# CONFIG_IP_DCCP_CCID3 is not set
# CONFIG_IP_DCCP_TFRC_LIB is not set
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
CONFIG_TIPC=y
# CONFIG_TIPC_ADVANCED is not set
CONFIG_TIPC_DEBUG=y
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
CONFIG_DECNET=y
# CONFIG_DECNET_ROUTER is not set
CONFIG_LLC=y
CONFIG_LLC2=m
# CONFIG_IPX is not set
CONFIG_ATALK=m
# CONFIG_DEV_APPLETALK is not set
CONFIG_X25=m
CONFIG_LAPB=m
CONFIG_ECONET=y
CONFIG_ECONET_AUNUDP=y
# CONFIG_ECONET_NATIVE is not set
CONFIG_WAN_ROUTER=m
# CONFIG_NET_SCHED is not set
CONFIG_NET_SCH_FIFO=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_HAMRADIO=y
#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m
#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=m
CONFIG_CAN_DEBUG_DEVICES=y
# CONFIG_IRDA is not set
CONFIG_BT=y
CONFIG_BT_L2CAP=m
# CONFIG_BT_SCO is not set
# CONFIG_BT_RFCOMM is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_HIDP is not set
#
# Bluetooth device drivers
#
# CONFIG_BT_HCIUSB is not set
CONFIG_BT_HCIBTUSB=y
# CONFIG_BT_HCIBTSDIO is not set
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y
# CONFIG_BT_HCIBCM203X is not set
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIVHCI=m
# CONFIG_AF_RXRPC is not set
#
# Wireless
#
CONFIG_CFG80211=m
CONFIG_NL80211=y
CONFIG_WIRELESS_EXT=y
CONFIG_MAC80211=m
#
# Rate control algorithm selection
#
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_SIMPLE=y
# CONFIG_MAC80211_RC_DEFAULT_NONE is not set
#
# Selecting 'y' for an algorithm will
#
#
# build the algorithm into mac80211.
#
CONFIG_MAC80211_RC_DEFAULT="simple"
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_SIMPLE=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG is not set
CONFIG_IEEE80211=y
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=y
CONFIG_IEEE80211_CRYPT_CCMP=y
CONFIG_IEEE80211_CRYPT_TKIP=y
CONFIG_IEEE80211_SOFTMAC=y
CONFIG_IEEE80211_SOFTMAC_DEBUG=y
# CONFIG_RFKILL is not set
CONFIG_NET_9P=m
# CONFIG_NET_9P_FD is not set
CONFIG_NET_9P_VIRTIO=m
CONFIG_NET_9P_DEBUG=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_AX88796=y
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
CONFIG_BLK_CPQ_DA=y
CONFIG_BLK_CPQ_CISS_DA=y
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=y
CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_VIRTIO_BLK=m
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
CONFIG_PHANTOM=y
CONFIG_EEPROM_93CX6=m
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
CONFIG_ASUS_LAPTOP=m
CONFIG_FUJITSU_LAPTOP=y
CONFIG_MSI_LAPTOP=y
# CONFIG_SONY_LAPTOP is not set
CONFIG_THINKPAD_ACPI=m
CONFIG_THINKPAD_ACPI_DEBUG=y
# CONFIG_THINKPAD_ACPI_DOCK is not set
CONFIG_THINKPAD_ACPI_BAY=y
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_CHR_DEV_OSST=y
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=y
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
# CONFIG_SCSI_SAS_HOST_SMP is not set
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=y
CONFIG_BLK_DEV_3W_XXXX_RAID=y
CONFIG_SCSI_3W_9XXX=y
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=5000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_SCSI_ADVANSYS=y
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
CONFIG_MEGARAID_LEGACY=y
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_OMIT_FLASHPOINT=y
CONFIG_SCSI_DMX3191D=y
# CONFIG_SCSI_EATA is not set
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_IPS=y
# CONFIG_SCSI_INITIO is not set
CONFIG_SCSI_INIA100=m
# CONFIG_SCSI_STEX is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=y
# CONFIG_SCSI_IPR_TRACE is not set
CONFIG_SCSI_IPR_DUMP=y
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA_FC=y
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=y
CONFIG_SCSI_DC395x=y
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_NSP32=m
# CONFIG_SCSI_SRP is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_SVW=m
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
CONFIG_PDC_ADMA=y
CONFIG_SATA_QSTOR=m
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
CONFIG_SATA_SIL=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_SIS=y
CONFIG_SATA_ULI=y
CONFIG_SATA_VIA=y
# CONFIG_SATA_VITESSE is not set
CONFIG_SATA_INIC162X=y
CONFIG_PATA_ACPI=y
# CONFIG_PATA_ALI is not set
CONFIG_PATA_AMD=y
CONFIG_PATA_ARTOP=y
CONFIG_PATA_ATIIXP=y
CONFIG_PATA_CMD640_PCI=m
CONFIG_PATA_CMD64X=y
CONFIG_PATA_CS5520=y
# CONFIG_PATA_CS5530 is not set
CONFIG_PATA_CS5535=y
# CONFIG_PATA_CS5536 is not set
CONFIG_PATA_CYPRESS=y
CONFIG_PATA_EFAR=m
CONFIG_ATA_GENERIC=y
CONFIG_PATA_HPT366=y
CONFIG_PATA_HPT37X=y
CONFIG_PATA_HPT3X2N=y
CONFIG_PATA_HPT3X3=y
# CONFIG_PATA_HPT3X3_DMA is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
CONFIG_PATA_TRIFLEX=y
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
CONFIG_PATA_OLDPIIX=y
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NINJA32=y
CONFIG_PATA_NS87410=m
CONFIG_PATA_NS87415=m
# CONFIG_PATA_OPTI is not set
CONFIG_PATA_OPTIDMA=y
CONFIG_PATA_PDC_OLD=m
# CONFIG_PATA_RADISYS is not set
CONFIG_PATA_RZ1000=y
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
CONFIG_PATA_PDC2027X=y
# CONFIG_PATA_SIL680 is not set
CONFIG_PATA_SIS=y
# CONFIG_PATA_VIA is not set
CONFIG_PATA_WINBOND=y
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=y
CONFIG_FIREWIRE_OHCI=y
CONFIG_FIREWIRE_SBP2=m
CONFIG_IEEE1394=y
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
#
# Controllers
#
# CONFIG_IEEE1394_PCILYNX is not set
# CONFIG_IEEE1394_OHCI1394 is not set
#
# Protocols
#
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_RAWIO is not set
CONFIG_I2O=m
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
# CONFIG_I2O_EXT_ADAPTEC is not set
CONFIG_I2O_CONFIG=m
# CONFIG_I2O_CONFIG_OLD_IOCTL is not set
# CONFIG_I2O_BUS is not set
CONFIG_I2O_BLOCK=m
# CONFIG_I2O_SCSI is not set
CONFIG_I2O_PROC=m
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_DUMMY=m
CONFIG_BONDING=y
# CONFIG_MACVLAN is not set
CONFIG_EQUALIZER=m
CONFIG_TUN=y
CONFIG_VETH=y
# CONFIG_NET_SB1000 is not set
CONFIG_ARCNET=m
# CONFIG_ARCNET_1201 is not set
CONFIG_ARCNET_1051=m
# CONFIG_ARCNET_RAW is not set
# CONFIG_ARCNET_CAP is not set
CONFIG_ARCNET_COM90xx=m
# CONFIG_ARCNET_COM90xxIO is not set
CONFIG_ARCNET_RIM_I=m
# CONFIG_ARCNET_COM20020 is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_ENC28J60=m
# CONFIG_ENC28J60_WRITEVERIFY is not set
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
CONFIG_TULIP_NAPI=y
# CONFIG_TULIP_NAPI_HW_MITIGATION is not set
CONFIG_DE4X5=y
CONFIG_WINBOND_840=m
CONFIG_DM9102=y
# CONFIG_ULI526X is not set
CONFIG_HP100=m
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
# CONFIG_PCNET32_NAPI is not set
CONFIG_AMD8111_ETH=m
# CONFIG_AMD8111E_NAPI is not set
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_B44=y
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
CONFIG_FORCEDETH=y
CONFIG_FORCEDETH_NAPI=y
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
CONFIG_NATSEMI=y
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R6040=m
CONFIG_SIS900=y
CONFIG_EPIC100=m
# CONFIG_SUNDANCE is not set
CONFIG_TLAN=y
CONFIG_VIA_RHINE=y
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_VIA_RHINE_NAPI is not set
CONFIG_SC92031=m
# CONFIG_NET_POCKET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
CONFIG_E1000_DISABLE_PACKET_SPLIT=y
CONFIG_E1000E=m
CONFIG_E1000E_ENABLED=y
CONFIG_IP1000=y
# CONFIG_IGB is not set
CONFIG_NS83820=y
CONFIG_HAMACHI=m
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=y
CONFIG_R8169_NAPI=y
CONFIG_SKGE=y
CONFIG_SKGE_DEBUG=y
CONFIG_SKY2=y
CONFIG_SKY2_DEBUG=y
CONFIG_SK98LIN=m
CONFIG_VIA_VELOCITY=y
CONFIG_TIGON3=y
CONFIG_BNX2=m
# CONFIG_QLA3XXX is not set
CONFIG_ATL1=m
# CONFIG_NETDEV_10000 is not set
CONFIG_TR=y
# CONFIG_IBMOL is not set
CONFIG_IBMLS=m
# CONFIG_3C359 is not set
# CONFIG_TMS380TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=y
CONFIG_LIBERTAS_SDIO=m
CONFIG_LIBERTAS_DEBUG=y
# CONFIG_AIRO is not set
CONFIG_HERMES=y
# CONFIG_PLX_HERMES is not set
CONFIG_TMD_HERMES=y
CONFIG_NORTEL_HERMES=y
# CONFIG_PCI_HERMES is not set
# CONFIG_ATMEL is not set
CONFIG_PRISM54=m
# CONFIG_USB_ZD1201 is not set
CONFIG_USB_NET_RNDIS_WLAN=m
CONFIG_RTL8180=m
CONFIG_RTL8187=m
# CONFIG_ADM8211 is not set
# CONFIG_P54_COMMON is not set
CONFIG_ATH5K=m
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set
# CONFIG_HOSTAP is not set
CONFIG_BCM43XX=m
CONFIG_BCM43XX_DEBUG=y
CONFIG_BCM43XX_DMA=y
# CONFIG_BCM43XX_DMA_AND_PIO_MODE is not set
CONFIG_BCM43XX_DMA_MODE=y
# CONFIG_BCM43XX_PIO_MODE is not set
CONFIG_B43=m
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
# CONFIG_B43_DEBUG is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
CONFIG_USB_KAWETH=m
# CONFIG_USB_PEGASUS is not set
CONFIG_USB_RTL8150=y
CONFIG_USB_USBNET=m
# CONFIG_USB_NET_AX8817X is not set
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_DM9601=m
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=m
# CONFIG_USB_NET_PLUSB is not set
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
# CONFIG_USB_NET_CDC_SUBSET is not set
# CONFIG_USB_NET_ZAURUS is not set
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
# CONFIG_PPPOE is not set
CONFIG_PPPOL2TP=y
# CONFIG_SLIP is not set
CONFIG_SLHC=y
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=y
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_VIRTIO_NET=y
CONFIG_ISDN=m
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
# CONFIG_ISDN_PPP_VJ is not set
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
# CONFIG_ISDN_AUDIO is not set
# CONFIG_ISDN_X25 is not set
#
# ISDN feature submodules
#
# CONFIG_ISDN_DRV_LOOP is not set
CONFIG_ISDN_DIVERSION=m
#
# ISDN4Linux hardware drivers
#
#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set
#
# Active cards
#
CONFIG_HYSDN=m
# CONFIG_ISDN_DRV_GIGASET is not set
# CONFIG_ISDN_CAPI is not set
CONFIG_PHONE=y
# CONFIG_PHONE_IXJ is not set
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_EVBUG=m
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_SUNKBD=m
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_XTKBD=m
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_STOWAWAY=y
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
# CONFIG_MOUSE_SERIAL is not set
CONFIG_MOUSE_APPLETOUCH=m
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_WISTRON_BTNS=y
# CONFIG_INPUT_ATLAS_BTNS is not set
CONFIG_INPUT_ATI_REMOTE=y
# CONFIG_INPUT_ATI_REMOTE2 is not set
CONFIG_INPUT_KEYSPAN_REMOTE=y
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=y
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=m
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=y
# CONFIG_GAMEPORT_NS558 is not set
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=y
CONFIG_GAMEPORT_FM801=y
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
CONFIG_ROCKETPORT=m
# CONFIG_CYCLADES is not set
CONFIG_DIGIEPCA=y
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
# CONFIG_MOXA_SMARTIO_NEW is not set
# CONFIG_ISI is not set
CONFIG_SYNCLINK=y
# CONFIG_SYNCLINKMP is not set
CONFIG_SYNCLINK_GT=y
CONFIG_N_HDLC=y
# CONFIG_RISCOM8 is not set
CONFIG_SPECIALIX=m
# CONFIG_SPECIALIX_RTSCTS is not set
CONFIG_SX=m
CONFIG_RIO=y
# CONFIG_RIO_OLDPCI is not set
# CONFIG_STALDRV is not set
CONFIG_NOZOMI=y
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
CONFIG_PPDEV=y
CONFIG_HVC_DRIVER=y
CONFIG_HVC_XEN=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_GEODE=y
CONFIG_HW_RANDOM_VIA=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
CONFIG_R3964=m
CONFIG_APPLICOM=y
# CONFIG_SONYPI is not set
CONFIG_MWAVE=m
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
CONFIG_CS5535_GPIO=m
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=y
CONFIG_TCG_TPM=y
# CONFIG_TCG_TIS is not set
# CONFIG_TCG_NSC is not set
CONFIG_TCG_ATMEL=m
# CONFIG_TCG_INFINEON is not set
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_OCORES=m
# CONFIG_I2C_PARPORT is not set
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_I2C_SIMTEC=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_STUB=m
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
#
# Miscellaneous I2C Chip support
#
CONFIG_DS1682=m
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
CONFIG_PCF8575=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_TPS65010=m
CONFIG_SENSORS_MAX6875=m
CONFIG_SENSORS_TSL2550=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y
#
# SPI support
#
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
CONFIG_SPI_BITBANG=y
CONFIG_SPI_BUTTERFLY=m
CONFIG_SPI_LM70_LLP=y
#
# SPI Protocol Masters
#
CONFIG_SPI_AT25=y
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
CONFIG_W1=y
# CONFIG_W1_CON is not set
#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_MATROX=y
CONFIG_W1_MASTER_DS2490=y
CONFIG_W1_MASTER_DS2482=m
#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
# CONFIG_W1_SLAVE_SMEM is not set
# CONFIG_W1_SLAVE_DS2433 is not set
CONFIG_W1_SLAVE_DS2760=y
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
CONFIG_PDA_POWER=y
CONFIG_BATTERY_DS2760=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_SENSORS_ABITUGURU=y
CONFIG_SENSORS_ABITUGURU3=y
# CONFIG_SENSORS_AD7418 is not set
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_I5K_AMB=m
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_F71882FG=y
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
CONFIG_SENSORS_FSCHMD=m
CONFIG_SENSORS_GL518SM=m
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IBMPEX=m
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM70=y
# CONFIG_SENSORS_LM75 is not set
CONFIG_SENSORS_LM77=m
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
# CONFIG_SENSORS_LM92 is not set
CONFIG_SENSORS_LM93=m
# CONFIG_SENSORS_MAX1619 is not set
CONFIG_SENSORS_MAX6650=m
# CONFIG_SENSORS_PC87360 is not set
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_SIS5595=y
CONFIG_SENSORS_DME1737=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_THMC50=m
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_VT1211=y
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
# CONFIG_SENSORS_W83792D is not set
CONFIG_SENSORS_W83793=m
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
CONFIG_SENSORS_W83627EHF=y
CONFIG_SENSORS_HDAPS=m
CONFIG_SENSORS_APPLESMC=m
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=y
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=y
CONFIG_ALIM1535_WDT=y
CONFIG_ALIM7101_WDT=y
CONFIG_SC520_WDT=m
CONFIG_IB700_WDT=y
CONFIG_IBMASR=m
CONFIG_WAFER_WDT=m
# CONFIG_I6300ESB_WDT is not set
CONFIG_ITCO_WDT=m
# CONFIG_ITCO_VENDOR_SUPPORT is not set
CONFIG_IT8712F_WDT=y
# CONFIG_SC1200_WDT is not set
CONFIG_PC87413_WDT=m
CONFIG_60XX_WDT=m
CONFIG_SBC8360_WDT=y
CONFIG_SBC7240_WDT=m
CONFIG_CPU5_WDT=y
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=y
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83877F_WDT is not set
CONFIG_W83977F_WDT=y
# CONFIG_MACHZ_WDT is not set
CONFIG_SBC_EPX_C3_WATCHDOG=y
#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
CONFIG_WDTPCI=y
# CONFIG_WDT_501_PCI is not set
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
CONFIG_SSB=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_DEBUG=y
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_DVB_CORE is not set
CONFIG_DAB=y
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_ALI=m
# CONFIG_AGP_ATI is not set
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
CONFIG_DRM_MGA=m
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
# CONFIG_FB is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_LTV350QV=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CORGI=y
CONFIG_BACKLIGHT_PROGEAR=y
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y
#
# Display hardware drivers
#
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
# CONFIG_VIDEO_SELECT is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
CONFIG_SOUND=y
#
# Advanced Linux Sound Architecture
#
# CONFIG_SND is not set
#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
# CONFIG_SOUND_TRIDENT is not set
CONFIG_SOUND_MSNDCLAS=m
CONFIG_MSNDCLAS_INIT_FILE="/etc/sound/msndinit.bin"
CONFIG_MSNDCLAS_PERM_FILE="/etc/sound/msndperm.bin"
CONFIG_SOUND_MSNDPIN=m
CONFIG_MSNDPIN_INIT_FILE="/etc/sound/pndspini.bin"
CONFIG_MSNDPIN_PERM_FILE="/etc/sound/pndsperm.bin"
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y
CONFIG_HIDRAW=y
#
# USB Input Devices
#
# CONFIG_USB_HID is not set
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
CONFIG_USB_MOUSE=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
CONFIG_USB_DYNAMIC_MINORS=y
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_SSB=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_SL811_HCD=m
CONFIG_USB_R8A66597_HCD=m
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
# CONFIG_USB_STORAGE_DATAFAB is not set
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
CONFIG_USB_MICROTEK=m
CONFIG_USB_MON=y
#
# USB port drivers
#
CONFIG_USB_USS720=m
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
CONFIG_USB_EMI26=y
# CONFIG_USB_ADUTUX is not set
CONFIG_USB_AUERSWALD=y
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
# CONFIG_USB_BERRY_CHARGE is not set
CONFIG_USB_LED=m
CONFIG_USB_CYPRESS_CY7C63=m
CONFIG_USB_CYTHERM=y
CONFIG_USB_PHIDGET=y
# CONFIG_USB_PHIDGETKIT is not set
CONFIG_USB_PHIDGETMOTORCONTROL=m
CONFIG_USB_PHIDGETSERVO=m
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
CONFIG_USB_LD=y
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GADGET is not set
CONFIG_MMC=m
CONFIG_MMC_DEBUG=y
# CONFIG_MMC_UNSAFE_RESUME is not set
#
# MMC/SD Card Drivers
#
# CONFIG_MMC_BLOCK is not set
CONFIG_SDIO_UART=m
#
# MMC/SD Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_RICOH_MMC=m
CONFIG_MMC_WBSD=m
# CONFIG_MMC_TIFM_SD is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
#
# LED drivers
#
#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
CONFIG_INFINIBAND=y
# CONFIG_INFINIBAND_USER_MAD is not set
CONFIG_INFINIBAND_USER_ACCESS=y
CONFIG_INFINIBAND_USER_MEM=y
CONFIG_INFINIBAND_ADDR_TRANS=y
# CONFIG_INFINIBAND_MTHCA is not set
# CONFIG_INFINIBAND_AMSO1100 is not set
# CONFIG_MLX4_INFINIBAND is not set
CONFIG_INFINIBAND_IPOIB=m
# CONFIG_INFINIBAND_IPOIB_CM is not set
CONFIG_INFINIBAND_IPOIB_DEBUG=y
CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y
# CONFIG_INFINIBAND_SRP is not set
# CONFIG_INFINIBAND_ISER is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_TEST=m
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
CONFIG_RTC_DRV_MAX6900=m
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
# CONFIG_RTC_DRV_M41T80_WDT is not set
#
# SPI RTC drivers
#
CONFIG_RTC_DRV_RS5C348=y
CONFIG_RTC_DRV_MAX6902=m
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=m
# CONFIG_RTC_DRV_DS1553 is not set
CONFIG_RTC_DRV_STK17TA8=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_M48T86=y
CONFIG_RTC_DRV_M48T59=y
CONFIG_RTC_DRV_V3020=y
#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
CONFIG_AUXDISPLAY=y
#
# Userspace I/O
#
CONFIG_UIO=m
CONFIG_UIO_CIF=m
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_EFI_VARS=y
CONFIG_DELL_RBU=y
CONFIG_DCDBAS=m
CONFIG_DMIID=y
#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4DEV_FS=y
CONFIG_EXT4DEV_FS_XATTR=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
# CONFIG_EXT4DEV_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
CONFIG_JBD2_DEBUG=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
CONFIG_REISERFS_CHECK=y
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_NOLOCK=m
CONFIG_GFS2_FS_LOCKING_DLM=m
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_DEBUG_MASKLOG=y
# CONFIG_OCFS2_DEBUG_FS is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
# CONFIG_VFAT_FS is not set
CONFIG_FAT_DEFAULT_CODEPAGE=437
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
#
# Miscellaneous filesystems
#
CONFIG_ADFS_FS=y
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
CONFIG_ECRYPT_FS=m
# CONFIG_HFS_FS is not set
CONFIG_HFSPLUS_FS=y
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
CONFIG_VXFS_FS=y
CONFIG_HPFS_FS=m
CONFIG_QNX4FS_FS=y
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=y
# CONFIG_UFS_FS_WRITE is not set
CONFIG_UFS_DEBUG=y
# CONFIG_NETWORK_FILESYSTEMS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
# CONFIG_ACORN_PARTITION_CUMANA is not set
# CONFIG_ACORN_PARTITION_EESOX is not set
# CONFIG_ACORN_PARTITION_ICS is not set
# CONFIG_ACORN_PARTITION_ADFS is not set
CONFIG_ACORN_PARTITION_POWERTEC=y
CONFIG_ACORN_PARTITION_RISCIX=y
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
CONFIG_SYSV68_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
CONFIG_NLS_CODEPAGE_775=y
# CONFIG_NLS_CODEPAGE_850 is not set
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_855=y
# CONFIG_NLS_CODEPAGE_857 is not set
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
CONFIG_NLS_CODEPAGE_863=y
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=m
# CONFIG_NLS_CODEPAGE_936 is not set
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
# CONFIG_NLS_CODEPAGE_949 is not set
CONFIG_NLS_CODEPAGE_874=y
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
CONFIG_NLS_CODEPAGE_1251=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
CONFIG_NLS_ISO8859_4=y
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
# CONFIG_NLS_ISO8859_13 is not set
CONFIG_NLS_ISO8859_14=m
# CONFIG_NLS_ISO8859_15 is not set
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_UTF8=y
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set
CONFIG_INSTRUMENTATION=y
CONFIG_PROFILING=y
# CONFIG_OPROFILE is not set
# CONFIG_KPROBES is not set
# CONFIG_MARKERS is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_LATENCYTOP is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_SAMPLES=y
CONFIG_SAMPLE_KOBJECT=m
CONFIG_NONPROMISC_DEVMEM=y
CONFIG_EARLY_PRINTK=y
CONFIG_DOUBLEFAULT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y
CONFIG_DEFAULT_IO_DELAY_TYPE=3
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=y
CONFIG_CRYPTO_NULL=m
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_LRW=m
# CONFIG_CRYPTO_XTS is not set
CONFIG_CRYPTO_CTR=m
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
# CONFIG_CRYPTO_BLOWFISH is not set
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_586=y
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SALSA20=y
CONFIG_CRYPTO_SALSA20_586=m
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_CRC7=m
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_FORCE_MINIMAL_CONFIG=y
CONFIG_FORCE_MINIMAL_CONFIG_PHYS=y
CONFIG_X86_32_ALWAYS_ON=y
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 11:13 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Ingo Molnar
@ 2008-02-02 15:51 ` Jeff Garzik
2008-02-02 16:01 ` James Bottomley
2008-02-02 17:08 ` Ingo Molnar
2008-02-02 18:44 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Greg KH
1 sibling, 2 replies; 23+ messages in thread
From: Jeff Garzik @ 2008-02-02 15:51 UTC (permalink / raw)
To: Ingo Molnar
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi
Ingo Molnar wrote:
> ===================================================================
> --- linux.orig/drivers/scsi/lpfc/lpfc_init.c
> +++ linux/drivers/scsi/lpfc/lpfc_init.c
> @@ -1894,7 +1894,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev,
> uint16_t iotag;
> int bars = pci_select_bars(pdev, IORESOURCE_MEM);
>
> - if (pci_enable_device_bars(pdev, bars))
> + if (pci_enable_device_io(pdev))
> goto out;
Look at the line right above it... AFAICS you want
pci_enable_device_mem(), if the mask is selecting IORESOURCE_MEM BARs.
Also a CC to linux-scsi and the driver author would be nice, as they are
the ones with hardware and can verify.
This set of changes seemed like 50% guesswork to me, without consulting
the authors :( And unlike many changes, you actually have to know the
hardware [or get clues from surrounding code] to make the change.
Jeff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 15:51 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
@ 2008-02-02 16:01 ` James Bottomley
2008-02-02 17:08 ` Ingo Molnar
1 sibling, 0 replies; 23+ messages in thread
From: James Bottomley @ 2008-02-02 16:01 UTC (permalink / raw)
To: Jeff Garzik
Cc: Ingo Molnar, Greg KH, Linus Torvalds, Andrew Morton,
linux-kernel, linux-pci, pcihpd-discuss, linux-scsi
On Sat, 2008-02-02 at 10:51 -0500, Jeff Garzik wrote:
> Ingo Molnar wrote:
> > ===================================================================
> > --- linux.orig/drivers/scsi/lpfc/lpfc_init.c
> > +++ linux/drivers/scsi/lpfc/lpfc_init.c
> > @@ -1894,7 +1894,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev,
> > uint16_t iotag;
> > int bars = pci_select_bars(pdev, IORESOURCE_MEM);
> >
> > - if (pci_enable_device_bars(pdev, bars))
> > + if (pci_enable_device_io(pdev))
> > goto out;
>
> Look at the line right above it... AFAICS you want
> pci_enable_device_mem(), if the mask is selecting IORESOURCE_MEM BARs.
>
> Also a CC to linux-scsi and the driver author would be nice, as they are
> the ones with hardware and can verify.
>
> This set of changes seemed like 50% guesswork to me, without consulting
> the authors :( And unlike many changes, you actually have to know the
> hardware [or get clues from surrounding code] to make the change.
Jeff is right, this fix is wrong.
The correct fix is here:
http://marc.info/?l=linux-scsi&m=120196768605031
Ingo, could you please cc linux-scsi on your mails ... it would have
been a complete disaster to have this incorrect patch go in.
James
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 15:51 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
2008-02-02 16:01 ` James Bottomley
@ 2008-02-02 17:08 ` Ingo Molnar
2008-02-02 17:33 ` Jeff Garzik
2008-02-02 18:08 ` James Bottomley
1 sibling, 2 replies; 23+ messages in thread
From: Ingo Molnar @ 2008-02-02 17:08 UTC (permalink / raw)
To: Jeff Garzik
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> ===================================================================
>> --- linux.orig/drivers/scsi/lpfc/lpfc_init.c
>> +++ linux/drivers/scsi/lpfc/lpfc_init.c
>> @@ -1894,7 +1894,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev,
>> uint16_t iotag;
>> int bars = pci_select_bars(pdev, IORESOURCE_MEM);
>> - if (pci_enable_device_bars(pdev, bars))
>> + if (pci_enable_device_io(pdev))
>> goto out;
>
> Look at the line right above it... AFAICS you want
> pci_enable_device_mem(), if the mask is selecting IORESOURCE_MEM BARs.
>
> Also a CC to linux-scsi and the driver author would be nice, as they
> are the ones with hardware and can verify.
it would have been totally appropriate for me to just send a mail to
lkml with the proper subject line about the breakage. (I might even have
decided to stay completely silent about the issue and fix it for my own
build, letting you guys figure it out.)
Instead i did a search of lkml (based on the function name in the build
error) and figured out where the pull request was on lkml: Greg. I
replied to that mail, he'll obviously know whom else to Cc from that
point on (if anyone). I really didnt want to (nor did i need to) figure
out whether this was some general driver level API change that happen
kernel-wide, or some SCSI specific change. I simply replied to the pull
request whose Cc: line seemed well-populated to me already. I also took
a look at the commit itself and did a quick hack in a hurry to keep the
tests rolling. It really did not occur to me that i should have added
anyone else to the Cc: line, as linux-pci@atrey.karlin.mff.cuni.cz was
Cc:-ed already so i assumed the interest was from that angle.
( And as this was spent from my family's weekend time and i had no time
and no interest to dig any further than to figure out the "first hop"
of the change that broke the build, and the parties who initiated that
hop. I'm in fact surprised that your and James's answer to my
bugreport is hostility. )
So i find your suggestion that i should have added more people to the
Cc: line unfair on several levels.
> This set of changes seemed like 50% guesswork to me, without
> consulting the authors :( And unlike many changes, you actually have
> to know the hardware [or get clues from surrounding code] to make the
> change.
you mean the whole set of changes? Or just mine? Mine was a 30 seconds
guesswork of course, i dont have the hardware, i didnt do the change,
nor did i do anything near that code - i just saw the build failure stop
my testing and sent in this notification and a hack. That's why i sent
it to Greg, as a reply to the mail where he pushed these changes
upstream and who'll know what to do with it from that point on. My patch
can be totally thrown away (and should be, apparently).
but ... i guess next time i'll think twice before sending any bugreports
about or related to the SCSI code anywhere, unless they become really
annoying. Who needs this hassle?
Ingo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 17:08 ` Ingo Molnar
@ 2008-02-02 17:33 ` Jeff Garzik
2008-02-02 17:57 ` Ingo Molnar
2008-02-02 18:08 ` James Bottomley
1 sibling, 1 reply; 23+ messages in thread
From: Jeff Garzik @ 2008-02-02 17:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
Ingo Molnar wrote:
> it would have been totally appropriate for me to just send a mail to
> lkml with the proper subject line about the breakage. (I might even have
> decided to stay completely silent about the issue and fix it for my own
> build, letting you guys figure it out.)
Oh come on... You are smart enough to know to at least CC the driver
maintainer, the key POC who should be aware of breakage of their driver.
That is a standard courtesy.
> ( And as this was spent from my family's weekend time and i had no time
> and no interest to dig any further than to figure out the "first hop"
> of the change that broke the build, and the parties who initiated that
> hop. I'm in fact surprised that your and James's answer to my
> bugreport is hostility. )
I'm sorry you read "would be nice" as hostility.
> So i find your suggestion that i should have added more people to the
> Cc: line unfair on several levels.
As I noted, it is an obvious courtesy to CC the driver maintainer, at
the very least.
_Especially_ when it is a change that requires some knowledge of the
hardware, as was this case.
>> This set of changes seemed like 50% guesswork to me, without
>> consulting the authors :( And unlike many changes, you actually have
>> to know the hardware [or get clues from surrounding code] to make the
>> change.
>
> you mean the whole set of changes?
The whole set of changes, yes, not just yours.
> but ... i guess next time i'll think twice before sending any bugreports
> about or related to the SCSI code anywhere, unless they become really
> annoying. Who needs this hassle?
The fact is, each larger subsystem (net, scsi, ata I know) has several
vendor contacts and driver maintainers who for various reasons prefer a
more focused -- and often less hostile -- mailing list to LKML.
I have a hard enough time as it is, trying to convince hardware vendors
to work with us, that we are not all assholes.
How about respecting the preferences of certain segments of a very large
community, even when they differ from your own? We have a
community-accepted method of expressing these preferences, the
MAINTAINERS file.
IMO, standard practice should be:
* To or CC: driver maintainer mentioned in MAINTAINERS (if any)
* CC: LKML, any list mentioned in MAINTAINERS
So, how about CC'ing the targets that have nicely requested to be CC'd?
Jeff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 17:33 ` Jeff Garzik
@ 2008-02-02 17:57 ` Ingo Molnar
2008-02-02 18:49 ` Jeff Garzik
0 siblings, 1 reply; 23+ messages in thread
From: Ingo Molnar @ 2008-02-02 17:57 UTC (permalink / raw)
To: Jeff Garzik
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> it would have been totally appropriate for me to just send a mail to lkml
>> with the proper subject line about the breakage. (I might even have
>> decided to stay completely silent about the issue and fix it for my own
>> build, letting you guys figure it out.)
>
> Oh come on... You are smart enough to know to at least CC the driver
> maintainer, the key POC who should be aware of breakage of their
> driver. That is a standard courtesy.
is there any particular reason why you cut out the most relevant part of
my reply, which happens to answer all your questions AFAICS:
>> Instead i did a search of lkml (based on the function name in the
>> build error) and figured out where the pull request was on lkml:
>> Greg. I replied to that mail, he'll obviously know whom else to Cc
>> from that point on (if anyone). I really didnt want to (nor did i
>> need to) figure out whether this was some general driver level API
>> change that happen kernel-wide, or some SCSI specific change. I
>> simply replied to the pull request whose Cc: line seemed
>> well-populated to me already. I also took a look at the commit itself
>> and did a quick hack in a hurry to keep the tests rolling. It really
>> did not occur to me that i should have added anyone else to the Cc:
>> line, as linux-pci@atrey.karlin.mff.cuni.cz was Cc:-ed already so i
>> assumed the interest was from that angle.
had you read this portion you'd have realized that i did not search for
any "owner" of the file, i simply searched for the person who introduced
the change, and the on-lkml mail where the change was introduced.
and that's all that should be needed, really. Believe me, i hit tons of
bugs all across the kernel, often several bugs a day, and it's hard even
for me to figure out who "maintains" a file and when. (and in Linux
there's no "ownership" of files anyway) So as a general rule i go after
changes instead, and that's exactly what i did here too. I do
delta/regression QA - i.e. i watch for _changes_ that break the kernel
and hence the general 'owner' of a file is often irrelevant - it's the
maintainer who introduces a change who matters, and we do lots of
cross-maintain merges. Only if i do not manage to identify a change do i
try to figure out who maintains a file at that given moment. (But those
mails often go into black holes, they get bounced, subscriber-required
email lists, etc. etc.) It's also nontrivial to map the files to the
MAINTAINERS file, and it's also quite outdated in some portions. So the
MAINTAINERS file is the last resort i use.
so i'm still totally befuddled why you think that there was anything
particularly wrong or unhelpful about me replying to the specific pull
request that introduced a particular breakage into the kernel. Had i
mailed to lkml with a terse "kernel build broke" message with just an
URL to a config and the build breakage, you could rightfully have
complained that i should have done more to properly direct my bugreport.
But this breakage was about a PCI API change, the pull request had a PCI
mailing list Cc:-ed, why should i have thought that this needs the
attention of any other parties?
Ingo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 17:08 ` Ingo Molnar
2008-02-02 17:33 ` Jeff Garzik
@ 2008-02-02 18:08 ` James Bottomley
2008-02-02 19:00 ` Ingo Molnar
1 sibling, 1 reply; 23+ messages in thread
From: James Bottomley @ 2008-02-02 18:08 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jeff Garzik, Greg KH, Linus Torvalds, Andrew Morton,
linux-kernel, linux-pci, pcihpd-discuss, linux-scsi
On Sat, 2008-02-02 at 18:08 +0100, Ingo Molnar wrote:
> * Jeff Garzik <jeff@garzik.org> wrote:
>
> > Ingo Molnar wrote:
> >> ===================================================================
> >> --- linux.orig/drivers/scsi/lpfc/lpfc_init.c
> >> +++ linux/drivers/scsi/lpfc/lpfc_init.c
> >> @@ -1894,7 +1894,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev,
> >> uint16_t iotag;
> >> int bars = pci_select_bars(pdev, IORESOURCE_MEM);
> >> - if (pci_enable_device_bars(pdev, bars))
> >> + if (pci_enable_device_io(pdev))
> >> goto out;
> >
> > Look at the line right above it... AFAICS you want
> > pci_enable_device_mem(), if the mask is selecting IORESOURCE_MEM BARs.
> >
> > Also a CC to linux-scsi and the driver author would be nice, as they
> > are the ones with hardware and can verify.
>
> it would have been totally appropriate for me to just send a mail to
> lkml with the proper subject line about the breakage. (I might even have
> decided to stay completely silent about the issue and fix it for my own
> build, letting you guys figure it out.)
We agreed to differ a while ago on your head in the sand, post it to
LKML because everybody follows that list attitude. Some nice soul will
always (eventually) forward to the correct list, so this practice more
or less works (just not in as timely fashion as actually posting to the
relevant list).
> Instead i did a search of lkml (based on the function name in the build
> error) and figured out where the pull request was on lkml: Greg. I
> replied to that mail, he'll obviously know whom else to Cc from that
> point on (if anyone). I really didnt want to (nor did i need to) figure
> out whether this was some general driver level API change that happen
> kernel-wide, or some SCSI specific change. I simply replied to the pull
> request whose Cc: line seemed well-populated to me already. I also took
> a look at the commit itself and did a quick hack in a hurry to keep the
> tests rolling. It really did not occur to me that i should have added
> anyone else to the Cc: line, as linux-pci@atrey.karlin.mff.cuni.cz was
> Cc:-ed already so i assumed the interest was from that angle.
>
> ( And as this was spent from my family's weekend time and i had no time
> and no interest to dig any further than to figure out the "first hop"
> of the change that broke the build, and the parties who initiated that
> hop. I'm in fact surprised that your and James's answer to my
> bugreport is hostility. )
What's hostile about telling you your patch is wrong and pointing you at
the correct one?
> So i find your suggestion that i should have added more people to the
> Cc: line unfair on several levels.
>
> > This set of changes seemed like 50% guesswork to me, without
> > consulting the authors :( And unlike many changes, you actually have
> > to know the hardware [or get clues from surrounding code] to make the
> > change.
>
> you mean the whole set of changes? Or just mine? Mine was a 30 seconds
> guesswork of course, i dont have the hardware, i didnt do the change,
> nor did i do anything near that code - i just saw the build failure stop
> my testing and sent in this notification and a hack. That's why i sent
> it to Greg, as a reply to the mail where he pushed these changes
> upstream and who'll know what to do with it from that point on. My patch
> can be totally thrown away (and should be, apparently).
>
> but ... i guess next time i'll think twice before sending any bugreports
> about or related to the SCSI code anywhere, unless they become really
> annoying. Who needs this hassle?
Oh good grief, don't come the raw prawn with us!
You're a kernel maintainer, you are expected to know the rules and
follow them. The very fact that a well known maintainer posts a patch
with a signed-off-by to Andrew and Linus means that it likely gets
applied. Because of this, maintainers and other people with similarly
trusted positions are expected to go via the lists and subsystems in
part as general courtesy, but also to verify that their patch is
actually valid before it gets applied.
Are you seriously telling us that it required too much investigation on
your part to figure out that something with a compile failure in
drivers/scsi might belong on the scsi list?
Let me tell you exactly what would have happened if that patch had been
applied: Because the wrong bars were enabled, the device would have
attached but been non-functional. Likely Emulex would have picked this
up in their -rc1 testing and spent several days trying to trace the
cause in their labs. Chances are, that, because this type of breakage
is extremely subtle, they wouldn't have noticed the fact that the enable
should have been _mem not _io. Then they would have raised the issue to
linux-scsi. It would probably take at least a person week of effort
before anyone finally noticed what the issue was.
If you can't see that your behaviour needs modifying, I suggest you
seriously consider your position. For all our talk of a nice utopian
democracy of meritocracy in Open Source, we're critically dependent on
the tree gatekeepers to maintain this. None of us is immune from the
subtle lure of the arrogance of power but it's a corrosive poison and
must be avoided at every turn. You and I follow more rules and are held
to a higher standard that the average patch submitter because of our
position in the community (not in spite of it).
James
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24)
2008-02-02 11:13 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Ingo Molnar
2008-02-02 15:51 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
@ 2008-02-02 18:44 ` Greg KH
2008-02-02 19:05 ` Ingo Molnar
1 sibling, 1 reply; 23+ messages in thread
From: Greg KH @ 2008-02-02 18:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Andrew Morton, linux-kernel, linux-pci, pcihpd-discuss
On Sat, Feb 02, 2008 at 12:13:22PM +0100, Ingo Molnar wrote:
>
> * Greg KH <gregkh@suse.de> wrote:
>
> > PCI: Remove users of pci_enable_device_bars()
> > PCI: Remove pci_enable_device_bars()
>
> simple allyesconfig testing found a build failure due to last night's
> PCI merge, on 32-bit x86:
>
> drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one':
> drivers/scsi/lpfc/lpfc_init.c:1897: error: implicit declaration of function 'pci_enable_device_bars'
>
> fix attached.
>
> ( This call has been introduced upstream 3 weeks ago by commit
> 8a4df120b07, but the PCI tree has apparently not been fully re-tested
> with Linus-latest since that point. )
Wait, my testing caught this. I made the change to the patch myself,
adding the needed conversion to my tree, it's here, on my disk!
Oh crap, I never checked it in.
/me goes off to sulk in shame.
Very sorry about this, totally my fault, I knew this needed to be fixed,
fixed it, but it didn't propogate to the tree to send to Linus.
I suck. I need a vacation and an empty inbox.
I'll be sending fixup patches for this and other merge messes in a few
hours, once the coffee has kicked in...
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 17:57 ` Ingo Molnar
@ 2008-02-02 18:49 ` Jeff Garzik
2008-02-02 19:35 ` Ingo Molnar
0 siblings, 1 reply; 23+ messages in thread
From: Jeff Garzik @ 2008-02-02 18:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
Ingo Molnar wrote:
> * Jeff Garzik <jeff@garzik.org> wrote:
>
>> Ingo Molnar wrote:
>>> it would have been totally appropriate for me to just send a mail to lkml
>>> with the proper subject line about the breakage. (I might even have
>>> decided to stay completely silent about the issue and fix it for my own
>>> build, letting you guys figure it out.)
>> Oh come on... You are smart enough to know to at least CC the driver
>> maintainer, the key POC who should be aware of breakage of their
>> driver. That is a standard courtesy.
>
> is there any particular reason why you cut out the most relevant part of
> my reply, which happens to answer all your questions AFAICS:
>
>>> Instead i did a search of lkml (based on the function name in the
>>> build error) and figured out where the pull request was on lkml:
>>> Greg. I replied to that mail, he'll obviously know whom else to Cc
>>> from that point on (if anyone). I really didnt want to (nor did i
>>> need to) figure out whether this was some general driver level API
>>> change that happen kernel-wide, or some SCSI specific change. I
>>> simply replied to the pull request whose Cc: line seemed
>>> well-populated to me already. I also took a look at the commit itself
>>> and did a quick hack in a hurry to keep the tests rolling. It really
>>> did not occur to me that i should have added anyone else to the Cc:
>>> line, as linux-pci@atrey.karlin.mff.cuni.cz was Cc:-ed already so i
>>> assumed the interest was from that angle.
>
> had you read this portion you'd have realized that i did not search for
> any "owner" of the file, i simply searched for the person who introduced
> the change, and the on-lkml mail where the change was introduced.
And therein lies the problem. The original submittor omitted relevant
maintainers, you followed that [incorrect] example, and the end result
was clear: an obviously wrong change.
Thus, the problem is precisely what you stated: you did not bother to
search for people who care about that file.
> and that's all that should be needed, really. Believe me, i hit tons of
Hardly. What part of "this change requires knowledge of the hardware"
is difficult to understand?
And if you do not have that knowledge, why is it so trying to CC people
who actively maintain a driver, and have that knowledge?
It's simple common sense to -ask- or at least -notify- in such cases.
That the original submittor made the same mistake is no reason to repeat
the mistake.
> bugs all across the kernel, often several bugs a day, and it's hard even
> for me to figure out who "maintains" a file and when. (and in Linux
> there's no "ownership" of files anyway) So as a general rule i go after
> changes instead, and that's exactly what i did here too. I do
> delta/regression QA - i.e. i watch for _changes_ that break the kernel
> and hence the general 'owner' of a file is often irrelevant - it's the
> maintainer who introduces a change who matters, and we do lots of
> cross-maintain merges. Only if i do not manage to identify a change do i
> try to figure out who maintains a file at that given moment. (But those
> mails often go into black holes, they get bounced, subscriber-required
> email lists, etc. etc.) It's also nontrivial to map the files to the
> MAINTAINERS file, and it's also quite outdated in some portions. So the
> MAINTAINERS file is the last resort i use.
That's a long list of excuses in an attempt to ignore the facts:
Fact 1: The driver you modified is actively maintained
Fact 2: The driver maintainer has respectfully indicated, through the
standard community mechanism, the useful points of contact.
Fact 3: The MAINTAINERS entry is correct and up-to-date.
Fact 4: Even if you wanted to ignore MAINTAINERS, 'git log' on the
relevant file could have told you who are useful parties to CC.
It's just common courtesy to CC a driver maintainer, ESPECIALLY when a
change requires knowledge of the driver/hardware in question.
> so i'm still totally befuddled why you think that there was anything
> particularly wrong or unhelpful about me replying to the specific pull
> request that introduced a particular breakage into the kernel. Had i
> mailed to lkml with a terse "kernel build broke" message with just an
> URL to a config and the build breakage, you could rightfully have
> complained that i should have done more to properly direct my bugreport.
> But this breakage was about a PCI API change, the pull request had a PCI
> mailing list Cc:-ed, why should i have thought that this needs the
> attention of any other parties?
Because the change required knowledge not only of PCI, but of the
hardware in question. As your patch demonstrated.
And yes -- the original changes should have been CC'd to interested
parties as well. I'm still waiting to hear back from Alan or Bart
whether the ATA/IDE changes in that PCI pile actually work... the
original changeset even noted that relevant parties had not yet been
queried.
Jeff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 18:08 ` James Bottomley
@ 2008-02-02 19:00 ` Ingo Molnar
0 siblings, 0 replies; 23+ messages in thread
From: Ingo Molnar @ 2008-02-02 19:00 UTC (permalink / raw)
To: James Bottomley
Cc: Jeff Garzik, Greg KH, Linus Torvalds, Andrew Morton,
linux-kernel, linux-pci, pcihpd-discuss, linux-scsi
* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> Are you seriously telling us that it required too much investigation
> on your part to figure out that something with a compile failure in
> drivers/scsi might belong on the scsi list?
This is getting silly. Let me repeat it, because IMO it's really
straightforward. My (quick) investigation based on the function name
that was in the error message:
drivers/scsi/lpfc/lpfc_init.c:1897: error: implicit declaration
of function 'pci_enable_device_bars'
a straightforward search on "pci_enable_device_bars" led to a recent PCI
API related change pushed by Greg, with the following straightforward
subject line:
[GIT PATCH] PCI patches for 2.6.24
http://lkml.org/lkml/2008/2/1/483
the email had this description:
| Some general cleanups, minor tweaks, and a bit of PCI hotplug
| updates, and some PCI Express updates for new features, if your
| hardware happens to support it.
furthermore, the mail already had two PCI mailing lists in its Cc: line.
The PCI subsystem regularly does cross-treee changes, by its nature.
i had all reasons to believe that this was a (innocious looking) PCI
subsystem change and a harmless (but a tad under-tested) API cleanup
that went haywire: it smelled like PCI, it walked like PCI and it
quacked like PCI.
So to me it was clearly a PCI merge not an SCSI merge, and i was really
only interested in the first hop, i.e. i was primarily interested in the
pull request that clearly changed multiple subsystems, and a seemingly
API change that broke the build.
Three mailing lists and three maintainers were already on the Cc: line
for that pull request. So tell me, exactly what should have let me to
believe that i should have added anyone else to the _already_ sizable
Cc: line?? I could have done it, had i have more time and had i realized
the full scope of the change and the somewhat misleading Cc:s that were
on the original pull request, but i clearly was not _required_ to - and
your suggestions to the contrary are ridiculous.
Furthermore i reject the sometimes derogatory undertone of your mails
that implies that i should somehow have done more or different work than
i already did.
I really hope you treat other contributors and bug-reporters better than
you treated me :( Shall this be my last voluntary SCSI contribution for
a good while.
Ingo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24)
2008-02-02 18:44 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Greg KH
@ 2008-02-02 19:05 ` Ingo Molnar
2008-02-02 20:56 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
0 siblings, 1 reply; 23+ messages in thread
From: Ingo Molnar @ 2008-02-02 19:05 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Andrew Morton, linux-kernel, linux-pci, pcihpd-discuss
* Greg KH <gregkh@suse.de> wrote:
> > ( This call has been introduced upstream 3 weeks ago by commit
> > 8a4df120b07, but the PCI tree has apparently not been fully
> > re-tested with Linus-latest since that point. )
>
> Wait, my testing caught this. I made the change to the patch myself,
> adding the needed conversion to my tree, it's here, on my disk!
>
> Oh crap, I never checked it in.
>
> /me goes off to sulk in shame.
you might want to join the (sizable) club of us deeply ashamed people
who recently introduced upstream build failures :-/
Ingo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 18:49 ` Jeff Garzik
@ 2008-02-02 19:35 ` Ingo Molnar
2008-02-02 20:48 ` Jeff Garzik
0 siblings, 1 reply; 23+ messages in thread
From: Ingo Molnar @ 2008-02-02 19:35 UTC (permalink / raw)
To: Jeff Garzik
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
* Jeff Garzik <jeff@garzik.org> wrote:
>> so i'm still totally befuddled why you think that there was anything
>> particularly wrong or unhelpful about me replying to the specific
>> pull request that introduced a particular breakage into the kernel.
>> Had i mailed to lkml with a terse "kernel build broke" message with
>> just an URL to a config and the build breakage, you could rightfully
>> have complained that i should have done more to properly direct my
>> bugreport. But this breakage was about a PCI API change, the pull
>> request had a PCI mailing list Cc:-ed, why should i have thought that
>> this needs the attention of any other parties?
>
> Because the change required knowledge not only of PCI, but of the
> hardware in question. As your patch demonstrated.
>
> And yes -- the original changes should have been CC'd to interested
> parties as well. I'm still waiting to hear back from Alan or Bart
> whether the ATA/IDE changes in that PCI pile actually work... the
> original changeset even noted that relevant parties had not yet been
> queried.
so please tell me Jeff. If Greg, who is the super-maintainer of your
code area, and who deals with your code every day and changes it every
minute and hour, simply did not Cc: the SCSI list - how am i, a largely
outside party in this matter, supposed to notice that 3 maintainers and
3 mailing lists in the Cc: were somehow not enough and that i was
supposed to grow the already sizable Cc: list even more?
Ingo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 19:35 ` Ingo Molnar
@ 2008-02-02 20:48 ` Jeff Garzik
2008-02-04 12:57 ` Ingo Molnar
0 siblings, 1 reply; 23+ messages in thread
From: Jeff Garzik @ 2008-02-02 20:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
Ingo Molnar wrote:
> so please tell me Jeff. If Greg, who is the super-maintainer of your
> code area, and who deals with your code every day and changes it every
> minute and hour, simply did not Cc: the SCSI list - how am i, a largely
> outside party in this matter, supposed to notice that 3 maintainers and
> 3 mailing lists in the Cc: were somehow not enough and that i was
> supposed to grow the already sizable Cc: list even more?
Because, regardless of the situation, it's both common courtesy and wise
practice to CC relevant driver maintainers, when you touch a driver.
And it's just common sense: Greg simply does not know the intimate
details of every PCI driver. Nor do I. Nor you.
In the case of lpfc here, we have an active driver maintainer, and an
up-to-date MAINTAINERS entry. Even if you are too slack to read
MAINTAINERS, 'git log' would have given you the same info.
Don't pretend there is some benefit here to ignoring the people that
best know the driver. I don't buy that; it simply makes no engineering
sense whatsoever.
Jeff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 19:05 ` Ingo Molnar
@ 2008-02-02 20:56 ` Jeff Garzik
2008-02-02 23:23 ` Greg KH
0 siblings, 1 reply; 23+ messages in thread
From: Jeff Garzik @ 2008-02-02 20:56 UTC (permalink / raw)
To: Ingo Molnar
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss
Ingo Molnar wrote:
> * Greg KH <gregkh@suse.de> wrote:
>
>>> ( This call has been introduced upstream 3 weeks ago by commit
>>> 8a4df120b07, but the PCI tree has apparently not been fully
>>> re-tested with Linus-latest since that point. )
>> Wait, my testing caught this. I made the change to the patch myself,
>> adding the needed conversion to my tree, it's here, on my disk!
>>
>> Oh crap, I never checked it in.
>>
>> /me goes off to sulk in shame.
>
> you might want to join the (sizable) club of us deeply ashamed people
> who recently introduced upstream build failures :-/
Personal CC differences aside <grin> I do think you guys both do a good
job of staying on top of your subsystems.
We all wear the brown paper bag on occasion, and with the "merge
maelstrom" during each merge window, I'm quite frankly amazed at how
_little_ stuff get broken overall.
Jeff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 20:56 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
@ 2008-02-02 23:23 ` Greg KH
0 siblings, 0 replies; 23+ messages in thread
From: Greg KH @ 2008-02-02 23:23 UTC (permalink / raw)
To: Jeff Garzik
Cc: Ingo Molnar, Andrew Morton, pcihpd-discuss, Greg KH,
linux-kernel, Linus Torvalds, linux-pci
On Sat, Feb 02, 2008 at 03:56:04PM -0500, Jeff Garzik wrote:
> Ingo Molnar wrote:
> > * Greg KH <gregkh@suse.de> wrote:
> >
> >>> ( This call has been introduced upstream 3 weeks ago by commit
> >>> 8a4df120b07, but the PCI tree has apparently not been fully
> >>> re-tested with Linus-latest since that point. )
> >> Wait, my testing caught this. I made the change to the patch myself,
> >> adding the needed conversion to my tree, it's here, on my disk!
> >>
> >> Oh crap, I never checked it in.
> >>
> >> /me goes off to sulk in shame.
> >
> > you might want to join the (sizable) club of us deeply ashamed people
> > who recently introduced upstream build failures :-/
>
> Personal CC differences aside <grin> I do think you guys both do a good
> job of staying on top of your subsystems.
Heh, thanks.
> We all wear the brown paper bag on occasion, and with the "merge
> maelstrom" during each merge window, I'm quite frankly amazed at how
> _little_ stuff get broken overall.
Yeah, I re-ran some statistics the other day on our kernel development
rate, and changed my formula after Andrew accused me of severely
undercounting the rate of change.
Turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did:
lines added per day: 4945
lines removed per day: 2006
lines modified per day: 1702
And note, that is real stuff, not renames or file moves at all, git
handles not reporting that.
That's for the 99 days that it took to do 2.6.24-rc8 (I need to re-run
the scripts now that 2.6.24 is out.)
It's fricken scarily amazing that things are still working at all...
Just something to make you all sleep well at night :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-02 20:48 ` Jeff Garzik
@ 2008-02-04 12:57 ` Ingo Molnar
2008-02-04 13:12 ` Andrew Morton
2008-02-04 15:30 ` Jeff Garzik
0 siblings, 2 replies; 23+ messages in thread
From: Ingo Molnar @ 2008-02-04 12:57 UTC (permalink / raw)
To: Jeff Garzik
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> so please tell me Jeff. If Greg, who is the super-maintainer of your
>> code area, and who deals with your code every day and changes it
>> every minute and hour, simply did not Cc: the SCSI list - how am i, a
>> largely outside party in this matter, supposed to notice that 3
>> maintainers and 3 mailing lists in the Cc: were somehow not enough
>> and that i was supposed to grow the already sizable Cc: list even
>> more?
>
> Because, regardless of the situation, it's both common courtesy and
> wise practice to CC relevant driver maintainers, when you touch a
> driver.
>
> And it's just common sense: Greg simply does not know the intimate
> details of every PCI driver. Nor do I. Nor you.
>
> In the case of lpfc here, we have an active driver maintainer, and an
> up-to-date MAINTAINERS entry. Even if you are too slack to read
> MAINTAINERS, 'git log' would have given you the same info.
>
> Don't pretend there is some benefit here to ignoring the people that
> best know the driver. I don't buy that; it simply makes no
> engineering sense whatsoever.
what you _STILL_ do not realize is the following: you still attribute
the lack of Cc:s to some intention of mine. No, it was not my intention.
At first glance the Cc: looked large and complete enough in an
_existing_ discussion and that's was the end of my (brief) attention
regarding the Cc: line. Yes, it would have been a bit better had i
noticed the lack of Cc:s in an existing discussion, but i didnt.
[ And it might not surprise you if i observe here that i think this
little mishap is further (incidental) proof that having this many
mailing list aliases to get the 'guaranteed attention' of maintainers
is just super fragile and does not serve users at all. Even Greg and i
got it wrong accidentally. If _we_ get it wrong, who will get it
right? I see several mis-Cc:ed emails every day and there's over a
1000 unfixed bugs in bugzilla for 2.6 alone. It does not take a genius
to observe that something is fundamentally wrong ;-) That 2.6 works on
your or my box is a _very_ poor metric - we both fix bugs on our
systems super fast so we've got a very biased first-hand experience
about the stability and reliability of the kernel. We never really
feel the kind of frustration that testers feel when their mail to lkml
gets ignored. We never really feel the helplessness that comes from
unfixed bugs. ]
Ingo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-04 12:57 ` Ingo Molnar
@ 2008-02-04 13:12 ` Andrew Morton
2008-02-04 15:32 ` Jeff Garzik
2008-02-04 15:30 ` Jeff Garzik
1 sibling, 1 reply; 23+ messages in thread
From: Andrew Morton @ 2008-02-04 13:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jeff Garzik, Greg KH, Linus Torvalds, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
On Mon, 4 Feb 2008 13:57:36 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Jeff Garzik <jeff@garzik.org> wrote:
>
> > Ingo Molnar wrote:
> >> so please tell me Jeff. If Greg, who is the super-maintainer of your
> >> code area, and who deals with your code every day and changes it
> >> every minute and hour, simply did not Cc: the SCSI list - how am i, a
> >> largely outside party in this matter, supposed to notice that 3
> >> maintainers and 3 mailing lists in the Cc: were somehow not enough
> >> and that i was supposed to grow the already sizable Cc: list even
> >> more?
> >
> > Because, regardless of the situation, it's both common courtesy and
> > wise practice to CC relevant driver maintainers, when you touch a
> > driver.
> >
> > And it's just common sense: Greg simply does not know the intimate
> > details of every PCI driver. Nor do I. Nor you.
> >
> > In the case of lpfc here, we have an active driver maintainer, and an
> > up-to-date MAINTAINERS entry. Even if you are too slack to read
> > MAINTAINERS, 'git log' would have given you the same info.
> >
> > Don't pretend there is some benefit here to ignoring the people that
> > best know the driver. I don't buy that; it simply makes no
> > engineering sense whatsoever.
>
> what you _STILL_ do not realize is the following: you still attribute
> the lack of Cc:s to some intention of mine. No, it was not my intention.
> At first glance the Cc: looked large and complete enough in an
> _existing_ discussion and that's was the end of my (brief) attention
> regarding the Cc: line. Yes, it would have been a bit better had i
> noticed the lack of Cc:s in an existing discussion, but i didnt.
Actually I (and probably others) generally avoid cc'ing mailing lists on
patch traffic. I spew out enough script-generated traffic as it is.
> ...
> mailing list aliases to get the 'guaranteed attention' of maintainers
>
whoa. You must know better mailing lists than I do ;)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-04 12:57 ` Ingo Molnar
2008-02-04 13:12 ` Andrew Morton
@ 2008-02-04 15:30 ` Jeff Garzik
1 sibling, 0 replies; 23+ messages in thread
From: Jeff Garzik @ 2008-02-04 15:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Greg KH, Linus Torvalds, Andrew Morton, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
Ingo Molnar wrote:
> * Jeff Garzik <jeff@garzik.org> wrote:
>
>> Ingo Molnar wrote:
>>> so please tell me Jeff. If Greg, who is the super-maintainer of your
>>> code area, and who deals with your code every day and changes it
>>> every minute and hour, simply did not Cc: the SCSI list - how am i, a
>>> largely outside party in this matter, supposed to notice that 3
>>> maintainers and 3 mailing lists in the Cc: were somehow not enough
>>> and that i was supposed to grow the already sizable Cc: list even
>>> more?
>> Because, regardless of the situation, it's both common courtesy and
>> wise practice to CC relevant driver maintainers, when you touch a
>> driver.
>>
>> And it's just common sense: Greg simply does not know the intimate
>> details of every PCI driver. Nor do I. Nor you.
>>
>> In the case of lpfc here, we have an active driver maintainer, and an
>> up-to-date MAINTAINERS entry. Even if you are too slack to read
>> MAINTAINERS, 'git log' would have given you the same info.
>>
>> Don't pretend there is some benefit here to ignoring the people that
>> best know the driver. I don't buy that; it simply makes no
>> engineering sense whatsoever.
>
> what you _STILL_ do not realize is the following: you still attribute
> the lack of Cc:s to some intention of mine. No, it was not my intention.
I was never speaking to intent.
I was noting that, having been in the kernel community for years, both
of you guys should know that you should always CC a driver author, when
touching their driver.
Even after this thread, I have not even heard a "yes, I agree, I should
have CC'd the driver author since they know the most about the driver"
from either of you, which is quite disappointing.
Instead, I get this long thread in response...
> is just super fragile and does not serve users at all. Even Greg and i
> got it wrong accidentally. If _we_ get it wrong, who will get it
Sure. But... do you agree the CC list should have included the driver
author? Do you agree that a mistake was made in this case?
Jeff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [patch] pci: pci_enable_device_bars() fix
2008-02-04 13:12 ` Andrew Morton
@ 2008-02-04 15:32 ` Jeff Garzik
0 siblings, 0 replies; 23+ messages in thread
From: Jeff Garzik @ 2008-02-04 15:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Greg KH, Linus Torvalds, linux-kernel, linux-pci,
pcihpd-discuss, linux-scsi, James Bottomley
Andrew Morton wrote:
> Actually I (and probably others) generally avoid cc'ing mailing lists on
> patch traffic. I spew out enough script-generated traffic as it is.
You pretty much always ensure the driver author gets CC'd, which is
exemplary :)
Jeff
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2008-02-04 15:32 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-01 23:11 [GIT PATCH] PCI patches for 2.6.24 Greg KH
2008-02-02 0:42 ` Andrew Morton
2008-02-02 0:49 ` Greg KH
2008-02-02 1:07 ` Andrew Morton
2008-02-02 11:13 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Ingo Molnar
2008-02-02 15:51 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
2008-02-02 16:01 ` James Bottomley
2008-02-02 17:08 ` Ingo Molnar
2008-02-02 17:33 ` Jeff Garzik
2008-02-02 17:57 ` Ingo Molnar
2008-02-02 18:49 ` Jeff Garzik
2008-02-02 19:35 ` Ingo Molnar
2008-02-02 20:48 ` Jeff Garzik
2008-02-04 12:57 ` Ingo Molnar
2008-02-04 13:12 ` Andrew Morton
2008-02-04 15:32 ` Jeff Garzik
2008-02-04 15:30 ` Jeff Garzik
2008-02-02 18:08 ` James Bottomley
2008-02-02 19:00 ` Ingo Molnar
2008-02-02 18:44 ` [patch] pci: pci_enable_device_bars() fix (was: [GIT PATCH] PCI patches for 2.6.24) Greg KH
2008-02-02 19:05 ` Ingo Molnar
2008-02-02 20:56 ` [patch] pci: pci_enable_device_bars() fix Jeff Garzik
2008-02-02 23:23 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).