28 Aug, 2019

1 commit

  • With the goal of moving the core of the greybus code out of staging, the
    include files need to be moved to include/linux/greybus.h and
    include/linux/greybus/

    Cc: Vaibhav Hiremath
    Cc: Johan Hovold
    Cc: Vaibhav Agarwal
    Cc: Rui Miguel Silva
    Cc: David Lin
    Cc: "Bryan O'Donoghue"
    Cc: greybus-dev@lists.linaro.org
    Cc: devel@driverdev.osuosl.org
    Acked-by: Mark Greer
    Acked-by: Viresh Kumar
    Acked-by: Alex Elder
    Link: https://lore.kernel.org/r/20190825055429.18547-8-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

11 Nov, 2017

2 commits

  • Now that the SPDX tag is in all greybus files, that identifies the
    license in a specific and legally-defined manner. So the extra GPL text
    wording can be removed as it is no longer needed at all.

    This is done on a quest to remove the 700+ different ways that files in
    the kernel describe the GPL license text. And there's unneeded stuff
    like the address (sometimes incorrect) for the FSF which is never
    needed.

    No copyright headers or other non-license-description text was removed.

    Cc: Vaibhav Hiremath
    Reviewed-by: Alex Elder
    Acked-by: Vaibhav Agarwal
    Acked-by: David Lin
    Acked-by: Johan Hovold
    Acked-by: Viresh Kumar
    Acked-by: Mark Greer
    Acked-by: Rui Miguel Silva
    Acked-by: "Bryan O'Donoghue"
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • It's good to have SPDX identifiers in all files to make it easier to
    audit the kernel tree for correct licenses.

    Update the drivers/staging/greybus files files with the correct SPDX
    license identifier based on the license text in the file itself. The
    SPDX identifier is a legally binding shorthand, which can be used
    instead of the full boiler plate text.

    This work is based on a script and data from Thomas Gleixner, Philippe
    Ombredanne, and Kate Stewart.

    Cc: Vaibhav Hiremath
    Cc: "Bryan O'Donoghue"
    Cc: Thomas Gleixner
    Cc: Kate Stewart
    Cc: Philippe Ombredanne
    Acked-by: Vaibhav Agarwal
    Acked-by: David Lin
    Reviewed-by: Alex Elder
    Acked-by: Johan Hovold
    Acked-by: Viresh Kumar
    Acked-by: Mark Greer
    Acked-by: Rui Miguel Silva
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

19 Sep, 2016

1 commit


27 Jul, 2016

2 commits

  • S2 Loader doesn't support runtime PM operations currently and we will
    fail to suspend/resume the bundle for firmware management protocols.

    Once that happens, the bundle and its connections will be pretty much
    useless as we would have tried to disable/enable all connections during
    such an operation and the S2 loader doesn't expect the connections to go
    away during normal operation (except in the case of mode-switch).

    This patch defines a new quirk GB_INTERFACE_QUIRK_NO_PM and uses a new
    interface init status value (GB_INIT_S2_LOADER_INITIALIZED) which will
    be advertised by S2 Loader now in the init status.

    After detecting the currently running stage as S2 Loader, the kernel
    wouldn't attempt suspending or resuming the bundle.

    Reviewed-by: David Lin
    Reviewed-by: Johan Hovold
    Signed-off-by: Viresh Kumar
    Signed-off-by: Greg Kroah-Hartman

    Viresh Kumar
     
  • This patch implements runtime PM support for firmware management bundle.
    This guarantees that the bundle will be active, while the AP or the
    Module is trying to exchange any operations over any of the CPorts.

    - Firmware Management CPort:

    Runtime PM get/put calls are placed around the ioctl calls, which are
    all implemented as blocking ioctls.

    - Component Authentication CPort:

    Runtime PM get/put calls are placed around the ioctl calls, which are
    all implemented as blocking ioctls.

    - SPI:

    Uses the interface provided by spilib.c and runtime PM get/put are
    called around connection usage.

    - firmware-download:

    This is the most tricky one. All operations on this CPort are
    initiated from the Module and not from the AP. And the AP needs to do
    runtime_pm_get() before any request is received over this CPort.

    The module doesn't send any request over this connection, unless the
    AP has requested the module over firmware management CPort to download
    a firmware package over firmware download CPort.

    And so the runtime PM get/put calls around the ioctls in
    fw-management.c are sufficient to handle the firmware management CPort
    as well.

    Signed-off-by: Viresh Kumar
    Signed-off-by: Greg Kroah-Hartman

    Viresh Kumar
     

22 Jul, 2016

1 commit

  • spilib is used by multiple users currently (spi.c and fw-core.c) but
    commit aa52b62a0556 broke that hierarchy and introduced gbphy dependent
    code in spilib.

    This may have unreliable consequences as we are doing following
    operation unconditionally now:

    gbphy_dev = to_gbphy_dev(spi->parent);
    gbphy_runtime_get_sync(gbphy_dev);

    which may not go well when the parent is of type &bundle->dev
    (fw-core.c).

    This patch introduces spilib_ops and lets the users of the core register
    them. This shall have no functional change for the spi.c usecase and
    shall fix the unreliable results for the fw-core.c usecase.

    Tested by writing to mtd0 dev and verifying (with print messages) that
    the below routines are getting called for a gpbridge-test module.

    Fixes: aa52b62a0556 ("spi: Add runtime_pm support")
    Signed-off-by: Viresh Kumar
    Signed-off-by: Greg Kroah-Hartman

    Viresh Kumar
     

07 Jul, 2016

1 commit

  • This patch adds Component Authentication Protocol support in greybus.
    The purpose of the CAP protocol is to authenticate the Module hardware,
    and it can only be used when it is present as part of the
    firmware-management bundle, on a separate CPort.

    Compile tested only.

    Signed-off-by: Viresh Kumar
    Reviewed-by: Jun Li
    Tested-by: Jun Li
    Signed-off-by: Alex Elder

    Viresh Kumar
     

21 May, 2016

1 commit


15 May, 2016

2 commits


30 Apr, 2016

1 commit


28 Apr, 2016

1 commit

  • All firmware packages on the Modules or Interfaces are now managed by a
    special Firmware Management Protocol. The Interface Manifest shall
    at least contain the Firmware Management Bundle and a Firmware
    Management Protocol CPort within it.

    The bundle may contain additional CPorts based on the extra
    functionality required to manage firmware packages.

    For example, this is how the Firmware Management Bundle of the Interface
    Manifest may look like:

    ; Firmware Management Bundle (Bundle 1):
    [bundle-descriptor 1]
    class = 0x16

    ; (Mandatory) Firmware Management Protocol on CPort 1
    [cport-descriptor 1]
    bundle = 1
    protocol = 0x18

    ; (Optional) Firmware Download Protocol on CPort 2
    [cport-descriptor 2]
    bundle = 1
    protocol = 0x17

    ; (Optional) SPI protocol on CPort 3
    [cport-descriptor 3]
    bundle = 1
    protocol = 0x0b

    ; (Optional) Component Authentication Protocol (CAP) on CPort 4
    [cport-descriptor 4]
    bundle = 1
    protocol = 0xXX //TBD

    This patch adds the basic firmware-management bundle driver, which just
    creates a firmware-management connection. Support for individual
    protocols will be added separately.

    Signed-off-by: Viresh Kumar
    Signed-off-by: Greg Kroah-Hartman

    Viresh Kumar