1. 27 Aug, 2019 1 commit
  2. 12 Aug, 2019 1 commit
    • Wenwen Wang's avatar
      i3c: master: fix a memory leak bug · 7afe9a4e
      Wenwen Wang authored
      In i3c_master_getmwl_locked(), the buffer used for the dest payload data is
      allocated using kzalloc() in i3c_ccc_cmd_dest_init(). Later on, the length
      of the dest payload data is checked against 'sizeof(*mwl)'. If they are not
      equal, -EIO is returned to indicate the error. However, the allocated
      buffer is not deallocated on this path, leading to a memory leak.
      To fix the above issue, free the buffer before returning the error.
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
  3. 11 Aug, 2019 3 commits
  4. 27 Jul, 2019 1 commit
  5. 04 Jul, 2019 1 commit
  6. 20 Jun, 2019 3 commits
  7. 28 May, 2019 1 commit
  8. 21 May, 2019 1 commit
  9. 06 May, 2019 1 commit
  10. 10 Apr, 2019 2 commits
  11. 30 Mar, 2019 1 commit
  12. 28 Feb, 2019 1 commit
  13. 26 Jan, 2019 1 commit
  14. 25 Jan, 2019 1 commit
  15. 22 Jan, 2019 1 commit
  16. 15 Jan, 2019 1 commit
  17. 07 Jan, 2019 1 commit
  18. 12 Dec, 2018 1 commit
  19. 05 Dec, 2018 6 commits
  20. 12 Nov, 2018 1 commit
    • Boris Brezillon's avatar
      i3c: Add core I3C infrastructure · 3a379bbc
      Boris Brezillon authored
      Add core infrastructure to support I3C in Linux and document it.
      This infrastructure adds basic I3C support. Advanced features will be
      added afterwards.
      There are a few design choices that are worth mentioning because they
      impact the way I3C device drivers can interact with their devices:
      - all functions used to send I3C/I2C frames must be called in
        non-atomic context. Mainly done this way to ease implementation, but
        this is not set in stone, and if anyone needs async support, new
        functions can be added later on.
      - the bus element is a separate object, but it's tightly coupled with
        the master object. We thus have a 1:1 relationship between i3c_bus
        and i3c_master_controller objects, and if 2 master controllers are
        connected to the same bus and both exposed to the same Linux instance
        they will appear as two distinct busses, and devices on this bus will
        be exposed twice.
      - I2C backward compatibility has been designed to be transparent to I2C
        drivers and the I2C subsystem. The I3C master just registers an I2C
        adapter which creates a new I2C bus. I'd say that, from a
        representation PoV it's not ideal because what should appear as a
        single I3C bus exposing I3C and I2C devices here appears as 2
        different buses connected to each other through the parenting (the
        I3C master is the parent of the I2C and I3C busses).
        On the other hand, I don't see a better solution if we want something
        that is not invasive.
      Missing features:
      - I3C HDR modes are not supported
      - no support for multi-master and the associated concepts (mastership
        handover, support for secondary masters, ...)
      - I2C devices can only be described using DT because this is the only
        use case I have. However, the framework can easily be extended with
        ACPI and board info support
      - I3C slave framework. This has been completely omitted, but shouldn't
        have a huge impact on the I3C framework because I3C slaves don't see
        the whole bus, it's only about handling master requests and generating
        IBIs. Some of the struct, constant and enum definitions could be
        shared, but most of the I3C slave framework logic will be different
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>