1. 07 3月, 2012 1 次提交
    • O
      remoteproc: resource table overhaul · fd2c15ec
      Ohad Ben-Cohen 提交于
      The resource table is an array of 'struct fw_resource' members, where
      each resource entry is expressed as a single member of that array.
      
      This approach got us this far, but it has a few drawbacks:
      
      1. Different resource entries end up overloading the same members of 'struct
         fw_resource' with different meanings. The resulting code is error prone
         and hard to read and maintain.
      
      2. It's impossible to extend 'struct fw_resource' without breaking the
         existing firmware images (and we already want to: we can't introduce the
         new virito device resource entry with the current scheme).
      
      3. It doesn't scale: 'struct fw_resource' must be as big as the largest
         resource entry type. As a result, smaller resource entries end up
         utilizing only small part of it.
      
      This is fixed by defining a dedicated structure for every resource type,
      and then converting the resource table to a list of type-value members.
      Instead of a rigid array of homogeneous structs, the resource table
      is turned into a collection of heterogeneous structures.
      
      This way:
      1. Resource entries consume exactly the amount of bytes they need.
      2. It's easy to extend: just create a new resource entry structure, and assign
         it a new type.
      3. The code is easier to read and maintain: the structures' members names are
         meaningful.
      
      While we're at it, this patch has several other resource table changes:
      1. The resource table gains a simple header which contains the
         number of entries in the table and their offsets within the table. This
         makes the parsing code simpler and easier to read.
      2. A version member is added to the resource table. Should we change the
         format again, we'll bump up this version to prevent breakage with
         existing firmware images.
      3. The VRING and VIRTIO_DEV resource entries are combined to a single
         VDEV entry. This paves the way to supporting multiple VDEV entries.
      4. Since we don't really support 64-bit rprocs yet, convert two stray u64
         members to u32.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Iliyan Malchev <malchev@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: John Williams <john.williams@petalogix.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
      Cc: Anna Suman <s-anna@ti.com>
      Cc: Clark Rob <rob@ti.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Saravana Kannan <skannan@codeaurora.org>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Kieran Bingham <kieranbingham@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      fd2c15ec
  2. 04 3月, 2012 1 次提交
  3. 29 2月, 2012 5 次提交
    • O
      rpmsg: fix published buffer length in rpmsg_recv_done · f1d9e9c7
      Ohad Ben-Cohen 提交于
      After processing an incoming message, always publish the real size
      of its containing buffer when putting it back on the available rx ring.
      
      Using any different value might erroneously limit the remote processor
      (leading it to think the buffer is smaller than it really is).
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Rob Clark <rob@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      f1d9e9c7
    • O
      rpmsg: validate incoming message length before propagating · 9648224e
      Ohad Ben-Cohen 提交于
      When an inbound message arrives, validate its reported length before
      propagating it, otherwise buggy (or malicious) remote processors might
      trick us into accessing memory which we really shouldn't.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Rob Clark <rob@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      9648224e
    • O
      rpmsg: fix name service endpoint leak · fa2d7795
      Ohad Ben-Cohen 提交于
      The name service endpoint wasn't destroyed, so fix it.
      
      This is achieved by introducing an internal __rpmsg_destroy_ept
      function which doesn't assume the given ept is bound to an rpmsg
      channel (much like the existing __rpmsg_create_ept).
      
      This is needed because the name service ept belongs to the rpmsg bus,
      and is never bound with a specific rpdev.
      Reported-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Rob Clark <rob@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      fa2d7795
    • O
      remoteproc/omap: two Kconfig fixes · 9cd8eb43
      Ohad Ben-Cohen 提交于
      1. Depend on OMAP_IOMMU instead of selecting it, to fix an unmet
         direct dependency of it (and its imminent build error)
      2. Set default to 'no' (achieved implicitly by dropping the 'default'
         line)
      Reported-by: NRussell King <linux@arm.linux.org.uk>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Rob Clark <rob@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      9cd8eb43
    • O
      remoteproc: make sure we're parsing a 32bit firmware · 40b78b2c
      Ohad Ben-Cohen 提交于
      Make sure we're parsing a 32bit image, since we only support
      the ELF32 binary format at this point.
      
      This should prevent unexpected behavior with non 32bit binaries.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Rob Clark <rob@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      40b78b2c
  4. 23 2月, 2012 6 次提交
    • O
      remoteproc: s/big switch/lookup table/ · e12bc14b
      Ohad Ben-Cohen 提交于
      A lookup table would be easier to extend, and the resulting
      code is a bit cleaner.
      Reported-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      e12bc14b
    • O
      remoteproc: bail out if firmware has different endianess · cf59d3e9
      Ohad Ben-Cohen 提交于
      At this point we don't support remote processors that have
      a different endianess than the host.
      
      Look out for these unsupported scenarios, and bail out if
      encountered.
      Reported-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Mark Grosen <mgrosen@ti.com>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      cf59d3e9
    • O
      remoteproc: don't use virtio's weak barriers · dd6da1c5
      Ohad Ben-Cohen 提交于
      When creating a virtqueue for rpmsg, tell virtio we're not interested
      in "weak" smp barriers, since we're talking to a real device.
      
      On ARM, this means using a DSB instead of a DMB, which is needed
      for platforms that kick the remote processor using some kind of
      a mailbox device mapped to Device memory (otherwise the kick can
      jump ahead and wake the remote processor before it has observed
      the changes to the vrings).
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      dd6da1c5
    • A
      rpmsg: rename virtqueue_add_buf_gfp to virtqueue_add_buf · b719587e
      Axel Lin 提交于
      Since commit 7bb7aef2 "virtio: rename virtqueue_add_buf_gfp to virtqueue_add_buf",
      virtqueue_add_buf_gfp is already rename to virtqueue_add_buf now.
      
      This patch fixes below build error:
       CC [M]  drivers/rpmsg/virtio_rpmsg_bus.o
      drivers/rpmsg/virtio_rpmsg_bus.c: In function 'rpmsg_send_offchannel_raw':
      drivers/rpmsg/virtio_rpmsg_bus.c:723: error: implicit declaration of function 'virtqueue_add_buf_gfp'
      make[2]: *** [drivers/rpmsg/virtio_rpmsg_bus.o] Error 1
      make[1]: *** [drivers/rpmsg] Error 2
      make: *** [drivers] Error 2
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      b719587e
    • O
      rpmsg: depend on EXPERIMENTAL · 4ba60295
      Ohad Ben-Cohen 提交于
      There isn't any binary change in sight or evidence of any stability
      issue, but as we just begin to get traction we can't rule them out
      completely.
      
      To be on the safe side, let's mark rpmsg as EXPERIMENTAL, and remove
      it later on after we have several happy users.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Rob Clark <rob@ti.com>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      4ba60295
    • O
      remoteproc: depend on EXPERIMENTAL · 489d129a
      Ohad Ben-Cohen 提交于
      Remoteproc is still under development and as it gets traction we
      definitely expect to do some changes in the binary format (most probably
      only in the resource table, e.g. the upcoming move to TLV-based entries).
      
      Active testing and use of remoteproc is most welcome, but we don't want
      users to expect backward binary compatibility with the preliminary
      images we have today.
      
      Therefore mark remoteproc as EXPERIMENTAL, and explicitly inform the user
      about this when a new remote processor is registered.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Rob Clark <rob@ti.com>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      489d129a
  5. 09 2月, 2012 13 次提交
    • O
      rpmsg: add Kconfig menu · f8289eda
      Ohad Ben-Cohen 提交于
      Add a dedicated Kconfig menu for the rpmsg drivers, so they
      don't show up in the main driver menu.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      f8289eda
    • O
      remoteproc: add Kconfig menu · 650d6561
      Ohad Ben-Cohen 提交于
      Add a dedicated Kconfig menu for the remoteproc drivers, so they
      don't show up in the main driver menu.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      650d6561
    • O
      remoteproc: look for truncated firmware images · 9bc91231
      Ohad Ben-Cohen 提交于
      Make sure firmware isn't truncated before accessing its data.
      Reported-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      9bc91231
    • O
      remoteproc/omap: utilize module_platform_driver · 63d667bf
      Ohad Ben-Cohen 提交于
      Ditch some boilerplate code by employing the module_platform_driver
      helper.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      63d667bf
    • O
      remoteproc: remove unused resource type · 2fd51811
      Ohad Ben-Cohen 提交于
      RSC_VIRTIO_CFG isn't being used, so remove it.
      
      Originally it was introduced to overcome a resource table limitation
      that prevented describing a virtio device in a single resource table
      entry.
      
      The plan though is to describe resource table entries in a TLV fashion,
      where each entry will consume the amount of space it requires,
      so the original limitation is anyway temporary.
      Reported-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      2fd51811
    • M
      remoteproc: avoid registering a virtio device if not supported · 7d2d3956
      Mark Grosen 提交于
      Let remoteproc know when the firmware doesn't support any virtio
      functionality, so registering a virtio device can be avoided.
      
      This is needed for remote processors that doesn't require any
      virtio-based communications, but are still controlled via remoteproc.
      
      [ohad@wizery.com: write commit log]
      Signed-off-by: NMark Grosen <mgrosen@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      7d2d3956
    • M
      remoteproc: do not require an iommu · 0798e1da
      Mark Grosen 提交于
      Not all remote processors employ an IOMMU, so do not error out
      on !iommu_present().
      
      Note: we currently still use iommu_present() to tell whether we need
      to configure an IOMMU or not. That works for simple cases, but will
      easily fail with more complicated ones (e.g. where an IOMMU exists,
      but not all remote processors use it). When those use cases show up,
      we will solve them by introducing something like remoteproc hw
      capabilities.
      
      [ohad@wizery.com: write commit log]
      Signed-off-by: NMark Grosen <mgrosen@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      0798e1da
    • O
      samples/rpmsg: add an rpmsg driver sample · 779b96d2
      Ohad Ben-Cohen 提交于
      Add an rpmsg driver sample, which demonstrates how to communicate with
      an AMP-configured remote processor over the rpmsg bus.
      
      Note how once probed, the driver can immediately start sending messages
      using the rpmsg_send() API, without having to worry about creating endpoints
      or allocating rpmsg addresses: all that work is done by the rpmsg bus,
      and the required information is already embedded in the rpmsg channel
      that the driver is probed with.
      
      In this sample, the driver simply sends a "Hello World!" message to the remote
      processor repeatedly.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      779b96d2
    • O
      rpmsg: add virtio-based remote processor messaging bus · bcabbcca
      Ohad Ben-Cohen 提交于
      Add a virtio-based inter-processor communication bus, which enables
      kernel drivers to communicate with entities, running on remote
      processors, over shared memory using a simple messaging protocol.
      
      Every pair of AMP processors share two vrings, which are used to send
      and receive the messages over shared memory.
      
      The header of every message sent on the rpmsg bus contains src and dst
      addresses, which make it possible to multiplex several rpmsg channels on
      the same vring.
      
      Every rpmsg channel is a device on this bus. When a channel is added,
      and an appropriate rpmsg driver is found and probed, it is also assigned
      a local rpmsg address, which is then bound to the driver's callback.
      
      When inbound messages carry the local address of a bound driver,
      its callback is invoked by the bus.
      
      This patch provides a kernel interface only; user space interfaces
      will be later exposed by kernel users of this rpmsg bus.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: Rusty Russell <rusty@rustcorp.com.au> (virtio_ids.h)
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      bcabbcca
    • O
      remoteproc/omap: add a remoteproc driver for OMAP4 · 34ed5a33
      Ohad Ben-Cohen 提交于
      Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and
      and DSP subsystems.
      
      Use the omap_device_* API to control the hardware state, and utilize
      the OMAP mailbox to interrupt the remote processor when a new message
      is pending (the mailbox payload is used to tell it which virtqueue was
      the message placed in).
      
      Conversely, when an inbound mailbox message arrives, tell the remoteproc
      core which virtqueue is triggered.
      
      Later we will also use the mailbox payload to signal omap-specific
      events like remote crashes (which will be used to trigger remoteproc
      recovery) and power management transitions. At that point we will also
      extend the remoteproc core to support this.
      
      Based on (but now quite far from) work done by Fernando Guzman Lugo
      <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      34ed5a33
    • O
      remoteproc: create rpmsg virtio device · ac8954a4
      Ohad Ben-Cohen 提交于
      Create an rpmsg virtio device to allow message-based communication
      with the remote processor (but only if supported by its firmware).
      
      There are several advantages to provide this functionality at
      the remoteproc-level:
      - to support it, platforms only have to provide their own ->kick()
        handler; no need to duplicate the rest of the code.
      - the virtio device is created only when the remote processor is
        registered and ready to go. No need to depend on initcall magic.
        moreover, we only add the virtio device if the firmware really
        supports it, and only after we know the supported virtio device features.
      - correct device model hierarchy can be set, and that is useful
        for natural power management and DMA API behavior.
      - when the remote processor crashes (or removed) we only need
        to remove the virtio device, and the driver core will take care of
        the rest. No need to implement any out-of-bound notifiers.
      - we can now easily bind the virtio device to its rproc handle, and
        this way we don't need any name-based remoteproc ->get() API.
      
      Currently we only support creating a single rpmsg virtio device per
      remote processor, but later this is going to be extended to support
      creating numerous virtio devices of other types too (block, net,
      console...).
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      ac8954a4
    • O
      remoteproc: add debugfs entries · 6391a706
      Ohad Ben-Cohen 提交于
      Expose several remote processor properties (name, state, trace buffer)
      that are helpful for debugging.
      
      This part is extracted to a separate patch just to keep the review load
      down.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      6391a706
    • O
      remoteproc: add framework for controlling remote processors · 400e64df
      Ohad Ben-Cohen 提交于
      Modern SoCs typically employ a central symmetric multiprocessing (SMP)
      application processor running Linux, with several other asymmetric
      multiprocessing (AMP) heterogeneous processors running different instances
      of operating system, whether Linux or any other flavor of real-time OS.
      
      Booting a remote processor in an AMP configuration typically involves:
      - Loading a firmware which contains the OS image
      - Allocating and providing it required system resources (e.g. memory)
      - Programming an IOMMU (when relevant)
      - Powering on the device
      
      This patch introduces a generic framework that allows drivers to do
      that. In the future, this framework will also include runtime power
      management and error recovery.
      
      Based on (but now quite far from) work done by Fernando Guzman Lugo
      <fernando.lugo@ti.com>.
      
      ELF loader was written by Mark Grosen <mgrosen@ti.com>, based on
      msm's Peripheral Image Loader (PIL) by Stephen Boyd <sboyd@codeaurora.org>.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      400e64df
  6. 20 1月, 2012 10 次提交
  7. 19 1月, 2012 4 次提交