On 12/27/21 8:02 PM, Jiasheng Jiang wrote:
> Sorry the previous email is forgetten to wrap line.
> This email is corrected and the content is the same.
>
> On Mon, Dec 27, 2021 at 11:54:10PM +0800, Alex Elder wrote:
>> I think this is a good change, but I would like you to improve
>> the description, and fix some different bugs introduced by your
>> change.
>>
>> What you are specifically doing is checking for a null return
>> from devm_kcalloc() in gb_generate_enum_strings(), and are
>> returning the NULL pointer if that occurs. That means you
>> need to update all the callers of gb_generate_enum_strings()
>> to also handle a possible null return value.
>>
>> The fix does a good thing, and your description is correct
>> about what you are fixing. But it should supply more
>> complete context for the change.
>
> Thanks for your advice, I will correct my description in next version.
> But I still have some question about the devm_kzalloc().
>
>> You can't simply return here. If you look a bit above this,
>> where the call to allocate a control structure is done, you
>> see that a NULL return there jumps to the "error" label, so
>> any already allocated and initialized control widgets get
>> cleaned up before returning.
>
> Actually, I have already thought of whether it needs to free after the
> devm_kzalloc().
> As we can find in the gbaudio_tplg_create_widget(), the widget_kctls is
> allocated by devm_kzalloc(), but isn't released when
> gbaudio_tplg_create_wcontrol() fails and goto error.
> And I check of the comment of the devm_kmalloc() in `drivers/base/devres.c`,
> because devm_kzalloc() returns devm_kmalloc().
> And it says that "Memory allocated with this function is automatically
> freed on driver detach."
> So there is no need to free the memory manually.
> Is that right?
You are partially right, but you're missing something. Yes, anything
allocated with devm_kzalloc() will be freed automatically when the
last reference to the device is dropped.
But the two places you're returning are in the middle of a loop (in
gbaudio_tplg_create_widget() and gbaudio_tplg_process_kcontrols()).
Each is building up a sort of hierarchical data structure, and as
you can see, the existing code takes care to de-construct the partially
built structure in the event an error occurs before it completes.
There is a chance that your simple return would "work", but by
reading the surrounding code you should recognize that the proper
way to handle the error is to jump to the cleanup at the end.
The other alternative would be to fix those functions so they
don't do that controlled cleanup on error and simply return
early (as you were proposing). But without digging deeper, I
would assume the original developers designed it this way
very intentionally, because it avoids a problem somewhere.
-Alex
> And I am sorry again because of the lack of the above explanation in my
> commit message.
> I will also add to my new commit.
>
> Thanks,
> Jiang
>
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the greybus audio code to use default_groups field which
has been the preferred way since aa30f47cf666 ("kobject: Add support for
default attribute groups to kobj_type") so that we can soon get rid of
the obsolete default_attrs field.
Cc: Vaibhav Agarwal <vaibhav.sr(a)gmail.com>
Cc: Mark Greer <mgreer(a)animalcreek.com>
Cc: Johan Hovold <johan(a)kernel.org>
Cc: Alex Elder <elder(a)kernel.org>
Cc: greybus-dev(a)lists.linaro.org
Cc: linux-staging(a)lists.linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/greybus/audio_manager_module.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager_module.c b/drivers/staging/greybus/audio_manager_module.c
index 525cf8f8394f..0a0f0a394c84 100644
--- a/drivers/staging/greybus/audio_manager_module.c
+++ b/drivers/staging/greybus/audio_manager_module.c
@@ -142,11 +142,12 @@ static struct attribute *gb_audio_module_default_attrs[] = {
&gb_audio_module_op_devices_attribute.attr,
NULL, /* need to NULL terminate the list of attributes */
};
+ATTRIBUTE_GROUPS(gb_audio_module_default);
static struct kobj_type gb_audio_module_type = {
.sysfs_ops = &gb_audio_module_sysfs_ops,
.release = gb_audio_module_release,
- .default_attrs = gb_audio_module_default_attrs,
+ .default_groups = gb_audio_module_default_groups,
};
static void send_add_uevent(struct gb_audio_manager_module *module)
--
2.34.1
On 12/24/21 3:03 AM, Jiasheng Jiang wrote:
> As the possible alloc failure of devm_kcalloc, it could return null
> pointer.
> To prevent the dereference of the null pointer, it should be checked.
I think this is a good change, but I would like you to improve
the description, and fix some different bugs introduced by your
change.
What you are specifically doing is checking for a null return
from devm_kcalloc() in gb_generate_enum_strings(), and are
returning the NULL pointer if that occurs. That means you
need to update all the callers of gb_generate_enum_strings()
to also handle a possible null return value.
The fix does a good thing, and your description is correct
about what you are fixing. But it should supply more
complete context for the change.
More below.
> Fixes: e65579e335da ("greybus: audio: topology: Enable enumerated control support")
> Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn>
> ---
> drivers/staging/greybus/audio_topology.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/staging/greybus/audio_topology.c b/drivers/staging/greybus/audio_topology.c
> index 1fc7727ab7be..e9f47a1f0d28 100644
> --- a/drivers/staging/greybus/audio_topology.c
> +++ b/drivers/staging/greybus/audio_topology.c
> @@ -146,7 +146,11 @@ static const char **gb_generate_enum_strings(struct gbaudio_module_info *gb,
> __u8 *data;
>
> items = le32_to_cpu(gbenum->items);
> +
> strings = devm_kcalloc(gb->dev, items, sizeof(char *), GFP_KERNEL);
> + if (!strings)
> + return NULL;
> +
> data = gbenum->names;
>
> for (i = 0; i < items; i++) {
> @@ -654,7 +658,10 @@ static int gbaudio_tplg_create_enum_kctl(struct gbaudio_module_info *gb,
>
> /* since count=1, and reg is dummy */
> gbe->items = le32_to_cpu(gb_enum->items);
> +
> gbe->texts = gb_generate_enum_strings(gb, gb_enum);
> + if (!gbe->texts)
> + return -ENOMEM;
>
> /* debug enum info */
> dev_dbg(gb->dev, "Max:%d, name_length:%d\n", gbe->items,
> @@ -861,7 +868,10 @@ static int gbaudio_tplg_create_enum_ctl(struct gbaudio_module_info *gb,
>
> /* since count=1, and reg is dummy */
> gbe->items = le32_to_cpu(gb_enum->items);
> +
> gbe->texts = gb_generate_enum_strings(gb, gb_enum);
> + if (!gbe->texts)
> + return -ENOMEM;
>
> /* debug enum info */
> dev_dbg(gb->dev, "Max:%d, name_length:%d\n", gbe->items,
> @@ -1032,8 +1042,12 @@ static int gbaudio_tplg_create_widget(struct gbaudio_module_info *module,
> csize += offsetof(struct gb_audio_ctl_elem_info, value);
> csize += offsetof(struct gb_audio_enumerated, names);
> csize += le16_to_cpu(gbenum->names_length);
> +
> control->texts = (const char * const *)
> gb_generate_enum_strings(module, gbenum);
> + if (!control->texts)
> + return -ENOMEM;
> +
You can't simply return here. If you look a bit above this,
where the call to allocate a control structure is done, you
see that a NULL return there jumps to the "error" label, so
any already allocated and initialized control widgets get
cleaned up before returning.
> control->items = le32_to_cpu(gbenum->items);
> } else {
> csize = sizeof(struct gb_audio_control);
> @@ -1181,8 +1195,12 @@ static int gbaudio_tplg_process_kcontrols(struct gbaudio_module_info *module,
> csize += offsetof(struct gb_audio_ctl_elem_info, value);
> csize += offsetof(struct gb_audio_enumerated, names);
> csize += le16_to_cpu(gbenum->names_length);
> +
> control->texts = (const char * const *)
> gb_generate_enum_strings(module, gbenum);
> + if (!control->texts)
> + return -ENOMEM;
> +
You have basically the same issue here. You can't just return,
you must do some cleanup too.
-Alex
> control->items = le32_to_cpu(gbenum->items);
> } else {
> csize = sizeof(struct gb_audio_control);
>
On Wed, Dec 22, 2021 at 10:54:41AM +0100, Lukas Bulwahn wrote:
> Dear Vaibhav, dear Johan, dear Alex, dear Greg,
>
> I have seen that the greybus arche driver has been under heavy
> development in 2016 and 2017 with some further clean-up in 2019.
>
> However, so far, the config GREYBUS_ARCHE for this driver still
> depends on the out-of-tree config USB_HSIC_USB3613, with a proper
> exception made for compile testing (with COMPILE_TEST).
>
> Will this USB_HSIC_USB3613 config and driver still be added in the
> mainline kernel in the near future, so that the config dependencies
> are consistent in mainline?
Do you have this hardware? If so, we can add the driver, but given that
I did not think the chip ever actually shipped, it didn't make much
sense.
> Or, are the further out-of-tree additions still maintained for the
> current kernel and will stay out of tree? Is this arche driver not
> needed anymore and can be dropped?
Do you want to drop it as it is causing problems for you? It's a good
example driver for those wanting to create a greybus host controller
driver so it's nice to have in the tree, unless you have a different one
that should be merged instead?
thanks,
greg k-h
On Fri, Dec 17, 2021 at 11:34:08AM -0300, Jorge Eduardo Fermino Oliveia Silva wrote:
[Note: I am traveling for the next week so I won't be very responsive.]
Hi Jorge.
Before we get to the platch please remember that you should send all
Greybus patches to greybus-dev(a)lists.linaro.org and
linux-kernel(a)vger.kernel.org. I will add them in now and leave all of
the context so other can see what you sent.
> Solve CHECK: Lines should not end with a '('
>
> Reported-by: Jorge Eduardo Fermino Oliveia Silva <jorgeubermensch(a)gmail.com>
> Signed-off-by: Jorge Eduardo Fermino Oliveia Silva <jorgeubermensch(a)gmail.com>
> ---
> drivers/staging/greybus/audio_manager_private.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_manager_private.h b/drivers/staging/greybus/audio_manager_private.h
> index 2b3a766c7de7..a17f09a19014 100644
> --- a/drivers/staging/greybus/audio_manager_private.h
> +++ b/drivers/staging/greybus/audio_manager_private.h
> @@ -12,10 +12,10 @@
>
> #include "audio_manager.h"
>
> -int gb_audio_manager_module_create(
> - struct gb_audio_manager_module **module,
> - struct kset *manager_kset,
> - int id, struct gb_audio_manager_module_descriptor *desc);
> +int gb_audio_manager_module_create(struct gb_audio_manager_module **module,
> + struct kset *manager_kset,
> + int id,
> + struct gb_audio_manager_module_descriptor *desc);
>
> /* module destroyed via kobject_put */
The part you're removing has all of the parameters at the same
indentation level and what you adding has them at two different
indentation levels so I'm not sure this is a step forward. Since the
kernel coding style doesn't address this specific case, AFAICS, I would
leave it as is despite the complaint. If others disagree then go ahead
as I really don't care much either way.
Mark
--
On 12/11/21 9:16 PM, Jason Wang wrote:
> The double `for' in the comment in line 81 is repeated. Remove one
> of them from the comment.
This looks fine. But it's so trivial... Are you aware
of *any* other similar trivial problems in comments that
could be fixed together with this? If so, I would prefer
that.
If you've looked, and there are no others:
Reviewed-by: Alex Elder <elder(a)linaro.org>
> Signed-off-by: Jason Wang <wangborong(a)cdjrlc.com>
> ---
> drivers/greybus/es2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/greybus/es2.c b/drivers/greybus/es2.c
> index 15661c7f3633..e89cca015095 100644
> --- a/drivers/greybus/es2.c
> +++ b/drivers/greybus/es2.c
> @@ -78,7 +78,7 @@ struct es2_cport_in {
> * @hd: pointer to our gb_host_device structure
> *
> * @cport_in: endpoint, urbs and buffer for cport in messages
> - * @cport_out_endpoint: endpoint for for cport out messages
> + * @cport_out_endpoint: endpoint for cport out messages
> * @cport_out_urb: array of urbs for the CPort out messages
> * @cport_out_urb_busy: array of flags to see if the @cport_out_urb is busy or
> * not.
>