linux

staging: greybus: add SPDX identifiers to all greybus driver files 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 <hvaibhav.linux@gmail.com> Cc: "Bryan O'Donoghue" <pure.logic@nexus-software.ie> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Vaibhav Agarwal <vaibhav.sr@gmail.com> Acked-by: David Lin <dtwlin@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> Acked-by: Johan Hovold <johan@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-11-07 14:58:41 +01:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

staging: greybus: move core include files to include/linux/greybus/ 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 <hvaibhav.linux@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Vaibhav Agarwal <vaibhav.sr@gmail.com> Cc: Rui Miguel Silva <rmfrfs@gmail.com> Cc: David Lin <dtwlin@gmail.com> Cc: "Bryan O'Donoghue" <pure.logic@nexus-software.ie> Cc: greybus-dev@lists.linaro.org Cc: devel@driverdev.osuosl.org Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Alex Elder <elder@kernel.org> Link: https://lore.kernel.org/r/20190825055429.18547-8-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-08-25 07:54:27 +02:00

greybus: tracing: add module traces Define a new gb_module trace point event class, used to trace events associated with the module abstraction. Define four basic trace points for this--creation time, drop of last reference, before registring interfaces and after de-registering them. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-05-23 23:05:31 -05:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

staging: greybus: Parenthesis alignment Some parameters are aligned with parentheses. Some parentheses was opened at end of line. Signed-off-by: Cristian Sicilia <sicilia.cristian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-25 17:58:15 +01:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

staging: greybus: Parenthesis alignment Some parameters are aligned with parentheses. Some parentheses was opened at end of line. Signed-off-by: Cristian Sicilia <sicilia.cristian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-25 17:58:15 +01:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

staging: greybus: Parenthesis alignment Some parameters are aligned with parentheses. Some parentheses was opened at end of line. Signed-off-by: Cristian Sicilia <sicilia.cristian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-25 17:58:15 +01:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: tracing: add module traces Define a new gb_module trace point event class, used to trace events associated with the module abstraction. Define four basic trace points for this--creation time, drop of last reference, before registring interfaces and after de-registering them. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-05-23 23:05:31 -05:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

staging: greybus: Parenthesis alignment Some parameters are aligned with parentheses. Some parentheses was opened at end of line. Signed-off-by: Cristian Sicilia <sicilia.cristian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-25 17:58:15 +01:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

treewide: Use struct_size() for kmalloc()-family One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL); This patch makes the changes for kmalloc()-family (and kvmalloc()-family) uses. It was done via automatic conversion with manual review for the "CHECKME" non-standard cases noted below, using the following Coccinelle script: // pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len * // sizeof *pkey_cache->table, GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // Same pattern, but can't trivially locate the trailing element name, // or variable name. @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; expression SOMETHING, COUNT, ELEMENT; @@ - alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP) + alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP) Signed-off-by: Kees Cook <keescook@chromium.org>

2018-05-08 13:45:50 -07:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: tracing: add module traces Define a new gb_module trace point event class, used to trace events associated with the module abstraction. Define four basic trace points for this--creation time, drop of last reference, before registring interfaces and after de-registering them. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-05-23 23:05:31 -05:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

staging: greybus: Parenthesis alignment Some parameters are aligned with parentheses. Some parentheses was opened at end of line. Signed-off-by: Cristian Sicilia <sicilia.cristian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-25 17:58:15 +01:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: fix a leak on error in gb_module_create() We should release ->interfaces[0] as well. Fixes: b15d97d77017 ("greybus: core: add module abstraction") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-10-14 22:18:21 +03:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: interface: clean up ES3 activation-retry hack Clean up the ES3 activation retry-hack and isolate it in the interface code. This way the retry hack can be reused when we soon start allowing interfaces to be reactivated after having been powered down. Reviewed-by: Sandeep Patil <sspatil@google.com> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Reviewed-by: Alex Elder <elder@linaro.org> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Patrick Titiano <ptitiano@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-07-20 16:40:22 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: interface: use an enum for interface type Use an enum for the interface type instead of using the SVC protocol values directly. Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Reviewed-by: Alex Elder <elder@linaro.org> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Sandeep Patil <sspatil@google.com> Reviewed-by: Patrick Titiano <ptitiano@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-07-20 16:40:20 +02:00

greybus: module: suppress activation error message for dummy interfaces We currently handle dummy interfaces by deactivating them using activation error paths, but we don't want the corresponding module_inserted error message to be printed. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-07-19 15:24:50 +02:00

staging: greybus: Parenthesis alignment Some parameters are aligned with parentheses. Some parentheses was opened at end of line. Signed-off-by: Cristian Sicilia <sicilia.cristian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-25 17:58:15 +01:00

greybus: module: suppress activation error message for dummy interfaces We currently handle dummy interfaces by deactivating them using activation error paths, but we don't want the corresponding module_inserted error message to be printed. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-07-19 15:24:50 +02:00

greybus: interface: retry enumeration of UniPro-only modules Greybus modules will sometimes fail to send the mailbox poke and erroneously be enumerated as UniPro-only modules. The root cause for this on the module side is not fully understand, but it seems that this may be due to "the bootrom bug:" a known problem with the bootrom where linkup will occasionally fail because of a race condition. Before the new hotplug code was implemented in the firmware, the SVC would retry enumeration of modules that did not send the mailbox poke; this patch ports that functionality to the AP. Signed-off-by: Jeffrey Carlyle <jcarlyle@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-05-18 18:55:13 -07:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

staging: greybus: Parenthesis alignment Some parameters are aligned with parentheses. Some parentheses was opened at end of line. Signed-off-by: Cristian Sicilia <sicilia.cristian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-25 17:58:15 +01:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: interface: prevent reactivation during removal Make sure to prevent an interface that is going away from being reactivated. This is needed to preemptively close a race between the upcoming feature to reactivate a powered-down interface and physical removal (i.e. module_removed event processing) as well as logical removal (e.g. the current system-suspend hack). Reviewed-by: Sandeep Patil <sspatil@google.com> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Reviewed-by: Alex Elder <elder@linaro.org> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Patrick Titiano <ptitiano@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-07-20 16:40:24 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: module: implement controlled module removal Implement controlled module removal through a new module attribute "eject". When a non-zero argument is written to the attribute, all interfaces of the module are disabled (e.g. bundles are deregistered) and deactivated (e.g. powered off) before instructing the SVC to physically eject the module. Note that the module device is not deregistered until the SVC has reported the physical removal of all of its interfaces. A new interface mutex is added to enforce interface state-change serialisation. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:25 +02:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: tracing: add module traces Define a new gb_module trace point event class, used to trace events associated with the module abstraction. Define four basic trace points for this--creation time, drop of last reference, before registring interfaces and after de-registering them. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-05-23 23:05:31 -05:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

greybus: tracing: add module traces Define a new gb_module trace point event class, used to trace events associated with the module abstraction. Define four basic trace points for this--creation time, drop of last reference, before registring interfaces and after de-registering them. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-05-23 23:05:31 -05:00

greybus: core: add module abstraction Add Greybus module abstraction that will be used to implement controlled module removal (eject) and represent module geometry. Greybus module devices correspond to physical modules and have one or more interfaces. Modules have an id that is identical to the id of their primary interface, which in turn is the interface with lowest numbered id. The module name is constructed from the bus and module id: <bus_id>-<module_id> Interfaces, bundles, and control devices are consequently renamed as <bus_id>-<module_id>.<interface_id> <bus_id>-<module_id>.<interface_id>.<bundle_id> <bus_id>-<module_id>.<interface_id>.ctrl As before, interface ids (and therefore in a sense now also module ids) correspond to physical interface positions on the frame. Modules have the following attributes: module_id num_interfaces where module_id is the id of the module and num_interface the number of interfaces the module has. Note that until SVC module-size detection has been implemented, all interfaces are considered to be part of 1x2 modules. Specifically, the two interfaces of a 2x2 module will be presented as two 1x2 modules for now. Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

2016-04-23 18:47:24 +02:00

236 lines 4.9 KiB Raw Permalink Normal View History

236 lines

4.9 KiB

Raw Permalink Normal View History