1. 30 Apr, 2013 1 commit
  2. 21 Apr, 2013 1 commit
  3. 15 Apr, 2013 1 commit
  4. 20 Mar, 2013 1 commit
  5. 28 Feb, 2013 2 commits
  6. 11 Jan, 2013 1 commit
  7. 09 Jan, 2013 1 commit
  8. 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: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0fe763c5
  9. 18 Dec, 2012 1 commit
  10. 28 Sep, 2012 1 commit
  11. 12 Sep, 2012 1 commit
  12. 17 Jul, 2012 1 commit
    • Federico Fuga's avatar
      rpmsg: fix dependency on initialization order · 96342526
      Federico Fuga authored
      When rpmsg drivers are built into the kernel, they must not initialize
      before the rpmsg bus does, otherwise they'd trigger a BUG() in
      drivers/base/driver.c line 169 (driver_register()).
      
      To fix that, and to stop depending on arbitrary linkage ordering of
      those built-in rpmsg drivers, we make the rpmsg bus initialize at
      subsys_initcall.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarFederico Fuga <fuga@studiofuga.com>
      [ohad: rewrite the commit log]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      96342526
  13. 05 Jul, 2012 1 commit
    • Ohad Ben-Cohen's avatar
      remoteproc: maintain a generic child device for each rproc · b5ab5e24
      Ohad Ben-Cohen authored
      For each registered rproc, maintain a generic remoteproc device whose
      parent is the low level platform-specific device (commonly a pdev, but
      it may certainly be any other type of device too).
      
      With this in hand, the resulting device hierarchy might then look like:
      
      omap-rproc.0
       |
       - remoteproc0  <---- new !
          |
          - virtio0
          |
          - virtio1
             |
             - rpmsg0
             |
             - rpmsg1
             |
             - rpmsg2
      
      Where:
      - omap-rproc.0 is the low level device that's bound to the
        driver which invokes rproc_register()
      - remoteproc0 is the result of this patch, and will be added by the
        remoteproc framework when rproc_register() is invoked
      - virtio0 and virtio1 are vdevs that are registered by remoteproc
        when it realizes that they are supported by the firmware
        of the physical remote processor represented by omap-rproc.0
      - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
        channels, and are registerd by the rpmsg bus when it gets notified
        about their existence
      
      Technically, this patch:
      - changes 'struct rproc' to contain this generic remoteproc.x device
      - creates a new "remoteproc" type, to which this new generic remoteproc.x
        device belong to.
      - adds a super simple enumeration method for the indices of the
        remoteproc.x devices
      - updates all dev_* messaging to use the generic remoteproc.x device
        instead of the low level platform-specific device
      - updates all dma_* allocations to use the parent of remoteproc.x (where
        the platform-specific memory pools, most commonly CMA, are to be found)
      
      Adding this generic device has several merits:
      - we can now add remoteproc runtime PM support simply by hooking onto the
        new "remoteproc" type
      - all remoteproc log messages will now carry a common name prefix
        instead of having a platform-specific one
      - having a device as part of the rproc struct makes it possible to simplify
        refcounting (see subsequent patch)
      
      Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
      discussing these ideas in one of the remoteproc review threads and
      to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
      with the (upcoming) runtime PM support for remoteproc.
      
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      b5ab5e24
  14. 04 Jul, 2012 2 commits
    • Ohad Ben-Cohen's avatar
      rpmsg: make sure inflight messages don't invoke just-removed callbacks · 15fd943a
      Ohad Ben-Cohen authored
      When inbound messages arrive, rpmsg core looks up their associated
      endpoint (by destination address) and then invokes their callback.
      
      We've made sure that endpoints will never be de-allocated after they
      were found by rpmsg core, but we also need to protect against the
      (rare) scenario where the rpmsg driver was just removed, and its
      callback function isn't available anymore.
      
      This is achieved by introducing a callback mutex, which must be taken
      before the callback is invoked, and, obviously, before it is removed.
      
      Cc: stable <stable@vger.kernel.org>
      Reported-by: default avatarFernando Guzman Lugo <fernando.lugo@ti.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      15fd943a
    • Ohad Ben-Cohen's avatar
      rpmsg: avoid premature deallocation of endpoints · 5a081caa
      Ohad Ben-Cohen authored
      When an inbound message arrives, the rpmsg core looks up its
      associated endpoint and invokes the registered callback.
      
      If a message arrives while its endpoint is being removed (because
      the rpmsg driver was removed, or a recovery of a remote processor
      has kicked in) we must ensure atomicity, i.e.:
      
      - Either the ept is removed before it is found
      
      or
      
      - The ept is found but will not be freed until the callback returns
      
      This is achieved by maintaining a per-ept reference count, which,
      when drops to zero, will trigger deallocation of the ept.
      
      With this in hand, it is now forbidden to directly deallocate
      epts once they have been added to the endpoints idr.
      
      Cc: stable <stable@vger.kernel.org>
      Reported-by: default avatarFernando Guzman Lugo <fernando.lugo@ti.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      5a081caa
  15. 04 Mar, 2012 1 commit
  16. 28 Feb, 2012 3 commits
    • Ohad Ben-Cohen's avatar
      rpmsg: fix published buffer length in rpmsg_recv_done · f1d9e9c7
      Ohad Ben-Cohen authored
      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: default avatarOhad 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
    • Ohad Ben-Cohen's avatar
      rpmsg: validate incoming message length before propagating · 9648224e
      Ohad Ben-Cohen authored
      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: default avatarOhad 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
    • Ohad Ben-Cohen's avatar
      rpmsg: fix name service endpoint leak · fa2d7795
      Ohad Ben-Cohen authored
      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: default avatarOmar Ramirez Luna <omar.ramirez@ti.com>
      Signed-off-by: default avatarOhad 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
  17. 22 Feb, 2012 2 commits
    • Axel Lin's avatar
      rpmsg: rename virtqueue_add_buf_gfp to virtqueue_add_buf · b719587e
      Axel Lin authored
      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: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      b719587e
    • Ohad Ben-Cohen's avatar
      rpmsg: depend on EXPERIMENTAL · 4ba60295
      Ohad Ben-Cohen authored
      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: default avatarOhad 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
  18. 08 Feb, 2012 2 commits
    • Ohad Ben-Cohen's avatar
      rpmsg: add Kconfig menu · f8289eda
      Ohad Ben-Cohen authored
      Add a dedicated Kconfig menu for the rpmsg drivers, so they
      don't show up in the main driver menu.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      f8289eda
    • Ohad Ben-Cohen's avatar
      rpmsg: add virtio-based remote processor messaging bus · bcabbcca
      Ohad Ben-Cohen authored
      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: default avatarOhad 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