27 Feb, 2012

1 commit

  • The problem in

    commit fea80311a939a746533a6d7e7c3183729d6a3faf
    Author: Randy Dunlap
    Date: Sun Jul 24 11:39:14 2011 -0700

    iomap: make IOPORT/PCI mapping functions conditional

    is that if your architecture supplies pci_iomap/pci_iounmap, it expects
    always to supply them. Adding empty body defitions in the !CONFIG_PCI
    case, which is what this patch does, breaks the parisc compile because
    the functions become doubly defined. It took us a while to spot this,
    because we don't actually build !CONFIG_PCI very often (only if someone
    is brave enough to test the snake/asp machines).

    Since the note in the commit log says this is to fix a
    CONFIG_GENERIC_IOMAP issue (which it does because CONFIG_GENERIC_IOMAP
    supplies pci_iounmap only if CONFIG_PCI is set), there should actually
    have been a condition upon this. This should make sure no other
    architecture's !CONFIG_PCI compile breaks in the same way as parisc.

    The fix had to be updated to take account of the GENERIC_PCI_IOMAP
    separation.

    Reported-by: Rolf Eike Beer
    Signed-off-by: James Bottomley

    James Bottomley
     

29 Nov, 2011

1 commit


26 Jul, 2011

1 commit

  • When CONFIG_PCI is not enabled, CONFIG_EISA=y, and CONFIG_GENERIC_IOMAP=y,
    drivers/net/3c59x.c build fails due to a recent small change to
    that surrounds pci_iomap() and pci_iounmap() with
    #ifdef CONFIG_PCI/#endif.

    Since that patch to iomap.h looks correct, add stubs for pci_iomap() and
    pci_iounmap() with CONFIG_PCI is not enabled to fix the build errors.

    drivers/net/3c59x.c:1026: error: implicit declaration of function 'pci_iomap'
    drivers/net/3c59x.c:1038: error: implicit declaration of function 'pci_iounmap'

    Signed-off-by: Randy Dunlap
    Cc: Jonas Bonn
    Cc: Arnd Bergmann
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

23 Jul, 2011

1 commit


25 Apr, 2008

1 commit


09 Feb, 2008

1 commit


17 Apr, 2005

2 commits

  • In the new io infrastructure, all of our operators are expecting the
    underlying device to be little endian (because the PCI bus, their main
    consumer, is LE).

    However, there are a fair few devices and busses in the world that are
    actually Big Endian. There's even evidence that some of these BE bus and
    chip types are attached to LE systems. Thus, there's a need for a BE
    equivalent of our io{read,write}{16,32} operations.

    The attached patch adds this as io{read,write}{16,32}be. When it's in,
    I'll add the first consume (the 53c700 SCSI chip driver).

    Signed-off-by: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    James Bottomley
     
  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds