1. 27 Jun, 2011 6 commits
    • matt mooney's avatar
      857aab34
    • Yoshihiro Shimoda's avatar
      usb: r8a66597-hcd: fix cannot detect low/full speed device · 87abd0a9
      Yoshihiro Shimoda authored
      This controller can control "Transaction Translators", but
      the hcd->has_tt is not set.
      Since the commit d199c96d
      ("USB: prevent buggy from crashing the USB stack") has checked it,
      the driver could not work the low/full speed device.
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      87abd0a9
    • Gabor Juhos's avatar
      USB: ehci-ath79: fix a NULL pointer dereference · c27d5368
      Gabor Juhos authored
      Loading the ehci-hcd module on the ath79 platform causes
      a NULL pointer dereference:
      
      CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == c0252928, ra == c00de968
      Oops[#1]:
      Cpu 0
      $ 0   : 00000000 00000070 00000001 00000000
      $ 4   : 802cf870 0000117e ffffffff 8019c7bc
      $ 8   : 0000000a 00000002 00000001 fffffffb
      $12   : 8026ef20 0000000f ffffff80 802dad3c
      $16   : 8077a2d4 8077a200 c00f3484 8019ed84
      $20   : c00f0000 00000003 000000a0 80262c2c
      $24   : 00000002 80079da0
      $28   : 80788000 80789c80 80262b14 c00de968
      Hi    : 00000000
      Lo    : b61f0000
      epc   : c0252928 __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd]
          Not tainted
      ra    : c00de968 usb_add_hcd+0x2a4/0x858 [usbcore]
      Status: 1000c003    KERNEL EXL IE
      Cause : 00800008
      BadVA : 00000000
      PrId  : 00019374 (MIPS 24Kc)
      Modules linked in: ehci_hcd(+) pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG
      xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filte
      r ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc ath mac80211
      usbcore nls_base input_polldev crc_ccitt cfg80211 compat input_core a
      rc4 aes_generic crypto_algapi
      Process insmod (pid: 379, threadinfo=80788000, task=80ca2180,
      tls=77fe52d0)
      Stack : c0253184 80c57d80 80789cac 8077a200 00000001 8019edc0 807fa800 8077a200
              8077a290 c00f3484 8019ed84 c00f0000 00000003 000000a0 80262c2c c00de968
              802d0000 800878cc c0253228 c02528e4 c0253184 80c57d80 80bf6800 80ca2180
              8007b75c 00000000 8077a200 802cf830 802d0000 00000003 fffffff4 00000015
              00000348 00000124 800b189c c024bb4c c0255000 801a27e8 c0253228 c02528e4
              ...
      Call Trace:
      [<c0252928>] __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd]
      
      It is caused by:
      
        commit c430131a
        Author: Jan Andersson <jan@gaisler.com>
        Date:   Tue May 3 20:11:57 2011 +0200
      
            USB: EHCI: Support controllers with big endian capability regs
      
            The two first HC capability registers (CAPLENGTH and HCIVERSION)
            are defined as one 8-bit and one 16-bit register. Most HC
            implementations have selected to treat these registers as part
            of a 32-bit register, giving the same layout for both big and
            small endian systems.
      
            This patch adds a new quirk, big_endian_capbase, to support
            controllers with big endian register interfaces that treat
            HCIVERSION and CAPLENGTH as individual registers.
      Signed-off-by: default avatarJan Andersson <jan@gaisler.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      The reading of the HC capability register has been moved by that
      commit to a place where the ehci->caps field is not initialized
      yet. This patch moves the reading of the register back to the
      original place.
      Acked-by: default avatarJan Andersson <jan@gaisler.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c27d5368
    • Uwe Bonnes's avatar
      USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c · 309427b6
      Uwe Bonnes authored
      appended patch adds support for the new FTDI FT232H chip. This chip is a
      single channel version of the dual FT2232H/quad FT4232H, coming with it's
      own default PID 0x6014 (FT2232H uses the same PID 0x6010 like FT2232C,
      FT4232H has also it's own PID).
      
      The patch was checked on an UM232H module and a terminal program with TX/RX
      shorted to that typing in the terminal reproduced the characters.
      Signed-off-by: default avatarUwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      309427b6
    • Arvid Brodin's avatar
      usb/isp1760: Fix bug preventing the unlinking of control urbs · 8b1ab60c
      Arvid Brodin authored
      Both control and bulk transfers use isp1760 slots of type ATL, but the
      driver unlink code for ATL slots only acts on urbs describing a bulk
      transfer, letting the code for INT slots take care of the unlink instead,
      which often ended up removing the interrupt transfer for root hub events
      instead. That's not good, and gets fixed by this patch.
      Signed-off-by: default avatarArvid Brodin <arvid.brodin@enea.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8b1ab60c
    • Greg Kroah-Hartman's avatar
      Merge branch 'for-usb-linus' of... · 95a2424f
      Greg Kroah-Hartman authored
      Merge branch 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
      
      * 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
        USB: Fix up URB error codes to reflect implementation.
        xhci: Always set urb->status to zero for isoc endpoints.
        xhci: Add reset on resume quirk for asrock p67 host
        xHCI 1.0: Incompatible Device Error
        xHCI 1.0: Force Stopped Event(FSE)
        xhci: Don't warn about zeroed bMaxBurst descriptor field.
        USB: Free bandwidth when usb_disable_device is called.
        xhci: Reject double add of active endpoints.
      95a2424f
  2. 17 Jun, 2011 4 commits
    • Sarah Sharp's avatar
      USB: Fix up URB error codes to reflect implementation. · a9e75863
      Sarah Sharp authored
      Documentation/usb/error-codes.txt mentions that urb->status can be set to
      -EXDEV, if the isochronous transfer was not fully completed.  However, in
      practice, EHCI, UHCI, and OHCI all only set -EXDEV in the individual frame
      status, never in the URB status.  Those host controller actually always
      pass in a zero status to usb_hcd_giveback_urb, and rely on the core to set
      the appropriate status value.
      
      The xHCI driver ran into issues with the uvcvideo driver when it tried to
      set -EXDEV in urb->status, because the driver refused to submit URBs, and
      the userspace camera application's video froze.
      
      Clean up the documentation to reflect the actual implementation.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      a9e75863
    • Sarah Sharp's avatar
      xhci: Always set urb->status to zero for isoc endpoints. · b3df3f9c
      Sarah Sharp authored
      When the xHCI driver encounters a Missed Service Interval event for an
      isochronous endpoint ring, it means the host controller skipped over
      one or more isochronous TDs.  For TD that is skipped, skip_isoc_td() is
      called.  This sets the frame descriptor status to -EXDEV, and also sets
      the value stored in the int pointed to by status to -EXDEV.
      
      If the isochronous TD happens to be the last TD in an URB,
      handle_tx_event() will use the status variable to give back the URB to
      the USB core.  That means drivers will see urb->status as -EXDEV.
      
      It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
      an isochronous urb, regardless of what the frame status is.  See
      itd_complete() in ehci-sched.c:
      
                      } else {
                              /* URB was too late */
                              desc->status = -EXDEV;
                      }
              }
      
              /* handle completion now? */
              if (likely ((urb_index + 1) != urb->number_of_packets))
                      goto done;
      
              /* ASSERT: it's really the last itd for this urb
              list_for_each_entry (itd, &stream->td_list, itd_list)
                      BUG_ON (itd->urb == urb);
               */
      
              /* give urb back to the driver; completion often (re)submits */
              dev = urb->dev;
              ehci_urb_done(ehci, urb, 0);
      
      ehci_urb_done() completes the URB with the status of the third argument, which
      is always zero in this case.
      
      It turns out that many USB webcam drivers, such as uvcvideo, cannot
      handle urb->status set to a non-zero value.  They will not resubmit
      their isochronous URBs in that case, and userspace will see a frozen
      video.
      
      Change the xHCI driver to be consistent with the EHCI and UHCI driver,
      and always set urb->status to 0 for isochronous URBs.
      
      This patch should be backported to kernels as old as 2.6.36
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
      Cc: stable@kernel.org
      b3df3f9c
    • Maarten Lankhorst's avatar
      xhci: Add reset on resume quirk for asrock p67 host · c877b3b2
      Maarten Lankhorst authored
      The asrock p67 xhci controller completely dies on resume, add a
      quirk for this, to bring the host back online after a suspend.
      
      This should be backported to stable kernels as old as 2.6.37.
      Signed-off-by: default avatarMaarten Lankhorst <m.b.lankhorst@gmail.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      c877b3b2
    • Alex He's avatar
      xHCI 1.0: Incompatible Device Error · f6ba6fe2
      Alex He authored
      It is one new TRB Completion Code for the xHCI spec v1.0.
      Asserted if the xHC detects a problem with a device that does not allow it to
      be successfully accessed, e.g. due to a device compliance or compatibility
      problem. This error may be returned by any command or transfer, and is fatal
      as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
      of ISOC for transfer case. And return -ENODEV for configure endpoint command,
      evaluate context command and address device command if there is an incompatible
      Device Error. The error codes will be sent back to the USB core to decide how
      to do. It's unnecessary for other commands because after the three commands run
      successfully means that the device has been accepted.
      Signed-off-by: default avatarAlex He <alex.he@amd.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      f6ba6fe2
  3. 16 Jun, 2011 3 commits
    • Alan Stern's avatar
      USB: don't let errors prevent system sleep · 0af212ba
      Alan Stern authored
      This patch (as1464) implements the recommended policy that most errors
      during suspend or hibernation should not prevent the system from going
      to sleep.  In particular, failure to suspend a USB driver or a USB
      device should not prevent the sleep from succeeding:
      
      Failure to suspend a device won't matter, because the device will
      automatically go into suspend mode when the USB bus stops carrying
      packets.  (This might be less true for USB-3.0 devices, but let's not
      worry about them now.)
      
      Failure of a driver to suspend might lead to trouble later on when the
      system wakes up, but it isn't sufficient reason to prevent the system
      from going to sleep.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0af212ba
    • Alan Stern's avatar
      USB: don't let the hub driver prevent system sleep · cbb33004
      Alan Stern authored
      This patch (as1465) continues implementation of the policy that errors
      during suspend or hibernation should not prevent the system from going
      to sleep.
      
      In this case, failure to turn on the Suspend feature for a hub port
      shouldn't be reported as an error.  There are situations where this
      does actually occur (such as when the device plugged into that port
      was disconnected in the recent past), and it turns out to be harmless.
      There's no reason for it to prevent a system sleep.
      
      Also, don't allow the hub driver to fail a system suspend if the
      downstream ports aren't all suspended.  This is also harmless (and
      should never happen, given the change mentioned above); printing a
      warning message in the kernel log is all we really need to do.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      cbb33004
    • Alan Stern's avatar
      USB: change maintainership of ohci-hcd and ehci-hcd · 578333ab
      Alan Stern authored
      Following the loss of David Brownell, I volunteer to maintain the
      ohci-hcd and ehci-hcd drivers.  This patch (as1472) makes it official.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      578333ab
  4. 15 Jun, 2011 4 commits
    • Alex He's avatar
      xHCI 1.0: Force Stopped Event(FSE) · e1cf486d
      Alex He authored
      FSE shall occur on the TD natural boundary. The software ep_ring dequeue pointer
      exceed the hardware ep_ring dequeue pointer in these cases of Table-3. As a
      result, the event_trb(pointed by hardware dequeue pointer) of the FSE can't be
      found in the current TD(pointed by software dequeue pointer). What should we do
      is to figured out the FSE case and skip over it.
      Signed-off-by: default avatarAlex He <alex.he@amd.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      e1cf486d
    • Sarah Sharp's avatar
      xhci: Don't warn about zeroed bMaxBurst descriptor field. · d2333632
      Sarah Sharp authored
      The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed
      Endpoint Companion descriptor is supposed to indicate how many packets a
      SS device can handle before it needs to wait for an explicit handshake
      from the host controller.  A zero value means the device can only handle
      one packet before it needs a handshake.  Remove a warning in the xHCI
      driver that implies this is an invalid value.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      d2333632
    • Sarah Sharp's avatar
      USB: Free bandwidth when usb_disable_device is called. · fccf4e86
      Sarah Sharp authored
      Tanya ran into an issue when trying to switch a UAS device from the BOT
      configuration to the UAS configuration via the bConfigurationValue sysfs
      file.  Before installing the UAS configuration, set_bConfigurationValue()
      calls usb_disable_device().  That function is supposed to remove all host
      controller resources associated with that device, but it leaves some state
      in the xHCI host controller.
      
      Commit 0791971b
      	usb: allow drivers to use allocated bandwidth until unbound
      added a call to usb_disable_device() in usb_set_configuration(), before
      the xHCI bandwidth functions were invoked.  That commit fixed a bug, but
      also introduced a bug that is triggered when a configured device is
      switched to a new configuration.
      
      usb_disable_device() goes through all the motions of unbinding the drivers
      attached to active interfaces and removing the USB core structures
      associated with those interfaces, but it doesn't actually remove the
      endpoints from the internal xHCI host controller bandwidth structures.
      
      When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
      set to true, the entries in udev->ep_out and udev->ep_in will be set to
      NULL.  Usually, when the USB core installs a new configuration,
      usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
      and udev->ep_in before adding any new endpoints.  However, when the new
      UAS configuration was added, all those entries were null, so none of the
      old endpoints in the BOT configuration were dropped.
      
      The xHCI driver blindly added the UAS configuration endpoints, and some of
      the endpoint addresses overlapped with the old BOT configuration
      endpoints.  This caused the xHCI host to reject the Configure Endpoint
      command.  Now that the xHCI driver code is cleaned up to reject a
      double-add of active endpoints, we need to fix the USB core to properly
      drop old endpoints in usb_disable_device().
      
      If the host controller driver needs bandwidth checking support, make
      usb_disable_device() call usb_disable_endpoint() with
      reset_hardware set to false, drop the endpoints from the xHCI host
      controller, and then call usb_disable_endpoint() again with
      reset_hardware set to true.
      
      The first call to usb_disable_endpoint() will cancel any pending URBs and
      wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
      pointers in udev->ep_out and udev->ep in intact.  Then
      usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
      to drop.
      
      The final call to usb_disable_endpoint() will do two things:
      
      1. It will call usb_hcd_disable_endpoint() again, which should be harmless
      since the ep->urb_list should be empty after the first call to
      usb_disable_endpoint() returns.
      
      2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
      usb_hcd_disable_endpoint().  That call will have no effect, since the xHCI
      driver doesn't set the endpoint_disable function pointer.
      
      Note that usb_disable_device() will now need to be called with
      hcd->bandwidth_mutex held.
      
      This should be backported to kernels as old as 2.6.32.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: default avatarTanya Brokhman <tlinder@codeaurora.org>
      Cc: ablay@codeaurora.org
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: stable@kernel.org
      fccf4e86
    • Sarah Sharp's avatar
      xhci: Reject double add of active endpoints. · fa75ac37
      Sarah Sharp authored
      While trying to switch a UAS device from the BOT configuration to the UAS
      configuration via the bConfigurationValue file, Tanya ran into an issue in
      the USB core.  usb_disable_device() sets entries in udev->ep_out and
      udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
      functions to remove the BOT configuration endpoints from the xHCI host's
      internal structures.
      
      The USB core would then attempt to add endpoints for the UAS
      configuration, and some of the endpoints had the same address as endpoints
      in the BOT configuration.  The xHCI driver blindly added the endpoints
      again, but the xHCI host controller rejected the Configure Endpoint
      command because active endpoints were added without being dropped.
      
      Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
      add active endpoints without first calling xhci_drop_endpoint().
      
      This should be backported to kernels as old as 2.6.31.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: default avatarTanya Brokhman <tlinder@codeaurora.org>
      Cc: stable@kernel.org
      fa75ac37
  5. 14 Jun, 2011 2 commits
  6. 13 Jun, 2011 10 commits
  7. 12 Jun, 2011 8 commits
  8. 11 Jun, 2011 3 commits
    • Mika Westerberg's avatar
      net: ep93xx_eth: fix DMA API violations · f1c089e3
      Mika Westerberg authored
      Russell King said:
      >
      > So, to summarize what its doing:
      >
      > 1. It allocates buffers for rx and tx.
      > 2. It maps them with dma_map_single().
      >       This transfers ownership of the buffer to the DMA device.
      > 3. In ep93xx_xmit,
      > 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
      >       This violates the DMA buffer ownership rules - the CPU should
      >       not be writing to this buffer while it is (in principle) owned
      >       by the DMA device.
      > 3b. It then calls dma_sync_single_for_cpu() for the buffer.
      >       This transfers ownership of the buffer to the CPU, which surely
      >       is the wrong direction.
      > 4. In ep93xx_rx,
      > 4a. It calls dma_sync_single_for_cpu() for the buffer.
      >       This at least transfers the DMA buffer ownership to the CPU
      >       before the CPU reads the buffer
      > 4b. It then uses skb_copy_to_linear_data() to copy the data out.
      >       At no point does it transfer ownership back to the DMA device.
      > 5. When the driver is removed, it dma_unmap_single()'s the buffer.
      >       This transfers ownership of the buffer to the CPU.
      > 6. It frees the buffer.
      >
      > While it may work on ep93xx, it's not respecting the DMA API rules,
      > and with DMA debugging enabled it will probably encounter quite a few
      > warnings.
      
      This patch fixes these violations.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@iki.fi>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Tested-by: default avatarPetr Stetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1c089e3
    • Mika Westerberg's avatar
      net: ep93xx_eth: drop GFP_DMA from call to dma_alloc_coherent() · 1f758a43
      Mika Westerberg authored
      Commit a197b59a (mm: fail GFP_DMA allocations when ZONE_DMA is not
      configured) made page allocator to return NULL if GFP_DMA is set but
      CONFIG_ZONE_DMA is disabled.
      
      This causes ep93xx_eth to fail:
      
       WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
       Modules linked in:
       [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
       [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
       [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
       [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
       [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
       [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
       [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
       [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
       [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
       [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
       [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
       [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
       [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)
      
      Since there is no restrictions for DMA on ep93xx, we can fix this by just
      removing the GFP_DMA flag from the call.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@iki.fi>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Tested-by: default avatarPetr Stetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f758a43
    • Mika Westerberg's avatar
      net: ep93xx_eth: allocate buffers using kmalloc() · 3247a1fc
      Mika Westerberg authored
      We can use simply kmalloc() to allocate the buffers. This also simplifies the
      code and allows us to perform DMA sync operations more easily.
      
      Memory is allocated with only GFP_KERNEL since there are no DMA allocation
      restrictions on this platform.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@iki.fi>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Tested-by: default avatarPetr Stetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3247a1fc