greybus-dev

greybus-dev@lists.linaro.org

1 participants
570 discussions

[PATCH v4 0/5] misc: Add mikroBUS driver

by Ayush Singh

MikroBUS is an open standard developed by MikroElektronika for connecting add-on boards to microcontrollers or microprocessors. It essentially allows you to easily expand the functionality of your main boards using these add-on boards. This patchset adds mikroBUS as a Linux bus type and provides a driver to parse and register the mikroBUS board using mikroBUS manifest. The patchset is based on work originally done by Vaishnav. Link: https://www.mikroe.com/mikrobus Link: https://docs.beagleboard.org/latest/boards/beagleplay/ Link: https://lore.kernel.org/lkml/20240315184908.500352-1-ayushdevel1325@gmail.c… Patch v3 Changes v4: - Better commit messages - Remove clickID, serdev, pwm, regulator, clocks etc. Just the basic mikroBUS driver. - Fix a lot of memory leaks, unused variables, etc. - Create accompanying PR in Greybus Spec repository - Switch to 80 columns formatting - Some other fixes pointed out in v3 Changes in v3: - Use phandle instead of busname for spi - Use spi board info for registering new device - Convert dt bindings to yaml - Add support for clickID - Code cleanup and style changes - Additions required to spi, serdev, w1 and regulator subsystems Changes in v2: - support for adding mikroBUS ports from DT overlays, - remove debug sysFS interface for adding mikrobus ports, - consider extended pin usage/deviations from mikrobus standard specifications - use greybus CPort protocol enum instead of new protocol enums - Fix cases of wrong indentation, ignoring return values, freeing allocated resources in case of errors and other style suggestions in v1 review. Ayush Singh (5): dt-bindings: misc: Add mikrobus-connector spi: Make of_find_spi_controller_by_node() available greybus: Add mikroBUS manifest types mikrobus: Add mikroBUS driver dts: ti: k3-am625-beagleplay: Add mikroBUS .../connector/mikrobus-connector.yaml | 113 +++ MAINTAINERS | 7 + .../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 80 +- drivers/misc/Kconfig | 1 + drivers/misc/Makefile | 1 + drivers/misc/mikrobus/Kconfig | 15 + drivers/misc/mikrobus/Makefile | 5 + drivers/misc/mikrobus/mikrobus_core.c | 696 ++++++++++++++++++ drivers/misc/mikrobus/mikrobus_core.h | 151 ++++ drivers/misc/mikrobus/mikrobus_manifest.c | 503 +++++++++++++ drivers/misc/mikrobus/mikrobus_manifest.h | 29 + drivers/spi/spi.c | 206 +++--- include/linux/greybus/greybus_manifest.h | 49 ++ include/linux/spi/spi.h | 4 + 14 files changed, 1750 insertions(+), 110 deletions(-) create mode 100644 Documentation/devicetree/bindings/connector/mikrobus-connector.yaml create mode 100644 drivers/misc/mikrobus/Kconfig create mode 100644 drivers/misc/mikrobus/Makefile create mode 100644 drivers/misc/mikrobus/mikrobus_core.c create mode 100644 drivers/misc/mikrobus/mikrobus_core.h create mode 100644 drivers/misc/mikrobus/mikrobus_manifest.c create mode 100644 drivers/misc/mikrobus/mikrobus_manifest.h base-commit: 61996c073c9b070922ad3a36c981ca6ddbea19a5 -- 2.44.0

1 year, 2 months

[PATCH] greybus: Fix deref of NULL in __gb_lights_flash_brightness_set

by Mikhail Lobanov

Dereference of null pointer in the __gb_lights_flash_brightness_set function. Assigning the channel the result of executing the get_channel_from_mode function without checking for NULL may result in an error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Signed-off-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> --- drivers/staging/greybus/light.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 87d36948c610..929514350947 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -148,10 +148,15 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) GB_CHANNEL_MODE_TORCH); /* For not flash we need to convert brightness to intensity */ - intensity = channel->intensity_uA.min + + + if (channel) { + intensity = channel->intensity_uA.min + (channel->intensity_uA.step * channel->led->brightness); - return __gb_lights_flash_intensity_set(channel, intensity); + return __gb_lights_flash_intensity_set(channel, intensity); + } + + return 0; } #else static struct gb_channel *get_channel_from_cdev(struct led_classdev *cdev) -- 2.43.0

1 year, 3 months

[PATCH v2] greybus: Avoid fake flexible array for response data

by Kees Cook

FORTIFY_SOURCE has been ignoring 0-sized destinations while the kernel code base has been converted to flexible arrays. In order to enforce the 0-sized destinations (e.g. with __counted_by), the remaining 0-sized destinations need to be handled. Instead of converting an empty struct into using a flexible array, just directly use a pointer without any additional indirection. Remove struct gb_bootrom_get_firmware_response and struct gb_fw_download_fetch_firmware_response. Signed-off-by: Kees Cook <keescook(a)chromium.org> --- Cc: Alex Elder <elder(a)kernel.org> Cc: Viresh Kumar <vireshk(a)kernel.org> Cc: Johan Hovold <johan(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Gustavo A. R. Silva <gustavo(a)embeddedor.com> Cc: greybus-dev(a)lists.linaro.org Cc: linux-staging(a)lists.linux.dev v2: add comments about removed structs v1: https://patchwork.kernel.org/project/linux-hardening/patch/20240216232824.w… --- drivers/staging/greybus/bootrom.c | 8 ++++---- drivers/staging/greybus/fw-download.c | 8 ++++---- include/linux/greybus/greybus_protocols.h | 8 ++------ 3 files changed, 10 insertions(+), 14 deletions(-) diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index 79581457c4af..c0d338db6b52 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -243,10 +243,10 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) struct gb_bootrom *bootrom = gb_connection_get_data(op->connection); const struct firmware *fw; struct gb_bootrom_get_firmware_request *firmware_request; - struct gb_bootrom_get_firmware_response *firmware_response; struct device *dev = &op->connection->bundle->dev; unsigned int offset, size; enum next_request_type next_request; + u8 *firmware_response; int ret = 0; /* Disable timeouts */ @@ -280,15 +280,15 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) goto unlock; } - if (!gb_operation_response_alloc(op, sizeof(*firmware_response) + size, - GFP_KERNEL)) { + /* gb_bootrom_get_firmware_response contains only a byte array */ + if (!gb_operation_response_alloc(op, size, GFP_KERNEL)) { dev_err(dev, "%s: error allocating response\n", __func__); ret = -ENOMEM; goto unlock; } firmware_response = op->response->payload; - memcpy(firmware_response->data, fw->data + offset, size); + memcpy(firmware_response, fw->data + offset, size); dev_dbg(dev, "responding with firmware (offs = %u, size = %u)\n", offset, size); diff --git a/drivers/staging/greybus/fw-download.c b/drivers/staging/greybus/fw-download.c index 543692c567f9..a06065fb0c5e 100644 --- a/drivers/staging/greybus/fw-download.c +++ b/drivers/staging/greybus/fw-download.c @@ -271,11 +271,11 @@ static int fw_download_fetch_firmware(struct gb_operation *op) struct gb_connection *connection = op->connection; struct fw_download *fw_download = gb_connection_get_data(connection); struct gb_fw_download_fetch_firmware_request *request; - struct gb_fw_download_fetch_firmware_response *response; struct fw_request *fw_req; const struct firmware *fw; unsigned int offset, size; u8 firmware_id; + u8 *response; int ret = 0; if (op->request->payload_size != sizeof(*request)) { @@ -325,8 +325,8 @@ static int fw_download_fetch_firmware(struct gb_operation *op) goto put_fw; } - if (!gb_operation_response_alloc(op, sizeof(*response) + size, - GFP_KERNEL)) { + /* gb_fw_download_fetch_firmware_response contains only a byte array */ + if (!gb_operation_response_alloc(op, size, GFP_KERNEL)) { dev_err(fw_download->parent, "error allocating fetch firmware response\n"); ret = -ENOMEM; @@ -334,7 +334,7 @@ static int fw_download_fetch_firmware(struct gb_operation *op) } response = op->response->payload; - memcpy(response->data, fw->data + offset, size); + memcpy(response, fw->data + offset, size); dev_dbg(fw_download->parent, "responding with firmware (offs = %u, size = %u)\n", offset, diff --git a/include/linux/greybus/greybus_protocols.h b/include/linux/greybus/greybus_protocols.h index aeb8f9243545..820134b0105c 100644 --- a/include/linux/greybus/greybus_protocols.h +++ b/include/linux/greybus/greybus_protocols.h @@ -232,9 +232,7 @@ struct gb_fw_download_fetch_firmware_request { __le32 size; } __packed; -struct gb_fw_download_fetch_firmware_response { - __u8 data[0]; -} __packed; +/* gb_fw_download_fetch_firmware_response contains no other data */ /* firmware download release firmware request */ struct gb_fw_download_release_firmware_request { @@ -414,9 +412,7 @@ struct gb_bootrom_get_firmware_request { __le32 size; } __packed; -struct gb_bootrom_get_firmware_response { - __u8 data[0]; -} __packed; +/* gb_bootrom_get_firmware_response contains no other data */ /* Bootrom protocol Ready to boot request */ struct gb_bootrom_ready_to_boot_request { -- 2.34.1

1 year, 3 months

[PATCH] staging: greybus: put macro in a do - while loop

by Dileep Sankhla

Enclose the macro gb_loopback_stats_attrs defined with multiple replacement statements in a do - while loop. This avoids possible if/else logic defects and clears a checkpatch error. ERROR: Macros with multiple statements should be enclosed in a do - while loop Signed-off-by: Dileep Sankhla <dileepsankhla.ds(a)gmail.com> --- drivers/staging/greybus/loopback.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index bb33379b5297..eb5a7a20f5a3 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -162,9 +162,11 @@ static ssize_t name##_avg_show(struct device *dev, \ static DEVICE_ATTR_RO(name##_avg) #define gb_loopback_stats_attrs(field) \ - gb_loopback_ro_stats_attr(field, min, u); \ - gb_loopback_ro_stats_attr(field, max, u); \ - gb_loopback_ro_avg_attr(field) + do { \ + gb_loopback_ro_stats_attr(field, min, u); \ + gb_loopback_ro_stats_attr(field, max, u); \ + gb_loopback_ro_avg_attr(field); \ + } while (0) #define gb_loopback_attr(field, type) \ static ssize_t field##_show(struct device *dev, \ -- 2.40.1

1 year, 3 months

[PATCH] greybus: move is_gb_* functions out of greybus.h

by Ricardo B. Marliere

The functions below are only used within the context of drivers/greybus/core.c, so move them all into core and drop their 'inline' specifiers: is_gb_host_device(), is_gb_module(), is_gb_interface(), is_gb_control(), is_gb_bundle() and is_gb_svc(). Suggested-by: Alex Elder <elder(a)ieee.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo(a)marliere.net> --- drivers/greybus/core.c | 30 ++++++++++++++++++++++++++++++ include/linux/greybus.h | 30 ------------------------------ 2 files changed, 30 insertions(+), 30 deletions(-) diff --git a/drivers/greybus/core.c b/drivers/greybus/core.c index 5714be740470..f660b213233d 100644 --- a/drivers/greybus/core.c +++ b/drivers/greybus/core.c @@ -27,6 +27,36 @@ int greybus_disabled(void) } EXPORT_SYMBOL_GPL(greybus_disabled); +static int is_gb_host_device(const struct device *dev) +{ + return dev->type == &greybus_hd_type; +} + +static int is_gb_module(const struct device *dev) +{ + return dev->type == &greybus_module_type; +} + +static int is_gb_interface(const struct device *dev) +{ + return dev->type == &greybus_interface_type; +} + +static int is_gb_control(const struct device *dev) +{ + return dev->type == &greybus_control_type; +} + +static int is_gb_bundle(const struct device *dev) +{ + return dev->type == &greybus_bundle_type; +} + +static int is_gb_svc(const struct device *dev) +{ + return dev->type == &greybus_svc_type; +} + static bool greybus_match_one_id(struct gb_bundle *bundle, const struct greybus_bundle_id *id) { diff --git a/include/linux/greybus.h b/include/linux/greybus.h index 18c0fb958b74..38c45ec7d099 100644 --- a/include/linux/greybus.h +++ b/include/linux/greybus.h @@ -113,36 +113,6 @@ extern struct device_type greybus_control_type; extern struct device_type greybus_bundle_type; extern struct device_type greybus_svc_type; -static inline int is_gb_host_device(const struct device *dev) -{ - return dev->type == &greybus_hd_type; -} - -static inline int is_gb_module(const struct device *dev) -{ - return dev->type == &greybus_module_type; -} - -static inline int is_gb_interface(const struct device *dev) -{ - return dev->type == &greybus_interface_type; -} - -static inline int is_gb_control(const struct device *dev) -{ - return dev->type == &greybus_control_type; -} - -static inline int is_gb_bundle(const struct device *dev) -{ - return dev->type == &greybus_bundle_type; -} - -static inline int is_gb_svc(const struct device *dev) -{ - return dev->type == &greybus_svc_type; -} - static inline bool cport_id_valid(struct gb_host_device *hd, u16 cport_id) { return cport_id != CPORT_ID_BAD && cport_id < hd->num_cports; --- base-commit: 70ff1fe626a166dcaadb5a81bfe75e22c91f5dbf change-id: 20240226-device_cleanup-greybus2-b763f50221ab Best regards, -- Ricardo B. Marliere <ricardo(a)marliere.net>

1 year, 3 months

[PATCH] staging: greybus: fix get_channel_from_mode() failure path

by Dan Carpenter

The get_channel_from_mode() function is supposed to return the channel which matches the mode. But it has a bug where if it doesn't find a matching channel then it returns the last channel. It should return NULL instead. Also remove an unnecessary NULL check on "channel". Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> --- drivers/staging/greybus/light.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index d62f97249aca..a5c2fe963866 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -95,15 +95,15 @@ static struct led_classdev *get_channel_cdev(struct gb_channel *channel) static struct gb_channel *get_channel_from_mode(struct gb_light *light, u32 mode) { - struct gb_channel *channel = NULL; + struct gb_channel *channel; int i; for (i = 0; i < light->channels_count; i++) { channel = &light->channels[i]; - if (channel && channel->mode == mode) - break; + if (channel->mode == mode) + return channel; } - return channel; + return NULL; } static int __gb_lights_flash_intensity_set(struct gb_channel *channel, -- 2.43.0

1 year, 3 months

[PATCH][next] staging: greybus: Remove redundant variable 'mask'

by Colin Ian King

The variable mask is being assigned and bit-set but it is never being used apart from this. The variable is redundant and can be removed. Cleans up clang scan build warning: drivers/staging/greybus/audio_topology.c:764:15: warning: variable 'mask' set but not used [-Wunused-but-set-variable] Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> --- drivers/staging/greybus/audio_topology.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/greybus/audio_topology.c b/drivers/staging/greybus/audio_topology.c index 08e6a807c132..5dc4721105d4 100644 --- a/drivers/staging/greybus/audio_topology.c +++ b/drivers/staging/greybus/audio_topology.c @@ -761,7 +761,6 @@ static int gbcodec_enum_dapm_ctl_put(struct snd_kcontrol *kcontrol, { int ret, wi, ctl_id; unsigned int val, mux, change; - unsigned int mask; struct snd_soc_dapm_widget_list *wlist = snd_kcontrol_chip(kcontrol); struct snd_soc_dapm_widget *widget = wlist->widgets[0]; struct gb_audio_ctl_elem_value gbvalue; @@ -802,7 +801,6 @@ static int gbcodec_enum_dapm_ctl_put(struct snd_kcontrol *kcontrol, mux = ucontrol->value.enumerated.item[0]; val = mux << e->shift_l; - mask = e->mask << e->shift_l; if (le32_to_cpu(gbvalue.value.enumerated_item[0]) != ucontrol->value.enumerated.item[0]) { @@ -815,7 +813,6 @@ static int gbcodec_enum_dapm_ctl_put(struct snd_kcontrol *kcontrol, if (ucontrol->value.enumerated.item[1] > e->items - 1) return -EINVAL; val |= ucontrol->value.enumerated.item[1] << e->shift_r; - mask |= e->mask << e->shift_r; if (le32_to_cpu(gbvalue.value.enumerated_item[1]) != ucontrol->value.enumerated.item[1]) { change = 1; -- 2.39.2

1 year, 3 months

[PATCH] greybus: audio: apbridgea: Remove flexible array from struct audio_apbridgea_hdr

by Erick Archer

When a struct containing a flexible array is included in another struct, and there is a member after the struct-with-flex-array, there is a possibility of memory overlap. These cases must be audited [1]. See: struct inner { ... int flex[]; }; struct outer { ... struct inner header; int overlap; ... }; This is the scenario for the "struct audio_apbridgea_hdr" structure that is included in the following "struct audio_apbridgea_*_request" structures: struct audio_apbridgea_set_config_request struct audio_apbridgea_register_cport_request struct audio_apbridgea_unregister_cport_request struct audio_apbridgea_set_tx_data_size_request struct audio_apbridgea_prepare_tx_request struct audio_apbridgea_start_tx_request struct audio_apbridgea_stop_tx_request struct audio_apbridgea_shutdown_tx_request struct audio_apbridgea_set_rx_data_size_request struct audio_apbridgea_prepare_rx_request struct audio_apbridgea_start_rx_request struct audio_apbridgea_stop_rx_request struct audio_apbridgea_shutdown_rx_request The pattern is like the one shown below: struct audio_apbridgea_hdr { ... __u8 data[]; } __packed; struct audio_apbridgea_*_request { struct audio_apbridgea_hdr hdr; ... } __packed; In this case, the trailing flexible array can be removed because it is never used. Link: https://github.com/KSPP/linux/issues/202 [1] Signed-off-by: Erick Archer <erick.archer(a)gmx.com> --- Hi everyone, I'm not sure this patch is correct. My concerns are: The "struct audio_apbridgea_hdr" structure is used as a first member in all the "struct audio_apbridgea_*_request" structures. And these last structures are used in the "gb_audio_apbridgea_*(...)" functions. These functions fill the "request" structure and always use: gb_hd_output(connection->hd, &req, sizeof(req), GB_APB_REQUEST_AUDIO_CONTROL, true); Then, the "gb_hd_output(struct gb_host_device *hd, ...)" function calls: hd->driver->output(hd, req, size, cmd, async); The first parameter to this function is of type: struct gb_host_device { ... const struct gb_hd_driver *driver; ... }; And the "gb_hd_driver" structure is defined as: struct gb_hd_driver { ... int (*output)(struct gb_host_device *hd, void *req, u16 size, u8 cmd, bool async); }; Therefore, my question is: Where is the "output" function pointer set? I think I'm missing something. I have search for another greybus drivers and I have found that, for example, the "es2_ap_driver" (drivers/greybus/es2.c) sets the "output" member in: static struct gb_hd_driver es2_driver = { ... .output = output, }; I think that the flexible array that I have removed should be used in the function assigned to the "output" function pointer. But I am not able to find this function. A bit of light on this would be greatly appreciated. Thanks, Erick --- drivers/staging/greybus/audio_apbridgea.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/greybus/audio_apbridgea.h b/drivers/staging/greybus/audio_apbridgea.h index efec0f815efd..ab707d310129 100644 --- a/drivers/staging/greybus/audio_apbridgea.h +++ b/drivers/staging/greybus/audio_apbridgea.h @@ -65,7 +65,6 @@ struct audio_apbridgea_hdr { __u8 type; __le16 i2s_port; - __u8 data[]; } __packed; struct audio_apbridgea_set_config_request { -- 2.25.1

1 year, 3 months

[PATCH] greybus: constify the struct device_type usage

by Ricardo B. Marliere

Since commit aed65af1cc2f ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Move the greybus_hd_type, greybus_module_type, greybus_interface_type, greybus_control_type, greybus_bundle_type and greybus_svc_type variables to be constant structures as well, placing it into read-only memory which can not be modified at runtime. Signed-off-by: Ricardo B. Marliere <ricardo(a)marliere.net> --- drivers/greybus/bundle.c | 2 +- drivers/greybus/control.c | 2 +- drivers/greybus/hd.c | 2 +- drivers/greybus/interface.c | 2 +- drivers/greybus/module.c | 2 +- drivers/greybus/svc.c | 2 +- include/linux/greybus.h | 12 ++++++------ 7 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/greybus/bundle.c b/drivers/greybus/bundle.c index 84660729538b..a6e1cca06172 100644 --- a/drivers/greybus/bundle.c +++ b/drivers/greybus/bundle.c @@ -166,7 +166,7 @@ static const struct dev_pm_ops gb_bundle_pm_ops = { SET_RUNTIME_PM_OPS(gb_bundle_suspend, gb_bundle_resume, gb_bundle_idle) }; -struct device_type greybus_bundle_type = { +const struct device_type greybus_bundle_type = { .name = "greybus_bundle", .release = gb_bundle_release, .pm = &gb_bundle_pm_ops, diff --git a/drivers/greybus/control.c b/drivers/greybus/control.c index 359a25841973..b5cf49d09df2 100644 --- a/drivers/greybus/control.c +++ b/drivers/greybus/control.c @@ -436,7 +436,7 @@ static void gb_control_release(struct device *dev) kfree(control); } -struct device_type greybus_control_type = { +const struct device_type greybus_control_type = { .name = "greybus_control", .release = gb_control_release, }; diff --git a/drivers/greybus/hd.c b/drivers/greybus/hd.c index 72b21bf2d7d3..e2f3496bddc3 100644 --- a/drivers/greybus/hd.c +++ b/drivers/greybus/hd.c @@ -116,7 +116,7 @@ static void gb_hd_release(struct device *dev) kfree(hd); } -struct device_type greybus_hd_type = { +const struct device_type greybus_hd_type = { .name = "greybus_host_device", .release = gb_hd_release, }; diff --git a/drivers/greybus/interface.c b/drivers/greybus/interface.c index 9ec949a438ef..a88dc701289c 100644 --- a/drivers/greybus/interface.c +++ b/drivers/greybus/interface.c @@ -765,7 +765,7 @@ static const struct dev_pm_ops gb_interface_pm_ops = { gb_interface_runtime_idle) }; -struct device_type greybus_interface_type = { +const struct device_type greybus_interface_type = { .name = "greybus_interface", .release = gb_interface_release, .pm = &gb_interface_pm_ops, diff --git a/drivers/greybus/module.c b/drivers/greybus/module.c index 36f77f9e1d74..7f7153a1dd60 100644 --- a/drivers/greybus/module.c +++ b/drivers/greybus/module.c @@ -81,7 +81,7 @@ static void gb_module_release(struct device *dev) kfree(module); } -struct device_type greybus_module_type = { +const struct device_type greybus_module_type = { .name = "greybus_module", .release = gb_module_release, }; diff --git a/drivers/greybus/svc.c b/drivers/greybus/svc.c index 0d7e749174a4..4256467fcd35 100644 --- a/drivers/greybus/svc.c +++ b/drivers/greybus/svc.c @@ -1305,7 +1305,7 @@ static void gb_svc_release(struct device *dev) kfree(svc); } -struct device_type greybus_svc_type = { +const struct device_type greybus_svc_type = { .name = "greybus_svc", .release = gb_svc_release, }; diff --git a/include/linux/greybus.h b/include/linux/greybus.h index 18c0fb958b74..5f9791fae3c0 100644 --- a/include/linux/greybus.h +++ b/include/linux/greybus.h @@ -106,12 +106,12 @@ struct dentry *gb_debugfs_get(void); extern struct bus_type greybus_bus_type; -extern struct device_type greybus_hd_type; -extern struct device_type greybus_module_type; -extern struct device_type greybus_interface_type; -extern struct device_type greybus_control_type; -extern struct device_type greybus_bundle_type; -extern struct device_type greybus_svc_type; +extern const struct device_type greybus_hd_type; +extern const struct device_type greybus_module_type; +extern const struct device_type greybus_interface_type; +extern const struct device_type greybus_control_type; +extern const struct device_type greybus_bundle_type; +extern const struct device_type greybus_svc_type; static inline int is_gb_host_device(const struct device *dev) { --- base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d change-id: 20240219-device_cleanup-greybus-c97c1ef52458 Best regards, -- Ricardo B. Marliere <ricardo(a)marliere.net>

1 year, 3 months

tree for the greybus subsystem

by Dileep Sankhla

Hello, I am fixing a coding style problem in the loopback bridge driver for the Greybus loopback module. The source code file (please see [0]) is located in the staging tree for the linux-next. In order to create the patch, I need to find the right development tree. I checked the MAINTAINERS file for the Greybus subsystem development tree but could not find one. I also searched [1] for "greybus", but without success. What is the development tree for the greybus subsystem? Regards, Dileep [0]: drivers/staging/greybus/loopback.c [1]: https://git.kernel.org/pub/scm/linux/kernel/git/

1 year, 3 months

← Newer
1
...
5
6
7
8
9
10
11
...
57
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev