On 11/15/20 9:17 AM, Greg Kroah-Hartman wrote:
> On Sun, Nov 15, 2020 at 03:53:16PM +0100, Emmanouil Perselis wrote:
>> This patch fixes the warning "static const char * array should
>> probably be static const char * const" in
>> drivers/staging/greybus/audio_manager_module.c
>> I think Greg's patch bot is telling you that you need
>> to carbon-copy the mailing list on your patch submission,
>> not just address it to the maintainers.
Added addresses to carbon copy.
>> -Alex
>>
>> Signed-off-by: Emmanouil Perselis <perselis.e(a)gmail.com>
>> ---
>> drivers/staging/greybus/audio_manager_module.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/greybus/audio_manager_module.c b/drivers/staging/greybus/audio_manager_module.c
>> index 2bfd804183c4..6ef7381f4e85 100644
>> --- a/drivers/staging/greybus/audio_manager_module.c
>> +++ b/drivers/staging/greybus/audio_manager_module.c
>> @@ -158,7 +158,7 @@ static void send_add_uevent(struct gb_audio_manager_module *module)
>> char ip_devices_string[64];
>> char op_devices_string[64];
>>
>> - char *envp[] = {
>> + static const char * const envp[] = {
>> name_string,
>> vid_string,
>> pid_string,
>> --
>> 2.20.1
>>
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
> a patch that has triggered this response. He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created. Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - Your patch was sent privately to Greg. Kernel development is done in
> public, please always cc: a public mailing list with a patch
> submission. Using the tool, scripts/get_maintainer.pl on the patch
> will tell you what mailing list to cc.
>
> - You did not specify a description of why the patch is needed, or
> possibly, any description at all, in the email body. Please read the
> section entitled "The canonical patch format" in the kernel file,
> Documentation/SubmittingPatches for what is needed in order to
> properly describe the change.
>
> - You did not write a descriptive Subject: for the patch, allowing Greg,
> and everyone else, to know what this patch is all about. Please read
> the section entitled "The canonical patch format" in the kernel file,
> Documentation/SubmittingPatches for what a proper Subject: line should
> look like.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot
>
Signed-off-by: Emmanouil Perselis <perselis.e(a)gmail.com>
---
drivers/staging/greybus/audio_manager_module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager_module.c b/drivers/staging/greybus/audio_manager_module.c
index 2bfd804183c4..6ef7381f4e85 100644
--- a/drivers/staging/greybus/audio_manager_module.c
+++ b/drivers/staging/greybus/audio_manager_module.c
@@ -158,7 +158,7 @@ static void send_add_uevent(struct gb_audio_manager_module *module)
char ip_devices_string[64];
char op_devices_string[64];
- char *envp[] = {
+ static const char * const envp[] = {
name_string,
vid_string,
pid_string,
--
2.20.1
When gb_audio_apbridgea_register_cport failed, maybe:
1) gb_pm_runtime_get_sync failed, usage counter remained unchanged;
2) gb_hd_output failed, usage counter remained increased;
In error state, there are two different states in usage cpounter. So,
if gb_hd_output failed, we should call gb_pm_runtime_put_autosuspend
ot decrease usage counter for balabce preventing reference leak. And
we fixed it by add gb_pm_runtime_put_autosuspend when gb_hd_output
failed.
Fixes: 6ba7fad430d63 ("greybus: audio: add runtime pm support")
Signed-off-by: Zhang Qilong <zhangqilong3(a)huawei.com>
---
Changelog:
v2
- fix the name for fixed commit id
---
drivers/staging/greybus/audio_apbridgea.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_apbridgea.c b/drivers/staging/greybus/audio_apbridgea.c
index 26117e390deb..50545fd9756c 100644
--- a/drivers/staging/greybus/audio_apbridgea.c
+++ b/drivers/staging/greybus/audio_apbridgea.c
@@ -42,8 +42,12 @@ int gb_audio_apbridgea_register_cport(struct gb_connection *connection,
if (ret)
return ret;
- return gb_hd_output(connection->hd, &req, sizeof(req),
+ ret = gb_hd_output(connection->hd, &req, sizeof(req),
GB_APB_REQUEST_AUDIO_CONTROL, true);
+ if (ret)
+ gb_pm_runtime_put_autosuspend(connection->bundle);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(gb_audio_apbridgea_register_cport);
--
2.25.4
Simplify the return expression.
Signed-off-by: Liu Shixin <liushixin2(a)huawei.com>
---
drivers/greybus/svc.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/greybus/svc.c b/drivers/greybus/svc.c
index ce7740ef449b..dca251172cd2 100644
--- a/drivers/greybus/svc.c
+++ b/drivers/greybus/svc.c
@@ -1345,18 +1345,12 @@ struct gb_svc *gb_svc_create(struct gb_host_device *hd)
int gb_svc_add(struct gb_svc *svc)
{
- int ret;
-
/*
* The SVC protocol is currently driven by the SVC, so the SVC device
* is added from the connection request handler when enough
* information has been received.
*/
- ret = gb_connection_enable(svc->connection);
- if (ret)
- return ret;
-
- return 0;
+ return gb_connection_enable(svc->connection);
}
static void gb_svc_remove_modules(struct gb_svc *svc)
--
2.25.1
On Thu, Sep 03, 2020 at 09:57:42AM +0800, Ye Bin wrote:
> In gb_bootrom_get_firmware funtion fw maybe null, we must test it before
> use it.
No, fw will never be NULL when ret is zero so the current code is
correct.
Greg, please drop this one from your testing branch.
> Signed-off-by: Ye Bin <yebin10(a)huawei.com>
> ---
> drivers/staging/greybus/bootrom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c
> index a8efb86de140..e1573a5febf0 100644
> --- a/drivers/staging/greybus/bootrom.c
> +++ b/drivers/staging/greybus/bootrom.c
> @@ -298,7 +298,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op)
>
> queue_work:
> /* Refresh timeout */
> - if (!ret && (offset + size == fw->size))
> + if (!ret && fw && (offset + size == fw->size))
> next_request = NEXT_REQ_READY_TO_BOOT;
> else
> next_request = NEXT_REQ_GET_FIRMWARE;
Johan
Hi,
This Patch series is an update to the mikroBUS driver
RFC v1 Patch : https://lkml.org/lkml/2020/7/24/518 .
The mikrobus driver is updated to add mikrobus ports from device-tree
overlays, the debug interfaces for adding mikrobus ports through sysFS
is removed, and the driver considers the extended usage of mikrobus
port pins from their standard purposes.
change log:
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 protcol enums
Fix cases of wrong indendation, ignoring return values, freeing
allocated resources in case of errors and other style suggestions
in v1 review.
Vaishnav M A (3):
add mikrobus descriptors to greybus_manifest
mikroBUS driver for add-on boards on mikrobus ports
Add Device Tree Bindings for mikroBUS port
.../bindings/misc/linux,mikrobus.txt | 81 ++
MAINTAINERS | 6 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/mikrobus/Kconfig | 16 +
drivers/misc/mikrobus/Makefile | 7 +
drivers/misc/mikrobus/mikrobus_core.c | 692 ++++++++++++++++++
drivers/misc/mikrobus/mikrobus_core.h | 191 +++++
drivers/misc/mikrobus/mikrobus_manifest.c | 444 +++++++++++
drivers/misc/mikrobus/mikrobus_manifest.h | 21 +
drivers/misc/mikrobus/mikrobus_port.c | 171 +++++
include/linux/greybus/greybus_manifest.h | 47 ++
12 files changed, 1678 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/linux,mikrobus.txt
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
create mode 100644 drivers/misc/mikrobus/mikrobus_port.c
--
2.25.1