1. 30 4月, 2012 1 次提交
    • L
      pipes: add a "packetized pipe" mode for writing · 9883035a
      Linus Torvalds 提交于
      The actual internal pipe implementation is already really about
      individual packets (called "pipe buffers"), and this simply exposes that
      as a special packetized mode.
      
      When we are in the packetized mode (marked by O_DIRECT as suggested by
      Alan Cox), a write() on a pipe will not merge the new data with previous
      writes, so each write will get a pipe buffer of its own.  The pipe
      buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
      will tell the reader side to break the read at that boundary (and throw
      away any partial packet contents that do not fit in the read buffer).
      
      End result: as long as you do writes less than PIPE_BUF in size (so that
      the pipe doesn't have to split them up), you can now treat the pipe as a
      packet interface, where each read() system call will read one packet at
      a time.  You can just use a sufficiently big read buffer (PIPE_BUF is
      sufficient, since bigger than that doesn't guarantee atomicity anyway),
      and the return value of the read() will naturally give you the size of
      the packet.
      
      NOTE! We do not support zero-sized packets, and zero-sized reads and
      writes to a pipe continue to be no-ops.  Also note that big packets will
      currently be split at write time, but that the size at which that
      happens is not really specified (except that it's bigger than PIPE_BUF).
      Currently that limit is the system page size, but we might want to
      explicitly support bigger packets some day.
      
      The main user for this is going to be the autofs packet interface,
      allowing us to stop having to care so deeply about exact packet sizes
      (which have had bugs with 32/64-bit compatibility modes).  But user
      space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
      fail with an EINVAL on kernels that do not support this interface.
      Tested-by: NMichael Tokarev <mjt@tls.msk.ru>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Thomas Meyer <thomas@m3y3r.de>
      Cc: stable@kernel.org  # needed for systemd/autofs interaction fix
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9883035a
  2. 28 4月, 2012 1 次提交
  3. 27 4月, 2012 1 次提交
  4. 26 4月, 2012 1 次提交
  5. 25 4月, 2012 1 次提交
    • A
      USB: EHCI: fix crash during suspend on ASUS computers · 151b6128
      Alan Stern 提交于
      This patch (as1545) fixes a problem affecting several ASUS computers:
      The machine crashes or corrupts memory when going into suspend if the
      ehci-hcd driver is bound to any controllers.  Users have been forced
      to unbind or unload ehci-hcd before putting their systems to sleep.
      
      After extensive testing, it was determined that the machines don't
      like going into suspend when any EHCI controllers are in the PCI D3
      power state.  Presumably this is a firmware bug, but there's nothing
      we can do about it except to avoid putting the controllers in D3
      during system sleep.
      
      The patch adds a new flag to indicate whether the problem is present,
      and avoids changing the controller's power state if the flag is set.
      Runtime suspend is unaffected; this matters only for system suspend.
      However as a side effect, the controller will not respond to remote
      wakeup requests while the system is asleep.  Hence USB wakeup is not
      functional -- but of course, this is already true in the current state
      of affairs.
      
      This fixes Bugzilla #42728.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: NOleksij Rempel (fishor) <bug-track@fisher-privat.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      151b6128
  6. 24 4月, 2012 1 次提交
  7. 23 4月, 2012 3 次提交
  8. 21 4月, 2012 6 次提交
  9. 18 4月, 2012 3 次提交
  10. 17 4月, 2012 3 次提交
  11. 16 4月, 2012 3 次提交
  12. 14 4月, 2012 3 次提交
    • L
      do not export kernel's NULL #define to userspace · 2084c24a
      Lubos Lunak 提交于
      GCC's NULL is actually __null, which allows detecting some questionable
      NULL usage and warn about it.  Moreover each platform/compiler should
      have its own stddef.h anyway (which is different from linux/stddef.h).
      
      So there's no good reason to leak kernel's NULL to userspace and
      override what the compiler provides.
      Signed-off-by: NLuboš Luňák <l.lunak@suse.cz>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2084c24a
    • M
      skbuff: struct ubuf_info callback type safety · ca8f4fb2
      Michael S. Tsirkin 提交于
      The skb struct ubuf_info callback gets passed struct ubuf_info
      itself, not the arg value as the field name and the function signature
      seem to imply. Rename the arg field to ctx to match usage,
      add documentation and change the callback argument type
      to make usage clear and to have compiler check correctness.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca8f4fb2
    • G
      ipv6: fix problem with expired dst cache · 1716a961
      Gao feng 提交于
      If the ipv6 dst cache which copy from the dst generated by ICMPV6 RA packet.
      this dst cache will not check expire because it has no RTF_EXPIRES flag.
      So this dst cache will always be used until the dst gc run.
      
      Change the struct dst_entry,add a union contains new pointer from and expires.
      When rt6_info.rt6i_flags has no RTF_EXPIRES flag,the dst.expires has no use.
      we can use this field to point to where the dst cache copy from.
      The dst.from is only used in IPV6.
      
      rt6_check_expired check if rt6_info.dst.from is expired.
      
      ip6_rt_copy only set dst.from when the ort has flag RTF_ADDRCONF
      and RTF_DEFAULT.then hold the ort.
      
      ip6_dst_destroy release the ort.
      
      Add some functions to operate the RTF_EXPIRES flag and expires(from) together.
      and change the code to use these new adding functions.
      
      Changes from v5:
      modify ip6_route_add and ndisc_router_discovery to use new adding functions.
      
      Only set dst.from when the ort has flag RTF_ADDRCONF
      and RTF_DEFAULT.then hold the ort.
      Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1716a961
  13. 13 4月, 2012 2 次提交
    • M
      ARM: 7366/3: amba: Remove AMBA level regulator support · 1e45860f
      Mark Brown 提交于
      The AMBA bus regulator support is being used to model on/off switches
      for power domains which isn't terribly idiomatic for modern kernels with
      the generic power domain code and creates integration problems on platforms
      which don't use regulators for their power domains as it's hard to tell
      the difference between a regulator that is needed but failed to be provided
      and one that isn't supposed to be there (though DT does make that easier).
      
      Platforms that wish to use the regulator API to manage their power domains
      can indirect via the power domain interface.
      
      This feature is only used with the vape supply of the db8500 PRCMU
      driver which supplies the UARTs and MMC controllers, none of which have
      support for managing vcore at runtime in mainline (only pl022 SPI
      controller does).  Update that supply to have an always_on constraint
      until the power domain support for the system is updated so that it is
      enabled for these users, this is likely to have no impact on practical
      systems as probably at least one of these devices will be active and
      cause AMBA to hold the supply on anyway.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Tested-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1e45860f
    • P
      kconfig: fix IS_ENABLED to not require all options to be defined · 69349c2d
      Paul Gortmaker 提交于
      Using IS_ENABLED() within C (vs.  within CPP #if statements) in its
      current form requires us to actually define every possible bool/tristate
      Kconfig option twice (__enabled_* and __enabled_*_MODULE variants).
      
      This results in a huge autoconf.h file, on the order of 16k lines for a
      x86_64 defconfig.
      
      Fixing IS_ENABLED to be able to work on the smaller subset of just
      things that we really have defined is step one to fixing this.  Which
      means it has to not choke when fed non-enabled options, such as:
      
        include/linux/netdevice.h:964:1: warning: "__enabled_CONFIG_FCOE_MODULE" is not defined [-Wundef]
      
      The original prototype of how to implement a C and preprocessor
      compatible way of doing this came from the Google+ user "comex ." in
      response to Linus' crowdsourcing challenge for a possible improvement on
      his earlier C specific solution:
      
      	#define config_enabled(x)       (__stringify(x)[0] == '1')
      
      In this implementation, I've chosen variable names that hopefully make
      how it works more understandable.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69349c2d
  14. 12 4月, 2012 4 次提交
  15. 11 4月, 2012 6 次提交
    • E
      tcp: avoid order-1 allocations on wifi and tx path · a21d4572
      Eric Dumazet 提交于
      Marc Merlin reported many order-1 allocations failures in TX path on its
      wireless setup, that dont make any sense with MTU=1500 network, and non
      SG capable hardware.
      
      After investigation, it turns out TCP uses sk_stream_alloc_skb() and
      used as a convention skb_tailroom(skb) to know how many bytes of data
      payload could be put in this skb (for non SG capable devices)
      
      Note : these skb used kmalloc-4096 (MTU=1500 + MAX_HEADER +
      sizeof(struct skb_shared_info) being above 2048)
      
      Later, mac80211 layer need to add some bytes at the tail of skb
      (IEEE80211_ENCRYPT_TAILROOM = 18 bytes) and since no more tailroom is
      available has to call pskb_expand_head() and request order-1
      allocations.
      
      This patch changes sk_stream_alloc_skb() so that only
      sk->sk_prot->max_header bytes of headroom are reserved, and use a new
      skb field, avail_size to hold the data payload limit.
      
      This way, order-0 allocations done by TCP stack can leave more than 2 KB
      of tailroom and no more allocation is performed in mac80211 layer (or
      any layer needing some tailroom)
      
      avail_size is unioned with mark/dropcount, since mark will be set later
      in IP stack for output packets. Therefore, skb size is unchanged.
      Reported-by: NMarc MERLIN <marc@merlins.org>
      Tested-by: NMarc MERLIN <marc@merlins.org>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a21d4572
    • R
      vgaarb.h: fix build warnings · 6069a4c9
      Randy Dunlap 提交于
      Fix build warnings by providing a struct stub since no fields of
      the struct are used:
      
      include/linux/vgaarb.h:66:9: warning: 'struct pci_dev' declared inside parameter list
      include/linux/vgaarb.h:66:9: warning: its scope is only this definition or declaration, which is probably not what you want
      include/linux/vgaarb.h:99:34: warning: 'struct pci_dev' declared inside parameter list
      include/linux/vgaarb.h:109:6: warning: 'struct pci_dev' declared inside parameter list
      include/linux/vgaarb.h:121:8: warning: 'struct pci_dev' declared inside parameter list
      include/linux/vgaarb.h:140:37: warning: 'struct pci_dev' declared inside parameter list
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6069a4c9
    • S
      pinctrl: include <linux/bug.h> to prevent compile errors · 6f11f6f1
      Stephen Warren 提交于
      Macros in <linux/pinctrl/machine.h> call ARRAY_SIZE(), the definition of
      which eventually calls BUILD_BUG_ON_ZERO(), which is defined in
      <linux/bug.h>. Include that so that every .c file using the pinctrl macros
      doesn't have to do that itself.
      Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      6f11f6f1
    • D
      pinctrl: fix compile error if not select PINMUX support · 89e004e7
      Dong Aisheng 提交于
      The pinctrl_register_mappings is defined in core.c, so change the dependent
      macro from CONFIG_MUX to CONFIG_PINCTRL.
      
      The compile error message is:
      drivers/pinctrl/core.c:886: error: redefinition of 'pinctrl_register_mappings'
      include/linux/pinctrl/machine.h:160: note: previous definition of 'pinctrl_register_mappings' was here
      make[2]: *** [drivers/pinctrl/core.o] Error 1
      make[1]: *** [drivers/pinctrl] Error 2
      make: *** [drivers] Error 2
      Acked-by: NStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      89e004e7
    • G
      irq: Kill pointless irqd_to_hw export · a699e4e4
      Grant Likely 提交于
      It makes no sense to export this trivial function.  Make it a static inline
      instead.
      
      This patch also drops virq_to_hw from arch/c6x since it is unused by that
      architecture.
      
      v2: Move irq_hw_number_t into types.h to fix ARM build failure
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      a699e4e4
    • G
      usb: musb: wake the device before ulpi transfers · bf070bc1
      Grazvydas Ignotas 提交于
      musb can be suspended at the time some other driver wants to do ulpi
      transfers using usb_phy_io_* functions, and that can cause data abort,
      as it happened with isp1704_charger:
      http://article.gmane.org/gmane.linux.kernel/1226122
      
      Add pm_runtime to ulpi functions to rectify this. This also adds io_dev
      to usb_phy so that pm_runtime_* functions can be used.
      
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      bf070bc1
  16. 10 4月, 2012 1 次提交