1. 20 Feb, 2014 3 commits
    • Josh Cartwright's avatar
      usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP · e7d613d1
      Josh Cartwright authored
      Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
      msm_otg_{suspend,resume} routines, however these routines are only being
      built when CONFIG_PM_SLEEP.  In addition, msm_otg_{suspend,resume} also
      depends on msm_hsusb_config_vddcx(), which is only built when
      CONFIG_PM_SLEEP.
      
      Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
      preprocessor conditional, and moving msm_hsusb_config_vddcx().
      
      While we're here, eliminate the CONFIG_PM conditional for setting
      up the dev_pm_ops.
      
      This address the following errors Russell King has hit doing randconfig
      builds:
      
      drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
      drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
      drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
      drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'
      
      Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
      Reported-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJosh Cartwright <joshc@codeaurora.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      e7d613d1
    • Andrzej Pietrasiewicz's avatar
      usb: gadget: fix NULL pointer dereference · f0f42204
      Andrzej Pietrasiewicz authored
      Fix possible NULL pointer dereference introduced in
      commit 219580e6 (usb: f_fs: check quirk to pad epout
      buf size when not aligned to maxpacketsize)
      
      In cases we do wait with:
      
      wait_event_interruptible(epfile->wait, (ep = epfile->ep));
      
      for endpoint to be enabled, functionfs_bind() has not been called yet
      and epfile->ffs->gadget is still NULL and the automatic variable 'gadget'
      has been initialized with NULL at the point of its definition.
      Later on it is used as a parameter to:
      
      usb_ep_align_maybe(gadget, ep->ep, len)
      
      which in turn dereferences it.
      
      This patch fixes it by moving the actual assignment to the local 'gadget'
      variable after the potential waiting has completed.
      Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      f0f42204
    • Peter Chen's avatar
      usb: gadget: printer: using gadget_is_otg to check otg support at runtime · 8679059e
      Peter Chen authored
      We need to use gadget_is_otg to check if the gadget is really
      otg support at runtime, other composite gadget drivers have already
      followed this method.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      8679059e
  2. 18 Feb, 2014 6 commits
    • Florian Fainelli's avatar
      usb: gadget: bcm63xx_udc: fix build failure on DMA channel code · 2d1f7af3
      Florian Fainelli authored
      Commit 3dc6475c ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
      changed the ENETDMA[CS] macros such that they are no longer macros, but
      actual register offset definitions. The bcm63xx_udc driver was not
      updated, and as a result, causes the following build error to pop up:
      
       CC      drivers/usb/gadget/u_ether.o
      drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write':
      drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not
      a function
      drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel':
      drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not
      a function
      drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not
      a function
      
      Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to
      take an extra channel argument, and use the channel width
      (ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence
      doing again what the macro implicitely did for us.
      
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Jonas Gorski <jogo@openwrt.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      2d1f7af3
    • Daniel Mack's avatar
      usb: musb: do not sleep in atomic context · 30d361bf
      Daniel Mack authored
      musb_port_reset() is called from musb_hub_control() which in turn holds
      a spinlock, so musb_port_reset() is not allowed to call msleep().
      
      With the asynchronous work helpers in place, this is fortunately easy to
      fix by rescheduling the reset deassertion function to after the time
      when the wait period is finished.
      
      Note, however, that the MUSB_POWER_RESUME bit is only set on AM33xx
      processors under rare conditions such as when to another driver
      reporting an error during suspend. Hence, this didn't hit me yet in
      normal operation.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      30d361bf
    • Sachin Kamat's avatar
      usb: gadget: s3c2410_udc: Fix build error · d246c9d5
      Sachin Kamat authored
      Pass value instead of address as expected by 'usb_ep_set_maxpacket_limit'.
      Fixes the following compilation error introduced by commit e117e742
      ("usb: gadget: add "maxpacket_limit" field to struct usb_ep"):
      
      drivers/usb/gadget/s3c2410_udc.c: In function ‘s3c2410_udc_reinit’:
      drivers/usb/gadget/s3c2410_udc.c:1632:3: error:
      cannot take address of bit-field ‘maxpacket’
         usb_ep_set_maxpacket_limit(&ep->ep, &ep->ep.maxpacket);
      Signed-off-by: default avatarSachin Kamat <sachin.kamat@linaro.org>
      Reviewed-by: default avatarRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      d246c9d5
    • Roger Quadros's avatar
      usb: musb: core: Fix remote-wakeup resume · 33f8d75f
      Roger Quadros authored
      During resume don't touch SUSPENDM/RESUME bits of POWER register
      while restoring controller context. These bits might be changed
      by the controller during resume operation and so will be different
      than what they were during suspend.
      
      e.g. SUSPENDM bit is set by software during USB global suspend but
      automatically cleared by the controller during remote wakeup or
      during resume. Setting this bit back while restoring context
      causes undesired behaviour. i.e. Babble interrupt is generated
      and USB is broken.
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      33f8d75f
    • Ajay Kumar Gupta's avatar
      usb: musb: host: Fix SuperSpeed hub enumeration · 3c4653c1
      Ajay Kumar Gupta authored
      Disables PING on status phase of control transfer.
      PING token is not mandatory in status phase of control transfer
      and so some high speed USB devices don't support it. If such devices
      are connected to MUSB then they would not respond to PING token
      causing delayed or failed enumeration.
      
      [Roger Q] Fixes enumeration issues with some Super-Speed USB hubs
      e.g. Dlink DUB-1340
      Signed-off-by: default avatarAjay Kumar Gupta <ajay.gupta@ti.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      3c4653c1
    • Felipe Balbi's avatar
      usb: musb: fix obex in g_nokia.ko causing kernel panic · 30a70b02
      Felipe Balbi authored
      phy_power_off() can, depending on the PHY being used,
      start I2C transactions which shouldn't happen in
      atomic context.
      
      Current call to phy_power_off() inside omap2430_runtime
      callbacks causes the following dump, as a fix, just don't
      power off the PHY in runtime.
      
      [   18.606414] [<c037eac0>] (__schedule+0x5c/0x50c) from [<c037d3bc>] (schedule_timeout+0x1f4/0x25c)
      [   18.623809] [<c037d3bc>] (schedule_timeout+0x1f4/0x25c) from [<c037f12c>] (wait_for_common+0xc8/0x1ac)
      [   18.649291] [<c037f12c>] (wait_for_common+0xc8/0x1ac) from [<c028c1c0>] (omap_i2c_xfer+0x338/0x488)
      [   18.674499] [<c028c1c0>] (omap_i2c_xfer+0x338/0x488) from [<c0288144>] (__i2c_transfer+0x40/0x74)
      [   18.692047] [<c0288144>] (__i2c_transfer+0x40/0x74) from [<c0288a2c>] (i2c_transfer+0x6c/0x90)
      [   18.709320] [<c0288a2c>] (i2c_transfer+0x6c/0x90) from [<c02351c8>] (regmap_i2c_read+0x48/0x68)
      [   18.726715] [<c02351c8>] (regmap_i2c_read+0x48/0x68) from [<c023161c>] (_regmap_raw_read+0x128/0x220)
      [   18.752685] [<c023161c>] (_regmap_raw_read+0x128/0x220) from [<c02317b4>] (regmap_raw_read+0xa0/0x130)
      [   18.779052] [<c02317b4>] (regmap_raw_read+0xa0/0x130) from [<c023193c>] (regmap_bulk_read+0xf8/0x16c)
      [   18.805694] [<c023193c>] (regmap_bulk_read+0xf8/0x16c) from [<c0238ea8>] (twl_i2c_read+0xa4/0xe0)
      [   18.823730] [<c0238ea8>] (twl_i2c_read+0xa4/0xe0) from [<c0274d34>] (__twl4030_phy_power.isra.12+0x1c/0x58)
      [   18.850921] [<c0274d34>] (__twl4030_phy_power.isra.12+0x1c/0x58) from [<c0274df0>]
      (twl4030_phy_power.part.14+0x80/0xc8)
      [   18.879699] [<c0274df0>] (twl4030_phy_power.part.14+0x80/0xc8) from [<c0274f9c>]
      (twl4030_set_suspend+0x54/0x1e8)
      [   18.908325] [<c0274f9c>] (twl4030_set_suspend+0x54/0x1e8) from [<c027c8c4>]
      (omap2430_runtime_resume+0x5c/0x64)
      [   18.937042] [<c027c8c4>] (omap2430_runtime_resume+0x5c/0x64) from [<c0225dd0>]
      (pm_generic_runtime_resume+0x2c/0x38)
      [   18.966461] [<c0225dd0>] (pm_generic_runtime_resume+0x2c/0x38) from [<c0229fe0>] (__rpm_callback+0x54/0x80)
      [   18.995117] [<c0229fe0>] (__rpm_callback+0x54/0x80) from [<c022a04c>] (rpm_callback+0x40/0x74)
      [   19.013610] [<c022a04c>] (rpm_callback+0x40/0x74) from [<c022b3c8>] (rpm_resume+0x448/0x63c)
      [   19.031921] [<c022b3c8>] (rpm_resume+0x448/0x63c) from [<c022b2e4>] (rpm_resume+0x364/0x63c)
      [   19.050140] [<c022b2e4>] (rpm_resume+0x364/0x63c) from [<c022b874>] (__pm_runtime_resume+0x48/0x74)
      [   19.077728] [<c022b874>] (__pm_runtime_resume+0x48/0x74) from [<c027b4fc>] (musb_gadget_pullup+0x1c/0xb4)
      [   19.105895] [<c027b4fc>] (musb_gadget_pullup+0x1c/0xb4) from [<bf025c14>] (usb_function_deactivate+0x54/0xa4
      [libcomposite])
      [   19.135955] [<bf025c14>] (usb_function_deactivate+0x54/0xa4 [libcomposite]) from [<bf05b3b8>]
      (obex_bind+0x124/0x1d8 [usb_f_obex])
      [   19.166870] [<bf05b3b8>] (obex_bind+0x124/0x1d8 [usb_f_obex]) from [<bf025794>] (usb_add_function+0x58/0xf4
      [libcomposite])
      [   19.197143] [<bf025794>] (usb_add_function+0x58/0xf4 [libcomposite]) from [<bf037420>]
      (nokia_bind_config+0x204/0x250 [g_nokia])
      [   19.227905] [<bf037420>] (nokia_bind_config+0x204/0x250 [g_nokia]) from [<bf0263fc>] (usb_add_config+0x28/0xc0
      [libcomposite])
      [   19.258483] [<bf0263fc>] (usb_add_config+0x28/0xc0 [libcomposite]) from [<bf03709c>] (nokia_bind+0x9c/0x21c
      [g_nokia])
      [   19.288421] [<bf03709c>] (nokia_bind+0x9c/0x21c [g_nokia]) from [<bf0275bc>] (composite_bind+0x74/0x180
      [libcomposite])
      [   19.318420] [<bf0275bc>] (composite_bind+0x74/0x180 [libcomposite]) from [<c027d658>]
      (udc_bind_to_driver+0x2c/0xc4)
      [   19.348114] [<c027d658>] (udc_bind_to_driver+0x2c/0xc4) from [<c027d764>] (usb_gadget_probe_driver+0x74/0x94)
      [   19.377166] [<c027d764>] (usb_gadget_probe_driver+0x74/0x94) from [<c00086f8>] (do_one_initcall+0x94/0x138)
      [   19.406005] [<c00086f8>] (do_one_initcall+0x94/0x138) from [<c007a460>] (load_module+0x113c/0x13c4)
      [   19.434051] [<c007a460>] (load_module+0x113c/0x13c4) from [<c007a7b4>] (SyS_init_module+0xcc/0xec)
      [   19.462127] [<c007a7b4>] (SyS_init_module+0xcc/0xec) from [<c000dd40>] (ret_fast_syscall+0x0/0x30)
      [   19.490753] Code: 0a00002e e1a00004 eb001438 e598300c (e5d3202c)
      [   19.506805] ---[ end trace 060b62ec0d68a78b ]---
      [   19.523132] Kernel panic - not syncing: Fatal exception in interrupt
      
      dump is from 3.12-rc5 kernel
      Reported-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      30a70b02
  3. 11 Feb, 2014 2 commits
    • Raymond Wanyoike's avatar
      usb: option: blacklist ZTE MF667 net interface · 3635c7e2
      Raymond Wanyoike authored
      Interface #5 of 19d2:1270 is a net interface which has been submitted to the
      qmi_wwan driver so consequently remove it from the option driver.
      Signed-off-by: default avatarRaymond Wanyoike <raymond.wanyoike@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3635c7e2
    • Greg Kroah-Hartman's avatar
      Merge tag 'for-usb-linus-2014-02-11' of... · 2991942f
      Greg Kroah-Hartman authored
      Merge tag 'for-usb-linus-2014-02-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
      
      Sarah writes:
      
      xhci: Revert TD fragment hacks.
      
      Hi Greg,
      
      Recently, we found that commit "35773dac "usb: xhci: Link TRB must not
      occur within a USB payload burst" causes a userspace regression.  It will
      cause larger transfers submitted through usbfs that would have succeeded
      on older kernels to be rejected.
      
      Commit 35773dac was designed to address an issue where an ASIX USB
      ethernet device would get wedged when it was connected to a 1.0 xHCI
      host.  Only this particular ethernet device was impacted, because only the
      ax88179_178a driver implemented scatter-gather in 3.12.  The xHCI driver
      doesn't currently support TD fragment rules, and commit 35773dac was a
      quick hack that partially implemented one of the rules.
      
      This is the third regression this patch has caused.  There's yet another
      quick hack to work around the issue, but I really want to support TD
      fragments properly, rather than hacking around it.  It will take us a
      kernel release or two to get it implemented, since it is a big
      architectural change.
      
      This patchset backs out commit 35773dac, and the two bug fix patches
      for it.  The first patch limits arbitrarily aligned scatter-gather under
      xHCI 1.0 hosts.
      
      As a result of this patchset:
      
      1. usb-storage and uas will still be able to use scatter-gather, since
         they submit max packet sized aligned transfers.
      2. usbfs will behave exactly as before, no more userspace regressions.
      3. The ax88179_178a driver works fine without scatter-gather (Mark Lord
         confirms this).
      
      Users of the ASIX chipset may still see occasional packet loss on 1.0 xHCI
      hosts, if the xHCI driver needs to split a TRB across 64-KB boundaries,
      and a link TRB happens to fall between those two TRBs.  I expect this
      corner case to be infrequent.
      
      Sarah Sharp
      2991942f
  4. 07 Feb, 2014 5 commits
    • Sarah Sharp's avatar
      Revert "usb: xhci: Link TRB must not occur within a USB payload burst" · 3d4b81ed
      Sarah Sharp authored
      This reverts commit 35773dac.  It's a
      hack that caused regressions in the usb-storage and userspace USB
      drivers that use usbfs and libusb.  Commit 70cabb7d992f "xhci 1.0: Limit
      arbitrarily-aligned scatter gather." should fix the issues seen with the
      ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org # 3.12
      3d4b81ed
    • Sarah Sharp's avatar
      Revert "xhci: Avoid infinite loop when sg urb requires too many trbs" · 9cf00d91
      Sarah Sharp authored
      This reverts commit d6c9ea90.
      
      We are ripping out commit 35773dac "usb:
      xhci: Link TRB must not occur within a USB payload burst" because it's a
      hack that caused regressions in the usb-storage and userspace USB
      drivers that use usbfs and libusb.  This commit attempted to fix the
      issues with that patch.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org # 3.12
      9cf00d91
    • Sarah Sharp's avatar
      Revert "xhci: Set scatter-gather limit to avoid failed block writes." · 1386ff75
      Sarah Sharp authored
      This reverts commit f2d9b991.
      
      We are ripping out commit 35773dac "usb:
      xhci: Link TRB must not occur within a USB payload burst" because it's a
      hack that caused regressions in the usb-storage and userspace USB
      drivers that use usbfs and libusb.  This commit attempted to fix the
      issues with that patch.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org #3.12
      1386ff75
    • Sarah Sharp's avatar
      xhci 1.0: Limit arbitrarily-aligned scatter gather. · 247bf557
      Sarah Sharp authored
      xHCI 1.0 hosts have a set of requirements on how to align transfer
      buffers on the endpoint rings called "TD fragment" rules.  When the
      ax88179_178a driver added support for scatter gather in 3.12, with
      commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a:
      enable tso if usb host supports sg dma", it broke the device under xHCI
      1.0 hosts.  Under certain network loads, the device would see an
      unexpected short packet from the host, which would cause the device to
      stop sending ethernet packets, even through USB packets would still be
      sent.
      
      Commit 35773dac "usb: xhci: Link TRB must not occur within a USB
      payload burst" attempted to fix this.  It was a quick hack to partially
      implement the TD fragment rules.  However, it caused regressions in the
      usb-storage layer and userspace USB drivers using libusb.  The patches
      to attempt to fix this are too far reaching into the USB core, and we
      really need to implement the TD fragment rules correctly in the xHCI
      driver, instead of continuing to wallpaper over the issues.
      
      Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0
      hosts.  Only the ax88179_178a driver checks the no_sg_constraint flag,
      so don't set it for 1.0 hosts.  This should not impact usb-storage or
      usbfs behavior, since they pass down max packet sized aligned sg-list
      entries (512 for USB 2.0 and 1024 for USB 3.0).
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: default avatarMark Lord <mlord@pobox.com>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Bjørn Mork <bjorn@mork.no>
      Cc: Freddy Xin <freddy@asix.com.tw>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: stable@vger.kernel.org # 3.12
      247bf557
    • Jan Moskyto Matejka's avatar
      Modpost: fixed USB alias generation for ranges including 0x9 and 0xA · 03b56329
      Jan Moskyto Matejka authored
      Commit afe2dab4 ("USB: add hex/bcd detection to usb modalias generation")
      changed the routine that generates alias ranges. Before that change, only
      digits 0-9 were supported; the commit tried to fix the case when the range
      includes higher values than 0x9.
      
      Unfortunately, the commit didn't fix the case when the range includes both
      0x9 and 0xA, meaning that the final range must look like [x-9A-y] where
      x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced.
      
      Modprobe doesn't complain as it sees no difference between no-match and
      bad-pattern results of fnmatch().
      
      Fixing this simple bug to fix the aliases.
      Also changing the hardcoded beginning of the range to uppercase as all the
      other letters are also uppercase in the device version numbers.
      
      Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK.
      Signed-off-by: default avatarJan Moskyto Matejka <mq@suse.cz>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03b56329
  5. 05 Feb, 2014 3 commits
  6. 04 Feb, 2014 10 commits
  7. 03 Feb, 2014 4 commits
    • Linus Torvalds's avatar
      Linus 3.14-rc1 · 38dbfb59
      Linus Torvalds authored
      38dbfb59
    • Linus Torvalds's avatar
      Merge branch 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 69048e01
      Linus Torvalds authored
      Pull parisc updates from Helge Deller:
       "The three major changes in this patchset is a implementation for
        flexible userspace memory maps, cache-flushing fixes (again), and a
        long-discussed ABI change to make EWOULDBLOCK the same value as
        EAGAIN.
      
        parisc has been the only platform where we had EWOULDBLOCK != EAGAIN
        to keep HP-UX compatibility.  Since we will probably never implement
        full HP-UX support, we prefer to drop this compatibility to make it
        easier for us with Linux userspace programs which mostly never checked
        for both values.  We don't expect major fall-outs because of this
        change, and if we face some, we will simply rebuild the necessary
        applications in the debian archives"
      
      * 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: add flexible mmap memory layout support
        parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc
        parisc: convert uapi/asm/stat.h to use native types only
        parisc: wire up sched_setattr and sched_getattr
        parisc: fix cache-flushing
        parisc/sti_console: prefer Linux fonts over built-in ROM fonts
      69048e01
    • Mikulas Patocka's avatar
      hpfs: optimize quad buffer loading · 1c0b8a7a
      Mikulas Patocka authored
      HPFS needs to load 4 consecutive 512-byte sectors when accessing the
      directory nodes or bitmaps.  We can't switch to 2048-byte block size
      because files are allocated in the units of 512-byte sectors.
      
      Previously, the driver would allocate a 2048-byte area using kmalloc,
      copy the data from four buffers to this area and eventually copy them
      back if they were modified.
      
      In the current implementation of the buffer cache, buffers are allocated
      in the pagecache.  That means that 4 consecutive 512-byte buffers are
      stored in consecutive areas in the kernel address space.  So, we don't
      need to allocate extra memory and copy the content of the buffers there.
      
      This patch optimizes the code to avoid copying the buffers.  It checks
      if the four buffers are stored in contiguous memory - if they are not,
      it falls back to allocating a 2048-byte area and copying data there.
      Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1c0b8a7a
    • Mikulas Patocka's avatar
      hpfs: remember free space · 2cbe5c76
      Mikulas Patocka authored
      Previously, hpfs scanned all bitmaps each time the user asked for free
      space using statfs.  This patch changes it so that hpfs scans the
      bitmaps only once, remembes the free space and on next invocation of
      statfs it returns the value instantly.
      
      New versions of wine are hammering on the statfs syscall very heavily,
      making some games unplayable when they're stored on hpfs, with load
      times in minutes.
      
      This should be backported to the stable kernels because it fixes
      user-visible problem (excessive level load times in wine).
      Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2cbe5c76
  8. 02 Feb, 2014 7 commits