greybus-dev

greybus-dev@lists.linaro.org

6 participants
595 discussions

[PATCH v2 0/6] Enable Greybus Audio codec driver

by Vaibhav Agarwal

The existing GB Audio codec driver is dependent on MSM8994 Audio driver. During the development stage, this dependency was configured due to various changes involved in MSM Audio driver to enable addtional codec card and some of the changes proposed in mainline ASoC framework. However, these are not the real dependencies and some of them can be easily removed. The folowing patch series includes the changes to resolve unnecessary depedencies and make the codec driver functional with the latest kernel. Patch 1,2: Incudes jack framework related changes. Patch 3,4,5: Resolves compilation error observed with the latest kernel and also provides helper APIs required to allow dynamic addition/removal of modules. Patch 6: Finally provides config options and related Makefile changes to enable GB Codec driver. Thanks to Alexandre for raising the headsup [1] and motivating me to provide the necessary changes. [1] https://lore.kernel.org/lkml/20200507212912.599433-1-alexandre.belloni@boot… Changes from v1 - Include the changes for the review comments suggested by Dan - Rebase to latest staging-next Vaibhav Agarwal (6): staging: greybus: audio: Update snd_jack FW usage as per new APIs staging: greybus: audio: Maintain jack list within GB Audio module staging: greybus: audio: Resolve compilation errors for GB codec module staging: greybus: audio: Resolve compilation error in topology parser staging: greybus: audio: Add helper APIs for dynamic audio modules staging: greybus: audio: Enable GB codec, audio module compilation. drivers/staging/greybus/Kconfig | 14 +- drivers/staging/greybus/Makefile | 6 +- drivers/staging/greybus/audio_codec.c | 178 +++++++++++--------- drivers/staging/greybus/audio_codec.h | 12 +- drivers/staging/greybus/audio_helper.c | 197 +++++++++++++++++++++++ drivers/staging/greybus/audio_helper.h | 17 ++ drivers/staging/greybus/audio_module.c | 15 +- drivers/staging/greybus/audio_topology.c | 128 +++++++-------- 8 files changed, 412 insertions(+), 155 deletions(-) create mode 100644 drivers/staging/greybus/audio_helper.c create mode 100644 drivers/staging/greybus/audio_helper.h base-commit: af7b4801030c07637840191c69eb666917e4135d -- 2.26.2

5 years, 4 months

[PATCH AUTOSEL 4.9 45/50] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Sasha Levin

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 5649ef1e379d..82a1c2cf6687 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -413,6 +413,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -471,9 +472,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

5 years, 4 months

[PATCH AUTOSEL 4.14 64/72] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Sasha Levin

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 101ca5097fc9..93e2c091c565 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -412,6 +412,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -470,9 +471,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

5 years, 4 months

[PATCH AUTOSEL 4.19 095/106] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Sasha Levin

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 38e85033fc4b..afb2e5e5111a 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -411,6 +411,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -469,9 +470,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

5 years, 4 months

[PATCH AUTOSEL 5.4 155/175] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Sasha Levin

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 68c5718be827..c4b16bb5c1a4 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -411,6 +411,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -469,9 +470,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

5 years, 4 months

[PATCH AUTOSEL 5.7 247/274] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Sasha Levin

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 68c5718be827..c4b16bb5c1a4 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -411,6 +411,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -469,9 +470,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

5 years, 4 months

[PATCH AUTOSEL 5.6 172/606] staging: greybus: Fix uninitialized scalar variable

by Sasha Levin

From: Oscar Carter <oscar.carter(a)gmx.com> commit 34625c1931f8204c234c532b446b9f53c69f4b68 upstream. In the "gb_tty_set_termios" function the "newline" variable is declared but not initialized. So the "flow_control" member is not initialized and the OR / AND operations with itself results in an undefined value in this member. The purpose of the code is to set the flow control type, so remove the OR / AND self operator and set the value directly. Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable") Fixes: e55c25206d5c9 ("greybus: uart: Handle CRTSCTS flag in termios") Signed-off-by: Oscar Carter <oscar.carter(a)gmx.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200510101426.23631-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/greybus/uart.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c index 55c51143bb09..4ffb334cd5cd 100644 --- a/drivers/staging/greybus/uart.c +++ b/drivers/staging/greybus/uart.c @@ -537,9 +537,9 @@ static void gb_tty_set_termios(struct tty_struct *tty, } if (C_CRTSCTS(tty) && C_BAUD(tty) != B0) - newline.flow_control |= GB_SERIAL_AUTO_RTSCTS_EN; + newline.flow_control = GB_SERIAL_AUTO_RTSCTS_EN; else - newline.flow_control &= ~GB_SERIAL_AUTO_RTSCTS_EN; + newline.flow_control = 0; if (memcmp(&gb_tty->line_coding, &newline, sizeof(newline))) { memcpy(&gb_tty->line_coding, &newline, sizeof(newline)); -- 2.25.1

5 years, 4 months

[RESEND PATCH v1 0/6] Enable Greybus Audio codec driver

by Vaibhav Agarwal

[REQUEST] This patch series intends to "Enable Greybus Audio codec driver" existing in the staging tree. I have shared the original patch series with Greybus-Dev mailing list and as per the suggestion from Alexandre, I'm also interested to push Greybus Audio to sound soc tree. Thus, now I'm resending it to ASoc maintainers for review. Following is the top level SW design for GB Codec driver and GB Audio modules. +--------------+ +-------------->+GBA Module 1 | | +--------------+ +-----------------------+ | | | | | Greybus | +--------------+ | SND SOC | Audio +-------------->+GBA Module 2 | | Framework | Codec | +--------------+ | | Driver | | | | +-----------------------+ +--------------+ +-------------->+GBA Module N | +--------------+ Patch 5 contains the changes to provide helper APIs to link DAPM DAI widgets for the module added and remove/free component controls for the module removed dynamically. Eventually, I propose to extend snd_soc_xxx APIs for this purpose. Kindly share your inputs. [COVER LETTER] The existing GB Audio codec driver is dependent on MSM8994 Audio driver. During the development stage, this depdency was configured due to various changes involved in MSM Audio driver to enable addtional codec card and some of the changes proposed in mainline ASoC framework. However, these are not the real dependencies and some of them can be easily removed. The folowing patch series includes the changes to resolve unnecessary depedencies and make the codec driver functional with the latest kernel. Patch 1,2: Incudes jack framework related changes. Patch 3,4,5: Resolves compilation error observed with the latest kernel and also provides helper APIs required to allow dynamic addition/removal of modules. Patch 6: Finally provides config options and related Makefile changes to enable GB Codec driver. Thanks to Alexandre for raising the headsup [1] and motivating me to provide the necessary changes. [1] https://lore.kernel.org/lkml/20200507212912.599433-1-alexandre.belloni@boot… Vaibhav Agarwal (6): staging: greybus: audio: Update snd_jack FW usage as per new APIs staging: greybus: audio: Maintain jack list within GB Audio module staging: greybus: audio: Resolve compilation errors for GB codec module staging: greybus: audio: Resolve compilation error in topology parser staging: greybus: audio: Add helper APIs for dynamic audio modules staging: greybus: audio: Enable GB codec, audio module compilation. drivers/staging/greybus/Kconfig | 14 +- drivers/staging/greybus/Makefile | 6 +- drivers/staging/greybus/audio_codec.c | 187 +++++++++++++-------- drivers/staging/greybus/audio_codec.h | 12 +- drivers/staging/greybus/audio_helper.c | 197 +++++++++++++++++++++++ drivers/staging/greybus/audio_helper.h | 17 ++ drivers/staging/greybus/audio_module.c | 20 +-- drivers/staging/greybus/audio_topology.c | 130 +++++++-------- 8 files changed, 427 insertions(+), 156 deletions(-) create mode 100644 drivers/staging/greybus/audio_helper.c create mode 100644 drivers/staging/greybus/audio_helper.h base-commit: ae73e7784871ebe2c43da619b4a1e2c9ff81508d -- 2.26.2

5 years, 4 months

[PATCH 0/8] Add helper for accessing Power Management callbacs

by Krzysztof Wilczyński

This series aims to add a new driver_to_pm() helper allowing for accessing the Power Management callbacs for a particular device. Access to the callbacs (struct dev_pm_ops) is normally done through using the pm pointer that is embedded within the device_driver struct. This new helper allows for the code required to reference the pm pointer and access Power Management callbas to be simplified. Changing the following: struct device_driver *drv = dev->driver; if (dev->driver && dev->driver->pm && dev->driver->pm->prepare) { int ret = dev->driver->pm->prepare(dev); To: const struct dev_pm_ops *pm = driver_to_pm(dev->driver); if (pm && pm->prepare) { int ret = pm->prepare(dev); Or, changing the following: const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL; To: const struct dev_pm_ops *pm = driver_to_pm(dev->driver); This series builds on top of the previous commit 6da2f2ccfd2d ("PCI/PM: Make power management op coding style consistent") that had an aim to make accessing the Power Managemnet callbacs more consistent. No functional change intended. Links: https://lore.kernel.org/driverdev-devel/20191014230016.240912-6-helgaas@ker… https://lore.kernel.org/driverdev-devel/8592302.r4xC6RIy69@kreacher/ https://lore.kernel.org/driverdev-devel/20191016135002.GA24678@kadam/ Krzysztof Wilczyński (8): driver core: Add helper for accessing Power Management callbacs ACPI: PM: Use the new device_to_pm() helper to access struct dev_pm_ops greybus: Use the new device_to_pm() helper to access struct dev_pm_ops scsi: pm: Use the new device_to_pm() helper to access struct dev_pm_ops usb: phy: fsl: Use the new device_to_pm() helper to access struct dev_pm_ops PCI/PM: Use the new device_to_pm() helper to access struct dev_pm_ops PM: Use the new device_to_pm() helper to access struct dev_pm_ops net/iucv: Use the new device_to_pm() helper to access struct dev_pm_ops drivers/acpi/device_pm.c | 5 ++- drivers/base/power/domain.c | 12 ++++-- drivers/base/power/generic_ops.c | 65 ++++++++++++++------------------ drivers/base/power/main.c | 48 +++++++++++++++-------- drivers/base/power/runtime.c | 7 ++-- drivers/greybus/bundle.c | 4 +- drivers/pci/pci-driver.c | 32 ++++++++-------- drivers/scsi/scsi_pm.c | 8 ++-- drivers/usb/phy/phy-fsl-usb.c | 11 ++++-- include/linux/device/driver.h | 15 ++++++++ net/iucv/iucv.c | 30 +++++++++------ 11 files changed, 138 insertions(+), 99 deletions(-) -- 2.26.2

5 years, 5 months

[PATCH] staging: greybus: loopback: fix a spelling error.

by Till Varoquaux

Successed -> succeeded. Signed-off-by: Till Varoquaux <till.varoquaux(a)gmail.com> --- drivers/staging/greybus/loopback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index 583d9708a191..2471448ba42a 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -135,7 +135,7 @@ static ssize_t name##_##field##_show(struct device *dev, \ char *buf) \ { \ struct gb_loopback *gb = dev_get_drvdata(dev); \ - /* Report 0 for min and max if no transfer successed */ \ + /* Report 0 for min and max if no transfer succeeded */ \ if (!gb->requests_completed) \ return sprintf(buf, "0\n"); \ return sprintf(buf, "%" #type "\n", gb->name.field); \ -- 2.25.4

5 years, 5 months

← Newer
1
...
35
36
37
38
39
40
41
...
60
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev