1. 04 Aug, 2016 1 commit
    • Krzysztof Kozlowski's avatar
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski authored
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      Semantic patches for this change (at least most of them):
          virtual patch
          virtual context
          identifier f, attrs;
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          identifier r.f;
          - NULL
          + 0
          // Options: --all-includes
          virtual patch
          virtual context
          identifier f, attrs;
          type t;
          t f(..., struct dma_attrs *attrs);
          identifier r.f;
          - NULL
          + 0
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: 's avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: 's avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: 's avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: 's avatarHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: 's avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: 's avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 08 Mar, 2016 1 commit
    • Bjorn Helgaas's avatar
      PCI: Include pci/hotplug Kconfig directly from pci/Kconfig · e7e127e3
      Bjorn Helgaas authored
      Include pci/hotplug/Kconfig directly from pci/Kconfig, so arches don't
      have to source both pci/Kconfig and pci/hotplug/Kconfig.
      Note that this effectively adds pci/hotplug/Kconfig to the following
      arches, because they already sourced drivers/pci/Kconfig but they
      previously did not source drivers/pci/hotplug/Kconfig:
      Inspired-by-patch-from: Bogicevic Sasa <brutallesale@gmail.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
  3. 30 Jan, 2016 1 commit
  4. 20 Jan, 2016 1 commit
  5. 12 Jan, 2016 1 commit
  6. 12 Dec, 2015 1 commit
    • Mikulas Patocka's avatar
      parisc iommu: fix panic due to trying to allocate too large region · e46e31a3
      Mikulas Patocka authored
      When using the Promise TX2+ SATA controller on PA-RISC, the system often
      crashes with kernel panic, for example just writing data with the dd
      utility will make it crash.
      Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources
      CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
       [<000000004021497c>] show_stack+0x14/0x20
       [<0000000040410bf0>] dump_stack+0x88/0x100
       [<000000004023978c>] panic+0x124/0x360
       [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
       [<0000000040453150>] sba_map_sg+0x260/0x5b8
       [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
       [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
       [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
       [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
       [<000000004049da34>] scsi_request_fn+0x6e4/0x970
       [<00000000403e95a8>] __blk_run_queue+0x40/0x60
       [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
       [<000000004049a534>] scsi_run_queue+0x2a4/0x360
       [<000000004049be68>] scsi_end_request+0x1a8/0x238
       [<000000004049de84>] scsi_io_completion+0xfc/0x688
       [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0
      The cause of the crash is not exhaustion of the IOMMU space, there is
      plenty of free pages. The function sba_alloc_range is called with size
      0x11000, thus the pages_needed variable is 0x11. The function
      sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
      0x10 (because dma_get_seg_boundary(dev) returns 0xffff).
      The function sba_search_bitmap attempts to allocate 17 pages that must not
      cross 16-page boundary - it can't satisfy this requirement
      (iommu_is_span_boundary always returns true) and fails even if there are
      many free entries in the IOMMU space.
      How did it happen that we try to allocate 17 pages that don't cross
      16-page boundary? The cause is in the function iommu_coalesce_chunks. This
      function tries to coalesce adjacent entries in the scatterlist. The
      function does several checks if it may coalesce one entry with the next,
      one of those checks is this:
      	if (startsg->length + dma_len > max_seg_size)
      When it finishes coalescing adjacent entries, it allocates the mapping:
      sg_dma_len(contig_sg) = dma_len;
      dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
      sg_dma_address(contig_sg) =
      	| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
      	| dma_offset;
      It is possible that (startsg->length + dma_len > max_seg_size) is false
      (we are just near the 0x10000 max_seg_size boundary), so the funcion
      decides to coalesce this entry with the next entry. When the coalescing
      succeeds, the function performs
      	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
      And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
      iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
      to allocate 17 pages for a device that must not cross 16-page boundary.
      To fix the bug, we must make sure that dma_len after addition of
      dma_offset and alignment doesn't cross the segment boundary. I.e. change
      	if (startsg->length + dma_len > max_seg_size)
      	if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)
      This patch makes this change (it precalculates max_seg_boundary at the
      beginning of the function iommu_coalesce_chunks). I also added a check
      that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
      not needed for Promise TX2+ SATA, but it may be needed for other devices
      that have dma_get_seg_boundary lower than dma_get_max_seg_size).
      Signed-off-by: 's avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
  7. 10 Nov, 2015 1 commit
  8. 22 Oct, 2015 1 commit
  9. 15 Sep, 2015 1 commit
    • Bjorn Helgaas's avatar
      PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code" · 237865f1
      Bjorn Helgaas authored
      Revert dff22d20 ("PCI: Call pci_read_bridge_bases() from core instead
      of arch code").
      Reading PCI bridge windows is not arch-specific in itself, but there is PCI
      core code that doesn't work correctly if we read them too early.  For
      example, Hannes found this case on an ARM Freescale i.mx6 board:
        pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
        pci 0000:00:00.0: PCI bridge to [bus 01-ff]
        pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window)
        pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000]
        pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000]
        pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100]
      The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs
      0x204100 of space, and mem windows are megabyte-aligned.
      Bus sizing can increase a bridge window size, but never *decrease* it (see
      d65245c3 ("PCI: don't shrink bridge resources")).  Prior to
      dff22d20, ARM didn't read bridge windows at all, so the "original size"
      was zero, and we assigned a 3MB window.
      After dff22d20, we read the bridge windows before sizing the bus.  The
      firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since
      we never decrease the size, we kept 16MB even though we only needed 3MB.
      But 16MB doesn't fit in the host bridge aperture, so we failed to assign
      space for the window and the downstream devices.
      I think this is a defect in the PCI core: we shouldn't rely on the firmware
      to assign sensible windows.
      Ray reported a similar problem, also on ARM, with Broadcom iProc.
      Issues like this are too hard to fix right now, so revert dff22d20.
      Reported-by: 's avatarHannes <oe5hpm@gmail.com>
      Reported-by: 's avatarRay Jui <rjui@broadcom.com>
      Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@mail.gmail.com
      Link: http://lkml.kernel.org/r/55F75BB8.4070405@broadcom.comSigned-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: 's avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: 's avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  10. 10 Sep, 2015 1 commit
  11. 08 Sep, 2015 1 commit
    • Helge Deller's avatar
      PCI,parisc: Enable 64-bit bus addresses on PA-RISC · e02a653e
      Helge Deller authored
      Commit 3a9ad0b4 ("PCI: Add pci_bus_addr_t") unconditionally introduced usage of
      64-bit PCI bus addresses on all 64-bit platforms which broke PA-RISC.
      It turned out that due to enabling the 64-bit addresses, the PCI logic decided
      to use the GMMIO instead of the LMMIO region. This commit simply disables
      registering the GMMIO and thus we fall back to use the LMMIO region as before.
      Reverts commit 45ea2a5f
      ("PCI: Don't use 64-bit bus addresses on PA-RISC")
      To: linux-parisc@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Meelis Roos <mroos@linux.ee>
      Cc: stable@vger.kernel.org  # v3.19+
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
  12. 31 Jul, 2015 1 commit
  13. 23 Jul, 2015 1 commit
    • Lorenzo Pieralisi's avatar
      PCI: Call pci_read_bridge_bases() from core instead of arch code · dff22d20
      Lorenzo Pieralisi authored
      When we scan a PCI bus, we read PCI-PCI bridge window registers with
      pci_read_bridge_bases() so we can validate the resource hierarchy.  Most
      architectures call pci_read_bridge_bases() from pcibios_fixup_bus(), but
      PCI-PCI bridges are not arch-specific, so this doesn't need to be in
      arch-specific code.
      Call pci_read_bridge_bases() directly from the PCI core instead of from
      arch code.
      For alpha and mips, we now call pci_read_bridge_bases() always; previously
      we only called it if PCI_PROBE_ONLY was set.
      [bhelgaas: changelog]
      Signed-off-by: 's avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Ralf Baechle <ralf@linux-mips.org>
      CC: James E.J. Bottomley <jejb@parisc-linux.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Richard Henderson <rth@twiddle.net>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: David Howells <dhowells@redhat.com>
      CC: Russell King <linux@arm.linux.org.uk>
      CC: Tony Luck <tony.luck@intel.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Guenter Roeck <linux@roeck-us.net>
      CC: Michal Simek <monstr@monstr.eu>
      CC: Chris Zankel <chris@zankel.net>
  14. 24 Apr, 2015 1 commit
    • Scott Wood's avatar
      parisc: %pf is only for function pointers · a4e4f67f
      Scott Wood authored
      Use %ps for actual addresses, otherwise you'll get bad output
      on arches like parisc64 where %pf expects a function descriptor.
      This wasn't normally seen on parisc64 because the code is not built
      unless DEBUG_SUPERIO_INIT is manually defined.
      Patch modified by Helge Deller to utilize KERN_DEBUG.
      Signed-off-by: 's avatarScott Wood <scottwood@freescale.com>
      Cc: linux-parisc@vger.kernel.org
      cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
  15. 21 Apr, 2015 1 commit
  16. 15 Apr, 2015 1 commit
  17. 06 Mar, 2015 1 commit
  18. 16 Jan, 2015 1 commit
  19. 01 Oct, 2014 1 commit
  20. 21 Sep, 2014 2 commits
  21. 19 Sep, 2014 1 commit
    • Kirill Tkhai's avatar
      sched, cleanup, treewide: Remove set_current_state(TASK_RUNNING) after schedule() · f139caf2
      Kirill Tkhai authored
      schedule(), io_schedule() and schedule_timeout() always return
      with TASK_RUNNING state set, so one more setting is unnecessary.
      (All places in patch are visible good, only exception is
       kiblnd_scheduler() from:
       Its schedule() is one line above standard 3 lines of unified diff)
      No places where set_current_state() is used for mb().
      Signed-off-by: 's avatarKirill Tkhai <ktkhai@parallels.com>
      Signed-off-by: 's avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1410529254.3569.23.camel@tkhai
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Anil Belur <askb23@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Dave Kleikamp <shaggy@kernel.org>
      Cc: David Airlie <airlied@linux.ie>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dmitry Eremin <dmitry.eremin@intel.com>
      Cc: Frank Blaschka <blaschka@linux.vnet.ibm.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Isaac Huang <he.huang@intel.com>
      Cc: James E.J. Bottomley <JBottomley@parallels.com>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: J. Bruce Fields <bfields@fieldses.org>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Laura Abbott <lauraa@codeaurora.org>
      Cc: Liang Zhen <liang.zhen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Masaru Nomura <massa.nomura@gmail.com>
      Cc: Michael Opdenacker <michael.opdenacker@free-electrons.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Oleg Drokin <green@linuxhacker.ru>
      Cc: Peng Tao <bergwolf@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Robert Love <robert.w.love@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Cc: Ursula Braun <ursula.braun@de.ibm.com>
      Cc: Zi Shen Lim <zlim.lnx@gmail.com>
      Cc: devel@driverdev.osuosl.org
      Cc: dm-devel@redhat.com
      Cc: dri-devel@lists.freedesktop.org
      Cc: fcoe-devel@open-fcoe.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux390@de.ibm.com
      Cc: linux-afs@lists.infradead.org
      Cc: linux-cris-kernel@axis.com
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-parisc@vger.kernel.org
      Cc: linux-raid@vger.kernel.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-scsi@vger.kernel.org
      Cc: qla2xxx-upstream@qlogic.com
      Cc: user-mode-linux-devel@lists.sourceforge.net
      Cc: user-mode-linux-user@lists.sourceforge.net
      Signed-off-by: 's avatarIngo Molnar <mingo@kernel.org>
  22. 27 Aug, 2014 1 commit
  23. 31 Jul, 2013 1 commit
    • Thomas Bogendoerfer's avatar
      parisc: Fix interrupt routing for C8000 serial ports · dd5e6d6a
      Thomas Bogendoerfer authored
      We can't use dev->mod_index for selecting the interrupt routing entry,
      because it's not an index into interrupt routing table. It will be even
      wrong on a machine with 2 CPUs (4 cores). But all needed information is
      contained in the PAT entries for the serial ports. mod[0] contains the
      iosapic address and mod_info has some indications for the interrupt
      input (at least it looks like it). This patch implements the searching
      for the right iosapic and uses this interrupt input information.
      Signed-off-by: 's avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
  24. 25 Jul, 2013 1 commit
  25. 09 Jul, 2013 1 commit
  26. 29 Jun, 2013 1 commit
  27. 18 Jun, 2013 1 commit
  28. 01 Jun, 2013 2 commits
    • Helge Deller's avatar
      parisc/PCI: lba: fix: convert to pci_create_root_bus() for correct root bus resources (v2) · b204a4d2
      Helge Deller authored
      commit dc7dce28
      Author: Bjorn Helgaas <bhelgaas@google.com>
      Date:   Fri Oct 28 16:27:27 2011 -0600
         parisc/PCI: lba: convert to pci_create_root_bus() for correct root bus
        Supply root bus resources to pci_create_root_bus() so they're correct
        immediately.  This fixes the problem of "early" and "header" quirks seeing
        incorrect root bus resources.
      added tests for elmmio_space.start while it should use
      elmmio_space.flags.  This for example led to incorrect resource
      assignments and a non-working stifb framebuffer on most parisc machines.
      LBA 10:1: PCI host bridge to bus 0000:01
      pci_bus 0000:01: root bus resource [io  0x12000-0x13fff] (bus address [0x2000-0x3fff])
      pci_bus 0000:01: root bus resource [mem 0xfffffffffa000000-0xfffffffffbffffff] (bus address [0xfa000000-0xfbffffff])
      pci_bus 0000:01: root bus resource [mem 0xfffffffff4800000-0xfffffffff4ffffff] (bus address [0xf4800000-0xf4ffffff])
      pci_bus 0000:01: root bus resource [??? 0x00000001 flags 0x0]
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
      Acked-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
    • Bjorn Helgaas's avatar
      parisc/PCI: Set type for LBA bus_num resource · b47d4934
      Bjorn Helgaas authored
      The non-PAT resource probing code failed to set the type of the LBA bus_num
      resource (30aa80da "parisc/PCI: register busn_res for root buses" did
      the corresponding thing for the PAT case).
      This causes incorrect resource assignments and a non-working stifb
      framebuffer on most parisc machines.
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
  29. 24 May, 2013 1 commit
  30. 06 May, 2013 1 commit
    • Helge Deller's avatar
      parisc: fix partly 16/64k PAGE_SIZE boot · 6a45716a
      Helge Deller authored
      This patch fixes partly PAGE_SIZEs of 16K or 64K by adjusting the
      assembler PTE lookup code and the assembler TEMPALIAS code.  Furthermore
      some data alignments for PAGE_SIZE have been limited to 4K (or less) to
      not waste too much memory with greater page sizes. As a side note, the
      palo loader can (currently) only handle up to 10 ELF segments which is
      fixed with tighter aligning as well.
      My testings indicated that the ldci command in the sba iommu coding
      needed adjustment by the PAGE_SHIFT value and that the I/O PDIR Page
      size was only set to 4K for my machine (C3000).
      All this fixes partly the boot, but there are still quite some caching
      problems left.  Examples are e.g. the symbios logic driver which is
      sym0: <896> rev 0x7 at pci 0000:00:0f.0 irq 69
      sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
      and the tulip network driver which doesn't seem to work correctly
      Sending BOOTP requests .net eth0: Setting full-duplex based on MII#1
      link partner capability of 05e1
      ..... timed out!
      Beside those kernel fixes glibc will need fixes too to be able to handle
      >4K page sizes.
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
  31. 09 Apr, 2013 1 commit
    • Al Viro's avatar
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro authored
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
  32. 22 Feb, 2013 1 commit
  33. 20 Feb, 2013 4 commits
  34. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      Drivers: misc: remove __dev* attributes. · 0fe763c5
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  35. 22 Aug, 2012 1 commit