Hi,
I have been working on the Google Summer of Code Project : Click Board
Support through Greybus
<https://summerofcode.withgoogle.com/projects/#5996499987595264> , which
aims to bring in support for MikroElektronika Click Boards
<https://www.mikroe.com/click> through Greybus Simulator
<https://github.com/projectara/gbsim> , I was able to set up and bring in
support for some of the Click boards through Greybus Simulator and passing
the properties related to the Click Board device driver manipulating the
product string and vendor string properties in the manifest, however I am
stuck now as some of the click boards require additional platform data(like
Reset Pin, Interrupts..etc) passed to the spi_new_device/i2c_new_device
calls, does Greybus allow passing of these parameters to the driver, if so
can someone guide me with the documentation for the same or point me a
suitable example so that I can implement the solution in the project.
If greybus doesn't allow for passing these parameters what would be the
ideal way to bring in support for these click boards(which mostly uses
SPI/I2C interfaces) through the greybus subsystem?.
Thanks and Regards
Vaishnav M A
GSoC '19 Student Under Beagleboard.org
Remove function gb_i2c_device_setup as all it does is call
gb_i2c_functionality_operation.
Rename gb_i2c_functionality_operation to gb_i2c_device_setup to maintain
compatibility with call sites.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux(a)gmail.com>
---
drivers/staging/greybus/i2c.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/greybus/i2c.c b/drivers/staging/greybus/i2c.c
index 7bb85a75d3b1..b2522043a1a4 100644
--- a/drivers/staging/greybus/i2c.c
+++ b/drivers/staging/greybus/i2c.c
@@ -31,7 +31,14 @@ static u32 gb_i2c_functionality_map(u32 gb_i2c_functionality)
return gb_i2c_functionality; /* All bits the same for now */
}
-static int gb_i2c_functionality_operation(struct gb_i2c_device *gb_i2c_dev)
+/*
+ * Do initial setup of the i2c device. This includes verifying we
+ * can support it (based on the protocol version it advertises).
+ * If that's OK, we get and cached its functionality bits.
+ *
+ * Note: gb_i2c_dev->connection is assumed to have been valid.
+ */
+static int gb_i2c_device_setup(struct gb_i2c_device *gb_i2c_dev)
{
struct gb_i2c_functionality_response response;
u32 functionality;
@@ -235,19 +242,6 @@ static const struct i2c_algorithm gb_i2c_algorithm = {
.functionality = gb_i2c_functionality,
};
-/*
- * Do initial setup of the i2c device. This includes verifying we
- * can support it (based on the protocol version it advertises).
- * If that's OK, we get and cached its functionality bits.
- *
- * Note: gb_i2c_dev->connection is assumed to have been valid.
- */
-static int gb_i2c_device_setup(struct gb_i2c_device *gb_i2c_dev)
-{
- /* Assume the functionality never changes, just get it once */
- return gb_i2c_functionality_operation(gb_i2c_dev);
-}
-
static int gb_i2c_probe(struct gbphy_device *gbphy_dev,
const struct gbphy_device_id *id)
{
--
2.19.1
From: Colin Ian King <colin.king(a)canonical.com>
The variable is_empty is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
---
drivers/staging/greybus/audio_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager.c b/drivers/staging/greybus/audio_manager.c
index c2a4af4c1d06..9b19ea9d3fa1 100644
--- a/drivers/staging/greybus/audio_manager.c
+++ b/drivers/staging/greybus/audio_manager.c
@@ -86,7 +86,7 @@ EXPORT_SYMBOL_GPL(gb_audio_manager_remove);
void gb_audio_manager_remove_all(void)
{
struct gb_audio_manager_module *module, *next;
- int is_empty = 1;
+ int is_empty;
down_write(&modules_rwsem);
--
2.20.1
