linux-next: Tree for July 8 - Kernel

This is a discussion on linux-next: Tree for July 8 - Kernel ; Hi all, Changes since next-20080704: Temporarily dropped tree: ttydev (since it would not import on top of any tree I have) The usb.current gained a white space conflict against Linus' tree (which I assume will be gone as soon as ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: linux-next: Tree for July 8

  1. linux-next: Tree for July 8

    Hi all,

    Changes since next-20080704:

    Temporarily dropped tree: ttydev (since it would not import on top of any
    tree I have)

    The usb.current gained a white space conflict against Linus' tree (which I
    assume will be gone as soon as Greg rebases his tree).

    The usb tree gained a conflict against Linus' tree.

    The tip-core tree gained a conflict against Linus' tree.

    The sched tree lost a build fix patch.

    The x86 tree lost a conflict against Linus' tree but gained two against
    the ftrace tree.

    The pci tree gained a conflict against the driver-core tree and needed
    another build fix patch.

    The kbuild tree needed a commit reverted to fix the build.

    The acpi tree gained three m conflicts against the pci tree.

    The scsi tree gained 2 conflicts against the driver-core tree.

    the powerpc tree lost a conflict against the i2c tree.

    The net tree lost a conflict against Linus' tree but gained three more
    against the wireless-current, pci and x86 trees.

    The wireless tree lost its 2 conflicts.

    The trivial tree gained a conflict against Linus' tree.

    The firmware tree gained a conflict against Linus' tree.

    The battery tree gained 2 conflicts against the arm tree.

    The generic-ipi tree lost a conflict and a build fix patch.

    The mfd tree gained a conflict against Linus' tree.

    The hdlc tree gained 2 conflicts against the net tree.

    I have also applied the following patches for known problems (I assume
    that these will be merged into their appropriate trees shortly):

    fix "ftrace: store mcount address in rec->ip"
    linux-next: zero based percpu build error on s390
    sparc64: sysdev API change fallout

    The patches are no longer applied:

    NFS: Fix the mount protocol defaults for binary mounts (applies,
    but breaks the build)
    ttydev: fix pamc_zilog for tty pointer move
    ttydev: sparc fix for tty move
    ttydev: sparc32 fix for tty move
    atmel_serial: Fix tty_port breakage (the ttydev tree is not
    included today)
    linux-next: generic helpers for arch IPI function calls build bug / s390
    (no longer needed)

    I have also reverted 2 commits from the mmc tree because one of them
    broke the powerpc allyesconfig build.

    I also accidentally removed the merge log before committing it to the
    tree but the summary is still below.

    ----------------------------------------------------------------------------

    I have created today's linux-next tree at
    git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
    (patches at
    http://www.kernel.org/pub/linux/kern...fr/linux-next/). If you
    are tracking the linux-next tree using git, you should not use "git pull"
    to do so as that will try to merge the new linux-next release with the
    old one. You should use "git fetch" as mentioned in the FAQ on the wiki
    (see below).

    You can see which trees have been included by looking in the Next/Trees
    file in the source. There are also quilt-import.log and merge.log files
    in the Next directory. Between each merge, the tree was built with
    a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
    final fixups, it is also built with powerpc allnoconfig,
    44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.

    Below is a summary of the state of the merge.

    We are up to 104 trees (counting Linus' and 14 trees of patches pending for
    Linus' tree), more are welcome (even if they are currently empty).
    Thanks to those who have contributed, and to those who haven't, please do.

    Status of my local build tests will be at
    http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
    advice about cross compilers/configs that work, we are always open to add
    more builds.

    Thanks to Jan Dittmer for adding the linux-next tree to his build tests
    at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
    Dunlap for doing many randconfig builds.

    There is a wiki covering stuff to do with linux-next at
    http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.

    --
    Cheers,
    Stephen Rothwell sfr@canb.auug.org.au

    $ git checkout master
    $ git reset --hard stable
    Merging origin/master
    Merging powerpc-merge/merge
    Merging scsi-rc-fixes/master
    Merging net-current/master
    Merging sparc-current/master
    Merging sound-current/for-linus
    Merging arm-current/master
    Merging pci-current/for-linus
    Merging wireless-current/master
    Merging kbuild-current/master
    Merging quilt/driver-core.current
    Merging quilt/usb.current
    CONFLICT (content): Merge conflict in drivers/usb/core/hcd.c
    Merging cpufreq-current/fixes
    Merging input-current/for-linus
    Merging md-current/for-2.6.26
    Merging quilt/driver-core
    Merging quilt/usb
    CONFLICT (content): Merge conflict in drivers/usb/core/hub.c
    Merging tip-core/auto-core-next
    CONFLICT (content): Merge conflict in lib/vsprintf.c
    Merging cpus4096/auto-cpus4096-next
    Merging ftrace/auto-ftrace-next
    Merging genirq/auto-genirq-next
    Merging safe-poison-pointers/auto-safe-poison-pointers-next
    Merging sched/auto-sched-next
    CONFLICT (content): Merge conflict in kernel/Makefile
    CONFLICT (content): Merge conflict in kernel/sched.c
    CONFLICT (content): Merge conflict in kernel/sched_rt.c
    Merging stackprotector/auto-stackprotector-next
    Merging timers/auto-timers-next
    Merging x86/auto-x86-next
    CONFLICT (content): Merge conflict in arch/x86/kernel/entry_32.S
    CONFLICT (content): Merge conflict in arch/x86/kernel/entry_64.S
    CONFLICT (content): Merge conflict in arch/x86/kernel/process_32.c
    CONFLICT (content): Merge conflict in arch/x86/kernel/process_64.c
    CONFLICT (content): Merge conflict in drivers/base/topology.c
    CONFLICT (content): Merge conflict in include/asm-x86/irqflags.h
    Merging pci/linux-next
    CONFLICT (content): Merge conflict in arch/sparc64/kernel/pci.c
    CONFLICT (delete/modify): arch/x86/kernel/setup_64.c deleted in HEAD and modified in pci/linux-next. Version pci/linux-next of arch/x86/kernel/setup_64.c left in tree.
    CONFLICT (content): Merge conflict in arch/x86/pci/irq.c
    CONFLICT (content): Merge conflict in arch/x86/pci/pci.h
    CONFLICT (content): Merge conflict in include/linux/device.h
    Applying pci: usb fixup 1
    Applying pci: include linux/pm_wakeup.h for device_set_wakeup_capable
    Merging quilt/device-mapper
    Merging hid/mm
    Merging quilt/i2c
    CONFLICT (content): Merge conflict in drivers/i2c/i2c-core.c
    Merging quilt/kernel-doc
    Merging avr32/avr32-arch
    Merging v4l-dvb/stable
    CONFLICT (content): Merge conflict in drivers/media/video/Kconfig
    Applying v4l-dvb: class_for_each_device API change fallout
    Merging s390/features
    CONFLICT (content): Merge conflict in drivers/s390/block/dasd.c
    CONFLICT (content): Merge conflict in drivers/s390/block/dasd_eckd.c
    CONFLICT (content): Merge conflict in drivers/s390/block/dasd_fba.c
    CONFLICT (content): Merge conflict in drivers/s390/char/tape_core.c
    CONFLICT (content): Merge conflict in drivers/s390/cio/device_fsm.c
    CONFLICT (content): Merge conflict in drivers/s390/cio/qdio.c
    CONFLICT (content): Merge conflict in drivers/s390/net/claw.c
    CONFLICT (content): Merge conflict in drivers/s390/net/ctcm_main.c
    CONFLICT (content): Merge conflict in drivers/s390/net/lcs.c
    CONFLICT (content): Merge conflict in drivers/s390/net/netiucv.c
    Merging sh/master
    Merging jfs/next
    Merging kbuild/master
    Created commit 9aeede5: Revert "kconfig: normalize int/hex values"
    Merging quilt/ide
    Merging libata/NEXT
    Merging nfs/linux-next
    Merging xfs/master
    Merging infiniband/for-next
    Merging acpi/test
    CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
    CONFLICT (content): Merge conflict in arch/ia64/kernel/process.c
    CONFLICT (content): Merge conflict in arch/x86/kernel/process.c
    CONFLICT (content): Merge conflict in arch/x86/kernel/srat_32.c
    CONFLICT (content): Merge conflict in drivers/acpi/processor_core.c
    CONFLICT (content): Merge conflict in drivers/acpi/processor_throttling.c
    CONFLICT (content): Merge conflict in drivers/acpi/sleep/main.c
    CONFLICT (content): Merge conflict in drivers/pci/pci.c
    CONFLICT (content): Merge conflict in drivers/pci/pci.h
    CONFLICT (content): Merge conflict in include/acpi/acpi_bus.h
    CONFLICT (content): Merge conflict in include/asm-ia64/processor.h
    CONFLICT (content): Merge conflict in include/asm-x86/processor.h
    Merging blackfin/for-linus
    Merging nfsd/nfsd-next
    CONFLICT (content): Merge conflict in net/sunrpc/svc.c
    Merging ieee1394/for-next
    Merging hwmon/testing
    Merging ubi/master
    Merging kvm/master
    Merging dlm/next
    Merging scsi/master
    CONFLICT (content): Merge conflict in drivers/s390/scsi/zfcp_aux.c
    CONFLICT (content): Merge conflict in drivers/s390/scsi/zfcp_def.h
    Applying scsi: fix fallout from the class_find_device API change
    Applying scsi: fix fallout from KOBJ_NAME_LEN removal
    Merging ia64/test
    Merging tests/master
    CONFLICT (content): Merge conflict in lib/Kconfig.debug
    Merging ocfs2/linux-next
    Merging selinux/for-akpm
    Merging quilt/m68k
    Merging powerpc/powerpc-next
    CONFLICT (content): Merge conflict in drivers/macintosh/mediabay.c
    Merging lblnet/master
    Merging ext4/next
    Merging 4xx/next
    Merging async_tx/next
    Merging udf/for_next
    Merging security-testing/next
    Merging net/master
    CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt
    CONFLICT (content): Merge conflict in arch/x86/configs/x86_64_defconfig
    CONFLICT (content): Merge conflict in drivers/net/fs_enet/fs_enet-main.c
    CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-3945..c
    CONFLICT (content): Merge conflict in drivers/pci/pci-acpi.c
    Merging sparc/master
    Merging galak/powerpc-next
    Merging mtd/master
    Merging wireless/master
    Merging crypto/master
    Merging vfs/vfs-2.6.25
    Merging sound/master
    Merging arm/devel
    CONFLICT (content): Merge conflict in arch/arm/kernel/time.c
    CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-yl-9200.c
    Merging cpufreq/next
    CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
    Merging v9fs/for-next
    Merging quilt/rr
    CONFLICT (content): Merge conflict in drivers/char/hvc_console.h
    CONFLICT (content): Merge conflict in kernel/stop_machine.c
    Merging cifs/master
    Merging mmc/next
    Merging gfs2/master
    Merging input/next
    Merging semaphore/semaphore
    Merging semaphore-removal/semaphore-removal
    CONFLICT (content): Merge conflict in drivers/net/ps3_gelic_wireless.c
    CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_attr.c
    CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_def.h
    CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mbx.c
    CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mid.c
    CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_os.c
    Merging bkl-removal/bkl-removal
    CONFLICT (content): Merge conflict in fs/nfs/file.c
    Merging trivial/next
    CONFLICT (content): Merge conflict in include/linux/securebits.h
    Merging ubifs/for_andrew
    Merging lsm/for-next
    Merging block/for-next
    Merging embedded/master
    Merging firmware/master
    CONFLICT (content): Merge conflict in drivers/atm/Makefile
    CONFLICT (content): Merge conflict in drivers/char/ip2/ip2main.c
    CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Makefile
    CONFLICT (delete/modify): drivers/usb/serial/ti_fw_3410.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_3410.h left in tree.
    CONFLICT (delete/modify): drivers/usb/serial/ti_fw_5052.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_5052.h left in tree.
    CONFLICT (content): Merge conflict in drivers/usb/serial/ti_usb_3410_5052.c
    CONFLICT (content): Merge conflict in include/linux/firmware.h
    CONFLICT (content): Merge conflict in sound/pci/Kconfig
    CONFLICT (content): Merge conflict in sound/pci/maestro3.c
    CONFLICT (content): Merge conflict in sound/pci/ymfpci/ymfpci_main.c
    Merging pcmcia/master
    Merging battery/master
    CONFLICT (content): Merge conflict in drivers/power/Kconfig
    CONFLICT (content): Merge conflict in drivers/power/Makefile
    Merging leds/for-mm
    Merging backlight/for-mm
    CONFLICT (content): Merge conflict in drivers/video/backlight/Kconfig
    CONFLICT (content): Merge conflict in drivers/video/backlight/Makefile
    Merging kgdb/kgdb-next
    Merging slab/for-next
    Merging m68knommu/for-next
    Merging uclinux/for-next
    Merging md/for-next
    Merging cris/for-next
    Merging kmemcheck/auto-kmemcheck-next
    CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
    CONFLICT (content): Merge conflict in include/asm-x86/pgtable.h
    CONFLICT (content): Merge conflict in kernel/sysctl.c
    Merging generic-ipi/auto-generic-ipi-next
    CONFLICT (content): Merge conflict in arch/powerpc/mm/slice.c
    CONFLICT (content): Merge conflict in arch/s390/kernel/time.c
    CONFLICT (content): Merge conflict in arch/x86/kvm/vmx.c
    CONFLICT (content): Merge conflict in init/main.c
    CONFLICT (content): Merge conflict in net/iucv/iucv.c
    CONFLICT (content): Merge conflict in virt/kvm/kvm_main.c
    Applying generic-ipi: powerpc fallout fixes
    Merging mips/mips-for-linux-next
    Merging mfd/for-next
    CONFLICT (content): Merge conflict in MAINTAINERS
    Merging hdlc/hdlc-next
    CONFLICT (content): Merge conflict in drivers/net/wan/cosa.c
    CONFLICT (content): Merge conflict in drivers/net/wan/hdlc_fr.c
    CONFLICT (content): Merge conflict in drivers/net/wan/pc300_drv.c
    Applying linux-next: zero based percpu build error on s390
    Created commit 67849ef: Revert "mmc: fix spares errors of sdhci.c"
    Created commit 57488a6: Revert "sdhci: graceful handling of bad addresses"
    Applying sparc64: sysdev API change fallout

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkhzMesACgkQjjKRsyhoI8zMngCgvChWLXx+29 xZH4kYXfPEZ4FB
    xxwAn1enjC+rLpzWs3/M7DXkAno+UuYP
    =/Xj9
    -----END PGP SIGNATURE-----


  2. Re: linux-next: Tree for July 8 (HID)

    drivers/built-in.o: In function `usb_kbd_probe':
    usbkbd.c.text+0x1457c9): undefined reference to `usbhid_lookup_quirk'
    drivers/built-in.o: In function `usb_mouse_probe':
    usbmouse.c.text+0x14603c): undefined reference to `usbhid_lookup_quirk'
    make[1]: *** [.tmp_vmlinux1] Error 1


    from (partial config):

    CONFIG_HID_SUPPORT=y
    CONFIG_HID=y
    # CONFIG_HID_DEBUG is not set
    CONFIG_HIDRAW=y

    #
    # USB Input Devices
    #
    CONFIG_USB_HID=m
    CONFIG_USB_HIDINPUT_POWERBOOK=y
    CONFIG_HID_FF=y
    # CONFIG_HID_PID is not set
    CONFIG_LOGITECH_FF=y
    CONFIG_LOGIRUMBLEPAD2_FF=y
    # CONFIG_PANTHERLORD_FF is not set
    # CONFIG_THRUSTMASTER_FF is not set
    # CONFIG_ZEROPLUS_FF is not set
    CONFIG_USB_HIDDEV=y

    #
    # USB HID Boot Protocol drivers
    #
    CONFIG_USB_KBD=y
    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


    ---
    ~Randy
    Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
    http://linuxplumbersconf.org/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: linux-next: Tree for July 8 (ns8390)

    On Tue, 8 Jul 2008 11:35:29 -0700
    Randy Dunlap wrote:

    > (for Alan
    >
    > drivers/built-in.o: In function `ne_drv_resume':
    > ne.c.text+0xc9902): undefined reference to `NS8390_init'
    > drivers/built-in.o: In function `ne_block_output':
    > ne.c.text+0xc9c31): undefined reference to `NS8390_init'
    > drivers/built-in.o: In function `ne_probe1':
    > ne.c.init.text+0xbbb3): undefined reference to `NS8390_init'
    > drivers/built-in.o: In function `hp_probe1':
    > hp.c.init.text+0xc15a): undefined reference to `NS8390_init'


    beats me... my ne.c doesn't reference NS8390_init at all. The patch has
    been going around for so long I've really lost track of what happened to
    it over the many months.

    My tree has NS8390p_init in both of those drivers and no reference to
    NS8390_init at all.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: linux-next: Tree for July 8 (ns8390)

    Diff between my tree 8390 bits and linux-next ones

    8390: diff between next and my driver

    From: Alan Cox

    Please try this and if it sorts it fold it into the driver. This is a diff
    between my tree and the linux-next tree
    ---

    drivers/net/hp-plus.c | 2 +-
    drivers/net/hp.c | 2 +-
    drivers/net/ne.c | 8 ++++----
    drivers/net/wd.c | 2 +-
    4 files changed, 7 insertions(+), 7 deletions(-)


    diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
    index c2c4f49..8239939 100644
    --- a/drivers/net/hp-plus.c
    +++ b/drivers/net/hp-plus.c
    @@ -262,7 +262,7 @@ static int __init hpp_probe1(struct net_device *dev, int ioaddr)
    }

    outw(Perf_Page, ioaddr + HP_PAGING);
    - NS8390_init(dev, 0);
    + NS8390p_init(dev, 0);
    /* Leave the 8390 and HP chip reset. */
    outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION);

    diff --git a/drivers/net/hp.c b/drivers/net/hp.c
    index 8281209..0a8c649 100644
    --- a/drivers/net/hp.c
    +++ b/drivers/net/hp.c
    @@ -389,7 +389,7 @@ static void __init
    hp_init_card(struct net_device *dev)
    {
    int irq = dev->irq;
    - NS8390_init(dev, 0);
    + NS8390p_init(dev, 0);
    outb_p(irqmap[irq&0x0f] | HP_RUN,
    dev->base_addr - NIC_OFFSET + HP_CONFIGURE);
    return;
    diff --git a/drivers/net/ne.c b/drivers/net/ne.c
    index 1412697..4a8a4b1 100644
    --- a/drivers/net/ne.c
    +++ b/drivers/net/ne.c
    @@ -355,7 +355,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
    }

    /* Read the 16 bytes of station address PROM.
    - We must first initialize registers, similar to NS8390_init(eifdev, 0).
    + We must first initialize registers, similar to NS8390p_init(eifdev, 0).
    We can't reliably read the SAPROM address without this.
    (I learned the hard way!). */
    {
    @@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
    #ifdef CONFIG_NET_POLL_CONTROLLER
    dev->poll_controller = eip_poll;
    #endif
    - NS8390_init(dev, 0);
    + NS8390p_init(dev, 0);

    ret = register_netdev(dev);
    if (ret)
    @@ -794,7 +794,7 @@ retry:
    if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
    printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
    ne_reset_8390(dev);
    - NS8390_init(dev,1);
    + NS8390p_init(dev,1);
    break;
    }

    @@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform_device *pdev)

    if (netif_running(dev)) {
    ne_reset_8390(dev);
    - NS8390_init(dev, 1);
    + NS8390p_init(dev, 1);
    netif_device_attach(dev);
    }
    return 0;
    diff --git a/drivers/net/wd.c b/drivers/net/wd.c
    index fa14255..6f9aa16 100644
    --- a/drivers/net/wd.c
    +++ b/drivers/net/wd.c
    @@ -337,7 +337,7 @@ static int __init wd_probe1(struct net_device *dev, int ioaddr)
    #ifdef CONFIG_NET_POLL_CONTROLLER
    dev->poll_controller = ei_poll;
    #endif
    - NS8390_init(dev, 0);
    + NS8390p_init(dev, 0);

    #if 1
    /* Enable interrupt generation on softconfig cards -- M.U */
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: linux-next: Tree for July 8 (ns8390)

    On Tue, 8 Jul 2008 19:35:13 +0100 Alan Cox wrote:

    > Diff between my tree 8390 bits and linux-next ones
    >
    > 8390: diff between next and my driver
    >
    > From: Alan Cox
    >
    > Please try this and if it sorts it fold it into the driver. This is a diff
    > between my tree and the linux-next tree


    Yes, that's good. Thanks/Ack.

    > ---
    >
    > drivers/net/hp-plus.c | 2 +-
    > drivers/net/hp.c | 2 +-
    > drivers/net/ne.c | 8 ++++----
    > drivers/net/wd.c | 2 +-
    > 4 files changed, 7 insertions(+), 7 deletions(-)
    >
    >
    > diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
    > index c2c4f49..8239939 100644
    > --- a/drivers/net/hp-plus.c
    > +++ b/drivers/net/hp-plus.c
    > @@ -262,7 +262,7 @@ static int __init hpp_probe1(struct net_device *dev, int ioaddr)
    > }
    >
    > outw(Perf_Page, ioaddr + HP_PAGING);
    > - NS8390_init(dev, 0);
    > + NS8390p_init(dev, 0);
    > /* Leave the 8390 and HP chip reset. */
    > outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION);
    >
    > diff --git a/drivers/net/hp.c b/drivers/net/hp.c
    > index 8281209..0a8c649 100644
    > --- a/drivers/net/hp.c
    > +++ b/drivers/net/hp.c
    > @@ -389,7 +389,7 @@ static void __init
    > hp_init_card(struct net_device *dev)
    > {
    > int irq = dev->irq;
    > - NS8390_init(dev, 0);
    > + NS8390p_init(dev, 0);
    > outb_p(irqmap[irq&0x0f] | HP_RUN,
    > dev->base_addr - NIC_OFFSET + HP_CONFIGURE);
    > return;
    > diff --git a/drivers/net/ne.c b/drivers/net/ne.c
    > index 1412697..4a8a4b1 100644
    > --- a/drivers/net/ne.c
    > +++ b/drivers/net/ne.c
    > @@ -355,7 +355,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
    > }
    >
    > /* Read the 16 bytes of station address PROM.
    > - We must first initialize registers, similar to NS8390_init(eifdev, 0).
    > + We must first initialize registers, similar to NS8390p_init(eifdev, 0).
    > We can't reliably read the SAPROM address without this.
    > (I learned the hard way!). */
    > {
    > @@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
    > #ifdef CONFIG_NET_POLL_CONTROLLER
    > dev->poll_controller = eip_poll;
    > #endif
    > - NS8390_init(dev, 0);
    > + NS8390p_init(dev, 0);
    >
    > ret = register_netdev(dev);
    > if (ret)
    > @@ -794,7 +794,7 @@ retry:
    > if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
    > printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
    > ne_reset_8390(dev);
    > - NS8390_init(dev,1);
    > + NS8390p_init(dev,1);
    > break;
    > }
    >
    > @@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform_device *pdev)
    >
    > if (netif_running(dev)) {
    > ne_reset_8390(dev);
    > - NS8390_init(dev, 1);
    > + NS8390p_init(dev, 1);
    > netif_device_attach(dev);
    > }
    > return 0;
    > diff --git a/drivers/net/wd.c b/drivers/net/wd.c
    > index fa14255..6f9aa16 100644
    > --- a/drivers/net/wd.c
    > +++ b/drivers/net/wd.c
    > @@ -337,7 +337,7 @@ static int __init wd_probe1(struct net_device *dev, int ioaddr)
    > #ifdef CONFIG_NET_POLL_CONTROLLER
    > dev->poll_controller = ei_poll;
    > #endif
    > - NS8390_init(dev, 0);
    > + NS8390p_init(dev, 0);
    >
    > #if 1
    > /* Enable interrupt generation on softconfig cards -- M.U */
    > --


    ---
    ~Randy
    Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
    http://linuxplumbersconf.org/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: linux-next: Tree for July 8: nx6325-related commits

    Hi Ingo,

    On Tuesday, 8 of July 2008, Stephen Rothwell wrote:
    > Hi all,
    >
    > Changes since next-20080704:
    >
    > Temporarily dropped tree: ttydev (since it would not import on top of any
    > tree I have)
    >
    > The usb.current gained a white space conflict against Linus' tree (which I
    > assume will be gone as soon as Greg rebases his tree).
    >
    > The usb tree gained a conflict against Linus' tree.
    >
    > The tip-core tree gained a conflict against Linus' tree.
    >
    > The sched tree lost a build fix patch.
    >
    > The x86 tree lost a conflict against Linus' tree but gained two against
    > the ftrace tree.


    Commits 0b3d81ad4f765513347a04434efc15cbdc4e1c54
    ("x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APIC") and
    e38502eb8aa82314d5ab0eba45f50e6790dadd88
    ("x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systems")
    don't work on x86_64, because acpi_dmi_table[] depends on __i386__.

    Moreover, if you make them work (by removing that dependency), they hang my
    nx6325 solid early during boot.

    The revert patch is appended for your convenience. ;-)

    Thanks,
    Rafael

    ---
    arch/x86/kernel/acpi/boot.c | 47 --------------------------------------------
    1 file changed, 47 deletions(-)

    Index: linux-next/arch/x86/kernel/acpi/boot.c
    ================================================== =================
    --- linux-next.orig/arch/x86/kernel/acpi/boot.c
    +++ linux-next/arch/x86/kernel/acpi/boot.c
    @@ -83,8 +83,6 @@ int acpi_lapic;
    int acpi_ioapic;
    int acpi_strict;

    -static int disable_irq0_through_ioapic __initdata;
    -
    u8 acpi_sci_flags __initdata;
    int acpi_sci_override_gsi __initdata;
    int acpi_skip_timer_override __initdata;
    @@ -996,10 +994,6 @@ mp_override_legacy_irq(u8 bus_irq, u8 po
    int pin;
    struct mp_config_intsrc mp_irq;

    - /* Skip the 8254 timer interrupt (IRQ 0) if requested. */
    - if (bus_irq == 0 && disable_irq0_through_ioapic)
    - return;
    -
    /*
    * Convert 'gsi' to 'ioapic.pin'.
    */
    @@ -1066,10 +1060,6 @@ static void __init mp_config_acpi_legacy
    for (i = 0; i < 16; i++) {
    int idx;

    - /* Skip the 8254 timer interrupt (IRQ 0) if requested. */
    - if (i == 0 && disable_irq0_through_ioapic)
    - continue;
    -
    for (idx = 0; idx < mp_irq_entries; idx++) {
    struct mp_config_intsrc *irq = mp_irqs + idx;

    @@ -1429,17 +1419,6 @@ static int __init force_acpi_ht(const st
    }

    /*
    - * Don't register any I/O APIC entries for the 8254 timer IRQ.
    - */
    -static int __init
    -dmi_disable_irq0_through_ioapic(const struct dmi_system_id *d)
    -{
    - pr_notice("%s detected: disabling IRQ 0 through I/O APIC\n", d->ident);
    - disable_irq0_through_ioapic = 1;
    - return 0;
    -}
    -
    -/*
    * If your system is blacklisted here, but you find that acpi=force
    * works for you, please contact acpi-devel@sourceforge.net
    */
    @@ -1606,32 +1585,6 @@ static struct dmi_system_id __initdata a
    DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
    },
    },
    - /*
    - * HP laptops which use a DSDT reporting as HP/SB400/10000,
    - * which includes some code which overrides all temperature
    - * trip points to 16C if the INTIN2 input of the I/O APIC
    - * is enabled. This input is incorrectly designated the
    - * ISA IRQ 0 via an interrupt source override even though
    - * it is wired to the output of the master 8259A and INTIN0
    - * is not connected at all. Abandon any attempts to route
    - * IRQ 0 through the I/O APIC therefore.
    - */
    - {
    - .callback = dmi_disable_irq0_through_ioapic,
    - .ident = "HP NX6125 laptop",
    - .matches = {
    - DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
    - DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6125"),
    - },
    - },
    - {
    - .callback = dmi_disable_irq0_through_ioapic,
    - .ident = "HP NX6325 laptop",
    - .matches = {
    - DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
    - DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
    - },
    - },
    {}
    };

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: linux-next: Tree for July 8 (HID)

    On Tue, 8 Jul 2008, Randy Dunlap wrote:

    > drivers/built-in.o: In function `usb_kbd_probe':
    > usbkbd.c.text+0x1457c9): undefined reference to `usbhid_lookup_quirk'
    > drivers/built-in.o: In function `usb_mouse_probe':
    > usbmouse.c.text+0x14603c): undefined reference to `usbhid_lookup_quirk'
    > make[1]: *** [.tmp_vmlinux1] Error 1


    This got introduced by Jiri's

    HID: fix quirk handling in usbmouse/kbd

    Added to CC (and added also Pascal).

    The dependency of usbkbd/usbmouse on usbhid is strange anyway. I'd
    probably remove the whole quirk lookup thing from usbkbd/usbmouse drivers.
    They introduce this ugly dependency, which is not worth it I guess. Also
    usbkbd/usbmouse drivers are not needed in the vast majority of cases
    anyway, and they shouldn't be loaded in standard configurations at all.

    --
    Jiri Kosina
    SUSE Labs
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: linux-next: Tree for July 8: nx6325-related commits

    On Wed, 9 Jul 2008, Rafael J. Wysocki wrote:

    > Commits 0b3d81ad4f765513347a04434efc15cbdc4e1c54
    > ("x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APIC") and
    > e38502eb8aa82314d5ab0eba45f50e6790dadd88
    > ("x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systems")
    > don't work on x86_64, because acpi_dmi_table[] depends on __i386__.
    >
    > Moreover, if you make them work (by removing that dependency), they hang my
    > nx6325 solid early during boot.


    I have build an x86-64 cross-compiler now and can test 64-bit kernels.
    I have tested the patches you have requested to be reverted in a 64-bit
    configuration now and discovered the following problems elsewhere:

    1. Unlike the 32-bit one, the 64-bit variation of the LVT0 setup code for
    the "8259A Virtual Wire" through the local APIC timer configuration
    does not fully configure the relevant irq_chip structure. Instead it
    relies on the preceding I/O APIC code to have set it up, which does not
    happen if the I/O APIC variants have not been tried. I think this is
    the reason of your hang.

    2. As mentioned in the other mail, there is no such entity as ISA IRQ2.
    The ACPI spec does not make it explicitly clear, but does not preclude
    it either -- all it says is ISA legacy interrupts are identity mapped
    by default (subject to overrides), but it does not state whether IRQ2
    exists or not. As a result if there is no IRQ0 override, then IRQ2 is
    normally initialised as an ISA interrupt, which implies an
    edge-triggered line, which is unmasked by default as this is what we do
    for edge-triggered I/O APIC interrupts so as not to miss an edge.

    To the best of my knowledge it is useless, as IRQ2 has not been in use
    since the PC/AT as back then it was taken by the 8259A cascade
    interrupt to the slave, with the line posiotion in the slot rerouted to
    newly-created IRQ9. No device could thus make use of this line with
    the pair of 8259A chips. Now in theory INTIN2 of the I/O APIC may be
    usable, but the interrupt of the device wired to it would not be
    available in the PIC mode at all, so I seriously doubt if anybody
    decided to reuse it for a regular device (anybody please feel free to
    prove me otherwise).

    However there are two common uses of INTIN2. One is for IRQ0, with an
    ACPI interrupt override (or its equivalent in the MP table). But in
    this case IRQ2 is gone entirely with INTIN0 left vacant. The other one
    is for an 8959A ExtINTA cascade. In this case IRQ0 goes to INTIN0 and
    if ACPI is used INTIN2 is assumed to be IRQ2 (there is no override and
    ACPI has no way to report ExtINTA interrupts). This is where a problem
    happens.

    The problem is INTIN2 is configured as a native APIC interrupt, with a
    vector assigned and the mask cleared. And the line may indeed get
    active and inject interrupts if the master 8959A has its timer
    interrupt enabled (it might happen for other interrupts too, but they
    are normally masked in the process of rerouting them to the I/O APIC).
    There are two cases where it will happen:

    * When the I/O APIC NMI watchdog is enabled. This is actually a
    misnomer as the watchdog pulses are delivered through the 8259A to
    the LINT0 inputs of all the local APICs in the system. The
    implication is the output of the master 8259A goes high and low
    repeatedly, signalling interrupts to INTIN2 which is enabled too!

    [The origin of the name is I think for a brief period during the
    development we had a capability in our code to configure the watchdog
    to use an I/O APIC input; that would be INTIN2 in this scenario.]

    * When the native route of IRQ0 via INTIN0 fails for whatever reason --
    as it happens with the system considered here. In this scenario the
    timer pulse is delivered through the 8259A to LINT0 input of the
    local APIC of the bootstrap processor, quite similarly to how is done
    for the watchdog described above. The result is, again, INTIN2
    receives these pulses too. Rafael's system used to escape this
    scenario, because an incorrect IRQ0 override would occupy INTIN2 and
    prevent it from being unmasked.

    My conclusion is IRQ2 should be excluded from configuration in all the
    cases and the current exception for ACPI systems should be lifted. The
    reason being the exception not only being useless, but harmful as well.

    I have patches ready to address both issues, but I will test them against
    linux-next yet, to avoid any dissynchronisation that may happen similar to
    some recent experiences. I shall post the patches later today. At that
    point 0b3d81ad4f765513347a04434efc15cbdc4e1c54 and
    e38502eb8aa82314d5ab0eba45f50e6790dadd88 should be safe to bring back.

    Maciej
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: linux-next: Tree for July 8: nx6325-related commits

    On Wed, Jul 09, 2008 at 03:17:58PM +0100, Maciej W. Rozycki wrote:
    > On Wed, 9 Jul 2008, Rafael J. Wysocki wrote:
    >
    > > Commits 0b3d81ad4f765513347a04434efc15cbdc4e1c54
    > > ("x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APIC") and
    > > e38502eb8aa82314d5ab0eba45f50e6790dadd88
    > > ("x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systems")
    > > don't work on x86_64, because acpi_dmi_table[] depends on __i386__.
    > >
    > > Moreover, if you make them work (by removing that dependency), they hang my
    > > nx6325 solid early during boot.

    >
    > I have build an x86-64 cross-compiler now and can test 64-bit kernels.
    > I have tested the patches you have requested to be reverted in a 64-bit
    > configuration now and discovered the following problems elsewhere:
    >
    > 1. Unlike the 32-bit one, the 64-bit variation of the LVT0 setup code for
    > the "8259A Virtual Wire" through the local APIC timer configuration
    > does not fully configure the relevant irq_chip structure. Instead it
    > relies on the preceding I/O APIC code to have set it up, which does not
    > happen if the I/O APIC variants have not been tried. I think this is
    > the reason of your hang.


    FYI, I looked further into the missing interrupt problem (testing on
    64-bit, with Rafael's patch version and "Virtual Wire Mode" for the
    timer IRQ).
    Just before the weird behaviour I have two log entries:

    APIC error on CPU1: 00(40)
    APIC error on CPU0: 00(40)

    AFAIK 0x40 is "Illegal Register Address" error:

    "Illegal Register Address (IRA)Bit 7. The IRA bit when set to 1
    indicates that an access to an unimplemented register location within
    the local APIC register range (APIC Base Address + 4 Kbytes) was
    attempted."

    I've tried to track down who is responsible for that access. But I
    didn't find the offender yet. Maybe it's Linux or some SMM stuff?
    Don't know.

    Right after those messages no interrupts from PIT/PIC (which should be
    "virtual wired" to LVT0 of CPU0) are received anymore. I dumped PIC
    and local APIC settings but I did not find any suspicious things here.

    > 2. As mentioned in the other mail, there is no such entity as ISA IRQ2.
    > The ACPI spec does not make it explicitly clear, but does not preclude
    > it either -- all it says is ISA legacy interrupts are identity mapped
    > by default (subject to overrides), but it does not state whether IRQ2
    > exists or not. As a result if there is no IRQ0 override, then IRQ2 is
    > normally initialised as an ISA interrupt, which implies an
    > edge-triggered line, which is unmasked by default as this is what we do
    > for edge-triggered I/O APIC interrupts so as not to miss an edge.
    >
    > To the best of my knowledge it is useless, as IRQ2 has not been in use
    > since the PC/AT as back then it was taken by the 8259A cascade
    > interrupt to the slave, with the line posiotion in the slot rerouted to
    > newly-created IRQ9. No device could thus make use of this line with
    > the pair of 8259A chips. Now in theory INTIN2 of the I/O APIC may be
    > usable, but the interrupt of the device wired to it would not be
    > available in the PIC mode at all, so I seriously doubt if anybody
    > decided to reuse it for a regular device (anybody please feel free to
    > prove me otherwise).
    >
    > However there are two common uses of INTIN2. One is for IRQ0, with an
    > ACPI interrupt override (or its equivalent in the MP table). But in
    > this case IRQ2 is gone entirely with INTIN0 left vacant. The other one
    > is for an 8959A ExtINTA cascade. In this case IRQ0 goes to INTIN0 and
    > if ACPI is used INTIN2 is assumed to be IRQ2 (there is no override and
    > ACPI has no way to report ExtINTA interrupts). This is where a problem
    > happens.
    >
    > The problem is INTIN2 is configured as a native APIC interrupt, with a
    > vector assigned and the mask cleared. And the line may indeed get
    > active and inject interrupts if the master 8959A has its timer
    > interrupt enabled (it might happen for other interrupts too, but they
    > are normally masked in the process of rerouting them to the I/O APIC).
    > There are two cases where it will happen:
    >
    > * When the I/O APIC NMI watchdog is enabled. This is actually a
    > misnomer as the watchdog pulses are delivered through the 8259A to
    > the LINT0 inputs of all the local APICs in the system. The
    > implication is the output of the master 8259A goes high and low
    > repeatedly, signalling interrupts to INTIN2 which is enabled too!
    >
    > [The origin of the name is I think for a brief period during the
    > development we had a capability in our code to configure the watchdog
    > to use an I/O APIC input; that would be INTIN2 in this scenario.]
    >
    > * When the native route of IRQ0 via INTIN0 fails for whatever reason --
    > as it happens with the system considered here. In this scenario the
    > timer pulse is delivered through the 8259A to LINT0 input of the
    > local APIC of the bootstrap processor, quite similarly to how is done
    > for the watchdog described above. The result is, again, INTIN2
    > receives these pulses too. Rafael's system used to escape this
    > scenario, because an incorrect IRQ0 override would occupy INTIN2 and
    > prevent it from being unmasked.
    >
    > My conclusion is IRQ2 should be excluded from configuration in all the
    > cases and the current exception for ACPI systems should be lifted. The
    > reason being the exception not only being useless, but harmful as well.


    Before I reread all the above -- here are just some early comments
    regarding the IRQ0 override:

    * HPET timer 0 in legacy mode should be connected to INTIN2.

    * To configure this at least some chipsets are able to "swap" INTIN0
    and INTIN2:

    Say default is IRQ0 -> INTIN0 and output of PIC -> INTIN2. Doing
    "some chipset magic" it is possible to swap it such that IRQ0 ->
    INTIN2 and output of PIC -> INTIN0.

    I might be wrong but maybe that "feature" was invented for HPET
    usage in legacy mode -- to deliver timer interrupts to INTIN2.
    IMHO for this scenario the IRQ0/INTIN2 override exists.

    To complete the confusion, the nx6325 box that I am testing on
    advertises an IRQ0/INTIN2 override but INTIN0/INTIN2 are _not_
    swapped ... That's the point where I think the BIOS of the box is
    totally broken or I just missed some real important bit. ;-(


    Regards,

    Andreas


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: linux-next: Tree for July 8: nx6325-related commits

    On Thu, 10 Jul 2008, Andreas Herrmann wrote:

    > FYI, I looked further into the missing interrupt problem (testing on
    > 64-bit, with Rafael's patch version and "Virtual Wire Mode" for the
    > timer IRQ).
    > Just before the weird behaviour I have two log entries:
    >
    > APIC error on CPU1: 00(40)
    > APIC error on CPU0: 00(40)
    >
    > AFAIK 0x40 is "Illegal Register Address" error:
    >
    > "Illegal Register Address (IRA)Bit 7. The IRA bit when set to 1
    > indicates that an access to an unimplemented register location within
    > the local APIC register range (APIC Base Address + 4 Kbytes) was
    > attempted."
    >
    > I've tried to track down who is responsible for that access. But I
    > didn't find the offender yet. Maybe it's Linux or some SMM stuff?
    > Don't know.
    >
    > Right after those messages no interrupts from PIT/PIC (which should be
    > "virtual wired" to LVT0 of CPU0) are received anymore. I dumped PIC
    > and local APIC settings but I did not find any suspicious things here.


    The return address from the interrupt handler would be useful here as I
    would expect it not to be far off from the offending access. I haven't
    seen such errors on my system, so I cannot track the cause down myself.

    > Before I reread all the above -- here are just some early comments
    > regarding the IRQ0 override:
    >
    > * HPET timer 0 in legacy mode should be connected to INTIN2.


    The HPET spec uses INTIN2 throughout, but I think unless a counterexample
    is seen, we should simply assume it uses the same lines the 8254 uses or
    would use, which is ISA IRQ0, and is subject to the same ACPI interrupt
    routing rules. This is especially implied by how the LEG_RT_CNF bit has
    been specified and what common sense suggests. Alternatively we could
    assume any system which maps ISA IRQ0 to INTIN0 is not compliant to the
    HPET spec.

    I cannot tell more about the HPET in the native mode at the moment --
    certainly it is not safe to share an I/O APIC pin between an HPET
    interrupt and the ExtINTA line. And ACPI has no way to report ExtINTA
    lines, so I suppose the best bet is either to reuse the line that is known
    to work for IRQ0, replacing the 8254 or to avoid the legacy range of up to
    IRQ15 in the APIC mode altogether. All I can say is the three HPET timers
    on my system support the interrupts IRQ20-23 as well as, in the case of
    the timer #2, IRQ11.

    Unfortunately the quality of the spec (at least version 1.0a I have here)
    is rather substandard.

    > * To configure this at least some chipsets are able to "swap" INTIN0
    > and INTIN2:
    >
    > Say default is IRQ0 -> INTIN0 and output of PIC -> INTIN2. Doing
    > "some chipset magic" it is possible to swap it such that IRQ0 ->
    > INTIN2 and output of PIC -> INTIN0.
    >
    > I might be wrong but maybe that "feature" was invented for HPET
    > usage in legacy mode -- to deliver timer interrupts to INTIN2.
    > IMHO for this scenario the IRQ0/INTIN2 override exists.


    Well, it sounds like a "feature" to workaround the broken spec which
    refers explicitly to INTIN2 rather than ISA IRQ0. Historically, IRQ0 was
    typically routed to INTIN2 rather than INTIN0 (and the ExtINTA line went
    to the latter) even on APIC implementations as discrete as the 82489DX,
    where the system implementer had full freedom to route lines however they
    liked as all were external and went through the PCB.

    The only explanation I could imagine is such a setup was specified among
    the few "default configurations" Intel's Multiprocessor Specification
    provided. Even in its first publicly available version 1.1 full routing
    tables could have been specified which could describe arbitrary
    configurations. However it is possible earlier versions might have been
    limited in this regard and for example provide for these "default
    configurations" only. I have a vague recollection from some discussion
    which makes me think this was really the case. Then most of the
    implementers followed the early ones, including interrupt routing
    hardwired on-chip inside more integrated implementations, and therefore
    most of the systems at least up to the moment ACPI has started being
    deployed used the arrangement where IRQ0 is wired to INTIN2.

    > To complete the confusion, the nx6325 box that I am testing on
    > advertises an IRQ0/INTIN2 override but INTIN0/INTIN2 are _not_
    > swapped ... That's the point where I think the BIOS of the box is
    > totally broken or I just missed some real important bit. ;-(


    I have posted the patches now -- it has been longer than expected, but
    with the number of local patches in my tree reaching 90 I had to improve
    procedures for tree updates and it took me some extra time. I think these
    patches will let us improve some other code that has been recently
    prepared to tackle this nx6325 breakage as soon as possible. I'll have a
    look into it.

    Now that you mentioned that the SB400 is capable of swapping INTIN0 and
    INTIN2, I think this is information we could make use of to patch
    interrupt routing tables correctly. Is the state of the swapping circuit
    readable from the chip anywhere?

    Maciej
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: linux-next: Tree for July 8 (HID)

    On Wed, 9 Jul 2008 09:59:24 +0200 (CEST) Jiri Kosina wrote:

    > On Tue, 8 Jul 2008, Randy Dunlap wrote:
    >
    > > drivers/built-in.o: In function `usb_kbd_probe':
    > > usbkbd.c.text+0x1457c9): undefined reference to `usbhid_lookup_quirk'
    > > drivers/built-in.o: In function `usb_mouse_probe':
    > > usbmouse.c.text+0x14603c): undefined reference to `usbhid_lookup_quirk'
    > > make[1]: *** [.tmp_vmlinux1] Error 1

    >
    > This got introduced by Jiri's
    >
    > HID: fix quirk handling in usbmouse/kbd
    >
    > Added to CC (and added also Pascal).
    >
    > The dependency of usbkbd/usbmouse on usbhid is strange anyway. I'd
    > probably remove the whole quirk lookup thing from usbkbd/usbmouse drivers.
    > They introduce this ugly dependency, which is not worth it I guess. Also
    > usbkbd/usbmouse drivers are not needed in the vast majority of cases
    > anyway, and they shouldn't be loaded in standard configurations at all.


    Build error still present in linux-next 20080718.
    Please fix it in some manner.

    ---
    ~Randy
    Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
    http://linuxplumbersconf.org/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: linux-next: Tree for July 8 (HID)

    On Fri, 18 Jul 2008, Randy Dunlap wrote:

    >> The dependency of usbkbd/usbmouse on usbhid is strange anyway. I'd
    >> probably remove the whole quirk lookup thing from usbkbd/usbmouse
    >> drivers. They introduce this ugly dependency, which is not worth it I
    >> guess. Also usbkbd/usbmouse drivers are not needed in the vast majority
    >> of cases anyway, and they shouldn't be loaded in standard
    >> configurations at all.

    > Build error still present in linux-next 20080718.
    > Please fix it in some manner.


    OK, I have just completely removed the quirk lookup from usbmouse/usbkbd
    drivers. So this should be fixed in next -next.

    Thanks,

    --
    Jiri Kosina
    SUSE Labs
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread