drivers/staging/greybus/pwm.c uses the old style PWM callbacks, new drivers
should stick to the atomic API instead.
---
drivers/staging/greybus/TODO | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/greybus/TODO b/drivers/staging/greybus/TODO
index 31f1f2cb401c..6461e0132fe3 100644
--- a/drivers/staging/greybus/TODO
+++ b/drivers/staging/greybus/TODO
@@ -1,3 +1,5 @@
* Convert all uses of the old GPIO API from <linux/gpio.h> to the
GPIO descriptor API in <linux/gpio/consumer.h> and look up GPIO
lines from device tree or ACPI.
+* Make pwm.c use the struct pwm_ops::apply instead of ::config, ::set_polarity,
+ ::enable and ::disable.
--
2.29.2
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