In gbaudio_dapm_free_controls(), if one of the widgets is not found, an error
will be returned directly, which will cause the rest to be unable to be freed,
resulting in leak.
This patch fixes the bug. If if one of them is not found, just skip and free the others.
Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic audio module")
Reported-by: Hulk Robot <hulkci(a)huawei.com>
Signed-off-by: Wang Hai <wanghai38(a)huawei.com>
---
drivers/staging/greybus/audio_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_helper.c b/drivers/staging/greybus/audio_helper.c
index 237531ba60f3..3011b8abce38 100644
--- a/drivers/staging/greybus/audio_helper.c
+++ b/drivers/staging/greybus/audio_helper.c
@@ -135,7 +135,8 @@ int gbaudio_dapm_free_controls(struct snd_soc_dapm_context *dapm,
if (!w) {
dev_err(dapm->dev, "%s: widget not found\n",
widget->name);
- return -EINVAL;
+ widget++;
+ continue;
}
widget++;
#ifdef CONFIG_DEBUG_FS
--
2.17.1
drivers/staging/greybus/pwm.c uses the old style PWM callbacks, new drivers
should stick to the atomic API instead.
Signed-off-by: Uwe Kleine-König <uwe(a)kleine-koenig.org>
---
On 12/8/20 10:39 AM, Johan Hovold wrote:
> No sign off?
>
> Please also add a staging prefix since this part of greybus still lives
> there.
That after all these years I still fail occasionally to add a sign-off
... /me shakes his head about himself.
Anyhow, here comes a v2, also with the requested prefix.
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
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